search for: r_externalptraddr

...system of differential equations to be defined in a dll that has been dynamically loaded from the file named in dllname. I use getNativeSymbolInfo(func, dllname)$address to get the address of the function and pass it to a C function called via the .Call interface. Inside that C function, I use R_ExternalPtrAddr(deriv_func) to get the function pointer. This requires typcasting the return value of R_ExternalPtrAddr from (void *) to (deriv_func *), defined in a typedef in call_lsoda(). To be more explicit (I'm replacing irrelevant arguments with ellipses): In lsoda(...,func,dllname,...), func contain...

...(cudaMalloc((void**)&x, *lenth * sizeof(double))); //protect the R external pointer from finalizer SEXP ext = PROTECT(R_MakeExternalPtr(x, R_NilValue, R_NilValue)); R_RegisterCFinalizerEx(ext, _finalizer, TRUE); ? //copying CPU to GPU cublascall(cublasSetVector(*lenth, sizeof(double), temp, 1,? R_ExternalPtrAddr(ext), 1)); ? ? ? ? ? ?UNPROTECT(2); return ext; } here is my finalized for my create function, /* define finalizer for R external pointer input is R external pointer, function will finalize the pointer? when it is not in use. */ static void _finalizer(SEXP ext) { if (!R_ExternalPtrAddr(ext)) re...

...l the finalizer and then unregister it? (this would also work when removing the SEXP external pointer object is difficult because it was handed over to the closing function directly as a parameter) Best regards Jens Oehlschl?gel // C-code static void rindex_finalize(SEXP extPtr){ pINT ptr = R_ExternalPtrAddr(extPtr); if(ptr){ Free(ptr); Rprintf("finalized\n"); }else{ Rprintf("nothing to finalize\n"); } return; } SEXP rindex_open( SEXP Sn ){ int i,n = INTEGER(Sn)[0]; pINT ptr = Calloc(sizeof(INT)*n, INT); SEXP extPtr, ret; for (i=0;i<n;i++){ ptr...

...= as.integer(0))[-1] # skip handle } where "handle" was the result of a .Call to a routine which returned a SEXP which was the result of a R_MakeExternalPtr() call The "c" routine looked like: void groovyDevice_getDeviceInfo(SEXP handle, int *status) { groovyHandle *gh = R_ExternalPtrAddr(handle); *status = GroovyStatus(gh); } This all used to work fine. As of 2.15.0, I now get this: Warning message: In getDeviceInfo() : passing an object of type 'externalptr' to .C (arg 1) is deprecated Passing the same handle to a .Call() does [of course] work fine. I thought m...

...;createSession(attributes); void* temp = session; SEXP out = R_MakeExternalPtr(temp, R_NilValue, R_NilValue); return out; The following is how I try to retrieve the class object in a different C++ function called "soamSubmit", where sesCon is the externalPtr : void* temp = R_ExternalPtrAddr(sesCon); Session* sesPtr = reinterpret_cast<Session*>(temp); The error I get when trying to run the R function is : *** caught segfault *** address 0x3, cause 'memory not mapped' Traceback: 1: .Call("soamSubmit", counter, sesCon, final.script, packages) 2: soam...

...| (Windows, Rtools 3.4), same also on win-builder reports even more | issues, especially legacy Fortran (mainly Roger's #2 and #3), but also | | "warning: ISO C forbids conversion of object pointer to function pointer | type" | | The latter results from using pointers returned by R_ExternalPtrAddr() | for calling user-defined functions in DLLs, cf. the following thread | from the very beginning: | https://stat.ethz.ch/pipermail/r-devel/2004-September/030792.html | | What is now expected to do? | | 1. Is it really the intention to start a complete rewrite of all legacy | Fortran code? |...

...g 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); R_ClearExternalPtr(eptr); } SEXP h5R_allocate(SEXP size) { int i = INTEGER(size)[0]; char* vector = (char*) malloc(i*sizeof(char)); SEXP e_ptr = R_MakeExternalPtr(vector, R_NilValue, R_NilValue); R_RegisterCFinalizerEx(e_ptr, h5R_allocate_finalizer, TRU...

Hi Kurt, I have started to look into this, and I need some guidance about how to prioritize my repairs. There are basically 4 categories of warnings from gfortran?s pedantic critique of my packages: 1. Some errant tab characters it doesn?t like, 2. Too many or too few continue statements 3. Horrible (and obsolescent) arithmetic and computed gotos 4. undeclared doubles and dubious

...s)+2, sizeof(char)); tmp = Calloc(strlen(s)+2, char); *tmp = '-'; strcpy(tmp+1, s); objv[objc++] = Tcl_NewStringObj(tmp, -1); free(tmp); } if (!isNull(t = VECTOR_ELT(avec, i))) objv[objc++] = (Tcl_Obj *) R_ExternalPtrAddr(t); } and I can't see how tmp can be NULL at the free(), nor can I see it mattering if it is not set to NULL (notice that it goes out of scope with the for loop). -pd > On 7 Jun 2020, at 16:00 , Jeroen Ooms <jeroenooms at gmail.com> wrote: > > On Sun, Jun 7, 2020 at 3:...

