Hi! I've been browsing through the last months' archive and I can't
find an answer to my question, so here it is (let's hope it's not too
obvious):
I'm working on extensions of an R library, and I would be very
surprised if everyone developing R packages is doing the following, as I do:
1.- Write down a modification of an R file
2.- Exit the current R session
3.- Install the package as root (sudo R CMD INSTALL...)
4.- Launch a new R session
5.- Test the change, if it does not work, go back to 1 or debug.
6.- Finish.
Is this the proper (but quite awkward) way to proceed or there is an
alternative to skip steps 2 to 4? I'm using emacs with ESS under linux.
Thank you in advance for your time! Best regards,
-- --
Jose Luis Aznarte M. http://decsai.ugr.es/~jlaznarte
Department of Computer Science and Artificial Intelligence
Universidad de Granada Tel. +34 - 958 - 24 04 67
GRANADA (Spain) Fax: +34 - 958 - 24 00 79
It depends on the change, but I never install an unreleased package into the main library, so do not need sudo for 3). I have a 'test-library' library that is in R_LIBS in ~/.Rprofile and I use solely for package testing. If this is a change to the NAMESPACE or an unexported object you do need to re-install, but many changes can be tested via source()ing the new file and example(). If the test suite is good enough, 'R CMD check' may do all the tests you need without installing the test package anywhere else. On Mon, 26 Mar 2007, "Jos? Luis Aznarte M." wrote:> Hi! I've been browsing through the last months' archive and I can't > find an answer to my question, so here it is (let's hope it's not too > obvious): > I'm working on extensions of an R library, and I would be very > surprised if everyone developing R packages is doing the following, as I do: > > 1.- Write down a modification of an R file > 2.- Exit the current R session > 3.- Install the package as root (sudo R CMD INSTALL...) > 4.- Launch a new R session > 5.- Test the change, if it does not work, go back to 1 or debug. > 6.- Finish. > > Is this the proper (but quite awkward) way to proceed or there is an > alternative to skip steps 2 to 4? I'm using emacs with ESS under linux. > Thank you in advance for your time! Best regards, > > -- -- > Jose Luis Aznarte M. http://decsai.ugr.es/~jlaznarte > Department of Computer Science and Artificial Intelligence > Universidad de Granada Tel. +34 - 958 - 24 04 67 > GRANADA (Spain) Fax: +34 - 958 - 24 00 79 > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
Jos? Luis Aznarte M. wrote:> Hi! I've been browsing through the last months' archive and I can't > find an answer to my question, so here it is (let's hope it's not too > obvious): > I'm working on extensions of an R library, and I would be very > surprised if everyone developing R packages is doing the following, as I do: > > 1.- Write down a modification of an R file > 2.- Exit the current R session > 3.- Install the package as root (sudo R CMD INSTALL...) > 4.- Launch a new R session > 5.- Test the change, if it does not work, go back to 1 or debug. > 6.- Finish. > > Is this the proper (but quite awkward) way to proceed or there is an > alternative to skip steps 2 to 4? I'm using emacs with ESS under linux. > Thank you in advance for your time! Best regards,I don't do 2, 3, 4 that way. I just run the sessions in parallel, and do (no root privilege required): R CMD INSTALL -l sometemplace mypackage and in a parallel session, do library(mypackage, lib.loc="sometemplate") okay, after a while, I ended up with a few /sometemplace's and a few R sessions, but it is much better than doing installing system-wide as root and overwriting it over and over with semi-broken or work-in-progress versions. Hope this helps. Hin-Tak Leung
On 3/26/07, "Jos? Luis Aznarte M." <jlaznarte at decsai.ugr.es> wrote:> Hi! I've been browsing through the last months' archive and I can't > find an answer to my question, so here it is (let's hope it's not too > obvious): > I'm working on extensions of an R library, and I would be very > surprised if everyone developing R packages is doing the following, as I do: > > 1.- Write down a modification of an R file > 2.- Exit the current R session > 3.- Install the package as root (sudo R CMD INSTALL...) > 4.- Launch a new R session > 5.- Test the change, if it does not work, go back to 1 or debug. > 6.- Finish. > > Is this the proper (but quite awkward) way to proceed or there is an > alternative to skip steps 2 to 4? I'm using emacs with ESS under linux. > Thank you in advance for your time! Best regards,I have a file in the root directory of all of my packages that looks like this: library(meifly) lapply(dir("~/documents/meifly/meifly/R", "\\.[Sr]$", full.name=T), source) That way I can modify files in my text editor, and then run source("load.r") to update all my changes. This isn't completely full proof as it loads everything into the global workspace so any namespace problems won't be apparent. I also have "\e[A": history-search-backward "\e[B": history-search-forward in my .inputrc file. This lets me type in "s", then press the up key a couple of times to get back to the last time I used source(...). Similarly for any other prefix of a previously typed command - this is a huge time saver. Finally, in ~/.profile I have alias R='R --no-save --no-restore-data --quiet' which saves me a few keystrokes when quitting R (and a lot of guff when I open R) and ensures I always start with a clean workspace. Hadley
Jos? Luis Aznarte M. wrote:> Hin-Tak Leung wrote: >> I don't do 2, 3, 4 that way. I just run the sessions in parallel, >> and do (no root privilege required): >> >> R CMD INSTALL -l sometemplace mypackage >> >> and in a parallel session, do >> >> library(mypackage, lib.loc="sometemplate") > What do you mean by "sometemplate"? Is that the complete path to > where the library's source is? Or is it a temporary folder to install > it? In that case, I could use /tmp/ (in linux) to install test versions > of the library? And, by doing the "library(mypackage, lib.log="/tmp")" > call, do I overwrite the current one, including namespaces and so on? > Sorry I did not understand exactly what you meant. Thank you so much > anyway. :-)typo... happier with this below? Both of them (same "/tmp") is an alternative installed location, not source location. R CMD INSTALL -l /tmp mypackage library(mypackage, lib.loc="/tmp") I don't think you can do 'library(mypackage, lib.loc="/tmp")' twice (with a re-install in the middle), if that's what you are thinking. I think you need to do detach(package:mypackage) at least, and even then, windows's dll loader gets very confused. I believe I had managed to crash R by dyn.load()'ing two object files of the same name twice under wine, so I am not sure it is a good idea. I read somewhere that object files are never unloaded, but you'll need to hear it from the R experts... HTL
On 3/26/07, "Jos? Luis Aznarte M." <jlaznarte at decsai.ugr.es> wrote:> Hi! I've been browsing through the last months' archive and I can't > find an answer to my question, so here it is (let's hope it's not too > obvious): > I'm working on extensions of an R library, and I would be very > surprised if everyone developing R packages is doing the following, as I do: > > 1.- Write down a modification of an R file > 2.- Exit the current R session > 3.- Install the package as root (sudo R CMD INSTALL...) > 4.- Launch a new R session > 5.- Test the change, if it does not work, go back to 1 or debug. > 6.- Finish. > > Is this the proper (but quite awkward) way to proceed or there is an > alternative to skip steps 2 to 4? I'm using emacs with ESS under linux.John Chambers has provided an alternative approach of using trace(fname, edit = TRUE) where fname is the name of your function. (Make sure that the server for emacsclient has been started in your emacs session with M-x server-start.) This opens an emacs buffer containing the source for the function which you can then edit. After writing the file and closing the client (C-x #) your ESS session has the new definition installed in the package's namespace. This will work even for objects hidden in the namespace. The argument "signature" allows you to edit S4 methods on the fly like this. In my experience you cannot edit registered S3 methods like this but it may be that I am just not using trace correctly. Of course you must copy the modified version of the source code to your package sources when you are done. As others have indicated, it is a good practice to install development versions of packages in a private library so you do not need to use sudo or worry about messing up system-wide directories.