similar to: A 'true' R-wrapper for C++ classes

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

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

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

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

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

On 4/25/24 17:01, Ivan Krylov via R-devel wrote: > 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 >

I have encountered a strange behavior of the str function - it seems to modify the object that is displayed. Probably I'm using something unsupported (objects consisting just of an external reference), but still I'm curious as of why this happens. I create (in C code) EXTPTRSXP and associate a class to it via SET_CLASS. Such objects works fine until it's passed to str as the

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

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

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

Jeroen, I agree that it may be useful to have some kind of "finally"-like infrastructure. However, in the use cases you list there are already ways to do that - the same way that R_alloc uses. First, you don't need to call UNPROTECT - the whole point is that the protection stack is automatically popped in case of an abnormal termination. That is precisely how memory leaks are

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

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

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,

I've been inspired to look at the R source code by some strange timing results that I wrote about on my blog at radfordneal.wordpress.com (see the posts on "Speeding up parentheses..." and "Two surprising things...". I discovered that the strange speed advantage of curly brackets over parentheses is partially explained by an inefficiency in the evalList and

I found a bug in one of the fourteen speed patches I posted, namely in patch-vec-subset. I've fixed this (I now see one does need to duplicate index vectors sometimes, though one can avoid it most of the time). I also split this patch in two, since it really has two different and independent parts. The patch-vec-subset patch now has only some straightforward (locally-checkable) speedups for

Hello. I've been trying to wrap up the R_NilValue into OCaml-R. I nevertheless get a segfault. As I gathered, R_NilValue is declared in Rinternals.h: > /* Special Values */ > LibExtern SEXP R_NilValue; /* The nil object */ > LibExtern SEXP R_UnboundValue; /* Unbound marker */ > LibExtern SEXP R_MissingArg; /* Missing argument marker */ So, in my r_data.c

Thanks, Gabriel. On Mon, 2020-09-07 at 14:38 -0700, Gabriel Becker wrote: > I cannot speak to initial intent, perhaps others can. I can say that > there is at least one place where the difference between R_NilValue > and NULL is very important as of right now. The current design of the > ALTREP framework contract expects ALTREP methods that return a SEXP > to return C NULL when