[Pharo-project] 'self halt' safety net

Ben Coman 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
>>>> the
>>>> user interrupt - but not always - and anyhow clearing so many debug
>>>> windows
>>>> is a pain.  So..... could 'self halt' be made to monitor the rate that
>>>> the
>>>> 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
>>>> up
>>>> 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
>>> stuff).
>>> 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
>> changes.
>> 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
>> image.
>>
>> regards -ben
>>
>>     
[Debug logs deleted]



More information about the Pharo-project mailing list