[Rcpp-devel] Resolving NativeSymbolInfos from Rcpp

[Davor Cubranic]

Luckily, the functionality was all contained in two files. I just copied 
those from R source into my package, removed the NativeSymbolInfo trick 
from my code, and everything worked fine. The licenses are both GPL, so 
it's OK in that respect.

Davor


On 12-10-07 01:59 PM, Dirk Eddelbuettel wrote:
>
> On 7 October 2012 at 13:40, Davor Cubranic wrote:
> | Just a heads up that the hack to convert NativeSymbolInfo of an object
> | in one package to a function pointer that is called from another (in my
> | case, calling "loess_raw" in stats from rgam), is not allowed any more
> | in development versions of R and will cause a crash.
>
> Not surprising, given all the other API tightening going on.
>
> So what are you going to do for your package?  Import loess as source?
>
> Dirk
>
> | Davor
> |
> |
> | On 10-06-10 03:28 PM, Davor Cubranic wrote:
> | > On 2010-06-08, at 10:46 PM, Romain Francois wrote:
> | >
> | >>>> Reading the information on writing R extensions, it sounds like there
> | >>>> may not be a way to get to the address of an object in another
> | >>>> package's DLL. (In this case, in stats.so.) However, there is a
> | >>>> NativeSymbolInfo for stats:::R_loess_raw, which includes all sorts of
> | >>>> info about the C method. Is there a way that this can be used to get a
> | >>>> function pointer to it from within my code? And if this is too
> | >>>> unportable, is there a cleaner way?
> | >>
> | >> After some more coffee, I came up with this:
> | >> [...]
> | >> Please expand the part that is actually suppose to call loess_raw and let us know if something useful happens.
> | >
> | > That worked like a charm, Romain, thank you so much! (At least on OS X, I only tested it there so far.)
> | >
> | > Davor
> | >
> |
> | _______________________________________________
> | Rcpp-devel mailing list
> | Rcpp-devel at lists.r-forge.r-project.org
> | https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>