Re: [Rd] Recent and upcoming changes to R-devel

From: Duncan Murdoch <>
Date: Thu, 07 Jul 2011 10:17:53 -0400

On 07/07/2011 3:38 AM, wrote:
> Thank you Duncan for those reassurances. I still have a couple of questions, as below, but there was definitely some good news for me in your replies:
> - IIUC , the "source" attribute will still be available for everything, provided R_KEEP_PKG_SOURCE=yes (I am not so worried about srcrefs)

No, the "source" attribute will go away. Setting R_KEEP_PKG_SOURCE=yes will give you a "srcref" attribute on the function (not just on its body. You can then get a copy of the source using something like

as.character(attr(fn, "srcref"))

It would be possible to put in special case code so that attr(fn, "source") did this, but the main point of this exercise is to simplify things, so special-casing is out. This will be inconvenient for you during the transition, but it shouldn't be too bad.
> - modifying the body of a function automatically disposes of the previous byte-compiled version.

I believe that's true, but I haven't been involved in writing that part. I would guess there are ways to subvert this (i.e. modify the body without discarding the byte-compiled version), but hopefully it is easier to do it right.
> *If* that's all there is, then I can easily enough modify 'debug' to work with byte-compiled code. But I am still a bit concerned, because I can remember in the past reading somewhat scary things like this:
> "... sealing the namespace means the byte compiler can make certain assumptions for efficiency..."
> Q1: So my concern is something like this: even if I can successfully 'mtrace' one function X in eg baseenv() for when X is called directly, maybe a byte-compiled version of another function Y (in baseenv() or elsewhere) that calls X will somehow still invoke the original byte-compiled version of X. EG if the BC knows that X has been reduced to piece-of-BC-code #924, then maybe the BC of Y contains "call BC#924 now" rather than "call X now". So only direct calls to X would pick up the modified version. Can someone confirm that "this sort of thing" won't happen?
> Obviously this is a bit non-specific and is based on ignorance-- but that's inevitable because there isn't much information about the BC. The manuals for R-2.14-dev have almost none, for example.
> The Windows binary of R-devel on 6-7-2011 didn't yet seem to be the pre-byte-compiled version mentioned in Brian Ripley's announcement, so I haven't been able to test anything.
> Q2: From DM's first reply:
> "... but that is something
> that is either ..., or avoided by re-installing without byte compiling."
> How would the latter be done? And would it be possible for the Windows binary distro, or just for the source distro? My reading of the first email about changes in R-2.14-devel was that the distro would be byte-compiled already.

What I had in mind was re-installing from source, since the binary distribution will definitely be byte compiled. But there may be other ways to do it.

Duncan Murdoch mailing list Received on Thu 07 Jul 2011 - 14:21:18 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Thu 07 Jul 2011 - 16:20:07 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive