similar to: most robust way to call R API functions from a secondary thread

Stepan, Andreas gave a lot more thought into what you question in your reply. His question was how you can avoid what you where proposing and have proper threading under safe conditions. Having dealt with this before, I think Andreas' write up is pretty much the most complete analysis I have seen. I'd wait for Luke to chime in as the ultimate authority if he gets to it. The

Your analysis looks pretty complete to me and your solutions seems plausible. That said, I don't know that I would have the level of confidence yet that we haven't missed an important point that I would want before going down this route. Losing stack checking is risky; it might be eventually possible to provide some support for this to be handled via a thread-local variable. Ensuring

Hi Andreas, note that with the introduction of ALTREP, as far as I understand, calls as "simple" as DATAPTR can execute arbitrary code (R or native). Even without ALTREP, if you execute user-provided R code via Rf_eval and such on some custom thread, you may end up executing native code of some package, which may assume it is executed only from the R main thread. Could you (1)

I think it's also worth saying that some of these issues affect C code as well; e.g. this is not safe: FILE* f = fopen(...); Rf_eval(...); fclose(f); whereas the C++ equivalent would likely handle closing of the file in the destructor. In other words, I think many users just may not be cognizant of the fact that most R APIs can longjmp, and what that implies for cleanup of

The attached patch should solve the following problem: ssh-agent creates a temporary directory under /tmp with '600' permissions. The actual socket file is created in that dir using the default umask. That's no problem in U*X systems since nobody but the owner of the directory can read the socket file. Unfortunately, Windows has a user privilege called "Bypass traverse

Patch registers SIGTSTP hook where it sends reset terminal color control sequence using write and fsync. Handler is installed only if signal is not being ignored. Patch uses rl_free_line_state and rl_cleanup_after_signal to unhook readline from terminal, then it calls original TSTP handler using approach in URL below and again hooks readline using rl_reset_after_signal. Handling is based on code

Hello, I?m trying to leverage R_ToplevelExec to implement C level try/catch. The way it is implemented allows for running a function in a top level context. This context gets an empty handler stack, so either the function runs correctly or it jumps. When it jumps, it does not find a handler, so it jumps to the top level context. R does not allow me to call begin context and end context

tl;dr: we need better C++ tools and documentation. We collectively know more now with the rise of tools like rchk and improved documentation such as Tomas?s post. That?s a start, but it appears that there still is a lot of knowledge that would deserve to be promoted to actual documentation of best practices. I think it is important to not equate C++ as a language, and Rcpp. Also, C++ is not

Hello! This is my first post here. I came across the very same problem. It can be reproduced within modified tests/Embedding/RParseEval.c Actually this example has another issue, namely it doesn't wrap everything in R_ToplevelExec . This is a major show stopper for newcomers as that function is barely mentioned anywhere and longjmp into terminated setuploop function followed by R_suicide

I am trying to install Rpy to test it out as an R interface for a project that I am working on. However, I get the following error. Any clues as to what might be going on? I have alo tried RSPython, but I gave up due to errors. RSPython segfaults when started from R and gives an error message I can;t remember from python. Thanks, Brett >>> import rpy Traceback (most recent call

Dear r-devel folks, [if this is more appropriate for r-pkg-devel please let me know and I'll repost it over there ...] I'm writing to ask for help with some R/C++ integration idioms that are used in a package I'm maintaining, that are unfamilar to me, and that are now being flagged as problematic by Tomas Kalibera's 'rchk' machinery (https://github.com/kalibera/rchk);

I am compiling the Embedding examples in the tests directory and get an undefined reference. I include the make output as well as grep'd output of nm on libR.so and compiler and arch information. Do I have an improperly built R shared library or is there a problem with the Embedding tests or something else I am not seeing? Thanks for any help! George ost at

Thanks, that's really useful. One more question for you, or someone else here: const ArrayXd glmLink::linkFun(const ArrayXd& mu) const { return as<ArrayXd>(::Rf_eval(::Rf_lang2(as<SEXP>(d_linkFun), as<SEXP>(Rcpp::NumericVector(mu.data(), mu.data() + mu.size())) ), d_rho); } I guess I need that to read

First, thank you to Tomas for writing his recent post[0] on the R developer blog. It raised important issues in interfacing R's C API and C++ code. However I do _not_ think the conclusion reached in the post is helpful > don?t use C++ to interface with R There are now more than 1,600 packages on CRAN using C++, the time is long past when that type of warning is going to be useful to the

Hello, When using R_tryEval (from JRI in my case), is there a way to setup error recovery strategy and more generally calling handlers. From my reading of context.c, R_tryEval calls R_ToplevelExec which creates a context like this: begincontext(&thiscontext, CTXT_TOPLEVEL, R_NilValue, R_GlobalEnv, R_BaseEnv, R_NilValue, R_NilValue); so I guess what I am trying to do is add

Is there any way to distinguish between an error and a user interruption in R_tryEval? In both cases the ErrorOccurred argument is set to 1. For my application I need a different action in case of a SIGINT. >From the source code I infer that R_tryEval basically wraps eval in R_ToplevelExec, which returns TRUE if fun returns normally, FALSE if it results in a jump to top level. However both an

I look every now and then at RPy. It is not yet a Debian package as it had the odd problem here or there -- initially an Atlas interaction, currently something with long_jump() which cannot be found when R's dynamic library is loaded. [1] It is called R_eval.c: /* Abort the current R computation and signal a KeyboardInterrupt exception */ void interrupt_R(int signum) { interrupted = 1;

Hi , I tried to do the following . Before I execute the R script , i tried to clear the work space using rm(list = ls(all = TRUE)); . I get the following back trace . Its a huge backtrace , attached a part of it . Can anyone help why I get this ? #13 0x00002aaaaafd612f in Rf_eval (e=0x1448d68, rho=0x16c6780) at eval.c:399 #14 0x00002aaaaafdabf6 in Rf_applyClosure (call=0x1447108, op=0x1448f60,

Hi Simon, Widespread errors would have caught my earlier as the way that code is using only one initialization of the embedded R, is used quite a bit, and is covered by quite a few unit tests. This is the only situation I am aware of in which an error occurs. What is a "correct context", or initial context, the code should from ? Searching for "context" in the R-exts manual

Dear list, I am trying to embed R into a C++ program. After some tinkering, reading the documentation and browsing the source code I have this more or less working. A very very condensed and very simplified version of the code is included below. The program can create plots. However, after the plot is initially drawn it is no longer updated. When scaling or updating the plot the window becomes