Re: [Rd] [Fwd: opened symbols in libR.so available.]

From: Guillaume Yziquel <guillaume.yziquel_at_citycable.ch>
Date: Sun, 29 Nov 2009 16:54:38 +0100

Uwe Ligges a écrit :
> Guillaume Yziquel wrote:

>> Hi.
>>
>> I've patched Dirk Eddelbuettel's Debian package of R, namely r-base, in
>> order to make hidden symbols of the library libR.so available is now
>> available:
>>
>>     http://yziquel.homelinux.org/debian/pool/main/r/r-base/
>>
>> For instance, the mkPROMISE symbol is available:
>>
>>> yziquel_at_seldon:/usr/lib/R/lib$ nm -D libR.so | grep mkPROMISE
>>> 000000000011f6f0 T Rf_mkPROMISE
>>> yziquel_at_seldon:/usr/lib/R/lib$ 
>>
>> Instructions for my personal repository are available here:
>>
>>     http://yziquel.homelinux.org/topos/debian-repository.html
>>
>> I hope this will be useful to people who wish to develop
>> things, test things, reverse-engineer things from the libR.so library.
>>
>> I've been told that there's an interesting scheme, used by r-base-ra, 
>> to make packages coexist with R. As of now, it simply replaces the 
>> Debian version number, currently -1, with the Debian version number 
>> -1hackable.
>>
>> All the best,

>
>
> Umm, you know,
>
> 1. there is some reason why not everything is exported from libR.so,
> particularly those parts of the API that are matter to change or are
> undocumented for other reasons.

Yes. For sure. These are good reasons.

Interfacing to hidden symbols in order to try out stuff from an interactive session is also a good reason. I'd rather have to deal with a moving API than contemplating an API moving.

(As a side-note, putting tryEval in the API wouldn't be such a bad idea...)

> 2. if you do not want to listen to 1.:
> R is open source, hence no need to reverse-engineer or "hack" anything
> there, just change the sources and recompile in a way that they export
> those names.

That's what I did. As I did not want to screw up my whole Debian system, I built up a package, which might be useful for people writing language bindings. It's pointless to buy a second computer or meddle with chroots just to recompile R. That's all.

If people do not have the same needs as I do (namely, why what I am passing to tryEval, eval, applyClosure gives a segfault), there's no point in installing such a package. I set it up because such a post remained unanswered:

        https://stat.ethz.ch/pipermail/r-devel/2009-November/055813.html

The whole point is that I have to develop on a naked libR.so to get my binding going. Then I'll consider cleaning things up, and make it compile against a regular libR.so. In the end, the OCaml-R API will be as safe as possible, with extremely strong typing.

> Best,
> Uwe Ligges

As to reverse-engineering, reading the R source code is already reverse-engineering, as is reading any complex C code which is insufficiently documented (insufficiently with respect to my needs, because otherwise, R-ints.pdf, R-exts.pdf and R-lang.pdf have a lot of information).

All the best,

-- 
      Guillaume Yziquel
http://yziquel.homelinux.org/

______________________________________________
R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Sun 29 Nov 2009 - 15:58:30 GMT

This archive was generated by hypermail 2.2.0 : Sun 29 Nov 2009 - 16:10:54 GMT