similar to: How to properly finalize external pointers?

Hi Everyone, At the end of this email is a transcript of a problem I have found in RODBC version 2.3-1. It appears that the bug fix in odbcClose for the memory leak has meant that the garbage collector is falling over when it tries to free up the extPtr attribute of the RODBC connection pointer. Any advice on how to fix this? Thanks for your help, Tom

I'm using external pointers and seemingly leaking memory. My determination of a memory leak is that the R process continually creeps up in memory as seen by top while the usage as reported by gc() stays flat. I have isolated the C code: void h5R_allocate_finalizer(SEXP eptr) { Rprintf("Calling the finalizer\n"); void* vector = R_ExternalPtrAddr(eptr); free(vector);

Hello, I'm looking for examples of how to handle serialization of external pointers. We use external pointers intensively in Rcpp for modules and one popular request is to have persistence. And I guess we need to be able to serialize/deserialize external pointers for this. Also, module objects are all instances of reference classes, so maybe that can be handled at the R level ? Romain

My question is based on a project I have partially done, but there is still something I'm not clear. My goal is to create a R package contains GPU functions (some are from Nividia cuda library, some are my self-defined CUDA functions) My design is quite different from current R's GPU package, I want to create a R object (external pointer) point to GPU address, and run my GPU function

Dear all, I have wrapped a C++ function in an R package. I allocate/deallocate memory using C++ 'new' and 'delete'. In order to allow user interrupts without memory leaks I've moved all the delete statements required after an interrupt to a separate C++ function freeMemory(), which is called using on.exit() just before the .C() call. I am concerned about the

Hi, I have followed the recommended steps for creating a package (rctest). As of now, my goal is simply to understand how various pieces fit together. The package includes: (1) C code with source in sub-directories, compiled to create a static library. (a) There is a single C-struct (dns) a simple 'matrix': {int m; int n; double *d;} (b) C code to create random matrix of a certain size.

Currently, I load the RData file then ls() and str(). But loading the file takes too long if the file is big. Most of the time, I only interested what the variables are in the the file and the attributes of the variables (like if it is a data.frame, matrix, what are the colnames/rownames, etc.) I'm wondering if there is any facility in R to help me avoid loading the whole file.

On 11/30/2012 6:36 PM, Lang Hames wrote: > > > RBP is used as the frame pointer on x86 (hence its automatic > appearance in your code), and shouldn't be allocated to any vreg in > function bar. Loading/saving RBP should be managed by the stack frame > setup/teardown code. > If it doesn't already, your allocator should filter out reserved > registers (See

I have a new problem: Register RBP is used in a function foo. (I am not allocating RBP to any virtual register, the instances of RBP in function foo are in the machine code when my register allocator starts.) Function foo calls function bar. Register RBP is not saved across the call, though it is live after the call. Function bar includes a virtual register. The code that I'm using to