...); > > *tmp = '-'; > > strcpy(tmp+1, s); > > objv[objc++] = Tcl_NewStringObj(tmp, -1); > > free(tmp); > > } > > if (!isNull(t = VECTOR_ELT(avec, i))) > > objv[objc++] = (Tcl_Obj *) R_ExternalPtrAddr(t); > > } > > > > and I can't see how tmp can be NULL at the free(), nor can I see it mattering if it is not set to NULL (notice that it goes out of scope with the for loop). > > Right. And the calloc->Calloc change doesn't look like an issue either > -- jus...

...hould only be used as part of an object with normal semantics, for example an attribute or an element of a list." So I've written up a workable C function as such: SEXP my_c_function(SEXP param) { SEXP temp = getAttrib(param, install("ptr_attribute")); void * ptr = R_ExternalPtrAddr(temp); ... // do useful things with ptr } I can pass my_c_function() an object with "normal" semantics (such as an integer vector), where the external pointer object is a parameter named "ptr_attribute". The function extracts the pointer object from param; i.e. this fun...

...hat GCC 4.9.3 (Windows, Rtools 3.4), same also on win-builder reports even more issues, especially legacy Fortran (mainly Roger's #2 and #3), but also "warning: ISO C forbids conversion of object pointer to function pointer type" The latter results from using pointers returned by R_ExternalPtrAddr() for calling user-defined functions in DLLs, cf. the following thread from the very beginning: https://stat.ethz.ch/pipermail/r-devel/2004-September/030792.html What is now expected to do? 1. Is it really the intention to start a complete rewrite of all legacy Fortran code? 2. Is there now...

...SET_VECTOR_ELT(mydata->ans, 0, mydata->R_a ); SET_VECTOR_ELT(mydata->ans, 1, mydata->R_b ); ... // all protects get unprotected before return // finalizer is registered as well return Rdata; Later on in read_my_data() I read the pointer: my_data_ptr *mydata = (my_data_ptr*) R_ExternalPtrAddr(Rdata); // and REAL(mydata->R_a) yields error since TYPEOF(mydata->R_a) is not REALSXP as it should be but RAWSXP for some reason // (sometimes it's STRSXP or INTSXP while it should always be REALSXP) // The error message says: // REAL() can only be applied to a 'numeric', not a...

...-'; >>>> strcpy(tmp+1, s); >>>> objv[objc++] = Tcl_NewStringObj(tmp, -1); >>>> free(tmp); >>>> } >>>> if (!isNull(t = VECTOR_ELT(avec, i))) >>>> objv[objc++] = (Tcl_Obj *) R_ExternalPtrAddr(t); >>>> } >>>> >>>> and I can't see how tmp can be NULL at the free(), nor can I see it mattering if it is not set to NULL (notice that it goes out of scope with the for loop). >>> >>> Right. And the calloc->Calloc change doesn't l...

...~foo(); fun(); } --------------------- C-wrapper: extern "C" SEXP R_foo_init() { foo* ptr= new foo(); SEXP res; PROTECT(res = R_MakeExternalPtr(ptr, R_NilValue, R_NilValue)); UNPROTECT(1); return res; } extern "C" SEXP R_foo_fun(SEXP obj) { foo *ptr= (foo *) R_ExternalPtrAddr(obj); ptr->fun(); return R_NilValue; } --------------------- R-wrapper: defineClass(className = "foo"); vtkObject$defineFields(ptr = "externalptr"); vtkObject$defineMethod( "initialize", function(){ ptr <- .Call("R_foo_init") } ); vtkObj...

I have some C data I want to pass back to R opaquely, and then back to C. I understand external pointers are the way to do so. I'm trying to find how they interact with garbage collection and object lifetime, and what I need to do so that the memory lives until the calling R process ends. Could anyone give me some pointers? I haven't found much documentation. An earlier message

...; *tmp = '-'; >>> strcpy(tmp+1, s); >>> objv[objc++] = Tcl_NewStringObj(tmp, -1); >>> free(tmp); >>> } >>> if (!isNull(t = VECTOR_ELT(avec, i))) >>> objv[objc++] = (Tcl_Obj *) R_ExternalPtrAddr(t); >>> } >>> >>> and I can't see how tmp can be NULL at the free(), nor can I see it mattering if it is not set to NULL (notice that it goes out of scope with the for loop). >> >> Right. And the calloc->Calloc change doesn't look like an issue...

Hello Apologies for cross-posting, the discussion should (if) go to R-devel, but I also want to reach the rcpp-devel people. My C++ class FOO is a module available through Rcpp, and it works fine and is -- so far -- bug free. With trying to further develop my R package, I thought it was a good idea to interface my C++ workhorse FOO with an S4 class Foo. After some long and not always insightful

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.

...tmp = Calloc(strlen(s)+2, char); > *tmp = '-'; > strcpy(tmp+1, s); > objv[objc++] = Tcl_NewStringObj(tmp, -1); > free(tmp); > } > if (!isNull(t = VECTOR_ELT(avec, i))) > objv[objc++] = (Tcl_Obj *) R_ExternalPtrAddr(t); > } > > and I can't see how tmp can be NULL at the free(), nor can I see it mattering if it is not set to NULL (notice that it goes out of scope with the for loop). Right. And the calloc->Calloc change doesn't look like an issue either -- just checking for a NULL. If th...