From mailinglist.honeypot at gmail.com  Wed Jul  6 21:04:15 2011
From: mailinglist.honeypot at gmail.com (Steve Lianoglou)
Date: Wed, 6 Jul 2011 15:04:15 -0400
Subject: [Rd] Recent and upcoming changes to R-devel
In-Reply-To: <59614E65-86AC-4CB5-81E5-96A57A292056@r-project.org>
References: <alpine.OSX.1.00.1107041124460.59432@tystie.local>
	<CAC2h7uujLLQQCzQBgfCmbaFg-UeQqMzntQfXD8YhyjSRQpAWDw@mail.gmail.com>
	<4E146649.7080909@gmail.com>
	<CAC2h7utabPFeseTpikDwWzEXV_im2G_-M7X4nr0Souk81pqhPg@mail.gmail.com>
	<59614E65-86AC-4CB5-81E5-96A57A292056@r-project.org>
Message-ID: <CAHA9McMG0CCxhk6eOKrtFx2PNF2=bu61pZs8m5ZwW9EDoLoALQ@mail.gmail.com>

On Wed, Jul 6, 2011 at 10:17 AM, Simon Urbanek
<simon.urbanek at r-project.org> wrote:
>
> On Jul 6, 2011, at 10:06 AM, Kasper Daniel Hansen wrote:
[aggressive trimming]
>>> It seems like something a front end could do to make assignInNamespace
>>> easier to use to make working with namespaces easier.
>>
>> Indeed I find this change to be a very welcome addition to R that will
>> make the life easier for many of us; especially when you are using
>> someone else's package.
>>
>> My use case is also not debugging my own code when it is a at a
>> semi-mature level. ?I am addressing the very early stages of
>> developing a new package. ?In my workflow (which may differ from other
>> people's; but I do think a substantial number would agree with me),
>> the early stages of development usually entails bringing order to a
>> number of R scripts; figuring out the structure of the basic objects
>> as well as the arguments for the important functions/methods. ?In this
>> early stage, almost any evaluation I do at the R prompt is followed by
>> refactoring some part of the code (and then sourcing it into R).
>>
>> Once the code is semi-matured (after the first couple of weeks), I
>> don't think I would mind a NAMESPACE at all, but I believe I would
>> find it very frustrating during the very early development stage
>> (which I am going through right now for one package and which I went
>> through a month ago for another package).
>>
>
> .. but in that case it's easier to just source the package code. That allows much easier and consistent editing as well since you know everything is in the workspace, so you are not dealing with two sets of code.

And you could also try using Hadley's devtools package:
https://github.com/hadley/devtools/

Last I tried to use it, there was some problems with some S4isms (that
maybe were my fault(?)) so I switched back to sourcing my
development-package-dirs (which is fine until you've got compiled
code) -- but maybe the problems I was having with devtools have also
been resolved. It could be worth a try.

-steve

-- 
Steve Lianoglou
Graduate Student: Computational Systems Biology
?| Memorial Sloan-Kettering Cancer Center
?| Weill Medical College of Cornell University
Contact Info: http://cbio.mskcc.org/~lianos/contact



[Rd] Recent and upcoming changes to R-devel
Steve Lianoglou