Hi Harry.
Thanks for providing the details about the plan. I'll try to take
a look at some of the Open Office documents in the next week. For the
most part, the inter-system interfaces are the same and only the
mechanics are specific to the host.
I hope OO doesn't require that we add _all_ S functions to a menu.
If for no other reason, the user will be overwhelmed. Gnumeric
requires that we register them with the function manager at run-time
which means we can tailor them to the particular session/application.
What one typically wants is a way to tell OO that if it is looking for
a function, ask R does it have that function. There are a variety of
issues about argument types, etc. These aside, what we typically want
to have is a that R is embedded in OO and the R-OO bridge provides a
way to marshall a call from OO to R. And we also want a bi-directional
interface so that R can access the OO sheet, etc. from R functions.
I'll try to briefly address the libR.so issues.
Some of the (many) things that I do not have a good grasp on are:
- which R functions are available to the calling app. There is a list of
functions listed in Chapter 5 of the "Writing R Extensions" doc.
But there is also a function defined as:
call_R(char*, long, void**, char**, long*, char**, long, char**);
which appears to provide access to all R functions. Is this the case?
- If we have a routine that is responsible for marshalling all calls
from OO to R, we can have it use call_R or alternatively construct and
evaluate an R expression directly in C code. If you look in the
RGnumeric.c file and specifically at the routine
RGnumeric_fixedArgCall(), you'll see an example of the marshalling
routine. This is a more explicit and flexible version of call_R()
and will do error handling correctly!
- how do R and optional R packages (such as Bioconductor) interact via libR.so?
- If you think of libR.so as simply being a way to embedd R into
another application (just like we can load a library into R), then
that version of R inside a host application runs exactly as it would
as a stand-alone. One loads any [optional] R package using the
library() function in R and the R engine will take care of all the
details, e.g. loading the .so/.dll for that library, the S code, etc.
The only important thing is that packages in which the C/Fortran code
use routines in R must be installed after R has been built with
libR.so enabled. This is the default when R is configured with the
--enable-R-shlib option and packages are subsequently installed. Any
package installed before R was built as a shared library may not work.
- Do all optional packages have to be defined when building libR.so? (this
doesn't sound right) Or if not, how is libR.so informed that it has to load an
additional package?
No. They can be installed whenever needed.
Somebody will have to tell R to load that additional package when it
is needed. This can be done either in the startup script for R
(i.e. Rprofile) or by the "user" of OO. Typically, you will add a
function to OO that will load the relevant R packages. This function
is your OO wrapper to the R functionality.
- Is this process integral to the runtime so that once Bioconductor or other
package is installed via 'R INSTALL ..', libR.so can access them just like R?
Yes. R and libR.so are almost exactly the same. From one point of
view, the difference is how they start - R is a stand alone
application that starts itself; libR.so is started by some other
application.
This should be very interesting. I'll try to find some time to read
the OO docs and help out.
D.
Harry Mangalam wrote:
Hi All,
A group of about 3-4 of us are looking into the possibility of incorporating R
into OpenOffice's (OO) spreadsheet component (sc) . We wish to use OO's nice
ODBC ability to query a postgresql-based gene expression database thus
populating an OO sc and then use Bioconductor via R to analyse user-selected
parts of this spreadsheet.
We've looked at and compiled and used RGnumeric (with Duncan's help) to see
what's possible under Gnumeric, but AFAIK gnumeric won't have DB connectivity
for some time and has neither the finish nor the integration of OO.
We've reviewed quite a few documents that describe the integration approach and
while it seems to be a bit complex (mostly due to UNO - OO's CORBA-like
integration strategy), it seems to be quite doable.
We envision it working ike this:
- build R as a shared lib - libR.so [trivial - the R team has done this for us]
- use the UNO framework to direct the writing of an IDL that allows libR.so to
be linked into the OO sc runtime [time consuming to digest all the docs and get
a feel for how to do this, altho there are some introductory docs at:
http://sc.openoffice.org/addin_howto.html
- write code that will automate the insertion of available R functions into the
OO sc menu system. [possibly tricky but mostly tedious..?]
- write the query interface to the database within OO [pretty easy]
Some of the (many) things that I do not have a good grasp on are:
- which R functions are available to the calling app. There is a list of
functions listed in Chapter 5 of the "Writing R Extensions" doc.
But there is also a function defined as:
call_R(char*, long, void**, char**, long*, char**, long, char**);
which appears to provide access to all R functions. Is this the case?
- how do R and optional R packages (such as Bioconductor) interact via libR.so?
- Do all optional packages have to be defined when building libR.so? (this
doesn't sound right) Or if not, how is libR.so informed that it has to load an
additional package?
- Is this process integral to the runtime so that once Bioconductor or other
package is installed via 'R INSTALL ..', libR.so can access them just like R?
--
Cheers, Harry
Harry J Mangalam - 949 856 2847 (v&f) - hjm@tacgi.com
<<plain text preferred>>