Skip to content

[R-gui] Interfaces between GUIs and R

10 messages · Byron Ellis, Thomas Friedrichsmeier, Duncan Murdoch +2 more

Original
Byron Ellis
# 
Hi folks, this is a question for all you GUI developers out there 
though, in particular, to those who work on SciViews and RKward (though 
anyone else is certainly welcome to chime in). Presently, my StatPaper 
app (which will have a website soon, I've just been busy this week) and 
AFAIK RKward employ a "kernel"-type interaction method (SciViews 
mentions a kernel, but I haven't been able to test it to see how it 
works) with R, that is R itself runs as a separate process and 
communication takes place over either the STDIN/STDOUT associated with 
the process or through some other means (say, UNIX sockets).  This 
works fine if we're just passing text back and forth, but when we want 
to start passing objects or graphics device information things start to 
do downhill pretty quickly.

My question: Is there any interest in developing a general kernel 
interaction protocol for R GUIs? This would most likely include the 
following:
	* Representation of data objects
	* Execution of R statements
	* Returning graphics of the kernel link
	* ???

Recently, I've been looking at the OpenMath protocol 
(http://www.openmath.org) for use in StatPaper and it seems fairly 
simple and robust. It bears a great deal of resemblance to the MathLink 
protocol employed by Mathematica. At the moment I think this entire 
thing could be done as an R package, possibly using the REventLoop 
mechanism for the server (though I don't know that it would be 
necessary) and also providing client access so that two R installations 
could communicate (I know that Rpvm and Rmpi already exist, though they 
have a somewhat different goal) in a standard fashion if desired.


Byron Ellis (bellis@hsph.harvard.edu)
"Oook" - The Librarian
Philippe GROSJEAN
# 
Hi Byron,

Indeed, yes, SciViews uses --ess mode of R with redirection of stdin and
stdout in RTerm.exe... but it provides even much more, including control of
the native Graph devices (using Windows API, which is probably difficult to
transpose to Unix/Linux). The SciViews plugs offers also some control over
child windows of the R process, like tcl/tk, Java, RGL,... windows/dialog
boxes. Functions to exchange matrices are planned, but not finalized yet.

By the way, you say that you were not able to test SciViews. Is it because
you have not PC with Windows, or because SciViews did not install correctly
on your test machine? If it is the second answer, please, give me some
feedback.

There is a COM server for R by Thomas Baier that offers a different way to
connect to R, and proposes a Graph device and direct matrices exchange.
However, you should be aware of a big difference between the SciViews R plug
(which is another COM server), and Thomas Baier's R COM server: the first
one uses asynchronous communication while the second one uses synchronous
communication. This has a major impact on what you can do with them. Here is
quick summary of differences:

				R COM Server	SciViews R Plug
communication		synchronous		asynchronous
client implementation	easy (5 methods)	more difficult (callbacks,...)
speed of execution	++			+
interruptible calc	no			yes
friezes the client(*)	yes			no
concurrent kernels(**)	no			yes

(*)  A single threaded client must wait for the completion of the
calculation with synchronous evaluation, while it can process other code
during evaluation with an asynchronous evaluation
(**) As a consequence, an asynchronous evaluation allows simultaneous
evaluation in different kernels (some kind of parallelization), while with a
synchronous evaluation one can connect to several kernels, but must
serialize evaluations in these different kernels.

As a conclusion, I consider R COM Server as a fast and simple interface to
R, but it has some limitations, like client friezing, uninterruptible
calculations, and no concurrent evaluations in differents kernels that makes
it less suitable for a complete GUI client. The SciViews R Plug is more
designed towards this goal.

There are many, many other ways to connect to R from a GUI client (see
OmegaHat project, for instance). Simon Urbanek develops also a Rserver based
on TCP/IP (http://stats.math.uni-augsburg.de/Rserve/), which is in this
respect closer to MathLink.

Concerning MathLink, yes, it is a nice interface for calculation kernels. I
am working on the SciViews Mathematica Plug using this protocol, and it is a
real pleasure! Although it is not open source, I think that Wolfram Research
release it with a license that allows for freely implementing different
clients and servers, outside of Mathematica.

OpenMath is a standard to exchange mathematical objects, but it is not much
focused on actually implementing the connection between the backend and the
frontend, as far as I know. MathLink is an excellent implementation of such
a backend/frontend communication protocol. If someone would like to code a
MathLink connection (or something equivalent) for R, it should be wonderful.
However, I suspect the task is not at all as easy as it could seem at first
glance!

Another remark: do not deconsider pipes or sockets: they work very well with
R, and you are not restricted to exchange text. You can also pass images
(graphs), numerical matrices,... However, if you want to share objects by
reference between R and your GUI client, then, this is a different story!
Note, however, that MathLink uses internally a single channel and serializes
communication through it by passing text, images, numerical matrices, error
messages in turn, using a custom protocol. This is why it can run a remote
kernel so easily. If it had to share matrices by reference, it would be not
possible or very difficult to work with remote kernels!

Best,

Philippe Grosjean

...........]<(({?<...............<?}))><...............................
 ) ) ) ) )
