[Pharo-project] 'self halt' safety net
btc at openInWorld.com
Mon Aug 27 17:44:33 CEST 2012
Igor Stasenko wrote:
> you can open .changes file in another image to rescue your code.
Thanks Igor. I gave that a go but couldn't work it out. I tried the
following: Unzipped a fresh image, copied the .changes file into the
folder to overwrite the existing .changes file, then after starting the
image tried (World > Tools > Recover lost changes...) but I get
"Information: this image has never been saved since changes were
compressed." Saving the image seems to empty the .changes file. I
could not find another way. Is there something else I should be doing?
> also you can patch the image's bytecode to avoid entering an offending method
> (like a method which enters the drawing , just see its bytecode in
> another image,
> and the find same byte sequence in crashing image, and put return self bytecode)
Thanks, but that is beyond my capability at the moment. Probably
wishing for too much, but ideally some mechanism might use info from the
debug.log to do this automatically.
> On 25 August 2012 03:42, Ben Coman <btc at openinworld.com> wrote:
>> Igor Stasenko wrote:
>>> On 4 August 2012 04:11, Ben Coman <btc at openinworld.com> wrote:
>>>> As probably many newbies do from time to time, I am learning the system
>>>> splattering 'self halt' around, and once again slipped one into the wrong
>>>> place where I should have used 'haltOnce' and had a massive number of
>>>> pre-debugger windows come up. I managed to get it back this time with
>>>> user interrupt - but not always - and anyhow clearing so many debug
>>>> is a pain. So..... could 'self halt' be made to monitor the rate that
>>>> halt windows appear, and when more than some value from one of them (say
>>>> five per second) it starts getting ignored and shows a dialog asking the
>>>> user if they really meant this and enable danger mode, or if they screwed
>>>> and want to revert the method containing the suspect 'halt'.
>>> If we look from user's perspective (not machine perspective), apparently
>>> it is pointless to throw so many messages at the user's face, because
>>> he cannot deal with them
>>> in meaningful manner at such rate.
>>> So, i think there should be something like following:
>>> - if exception requires a user interaction, we do show the popup, but
>>> meanwhile remember
>>> the exception which initiated it.
>>> - if there's next exception incoming and also asks UI manager to show
>>> it to user, we queue it,
>>> letting user to deal with first one.. (or we delay the popup , say 1
>>> each 5 seconds).
>>> and finally, a queue should have some reasonable limit, after which we
>>> stop queuing , because again, user certainly won't be willing to waste
>>> his time dealing with 10000000 exceptions of same kind one by one. It
>>> doesn't makes sense anyways.
>>> In such case we can just ignore halt and let program continue (but
>>> increment some counter to show user how many of them are there).
>>> If exception is different (an Error) then on queue overflow, i think
>>> it should terminate the process with exception (but of course, special
>>> care must be taken if process is UI process).
>>> Of course making it too smart is pointless, because it is impossible
>>> to predict whether it is good idea
>>> to terminate process or letting it continue to run in case of exception.
>>> But for that we can have settings and options, to tune that at user's
>>> discretion, as well as default
>>> settings on a per-exception class base.
>>>> anyhow, just musing.... -ben
>>> i know by myself how annoying it can be (up to unresponsive image)
>>> and i think most of us is facing such situation time to time (heh..
>>> just yesterday we had it with Camillo while hacking ocompletion
>>> i learned to be careful and avoid such situations.. but sometimes it
>>> is hard and better tooling support will be helpful, no doubt.
>> Another use case that just happened to me. This is not 'halt' related but
>> just a typo... (which suddenly makes the whole system feel a bit fragile)
>> Working on a small new feature in the drawing loop of Roassal, I would guess
>> "all" that I did was leave out a full stop at the end a line. So the image
>> locked and crashed after about 20 seconds. Unfortunately now the image is
>> crashing every time I try to open it. Some mechanism to throttle and
>> temporarily ignore the error to allow me to rectify the problem would have
>> been immensely useful. In this case, perhaps something like blocking the
>> main UI loop and presenting a modal window of a very basic self contained
>> text editor on the offending method.
>> At this moment, another immensely useful tool would be able to diff the
>> source code between a running image and an offline image, and import the
>> Is there any other way I might recover recent changes? Previously I have
>> not had much luck mixing a new image with the changes file fromt he crashed
>> regards -ben
[Debug logs deleted]
More information about the Pharo-project