[Rd] Developer work cycle

Mark.Bravington at csiro.au Mark.Bravington at csiro.au
Fri Mar 30 02:58:37 CEST 2007


Couple of quick points:

FYI1: the 'mtrace' function in the 'debug' package does let you trace hidden S3 methods (though it lacks the edit= argument).

FYI2: In my own alpha-version of 'mvbutils', I am able to do live edits of code in (selected) installed packages, including adding & deleting functions from the namespace, and also to do a quick patch of the installed library from inside R (rather than requiring re-installation) so that the modified version is loaded next time I use 'library'. I only need to re-build the package with rcmd when I want to update the helpfiles. My plan is to release the new 'mvbutils' later this year-- time permitting.

Mark

Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS

ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623
 

> -----Original Message-----
> From: r-devel-bounces at r-project.org 
> [mailto:r-devel-bounces at r-project.org] On Behalf Of John Chambers
> Sent: Friday, 30 March 2007 10:34 AM
> To: Douglas Bates
> Cc: "José Luis Aznarte M."; r-devel at r-project.org
> Subject: Re: [Rd] Developer work cycle
> 
> Douglas Bates wrote:
> > 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.
> >   
> Indeed, trace() does not currently work for registered S3 
> methods, with or without the edit=TRUE argument.
> 
> There is a fix, just committed to r-devel, which should be in 
> the final 2.5.0.
> > 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.
> >
> > ______________________________________________
> > R-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >   
> 
> 	[[alternative HTML version deleted]]
> 
> 
>



More information about the R-devel mailing list