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/main/memory.c:1137
x_l
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 <- "globa
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 Wind
Function 'do_mapply' in mapply.c has the following fragment.
for (int i = 0; i < longest; i++) {
Variable 'longest' is declared as R_xlen_t. Its value can be larger than the
maximum int.
In the fragment, when 'longest' is larger than the maximum int, when 'i'
reaches the maximum int, i++ wi
I don't know if this is a bug per se, but an undesired behavior in
read.dcf. read.dcf takes a file argument and passes it to gzfile if
it's a character:
if (is.character(file)) {
file <- gzfile(file)
on.exit(close(file))
}
This gzfile connection is passed to readLines (line
> 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
> Gábor Csárdi
> on Sun, 13 Nov 2016 20:49:57 + writes:
> Using dup() before fdopen() (and calling fclose() on the connection
> when it is closed) indeed fixes the memory leak.
>
Thank you, Gábor!
Yes I can confirm that this fixes the memory leak.
I'm testing ('make check-all')
