Kasper, With all due respect to nearly everyone else here, and in other groups, (IMNSHO on this point), do not start with a morph. Draw on a bitmap/Form, and then display the result. It does wonders for allowing/forcing you to think about resolutions, resulting in code that has a chance of being reused on non-display devices (Windows has an advantage on that front - as much as I hate to admit they got something right<g>). The pattern I recommended in another post not only helps in reuse and portability to other dialects, it will (if you let it), help you to focus your breakpoints to things that matter to your code *before* the gui gets involved - recursive meltdown should be dramatically less likely as a result. HTH Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Henrik Sperre Johansen [henrik.s.johansen@veloxit.no] Sent: Friday, December 16, 2011 3:34 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] When is a freeze a bug or me fiddling too much On 16.12.2011 09:25, Kasper Ãsterbye wrote:
Hi all,
I have spend some time fiddling with Pharo, wonderful!
I have always had a tendency to redefine vital methods in ST, and sometimes that kills it (typically it just hangs). Pharo seems a little more prone to that than what I was used to. In particular, I seem to have a tendency to spot methods where inserting a "self halt" will cause the pre-debugger to open a new pre-debugger to open a new pre-debugger to....
My question is - are there any guidelines on when I should just live with it, or if it is a bug?
Best,
Kasper Halting in a method used to display the debugger will break any smalltalk I regularily use, at least. Which is why I like using haltOnce :)
Cheers, Henry