[squeak-dev] unloadReloadablePackages

David T. Lewis lewis at mail.msen.com
Mon Dec 30 15:54:10 UTC 2013


On Mon, Dec 30, 2013 at 11:05:47AM +0000, Frank Shearar 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.
> 

I did not look at any of the packages other than ST80, but that one is
nowhere close to being complete. I cannot speak to any of the others.

Try removing ST80 from an image that has one or more MVC projects and you
will see some of the issues. I did not look into it any further than this
because it was apparent that the original cleanup code was simply missing.
That's why I was suggesting to restore the original method and mark it as
deprecated.

Dave



More information about the Squeak-dev mailing list