( ( ( ( (       Dr. Philippe Grosjean
 ) ) ) ) )
( ( ( ( (       LOV, UMR 7093
 ) ) ) ) )      Station Zoologique
( ( ( ( (       Observatoire Oceanologique
 ) ) ) ) )      BP 28
( ( ( ( (       06234 Villefranche sur mer cedex
 ) ) ) ) )      France
( ( ( ( (
 ) ) ) ) )      tel: +33.4.93.76.38.18, fax: +33.4.93.76.38.34
( ( ( ( (
 ) ) ) ) )      e-mail: phgrosjean@sciviews.org
( ( ( ( (       SciViews project coordinator (http://www.sciviews.org)
 ) ) ) ) )
.......................................................................



-----Original Message-----
From: r-sig-gui-bounces@stat.math.ethz.ch
[mailto:r-sig-gui-bounces@stat.math.ethz.ch]On Behalf Of Byron Ellis
Sent: mercredi 2 avril 2003 11:40
To: R-sig-gui@stat.math.ethz.ch
Subject: [R-gui] Interfaces between GUIs and R


Hi folks, this is a question for all you GUI developers out there
though, in particular, to those who work on SciViews and RKward (though
anyone else is certainly welcome to chime in). Presently, my StatPaper
app (which will have a website soon, I've just been busy this week) and
AFAIK RKward employ a "kernel"-type interaction method (SciViews
mentions a kernel, but I haven't been able to test it to see how it
works) with R, that is R itself runs as a separate process and
communication takes place over either the STDIN/STDOUT associated with
the process or through some other means (say, UNIX sockets).  This
works fine if we're just passing text back and forth, but when we want
to start passing objects or graphics device information things start to
do downhill pretty quickly.

My question: Is there any interest in developing a general kernel
interaction protocol for R GUIs? This would most likely include the
following:
	* Representation of data objects
	* Execution of R statements
	* Returning graphics of the kernel link
	* ???

Recently, I've been looking at the OpenMath protocol
(http://www.openmath.org) for use in StatPaper and it seems fairly
simple and robust. It bears a great deal of resemblance to the MathLink
protocol employed by Mathematica. At the moment I think this entire
thing could be done as an R package, possibly using the REventLoop
mechanism for the server (though I don't know that it would be
necessary) and also providing client access so that two R installations
could communicate (I know that Rpvm and Rmpi already exist, though they
have a somewhat different goal) in a standard fashion if desired.


Byron Ellis (bellis@hsph.harvard.edu)
"Oook" - The Librarian

_______________________________________________
R-SIG-GUI mailing list
R-SIG-GUI@stat.math.ethz.ch
https://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui
Thomas Friedrichsmeier
# 
Hi!

Since you explicitely mention RKward, I'll have to comment. In fact, RKward 
runs R in a separate thread and communicates via STDIN/STDOUT. This was more 
of a quick and dirty approach however, and I did not really think it was a 
good design. The very vague idea I had on how to deal with graphics and the 
like was to pass them via temporary files. Not very efficient, not very 
elegant.
By the way, however, RKward is on ice, and not likely to come back. Since I 
failed to attract further developers, and did not feel, I could reasonably 
get that program anywhere all alone, I went over to obversive (which BTW - 
shameless plug - runs on MacOSX, among other platforms). Zed Shaw is 
currently working on a CORBA-based backend for obversive, that might 
potentially be of interest to other GUI-projects, too. Last thing he said, 
he's close to having the basic functionality working.
Now for obversive, I have not bothered myself with the backend at all, but it 
would seem to me, like the functionality you mention would indeed come in 
handy. Zed is obviously more qualified to comment on this in detail.
Generally, I'd think it's a good idea to join forces on those problems, that 
all of our projects will have to face sooner or later.

Thomas
On Wednesday 02 April 2003 23:39, Byron Ellis wrote:
Duncan Murdoch
# 
On Wed, 2 Apr 2003 16:39:50 -0500, you wrote in message
<A1D6FFC0-6553-11D7-B170-000393BDE1EC@hsph.harvard.edu>:
I think there's definitely interest in that.  Before you start from
scratch, you should look at Thomas Baier's DCOM interface (in
http://www.cran.r-project.org/contrib/extra/dcom).  It does some of
what you're looking for.

Duncan Murdoch
Duncan Temple Lang
# 
As you know, I have been working on connecting many systems with R
(e.g. Perl, Python, Java, Octave, XLisp, S-Plus, ...), and have been
trying to get across that using strings across systems is quite
limiting for general computations.  Direct embedding, COM/CORBA, SOAP
or our own version of an XML format for Stat objects seems to be an
obvious collection of approaches.  Robert and I put together much of
an RSXMLObjects package which serializes and reads arbitrary S objects
(including language objects, etc.) using an XML format.  The
structures can be easily extended (in the XML sense) to support other
languages.

If the set of kernels is known and fixed, creating a new or
non-standard protocol is fine.  If people are likely to want to add
new kernels, they would then have to implement that protocol.  Using
something like CORBA/COM, SOAP or embedding would increase the chances
of that person being able to use existing facilities in that kernel.

 D.
Byron Ellis wrote:

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Byron Ellis
    

    

      
      #
    

  


  

      
On Thursday, April 3, 2003, at 03:11  AM, Philippe Grosjean wrote:

        

            

      
      
      
    

        
I was curious how you were going to handle the graphics devices... Are 
you somehow capturing the output from the devga device under the 
Windows platform?

            

      
      
      
    

        
Its the first--- most of my computing is done on the OS X platform or 
the Linux platform these days so I haven't gotten around to running it 
on my Win2K installation.

*snip*

            

      
      
      
    

        
As far as I can determine from working with the C APIs, the OpenMath 
and MathLink protocols are quite similar, though they use a slightly 
different protocol syntax you can generate a complete mapping from one 
to the other:
	MLPutInteger -> OMputInt32
	MLPutReal     -> OMputFloat64
	MLPutSymbol-> OMputSymbol (though OpenMath seems to suport a namespace 
mechanism they call "CD"s for some reason)

There's no function for MLPutFunction, rather they use a more open 
ended mechanism (OMputApp,OMputSymbol,...,OMputEndApp) eliminating the 
need to send an argument count. This is slightly more difficult to 
serialize. There are also other elements for sending richer structures 
(to simulate MathLink arrays and whatnot) via OMputObject and 
OMputEndObject. This makes it pretty easy to build lists and arrays. 
You can also send opaque byte objects much like MathLink.

The API has mechanisms for socket transfer (*NIX,Win32) and *NIX 
sockets (*NIX only, of course) with either binary or "XML" 
serialization (though it doesn't produce a document that conforms to 
the XML standard... it just happens to use an XML-like structure that 
you could stick into an XML document)

Admittedly, the website and most of the papers seem to talk about these 
complex server set ups where various servers offer a variety of 
services dispatched through a hub of some sort, but the reality of the 
situation is the API is basically a MathLink clone (which is fine, 
since it was exactly what I expected it to be :-))

            

      
      
      
    

        
At present I was only really thinking about a serial style 
communication--- something like Rpvm would probably be more appropriate 
if I wanted to share objects directly.

            

      
      
      
    

        

      
      
    

        
Byron Ellis (bellis@hsph.harvard.edu)
"Oook" - The Librarian

  
  


  


      

    

    

      
      

        


  

        

      Byron Ellis
    

    

      
      #
    

  


  

      
On Thursday, April 3, 2003, at 09:02  AM, Duncan Temple Lang wrote:

        

            

      
      
      
    

        
Yep, thats why I made sure you were on the R-gui roles when I sent the 
message. otherwise you would have been CC'd  ;-)

            

      
      
      
    

        
I had forgotten about RSXMLObjects

            

      
      
      
    

        
I saw that stuff as well as SSOAP, though I couldn't figure out if the 
latter actually provided a server mechanism. The problem with 
SOAP/XMLRPC that I see so far is a lack of state, since the kernel 
paradigm is generally taken to be stateful and, I think, for good 
reason: if you have some long running calculation you don't really want 
to repeat the entire calculation because you forgot to change the title 
of a graph (in Sweave, for install, anything long running I tend to run 
separately to avoid having it run in the weave portion). Sure, we could 
implement state using session IDs and whatnot, but it seems like an 
awful lot of work just to use the current "hot" XML structure. An XML 
stream would seem more appropriate, except that XML isn't really 
conducive to streaming---it is a document format after all-- and is 
awfully verbose, especially if we start passing complex graphs around 
(isomorphic to the PS vs. PDF argument I guess)

            

      
      
      
    

        
Well, in this case the kernel is R. :-) However, protocol aside (in 
some sense the exact protocol is secondary) there are a variety of 
things that are sort of general to the kernel execution universe. For 
instance, separate execution spaces for sessions--- if I have two 
documents I don't really want execution in one document to affect the 
other documents because thats just weird and liable to trip people up 
since they are visually separate documents. Having multiple 
interpreters around would solve this since they would live in their own 
spaces, but launching multiple copies of R (one for each document and 
since the session has state R basically has to hang around for as long 
as the document is open) is going to get really expensive. Multiple 
interpreters within R would be nice (I'm not talking about 
multithreading, just the ability to run multiple 
interpreters---something I seem to recall Robert mentioning a year or 
so ago) but would likely involve moving a goodly ways towards thread 
safety--or at the very least passing the interpreter structure to all 
the functions, breaking everything. :-) At the moment, there may be a 
way to hack this behavior using environments, but I suspect people 
could still break the paradigm (either intentionally or inadvertently) 
with relative ease. I'm sure there are other issues as well :-) (like a 
graphics device that exposes the display list to R s.t. it can be 
serialized from whatever communication protocol you desire... except 
for the font metrics, this would be fairly straightforward... would we 
need the font metrics to just record the display list? I'm not sure)

