Debugging with morphic

> Hi All (and especially the Pinesoft crew),
>
> When an error is triggered by a displayOn: method, the bottom bar is
> being filled with debugger windows. It then become hardly debuggable.
> Ideally, the system should not display a window if an error is
> triggered in the displayOn.
>
> Do you have any recommandation/conviention/enhancement to prevent the
> image to hang when an error is signaled in a displayOn. This is really
> annoying.
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

> I'm sure I can come up with something... you obvioulsy want some  
> kind of
> debugger if an error occurs.
> The taskbar works effectively synchronously with the display and  
> should
> handle self inflicted errors.
> Other display errors *should* get managed by the #errorOnDraw thing,  
> but not
> always it would seem.
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Alexandre Bergel" <[hidden email]>
> To: "Pharo Development" <[hidden email]>
> Sent: Saturday, February 14, 2009 4:53 PM
> Subject: [Pharo-project] Debugging with morphic
>
>
>> Hi All (and especially the Pinesoft crew),
>>
>> When an error is triggered by a displayOn: method, the bottom bar is
>> being filled with debugger windows. It then become hardly debuggable.
>> Ideally, the system should not display a window if an error is
>> triggered in the displayOn.
>>
>> Do you have any recommandation/conviention/enhancement to prevent the
>> image to hang when an error is signaled in a displayOn. This is  
>> really
>> annoying.
>>
>> Cheers,
>> Alexandre
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>I was just wondering how you guys debug your morphic programming.
> There is probably something wrong in the way I do. I cannot imagine
> people have been doing some morphic for so long without having a
> simple way to debug it.
>
> Cheers,
> Alexandre
>
>
> On 14 Feb 2009, at 18:26, Gary Chambers wrote:
>
>> I'm sure I can come up with something... you obvioulsy want some
>> kind of
>> debugger if an error occurs.
>> The taskbar works effectively synchronously with the display and
>> should
>> handle self inflicted errors.
>> Other display errors *should* get managed by the #errorOnDraw thing,
>> but not
>> always it would seem.
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Alexandre Bergel" <[hidden email]>
>> To: "Pharo Development" <[hidden email]>
>> Sent: Saturday, February 14, 2009 4:53 PM
>> Subject: [Pharo-project] Debugging with morphic
>>
>>
>>> Hi All (and especially the Pinesoft crew),
>>>
>>> When an error is triggered by a displayOn: method, the bottom bar is
>>> being filled with debugger windows. It then become hardly debuggable.
>>> Ideally, the system should not display a window if an error is
>>> triggered in the displayOn.
>>>
>>> Do you have any recommandation/conviention/enhancement to prevent the
>>> image to hang when an error is signaled in a displayOn. This is
>>> really
>>> annoying.
>>>
>>> Cheers,
>>> Alexandre
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 

