[Rd] Dynamic C Symbols and Embedding Suggestion

Byron Ellis bellis@hsph.harvard.edu
Mon, 14 May 2001 11:28:18 -0400 (EDT)


On Mon, 14 May 2001, Duncan Temple Lang wrote:

> Byron Ellis wrote:
> > 
> 
> One reason for this omission is that I haven't yet found a need for
> it. But the embedding R in another application is still reasonably recent
> (at least on Unix), so the more we found out about what is needed, the better.
> 
> Here are some reasons I think we haven't needed to be able to access
> the symbols in the host application.
> 
> Firstly, most C routines are not directly callable from R. Certainly
> those accessed by .Call, .External require knowledge of R. Because of this
> explicit dependency on libR.so, and the need to ensure that
> they are called only after R has been initialized makes it more sensible
> to load them as a regular R package as part of the post-initialization of R.
> 
> Routines accessed via .C and .Fortran typically need an extra layer
> of indirection to handle arguments as they come from R to the native code.
> For example, an S call
>   .C("foo", x, length(x))
> might map to the C routine
>    void foo(double *x, Sint *len) {
>       realFoo(x, *len);
>    }
> 
> The real routine is realFoo() and we have to convert the length
> argument to a scalar rather than a pointer to a scalar.  In this
> setup, R need never know about realFoo() explicitly. It will be
> resolved by the dynamic loader (for better or worse).  Luke and I (at
> the very least) are keen to avoid the dynamic loader and to have
> people explicitly link against libraries as it avoids
> platform-specific nuances of the loader that are very hard to control.
> 
> 
> The examples where it is useful for R to be able to see symbols in the
> host application are those that take no arguments and whose value is
> ignored. Are there any interesting examples of this? 

I'm not thinking so much in terms of random C functions that we may want
to call from R--- but rather functions which are intended to be called
from R but need to be in the host application for one reason or another.
Two immediate examples come to my mind (at least on the Windows
platform--you should be able to get around this first one in X and the
second doesn't apply to *NIX platforms :-)):

1. GUI interfaces a la S-Plus. That is to say the ability to add menus or
other things (graphics devices, etc.) to the primary GUI interface from R.
For instance, I have a piece of code that lets me attach arbitrary R
expressions to menu items which are then executed by taking over the
console interface temporarily (with the option to suppress output). In the
case of the official R GUI obviously you don't have this problem since it
is relatively tightly coupled to the core engine and the executable itself
doesn't really do anything.

2. An ActiveX control (see, doesn't apply ;-)). In this situation
(specifically embedding R in Internet Explorer to match the SNetscape
control since IE has something like 97% of the Windows desktop
marketshare) I can't use the hack described in my original email since
GetModuleHandle(NULL) returns IEXPLORE.EXE not a handle to the COM DLL
(unfortunate, but true). In this case I'd like to add some links between
the Javascript event model and R so I need to expose the fire*
functionality.

> 
> Thanks for pointing out the idea of separating the two task currently
> performed by AddDLL(). I'll separate them later today.

Nifty.

> 
>  D.



Byron Ellis (bellis@hsph.harvard.edu)


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._