Once it gets going, a couple of simple invariants would seem to maintain
sanity.  Something like:

	1. There is always an active module that changes are going to.

	2. If you remove a module, you must also remove any parts of it that
are installed in the system.



-Lex


> I haven't found a nice way yet to do a sanity check, but attached is a =
> workspace doit that creates a dictionary mapping Class category names to =
> names of classes within each category which do not appear to be a part =
> of the Module system.  In my case, there are quite a few, about 109 =
> classes in dozens of categories, including some that look like they are =
> part of ModSqueak itself.  This map will at least give me some inroads =
> towards identifying things that may be missing as I try to port the code =
> over to VisualWorks.  I'd be curious to find out if anyone else notices =
> similar problems in ModSqueak, or if instead there is something that =
> I've missed while getting it running.