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:
yziq...@seldon:/usr/lib/R/lib$ nm -D libR.so | grep mkPROMISE
000000000011f6f0 T Rf_mkPROMISE
yziq...@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/
______________________________________________
[email protected] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
