October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Speeding up Pharo 1.1

by Igor Stasenko

On 17 October 2010 21:45, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > > Levente Uzonyi-2 wrote: >> >> >> Btw why doesn't the windows VM signal the semaphore? >> >> >> Levente >> >> >> > > http://forum.world.st/InputSemaphore-on-Windows-td1934394.html#a2014576 > > Basically, there may or may not be some issue with them not being noticed in > the image, it hasn't been a priority since the Squeak image doesn't depend > on it, and no-one have set aside the time to fix it. > Not very hard really, just time-consuming and tedious checking you've hit > all the points it has to be signalled. > I don't think that this is the problem with image being sluggy. It would feel sluggy from very beginning, not after you load a lots of stuff into image, isnt? > Cheers, > Henry > -- > View this message in context: http://forum.world.st/Speeding-up-Pharo-1-1-tp2998198p2999271.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 17, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Schwab,Wilhelm K

I don't know why the Windows VM does not signal the semaphore. There are, of course, good and bad possible reasons why that might be. The up side includes possible motives of compensating for weirdness in the Windows event queue over the many versions. Dolphin tries to be correct about it, and it took some effort; arguments could be made that they failed to get it right across all platforms (I recall having troubles with COM servers failing to run at times with the default event loop); OA dropped official support for Win2k years before that was appropriate (if it is even now), and the message queue appeared to be at the center of it. Correct me if I'm missing a combination of versions, but every time I have tried an old Squeak image and a modern vm on any old version of Windows I happened to have handy, dragging time image onto the vm worked. The bad part of waiting with a timeout is that the system runs (good) even when it is not properly managing the message queue, masking the problem (bad). As Levente suggets, one way to react to this is to ensure that the Linux and Mac vms do not need the timeout. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Sunday, October 17, 2010 12:17 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Speeding up Pharo 1.1 On Sun, 17 Oct 2010, Henrik Johansen wrote: > > > Den 17. okt. 2010 kl. 00:37 skrev Levente Uzonyi <leves(a)elte.hu>: > >> Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed. >> >> >> Levente > It doesn't, there's effectively polling done in the UI threads hand processing on Squeak. I see. But MessageTally doesn't: MessageTally spyAllOn: [ 10 seconds asDelay wait ] Squeak: **Leaves** 99.7% {9970ms} ProcessorScheduler class>>idleProcess Pharo: **Leaves** 89.9% {8990ms} ProcessorScheduler class>>idleProcess 10.1% {1010ms} Delay>>wait > > If it were to -only- use the semaphore, it would run into the same issue as the non-polling fetcher made for pharo when it was properly decoupled from the UI, namely that Windoze VMs don't even raise it. Okay, so the windows VM doesn't signal the semaphore. It could/should still be used at least on other platforms. A mixed system is also possible, because one can wait for a semaphore signal with a timeout. So for windows the timeout can be 10ms, while on other platforms 1000ms. Also waiting for 10ms, no matter how long the event processing took is a bad idea IMHO. Waiting for a total 10ms (which includes the time spent during processing the events) results in a more responsive system. Btw why doesn't the windows VM signal the semaphore? Levente > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 17, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Henrik Sperre Johansen

Levente Uzonyi-2 wrote: > > > Btw why doesn't the windows VM signal the semaphore? > > > Levente > > > http://forum.world.st/InputSemaphore-on-Windows-td1934394.html#a2014576 Basically, there may or may not be some issue with them not being noticed in the image, it hasn't been a priority since the Squeak image doesn't depend on it, and no-one have set aside the time to fix it. Not very hard really, just time-consuming and tedious checking you've hit all the points it has to be signalled. Cheers, Henry -- View this message in context: http://forum.world.st/Speeding-up-Pharo-1-1-tp2998198p2999271.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 17, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Levente Uzonyi

On Sun, 17 Oct 2010, Henrik Johansen wrote: > > > Den 17. okt. 2010 kl. 00:37 skrev Levente Uzonyi <leves(a)elte.hu>: > >> Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed. >> >> >> Levente > It doesn't, there's effectively polling done in the UI threads hand processing on Squeak. I see. But MessageTally doesn't: MessageTally spyAllOn: [ 10 seconds asDelay wait ] Squeak: **Leaves** 99.7% {9970ms} ProcessorScheduler class>>idleProcess Pharo: **Leaves** 89.9% {8990ms} ProcessorScheduler class>>idleProcess 10.1% {1010ms} Delay>>wait > > If it were to -only- use the semaphore, it would run into the same issue as the non-polling fetcher made for pharo when it was properly decoupled from the UI, namely that Windoze VMs don't even raise it. Okay, so the windows VM doesn't signal the semaphore. It could/should still be used at least on other platforms. A mixed system is also possible, because one can wait for a semaphore signal with a timeout. So for windows the timeout can be 10ms, while on other platforms 1000ms. Also waiting for 10ms, no matter how long the event processing took is a bad idea IMHO. Waiting for a total 10ms (which includes the time spent during processing the events) results in a more responsive system. Btw why doesn't the windows VM signal the semaphore? Levente > > Cheers, > Henry > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 17, 2010

