> 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')
> 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
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
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
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
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
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
