On 10 February 2013 00:43, David T. Lewis lewis@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.
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'.