When you launch the debugger from TestRunner by clicking on an error list item, the PreDebugWindow is very slow to be drawn and it seem that each part of the window and invalidated area are drawn and flushed to the Display. The back buffering (draw all parts the flush the affected area to the Display) of the Display seem bypassed.
Other one has seen this ? or just me ?
Alain
On 6/21/05, Alain Fischer mailinglist.fischer@bluewin.ch wrote:
When you launch the debugger from TestRunner by clicking on an error list item, the PreDebugWindow is very slow to be drawn and it seem that each part of the window and invalidated area are drawn and flushed to the Display. The back buffering (draw all parts the flush the affected area to the Display) of the Display seem bypassed.
Other one has seen this ? or just me ?
Yes, I see this all the time - not just when using the TestRunner (and not always then, it doesn't seem to be very consistent). It's probably my number one frustration when developing in Squeak these days. The only workaround I've found is to simply not have many system windows open at any one time... anyone have a fix for this?
Avi
Switch to TestRunnerPlus (part of ToolBuilder examples). Or more accurately: Switch to any TestRunner which does not run tests in concurrent processes, thereby creating unforeseen interactions with the primary UI process, thereby at some point having multiple UI processes running thereby screwing up the display. It's amazing to me how people can deal with the default TestRunner at all given how flawed it is.
Cheers, - Andreas
Avi Bryant wrote:
On 6/21/05, Alain Fischer mailinglist.fischer@bluewin.ch wrote:
When you launch the debugger from TestRunner by clicking on an error list item, the PreDebugWindow is very slow to be drawn and it seem that each part of the window and invalidated area are drawn and flushed to the Display. The back buffering (draw all parts the flush the affected area to the Display) of the Display seem bypassed.
Other one has seen this ? or just me ?
Yes, I see this all the time - not just when using the TestRunner (and not always then, it doesn't seem to be very consistent). It's probably my number one frustration when developing in Squeak these days. The only workaround I've found is to simply not have many system windows open at any one time... anyone have a fix for this?
Avi
On 6/21/05, Andreas Raab andreas.raab@gmx.de wrote:
Switch to TestRunnerPlus (part of ToolBuilder examples). Or more accurately: Switch to any TestRunner which does not run tests in concurrent processes, thereby creating unforeseen interactions with the primary UI process, thereby at some point having multiple UI processes running thereby screwing up the display. It's amazing to me how people can deal with the default TestRunner at all given how flawed it is.
Yes, ok - but what about when I do want to raise a debugger from a non-UI process? Is there some safe, accepted way to do that?
Avi
Avi Bryant wrote:
Yes, ok - but what about when I do want to raise a debugger from a non-UI process? Is there some safe, accepted way to do that?
The following is pretty safe (no idea if it's "accepted" ;-)
| process | process := Processor activeProcess. WorldState addDeferredUIMessage:[ process debugWithTitle: 'Debug me!'. ]. process suspend.
To try this just put it into a "[ ]fork".
Cheers, - Andreas
On 6/22/05, Andreas Raab andreas.raab@gmx.de wrote:
Avi Bryant wrote:
Yes, ok - but what about when I do want to raise a debugger from a non-UI process? Is there some safe, accepted way to do that?
The following is pretty safe (no idea if it's "accepted" ;-)
| process | process := Processor activeProcess. WorldState addDeferredUIMessage:[ process debugWithTitle: 'Debug me!'. ]. process suspend.To try this just put it into a "[ ]fork".
I tried that several times; about half the time it worked just fine, the other half I got the slow redrawing. Once I got an error while trying to draw the main pane of the debugger.
Avi
I tried that several times; about half the time it worked just fine, the other half I got the slow redrawing. Once I got an error while trying to draw the main pane of the debugger.
Have you checked whether your image was in a bad state already? The above would not *create* such a problematic state but it would suffer from it if your image were already in that state.
Cheers, - Andreas
On 6/22/05, Andreas Raab andreas.raab@gmx.de wrote:
I tried that several times; about half the time it worked just fine, the other half I got the slow redrawing. Once I got an error while trying to draw the main pane of the debugger.
Have you checked whether your image was in a bad state already? The above would not *create* such a problematic state but it would suffer from it if your image were already in that state.
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?
Avi
I think the defer display update stuff might be turned off as a result of the error and that causes slow apparent updates.
tim -- Tim Rowledge, tim@rowledge.org, http://www.rowledge.org/tim Strange OpCodes: XO: Execute Operator
Am 22.06.2005 um 01:34 schrieb Tim Rowledge:
I think the defer display update stuff might be turned off as a result of the error and that causes slow apparent updates.
That was my suspicion, too. Does that happen on any VM? I can only remember seeing it on a Mac. But then, that's what I most often use.
- Bert -
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
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
Hi Andreas,
What are the steps to install ToolBuilder and then run TestRunnerPlus ?
Is this enough to install: http://kilana.unibe.ch:8888/ToolBuilder/ToolBuilder-Kernel-ar.10.mcz then: http://kilana.unibe.ch:8888/ToolBuilder/ToolBuilder-Examples-cwp.4.mcz
Have a nice day. Alain
On 21 juin 05, at 23:51, Andreas Raab wrote:
Switch to TestRunnerPlus (part of ToolBuilder examples). Or more accurately: Switch to any TestRunner which does not run tests in concurrent processes, thereby creating unforeseen interactions with the primary UI process, thereby at some point having multiple UI processes running thereby screwing up the display. It's amazing to me how people can deal with the default TestRunner at all given how flawed it is.
Cheers,
- Andreas
Avi Bryant wrote:
On 6/21/05, Alain Fischer mailinglist.fischer@bluewin.ch wrote:
When you launch the debugger from TestRunner by clicking on an error list item, the PreDebugWindow is very slow to be drawn and it seem that each part of the window and invalidated area are drawn and flushed to the Display. The back buffering (draw all parts the flush the affected area to the Display) of the Display seem bypassed.
Other one has seen this ? or just me ?
Yes, I see this all the time - not just when using the TestRunner (and not always then, it doesn't seem to be very consistent). It's probably my number one frustration when developing in Squeak these days. The only workaround I've found is to simply not have many system windows open at any one time... anyone have a fix for this? Avi
squeak-dev@lists.squeakfoundation.org
-
Alain Fischer -
Andreas Raab -
Andrew Greenberg -
Avi Bryant -
Bert Freudenberg -
Tim Rowledge