Re: [Rd] formal process for orphaning a package
I agree that the file shows the _reasons_ but that is not the same as a _process_. With the high volume of packages that the CRAN maintainers handle, an explicit procedure beyond "request it" is needed or should at least be spelled out. We have pushed everything CRAN-related else towards automation, verification, and formalization; this shouldn't be different. On Wed, Sep 21, 2016 at 12:53 PM, Andrew Redd wrote: > The README states clearly that a package is orphaned under any of three > conditions: > > The Maintainer requests is. > The maintainer email bounces > The maintainer is unresponsive to requests regarding the package from CRAN > maintainers > > But I think that it is a good idea to include those conditions in the > manuals. > > On Wed, Sep 21, 2016 at 9:30 AM Max Kuhn wrote: >> >> The CRAN policy page >> (https://cran.r-project.org/web/packages/policies.html) implies that >> there is a formal procedure for orphaning a package but none is >> mentioned in the Extensions manual >> (https://cran.r-project.org/doc/manuals/r-devel/R-exts.html). >> >> This page (https://cran.r-project.org/src/contrib/Orphaned/README) >> implies that one would simply resubmit the package to CRAN with the >> text "ORPHANED" in the `Maintainer` field. >> >> Is this the case? >> >> If this is not documented somewhere, can it be added to the Extensions >> manual? >> >> Thanks, >> >> Max >> >> __ >> 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] formal process for orphaning a package
The CRAN policy page (https://cran.r-project.org/web/packages/policies.html) implies that there is a formal procedure for orphaning a package but none is mentioned in the Extensions manual (https://cran.r-project.org/doc/manuals/r-devel/R-exts.html). This page (https://cran.r-project.org/src/contrib/Orphaned/README) implies that one would simply resubmit the package to CRAN with the text "ORPHANED" in the `Maintainer` field. Is this the case? If this is not documented somewhere, can it be added to the Extensions manual? Thanks, Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Programming Tools CTV
On Thu, Jan 22, 2015 at 1:05 PM, Achim Zeileis wrote: > On Thu, 22 Jan 2015, Max Kuhn wrote: > >> On Thu, Jan 22, 2015 at 12:45 PM, Achim Zeileis >> wrote: >>> >>> On Thu, 22 Jan 2015, Max Kuhn wrote: >>> >>>> I've had a lot of requests for additions to the reproducible research >>>> task view that fall into a grey area (to me at least). >>>> >>>> For example, roxygen2 is a tool that broadly enable reproducibility >>>> but I see it more as a tool for better programming. I'm about to check >>>> in a new version of the task view that includes packrat and >>>> checkpoint, as they seem closer to reproducible research, but also >>>> feel like coding tools. >>>> >>>> There are a few other packages that many would find useful for better >>>> coding: devtools, testthat, lintr, codetools, svTools, rbenchmark, >>>> pkgutils, etc. >>>> >>>> This might be some overlap with the HPC task view. I would think that >>>> rJava, Rcpp and the like are better suited there but this is arguable. >>>> >>>> The last time I proposed something like this, Martin deftly convinced >>>> me to be the maintainer. It is probably better for everyone if we >>>> avoid that on this occasion. >>>> >>>> * Does anyone else see the need for this? >>>> >>>> * What other packages fit into this bin? >>>> >>>> * Would anyone like to volunteer? >>> >>> >>> >>> Max, thanks for the suggestion. We had a somewhat related proposal on >>> R-help >>> from Luca Braglia a couple of months ago, suggesting a "Package >>> Development" >>> task view: >>> https://mailman.stat.ethz.ch/pipermail/r-devel/2014-July/069454.html >>> >>> He put up some ideas on Github: >>> https://github.com/lbraglia/PackageDevelopmentTaskView >>> >>> When Luca asked me (ctv maintainer) and Dirk (HPC task view maintainer) >>> for >>> feedback off-list, I replied that it is important that task views are >>> focused in order to be useful and maintainable. My feeling was that >>> "PackageDevelopment" was too broad and also "ProgrammingTools" is still >>> too >>> board, I think. This could mean a lot of things/tools to a lot of people. >>> >>> But maybe it would be to factor out some aspect that is sharp and >>> clear(er)? >>> Or split it up into bits where there are (more or less) objectively clear >>> criteria for what goes in and what does not? >> >> >> It's funny that you said that. As I was updating the RR CTV, it >> realized what a beast it is right now. I thought about making a github >> project earlier today that would have more detailed examples and >> information. >> >> I see two problems with that as the *sole* solution. >> >> First, it is divorced from CRAN CTV and that is a place that people >> know and will look. I had no idea of Luca's work for this exact >> reason. >> >> Secondly, might be intimidating for new R users who, I think, are the >> targeted cohort for the CTVs. > > > Yes, I agree. There should (an) additional task view(s) on CRAN related to > this. > >> How about a relatively broad definition that is succinct in content >> with a link to a github repos? > > > I think this doesn't fit well with the existing development model and might > require duplicating changes in the of the task view. In order > to be easily installable I need the in the task view on CRAN > and not just in the linked list on Github. Many of the task views are encyclopedic and still focused. Perhaps my issues with RR are more related to how I currently organize it. I'll try to solve it that way. > Therefore, I would suggest splitting up the topic into things that are > fairly sharp and clear. (Of course, it is impossible to avoid overlap > completely.) For example, one could add "LanguageInterfaces" or something > like that. Looking at Luca's page, I think he does a great job of clustering packages. My suggestions for focused topics are: - Package Development* - Foreign Languages Interfaces - Code Analysis and Debugging - Profiling and Benchmarking - Unit Testing * I would define the first one to be more narrow than the original definition. I think that most of these would encompass less than 10 packages if we don't include all the Rcpp depends =] > And the task views on CRAN can always include to further > documentation on Github and elsewhere. Especially when it comes to package > development there are also clearly different preferences about what is good > style or the right tools (say Github vs. R-Forge, knitr vs. Sweave, etc.) Yes. The comments above would not exclude this approach, which is/was/might be my intention for RR. Thanks, Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Programming Tools CTV
On Thu, Jan 22, 2015 at 12:45 PM, Achim Zeileis wrote: > On Thu, 22 Jan 2015, Max Kuhn wrote: > >> I've had a lot of requests for additions to the reproducible research >> task view that fall into a grey area (to me at least). >> >> For example, roxygen2 is a tool that broadly enable reproducibility >> but I see it more as a tool for better programming. I'm about to check >> in a new version of the task view that includes packrat and >> checkpoint, as they seem closer to reproducible research, but also >> feel like coding tools. >> >> There are a few other packages that many would find useful for better >> coding: devtools, testthat, lintr, codetools, svTools, rbenchmark, >> pkgutils, etc. >> >> This might be some overlap with the HPC task view. I would think that >> rJava, Rcpp and the like are better suited there but this is arguable. >> >> The last time I proposed something like this, Martin deftly convinced >> me to be the maintainer. It is probably better for everyone if we >> avoid that on this occasion. >> >> * Does anyone else see the need for this? >> >> * What other packages fit into this bin? >> >> * Would anyone like to volunteer? > > > Max, thanks for the suggestion. We had a somewhat related proposal on R-help > from Luca Braglia a couple of months ago, suggesting a "Package Development" > task view: > https://mailman.stat.ethz.ch/pipermail/r-devel/2014-July/069454.html > > He put up some ideas on Github: > https://github.com/lbraglia/PackageDevelopmentTaskView > > When Luca asked me (ctv maintainer) and Dirk (HPC task view maintainer) for > feedback off-list, I replied that it is important that task views are > focused in order to be useful and maintainable. My feeling was that > "PackageDevelopment" was too broad and also "ProgrammingTools" is still too > board, I think. This could mean a lot of things/tools to a lot of people. > > But maybe it would be to factor out some aspect that is sharp and clear(er)? > Or split it up into bits where there are (more or less) objectively clear > criteria for what goes in and what does not? It's funny that you said that. As I was updating the RR CTV, it realized what a beast it is right now. I thought about making a github project earlier today that would have more detailed examples and information. I see two problems with that as the *sole* solution. First, it is divorced from CRAN CTV and that is a place that people know and will look. I had no idea of Luca's work for this exact reason. Secondly, might be intimidating for new R users who, I think, are the targeted cohort for the CTVs. How about a relatively broad definition that is succinct in content with a link to a github repos? Thanks, Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Programming Tools CTV
I've had a lot of requests for additions to the reproducible research task view that fall into a grey area (to me at least). For example, roxygen2 is a tool that broadly enable reproducibility but I see it more as a tool for better programming. I'm about to check in a new version of the task view that includes packrat and checkpoint, as they seem closer to reproducible research, but also feel like coding tools. There are a few other packages that many would find useful for better coding: devtools, testthat, lintr, codetools, svTools, rbenchmark, pkgutils, etc. This might be some overlap with the HPC task view. I would think that rJava, Rcpp and the like are better suited there but this is arguable. The last time I proposed something like this, Martin deftly convinced me to be the maintainer. It is probably better for everyone if we avoid that on this occasion. * Does anyone else see the need for this? * What other packages fit into this bin? * Would anyone like to volunteer? Thanks, Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] csv version of data in an R object
For a package, I need to write a csv version of a data set to an R object. Right now, I use: out <- capture.output( write.table(x, sep = ",", na = "?", file = "", quote = FALSE, row.names = FALSE, col.names = FALSE)) To me, this is fairly slow; 131 seconds for a data frame with 8100 rows and 1400 columns. The data will be in a data frame; I know write.table() would be faster with a matrix. I was looking into converting the data frame to a character matrix using as.matrix() or, better yet, format() prior to the call above. However, I'm not sure what an appropriate value of 'digits' should be so that the character version of numeric data has acceptable fidelity. I also tried using a text connection and sink() as shown in ?textConnection but there was no speedup. Any suggestions or ideas? Thanks, Max > sessionInfo() R version 2.14.0 (2011-10-31) Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/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.14.0 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] informal conventions/checklist for new predictive modeling packages
Working on the caret package has exposed me to the wide variety of
approaches that different authors have taken to creating predictive
modeling functions (aka machine learning)(aka pattern recognition).
I suspect that many package authors are neophyte R users and are
stumbling through the process of writing their first R package (or R
code). As such, they may not have been exposed to some of the informal
conventions that have evolved over time. Also, their package may be
intended to demonstrate their research and not for "production"
modeling. In any case, it might be a good idea to print up a few
points for consideration when creating a predictive modeling package.
I don't propose changes to existing code.
Some of this is obvious and not limited to this class of modeling
packages. Many of these points are arguable, so please do so.
If this seems useful, perhaps we could repost the final list to R-Help
to use as a checklist.
Those of you who have used my code will probably realize that I am not
a grand architect of R packages =] I'd love to get feedback from those
of you with a broader perspective and better software engineering
skills than I (a low bar to step over).
I have marked a few of these items with an OCD tag since I might be
taking it a bit too far.
The list:
(1) Extend the work of others. There is an amazing amount of unneeded
redundancy. There are plenty of times that users implement their own
version of a function because there is an missing feature, but a lot
of time is spent re-creating duplicate functions. For example, kernlab
has an excellent set of kernel functions that are really efficient and
have useful ancillary functions. People may not new aware of these
functions, but they are one RSiteSearch away. (Perhaps we could
nominate a few packages like kernlab that implement a specific tool
well)
(2) When modeling a categorical outcome, use a factor as input (as
opposed to 0/1 indicators or integers). Factors are exactly the kind
of feature that separates R from other languages (I'm looking at you
SAS) and is a natural structure for this data type.
corollary (2a): save the factor levels in the model object somewhere
corollary (2b): return predicted classes as factors with the same
levels (and ordering of levels).
(3) Implement a separate prediction function. Some packages only make
predictions when the model is built, so effectively the model cannot
be used at any point in the future.
corollary (3a): use object-orientation (eg. predict.{class}) and not
some made-up function name "modelPredict()" for predicting new
samples.
(4) If the method only accepts a specific type of input (eg. matrix or
data frame), please do the conversion whenever appropriate.
(5) Provide a formula interface (eg. foo(y~x, data = dat)) and
non-formula interface (foo(x, y) to the function. Formula methods are
really inefficient at this time for large dimensional data but are
fantastically convenient. There are some good reasons to not use
formulas, such as functions that do not use a design matrix (eg.
cforest()) or need factors to be handled in a non-standard way (eg.
cubist()).
(6) Don't require a test set when model building.
(7) Control all written output during model-building time with a
verbose option. Resampling can make a mess out of things if
output/logging is always exposed.
(8) Please use RSiteSearch to avoid name collisions between packages
(eg. gam(), splsda(), roc(), LogitBoost()). Also search Bioconductor.
(9) Allow the predict function to generate results from many different
sub-models simultaneously. For example, pls() can return predictions
across many values of ncomp. enet(), cubist(), blackboost() are other
examples.
corollary (9a): [OCD] ensure the same object type for predictions.
There are occasions where predict() will return a vector or a matrix
depending on the context. I would argue that this is not optimal.
(10) Use a limited vocabulary for options. For example, some predict()
functions have a "type" options to switch between predicted classes
and class probabilities. Values of "type" pertaining to class
probabilities range from "prob", "probability", "posterior", "raw",
"response", etc. I'll make a suggestion of "prob" as a possible
standard for this situation.
(11) Make sure that class probabilities sum to one. Seriously.
(12) If the model implicitly conducts feature selection, do not
require un-used predictors to be present in future data sets for
prediction. This may be a problem when the formula interface to models
is used, but it looks like many functions reference columns by
position and not name.
(13) Packages that have their own cross-validation functions should
allow the users to pass in the specific folds/resamping indicators to
maintain consistency across similar functions in other packages.
(14) [OCD] For binary classification models, model the probability of
the first level of a factor as the event of interest (again, for
consistency) Note that glm() d
Re: [Rd] object not found whilst loading namespace
Please disregard the last email...
The issue was a syntactical error in a file that, alphabetically,
comes before confusionMatrix.R in the package.
The odd thing was that the problem in this file did not throw and
error (or I would have easily found it). I decided to source the R
files one by one to see if there were any issues and that showed the
problem:
> source("~/Code/caret/pkg/caret/R/classLevels.R")
Error in source("~/Code/caret/pkg/caret/R/classLevels.R") :
~/Code/caret/pkg/caret/R/classLevels.R:150:0: unexpected end of input
Thanks anyway,
Max
On Tue, Mar 15, 2011 at 9:48 PM, Max Kuhn wrote:
> I've been updating a package and, when installing a local devel
> version, I get an error "object 'confusionMatrix' not found whilst
> loading namespace". Looking around online, it appears that this might
> be related to loading a specific RData file, but it doesn't seem to be
> the case AFAICT.
>
> I've installed the devel version in the last week without issues and
> the confusionMatrix code has been touched in a while.
>
> Thanks,
>
> Max
>
>> sessionInfo()
> R version 2.11.1 (2010-05-31)
> 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
>
> other attached packages:
> [1] caret_4.71 reshape_0.8.3 plyr_1.2.1 lattice_0.18-8
>
> loaded via a namespace (and not attached):
> [1] grid_2.11.1
>
>
> pkg_kuhna03$ R CMD INSTALL caret
> * installing to library ‘/Library/Frameworks/R.framework/Resources/library’
> * installing *source* package ‘caret’ ...
> ** libs
> *** arch - i386
> gcc -arch i386 -std=gnu99
> -I/Library/Frameworks/R.framework/Resources/include
> -I/Library/Frameworks/R.framework/Resources/include/i386
> -I/usr/local/include -fPIC -g -O2 -c caret.c -o caret.o
> gcc -arch i386 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names
> -undefined dynamic_lookup -single_module -multiply_defined suppress
> -L/usr/local/lib -o caret.so caret.o
> -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework
> -Wl,CoreFoundation
> installing to
> /Library/Frameworks/R.framework/Resources/library/caret/libs/i386
> *** arch - x86_64
> gcc -arch x86_64 -std=gnu99
> -I/Library/Frameworks/R.framework/Resources/include
> -I/Library/Frameworks/R.framework/Resources/include/x86_64
> -I/usr/local/include -fPIC -g -O2 -c caret.c -o caret.o
> gcc -arch x86_64 -std=gnu99 -dynamiclib
> -Wl,-headerpad_max_install_names -undefined dynamic_lookup
> -single_module -multiply_defined suppress -L/usr/local/lib -o caret.so
> caret.o -F/Library/Frameworks/R.framework/.. -framework R
> -Wl,-framework -Wl,CoreFoundation
> installing to
> /Library/Frameworks/R.framework/Resources/library/caret/libs/x86_64
> ** R
> ** data
> ** inst
> ** preparing package for lazy loading
> Loading required package: plyr
>
> Attaching package: 'reshape'
>
> The following object(s) are masked from 'package:plyr':
>
> round_any
>
> ** help
> *** installing help indices
> ** building package indices ...
> ** testing if installed package can be loaded
> Error : object 'confusionMatrix' not found whilst loading namespace 'caret'
> ERROR: loading failed
> * removing ‘/Library/Frameworks/R.framework/Resources/library/caret’
> * restoring previous ‘/Library/Frameworks/R.framework/Resources/library/caret’
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] object not found whilst loading namespace
I've been updating a package and, when installing a local devel version, I get an error "object 'confusionMatrix' not found whilst loading namespace". Looking around online, it appears that this might be related to loading a specific RData file, but it doesn't seem to be the case AFAICT. I've installed the devel version in the last week without issues and the confusionMatrix code has been touched in a while. Thanks, Max > sessionInfo() R version 2.11.1 (2010-05-31) 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 other attached packages: [1] caret_4.71 reshape_0.8.3 plyr_1.2.1 lattice_0.18-8 loaded via a namespace (and not attached): [1] grid_2.11.1 pkg_kuhna03$ R CMD INSTALL caret * installing to library ‘/Library/Frameworks/R.framework/Resources/library’ * installing *source* package ‘caret’ ... ** libs *** arch - i386 gcc -arch i386 -std=gnu99 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/i386 -I/usr/local/include-fPIC -g -O2 -c caret.c -o caret.o gcc -arch i386 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/lib -o caret.so caret.o -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation installing to /Library/Frameworks/R.framework/Resources/library/caret/libs/i386 *** arch - x86_64 gcc -arch x86_64 -std=gnu99 -I/Library/Frameworks/R.framework/Resources/include -I/Library/Frameworks/R.framework/Resources/include/x86_64 -I/usr/local/include-fPIC -g -O2 -c caret.c -o caret.o gcc -arch x86_64 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/lib -o caret.so caret.o -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation installing to /Library/Frameworks/R.framework/Resources/library/caret/libs/x86_64 ** R ** data ** inst ** preparing package for lazy loading Loading required package: plyr Attaching package: 'reshape' The following object(s) are masked from 'package:plyr': round_any ** help *** installing help indices ** building package indices ... ** testing if installed package can be loaded Error : object 'confusionMatrix' not found whilst loading namespace 'caret' ERROR: loading failed * removing ‘/Library/Frameworks/R.framework/Resources/library/caret’ * restoring previous ‘/Library/Frameworks/R.framework/Resources/library/caret’ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] broken link on CRAN
Peter and Simon, That was the issue. Thanks, Max On Mon, Feb 28, 2011 at 3:48 PM, Simon Urbanek wrote: > > On Feb 28, 2011, at 3:22 PM, Max Kuhn wrote: > >> The link to >> >> http://cran.r-project.org/bin/macosx/R-2.12.1.pkg >> >> on the CRAN page >> >> http://cran.r-project.org/bin/macosx/ >> >> is broken. > > There is no such link on the page - it's R-2.12.2.pkg now - I suspect you > have a cached page in your browser - try reloading it. > > Cheers, > Simon > > >> Also, the email address for the webmaster is null (which is >> why I'm emailing here). >> >> Thanks, >> >> Max >> >> > > -- Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] broken link on CRAN
The link to http://cran.r-project.org/bin/macosx/R-2.12.1.pkg on the CRAN page http://cran.r-project.org/bin/macosx/ is broken. Also, the email address for the webmaster is null (which is why I'm emailing here). Thanks, Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Reproducible Research task view
I would like to suggest a Reproducible Research CRAN task view. This was discussed briefly in one of the useR! sessions this year. >From quick browse through CRAN, I counted 19 packages that were associated with Sweave or other methods for reproducible research. I think that we've gotten to a point where some additional documentation that enumerates/compares/contrasts the various packages would be helpful. I'd like to volunteer to create and maintain the task view. Any thoughts? Thanks, Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] packages checks on OS X with 2.12 devel
Professor Ripley, >> R version 2.12.0 Under development (unstable) (2010-08-08 r52687) >> Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) >> >> I install packages via install.packages with type = "source" (I stick >> to arch=x86_64). I've had no issues with installs. > > What is very strange is that you seem to have built R with two archs: why if > you don't want to use i386? If you build R with just one arch, it will only > install/check ... that one arch. So this is shooting yourself in the foot! I used the pre-compiled version from http://r.research.att.com/. Perhaps something has changed there; I've never had this come up as an issue. > --no-multiarch is an option to check, not to R. This is the mistake on my part. Everything is working now. Thanks, Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] packages checks on OS X with 2.12 devel
I'm checking packages under the devel version on OS X > sessionInfo() R version 2.12.0 Under development (unstable) (2010-08-08 r52687) Platform: x86_64-apple-darwin9.8.0/x86_64 (64-bit) I install packages via install.packages with type = "source" (I stick to arch=x86_64). I've had no issues with installs. When I check packages via R --arch=x86_64 CMD check package I see: * using platform: x86_64-apple-darwin9.8.0 (64-bit) … * loading checks for arch ‘i386’ … * loading checks for arch ‘x86_64’ … ** running examples for arch ‘i386’ The check then fails since the packages are not installed on i386. I tried R --arch=x86_64 --no-multiarch CMD check package but that still runs checks on x86_64 and i386. I didn't find anything else in the "what's new" for the latest devel version. I'd prefer not to install the full crane and bioconductor set in both architectures. Any suggestions (especially for the documentation that I'm sure exists but I can't find). Thanks, Max -- Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Creating RPMs for Packages
My company is trying to manage R installations across a number large SMP machines. We're thinking out the best way to manage the packages installs and updates. They would be happy if we could work out RPM's for package installations (traceable, easily facilitated with existing sw management tools). I don't know a lot and RPMs beyond how to use them, but it seems plausible to write R code to create the RPM package. If we need to update package X, which triggers and update of ancillary packages Y and Z, it should be possible to use available.packages() to figure out the dependencies, download the sources, write out the RPM headers and package things up. Before I try to write any code, does anyone see any issues with this (or has it already been done)? Is this a ridiculous approach? Thanks, Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] link to latest package announcements
I wasn't sure where to send this... On the "What's New" section of the homepage, the "Latest" package link points towards https://stat.ethz.ch/pipermail/r-packages/2008/date.html#end It should probably point towards 2009. Thanks, Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Closed-source non-free ParallelR ?
> REvolution appear to be offering ParallelR only when bundled with their R > Enterprise edition. As such it appears to be non-free and closed source. >http://www.revolution-computing.com/products/parallel-r.php Have you also looked at: http://nws-r.sourceforge.net/ The core of their ParallelR product is nws and that package was last updated a month ago. -- Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggestion for R >= 3.0: computer-readable CHANGELOG
On Fri, Apr 17, 2009 at 2:09 PM, Philippe Grosjean
wrote:
> OK, then, I catch the practical point of view that is: nobody will use it
> and we cannot force people to use it. So, it means that we should think
> about tools to *automatically* generate a limited set of entries in the
> CHANGELOG.
Of course this tells you what was changed but not why. I'd like to
know a more top-level "what" and, more importantly, "why".
It would also pick up code formatting changes.
> Something like new functions appearing in a package, functions being
> deprecated, change in the function's interface (arguments definition),
> change in the dependence of packages could be tracked automatically if the
> previous version of the package is available. This should be the case for
> packages on CRAN and Bioconductor, after first release. So, those
> "changelog" tools should be best deployed at this level.
>
> Further details could be provided directly inside the code, using simple
> formatting, and proposed as a purely optional feature. I think at something
> like:
>
> foo <- function (x, mynewarg) {
> #CHANGE# arg:mynewarg:A new argument in my function
> ...
> }
>
> or
>
> bar <- function (y) {
> #CHANGE# fun:Short details about this new function
> }
>
My code is ugly enough without the extra help, and this would take
things to a new level of ugly.
Sorry to pick on this, but it is also optional and suffers from the
same issues as you mentioned above.
--
Max
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] no visible binding for global variable
Everyone,
I know that this has been discussed a few times on the list, but I
think that there is a high false positive rate of messages from
findGlobals during R CMD check (I know the help page has that "The
result is an approximation").
Here are two examples of from the caret package:
This function get the message "predictors.gbm: no visible binding for
global variable 'rel.inf'"
predictors.gbm <- function(x, ...)
{
library(gbm)
varList <- if(hasTerms(x)) predictors(x$terms) else colnames(x$data$x.order)
relImp <- summary(x, plotit = FALSE)
varUsed <- as.character(subset(relImp, rel.inf != 0)$var)
basicVars(varList, varUsed)
}
So it didn't take the context into account that subset isn't
(necessarily) looking in the global environment.
Also, the package has a file splsda.R that has the message
"splsda.default: no visible binding for global variable 'ncomp'". The
oddness of this one is that there is no variable named ncomp
explicitly mentioned in the file (confirmed by grep and I checked that
the function wasn't accidentally defined twice).
In fairness, this function has caught little issues in my code that
could have led to issues, so I'm certainly not implying that it is
ineffective. Looking through the page with package check results,
there are a lot of packages with these types of notes and it makes me
wonder how many of them are real issues. Of course they are only
notes, but the extra verboseness might make people not pay as much
attention when a big issues arises.
Thanks
Max
> sessionInfo()
R version 2.9.0 Under development (unstable) (2009-01-22 r47686)
i386-apple-darwin9.6.0
locale:
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
other attached packages:
[1] codetools_0.2-1
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestions for improving R-FAQ
Hadley, These are good suggestions. > * Remove infrequently asked questions - e.g. 2.3, 2.4, 7.9, 7.11, > 7.12, 7.15, 7.19, 7.23, 7.28 I'd like to lobby to keep 7.23 and 7.28. I still get questions about those. Sampling bias might be an issue: we don't get questions (to r-help) for those because those are in the FAQ. Perhaps that is wishful thinking on my part. -- Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] name conflicts
Everyone, I've got code in my package that uses LogitBoost from the caTools package. caTools does not have a namespace. My package also uses loads RWeka, which has a namespace, and also has a function called LogitBoost. After loading both packages, how can I be specific about running the version from caTools (since caTools:::LogitBoost won't work)? Thanks, Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Sweave: Variables in code chunk headers
On Dec 1, 2007 3:56 PM, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > My understanding is that Michael wants to have the Sweave options in a > chunk depend on a calculation happening in the underlying R session. > This is hard to do with hooks, because they are run after the options > have already been processed. This may not be of practical help, but odfWeave allows you to do this (assuming that I understand the question). One clean way to do this in Sweave would be to change how the device is called. In odfWeave, if <>=. a new device is opened and the image specifications are retreived from global variables. See odfWeave:::RweaveOdfRuncode, setimageDefs and adjustImageSize in the odfWeave package. I'd love to see this type of change in Sweave, but it would be a big departure form the current code base. -- Max __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
