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 ([EMAIL PROTECTED]) "Oook" -- The Librarian ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
