RE: [Rd] getAnywhere and functions starting with "." (PR#7684)
Were you unaware that the NEWS file is browsable at https://svn.r-project.org/R/trunk/NEWS ? On Sat, 12 Feb 2005 [EMAIL PROTECTED] wrote: [MVB] 'getAnywhere' crashes when its argument starts with a period: [UL] Has already been fixed, as you can easily see, e.g., from R-devels NEWS file, section BUG FIXES: Good, thanks. It seems quite common for bugs to be reported after they have been fixed in R-devel. This is likely to occur when-- as in the 'getAnywhere' case-- there's no record of the bug in Bug Tracking (I do check before submitting). It is common for bugs to be reported after they have been discussed on the R-devel list and fixed, as here. Checking R-devel news can be cumbersome-- I couldn't reach the ftp site yesterday, for example, and it's not always feasible to download 12MB-- and many users won't be set up to handle it. To avoid wasting R-core's time over repeat posts, is there some mileage in R-core adding "fixed in Rdevel" bug reports into the Bug Tracking system, even if there is no prior bug report? To avoid wasting R-core's time, do consult the latest version or at least its NEWS file. -- 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@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Notes on bug reports 3229 and 3242 - as.matrix.data.fram e
I agree. Sorry for bothering. With regards, Gregor -Original Message- From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] Sent: pet 2005-02-11 22:35 To: Gorjanc Gregor Cc: Liaw, Andy; r-devel@stat.math.ethz.ch Subject: RE: [Rd] Notes on bug reports 3229 and 3242 - as.matrix.data.fram e ... > ! I agree completely and as I have described up it is my fault that > ! I have/had problems with as.matrix.data.frame by use of write.table. > ! But I think that my proposal is nice, since as.matrix.data.frame would > ! be more robust. It is actually much less robust. It would work for embedded data frames of one column, but you could have a list column with entries of different lengths. e.g. X <- data.frame(x=1:2, y = I(list(a=1, b=3:4))) > as.matrix(X) x y a 1 1 b 2 Integer,2 With your fix, this becomes an error. And I could replace those entries by data frames containing lists of dates Note that in R-devel write.table does not convert data frames to matrices, so this does not arise. We could treat your example specially, but surely it was an error that is better found out about than hushed up. -- 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@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] getAnywhere and functions starting with "." (PR#7684)
>> [MVB] 'getAnywhere' crashes when its argument starts with a period: > [UL] Has already been fixed, as you can easily see, e.g., from R-devels NEWS file, section BUG FIXES: Good, thanks. It seems quite common for bugs to be reported after they have been fixed in R-devel. This is likely to occur when-- as in the 'getAnywhere' case-- there's no record of the bug in Bug Tracking (I do check before submitting). Checking R-devel news can be cumbersome-- I couldn't reach the ftp site yesterday, for example, and it's not always feasible to download 12MB-- and many users won't be set up to handle it. To avoid wasting R-core's time over repeat posts, is there some mileage in R-core adding "fixed in Rdevel" bug reports into the Bug Tracking system, even if there is no prior bug report? Mark Mark Bravington CSIRO Mathematical & Information Sciences Marine Laboratory Castray Esplanade Hobart 7001 TAS ph (+61) 3 6232 5118 fax (+61) 3 6232 5012 mob (+61) 438 315 623 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Can't install add-on package using R-2.0.1-0.fdr.2.fc3.i386.rpm (PR#7688)
Full_Name: mengcheng Version: R-2.0.1-0.fdr.2.fc3.i386.rpm OS: Submission from: (NULL) (216.204.103.5) Somehow R-2.0.1-0.fdr.2.fc3.i386.rpm didn't install R properly. I install R on my fedora 3 using my R-2.0.1-0.fdr.2.fc3.i386.rpm. But when I try to install add-on packages, it fails and show the warning message: /usr/lib/R/bin/Rcmd: line 45: exec: INSTALL: not found I then reinstall R using R-2.0.0-0.fdr.1.fc2.i386.rpm and it work perfectly this time when I try to install add-on. __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: [R-SIG-Mac] Bug running pbinom() in R-GUI?
Brian, On Feb 11, 2005, at 4:14 PM, Prof Brian Ripley wrote: The problem rather is that if R_CheckUserInterrupt is so expensive, we need to redesign it, for it should not be I agree, that's why I named it a 'quick fix'. Unfortunately a more 'proper' fix is far from trivial. Talking of handling interrupts alone, at a first glance Mac OS doesn't need a specific flag like Win, because it handles SIGINT like other unices (in fact that's the default if aqua is disabled). But at the second glance the issue is more tricky: although it is still possible to use the same check as on other unices, which allows anyone to interrupt R using SIGINT, we actually want some GUI element to trigger this - and we get response from GUI elements only if we run the system loop. So checking the interrupt flag is not expensive, but running the loop to enable GUI elements to set the flag is expensive. Currently we don't use threads in the GUI to ensure stability (other than for reading/writing pipes), so the system loop is embedded in the REPL, hence the "Stop" button (which in fact just sends SIGINT when triggered) doesn't work unless we run the system loop ... I have an experimental version of the GUI that runs REPL and system loop in separate threads, but there are many issues, predominantly because the Application Framework is not thread-safe. Using distributed objects to circumvent this has quite big impact on performance, especially for the graphics device, so I'm not ready to do that step with the current public GUI yet. I'll dig a bit to see whether I can come up with some way to get GUI response squeezed in without R_ProcessEvents somehow, but for the time being the quick fix is the only concrete solution I can offer... Best, Simon __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Notes on bug reports 3229 and 3242 - as.matrix.data.fram e
On Fri, 11 Feb 2005, Gorjanc Gregor wrote: From: Liaw, Andy [mailto:[EMAIL PROTECTED] From: Gorjanc Gregor ! Yes, I was not able to do it from my data. But bellow is one. It is ! a stupid one, but it works. The problem is use of as.data.frame in ! tmp1$L <- as.data.frame(tmp$L). This looks like to produce a corrupted ! data.frame. If I use just tmp1$L <- tmp$L, write.table and ! as.matrix.data.frame works OK. I still think that mine proposal can ! give benefit, since it works also on corrupted data frames. data(warpbreaks) tmp <- as.data.frame(tapply(breaks, list(wool, tension), mean)) tmp1 <- data.frame(level=rownames(tmp)) tmp1$L <- as.data.frame(tmp$L) Here's the problem that Brian is referring to: Why do you make one variable in the data frame a data frame? That's what caused problem in write.table()! ! I agree completely and as I have described up it is my fault that ! I have/had problems with as.matrix.data.frame by use of write.table. ! But I think that my proposal is nice, since as.matrix.data.frame would ! be more robust. It is actually much less robust. It would work for embedded data frames of one column, but you could have a list column with entries of different lengths. e.g. X <- data.frame(x=1:2, y = I(list(a=1, b=3:4))) as.matrix(X) x y a 1 1 b 2 Integer,2 With your fix, this becomes an error. And I could replace those entries by data frames containing lists of dates Note that in R-devel write.table does not convert data frames to matrices, so this does not arise. We could treat your example specially, but surely it was an error that is better found out about than hushed up. -- 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@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: [R-SIG-Mac] Bug running pbinom() in R-GUI?
The problem rather is that if R_CheckUserInterrupt is so expensive, we
need to redesign it, for it should not be (and is not on other platforms
as the comments below show). See the comment in src/main/errors.c.
One idea might be for the GUI to set a flag that R_CheckUserInterrupt
consults (which is what happens on Windows via another thread).
I agree that pbeta seems far too enthusiastic on checking, but the
`weight' of R_CheckUserInterrupt needs to be comparable across platforms
or this will recur. Looks to me like it at least 100x more expensive on
OS X than anywhere else. (I timed 1us on Windows, and the timings below
suggest 140us.)
(I think we need to understand why there is a check in that loop, rather
than just choose some arbitrary frequency: looks to me that it is simple
enough to check every million since pbeta(0.5, 1e6, 1e6) takes less than
0.1s on my machine. But integer overflow of n cuts in before it gets
really slow, and I suspect that by n=1e6 it is better to use an
approximation than a sum.)
On Fri, 11 Feb 2005, Simon Urbanek wrote:
On Feb 10, 2005, at 7:38 PM, George W. Gilchrist wrote:
Today I was running a graduate level stats lab using R and we encountered a
major problem while using the current build of the Cocoa GUI:
From the GUI:
system.time(pbinom(80, 1e5, 806/1e6))
[1] 14.37 4.94 30.29 0.00 0.00
From the command line on the same machine:
system.time(pbinom(80, 1e5, 806/1e6))
[1] 0.02 0.00 0.02 0.00 0.00
I've tried the CRAN version and the latest build of the R-GUI and both
deliver the same terrible performance. It seems as if this only occurs for
certain arguments, but we saw this on ~15 different machines today. And it
seems to only be when running the Cocoa GUI. No problems at all with this
under Windoze. Any ideas?
The cause is pbeta_raw calling (indirectly via R_CheckUserInterrupt)
R_ProcessEvents for every iteration - and for small p the number of
iterations goes really high (e.g. for the case above n=99919).
R_ProcessEvents is not a cheap operation, because it enters system event loop
and processes any pending events. A quick fix could be the following patch,
which checks for break only after several iterations (including the first
one, just in case this is part of a sequence that may need user interaction).
Index: src/nmath/pbeta.c
===
--- src/nmath/pbeta.c (revision 33148)
+++ src/nmath/pbeta.c (working copy)
@@ -139,7 +139,8 @@
for(i= 1; i <= n; i++) {
#ifndef MATHLIB_STANDALONE
/* for now, at least allow this:*/
- R_CheckUserInterrupt();
+ if ((i&1023)==1)
+ R_CheckUserInterrupt();
#endif
if (p1 <= 1 && term / eps <= finsum)
break;
after this patch has been applied I get in the GUI:
system.time(pbinom(80, 1e5, 806/1e6))
[1] 0.02 0.00 0.08 0.00 0.00
Cheers,
Simon
__
R-devel@stat.math.ethz.ch 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@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] double/integer (PR#7687)
On Fri, 11 Feb 2005 [EMAIL PROTECTED] wrote:
Full_Name: Chris Spencer
Version: 2.0.1
OS: Linux
Submission from: (NULL) (163.1.211.93)
Dear R team,
I realise that the following is a bit unsafe (the combination of doubles and
integers), however I wondered whether the following behaviour is expected:
#Test R
test <- vector(length=10);
for(i in 1:10){temp = i/1000; test[i] = (i == temp*1000);}
table(test);
test
FALSE TRUE
1472 98528
Certainly. You might even expect worse behaviour than that.
temp can be exactly represented in double precision only when i is a
multiple of 125. Depending on exactly how the computations are done and
how many extra guard digits are carried you could get FALSE for nearly all
i not a multiple of 125. The fact that you get TRUE 98% of the time is
better accuracy than you should expect.
-thomas
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Notes on bug reports 3229 and 3242 - as.matrix.data.fram e
From: Liaw, Andy [mailto:[EMAIL PROTECTED] > From: Gorjanc Gregor > ! Yes, I was not able to do it from my data. But bellow is one. It is > ! a stupid one, but it works. The problem is use of as.data.frame in > ! tmp1$L <- as.data.frame(tmp$L). This looks like to produce > a corrupted > ! data.frame. If I use just tmp1$L <- tmp$L, write.table and > ! as.matrix.data.frame works OK. I still think that mine proposal can > ! give benefit, since it works also on corrupted data frames. > > data(warpbreaks) > tmp <- as.data.frame(tapply(breaks, list(wool, tension), mean)) > tmp1 <- data.frame(level=rownames(tmp)) > tmp1$L <- as.data.frame(tmp$L) Here's the problem that Brian is referring to: Why do you make one variable in the data frame a data frame? That's what caused problem in write.table()! ! I agree completely and as I have described up it is my fault that ! I have/had problems with as.matrix.data.frame by use of write.table. ! But I think that my proposal is nice, since as.matrix.data.frame would ! be more robust. ! With regards, Gregor __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pipe / Fork: Partial Solution / Providing Connections from C?
On Fri, Feb 11, 2005 at 02:32:20PM +0100, Peter Dalgaard wrote:
> "Jan T. Kim" <[EMAIL PROTECTED]> writes:
>
> > > Well, that is probably reasonably easy, but (not the least due to that
> > > fact) I'm still surprised that it has not been done already. I can hardly
> > > imagine that I'm the first one to want to use some external utility from
> > > an R program in this way.
> > >
> > > So, what do you R-devel folks do in this case, and what would you
> > > recommend?
> >
> > I'm still curious about this one. If there really is no way of running
> > stuff through external filter processes in R, I'd volunteer to add
> > that.
> >
> > Best regards & thanks in advance, Jan
>
> If you know how, please do. I have a suspicion it might not be as easy
> as it sounds because of the producer/consumer aspects. Notice, though,
> that in most cases you can get by with system() or pipe() and a
> temporary file for either the input or the output.
Personally, I see filtering as a process, and the sequence of collecting
input in a file, then filtering that into an output file, then reading
that and carrying on with it as a more complex process that involves
filtering as a part of it. Additional complexity means that there's more
that can go wrong, which is why I dislike temporary files.
Specifically. I've seen it happen too often (including to myself) that
things went wrong because other processes were interfering with the
temporary files (in most cases, other processes running the same program).
> I remember speculating about these matters when I was first introduced
> to pipes in C: They'd show you how to open a pipe for reading and how
> to do it for writing, but not how to do both with the same process.
> Took me a while to realize that there is a nontrivial deadlock issue
> if you try to write to a process that itself is blocked trying to
> write its output. Now that is of course not to say that it cannot be
> done with clever multiplexing and buffering techniques -- or
> multithreading, except that R isn't threaded.
It's clear to me that for real dynamic filtering, you need two processes
(or threads). This requires that the operating system supports forking,
i.e. that the fork package works. Without that, filtering is not
possible, at least I'm not in any way I'm aware of.
So, my plan would be to add some function to src/main/connections.c for
setting up a pipe running through an external command and returning the
write and read connections for use in the R program. Then, one could do
something like (modelled after the pipe example in the base docs):
library(fork);
data2 <- c(
"450, 390, 467, 654, 30, 542, 334, 432, 421,",
"357, 497, 493, 550, 549, 467, 575, 578, 342,",
"446, 547, 534, 495, 979, 479");
fp <- filterpipe("sed -e s/,$//");
{
pid <- fork(slave = NULL)
if (pid == 0)
{
close(fp$read);
write(data2, file = fp$write);
close(fp$write);
exit();
}
else
{
close(fp$write);
x <- scan(fp$read);
close(fp$read);
wait(pid);
}
}
Thinking about your buffering suggestion, it occurs to me that it *may*
be possible to create two anonymous files (of the file("") type) and
to connect these to the stdin and the stdout of an external process.
In fact, a couple of days ago I checked whether pipe() would perhaps
accept optional file arguments for specifying the external process'
stdin and stdout, so I could e.g.
f <- file("");
p <- pipe("sed -e s/,$//", stdin = f);
write(data2, file = f);
scan(p);
but that turned out to be another detour on the way that took me here...
Best regards, Jan
--
+- Jan T. Kim ---+
|*NEW*email: [EMAIL PROTECTED] |
|*NEW*WWW: http://www.cmp.uea.ac.uk/people/jtk |
*-=< hierarchical systems are for files, not for humans >=-*
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Re: [R-SIG-Mac] Bug running pbinom() in R-GUI?
On Feb 10, 2005, at 7:38 PM, George W. Gilchrist wrote:
Today I was running a graduate level stats lab using R and we
encountered a
major problem while using the current build of the Cocoa GUI:
From the GUI:
system.time(pbinom(80, 1e5, 806/1e6))
[1] 14.37 4.94 30.29 0.00 0.00
From the command line on the same machine:
system.time(pbinom(80, 1e5, 806/1e6))
[1] 0.02 0.00 0.02 0.00 0.00
I've tried the CRAN version and the latest build of the R-GUI and both
deliver the same terrible performance. It seems as if this only occurs
for
certain arguments, but we saw this on ~15 different machines today.
And it
seems to only be when running the Cocoa GUI. No problems at all with
this
under Windoze. Any ideas?
The cause is pbeta_raw calling (indirectly via R_CheckUserInterrupt)
R_ProcessEvents for every iteration - and for small p the number of
iterations goes really high (e.g. for the case above n=99919).
R_ProcessEvents is not a cheap operation, because it enters system
event loop and processes any pending events. A quick fix could be the
following patch, which checks for break only after several iterations
(including the first one, just in case this is part of a sequence that
may need user interaction).
Index: src/nmath/pbeta.c
===
--- src/nmath/pbeta.c (revision 33148)
+++ src/nmath/pbeta.c (working copy)
@@ -139,7 +139,8 @@
for(i= 1; i <= n; i++) {
#ifndef MATHLIB_STANDALONE
/* for now, at least allow this:*/
- R_CheckUserInterrupt();
+ if ((i&1023)==1)
+ R_CheckUserInterrupt();
#endif
if (p1 <= 1 && term / eps <= finsum)
break;
after this patch has been applied I get in the GUI:
> system.time(pbinom(80, 1e5, 806/1e6))
[1] 0.02 0.00 0.08 0.00 0.00
Cheers,
Simon
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] double/integer (PR#7687)
Full_Name: Chris Spencer
Version: 2.0.1
OS: Linux
Submission from: (NULL) (163.1.211.93)
Dear R team,
I realise that the following is a bit unsafe (the combination of doubles and
integers), however I wondered whether the following behaviour is expected:
> #Test R
> test <- vector(length=10);
> for(i in 1:10){temp = i/1000; test[i] = (i == temp*1000);}
> table(test);
test
FALSE TRUE
1472 98528
For example I can also make the following error:
> as.integer(259.765*1000);
[1] 259765
> as.integer(259.763*1000);
[1] 259762
Would you expect this to be the case and if so why?
Thanks for your help.
Chris Spencer
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] formatC with illegal input crashes Rgui (PR#7686)
Full_Name: Peter Ehlers Version: rw2001pat (2005-02-03) OS: Win XP Submission from: (NULL) (136.159.61.115) formatC(1, flag="s") crashes Rgui. Similarly for flag=[SnZ]. Stupid input, of course, but I'm error-prone. Peter __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] Notes on bug reports 3229 and 3242 - as.matrix.data.fram e
> From: Gorjanc Gregor
>
> ! Look after character !
>
> From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
> You too have not give an reproducible example!
> ! Yes, I was not able to do it from my data. But bellow is one. It is
> ! a stupid one, but it works. The problem is use of as.data.frame in
> ! tmp1$L <- as.data.frame(tmp$L). This looks like to produce
> a corrupted
> ! data.frame. If I use just tmp1$L <- tmp$L, write.table and
> ! as.matrix.data.frame works OK. I still think that mine proposal can
> ! give benefit, since it works also on corrupted data frames.
>
> data(warpbreaks)
> tmp <- as.data.frame(tapply(breaks, list(wool, tension), mean))
> tmp1 <- data.frame(level=rownames(tmp))
> tmp1$L <- as.data.frame(tmp$L)
Here's the problem that Brian is referring to: Why do you make one variable
in the data frame a data frame? That's what caused problem in
write.table()!
Andy
> write.table(tmp1)
> Error in as.matrix.data.frame(x) : dim<- : dims [product 2]
> do not match the length of object [3]
>
> tmp1$L <- tmp$L
> write.table(tmp1)
> "level" "L"
> "1" "A" 44.6
> "2" "B" 28.2
>
> If you have a corrupt data frame, the function may fail,
> which is what
> happened in the PR# you quote.
>
> Please note: you should not be calling as.matrix.data.frame,
> but as.matrix.
> ! I called it because I had problems with write.table and
> that function
> ! calls as.matrix.data.frame.
>
> On Fri, 11 Feb 2005, Gorjanc Gregor wrote:
>
> > Hello R developers.
> >
> > I encountered the same problem as Uwe Ligges with
> as.matrix.data.frame()
> > in bug reports 3229 and 3242 - under section not-reproducible.
> >
> > Example I have is:
> >
> >> tmp
> > level 2100-D
> > 1 biological_process unknown NA
> > 2 cellular process -5.88
> > 3 development -8.42
> > 4physiological process -6.55
> > 5 regulation of biological process NA
> > 6 viral life cycle NA
> >
> >> str(tmp)
> > `data.frame': 6 obs. of 2 variables:
> > $ level : Factor w/ 6 levels "biological_..",..: 1 2 3 4 5 6
> > $ 2100-D_mean:`data.frame':6 obs. of 1 variable:
> > ..$ 2100-D: num NA -5.88 -8.42 -6.55 NA NA
>
> I think you have a data frame column in a data frame, and
> that cannot be
> made directly into a matrix. It's the steps that got you
> here that are
> the problem.
>
> >> as.matrix.data.frame(tmp)
> > Error in as.matrix.data.frame(tmp) : dim<- : dims [product 6] do not
> > match the length of object [7]
> >
> > The error associated with this is comming up at the end of function
> > as.matrix.data.frame where it is used:
> >
> >dim(X) <- c(n, length(X)/n)
> >
> > ?dim says
> > 'dim' has a method for 'data.frame's, which returns the
> length of
> > the 'row.names' attribute of 'x' and the length of 'x' (the
> > numbers of "rows" and "columns").
> >
> > This part is ok. The problem is with X, which is "intensively"
> > modified through the function. Before this (dim(X) <- ...) call
> > X in my case is:
> >
> >> x <- tmp
> >> "code from as.matrix.data.frame down to dim(X) <- ..."
> >> X
> > [[1]]
> > [1] "biological_process unknown"
> >
> > [[2]]
> > [1] "cellular process"
> >
> > [[3]]
> > [1] "development"
> >
> > [[4]]
> > [1] "physiological process"
> >
> > [[5]]
> > [1] "regulation of biological process"
> >
> > [[6]]
> > [1] "viral life cycle"
> >
> > [[7]]
> > [1]NA -5.88 -8.42 -6.55NANA
> >
> > So we can see, that X is somehow destroyed - the first and second
> > column of tmp differ. For dim command this should really be one
> > long vector. So the problem lies in line
> >
> >X <- unlist(X, recursive = FALSE, use.names = FALSE)
> >
> > where it should be
> >
> >X <- unlist(X, recursive = TRUE, use.names = FALSE)
> >
> >
> > I have checked source code for that function from R as well as
> > in R-devel sources. I was not succesfull in reproducing the above
> > with the data frame bellow though. It did not report any problems
> > with old as.matrix.data.frame. There must be some trick with
> > first column in my data. So I am quite sure my suggestion is
> > OK.
> >
> > tmp1 <- data.frame(level=c("A A", "B B"), x=c(NA, -5.8))
> >
> > --
> > Lep pozdrav / With regards,
> >Gregor GORJANC
> >
> > ---
> > University of Ljubljana
> > Biotechnical Faculty URI: http://www.bfro.uni-lj.si
> > Zootechnical Departmentemail: gregor.gorjanc bfro.uni-lj.si
> > Groblje 3 tel: +386 (0)1 72 17 861
> > SI-1230 Domzalefax: +386 (0)1 72 17 888
> > Slovenia
> >
> > __
> > R-devel@stat.math.ethz.ch mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> >
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> Professor of Applied Statistics, http://www.stats.ox.ac.
RE: [Rd] Notes on bug reports 3229 and 3242 - as.matrix.data.frame
! Look after character !
From: Prof Brian Ripley [mailto:[EMAIL PROTECTED]
You too have not give an reproducible example!
! Yes, I was not able to do it from my data. But bellow is one. It is
! a stupid one, but it works. The problem is use of as.data.frame in
! tmp1$L <- as.data.frame(tmp$L). This looks like to produce a corrupted
! data.frame. If I use just tmp1$L <- tmp$L, write.table and
! as.matrix.data.frame works OK. I still think that mine proposal can
! give benefit, since it works also on corrupted data frames.
data(warpbreaks)
tmp <- as.data.frame(tapply(breaks, list(wool, tension), mean))
tmp1 <- data.frame(level=rownames(tmp))
tmp1$L <- as.data.frame(tmp$L)
write.table(tmp1)
Error in as.matrix.data.frame(x) : dim<- : dims [product 2] do not match the
length of object [3]
tmp1$L <- tmp$L
write.table(tmp1)
"level" "L"
"1" "A" 44.6
"2" "B" 28.2
If you have a corrupt data frame, the function may fail, which is what
happened in the PR# you quote.
Please note: you should not be calling as.matrix.data.frame, but as.matrix.
! I called it because I had problems with write.table and that function
! calls as.matrix.data.frame.
On Fri, 11 Feb 2005, Gorjanc Gregor wrote:
> Hello R developers.
>
> I encountered the same problem as Uwe Ligges with as.matrix.data.frame()
> in bug reports 3229 and 3242 - under section not-reproducible.
>
> Example I have is:
>
>> tmp
> level 2100-D
> 1 biological_process unknown NA
> 2 cellular process -5.88
> 3 development -8.42
> 4physiological process -6.55
> 5 regulation of biological process NA
> 6 viral life cycle NA
>
>> str(tmp)
> `data.frame': 6 obs. of 2 variables:
> $ level : Factor w/ 6 levels "biological_..",..: 1 2 3 4 5 6
> $ 2100-D_mean:`data.frame':6 obs. of 1 variable:
> ..$ 2100-D: num NA -5.88 -8.42 -6.55 NA NA
I think you have a data frame column in a data frame, and that cannot be
made directly into a matrix. It's the steps that got you here that are
the problem.
>> as.matrix.data.frame(tmp)
> Error in as.matrix.data.frame(tmp) : dim<- : dims [product 6] do not
> match the length of object [7]
>
> The error associated with this is comming up at the end of function
> as.matrix.data.frame where it is used:
>
>dim(X) <- c(n, length(X)/n)
>
> ?dim says
> 'dim' has a method for 'data.frame's, which returns the length of
> the 'row.names' attribute of 'x' and the length of 'x' (the
> numbers of "rows" and "columns").
>
> This part is ok. The problem is with X, which is "intensively"
> modified through the function. Before this (dim(X) <- ...) call
> X in my case is:
>
>> x <- tmp
>> "code from as.matrix.data.frame down to dim(X) <- ..."
>> X
> [[1]]
> [1] "biological_process unknown"
>
> [[2]]
> [1] "cellular process"
>
> [[3]]
> [1] "development"
>
> [[4]]
> [1] "physiological process"
>
> [[5]]
> [1] "regulation of biological process"
>
> [[6]]
> [1] "viral life cycle"
>
> [[7]]
> [1]NA -5.88 -8.42 -6.55NANA
>
> So we can see, that X is somehow destroyed - the first and second
> column of tmp differ. For dim command this should really be one
> long vector. So the problem lies in line
>
>X <- unlist(X, recursive = FALSE, use.names = FALSE)
>
> where it should be
>
>X <- unlist(X, recursive = TRUE, use.names = FALSE)
>
>
> I have checked source code for that function from R as well as
> in R-devel sources. I was not succesfull in reproducing the above
> with the data frame bellow though. It did not report any problems
> with old as.matrix.data.frame. There must be some trick with
> first column in my data. So I am quite sure my suggestion is
> OK.
>
> tmp1 <- data.frame(level=c("A A", "B B"), x=c(NA, -5.8))
>
> --
> Lep pozdrav / With regards,
>Gregor GORJANC
>
> ---
> University of Ljubljana
> Biotechnical Faculty URI: http://www.bfro.uni-lj.si
> Zootechnical Departmentemail: gregor.gorjanc bfro.uni-lj.si
> Groblje 3 tel: +386 (0)1 72 17 861
> SI-1230 Domzalefax: +386 (0)1 72 17 888
> Slovenia
>
> __
> R-devel@stat.math.ethz.ch 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@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Notes on bug reports 3229 and 3242 - as.matrix.data.frame
You too have not give an reproducible example!
If you have a corrupt data frame, the function may fail, which is what
happened in the PR# you quote.
Please note: you should not be calling as.matrix.data.frame, but as.matrix.
On Fri, 11 Feb 2005, Gorjanc Gregor wrote:
Hello R developers.
I encountered the same problem as Uwe Ligges with as.matrix.data.frame()
in bug reports 3229 and 3242 - under section not-reproducible.
Example I have is:
tmp
level 2100-D
1 biological_process unknown NA
2 cellular process -5.88
3 development -8.42
4physiological process -6.55
5 regulation of biological process NA
6 viral life cycle NA
str(tmp)
`data.frame': 6 obs. of 2 variables:
$ level : Factor w/ 6 levels "biological_..",..: 1 2 3 4 5 6
$ 2100-D_mean:`data.frame':6 obs. of 1 variable:
..$ 2100-D: num NA -5.88 -8.42 -6.55 NA NA
I think you have a data frame column in a data frame, and that cannot be
made directly into a matrix. It's the steps that got you here that are
the problem.
as.matrix.data.frame(tmp)
Error in as.matrix.data.frame(tmp) : dim<- : dims [product 6] do not
match the length of object [7]
The error associated with this is comming up at the end of function
as.matrix.data.frame where it is used:
dim(X) <- c(n, length(X)/n)
?dim says
'dim' has a method for 'data.frame's, which returns the length of
the 'row.names' attribute of 'x' and the length of 'x' (the
numbers of "rows" and "columns").
This part is ok. The problem is with X, which is "intensively"
modified through the function. Before this (dim(X) <- ...) call
X in my case is:
x <- tmp
"code from as.matrix.data.frame down to dim(X) <- ..."
X
[[1]]
[1] "biological_process unknown"
[[2]]
[1] "cellular process"
[[3]]
[1] "development"
[[4]]
[1] "physiological process"
[[5]]
[1] "regulation of biological process"
[[6]]
[1] "viral life cycle"
[[7]]
[1]NA -5.88 -8.42 -6.55NANA
So we can see, that X is somehow destroyed - the first and second
column of tmp differ. For dim command this should really be one
long vector. So the problem lies in line
X <- unlist(X, recursive = FALSE, use.names = FALSE)
where it should be
X <- unlist(X, recursive = TRUE, use.names = FALSE)
I have checked source code for that function from R as well as
in R-devel sources. I was not succesfull in reproducing the above
with the data frame bellow though. It did not report any problems
with old as.matrix.data.frame. There must be some trick with
first column in my data. So I am quite sure my suggestion is
OK.
tmp1 <- data.frame(level=c("A A", "B B"), x=c(NA, -5.8))
--
Lep pozdrav / With regards,
Gregor GORJANC
---
University of Ljubljana
Biotechnical Faculty URI: http://www.bfro.uni-lj.si
Zootechnical Departmentemail: gregor.gorjanc bfro.uni-lj.si
Groblje 3 tel: +386 (0)1 72 17 861
SI-1230 Domzalefax: +386 (0)1 72 17 888
Slovenia
__
R-devel@stat.math.ethz.ch 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@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Notes on bug reports 3229 and 3242 - as.matrix.data.frame
Hello R developers.
I encountered the same problem as Uwe Ligges with as.matrix.data.frame()
in bug reports 3229 and 3242 - under section not-reproducible.
Example I have is:
> tmp
level 2100-D
1 biological_process unknown NA
2 cellular process -5.88
3 development -8.42
4physiological process -6.55
5 regulation of biological process NA
6 viral life cycle NA
> str(tmp)
`data.frame': 6 obs. of 2 variables:
$ level : Factor w/ 6 levels "biological_..",..: 1 2 3 4 5 6
$ 2100-D_mean:`data.frame':6 obs. of 1 variable:
..$ 2100-D: num NA -5.88 -8.42 -6.55 NA NA
> as.matrix.data.frame(tmp)
Error in as.matrix.data.frame(tmp) : dim<- : dims [product 6] do not
match the length of object [7]
The error associated with this is comming up at the end of function
as.matrix.data.frame where it is used:
dim(X) <- c(n, length(X)/n)
?dim says
'dim' has a method for 'data.frame's, which returns the length of
the 'row.names' attribute of 'x' and the length of 'x' (the
numbers of "rows" and "columns").
This part is ok. The problem is with X, which is "intensively"
modified through the function. Before this (dim(X) <- ...) call
X in my case is:
> x <- tmp
> "code from as.matrix.data.frame down to dim(X) <- ..."
> X
[[1]]
[1] "biological_process unknown"
[[2]]
[1] "cellular process"
[[3]]
[1] "development"
[[4]]
[1] "physiological process"
[[5]]
[1] "regulation of biological process"
[[6]]
[1] "viral life cycle"
[[7]]
[1]NA -5.88 -8.42 -6.55NANA
So we can see, that X is somehow destroyed - the first and second
column of tmp differ. For dim command this should really be one
long vector. So the problem lies in line
X <- unlist(X, recursive = FALSE, use.names = FALSE)
where it should be
X <- unlist(X, recursive = TRUE, use.names = FALSE)
I have checked source code for that function from R as well as
in R-devel sources. I was not succesfull in reproducing the above
with the data frame bellow though. It did not report any problems
with old as.matrix.data.frame. There must be some trick with
first column in my data. So I am quite sure my suggestion is
OK.
tmp1 <- data.frame(level=c("A A", "B B"), x=c(NA, -5.8))
--
Lep pozdrav / With regards,
Gregor GORJANC
---
University of Ljubljana
Biotechnical Faculty URI: http://www.bfro.uni-lj.si
Zootechnical Departmentemail: gregor.gorjanc bfro.uni-lj.si
Groblje 3 tel: +386 (0)1 72 17 861
SI-1230 Domzalefax: +386 (0)1 72 17 888
Slovenia
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Pipe / Fork: Partial Solution / Providing Connections from C?
"Jan T. Kim" <[EMAIL PROTECTED]> writes: > > Well, that is probably reasonably easy, but (not the least due to that > > fact) I'm still surprised that it has not been done already. I can hardly > > imagine that I'm the first one to want to use some external utility from > > an R program in this way. > > > > So, what do you R-devel folks do in this case, and what would you > > recommend? > > I'm still curious about this one. If there really is no way of running > stuff through external filter processes in R, I'd volunteer to add > that. > > Best regards & thanks in advance, Jan If you know how, please do. I have a suspicion it might not be as easy as it sounds because of the producer/consumer aspects. Notice, though, that in most cases you can get by with system() or pipe() and a temporary file for either the input or the output. I remember speculating about these matters when I was first introduced to pipes in C: They'd show you how to open a pipe for reading and how to do it for writing, but not how to do both with the same process. Took me a while to realize that there is a nontrivial deadlock issue if you try to write to a process that itself is blocked trying to write its output. Now that is of course not to say that it cannot be done with clever multiplexing and buffering techniques -- or multithreading, except that R isn't threaded. BTW, we met in Heidelberg at the ECMBM ages ago, didn't we? -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Pipe / Fork: Partial Solution / Providing Connections from C?
Dear All, On Tue, Feb 01, 2005 at 07:50:17PM +, Jan T. Kim wrote: > On Tue, Feb 01, 2005 at 01:44:37PM +, Prof Brian Ripley wrote: > > If we only had to consider standard Unices, pipe() would allow read-write > > modes. As it is, it is easy for you to write an OS-specific extension. I've looked into this and tried to write a function that would start an external process and return two connections, one for writing to the external process and one for reading from it. Unfortunately, I haven't found a way to implement this in a package, without altering the R source code itself (details below). As an alternative / workaround, I coded up a function xpipe(cmd, input) that takes a command to start the external process (cmd) and a character containing the lines to be written (input), and returns a character vector containing the output produced by the external process. The xpipe package is available at http://www2.cmp.uea.ac.uk/~jtk/software/xpipe_0.0-1.tar.gz To an extent, this provides the functionality I was looking for, but it is not satisfactory because the output cannot be processed by R on line -- xpipe accumulates the entire output and returns it only after the external process has terminated. Also technically, it's cumbersome to use: For obtaining something else than a character value, it seems one has to write the output into an anonymous file and then use scan, read.table or whatever to read from that file. Therefore, I still look for a way to implement the design where the pipe ends are returned as R connections. The problem in doing so is that connections are stored in a static Rconnection Connections[NCONNECTIONS]; (file src/main/connections.c), and I cannot find any function that provides an interface for allocating a slot in the Connections array and storing a connection set up by a the code in my package there. There is a non-static (i.e. externally visible) NextConnection function (which is not declared in any header, though), and nothing like Rboolean setConnection(int connNumber, Rconnection *conn); Rconnection *getConnection(int connNumber); I haven't found any relevant documentation on these issues (R-exts doesn't have any info on handling connections in C code at all). Can any of you direct me to such docs, or point out how I can instantiate and return connections from within a package? > Well, that is probably reasonably easy, but (not the least due to that > fact) I'm still surprised that it has not been done already. I can hardly > imagine that I'm the first one to want to use some external utility from > an R program in this way. > > So, what do you R-devel folks do in this case, and what would you > recommend? I'm still curious about this one. If there really is no way of running stuff through external filter processes in R, I'd volunteer to add that. Best regards & thanks in advance, Jan -- +- Jan T. Kim ---+ |*NEW*email: [EMAIL PROTECTED] | |*NEW*WWW: http://www.cmp.uea.ac.uk/people/jtk | *-=< hierarchical systems are for files, not for humans >=-* __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-patched Make Check Fails on reg-tests-1.R on linux and OS X
Stefano Iacus has been able to reproduce this on MacOS X (it was a
segfault in a later example), and we have just now committed a workaround.
I think it probably was an OS-specific quirk in vsnprintf.
On Tue, 8 Feb 2005, Prof Brian Ripley wrote:
Since no one else has this problem, I suggest you check the integrity of your
checkout, or, better, use an R-patched tarball that can easily be verified.
This looks very like a mismatched build and test: that is your R build has
not be updated to include the patch which is being tested.
A completely clean build from a tarball will ensure that is not the case.
Reporting problems using unreleased compilers (gcc 3.4.4 is not released)
isn't going to win you a lot of sympathy: they have been responsible for a
large number of (mis-directed) problem reports. If you didn't have the
problem on two machines I would be suggesting using released versions of the
tools.
FYI, R is tested on released compilers on i686 Linux several times a day, and
at least weekly on other common platforms. We would know soon enough if
there was an R problem in 'make all check' on those platforms.
On Mon, 7 Feb 2005, Jake Bowers wrote:
Dear Developers,
I've been playing around with compiling R on my Debian Linux machine (dual
Athlon 1.4ghz) and my OS X machine (dual G5). I'm emailing now because
reg-tests-1.R fails during make check on my debian machine using gcc-3.4,
and on my OS X machine using gcc-3.3. I am using r-patched updated via svn
today (Updated to revision 33075.)
Here are some details:
**Using gcc-3.4 on debian:
gcc-3.4 (GCC) 3.4.4 20041218 (prerelease) (Debian 3.4.3-6)
wes:/home/temp/R/r-patched/tests# tail reg-tests-1.Rout.fail
## automatic row.names can be number-like, MM, 2004-11-26
d0 <- data.frame(x=1:3, y=pi*2:0)
row.names(d0)[3] <- c("01.00")
write.table(d0, (tf <- tempfile()))
d <- read.table(tf)
## gave error ("duplicate row.names") in 2.0.1
stopifnot(all.equal(d,d0))
unlink(tf)
**Using gcc-3.3 on debian works fine (passes all make check).
gcc (GCC) 3.3.5 (Debian 1:3.3.5-5)
**Using gcc-3.3 on OS X.
gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1671)
More info on my OS X build:
./configure --with-blas='-framework vecLib' --with-lapack --with-aqua
--with-x --with-tcl-config=/Library/Frameworks/Tcl.framework/tclConfig.sh
--with-tk-config=/Library/Frameworks/Tk.framework/tkConfig.sh
--enable-R-shlib TCLTK_LIBS='-framework Tcl -framework Tk'
TCLTK_CPPFLAGS='-I/Library/Frameworks/Tcl.Framework/Headers
-I/Library/Frameworks/Tk.Framework/Headers' --with-recommended
g77 is version 3.4 downloaded from hpc.sf.net.
GNU Fortran (GCC) 3.4.2
echo $PATH
/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/sw/bin:/sw/sbin:/usr/local/pvm3/lib:/usr/local/pvm3/bin/DARWIN
and, to prevent it from using stuff in the fink directory:
CPPFLAGS='-I/usr/local/include'
Here is the output where make check fails:
running regression tests
running code in 'reg-tests-1.R' ...make[3]: *** [reg-tests-1.Rout] Error 1
make[2]: *** [test-Reg] Error 2
make[1]: *** [test-all-basics] Error 1
make: *** [check-all] Error 2
sphere:~/TEMP/R/r-patched/tests jwbowers$ tail reg-tests-1.Rout.fail
## automatic row.names can be number-like, MM, 2004-11-26
d0 <- data.frame(x=1:3, y=pi*2:0)
row.names(d0)[3] <- c("01.00")
write.table(d0, (tf <- tempfile()))
d <- read.table(tf)
## gave error ("duplicate row.names") in 2.0.1
stopifnot(all.equal(d,d0))
unlink(tf)
Should I be very concerned about this? I tend to mostly use my OS X
machine since the Linux box is about 4 years old.
I hope this information is helpful --- I'm sorry if this is something
obvious! (I found some posts from last summer about problems with gcc-3.4,
which might explain the problems with gcc-3.4 on linux, but I didn't find
anything obvious about gcc-3.3 on the Mac).
Thanks so much for all of your work!!
Best,
Jake
Jake Bowers
Assistant Professor
Dept of Political Science
University of Michigan
http://www.umich.edu/~jwbowers
__
R-devel@stat.math.ethz.ch 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
--
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@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Canonical S4 Method signature
Paul Roebuck schrieb:
I have trouble finding applicable examples of S4 methods.
Could someone tell me the canonical method for a function
that takes either one or two arguments corresponding to
dimensions? So if vector output desired, only one argument
'n' would be provided. For matrix, two would be provided
corresponding to 'm' and 'n' in that order. And therein
lies the rub as I don't really want to require specifying
the argument name in order to do this.
foo(3) # n = 3
foo(3, 4) # m = 3, n = 4
foo(n = 3, 4) # m = 4, n = 3
What I have come up with thus far is below but that reverses
the order for second case. I could swap them internally if
I knew whether they were specified by name.
setGeneric("foo", function(n, m = n) {
cat("generic", match.call()[[1]], "\n")
standardGeneric("foo")
})
One other alternative might be to just use dots for the
function argument and assign them names internally.
Similar functions in some package? Suggestions (besides
not using S4)?
TIA
--
SIGSIG -- signature too long (core dumped)
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Hi,
maybe the following is a starting point and comes close to what you want ...
Matthias
if(!isGeneric("foo"))
setGeneric("foo", function(m, n) standardGeneric("foo"))
setMethod("foo", signature(m = "missing", n = "numeric"),
function(n){
# do something
# for example
print(n)
})
setMethod("foo", signature(m = "numeric", n = "numeric"),
function(m, n){
# do something
# for example
print(m)
print(n)
})
foo(3, 4)
foo(n = 3, 4)
# unfortunatelly you have to do
foo(,3)
# or
foo(n = 3)
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] getAnywhere and functions starting with "." (PR#7684)
[EMAIL PROTECTED] wrote:
> Full_Name: Mark Bravington
> Version: 2.0.1
> OS: Windows XP
> Submission from: (NULL) (140.79.22.104)
>
>
> 'getAnywhere' crashes when its argument starts with a period:
>
>
>>getAnywhere( '.onLoad')
>
> Error in exists(x, envir, mode, inherits) :
> invalid first argument
>
> One fix might be to replace the line
>
> if ( !is.null(f <- getS3method(gen, cl, TRUE))) {
>
> with
>
> if ( nchar( gen) && !is.null(f <- getS3method(gen, cl, TRUE))) {
>
> Mark
>
> __
> R-devel@stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
Has already been fixed, as you can easily see, e.g., from R-devels NEWS
file, section BUG FIXES:
o getAnywhere() was confused by names with leading or trailing dots
(spotted by Robert McGehee)
Uwe Ligges
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] getAnywhere and functions starting with "." (PR#7684)
This was mentioned a week or so ago on R-devel and is already fixed in the
current sources: from the NEWS file
o getAnywhere() was confused by names with leading or trailing dots
(spotted by Robert McGehee)
On Fri, 11 Feb 2005 [EMAIL PROTECTED] wrote:
Full_Name: Mark Bravington
Version: 2.0.1
OS: Windows XP
Submission from: (NULL) (140.79.22.104)
'getAnywhere' crashes when its argument starts with a period:
It does not: it gives an error. Please do read the comment on this in the
posting guide!
getAnywhere( '.onLoad')
Error in exists(x, envir, mode, inherits) :
invalid first argument
One fix might be to replace the line
if ( !is.null(f <- getS3method(gen, cl, TRUE))) {
with
if ( nchar( gen) && !is.null(f <- getS3method(gen, cl, TRUE))) {
Mark
__
R-devel@stat.math.ethz.ch 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@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
