Re: [Rd] tests/ok-errors.R ## bad infinite recursion
On Thu 22 May 2008 at 07:09:51 PM +0100, Prof Brian Ripley wrote:
> Why not raise your limits to more reasonable levels? These failures are
> warning you that your limits (stack, it looks) are too low.
These are the default netbsd levels (soft limit). As a user I
can raise the stack to 3072 and the test exits with the expected
result.
However, isn't the purpose of the test to identify if something is
wrong? The problem is: there was _no_failure_ when the ulimit was
reached! When the stack limit is reached the process adds 1 to
the load and does not log or return.
An arbitrary amount of stack may be used before a 'recursive
infinite loop is invoked' so just raising the ulimit doesn't
fix anything other than making the test pass, it just hides the
problem.
These ulimits have been in place for some time on our production
systems, with no problem. Only problem we have experienced is the
test script.
Incidentally ktrace did not indicate what was going on after the
process reached point of no return.
> Also, the descriptors limit should be at least 128 (and no system we looked
> at recently had less than 256).
We have never run out of file descriptors, and given our modeling
tasks, it is unlikely this will ever happen.
At this point I'm looking for a consensus as to whether the shell,
kernel, or R should kill the process when the stack (or another)
ulimit is reached.
I'm thinking it is the kernel/shell that should kill a process
that touches a ulimit; but I'm not 100% on this.
// George
> On Thu, 22 May 2008, George Georgalis wrote:
>
>> I've come across a handful of tests that
>> fail at our site. I consider this one the
>> worst because the process does not return.
>>
>> The patch below simply bypasss the test,
>> but the errors in the out file are included
>> as well. I suspect this is due to more or
>> tighter ulimits on this system.
>>
>> But I'm not sure if this is result of
>> different expectations (kernel/userland) of
>> what should be done in the curcumstance.
>>
>> // George
>>
>>
>> NetBSD chime 4.0_STABLE NetBSD 4.0_STABLE (CHIME) #6: Tue Apr 29 16:49:55
>> EDT 2008 [EMAIL PROTECTED]:/usr/obj/sys/arch/amd64/compile/CHIME amd64
>>
>> time(cpu-seconds)unlimited
>> file(blocks) unlimited
>> coredump(blocks) 1
>> data(kbytes) 262144
>> stack(kbytes)2048
>> lockedmem(kbytes)670964
>> memory(kbytes) 2012892
>> nofiles(descriptors) 64
>> processes160
>> sbsize(bytes)unlimited
>>
>>
>>
>> --- ok-errors.R.orig2007-09-25 18:05:05.0 -0400
>> +++ ok-errors.R 2008-05-21 16:09:12.0 -0400
>> @@ -16,7 +16,40 @@
>>
>> getenv("USER") # should produce correct error message.
>>
>> -## bad infinite recursion / on.exit / ... interactions
>> -bar <- function() 1+1
>> -foo <- function() { on.exit(bar()); foo() }
>> -foo() # now simple "infinite recursion"
>> +### bad infinite recursion / on.exit / ... interactions
>> +#bar <- function() 1+1
>> +#foo <- function() { on.exit(bar()); foo() }
>> +#foo() # now simple "infinite recursion"
>> +#
>> +#
>> +#> ## bad infinite recursion / on.exit / ... interactions
>> +#> bar <- function() 1+1
>> +#> foo <- function() { on.exit(bar()); foo() }
>> +#> foo() # now simple "infinite recursion"
>> +#Error: C stack usage is too close to the limit
>> +#Error: C stack usage is too close to the limit
>> +#Error: C stack usage is too close to the limit
>> +#Error: C stack usage is too close to the limit
>> +#Error: C stack usage is too close to the limit
>> +#Error: segfault from C stack overflow
>> +#Error: C stack usage is too close to the limit
>> +#Error during wrapup: C stack usage is too close to the limit
>> +#Error: C stack usage is too close to the limit
>> +#Error during wrapup: C stack usage is too close to the limit
>> +#Error: C stack usage is too close to the limit
>> +#Error during wrapup: C stack usage is too close to the limit
>> +#Error: C stack usage is too close to the limit
>> +#Error during wrapup: C stack usage is too close to the limit
>> +#Error: C stack usage is too close to the limit
>> +#Error during wrapup: C stack usage is too close to the limit
>> +#Error: C stack usage is too close to the limit
>> +#Error during wrapup: C stack usage is too close to the limit
>> +#Error: C stack usage is too close to the limit
>> +#Error during wrapup: C stack usage is too close to the limit
>> +#Error: C stack usage is too close to the limit
>> +#Error during wrapup: C stack usage is too close to the limit
>> +#Error: C stack usage is too close to the limit
>> +#Error during wrapup: C stack usage is too close to the limit
>> +#Error: C stack usage is too close to the limit
>> +#
>> +# and machine remains at load of 1, R process does not exit or log for
>> several minutes.
>>
>>
>> --
>> George Georgalis, information system scientist <
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
Re: [Rd] names<- bug or feature?
On 5/23/2008 2:22 PM, Patrick Burns wrote: The two statements below with 'names' are conceptually the same. The second performs the desired operation while the first does not. > xx <- list(A=c(a=1, b=2)) > names(xx$A[1]) <- "changed" > xx $A a b 1 2 > names(xx$A)[1] <- "changed" > xx $A changed b 1 2 This is observed in 2.4.0 on Linux as well as 2.7.0 and 2.8.0 on Windows XP. Those aren't the same. The first one says to extract the first element of xx$A and set its names. The second says to set the first name of xx$A. Remember that names(x) <- y is the same as *tmp* <- x x <- `names<-`(*tmp*, y) which in your first case expands to *tmp* <- xx$A[1] xx$A[1] <- `names<-`(*tmp*, "changed") But assigning a named number to a numeric vector has no effect on the names. It would be like xx <- c(a=1, b=2) xx[1] <- c(d=1) which has no effect on xx. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] names<- bug or feature?
The two statements below with 'names' are conceptually the same. The second performs the desired operation while the first does not. > xx <- list(A=c(a=1, b=2)) > names(xx$A[1]) <- "changed" > xx $A a b 1 2 > names(xx$A)[1] <- "changed" > xx $A changed b 1 2 This is observed in 2.4.0 on Linux as well as 2.7.0 and 2.8.0 on Windows XP. Patrick Burns [EMAIL PROTECTED] +44 (0)20 8525 0696 http://www.burns-stat.com (home of S Poetry and "A Guide for the Unwilling S User") __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] seeing an S4 method, not using it
Hi Thibaut --
The short answer seems to be that this is fixed in the devel
implementation of S4 (at least, my effort at reproducing this was
successful in 2.7 but not R version 2.8.0 Under development (unstable)
(2008-05-22 r45762)).
I think it is like this
http://tolstoy.newcastle.edu.au/R/e2/devel/07/09/4469.html
My understanding of the problem is that when the object is read in the
necessary package is 'load'ed but not 'attach'ed -- R knows about the
class definition, etc, but methods and functions from the package are
not on the search path, i.e., after reading your data object, the result
of search() does not contain the package.
When you 'show' your object, S4 tries to find an appropriate method, but
does not. So it uses the default, and makes a note that your object
should be printed with that. After printing, showMethods('show') will
indicate that your object has a 'show' method inherited from 'ANY'.
Unfortunately, if you now load the package, nothing good happens -- the
appropriate show method is available, but S4 thinks that it already
knows a method for your object (the 'ANY' method) so does not find your
version.
Confusing, isn't it?
Martin
Thibaut Jombart wrote:
Dear list,
here is a problem I met when trying to use a method for an S4 object,
without loading the package in which the method was defined. I do not
know if this is a bug, or a mistake of mine. Normally, I think the
package in which the appropriate method is defined is loaded
automatically when calling the method. The problem is that if the
package is indeed loaded automatically, the appropriate method is not used.
An example using the package pixmap (but I obtained similar results with
S4 objects from adegenet and phylobase packages):
# in one R session
> library(pixmap)
> foo <- new("pixmap")
## here the object is printed with the appropriate show method.
> foo
Pixmap image
Type : pixmap
Size : 0x0
Resolution : 0x0
Bounding box : 0 0 0 0
> setClass("myClass", contains="pixmap") # used later
[1] "myClass"
> foo2 <- new("myClass")
## show is ok too
> foo2
Pixmap image
Type : myClass
Size : 0x0
Resolution : 0x0
Bounding box : 0 0 0 0
save.image()
# after closing R and starting a new session, loading the .RData
# (pixmap is not loaded)
> foo
Loading required package: pixmap ## <-- pixmap loaded automatically
An object of class “pixmap”
Slot "size":
[1] 0 0
Slot "cellres":
[1] 0 0
Slot "bbox":
[1] 0 0 0 0
Slot "bbcent":
logical(0)
## the object is not printed correctly. Yet:
> getMethod("show","pixmap")
Method Definition:
function (object)
{
cat("Pixmap image\n")
cat(" Type :", class(object), "\n")
cat(" Size :", paste([EMAIL PROTECTED], collapse = "x"),
"\n")
cat(" Resolution :", paste([EMAIL PROTECTED], collapse = "x"),
"\n")
cat(" Bounding box :", [EMAIL PROTECTED], "\n")
if (is(object, "pixmapIndexed"))
cat(" Nr. of colors :", length(unique(as([EMAIL PROTECTED],
"vector"))), "of", length([EMAIL PROTECTED]), "\n")
cat("\n")
}
Signatures:
object
target "pixmap"
defined "pixmap"
More surprisingly, the printing of foo2 is correct:
> foo2
Pixmap image
Type : myClass
Size : 0x0
Resolution : 0x0
Bounding box : 0 0 0 0
Plus, detaching the package pixmap and re-loading it did not help.
I tried to trace the show method to get an idea of what was going on,
but 'tracing' the problem, solved the problem (!). I used:
> trace("show",browser, signature="pixmap")
> foo
Tracing structure(function (object) on entry
Called from: eval(expr, envir, enclos)
Browse[1]>
Pixmap image
Type : pixmap
Size : 0x0
Resolution : 0x0
Bounding box : 0 0 0 0
> tracingState(FALSE)
> foo
Pixmap image
Type : pixmap
Size : 0x0
Resolution : 0x0
Bounding box : 0 0 0 0
Running debug on trace, I found that the correct show method was used
after this command line:
methods::.TraceWithMethods("show", browser, signature = "pixmap", where
= .GlobalEnv)
But I admit I did not go much further in .TraceWithMethods.
I did not find related topics among known bugs (S4methods section), yet
I found this possibly related topic:
http://tolstoy.newcastle.edu.au/R/e2/devel/07/05/3111.html
but this did not give me an answer.
Is this a normal behaviour?
Here is my sessionInfo (second session):
> sessionInfo()
R version 2.7.0 (2008-04-22)
i686-pc-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] datasets utils stats graphics grDevices methods base
other attached packages:
[1] pixmap_0.4-7 ade4_1.4-8 MASS_7.2-42
loaded via a namespace (and not attached):
[1] tools_2.7.0
My OS is an Ubuntu 8.04 for 32bits systems.
Thanks in advance.
Best regards,
Thibaut.
--
Martin Morgan
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seat
Re: [Rd] grid error message when resizing graphics window after tcltk loaded
One more follow-up here before I head out for the weekend.
I added a PrintValue(gvp); immediately after the gvp = ... around line
647 in grid.c in function L_unsetviewport.
Then I recompile R, and run the code loop below, and resize the window,
very small, then large, repeated) until I see the offending error message.
I obviously am getting a long list of thing that look like
viewport[GRID.VP.262]
while I resize the window, with '262' varying. But eventually, I will see,
viewport[ROOT]
Error: 11Cannot pop the top-level viewport (grid and graphics output mixed?)
I'm a bit in over my head at this point, but maybe this can give someone
a clue. If there's anything I can try on this end to further diagnose
the problem, please let me know.
One more piece of information.
At work (on the RHEL4 machine described below), if I have a graphic that
takes a 'long time' to draw (e.g., print 10's of characters using
grid.text at random points), I can hit the "close" button on the device
window while it is drawing, which will almost always cause a
segmentation fault.
Contrasted at home (setup described below), I could click the button,
but it would not respond to my request to close the window until after
it had finished drawing, at which point it would close the graphics
window gracefully as expected.
Erik
Erik Iverson wrote:
Dear R-devel / Dr. Murrell -
This is similar but ultimately unrelated (I think) to something I posted
about in February. See my original post here:
https://stat.ethz.ch/pipermail/r-devel/2008-February/048278.html
I start R with the --vanilla option, and run the following code.
## BEGIN SAMPLE R CODE
library(grid)
for(i in seq(0, 1, by = .1)) {
for(j in seq(0, 1, by = .1)) {
angle <- runif(1, 1, 180)
col <- sample(colors(), 1)
pushViewport(viewport(x = i, y= j, width = .1, height = .1,
angle = angle, gp = gpar(col = col)))
grid.rect()
popViewport()
}
}
## END SAMPLE R CODE
I can then resize the resulting R Graphics Device window and everything
seems to work fine.
If I then do issue 'library(tcltk)', and reissue the above code, and
then resize the resulting window to something fairly small, I get the
following error that shows up at my R prompt:
Error: Cannot pop the top-level viewport (grid and graphics output mixed?)
The error seems harmless, but eventually, after doing this "enough", and
closing the graphics window, R may segfault,
*** caught segfault ***
address 0xfc, cause 'memory not mapped'
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
I have tracked down the error message I am receiving with some very
rudimentary techniques, and narrowed it down to the L_unsetviewport
function defined in grid.c. The error string in question appears two
places in that function, and I determined in my case that it is the
first instance that is actually outputting the error. That's about as
far as I can take it unfortunately.
Again, this only seems to happen after I load the tcltk package.
I am running RHEL version 4 with KDE on a 32-bit Intel processor.
Here is my session info, immediately after starting R...
sessionInfo()
R version 2.7.0 (2008-04-22)
i686-pc-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Thanks,
Erik Iverson
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] rgb to cmyk conversion is wrong in src/library/grDevices/src/devPS.c (PR#11509)
The conversion of RGB to CMYK takes place in PostScriptSetCol() starting at
line 2900 of R-2.7.0/src/library/grDevices/src/devPS.c
if(strcmp(mm, "cmyk") == 0) {
double c = 1.0-r, m=1.0-g, y=1.0-b, k=c;
k = fmin2(k, m);
k = fmin2(k, y);
if(k == 1.0) c = m = y = 0.0;
else {c /= (1.-k); m /= (1.-k); y /= (1.-k);}
r, g, and b have already been normalized to the range [0,1] before the
function was called, so this is almost right. The last line should actually
be something like
else { c = (c - k)/(1 - k); m = (m - k)/(1 - k); y = (y - k)/(1 - k);}
Here is some R code I wrote that does the conversion, so you can see what it's
supposed to be doing:
rgb2cmyk <- function(rgb){
## rgb is a vector of 3 numbers in the 0 to 255 range
## returns cmyk vector of 4 numbers in [0,1]
cmy <- 1 - rgb/255
names(cmy) <- c("c", "m", "y")
k <- min(min(min(1, cmy[1]), cmy[2]), cmy[3])
if(k == 1) c(cmy, k = 1)
else c(c(cmy - k)/(1-k), k = k)
}
--please do not edit the information below--
Version:
platform = i686-redhat-linux-gnu
arch = i686
os = linux-gnu
system = i686, linux-gnu
status = Patched
major = 2
minor = 7.0
year = 2008
month = 05
day = 22
svn rev = 45762
language = R
version.string = R version 2.7.0 Patched (2008-05-22 r45762)
Locale:
LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=en_US;LC_COLLATE=en_US;LC_MONETARY=C;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils,
package:datasets, package:methods, Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] feature request for M$-Windows install (PR#11499)
Duncan Murdoch wrote: After some offline followups, I'm pretty sure the issue here is with the "Start in" directory that the installer puts in the shortcut. Unfortunately, as far as I can determine, there is no way to tell Windows to set the working directory to the user's personal directory (My Documents, typically). The closest we could get is %USERPROFILE%, which is the parent of My Documents. (My Documents is not always named that, so %USERPROFILE%\My Documents is not safe.) We currently set the shortcut to the My Documents directory of the person who performs the install, so the shortcut that gets created will only work for them. I'd be interested in hearing suggestions for what to do here. We could go back to setting it to RHOME/bin, and then have the startup code cd to My Documents, but that removes flexibility for people who were actually making use of that entry. Duncan Murdoch I tried two options: %USERPROFILE% and %USERNAME% Just as reminder, here is where it currently points (identical for all users). Start in: "C:\Documents and Settings\voland.CAREDS\My Documents" Start in: "C:\Documents and Settings\%USERPROFILE%\My Documents" on this system points to our H: network (home drive) I still need to have the user try to start R with this configuration. Start in: "C:\Documents and Settings\%USERNAME%\My Documents" on this system points to "C:\Documents and Settings\voland\My Documents" (logged in as me) and the user still gets the error message when trying to start R (logged in as the user) I would be content with some option in a custom install. I do not need to allow different configurations for each user. I prefer that the user be without install permissions most of the time. Thanks for your suggestions. Rick Voland [EMAIL PROTECTED] -- Rick Voland [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] seeing an S4 method, not using it
Dear list,
here is a problem I met when trying to use a method for an S4 object,
without loading the package in which the method was defined. I do not
know if this is a bug, or a mistake of mine. Normally, I think the
package in which the appropriate method is defined is loaded
automatically when calling the method. The problem is that if the
package is indeed loaded automatically, the appropriate method is not used.
An example using the package pixmap (but I obtained similar results with
S4 objects from adegenet and phylobase packages):
# in one R session
> library(pixmap)
> foo <- new("pixmap")
## here the object is printed with the appropriate show method.
> foo
Pixmap image
Type : pixmap
Size : 0x0
Resolution : 0x0
Bounding box : 0 0 0 0
> setClass("myClass", contains="pixmap") # used later
[1] "myClass"
> foo2 <- new("myClass")
## show is ok too
> foo2
Pixmap image
Type : myClass
Size : 0x0
Resolution : 0x0
Bounding box : 0 0 0 0
save.image()
# after closing R and starting a new session, loading the .RData
# (pixmap is not loaded)
> foo
Loading required package: pixmap ## <-- pixmap loaded automatically
An object of class “pixmap”
Slot "size":
[1] 0 0
Slot "cellres":
[1] 0 0
Slot "bbox":
[1] 0 0 0 0
Slot "bbcent":
logical(0)
## the object is not printed correctly. Yet:
> getMethod("show","pixmap")
Method Definition:
function (object)
{
cat("Pixmap image\n")
cat(" Type :", class(object), "\n")
cat(" Size :", paste([EMAIL PROTECTED], collapse = "x"),
"\n")
cat(" Resolution :", paste([EMAIL PROTECTED], collapse = "x"),
"\n")
cat(" Bounding box :", [EMAIL PROTECTED], "\n")
if (is(object, "pixmapIndexed"))
cat(" Nr. of colors :", length(unique(as([EMAIL PROTECTED],
"vector"))), "of", length([EMAIL PROTECTED]), "\n")
cat("\n")
}
Signatures:
object
target "pixmap"
defined "pixmap"
More surprisingly, the printing of foo2 is correct:
> foo2
Pixmap image
Type : myClass
Size : 0x0
Resolution : 0x0
Bounding box : 0 0 0 0
Plus, detaching the package pixmap and re-loading it did not help.
I tried to trace the show method to get an idea of what was going on,
but 'tracing' the problem, solved the problem (!). I used:
> trace("show",browser, signature="pixmap")
> foo
Tracing structure(function (object) on entry
Called from: eval(expr, envir, enclos)
Browse[1]>
Pixmap image
Type : pixmap
Size : 0x0
Resolution : 0x0
Bounding box : 0 0 0 0
> tracingState(FALSE)
> foo
Pixmap image
Type : pixmap
Size : 0x0
Resolution : 0x0
Bounding box : 0 0 0 0
Running debug on trace, I found that the correct show method was used
after this command line:
methods::.TraceWithMethods("show", browser, signature = "pixmap", where
= .GlobalEnv)
But I admit I did not go much further in .TraceWithMethods.
I did not find related topics among known bugs (S4methods section), yet
I found this possibly related topic:
http://tolstoy.newcastle.edu.au/R/e2/devel/07/05/3111.html
but this did not give me an answer.
Is this a normal behaviour?
Here is my sessionInfo (second session):
> sessionInfo()
R version 2.7.0 (2008-04-22)
i686-pc-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] datasets utils stats graphics grDevices methods base
other attached packages:
[1] pixmap_0.4-7 ade4_1.4-8 MASS_7.2-42
loaded via a namespace (and not attached):
[1] tools_2.7.0
My OS is an Ubuntu 8.04 for 32bits systems.
Thanks in advance.
Best regards,
Thibaut.
--
##
Thibaut JOMBART
CNRS UMR 5558 - Laboratoire de Biométrie et Biologie Evolutive
Universite Lyon 1
43 bd du 11 novembre 1918
69622 Villeurbanne Cedex
Tél. : 04.72.43.29.35
Fax : 04.72.43.13.88
[EMAIL PROTECTED]
http://biomserv.univ-lyon1.fr/%7Ejombart/
http://adegenet.r-forge.r-project.org/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
