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

[Rolf Turner]

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 
handicapped!

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

cheers,

Rolf

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.