[Rd] r-forge certificate expired?
Is anybody else getting the error that R-Forge's certificate has expired on 2010-05-21? I'm wondering if it is safe to proceed with adding a security exception... ~Michal __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] warning from install.packages()
> On 25/05/10 23:25 PM, "Ben Bolker" ufl.edu> wrote:
> Just curious: is there a particular reason why install.packages()
> gives a warning in normal use when 'lib' is not specified (e.g. argument
> 'lib' is missing: using '/usr/local/lib/R/site-library' )?
Bump.
>From install.packages in utils/R/packages2.R:
if(missing(lib) || is.null(lib)) {
lib <- .libPaths()[1L]
if(length(.libPaths()) > 1L)
warning(gettextf("argument 'lib' is missing: using '%s'", lib),
immediate. = TRUE, domain = NA)
}
If I were patching this I would simply comment out this whole test
(rather than making a message() à la Jari Oksanen) -- it seems to
make the most sense to execute the documented behavior silently ...
I will submit this as a wishlist item shortly if no-one complains.
Ben Bolker
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 00LOCK and nfs
Further experimentation using this patch to install.packages shows
that I sometimes have remaining 00LOCK-pkgname directories after doing
a massive update on a multi-user system with R installed on NFS.
However, I have never had install.packages/update.packages stop midway
because of an unremovable 00LOCK directory. I therefore consider the
patch to be big improvement for people like me, having a multi-user R
installed on NFS. Private followups to my original email shows that I
am not the only one with this problem.
I would very much like the patch (or some variant hereof) to be
considered for inclusion in R-devel.
Kasper
On Tue, May 18, 2010 at 11:59 AM, Kasper Daniel Hansen
wrote:
> This is a follow-up to an old thread with kind of solution to the
> 00LOCK problem on NFS.
>
> I have made a patch to install.packages to accept a new argument
> locktype = c("lock", "no-lock", "pkglock")
> which is passed to R CMD INSTALL. This addition might have
> independent interest aside from the NFS problem, as it exposes
> functionality from R CMD INSTALL to install.packages and the very
> convenient update.packages. Patches are at
> http://www.biostat.jhsph.edu/~khansen/packages2.R-patch
> http://www.biostat.jhsph.edu/~khansen/install.packages.Rd-patch
> (patches to files in the utils package) and both
> R-devel (R version 2.12.0 Under development (unstable) (2010-05-17 r52025))
> and
> R-2.11 (R version 2.11.0 Patched (2010-05-17 r52025))
> passed make check-all with these two patches applied. I thought about
> adding a note describing my findings below to the details section, but
> decided against it.
>
> Regarding the 00LOCK problem. In my testing, using the patches above
> and setting locktype = "pkglock", makes it possible to deal with the
> NFS problem. Specifically, I have not been able to make
> update.packages() fail midway, due to a un-removable 00LOCK file
> (which is not too surprising, as I now have a per-package lock).
>
> However, sometimes (but far less frequently than before), a
> 00LOCK-pkgname directory remains after update/install.packages.
> Sometimes this 00LOCK-pkgname directory does not contain any .nfs*
> files (!?) and sometimes it does. For this reason, I still precede any
> install/update.packages with a check for the existence of a
> 00LOCK-pkgname directory and an attempt to remove it.
>
> The difference between using locktype = "pkglock" and not is
> specifically that without, it was possible for update.packages to fail
> midway even though there were no 00LOCK* files at the start of the
> update process.
>
> Originally I hypothesized that the presence of the .nfs* files in the
> 00LOCK directory had to do with synchronization issues between the
> file server and the compute node. In order to approach this I tried
> to insert a
> system("sleep 10")
> at the beginning of
> do_cleanup
> in
> tools/R/install.R
> but that did not work.
>
> Since the pkglock approach described above seems to solve this issue
> for me, I have not pursued the synchronization issue further.
>
> Kasper
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-forge certificate expired?
On 01.06.2010 11:18, Michał Bojanowski wrote: Is anybody else getting the error that R-Forge's certificate has expired on 2010-05-21? I'm wondering if it is safe to proceed with adding a security exception... Yes, I asked Stefan already and R-forge is trying to get a new one which takes more time than expected. Uwe Ligges ~Michal __ 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] codetools: Suggestion to detect potentially unassigned variables
This is just a note/wishlist/for the record:
With
foo1 <- function() {
res;
}
foo2 <- function() {
for (i in c()) res <- 1;
res;
}
foo3 <- function() {
while (FALSE) res <- 1;
res;
}
foo4 <- function() {
if (FALSE) res <- 1;
res;
}
we get:
> foo1()
Error in foo1() : object 'res' not found
> foo2()
Error in foo2() : object 'res' not found
> foo3()
Error in foo3() : object 'res' not found
> foo4()
Error in foo4() : object 'res' not found
Running R CMD check on R v2.11.1pat we get:
* checking R code for possible problems ... NOTE
foo1: no visible binding for global variable 'res'
An improvement would be to also report that:
foo2: variable 'res' may not be assigned
foo3: variable 'res' may not be assigned
foo4: variable 'res' may not be assigned
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggested tidying up
On 31.05.2010 23:13, Vincent Goulet wrote:
Package grDevices has a function cm() to convert from inches to centimeters.
Its definition is:
cm<- function(x) 2.54*x
As far as I can tell, the function is not used anywhere in the R sources (I grepped for "cm(",
"cm)" and ", cm".) I did not check for all packages on CRAN, though.
I found it easier to remember cm() rather than 2.54.
By the way, before deprecating (rather than at once removing) a
function: have you also grepped through all CRAN and BioC packages?
And have you grepped for "\"cm\"", "'cm'" and other occurrences? cm may
be called in a call(), do.call() or other construct, hence the real test
is to remove the cm function, rebuild R and run the checks and run
checks on all at least all 3000 packages from CRAN + BioC.
Best wishes,
Uwe Ligges
May I propose to remove this apparently useless function from the sources?
[I stubbled upon this function because my package actuar also has a cm()
function that masks the one from grDevices.]
Dr. Vincent Goulet
Full Professor
École d'actuariat, Université Laval, Québec
vincent.gou...@act.ulaval.ca http://vgoulet.act.ulaval.ca
__
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
