[Rd] improvements to plm fitting
In the course of some work I have been doing for Revolution Analytics I have
had the necessity of modifying the plm function so that it would not die
halfway through fitting. In particular, I was able to more than halve the
runtime (for my particular run) and improve its memory usage with three
small modifications:
1.) Replacing throughout apply(X, 2, mean) with colMeans, similarly with
colSums()
2.) In pdata.frame()
Replacing
#n <- length(Ti)
#time <- c()
#for (i in 1:n){
#time <- c(time, 1:Ti[i])
#}
with 'time <- sequence(Ti)'
3.) To uncork the particular bottleneck I was experiencing in Tapply (the
fitting would die halfway through a massive tapply() ) I have modified the
function to process things in chunks. By still using tapply we do not give
up too much efficiency and gain the ability to fit much larger models. Here
is the down-and-dirty code, set at the moment to do everything in one go,
but controllable via 'num_blocks' or 'block_size'. A nice way to handle
this would be for it to be left as a parameter that, by default, is set to
do the entire data set at once.
Tapply.default <- function (x, effect, func, ...)
{
na.x <- is.na(x)
effect_unique <- unique(effect)
n_effects <- length( effect_unique )
uniqval <- array(dim=n_effects)
attr(uniqval, "dimnames")[[1]] <- as.character(effect_unique)
# change this back so that it can handle larger datasets
block_size <- n_effects
num_blocks <- ceiling( n_effects / block_size )
for( i in 1:num_blocks ){
these_ind <- ((i-1)*block_size + 1):min(n_effects, (i*block_size))
these_effects <- effect_unique[ these_ind ]
this_x<- x[ effect %in% these_effects ]
this_effect <- factor(effect[ effect %in% these_effects ] )
uniqval[these_ind] <- tapply(this_x, this_effect, func, ...)
}
nms <- attr(uniqval, "dimnames")[[1]]
attr(uniqval, "dimnames") <- attr(uniqval, "dim") <- NULL
names(uniqval) <- nms
result <- uniqval[as.character(effect)]
result[na.x] <- NA
result
}
Again, Revolution Analytics is to thank for these improvements, should they
make it into the package. I am happy to work with the authors to see that
this is incorporated.
Thanks, as always, to Yves and everyone else volunteering their time and
expertise.
Kyle
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] package test failed on Solaris x86 -- help needed for debugging
Dear R developers, we have currently a 'mysterious' test problem with one package that successfully passed the tests on all platforms, with the only exception of Solaris x86 where obviously one of our help examples breaks the CRAN test. As we don't own such a machine I want to ask about a possibility to run a few tests on such a system: r-patched-solaris-x86 An even more recent version of R on the same OS (Solaris 10) and with the same compiler (Sun Studio 12u1) would help also. Any assistance is appreciated Thomas Petzoldt -- Thomas Petzoldt Technische Universitaet Dresden Institut fuer Hydrobiologiethomas.petzo...@tu-dresden.de 01062 Dresden http://tu-dresden.de/hydrobiologie/ GERMANY __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [2.11.1] Cross build for Win: psignal.h No such file or directory
Hi, I'm trying to build R with Radford Neal's patches. I did successful before on Win, but with 2.11.1 version i got some problems. So my next try was cross build on Linux. (without patches, yet) I use: ./configure --build i686-pc-linux-gnu --host i686-pc-mingw32 --with-x=no And get: configure: WARNING: you cannot build info or HTML versions of the R manuals using cross tools not prefixed with host triplet In file included from dynload.c:33 ../../src/inculde/Defn.h:142:22: error psignal.h: No such file or directory I know that the file is in /gnuwin32/fixed/h, so something i did wrong. But no idea what. -- Miłego dnia __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] advice on writing/maintaining an R package with a version control system
Dear all, As I resume my dissertation work next month, I'd like to actually start an R package this time around. I haven't done so because I update my code very often (still in development phase), so running the skeleton function, running checks, building, and re-installing the package onto the system seemed like a long and tedious process. I would like to hear your experience on how you start an R package with a version control system. Currently, I have most of my functions in an R source file. I expect to use a skeleton function to generate the package directory (most likely Rcpp's), and start git as my version control system (although the advice I'm seeking isn't git-specific). Once the version control system is set up, a few questions: 1. Do you update your code directly into the multiple R files in ./src, or do you update the main R source file? I'm assuming the former since we're using version control. 2. What is your process for updating and testing your code? Do you run checks, build, and re-install the package to test? Or do you have some fancy workflow? Please share. Thanks for your advice. Vinh -- Vinh Nguyen Department of Statistics Donald Bren School of ICS 2231 Bren Hall University of California, Irvine Irvine, CA 92607 vqngu...@uci.edu | http://www.ics.uci.edu/~vqnguyen/ Schedule a meeting: http://tungle.me/VinhNguyen __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package test failed on Solaris x86 -- help needed for debugging
Dear Thomas,
Is this the deSolve package?
http://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/deSolve-00check.html
I can help you with that. It does pass R CMD check on my OpenSolaris
installation, but I am getting some compiler warnings. I will send you
details.
Martyn
On Thu, 2010-09-16 at 11:16 +0200, Thomas Petzoldt wrote:
> Dear R developers,
>
> we have currently a 'mysterious' test problem with one package that
> successfully passed the tests on all platforms, with the only exception
> of Solaris x86 where obviously one of our help examples breaks the CRAN
> test.
>
> As we don't own such a machine I want to ask about a possibility to run
> a few tests on such a system:
>
> r-patched-solaris-x86
>
> An even more recent version of R on the same OS (Solaris 10) and with
> the same compiler (Sun Studio 12u1) would help also.
>
> Any assistance is appreciated
>
>
> Thomas Petzoldt
>
>
---
This message and its attachments are strictly confidenti...{{dropped:8}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] advice on writing/maintaining an R package with a version control system
On Sep 16, 2010, at 10:06 AM, Vinh Nguyen wrote: > Dear all, > > As I resume my dissertation work next month, I'd like to actually > start an R package this time around. I haven't done so because I > update my code very often (still in development phase), so running the > skeleton function, running checks, building, and re-installing the > package onto the system seemed like a long and tedious process. > I guess it depends on the package, but in general I find it's so fast that it's not worth bothering with the alternatives. It's just one line to build, install a package and run the desired test code. The time to do that is usually in single-digit seconds which I'm happy with. > I would like to hear your experience on how you start an R package > with a version control system. Currently, I have most of my functions > in an R source file. I expect to use a skeleton function to generate > the package directory (most likely Rcpp's), and start git as my > version control system (although the advice I'm seeking isn't > git-specific). Once the version control system is set up, a few > questions: > > 1. Do you update your code directly into the multiple R files in > ./src, or do you update the main R source file? I suspect you mean ./R not ./src if it's an R source file. Personally, I group functions by topic into files, some others put one function per file - it's all about personal preferences because the installed package won't have any of the files you're using so technically it doesn't matter. > I'm assuming the > former since we're using version control. > 2. What is your process for updating and testing your code? Do you > run checks, build, and re-install the package to test? Or do you have > some fancy workflow? Please share. > I just run R CMD build xxx && R CMD INSTALL xxx && R sometimes also including the test code in the last R call so running it requires pressing only two keys. Once I'm happy that the stuff seems to work I run the checks and then commit. (If I'm confident I commit right away since I use SVN and my RForge does run checks on commit so I don't have to bother doing that - it also checks on a different system which is good in case you forgot to add files to the VCS). If you have large or complex packages, it may be useful to just change a function at a time in the interactive session -- but that's trivial as you simply send the assignment from your editor. (Some tricks may be needed if namespaces are involved but they are usually simple ways around). Just my very personal $0.02. Cheers, Simon > Thanks for your advice. > > Vinh > -- > Vinh Nguyen > Department of Statistics > Donald Bren School of ICS > 2231 Bren Hall > University of California, Irvine > Irvine, CA 92607 > vqngu...@uci.edu | http://www.ics.uci.edu/~vqnguyen/ > Schedule a meeting: http://tungle.me/VinhNguyen > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] package test failed on Solaris x86 -- help needed for debugging
On 16.09.2010 17:05, Martyn Plummer wrote: Dear Thomas, Is this the deSolve package? http://www.r-project.org/nosvn/R.check/r-patched-solaris-x86/deSolve-00check.html I can help you with that. It does pass R CMD check on my OpenSolaris installation, but I am getting some compiler warnings. I will send you details. Martyn You are right and there are many reasons what can be wrong, i.e. an obsolete comma in the example, the call to colorRampPalette after the ode.2D call or any problem with the C code. I wonder why this problem is so specific because it runs on all other eleven platforms including Solaris / Sparc. Details about the compiler warnings are welcome. Thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Possible bug or annoyance with library.dynam.unload()
Hello,
I have a package with a namespace. Because I use Roxygen that overwrites the
NAMESPACE file each time it is run, I use a R/zzz.R file with
an .onLoad() and .onUnload() functions to take care of loading and unloading
my shared library.
The problem: if I load my library from a local directory, then the unloading
of the package fails, e.g:
# loads fine
>library(Foo, lib.loc=".Rcheck")
>unloadNamespace("Foo")
Warning message:
.onUnload failed in unloadNamespace() for 'Foo', details:
call: library.dynam.unload("Foo", libpath)
error: shared library 'Foo' was not loaded
# I traced it a little:
>library.dynam.unload("Foo", ".Rcheck/Foo")
Error in library.dynam.unload("Foo", ".Rcheck/Foo") :
shared library 'Foo' was not loaded
# using an absolute path works
>library.dynam.unload("Foo", "/home/toto/.Rcheck/Foo")
So from what I understand, the problem is either that the relative libpath
is sent to the .onUnload() function instead of the absolute one,
or that library.dynam.unload() should be modified to handle the relative
paths.
Am I missing something ? What should I do ?
Thanks,
Karl
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] advice on writing/maintaining an R package with a version control system
Since you are using git you may want to consider a submodule for your project. It is often helpful to build a full library in c++ complete with it's own unit tests. You can then package this library inside of your R project as a submodule. This can speed up the testing phase of the project b/c you don't have to recompile and install the package every time you need to patch/test your code. For examples, see fts: http://github.com/armstrtw/fts. -Whit On Thu, Sep 16, 2010 at 11:15 AM, Simon Urbanek wrote: > On Sep 16, 2010, at 10:06 AM, Vinh Nguyen wrote: > >> Dear all, >> >> As I resume my dissertation work next month, I'd like to actually >> start an R package this time around. I haven't done so because I >> update my code very often (still in development phase), so running the >> skeleton function, running checks, building, and re-installing the >> package onto the system seemed like a long and tedious process. >> > > I guess it depends on the package, but in general I find it's so fast that > it's not worth bothering with the alternatives. It's just one line to build, > install a package and run the desired test code. The time to do that is > usually in single-digit seconds which I'm happy with. > > >> I would like to hear your experience on how you start an R package >> with a version control system. Currently, I have most of my functions >> in an R source file. I expect to use a skeleton function to generate >> the package directory (most likely Rcpp's), and start git as my >> version control system (although the advice I'm seeking isn't >> git-specific). Once the version control system is set up, a few >> questions: >> >> 1. Do you update your code directly into the multiple R files in >> ./src, or do you update the main R source file? > > I suspect you mean ./R not ./src if it's an R source file. Personally, I > group functions by topic into files, some others put one function per file - > it's all about personal preferences because the installed package won't have > any of the files you're using so technically it doesn't matter. > > >> I'm assuming the >> former since we're using version control. >> 2. What is your process for updating and testing your code? Do you >> run checks, build, and re-install the package to test? Or do you have >> some fancy workflow? Please share. >> > > I just run > R CMD build xxx && R CMD INSTALL xxx && R > sometimes also including the test code in the last R call so running it > requires pressing only two keys. Once I'm happy that the stuff seems to work > I run the checks and then commit. (If I'm confident I commit right away since > I use SVN and my RForge does run checks on commit so I don't have to bother > doing that - it also checks on a different system which is good in case you > forgot to add files to the VCS). > > If you have large or complex packages, it may be useful to just change a > function at a time in the interactive session -- but that's trivial as you > simply send the assignment from your editor. (Some tricks may be needed if > namespaces are involved but they are usually simple ways around). > > Just my very personal $0.02. > > Cheers, > Simon > > > > >> Thanks for your advice. >> >> Vinh >> -- >> Vinh Nguyen >> Department of Statistics >> Donald Bren School of ICS >> 2231 Bren Hall >> University of California, Irvine >> Irvine, CA 92607 >> vqngu...@uci.edu | http://www.ics.uci.edu/~vqnguyen/ >> Schedule a meeting: http://tungle.me/VinhNguyen >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a small suggestion for improving the building of packages
> From: Uwe Ligges
> Date: Wed, 15 Sep 2010 15:23:01 +0200
> On 29.08.2010 22:34, Kyle Matoba wrote:
> > All,
> >
> > I just finished the process of build a package for the first time and
> found
> > it characteristically (for R) very straightforward and well
> documented.
> >
> > Whenever I deal with open source software I always endeavor to finish
> the
> > task I have in mind, and upon completing this, I then revisit all of
> the
> > configurations, customizing as necessary to achieve my goals more
> fully.
> > The ability to achieve some minimal level of functionality without
> the
> need
> > for much filling in of configuration files, etc., is, I feel,
> important to
>
> > not scaring off the less technically inclined such as myself.
> >
> > Based on this heuristic, it is my understanding that a few small
> suggestions
> > could make building a warning-free package as easy as running
> > package.skeleton(), then R CMD check, R CMD build:
> >
> > - Fill in default titles for each of the '*.Rd' files in /man
> > - Take out the tildes in the 'examples' section of the '*-package.Rd'
> main
>
> > documentation file for the package (it seems to confuse the latex
> compiler)
> > - Put the lines '~~ Optionally other standard keywords, one per line,
> from
>
> > file KEYWORDS in ~~
> > ~~ the R documentation directory ~~' into the \references{} section,
> there
>
> > is presently a warning about all text needing to be in a section.
> Dear Kyle,
> thanks for the suggestions. Actually, it is intended to generate
> warnings /
> Errors in R CMD check: We want to force package developers to document
> their
> packages probably. This way, package maintainers / developers have to
> touch
> each Rd file and cannot use them as is in order to pass the checks.
> Best wishes,
> uwe
Dear Uwe,
in principle, I totally agree with your point of politely forcing developers
to write well documented packages. However, when you're trying to put
together a package, you (or at least I) never get it completely right on the
first, say, 20 tries ;-) Yet, by running package.skelleton() over and over
to keep track of changes you made during the process, you overwrite all Rd
files each time - including the ones that you might already have put a lot
of effort into. And delaying documentation to the very end of the process is
probably not the best idea either ;-) IMHO the community should favor the
approaches taken by packages such as roxygen or inlinedocs as at least it
provides some sort of direct synchronization between code and documentation.
Maybe one could agree on rejecting code that is missing roxygen or inlinedoc
code, which would ensure that code is documented properly. In fact, isn't
programming all about automating unnecessary manual procedures? I would
count starting from scratch with all help files time and time again to be
one of those unnecessary procedures. This time could better be invested in
increasing the package's functionality.
Best regards, my thanks go out to everyone as well,
Janko
> > Thanks, as always, to everyone for their hard work to keep my
> statistical
> > computing free and easy.
> >
> > Best,
> >
> > Kyle
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-devel_at_r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a small suggestion for improving the building of packages
On 16.09.2010 20:18, Janko Thyson wrote:
From: Uwe Ligges
Date: Wed, 15 Sep 2010 15:23:01 +0200
On 29.08.2010 22:34, Kyle Matoba wrote:
All,
I just finished the process of build a package for the first time and
found
it characteristically (for R) very straightforward and well
documented.
Whenever I deal with open source software I always endeavor to finish
the
task I have in mind, and upon completing this, I then revisit all of
the
configurations, customizing as necessary to achieve my goals more
fully.
The ability to achieve some minimal level of functionality without
the
need
for much filling in of configuration files, etc., is, I feel,
important to
not scaring off the less technically inclined such as myself.
Based on this heuristic, it is my understanding that a few small
suggestions
could make building a warning-free package as easy as running
package.skeleton(), then R CMD check, R CMD build:
- Fill in default titles for each of the '*.Rd' files in /man
- Take out the tildes in the 'examples' section of the '*-package.Rd'
main
documentation file for the package (it seems to confuse the latex
compiler)
- Put the lines '~~ Optionally other standard keywords, one per line,
from
file KEYWORDS in ~~
~~ the R documentation directory ~~' into the \references{} section,
there
is presently a warning about all text needing to be in a section.
Dear Kyle,
thanks for the suggestions. Actually, it is intended to generate
warnings /
Errors in R CMD check: We want to force package developers to document
their
packages probably. This way, package maintainers / developers have to
touch
each Rd file and cannot use them as is in order to pass the checks.
Best wishes,
uwe
Dear Uwe,
in principle, I totally agree with your point of politely forcing developers
to write well documented packages. However, when you're trying to put
together a package, you (or at least I) never get it completely right on the
first, say, 20 tries ;-) Yet, by running package.skelleton() over and over
to keep track of changes you made during the process, you overwrite all Rd
files each time - including the ones that you might already have put a lot
of effort into. And delaying documentation to the very end of the process is
probably not the best idea either ;-) IMHO the community should favor the
approaches taken by packages such as roxygen or inlinedocs as at least it
provides some sort of direct synchronization between code and documentation.
Maybe one could agree on rejecting code that is missing roxygen or inlinedoc
code, which would ensure that code is documented properly. In fact, isn't
programming all about automating unnecessary manual procedures? I would
count starting from scratch with all help files time and time again to be
one of those unnecessary procedures. This time could better be invested in
increasing the package's functionality.
- I don't think package.skeleton overwrites files unless you ask for it.
- I think once you got started with your package, it is not required to
call package skeleton again. I tend to add files manually since I am
working on the package hierarchy itself using some editor...
- Last time I used package.skeleton is probably more than 2 years ago
(except for presentations in courses about package creation).
Best,
Uwe
Best regards, my thanks go out to everyone as well,
Janko
Thanks, as always, to everyone for their hard work to keep my
statistical
computing free and easy.
Best,
Kyle
[[alternative HTML version deleted]]
__
R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a small suggestion for improving the building of packages
> From: r-devel-boun...@r-project.org > [mailto:r-devel-boun...@r-project.org] On Behalf Of Janko Thyson > Sent: Thursday, September 16, 2010 11:19 AM > To: r-de...@r-project. org > Subject: Re: [Rd] a small suggestion for improving the > building of packages ... > Dear Uwe, > in principle, I totally agree with your point of politely > forcing developers > to write well documented packages. However, when you're trying to put > together a package, you (or at least I) never get it > completely right on the > first, say, 20 tries ;-) Yet, by running package.skelleton() > over and over > to keep track of changes you made during the process, you > overwrite all Rd > files each time - including the ones that you might already > have put a lot > of effort into. Running package.skeleton more than once is destructive. Perhaps it needs an update=TRUE/FALSE sort of option to let you add functions and Rd templates. When I start a package I don't use package.skeleton, mainly because it won't make all the usual directories that I expect to eventually use: src, data, inst, test (or it is tests?), etc. I'd rather that it made all the usual directories (with the proper spelling) so I could delete them if they ended up being empty. Do other package writers use package.skeleton routinely? I copy a template package directory, edit the template DESCRIPTION file, copy my code into the appropriate subdirectories, and run prompt(func, filename="pkg/man/func.Rd") on each function or dataset. The last step is a pain: it would be nice if prompt had a dir= or destdir= argument so that prompt(func, destdir="pkg/man") would make the file "pkg/man/func.Rd". Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com > And delaying documentation to the very end of > the process is > probably not the best idea either ;-) IMHO the community > should favor the > approaches taken by packages such as roxygen or inlinedocs as > at least it > provides some sort of direct synchronization between code and > documentation. > Maybe one could agree on rejecting code that is missing > roxygen or inlinedoc > code, which would ensure that code is documented properly. In > fact, isn't > programming all about automating unnecessary manual > procedures? I would > count starting from scratch with all help files time and time > again to be > one of those unnecessary procedures. This time could better > be invested in > increasing the package's functionality. > > Best regards, my thanks go out to everyone as well, > Janko > > > > Thanks, as always, to everyone for their hard work to keep my > > statistical > > > computing free and easy. > > > > > > Best, > > > > > > Kyle > > > > > > [[alternative HTML version deleted]] > > > > > > __ > > > R-devel_at_r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a small suggestion for improving the building of packages
On 16/09/2010 2:43 PM, Uwe Ligges wrote:
On 16.09.2010 20:18, Janko Thyson wrote:
>> From: Uwe Ligges
>> Date: Wed, 15 Sep 2010 15:23:01 +0200
>> On 29.08.2010 22:34, Kyle Matoba wrote:
>>> All,
>>>
>>> I just finished the process of build a package for the first time and
>> found
>>> it characteristically (for R) very straightforward and well
>> documented.
>>>
>>> Whenever I deal with open source software I always endeavor to finish
>> the
>>> task I have in mind, and upon completing this, I then revisit all of
>> the
>>> configurations, customizing as necessary to achieve my goals more
>> fully.
>>> The ability to achieve some minimal level of functionality without
>> the
>> need
>>> for much filling in of configuration files, etc., is, I feel,
>> important to
>>
>>> not scaring off the less technically inclined such as myself.
>>>
>>> Based on this heuristic, it is my understanding that a few small
>> suggestions
>>> could make building a warning-free package as easy as running
>>> package.skeleton(), then R CMD check, R CMD build:
>>>
>>> - Fill in default titles for each of the '*.Rd' files in /man
>>> - Take out the tildes in the 'examples' section of the '*-package.Rd'
>> main
>>
>>> documentation file for the package (it seems to confuse the latex
>> compiler)
>>> - Put the lines '~~ Optionally other standard keywords, one per line,
>> from
>>
>>> file KEYWORDS in ~~
>>> ~~ the R documentation directory ~~' into the \references{} section,
>> there
>>
>>> is presently a warning about all text needing to be in a section.
>> Dear Kyle,
>> thanks for the suggestions. Actually, it is intended to generate
>> warnings /
>> Errors in R CMD check: We want to force package developers to document
>> their
>> packages probably. This way, package maintainers / developers have to
>> touch
>> each Rd file and cannot use them as is in order to pass the checks.
>> Best wishes,
>> uwe
>
> Dear Uwe,
> in principle, I totally agree with your point of politely forcing developers
> to write well documented packages. However, when you're trying to put
> together a package, you (or at least I) never get it completely right on the
> first, say, 20 tries ;-) Yet, by running package.skelleton() over and over
> to keep track of changes you made during the process, you overwrite all Rd
> files each time - including the ones that you might already have put a lot
> of effort into. And delaying documentation to the very end of the process is
> probably not the best idea either ;-) IMHO the community should favor the
> approaches taken by packages such as roxygen or inlinedocs as at least it
> provides some sort of direct synchronization between code and documentation.
> Maybe one could agree on rejecting code that is missing roxygen or inlinedoc
> code, which would ensure that code is documented properly. In fact, isn't
> programming all about automating unnecessary manual procedures? I would
> count starting from scratch with all help files time and time again to be
> one of those unnecessary procedures. This time could better be invested in
> increasing the package's functionality.
- I don't think package.skeleton overwrites files unless you ask for it.
- I think once you got started with your package, it is not required to
call package skeleton again. I tend to add files manually since I am
working on the package hierarchy itself using some editor...
Hi Uwe. This message is mostly for Janko and others.
You can add them manually, but I would usually use prompt(), a generic
function that produces just one .Rd file.
It's really one of the prompt methods that package.skeleton is calling
to produce the bad man pages. My own feeling is that package.skeleton
should produce a package that is installable, but it shouldn't pass "R
CMD check" unless there's some manual intervention to fill in the details.
I think that is the current state of affairs, but if we're producing
something that causes "R CMD build" or "R CMD INSTALL" to fail, please
let us know.
By the way, I don't think the title can be filled in automatically
unless a user has roxygen style documentation, so we don't. But doesn't
the roxygen package do that?
Duncan Murdoch
- Last time I used package.skeleton is probably more than 2 years ago
(except for presentations in courses about package creation).
Best,
Uwe
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a small suggestion for improving the building of packages
> -Ursprüngliche Nachricht- > Von: William Dunlap [mailto:wdun...@tibco.com] > Gesendet: Donnerstag, 16. September 2010 20:45 > An: Janko Thyson; r-de...@r-project. org > Betreff: RE: [Rd] a small suggestion for improving the building of > packages > > > From: r-devel-boun...@r-project.org > > [mailto:r-devel-boun...@r-project.org] On Behalf Of Janko Thyson > > Sent: Thursday, September 16, 2010 11:19 AM > > To: r-de...@r-project. org > > Subject: Re: [Rd] a small suggestion for improving the > > building of packages > ... > > Dear Uwe, > > in principle, I totally agree with your point of politely > > forcing developers > > to write well documented packages. However, when you're trying to put > > together a package, you (or at least I) never get it > > completely right on the > > first, say, 20 tries ;-) Yet, by running package.skelleton() > > over and over > > to keep track of changes you made during the process, you > > overwrite all Rd > > files each time - including the ones that you might already > > have put a lot > > of effort into. > > Running package.skeleton more than once is destructive. > Perhaps it needs an update=TRUE/FALSE sort of option > to let you add functions and Rd templates. Uwe just pointed out that there is the argument 'force' that does that but since it said 'If FALSE will not overwrite an existing directory' I somehow didn't consider it to handle the update=TRUE/FALSE case. My bad. > > When I start a package I don't use package.skeleton, > mainly because it won't make all the usual directories > that I expect to eventually use: src, data, inst, test > (or it is tests?), etc. I'd rather that it made all > the usual directories (with the proper spelling) so > I could delete them if they ended up being empty. > Do other package writers use package.skeleton routinely? I agree. It would be nice if package.skeleton() would create a 'full-feature' skeleton removing empty directories during R CMD check. > > I copy a template package directory, edit the template > DESCRIPTION file, copy my code into the appropriate > subdirectories, and run prompt(func, filename="pkg/man/func.Rd") > on each function or dataset. The last step is a pain: > it would be nice if prompt had a dir= or destdir= argument > so that >prompt(func, destdir="pkg/man") > would make the file "pkg/man/func.Rd". > Oh, never really considered 'prompt()' before. Thanks for the suggestion! All the manuals always mention 'package.skeleton()' But couldn't you realize your destdir feature by just building a wrapper around 'prompt()' or using it in a sapply/lapply construct? The last couple of days I played around with Roxygen and together with a couple of utility-functions I managed to completely automate the whole process from creating a full-feature skeleton, processing the Rds with roxygenize() and running the full R CMD suite on the package. That way you document your code right within the actual script which I think is great. Best regards, Janko > Bill Dunlap > Spotfire, TIBCO Software > wdunlap tibco.com > > > And delaying documentation to the very end of > > the process is > > probably not the best idea either ;-) IMHO the community > > should favor the > > approaches taken by packages such as roxygen or inlinedocs as > > at least it > > provides some sort of direct synchronization between code and > > documentation. > > Maybe one could agree on rejecting code that is missing > > roxygen or inlinedoc > > code, which would ensure that code is documented properly. In > > fact, isn't > > programming all about automating unnecessary manual > > procedures? I would > > count starting from scratch with all help files time and time > > again to be > > one of those unnecessary procedures. This time could better > > be invested in > > increasing the package's functionality. > > > > Best regards, my thanks go out to everyone as well, > > Janko > > > > > > Thanks, as always, to everyone for their hard work to keep my > > > statistical > > > > computing free and easy. > > > > > > > > Best, > > > > > > > > Kyle > > > > > > > > [[alternative HTML version deleted]] > > > > > > > > __ > > > > R-devel_at_r-project.org mailing list > > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a small suggestion for improving the building of packages
> -Ursprüngliche Nachricht-
> Von: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> Gesendet: Donnerstag, 16. September 2010 20:55
> An: Uwe Ligges
> Cc: Janko Thyson; r-de...@r-project. org
> Betreff: Re: [Rd] a small suggestion for improving the building of
> packages
>
> On 16/09/2010 2:43 PM, Uwe Ligges wrote:
> >
> > On 16.09.2010 20:18, Janko Thyson wrote:
> > >> From: Uwe Ligges
> > >> Date: Wed, 15 Sep 2010 15:23:01 +0200
> > >> On 29.08.2010 22:34, Kyle Matoba wrote:
> > >>> All,
> > >>>
> > >>> I just finished the process of build a package for the first
> time and
> > >> found
> > >>> it characteristically (for R) very straightforward and well
> > >> documented.
> > >>>
> > >>> Whenever I deal with open source software I always endeavor to
> finish
> > >> the
> > >>> task I have in mind, and upon completing this, I then revisit
> all of
> > >> the
> > >>> configurations, customizing as necessary to achieve my goals
> more
> > >> fully.
> > >>> The ability to achieve some minimal level of functionality
> without
> > >> the
> > >> need
> > >>> for much filling in of configuration files, etc., is, I feel,
> > >> important to
> > >>
> > >>> not scaring off the less technically inclined such as myself.
> > >>>
> > >>> Based on this heuristic, it is my understanding that a few small
> > >> suggestions
> > >>> could make building a warning-free package as easy as running
> > >>> package.skeleton(), then R CMD check, R CMD build:
> > >>>
> > >>> - Fill in default titles for each of the '*.Rd' files in /man
> > >>> - Take out the tildes in the 'examples' section of the '*-
> package.Rd'
> > >> main
> > >>
> > >>> documentation file for the package (it seems to confuse the
> latex
> > >> compiler)
> > >>> - Put the lines '~~ Optionally other standard keywords, one per
> line,
> > >> from
> > >>
> > >>> file KEYWORDS in ~~
> > >>> ~~ the R documentation directory ~~' into the \references{}
> section,
> > >> there
> > >>
> > >>> is presently a warning about all text needing to be in a
> section.
> > >> Dear Kyle,
> > >> thanks for the suggestions. Actually, it is intended to generate
> > >> warnings /
> > >> Errors in R CMD check: We want to force package developers to
> document
> > >> their
> > >> packages probably. This way, package maintainers / developers
> have to
> > >> touch
> > >> each Rd file and cannot use them as is in order to pass the
> checks.
> > >> Best wishes,
> > >> uwe
> > >
> > > Dear Uwe,
> > > in principle, I totally agree with your point of politely forcing
> developers
> > > to write well documented packages. However, when you're trying to
> put
> > > together a package, you (or at least I) never get it completely
> right on the
> > > first, say, 20 tries ;-) Yet, by running package.skelleton() over
> and over
> > > to keep track of changes you made during the process, you
> overwrite all Rd
> > > files each time - including the ones that you might already have
> put a lot
> > > of effort into. And delaying documentation to the very end of the
> process is
> > > probably not the best idea either ;-) IMHO the community should
> favor the
> > > approaches taken by packages such as roxygen or inlinedocs as at
> least it
> > > provides some sort of direct synchronization between code and
> documentation.
> > > Maybe one could agree on rejecting code that is missing roxygen or
> inlinedoc
> > > code, which would ensure that code is documented properly. In
> fact, isn't
> > > programming all about automating unnecessary manual procedures? I
> would
> > > count starting from scratch with all help files time and time
> again to be
> > > one of those unnecessary procedures. This time could better be
> invested in
> > > increasing the package's functionality.
> >
> > - I don't think package.skeleton overwrites files unless you ask for
> it.
> >
> > - I think once you got started with your package, it is not required
> to
> > call package skeleton again. I tend to add files manually since I am
> > working on the package hierarchy itself using some editor...
>
> Hi Uwe. This message is mostly for Janko and others.
>
> You can add them manually, but I would usually use prompt(), a generic
> function that produces just one .Rd file.
>
> It's really one of the prompt methods that package.skeleton is calling
> to produce the bad man pages. My own feeling is that package.skeleton
> should produce a package that is installable, but it shouldn't pass "R
> CMD check" unless there's some manual intervention to fill in the
> details.
> I think that is the current state of affairs, but if we're producing
> something that causes "R CMD build" or "R CMD INSTALL" to fail, please
> let us know.
>
> By the way, I don't think the title can be filled in automatically
> unless a user has roxygen style documentation, so we don't. But
> doesn't
> the roxygen package do that?
>
Yes it does but I ran into the problem of roxygen not be
Re: [Rd] a small suggestion for improving the building of packages
On 16/09/2010 2:45 PM, William Dunlap wrote: > From: r-devel-boun...@r-project.org > [mailto:r-devel-boun...@r-project.org] On Behalf Of Janko Thyson > Sent: Thursday, September 16, 2010 11:19 AM > To: r-de...@r-project. org > Subject: Re: [Rd] a small suggestion for improving the > building of packages ... > Dear Uwe, > in principle, I totally agree with your point of politely > forcing developers > to write well documented packages. However, when you're trying to put > together a package, you (or at least I) never get it > completely right on the > first, say, 20 tries ;-) Yet, by running package.skelleton() > over and over > to keep track of changes you made during the process, you > overwrite all Rd > files each time - including the ones that you might already > have put a lot > of effort into. Running package.skeleton more than once is destructive. Perhaps it needs an update=TRUE/FALSE sort of option to let you add functions and Rd templates. Yes, that would be a nice addition. I think good default behaviour would be to only create new files if none of the same name already exist (and warn that's what you did), but with an option to completely overwrite what was there. When I start a package I don't use package.skeleton, mainly because it won't make all the usual directories that I expect to eventually use: src, data, inst, test (or it is tests?), etc. I'd rather that it made all the usual directories (with the proper spelling) so I could delete them if they ended up being empty. Do other package writers use package.skeleton routinely? I don't make a lot of new packages, but I do use it for quick little ones. I'm not so sure we should create all the directories: it's mainly aimed at beginners, who might find that intimidating. Advanced users can do what you do. Perhaps an option (default off) to create everything would be a good compromise. Duncan Murdoch I copy a template package directory, edit the template DESCRIPTION file, copy my code into the appropriate subdirectories, and run prompt(func, filename="pkg/man/func.Rd") on each function or dataset. The last step is a pain: it would be nice if prompt had a dir= or destdir= argument so that prompt(func, destdir="pkg/man") would make the file "pkg/man/func.Rd". Bill Dunlap Spotfire, TIBCO Software wdunlap tibco.com > And delaying documentation to the very end of > the process is > probably not the best idea either ;-) IMHO the community > should favor the > approaches taken by packages such as roxygen or inlinedocs as > at least it > provides some sort of direct synchronization between code and > documentation. > Maybe one could agree on rejecting code that is missing > roxygen or inlinedoc > code, which would ensure that code is documented properly. In > fact, isn't > programming all about automating unnecessary manual > procedures? I would > count starting from scratch with all help files time and time > again to be > one of those unnecessary procedures. This time could better > be invested in > increasing the package's functionality. > > Best regards, my thanks go out to everyone as well, > Janko > > > > Thanks, as always, to everyone for their hard work to keep my > > statistical > > > computing free and easy. > > > > > > Best, > > > > > > Kyle > > > > > > [[alternative HTML version deleted]] > > > > > > __ > > > R-devel_at_r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a small suggestion for improving the building of packages
The phrase that caught my attention in your post is the one about "running package.skeleton() over and over". When I'm developing packages, I never run it more than once. And I usually delete a lot of the files it produces (since I like to organize my functions in logical batches and not in separate files). And once I think I have the file structure organized, I put everything under version control and run future development out that system. Can you explain why you would need to re-run package.skeleton()? Is there some use case that I am missing? Kevin On 9/16/2010 1:18 PM, Janko Thyson wrote: Dear Uwe, in principle, I totally agree with your point of politely forcing developers to write well documented packages. However, when you're trying to put together a package, you (or at least I) never get it completely right on the first, say, 20 tries ;-) Yet, by running package.skelleton() over and over to keep track of changes you made during the process, you overwrite all Rd files each time - including the ones that you might already have put a lot of effort into. And delaying documentation to the very end of the process is probably not the best idea either ;-) IMHO the community should favor the approaches taken by packages such as roxygen or inlinedocs as at least it provides some sort of direct synchronization between code and documentation. Maybe one could agree on rejecting code that is missing roxygen or inlinedoc code, which would ensure that code is documented properly. In fact, isn't programming all about automating unnecessary manual procedures? I would count starting from scratch with all help files time and time again to be one of those unnecessary procedures. This time could better be invested in increasing the package's functionality. Best regards, my thanks go out to everyone as well, Janko __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a small suggestion for improving the building of packages
I agree with Kevin, I never run package.skeleton more than once. But one advantage to running it over and over again is if you change the names or the ordering of function arguments. That gets autowritten and I could see that being convenient if you change those a lot (as you sometime do in development) Kasper On Thu, Sep 16, 2010 at 5:17 PM, Kevin R. Coombes wrote: > The phrase that caught my attention in your post is the one about "running > package.skeleton() over and over". When I'm developing packages, I never > run it more than once. And I usually delete a lot of the files it produces > (since I like to organize my functions in logical batches and not in > separate files). And once I think I have the file structure organized, I > put everything under version control and run future development out that > system. > > Can you explain why you would need to re-run package.skeleton()? Is there > some use case that I am missing? > > Kevin > > On 9/16/2010 1:18 PM, Janko Thyson wrote: >> >> Dear Uwe, >> in principle, I totally agree with your point of politely forcing >> developers >> to write well documented packages. However, when you're trying to put >> together a package, you (or at least I) never get it completely right on >> the >> first, say, 20 tries ;-) Yet, by running package.skelleton() over and over >> to keep track of changes you made during the process, you overwrite all Rd >> files each time - including the ones that you might already have put a lot >> of effort into. And delaying documentation to the very end of the process >> is >> probably not the best idea either ;-) IMHO the community should favor the >> approaches taken by packages such as roxygen or inlinedocs as at least it >> provides some sort of direct synchronization between code and >> documentation. >> Maybe one could agree on rejecting code that is missing roxygen or >> inlinedoc >> code, which would ensure that code is documented properly. In fact, isn't >> programming all about automating unnecessary manual procedures? I would >> count starting from scratch with all help files time and time again to be >> one of those unnecessary procedures. This time could better be invested in >> increasing the package's functionality. >> >> Best regards, my thanks go out to everyone as well, >> Janko > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] environment variable for tar()/untar()
Hi,
Is there any reason why tar() and untar() don't use the
same environment variable?
Usage:
tar(tarfile, files = NULL,
compression = c("none", "gzip", "bzip2", "xz"),
compression_level = 6, tar = Sys.getenv("tar"))
Usage:
untar(tarfile, files = NULL, list = FALSE, exdir = ".",
compressed = NA, extras = NULL, verbose = FALSE,
tar = Sys.getenv("TAR"))
Thanks!
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] S4 plot generic documentation
Hi, Say we want to supply a generic plot() in a package with a simple class, like this: ------ setClass("track", representation=representation(x="numeric", y="numeric")) if (!isGeneric("plot")) { setGeneric("plot", function(x, y, ...) standardGeneric("plot")) } setMethod("plot", signature(x="track", y="missing"), function(x, y, ...) { plot(x...@x, x...@y, ...) }) --- --- To document the new method, I thought argument 'y' shouldn't need to be documented in the package because it's declared 'missing', and the following in plot-methods.Rd would be ok: --- --- \name{plot-methods} \docType{methods} \alias{plot-methods} \alias{plot} \alias{plot,track,missing-method} \title{Methods} \description{A plotting method} \usage{\S4method{plot}{track,missing}(x, \ldots)} \arguments{ \item{x}{track.} \item{\ldots}{Arguments passed to \code{\link{plot}}.} } \section{Methods}{ \describe{ \item{plot}{\code{signature(x="track", y="missing")}: some plot.} } } \keyword{methods} --- --- yet 'R CMD check' issues a warning: --- --- Codoc mismatches from documentation object 'plot-methods': \S4method{plot}{track,missing} Code: function(x, y, ...) Docs: function(x, ...) Argument names in code not in docs: y Mismatches in argument names: Position: 2 Code: y Docs: ... --- --- So it seems as if I'm asked to document the generic, not the particular method. What am I misunderstanding? Thanks. Cheers, -- Seb __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a small suggestion for improving the building of packages
FWIW, the package-building tools in the 'mvbutils' package-- see ?mvbutils.packaging.tools-- are supposed to alleviate much of this (provided of course you are willing to sign up to MY view of the universe...). Building a "legal" package out of existing code from scratch takes me less than 5 minutes, I never have to write a line of Rd or call package.skeleton() or remember the syntax of NAMESPACE files etc, and if I don't want to write any doco myself yet I don't have to. Plus, once I've built the package the first time, I can continue to work on it "live", without needing to unload/rebuild/reinstall all the time. The modus operandi is to work from a "task package folder"-- a level above/before the formal source-package layout-- which is the basis for (i) automatically generating the source package, and (ii) updating the installed package. WRTO some of the points in the discussion already: - Using fixr( myfunc, new.doc=T) is a bit like 'prompt'. It will add "legal" documentation to your function 'myfunc'-- ie it should pass RCMD CHECK. (As per an earlier post, this is "automatically manipulating some text to fill in the minimal documentation necessary to pass checks"). Of course, it still won't be much use to human beings unless you take the trouble to edit it. Having said that, I've come across some packages on CRAN with documentation that is little better... - Documentation is in plain-text that is automatically converted to Rd format later. Even if your plain-text is "wrong", it should still emerge as "legal" Rd & help files. - It's subsequently up to you to keep the doco in synch with any changes you make to the function itself, but at least the code & documentation for a function live next to each other in the same text file, so you are confronted with the one whenever you change the other. - You can work "live" on your package while it's loaded, and all changes/additions to the code and documentation are instantly reflected. [I know I said this already, but it bears repeating :)] R 2.12 has changed the structure of installed packages (specifically, where DLLs live), and I haven't had time to tweak mvbutils accordingly-- hopefully I will find some time to sort it out before the release of 2.12. This email may not excite much interest because-- unlike some of the other writers-- I personally found the R package creation process to be rather horrendous; it required me to learn a whole lot of very specific things that inevitably were forgotten by the next time I had to do it. In fact, it was enough to put me off writing documentation or proper packages for a long time. Now that I have an easy-to-use system in place, I've been much better about writing documentation and distributing mini-packages to colleagues. 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 Kasper Daniel Hansen wrote: > I agree with Kevin, I never run package.skeleton more than once. But > one advantage to running it over and over again is if you change the > names or the ordering of function arguments. That gets autowritten > and I could see that being convenient if you change those a lot (as > you sometime do in development) > > Kasper > > On Thu, Sep 16, 2010 at 5:17 PM, Kevin R. Coombes > wrote: >> The phrase that caught my attention in your post is the one about >> "running package.skeleton() over and over". When I'm developing >> packages, I never run it more than once. And I usually delete a lot >> of the files it produces (since I like to organize my functions in >> logical batches and not in separate files). And once I think I >> have the file structure organized, I put everything under version >> control and run future development out that system. >> >> Can you explain why you would need to re-run package.skeleton()? Is >> there some use case that I am missing? >> >> Kevin >> >> On 9/16/2010 1:18 PM, Janko Thyson wrote: >>> >>> Dear Uwe, >>> in principle, I totally agree with your point of politely forcing >>> developers to write well documented packages. However, when you're >>> trying to put together a package, you (or at least I) never get it >>> completely right on the first, say, 20 tries ;-) Yet, by running >>> package.skelleton() over and over to keep track of changes you made >>> during the process, you overwrite all Rd files each time - including >>> the ones that you might already have put a lot of effort into. And >>> delaying documentation to the very end of the process is probably >>> not the best idea either ;-) IMHO the community should favor the >>> approaches taken by packages such as roxygen or inlinedocs as at >>> least it provides some sort of direct synchronization between code >>> and documentation. Maybe one could agree on rejecting code that is >>> missing roxygen or inlinedoc code, which would ensu
