Splitting tools

[Dan Ingalls]

[I accidentally sent this to Modules, and am cross-posting this to the Packages list, since it seems that similar work is going on there as well.  My apologies if you get multiple copies -- Dan]

>On Tue, 1 Mar 2005 19:28:09 -0800, Dan Ingalls <Dan at SqueakLand.org> wrote:
>
>>Does such a tool exist right now?  If not, I think it would be a great aid to the project of partitioning the image.
>
>It certainly would. When I worked with VW last year, we had such a tool which greatly helped in determining prerequisites. First it would tell you what packages where needed, but it had a detail view that would tell you why these were needed.
>
>With that, we could in theory point at ToolBuilder and some 'favorite morphs' and start hacking away.


Folks -

I went back and tracked down my old code and messages to the Squeak list.  It is from February 2001 (!!) and I attach the summary below.  It turns out that most of the code is still in the image.  I haven't tested it, but I'd be happy to help anyone to fix it or use it.

The principle was extremely simple, and very few lines of code.
Here's an example of its use:
	Start with a set of "package roots", such as {Celeste. Scamper. MailMessage}.
	First establish the list of classes and methods that appear to be unused
		in the full system
	Then compute the same result but in the absence of the package roots.
	The *newly* inaccessible classes and methods presumably are only
		used by package roots, so they should be added to the package.
	Iterate the previous two steps until the package does not grow any more.

 The comments with update #3735 below give the excellent results achieved in deriving a package for the three network applications of the time.

This code all worked four years ago, and it was the basis for the preliminary partitioning in the Environments project.   I mainly wanted to point it out, in case it might be of use to people in partitioning the current image.  It may be entirely subsumed by Daniel V's MudPie but, if not, then it might save people some time.

Hope this is of some use.

	- Dan
-----------------------------------------


3735BetterShrink-di -- Dan Ingalls -- 27 February 2001
Introduces a new image partitioning tool that is essentially a local version of majorShrink.  The idea is to pick some application like Scamper, or some cluster like all the 3D classes, and remove it, and also remove everything that is solely referred to by it.  The way it works is:
	Record all unsent messages and unused classes at the outset
	Mark the application or cluster as removed
	Note all *newly* unreferenced methods and unused classes
		and iteratively remove them as well
For example, the expression
	Smalltalk reportClassAndMethodRemovalsFor: #(Celeste Scamper MailMessage)
reports 63 classes and 155 other messages that can be removed.
Also, introduces a new method, fileOutAndRemove:... that will take such results, build a changeSet from them, fileOut everything that is about to be removed, and then remove all of the classes and related messages as well.  For the above example, this method produces a 290k fileOut, and saves about 104k from the system.  More importantly, if you fileIn the changeSet afterward, the system returns to approximately its former size, and you can run Scamper again.  It's a way to fileOut a package that never existed.  Tools for Pools yet to come.