The hardware and bandwidth for this mirror is donated by METANET, the Webhosting and Full Service-Cloud Provider.
If you wish to report a bug, or if you are interested in having us mirror your free-software or open-source project, please feel free to contact us at mirror[@]metanet.ch.
R packages available via the CRAN mirror network system are of consistently high quality and tend to “Just Work”. One of the many reasons for this is a good culture of “do not break other packages” which is controlled for / enacted by the CRAN maintainers. Package maintainers are expected to do their part—by checking their packages!
To take one example, Rcpp is package with a pretty large tail of dependencies: as of this writing in late 2017, about 1270 other packages use it. So 1270 other packages need to be tested. This takes time, especially when running serially. But it is easy to parallelise.
Previously, a few ad-hoc scripts (available here) were used for a number of packages. The scripts were one-offs and did their job. But with the idea of running jobs in parallel, the liteq package by Gabor Csardi fit the requirements nicely.
The first operation is to enqueue jobs. In the simplest form we do (assuming the included script is in the PATH)
The same operation can also be done from R itself, see help(enqueueJobs). A package name has to be supplied; a directory name (for the queue directory) is optional. This function uses two base R functions to get all available packages and then determine the (non-recursive, first-level) reverse dependencies of the given package. These are then added to the queue as “jobs”.
This is the second operation, and it can be done in parallel. In other words, in several shells do:
which will find the (current) queue file in the specified directory for the given package—here Rcpp. Again, this can also be done from an R prompt if prefered, see help(dequeueJobs).
Each worker, when idle, goes to the queue and requests a job, which it then labors over by testing the thus-given reverse depedency. Once done, the worker is idle and returns to the queue and the cycle repeats.
As there is absolutely no interdepedence between the tests, this parallelises easily up to the resource level of the machine.
To illustrate, “wall time” for a reverse-dependecy check of Rcpp decreased from 14.91 hours to 3.75 hours (or almost four-fold) using six workers. An earlier run of RcppArmadillo decreased from 5.87 hours to 1.92 hours (or just over three-fold) using four workers, and to 1.29 hours (or by 4.5) using six workers (and a fresh ccache, see here for its impact). In all cases the machine which was used was generally not idle.
The following screenshot shows a run for RcppArmadillo with six workers. It shows the successes in green, skipped jobs in blue (from packages which sometimes would result in runaway tests), and no failures (which would be shown in red).
The split screen and additional tables are thanks to the wonderful byobu wrapper around tmux.
The scripts use an internal YAML file access via the config package by JJ. The following locations are searched: .prrd.yaml, ~/.R/prrd.yaml, ~/.prrd.yaml, and /etc/R/prrd.yaml. For my initial tests I used these values:
## config for prrd package
default:
setup: "~/git/prrd/local/setup.R"
workdir: "/tmp/prrd"
libdir: "/tmp/prrd/lib"
debug: "false"
verbose: "false"The workdir and libdir variables specify where tests are run and which additonal library directory is used. A more interesting variable is setup, which points to a helper script which gets sourced. This permits setting of the CRAN repo address and any additonal environment variables needed for tests. My current script is in the repository.
While the package is new, it has already been used for a few complete reverse depends tests runs.
The package is now on CRAN and can be installed via a standard
install.packages("prrd")Dirk Eddelbuettel
GPL (>= 2)
These binaries (installable software) and packages are in development.
They may not be fully stable and should be used with caution. We make no claims about them.