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.