>I was just wondering how you guys debug your morphic programming.
> There is probably something wrong in the way I do. I cannot imagine
> people have been doing some morphic for so long without having a
> simple way to debug it.
>
> Cheers,
> Alexandre
>
>
> On 14 Feb 2009, at 18:26, Gary Chambers wrote:
>
>> I'm sure I can come up with something... you obvioulsy want some
>> kind of
>> debugger if an error occurs.
>> The taskbar works effectively synchronously with the display and
>> should
>> handle self inflicted errors.
>> Other display errors *should* get managed by the #errorOnDraw thing,
>> but not
>> always it would seem.
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Alexandre Bergel" <[hidden email]>
>> To: "Pharo Development" <[hidden email]>
>> Sent: Saturday, February 14, 2009 4:53 PM
>> Subject: [Pharo-project] Debugging with morphic
>>
>>
>>> Hi All (and especially the Pinesoft crew),
>>>
>>> When an error is triggered by a displayOn: method, the bottom bar is
>>> being filled with debugger windows. It then become hardly debuggable.
>>> Ideally, the system should not display a window if an error is
>>> triggered in the displayOn.
>>>
>>> Do you have any recommandation/conviention/enhancement to prevent the
>>> image to hang when an error is signaled in a displayOn. This is
>>> really
>>> annoying.
>>>
>>> Cheers,
>>> Alexandre
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Regards, Gary
>
> ----- Original Message -----
> From: "Alexandre Bergel" <[hidden email]>
> To: <[hidden email]>
> Sent: Saturday, February 14, 2009 6:29 PM
> Subject: Re: [Pharo-project] Debugging with morphic
>
>
>>I was just wondering how you guys debug your morphic programming.
>> There is probably something wrong in the way I do. I cannot imagine
>> people have been doing some morphic for so long without having a
>> simple way to debug it.
>>
>> Cheers,
>> Alexandre
>>
>>
>> On 14 Feb 2009, at 18:26, Gary Chambers wrote:
>>
>>> I'm sure I can come up with something... you obvioulsy want some
>>> kind of
>>> debugger if an error occurs.
>>> The taskbar works effectively synchronously with the display and
>>> should
>>> handle self inflicted errors.
>>> Other display errors *should* get managed by the #errorOnDraw thing,
>>> but not
>>> always it would seem.
>>>
>>> Regards, Gary
>>>
>>> ----- Original Message -----
>>> From: "Alexandre Bergel" <[hidden email]>
>>> To: "Pharo Development" <[hidden email]>
>>> Sent: Saturday, February 14, 2009 4:53 PM
>>> Subject: [Pharo-project] Debugging with morphic
>>>
>>>
>>>> Hi All (and especially the Pinesoft crew),
>>>>
>>>> When an error is triggered by a displayOn: method, the bottom bar is
>>>> being filled with debugger windows. It then become hardly debuggable.
>>>> Ideally, the system should not display a window if an error is
>>>> triggered in the displayOn.
>>>>
>>>> Do you have any recommandation/conviention/enhancement to prevent the
>>>> image to hang when an error is signaled in a displayOn. This is
>>>> really
>>>> annoying.
>>>>
>>>> Cheers,
>>>> Alexandre
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Gary, Alexandre,
>
> I have long advocated an approach to this in the Dolphin community -  
> not sure how many people have really adopted it, but the same ideas  
> should work here.  Gary just hit a big part of it - set yourself up  
> to do something dangerous (don't do it yet), save, then try it.  If  
> it blows up, learn what you can, close, and try again.
>
> In Dolphin, the debate surrounds view subclasses.  I submit that  
> most of them are unnecessary, as an image presenter can do the job.  
> There are exceptions, but probably not many with a little  
> creativity.  The trick then is to generate code that draws on a  
> canvas.  Start out with a bitmap that you do not even expect to  
> display.  The debugger says hello, and no real harm is done.  When  
> the notifiers cease, it's time to actually look at the image.  More  
> fun, and perhaps some iteration, but nothing bad really happens.  
> Once it runs and is correct, it can go into a standard presenter.  
> The alternative of making a view puts the system increases risk  
> unless one protects the drawing to ensure the view ends up in a sane  
> state.
>
> Another thing that can be very helpful is a class called Once.  It  
> can be #reset and is used something like (if there is interest I can  
> look for it)
>
> Once do:[
>    self halt.
> ].
>
> with the predictable result - one pass through the offending code  
> halts, the rest go merrily onward until a Once reset occurs.
>
> Here's hoping that was worth the time you wasted reading it :)
>
> Bill
>
>
> ----
> Wilhelm K. Schwab, Ph.D.
> bschwab AT anest DOT ufl DOT edu
>
> ________________________________________
> From: [hidden email] [[hidden email]
> ] On Behalf Of Gary Chambers [[hidden email]]
> Sent: Saturday, February 14, 2009 2:03 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Debugging with morphic
>
> More often than not the emergency evaluator can save you from having  
> to
> reload changes...
> Otherwise, save often after careful consideration and before likely
> dangerous changes. Not a huge hassle to relaunch and load the last  
> changes
> either though.
>
> Regards, Gary
>
> ----- Original Message -----
> From: "Alexandre Bergel" <[hidden email]>
> To: <[hidden email]>
> Sent: Saturday, February 14, 2009 6:29 PM
> Subject: Re: [Pharo-project] Debugging with morphic
>
>
>> I was just wondering how you guys debug your morphic programming.
>> There is probably something wrong in the way I do. I cannot imagine
>> people have been doing some morphic for so long without having a
>> simple way to debug it.
>>
>> Cheers,
>> Alexandre
>>
>>
>> On 14 Feb 2009, at 18:26, Gary Chambers wrote:
>>
>>> I'm sure I can come up with something... you obvioulsy want some
>>> kind of
>>> debugger if an error occurs.
>>> The taskbar works effectively synchronously with the display and
>>> should
>>> handle self inflicted errors.
>>> Other display errors *should* get managed by the #errorOnDraw thing,
>>> but not
>>> always it would seem.
>>>
>>> Regards, Gary
>>>
>>> ----- Original Message -----
>>> From: "Alexandre Bergel" <[hidden email]>
>>> To: "Pharo Development" <[hidden email]>
>>> Sent: Saturday, February 14, 2009 4:53 PM
>>> Subject: [Pharo-project] Debugging with morphic
>>>
>>>
>>>> Hi All (and especially the Pinesoft crew),
>>>>
>>>> When an error is triggered by a displayOn: method, the bottom bar  
>>>> is
>>>> being filled with debugger windows. It then become hardly  
>>>> debuggable.
>>>> Ideally, the system should not display a window if an error is
>>>> triggered in the displayOn.
>>>>
>>>> Do you have any recommandation/conviention/enhancement to prevent  
>>>> the
>>>> image to hang when an error is signaled in a displayOn. This is
>>>> really
>>>> annoying.
>>>>
>>>> Cheers,
>>>> Alexandre
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

