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

Re: [Pharo-project] New changes to Gofer

by Fernando olivero

Thanks for the advice! I'll adapt the AlienLoader to the work with Metacello and post it when its done. Fernando Il giorno Oct 22, 2009, alle ore 8:42 PM, Tudor Girba ha scritto: > If you want to take a look at the Metacello configuration of Moose, > you can find it in the ConfigurationOfMoose package. > > Cheers, > Doru > > > On 22 Oct 2009, at 20:40, StÃ©phane Ducasse wrote: > >> may be fernando you should have a look at Metacello >> because it is used gofer and it will be the way to go soon :) >> You can have a look at Glamour, Mondrian or MooseLoader as an >> example. >> >> Stef >> >> On Oct 22, 2009, at 8:34 PM, Fernando olivero wrote: >> >>> Hi, when loading Lumiere an deprecation warning comes up, seems that >>> the Flair configuration and gofer usage change significantly. >>> >>> Gofer Seems to have a much more expresive protocol now! Great! >>> >>> But could somebody provide examples on how to implement behavior >>> in a >>> loader for >>> >>> 1. loading the lastest versions of several packages. >>> 2. commit to squeaksource some pacakges >>> >>> Would be really helpfull to update Alien, AlienOpenGL, Lumiere >>> loaders. >>> >>> >>> Fernando >>> >>> _______________________________________________ >>> 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 > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 22, 2009

Re: [Pharo-project] Bug in OCompletion

by Mariano Martinez Peck

Yes! because it has also included a really nice improvement in the "UI" thanks to Michael Davids. On Thu, Oct 22, 2009 at 5:13 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Thanks indeed! > > I guess the fix made it in the latest dev image, because now it is a > pleasure to work with OCompletion. > > Cheers, > Doru > > > On 20 Oct 2009, at 02:18, Mariano Martinez Peck wrote: > > > Thanks to romain, he did a fix. I think it would be integrated in > > next Pharo dev. See details here: > > > > http://code.google.com/p/pharo/issues/detail?id=1236 > > > > cheers > > > > mariano > > > > On Sun, Oct 18, 2009 at 7:03 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com > > > wrote: > > This bug has been closed but I can still reproduce it in 10479. Can > > someone please test it and tell me if I am not > > > > the only one. > > > > Thanks > > > > mariano > > > > > > > > On Wed, Sep 23, 2009 at 4:29 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr > > > wrote: > > > > > > Begin forwarded message: > > > >> From: Mariano Martinez Peck <marianopeck(a)gmail.com> > >> Date: September 23, 2009 8:20:40 PM CEDT > >> To: Pharo Development <pharo-project(a)lists.gforge.inria.fr> > >> Subject: [Pharo-project] Bug in OCompletion > >> Reply-To: Pharo-project(a)lists.gforge.inria.fr > >> > >> http://code.google.com/p/pharo/issues/detail?id=1236 > >> > >> Tested with OBSystemBrowserAdaptor in pharo1.0-10451-BETAdev09.09.3 > >> on Windows. > >> > >> To reproduce: > >> > >> 1) Open a System Browser > >> 2) Create a new class. When you do this, when you are changing > >> "#NameOfSubclass" to "#YourClass", after doing this press the down > >> arrow key > >> 3) An empty pop up will be brought and the keyboard won't respond. > >> To fix > >> this, you must press "Esc" key. > >> > >> > >> Best, > >> > >> Mariano > >> > >> _______________________________________________ > >> 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 > > -- > www.tudorgirba.com > > "If you interrupt the barber while he is cutting your hair, you will > end up with a messy haircut." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2009

Re: [Pharo-project] Bug in OCompletion

by Tudor Girba

