On loading WxSqueak into a fresh 3.7

[Rob Gayvert]

Steven Swerling wrote:

> I played around with trying to get Wx's mcz to load into a fresh 
> squeak 3.7, trying various strategies. Not that it's not doable, but 
> it's awfully slow going. Monticello seems to have a very hard time 
> with Wx, so the turnaround on each experiment or change is very long 
> (about 1/2 hour on my machine).

That's about what it takes to load a full change set into a fresh 3.7 
image, so I don't think it Monticello's fault, it's just a ton of code.

> MCZ files are still a good way to get new changes from Rob on an 
> already working system. The trouble with a fresh image is getting all 
> those constants initialized at the right time, and Monticello is not 
> able to be flexible when it comes to classes with pool dicts.

Is there a better way of handling all of the constants? Would using a 
SharedPool help in any way?

> Perhaps some interim steps are in order (but imminently deferrable). 
> Try to make 4 separate Wx monticello packages:
> - A package for all the base system extentions, called, say, 
> *wxextentions. Easy.

And most of this will probably go away with ToolBuilder.

> - A package for the plugin generation. This stuff has a dependency on 
> VMMaker, itself a rather large package, so it might be nice to 
> separate out from Wx proper. Probably pretty easy.

Yes, my intention was to make the code generation classes disposable. I 
need to see if there are any lingering dependencies.

> - A WxBootstrap package that just contains those few classes needed to 
> get filed in so that all the constants can be initialized. It's 
> necessary to initialize all the constants before all the subclasses 
> that access those constants get filed in. This is complicated by the 
> fact that some of the WxConstants are objects from the Wx sub 
> hierarchy (like a WxColour for wxBlack). Very hard.

Do things like wxBlack really need to be initialized, or just be present 
in the pool dictionary? My current change set simply sets the ones with 
object values to nil (in fact, all of the int values are bogus, and may 
vary by platform). All of the constants (ints and objects) get loaded 
from the plugin at startup time (WxBase initialize).

Would it help if the constants with object values were in a separate 
dictionary? I considered that, but didn't see any obvious advantage.

> - WxWidgets -- the rest of the classes. Easy.

> That's a lot, enough that I can see how you might want to just skip 
> it, say they have to get it all working "by hand" in a fresh image, 
> and just use monticello for updates.
>
> Anywho, I underestimated how hard it would be to generate a SAR file. 
> I didn't realize how hard it would be to handle all those constants 
> sitting in the Pool dictionary.