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

R. Michael Weylandt michael.weylandt at gmail.com
Thu May 17 01:09:30 CEST 2012


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?
[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.

Thanks again,
Michael

>
> Cheers,
> Simon
>



More information about the R-SIG-Mac mailing list