The problem we're encountering is really vicious. It is hard to identify a situation when it happens. I tried to define a simple subclass of morph with an erroneous drawOn: method, but it behaved as one would expect: the morph is colored in red. In mondrian, if a zero- arg block is provided when a one-arg block is expected, boom... Hard to reproduce...
Cheers, Alexandre On 30 Nov 2009, at 18:06, Schwab,Wilhelm K wrote: > 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: [email protected] > [mailto:[email protected] > ] 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). 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
