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

[Byron Ellis]

On Oct 20, 2005, at 9:21 AM, 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.
>


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