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

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

by Lukas Renggli

> 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. 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

May 9, 2010

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

by Igor Stasenko

Hello guys, sorry for resurrecting this topic, but i seem found the cause of it: - its an annotation pane, which makes browsing so slow! 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.

May 9, 2010

Re: [Pharo-project] Where is my beloved annotation panes?

by Igor Stasenko

Found it. Thanks. On 9 May 2010 20:40, Alain Plantec <alain.plantec(a)free.fr> wrote: > Le 09/05/2010 19:30, Igor Stasenko a Ã©crit : >> >> Hi, guys, >> >> the first thing, which i always doing on fresh image is turning on the >> annotation panes, so i can always see the method's author and last >> modification date. >> I found that in newest pharo1.1.(11343) this option (as well as many >> others) is gone from preferences browser. >> Please, tell me that you didn't removed it, and this is only a >> temporary regression. >> > > :) > > From the setting browser: > Code browsing/Show annotation pane > or: > CodeHolder showAnnotationPane: true > > Cheers > 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] Where is my beloved annotation panes?

by Alain Plantec

Le 09/05/2010 19:30, Igor Stasenko a Ã©crit : > Hi, guys, > > the first thing, which i always doing on fresh image is turning on the > annotation panes, so i can always see the method's author and last > modification date. > I found that in newest pharo1.1.(11343) this option (as well as many > others) is gone from preferences browser. > Please, tell me that you didn't removed it, and this is only a > temporary regression. > :) From the setting browser: Code browsing/Show annotation pane or: CodeHolder showAnnotationPane: true Cheers Alain

May 9, 2010

[Pharo-project] Where is my beloved annotation panes?

by Igor Stasenko

Hi, guys, the first thing, which i always doing on fresh image is turning on the annotation panes, so i can always see the method's author and last modification date. I found that in newest pharo1.1.(11343) this option (as well as many others) is gone from preferences browser. Please, tell me that you didn't removed it, and this is only a temporary regression. -- Best regards, Igor Stasenko AKA sig.

May 9, 2010

Re: [Pharo-project] new gettext package

by Philippe Marschall

On 07.05.2010 16:17, Hilaire Fernandes wrote: > I have uploaded a new version of the gettext package. I have removed a > few classes used for the itnernal translator. So now, only gettext based > catalog messages is used. > > Philipp, I have added a String>>translateTo: aLocale you can used from > Seaside application. Thanks, but I think I don't need it. I spent a bit of time hacking and came up with a protoype [1] (Seaside-Gettext-Core and Seaside-Gettext-Examples). - I made a per request localization context that caches the domain, locale and translator. That stuff now is only looked up the first time you translate a string in a request. Because of this I can use #translate:inDomain: directly. - The domain is based on the application and not the class category of the sender. - The locale is first looked up on the session and then the request. - I made a subclass of GetTextExporter that uses a custom TranslatedReceiverFinder based on RB (thanks to Lukas "Wizard of RB") that searches for my selectors. I'll make a post to seaside-dev on how to use it. I'm a happy camper now. [1] http://www.squeaksource.com/Seaside29Addons.html Cheers Philippe

May 9, 2010

Re: [Pharo-project] Freetype plugin archive

by David T. Lewis

On Sun, May 02, 2010 at 08:55:33AM -0700, Michael Rueger wrote: > On 5/1/10 11:31 AM, Bert Freudenberg wrote: > >On 01.05.2010, at 18:31, David T. Lewis wrote: > > >>Do you know if the rest of the stuff in http://source.impara.de/freetype/ > >>still has value (or has it been superceded by Freetype Plus)? > > I would think so, that's why there wasn't any further development on the > freetype plugin. > The current repositories are of somewhat historical value for e.g. the > Sophie builds. I have opened a new SqueakSource project for the Freetype plugin (FT2Plugin). MCHttpRepository location: 'http://www.squeaksource.com/FreetypePlugin' user: '' password: '' This contains copies of all the Freetype-Plugin entries from the archival repository at http://source.impara.de/freetype, as well as one additional update from Mantis 7521. Project administrators are Andy Tween, Bert Freudenberg and me. Developers are everyone whose author initials appear in the original archive. VMMaker class>>updateFromServer should now load FT2Plugin from the new FreetypePlugin repository. A similar update will be needed for ConfigurationOfVMMaker for Pharo. For now the original package name Freetype-Plugin has been retained, although I note that this conflicts with the current packaging of Freetype in SqS/Freetype Plus, so a change to the package name may be in order. FT2Plugin contains dependencies on Freetype. This is the reason that I moved it to a separate SqueakSource project rather than include it in the SqS/VMMaker repository. Dave

May 9, 2010

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

by Igor Stasenko

