[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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
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
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
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 -- denker@acm.org http://www.marcusdenker.de
I agree with you Marcus... Alexandre On 18 Feb 2009, at 23:19, Marcus Denker wrote:
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 -- denker@acm.org http://www.marcusdenker.de
_______________________________________________ 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
2009/2/14 Gary Chambers <gazzaguru2@btinternet.com>:
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.
I think its one of biggest issue for newcomers who trying to implement new or improve current UI. Some cases is relatively easy to debug, when you playing with morphs for instance. But it you getting deeper into Canvas & Balloon rendering , the cost of error it very high - in most cases you have to restart image. One of the good things about having multiple host windows, that you can open debugger in separate host window and debug UI in second one by stepping through most low-level methods, which perform drawing. This would make debugging graphics & UI much easier. That's what i like to be made possible.
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
-- Best regards, Igor Stasenko AKA sig.
participants (7)
-
Alexandre Bergel -
Alexandre Bergel -
Gary Chambers -
Igor Stasenko -
Marcus Denker -
Michael Roberts -
Schwab,Wilhelm K