On Fri, Jan 17, 2014 at 12:43 AM, Gabriel Becker <gmbec...@ucdavis.edu> wrote: > There were some deeper issues with what you asked, though. Sourcing an R > file will have no effect on a package in the namespace at all unless you > are using something like ESS's developer mode which sources the file into > the package namespace. Furthermore, C code included in R packages is only > compiled at installation from source or binary build time. > > Even if you are using a developer mode, sourcing an R file will have no > effect on a) the shared object library (DLL/so/dylib) available in the R > session, nor which shared objects are associated with the package. There > are ways to unload shared libraries within an R session, but personally I > tend to avoid them. The best way of being absolutely sure that the right > shared library is getting used is to reinstall the package, then close the > R session and restart.
I value having a short turnaround time in debugging over such absolute surety, so I would recommend using load_all from Hadley's devtools package, which is usually able to recompile and reload the library without restarting R. I think the OP indicated that they are using RStudio, which should have a way to drive devtools (still, "source" would be the wrong command.) Peter ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel