[squeak-dev] unloadReloadablePackages
Tobias Pape
Das.Linux at gmx.de
Mon Dec 30 13:21:41 UTC 2013
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?
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/2366538b/signature.pgp
More information about the Squeak-dev
mailing list
|