Re: [Pharo-project] Missing Close in About Dialog

by Bernhard Pieber

Ah, interesting! I just tested it again more thoroughly and I found out that it has to do with the size of the Pharo window. If I maximize it on my 30" display the dialog truncated so that the OK button is not visible. If I make the window is much smaller it appears. See http://dl.dropbox.com/u/6204244/Pharo%20About%20Dialog.png. Thanks for the fast response! Cheers, Bernhard Am 17.10.2010 um 16:08 schrieb Schwab,Wilhelm K: > Are you sure? I see an OK button at the bottom right of About in an image that identifies itself the same way. > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Bernhard Pieber [bernhard(a)pieber.com] > Sent: Sunday, October 17, 2010 10:05 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: [Pharo-project] Missing Close in About Dialog > > Dear Pharo Folks, > > It is a very minor thing but I wanted to let you know that the About Dialog (World Menu > System > Aboutâ¦) in the latest stable Pharo Dev image (Pharo-1.1.1-dev10.09.1) has not got any Close button. > > Cheers, > Bernhard > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 17, 2010

Re: [Pharo-project] Missing Close in About Dialog

by Schwab,Wilhelm K

Are you sure? I see an OK button at the bottom right of About in an image that identifies itself the same way. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Bernhard Pieber [bernhard(a)pieber.com] Sent: Sunday, October 17, 2010 10:05 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Missing Close in About Dialog Dear Pharo Folks, It is a very minor thing but I wanted to let you know that the About Dialog (World Menu > System > Aboutâ¦) in the latest stable Pharo Dev image (Pharo-1.1.1-dev10.09.1) has not got any Close button. Cheers, Bernhard _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 17, 2010

[Pharo-project] Missing Close in About Dialog

by Bernhard Pieber

Dear Pharo Folks, It is a very minor thing but I wanted to let you know that the About Dialog (World Menu > System > Aboutâ¦) in the latest stable Pharo Dev image (Pharo-1.1.1-dev10.09.1) has not got any Close button. Cheers, Bernhard

Oct. 17, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Igor Stasenko

