[R-pkg-devel] [FORGED] Re: Puzzled about "locked environments".
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
>>> In a function "foo()" in the package, I have lines like:
>>> big <- 42
>>> 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.
More information about the R-package-devel