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
Unfortunately, this is an issue which I cant easily reproduce, at least not
without a third party tool (
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?