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