On 17 October 2010 01:37, Levente Uzonyi <leves(a)elte.hu> wrote: > On Sat, 16 Oct 2010, Bart Veenstra wrote: > >> Hi list, >> >> I have been working with Pharo for almost a month now, and I suspect >> that the performance is degrading fast. UI tasks takes several seconds >> to react to my keyboard. > > That kind of sluggishness is probably related to finalization/gc. Please > send us the result of the following expression: > > (WeakArray classPool at: #FinalizationDependents) > Â Â Â Â select: [ :each | each notNil ] > Â Â Â Â thenCollect: [ :each | each class -> each size ] > > There's another source of sluggishness though. The input is only processed > at every 10 milliseconds (actually more rarely, because there's at least 10 > ms delay between input processing). > If I evalute [InputEventPollingFetcher eventPollPeriod: 1], then Pharo 1.1 > feels more responsive. > Btw it would be better to use the input semaphore instead of polling for > events, like Squeak does it. I wonder why was it changed. > because windows VM does not signaling input semaphore > > Levente > >> >> At work we use VAST and I have experience with VW as well and those >> smalltaks react to my keyboard and mouse actions instantly. But Pharo >> works very sluggish. >> >> My image is about 130MB because I have loaded all dutch postcode in >> memory, but that should not affect the performance of general >> operations like typing with the keyboard. I am not a fast typer, but >> sometimes it takes seconds to show my keyboard input. I can't use the >> down key to select the right method from suggestions, because it seems >> to lockup completely. >> >> Are there ways to speedup Pharo? I would love to use cogVM but I >> haven't got gemtools working on it... >> >> Will upgrading to 1.1.1 fix these issues? >> >> Is my OS (Windows 7-64bit) causing these issues? >> >> Regards, >> >> Bart >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 17, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Henrik Johansen

Den 17. okt. 2010 kl. 00:37 skrev Levente Uzonyi <leves(a)elte.hu>: > Btw it would be better to use the input semaphore instead of polling for events, like Squeak does it. I wonder why was it changed. > > > Levente It doesn't, there's effectively polling done in the UI threads hand processing on Squeak. If it were to -only- use the semaphore, it would run into the same issue as the non-polling fetcher made for pharo when it was properly decoupled from the UI, namely that Windoze VMs don't even raise it. Cheers, Henry

Oct. 17, 2010

Re: [Pharo-project] bad bracket autocompletion in Pharo Core 1.2

by Mariano Martinez Peck

On Sun, Oct 17, 2010 at 10:51 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > I have a question: > does shout support closing parenthesis behavior? > > > I wonder the same. I don't see the difference between this and shout smart characters. > Stef > > On Oct 16, 2010, at 10:27 PM, Pavel Krivanek wrote: > > > Can we add a setting for it? (issue > > http://code.google.com/p/pharo/issues/detail?id=3113) > > > > Cheers, > > -- Pavel > > > > On Tue, Oct 12, 2010 at 8:58 AM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> thanks! > >> > >> > >> On Oct 11, 2010, at 9:37 AM, Fernando olivero wrote: > >> > >>> Hi , it was a enhancement i did starting from a Chris Muller > enhancement for Squeak. > >>> > >>> ISSUE 2653. > >>> > http://code.google.com/p/pharo/issues/detail?id=2653&can=1&q=auto&colspec=I… > >>> > >>> I did a test, maybe a good start would be to see if its failing now. > >>> > >>> Fernando > >>> > >>> On Oct 9, 2010, at 2:18 PM, Juan Vuletich wrote: > >>> > >>>> Hi Folks, > >>>> > >>>> Cuis doesn't include #autoEnclose, so I don't know how it should > behave. > >>>> > >>>> Cheers, > >>>> Juan Vuletich > >>>> > >>>> Mariano Martinez Peck wrote: > >>>>> Guille, if I remember correctly (not sure), these new classes like > >>>>> TextEditor and Smalltalk editor came from Cuis. Juan (Cuis author) i > >>>>> think he is in the mailing list but not read it so frequently. So, > for > >>>>> this issues maybe you can cc'ed him. > >>>>> > >>>>> Cheers > >>>>> > >>>>> Mariano > >>>>> > >>>>> 2010/10/9 Guillermo Polito <guillermopolito(a)gmail.com > >>>>> <mailto:guillermopolito@gmail.com>> > >>>>> > >>>>> Here is the piece of code that's behaving weird > >>>>> > >>>>> TextEditor>>dispatchOn: > >>>>> > >>>>> ... > >>>>> ... > >>>>> char := aKeyboardEvent keyCharacter. > >>>>> openers := '([{'. > >>>>> closers := ')]}'. > >>>>> ( closers includes: char) ifTrue: [ self blinkPrevParen: > >>>>> char ]. > >>>>> result := self normalCharacter: aKeyboardEvent. > >>>>> (self class autoEnclose and: [ openers includes: char ]) > >>>>> not ifTrue: [ ^ result ]. > >>>>> suffix := closers at: (openers indexOf: char). > >>>>> paragraph text append: suffix asString. > >>>>> self moveCursor: [ : position | position ] forward: true > >>>>> specialBlock: [ : pos | "no special behavior" ] event: > >>>>> aKeyboardEvent . > >>>>> self userHasEdited. > >>>>> > >>>>> ------------------------------------- > >>>>> > >>>>> So, if I evaluate "TextEditor autoEnclose: false", it is stops > >>>>> behaving like that :) > >>>>> > >>>>> What should be the desired behavior? Having it configurable as it > >>>>> is today but fix the strange bracket adding? remove this behavior? > >>>>> I can't find now how ParagraphEditor did this. > >>>>> > >>>>> Guille > >>>>> > >>>>> > >>>>> On Wed, Oct 6, 2010 at 10:34 PM, Guillermo Polito > >>>>> <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> > wrote: > >>>>> > >>>>> Yes, the issue can be reduced to: > >>>>> > >>>>> open parenthesis (or brackets), then something else (anywhere > >>>>> in the editor). > >>>>> > >>>>> 2010/10/6 Mariano Martinez Peck <marianopeck(a)gmail.com > >>>>> <mailto:marianopeck@gmail.com>> > >>>>> > >>>>> I detected a similar problem: > >>>>> > >>>>> once you type an opening parenthesis, and then something > >>>>> else, it adds a new one at the END of the code > >>>>> > >>>>> check > http://code.google.com/p/pharo/issues/detail?id=2939 > >>>>> > >>>>> 2010/10/6 Guillermo Polito <guillermopolito(a)gmail.com > >>>>> <mailto:guillermopolito@gmail.com>> > >>>>> > >>>>> http://code.google.com/p/pharo/issues/detail?id=3069 > >>>>> > >>>>> if you type: > >>>>> > >>>>> [] -> []] > >>>>> > >>>>> () -> ()) > >>>>> > >>>>> {} -> {}} > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Bye! > >>>>> > >>>>> _______________________________________________ > >>>>> Pharo-project mailing list > >>>>> Pharo-project(a)lists.gforge.inria.fr > >>>>> <mailto:Pharo-project@lists.gforge.inria.fr> > >>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Pharo-project mailing list > >>>>> Pharo-project(a)lists.gforge.inria.fr > >>>>> <mailto:Pharo-project@lists.gforge.inria.fr> > >>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Pharo-project mailing list > >>>>> Pharo-project(a)lists.gforge.inria.fr > >>>>> <mailto:Pharo-project@lists.gforge.inria.fr> > >>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>>>> > >>>>> > >>>>> > ------------------------------------------------------------------------ > >>>>> > >>>>> > >>>>> No virus found in this incoming message. > >>>>> Checked by AVG - www.avg.com > >>>>> Version: 9.0.862 / Virus Database: 271.1.1/3184 - Release Date: > 10/08/10 03:34:00 > >>>>> > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Pharo-project mailing list > >>>> Pharo-project(a)lists.gforge.inria.fr > >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 17, 2010