Andreas Raab wrote:
 > Nice analysis but there is really only one problem: By changing the
 > metaclass structure 3.9 breaks all projects that use eToys scripting.
 > This is a well-known problem and has really nothing to do with the
 > level of stability claimed for the project at SqueakMap - none of the
 > projects that were made for <3.9 will work in 3.9 proper if they
 > involve scripting.

I'm dubious that the VM should crash because of this. In fact, on 
further investigation, almost nothing in SqueakMap appears to work as 
intended. This includes installing e.g. LookEnhancements, or almost 
anything else (nothing I tried installed cleanly and worked, and a lot 
of things produced the recovery console thingie, although only the 15 
puzzle was able to provoke an actual direct abort).

If 3.9 is basically not compatible with the whole preexisting codebase 
(right down to its VM), then there's a serious problem. At minimim, 
SqueakMap on 3.9 should show a bright red alert on any package that 
won't be compatible. Given the indications that in fact none are 
compatible besides what comes with 3.9, perhaps SqueakMap needs to fork 
into the existing map and a new one for things that actually work in 
current and future versions of Squeak? With the 3.9 SqueakMap package 
loader showing the latter. Existing projects that are compatible (if 
any) would be copied over of course, and developers of packages that 
aren't compatible encouraged to update them.

A second problem is that I didn't find anywhere documenting this as a 
"known issue". There's no mention on the wiki or the main Squeak pages 
of this, and everything that mentions VM crashes indicates that they 
should be extremely rare and "unlikely to be triggered by Squeak code", 
among other things. (Experimental VMs notwithstanding.)

A Google search for squeak 3.9 "VM crash" turned up next to nil and no 
mention of 3.9 being incompatible with large chunks of the existing 
application base.

This should be documented more prominently. A particular problem is that 
a new user can very easily b0rk the entire system in the present state 
of things. Consider:
* A fresh install and running the default image produces a welcome page
   with a prominent link to open the package loader and encouragement to
   do so.
* Nothing (that I could find) in the package loader actually works with
   3.9 and, worse, they tend to screw the entire image up rather than
   simply not working themselves.
* The first item in the package loader, alphabetically, is -- you
   guessed it -- the 15 puzzle. The one that can actually outright crash
   the VM.

It's not hard to guess the results. And a non-techie is likely to 
conclude after a bit of fiddling that "this thing is quite unstable and 
not ready for primetime yet", although that actually only seems to be 
true if they use the package loader. :)

Of course, a non-techie might also make the mistake of loading a 
package, then (assuming things don't crash first) exiting and answering 
"yes" to the save prompt. If they simply unzipped Squeak 3.9 and then 
double-clicked the executable, as is likely, then they've probably just 
mangled the Squeak3.9-final-7067.image file and things won't work right 
without a reinstall. That is sure to make a good impression.

Recommendation: I'm not sure. If there's a simple tweak to 3.9 to 
restore back compatibility with older packages, the obvious, but if 
there's such a simple tweak it would probably have already been done. If 
there's not? I dunno...Boils down to a documentation/hide broken 
packages from the user type issue I guess.

P.S. I got suspicious at the length of time without a reply and checked 
the mailing list archives. That is the only place where your reply 
appeared. Suggest using "reply to all" to send to the user as well as 
the list. Also, list admins might want to look into a more complex munge 
of the addresses in the archives, as well. I could write a bot that 
parses "foo at bar.baz" as well as "foo at bar.baz" in a heartbeat and it's 
common enough now to be worth including such a feature in a harvester. 
I'm not that evil, but I'm sure there's someone equally capable that is, 
somewhere...