[Rd] Developer work cycle

[Douglas Bates]

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.