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

Martin Morgan m@rtin@morg@n @ending from ro@wellp@rk@org
Mon Jul 9 01:42:59 CEST 2018

On 07/08/2018 07:23 PM, Duncan Murdoch wrote:
> 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.

AssetPricing does, at least some of the time, in the body of a function 
(the indentation is confusing)

environment(vupdate) <- new.env()
environment(scrG) <- new.env()
environment(initx) <- new.env()
environment(cev) <- new.env()


so that assignment is to the unlocked new.env(). Presumably the new code 
assigns to bar's original environment, which is the (locked, once the 
package is loaded) package name space.

Martin Morgan

> 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
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

This email message may contain legally privileged and/or...{{dropped:2}}

More information about the R-package-devel mailing list