VM crash, reproducible, involving 15-Puzzle 1-1.1
John Ersatznom
j.ersatz at nowhere.invalid
Wed Jan 10 21:17:09 UTC 2007
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...
More information about the Squeak-dev
mailing list
|