Re: [Rd] (not just!) Windows R CMD build pkg leftovers
On Thu, 1 Dec 2005, Martin Morgan wrote:
Perhaps this earlier post slipped through the cracks? My apologies if
it's still 'in process', or I missed a response, or if the
contribution isn't helpful.
Have patience, it is `in process'. But if you consider such things
important (and clearly you do enough to pester) you should file a bug
report, not post to R-devel. This one appears to be a minor infelicity in
a procedure only for packages with broken vignettes. (It _would_ have
helped to have a clearer description of the problem being addressed:
INSTALL --build is nothing to do with vignettes, and not many CRAN
packages have vignettes and AFAIK none are broken. Think abut supplying
a NEWS entry to describe the fix.)
R.exe CMD is just a roundabout way of doing what Rcmd.exe does. Don't
confuse `necessary' with `recommended' or `efficient'.
At any rate, I realized that the problem is not windows-specific.
Also, generating $libdir by calling (a sligthly modified) R_tempfile
might give installation more of a fighting chance in a cluttered TMPDIR.
Not sure we should be encouraging such bad housekeeping!
Index: src/scripts/build.in
===
--- src/scripts/build.in(revision 36565)
+++ src/scripts/build.in(working copy)
@@ -76,7 +76,7 @@
my $R_platform = R_getenv(R_PLATFORM, unknown-binary);
my $gzip = R_getenv(R_GZIPCMD, gzip);
my $tar = R_getenv(TAR, tar);
-my $libdir = file_path(${R::Vars::TMPDIR}, Rinst.$$);
+my $libdir = R_tempfile(Rinst.);
my $INSTALL_opts = ;
$INSTALL_opts .= --use-zip if $opt_use_zip;
@@ -434,6 +434,8 @@
if($doit R_system($cmd)) {
$log-error();
$log-print(Installation failed.\n);
+ $log-print(Removing '$libdir'\n);
+ rmtree($libdir);
exit(1);
}
my $R_LIBS = $ENV{'R_LIBS'};
Index: share/perl/R/Utils.pm
===
--- share/perl/R/Utils.pm (revision 36565)
+++ share/perl/R/Utils.pm (working copy)
@@ -75,7 +75,7 @@
$pat . $$ . sprintf(%05d, rand(10**5)));
my $n=0;
-while(-f $retval){
+while(-e $retval){
$retval = file_path($R::Vars::TMPDIR,
$pat . $$ . sprintf(%05d, rand(10**5)));
croak Cannot find unused name for temporary file
Martin Morgan [EMAIL PROTECTED] writes:
A command
R CMD build pkg
that fails, e.g., because of C code compilation errors, leaves a
directory %TMPDIR%/Rinst.xxx containing the file R.css. Although R
CMD INSTALL --build cleans up after itself, build does not. A fix is
below. Also, build.in references Rcmd.exe, which I thought was no
longer necessary?
Index: build.in
===
--- build.in (revision 36450)
+++ build.in (working copy)
@@ -434,6 +434,8 @@
if($doit R_system($cmd)) {
$log-error();
$log-print(Installation failed.\n);
+$log-print(Removing '$libdir'\n);
+rmtree($libdir);
exit(1);
}
my $R_LIBS = $ENV{'R_LIBS'};
__
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
--
Brian D. Ripley, [EMAIL PROTECTED]
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] Enlightenment sought and a possible buglet in vector.Rd
Dear all,
First, I recently had reasons to read the help page of as.vector() and
noticed in the example section the following example:
x - c(a = 1, b = 2)
is.vector(x)
as.vector(x)
all.equal(x, as.vector(x)) ## FALSE
However, in all versions of R in which I executed this example, the
all.equal command returned TRUE which suggest that either the comment
in the help file is wrong or the all.equal/as.vector combination does
not work as intended in this case. For the former case, I attach
below a patch which would fix vector.Rd.
Secondly, I stumbled across two behaviours of R that I cannot explain
but would like to know why R behaves as it does. But since I expect
the explanations to be quite technical, I though that r-devel is the
more appropriate list to ask on than r-help.
The first example is the following:
f1
function(){
par.def - par(no.readonly=TRUE)
on.exit(par(par.def))
tt - sys.on.exit()
print(tt)
str(tt)
invisible()
}
f1()
par(par.def)
language par(par.def)
f2
function(){
par.def - par(no.readonly=TRUE)
on.exit(par(par.def))
print(tt - sys.on.exit())
str(tt)
invisible()
}
f2()
NULL
NULL
I found in the R language definition manual the passage that
discourages users of assigning objects within function calls since it
is not guaranteed that the assignment is ever made because of R's lazy
evaluation model. But this does not seem to explain the above
behaviour since the argument to print is evaluated. If I replace
sys.on.exit() with, say, ls() in both functions, then they produce the
same output (and the output that I expect). Why does f2() not work
with sys.on.exit()?
The second behaviour that I cannot explain was produced by code
written by somebody else, namely:
foo
function(x){
z - x/4
while( abs(z*z*z-x) 1e-10 ){
z - (2*z+x/z^2)/3
}
}
The documentation of function() says that if the end of a function is
reached without calling 'return', the value of the last evaluated
expression is returned. And this seems to happen in this case:
z - foo(3)
z
[1] 1.442250
However, my understanding was always that the return value of a
function issued on the command line will be printed; except, of
course, if invisible() is used to return the value. This is not the
case for the above function:
foo(3)
produces no output. And this had us stunned for some time. On the
other hand:
( foo(3) )
[1] 1.442250
So my question is why does R, when foo(3) is issued on the command
line, not print the value returned by the function?
Any enlightening comments are highly appreciated.
Cheers,
Berwin
Index: src/library/base/man/vector.Rd
===
--- src/library/base/man/vector.Rd (revision 36569)
+++ src/library/base/man/vector.Rd (working copy)
@@ -66,7 +66,7 @@
x - c(a = 1, b = 2)
is.vector(x)
as.vector(x)
-all.equal(x, as.vector(x)) ## FALSE
+all.equal(x, as.vector(x)) ## TRUE
###-- All the following are TRUE:
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Enlightenment sought and a possible buglet in vector.Rd
On Fri, 2 Dec 2005, Berwin A Turlach wrote:
[...]
The second behaviour that I cannot explain was produced by code
written by somebody else, namely:
foo
function(x){
z - x/4
while( abs(z*z*z-x) 1e-10 ){
z - (2*z+x/z^2)/3
}
}
The documentation of function() says that if the end of a function is
reached without calling 'return', the value of the last evaluated
expression is returned. And this seems to happen in this case:
Yes, but that value can be returned with R_Visible set to 0, by calling
invisible() _or otherwise_.
z - foo(3)
z
[1] 1.442250
However, my understanding was always that the return value of a
function issued on the command line will be printed; except, of
course, if invisible() is used to return the value. This is not the
case for the above function:
foo(3)
produces no output. And this had us stunned for some time. On the
other hand:
( foo(3) )
[1] 1.442250
So my question is why does R, when foo(3) is issued on the command
line, not print the value returned by the function?
R does not print the value of a while() loop. Try
x -3
z - x/4
while( abs(z*z*z-x) 1e-10 ){
z - (2*z+x/z^2)/3
}
.Last.value
and you are seeing no different. (Look up the code of do_while for why.)
--
Brian D. Ripley, [EMAIL PROTECTED]
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] all.equal() for mismatching names {was Enlightenment sought...}
BeT == Berwin A Turlach [EMAIL PROTECTED] on Fri, 2 Dec 2005 18:31:13 +0800 writes: BeT First, I recently had reasons to read the help page of as.vector() and BeT noticed in the example section the following example: BeT x - c(a = 1, b = 2) BeT is.vector(x) BeT as.vector(x) BeT all.equal(x, as.vector(x)) ## FALSE actually 'FALSE' was never the case, but non-TRUE once was, see below. BeT However, in all versions of R in which I executed this example, the BeT all.equal command returned TRUE which suggest that either the comment BeT in the help file is wrong or the all.equal/as.vector combination does BeT not work as intended in this case. For the former case, I attach BeT below a patch which would fix vector.Rd. We recently had the following posting on R-devel https://stat.ethz.ch/pipermail/r-devel/2005-October/034962.html (Subject: [Rd] all.equal() improvements (PR#8191)) where Andrew Piskorsky proposed a (quite extensive) patch to all.equal() in order to make sure that things like names must match for all.equal() to return TRUE. I did agree back then, and Brian partly disagreed with the very valid argument that all.equal() has been used in code testing (particularly R CMD check for packges), and that changes to make all.equal() more picky might well have bad consequences for package testing. Also Andy didn't provide the necessary patches to the documentation that would have been entailed. Well, all that's just an excuse for the fact that I had really lost the topic out of sight ;-) However, I'd like to take up the case, and I believe we should fix all.equal() for at at least the following reasons: 1- logical consistency 2- earlier R versions were more picky about name mismatch (upto R version 1.6.2) : x - c(a=1, b=pi); all.equal(x, as.vector(x)) [1] names for target but not for current [2] TRUE 3- two versions of S-plus were more picky too, in particular, S+3.4 which used to be our prototype: x - c(a=1, b=pi); all.equal(x, as.vector(x)) [1] names for target but not for current attr(, continue): [1] T Here's Splus 6.2 : x - c(a=1, b=pi); all.equal(x, as.vector(x)) [1] target, current classes differ: named : numeric [2] class of target is \named\, class of current is \numeric\ (coercing target to class of current) I really don't expect package checkings to fail because of a change. If some would start failing, a fix should be quiet simple for the package author and would help find inconsistencies in their own code IMO. Martin Maechler, ETH Zurich __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] t() dropping NULL dimnames {was all.equal() for mismatching names...}
MM == Martin Maechler [EMAIL PROTECTED]
on Fri, 2 Dec 2005 14:44:22 +0100 writes:
BeT == Berwin A Turlach [EMAIL PROTECTED]
on Fri, 2 Dec 2005 18:31:13 +0800 writes:
BeT First, I recently had reasons to read the help page of as.vector() and
BeT noticed in the example section the following example:
BeT x - c(a = 1, b = 2)
BeT is.vector(x)
BeT as.vector(x)
BeT all.equal(x, as.vector(x)) ## FALSE
MM actually 'FALSE' was never the case, but non-TRUE once was, see below.
BeT However, in all versions of R in which I executed this example, the
BeT all.equal command returned TRUE which suggest that either the comment
BeT in the help file is wrong or the all.equal/as.vector combination does
BeT not work as intended in this case. For the former case, I attach
BeT below a patch which would fix vector.Rd.
MM We recently had the following posting on R-devel
MM https://stat.ethz.ch/pipermail/r-devel/2005-October/034962.html
MM (Subject: [Rd] all.equal() improvements (PR#8191))
MM where Andrew Piskorsky proposed a (quite
MM extensive) patch to all.equal() in order to make sure that
MM things like names must match for all.equal() to return TRUE.
I'm testing the first part of Andy's proposition
{the 2nd part was about making the result strings more informative for
the case where all.equal() does *not* return TRUE}.
Interestingly, it did break 'make check' and because of a
somewhat subtle reason;
something we could consider an other (typically inconsequential)
inconsistency :
t() drops dimnames when they are list(NULL,NULL)
and has been doing so at least since R version 1.0.0 :
x - cbind(1:2, 2:1); dimnames(x) - list(NULL, NULL)
identical(x, t(x)) ## - FALSE !
str(t(x)) # no dimnames (i.e. dimnames(x) === NULL)
Now I'm looking into changing that one
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] t() dropping NULL dimnames {was all.equal() for mismatching names...}
On Fri, Dec 02, 2005 at 05:56:31PM +0100, Martin Maechler wrote:
BeT x - c(a = 1, b = 2)
BeT is.vector(x)
BeT as.vector(x)
BeT all.equal(x, as.vector(x)) ## FALSE
BeT However, in all versions of R in which I executed this example, the
BeT all.equal command returned TRUE which suggest that either the comment
My PR#8191 patch to all.equal() does fix that, e.g.:
x - c(a = 1, b = 2)
is.vector(x)
[1] TRUE
all.equal(x, as.vector(x))
[1] names for Target but not for Current
x
a b
1 2
as.vector(x)
[1] 1 2
MM We recently had the following posting on R-devel
MM https://stat.ethz.ch/pipermail/r-devel/2005-October/034962.html
MM (Subject: [Rd] all.equal() improvements (PR#8191))
I'm testing the first part of Andy's proposition
{the 2nd part was about making the result strings more informative for
the case where all.equal() does *not* return TRUE}.
Excellent, thank you for digging into this, Martin!
t() drops dimnames when they are list(NULL,NULL)
and has been doing so at least since R version 1.0.0 :
x - cbind(1:2, 2:1); dimnames(x) - list(NULL, NULL)
identical(x, t(x)) ## - FALSE !
str(t(x)) # no dimnames (i.e. dimnames(x) === NULL)
Now I'm looking into changing that one
Interesting. FYI, my PR#8192 subscripting sometimes loses names
hack does NOT fix or change that, I get the same result as you do
above - t(x) is losing dimnames in that case.
http://bugs.r-project.org/cgi-bin/R/wishlist?id=8192
S-Plus 6.2.1 (or at least my somewhat patched version of it) does not
seem to have that bug:
x - cbind(1:2, 2:1); dimnames(x) - list(NULL, NULL)
identical(x, t(x))
[1] T
dimnames(x)
[[1]]:
character(0)
[[2]]:
character(0)
dimnames(t(x))
[[1]]:
character(0)
[[2]]:
character(0)
--
Andrew Piskorski [EMAIL PROTECTED]
http://www.piskorski.com/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
