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

Re: [Pharo-project] Found it! [Was: A dog-slow browser ]

by StÃ©phane Ducasse

I would like to clean that! Please open a ticket and send code. I want a fast and cool ide. Stef On May 9, 2010, at 8:42 PM, Igor Stasenko wrote: > On 9 May 2010 21:21, Lukas Renggli <renggli(a)gmail.com> wrote: >>> but i seem found the cause of it: >>> - its an annotation pane, which makes browsing so slow! >> >> Of course, but that was always like that, no? >> >> Searching through all the compiled methods to count senders and >> through the changes file for the author takes a few 100 ms each time >> you select a method. >> > well, since now i found what is the cause of it, so i can do something > to have my cake and eating it too. > > CodeHolder annotationRequests > in Pharo: > #(#timeStamp #messageCategory #sendersCount #implementorsCount #allChangeSets) > > in Squeak: > Preferences defaultAnnotationRequests > #(#timeStamp #messageCategory #implementorsCount #allChangeSets) > > So, the Squeak's browsers feels faster with annotation panes simply > because they're not including #sendersCount > by default, which takes a huge amount of time. > > And now, all i need to be happy again is just do following: > > CodeHolder annotationRequests: (CodeHolder annotationRequests > copyWithout: #sendersCount ) > > i don't wanna argue, why Pharo includes this option by default, since > i can turn it off anyways. > > Thanks , Lukas > >> Lukas >> >> >>> >>> Right now i have two browser windows opened - one with annotation pane, >>> and other is not. >>> >>> The amount of delay between selecting a particular method and showing >>> it in a code pane is significant. >>> Its even different in a look & feel: if you have annotation pane >>> turned on, each time you selecting a different method, >>> it turns mouse cursor to a hourglass for a moment, and then turns it >>> back to arrow. >>> >>> And while in browser without annotation panes i can scroll through >>> methods list without feeling any seeming delay, >>> in window with annotation pane, its feel like a system using a pigeons >>> to deliver a method's sources to me :) >>> >>> >>> On 20 January 2010 18:28, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> Please, don't take it as a offense, but as a constructive critics :) >>>> >>>> Pharo-core browser is awfully slooow! >>>> That's why i prefer to develop in squeak trunk image. >>>> Why it showing the distracting hourglass cursor when stepping over a >>>> list of methods in method's list? >>>> >>>> (press and hold the up arrow key when inside a methods list)... damn.. >>>> what happens there, that it consumes so much time >>>> to just switch the source code in a single text pane? >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 9, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by Igor Stasenko

On 9 May 2010 23:17, Alain Plantec <alain.plantec(a)free.fr> wrote: > >> Ok, i took the 11343 >> - fixed the #condenseChanges >> - ran Â Smalltalk condenseChanges >> - changed the single method >> - saved image >> - ran Â Smalltalk condenseChanges again >> >> no crash reported. >> > > Indeed, with 11343 it seems ok. > With 11326 (updated -> 11346), crash during the second condenseChanges :( Alain, could you please send me an image +.changes saved just before running a second condenseChanges? I'll try to find the cause of it. > Alain >> >> >>> >>> Alain >>> >>> >> >> >> > > > _______________________________________________ > 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.

May 9, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by Alain Plantec

> Ok, i took the 11343 > - fixed the #condenseChanges > - ran Smalltalk condenseChanges > - changed the single method > - saved image > - ran Smalltalk condenseChanges again > > no crash reported. > Indeed, with 11343 it seems ok. With 11326 (updated -> 11346), crash during the second condenseChanges :( Alain > >> Alain >> >> > > >

May 9, 2010

Re: [Pharo-project] Found it! [Was: A dog-slow browser ]

by Igor Stasenko

The only nuisance, what left is chaging the mouse cursor. IMO, SystemNavigation should avoid changing a mouse cursor by itself. It doing so, when codeholder sends: self systemNavigation allCallsOn: aSelector IMO this is wrong: SystemNavigation is a system-wide service tool, and should not assume that image having any UI or mouse cursor, which can be changed during serving queries to it. An outer layer (like UI element), which queries a SystemNavigation could change a cursor, depending on context, but not SystemNavigation itself. On 9 May 2010 23:08, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 9 May 2010 22:37, Alain Plantec <alain.plantec(a)free.fr> wrote: >> Issue 2403 <http://code.google.com/p/pharo/issues/detail?id=2403>: >> Annotation pane is slow because of #sendersCount >> >> Le 09/05/2010 21:29, Schwab,Wilhelm K a Ã©crit : > > Added fix to that issue. Â (see a changeset in issue tracker) > > With it, an annotation pane could be as slow as it wants to, but it > doesn't hurth a user's experience, > since all information is fetched in background. > So, Pharo now could have an ultra-fast method switching, which no > longer depends from slowness of annotation panes > or its particular options :) > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

May 9, 2010

Re: [Pharo-project] Found it! [Was: A dog-slow browser ]

by Igor Stasenko

On 9 May 2010 22:37, Alain Plantec <alain.plantec(a)free.fr> wrote: > Issue 2403 <http://code.google.com/p/pharo/issues/detail?id=2403>: > Annotation pane is slow because of #sendersCount > > Le 09/05/2010 21:29, Schwab,Wilhelm K a Ã©crit : Added fix to that issue. (see a changeset in issue tracker) With it, an annotation pane could be as slow as it wants to, but it doesn't hurth a user's experience, since all information is fetched in background. So, Pharo now could have an ultra-fast method switching, which no longer depends from slowness of annotation panes or its particular options :) -- Best regards, Igor Stasenko AKA sig.

May 9, 2010

Re: [Pharo-project] Found it! [Was: A dog-slow browser ]

by Alain Plantec

Issue 2403 <http://code.google.com/p/pharo/issues/detail?id=2403>: Annotation pane is slow because of #sendersCount Le 09/05/2010 21:29, Schwab,Wilhelm K a Ã©crit : > FWIW, **THANKS** for staying with this one. My vote would be to adopt the faster defaults and to add an entry to an appropriate Wiki page on how to add items of interest. > > Duty calls: I desperately need to return to my milling machine. I will no doubt get involved in various details of Â± 0.001 inch, and completely forget about this thread:( However, many others will never even become aware of it, hence my preference for the faster option. > > Bill > > > > -----Original Message----- > From:pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko > Sent: Sunday, May 09, 2010 1:43 PM > To:Pharo-project@lists.gforge.inria.fr > Subject: Re: [Pharo-project] Found it! [Was: A dog-slow browser ] > > On 9 May 2010 21:21, Lukas Renggli<renggli(a)gmail.com> wrote: > >>> >> but i seem found the cause of it: >>> >> - its an annotation pane, which makes browsing so slow! >>> >> > >> > Of course, but that was always like that, no? >> > >> > Searching through all the compiled methods to count senders and >> > through the changes file for the author takes a few 100 ms each time >> > you select a method. >> > >> > well, since now i found what is the cause of it, so i can do something to have my cake and eating it too. > > CodeHolder annotationRequests > in Pharo: > #(#timeStamp #messageCategory #sendersCount #implementorsCount #allChangeSets) > > in Squeak: > Preferences defaultAnnotationRequests > #(#timeStamp #messageCategory #implementorsCount #allChangeSets) > > So, the Squeak's browsers feels faster with annotation panes simply because they're not including #sendersCount by default, which takes a huge amount of time. > > And now, all i need to be happy again is just do following: > > CodeHolder annotationRequests: (CodeHolder annotationRequests > copyWithout: #sendersCount ) > > i don't wanna argue, why Pharo includes this option by default, since i can turn it off anyways. > > Thanks , Lukas > > >> > Lukas >> > >> > >> >>> >> >>> >> Right now i have two browser windows opened - one with annotation >>> >> pane, and other is not. >>> >> >>> >> The amount of delay between selecting a particular method and showing >>> >> it in a code pane is significant. >>> >> Its even different in a look& feel: if you have annotation pane >>> >> turned on, each time you selecting a different method, it turns mouse >>> >> cursor to a hourglass for a moment, and then turns it back to arrow. >>> >> >>> >> And while in browser without annotation panes i can scroll through >>> >> methods list without feeling any seeming delay, in window with >>> >> annotation pane, its feel like a system using a pigeons to deliver a >>> >> method's sources to me:) >>> >> >>> >> >>> >> On 20 January 2010 18:28, Igor Stasenko<siguctua(a)gmail.com> wrote: >>> >>>> >>> Please, don't take it as a offense, but as a constructive critics:) >>>> >>> >>>> >>> Pharo-core browser is awfully slooow! >>>> >>> That's why i prefer to develop in squeak trunk image. >>>> >>> Why it showing the distracting hourglass cursor when stepping over a >>>> >>> list of methods in method's list? >>>> >>> >>>> >>> (press and hold the up arrow key when inside a methods list)... damn.. >>>> >>> what happens there, that it consumes so much time to just switch the >>>> >>> source code in a single text pane? >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> Best regards, >>>> >>> Igor Stasenko AKA sig. >>>> >>> >>>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Best regards, >>> >> Igor Stasenko AKA sig. >>> >> >>> >> _______________________________________________ >>> >> Pharo-project mailing list >>> >> Pharo-project(a)lists.gforge.inria.fr >>> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >>> >> > >> > >> > >> > -- >> > Lukas Renggli >>

