Yes, but that method hasn't been changed since '03, and this problem  
appears relatively new.  (It seems to pop up in many contexts.)  What  
other relatively recent changes have spawned this problem?

Is there a workaround?

On Jun 21, 2005, at 7:42 PM, Andreas Raab wrote:

> Avi Bryant wrote:
>
>> Well, I can see the problem using a fresh Squeak3.8-6665.image.  Now,
>> maybe that image is already in a bad state itself... how would I
>> check?
>>
>
> Oops. Clearly, I'm not doing enough Squeak work lately (heh, heh)  
> so my analysis was based on outdated (3.7 or earlier) information.  
> Looking at a plain 3.8 it seems pretty clear that Debugger  
> class>>openOn:context:label:contents:fullView: is the culprit - it  
> happily forks off a completely unsynchronized process to create the  
> debugger; *probably* assuming that the argument "process" must be  
> the active process. But if it isn't, then the newly forked process  
> interferes with the Morphic UI process with all of the  
> "interesting" effects you have noticed[*][**].
>
> [*] One of the issues is that SystemWindow will forcefully redraw  
> itself when activated/passivated and if this happens while we're  
> not running inside the main Morphic loop you can watch each and  
> every character being drawn individually (and as you noticed, this  
> takes a while).
>
> This method will never work, can never have worked, and must not  
> work that way. So I think some tarring and feathering is in order -  
> let's see whose initials are on that method ... ;-)
>
> [**] This also prooves my point that shared state concurrency is a  
> screwed up model to begin with. If people like Anthony cannot get  
> it right then nobody can.
>
> Cheers,
>   - Andreas
>