[R-gui] [Rd] R GUI considerations (was: R, Wine, and multi-threadedness)

[Philippe Grosjean]

Walter,

With the various answers you got to your "simple" question, you notice 
that there are several ways to feed commands into R and retrieve the 
results. If you just need to occasionnally feed commands that does not 
take a long time to process, and can afford to frozen your GUI during 
those calculations, this is a pretty simple way to solve the problem.

Things get more complicated when you add features to your GUI that 
require reintrancy (execute another command in R while the current one 
is not completed), asynchronous treatment (your GUI is not frozen and is 
not just "waiting for the answer" during long R calculations -well, a 
multithreade app using synchronous treatment works here too-), 
cancellation of long R treatments (like ESC under RGui, or Ctrl-C on the 
console), etc... A serious GUI needs all that, and its makes 
communication between R and your GUI more complex than just feeding 
commands and waiting for results.

One example: with SciViews-R, you have an object explorer that updates 
automatically, you have "calltips" (the syntax of a function is 
displayed in a tip when you enter something like 'myfunction('), you 
have completion lists, etc... All these features require the execution 
of R commands at any time, even if R is busy processing a long 
calculation. To get these features, I had to write a little bit more 
complex communication system with R. So, in practice, things are not so 
simple!

I wonder how you can add all these features to a GUI that use R just as 
an occasional backend calculator.
- How your GUI would know about the syntax of all functions (including 
your own custom ones) without asking the info to R?
- How the GUI would know what variables to propose in a list in a dialog 
box without asking R using something like 'ls()', or 'names(mydataframe)'?
- How to implement an object explorer that lists variables in the 
various environments, give some details about these variables, propose a 
contextual menu (that is, a list of function depending on the class of 
the object, the environment, the context of your analysis, ...), etc... 
without using a lot of reintrant communication with R?

Best,

Philippe Grosjean

Duncan Murdoch wrote:
> On 10/20/2005 12:21 PM, Walter Johnston wrote:
> 
> 
>>And the question:
>>
>>Is there a "simple" way (e.g. some socket based mechanism) to
>>feed commands into R and retrieve the results of those commands?
>> This would require that I program the sequence of commands I
>>want to use (or a means to generate them) and then be able parse
>>the resulting structure - I understand. But it would also allow
>>separation of the computation, the "statistical reasoning", and
>>the UI into (potentially) separate units which would not even
>>need to be on the same machine to inter-operate.  If there is a
>>reasonable way to do this, please tell me.
> 
> 
> Take a look at the Writing R Extensions manual.  There are several 
> levels at which you can interact with R.  The simplest is to act as a 
> console, feeding text in and getting text out.  If you actually want to 
> work with things as binary objects you'll need lower level access.  It's 
> not that bad if you just want to write a function that gets passed R 
> objects.  I don't think it be called "simple" if you want to do away 
> with the console completely, and start working directly with the evaluator.
> 
> Duncan Murdoch
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
>