[R-pkg-devel] Puzzled about "locked environments".

[Duncan Murdoch]

On 08/07/2018 6:57 PM, Rolf Turner wrote:
> 
> Recently I experimented with assigning a variable within the environment
> of a function in a package that I am developing.  Slightly more explicitly:
> 
> In a function "foo()" in the package, I have lines like:
> 
>      big <- 42
>      assign("big",big,envir=environment(bar))
> 
> where "bar()" is another function in the package.
> 
> This causes an error to be thrown:
> 
>> Error in assign("big", big, envir = environment(bar)) :
>>    cannot add bindings to a locked environment
> 
> The reason that I am puzzled about this is that I used this syntax
> repeatedly in my CRAN package "AssetPricing".  In this latter package
> the syntax seems to work flawlessly.  No errors are thrown.  No mention
> of "locked environments".
> 
> Why would environments get "locked" in the package that I am currently
> fooling about with, but not in the AssetPricing package?  Is there
> anything that I  can do to keep environments from getting "locked"?

It may be the timing.  When R is installing a package, it executes all 
of the code in the .R files (which has been consolidated into one file, 
but that doesn't matter).  This produces all of the objects and 
functions in the package.

Then it locks the environment, so that things don't change.

Then it compiles the functions.  If they were allowed to change, then 
the compilation would have to be redone.

So perhaps AssetPricing makes the change in the .R file, processed 
before locking, and your new package does it in a function, executed by 
the user after locking.

Or maybe not.

Duncan Murdoch

> 
> Can anyone suggest where I should start looking for differences in the
> nature of the two packages?
> 
> I could possibly give more detail, but I have no idea as to what might
> be relevant.
> 
> One difference is that AssetPricing involves no dynamically loaded
> Fortran code, whereas the package that I am currently fooling about with
> *does* involve such code.  (But neither "foo()" not "bar()" make direct
> calls to .Fortran().)
> 
> Grateful for any insights.
> 
> cheers,
> 
> Rolf Turner
>