You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The foreach package has a pretty good heuristic for auto-exporting variables from the user's session:
> library(foreach)
> library(doParallel)
> library(parallel)
> cl <- makeForkCluster()
> registerDoParallel(cl)
>
> f <- foreach(x=1:10, .combine=c, .verbose=TRUE)
> myvar <- 5
> myfunc <- function(i) i+ myvar
> myfunc2 <- function(j) myfunc(j)
> f %dopar% myfunc2(x)
automatically exporting the following variables from the local environment:
myfunc, myfunc2, myvar
...
[1] 6 7 8 9 10 11 12 13 14 15
Notice that it fully follows the trail of function calls all the way to myvar. It is implemented in foreach::getexports, foreach:::getsyms, foreach:::expandsyms. You can see how it is used in e.g. doParallel:::doParallelSNOW.
Just dropping by here to mention the globals package, which was created to attack these type of problems. The objective is to have one go-to package that provides a unified approach for static code inspection tailored to identifying globals/unknowns that need to be frozen/exported in asynchronous processing.
The package is currently leveraging the code walkers of the codetools package. Since codetools is rather conservative when it comes to identifying globals, and for our purposes we can allow ourselves to be much more liberal ("not much damage is done if we export a few falsely identified global variables"), I'm predicting that at some point globals will implement its own code walkers.
Systematically integrate function to check on non-local use into bplapply and friends
The text was updated successfully, but these errors were encountered: