- Pharo-dev - lists.pharo.org

[Pharo-project] pier 1.2

by Tudor Girba

Hi, We are happy to announce the release of Pier 1.2: http://www.piercms.com/download Whatâs new: - Mature value links (see http://www.piercms.com/doc/syntax for more details) - No _s or _k cruft in the url - Remembered last login - Smaller javascript code for faster page loading - Better default CSS (including a style for events) - Halos for enhanced editing - Pharo 0.1-10374 inside Enjoy and let us know what you think. Cheers, Lukas and Doru

July 11, 2009

[Pharo-project] Issue 946: UnicodeCompostitionStream and AttributedTextStream should be removed

by StÃ©phane Ducasse

Is it correct? What is the status of these classes? Sted

July 11, 2009

[Pharo-project] [ANN] 10376

by StÃ©phane Ducasse

- sender package annotation removed in default (non OB browser) - float fix 943

July 11, 2009

[Pharo-project] sender speed up

by StÃ©phane Ducasse

Hi guys in 10376 I removed the package information from the sender item list. MessageSet Can you have a look if this is better? worth not having the information? Stef

July 11, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Re: Usability and look-and-feel (was Re: The future ofSqueak & Pharo (was Re: [ANN] Pharo MIT licenseclean))

by StÃ©phane Ducasse

Thanks henrik I will have a look at that. If sombody else want to try and comment. It would be great! Stef On Jul 10, 2009, at 10:55 AM, Henrik Sperre Johansen wrote: > On 09.07.2009 23:03, Lukas Renggli wrote: >> >>> OUCH!!!! That's quite an example; just for giggles, I started up >>> a 3.9 polymorph image and retraced my steps (via message names, >>> same as in Pharo) and had a prompt reply. After doing that, I >>> found that Pharo (win32) had indeed completed the task. >>> >> >> Again, this has nothing to do with Pharo, OmniBrowser or Polymorph. >> >> This is PackageInfo that is so slow when trying to find out the >> owning >> package of each of the 6334 methods. If the display of the package >> for >> every method is removed the sender browser opens almost instantly. >> >> Lukas >> >> > Hmmm, really? I do have a fast machine, and it ran in 1,7 seconds > for me, but when I run TimeProfileBrowser on the block (first time, > later runs alot of stuff is already cached and thus won't show up as > prominently if you do TimeProfile on opening a batch of windows ), I > get the following percentages: > - 32% building the dynamic "all" category > - 19% reading all subclass selectors (these are then cached). > - 13% reading the timestamp of the compiledMethods /(these are > then cached) from sources to see if they're recent > - 20% finding extension classes, amongst other things PackageInfo > here spends half that time doing an includes: check with an > OrderedCollection with 174 elements... > -41% building the OB UI. > -7% GC'ing > > A good increase in response time could probably be seen by, as you > said, not selecting all category by default, instead promising of > it's calculation (In VisualWorks anyways, for those who don't know, > it's the same as a fork which returns a value, but blocks if the > value it attempted to be used before it's finished calculated). > > 2 small Performance "bugs" I encountered while checking the methods: > OBPackagesOrClassNode>>addUnpackagedCategories: categories to: pkgs > does: > SystemOrganization categories asSet difference: categories > Looking at what the includes check in difference: is done against, > it's clear the code should be: > SystemOrganization categories difference: categories asSet. > Difference: 500 repetitions in the debugger I had open at the time: > 10866 ms vs 581 ms. (20 times faster) > > PackageInfo >> externalClasses > reads: > myClasses := self classesAndMetaClasses. > then does an includes: check, could add an asSet on end there: > myClasses := self classesAndMetaClasses asSet. > Difference: 500 repetitions in the debugger I had open at the time: > 105444ms vs 11447 ms (9 times faster) > > With these 2 changes, the 20% in finding extension classes was > reduced to 11%. > > Cheers, > Henry > > > > <UseSetForIncludes. > 1.cs>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 11, 2009

Re: [Pharo-project] Pharo VM setup problem: where is pharo-vm-0.15.1b-linux source package available?

by StÃ©phane Ducasse

we can use the wiki (or the inria crappy site :)) Stef On Jul 10, 2009, at 11:42 PM, Mariano Martinez Peck wrote: > Stef: where should I put this type of things so that not to forget > it ? > > Google code seems not to have tickets that aren't bugs...or I don't > see them > > Best, > > Mariano > > On Thu, Jul 2, 2009 at 2:23 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > Thanks for the idea. > this would be nice to have a pointer to a forge for the vm code. > > Stef > > > Hi Mariano, > > > > I welcome your decision. More reasons: > > > > - Most linux distributions do not have a standard configuration. > > If you cannot go through the configuration/make/install cycle, a > > package may simply not run on a certain target system. > > If you cannot go through these cycles, your possibilities to fix > > that are very limited. > > > > - Without sources, consumers cannot directly contribute to the > defect > > tracking, fixing or development process > > > > > > Cheers, > > > > Andreas > > > > > > > > Mariano Martinez Peck schrieb: > >> I also think adding sources to Pharo webpage is a good idea. I saw > >> a lot of > >> people, who say "I wont use an enviorment in production that I > >> cannot have > >> the code and build it by myself". And I think they are correct! > >> > >> > >> On Wed, Jul 1, 2009 at 2:33 PM, Andreas Leidig <Andreas.Leidig(a)gmx.net > >> >wrote: > >> > >>> Dear List, > >>> > >>> who has/where is pharo-vm-0.15.1b-linux source package? > >>> > >>> I have a setup problem which I think I can determine or even solve > >>> with > >>> the sources. > >>> > >>> > >>> Cheers, > >>> > >>> Andreas > >>> > >>> > >>> _______________________________________________ > >>> 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

July 11, 2009

Re: [Pharo-project] Fix for issue 948

by StÃ©phane Ducasse

Soon integrated. I will also revert the senders annotation with package. stef On Jul 10, 2009, at 10:52 PM, Nicolas Cellier wrote: > Name: SLICE-Issue948-Mantis7361-FloatCompare-nice.1 > Author: nice > Time: 10 July 2009, 10:44:40 pm > UUID: 6460f6cf-3eab-4195-8013-a10d080c4b7b > Ancestors: > Dependencies: Kernel-nice.renggli.363, KernelTests-nice.121 > > Test and fix for issue http://code.google.com/p/pharo/issues/detail?id=948 > mantis http://bugs.squeak.org/view.php?id=7361 > > self assert: 0.5 >= (1/2). > > Thanks to Eliot for finding > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 11, 2009

[Pharo-project] [ANN] 103745

by StÃ©phane Ducasse

- adding gofer script in ScriptLoader :) - removing a lot of project related methods. Stef

July 11, 2009

Re: [Pharo-project] Fwd: [squeak-dev] Re: Usability and look-and-feel (was Re: The future ofSqueak & Pharo (was Re: [ANN] Pharo MIT licenseclean))

by StÃ©phane Ducasse

On Jul 10, 2009, at 9:31 PM, Schwab,Wilhelm K wrote: > Stef, > > One of my greatest concerns about/for the Squeak community is an > overall tone of "*YOU* can't do that because *I* think its's ugly" - > or in this case, too slow. So, far be it from me to tell you that > you cannot have even a super slow browser that does something you > need. That's all the more true when you are doing such great things > for Smalltalk and Pharo in particular. I am certainly not > suggesting that we remove the browser that helps you make things > better. > > However, I suggest that we consider carefully what we choose as the > default tools, or at least give options to those who are finding the > current defaults to be slow. Even if we continue with the OB as the > default, we could at least have a script somewhere with a comment > along the lines of "for a faster (at the expense of features) IDE, > evaluate the following:". Yes we are concious about that. > It appears that we indeed have the alternate tools lurking in the > image, so a little advertising might go a long way until we can fix > the bottlenecks or Elliot makes a VM that overpowers them. I > *think* I am asking only that we advertise the options and perhaps > delay cleaning certain parts of the system until the high end tools > get a speed boost. Alternately, we could take up a recent > suggestion to temporarily disable specific features that are > hobbling performance - either way that preserves what you need is > fine by me. Is that reasonable? Yes I agree.

July 11, 2009

Re: [Pharo-project] Fwd: good keybinder

by StÃ©phane Ducasse

On Jul 10, 2009, at 8:16 PM, Esteban Lorenzano wrote: > On 2009-07-10 13:16:50 -0300, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> said: > >> >> >> Hi all >> >> I would love to have emacs like end of line and others. >> I remember that there were two keybinding frameworks working in >> Squeak. >> It would be great to rescue one and use it in pharo. >> Do you have any personal experience with that issue? >> >> Stef > > Well... Mars project was born because I was unable to properly program > a cmd+w key with keybinder :P > but anyway, +1 to a good keybinder :) :-D What are the news from Mars? Stef > > Esteban > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 11, 2009