Andreas knows alot more about one way of reading your question - he's
built small images, he knows what will definitely go out, and what's
harder to live without.

Reading your question as "What does this Spaghetti Tool do for me?"-
First, it will give you an answer to the question "what will require
refactoring or thought to remove? what can definitely be removed?" - The
critical stuff is simply the strong component that includes Object, plus
everything they reference (but that shouldn't add much, because if it is
referenced by the component, and inherits from Object, it is part of the
component).

Second it will give you answers to question like "I want to partition
some piece of code (say, the image, or a specific project), so that each
layer can be removed, in it's turn, from the top down. In the current
partition, what makes that impossible?"

Concretely, I can find out automatically that the Refactoring Browser UI
can't be removed from the package, despite being the obvious logical top
layer, because actually, it is referenced by the BrowserEnvironments and
Refactoring classes. I will also get specific reference paths, so I know
what I need to deal with. Then I need to either refactor the code, or
shift the borders, so those upward references are no more.

Note that the references given are only examples, not exhaustive lists
(I don't have a good idea on how to do this, yet), so this doesn't
directly tell you what will be needed. You can get that answer only
indirectly.

The nice thing is that it can *help* you get this answer - you could
very easily adapt this tool to help you with dealing with the whole
image. Here's a pretty practical recipe:
1. Use Andreas' advice to find all the classes that the VM or the
completely basic model of Squeak will require. Move them to a specific
System Category, like Base-VM-Requirements.
2. Now think about it like this - you need to make your strong component
that includes Object live completely in the Base* categories. Start by
seeing what other categories are in your strong component.
3. Now start targeting them for handling, one by one. You can do this by

 - pulling a class or category into Base (drag&drop the class, rename
the category, adding the prefix Base).
 - Find the reference paths to a category using SpTracer, and delete
methods in Base that reference classes outside it (noting what you're
breaking in the process).
 - For critical functionality used by Base (debugging), reimplement
minimally (stack dump) using only things in Base.
4. Rerunning the analysis to update your graph. You want to look at the
size of your strong component, and how many classes outside base are
part of it, as your source of feedback. When it's zero, you're almost
done. If the image startup code is in Base, after loading, this image
should never leave Base. You can delete everything else, or leave it as
optional fluff, or use only via dynamic registries, so it is there, but
optional.

Daniel

PhiHo Hoang <phiho.hoang at rogers.com> wrote:
> Thanks, Daniel. I went through all the examples now without a problem.
> 
> I looked at the samples, and tried to answer my question:
> 
>     'If I want to have an image with just two objects Metaclass and
> ProtoObject,
>     what other objects are also needed to build a self sufficient community'
> 
> So far I have not yet found what I am looking for.
> 
> Please find appended the exercises I did.
> 
> Any pointers to how to get at the answer is very much appreciated.
> 
> Cheers,
> 
> PhiHo.
> 
> Excercises:
> 
> graph := CodeGraphCreator graphForClassesAndExtensions: Smalltalk allClasses
> a GraphAdapter.
> 
> 1/-
> CodeAnalyzer referencePathBetweenClass: Metaclass andClass: ProtoObject in:
> graph
> 
> result set :
>  an OrderedCollection(a MethodReference Metaclass >> allInstances a
> MethodReference Array >> asSingleton a MethodReference Singleton >>
> superclass)
> 
> 2/-
> CodeAnalyzer referencePathBetweenClass: ProtoObject andClass:  Metaclass in:
> graph
> 
> result set :
> an OrderedCollection(a MethodReference ProtoObject >> ifNotNil: a
> MethodReference Array >> objectForDataStream: a MethodReference DiskProxy >>
> comeFullyUpOnReload: a MethodReference DataStream class >> initialize)
> 
> 3/-
> GraphAnalyzer new shortestPathFrom: {#ProtoObject} to: {#Metaclass}  in:
> graph
> 
> result set :
> #(#ProtoObject #Array #DiskProxy #DataStream #Metaclass)
> 
> 4/-
> GraphAnalyzer new shortestPathFrom:{#Metaclass} to:  {#ProtoObject}  in:
> graph
> 
> result set :
> #(#Metaclass #ClassBuilder #Object #ProtoObject)
> 
> 5/- How do I do something like 4/- for 'Metaclass class' and 'ProtoObject
> class' ?
>     Syntactically, how do I specify 'Metaclass class' and 'ProtoObject
> class'
>     in place of 'Metaclass' and 'ProtoObject', respectively.