[Rd] read.table / type.convert with NA values
Hello,
While assisting a fellow R-helper off list, I narrowed down an issue he
was having to the following behavior of type.convert, called through
read.table. This is using R 2.10.1, if newer versions don't exhibit
this behavior, apologies.
# generates numeric vector
> type.convert(c("123.42", "NA"))
[1] 123.42 NA
# generates a numeric vector, notice the space before 123.42
> type.convert(c(" 123.42 ", "NA"))
[1] 123.42 NA
# generates factor, notice the space before NA
# note that the 2nd element is actually " NA", not a true NA value
> type.convert(c("123.42", " NA"))
[1] 123.42 NA
Levels: 123.42 NA
How can this affect read.table/read.csv use 'in the wild'?
This gentleman had a data file that was
1) delimited by something other than white space, CSV in his case
2) contained missing values, designated by NA in his case
3) contained white space between delimiters and data values, e.g.,
NA, NA,4.5,NA
as opposed to
NA,NA,4.5,NA
With these 3 conditions met, read.table gives type.convert a character
vector like my third example above, and ultimately he got a data.frame
consisting of only factors when we were expecting numeric columns. This
was easily fixed either by modifying the read.csv function call to
specify colClasses directly, or in his case, strip.white = TRUE did the
job just fine.
I believe the confusion stems from the fact that with no NA values in
our data file, this would work as we would expect. The introduction of
what we thought were NA values changed the behavior. In reality, these
were not being treated as NA values by read.table/type.convert. The
question is, should they be in this case?
This behavior of read.table/type.convert may very well be what is
expected/needed. If so, this note could still be of use to someone in
the future if they stumble upon similar behavior. The fact I wasn't
able to uncover anyone who asked about it on list before probably means
the situation is rare.
Best Regards,
Erik Iverson
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] scoping goes wrong when some functions are used within others.
Joris Meys wrote:
Dear,
I'm following the r tag on stackoverflow.com, and couldn't but notice
there are quite some questions popping up that deal with scoping in
relation to custom functions. I grinded my teeth on it already, and I
have absolutely no clue what goes wrong. The general pattern is as
follows :
ff <- function(x){
y <- some_value
some_function(y)
}
ff(x)
Error in eval(expr, envir, enclos) : object 'y' not found
I get:
Error in ff(x) : object 'some_value' not found
which is entirely consistent, since it has not been bound to a value.
I tried to report this as a bug earlier, but got the message I used
the wrong channel. I also don't know how to formalize it into a bug
report on the report site. That's why I bring it to your attention
this way, and want to ask you whether this is by design and we're all
doing something wrong, whether these are problems within certain
packages/situations, ...
I solve these problems now by adding an environment to my global
environment, and delete it after the function finished running. But
this can't be the correct way.
The problem is described here :
http://stackoverflow.com/questions/3840769/scoping-and-functions-in-r-2-11-1-whats-going-wrong
Links to different reports, all having that same pattern but with
different functions :
http://stackoverflow.com/questions/3742415/r-statistical-scoping-error-using-transformby-part-of-the-doby-package
http://stackoverflow.com/questions/3768417/how-to-use-acast-reshape2-within-a-function-in-r
http://stackoverflow.com/questions/3661500/why-cant-i-pass-a-dataset-to-a-function
http://stackoverflow.com/questions/3574858/values-not-being-copied-to-the-next-local-environment
http://stackoverflow.com/questions/2646402/using-functions-and-environments
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] list comprehension to create an arbitrary-sized list with arbitrary names/values
This question probably belongs on R-help instead of R-devel. What works best for you will depend on how big 'mylist' is. An article discussing some possibilities can be found at: http://opendatagroup.com/2009/07/26/hash-package-for-r/ Hope this helps, --Erik Steve Kim wrote: In python, one can do this mydict = dict([(keyfun(x), valfun(x)) for x in mylist]) to create a dictionary with whatever keys and values we want from an input list of arbitrary size. In R, I want to similarly create a list with names/values that are generated by some keyfun and valfun (assuming that keyfun is guaranteed to return something suitable as a name). How can I do this? __ 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
Re: [Rd] Commenting conventions
dhi...@sonic.net wrote: This might be a dumb question, but I couldn't figure out how to find the answer: why is it that comments in R documentation files (i.e. in examples) typically start with a double hash (##) instead of a single hash? See the second paragraph in section 7.5 for the likely answer. http://ess.r-project.org/Manual/ess.html#Indenting __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] developing a package with a name space
Hello - I'm currently maintaining an R package that uses a name space, and am also starting a new R package that will use a name space. According the the R News June 2003 issue, "Adding a name space to a package may complicate debugging code ... it is a good idea not to add a name space to a package until it is completely debugged, and to remove the name space if further debugging is needed ... other alternatives are being explored ... ". Is renaming/removing the NAMESPACE file still the favored approach when developing and debugging code for an R package? I suppose the alternative I have in mind is something like sourcing an R file, and using assignInNamespace(), may be more trouble than it is worth. I am doing this development using ESS by the way. Thanks for any guidance! Erik Iverson __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R's X11 Device Properties
Hello, This is an issue that is at the interface of R, X, and my window manager (either icewm or openbox, both latest versions). I am running R 2.10.1 on Ubuntu 9.10. My goal: When an X11 device is started in R (e.g., by simply calling plot), I would like for the resulting window to be in the "always on top" state, and for focus not to switch to it. Configuring this behavior is handled through the window manager, but both of the above referenced window managers require that the first element of window's WM_CLASS property, second element of window's WM_CLASS property, or the window's WM_WINDOW_ROLE property be set so that the right window can be matched. If I start R, type plot(1,1) and then run "xprop" (command line program to inspect X window properties) on the resulting X11 window, none of these properties show up in the resulting output. Is there any hope for this to change? I did notice in ?X11 that "The standard X11 resource geometry can be used to specify the window position and/or size, but will be overridden by values specified as arguments or non-NA defaults set in X11.options. The class looked for is R_x11." This "R_x11" class works fine for setting the geometry in .Xresources, but it does not seem to be the same "class" as WM_CLASS referenced above. Unfortunately, this is about as far as my knowledge of X goes, so hopefully this makes sense. If anyone has any pointers, they would be welcome. Thank you! Best Regards, Erik Iverson __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] org-mode (was Re: Feature Request: Multiline Comments)
Martin Morgan wrote: On 02/14/2010 08:11 AM, Saptarshi Guha wrote: Hello, Is it possible to extend the R lexer/parser to include multiline comments like /* acomment */ ? This way I can integrate emacs org-mode with my R code, so that I can have a table of contents, section folding, html-output of source etc. Hi Saptarshi -- Do you know about http://orgmode.org/worg/org-tutorials/org-R/org-R.php ? And also the very excellent org-babel, which can be used with R! http://orgmode.org/worg/org-contrib/babel/index.php __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error in grid.text after tcltk package loaded
Hello -
I am noticing some strange errors when using the grid package, but
(apparently) only after loading the tcltk package. The interaction here
does not make sense to me, and I'm wondering if anyone else can
reproduce this, or if it is specific to my setup. Here is my sessionInfo:
sessionInfo()
R version 2.6.2 RC (2008-02-04 r44332)
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=en_US.UTF-8;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] tcltk grid stats graphics grDevices utils datasets
[8] methods base
This also happens to me in R 2.6.1. I'm running Linux (RHEL 4) on a
32-bit Intel CPU and using KDE. These are R versions that I have
compiled myself.
I try the following in R (started with --vanilla), this is the simplest
code I have to reproduce the problem on my end.
## Start R Code
library(grid)
library(tcltk)
grid.text("a", x = seq(0,1, by = .001))
## End R Code
The graphic draws to my X11 device, however, when I try to move the X11
R Graphics Device window with my mouse and 'drop' it somewhere by
releasing the mouse button, I get errors like the following:
> Error in grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x,
: invalid color name
> Error in grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x,
: REAL() can only be applied to a 'numeric', not a 'NULL'
> Error in grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x,
: VECTOR_ELT() can only be applied to a 'list', not a 'integer'
> Error in grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x,
: REAL() can only be applied to a 'numeric', not a 'character'
> Error in grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x,
: REAL() can only be applied to a 'numeric', not a 'NULL'
> Error in grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x,
: REAL() can only be applied to a 'numeric', not a 'char'
In addition: Warning message:
In grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x, :
supplied color is not numeric nor character
My traceback always looks like this:
> traceback()
5: .Call.graphics(fnname, ..., PACKAGE = "grid")
4: grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x,
x$y, resolveHJust(x$just, x$hjust), resolveVJust(x$just,
x$vjust), x$rot, x$check.overlap)
3: drawDetails.text(x, recording = FALSE)
2: drawDetails(x, recording = FALSE)
1: drawGrob(x)
I can only get these messages to happen after loading the tcltk package,
using grid.text, with 'many' text strings (happens rarely with 100,
almost every move with 1000 strings as in my example).
I found just one reference to a similar error message in the archives,
although not to do with grid. Here's a link:
https://stat.ethz.ch/pipermail/r-devel/2008-January/048117.html
Can anyone else replicate this? Any ideas on what's going on?
Best,
Erik Iverson
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error in grid.text after tcltk package loaded
Erik Iverson wrote:
> Hello -
>
> I am noticing some strange errors when using the grid package, but
> (apparently) only after loading the tcltk package. The interaction here
> does not make sense to me, and I'm wondering if anyone else can
> reproduce this, or if it is specific to my setup. Here is my sessionInfo:
>
> sessionInfo()
> R version 2.6.2 RC (2008-02-04 r44332)
> 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=en_US.UTF-8;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] tcltk grid stats graphics grDevices utils datasets
> [8] methods base
>
> This also happens to me in R 2.6.1. I'm running Linux (RHEL 4) on a
> 32-bit Intel CPU and using KDE. These are R versions that I have
> compiled myself.
>
> I try the following in R (started with --vanilla), this is the simplest
> code I have to reproduce the problem on my end.
>
> ## Start R Code
>
> library(grid)
> library(tcltk)
> grid.text("a", x = seq(0,1, by = .001))
>
> ## End R Code
>
> The graphic draws to my X11 device, however, when I try to move the X11
> R Graphics Device window with my mouse and 'drop' it somewhere by
> releasing the mouse button, I get errors like the following:
>
> > Error in grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x,
> : invalid color name
> > Error in grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x,
> : REAL() can only be applied to a 'numeric', not a 'NULL'
> > Error in grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x,
> : VECTOR_ELT() can only be applied to a 'list', not a 'integer'
> > Error in grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x,
> : REAL() can only be applied to a 'numeric', not a 'character'
> > Error in grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x,
> : REAL() can only be applied to a 'numeric', not a 'NULL'
> > Error in grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x,
> : REAL() can only be applied to a 'numeric', not a 'char'
> In addition: Warning message:
> In grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x, :
>supplied color is not numeric nor character
>
> My traceback always looks like this:
> > traceback()
> 5: .Call.graphics(fnname, ..., PACKAGE = "grid")
> 4: grid.Call.graphics("L_text", as.graphicsAnnot(x$label), x$x,
> x$y, resolveHJust(x$just, x$hjust), resolveVJust(x$just,
> x$vjust), x$rot, x$check.overlap)
> 3: drawDetails.text(x, recording = FALSE)
> 2: drawDetails(x, recording = FALSE)
> 1: drawGrob(x)
>
> I can only get these messages to happen after loading the tcltk package,
> using grid.text, with 'many' text strings (happens rarely with 100,
> almost every move with 1000 strings as in my example).
>
> I found just one reference to a similar error message in the archives,
> although not to do with grid. Here's a link:
>
> https://stat.ethz.ch/pipermail/r-devel/2008-January/048117.html
>
> Can anyone else replicate this? Any ideas on what's going on?
One more piece of information. In Gnome, I noticed the messages only
when I'd drag the window part of the way off the visible desktop, and
then drag it back on and drop it. You could see the X11 window 'flash'
white quickly and then redraw (sorry for imprecise terminology here).
On KDE, I have it set to show the X11 geometry when moving windows,
which means it must 'redraw' for each move, since the geometry window
obscures the device contents. Once I took off the geometry setting, I
had to drag the windows part of the way off the screen, and then back on
to cause this behavior.
>
> Best,
> 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] removing last piece of grid graphical output with grid.remove
Hello -
If I create multiple pieces of output in grid, and use grid.remove() to
try to remove the output from the graphics device, I cannot seem to
remove the final piece of output from the device until I 'refresh' the
graphics device by giving it focus. The function grid.remove() does
appear to remove the grob from the display list, however.
I noticed this when the example on page 200-201 in Paul Murrell's R
Graphics book did not work as expected when using
grid.remove("circles"). Can anyone replicate this?
## Example
library(grid)
## Create two circles
grid.circle(name = "redcircle", r = .20, gp = gpar(col = "red"))
grid.circle(name = "bluecircle", r = .25, gp = gpar(col = "blue"))
## removes the blue circle
grid.remove("bluecircle")
## the red circle will be deleted from the grid display list, but
## the graphics device will still show it until I 'refresh' the
## device by giving it focus via mouse or alt+tab, or producing
## more grid output
grid.remove("redcircle") ## still on my X11 device!
## more grid output
grid.text("Now the circle is gone!", name = "txt")
## But I can't get rid of this text on the device
## until I refresh device or do another grid call
grid.remove("txt") ## still on my X1 device!
> sessionInfo()
R version 2.6.2 (2008-02-08)
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=en_US.UTF-8;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] grid stats graphics grDevices utils datasets methods
[8] base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] rbind.data.frame drops attributes for factor variables
Dear R-devel -
I noticed that when I rbind two data.frames together, factor variables
lose their attributes in the resulting data.frame while numeric
variables do not.
As an example, create two data.frames, t1 and t2, with two variables
each. Give each variable an attribute called "label", and then perform
the rbind and look at the resulting structure.
EXAMPLE R CODE #
t1 <- data.frame(subject = 1:4, trt = factor(c("A","B","B","A")))
attr(t1$trt, "label") <- "Trt Label"
attr(t1$subject, "label") <- "Subject Label"
str(t1)
t2 <- data.frame(subject = 5:8, trt = factor(c("A","A","A","A")))
attr(t2$trt, "label") <- "Trt Label"
attr(t2$subject, "label") <- "Subject Label"
str(t2)
str(rbind(t1, t2))
END EXAMPLE R CODE #
The output of the last line of code is:
'data.frame': 8 obs. of 2 variables:
$ subject: atomic 1 2 3 4 5 6 7 8
..- attr(*, "label")= chr "Subject Label"
$ trt: Factor w/ 2 levels "A","B": 1 2 2 1 1 1 1 1
I do not see this documented anywhere in ?rbind, and do not know if it
is intended. It looks like the factor loses its attributes in
rbind.data.frame due to a call to as.vector. Of course, as.vector is
documented to drop the attributes of atomic vector types. I do not know
if this qualifies as a bug or intended since it is not stated in ?rbind
what will happen. sessionInfo() is below.
Best,
Erik Iverson
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] grid error message when resizing graphics window after tcltk loaded
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
Re: [Rd] grid error message when resizing graphics window after tcltk loaded
I unfortunately am having a far more difficult time replicating this on
my home computer.
> sessionInfo()
R version 2.7.0 (2008-04-22)
i486-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
I ran the same code loop as below after loading the tcltk package, and
resized the resulting window dozens of times before seeing the error
message only once. It would often not happen at all. At work, I will
see the message basically every time I resize the window.
Here are the main differences I can think of off the top of my head:
1) RHEL version 4 at work, Unbuntu (8.04) at home
2) Compile my own version of R at work from source, use the Ubuntu R
packages at home, http://cran.r-project.org/bin/linux/ubuntu/
3) Cairo support not enabled at work, it is enabled at home.
If anyone else can replicate this, that would be great. Otherwise, I am
going to try a few more tests tomorrow at work, and will reply with the
results.
Best,
Erik Iverson
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
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] More information on R segfaults, tcltk package, and graphics devices
Dear R-devel -
I have investigated the report I made at
https://stat.ethz.ch/pipermail/r-devel/2008-May/049683.html some more,
and believe I have enough information to warrant an update. My
sessionInfo() immediately after starting R is at the bottom of this message.
I decided to first concentrate on finding out why I sometimes receive a
segfault while closing a graphics window while the window is redrawing
after resizing it, but seemingly only after loading the tcltk package.
I do the following code in a --vanilla R session.
library(grid)
library(tcltk)
for(i in seq(0, 1, by = .1)) {
for(j in seq(0, 1, by = .01)) {
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()
}
}
I then simply resize the X11 window a bit to force a redraw of the
graphic, and then rapidly hit the 'X' close button on the X11 window
while the rectangles are redrawing. I will often get the behavior that
the window closes and R segfaults.
The gdb backtraces from the core dumps I produced mostly were failing in
GEcheckState from engine.c, but it was not clear to me what was going on
from the backtrace.
After much trial and error, I decided to put a breakpoint in the
removeDevice function from device.c.
I then do what I describe above, and get the following backtrace from
gdb, edited to show what I think is going on.
(gdb) bt
#0 removeDevice (devNum=1, findNext=TRUE) at devices.c:307
#1 0xb7962855 in handleEvent (event=
{type = 33, xany = {type = 33, serial = 15621, send_event = 1,
...(snip)...
, 268686226}})
at devX11.c:627
#2 0xb796296c in R_ProcessX11Events (data=0x0) at devX11.c:665
#3 0x080fd99c in R_runHandlers (handlers=0x8263d28, readMask=0x82cf6a0)
at sys-std.c:363
#4 0xb74e159e in RTcl_eventProc (evPtr=0x97dfbf0, flags=-1) at
tcltk_unix.c:136
#5 0xb749d6a3 in Tcl_ServiceEvent () from /usr/lib/libtcl8.4.so.0
#6 0xb749da32 in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so.0
#7 0xb74e14ee in TclSpinLoop (data=0x0) at tcltk_unix.c:60
#8 0x0814d4a6 in R_ToplevelExec (fun=0xb74e14d0 ,
data=0x0) at context.c:604
#9 0xb74e14b2 in TclHandler () at tcltk_unix.c:67
#10 0x08184f11 in R_CheckUserInterrupt () at errors.c:125
#11 0x0818d5cc in Rf_eval (e=0x8ab3010, rho=0x858f6f8) at eval.c:370
... (snip)... Many Rf_eval, Rf_applyClosure, etc.
#73 0x08173480 in do_recordGraphics (call=0x8308040, op=0x83223e0,
args=0x91f4c58,
env=0x8308040) at engine.c:2757
#74 0x081730a7 in GEplayDisplayList (dd=0x974f8e0) at engine.c:2547
#75 0xb7962659 in handleEvent (event=
{type = 12, xany = {type = 12, serial = 14493, send_event = 0,
...snip...
#79 0x0805b0ca in Rf_ReplIteration (rho=0x832ac68, savestack=0,
browselevel=0, state=0xbffbbc34)
at main.c:206
#80 0x0805b1ea in R_ReplConsole (rho=0x832ac68, savestack=0,
browselevel=0) at main.c:306
#81 0x0805b4d8 in run_Rmainloop () at main.c:967
#82 0x08058d91 in main (ac=0, av=0x0) at Rmain.c:35
#83 0xb7d61450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#84 0x08058cc1 in _start ()
What seems to be happening is during the
while (theList != R_NilValue && plotok)
loop in GEplayDisplayList, at some point R_CheckUserInterrupt can be
called, and if the tcltk package has been loaded, its TclHandler is
called, which eventually ends up getting removeDevice called, as the
backtrace above shows. From there, and please excuse my possibly loose
terminology here, the device no longer exists to R, and accessing the
'dd' variable as in GEcheckState can cause a segfault, if something did
not already go wrong while replaying the display list, such as the
strange grid errors such as "Cannot pop top-level viewport" and
"VECTOR_ELT() can only be applied to a 'list', not a 'NULL'" messages I
had been receiving.
Now, I have no idea if there is a fix, or how to go about it at this
point, but I believe that is what is happening, so if anyone wants to
investigate it further, this should be a good starting point. Perhaps
the relevant advice here is "Don't do that".
Please ask if I have not been clear enough or additional information
from gdb is needed.
Best,
Erik Iverson
[EMAIL PROTECTED]
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Error Message (PR#11602)
[EMAIL PROTECTED] wrote: Hello! My Name is Jan Matthias and I am from Cologne University in Germany. I have= problems with R , version 1.9.1. Is this a new record? Jan, update to the latest R, which is about 4 years newer than 1.9.1. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
