From simon.urbanek at r-project.org  Wed Nov  9 02:28:41 2011
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Tue, 8 Nov 2011 20:28:41 -0500
Subject: [Rd] Question on parsing R code from C
In-Reply-To: <loom.20111109T001139-68@post.gmane.org>
References: <loom.20111108T203022-872@post.gmane.org>
	<9465BE63-EA88-4BE2-8D1C-9E33BE8AA45D@r-project.org>
	<loom.20111108T224700-655@post.gmane.org>
	<3D4F776D-4D5D-4C39-90B3-12DF09C5C6BA@r-project.org>
	<loom.20111109T001139-68@post.gmane.org>
Message-ID: <AF0744B1-C119-4BF1-99D0-9DBA31E734F9@r-project.org>


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.



[Rd] Question on parsing R code from C
Simon Urbanek