Hello,
I am trying to find out why browsers get slower when you open more of them in Squeak 3.9 (see previous emails). One theory is that hidden browsers are redrawn. I'd like to test that by making a note on the Transcript every time a browser window gets redrawn. I have tried to override SystemWindow>>fullRedrawOn: aCanvas. Unfortunately, the image locks up when I try to accept a non-trivial variation. I have tried e.g.
fullDrawOn: aCanvas super fullDrawOn: aCanvas self title. "Hangs."
Sometimes I am able to accept more complicated variants of this, but invariably I ended up with a hanging mage. I have tried to write to transcript only if I am inside certain type of window, in order to avoid redrawing loops for the transcript window. That failed because I ws not able to accept these variants of fullDrawOn:.
Anything else I can try to count redraws?
Cheers
Matthias
Hi Matthias,
Its great to see work in this area!
Most likely you get into an endless loop because your logging behavior triggers another redraw. What you can try is to add an instance variable (or global) and use it as a counter, or you could log to a file.
HTH, Adrian
On May 2, 2008, at 12:03 , Matthias Berth wrote:
Hello,
I am trying to find out why browsers get slower when you open more of them in Squeak 3.9 (see previous emails). One theory is that hidden browsers are redrawn. I'd like to test that by making a note on the Transcript every time a browser window gets redrawn. I have tried to override SystemWindow>>fullRedrawOn: aCanvas. Unfortunately, the image locks up when I try to accept a non-trivial variation. I have tried e.g.
fullDrawOn: aCanvas super fullDrawOn: aCanvas self title. "Hangs."
Sometimes I am able to accept more complicated variants of this, but invariably I ended up with a hanging mage. I have tried to write to transcript only if I am inside certain type of window, in order to avoid redrawing loops for the transcript window. That failed because I ws not able to accept these variants of fullDrawOn:.
Anything else I can try to count redraws?
Cheers
Matthias
On Fri, May 2, 2008 at 1:36 PM, Adrian Lienhard adi@netstyle.ch wrote:
Most likely you get into an endless loop because your logging behavior triggers another redraw.
I was thinking that, too - but even when I do something simple like self title it locks up.
What you can try is to add an instance variable (or global) and use it as a counter, or you could log to a file.
Yes, that would be an option. I'll try that next time. For now I'm happy with turning off rounded corners to make browsers faster.
Cheers
Matthias
On May 2, 2008, at 12:03 , Matthias Berth wrote:
Hello,
I am trying to find out why browsers get slower when you open more of them in Squeak 3.9 (see previous emails). One theory is that hidden browsers are redrawn. I'd like to test that by making a note on the Transcript every time a browser window gets redrawn. I have tried to override SystemWindow>>fullRedrawOn: aCanvas. Unfortunately, the image locks up when I try to accept a non-trivial variation. I have tried e.g.
fullDrawOn: aCanvas super fullDrawOn: aCanvas self title. "Hangs."
Sometimes I am able to accept more complicated variants of this, but invariably I ended up with a hanging mage. I have tried to write to transcript only if I am inside certain type of window, in order to avoid redrawing loops for the transcript window. That failed because I ws not able to accept these variants of fullDrawOn:.
Anything else I can try to count redraws?
Cheers
Matthias
On 2-May-08, at 6:00 AM, Matthias Berth wrote:
On Fri, May 2, 2008 at 1:36 PM, Adrian Lienhard adi@netstyle.ch wrote:
Most likely you get into an endless loop because your logging behavior triggers another redraw.
I was thinking that, too - but even when I do something simple like self title it locks up.
What you can try is to add an instance variable (or global) and use it as a counter, or you could log to a file.
Or you could try something like redrawCount asString asDisplayText display which will render it in the top left corner of the Display. So long as you have your experimental subject browsers placed so as not to overdraw that you will be able to see it. Since there is no morph added anywhere, just a blit direct to the screen, you should be safe from lock ups.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim When all else fails, let a = 7. If that doesn't help, then read the manual.
Transcript is forcefully redrawn if you issue show: command. But, if you use just #nextPut:/ #nextPutAll: it will be not redrawn immediately, only when Transcript window is redrawn in world redraw cycle.
In previous posts to squeak-dev, i already highlighted this issue. There is no real need in updating Transcript window more often than each 20ms (which is a hard-coded world update cycle). And #show: command should not forcefully redraw window, just invalidate it , so on next cycle window will be updated automatically.
The only reason, why this bad habit is still present in image, because there are many applications which working in single-threaded manner, by locking UI, preventing it to update regularly, and as consequence you need to update things manually instead of letting world update cycle update it automatically. Some people advocating, that direct redraw of Transcript window each time you invoking #show: letting user to see message immediately. But, if you do not lock UI process with own lengthly process, which preventing updates each 20ms, what difference then? Do you really think you will notice 20ms delay? Also consider putting single character in transcript 1000 times in a row. Is there a real need to redraw Transcript each time for each character?
2008/5/2 Matthias Berth matthias.berth@googlemail.com:
Hello,
I am trying to find out why browsers get slower when you open more of them in Squeak 3.9 (see previous emails). One theory is that hidden browsers are redrawn. I'd like to test that by making a note on the Transcript every time a browser window gets redrawn. I have tried to override SystemWindow>>fullRedrawOn: aCanvas. Unfortunately, the image locks up when I try to accept a non-trivial variation. I have tried e.g.
fullDrawOn: aCanvas super fullDrawOn: aCanvas self title. "Hangs."
Sometimes I am able to accept more complicated variants of this, but invariably I ended up with a hanging mage. I have tried to write to transcript only if I am inside certain type of window, in order to avoid redrawing loops for the transcript window. That failed because I ws not able to accept these variants of fullDrawOn:.
Anything else I can try to count redraws?
Cheers
Matthias
Thanks a lot everyone, I think I'll make good use of your suggestions.
Cheers
Matthias
On Fri, May 2, 2008 at 11:17 PM, Igor Stasenko siguctua@gmail.com wrote:
Transcript is forcefully redrawn if you issue show: command. But, if you use just #nextPut:/ #nextPutAll: it will be not redrawn immediately, only when Transcript window is redrawn in world redraw cycle.
In previous posts to squeak-dev, i already highlighted this issue. There is no real need in updating Transcript window more often than each 20ms (which is a hard-coded world update cycle). And #show: command should not forcefully redraw window, just invalidate it , so on next cycle window will be updated automatically.
The only reason, why this bad habit is still present in image, because there are many applications which working in single-threaded manner, by locking UI, preventing it to update regularly, and as consequence you need to update things manually instead of letting world update cycle update it automatically. Some people advocating, that direct redraw of Transcript window each time you invoking #show: letting user to see message immediately. But, if you do not lock UI process with own lengthly process, which preventing updates each 20ms, what difference then? Do you really think you will notice 20ms delay? Also consider putting single character in transcript 1000 times in a row. Is there a real need to redraw Transcript each time for each character?
2008/5/2 Matthias Berth matthias.berth@googlemail.com:
Hello,
I am trying to find out why browsers get slower when you open more of them in Squeak 3.9 (see previous emails). One theory is that hidden browsers are redrawn. I'd like to test that by making a note on the Transcript every time a browser window gets redrawn. I have tried to override SystemWindow>>fullRedrawOn: aCanvas. Unfortunately, the image locks up when I try to accept a non-trivial variation. I have tried e.g.
fullDrawOn: aCanvas super fullDrawOn: aCanvas self title. "Hangs."
Sometimes I am able to accept more complicated variants of this, but invariably I ended up with a hanging mage. I have tried to write to transcript only if I am inside certain type of window, in order to avoid redrawing loops for the transcript window. That failed because I ws not able to accept these variants of fullDrawOn:.
Anything else I can try to count redraws?
Cheers
Matthias
-- Best regards, Igor Stasenko AKA sig.
Hi igor
Do you have some code to fix that?
Stef
On May 2, 2008, at 11:17 PM, Igor Stasenko wrote:
Transcript is forcefully redrawn if you issue show: command. But, if you use just #nextPut:/ #nextPutAll: it will be not redrawn immediately, only when Transcript window is redrawn in world redraw cycle.
In previous posts to squeak-dev, i already highlighted this issue. There is no real need in updating Transcript window more often than each 20ms (which is a hard-coded world update cycle). And #show: command should not forcefully redraw window, just invalidate it , so on next cycle window will be updated automatically.
The only reason, why this bad habit is still present in image, because there are many applications which working in single-threaded manner, by locking UI, preventing it to update regularly, and as consequence you need to update things manually instead of letting world update cycle update it automatically. Some people advocating, that direct redraw of Transcript window each time you invoking #show: letting user to see message immediately. But, if you do not lock UI process with own lengthly process, which preventing updates each 20ms, what difference then? Do you really think you will notice 20ms delay? Also consider putting single character in transcript 1000 times in a row. Is there a real need to redraw Transcript each time for each character?
2008/5/2 Matthias Berth matthias.berth@googlemail.com:
Hello,
I am trying to find out why browsers get slower when you open more of them in Squeak 3.9 (see previous emails). One theory is that hidden browsers are redrawn. I'd like to test that by making a note on the Transcript every time a browser window gets redrawn. I have tried to override SystemWindow>>fullRedrawOn: aCanvas. Unfortunately, the image locks up when I try to accept a non-trivial variation. I have tried e.g.
fullDrawOn: aCanvas super fullDrawOn: aCanvas self title. "Hangs."
Sometimes I am able to accept more complicated variants of this, but invariably I ended up with a hanging mage. I have tried to write to transcript only if I am inside certain type of window, in order to avoid redrawing loops for the transcript window. That failed because I ws not able to accept these variants of fullDrawOn:.
Anything else I can try to count redraws?
Cheers
Matthias
-- Best regards, Igor Stasenko AKA sig.
2008/5/3 stephane ducasse stephane.ducasse@free.fr:
Hi igor
Do you have some code to fix that?
Posted it on mantis. http://bugs.squeak.org/view.php?id=7033
Stef
On May 2, 2008, at 11:17 PM, Igor Stasenko wrote:
Transcript is forcefully redrawn if you issue show: command. But, if you use just #nextPut:/ #nextPutAll: it will be not redrawn immediately, only when Transcript window is redrawn in world redraw cycle.
In previous posts to squeak-dev, i already highlighted this issue. There is no real need in updating Transcript window more often than each 20ms (which is a hard-coded world update cycle). And #show: command should not forcefully redraw window, just invalidate it , so on next cycle window will be updated automatically.
The only reason, why this bad habit is still present in image, because there are many applications which working in single-threaded manner, by locking UI, preventing it to update regularly, and as consequence you need to update things manually instead of letting world update cycle update it automatically. Some people advocating, that direct redraw of Transcript window each time you invoking #show: letting user to see message immediately. But, if you do not lock UI process with own lengthly process, which preventing updates each 20ms, what difference then? Do you really think you will notice 20ms delay? Also consider putting single character in transcript 1000 times in a row. Is there a real need to redraw Transcript each time for each character?
2008/5/2 Matthias Berth matthias.berth@googlemail.com:
Hello,
I am trying to find out why browsers get slower when you open more of them in Squeak 3.9 (see previous emails). One theory is that hidden browsers are redrawn. I'd like to test that by making a note on the Transcript every time a browser window gets redrawn. I have tried to override SystemWindow>>fullRedrawOn: aCanvas. Unfortunately, the image locks up when I try to accept a non-trivial variation. I have tried e.g.
fullDrawOn: aCanvas super fullDrawOn: aCanvas self title. "Hangs."
Sometimes I am able to accept more complicated variants of this, but invariably I ended up with a hanging mage. I have tried to write to transcript only if I am inside certain type of window, in order to avoid redrawing loops for the transcript window. That failed because I ws not able to accept these variants of fullDrawOn:.
Anything else I can try to count redraws?
Cheers
Matthias
-- Best regards, Igor Stasenko AKA sig.
Thanks I was also thinking that having a thread safe transcript would be good for people trying some concurrent snippets.
Stef
On May 3, 2008, at 10:37 PM, Igor Stasenko wrote:
2008/5/3 stephane ducasse stephane.ducasse@free.fr:
Hi igor
Do you have some code to fix that?
Posted it on mantis. http://bugs.squeak.org/view.php?id=7033
Stef
On May 2, 2008, at 11:17 PM, Igor Stasenko wrote:
Transcript is forcefully redrawn if you issue show: command. But, if you use just #nextPut:/ #nextPutAll: it will be not redrawn immediately, only when Transcript window is redrawn in world redraw cycle.
In previous posts to squeak-dev, i already highlighted this issue. There is no real need in updating Transcript window more often than each 20ms (which is a hard-coded world update cycle). And #show: command should not forcefully redraw window, just invalidate it , so on next cycle window will be updated automatically.
The only reason, why this bad habit is still present in image, because there are many applications which working in single-threaded manner, by locking UI, preventing it to update regularly, and as consequence you need to update things manually instead of letting world update cycle update it automatically. Some people advocating, that direct redraw of Transcript window each time you invoking #show: letting user to see message immediately. But, if you do not lock UI process with own lengthly process, which preventing updates each 20ms, what difference then? Do you really think you will notice 20ms delay? Also consider putting single character in transcript 1000 times in a row. Is there a real need to redraw Transcript each time for each character?
2008/5/2 Matthias Berth matthias.berth@googlemail.com:
Hello,
I am trying to find out why browsers get slower when you open more of them in Squeak 3.9 (see previous emails). One theory is that hidden browsers are redrawn. I'd like to test that by making a note on the Transcript every time a browser window gets redrawn. I have tried to override SystemWindow>>fullRedrawOn: aCanvas. Unfortunately, the image locks up when I try to accept a non-trivial variation. I have tried e.g.
fullDrawOn: aCanvas super fullDrawOn: aCanvas self title. "Hangs."
Sometimes I am able to accept more complicated variants of this, but invariably I ended up with a hanging mage. I have tried to write to transcript only if I am inside certain type of window, in order to avoid redrawing loops for the transcript window. That failed because I ws not able to accept these variants of fullDrawOn:.
Anything else I can try to count redraws?
Cheers
Matthias
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
2008/5/4 stephane ducasse stephane.ducasse@free.fr:
Thanks I was also thinking that having a thread safe transcript would be good for people trying some concurrent snippets.
Check mantis, i seen report which dealing with thread safety for Transcript. Didn't examined it.
Stef
Tx I wrote once one based on nile. I should dig that.
stef
On May 4, 2008, at 11:52 AM, Igor Stasenko wrote:
2008/5/4 stephane ducasse stephane.ducasse@free.fr:
Thanks I was also thinking that having a thread safe transcript would be good for people trying some concurrent snippets.
Check mantis, i seen report which dealing with thread safety for Transcript. Didn't examined it.
Stef
-- Best regards, Igor Stasenko AKA sig.
On Sun, May 04, 2008 at 10:16:48AM +0200, stephane ducasse wrote:
Thanks I was also thinking that having a thread safe transcript would be good for people trying some concurrent snippets.
Stef
If you happen to be using a Unix or Mac VM, this is a more reliable way to do it, see class OSProcess:
debugMessage: aString "Print aString on standard output. The debug message is prefixed with the identity of the process in which the method is being evaluated, and the identity of the object which received the message. Useful for debugging timing or deadlock problems."
It would work on Windows too (prints to a Windows console), but I have not updated the plugin in a long time, sorry.
You can also just write to a file stream, or to a file stream on /dev/tty.
- Dave
Thanks Dave
I was more thinking that if people read my next chapter and try the code then Transcript show... may break the results displayed.
Now I would love to see really integrate a stdout so that we could get Squeak headless and using it as a "scripting" language. Right now on each platform we have to use a plugin which is not working the same or not available on the platform. Is there any chance that we would get
Output nextPut: 'zork'
Stef
On May 4, 2008, at 3:35 PM, David T. Lewis wrote:
On Sun, May 04, 2008 at 10:16:48AM +0200, stephane ducasse wrote:
Thanks I was also thinking that having a thread safe transcript would be good for people trying some concurrent snippets.
Stef
If you happen to be using a Unix or Mac VM, this is a more reliable way to do it, see class OSProcess:
debugMessage: aString "Print aString on standard output. The debug message is prefixed with the identity of the process in which the method is being evaluated, and the identity of the object which received the message. Useful for debugging timing or deadlock problems."
It would work on Windows too (prints to a Windows console), but I have not updated the plugin in a long time, sorry.
You can also just write to a file stream, or to a file stream on / dev/tty.
- Dave
Now I would love to see really integrate a stdout so that we could get Squeak headless and using it as a "scripting" language. Right now on each platform we have to use a plugin which is not working the same or not available on the platform. Is there any chance that we would get
Output nextPut: 'zork'
That is certainly easy to do, it would be just a matter of agreeing to make a #primitiveGetStdout available on all platforms. But to be honest, I'm not sure that this is suitable for a "base Squeak," and Squeak is probably never going to be a good choice as a scripting language IMHO.
In any case, if you feel like playing around with the idea, I put something into the CommandShell package that lets you use Squeak like an interactive shell, sort of a /bin/sh equivalent except that it also does Smalltalk. Evaluate "ExternalCommandShell start", save your image, start it up headless from the Unix command line, and viola a crude interactive shell. If you are really adventurous, you can use it as your Unix login shell ;) Note that I do *not* suggest this as a scripting language, but it's fun to play around with it.
Dave
On May 4, 2008, at 7:00 PM, David T. Lewis wrote:
Now I would love to see really integrate a stdout so that we could get Squeak headless and using it as a "scripting" language. Right now on each platform we have to use a plugin which is not working the same or not available on the platform. Is there any chance that we would get
Output nextPut: 'zork'
That is certainly easy to do, it would be just a matter of agreeing to make a #primitiveGetStdout available on all platforms. But to be honest, I'm not sure that this is suitable for a "base Squeak," and Squeak is probably never going to be a good choice as a scripting language IMHO.
I do not see why. why would I have to use Ruby to write little utilities that manage files and others. May be I should wait that ruby get an interactive environment and switch after all. We could have a debugger-enable version that brings you in the image if there is a bug and a headless version.
In any case, if you feel like playing around with the idea, I put something into the CommandShell package that lets you use Squeak like an interactive shell, sort of a /bin/sh equivalent except that it also does Smalltalk. Evaluate "ExternalCommandShell start", save your image, start it up headless from the Unix command line, and viola a crude interactive shell. If you are really adventurous, you can use it as your Unix login shell ;) Note that I do *not* suggest this as a scripting language, but it's fun to play around with it.
I will give a try. I still do not see why this would not be good to do scripts. I will also take over the scripting syntax mathieu implemented and that looks like pepsi.
Dave
squeak-dev@lists.squeakfoundation.org
-
Adrian Lienhard -
David T. Lewis -
Igor Stasenko -
Matthias Berth -
stephane ducasse -
tim Rowledge