Dears,
Alle 11:16, gioved? 24 febbraio 2005, Philippe Grosjean ha scritto:
[cut]
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.
Probably, these are things that could be a warm-up stage before something more
powerfull. oOO calc has widgets for that I suppose.
2) Using oOOWriter as a "notebook ? la Mathematica" editor, that is,
mixing plain text with calculations and graphs interactively generated by
R.
Personally, I don't like this way... but with a <component> that link R to oOO
could be "easy" open a terminal like console with R <somewhere> in OOwriter
to do that.
3) Using oOOWriter as a report editor (see for instance the reporting
features in the SciViews bundle on CRAN).
very nice!
4) Using oOOWriter as a WYSIWYG help files (.Rd) editor.
IMHO the features is "have help file write-able with any editor", the way to
write these is a user choice. Yes, WYSIWYG could help a bit.. :)
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,
good.
- be bidirectional,
good.
- 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),
I don't know exactly what you mean, but I am thinking about <something> like
SAS server-client do with many processes-threads. IMHO this is a powerfull
features that could trasform R in a killer app for companies that have data
on servers and analyst with clients. Probably this point contrast with first
point, either if R has/hasn't this capability.
Following this way, could be very good to collaborate with a database project
team like Postgresql (for example). Many apps have connection with this
software (eg. GIS) and actually exist a PL/R too.
With the same interest could be GNUe project, a free software ERP that already
have an applications server ready.
- allow connecting/disconnecting (hot plug) to a running R session that
was not started initially to interact with your client application,
an application server.. look at GNUe -www.gnue.org
- work the same way on all supported platforms.
good.
Clearly, solutions proposed in
http://cran.r-project.org/doc/manuals/R-exts.html#Linking-GUIs-and-other-fr
ont_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.
are you working with wxWidgets too?
Tcltk is a reality, but widgets are not so good, not so beauty.
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.
..your proposal is a good way to follow and, IMHO all could appreciate the
existance of ideas and real solutions.
From an analyst/user point of view (that use Sciviews+R / SAS on windows, or R
terminal either on win/linux) I found all these ideas good, but not *enough*.
IMHO, I could be very-very happy with:
1. On R front, start R as a server to handle multiple connection from
R-client through unix socket or tcp/ip. This feature should be part of
r-project directly. Many free software implementation has this already done
and could be an "easy" port.
2. On oOO front, have an additional application that share db widgets with the
new access-like app, share spreadsheet widget with Calc for data entry and
could communicate with R-server as a client, either locally and remotly for
datas. On oOO front, this new app should be a diagram editor like SAS
Enterprise Miner or SPSS Clementine, with code editing capabilities and a
terminal like console to R, good enough for the oOO target of users. These
features should be part of oOO project.
Again: what kind of widgets/toolkits? I found Gtk the best choice in terms of
quality, "freely" available, multi-platform. Novell is working hard to extend
windows support too, and this is very good.
RECAP
talk about with R-core team about "server" feature,
talk about with oOO team for a new app in analysis direction.
bye
Daniele Medri - http://www.medri.org
"There is a risk that data analysts will see patterns that are merely a
result of looking too hard. Under torture, the data readily yield false
confessions."