unloadReloadablePackages
Locked
unloadReloadablePackages
 
|
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. And now I gave up. If someone has, pleas send me a stripped image. Tanks. Best -Tobias . |
signature.asc (1K)
Re: unloadReloadablePackages
|
|
Re: unloadReloadablePackages
|
|
On 29.12.2013, at 21:02, Frank Shearar <[hidden email]> wrote: > On 29 December 2013 19:34, Tobias Pape <[hidden email]> 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? all this is called. The problem is here: The unloading works via Monticello with will: * Create an unloading path by comparing the package to an empty one * That way, It gets all necessary removal. * It then carries out the removals. * However: * The method removals come first * then the class removal * then categories.. The #unload is executed during the class removal phase, which means that even if ServiceRegistry had an #unload, it won't be triggered in time. I tried that just now: * add ServiceRegistry class>>#unload 1 halt. Unload ServiceRegistry. > DNU. > >> And now I gave up. If someone has, pleas send me a stripped image. >> Tanks. > > If I get anywhere on the problem, you'll be the first to know! :) Best -Tobias |
Re: unloadReloadablePackages
|
|
Re: unloadReloadablePackages
|
|
Re: unloadReloadablePackages
|
|
On 30.12.2013, at 12:05, Frank Shearar <[hidden email]> wrote: > On 29 December 2013 23:35, David T. Lewis <[hidden email]> wrote: >> On Sun, Dec 29, 2013 at 08:02:51PM +0000, Frank Shearar wrote: >>> On 29 December 2013 19:34, Tobias Pape <[hidden email]> 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. (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… > > This is the script I used to shrink my trunk base originally: > > #('39Deprecated' > '311Deprecated' > '45Deprecated' > 'Nebraska' > 'SmallLand-ColorTheme' > 'ST80' > 'ST80Tools' > 'SystemReporter' > 'ToolBuilder-MVC' > 'Universes' > 'XML-Parser') > do: [:pkgName| > (MCPackage named: pkgName) unload. > MCMcmUpdater disableUpdatesOfPackage: pkgName]. > > Smalltalk cleanUp. > > Note how it's almost identical to Chris', except that he routes > unloading through Installer. Note, however, that this script also > doesn't call #unload. IIRC, that's pretty much the only difference > between this and the old ReleaseBuilder logic. I deliberately pushed > all that unloading logic into the packages (read: classes within the > packages) themselves. But I didn't know that MC wouldn't run the > #unloads... -Tobias |
Re: unloadReloadablePackages
|
|
Re: unloadReloadablePackages
|
|
On 30.12.2013, at 14:18, Frank Shearar <[hidden email]> wrote: > On 30 December 2013 12:47, Tobias Pape <[hidden email]> wrote: >> >> On 30.12.2013, at 12:05, Frank Shearar <[hidden email]> wrote: >> >>> On 29 December 2013 23:35, David T. Lewis <[hidden email]> wrote: >>>> On Sun, Dec 29, 2013 at 08:02:51PM +0000, Frank Shearar wrote: >>>>> On 29 December 2013 19:34, Tobias Pape <[hidden email]> 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. 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. removed? Best -Tobias |
Re: unloadReloadablePackages
|
|
Re: unloadReloadablePackages
|
|
On 30.12.2013, at 14:41, Frank Shearar <[hidden email]> wrote: > On 30 December 2013 13:21, Tobias Pape <[hidden email]> wrote: >> >> On 30.12.2013, at 14:18, Frank Shearar <[hidden email]> wrote: >> >>> On 30 December 2013 12:47, Tobias Pape <[hidden email]> wrote: >>>> >>>> On 30.12.2013, at 12:05, Frank Shearar <[hidden email]> wrote: >>>> >>>>> On 29 December 2013 23:35, David T. Lewis <[hidden email]> wrote: >>>>>> On Sun, Dec 29, 2013 at 08:02:51PM +0000, Frank Shearar wrote: >>>>>>> On 29 December 2013 19:34, Tobias Pape <[hidden email]> 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. 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 |
Re: unloadReloadablePackages
|
|
Re: unloadReloadablePackages
|
|
Re: unloadReloadablePackages
|
|
| Free forum by Nabble | Edit this page |