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, -- Guillaume Yziquel http://yziquel.homelinux.org/
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. 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. Best, Uwe Ligges
Two quick comments while I catch up with the email back log from travelling: On 28 November 2009 at 10:50, Guillaume Yziquel wrote: | I've been told that there's an interesting scheme, used by r-base-ra, to It's 'r-base-core-ra' and I mentioned that in off-line email only to show that you can arrange to have more than one R interpreter in Debian. On 29 November 2009 at 16:54, Guillaume Yziquel wrote: | 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 Duncan, Uwe, and I have told you already, this may get frustrating in the long run as changes may break your bindings. Accessing a hidden API is doing so against the wishes of the API designers / maintainers... | 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. You do not need a chroot or second computer either. Just how r-base-core-ra uses the normal --prefix argument to configure to install into a second, non-overlapping file tree, you could use /usr/lib/ROcaml/ or some directory other than /usr/lib/R + /usr/share/R which are taken by the R package for Debian. R developers use the same --prefix trick to keep r-releases, r-patched, r-devel, ... installed at the same time. Anyway, good luck with the endeavour. Something useful may well come from it. Cheers, Dirk -- Three out of two people have difficulties with fractions.