[R-gui] Interfaces between GUIs and R

Thu Apr 3 11:11:25 MEST 2003

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