similar to: R_PreserveObject, R_ReleaseObject : reference counting needed ?

[Disclaimer: what is below reflects my understanding from reading the R source, others will correct where deemed necessary] On 1/2/10 12:00 PM, r-devel-request at r-project.org wrote: > > Hello, > > We are currently making lots of changes to Rcpp (see the open Rcpp > mailing list if interested [1] in the details). > > We are now using [2] R_PreserveObject and R_ReleaseObject

Hello. This is my first post to the list, so first I'd like to thank everybody for making and mantaining such a great product as R. I'm writting a native binding to R from Dolphin Smalltalk. I've followed up the examples of the documentation showing how to run R embedded, and I got it partially working. However, I have a problem with the reference handling of the R objects.

Hello, This is a question that probably reveals my lack of understanding. In a C function (call it cfunc), i created a SEXP, called S, and then called R_PreserveObject on S. I returned the SEXP to the calling R function (call it rfunc). Note, I didn't call R_ReleaseObject on S. v <- .Call("cfunc") So, are the following statements correct 1. S is 'doubly' protected

Dear list, While trying to identify the root of a problem I am having with garbage collected variables, I have come across the following oddity: depending on whether --verbose is set or not, I obtain different results. I have made a small standalone example to demonstrate it. The example is very artificial, but I had a hard time reproducing reliably the problem. So when I do: (the content of

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

Hello, I've been using R embedded in PL/R (R procedural language handler for PostgreSQL, http://www.joeconway.com/plr/) very successfully for several months now. A sincere "thank you" goes to the R development team for such a great product. I have a question I'm hoping someone here can help me with. In order to get the required functionality out of PL/R, I've had to

Apologies, I am resending this because my emails seem to go in HTML form. Hello, This is a question that probably reveals my lack of understanding. In a C function (call it cfunc), i created a SEXP, called S, and then called R_PreserveObject on S. I returned the SEXP to the calling R function (call it rfunc). Note, I didn't call R_ReleaseObject on S. v <- .Call("cfunc") So,

Apologies, I am resending this because my emails seem to go in HTML form. (I haven't as yet figured gmail web interface) Hello, This is a question that probably reveals my lack of understanding. In a C function (call it cfunc), i created a SEXP, called S, and then called R_PreserveObject on S. I returned the SEXP to the calling R function (call it rfunc). Note, I didn't call

Here's an update of my rawConnection() implementation. In addition to providing a raw version of textConnection(), this fixes two existing issues with textConnection(): one is that the current textConnection() implementation carries around unprotected SEXP pointers, the other is a performance problem due to prolific copying of the output buffer as output is accumulated line by line. This new

Hi, I am trying to figure a way to allocate a string SEXP so that gc() won't ever collect it. Here is a little bit of a background. Suppose I want to write a .Call-callable function that upon each call returns the same value, say mkChar("foo"): SEXP getFoo() { return mkChar("foo"); } The above implementation doesn't take advantage of the fact that

Hello, I submit a patch for review that implements code coverage tracing in the R interpreter. It records the lines that are actually executed and their associated frequency for which srcref information is available. I perfectly understands that this patch will not make its way inside R as it is, that they are many concerns of stability, compatibility, maintenance and so on. I would like to have

Hi! We?ve recently come across an example where a package (minqa) creates an Rcpp Function object in a static variable. This causes R_ReleaseObject to be called by the destructor at a very late point in time - as part of the system exit function: static Function cf("c"); I?m wondering if that is considered to be ?safe?? Is the R engine supposed to stay in a state where calls to API

>>> On Nov 28, 2009, at 7:50 PM, Guillaume Yziquel wrote: >>> >>> FWIW what I think you should be really looking at is >>> R_PreserveObject/R_ReleaseObject. > > OK. Thanks. >>> I would suggest looking at the many other R embeddings in other >>> languages that already exist since I don't think you approach is >>> very viable

I'd like to raise this again now that 4.4 is out. Below is a more complete patch which includes a function to properly cleanup libcurl when R quits. Implementing this is a little tricky because libcurl is a separate "module" in R, perhaps there is a better way, but this works: view: https://github.com/r-devel/r-svn/pull/166/files patch:

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 >

Martin, Well, thanks for jumping in! We need all the help we can get ;) I changed the execute bit as you suggested and recompiled, no luck, still the same error message. Below is the output you wanted me to look at, its a bit beyond me so I include both a brief grep summary and then the whole enchilada. I do note that my output is different from yours, but I'm not sure how to interpret. I

Martin, Well, thanks for jumping in! We need all the help we can get ;) I changed the execute bit as you suggested and recompiled, no luck, still the same error message. Below is the output you wanted me to look at, its a bit beyond me so I include both a brief grep summary and then the whole enchilada. I do note that my output is different from yours, but I'm not sure how to interpret. I

Calling R_ReleaseObject in a C++ destructor is not reliable - it can be bypassed by a non-local return, such as an error. Generally in R one cannot use C++ destructors reliably for anything that the R runtime wouldn't do on its own in case of a non-local return. A destructor that calls just UNPROTECT, in a way that balances out the protection stack (e.g. Rcpp Shield), is safe because R

Hello Group, I could use an advice on how SEXP handles work. My aim is to implement a system where I initially set a few global variables that are used for communication between C and R code. Then I do some work with R code and periodically call a function of my own that will update the system state. Such a design is useful for many purposes (for GUIs to name one). I am not entirely sure that R

Hello everyone, I've just attempted to build R-1.4 on Compaq Tru64 (I'll enclose the text from bug.report() from R-1.3.1 at the end.) The relevant part of the log is below. Any ideas? gcc -shared -o methods.so do_substitute_direct.o methods_list_dispatch.o method_meta_data.o slot.o -L/usr/local/lib /usr/ucb/ld: Warning: Unresolved: TYPEOF Rf_error Rf_protect Rf_substitute