Thanks indeed! I guess the fix made it in the latest dev image, because now it is a pleasure to work with OCompletion. Cheers, Doru On 20 Oct 2009, at 02:18, Mariano Martinez Peck wrote: > Thanks to romain, he did a fix. I think it would be integrated in > next Pharo dev. See details here: > > http://code.google.com/p/pharo/issues/detail?id=1236 > > cheers > > mariano > > On Sun, Oct 18, 2009 at 7:03 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > > wrote: > This bug has been closed but I can still reproduce it in 10479. Can > someone please test it and tell me if I am not > > the only one. > > Thanks > > mariano > > > > On Wed, Sep 23, 2009 at 4:29 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > > wrote: > > > Begin forwarded message: > >> From: Mariano Martinez Peck <marianopeck(a)gmail.com> >> Date: September 23, 2009 8:20:40 PM CEDT >> To: Pharo Development <pharo-project(a)lists.gforge.inria.fr> >> Subject: [Pharo-project] Bug in OCompletion >> Reply-To: Pharo-project(a)lists.gforge.inria.fr >> >> http://code.google.com/p/pharo/issues/detail?id=1236 >> >> Tested with OBSystemBrowserAdaptor in pharo1.0-10451-BETAdev09.09.3 >> on Windows. >> >> To reproduce: >> >> 1) Open a System Browser >> 2) Create a new class. When you do this, when you are changing >> "#NameOfSubclass" to "#YourClass", after doing this press the down >> arrow key >> 3) An empty pop up will be brought and the keyboard won't respond. >> To fix >> this, you must press "Esc" key. >> >> >> Best, >> >> Mariano >> >> _______________________________________________ >> 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 -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Oct. 22, 2009

Re: [Pharo-project] feedback about the "new inspector"

by Frederic Pluquet

Hello, Thank you for the feedback on NewInspector. This tool was firstly designed to be easily configurable for adapting the childs/label/description/callback to the needs of each developer. I think the default configuration seems to be too far from your wishes. The cool thing is that the configuration can be changed easily for each class :) So you must find the perfect default configuration for each class. I'll go to OOPSLA tomorrow. I will try to reflect on all your comments during the conference. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet On Thu, Oct 22, 2009 at 1:56 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Yes or you click on the class and say expand and this means that you > inpect it then. > > Stef > > On Oct 22, 2009, at 11:41 AM, Johan Brichau wrote: > > > > > On 22 Oct 2009, at 11:03, George Herolyants wrote: > > > >> 2009/10/21 Johan Brichau <johan.brichau(a)uclouvain.be>: > >>> - Do not 'inspect/explore' the class as a normal object but make it > >>> jump to a browser instead > >> > >> I don't agree with it. Class is a normal object and must be inspected > >> as all other objects, I think. But, it would be great to have menu > >> item or shortcut to open the class being inspected in a browser. > > > > Of course, inspecting classes as normal objects should still be > > possible using the inspector. > > In essence, 'Object inspect' should still open the normal inspector. > > > > My comment relates to having the 'Class' link in the tree. I have > > never wanted to inspect the class of an object at that level when > > inspecting 'regular objects'. Instead, I want to know the Object's > > class and use the convenient class browsers to find which methods the > > object understands. > > > > cheers > > > > ---------------------------- > > Johan Brichau > > johan.brichau(a)uclouvain.be > > > > > > > > > > > > _______________________________________________ > > 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. 22, 2009

Re: [Pharo-project] Perfect hash [was: Re: HashTable vs Dictionary]

by Andres Valloud

My point would be that either: * the hashed storage is always of size 1000 (or greater), so if you store a few objects in the hashed collection it wastes a lot of space; * the hashed storage changes size to match the objects stored in it, but looking at f(x) mod p risks reintroducing the collisions you wanted to avoid in the first place. So, to not waste space in this particular scenario, then either N should be small or basically all N objects should be stored in the hashed collection. If N is small, then why not set f(x) to produce values between 1 and N, and then use an array? And if N is large and the utilization of the hashed collection is close to 100% of N, then why not also use an array in that case? In the end, really nice perfect hash functions point the finger at alternatives that may obviate using hashed collections. Of course, your mileage may vary... Andres. Martin McClure wrote: > Andres Valloud wrote: > >> I thought I'd point out a subtle potential problem. Assume N = 1000, >> f(x_j) = j-1, and so k = 1 because 0 <= f(x_j) < N because 0 < j <= >> 1000. Now, store x_{7i} in a Set, for all i such that 1 <= 7i <= 1000. >> Clearly, f(x) is a perfect hash function as defined above. However, if >> the size of the table used by the set is a multiple of 7, performance >> will be terrible. >> >> > > Huh? If your hash function produces integers between 0 and 999, your > table size must be at least 1000, otherwise you store past the end of > your table. > > Regards, > > -Martin > >

