Did Marcus not write some code a while ago that checked the context before raising the error? or am I imagining that. I thought we could check the sender chain and prevented triggering. i.e if you are inside a particular call chain. In VW I had to just learn to not put breakpoints high up in the UI hierarchy but the system could be more clever. cheers Mike On Sun, Feb 15, 2009 at 8:15 AM, Alexandre Bergel <alexandre@bergel.eu> wrote:
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Gary Chambers [gazzaguru2@btinternet.com] Sent: Saturday, February 14, 2009 2:03 PM To: Pharo-project@lists.gforge.inria.fr 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" <alexandre@bergel.eu> To: <Pharo-project@lists.gforge.inria.fr> 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" <Alexandre.Bergel@inria.fr> To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project