[R-SIG-Mac] .First for R.app called twice?

[Simon Urbanek]

On May 16, 2012, at 7:09 PM, R. Michael Weylandt wrote:

> On Wed, May 16, 2012 at 3:04 PM, Simon Urbanek
> <simon.urbanek at r-project.org> wrote:
>> On May 16, 2012, at 1:10 PM, R. Michael Weylandt wrote:
>> 
>>> Suppose I have the following very simple ~/.Rprofile
>>> 
>>> .First <- function(){
>>>    assign("e", exp(1), .GlobalEnv)
>>>    lockBinding("e", .GlobalEnv)
>>> }
>>> 
>>> If I start R from the terminal, all is fine, but if I use R.app this
>>> throws an error about not being able to change the assigned value of a
>>> locked binding on "e". This makes me think that R.app hits .First()
>>> twice -- is that the intended behavior? [You can demonstrate this with
>>> cat() statements more directly, but I figured I'd show a use case]
>>> 
>>> I don't have access to another computer right now to confirm, but the
>>> difference between Terminal and R.app seems funny. If it seems to be a
>>> problem with my machine, I'll hunt further.
>>> 
>> 
>> It is somewhere between intention and a bug. It is caused by the necessity of the R.app GUI to deal with launches in a different working directory -- e.g. when you drag a folder on the GUI. Because the GUI has to setup R and start the event loop before it can accept open events it emulates the regular R behavior after receiving the open event by starting R with --no-restore-data first and then loading the workspace "by hand" and running .First(). This is all fine if you use your workspace to populate .First, but if you do that in .Renviron then .First gets called twice: first when R starts without a workspace and then by the GUI because it doesn't know that your .First does not come from the loaded workspace.
>> 
>> 
> 
> Thanks for your note, Simon. I think that I understand, but I'll dig around in the source just to make sure. I'm likely revealing my ignorance here, but is there any reason one or the other loads couldn't run as R --vanilla or with the interactive() flag turned off?

No, since the GUI is interactive -- note that the GUI doesn't do anything to the R afterwards. If we did not support changing working directories on document open we could start R without any flags. Another possible "fix" would be to run R with --no-profile and source it by hand, but I already feel bad about the somewhat strange sequence and the user typically wants to run .Rprofile from the home directory and not the dropped one.


> [My actual .Rprofile has the whole thing wrapped in
> if(interactive()){} to avoid trouble in R CMD .... scenarios] This
> might be a nonsense suggestion though -- I don't really use R other
> than starting a fresh workspace each time so I've never really thought
> through how that would be managed.
> 
>> Obviously, an easy work-around is to check with bindingIsLocked().
> 
> Hadn't thought of this -- I'll add it to my .Rprofile
> 
>> 
>> That said, I have added a very, very ugly hack to work around your case in the GUI.
> 
> Don't uglify the code base on my account, particularly when such an
> easy fix is available and I use the Terminal so much more.
> 

The only reason I called it a hack is that we need to store a copy of the first .First so we can compare it after the workspace is loaded. But at least this way .First is guaranteed to run once (unless you change .First in .First() in which case it will still run twice anyway ...) - so it may not be that bad ;).

Cheers,
Simon




> Thanks again,
> Michael
> 
>> 
>> Cheers,
>> Simon
>> 
> 
>