Re: [Rd] [Fwd: opened symbols in libR.so available.]
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 0011f6f0 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. 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [Fwd: opened symbols in libR.so available.]
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 0011f6f0 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/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Tabs in R source code
Some lines are indented by tabs and some lines are indented by spaces, in R source code. This might due to the fact that the source code is not from a single person. But I think that it is better to enforce a single convention. My editor defaults a tab to 8 spaces. So some source doesn't seem to be indented correctly in my editor. Since tab may be displayed differently in different editor, I recommend to replace all the tabs by the appropriate number of spaces to ensure the same indentation display. Could somebody update the source code in the future version by replacing tabs by spaces and enforce such a coding convention in the future? __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Display list redraw incomplete
Benilton Carvalho wrote: Hi, I'm observing the following warning with R-2.10.0 on a machine I have remote access to. Like what happened to Roger ( http://www.mail-archive.com/r-devel@r-project.org/msg08669.html ), two extra instances of X11 are open after dev.off(). Although I'm reporting this on R-2.10.0, it's reproducible on R-devel r50541. Any thoughts about this? Does it also happen if you work on that machine directly? What's the exact way you control that machine "remote"ly? I have never seens that and cannot reproduce it. Best, Uwe Ligges Thanks a lot for any info, b plot(1) dev.off() X11 4 Warning message: In dev.off() : Display list redraw incomplete sessionInfo() R version 2.10.0 (2009-10-26) x86_64-unknown-linux-gnu locale: [1] LC_CTYPE=en_US.iso885915 LC_NUMERIC=C [3] LC_TIME=en_US.iso885915LC_COLLATE=en_US.iso885915 [5] LC_MONETARY=C LC_MESSAGES=en_US.iso885915 [7] LC_PAPER=en_US.iso885915 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.iso885915 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Tabs in R source code
On 29/11/2009 10:58 AM, Peng Yu wrote: Some lines are indented by tabs and some lines are indented by spaces, in R source code. This might due to the fact that the source code is not from a single person. But I think that it is better to enforce a single convention. My editor defaults a tab to 8 spaces. So some source doesn't seem to be indented correctly in my editor. Since tab may be displayed differently in different editor, I recommend to replace all the tabs by the appropriate number of spaces to ensure the same indentation display. The R source code assumes that tabs occur every 8 columns, so if your editor is working properly, it should display files as intended. Could somebody update the source code in the future version by replacing tabs by spaces and enforce such a coding convention in the future? No, that would not be feasible, for the reason you give in the second sentence of your post. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Tabs in R source code
On Sun, Nov 29, 2009 at 10:40 AM, Duncan Murdoch wrote: > On 29/11/2009 10:58 AM, Peng Yu wrote: >> >> Some lines are indented by tabs and some lines are indented by spaces, >> in R source code. This might due to the fact that the source code is >> not from a single person. But I think that it is better to enforce a >> single convention. >> >> My editor defaults a tab to 8 spaces. So some source doesn't seem to >> be indented correctly in my editor. Since tab may be displayed >> differently in different editor, I recommend to replace all the tabs >> by the appropriate number of spaces to ensure the same indentation >> display. > > The R source code assumes that tabs occur every 8 columns, so if your editor > is working properly, it should display files as intended. > >> Could somebody update the source code in the future version by >> replacing tabs by spaces and enforce such a coding convention in the >> future? > > No, that would not be feasible, for the reason you give in the second > sentence of your post. I don't understand why it is not feasible. The spaces are displayed the same in all editors. If there are no tabs, the code should display the same in all editors. I know some languages that are recommended to have spaces rather than tabs for this reason. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Tabs in R source code
On 29/11/2009 11:50 AM, Peng Yu wrote: On Sun, Nov 29, 2009 at 10:40 AM, Duncan Murdoch wrote: On 29/11/2009 10:58 AM, Peng Yu wrote: Some lines are indented by tabs and some lines are indented by spaces, in R source code. This might due to the fact that the source code is not from a single person. But I think that it is better to enforce a single convention. My editor defaults a tab to 8 spaces. So some source doesn't seem to be indented correctly in my editor. Since tab may be displayed differently in different editor, I recommend to replace all the tabs by the appropriate number of spaces to ensure the same indentation display. The R source code assumes that tabs occur every 8 columns, so if your editor is working properly, it should display files as intended. Could somebody update the source code in the future version by replacing tabs by spaces and enforce such a coding convention in the future? No, that would not be feasible, for the reason you give in the second sentence of your post. I don't understand why it is not feasible. The spaces are displayed the same in all editors. If there are no tabs, the code should display the same in all editors. I know some languages that are recommended to have spaces rather than tabs for this reason. It is not feasible because it would require everyone who edits the source code to change the configuration of their editors. In my case, that would require changing about 3 different types of editors (I work on several different platforms). I would probably miss one, and re-introduce tabs the next time I edited a file on that editor. I've already seen problems in the NEWS and CHANGES files, which have recently changed to UTF-8 encoding. It's very irritating that my editor switches back to the Windows default if it doesn't see a byte-order mark, and that some editors that I use automatically delete the BOM. Requiring a particular "encoding" for tabs (i.e. converting them to spaces) would lead to the same problems, but on a much bigger scale. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] PROTECT and OCaml GC.
On Nov 28, 2009, at 7:50 PM, Guillaume Yziquel wrote: > Whit Armstrong a écrit : >> I've had success w/ using a reference counting paradigm in which the outside >> memory manager calls UNPROTECT_PTR(R_object_); in its destructor. >> So, in my case (using c++ ) if objects are allocated on the heap, which >> allocate R objects as their backend storage, I don't have to worry about out >> of order UNPROTECT calls b/c UNPROTECT_PTR will just put the objects that >> c++ destroys on the gc list. >> If you are using c as the glue for all your ocaml bindings, they you may >> want to have a look at this: >> http://github.com/armstrtw/rabstraction >> Or the in progress re-write here: http://github.com/armstrtw/RObjects >> -Whit > > Thanks a lot for these pointers. > > UNPROTECT_PTR seems quite interesting. As I understand it, it avoids caring > about protecting and unprotecting in the order the stacks would expect. This > is quite interesting, since I'd like to keep OCaml's GC to do housekeeping, > and not rely on referencing counting. > FWIW what I think you should be really looking at is R_PreserveObject/R_ReleaseObject. I would suggest looking at the many other R embeddings in other languages that already exist since I don't think you approach is very viable (but I think I expressed that already before). Cheers, Simon > I'm using C as the glue, but I want it to be as thin as possible. I will > probably not do reference counting in C, for instance. Nevertheless, there's > obviously good ideas in rabstraction/RObjects that I'll adapt. > > Thanks a lot. > > -- > Guillaume Yziquel > http://yziquel.homelinux.org/ > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tiny typos in R-exts
1. footnote 5, p. 52: "there is only a fine distinction between \dots
and \dots"
I should hope so :-) (from context, I think one of these should be
\ldots instead)
2. under "\keyword{key}", p. 45: "are not part of the packages' API."
Should that be "package's" ?
signature.asc
Description: OpenPGP digital signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Display list redraw incomplete
On Sun, 29 Nov 2009, Uwe Ligges wrote: Benilton Carvalho wrote: Hi, I'm observing the following warning with R-2.10.0 on a machine I have remote access to. Like what happened to Roger ( http://www.mail-archive.com/r-devel@r-project.org/msg08669.html ), two extra instances of X11 are open after dev.off(). Although I'm reporting this on R-2.10.0, it's reproducible on R-devel r50541. Any thoughts about this? Does it also happen if you work on that machine directly? What's the exact way you control that machine "remote"ly? I have never seens that and cannot reproduce it. I have seen it: it seems to be an X11 timing issue. If Benilton is that bothered, he could contribute a patch. The issue appeared to be that X11 was issuing a repaint on a window after it had been closed: it ought to be possible to block that in the devX11 code -- but it needs someone with a reproducible setup to contribute the patch. Best, Uwe Ligges Thanks a lot for any info, b plot(1) dev.off() X11 4 Warning message: In dev.off() : Display list redraw incomplete sessionInfo() R version 2.10.0 (2009-10-26) x86_64-unknown-linux-gnu locale: [1] LC_CTYPE=en_US.iso885915 LC_NUMERIC=C [3] LC_TIME=en_US.iso885915LC_COLLATE=en_US.iso885915 [5] LC_MONETARY=C LC_MESSAGES=en_US.iso885915[7] LC_PAPER=en_US.iso885915 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C[11] LC_MEASUREMENT=en_US.iso885915 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] PROTECT and OCaml GC.
Simon Urbanek a écrit : On Nov 28, 2009, at 7:50 PM, Guillaume Yziquel wrote: FWIW what I think you should be really looking at is R_PreserveObject/R_ReleaseObject. OK. Thanks. I would suggest looking at the many other R embeddings in other languages that already exist since I don't think you approach is very viable (but I think I expressed that already before). Lisp - the only thing I've seen is a translator: http://dan.corlan.net/R_to_common_lisp_translator/ I haven't found a binding for Haskell. Nor for Scheme. Do you know of any bindings of R to functional languages? since I don't think you approach is very viable (but I think I expressed that already before). You expressed the sentiment that it would be a very bad idea to bypass the current API. I would be happy to hear why you would think that a low-level binding is not possible, or not very viable. By low-level, I mean a binding that takes hold of R objects without using symbols all over to reference them. (Using symbols in the formals, the body or the environment of a closure is fine, for instance, but I'd like to execute a closure directly, and eventually be able to construct R closure from OCaml functions). Please elaborate on the difficulties you perceive. That would be helpful. Cheers, Simon All the best, Guillaume. -- Guillaume Yziquel http://yziquel.homelinux.org/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] tiny typos in R-exts
On 29/11/2009 1:39 PM, Ben Bolker wrote:
1. footnote 5, p. 52: "there is only a fine distinction between \dots
and \dots"
I should hope so :-) (from context, I think one of these should be
\ldots instead)
2. under "\keyword{key}", p. 45: "are not part of the packages' API."
Should that be "package's" ?
Thanks, I'll fix these.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [Fwd: opened symbols in libR.so available.]
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. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tzone attribute gets stripped on POSIXct variable
The POSIXct variable xx has a tzone attribute but if I add 1 second to it
then the tzone attribute gets stripped. Is that intended?
> xx <- as.POSIXct(format(Sys.time()), tz = "")
> dput(xx)
structure(1259541335.099, class = c("POSIXt", "POSIXct"), tzone = "")
> dput(xx+1)
structure(1259541336.099, class = c("POSIXt", "POSIXct"))
> R.version.string # Windows Vista
[1] "R version 2.10.0 Patched (2009-11-21 r50532)"
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
