similar to: potential bug in attribute handling for externalptr

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

Hi, It seems that new("externalptr") is always returning the same instance, and not a new one as one would expect from a call to new(). Of course this is hard to observe: > new("externalptr") <pointer: (nil)> > new("externalptr") <pointer: (nil)> since not a lot of details are displayed. For example, it's easy to see that 2

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,

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

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

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, 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

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

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

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

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

On 11 May 2017 at 12:16, Patrick Perry wrote: | I've done a bit more investigation into this issue. Here is my current | understanding of the situation: | | 1. I have a package on CRAN (corpus-0.3.1) that passes tests on all | platforms except for Linux. | 2. My package defines a C function, "xrealloc", for internal use. | 3. The libreadline library that R links to defines a

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

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

Hi, I’ve stumbled across something curious with the Relase_40 I have built here: I tried to build for aarch64-apple-iphoneos, but ended up getting ELF objects $ clang -target aarch64-apple-iphoneos -c tmp.ll -o tmp.o warning: overriding the module target triple with aarch64-apple-iphoneos [-Woverride-module] 1 warning generated. bin $ file tmp.o tmp.o: ELF 64-bit LSB relocatable, ARM aarch64,

Dear Developers, I've been struggling through writing R extension in C. I've been using an external pointer to store my data (please see sample below). I encountered a very weird erroneous behaviour: when I tried to use my external pointer to a structure holding several types of data, including SEXPs, I discovered that SEXPs change their types between returning from initialization

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

On Thu, 25 Apr 2024 14:45:04 +0200 Jeroen Ooms <jeroenooms at gmail.com> wrote: > Thoughts? How verboten would it be to create an empty external pointer object, add it to the preserved list, and set an on-exit finalizer to clean up the curl multi-handle? As far as I can tell, the internet module is not supposed to be unloaded, so this would not introduce an opportunity to jump to an

Dear R .Call() insiders, Can someone enlighten me how to properly finalize external pointers in C code (R-2.5.1 win)? What is the relation between R_ClearExternalPtr and the finalizer set in R_RegisterCFinalizer? I succeeded registering a finalizer that works when an R object containing an external pointer is garbage collected. However, I have some difficulties figuring out how to do that in an