From murdoch.duncan at gmail.com  Thu Jul  7 16:17:53 2011
From: murdoch.duncan at gmail.com (Duncan Murdoch)
Date: Thu, 07 Jul 2011 10:17:53 -0400
Subject: [Rd] Recent and upcoming changes to R-devel
In-Reply-To: <3D59DF35E7CF3E42BA70C23BD5CBE6A85F4E504957@exvic-mbx04.nexus.csiro.au>
References: <alpine.OSX.1.00.1107041124460.59432@tystie.local>	<3D59DF35E7CF3E42BA70C23BD5CBE6A85F4C199E22@exvic-mbx04.nexus.csiro.au>
	<4E12ED06.5040603@openanalytics.eu>
	<4E1310D9.6050901@gmail.com> <4E132BA0.5000003@walware.de>
	<4E132BFD.5090604@gmail.com> <4E1412D1.2040700@walware.de>,
	<4E144A77.8090601@gmail.com>
	<3D59DF35E7CF3E42BA70C23BD5CBE6A85F4E504957@exvic-mbx04.nexus.csiro.au>
Message-ID: <4E15C011.50106@gmail.com>

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

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



[Rd] Recent and upcoming changes to R-devel
Duncan Murdoch