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

Walter Johnston <walterj at ureach.com> wrote on 10/20/2005 12:21:09 PM:

A couple of non-flame comments and a question -

(1) I have used Smalltalk in various forms and recommend it
highly as an environment (try Squeak for a free implementation);
it is the origin of the model-view-controller paradigm for
interaction with a GUI. Tcl/Tk is also nice with its
event-driven model.

(2) DON'T keep re-implementing the same statistical algorithms
all over the place! Putting together software that can be
trusted is non-trivial - if you want to add to the available
resources I applaud you for it, but ADDing is not simply
translating to another language (though, if the "old" language
is no longer available or supported there are good reasons to do
so. :-) I use a package to accomplish something and I need to
trust the output from that package. I don't look for a "swiss
army knife" but rather a package that does what I need and does
it well (though I prefer packages that have more functionality).

(3) I like R because of the model which returns results in
"objects" (though, as a Smalltalker, I don't see much OO in the
language - maybe I missed something).

I agree with you here, and that is the reason why I disagree somewhat with
your second point.  If you have C code that implements statistical
algorithms and/or structures, and you want to use it in Smalltalk, it is
usually a good idea to write wrapper classes that put an object-oriented
face on the procedural code.  This is particularly true if you hope to
reuse the code.  You want to make the interface look and feel like
Smalltalk to reduce the cognitive dissonance of whoever is using the
wrapped code.  But as an experienced Smalltalker, I'm sure you already know
this.

(4) AI seemed to make more demonstrable progress when they
started separting the reasoning mechanism from the rules and
data (as in the old "expert systems").

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.

Thanks.

Walter Johnston

A couple of my VisualWorks apps communicate via sockets with R.  I am
sending the code to Walter via private email.  If anyone else wants it,
just ask.

Jeff

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

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.

See ?make.socket for R's socket routines.  Also in addition to the
socket routines in R itself, the tcltk package supports sockets
and those can be used even if you don't intend to use the tk user
interface.  The rpad package and the svSocket package both make
use of that.

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.

Yes, we had this discussion over two years ago:

https://stat.ethz.ch/pipermail/r-sig-gui/2003-April/000102.html

What StatPaper and RKWard do is start up a child R process that  
enters a server mode for exchanging information. StatPaper managed to  
pull off transmitting both text and graphics to render on the client  
side via OpenMath, which worked pretty damn well except for a couple  
of things:

1) Ideally I'd prefer to be running in a "kernel mode" rather than  
loading up an R packages. I don't recall exactly what the problem  
was, but I seem to recall weird things would happen occasionally.  
These days it would be pretty easy to implement a different front end  
that passed everything through an OpenMath socket (it uses UNIX or  
TCP sockets) but otherwise behaved as a Console. This is more or less  
analogous to what Mathematica does. Essentially an extension of the  
ESS mode.  R KERNEL anyone?

2) As was mentioned a couple of days in a different thread, extending  
the idea of I/O streams to event streams would be a nice thing. For  
example, instead of fixed-field formatting a table for your ANOVA you  
would actually "print" a table and leave the rendering of that table  
up to the front end. You could do this now by changing the print  
generic for everything, but doing it at the connection level seems  
somehow nicer. It also means that you can tell errors from output,  
which is a nice thing to have (StatPaper did this by wrapping  
everything in a "try" block. Warnings were a little tougher though)

3) StatPaper tended to bog down a bit during complex graphics  
(scatterplot of 100,000 points or something) because it had to  
serialize everything over the write and did so by mimicking R's  
internal graphics. I'm told that this actually worked quite well on  
dual processor machines, but on my iBook it was a bit slow.


---
Byron Ellis (ellis at stat.harvard.edu)
"Oook" -- The Librarian

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

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