preliminary parallel support

For review...

I bumped the version to 0.9 only to distinguish my dev version (that we use in production) from the regular one.

As discussed, it especially works well on modern OSes (meaning supporting fork). Windows users can still use it by instantiating a cluster, and making sure it is properly initialized. 
I am sure there are a lot of stuff to tweak or improve.
 

Can we attack this from the other direction? What's the minimum that
testhat needs to export so that you can implement this outside? I need to
get a new version out in the next couple of days to fix r-devel problems,
so this is a good opportunity to include smaller stuff in a release.

On Wednesday, September 17, 2014, Karl Forner <notifications@github.com>
wrote:

> In R/parallel.r:
>
> > @@ -0,0 +1,100 @@
> > +PSOCK <- function() 'PSOCK'
> > +FORK <- function() 'FORK'
> > +
> > +
> > +# modified version of parallel:::clusterApplyLB to add callback support
> > +# to monitor progress
> > +cluster_lapply_lb <- function (cl, x, fun, progress = NULL, ...) {
> > +  stopifnot(is.function(fun))
> > +
> > +  wrapper <- argfun <- function(i) c(list(x[[i]]), list(...))
> > +  if (!is.null(progress))
> > +    wrapper <- function(x) { y <- argfun(x); progress(y[[1]]); y }
> > +
> > +  parallel:::dynamicClusterApply(cl, fun, length(x), wrapper)
>
> The problem is that dynamicClusterApply calls recvOneResult which accesses
> .snowTimingData and accesses recvOneData. If we implement without calling
> the private functions we will end up in duplicating the whole parallel
> package. Suggestion ?
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/hadley/testthat/pull/127/files#r17650428>.
>


-- 
http://had.co.nz/