search for: r_releaseobject

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 to manage garbage collection instead of the PROTECT/UNPROTECT dance. This seems to work well, but I was wondering if there was documentation about it. In particular, if we preserve the same SEXP twice (or more), should we implement some sort of reference counting ? Reading the source (below, f...

...rs 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 to manage > garbage collection instead of the PROTECT/UNPROTECT dance. This seems to > work well, but I was wondering if there was documentation about it. The most precise technical documentation is in memory.c PROTECT is an alias for Rf_protect, itself an alias for SEXP protect(SEXP s); and...

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 from the GC by being associated both with 'v' and because it has been added to the precious list (via a call to R_PreserveObject without ReleaseObject being called) 2. I...

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 functions are valid, even after it has shut down?...

...a numerical vector "x" and "preserve it" * 2- make call "list(x)" * 3- return "x" to R */ SEXP x_R; int i; int n = INTEGER(n_R)[0]; /* Create a numerical vector "x_R" */ for (i=0; i<n; i++) { x_R = createObject(); R_ReleaseObject(x_R); printObject(x_R); R_gc(); } x_R = createObject(); printObject(x_R); R_gc(); R_ReleaseObject(x_R); Rprintf("Returning 'x' at %p\n", x_R); Rprintf(" (first element is %d)\n", REAL(x_R)[0]); return x_R; }

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

...y 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, are the following statements correct 1. S is 'doubly' protected from the GC by being associated both with 'v' and because it has been added to the precious list (via a call to R_PreserveObject without ReleaseObject being called) 2. I...

...s 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 R_ReleaseObject on S. v <- .Call("cfunc") So, are the following statements correct 1. S is 'doubly' protected from the GC by being associated both with 'v' and because it has been added to the precious list (via a call to R_PreserveObject without ReleaseObject being called) 2. I...

...I have a problem with the reference handling of the R objects. I've followed this strategy: every time I call a function in R and it answers me a SEXP, I called R_PreserveObject(sexp), and wrap it with a Smalltalk object. Whenever the Smalltalk object dies, I release the R object by calling R_ReleaseObject(sexp). This seems to handle well the life cycle, but makes the running process to use a growing and a never ending amount of memory. Actually, after experimenting a while, I isolated the problem to iterate over a loop which all it does is create an expresion for a number, call PreserveObject and...

...define PARSE_INCOMPLETE 2 #define PARSE_ERROR 3 #define PARSE_EOF 4 ----------------------------------------------------------- From non-exported header file ${R_HOME}/src/include/Defn.h ----------------------------------------------------------- extern void R_PreserveObject(SEXP); extern void R_ReleaseObject(SEXP); Use: ------------- The first time a PL/R function is called, the R function is built and parsed using R_ParseVector(), then cached for subsequent calls. Without R_PreserveObject() garbage collection destroys the object while PL/R is still trying to use it. R_ReleaseObject() is needed to...

...gIsActive(this->namesymbol, this->venv)) { + PROTECT(rm = lang2(install("rm"), this->namesymbol)); + eval(rm, this->venv); UNPROTECT(1); } - SET_VECTOR_ELT(OutTextData, idx, R_NilValue); + defineVar(this->namesymbol, tmp, this->venv); + UNPROTECT(1); + R_ReleaseObject(this->venv); + R_ReleaseObject(this->data); } static void outtext_destroy(Rconnection con) @@ -1795,6 +1822,17 @@ free(this->lastline); free(this); } +static void outtext_grow(Routtextconn this, int need) +{ + SEXP tmp = this->data; + int len = length(tmp); + if...

...countered s.t L >=nb_lines, the vector will be extended + * to L * growth_rate + */ +void do_Rcov_start(int nb_lines, double growth_rate) +{ + SEXP sexp; + + if (growth_rate < 1.1) + growth_rate = 1.1; + + if (R_Code_Coverage) return; + R_Code_Coverage = 1; + if (R_Cov_freqs_hash != NULL) + R_ReleaseObject(R_Cov_freqs_hash); + + /* put the params nb_lines and growth_rate as hidden vars of the hashed env */ + R_Cov_freqs_hash = R_NewHashedEnv(R_NilValue, ScalarInteger(0)); + PROTECT(sexp = ScalarInteger(nb_lines)); + defineVar(install(".nb_lines"), sexp, R_Cov_freqs_hash); + + PROTECT(sexp =...

>>> 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 (but I think I expressed that already before). > > Lisp - the only thing I've se...

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:

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

...nalPtrAddr U R_ExternalPtrTag U R_GlobalEnv U R_MakeExternalPtr U R_NaInt U R_NamesSymbol U R_NilValue U R_PreserveObject U R_RegisterCFinalizer U R_ReleaseObject U R_alloc 0000000000003a90 T R_base64_decode 0000000000003910 T R_base64_encode 0000000000005060 T R_call_R_write_function 0000000000003bc0 T R_check_bits 00000000000047f0 T R_curlMultiPerform 0000000000004db0 T R_curl_BinaryData_free 0000000000004c90 T R_curl_BinaryData_new 000000...

...nalPtrAddr U R_ExternalPtrTag U R_GlobalEnv U R_MakeExternalPtr U R_NaInt U R_NamesSymbol U R_NilValue U R_PreserveObject U R_RegisterCFinalizer U R_ReleaseObject U R_alloc 0000000000003a90 T R_base64_decode 0000000000003910 T R_base64_encode 0000000000005060 T R_call_R_write_function 0000000000003bc0 T R_check_bits 00000000000047f0 T R_curlMultiPerform 0000000000004db0 T R_curl_BinaryData_free 0000000000004c90 T R_curl_BinaryData_new 000000...