[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).
Cheers,
Simon
* - 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