[Rd] read.fwf; bug reports 8226 & 8236 (PR#8284)
It seems to me that the bug dealt with in bug reports 8226 and 8236
is still not fixed.
I obtained the revised version of read.fwf from the latest
R-patched and tried
try.it <- read.fwf("junk",w,header=TRUE,as.is=TRUE)
This gave the error
Error in read.table(file = FILE, header = header, sep = sep, as.is = as.is, :
more columns than column names
Inspection of file ``FILE'' revealed that (of course) the
first line of ``FILE'' was not tab separated and was hence
being treated as a single field.
I then tried the last of Emmanuel Paradis' proposed fixes; this
didn't quite work --- an extra ``sep'' (tab) gets tacked on at the
end of the line being catted and makes read.table think that there is
one more field than there actually are.
So I modified the fix to:
if (header) {
headerline <- readLines(file, n = 1)
head.last <- cumsum(widths)
head.first <- head.last - widths + 1
headerline <- substring(headerline,head.first,head.last)[!drop]
headerline <- paste(headerline,collapse=sep)
cat(file = FILE, headerline, "\n")
}
This works for me.
Brian Ripley says that this will crash with multiline records. Well,
at least it works with single line records, as the current version
seems not to.
cheers,
Rolf Turner
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Hiccup in installing R 2.2.0
Yesterday I downloaded R-2.2.0.tar.gz, gunzipped and untarred, and did the usual ./configure and make. Everything seemed to go smoothly until it got to the bit about installing recommended packages. It got past ``spatial'' but turned up a fatal error in respect of the ``boot'' package. Here is some of what appeared on the screen: ===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+=== . . . trls.influencetexthtmllatex example trmat texthtmllatex example variogram texthtmllatex example ** building package indices ... * DONE (spatial) begin installing recommended package boot * Installing *source* package 'boot' ... mkdir: cannot create directory `/tmp/Rtmp9726': File exists ERROR: cannot create temporary R session directory ERROR: installing package DESCRIPTION failed /home/faculty/rolf/Rinst/R-2.2.0/bin/INSTALL: test: argument expected *** Error code 1 make: Fatal error: Command failed for target `boot.ts' Current working directory /homes/faculty/rolf/Rinst/R-2.2.0/src/library/Recommended *** Error code 1 make: Fatal error: Command failed for target `recommended-packages' Current working directory /homes/faculty/rolf/Rinst/R-2.2.0/src/library/Recommended *** Error code 1 make: Fatal error: Command failed for target `stamp-recommended' ===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+===+=== The system I am working on is a ``sparc'' (from Sun) running Solaris 2.9. I checked on /tmp, and there was indeed a directory (empty) named Rtmp9726, owned by another user on our system. (It was dated October 7, 2005, i.e. about a week ago.) Fortunately (???) I have superuser priviledges, so I was able to remove this (empty) directory. I then tried ``make'' again, and this time it ran to completion. So I'm alright, Jack. It would seem however that something is not ***quite*** as it should be in the installation procedure. I thought I'd just draw this to youse guys' attention. :-) cheers, Rolf Turner [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Repeated use of dyn.load().
I sent this enquiry to r-help and received several sympathetic replies,
none of which were definitive.
It was kindly suggested to me that I might get better mileage out of
r-devel, so I'm trying here. I hope that this is not inappropriate.
My original enquiry to r-help:
==
I am working with a function "foo" that explicitly dynamically loads a
shared object library or "DLL", doing something like dyn.load("bar.so").
This is a debugging exercise so I make changes to the underlying
Fortran code (yes, I acknowledge that I am a dinosaur) remake the DLL
"bar.so" and then run foo again. This is all *without* quitting and
restarting R. (I'm going to have to do this a few brazillion times, and
I want the iterations to be as quick as possible.)
This seems to work --- i.e. foo seems to obtain the latest version of
bar.so. But have I just been lucky so far? (I have not experimented
heavily).
Am I running risks of leading myself down the garden path? Are there
Traps for Young (or even Old) Players lurking about?
I would appreciate Wise Counsel.
==
One of the replies that I received from r-help indicated that it might
be safer if I were to apply dyn.unload() on each iteration. So I
thought I might put in the line of code
on.exit(dyn.unload("bar.so"))
immediately after my call to dyn.load().
Comments?
Another reply pointed out that "Writing R Extensions" indicates that
there could be problems under Solaris, but does not single out any other
OS for comment. Might I infer that I am "safe" as long as I don't use
Solaris? (Which I certainly *won't* be doing.)
Thanks.
cheers,
Rolf Turner
--
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Puzzled about a new method for "[".
I recently tried to write a new method for "[", to be applied to data
frames, so that the object returned would retain (all) attributes of the
columns, including attributes that my code had created.
I thrashed around for quite a while, and then got some help from Rui
Barradas who showed me how to do it, in the following manner:
`[.myclass` <- function(x, i, j, drop = if (missing(i)) TRUE else
length(cols) == 1)[{
SaveAt <- lapply(x, attributes)
x <- NextMethod()
lX <- lapply(names(x),function(nm, x, Sat){
attributes(x[[nm]]) <- Sat[[nm]]
x[[nm]]}, x = x, Sat = SaveAt)
names(lX) <- names(x)
x <- as.data.frame(lX)
x
}
If I set class(X) <- c("myclass",class(X)) and apply "[" to X (e.g.
something like X[1:42,]) the attributes are retained as desired.
OK. All good. Now we finally come to my question! I want to put this
new method into a package that I am building. When I build the package
and run R CMD check I get a complaint:
... no visible binding for global variable ‘cols’
And indeed, there is no such variable. At first I thought that maybe
the code should be
`[.myclass` <- function(x, i, j, drop = if (missing(i)) TRUE else
length(j) == 1)[{
But I looked at "[.data.frame" and it has "cols" too; not "j".
So why doesn't "[.data.frame" throw a warning when R gets built?
Can someone please explain to me what's going on here?
cheers,
Rolf
P. S. I amended the code for my method, replacing "cols" by "j", and it
*seems* to run, and deliver the desired results. (And the package
checks, without complaint.) I am nervous, however, that there may be
some Trap for Young Players that I don't perceive, lurking about and
waiting to cause problems for me.
R.
--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Puzzled about a new method for "[".
On 4/11/19 10:31 AM, Duncan Murdoch wrote:
On 03/11/2019 4:11 p.m., Rolf Turner wrote:
I recently tried to write a new method for "[", to be applied to data
frames, so that the object returned would retain (all) attributes of the
columns, including attributes that my code had created.
I thrashed around for quite a while, and then got some help from Rui
Barradas who showed me how to do it, in the following manner:
`[.myclass` <- function(x, i, j, drop = if (missing(i)) TRUE else
length(cols) == 1)[{
SaveAt <- lapply(x, attributes)
x <- NextMethod()
lX <- lapply(names(x),function(nm, x, Sat){
attributes(x[[nm]]) <- Sat[[nm]]
x[[nm]]}, x = x, Sat = SaveAt)
names(lX) <- names(x)
x <- as.data.frame(lX)
x
}
If I set class(X) <- c("myclass",class(X)) and apply "[" to X (e.g.
something like X[1:42,]) the attributes are retained as desired.
OK. All good. Now we finally come to my question! I want to put this
new method into a package that I am building. When I build the package
and run R CMD check I get a complaint:
... no visible binding for global variable ‘cols’
And indeed, there is no such variable. At first I thought that maybe
the code should be
`[.myclass` <- function(x, i, j, drop = if (missing(i)) TRUE else
length(j) == 1)[{
But I looked at "[.data.frame" and it has "cols" too; not "j".
So why doesn't "[.data.frame" throw a warning when R gets built?
Can someone please explain to me what's going on here?
Defaults for parameters are evaluated in the evaluation frame of the
function, at the time the parameter is first used.
If you look at the source for "[.data.frame", you should see that "cols"
is defined there as a local variable. The "drop" argument shouldn't be
used until it is. (There's a call to "missing(drop)" early in the
source that doesn't count: it doesn't evaluate "drop", it just checks
whether it is specified by the caller.)
OK. As I understand what you're saying, the reason there isn't a
"no visible binding" problem in [.data.frame is that "cols" *is* defined
in the body of the function. Whereas, in my method, "cols" does not get
defined anywhere in the function, and thus triggers the warning.
I guess that a workaround would be to do a dummy assignment, like unto
cols <- 42 at the start of the code for my method.
(a) Are there perils involved with this strategy?
(b) Is there anything wrong with my current strategy of replacing
drop = if (missing(i)) TRUE else length(cols) == 1)
by
drop = if (missing(i)) TRUE else length(j) == 1)
???
As I said, this *seems* to work OK, by I cannot work through what the
implications might be.
Can anyone reassure me?
cheers,
Rolf
--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Puzzled about a new method for "[".
On 4/11/19 1:06 PM, Duncan Murdoch wrote:
On 03/11/2019 6:43 p.m., Rolf Turner wrote:
On 4/11/19 10:31 AM, Duncan Murdoch wrote:
On 03/11/2019 4:11 p.m., Rolf Turner wrote:
I recently tried to write a new method for "[", to be applied to data
frames, so that the object returned would retain (all) attributes of
the
columns, including attributes that my code had created.
I thrashed around for quite a while, and then got some help from Rui
Barradas who showed me how to do it, in the following manner:
`[.myclass` <- function(x, i, j, drop = if (missing(i)) TRUE else
length(cols) == 1)[{
SaveAt <- lapply(x, attributes)
x <- NextMethod()
lX <- lapply(names(x),function(nm, x, Sat){
attributes(x[[nm]]) <- Sat[[nm]]
x[[nm]]}, x = x, Sat = SaveAt)
names(lX) <- names(x)
x <- as.data.frame(lX)
x
}
If I set class(X) <- c("myclass",class(X)) and apply "[" to X (e.g.
something like X[1:42,]) the attributes are retained as desired.
OK. All good. Now we finally come to my question! I want to put this
new method into a package that I am building. When I build the package
and run R CMD check I get a complaint:
... no visible binding for global variable ‘cols’
And indeed, there is no such variable. At first I thought that maybe
the code should be
`[.myclass` <- function(x, i, j, drop = if (missing(i)) TRUE else
length(j) == 1)[{
But I looked at "[.data.frame" and it has "cols" too; not "j".
So why doesn't "[.data.frame" throw a warning when R gets built?
Can someone please explain to me what's going on here?
Defaults for parameters are evaluated in the evaluation frame of the
function, at the time the parameter is first used.
If you look at the source for "[.data.frame", you should see that "cols"
is defined there as a local variable. The "drop" argument shouldn't be
used until it is. (There's a call to "missing(drop)" early in the
source that doesn't count: it doesn't evaluate "drop", it just checks
whether it is specified by the caller.)
OK. As I understand what you're saying, the reason there isn't a
"no visible binding" problem in [.data.frame is that "cols" *is* defined
in the body of the function. Whereas, in my method, "cols" does not get
defined anywhere in the function, and thus triggers the warning.
I guess that a workaround would be to do a dummy assignment, like unto
cols <- 42 at the start of the code for my method.
(a) Are there perils involved with this strategy?
Only that 42 might not be the right value.
(b) Is there anything wrong with my current strategy of replacing
drop = if (missing(i)) TRUE else length(cols) == 1)
by
drop = if (missing(i)) TRUE else length(j) == 1)
[.data.frame is pretty complicated, and I haven't read it closely enough
to know if this is equivalent. I would suggest you consider not
including "drop" at all, just implicitly including it in "..." .
OK. I'll try that!
Thanks.
cheers,
Rolf
--
Honorary Research Fellow
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Puzzled about a new method for "[".
On 5/11/19 3:41 AM, Hadley Wickham wrote: For what it's worth, I don't think this strategy can work in general, because a class might have attributes that depend on its data/contents (e.g. https://vctrs.r-lib.org/articles/s3-vector.html#cached-sum). I don't think these are particularly common in practice, but it's dangerous to assume that you can restore a class simply by restoring its attributes after subsetting. You're probably right that there are lurking perils in general, but I am not trying to "restore a class". I simply want to *retain* attributes of columns in a data frame. * I have a data frame X * I attach attributes to certain of its columns; attr(X$melvin,"clyde") <- 42 (I *don't* change the class of X$melvin.) * I form a subset of X: Y <- X[1:100,3:10] * given that "melvin" is amongst columns 3 through 10 of X, I want Y$melvin to retain the attribute "clyde", i.e. I want attr(Y$melvin,"clyde") to return 42 There is almost surely a better approach than the one that I've chosen (isn't there always?) but it seems to work, and the perils certainly are not immediately apparent to me. cheers, Rolf -- Honorary Research Fellow Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Puzzled about a new method for "[".
On 5/11/19 10:54 AM, Duncan Murdoch wrote: On 04/11/2019 4:40 p.m., Pages, Herve wrote: Hi Rolf, On 11/4/19 12:28, Rolf Turner wrote: On 5/11/19 3:41 AM, Hadley Wickham wrote: For what it's worth, I don't think this strategy can work in general, because a class might have attributes that depend on its data/contents (e.g. https://urldefense.proofpoint.com/v2/url?u=https-3A__vctrs.r-2Dlib.org_articles_s3-2Dvector.html-23cached-2Dsum&d=DwICAg&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=pqLHzHYLUeyQnxA1K_XhSbKJql6r9wK1RXcDG2tuZ6s&s=kPUlNqBPr6j4lPvqkIj8w2Gl5JYGLqJ7ws6wH5tpGcw&e= ). I don't think these are particularly common in practice, but it's dangerous to assume that you can restore a class simply by restoring its attributes after subsetting. You're probably right that there are lurking perils in general, but I am not trying to "restore a class". I simply want to *retain* attributes of columns in a data frame. * I have a data frame X * I attach attributes to certain of its columns; attr(X$melvin,"clyde") <- 42 (I *don't* change the class of X$melvin.) * I form a subset of X: Y <- X[1:100,3:10] * given that "melvin" is amongst columns 3 through 10 of X, I want Y$melvin to retain the attribute "clyde", i.e. I want attr(Y$melvin,"clyde") to return 42 There is almost surely a better approach than the one that I've chosen (isn't there always?) but it seems to work, and the perils certainly are not immediately apparent to me. Maybe you've solved the problem for the columns that contain your objects but now you've introduced a potential problem for columns that contain objects with attributes whose value depend on content. Hadley it right that restoring the original attributes of a vector (list or atomic) after subsetting is unsafe. Right, so Rolf should only restore attributes that are ones he added in the first place. Unknown attributes should be left alone. Fair point. And that gets fiddly. I guess I'm going to have to rethink my strategy. cheers, Rolf -- Honorary Research Fellow Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Puzzled about a new method for "[".
On 5/11/19 9:37 PM, Iñaki Ucar wrote: You can try for testing with a column of class errors, from the package 'errors'. The attributes depend on the content in the way Hadley pointed out. Thanks, but it turns out to be much simpler than that. There is a very easy way to accomplish what I want --- simply give an attribute to the data frame, rather than to a certain column of that data frame. I don't know why the hell I didn't do that in the first place! Duh!!! Sorry for all the noise that this issue has generated. cheers, Rolf -- Honorary Research Fellow Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Xll.options().
This question seemed to me to be more appropriate for r-devel than for r-help. My apologies if this is not the case. Recently I installed ``cairo'' on my lap-top so that I could make use of the (newish) polypath() function, with on-screen graphics. (The polypath() function does not work with X11(type="Xlib").) The installation went smoothly, X11(type="cairo") works just fine, and polypath() works just fine. However the default "type" for X11() remains "Xlib" rather than "cairo". The help for X11.options() says (in respect of "type"): Default "cairo" where available and reliable, otherwise "Xlib". Now "cairo" is definitely available: > capabilities()["cairo"] cairo TRUE and moreover it works (just fine!) when I do X11(type="cairo") explicitly. I know that I can set the default to be "cairo" in my .Rprofile, but I am curious as to why "cairo" does not become the default automatically. Is it the case that "cairo" is ``not reliable'' under my system? It ***seems*** to be reliable. > sessionInfo() R version 2.13.1 Patched (2011-07-17 r56404) Platform: i686-pc-linux-gnu (32-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=C LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] datasets utils stats graphics grDevices methods base other attached packages: [1] misc_0.0-13 gtools_2.6.2spatstat_1.23-1 deldir_0.0-15 [5] mgcv_1.7-6 fortunes_1.4-2 MASS_7.3-13 loaded via a namespace (and not attached): [1] grid_2.13.1lattice_0.19-30Matrix_0.999375-50 nlme_3.1-101 cheers, Rolf Turner __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] X11.options().
On 08/08/11 20:20, Martin Maechler wrote:
Hi Rolf,
please excuse a short "top-reply":
No problema. Thanks for replying.
As I see you are using an operating system (instead of Win..),
can you try in the shell
echo 'X11.options()$type' | R --vanilla --slave
and does that really *not* report
[1] "cairo"
Sure.
It really does *not* report "cairo"!!!:
~> echo 'X11.options()$type' | R --vanilla --slave
[1] "Xlib"
??
(and BTW: Your subject had tolower("LL") instead of "11" )
Whoops. Oh dear. Blame it on senility. :-(
cheers,
Rolf
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] X11.options().
Uh, to get back to the (my) point --- anybody have any ideas as to why X11.options()$type is defaulting to "Xlib" rather than "cairo" even though cairo is available and apparently (???) ``reliable''? cheers, Rolf __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] X11.options().
On 09/08/11 20:43, Uwe Ligges wrote:
Fine for me on a recent Debian with R-2.13.1 patched.
Psigh! Why do the Computer Gods always pick on ***me***?
I think we will need more details of a really clean install and your
version of cairo etc.
[I'm on vacations and may be offline until Thursday]
When you get some time, can you please give me some explicit instructions as
to how to produce the details that you need?
No rush; this is kind of an academic question since I've worked around
the problem
by explicitly setting X11.options(type="cairo") in my .Rprofile.
cheers,
Rolf
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem installing R-devel data 4 March 2016.
I am trying to install the latest development version of R so as to be able to perform a package check according the rules specified for CRAN. I performed the following steps: (1) Downloaded R-devel.tar.gz, dated 04-Mar-2016 03:21, from CRAN (2) Upacked. (3) Created directory "BldDir" next to the directory "R-devel". (4) Changed directories to BldDir. (5) Executed ../R-devel/configure --with-tcltk --with-cairo . (6) Executed make . (7) Executed sudo make install . I got the error messages: . . . mkdir -p -- /usr/local/lib64/R/doc /usr/bin/install: cannot stat `FAQ': No such file or directory /usr/bin/install: cannot stat `RESOURCES': No such file or directory /usr/bin/install: cannot stat `NEWS': No such file or directory /usr/bin/install: cannot stat `NEWS.pdf': No such file or directory /usr/bin/install: cannot stat `NEWS.rds': No such file or directory /usr/bin/install: cannot stat `NEWS': No such file or directory /usr/bin/install: cannot stat `NEWS.pdf': No such file or directory make[1]: *** [install-sources2] Error 1 make[1]: Leaving directory `/home/rolf/Desktop/R-dev-inst/BldDir/doc' make: *** [install] Error 1 Can someone/anyone tell me what I am missing or doing wrong? Ta. cheers, Rolf Turner -- Technical Editor ANZJS Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem installing R-devel dated 4 March 2016.
Thanks Peter. I tried running the uninstalled R; it worked. I checked on the existence of FAQ, etc. --- yep everything was there. I don't know about over-zealous virus checkers; I haven't overtly installed any such. So, mystified, I started all over again from scratch. This time it worked; seamlessly. Totally mysterious. Story of my life. Be that as it were, all systems are go now, and my package checking was successful. Sorry for the noise. cheers, Rolf -- Technical Editor ANZJS Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 On 06/03/16 03:10, peter dalgaard wrote: On 05 Mar 2016, at 03:35 , Rolf Turner wrote: I am trying to install the latest development version of R so as to be able to perform a package check according the rules specified for CRAN. I performed the following steps: (1) Downloaded R-devel.tar.gz, dated 04-Mar-2016 03:21, from CRAN (2) Upacked. (3) Created directory "BldDir" next to the directory "R-devel". (4) Changed directories to BldDir. (5) Executed ../R-devel/configure --with-tcltk --with-cairo . (6) Executed make . (7) Executed sudo make install . I got the error messages: . . . mkdir -p -- /usr/local/lib64/R/doc /usr/bin/install: cannot stat `FAQ': No such file or directory /usr/bin/install: cannot stat `RESOURCES': No such file or directory /usr/bin/install: cannot stat `NEWS': No such file or directory /usr/bin/install: cannot stat `NEWS.pdf': No such file or directory /usr/bin/install: cannot stat `NEWS.rds': No such file or directory /usr/bin/install: cannot stat `NEWS': No such file or directory /usr/bin/install: cannot stat `NEWS.pdf': No such file or directory make[1]: *** [install-sources2] Error 1 make[1]: Leaving directory `/home/rolf/Desktop/R-dev-inst/BldDir/doc' make: *** [install] Error 1 Can someone/anyone tell me what I am missing or doing wrong? Beats me. & I just checked that make install works on my system (usually, I just run test versions out of their build dirs). You might check a couple of things though: - does ~/Desktop/R-dev-inst/BldDir/bin/R work? - does ~/Desktop/R-dev-inst/BldDir/doc/FAQ et al. actually exist? - is there an overzealous virus checker active (those have been known to move fresh files to "safe locations" right under peoples feet...) -pd Ta. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem installing R-devel dated 4 March 2016.
On 06/03/16 21:27, peter dalgaard wrote: Hm, we'll likely never find out. It looks a bit like a race condition or a Makefile deficiency in which some dependencies are not explicitly recorded (so that it tries to copy files before they have been made). I suppose that could happen if you try "make install" w/o a preceding "make". I am *certain* that the latter contretemps did not occur. I *know* that I did a make. Of course I *have* been known to be certain of things that weren't actually true But in this instance . As you say, we'll never find out. cheers, Rolf -pd On 06 Mar 2016, at 04:54 , Rolf Turner wrote: Thanks Peter. I tried running the uninstalled R; it worked. I checked on the existence of FAQ, etc. --- yep everything was there. I don't know about over-zealous virus checkers; I haven't overtly installed any such. So, mystified, I started all over again from scratch. This time it worked; seamlessly. Totally mysterious. Story of my life. Be that as it were, all systems are go now, and my package checking was successful. Sorry for the noise. cheers, Rolf -- Technical Editor ANZJS Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 On 06/03/16 03:10, peter dalgaard wrote: On 05 Mar 2016, at 03:35 , Rolf Turner wrote: I am trying to install the latest development version of R so as to be able to perform a package check according the rules specified for CRAN. I performed the following steps: (1) Downloaded R-devel.tar.gz, dated 04-Mar-2016 03:21, from CRAN (2) Upacked. (3) Created directory "BldDir" next to the directory "R-devel". (4) Changed directories to BldDir. (5) Executed ../R-devel/configure --with-tcltk --with-cairo . (6) Executed make . (7) Executed sudo make install . I got the error messages: . . . mkdir -p -- /usr/local/lib64/R/doc /usr/bin/install: cannot stat `FAQ': No such file or directory /usr/bin/install: cannot stat `RESOURCES': No such file or directory /usr/bin/install: cannot stat `NEWS': No such file or directory /usr/bin/install: cannot stat `NEWS.pdf': No such file or directory /usr/bin/install: cannot stat `NEWS.rds': No such file or directory /usr/bin/install: cannot stat `NEWS': No such file or directory /usr/bin/install: cannot stat `NEWS.pdf': No such file or directory make[1]: *** [install-sources2] Error 1 make[1]: Leaving directory `/home/rolf/Desktop/R-dev-inst/BldDir/doc' make: *** [install] Error 1 Can someone/anyone tell me what I am missing or doing wrong? Beats me. & I just checked that make install works on my system (usually, I just run test versions out of their build dirs). You might check a couple of things though: - does ~/Desktop/R-dev-inst/BldDir/bin/R work? - does ~/Desktop/R-dev-inst/BldDir/doc/FAQ et al. actually exist? - is there an overzealous virus checker active (those have been known to move fresh files to "safe locations" right under peoples feet...) -pd Ta. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] A trap for young players with the lapply() function.
From time to time I get myself into a state of bewilderment when using
apply() by calling it with FUN equal to a function which has an
"optional" argument named "X".
E.g.
xxx <- lapply(y,function(x,X){cos(x*X)},X=2*pi)
which produces the error message
Error in get(as.character(FUN), mode = "function", envir = envir) :
object 'y' of mode 'function' was not found
This of course happens because the name of the first argument of
lapply() is "X" and so it takes the value of this first argument to be
the supplied X (2*pi in the foregoing example) and then expects what the
user has denoted by "y" to be the value of FUN, and (obviously!) it isn't.
Once one realises what is going on, it's all quite obvious, and usually
pretty easy to fix. OTOH there are lots of functions around with second
or third arguments whose formal name is "X", and these can trip one up
until the penny drops.
This keeps happening to me, over and over again (with sufficiently long
intervals between occurrences so that my ageing memory forgets the
previous occurrence).
Is there any way to trap/detect the use of an optional argument called
"X" and thereby issue a more perspicuous error message?
This would be helpful to those users who, like myself, are bears of very
little brain.
Failing that (it does look impossible) might it not be a good idea to
add a warning to the help for lapply(), to the effect that if FUN has an
optional argument named "X" then passing this argument via "..." will
cause this argument to be taken as the first argument to lapply() and
thereby induce an error?
cheers,
Rolf Turner
--
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A trap for young players with the lapply() function.
On 28/03/17 04:21, Barry Rowlingson wrote:
On Mon, Mar 27, 2017 at 1:17 AM, Rolf Turner wrote:
Is there any way to trap/detect the use of an optional argument called
"X" and thereby issue a more perspicuous error message?
This would be helpful to those users who, like myself, are bears of very
little brain.
Failing that (it does look impossible)
You can get the names of named arguments:
> z = function(x,X){cos(x*X)}
> names(formals(z))
[1] "x" "X"
That doesn't seem to help. I tried putting a browser inside lapply()
and looked at formals(FUN). This gave NULL, because FUN has already
been taken to be the list argument "x" to which lapply() is being applied.
might it not be a good idea to
add a warning to the help for lapply(), to the effect that if FUN has an
optional argument named "X" then passing this argument via "..." will
cause this argument to be taken as the first argument to lapply() and
thereby induce an error?
Another idea might be to use purrr:map instead, which is quite happy
with X in your function:
> xxx <- purrr::map(y,function(x,X){cos(x*X)},X=2*pi)
> xxx
[[1]]
[1] 0.08419541
[[2]]
[1] 0.6346404
[[3]]
[1] 0.9800506
[[4]]
[1] 0.8686734
[[5]]
[1] -0.9220073
But don't feed `.x` to your puing cats, or fails silently:
> xxx <- purrr::map(y,function(x,.x){cos(x*.x)},.x=2*pi)
> xxx
[[1]]
NULL
But who would have a function with `.x` as an argument?
Indeed. It struck me that a possible workaround would be to change the
name of the first argument of lapply() from "X" to ".X". No-one would
have a function with an argument names ".X" --- at least I wouldn't, so
this would solve the problem for me.
It seems to me that this change could be made without breaking anything.
But perhaps I am engaging in my usual PollyAnna-ish optimism! :-)
cheers,
Rolf
--
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A trap for young players with the lapply() function.
On 28/03/17 15:26, Charles C. Berry wrote:
On Mon, 27 Mar 2017, Rolf Turner wrote:
From time to time I get myself into a state of bewilderment when using
apply() by calling it with FUN equal to a function which has an
"optional" argument named "X".
E.g.
xxx <- lapply(y,function(x,X){cos(x*X)},X=2*pi)
which produces the error message
Error in get(as.character(FUN), mode = "function", envir = envir) :
object 'y' of mode 'function' was not found
This of course happens because the name of the first argument of
lapply() is "X" and so it takes the value of this first argument to be
the supplied X (2*pi in the foregoing example) and then expects what
the user has denoted by "y" to be the value of FUN, and (obviously!)
it isn't.
The lapply help page addresses this issue in `Details' :
"it is good practice to name the first two arguments X and FUN if ... is
passed through: this both avoids partial matching to FUN and ensures
that a sensible error message is given if arguments named X or FUN are
passed through ..."
So that advice suggests something like:
xxx <- lapply( X=y, FUN=function(X,x){cos(X*x)}, x=2*pi )
That is of course very sound advice, but it pre-supposes that the user
is *aware* that there is a pitfall to be avoided. I was hoping for
something that would protect dweebs like myself from the pitfall given
that we are too obtuse to be cognizant of its existence.
I think that the suggestion I made, in response to a posting by Barry
Rowlingson, that the first argument of lapply() be given the name of
".X" rather than just-plain-X, would be (a) effective, and (b) harmless.
cheers,
Rolf
--
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A trap for young players with the lapply() function.
On 29/03/17 11:03, William Dunlap wrote: I think that the suggestion I made, in response to a posting by Barry Rowlingson, that the first argument of lapply() be given the name of ".X" rather than just-plain-X, would be (a) effective, and (b) harmless. It would break any call to *apply() that used X= to name the first argument. There are currently 3020 such calls in the R code in CRAN. Okay. Scratch that idea. One can avoid the problem by creating the function given as the FUN argument when one calls lapply() and the like. Don't give that function arguments named "X", "FUN", "USE.NAMES", etc. and perhaps make use of R's lexical scoping to avoid having to use many arguments to the function. E.g., instead of sapply(1:5, sin) use sapply(1:5, function(theta) sin(theta)) or instead of myY <- 3 sapply(1:5, atan2, y=myY) use myY <- 3 sapply(1:5, function(x) atan2(myY, x)) Again, all very sound advice but it does not address the problem of there being a trap for young players. The advice can only be applied by a user only if the user is *aware* of the trap. At this point it would appear that the problem is fundamentally unsolvable. :-( cheers, Rolf -- Technical Editor ANZJS Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A trap for young players with the lapply() function.
On 29/03/17 20:32, Enrico Schumann wrote:
(inline)
On Tue, 28 Mar 2017, Rolf Turner writes:
On 28/03/17 04:21, Barry Rowlingson wrote:
On Mon, Mar 27, 2017 at 1:17 AM, Rolf Turner wrote:
Is there any way to trap/detect the use of an optional argument called
"X" and thereby issue a more perspicuous error message?
This would be helpful to those users who, like myself, are bears of very
little brain.
Failing that (it does look impossible)
You can get the names of named arguments:
> z = function(x,X){cos(x*X)}
> names(formals(z))
[1] "x" "X"
That doesn't seem to help. I tried putting a browser inside lapply()
and looked at formals(FUN). This gave NULL, because FUN has already
been taken to be the list argument "x" to which lapply() is being
applied.
You can get the call, without the arguments being
matched, with `sys.call`. In your call of lapply,
saying `sys.call()` before anything else would give
you
lapply(y, function(x, X) {
cos(x * X)
}, X = 2 * pi)
which would allow you to get at the argument names of
your function.
if ("X" %in% names(sys.call()[[3L]][[2L]]))
warnings("found 'X'")
But more would be needed: you need to figure out which
argument you actually meant to be FUN. (In the above,
I simply assumed it was the second passed argument.)
That is, you would need to figure out which passed
argument is a function, which is not safe either,
since ... may also contain functions.
This idea appears to work for the particular example that I used, but it
is not clear to me how to make it work in general. E.g. if we define
foo <- function(x,X){X*x}
and then do
lapply(xxx,foo,X=2*pI)
we find that sys.call[[3]] is of length 1 and consists only of the
*name* "foo". One can then inspect
formals(get(as.character(sys.call[[3]])))
and find "X" therein, on the basis of which to trigger a warning.
However I don't know how to approach distinguish the two cases, or how
to discern if there may be other cases lurking in the bushes.
So the problem still looks insoluble to me.
cheers,
Rolf
--
Technical Editor ANZJS
Department of Statistics
University of Auckland
Phone: +64-9-373-7599 ext. 88276
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Constructor/extractor.
Preamble: = In spatial point pattern analysis an important component of a point pattern object is the *observation window*. In the spatstat package we have the function owin() to *construct* such a window. It creates an object of class "owin" which can happily exist separately from any point pattern object (object of class "ppp"). However we have at the moment no convenient function to *extract* the observation component of a ppp object, nor have we a really convenient means of (re-) assigning the window component of such an object. We can extract the component via X$window or more suavely via as.owin(X) --- but the latter is rather counter-intuitive and lacks parallelism with other usage. Re-assignment of the observation window component of X can be done either via X$window <- W or X <- X[W]. These are not quite the same. The former may leaves points which are outside of W hanging around. The latter does not suffer from this defect, and is more suave, but is not as intuitive as it might be. I suggested that we could make the owin() function generic, make the current owin() creator function into owin.default(), and build an extractor function owin.ppp() (and an assignment function owin<-.ppp () to assign an observation window to a ppp object). It was pointed out to me that this would make for an unorthodox syntax It is at the very least *unusual* if not unheard of for a function to be used both for *creation* of objects and for *extraction* of components from other objects. Questions: == My questions to R-devel are: (1) Are there any other functions in R that serve this dual role of constructor and extractor? (2) Even if there are no such functions, is there anything intrinsically *wrong* with having a function possessing this somewhat schizophrenic nature? Is it likely to cause confusion, induce syntactical mistakes, create errors, or produce wrong results? Any thoughts, comments, insights or suggestions gratefully received. cheers, Rolf Turner __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Chi-squared test p-value based on simulation.
Prompted by a (fairly!) recent question from Michael Fuller, I got
to thinking about the issue of goodness-of-fit testing via chisq.test()
using p-values obtained via simulation.
I believe that such p-values are really valid only if there are no ties
in the data. Since there are only finite number of possible samples
and hence only a finite number of statistic values, ties (while perhaps
improbable) are not impossible. So the validity of the p-values obtained
via simulation is possibly slightly suspect.
I am given to understand that the p-values remain valid if the ties are
broken *randomly*.
Might it thereby be advisable to jitter the values of (the "true" and
simulated) test statistics before calculating the p-value?
Anyone have any thoughts on this?
cheers,
Rolf Turner
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stringsAsFactors .... in expand.grid() etc
On 20/05/2009, at 1:49 AM, Martin Maechler wrote:
"RT" == Rolf Turner
on Tue, 19 May 2009 11:02:08 +1200 writes:
RT> While we're at it --- would it not make sense to have the
RT> stringsAsFactors
RT> argument (once it's working) of expand.grid() default to
options()
RT> $stringsAsFactors,
RT> rather than to FALSE?
NNNOOO !
Oh, alright! :-)
cheers,
Rolf
##
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] The "lib" argument in install.packages().
I was flummoxed for a long time by errors generated when I did
something like
install.packages(foo,lib="Rlib")
where ``Rlib'' is my personalized directory of R packages, which
lives in my home directory (from which I started R before issuing
the foregoing install.packages() call.
Recently someone (I forget who, but thanks very much to whomever
it was) pointed out that I needed to specify the complete pathname,
i.e. "/Users/rturner/Rlib" rather than the relative pathname "Rlib"
or "./Rlib" (which I'd also tried). When the complete pathname is
given the install.packages() call works seamlessly.
Remark: I have "/Users/rturner/Rlib" as the first entry of
my .libPaths(),
so just doing install.packages(foo) works --- but this gives a warning
about lib not being specified, which I find irksome.
Questions:
(1) Why is it that the complete pathname of ``lib'' has to
be specified? Cannot the code of install.packages() be
adjusted to work with relative pathnames?
(2) If indeed this is not possible, wouldn't it be kind and
helpful, to us young ( :-) ) and naive persons, to put an
indication in the help file for install.packages that the
complete pathname is required?
cheers,
Rolf Turner
P. S. > sessionInfo()
R version 2.10.0 (2009-10-26)
i386-apple-darwin8.11.1
locale:
[1] C
attached base packages:
[1] datasets utils stats graphics grDevices methods base
other attached packages:
[1] misc_0.0-11fortunes_1.3-6 MASS_7.3-3
##
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Hmisc for Mac OSX.
I'm not sure if this is the right target to which to direct this post,
but I couldn't think of anything more appropriate.
I just downloaded the Hmisc package to the Imac that I use. When I
attempted
to load it I got an error to the effect that it could not load the
library:
/Library/Frameworks/R.framework/Versions/2.5/Resources/lib/
libgfortran.2.dylib
Note the ``2.5'' in the foregoing path name; I am currently running
2.6.0, and
I suspect that this is the problem --- i.e. the Mac binary on CRAN
was built
under 2.5.x and this does not work with 2.6.y.
I note that the source and Windoze Hmisc packages are designated as
3.4-3, but
the Mac package is designated as 3.4-2 which would appear to imply
that it's
a step behind.
Could the Mac binary be updated please? Thanks.
cheers,
Rolf Turner
##
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Hmisc for Mac OSX.
On 6/11/2007, at 10:35 PM, Ken Beath wrote:
> On 06/11/2007, at 8:59 AM, Rolf Turner wrote:
>
>>
>> I'm not sure if this is the right target to which to direct this
>> post,
>> but I couldn't think of anything more appropriate.
>>
>
> R-Sig-Mac https://stat.ethz.ch/mailman/listinfo/r-sig-mac is for
> mac specific problems
Du! Of course. Why didn't I think of that!
>
>> I just downloaded the Hmisc package to the Imac that I use. When I
>> attempted
>> to load it I got an error to the effect that it could not load the
>> library:
>>
>> /Library/Frameworks/R.framework/Versions/2.5/Resources/lib/
>> libgfortran.2.dylib
>>
>> Note the ``2.5'' in the foregoing path name; I am currently running
>> 2.6.0, and
>> I suspect that this is the problem --- i.e. the Mac binary on CRAN
>> was built
>> under 2.5.x and this does not work with 2.6.y.
>>
>> I note that the source and Windoze Hmisc packages are designated as
>> 3.4-3, but
>> the Mac package is designated as 3.4-2 which would appear to imply
>> that it's
>> a step behind.
>>
>> Could the Mac binary be updated please? Thanks.
>>
>
> The mac binary at central CRAN is a t3.4-3, so it is probably a
> mirror problem,
> CRAN works for me, but uni of melbourne has the old Hmisc, but it
> works under 2.6 anyway.
I was using the Queensland/Brisbane mirror, and the package that I
downloaded
certainly did *not* work! But this morning it appears to have been
updated
to 3.4-3 and that does work. So all is well.
Thanks.
cheers,
Rolf Turner
##
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Extractor function for standard deviation.
I have from time to time seen inquiries on r-help in respect of
how to obtain the estimated standard deviation from the output of
fitting a linear model. And have had occasion to want to do this
myself.
The way I currently do it is something like summary(fit)$sigma
(where fit is returned by lm()).
It strikes me that it might be a good idea to have an extractor
function, analogous with coef() and resid(), to dig out this value.
This would be in keeping with the R philosophy of ``don't muck
about with the internal components of objects returned by functions,
because the internal structure of such objects might change in future
releases''.
I'm not sure what the name of the extractor function should be.
One idea would be to make sd() generic, and create a function
sd.lm() which could currently have code
sd.lm <- function(x,...) {
summary(x)$sigma
}
The sd.default() function would have the code of the current sd().
Does this idea have any merit?
cheers,
Rolf Turner
##
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] assign("FALSE", TRUE)
It was recently pointed out by Wacek Kusnierczyk that although one is
prevented from doing
FALSE <- TRUE
one *can* do
assign("FALSE",TRUE)
and have an object named ``FALSE'' with value TRUE in one's workspace.
This apparently has no deleterious effects; e.g. doing
sample(1:7,replace=FALSE)
gives a random permutation of 1:7 as expected and desired. I.e. the
local object named ``FALSE'' is not used.
Still, this seems counterintuitive and a bit confusing. Is it the
intended
state of affairs? I would have thought that
FALSE <-
and
assign("FALSE",)
would be completely equivalent.
This is clearly not a very important issue, but it might bear some
thinking about.
cheers,
Rolf Turner
##
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assign("FALSE", TRUE)
On 18/11/2008, at 11:11 AM, Martin Maechler wrote:
Yes. I'd propose that R-core look into how to make assignment to a
reserved word an error.
That's good news. Thanks.
cheers,
Rolf Turner
##
Attention:\ This e-mail message is privileged and confid...{{dropped:9}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
