[squeak-dev] unloadReloadablePackages

Tobias Pape Das.Linux at gmx.de
Mon Dec 30 13:46:05 UTC 2013


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.
  Notifying about method removal would be misleading if not plain wrong.

Best
	-Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1665 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131230/a8f1ba34/signature.pgp


More information about the Squeak-dev mailing list