From tplate at acm.org  Mon Apr  2 19:34:02 2007
From: tplate at acm.org (Tony Plate)
Date: Mon, 02 Apr 2007 11:34:02 -0600
Subject: [Rd] Developer work cycle
In-Reply-To: <D79013E40FEF254AAF0D72DFC94F27482308B4@extas4-hba.tas.csiro.au>
References: <4607F803.7060700@decsai.ugr.es><40e66e0b0703291103m2ff62deej1af424ab1de13ab@mail.gmail.com>	<460C5B09.4070501@r-project.org>
	<D79013E40FEF254AAF0D72DFC94F27482308B4@extas4-hba.tas.csiro.au>
Message-ID: <46113E8A.3000806@acm.org>

I tried to summarize some of the very useful tips in this discussion in 
the R Wiki at 
http://wiki.r-project.org/rwiki/doku.php?id=developers:workcycle

If you feel I used your contribution inappropriately, please let me know 
and I'll remove it.

Anyone, please feel free to improve it!

-- Tony Plate


Mark.Bravington at csiro.au wrote:
> 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]]
>>
>>
>>
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



[Rd] Developer work cycle
Tony Plate