On 2/10/13, 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.

Yes.

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

Yes, the question is how do we define success (i.e. construct a test)
for a use case like

1) take the full image
2) unload a package
3) reload the package
4) check if we the full image is still OK


 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.

Yes,

> I'm not so keen on the idea of just unloading things without some
> mechanism to verify that they stay reloadable.

Sure, I understand that Frank wants the same thing.

He indentified


    XML-Parser and Nebraska

as candidate for unloadable packages.



That's a fast track
> to bit rot.

I think the way out is to keep the current full image and construct
tests for unloading and reloading which can run on Jenkins.


--Hannes


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