[squeak-dev] unloadReloadablePackages

Frank Shearar frank.shearar at gmail.com
Mon Dec 30 13:18:05 UTC 2013


On 30 December 2013 12:47, Tobias Pape <Das.Linux at gmx.de> wrote:
>
> On 30.12.2013, at 12:05, Frank Shearar <frank.shearar at gmail.com> wrote:
>
>> On 29 December 2013 23:35, David T. Lewis <lewis at mail.msen.com> wrote:
>>> On Sun, Dec 29, 2013 at 08:02:51PM +0000, Frank Shearar wrote:
>>>> On 29 December 2013 19:34, Tobias Pape <Das.Linux at gmx.de> wrote:
>>>>> Dear Squeakers
>>>>>
>>>>> I give up.
>>>>> For roughly 6 hours I try to shrink my image using
>>>>>        Smalltalk unloadReloadablePackages
>>>>>
>>>>> It simply does not work currently.
>>>>> I have the said trunk image (Squeak4.5-13148#712) (NameVersion-Update#CIJob)
>>>>> but with the obsoletes removed as I explained a few emails ago.
>>>>>
>>>>> But to no avail.
>>>>> * Sometimes (!) ReleaseBuilder retains some obsoletes.
>>>>>  (removing the Obsoletes some time later with fixObsoleteReferences works, but
>>>>>   mostly not during unload)
>>>>> * same for VersionNumber-bla
>>>>> * SMLoader always retains obsoletes
>>>>> * Services-Base itches itself:
>>>>>  When its ServiceRegistry's #isInteractive was unloaded,
>>>>>  ServiceRegistry gets called again and calls #isInteractive
>>>>>  on its current, resulting in an DNU.
>>>>>  Issuing
>>>>>        Smalltalk at: #SystemChangeNotifier ifPresent: [:scn | scn
>>>>>                uniqueInstance noMoreNotificationsFor: ServiceRegistry].
>>>>>  manually works, but not as a #preambleOfRemoval.
>>>>
>>>> So it sounds like some packages' unload/reloads aren't being tested,
>>>> which is why they've now broken. I realise you've now given up :), but
>>>> did your explorations lead you through any #unload implementations?
>>>
>>> No it is not a matter of testing. It never worked in the first place, so
>>> it is an imcomplete implementation, not a bug.
>>
>> I don't think it's far off from being right though. I think Tobias has
>> simply found a bug: when an MCPackage unloads, it should run the
>> class-side #unload methods for any classes it contains, just like
>> loading runs the #initialize methods after loading the definitions.
>
> It does, when unloading the class definition
> (which subsequently calls Smalltalk>>#removeFromSystem: (or so)
> which in turn calls #unload on the class before removing) but too
> late, IMHO.
> The problem is, simply executing it at the beginning does not help
> because #unload would be called twice then…

Yes, but it's useless to call it then, because the things that it
calls are unloaded already. Unless I completely misunderstood what
you'd said?

Ah, and the calling-twice problem isn't strictly Monticello's fault,
is it? #unload gets called by Class >> #removeFromSystem:. And
#removeFromSystemUnlogged doesn't help, because the unload still gets
called.

I suppose if Monticello was smart enough to figure out that every
method definition for class Foo was being unloaded, and then Foo too,
so it need just #removeFromSystem: the class, then we wouldn't have
this problem.

Something like, in MCPackageLoader >> #basicLoad, in "Pass #4: Remove
the obsolete methods"

removals do: [:ea |
    ea isClassDefinition ifTrue: [ea unload]
   "Check the remaining removals to see if they still need to be done:
no point removing a method from a class that's just been removed"
    (ea isMethodDefinition and: [ea actualClass notNil]) ifTrue: [ea unload]].

Something like that, at any rate. The idea being that, like with
loading, we need to do something with the classes before we do things
with the methods.

frank

> Best
>         -Tobias


More information about the Squeak-dev mailing list