> Thanks Bill,
>
> Reading your post was indeed useful
>
> Alexandre
>
>
> On 14 Feb 2009, at 21:37, Schwab,Wilhelm K wrote:
>
>> Gary, Alexandre,
>>
>> I have long advocated an approach to this in the Dolphin community -
>> not sure how many people have really adopted it, but the same ideas
>> should work here.  Gary just hit a big part of it - set yourself up
>> to do something dangerous (don't do it yet), save, then try it.  If
>> it blows up, learn what you can, close, and try again.
>>
>> In Dolphin, the debate surrounds view subclasses.  I submit that
>> most of them are unnecessary, as an image presenter can do the job.
>> There are exceptions, but probably not many with a little
>> creativity.  The trick then is to generate code that draws on a
>> canvas.  Start out with a bitmap that you do not even expect to
>> display.  The debugger says hello, and no real harm is done.  When
>> the notifiers cease, it's time to actually look at the image.  More
>> fun, and perhaps some iteration, but nothing bad really happens.
>> Once it runs and is correct, it can go into a standard presenter.
>> The alternative of making a view puts the system increases risk
>> unless one protects the drawing to ensure the view ends up in a sane
>> state.
>>
>> Another thing that can be very helpful is a class called Once.  It
>> can be #reset and is used something like (if there is interest I can
>> look for it)
>>
>> Once do:[
>>    self halt.
>> ].
>>
>> with the predictable result - one pass through the offending code
>> halts, the rest go merrily onward until a Once reset occurs.
>>
>> Here's hoping that was worth the time you wasted reading it :)
>>
>> Bill
>>
>>
>> ----
>> Wilhelm K. Schwab, Ph.D.
>> bschwab AT anest DOT ufl DOT edu
>>
>> ________________________________________
>> From: [hidden email] [[hidden email]
>> ] On Behalf Of Gary Chambers [[hidden email]]
>> Sent: Saturday, February 14, 2009 2:03 PM
>> To: [hidden email]
>> Subject: Re: [Pharo-project] Debugging with morphic
>>
>> More often than not the emergency evaluator can save you from having
>> to
>> reload changes...
>> Otherwise, save often after careful consideration and before likely
>> dangerous changes. Not a huge hassle to relaunch and load the last
>> changes
>> either though.
>>
>> Regards, Gary
>>
>> ----- Original Message -----
>> From: "Alexandre Bergel" <[hidden email]>
>> To: <[hidden email]>
>> Sent: Saturday, February 14, 2009 6:29 PM
>> Subject: Re: [Pharo-project] Debugging with morphic
>>
>>
>>> I was just wondering how you guys debug your morphic programming.
>>> There is probably something wrong in the way I do. I cannot imagine
>>> people have been doing some morphic for so long without having a
>>> simple way to debug it.
>>>
>>> Cheers,
>>> Alexandre
>>>
>>>
>>> On 14 Feb 2009, at 18:26, Gary Chambers wrote:
>>>
>>>> I'm sure I can come up with something... you obvioulsy want some
>>>> kind of
>>>> debugger if an error occurs.
>>>> The taskbar works effectively synchronously with the display and
>>>> should
>>>> handle self inflicted errors.
>>>> Other display errors *should* get managed by the #errorOnDraw thing,
>>>> but not
>>>> always it would seem.
>>>>
>>>> Regards, Gary
>>>>
>>>> ----- Original Message -----
>>>> From: "Alexandre Bergel" <[hidden email]>
>>>> To: "Pharo Development" <[hidden email]>
>>>> Sent: Saturday, February 14, 2009 4:53 PM
>>>> Subject: [Pharo-project] Debugging with morphic
>>>>
>>>>
>>>>> Hi All (and especially the Pinesoft crew),
>>>>>
>>>>> When an error is triggered by a displayOn: method, the bottom bar
>>>>> is
>>>>> being filled with debugger windows. It then become hardly
>>>>> debuggable.
>>>>> Ideally, the system should not display a window if an error is
>>>>> triggered in the displayOn.
>>>>>
>>>>> Do you have any recommandation/conviention/enhancement to prevent
>>>>> the
>>>>> image to hang when an error is signaled in a displayOn. This is
>>>>> really
>>>>> annoying.
>>>>>
>>>>> Cheers,
>>>>> Alexandre
>>>>> --
>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>
> On 18.02.2009, at 22:46, Michael Roberts wrote:
>
>> Did Marcus not write some code a while ago that checked the context
>> before raising the error?
>
> I extended #haltIf: to check the selectors of methods on the stack.
> (This way one can put a halt into OrderedCollection>>add:, for  
> example).
>
> I think that behind this is some very important basic concept...
> Something like the idea that the world should not look the same from
> everywhere.
> E.g, one wants to be able to debug the UI and restrict the visibility
> of the
> breakpoints (and even then the code one changes) to the debug session.
>
> Nice area of research, we did some stuff that is related e.g.
>
> http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Denk07c
> http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Denk08b
>
> Much more is needed, both in terms of pure conceptual research and  
> then
> especially in making in "real".
>
>>>> Another thing that can be very helpful is a class called Once.  It
>>>> can be #reset and is used something like (if there is interest I  
>>>> can
>>>> look for it)
>>>>
>>>> Once do:[
>>>>  self halt.
>>>> ].
>
> There is #haltOnce in Pharo (and in Squeak, at least in 3.9).
>
> Marcus
>
> --
> Marcus Denker  --  [hidden email]
> http://www.marcusdenker.de
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>