[R-gui] Interfaces between GUIs and R

Thu Apr 3 14:51:02 MEST 2003

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

> 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.
>
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?

> 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.

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*
> 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!
>

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 :-))

> 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!

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.

>
> 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 at sciviews.org
> ( ( ( ( (       SciViews project coordinator (http://www.sciviews.org)
>  ) ) ) ) )
> .......................................................................
>
>
>
> -----Original Message-----
> From: r-sig-gui-bounces at stat.math.ethz.ch
> [mailto:r-sig-gui-bounces at stat.math.ethz.ch]On Behalf Of Byron Ellis
> Sent: mercredi 2 avril 2003 11:40
> To: R-sig-gui at 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 at hsph.harvard.edu)
> "Oook" - The Librarian
>
> _______________________________________________
> R-SIG-GUI mailing list
> R-SIG-GUI at stat.math.ethz.ch
> https://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui
>
>
>
>
Byron Ellis (bellis at hsph.harvard.edu)
"Oook" - The Librarian