Hi Phiho and all!

Quoting PhiHo Hoang <phiho.hoang at rogers.com>:
> Hi Goran,
> 
>     Ned wrote:
> 
> <QUOTE>
> 
> One thing that I thought was conspicuous by its absence is dependency
> information (including links to other SqueakMap entries). I realize
> that Modules will try to deal with dependencies, but pre-Modules need
> to tell people about this as well. And even with Modules code, it
> would be useful to take the internal dependency information and make
> it available in the SqueakMap interface (so I can get a package and
> its prerequisites if I want).
> 
> </QUOTE>
> 
>     I fully agreed with this. And since the name is SqueakMap, I would
> love
> to see the map for Squeak 3.2 itself. Each class is to be displayed with
> an
> ordered set of of immediate classes that it depends on.

Hehe, well, the name may imply a map of the classes in Squeak but that was
unintentional. Later, when the image gets separated into Modules we should
probably (as Ned proposed and that I have intended) let SqueakMap "scan" the
Modules it knows about (this can be done regularly or on request) and always
have updated dependencies to display. Since SqueakMap also knows about the
repositories it could actually also discover new Modules without having someone
registering them - that would probably be nice at least for the "base image
Modules".

But anyway - that would be dependencies between Modules, not classes.

>     Is this already implemented ? If not, would you consider this as a
> feature request :-)

Well, if what I describe above (map of modules, not classes) is fine then that
is already on the "drawing board". But I am not sure how a more detailed map
should be calculated/displayed?

Daniel has also sent me some nice code (Yes, I haven't forgotten!) that
calculates a few interesting things on a 3.3a image which I will try to include
into SqueakMap turning it also into some form of "bleeding edge status display"
regarding the work if splitting the image into Modules.

But I will probably have to run that in a parallell 3.3alpha-image that
autoupdates itself continuosly from the alpha stream and then let the SqueakMap
master image load the info from it using a common file or something.

>     Actually, I would love to look at the script more than the display
> :-)

I will post the latest code on SqueakMap later this weekend. It consists mainly
of two class categories, one for the SqueakMap itself (the domain model) and one
for the web frontend (using HttpView). The domain model does not depend on
anything else than regular Squeak. The webfrontend is written using HttpView
which only depends on Comanche (but can be used with any Squeak webserver
actually). The missing part is a Morphic SqueakMap browser, but I want to
"finish" the domain model and the web frontend first.

regards, Göran

Göran Hultgren, goran.hultgren at bluefish.se
GSM: +46 70 3933950, http://www.bluefish.se
\"Department of Redundancy department.\" -- ThinkGeek