[squeak-dev] unloadReloadablePackages

Frank Shearar frank.shearar at gmail.com
Mon Dec 30 13:56:54 UTC 2013


On 30 December 2013 13:55, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 30 December 2013 13:46, Tobias Pape <Das.Linux at gmx.de> wrote:
>>
>> On 30.12.2013, at 14:41, Frank Shearar <frank.shearar at gmail.com> wrote:
>>
>>> On 30 December 2013 13:21, Tobias Pape <Das.Linux at gmx.de> wrote:
>>>>
>>>> On 30.12.2013, at 14:18, Frank Shearar <frank.shearar at gmail.com> wrote:
>>>>
>>>>> 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?
>>>>>
>>>>
>>>> Yep, thats why unload couldn’t be called, because its gone already :(
>>>>
>>>>> 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.
>>>>
>>>> Exactly.
>>>>
>>>>>
>>>>> 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.
>>>>
>>>> Problem here: are all system notifications sent for each method to be
>>>> removed?
>>>
>>> I figured there'd be loads of things I didn't think of, which is why I
>>> hedged with "something like that" :) You're right. The above won't
>>> send the notifications for these removed methods, because Environment
>>>>> #forgetClass:logged: only notifies of the class removal. But then,
>>> this is what happens when you remove a class normally. If we want to
>>> start notifying of method removal on class removal, we should change
>>> Behavior >> #obsolete to do the notifying.
>>
>> Bad idea.
>> Obsoletion also happens on other occasions, eg, giving a class a new
>> instVar. The old class w/o the inst var is obsoloeted and all methods
>> are “moved” to the new.
>
> I don't think so. ClassBuilder builds a new class with the new shape,
> and copies over the old class' method dictionary. (See ClassBuilder >>
> #newSubclassOf:type:instanceVariables:from:. I don't see the old class
> being asked to #obsolete itself there.
>
>>   Notifying about method removal would be misleading if not plain wrong.
>
> Yes, if changing a class's shape does indeed cause the old version to
> become obsolete.
>
> At any rate, I'm wondering whether removing a class _normally_ causes
> notification of the removal of all its methods. If not (do we have
> tests for this?), then #basicLoad above doesn't need to do anything
> special.

(I forgot to add: we could write Monticello tests a bit more
easily/cleanly if Monticello-fbs.581 got reviewed and pushed to Trunk.
Just saying :)

frank
>
>> Best
>>         -Tobias
>>
>>
>>


More information about the Squeak-dev mailing list