Re: [Rd] Missing objects using dump.frames for post-mortem debugging of crashed batch jobs. Bug or gap in documentation?
> nospam@altfeld-im de
> on Tue, 15 Nov 2016 01:15:46 +0100 writes:
> Martin, thanks for the good news and sorry for wasting your (and others
> time) by not doing my homework and query bugzilla first (lesson learned!
> ).
>
> I have tested the new implementation from R-devel and observe a semantic
> difference when playing with the parameters:
>
> # Test script 1
> g <- "global"
> f <- function(p) {
> l <- "local"
> dump.frames()
> }
> f("parameter")
>
> results in
> # > debugger()
> # Message: object 'server' not foundAvailable environments had calls:
> # 1: source("~/.active-rstudio-document", echo = TRUE)
> # 2: withVisible(eval(ei, envir))
> # 3: eval(ei, envir)
> # 4: eval(expr, envir, enclos)
> # 5: .active-rstudio-document#9: f("parameter")
> #
> # Enter an environment number, or 0 to exit
> # Selection: 5
> # Browsing in the environment with call:
> # .active-rstudio-document#9: f("parameter")
> # Called from: debugger.look(ind)
> # Browse[1]> g
> # [1] "global"
> # Browse[1]>
>
> while dumping to a file
>
> # Test script 2
> g <- "global"
> f <- function(p) {
> l <- "local"
> dump.frames(to.file = TRUE, include.GlobalEnv = TRUE)
> }
> f("parameter")
>
> results in
> # > load("last.dump.rda")
> # > debugger()
> # Message: object 'server' not foundAvailable environments had calls:
> # 1: .GlobalEnv
> # 2: source("~/.active-rstudio-document", echo = TRUE)
> # 3: withVisible(eval(ei, envir))
> # 4: eval(ei, envir)
> # 5: eval(expr, envir, enclos)
> # 6: .active-rstudio-document#11: f("parameter")
> #
> # Enter an environment number, or 0 to exit
> # Selection: 6
> # Browsing in the environment with call:
> # .active-rstudio-document#11: f("parameter")
> # Called from: debugger.look(ind)
> # Browse[1]> g
> # Error: object 'g' not found
> # Browse[1]>
Your call to f() and the corresponding dump is heavily
obfuscated by all the wrap paper that Rstudio seems to wrap around a
simple function call (or just around using debugger() ?).
All this was to get the correct environments when things are run
in a batch job... and there's no Rstudio gift wrapping in that case.
In my simple use of the above, "g" is clearly available in the .GlobalEnv
component of last.dump :
> exists("g", last.dump$.GlobalEnv)
[1] TRUE
> get("g", last.dump$.GlobalEnv)
[1] "global"
>
and that's all what's promised, right?
In such a post mortem debugging, notably from a batch job (!),
you don't want your .GlobalEnv to be *replaced* by the
.GlobalEnv from 'last.dump', do you?
I think in the end, I think you are indirectly asking for new features to be
added to debugger(), namely that it works more seemlessly with
a last.dump object that has been created via 'include.GlobalEnv = TRUE'.
This wish for a new feature may be a very sensible wish.
I think it's fine if you add it as wish (for a new feature to
debugger()) to the R bugzilla site
( https://bugs.r-project.org/ -- after asking one of R core to
add you to the list of "registered ones" there, see the
boldface note in https://www.r-project.org/bugs.html )
Personally, I would only look into this issue if we also get a patch
proposal (see also https://www.r-project.org/bugs.html), because
already now you can easily get to "g" in your example.
Martin
> The semantic difference is that the global variable "g" is visible
> within the function "f" in the first version, but not in the second
> version.
>
> If I dump to a file and load and debug it then the search path through
> the
> frames is not the same during run time vs. debug time.
>
> An implementation with the same semantics could be achieved
> by applying this workaround currently:
>
> dump.frames()
> save.image(file = "last.dump.rda")
>
> Does it possibly make sense to unify the semantics?
>
> THX!
>
>
> On Mon, 2016-11-14 at 11:34 +0100, Martin Maechler wrote:
> > > nospam@altfeld-im de
> > > on Sun, 13 Nov 2016 13:11:38 +0100 writes:
> >
> > > Dear R friends, to allow post-mortem debugging In my
> > > Rscript based batch jobs I use
> >
> > >tryCatch( , error = function(e) {
> > > dump.frames(to.file = TRUE) })
> >
> > > to write the called frames into a dump file.
> >
> > > This is similar to the method recommended in the "Writing
> > > R extensions" manual in section 4.2 Debugging R code (page
> > > 96):
> >
> > > https://cran.r-project.org/doc/manuals/R-exts.pdf
> >
> > >> options(error = quote({dump.frames(to.file=TRUE); q()}))
> >
> >
> >
> > > When I load the dump later in a new R session to examine
> > > the error I use
> >
> > > load(file = "last.dump.rda") debugger(last.dump)
> >
> > > My problem is that the global objects in the workspace are
> > > NOT contained in the dump since "dump.frames" does not
> > > save the workspace.
> >
> > > This makes debugging diffi
Re: [Rd] ifelse() woes ... can we agree on a ifelse2() ?
Finally getting back to this :
> Hadley Wickham
> on Mon, 15 Aug 2016 07:51:35 -0500 writes:
> On Fri, Aug 12, 2016 at 11:31 AM, Hadley Wickham
> wrote:
>>> >> One possibility would also be to consider a
>>> "numbers-only" or >> rather "same type"-only {e.g.,
>>> would also work for characters} >> version.
>>>
>>> > I don't know what you mean by these.
>>>
>>> In the mean time, Bob Rudis mentioned dplyr::if_else(),
>>> which is very relevant, thank you Bob!
>>>
>>> As I have found, that actually works in such a "same
>>> type"-only way: It does not try to coerce, but gives an
>>> error when the classes differ, even in this somewhat
>>> debatable case :
>>>
>>> > dplyr::if_else(c(TRUE, FALSE), 2:3, 0+10:11) Error:
>>> `false` has type 'double' not 'integer'
>>> >
>>>
>>> As documented, if_else() is clearly stricter than
>>> ifelse() and e.g., also does no recycling (but of
>>> length() 1).
>>
>> I agree that if_else() is currently too strict - it's
>> particularly annoying if you want to replace some values
>> with a missing:
>>
>> x <- sample(10) if_else(x > 5, NA, x) # Error: `false`
>> has type 'integer' not 'logical'
>>
>> But I would like to make sure that this remains an error:
>>
>> if_else(x > 5, x, "BLAH")
>>
>> Because that seems more likely to be a user error (but
>> reasonable people might certainly believe that it should
>> just work)
>>
>> dplyr is more accommodating in other places (i.e. in
>> bind_rows(), collapse() and the joins) but it's
>> surprisingly hard to get all the details right. For
>> example, what should the result of this call be?
>>
>> if_else(c(TRUE, FALSE), factor(c("a", "b")),
>> factor(c("c", "b"))
>>
>> Strictly speaking I think you could argue it's an error,
>> but that's not very user-friendly. Should it be a factor
>> with the union of the levels? Should it be a character
>> vector + warning? Should the behaviour change if one set
>> of levels is a subset of the other set?
>>
>> There are similar issues for POSIXct (if the time zones
>> are different, which should win?), and difftimes
>> (similarly for units). Ideally you'd like the behaviour
>> to be extensible for new S3 classes, which suggests it
>> should be a generic (and for the most general case, it
>> would need to dispatch on both arguments).
> One possible principle would be to use c() -
> i.e. construct out as
> out <- c(yes[0], no[0]
> length(out) <- max(length(yes), length(no))
yes; this would require that a `length<-` method works for the
class of the result.
Duncan Murdoch mentioned a version of this, in his very
first reply:
ans <- c(yes, no)[seq_along(test)]
ans <- ans[seq_along(test)]
which is less efficient for atomic vectors, but requires
less from the class: it "only" needs `c` and `[` to work
and a mixture of your two proposals would be possible too:
ans <- c(yes[0], no[0])
ans <- ans[seq_along(test)]
which does *not* work for my "mpfr" numbers (CRAN package 'Rmpfr'),
but that's a buglet in the c.mpfr() implementation of my Rmpfr
package... (which has already been fixed in the development version on R-forge,
https://r-forge.r-project.org/R/?group_id=386)
> But of course that wouldn't help with factor responses.
Yes. However, a version of Duncan's suggestion -- of treating 'yes' first
-- does help in that case.
For once, mainly as "feasability experiment",
I have created a github gist to make my current ifelse2() proposal available
for commenting, cloning, pullrequesting, etc:
Consisting of 2 files
- ifelse-def.R : Functions definitions only, basically all the current
proposals, called ifelse*()
- ifelse-checks.R : A simplistic checking function
and examples calling it, notably demonstrating that my
ifelse2() does work with
"Date", (i.e. "POSIXct" and "POSIXlt"), factors,
and "mpfr" (the arbitrary-precision numbers in my package "Rmpfr")
Also if you are not on github, you can quickly get to the ifelse2()
definition :
https://gist.github.com/mmaechler/9cfc3219c4b89649313bfe6853d87894#file-ifelse-def-r-L168
> Also, if you're considering an improved ifelse(), I'd
> strongly urge you to consider adding an `na` argument,
I now did (called it 'NA.').
> so that you can use ifelse() to transform all three
> possible values in a logical vector.
> Hadley
> -- http://hadley.nz
For those who really hate GH (and don't want or cannot easily follow the
above URL), here's my current definition:
##' Martin Maechler, 14. Nov 2016 --- taking into account Duncan M. and Hadley's
##' ideas in the R-devel thread starting at (my mom's 86th birthday):
##' https://stat.ethz.ch/pipermail/r-devel/2016-August/072970.html
ifelse2 <-
Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?
Hi Paul, No problem. Is it best if I post examples to the bug report 16951? Kind regards, Mark -- Mark O'Connell, PhD student Department of Mathematics & Statistics 231 Top Logic National University of Ireland, Maynooth - Paul Murrell wrote: > > Thanks Frederick. > > Mark, if you have any examples to share, they would also be gratefully > received. > > Paul > > On 14/11/16 14:53, frede...@ofb.net wrote: > > Hi Paul, > > > > OK I tried not to make the examples too fancy. > > > > Please let me know what you think. They should probably be amended to > > support the Windows platform, but I think that task would be much > > easier for someone with access to Windows... > > > > By the way I'm Cc'ing Mark O'Connell who shared with me some great > > getGraphicsEvent examples - well, I found them useful, perhaps if > > these are going to the R distro somewhere, then his examples should be > > included as well. > > > > Thank you, > > > > Frederick > > > > On Mon, Nov 14, 2016 at 01:51:08PM +1300, Paul Murrell wrote: > >> > >> Great. Thanks! > >> > >> Paul > >> > >> On 14/11/16 13:41, frede...@ofb.net wrote: > >>> Hi Paul, > >>> > >>> Thank you, for some reason I didn't seem to get an email notification > >>> for your bugzilla comment! > >>> > >>> I will try to send you something shortly. > >>> > >>> Frederick > >>> > >>> On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote: > Hi > > The current status is that I am keen for people to contribute some > testing > code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) > > There were also some getGraphicsEvent() changes/fixes suggested by > Richard > Bodewits (cc'ed), for which I am also seeking test code. > > Paul > > On 13/11/16 09:00, frede...@ofb.net wrote: > > Hi Paul, > > > > Just checking in to see what the status is. > > > > From my perspective it seems logical to split off X11 into a separate > > package, so development can proceed at a reasonable rate, but I > > haven't yet tried to see if that's even possible. > > > > Thanks, > > > > Frederick > > > > On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote: > >> Hi > >> > >> Taking a look at those patches is now on my todo list, so I may be in > >> touch > >> with both of you at some point to request some testing. > >> > >> Paul > >> > >> On 26/07/16 07:17, frede...@ofb.net wrote: > >>> Dear Daniel Greenidge, > >>> > >>> To enable getGraphicsEvent on Cairo, you have two patches to choose > >>> from: > >>> > >>> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 > >>> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 > >>> > >>> The second one is by me, and the first one is from five years ago by > >>> Hugo Mildenberger. > >>> > >>> Both patches are very simple, they move some lines enabling > >>> getGrahpicsEvent outside of a if(!cairo) statement. My patch also adds > >>> the ability to execute code (e.g. for animation) while the interface > >>> is idle. > >>> > >>> Top guy Duncan Murdoch has expressed that he doesn't have time to work > >>> on applying these patches, and I haven't had any responses from the > >>> rest of the R Core Team. I was thinking that perhaps your best bet is > >>> to try to create a package called e.g. "X11-fixes" which people can > >>> use to get a better X11 library (there is also a bug waiting to be > >>> fixed from 2001: > >>> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702). > >>> > >>> I don't know if CRAN would accept such a package, or if you'd have to > >>> distribute it via GitHub, but R has excellent tools to facilitate the > >>> distribution of code via packages. Whether the R kernel exports enough > >>> functions to allow a package to take over event handling, I'm not > >>> sure. I was intending to look more into the details of this > >>> possibility but haven't had time. > >>> > >>> Best wishes, > >>> > >>> Frederick > >>> > >>> On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote: > Hi all, > > I'm writing an interactive plotting function for viewing fMRI > datasets. Currently, I get keypresses using > grDevices::getGraphicsEvent(). > > Unfortunately getGraphicsEvent() only supports the X11(type="Xlib") > graphics device on Unix systems. The Xlib device doesn't support > buffering (i.e. dev.hold() and dev.flush()), so redrawing the plots > causes lots of flickering. > > Is there a way to get keypresses while using the cairo graphics > device? Alternatively, is there a way to prevent flickering with the > Xlib graphics device? > > Best, > Daniel Gree
Re: [Rd] getGraphicsEvent() alternative for cairo graphics device?
Hi That sounds good - somewhere public like that would be best. Thanks! Paul On 16/11/16 00:13, Mark O'Connell wrote: Hi Paul, No problem. Is it best if I post examples to the bug report 16951? Kind regards, Mark -- Mark O'Connell, PhD student Department of Mathematics & Statistics 231 Top Logic National University of Ireland, Maynooth - Paul Murrell wrote: Thanks Frederick. Mark, if you have any examples to share, they would also be gratefully received. Paul On 14/11/16 14:53, frede...@ofb.net wrote: Hi Paul, OK I tried not to make the examples too fancy. Please let me know what you think. They should probably be amended to support the Windows platform, but I think that task would be much easier for someone with access to Windows... By the way I'm Cc'ing Mark O'Connell who shared with me some great getGraphicsEvent examples - well, I found them useful, perhaps if these are going to the R distro somewhere, then his examples should be included as well. Thank you, Frederick On Mon, Nov 14, 2016 at 01:51:08PM +1300, Paul Murrell wrote: Great. Thanks! Paul On 14/11/16 13:41, frede...@ofb.net wrote: Hi Paul, Thank you, for some reason I didn't seem to get an email notification for your bugzilla comment! I will try to send you something shortly. Frederick On Mon, Nov 14, 2016 at 08:55:20AM +1300, Paul Murrell wrote: Hi The current status is that I am keen for people to contribute some testing code (see https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951) There were also some getGraphicsEvent() changes/fixes suggested by Richard Bodewits (cc'ed), for which I am also seeking test code. Paul On 13/11/16 09:00, frede...@ofb.net wrote: Hi Paul, Just checking in to see what the status is. From my perspective it seems logical to split off X11 into a separate package, so development can proceed at a reasonable rate, but I haven't yet tried to see if that's even possible. Thanks, Frederick On Tue, Jul 26, 2016 at 09:23:35AM +1200, Paul Murrell wrote: Hi Taking a look at those patches is now on my todo list, so I may be in touch with both of you at some point to request some testing. Paul On 26/07/16 07:17, frede...@ofb.net wrote: Dear Daniel Greenidge, To enable getGraphicsEvent on Cairo, you have two patches to choose from: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=14364 https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16951 The second one is by me, and the first one is from five years ago by Hugo Mildenberger. Both patches are very simple, they move some lines enabling getGrahpicsEvent outside of a if(!cairo) statement. My patch also adds the ability to execute code (e.g. for animation) while the interface is idle. Top guy Duncan Murdoch has expressed that he doesn't have time to work on applying these patches, and I haven't had any responses from the rest of the R Core Team. I was thinking that perhaps your best bet is to try to create a package called e.g. "X11-fixes" which people can use to get a better X11 library (there is also a bug waiting to be fixed from 2001: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16702). I don't know if CRAN would accept such a package, or if you'd have to distribute it via GitHub, but R has excellent tools to facilitate the distribution of code via packages. Whether the R kernel exports enough functions to allow a package to take over event handling, I'm not sure. I was intending to look more into the details of this possibility but haven't had time. Best wishes, Frederick On Mon, Jul 25, 2016 at 02:15:59PM -0400, Daniel Greenidge wrote: Hi all, I'm writing an interactive plotting function for viewing fMRI datasets. Currently, I get keypresses using grDevices::getGraphicsEvent(). Unfortunately getGraphicsEvent() only supports the X11(type="Xlib") graphics device on Unix systems. The Xlib device doesn't support buffering (i.e. dev.hold() and dev.flush()), so redrawing the plots causes lots of flickering. Is there a way to get keypresses while using the cairo graphics device? Alternatively, is there a way to prevent flickering with the Xlib graphics device? Best, Daniel Greenidge __ 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 -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 p...@stat.auckland.ac.nz http://www.stat.auck
Re: [Rd] ifelse() woes ... can we agree on a ifelse2() ?
All,
Martin: Thanks for this and all the other things you are doing to both
drive R forward and engage more with the community about things like this.
Apologies for missing this discussion the first time it came around and if
anything here has already been brought up, but I wonder what exactly you
mean when you want recycling behavior.
Specifically, based on an unrelated discussion with Henrik Bengtsson on
Twitter, I wonder if preserving the recycling behavior test is longer than
yes, no, but making the case where
length( test ) < max(length( yes ), length( no ))
would simplify usage for userRs in a useful way. I suspect it's easy to
forget that the result is not guaranteed to be the length of test, even
for intermediate and advanced users familiar with ifelse and it's
strengths/weaknesses.
I certainly agree (for what that's worth...) that
x = rnorm(100)
y = ifelse2(x > 0, 1L, 2L)
should continue to work.
Also, If we combine a stricter contract that the output will always be of
length with the suggestion of a specified output class the pseudo code
could be
ifelse2 = function(test, yes, no, outclass) {
lenout = length(test)
out = as( rep(yes, length.out = lenout), outclass)
out[!test] = as(rep(no, length.out = lenout)[!test], outclass)
#handle NA stuff
out
}
NAs could be tricky if outclass were allowed to be completely general, but
doable, I think? Another approach if we ARE fast-passing while leaving
ifelse intact is that maybe NA's in test just aren't allowed in ifelse2.
I'm not saying we should definitely do that, but it's possible and would
make things faster.
Finally, In terms of efficiency, with the stuff that Luke and I are working
on, the NA detection could be virtually free in certain cases, which could
give a nice boost for long vectors that don't have any NAs (and 'know'
that they don't).
Best,
~G
On Tue, Nov 15, 2016 at 3:58 AM, Martin Maechler wrote:
> Finally getting back to this :
>
> > Hadley Wickham
> > on Mon, 15 Aug 2016 07:51:35 -0500 writes:
>
> > On Fri, Aug 12, 2016 at 11:31 AM, Hadley Wickham
> > wrote:
> >>> >> One possibility would also be to consider a
> >>> "numbers-only" or >> rather "same type"-only {e.g.,
> >>> would also work for characters} >> version.
> >>>
> >>> > I don't know what you mean by these.
> >>>
> >>> In the mean time, Bob Rudis mentioned dplyr::if_else(),
> >>> which is very relevant, thank you Bob!
> >>>
> >>> As I have found, that actually works in such a "same
> >>> type"-only way: It does not try to coerce, but gives an
> >>> error when the classes differ, even in this somewhat
> >>> debatable case :
> >>>
> >>> > dplyr::if_else(c(TRUE, FALSE), 2:3, 0+10:11) Error:
> >>> `false` has type 'double' not 'integer'
> >>> >
> >>>
> >>> As documented, if_else() is clearly stricter than
> >>> ifelse() and e.g., also does no recycling (but of
> >>> length() 1).
> >>
> >> I agree that if_else() is currently too strict - it's
> >> particularly annoying if you want to replace some values
> >> with a missing:
> >>
> >> x <- sample(10) if_else(x > 5, NA, x) # Error: `false`
> >> has type 'integer' not 'logical'
> >>
> >> But I would like to make sure that this remains an error:
> >>
> >> if_else(x > 5, x, "BLAH")
> >>
> >> Because that seems more likely to be a user error (but
> >> reasonable people might certainly believe that it should
> >> just work)
> >>
> >> dplyr is more accommodating in other places (i.e. in
> >> bind_rows(), collapse() and the joins) but it's
> >> surprisingly hard to get all the details right. For
> >> example, what should the result of this call be?
> >>
> >> if_else(c(TRUE, FALSE), factor(c("a", "b")),
> >> factor(c("c", "b"))
> >>
> >> Strictly speaking I think you could argue it's an error,
> >> but that's not very user-friendly. Should it be a factor
> >> with the union of the levels? Should it be a character
> >> vector + warning? Should the behaviour change if one set
> >> of levels is a subset of the other set?
> >>
> >> There are similar issues for POSIXct (if the time zones
> >> are different, which should win?), and difftimes
> >> (similarly for units). Ideally you'd like the behaviour
> >> to be extensible for new S3 classes, which suggests it
> >> should be a generic (and for the most general case, it
> >> would need to dispatch on both arguments).
>
> > One possible principle would be to use c() -
> > i.e. construct out as
>
> > out <- c(yes[0], no[0]
> > length(out) <- max(length(yes), length(no))
>
> yes; this would require that a `length<-` method works for the
> class of the result.
>
> Duncan Murdoch mentioned a version of this, in his very
> first reply:
>
> ans <- c(yes, no)[seq_along(test)]
> ans <- ans[seq_along(test)]
>
> w
Re: [Rd] creating a long list puts R in a state where many things stop working
For reference, running your code in a build of R-devel with sanitizers: > x <- vector(mode="list", length=3e9) memory.c:2747:27: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'R_len_t' (aka 'int') SUMMARY: AddressSanitizer: undefined-behavior memory.c:2747:27 in ASAN:DEADLYSIGNAL = ==50159==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc 0x00010b3452a7 bp 0x7fff5669d2b0 sp 0x7fff5669cd80 T0) ==50159==The signal is caused by a READ memory access. ==50159==Hint: address points to the zero page. #0 0x10b3452a6 in Rf_allocVector3 memory.c:2748 #1 0x10afc13b1 in do_makevector builtin.c:789 #2 0x10b238868 in bcEval eval.c:6041 #3 0x10b2241b8 in Rf_eval eval.c:626 #4 0x10b2794d4 in Rf_applyClosure eval.c:1160 #5 0x10b224d16 in Rf_eval eval.c:742 #6 0x10b286591 in do_set eval.c:2227 #7 0x10b2246ae in Rf_eval eval.c:695 #8 0x10b3229ef in Rf_ReplIteration main.c:258 #9 0x10b327280 in R_ReplConsole main.c:308 #10 0x10b327087 in run_Rmainloop main.c:1059 #11 0x10955fea4 in main Rmain.c:29 #12 0x7fffcabf3254 in start (libdyld.dylib+0x5254) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV memory.c:2748 in Rf_allocVector3 ==50159==ABORTING Abort trap: 6 Looks like there's an index here that needs to be R_xlen_t? https://github.com/wch/r-source/blob/6e7a2ed989027f3800d2e2d64e60e6d700034c6b/src/main/memory.c#L2747 Declared at https://github.com/wch/r-source/blob/6e7a2ed989027f3800d2e2d64e60e6d700034c6b/src/main/memory.c#L2476 -- could this index safely become R_xlen_t? Kevin On Mon, Nov 14, 2016 at 10:10 PM, Hervé Pagès wrote: > Hi, > > After I create a long list e.g. with > > x <- vector(mode="list", length=3e9) > > many bad things start to happen e.g. some things stop working with a > spurious error message: > > gc() > # Error in gc() : > # long vectors not supported yet: /home/hpages/src/R-3.3.2/src/m > ain/memory.c:1137 > > x_lens <- lengths(x) > # Error in lengths(x) : > # long vectors not supported yet: /home/hpages/src/R-3.3.2/src/m > ain/memory.c:1668 > > But then some of them work again: > > gc() > # used (Mb) gc trigger(Mb) max used(Mb) > # Ncells 57046 3.1 36800019.7 3518.7 > # Vcells 138060 1.1 4320596678 32963.6 4500397915 34335.4 > > while others still fail but now with a different error message: > > x_lens <- lengths(x) > # Error: evaluation nested too deeply: infinite recursion / > options(expressions=)? > > etc... > > The more I go, the more weird things I see so clearly my session > got corrupted. Finally, and not too surprisingly, after playing a > little bit more, my session eventually crashed. > > Thanks, > H. > > > sessionInfo() > R version 3.3.2 (2016-10-31) > Platform: x86_64-pc-linux-gnu (64-bit) > Running under: Ubuntu 14.04.3 LTS > > locale: > [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C > [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 > [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 > [7] LC_PAPER=en_US.UTF-8 LC_NAME=C > [9] LC_ADDRESS=C LC_TELEPHONE=C > [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > > -- > Hervé Pagès > > Program in Computational Biology > Division of Public Health Sciences > Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N, M1-B514 > P.O. Box 19024 > Seattle, WA 98109-1024 > > E-mail: hpa...@fredhutch.org > Phone: (206) 667-5791 > Fax:(206) 667-1319 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
