[squeak-dev] Towards SqueakCore

Frank Shearar frank.shearar at gmail.com
Tue Feb 12 13:40:21 UTC 2013


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.

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'.
>
>
>>
>
>


More information about the Squeak-dev mailing list