[Rd] R package repository management tools
R-devel, I'm setting up a custom repository and would like to use the install_version() function in the devtools package to control package versions. However, this function is dependent on having a CRAN-like repository setup with an archive directory and an Archive.rds file. Are there any package repository management tools that I could use? I asked this question on Stack Overflow yesterday but haven't received any answers as of yet. http://stackoverflow.com/questions/12146925/are-there-any-r-package-repository-management-tools Thanks, I appreciate the help. Erik [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] using setOldClass() causes warning on unloadNamespace() if the package imports methods
For the CRAN-package "surveillance", unloadNamespace("surveillance") gives the
following warning message:
In FUN(X[[2L]], ...) :
Created a package name, ‘2012-08-28 22:42:37’, when none found
Similar warnings appear for the CRAN-package "solaR" and probably some other
packages.
I created a dummy package (tarball is attached) to find out where this warning
comes from.
Apparently, the warning is related to the package defining a virtual S4 class
using setOldClass("fooS3class"). However, the crucial thing is that the warning
only appears, when the methods package is imported in the NAMESPACE. There is
also no warning if setClass("fooS3class") is used instead. So my question is:
What would be the right way of handling S3 classes in the S4 world?
My minor second question is: Should the NAMESPACE state exportMethods(coerce)
if the package defines new coerce-methods? It seems that coercion-methods
defined by the package using setAs() are also visible after loading the package
without explicitly exporting these. However, if one includes
exportMethods(coerce) then one must also document them (as stated by R CMD
check).
Thanks for any hints!
Sebastian
PS: using
R Under development (unstable) (2012-08-28 r60472)
Platform: x86_64-unknown-linux-gnu (64-bit)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] include dll in R-package
Thanks a lot for those examples, is there any example with Fortran source codes which could depend on an external Fortran DLL? Liy - 原始邮件 - 发件人: "Berend Hasselman" 收件人: "LIYING HUANG" 抄送: "Kasper Daniel Hansen" , r-devel@r-project.org 发送时间: 星期二, 2012年 8 月 28日 上午 7:02:02 主题: Re: [Rd] include dll in R-package On 28-08-2012, at 01:29, LIYING HUANG wrote: > > I am quite new in R, I looked at R manual- how to build R Package, > still not very clear. Yes, it would be very helpful if I could > download a package having Fortran source codes to look at, Do > you know any package built with Fortran source code? Thanks! > To mention a few: deSolve minpack.lm nleqslv rootSolve xts and probably many more. Berend __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] "Ambiguous" variation of default environment in `getClasses()` (standard function vs. formal S4 method)
Dear list, This probably makes perfect sense from the language designers' perspective, but at least for me this was/is quite an interesting and unexpected behavior which I thought might be worth sharing: The default value of argument |where|in function |getClasses()|seems to vary depending on whether |getClasses()|is called inside a *standard R function*or a *formal S4 method*. It is controlled by |.externalCallerEnv()|, which seems to be "vulnerable" to /lazy evaluation/and/or an "altered" /lexical scoping/structure (possible introduced by the definition of a formals S4 method?) and thus causes the variation**. I found it quite hard to understand what's exactly going on as you need to manually debug `getClasses()` in order to find out what the default value of `where` (controlled by `|.externalCallerEnv()`) actually is in the various settings|. But that of course might as well be just me ;-) For those interested, I tried to illustrate the behavior in this SO post: http://stackoverflow.com/questions/12166645/ambiguous-variation-of-default-environment-in-getclasses-standard-function/12174390#12174390 Best regards, Janko Thyson [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] include dll in R-package
On 29-08-2012, at 05:31, LIYING HUANG wrote: > > > Thanks a lot for those examples, is there any example with Fortran > source codes which could depend on an external Fortran DLL? > I wouldn't know. Berend __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] include dll in R-package
On 29/08/2012 12:19, Berend Hasselman wrote: On 29-08-2012, at 05:31, LIYING HUANG wrote: Thanks a lot for those examples, is there any example with Fortran source codes which could depend on an external Fortran DLL? I wouldn't know. Berend What does 'depend on' mean here? (All the context has been removed, pace the posting guide.) If it means 'link to', then any package which uses BLAS or LAPACK is an example. But strictly you cannot link to a DLL (although you can on Windows, but on OS X what R calls DLL is not what OS X calls a 'dynamic library'). If you want to dynamically load an external DLL then - there are no Fortran examples on CRAN - you need to ensure that the DLL is already linked to the Fortran runtime (which typically Fortran DLLs are not). -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Suggestion: Change default to download.file(..., mode="wb") ...instead of mode="w" with some bells and whistles
Hi,
I keep seeing the problem where people are download binary files as
text (mode="w") when using R's download.file() for FTP/HTTP downloads.
It often results in unnecessary troubleshooting until one concludes
that the downloaded file has been corrupted due to (what I think is)
translated newlines. Search the r-help mailing list and you'll find
other examples of this. This may or may not only be a problem for
Windows users.
I'd like to suggest to change the default of argument 'mode' of
download.file() to be mode="wb". The "default" is current mode="w"
except when argument 'mode' is missing (not explicitly given),
download.file() tries to be helpful by forcing 'mode' to be "wb" for
certain filename extensions. NB: help("download.file",
package="utils") has a paragraph on all this. BTW, the latter seems
to be done in a case-sensitive way, such that *.zip and *.ZIP will
have different behaviors.
Wouldn't it just be safer to change the default to mode="wb"? ...or
are there use cases that I'm overseeing - is anyone out there
intentionally using the "text" transfer mode?
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
