similar to: R_alloc with more than 2GB (PR#7721)

The tarballs R-devel_2005-02-16.tar.gz, R-devel_2005-02-15.tar.gz and R-devel_2005-02-14.tar.gz all had the property that when I run ./configure on them I get the following error message: config.status: error: cannot find input file: po/Makefile.in.in which terminates the configure script. After R-devel_2005-02-15.tar.gz was posted but before R-devel_2005-02-16.tar.gz was posted, Jeff Gentry

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

I have some questions and observations about these: Will these replace manually setting options(CRAN), which doesn't work in R-2.1.0? In R-2.1.0, setRepositories() looks to see if options("repos") contains a CRAN entry and will not override that CRAN entry even if the $R_HOME/etc/repositories file (which setRepositories reads from) contains a CRAN entry. Why is this? The user

Had been looking into Luke Tierney's R_AllocatePtr() and was left with a question about exactly when does R reclaim heap memory. Implication of 'simpleref.nw' is that one can allocate C data on the R heap, and as long as pointer object is alive, the data and pointer will remain valid. But it calls allocString() which is implemented using R_alloc(). 'Writing R Extensions" says

Hi, I have a C code which produces array of integers and potentially a string, and I have problems passing the string out. Here is the relevant part of the code: 1 PROTECT(Ret = allocVector(INTSXP, n)); 2 ret = (int*) INTEGER(Ret); /* get pointer to R's Ret */ 3 for(i=0; i<n; i++) ret[i] = data[i]; 4 Free(data); 5 i=1; 6 if (comment) { // comment was found 7 n

Hi, I have a C code which produces array of integers and potentially a string, and I have problems passing the string out. Here is the relevant part of the code: 1 PROTECT(Ret = allocVector(INTSXP, n)); 2 ret = (int*) INTEGER(Ret); /* get pointer to R's Ret */ 3 for(i=0; i<n; i++) ret[i] = data[i]; 4 Free(data); 5 i=1; 6 if (comment) { // comment was found 7 n

I haven't been able to build yesterday's R-devel (or, as a test, R-devel_2005-03-11) on Windows XP. The error message I'm getting is to do with 'arithmetic.c', as shown below. Current R-patched seems to build fine, and I've built previous R-devels from source fairly often in the past-- though I have no understanding whatsoever of what's going on. FWIW the only changes

[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

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

Thanks, That fixed the problem. Jarek -----Original Message----- From: ripley at stats.ox.ac.uk [mailto:ripley at stats.ox.ac.uk] Sent: Friday, July 15, 2005 11:11 AM To: Tuszynski, Jaroslaw W. Cc: r-devel at stat.math.ethz.ch Subject: Re: [R] Passing character strings from C code to R Reading the posting guide would have shown you that R-help was quite inappropriate, so I have moved this to

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,

Hi, I want to write a package where I would use shared memory for some vectors Any suggestion is appreciated... I wonder if the right approach would be to modify add a modified version of the allocVector(SEXPTYPE type, int length) function specifically shared_mem_id = shmget(shared_mem_key, SHM_SIZE, IPC_CREAT);

Hi, The following commands: > tar zxvf R-devel_2005-12-14.tar.gz > mv R-devel R-2.3 > cd R-2.3 > ./configure --with-blas='-framework vecLib' --with-lapack > make give me the following error on my Mac OS X system: ... g77 -fno-common -g -O2 -c xxxpr.f -o xxxpr.o make[3]: *** No rule to make target `-lintl', needed by `libR.dylib'. Stop. make[2]: *** [R]

The current version of S_alloc in src/main/memory.c is char *S_alloc(long nelem, int eltsize) { unsigned int i, size; char *p = R_alloc(nelem, eltsize); for(i=0 ; i<size; i++) p[i] = 0; return p; } which segfaults because `size' is not initialized. I am not what the right fix is, adding size = nelem * eltsize; before the loop seems to work. As an aside ... I think the seed*

Hello all, I want to highlight a recent change in R-devel to the larger developeR community. As of r41495, R maintains a global cache of CHARSXPs such that each unique string is stored only once in memory. For many common use cases, such as dimnames of matrices and keys in environments, the result is a significant savings in memory (and time under some circumstances). A result of these changes

I'm attempting to compile and install R version 1.7.1 for my statistical geneticists. It seems to compile correctly -- that is, it compiles without errors -- but the regression test is failing in the following manner: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > ## log > stopifnot(all.equal(log(1:10), log(1:10, exp(1)))) > stopifnot(all.equal(log10(30), log(30, 10))) >

Dear list I have two (trivial) memory-questions related to a call with .C: If I allocate memory with R_alloc in a C-program (called with .C), will that memory "be taken from" the "available memory pool" (of a maximum of 4gb?) which R can allocate? (This is the impression I get from "Writing R extensions".) If instead I use malloc; will that memory then be taken

Hi, I am trying to implement an algorithm in C which will be called via the .Call() interface. While reading the 'Writing R Extension' manual, I stumbled upon the R_alloc() function for allocating storage for C objects. The manual says it should be used to allocate storage if an C object is needed/created while manipulating R objects within a function called via the .Call() interface.

I am calling 'vmmin' several times from a C function (which is called via .C). It works very well, except for memory consumption. The cause is that vmmin allocates memory via R_alloc, and this memory is not freed as vmmin exits. Instead all the allocated memory is freed on return of the .C call. In one application, I have 2000 functions of 500 variables each to minimize. In each call to