similar to: R-alpha: R 0.50.a1 S_alloc BUG, priority = URGENT

A set of patches for R-0.50-a1 is now available as ftp://stat.auckland.ac.nz/pub/R/R-0.50-a1.patch1.gz The patches mainly fix problems reported since R-0.50-a1 but some older problems are also fixed. Here is the list of changes. Ross o Many subsetting and mutation problems with the new "expression" type have now been fixed. o When ask=T is set in par() the user is instructed

I want to write a little stand-alone C program that calls R_alloc, but I get a segmentation fault: int main(int argc, char** argv){ double* d = (double *)R_alloc(2, sizeof(double)); // <- segmentation fault! return 0; } gdb reveals that sizeof(double) evaluated to 0: > R_alloc (nelem=2, eltsize=0) at memory.c:1649 so it results in the segfault later. This is how I compile my

Full_Name: Wolfgang Huber Version: R-devel_2005-03-10 OS: alphaev68-dec-osf4.0f Submission from: (NULL) (62.253.128.15) This report concerns allocation of large (>2^31 byte) chunks of memory with R_alloc. I suspect it is a bug/typo but please don't hate me if it's actually a feature: In R, I can happily create large matrices: > a= matrix(0, nrow=191481, ncol=3063) > dim(a) [1]

Hello. I'm having difficulties getting R_alloc() to work. The test platform is a 64-bit Mac running R 2.2.1 installed via a .dmg file obtained from the R site. Details are given below, in a level of detail that I hope is appropriate. My eye was particularly drawn to line #2 in the gdb 'where' output, but line #1 seems sensible so I may just be displaying my ignorance by

Full_Name: Dan Kelley Version: 2.2.1 OS: Mac OSX Submission from: (NULL) (129.173.23.36) I'm having difficulties getting R_alloc() to work on a 64-bit Mac running R 2.2.1 installed via a .dmg file obtained from the R site. Details are given below, in a level of detail that I hope is appropriate. My eye was particularly drawn to line #2 in the gdb 'where' output, but line #1 seems

I am trying to write a C function to create a vector of integers that can be used by the R calling function. I do not know the size of the vector in the R calling function. (Well, actually, I have an upper limit on the size, but that is so large that R cannot allocate it. What I'm doing in the function is to do a sieving procedure, and the result will be small enough to fit into my

Does anyone know what exactly S_alloc() does? (Yes, it's porting time again ...) Thanks, -k =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To:

I am trying to get our database interface (PADI) working with R. The code does some memory allocation and for Splus there is an ifdef which controls whether malloc or S_alloc is called. I did nm R.binary | grep alloc to see if this was supported and I find there are some choices: [2490] | 446036| 272|FUNC |GLOB |0 |7 |R_alloc [806] | 693956| 312|FUNC |LOCL |0 |7

On 04-Jan-16 23:24, Michael Felt wrote: > The bulk is on my forums - the final post for today is: > > Results to date: > > A. It looks like I am going to need a newer compiler for C - xlc/xlC > V11 apparently does not understand this code: > > "/data/prj/cran/R-3.2.3/src/main/memory.c", line 2149.31: 1506-046 (S) > Syntax error. > > I will have to check

[Reposted from llvm-bugs mailing list. Also has an updated, hopefully better, patch associated with it.] Hi, The following program causes the LLVM GCC4 front end to ICE: struct A { virtual ~A(); }; template <typename Ty> struct B : public A { ~B () { delete [] val; } private: Ty* val; }; template <typename Ty> struct C : public A { C (); ~C (); }; template

The Rprofmem facility is currently enabled only if the configuration option --enable-memory-profiling is used. However, the overhead of having it enabled is negligible when profiling is not actually being done, and can easily be made even smaller. So I think it ought to be enabled all the time. I've attached a patch doing this, which also makes a number of other improvements to Rprofmem,

Use macro definition Cc: Jeremy Fitzhardinge <jeremy at goop.org> Cc: Chris Wright <chrisw at sous-sol.org> Cc: virtualization at lists.linux-foundation.org Cc: linux-ia64 at vger.kernel.org Signed-off-by: Fabian Frederick <fabf at skynet.be> --- This is untested. arch/ia64/kernel/paravirt.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git

Use macro definition Cc: Jeremy Fitzhardinge <jeremy at goop.org> Cc: Chris Wright <chrisw at sous-sol.org> Cc: virtualization at lists.linux-foundation.org Cc: linux-ia64 at vger.kernel.org Signed-off-by: Fabian Frederick <fabf at skynet.be> --- This is untested. arch/ia64/kernel/paravirt.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git

Hi all, Thanks to Prof. Ripley, Prof. Gentleman, and Simon Wood (did I miss anyone?). The problem seemed to have gone away. Everyone suggested using some malloc debugger (such as Electric Fence). All I did was following half of what BDR suggested below, i.e., changing all the S_alloc() calls to Calloc() and Free(). I didn't get to try efence, and the problem seems to have disappeared! As

The bulk is on my forums - the final post for today is: Results to date: A. It looks like I am going to need a newer compiler for C - xlc/xlC V11 apparently does not understand this code: "/data/prj/cran/R-3.2.3/src/main/memory.c", line 2149.31: 1506-046 (S) Syntax error. I will have to check if R-devel has different code before asking for assistence. +2139 #ifdef

Dear R users, I am currently trying to create my first personnal function and use it with the apply function. The purpose of this function is to create a vector summarizing the number of levels in a given selection of data.frame columns. I tried to transpose the indexation method used by the nlevels function but it doesn't seem to work. I did not find anything uesful in the archives so

Allocating many small objects triggers numerous garbage collections as R grows its memory, seriously degrading performance. The specific use case is in creating a STRSXP of several 1,000,000's of elements of 60-100 characters each; a simplified illustration understating the effects (because there is initially little to garbage collect, in contrast to an R session with several packages

The R core team proudly presents: \||||||||/ -R 0.61.1- /||||||||\ I've just rolled together a new patch release. It's available from the Auckland repository now, but please do not get it from there unless you are in a terrible hurry. It should find its way to the main CRAN site in Vienna this evening and then to the rest of the CRAN sites. There's also a

The R core team proudly presents: \||||||||/ -R 0.61.1- /||||||||\ I've just rolled together a new patch release. It's available from the Auckland repository now, but please do not get it from there unless you are in a terrible hurry. It should find its way to the main CRAN site in Vienna this evening and then to the rest of the CRAN sites. There's also a

Running on an Alpha machine which reports (uname -a) OSF1 bsdx01.bs.ehu.es V4.0 878 alpha and using the binary distribution put together by Albrecht Gebhardt (in http://cran.at.r-project.org/bin/osf/osf4.0/tar/alpha_ev5/) I obtain core dumps whenever I try to use package rpart. I have R REMOVE'd the rpart package, downloaded the source rpart_1.0-7.tar from CRAN and