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

Rolf Turner r@turner @ending from @uckl@nd@@c@nz
Mon Jul 9 02:29:10 CEST 2018

Thank you hugely.  Your suggestion nailed it.  I was *sure* that I
had tried doing

    environment(bar) <- new.env()

prior to doing the assignment and that it didn't help.  I was also sure
that in AssetPricing I done assignments into environments that *weren't* 
new.  Wrong on both counts. :-(  Jeez, it's tough being mentally 

Thanks very much for delving into this and for looking at the code in 
AssetPricing more carefully and perspicaciously than I did.



On 09/07/18 11:42, Martin Morgan wrote:
> 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()
> #
>      assign("dS",dS,envir=environment(vupdate))
>      assign("dS",dS,envir=environment(scrG))
>      assign("dS",dS,envir=environment(initx))
>      assign("dS",dS,envir=environment(cev))
> 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.

More information about the R-package-devel mailing list