On loading WxSqueak into a fresh 3.7

[Steven Swerling]

Hi,

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).

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.

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.
- 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.
- 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.
- 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.

[Rob Gayvert]

Post by Steven Swerling
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.

Post by Steven Swerling
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?

Post by Steven Swerling
Perhaps some interim steps are in order (but imminently deferrable).
- A package for all the base system extentions, called, say,
*wxextentions. Easy.

And most of this will probably go away with ToolBuilder.

Post by Steven Swerling
- 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.

Post by Steven Swerling
- 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.

Post by Steven Swerling
- 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.

[Steven Swerling]

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

That occurred to me. I didn't try it, though. My hunch was that it might
seem a bit strange. That's because shared pools resolve the problem by
making one class variable for *every* contant in the dictionary (browse
ZipConstants to see an example). Not sure what the impact would be at
runtime, pro or con. But during development, every time you clicked on a
class in the browser, it would likely take awhile to display the class
definition in the code pane. Not a deal-breaker, but it gave me pause.

Post by Rob Gayvert

Post by Steven Swerling
Perhaps some interim steps are in order (but imminently deferrable).
- A package for all the base system extentions, called, say,
*wxextentions. Easy.

And most of this will probably go away with ToolBuilder.

Yeah.

Post by Rob Gayvert

Post by Steven Swerling
- 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.

Just that the plugin is subclassed from SmartSyntaxPlugin, which is part
of VMMaker, itself a pretty hefty chunk. Nothing wrong with that (and
probably a lot is right). It's just that if the Wx classes that support
generation are in a separate package, it would make that much easier to
build a deployment image without them.

Post by Rob Gayvert

Post by Steven Swerling
- 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).

This is the money question. When you file in all the subclasses of
WxObject (and thus WxBase), a lot of the methods have constants from the
WxConstants dictionary. If WxConstants is nil at file-in, the constant
values in all the code of the subclasses is set to nil. Not sure why
this worked for me when I filed the changeset into my QuiteSmall image.
Either there is a difference between monticello and changesets in this
regard, or I made some mistake.

The ambitious thing to do would be to rewrite the initialization code so
that a full WxConstants dictionary and the other core constants dicts
are built *before* any of the classes that rely on them are filed in.
That's why I proposed a WxBootstrap package, a core set of classes
(maybe just WxLib and WxBase), with a hook to build all the core
constant dictionaries. After that is done, you can safely load in the
rest of the code.

This is all doable, it won't be a killer. But it's hard enough that
perhaps it should be deferred for now, just make people start with a
base image that has had all the constants initialized "by hand". The
WxSqueak classes are not tangled up in the way that, say, EToys is. So
drawing lines between the various pieces of Wx can be done later.

For Wx, the problem of building from a base squeak image mostly boils
down to getting all the constants properly initialized before loading
the code that uses those constants.