Emergency evaluator: "save and exit" command?
John Ersatznom
bbound at gmail.com
Fri Jan 12 03:32:31 UTC 2007
> 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!
More information about the Squeak-dev
mailing list
|