May 9, 2010

Re: [Pharo-project] Found it! [Was: A dog-slow browser ]

by Schwab,Wilhelm K

FWIW, **THANKS** for staying with this one. My vote would be to adopt the faster defaults and to add an entry to an appropriate Wiki page on how to add items of interest. Duty calls: I desperately need to return to my milling machine. I will no doubt get involved in various details of +/- 0.001 inch, and completely forget about this thread :( However, many others will never even become aware of it, hence my preference for the faster option. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Sunday, May 09, 2010 1:43 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Found it! [Was: A dog-slow browser ] On 9 May 2010 21:21, Lukas Renggli <renggli(a)gmail.com> wrote: >> but i seem found the cause of it: >> - its an annotation pane, which makes browsing so slow! > > Of course, but that was always like that, no? > > Searching through all the compiled methods to count senders and > through the changes file for the author takes a few 100 ms each time > you select a method. > well, since now i found what is the cause of it, so i can do something to have my cake and eating it too. CodeHolder annotationRequests in Pharo: #(#timeStamp #messageCategory #sendersCount #implementorsCount #allChangeSets) in Squeak: Preferences defaultAnnotationRequests #(#timeStamp #messageCategory #implementorsCount #allChangeSets) So, the Squeak's browsers feels faster with annotation panes simply because they're not including #sendersCount by default, which takes a huge amount of time. And now, all i need to be happy again is just do following: CodeHolder annotationRequests: (CodeHolder annotationRequests copyWithout: #sendersCount ) i don't wanna argue, why Pharo includes this option by default, since i can turn it off anyways. Thanks , Lukas > Lukas > > >> >> Right now i have two browser windows opened - one with annotation >> pane, and other is not. >> >> The amount of delay between selecting a particular method and showing >> it in a code pane is significant. >> Its even different in a look & feel: if you have annotation pane >> turned on, each time you selecting a different method, it turns mouse >> cursor to a hourglass for a moment, and then turns it back to arrow. >> >> And while in browser without annotation panes i can scroll through >> methods list without feeling any seeming delay, in window with >> annotation pane, its feel like a system using a pigeons to deliver a >> method's sources to me :) >> >> >> On 20 January 2010 18:28, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> Please, don't take it as a offense, but as a constructive critics :) >>> >>> Pharo-core browser is awfully slooow! >>> That's why i prefer to develop in squeak trunk image. >>> Why it showing the distracting hourglass cursor when stepping over a >>> list of methods in method's list? >>> >>> (press and hold the up arrow key when inside a methods list)... damn.. >>> what happens there, that it consumes so much time to just switch the >>> source code in a single text pane? >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 9, 2010

Re: [Pharo-project] (igor) Help for 1.1: condenseChanges does not work anymore

by Igor Stasenko

On 9 May 2010 21:39, Alain Plantec <alain.plantec(a)free.fr> wrote: > Le 09/05/2010 18:48, Igor Stasenko a Ã©crit : >> >> On 9 May 2010 13:29, Alain Plantec<alain.plantec(a)free.fr> Â wrote: >> >>> >> This was a result of lack of attention, not my real intent. :) >> > > ok, so we have the same version >> >> But unfortunately, this solution seems to be broken to. It works one time, >>> >>> but while trying to >>> condenseChanges again several time, my squeak process is killed without >>> flushing any log. >>> >> >> You mean running #condenseChanges multiple times in a row, or >> interrupting it and then start over again? >> You should know, that it is important to not interrupt it in the >> middle, because when you doing that, >> part of your methods having old source pointers, while rest part >> having new ones, >> and there is no way to tell, which one is correct. >> > > I take a fresh image. > SmalltalkImage current condenseChanges. > then > I update some methods individually and save my image, > then > SmalltalkImage current condenseChanges. > and it crash > Ok, i took the 11343 - fixed the #condenseChanges - ran Smalltalk condenseChanges - changed the single method - saved image - ran Smalltalk condenseChanges again no crash reported. > Alain > -- Best regards, Igor Stasenko AKA sig.

May 9, 2010

Re: [Pharo-project] Found it! [Was: A dog-slow browser ]

by Igor Stasenko

On 9 May 2010 21:21, Lukas Renggli <renggli(a)gmail.com> wrote: >> but i seem found the cause of it: >> - its an annotation pane, which makes browsing so slow! > > Of course, but that was always like that, no? > > Searching through all the compiled methods to count senders and > through the changes file for the author takes a few 100 ms each time > you select a method. > well, since now i found what is the cause of it, so i can do something to have my cake and eating it too. CodeHolder annotationRequests in Pharo: #(#timeStamp #messageCategory #sendersCount #implementorsCount #allChangeSets) in Squeak: Preferences defaultAnnotationRequests #(#timeStamp #messageCategory #implementorsCount #allChangeSets) So, the Squeak's browsers feels faster with annotation panes simply because they're not including #sendersCount by default, which takes a huge amount of time. And now, all i need to be happy again is just do following: CodeHolder annotationRequests: (CodeHolder annotationRequests copyWithout: #sendersCount ) i don't wanna argue, why Pharo includes this option by default, since i can turn it off anyways. Thanks , Lukas > Lukas > > >> >> Right now i have two browser windows opened - one with annotation pane, >> and other is not. >> >> The amount of delay between selecting a particular method and showing >> it in a code pane is significant. >> Its even different in a look & feel: if you have annotation pane >> turned on, each time you selecting a different method, >> it turns mouse cursor to a hourglass for a moment, and then turns it >> back to arrow. >> >> And while in browser without annotation panes i can scroll through >> methods list without feeling any seeming delay, >> in window with annotation pane, its feel like a system using a pigeons >> to deliver a method's sources to me :) >> >> >> On 20 January 2010 18:28, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> Please, don't take it as a offense, but as a constructive critics :) >>> >>> Pharo-core browser is awfully slooow! >>> That's why i prefer to develop in squeak trunk image. >>> Why it showing the distracting hourglass cursor when stepping over a >>> list of methods in method's list? >>> >>> (press and hold the up arrow key when inside a methods list)... damn.. >>> what happens there, that it consumes so much time >>> to just switch the source code in a single text pane? >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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.

