[Rd] Question on parsing R code from C

Simon Urbanek simon.urbanek at r-project.org
Wed Nov 9 02:28:41 CET 2011

On Nov 8, 2011, at 6:53 PM, KR wrote:

> Simon Urbanek <simon.urbanek <at> r-project.org> writes:
>> Except that you don't know what are macros, inlined functions and actual 
> functions. If you are careful you
>> can possibly fall back to external functions but, obviously, your code will be 
> less efficient. I would
>> still prefer including Rinternals.h - you must have a *really* good reason to 
> not do so ;)
> Hmmm yes there are good motives (I am not completely unreasonable, yet :P) but I 
> could probably cope with it if there is no other way.
> Regarding the rest of the e-mail, please let me be clearer on what my goal is. I 
> would need a function to create and initialize an R state, a function to close 
> the state, and a function (R_ParseVector?) that takes as input the R state and a 
> string (containing R code), evaluates the code and return an "error code" 
> (error, incomplete, done) plus (eventually) a string containing the output of 
> the computation.

That itself is quite simple - there is an example in R-ext 5.12.

> In my application I do not have any UI elements (it's console based), but I 
> would like calls to plot in R (and other functions using the graphic device) to 
> function as they would under R.exe (on windows), i.e. have persistent windows 
> popped up which you can resize ecc ecc. I naively thought that these graphic 
> capabilities came automatically with the R_ParseVector via some threading 
> techniques.

R_ParseVector doesn't evaluate anything so it's innocent here. Rf_eval() will run the actual code and it will create a window (if you use an interactive device) but the window won't respond to anything, because the moment Rf_eval() returns R has lost control and everything is up to your code. R is not threaded* (and the R API is not thread-safe) so the only way to continue is for you to run the run loop, i.e. you have to return control back to R so it can process events. 

Now the hard part is that running the event loop is system-dependent. You will see it discussed in R-ext 8.1 (unix) and 8.2 (Windows).


* - on unix R itself doesn't use threads because it's problematic (other than OpenMP); the Windows Rgui actually uses threads cautiously so that the UI stays responsive while R is busy, but this is not done by R but the GUI. Similarly R.app GUI uses threads to monitor I/O pipes but the system loop is meshed into R.

More information about the R-devel mailing list