Oct. 22, 2009

Re: [Pharo-project] HashTable vs Dictionary

by Andres Valloud

The nice way of doing this would be to have a layer of indirection so that the storage strategy decides how to use the hashed storage. However, compared to the current Set/Dictionary implementation, that may be a bit slower. It would not be a terrific idea to have multiple subclasses of Set/Dictionary depending on the storage strategy, as that would result in an explosion of classes. John M McIntosh wrote: > In the far past Visual Age would become the implementation logic for > Sets depending > on how big the set was, so for example with 10 elements it would be > linear list. Of course > it's been 14 years, perhaps I'm remembering it wrong. > > On 2009-10-22, at 6:46 AM, Lukas Renggli wrote: > > >>> So this means that by default we have bad performance. no? >>> >> No. >> >> In a fresh Pharo Web image less than 6% of the keys in Dictionaries >> and less than 10% of the values in Sets have a weak-hashes. Moreover >> the largest set with weak-hash values has 516 elements (on average >> only 1.8 elements), the largest dictionary with weak-hash keys has >> 1002 elements (on average only 4.3 elements). Using HashTable in such >> a situation would introduce a major speed penalty and waste a lot of >> memory. >> >> It would be cool if the Set and the Dictionary would choose their >> implementation strategy automatically depending on the use-case. In a >> standard Pharo image however that would just be the current >> implementation. There are simply no instances in the image where it >> would be worthwhile (large amount of data with bad hash) to use a >> HashMap. >> >> Lukas >> >> -- >> Lukas Renggli >> http://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 >> > > -- > = > = > = > ======================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

Oct. 22, 2009

[Pharo-project] release image 11011 for 1.1-alpha on the inria web site

by StÃ©phane Ducasse

Hi I released image 11011 for 1.1-alpha on the inria web site Stef

Oct. 22, 2009

Re: [Pharo-project] The package of ParagraphEditor

by StÃ©phane Ducasse

Yes! Stef On Oct 22, 2009, at 9:26 PM, Nicolas Cellier wrote: > I never understood why a User Interface class was in the Kernel > I'm curious to know what Pavel think about it ! > Squeak/trunk put it to a better place: > > ParagraphEditor ( snip ) > category: 'ST80-Controllers' > > Shouldn't Pharo follow this re-classification ? > > Nicolas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 22, 2009

[Pharo-project] The package of ParagraphEditor

by Nicolas Cellier

I never understood why a User Interface class was in the Kernel I'm curious to know what Pavel think about it ! Squeak/trunk put it to a better place: ParagraphEditor ( snip ) category: 'ST80-Controllers' Shouldn't Pharo follow this re-classification ? Nicolas

Oct. 22, 2009

Re: [Pharo-project] Perfect hash [was: Re: HashTable vs Dictionary]

by Martin McClure

Andres Valloud wrote: > > I thought I'd point out a subtle potential problem. Assume N = 1000, > f(x_j) = j-1, and so k = 1 because 0 <= f(x_j) < N because 0 < j <= > 1000. Now, store x_{7i} in a Set, for all i such that 1 <= 7i <= 1000. > Clearly, f(x) is a perfect hash function as defined above. However, if > the size of the table used by the set is a multiple of 7, performance > will be terrible. > Huh? If your hash function produces integers between 0 and 999, your table size must be at least 1000, otherwise you store past the end of your table. Regards, -Martin

Oct. 22, 2009