On Tue, Feb 12, 2013 at 01:40:21PM +0000, Frank Shearar wrote:
> On 10 February 2013 00:43, David T. Lewis <lewis at mail.msen.com> wrote:
> > On Sat, Feb 09, 2013 at 11:51:21PM +0000, Frank Shearar wrote:
> >> In the interests of revisiting Pavel Krivanek's work, and a long term
> >> goal of this community, I thought I'd use the Dependency Browser and
> >> dig out interpackage dependencies.
> >>
> >> By scraping the DependencyBrowser's contents together with a bit of UI
> >> scripting I've constructed a dotfile of Trunk (attached). Turning this
> >> into a PNG results in an 11MB image! [1] Nodes near the top are nodes
> >> that aren't used by many things.
> >>
> >> For instance, ReleaseBuilder's right at the top because nothing depends on it.
> >>
> >> One thing to note is that XML-Parser and Nebraska are only used by
> >> Universes, and that Universes isn't used by anything else.
> >>
> >> It occurs to me that we could thus remove these 3 packages from trunk
> >> and add the loading of these to ReleaseBuilderFor4dot5 [2], and still
> >> end up with a 4.5 that while apparently unchanged, actually has a
> >> smaller core.
> >>
> >> What do you think of trying this out as an experiment? How would we
> >> unload these packages? (I should note: I've nothing against these
> >> packages. They're just packages that aren't woven into the guts of the
> >> image, and are thus easily removable.)
> >
> > I would prefer to see the experiment focus on *reloadable* packages,
> > in the sense of SmalltalkImage>>unloadAllKnownPackages, where the
> > unloaded packages are supposedly distinct enough that they can be
> > reloaded after having been removed from the image. Success would
> > be defined as being able to unload a package, reload it, and verify
> > that the image is equivalent to what you started with. I think that
> > the packages you identified are probably good candidates for an initial
> > experiment with this.
> >
> > If we had some way to actually test that reloadable packages stay
> > that way over time, presumably with the help of Jenkins, it would be
> > a really good thing. I'm not entirely sure how to test for this, but
> > it would be very worthwhile if someone could figure it out. I think
> > that a verifiable set of truly reloadable packages would go a long
> > way toward improving modularity.
> >
> > I'm not so keen on the idea of just unloading things without some
> > mechanism to verify that they stay reloadable. That's a fast track
> > to bit rot.
> 
> I don't see how you're disagreeing with me. I realised after my
> initial post that the packages I'd taken as examples are actually
> unloadable, in the sense that they're in the list in
> #unloadAllKnownPackages.

I'm not disagreeing with you :)

Dave

> 
> What I'm suggesting is the inverse of #unloadAllKnownPackages: strip
> these out of Trunk, and add them in as part of preparing a release.
> The only difference to the current Trunk then - in theory - is that
> we'd want to take a ReleaseTrunk artifact and run all its tests
> (because the SqueakTrunk job obviously wouldn't run the tests).
> 
> Or, we expand the ExternalPackage-Foo jobs to cover all the packages
> added by the ReleaseBuilder.
> 
> (One problem: Installer's marked as being unloadable, and it's
> probably one of the last packages we'd want to unload. The
> ExternalPackage-Foo scripts I'm writing use Installer. But then, I
> could always have those scripts load Installer as a prerequisite.)
> 
> frank
> 
> >> frank
> >>
> >> [1] If you have dot installed, `dot -Tpng -o trunk-deps.dot
> >> trunk-deps.png` will do the trick.
> >
> > I think you meant 'dot -Tpng -o trunk-deps.png trunk-deps.dot'.
> > Nice picture :)
> >
> >
> >> [2] Installer squeak
> >>       package: 'trunk';
> >>       install: '39Deprecated-ar.19';
> >>       install: '311Deprecated-nice.2';
> >>       install: 'XML-Parser-ael.35';
> >>       install: 'Nebraska-ul.35';
> >>       install: 'Universes-nice.45'.
> >
> >
> >>
> >
> >