[Pharo-project] 'self halt' safety net

Ben Coman btc at openInWorld.com
Sat Aug 25 03:42:53 CEST 2012


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


----------------------------------------
THERE_BE_DRAGONS_HERE
MessageNotUnderstood: SmallInteger>>Transcript
25 August 2012 8:58:18.345 am

VM: Win32 - IX86 - 6.1 - CoInterpreter 
VMMaker-oscog-EstebanLorenzano.158 uuid: 
82eded98-68af-4c80-a472-4f6de293adcf May  1 2012, 
StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.158 uuid: 
82eded98-68af-4c80-a472-4f6de293adcf May  1 2012, 
https://git.gitorious.org/cogvm/blessed.git Commit: 
6aa3fd0f1188078d3167dec1a53031a61b97b688 Date: Tue May 1 20:28:14 2012 
+0200 By: Esteban Lorenzano <estebanlm at gmail.com>
Image: Pharo1.4 [Latest update: #14457]

SmallInteger(Object)>>doesNotUnderstand: #Transcript
    Receiver: 1
    Arguments and temporary variables:
        aMessage:     Transcript
        exception:     MessageNotUnderstood: SmallInteger>>Transcript
        resumeValue:     nil
    Receiver's instance variables:
1

ROOrthoVerticalLineShape>>lineSegmentsFor:
    Receiver: a ROOrthoVerticalLineShape
    Arguments and temporary variables:

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: crash.dmp
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20120825/12f26f88/attachment.ksh>


More information about the Pharo-project mailing list