May 9, 2010

Re: [Pharo-project] NetNameResolver in Pharo 1.1

by Schwab,Wilhelm K

Stef, Speaking of code, I have a fair bit of it that I need to check for slips and make available. The slips that are relevant would be anything in comments that might violate non-disclosure agreements[*]. What I need is something/anything that produces syntax colored output given a package name. The idea is that anything in the comment color needs careful scrutiny. Even colored html files that I could view in a web browser would probably do the trick. There was some mention that Seaside might already do this?? I will eventually look for or build something to do it, but pointers would be appreciated. [*] I try to be careful about it now, but sometimes run across old comments that were not for public consumption. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Sunday, May 09, 2010 9:33 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] NetNameResolver in Pharo 1.1 yes and we accept code :) On May 9, 2010, at 2:41 PM, Schwab,Wilhelm K wrote: > Mike, > > I completely agree that Pharo needs a clear sense of when it starts, and that network inititialization should happen then. Shutting down and restarting everything on image save is just wrong. Dolphin does all of this correctly; the key to which is to be willing to save an image that will "wake up" with garbage pointers, but will (because it realizes it is starting) clear all of that and re-initialize (often lazily) so everything is correct in the new session. Image saves are not relevant to cleanup in that case. It drove me nuts for a while, but I came to realize that it is the correct approach; one of many in Dolphin's design. > > One caveat that we should consider: the weird state of network initialization is perhaps not just due to the absense of session management in Squeak. It has been explained (Guzdial and Rose??) as being done in deference to some platforms that would react badly to premature network initialization. Is this just to allow dialup connections on some long-extinct platform? Is it just an excuse to provide cover for Squeak's lack of session management? Is it something that made some sense in 1995, but it obsolete in 2010? Sorry to be so blunt, but there might actually be a good reason for it (perhaps one that is no longer worth the cost) and we won't be able to decide that until we grapple with the truth on both sides. > > Another possibility: suppose that to do dialup on your ENIAC, there are problems with #initializeNetwork if it is called before you change the computer's oil. The problems might be real on some platforms. Does that mean that broadband-enabled Windows, Mac and Linux users all have to suffer because somebody has a museum piece somewhere? The answer might be to provide a command line option to defer initialization until the system is ready, but otherwise to do it once on startup. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Michael Roberts > Sent: Sunday, May 09, 2010 3:21 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] NetNameResolver in Pharo 1.1 > > On Sun, May 9, 2010 at 9:06 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >>> We should run the Magma test suite. >> >> Could you do that? > > Yes, i'm just asking Chris what the latest packages are. My emails on the subject don't seem to match the repository any more. > >> >>> It was not just related to those NetNameResolver methods IIRC. The >>> API changed very slightly. Also, the lazy initialization of >>> useOldNetwork made it really difficult to see what was going on. >> >> In my experiments #useOldNetwork was always 'false' on all platforms >> (Mac, Linux and Windows). Is this something that depends on the VM? > > I don't think so. I think it could just get into an odd state. Perhaps when using OSProcess to spawn/fork new images? > > >> Maybe we should rather remove the old network code and throw an error >> if somebody is using an old VM that doesn't support the new >> primitives. > > I would really like to remove the old network code. Definitely remove the switch and all the parallel code paths. Also, to me the network should be initialized on image startup once, and not when the first message is sent to the network classes. There are far too many checks for it. We need to be careful what the old and new API are. this is where documentation would really help. > > I ran your methods quickly. I'm a bit confused. NetNameResolver is now only returning a single address on my machine whereas before it returned a list of many for the local host. This was part of the problem, in that there was no order. There are various threads on it. > But what changed to cause this? Did we change 1.1 or the VM has a small change? i didn't track either. > > cheers, > Mike > >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> 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

May 9, 2010