On 21 March 2012 at 08:49, Hadley Wickham wrote: | > Sure, very valid question. I tend to do two things: | > | > a) at times experiment/try/play with the inline package and cxxfunction | > | > b) much more often, work with a package where, for force of habit, my | > typical workflow often is | > | > $ R CMD INSTALL mypkg && r -lmypkg -e 'someFunctionToTickle(3.14)' | > | > which does a 'library(mypkg)' for me (which is how r resolves the -l | > arguments) and then executes the R expression | > | > as I never got really happy with any of the unloading attempts. Littler's r | > starts very quickly and gives me a guaranteed clean slate, so I tend to work | > from there. | | Hmmmm, interesting. But R CMD install is still fairly slow, right? I | guess because you're installing directly from the package dir (and not | from a tarball built via R CMD build) it's a bit faster, and only | changed files need to be recompiled. You introduce a slight risk of
Plus I call 'g++' et al as 'ccache g++' so it's all cached in case of no changes, thanks to the amazing compiler caching package ccache (which is pretty standard on Linux). And you can tell R CMD INSTALL to skip steps like vignettes, tests, cleanup, ... to just load the R and C++ code. | problems caused by build artefacts left by previous runs, but that's | probably worth it for the speed (and you know much more about the | tradeoffs here than I do). Dunno. I just /like/ to know I work with real fresh R sessions without side-effects from anything lingering --- with the whole .onLoad, .onAttach, import from Namespace, ... soup lingering, this gives me some clarity. But "there is more than one way to do it" as they say... Dirk -- "Outside of a dog, a book is a man's best friend. Inside of a dog, it is too dark to read." -- Groucho Marx _______________________________________________ Rcpp-devel mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
