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.

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to