Emergency evaluator: "save and exit" command?

Is there something I can "evaluate" that does a "save and exit" of class
and method changes (but not the image itself)? Either to save everything
changed in the way of code, or to file out everything in a named package?

For some reason giving a morph the #none borderstyle and telling it to
openInWorld has crashed Morphic badly enough that it won't resume.
"Project newMorphic enter" and suchlike don't even get me an uncorrupted
project to file things out from before exiting.

Please reply to both sender and list.

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

On Thu, 11 Jan 2007 08:48:49 +0100, John Ersatznom wrote:

Of course, that's pretty much equivalent to killing the VM, but the  
changes file hint is invaluable.

John, you might want to learn about managing ChangeSets with a  
ChangeSorter, which is the traditional way to deal with source code  
packages, and then Monticello, which is an actual version control  
system.

- Bert -

On Jan 11, 2007, at 13:33 , Klaus D. Witzel wrote:

On Thu, 11 Jan 2007 13:56:58 +0100, Bert Freudenberg wrote:

> Of course, that's pretty much equivalent to killing the VM,

Hhm, killing the VM is not equivalent to #processShutDownList: (which is  
sent by #snapshot:andQuit:), isn't it. But it [killing] might be the only  
exit (or alt-F4, and the like) if #snapshot:andQuit: cannot do it for any  
reason.

/Klaus

On Jan 11, 2007, at 14:27 , Klaus D. Witzel wrote:

> On Thu, 11 Jan 2007 13:56:58 +0100, Bert Freudenberg wrote:
>
>> Of course, that's pretty much equivalent to killing the VM,
>
> Hhm, killing the VM is not equivalent to #processShutDownList:  
> (which is sent by #snapshot:andQuit:), isn't it. But it [killing]  
> might be the only exit (or alt-F4, and the like) if  
> #snapshot:andQuit: cannot do it for any reason.

Well, unless something in the shutdown list does any i/o operations,  
the net effect is the same ...

- Bert -

John Ersatznom puso en su mail :
If you have Squeak newer as 3.8, drag and drop this "intelligent" morph, if
not select via FileList.
Should go to topLeft of your desktop , with time, current change set , mouse
position.
Do control click and test if could do creating new change set and saving
each... seconds.
Is set to 60 seconds, but is not recurrent (fires one time only), but from
here you could start.
Or some take this and do some better and send to list...

Edgar

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

Hi John,

please don't cc anything to me; I'm a "frequent lurker" and use  
gmane.org's NNTP service for accessing mailing lists; there's no need to  
push me ;-)

On Fri, 12 Jan 2007 04:32:31 +0100, you wrote:

World menu > changes... > recently logged changes...

...
> This situation indicates a more general issue with the entire system.

Not really. "messing with existing code, especially core system classes",  
as you write it, is in the same league as "messing with the compiler"  
while using it. By using Squeak/Smalltalk for this sort of messing, open  
heart surgery was never easier in software industry 8-)

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

And I'm using Smalltalk-80 since its 2.x release, Visual Works and Squeak  
for quite some time and have never ever lost one line of source code. In  
my experience, working inside a living system either needs some carefull  
planning (for an exit strategy [pun not intended]) or plan B (trial and  
error recovery). I usually do both.

/Klaus

> P.S. Your message has provoked an apparent bug in Mozilla Thunderbird.

I'm not surprised to learn that my Opera/9.02 provoked an apparent bug in  
your Mozilla Thunderbird. FWIW, my message was sent with
Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii

On 11-Jan-07, at 7:32 PM, John Ersatznom wrote:

>
> Recovered how?

About 40% down the World menu you'll see 'changes'. click there and a  
new menu will appear - near the bootom it says 'recent log file..'  
and clicking that will open of recent image save/quit events. If you  
click on any one of those the system will scan the changels log  
forward from that time/date and give you a browser with each do it  
and method save you did. You can do a variety of things to re-install  
the ones you want. A common situation would be re-installing  
everything but the last few methods you changed since there is a good  
bet the last one cased the crash!


>
> 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? :))

Good grief John, nobody cares what MC version number stuff is. MC is  
there to store your work as you do it. When it reaches a state where  
you want to release a version you can save a package with a new name  
and even call version 1.0 if you want.
Your code isn't 'saved' it is compiled and a copy written to the  
changes log. This is not like editing C code and compiling a bunch of  
files later. We moved on from that quaint approach a while back :-)

I won't tackle Morphic issues since I simply don't et to play in that  
area.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Sailboat fuel for brains.

On Jan 12, 2007, at 11:06 AM, tim Rowledge wrote:

I'll note many years ago when we were working on the file primitives  
I had to kludge the codewarrior libraries to ensure file flush  
actually invoked the
proper mac os 7.x routine to flush the change log, oddly enough the  
codewarrior libraries would flush the internal buffer structure to  
disk, but not ask the
operating system to flush the file buffers.  I think it was Andreas  
who discovered that the change file wasn't being flushed on each  
write, thus
leading to a surprise in case of a VM crash.  People are welcome to  
cross check current 3.9 code to confirm the flush file primitive *is*  
still called tho, that
or the file closed.


--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

On Jan 12, 2007, at 11:06 AM, tim Rowledge wrote:

Ya, let's see sophie resource mgr, 296 versions. Generally I finish  
or attempt to finish work task, then run SUnits, then on confirmation  
check in the changes.
Occasionally I check them in busted and warn the other developers  
(but that is rare).  Since our repository exists on a different  
continent from me it's a way to ensure
in case my laptop hard disk fails (did in Nov), stolen, dropped etc,  
then I shouldn't lose more than a day of work.

Somedays multiple check in if I'm dealing with FFI code generation  
because a mistake on my part means the VM will crash, and recovery by  
loading some MC packages
is *much* simpler than dealing with change logs.

Lastly note that you can deal with change logs from another image if  
need be in case you've managed to screw  your image so badly it's un-
usable, thus allow you
to restore changes into another working image. But even then by using  
MC it's far easier.

--
========================================================================
===
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

John Ersatznom <[hidden email]> writes:
> This situation indicates a more general issue with the entire
> system.

There is a nice FAQ entry for this, which is only fair to read before
talking about massive redesigns of the system.  ;)

I agree the situation could be clearer.  What happens, though, is that
people who use the system a lot, just know the tools, and so the tools
never become easier for new users.

Anyway, your changes are all there in the changes file waiting for
you.  The simplest tool is "changes -> browse logged changes".  More
info on the situation in general is here:

    http://wiki.squeak.org/squeak/2168



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

Squeak has this frequent saving idea built in.  It's just so smooth
that you do not normally even see it...

It would be nice if, on startup, Squeak tried to determine if the last
exit was a crash.  If it was, it could open some kind a
changes-recovery window....


-Lex