> When in emergency evaluator,
 >
 > Smalltalk snapshot: false andQuit: true
 >
 > might do what you want. All class changes and method changes are
 > already  in the .changes file and can be recovered easily using
 > existing tools.
 >
 > HTH.
 >
 > /Klaus

Recovered how?

Someone else mentioned using Monticello for version control. That is 
what I had been doing in fact, but I hadn't actually had it export 
anything yet, since of course I didn't have anything usable yet, and I 
don't want to be at "version 56" of something before it's even finished 
(normally, a basic finished product is version 1 is it not? :))

This situation indicates a more general issue with the entire system. 
There are clear advantages to combining the development environment and 
the run-time environment, but there are clear disadvantages too, such as 
that things going wrong can b0rk the debugging tools and development 
environment. That the normal defensive practise of frequent saves with 
ctrl+S doesn't really protect you is another issue. (Unless these are 
written immediately to the changes file, without delay, and it really is 
easy to recover them.)

Perhaps the biggest issue is that even if you avoid the obviously 
dangerous (messing with existing code, especially core system classes) 
you can avoid crashing most Smalltalks, but not Squeak -- Morphic seems 
to be exceptionally vulnerable to being corrupted right to its core by a 
single user-made Morph that it doesn't like. I think Morphic needs to 
become much more robust before it can be considered "ready for 
prime-time", personally. All of the following occurred attempting to 
create a simple Morph able to convert a 2D array of numbers into a 
display of colored blocks via lookup-table:

* Making a BorderedMorph with an inset border and displaying a 2x2 grid
   worked fine, and it was easy to make it resize sensibly.
* Some changes made Morphic seem to hang, with CPU saturation. Ctrl+.
   enabled recovery, but one problem is immediately apparent:
   user-created, experimental UI gadgets operate in the same event
   dispatch system and at the same priority as the development tools.
   This doesn't occur developing in, say, C or Java, where at worst you'd
   have a window "not responding" and something to kill from Task
   Manager, running as a separate process from the development tools. You
   wouldn't lose even *unsaved* changes in one of your source code
   editors to such a thing, though you'd normally save the changes before
   compiling and running a test anyway, and then the changes would save
   to definite, identifiable source files on the disk. Those saved
   changes would definitely, and in a predictable place, survive even the
   unlikely occurrence of your app hanging or crashing Windows, and not
   need special tools to recover either; you'd just reopen them in your
   development tool after the three-finger salute and proceed with the
   bug-hunt.
* Making it 400x400 caused another apparent hang with CPU saturation.
   Ctrl+. didn't work in this case, except to make it possible to
   (veeerrryyyy slllloooowwwlllyyy!) use the UI. I pasted "<class of my
   morph> allInstancesDo: [:instance | instance delete]." into a
   workspace and fired it off, and fortunately that sufficed to gain back
   control. So Ctrl+. can't be relied upon, and either inset borders
   don't show much scalability or drawing 160,000 rectangles in a loop
   itself doesn't scale well. The latter would make the graphics
   primitives in Squeak on a 2GHz Athlon slower than QBasic(!) on mid-90s
   hardware(!!). (And that's two interpreted languages, just to ensure a
   fair comparison.)
* I reduced it to 20x20 and it was still slow, and removing the border
   (changing it from BorderedMorph to plain Morph and removing all
   border-setting code from my subclass) made it faster but it still drew
   a default black border around cells. I set the border to none
   (BorderStyle getBorderStyleForSymbol: #none IIRC) and attempted to
   "openInWorld" a new instance.
* Bang. Morphic crashed irrecoverably.

Trying to do a fairly simple thing with Morphic resulted in a completely 
b0rked system and an uncertain fate for half my data in under an hour. 
You can definitely rapid-prototype with this -- it takes far less time 
to crash the system than developing in a traditional language, and 
unfortunately it's as easy to do as it is in C despite the lack of 
dangling-pointer mayhem. This is apparently down to a) not having a way 
to run tests in a separate space that isolates the consequences of a 
failure -- firewalls between separate applications have been standard in 
even consumer-grade OSes and computers since the 90s, and b) the GUI 
being unstable and too-trusting, so that buggy (or, I expect, hostile) 
GUI objects can very easily render the whole system (rather than just 
themselves) unusable without having to do anything "unnatural". (Of 
course, hostile code could always crash the system by messing with the 
low-level guts of the system, but even if a deployment protected those 
guts from modification by making them read-only, a hostile graphical 
component or plugin could simply make the entire UI fail 
catastrophically. Apparently it's as simple to do as setting a null 
border-style and then attempting to display yourself.)

I'm not sure I'm actually going to bother trying to develop anything in 
Squeak until I have reason to believe the tools and UI have matured 
sufficiently that they are a) much more stable and b) it's much more 
obvious how to recover from or gracefully exit from failures, while 
avoiding any data loss.

P.S. Your message has provoked an apparent bug in Mozilla Thunderbird. I 
was quite certain I had configured Thunderbird to compose messages in 
plain text, yet trying to reply to yours always opened a composition 
window that was evidently trying to construct HTML. All the searching of 
options I subsequently did failed to reveal anywhere where I could 
specify "compose all messages, without exceptions, as plain text", which 
is funny since I was fairly sure I had already set such an option. (Tab 
size and conversion policy is also curiously hard to locate.) I did find 
an option to force sending of plain text on a per-domain basis and added 
a wildcard domain *.* there, but it had no effect. The correct effect 
would have obviously been to force plain text for all domains (since I 
don't know of any that don't contain a dot!) but clearly Thunderbird has 
an outright bug in that particular area. In case it matters, it calls 
itself version 1.0.7 (via help->about) and hasn't notified me of any 
updates, though I think it has update notification functionality, which 
means it appears I'm not using an outdated version. Unless it has even 
more bugs that conceal the existence of newer versions as well, of course.

Ultimately, to avoid polluting peoples' mailboxes with HTML (and 
probably winding up being ignored due to spam filters eating my 
message), I was forced to compose a new message (as new rather than as a 
reply), enter the addresses manually (yours and the list's), paste in 
your text, and manually add the > symbols. What a pain in the neck!