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.
Daniel
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>
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.
>
More information about the Packages
mailing list