Unloading packages with Environments (was Re: [squeak-dev] Re: Towards SqueakCore)

Frank Shearar frank.shearar at gmail.com
Tue Apr 2 13:45:47 UTC 2013


On 2 April 2013 10:35, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 1 April 2013 23:06, Colin Putney <colin at wiresong.com> wrote:
>>
>>
>>
>> On Mon, Apr 1, 2013 at 2:07 PM, Frank Shearar <frank.shearar at gmail.com>
>> wrote:
>>
>>> Right. That tells me there's an Alias still pointing to the XMLWriter
>>> class. So my half-baked theory is that something's missing in the
>>> Environment work and how it integrates with Monticello?
>>
>>
>> I don't think that's it. I mean sure, Environments is incomplete and buggy,
>> but the behaviour you describe can happen in Squeak 4.4 too. If there are
>> any instances of XMLWriter when you unload the class, they get migrated to
>> obsolete instances. The thing to do is, as Eliot suggested, figure out
>> what's pointing to them and how to sever those references before you unload
>> the class.
>
> And what's pointing to the class is an Alias. In a normally updated
> image (one in which XML-Parser has not been removed, PointerFinder
> shows a single path to XMLWriter:
>
> CLASS: SmalltalkImage class
> superclass: Object class
> subclasses: Array
> 383: XMLWriter class
>
> If I hack Environment >> #forgetClass:logged: and Environment >>
> #removeClass: to dump their arguments to the Transcript I can see that
> they're called. This invalidates my Environments-Monticello
> integration hypothesis: the bug, whatever it is, lies in Environment.
> After an unload (Monticello browser, right click, unload),
> PointerFinder on: XMLWriter says:
>
> globals: Environment
> bindings: IdentityDictionary
> array: Array
> 1301: Alias
> source: Association
> value: AnObsoleteXMLWriter class
>
> Of course, you should not even be able to evaluate "PointerFinder on:
> XMLWriter" - the class is supposed to be gone, and you should be told
> "there's no such class".
>
> So my next hypothesis is that unloading the package doesn't remove the
> association from the top level Environment's bindings instvar.

uSo it _looks_ like Environments has a slight case of split brain: the
contents and bindings instvars seem to do the same job (inspecting
"Environment default" and looking at the contents of contents and
bindings), and it looks like we're moving things over to bindings
(#assocationAt: pulls stuff out of contents, while
#associationOrUndeclaredAt: is more recent, and pulls stuff out of
bindings. #migrate copies contents' contents into bindings).

Does that sound like a fair assessment? If so, I suspect that we
simply haven't pushed the migration far enough yet.

> frank
>
>> Colin
>>
>>
>>
>>


More information about the Squeak-dev mailing list