Basically, a lot of the same stuff you work on :-)

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        
Byron Ellis (bellis@hsph.harvard.edu)
"Oook" - The Librarian

  
  


  


      

    

    

      
      

        


  

        

      Philippe GROSJEAN
    

    

      
      #
    

  


  

      
Byron Ellis wrote:

            

      
      
      
    

        
I capture the graph device window, i.e., I display it in my own application
instead of in its original place but R is still responsible directly of
(re)drawing its content. This way, I do not need to exchange large amounts
of data between the backend and the frontend (indeed, there are no exchanges
at all!) and all functionalities provided by the original R graph device are
still available in SciViews, like copy metafile/bitmap to the clipboard,
save the graphs directly in different formats, save and restore to and from
a variable in the R user workspace and management of a graph history that is
specific to the Windows version of R.

            

      
      
      
    

        
Then, as you suggest, OpenMath could be an excellent solution to interface
R. However, R  being a statistical package there are few needs in
representing complex mathematical notation. Even, R uses its own notation
for statistical models (formulas). I wonder if and how this could be easily
and automatically translated in a more traditional mathematical notation,...
and even if this would be desirable?!

            

      
      
      
    

        
Do you intend to initiate a project for making an OpenMath interface for R?
If yes, I would like to take part of it, and ultimately include these
features to the SciViews R plug.

            

      
      
      
    

        
I have looked a little closer to it, and indeed yes, it is closer to
MathLink as it looks like when you first browse their web site.

