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

[Guillaume Yziquel]

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/