Simon,
I can't speak to the specifics of your problem, but recursive errors from a GUI
thread can indeed happen. Imagine if the debugger itself had trouble opening.
Note that problem does not necessarily have to be "in the debugger;" it is
enough to have the attempt to open it invalidate something else and trigger
another debugger which invalidates something and so on until you run out of
memory or patience.
Some general comments:
(1) this type of thing is why I kick up dust any time somebody wants to take
away the notifier (aka pre-debugger, aka walkback window). The full debugger
takes time to open, and that extra time can make it that much harder to
interrupt something that is going nuts.
(2) Debugging drawing code is probably best done using a single-shot
breakpoint. I _think_ I have seen something about halt once in Pharo. FWIW,
somebody posted a class called Once that creates such a feature that looks like
Once do:[
"do anything here, but this is common:"
self halt.
].
Somewhere you need to do Once reset or something (it's obvious from the code)
to enable the breakpoint. Once evaluates the block one time, and then won't
evaluate the block again until told to do so. If there is a need for this in
Pharo, I should be able to "port" it - IIRC, it was licensed for public
consumption.
(3) I have yet identify this in Morphic (haven't had time to look for it), but
a LOT of community-created Dolphin code for views is completely needless. Yup,
I said that :) It's true too. Many times I have seen people create a view
when they could just as easily create a bitmap and display it in an image
presenter. The latter can be done efficiently by redrawing pieces of the
bitmap and updating only the corresponding portion of the image presenter - no
custom view required. The savings in programming overhead is larger than it
might seem due to Dolphin's handling of views as serialized objects.
Avoiding the custom view also simplifies debugging. One can write code to draw
to an in-memory bitmap and debug essentially free of concern. Once it stops
raising errors and runs, then display the result in an image presenter and fix
the visual problems. At the same time, add some resolution-based drawing, and
you have something that can print in addition to drawing on the display. You
might think about adopting analogous practices.
(4) I partition things into "just Smalltalk" and dangerous external
interfacing. By "just Smalltalk" I mean things that might go into an infinite
loop, but should never do anything horrible in terms of memory access. On the
dangerous side, I consider anything newly changed in the way of FFI and changes
to GUI elements; the latter goes on the list because it can meltdown as you are
seeing. For such situations, I get the image ready do the work, including a
do-it in plain view, save the image, and then do the thing that might blow up.
If it gets ugly, I use the debugger to learn what I can, quit w/o saving, and
start the next iteration. That way, I (hopefully) never save an unstable image.
Bill
________________________________
From: pharo-project-boun...@lists.gforge.inria.fr
[mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Simon Denier
Sent: Monday, November 30, 2009 2:18 PM
To: Pharo Development
Cc: Simon Denier
Subject: [Pharo-project] Is there something wrong in debugging in the Morphic
thread?
Unfortunately, this is an issue which I cant easily reproduce, at least not
without a third party tool
(1525<http://code.google.com/p/pharo/issues/detail?id=1525>). Now I would like
the general opinion/experience of debugging Morphic code especially in threads.
Usually an exception raised from within Morphic code pops up a debugger as
usual. However, from time to time, or for more complicated stuff, the situation
runs out of hand and tons of debugger pop up everywhere because the same faulty
gets obviously executed again and again.
Now can somebody with some Morphic knowledge explain how this is supposed to
work and how to deal with such issues?
--
Simon
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
