Hi, Jerry -

I'm taking the liberty of CC'ing the Squeak List, as we may find a couple of other enthusiasts.

>I am currently hacking a new majorShrink; I'm down to taking out Classes which seem to 
>be extraneous (and then finding that they're tightly bound into new stuff 
>somewhere :-) ). I have an image which is a bit over 1MB. This seems a bit 
>much, as I had an 803 KB image for 2.8. The last (massive) wave of 2.9 
>changes introduced many new things, and I had just begun a shrink effort on 
>these when you released 3.0. 
>
>Let me bang on what I have for another day, and then I'll send you a sample.

That would be great.

>MVC shrink)   I would love to work together on this. Just hacking majorShrink 
>is fine, but would like to see what could be done with a more sensitive 
>dependency mechanism (i.e., components) in the future.

Yes, no time for that before 3.0 closes, though.

>I can certainly have something "shippable" by Thursday, but in 
>any case, I'll be glad to send you things in whatever state tomorrow for 
>suggestions.

That would be great.  Thanks for your enthusiasm.

>Morphic shrink)   I guess I have some question as to what goes into a minimal 
>Morphic image. If it were simply a Smalltalk development system, I'd love to 
>give it a try. However, I assume that some Morphic development capabilities 
>would be necessary. I'd love to hear what you have in mind.

Well, at the risk of bringing you to a complete halt, here is what I would consider a decent (or at lest fun) non-network, non-3D suite (similar to majorShrink but with more fun to rationalize the extra space):

	All the games
	MidiScore player with Piano Roll and FM envelope editor
	The development system and PDA
	Projects

A much more content-oriented suite would be
	Etoy painting, viewers, scripting
	Projects

Then... Here's what you do (but don't get into this until you deliver MVC majorShrink;-).  Look at ImageSegment discoverActiveClasses.  Run this (it puts method dictionary faults in all classes), then exercise the suite, quit, resume, and then print IS activeClasses (it notes all classes that still have faults, and thus were never touched.).  THEN throw out every class that wasn't active, and run the removeUnsentMessages loop at the end of majorShrink.  This would be an interesting benchmark. 

Happy hunting

	- Dan