You are currently browsing the category archive for the ‘Packages’ category.
We’re pleased to announce a new version of roxygen2. The biggest news is that you can painlessly document your S4 classes, S4 methods and RC classes with roxygen2 – you can safely remove workarounds that used
@usage, and simply rely on roxygen2 to do the right thing. Roxygen2 is also much smarter when it comes to S3: you can remove existing uses of
@method, and can replace
Version 3.0 also includes many other improvements including better generation of usage, the ability to turn off wrapping in your Rd files and choose default roclets for a package, a safer
roxyngenize() if you prefer) and many other bug fixes and improvement. See the full list on the github release.
As always, you can install the latest version with
We’re very pleased to announce the release of devtools 1.4. This version brings many improvements to package installation, including automated vignette building, and a better way of referring to repos on github,
install_github("hadley/devtools"). There are also many other bug fixes and minor improvements; to see them all, please read the release notes file on github.
We’re very pleased to announce Shiny 0.8.0 (which actually went up on CRAN about two weeks ago). This release features a vastly better way to display tabular data, and new debugging tools that make it much easier to fix errors in your app.
We now support much more attractive and powerful displays of tabular data using the popular DataTables library. Our DataTables integration features pagination, searching/filtering, sorting, and more. Check out this demo to see it in action, and learn more about how to use it in your own apps by visiting the tutorial’s chapter on DataTables.
In version 0.8.0 of the Shiny package, we’ve greatly improved the set of debugging tools you can use with your Shiny apps. It’s now much easier to figure out what’s happening when things go wrong, thanks to two new features:
- Integration with the new visual debugger that’s available with RStudio v0.98. You can set breakpoints and step through your code much more easily than before.
- A new option ‘shiny.error’ which can take a function as an error handler. It is called when an error occurs in a reactive observer (e.g. when running an output rendering function). You can use options(shiny.error=traceback) to simply print a traceback, options(shiny.error=recover) for debugging from a regular R console, or options(shiny.error=browser) to jump into the RStudio visual debugger.
There have also been a few smaller tweaks and bug fixes. For the full list, you can take a look at our NEWS file.
Welcome, Yihui Xie!
If you’re reading this, there’s a good chance you have heard of Yihui Xie or have used his software; during his time as a PhD student at Iowa State University, he created the knitr, cranvas, and animation packages, among others.
We’re thrilled to announce that Yihui has joined the RStudio team! He will be one of the primary maintainers of the Shiny package and has already contributed some great improvements in the short time he has been with us.
We’re excited to announce Packrat, a new tool for managing the packages your R project depends on.
If you’ve ever been frustrated by package dependencies, whether juggling the packages needed by your own projects or getting someone else’s project to work, Packrat is for you. Similar in spirit to Bundler, Packrat understands package dependencies and manages them inside a private, project-specific library.
Packrat makes your project more isolated, portable, and reproducible. Because your project’s package dependencies travel with it, you control the environment in which your code runs. Your results are easy to duplicate on other machines, whether your own or your collaborators’.
We built Packrat to help us create self-sufficient R projects for deployment, but we think it has many other use cases. Lots more information, including installation instructions, can be found at the Packrat project page:
If you try it, we’d love to get your feedback. Leave a comment here or post in the packrat-discuss Google group.
RStudio maintains its own CRAN mirror, http://cran.rstudio.com. The server itself is a virtual machine run by Amazon’s EC2 service, and it syncs with the main CRAN mirror in Austria once per day. When you contact http://cran.rstudio.com, however, you’re probably not talking to our CRAN mirror directly. That’s because we use Amazon CloudFront, a content delivery network, which automatically distributes the content to locations all over the world. When you try to download a package from the Rstudio cloud mirror, it’ll be retrieved from a local CloudFront cache instead of the CRAN mirror itself. That means that, no matter where you are in the world, the data doesn’t need to travel very far, and so is fast to download.
To back this up with some data, we asked some friends to time downloads from all the CRAN mirrors. The RStudio mirror was not always the fastest (especially if you have a mirror nearby), but it was consistently fast around the world. (If you think you could improve on our testing methodology, the scripts and raw data are available at https://gist.github.com/hadley/5420147 – let us know what you come up with!)
You can use our mirror, even if you don’t use RStudio. (If you haven’t deliberately chosen a CRAN mirror in RStudio, we’ll use ours by default). It’s the first one in the list of mirrors (“0-Cloud”), or if you don’t want to select it every time you install a package, you can it as the default in your .Rprofile:
options(repos = c(CRAN = "http://cran.rstudio.com"))
Of course, speed isn’t the only factor you want to consider when choosing a mirror. Another important factor is reliability: is the mirror always available, and how often is it updated? CRAN provides the useful mirror monitoring report. Running a mirror is easy (it’s just a simple script run every few hours), so it’s a warning flag if a mirror has any non-green squares. We care about the availability of our mirror, and if it ever does go down, we’ll endeavour to fix it as quickly as possible.
Finally, because every download from a CRAN mirror is logged, CRAN mirrors provide a rich source of data about R and package usage. To date, it’s been hard to get access to this data. We wanted to change that, so you can now download our anonymised log data from cran-logs.rstudio.com. We’ve tried to strike a balance between utility and privacy. We’ve parsed the raw log data into fields that mean something to R users (like r version, architecture and os). The IP address is potentially revealing, so we’ve replaced it with a combination of country and a unique id within each day. This should make it possible to explore download patterns without undermining the privacy of the mirror users.
date time size r_version r_arch r_os date time size r_version r_arch r_os 1 2013-01-01 00:18:22 551371 2.15.2 x86_64 darwin9.8.0 2 2013-01-01 00:43:47 220277 2.15.2 x86_64 mingw32 3 2013-01-01 00:43:51 3505851 2.15.2 x86_64 mingw32 4 2013-01-01 00:43:53 761107 2.15.2 x86_64 mingw32 5 2013-01-01 00:31:15 187381 2.15.2 i686 linux-gnu 6 2013-01-01 00:59:46 2388932 2.15.2 x86_64 mingw32 package version country ip_id 1 knitr 0.9 RU 1 2 R.devices 2.1.3 US 2 3 PSCBS 0.30.0 US 2 4 R.oo 1.11.4 US 2 5 akima 0.5-8 US 3 6 spacetime 1.0-3 VN 4
Altogether, there’s currently around 150 megs of gzipped log files, representing over 7,000,000 package downloads. We’re looking forward to seeing what the R community does with this data, and we’ll highlight particularly interesting analyses in a future blog post. If you have any problems using the data, or you’d like to highlight a particularly interesting result, please feel free to email me.
We’re very pleased to announce the release of devtools 1.2. This version continues to make working with packages easier by increasing installation speed (skipping the build step unless
local = FALSE), enhancing vignette handling (to support the non-Sweave vignettes available in R 3.0.0), and providing better default compiler flags for C and C++ code.
Also new in this release is the
sha argument to
source_gist. If provided, this checks that the file you download is what your expected, and is an important safety feature when running scripts over the web.
Devtools 1.2 contains many other bug fixes and minor improvements; to see them all, please read the NEWS file on github.
Shiny version 0.4.0 is now available on CRAN. The most visible change is that the API has been slightly simplified. Your existing code will continue to work, although Shiny will print messages about how to migrate your code. Migration should be straightforward, as described below. It will take a bit of work to switch to the new API, but we think it’s worth it in the long run, because the new interface is somewhat simpler, and because it offers a better mapping between function names and reactive programming concepts.
We’ve also updated the Shiny tutorial to reflect the changes, and we’ve also added a some new content explaining Shiny’s reactive programming model in depth. If you want to have a better understanding of how Shiny works, see the sections under Understanding Reactivity, starting with the Reactivity Overview.
Another new feature is that Shiny now suspends outputs when they aren’t visible on the user’s web browser. For example, if your Shiny application has multiple tabs or conditional panels, Shiny will only run the calculations and send data for the currently-visible tabs and panels. This new feature will reduce network traffic and computational load on the server, resulting in a faster application.
Version 0.3.0 of Shiny is now available on CRAN. This version of Shiny has several new features and bug fixes. Some of the changes are under the hood: for example, Shiny now uses a more efficient algorithm for scheduling the execution of reactive functions. There are also some user-facing changes: for example, the new
runGitHub() function lets you download and run applications directly from a GitHub repository.
You can install the new version of Shiny with
Shiny makes it easy to develop interactive web applications that run on your own machine. But by itself, it isn’t designed to make your applications available to all comers over the internet (or intranet). You can’t run more than one Shiny application on the same port, and if your R process crashes or exits for any reason, your service becomes unavailable.
Our solution is Shiny Server, the application server for Shiny. Using Shiny Server, you can host multiple Shiny applications, as well as static web content, on a Linux server and make them available over the internet. You can specify what applications are available at what URL, or configure Shiny Server to let anyone with a user account on the server deploy their own Shiny applications. For more details, see our previous blog post.
Shiny Server is available as a public beta today. Follow the instructions on our GitHub project page to get started now!
We’re pleased to announce new versions of ggplot2 (0.9.3) and plyr (1.8). To get up and running with the new versions, start a clean R session without ggplot2 or plyr loaded, and run
install.packages(c("ggplot2", "gtable", "scales", "plyr")). Read on to find out what’s new.
Most of the changes version 0.9.3 are bug fixes. Perhaps the most visible change is that ggplot will now print out warning messages when you use
stat="bin" and also map a variable to y. For example, these are valid:
ggplot(mtcars, aes(wt, mpg)) + geom_bar(stat = "identity") ggplot(mtcars, aes(cyl)) + geom_bar(stat = "bin")
But this will result in some warnings:
ggplot(mtcars, aes(wt, mpg)) + geom_bar(stat = "bin") # The default stat for geom_bar is "bin", so this is the same as above: ggplot(mtcars, aes(wt, mpg)) + geom_bar()
The reason for this change is to make behavior more consistent –
stat_bin generates a y value, and so should not work when you also map a value to y.
For a full list of changes, please see the NEWS file.
Version 1.8 has 28 improvements and bug fixes. Among the most prominent:
- All parallel plyr functions gain a
.paroptsargument, a list of options that is passed onto
foreachwhich allows you to control parallel execution.
progress_timeis a new progress bar contributed by Mike Lawrence estimates the amount of time remaining before a job is complete
- The summarise() function now calculates columns sequentially, so you can calculate new columns from other new columns, like this:
summarise(mtcars, x = disp/10, y = x/10)
This behavior is similar to the mutate() function. Please be aware that this could change the behavior of existing code, if any columns of the output have the same name but different values as columns in the input. For example, this will result in different behavior in plyr 1.7 and 1.8:
summarise(mtcars, disp = disp/10, y = disp*10)
In the old version, the y column would equal
mtcars$disp * 10, and in the new version, it would equal
- There are a number of performance improvements:
a*plyuses more efficient indexing so should be more competitive with
idata.frameall have performance tweaks which will help a few people out a lot, and a lot of people a little.
For a full list of changes, please see the NEWS file.