[Rd] multiple packages using the same native code.

[Duncan Temple Lang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



There is work underway to be able to handle this concept
of a package providing native code to other packages.
It is done in several packages already, but it is time
to make the package mechanism extensible and this feature
is one of the motivating examples.  It probably won't make it
into 2.3.0 as I am only just finishing a quarter of intense teaching,
but it will be available reasonably soon (i.e. a month or so).


Copying the code is the most natural approach, but this does not
support the important case where one wants a single instance of
a shared native symbol, i.e. a global data object.

There are several situations that we want to be able to support
and these will be possible via a package mechanism that relies
more on R code than shell & Perl scripts.

James Bullard wrote:
> Seth, thanks for the advice. This solution seems like it might work, but 
> then all errors occur at runtime rather than at compile time. This seems 
> like I am exchanging one evil for another (run time segfaults versus 
> code duplication) Lets say we have these three package A, B, and C 
> defined more or less like this:
> 
> A/src/bar.c
> int bar()
> {
>     foo();
> }
> 
> B/src/baz.c
> int baz()
> {
>     foo();
> }
> 
> C/src/foo.c
> int foo()
> {
>     return 1;
> }
> 
> 
> Now, the only way I can see to do this is to copy foo.c into both src 
> directories of package A and B. This is not exactly what anyone wants, 
> but rather I'd rather just say that both package A and B depend on 
> package C. If I put them in a bundle then can I expect that the src will 
> always simultaneously be available? In this way I can easily modify the 
> configure script to handle this, but if I have no way to depend on the 
> presence of the code (ie. users could download and install packages 
> separately even if it's a bundle) then it seems like there is no way to 
> generally modify the configure file to do this.
> 
> 
> thanks, jim
> 
> 
> 
> 
> 
> Seth Falcon wrote:
> 
> 
>>Hi Jim,
>>
>>James Bullard <bullard at berkeley.edu> writes:
>> 
>>
>>
>>>I would like to construct two packages (A, B) which utilize a number of 
>>>common C functions. The most straightforward way to do this is just copy 
>>>the relevant .c and .h files from one src directory to the next, but 
>>>this is tedious especially in the face of multiple developers and
>>>changes.
>>>   
>>>
>>
>>I'm not sure I understand what you are after.  One possible solution
>>would be to create a third package 'C' that contains the common C
>>code.  This would allow you to call C function defined in 'C' from the
>>C code in 'A' or 'B'.
>>
>>Using a .onLoad hook and getNativeSymbolInfo(), you can pass C
>>function pointers to the code in packages A and B.
>>
>>Suppose in 'C' you have a C function foo() that is registered in the
>>usual manner so that it can be called by .Call or .C.
>>
>>Then in 'A' you could have (all untested, sorry, but hopefully it
>>sketches the idea for you):
>>
>>A/src/A.c
>>
>>  static DL_FUNC C_foo;
>>
>>  void init_funcs_from_C(SEXP foo_info) {
>>      C_foo = R_ExternalPtrAddr(foo_info);
>>  }
>>
>>  void bar(int *x) {
>>      ...
>>      z = C_foo();
>>      ...
>>  }
>>
>>
>>A/R/zzz.R
>>
>>  .onLoad <- function(libname, pkgname) {
>>      foo_info <- getNativeSymbolInfo("foo", PACKAGE="C")
>>      .Call("init_funcs_from_C", foo_info$address)
>>  }
>>
>>
>>+ seth
>>
>>______________________________________________
>>R-devel at r-project.org mailing list
>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> 
>>
> 
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

- --
Duncan Temple Lang                    duncan at wald.ucdavis.edu
Department of Statistics              work:  (530) 752-4782
4210 Mathematical Sciences Building   fax:   (530) 752-7099
One Shields Ave.
University of California at Davis
Davis,
CA 95616,
USA
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)

iD8DBQFEGrvp9p/Jzwa2QP4RAuoFAJ4ouFY/G21sWkw8fY/MCPc5GantdACdGFjE
xWGG+UGbxs1sTKN5o1+j69A=
=Isbq
-----END PGP SIGNATURE-----