On 9 May 2010 20:03, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > The problem was mainly that the UI did not show that it was destroying a lot of methods and I thought it was > blocked. So if you wait enough it seems ok. Lukas checked and reparse and check the system and it seems ok. > Yeah, i also had some troubles with interrupting it, caused by running an infinite loop. :) > Stef > > On May 9, 2010, at 6:55 PM, Igor Stasenko wrote: > -- Best regards, Igor Stasenko AKA sig.

May 9, 2010

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

by StÃ©phane Ducasse

The problem was mainly that the UI did not show that it was destroying a lot of methods and I thought it was blocked. So if you wait enough it seems ok. Lukas checked and reparse and check the system and it seems ok. Stef On May 9, 2010, at 6:55 PM, Igor Stasenko wrote: > Probably , a more crash-proof #condenseChanges > would be to use a mass-become. > So, you are not modifying existing methods, but making their copies > with updated source pointers > and copying their source into new changes file. > Then you do a single mass-become and so, all old methods get swapped > with new ones using a single massive blow. > In that way, its more safe, since if you interrupt the > #condenseChanges in the middle, > you can use debugger and browse the code , and if you decide to abort > it, nothing bad happen, > since methods with new source pointers is held in your temp collection > and not yet applied. > > On 9 May 2010 19:48, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 9 May 2010 13:29, Alain Plantec <alain.plantec(a)free.fr> wrote: >>> Hi all, >>>>> >>>>> i just replaced it with following: >>>>> >>>>> (CompiledMethod allInstances reject: #isInstalled) do: [:e | e >>>>> isInstalled ifFalse: [e destroySourcePointer]]. >>>>> >>>> >>>> Yes clearly a conceptual bug. >>>> But with the solution alain proposed ie not destroying while iterating on >>>> methods does not work >>>> (yes it condenses well but accessing some methods is broken). >>>> >>> >>> yes but Igor solution is a little bit different because 'e isInstalled' is >>> tested twice, >>> one for the reject: and the second in the do: block. >> >> This was a result of lack of attention, not my real intent. :) >> >> In bug entry for this issue i added a method which does just: >> (CompiledMethod allInstances reject: #isInstalled) do: #destroySourcePointer. >> >> there's no way how method can become installed when you changin its trailer. >> So, a single test #isInstalled is sufficient. >> A more faster way is to use a mass-become. >> But i think this is not a place where you need to care too much about >> performance. >> >>> 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. >> >>> Alain >>>> >>>> Lukas did a cool test that checks whether the we can parse the method. >>>> >>>> >>>> >>>>> >>>>> and made it to the end.. took about 5 minutes to wait. (12k methods + >>>>> become on every method is a little time consuming ;) >>>>> >>>>> -- >>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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. >> > > > > -- > 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

Probably , a more crash-proof #condenseChanges would be to use a mass-become. So, you are not modifying existing methods, but making their copies with updated source pointers and copying their source into new changes file. Then you do a single mass-become and so, all old methods get swapped with new ones using a single massive blow. In that way, its more safe, since if you interrupt the #condenseChanges in the middle, you can use debugger and browse the code , and if you decide to abort it, nothing bad happen, since methods with new source pointers is held in your temp collection and not yet applied. On 9 May 2010 19:48, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 9 May 2010 13:29, Alain Plantec <alain.plantec(a)free.fr> wrote: >> Hi all, >>>> >>>> i just replaced it with following: >>>> >>>> (CompiledMethod allInstances reject: #isInstalled) do: [:e | e >>>> isInstalled ifFalse: [e destroySourcePointer]]. >>>> >>> >>> Yes clearly a conceptual bug. >>> But with the solution alain proposed ie not destroying while iterating on >>> methods does not work >>> (yes it condenses well but accessing some methods is broken). >>> >> >> yes but Igor solution is a little bit different because 'e isInstalled' is >> tested twice, >> one for the reject: and the second in the do: block. > > This was a result of lack of attention, not my real intent. :) > > In bug entry for this issue i added a method which does just: > (CompiledMethod allInstances reject: #isInstalled) do: #destroySourcePointer. > > there's no way how method can become installed when you changin its trailer. > So, a single test #isInstalled is sufficient. > A more faster way is to use a mass-become. > But i think this is not a place where you need to care too much about > performance. > >> 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. > >> Alain >>> >>> Lukas did a cool test that checks whether the we can parse the method. >>> >>> >>> >>>> >>>> and made it to the end.. took about 5 minutes to wait. (12k methods + >>>> become on every method is a little time consuming ;) >>>> >>>> -- >>>> 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 >>>> >>> >>> _______________________________________________ >>> 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. > -- Best regards, Igor Stasenko AKA sig.

May 9, 2010