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.
Obviously, an easy work-around is to check with bindingIsLocked().
That said, I have added a very, very ugly hack to work around your case in the
GUI.
Cheers,
Simon
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