Best Regards,

Philippe Grosjean

...........]<(({?<...............<?}))><...............................
 ) ) ) ) )
( ( ( ( (       Dr. Philippe Grosjean
 ) ) ) ) )
( ( ( ( (       LOV, UMR 7093
 ) ) ) ) )      Station Zoologique
( ( ( ( (       Observatoire Oceanologique
 ) ) ) ) )      BP 28
( ( ( ( (       06234 Villefranche sur mer cedex
 ) ) ) ) )      France
( ( ( ( (
 ) ) ) ) )      tel: +33.4.93.76.38.18, fax: +33.4.93.76.38.34
( ( ( ( (
 ) ) ) ) )      e-mail: phgrosjean@sciviews.org
( ( ( ( (       SciViews project coordinator (http://www.sciviews.org)
 ) ) ) ) )
.......................................................................

  
  


  


      

    

    

      
      

        


  

        

      Byron Ellis
    

    

      
      #
    

  


  

      
On Friday, April 4, 2003, at 04:31  AM, Philippe Grosjean wrote:

        

            

      
      
      
    

        
Ah, slick :-)

            

      
      
      
    

        
Well, the nice thing about OpenMath is the namespacing (Content 
Dictionaries) let you specify pretty much any structure you like so it 
would be possible to completely serialize any R type using OpenMath in 
a straightforward manner. So (to steal of pseudo-Mathematica for a 
moment)
x <- function(a,b) { a + b }

