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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
