Next steps for MCP?

Daniel Vainsencher danielv at netvision.net.il
Mon May 26 12:03:21 UTC 2003


A few examples:

If Ned's connectors are loaded, then 
mma showPackageGraph
will draw the packages graph with their dependencies (including cycles).

mma showPackageDAGGraph
will draw the package components graph (that is with cyclicly dependent
parts of the graph unified into one node - creating a hierarchial
graph).

replacing "package" with "class" in the above will display each class as
a node, which is sometimes more useful if you haven't yet partitioned
your code into packages, and assuming small number of classes.

The graphs are not automatically layed out (just drag the nodes apart).
They can be using Neds graph aglo layout package, which does a
reasonable job on small graphs. Alternately, the code can output dot
files for the VizGraph package, which lays out and draws graphs quite
nicely (see the writeDotGraph: stuff.).

How does one initialize the MultiModuleAnalyzer (aka mma)?
MultiModuleAnalyzer onCategoriesWithPrefix: 'Morphic'
gives you one that focuses on the Class Categories that begin with the 
prefix. Since it uses PackageInfo to define package boundaries, class 
extensions related to those classes will be included in the analysis.

If you want to use a set of packages defined by yourself, do something 
like 
MultiModuleAnalyzer onPackagesNamed: #(Morphic Kernel) 

[SqueakLight]
Maybe you can replace some of your current removal code with actual
refactorings that keep the functionality usable. That would help make
Squeak naturally Light, which might be better for you long term...
whether SpT helps you do it or not.

Daniel

"Lic. Edgar J. De Cleene" <edgardec2001 at yahoo.com.ar> wrote:
> On 25/05/03 09:55, "Daniel Vainsencher" <danielv at netvision.net.il> wrote:
> 
> >> From what I've read of your snippet, it is a tool to do destructive
> > removal - in the sense that stuff is removed whether it is needed or
> > not. For example in this case, the *PropertyMorph stuff would be
> > removed, despite the fact that it is actually called by external methods
> > (which are shown to the user).
> > 
> > Which is a good way when you're trying to cut stuff out to get to a
> > specific subset that serves you. But when you want to preserve the
> > functionality (for example, Morphs should still be able to bring up
> > *PropertyMorphs), but in a form that is (un)loadable, you need to
> > perform manual refactorings.
> > 
> > SpT merely shows the paths of dependency clearly, so the human can
> > decide what refactorings to do. It also tests in the same way whether
> > the refactorings have made some components independently loadable.
> > 
> > Daniel
> Daniel:
> 
> Ok. I do more research .
> Yes , production of SqueakLight is still trial and error and destructive.
> Very thanks for you advice.
> Have you more examples for your Spaghetti tracer code ?
> 
> Cheers.
> Edgar
> 
> 
> Edgar



More information about the Squeak-dev mailing list