On 10 July 2013 20:44, David T. Lewis <lewis at mail.msen.com> wrote:
> On Wed, Jul 10, 2013 at 07:21:56PM +0100, Frank Shearar wrote:
>> On 10 July 2013 19:02, Colin Putney <colin at wiresong.com> wrote:
>> >
>> >
>> >
>> > On Wed, Jul 10, 2013 at 6:52 AM, Frank Shearar <frank.shearar at gmail.com>
>> > wrote:
>> >
>> >>
>> >> Er, so should we ever have classes with a nil environment? Is my
>> >> proposed change a stinky hack, or the right thing to do to lazily fix
>> >> the issue?
>> >
>> >
>> > We should never have classes with a nil environment.
>>
>>
>> OK, that's what I thought. But I have such an image. In fact, I
>> daresay that every alpha image produced in the 4.5 line has for months
>> and months had such classes. Making #declare: use the #environment
>> method instead of directly accessing the instvar "solves" the problem
>> - Morphic-fbs.633 will load - but I have no idea if that's a good
>> solution, or a bad, bad bandaid.
>>
>
> I have run into the nil environment problem in the course of updating
> images from trunk, so I suspect there is or was some kind of problem
> at some point. I worked around it manually in the update whenever a
> debugger popped up. The "fix" was to look at the class in the debugger,
> and do "environment := Array environment" (I used Array, but it could
> be any class that does have its environment set properly).
>
> That seemed to work but I'm sure there must be a better way to do it.
> Is there something we should put into the trunk update stream so that
> other people don't get stuck on the problem during updates?
>
> Dave

I sort've expected to see an explicit assigning of environments
somewhere. But Environment class >> #install doesn't do this. It
inserts itself in Smalltalk globals' place, which is great if a (class
instVarNamed: 'environment') == Smalltalk globals. But if a class'
environment was already nil, installing Environments would not have
touched the instvar, leaving busted state. (As in, leaving busted
state in the same, busted, state.)

frank