>>>>> David Brahm writes:
> I repeat my emails of 11/15/01 and 2/26/02, since it looks like this ESS
bug is
> still not fixed in ESS 5.1.23, and I think some resolution is needed.
> When help() is invoked, ESS makes a copy of .Last.value in the .GlobalEnv,
> which is *not* where R normally stores it (R stores it in package:base).
> When this copy becomes stale it leads to wrong answers. The bug is in
> essd-r.el, lines 63-64:
> (ess-retr-lastvalue-command
> . ".Last.value <-
get(\".ess.lvsave\",inherits=TRUE)\n") ; envir=1
> which should be changed (as I have done on my machine) to:
> (ess-retr-lastvalue-command
> . "assign(\".Last.value\", .ess.lvsave,
envir=NULL)\n") ; package:base
> Here's an example of how things can go wrong:
R> find(".Last.value")> [1] "package:base"
R> 0+1> [1] 1
R> .Last.value> [1] 1
R> ?seq # At this point a stale copy of .Last.value is written to pos=1
R> 0+2> [1] 2
R> .Last.value # WHOOPS! WRONG
VALUE!> [1] 1
R> find(".Last.value") # The right value is masked by the
stale copy> [1] ".GlobalEnv" "package:base"
> Whenever I bring this up, a debate begins over who should change (ESS
> or R). In particular, my solution will not work if package:base is
> "sealed". Here's the tail end of our last discussion:
> Rich Heiberger <rmh@surfer.sbm.temple.edu> wrote:
>> ... The effect of sealing package:base from the user means that R will
have
>> to store .Last.value in .GlobalEnv, which is the place ESS is using.
This
>> in effect is your solution 2) Change R to store .Last.value in
.GlobalEnv
>>
>> Net result, ESS does not change behavior, R has already promised to
>> change behavior.
> and Kurt Hornik <hornik@mithrandir.hornik.net> replied:
>> Not at all. Sealing base does not mean that .Last.value needs to be
>> stored in the user's workspace. The standard approach would be to
use
>> dynamic variables which are in fact functions with internal state
>> (typically maintained in their environments). E.g., .libPaths() in R
>> 1.4 or better illustrates the idea. There might be a .Last.value()
>> along these lines. The most prominent example is options() which is
>> used for manipulating .Options (see also the R FAQ): this is currently
>> visible to the user but it really should not.
>>
>> Let me discuss our strategy re .Last.value with some r-core members.
> Also, Rodney Sparapani <rsparapa@post.its.mcw.edu> suggested:
>> I may be in way over my head here. But, I think there is a 4th
solution.
>> Have ESS save .Last.value as some other variable in .GlobalEnv like
>> .Last.value.saved. That way .Last.value would not be hidden, and it
could
>> still be retreived if someone had done a help() or whatever.
> Any more thoughts?
I had raised this issue with a couple of r-core people, but without
coming to a final conclusion. I think the underlying issue is rather
subtle: what is attempted by playing with .Last.value is somehow to
restore the 'state' of the system before ESS started 'invisibly'
interacting with it. I have no idea if this makes sense conceptually in
a multithreaded setting. (And the same applies to .Last.value, up to
some extent.)
I would actually prefer that we stop playing with .Last.value, and
document this. If not, David's suggestion about assigning in envir NULL
(i.e., the base package) is certainly preferable to what ESS
currently has, but will need to reviewed once name spaces are fully in
place.
-k
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._