splitting tools

Daniel Vainsencher danielv at techunix.technion.ac.il
Tue Mar 8 01:35:59 UTC 2005

Just a note here:
The tool Dan describes here, AFAIU, allows one to determine what can be 
removed after a named set of categories is removed. IIUC, this is useful 
after the named categories are themselves removable (not depended on by 
other stuff).

MudPie can be used before that, to see what depends on what, and 
therefore what is preventing your package from being removable.

So they seem to me to be complements.

I've updated the SqueakMap version of MudPie to work on Squeak 
3.9+Connectors 2.2.


Dan Ingalls wrote:

 > [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> 
 >>> 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. 
 >     First establish the list of classes and methods that appear to be 
 >         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 
 > 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 
 > 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.

More information about the Packages mailing list