similar to: R-devel Digest, Vol 83, Issue 2

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

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

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

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

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

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

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

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

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

Hi, Starting with ordinary vectors, so we know what to expect: > mapply(function(x, y) {x * y}, 101:106, rep(1:3, 2)) [1] 101 204 309 104 210 318 > mapply(function(x, y) {x * y}, 101:106, 1:3) [1] 101 204 309 104 210 318 Now with an S4 object: setClass("A", representation(aa="integer")) a <- new("A", aa=101:106) > length(a)

Hi, Why can't I pass an expression to `within' by way of textual input to the 'parse' function? e.g., > x <- data.frame(a=1:5,b=LETTERS[1:5]) > x a b 1 1 A 2 2 B 3 3 C 4 4 D 5 5 E > within(x, parse(text="a<-a*10; b<-2:6")) a b 1 1 A 2 2 B 3 3 C 4 4 D 5 5 E > within(x, parse(text="a<-a*10; b<-2:6")[[1]]) a b 1 1 A 2 2 B 3

Dear list, I am trying to implement a publish-subscribe mechanism in for an embedded R interpreter. But somehow my registered closures seem to get collected by the GC, even though I have protected them. I have reducted my code to the following sample. Sorry if it is a little verbose. The first couple of call of calls still work, but at some point one of the callbacks (callback1 in my