[Rd] Recent and upcoming changes to R-devel
murdoch.duncan at gmail.com
Thu Jul 7 16:17:53 CEST 2011
On 07/07/2011 3:38 AM, Mark.Bravington at csiro.au 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
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.
More information about the R-devel