[R-gui] OpenOffice.org and R

Duncan Temple Lang duncan at wald.ucdavis.edu
Thu Feb 24 15:17:24 CET 2005


Philippe Grosjean wrote:
> Hello,
> 
> This is very interesting! I have always resisted to anything that could 
> mix R and Microsoft Office, because I believe it is against the Open 
> Source phylosophy. Of course, with OpenOffice, no problems!


R is consistent with non-Open source use so connecting to Excel is
not against the philosophy. We have connections to Oracle, Excel, etc.
Compile R on Solaris using Sun's compilers...
I believe  one very important aspect of R is the dissemination and
practice of good statistical techniques.


Connecting to available tools that people use and will
continue to use is a good thing and often better than having new
basic tools that are platform independent and equally inferior on all.
The specific connection here is that Excel is what an awful lot
of people use. oOO calc is there too. So is Gnumeric. Use them
since otherwise we are going to have to write a whole lot of new  software
that already exists and that people want to use, and most importantly
that requires careful design by people specializing in those areas.
Fix and extend the bits that don't work. I believe that is an
important aspect of the Open Source philosophy





> 
> There are many ways where interaction between R and OpenOffice would be 
> a mutual benefit. Usually, the one that come to the mind is to use R as 
> a powerful calculation engine for oOOCalc. Indeed, you will find ideas 
> in RGnumeric in OmegaHat, and also in RExcel (part of the R(D)Com server).
> 
> Other ways where interaction between R and OpenOffice could be interesting:
> 
> 1) Using oOOCalc as a powerful replacement of the data editor in R: 
> function edit(mydataframe) opens the dataframe in oOOCalc and changes 
> made are transmitted back to R.
> 
> 2) Using oOOWriter as a "notebook à la Mathematica" editor, that is, 
> mixing plain text with calculations and graphs interactively generated by R.
> 
> 3) Using oOOWriter as a report editor (see for instance the reporting 
> features in the SciViews bundle on CRAN).
> 
> and perhaps:
> 
> 4) Using oOOWriter as a WYSIWYG help files (.Rd) editor.
> 
> 
> Now, regarding the way you make R and oOO collaborate, there are again 
> many possibilities. Besides the shared library under Unix, and the 
> R.dll, or R(D)Com server in Windows, I think the optimal communication 
> would:
> - require no changes in R, and no recompilation,
> - be bidirectional,
> - allow communication with R even when it is busy calculating something 
> (in the case you can interact with R both at the command line and with 
> the external client simultaneously),

For that you need R to be capable of doing two things at once.
Multiple interpreters and threads are on the horizon,
perhaps some movement this summer.  However, 
assuming the mechanism is there, I believe there is an enormous
number of details to consider about the semantics.


> - allow connecting/disconnecting (hot plug) to a running R session that 
> was not started initially to interact with your client application,
> - work the same way on all supported platforms.
> 
> Clearly, solutions proposed in 
> http://cran.r-project.org/doc/manuals/R-exts.html#Linking-GUIs-and-other-front_002dends-to-R 
> do not match one or several items in this wishlist. Also, all of them use R 
> as a server exclusively, that is, you cannot interact with R as usual at 
> the command line at the same time you plug it into you client (well, you 
> have to program your own console window in the client app to get a control 
> of R through command line). Indeed, there are circumstances where you would 
> prefer to keep both a direct and indirect interaction with R. Options 1, 2 
> and 4 above  may fall in this category.
> 
> With Tom Short (the author of Rpad), we have started exploring the 
> possibilities to use sockets by means of Tcl. Tcl (tcltk R package) is 
> now widely usable with R, and it is possible to write a very powerful 
> socket server with this language. You will find a first implementation 
> of it in svSocket package (part of the SciViews bundle), and also a more 
> advanced one to exchange HTML data in Rpad. I think this is a promising 
> approach because it matches all items in the wishlist: it works the same 
> on all platforms; it permits hot plug no mather the way R was started 
> (console, Rgui under Windows, Emacs-ESS, ...), etc.


So you are (re)inventing inter-process communication.
And  specific to a small number of applications.
And are you going to add a security layer, object lifetime
or are you going to have objects? and all the other aspects
of DCOM and CORBA that already exist, that many applications 
can already use.  Why o why do we always  want to come up 
with inferior reinventions of something that already exists
without exploring how to make  the current setup work better?
The socket approach does not match  all the items on your wishlist.

 D.




> 
> Oh yes, and speaking about it, these is also the ESS mode of R (Emacs) 
> that could inspire you another way to embed R in oOO.
> 
> Finally, I would say that I am willing to help in your entreprise. If 
> you decide to use part or all of the R GUI API I am implementing in the 
> SciViews bundle, I can surely help you to use it (documentation is only 
> partial for the moment). I can also add, or adapt functions of this API 
> to make it more efficient in the context of your developments for oOO.
> 
> Best,
> 
> Philippe Grosjean
> 
> ..............................................<°}))><........
>  ) ) ) ) )
> ( ( ( ( (    Prof. Philippe Grosjean
>  ) ) ) ) )
> ( ( ( ( (    Numerical Ecology of Aquatic Systems
>  ) ) ) ) )   Mons-Hainaut University, Pentagone (3D08)
> ( ( ( ( (    Academie Universitaire Wallonie-Bruxelles
>  ) ) ) ) )   8, av du Champ de Mars, 7000 Mons, Belgium
> ( ( ( ( (
>  ) ) ) ) )   phone: + 32.65.37.34.97, fax: + 32.65.37.30.54
> ( ( ( ( (    email: Philippe.Grosjean at umh.ac.be
>  ) ) ) ) )
> ( ( ( ( (    web:   http://www.umh.ac.be/~econum
>  ) ) ) ) )          http://www.sciviews.org
> ( ( ( ( (
> ..............................................................
> 
> Ian Laurenson wrote:
> >I am investigating integrating OpenOffice.org with R.
> >
> >Before I start on such a project I thought I would check:
> >
> >Has anyone else has started such a project?
> >
> >If so, does anyone have a contact or web address so that I can see if I
> >can help?
> >
> >If not, can anyone give me additional pointers for getting started on
> >such a project?
> >I am aware of:
> >http://cran.r-project.org/doc/manuals/R-exts.html#Linking-GUIs-and-other-front_002dends-to-R) 
> >
> >Does anyone have a wish list for what they would like when using both
> >OpenOffice.org and R?
> >
> >I am getting proficient with OpenOffice.org's API and have used R a
> >little. I am aware of Gnumeric and its integration with R and am in the
> >process of looking into it further (very early days).
> >
> >For examples of my OpenOffice.org work see:
> >http://homepages.paradise.net.nz/hillview/OOo/
> >
> >Thanks, Ian Laurenson
> >
> >_______________________________________________
> >R-SIG-GUI mailing list
> >R-SIG-GUI at stat.math.ethz.ch
> >https://stat.ethz.ch/mailman/listinfo/r-sig-gui
> >
> >
> 
> _______________________________________________
> R-SIG-GUI mailing list
> R-SIG-GUI at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-gui

-- 
Duncan Temple Lang                duncan at wald.ucdavis.edu
Department of Statistics          work:  (530) 752-4782
371 Kerr Hall                     fax:   (530) 752-7099
One Shields Ave.
University of California at Davis
Davis, CA 95616, USA



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 184 bytes
Desc: not available
Url : https://stat.ethz.ch/pipermail/r-sig-gui/attachments/20050224/2609ddbe/attachment.bin


More information about the R-SIG-GUI mailing list