similar to: Problem with new("externalptr")

Greetings. 2.15.0 added this behavior http://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2012/03/29#n2012-03-29 o Passing R objects other than atomic vectors, functions, lists and environments to .C() is now deprecated and will give a warning. Most cases (especially NULL) are actually coding errors. NULL will be disallowed in future. This seems to make sense,

Dear all, I am confused about the inconsistent behaviors of `@<-` operator when used in different ways. Consider the following example: library(inline) # Function to generate an externalptr object with random address new_extptr <- cfunction(c(), ' SEXP val = PROTECT(ScalarLogical(1)); SEXP out = PROTECT(R_MakeExternalPtr(&val, R_NilValue, val)); UNPROTECT(2);

Given an externalptr object 'pool' which protects an R object 'prot': # SEXP prot = (a dynamically updated list with handles) SEXP pool = R_MakeExternalPtr(p, R_NilValue, prot); R_RegisterCFinalizerEx(pool, fin_pool, TRUE); WRE explains that 'prot' remains in existence as long as 'pool' is around. Does this also mean 'prot' still exists when the

Hi all, I've been writing a package and I've run into a problem that I'm unsure how to solve. I am looking to pass a C++ class object to R so that it may be passed back to another C++ function later on to be used. I'm quite new to R and this is my first time writing a package, so I hope you can bear with me. The following is how I create the class and use

On Sun, 18 Mar 2018, Jialin Ma wrote: > Dear all, > > I am confused about the inconsistent behaviors of `@<-` operator when > used in different ways. Consider the following example: > > library(inline) > > # Function to generate an externalptr object with random address > new_extptr <- cfunction(c(), ' > SEXP val = PROTECT(ScalarLogical(1)); >

Hi, I am using swig to build a wrapper for an c-function to use it in R. I would like to define a generic function, which gives back a void pointer. On the R side, I know what this pointer is pointing to, whether it is an integer or an string, or something else... but I need to somehow reinterpret the resulting "externalptr" into another form... a function that looks like the

Is the following expected behavior? > mkext <- inline::cfunction(language="C", body='return R_MakeExternalPtr(NULL, install("tag"), R_NilValue);') > x <- mkext() > y <- x > attr(y, "foo") <- "bar" > attributes(x) $foo [1] "bar" I would expect that modifying y's attributes should not affect x. [Tested

Hello I am trying to wrap some C++ classes into R. (1) Comparing the OOP and methods packages, I have came to this conclusion that OOP works much better for this wrapper -- please correct me if I am wrong. One question is why this useful package (OOP) is not included in the official release of R? (2) Choosing the OOP package way, I have carried out the following steps to wrap the C++

Hi all, I found that the finalizer of the externalPtr is not called when R is quitting. However, manually calling GC() works fine. This behavior is observed on devel R 2020-04-02 r78142 on Win and R 3.6.3 on Ubuntu. I make a reproducible package here: https://github.com/Jiefei-Wang/example Here is the detail of how to reproduce the problem, I create a temporary file in the package root path and

Dear R friends. After having some troubles learning how to create a ffdf object, now I find myself having problems saving it. this is the data i´d like to save: str(DATA) List of 3 $ virtual: 'data.frame': 6 obs. of 7 variables: .. $ VirtualVmode : chr "double" "short" "integer" "integer" ... .. $ AsIs : logi FALSE FALSE FALSE

See R_RegisterCFinalizerEx() and set onexit to nonzero. Here: https://github.com/wch/r-source/blob/9353ddfa8d30069ad8975e0364307d710f2488d5/src/include/Rinternals.h#L1279-L1280 Gabor On Fri, Apr 3, 2020 at 1:56 PM Wang Jiefei <szwjf08 at gmail.com> wrote: > > Hi all, > > I found that the finalizer of the externalPtr is not called when R is > quitting. However, manually

Hi, I want to read a text file into R with .Call(). So I define some NEW_CHARACTER() to store the chracters read and use SET_STRING_ELT to fill the elements. e.g. PROTECT(qNames = NEW_CHARACTER(10000)); char *foo; // This foo holds the string I want. while(foo = readLine(FN)){ SET_STRING_ELT(qNames, i, mkChar(foo))); } In this way, I can get the desired character from qNames. The only problem

Use R_RegisterFinalizerEx in your C code. See https://cran.r-project.org/doc/manuals/r-release/R-exts.html#External-pointers-and-weak-references This still gives you only "best effort"; for anything stronger you would need a different approach. In general, finalizers should only be used as a backstop, not as a primary resource management tool (in R or any other garbage-collected

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

Is there a 'proper' way of checking if cluster is active. For example, I create a cluster called .PBcluster > str(.PBcluster) List of 4 $ :List of 3 ..$ con :Classes 'sockconn', 'connection' atomic [1:1] 3 .. .. ..- attr(*, "conn_id")=<externalptr> ..$ host: chr "localhost" ..$ rank: int 1 ..- attr(*, "class")= chr

I am out of my league with this question. The following code starts the java imaging program ImageJ from within R, and displays an image (assuming ImageJ is installed on your computer). library(RImageJ) img <- IJ$openImage( file.choose() ) #pick an available .tif file img$show() # make the image object visible # An image is now displayed # find out about the objects involved >

Hi, I'm using R_MakeExternalPtr() to store handles to (COM) objects in a SEXP. The code basically is sexp = R_MakeExternalPtr(handle,R_NilValue,R_NilValue); R_RegisterCFinalizerEx(...); After creating the sexp, LENGTH(sexp) returns some quite large integer value. It seems like an "unitialized" value. Can I safely assume, that an SEXP of type EXTPTRSXP can only contain a single

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

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

Dear all, I do not completely understand following behaviour : > con <- file("test.txt") > isOpen(con) [1] FALSE > open(con) > isOpen(con) [1] TRUE > close(con) > isOpen(con) Error in isOpen(con) : invalid connection > str(con) Classes 'file', 'connection' atomic [1:1] 3 ..- attr(*, "conn_id")=<externalptr> Why do I get an