[Rd] a small suggestion for improving the building of packages
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.
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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] a small suggestion for improving the building of packages
Uwe,
Yes, this makes good sense. All I am saying is that it is somewhat out of
the "open-source, the user is smart and we should not _artificially force_
him or her to jump through some hoop". I do not contend that packages
destined for CRAN should have anything but the fullest documentation
possible: somewhat in the spirit of other open-source projects R should
impose quite stringent requirements for potential contributors, but make it
as easy as possible for someone to play around on their own isolated
projects.
Keep up the good work.
Best,
Kyle
2010/9/15 Uwe Ligges
>
>
> 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
>
>
>
>
> 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@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
[[alternative HTML version deleted]]
__
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
Yes, well, anyone clever enough to do this will not be stopped by
automatically manipulating some text to fill in the minimal documentation
necessary to pass checks.
On Wed, Sep 15, 2010 at 8:01 AM, Liaw, Andy wrote:
> From: Uwe Ligges
>
> >
> >
> > 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.
>
> Or else it may be possible to have some malicious person write a script
> that
> automagically generate some large number of bogus packages and submit
> them to CRAN...
>
> Andy
>
>
> > Best wishes,
> > uwe
> >
> >
> >
> >
> > > 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@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
> >
> Notice: This e-mail message, together with any attach...{{dropped:16}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[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] pictex
The example at ?pictex does not work (the driver apparently uses
'rotatebox') for me as stated. It did compile after including the
graphicsx package. A MWE is at the help page for pictex. I tried to
get in touch with Valerio but his email bounced. Probably we want to
add a \usepackage{graphicsx} to the help page and try to track down
Valerio.
Cheers,
Kyle
This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009)
> sessionInfo()
R version 2.10.1 (2009-12-14)
x86_64-apple-darwin9.8.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_2.10.1
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