R:Assign[Var(x),R:Function[{Var(a),Var(b)},{R:Sum[Var(a),Var(b)]}]]

Whether or not we'd WANT to do this is up for grabs :-) My intent is 
to, essentially, implement the equivalent of "Enter" from Mathematica 
(for entering lines of code) initially as well as the code necessary to 
transport graphics data across the link in a "display list" of some 
sort (or at the very least as a set of OpenMath functions). I'd rather 
have something simple that works at first rather than something complex 
that never gets finished ;-)

            

      
      
      
    

        
I have a *very* primitive OpenMath package for R that allows two R 
instances to talk to each other at the moment (via UNIX and TCP 
sockets). It can pass the primitives as well as Objects (lists with a 
class attribute basically) and Applications (also a list, different 
class attribute). It seems like this might eventually be a job for 
REventLoop, but I haven't yet fathomed how to do away with stdin/stdout 
entirely (since this I/O mechanism is message based, not data stream 
based stdin/stdout type interfaces don't have much meaning... though I 
would *like* Enter[Some Text] to simulate entering a line for managing 
block generation (each output generating statement generates a new 
block of text) and error reporting as its oh-so-much-more-useful to 
have a "syntax error" attached to a particular line rather than an 
arbitrarily large hunk of code).

There isn't any documentation at all and little error handling, but 
since you're interested I can start making that package available 
through some mechanism relatively soon (I should really get this stuff 
into a SourceForge project or something similar). The "StatPaper" side 
of things is all ObjectiveC based and actually already supports the 
notion of an "evaluator" where objects are set to handle a particular 
namespace (for instance, there is a class that handles the "Plot" 
namespace for mapping a prospective stream of ObjectMath data back into 
an image representation, a PDF in this case, which is based on 
devQuartz... though with different handling for font metrics and such)

            

      
      
      
    

        
Byron Ellis (bellis@hsph.harvard.edu)
"Oook" - The Librarian

  
  


  


      

    

    
2 days later

    

      
      

        


  

        

      Philippe GROSJEAN
    

    

      
      #
    

  


  

      
Byron Ellis wrote:

            

      
      
      
    

        
... and in another message:

            

      
      
      
    

        
It is exactly my point of view. That is the reason why I use --ess mode of R
today (because it works right now and it is simple). I have:

Today's SciViews R Plug:  frontend (GUI client) <-> R Plug (COM) <-> R
using --ess
And in the future:        frontend              <-> R Plug (COM) <-> R using
?OpenMath / MathLink / RSXMLObjects? with better integration between R and
the R Plug.

In other words, I am ready to use better technologies when they will be
available. The design of the SciViews R Plug, with an intermediary COM layer
allows me to concentrate on the GUI Client that "sees" only an (almost)
definitive COM interface, and it leaves me the opportunity to change the
internals of the R Plug, that is, to replace the simple but rudimental --ess
mode by something else when the technology will be there. Of course, I
encourage all developments and initiatives for enhancing connectivity of R.
However, I am also waiting for features that are not found commonly in most
current interfaces.

For instance, I am curious which interface allows interruptible calculation:
- --ess mode, using Ctrl-C, and consequently the current SciViews R Plug
does,
- and then ???

Best,

Philippe Grosjean

...........]<(({?<...............<?}))><...............................
 ) ) ) ) )
( ( ( ( (       Dr. Philippe Grosjean
 ) ) ) ) )
( ( ( ( (       LOV, UMR 7093
 ) ) ) ) )      Station Zoologique
( ( ( ( (       Observatoire Oceanologique
 ) ) ) ) )      BP 28
( ( ( ( (       06234 Villefranche sur mer cedex
 ) ) ) ) )      France
( ( ( ( (
 ) ) ) ) )      tel: +33.4.93.76.38.18, fax: +33.4.93.76.38.34
( ( ( ( (
 ) ) ) ) )      e-mail: phgrosjean@sciviews.org
( ( ( ( (       SciViews project coordinator (http://www.sciviews.org)
 ) ) ) ) )
.......................................................................