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

Re: [Pharo-project] vm on ubuntu

by Dale Henrichs

Oct. 31, 2009

Re: [Pharo-project] dictionary value is an array?

by StÃ©phane Ducasse

what is a parallel array? > 2009/10/31 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Hello all, >> >> FWIW, Dolphin "lookup tables" use parallel arrays for keys and >> values. OA's claim (I do not dispute it, I'm simply reporting what >> they said) is that the result is faster than a dictionary based on >> associations. >> >> Bill >> >> > > Squeak.MethodDictionary is an example of this pattern too > >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- >> project-bounces(a)lists.gforge.inria.fr] On Behalf Of Nicolas Cellier >> Sent: Saturday, October 31, 2009 9:23 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] dictionary value is an array? >> >> 2009/10/31 Igor Stasenko <siguctua(a)gmail.com>: >>> 2009/10/31 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>> 2009/10/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>>> >>>>> Hi nicolas >>>>> >>>>> If I remember you proposed fixes to have dictionary values -> >>>>> array? >>>>> Is it correct? >>>>> >>>>> I was wondering why? >>>>> Because a set makes more sense to me since >>>>> - the order of the elements in values is not useful >>>>> (because >>>>> they come from a dict) >>>>> - the occurrences not really either >>>>> - we cannot add to the results so we should create another >>>>> collection >>>>> >>>>> May be I'm totally wrong with the changes but I think that values >>>>> should be set while keys an array. >>>>> I would be interested in discussion on that. >>>>> >>>>> Stef >>>>> >>>>> >>>> >>>> Dictionary values is already an Array... >>>> I proposed to change keys accordingly. >>>> >>>> Historically, they were a Bag and a Set because they were >>>> unordered. >>>> >>>> But very few or no sender expect a behavior specific to a Bag or >>>> a Set. >>>> Most just do: select: collect: asArray asSortedCollection etc... >>>> That's where an Array outperforms a Set or a Bag. >>>> >>>> So we are paying the price of a Set or a Bag almost for nothing... >>>> And that is why you can see a #fasterKeys. >>>> >>>> The drawback is that a few senders will add: to or remove: from >>>> keys. >>>> My estimation is around 5%. >>>> Inside the image, no problem, it is easy to fix, just write >>>> (someDictionary keys asSet). >>>> But that put a load on package maintainers. >>>> >>> >>> +1 Nicolas. Personally, i think that modifying a collection which >>> not >>> constructed by your own code >>> is bad programming style, because you never know where this >>> collection >>> is came from and you can't be sure that there is no other users of >>> it, >>> which in own turn may modify it at any moment, while often you >>> assuming that only you own the collection and don't expecting any >>> modifications to it except in own code. >>> So, IMO this approach is error prone, and you should never use >>> #remove: or #add: with collections which constructed by separate >>> package/layer, and instead, use #asSet, #asOrderedCollection and, of >>> course #copy, before starting manipulating its elements. >>> >> >> I agree. removing from another one's collection is not that well >> behaved ! >> It's putting expectations higher than necessary. >> >> I see this as a sort of optimization breaking encapsulation... >> I want to come with a better optimization. >> Unfortunately, historical uses will be found here and there, #keys >> being a well-known case. >> We have to put pressure on maintainers... >> Who ever takes this path shall be ready to sell the idea, and prove >> that gains > costs. >> >> A team modifying kernel in uncompatible manner (and we have to, or >> just stick to Squeak 3.7) shall provide support for a smooth >> transiiton. >> Sometimes I feel it would be convenient to inquire a code base >> larger than just an image, so that we can emit proposals and sell >> the idea rather than just waiting for complaints passively.... >> >> Nicolas >> >>> >>>> Nicolas >>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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. >>> >>> _______________________________________________ >>> 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. 31, 2009

Re: [Pharo-project] Pharo analog to Dolphin's "immediate objects"?

by Nicolas Cellier

2009/10/31 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Hello all, > > Dolphin stores small integers and characters entirely in the header, and describes them as having "immediate" storage. Â Is there a similar concept in Pharo? > > I _think_ I can get around it by looking at other tests such as #isBytes, but I am still trying to decide whether they are simply named the same way or actually do the same thing. > > Bill > In squeak, Characters are not immediate... SmallInteger are. I don't see an #isImmediate message though unlike VW/Dolphin... > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 31, 2009

Re: [Pharo-project] Bitten by MethodReference

by StÃ©phane Ducasse

>> > > Yes, i wondering myself, what is the point to reference the methods in > such style. > The way, how actual class & its method get resolved makes it > impossible to reference a method in > arbitrary class object, especially one which is not installed into > system dictionary. Indeed. I have no idea. > I think its lacking additional form of indirection, which should be an > environment object who is responsible for > delivering the method's source code along with resolving the class by > its name. Without such indirection, i see no point in having a > MethodReference per se, > because you can always do the same thing by yourself , i.e. (Smalltalk > at: #SomeClass) methodDict at: #someSelector. yes > Without that, i see no point why i would want to use it, because it > always points to same thing, no matter where i using the > MethodReference. I imagine that we will have to clean that. It costs me a couple of hours looking for the wrong bug when copying classes..... grgrgrgrg Stef

Oct. 31, 2009

[Pharo-project] Pharo analog to Dolphin's "immediate objects"?

by Schwab,Wilhelm K

Hello all, Dolphin stores small integers and characters entirely in the header, and describes them as having "immediate" storage. Is there a similar concept in Pharo? I _think_ I can get around it by looking at other tests such as #isBytes, but I am still trying to decide whether they are simply named the same way or actually do the same thing. Bill

Oct. 31, 2009

Re: [Pharo-project] Hashed collection improvements: Some code

by StÃ©phane Ducasse

>> > > Smalltalk apart, I wish you a healthy future. Me too. The news are good apparently my problems was a false positive of the investigation tools. I should say that I like false positives now. Still it makes me think about life and stress during this period :) Stef

Oct. 31, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by StÃ©phane Ducasse

what would be good is to have a small discussion on the key and minimal features that could be added to Announcements, add some tests and code. Stef On Oct 31, 2009, at 5:17 PM, StÃ©phane Ducasse wrote: > Levente > > what I would really love :) > is if you could provide some extensions to the new version based on > your experience. > I think that Announcements are a bit limited right now. Then the core > would be enhanced and we > could clarified the license. > > Stef > > On Oct 30, 2009, at 1:25 AM, Levente Uzonyi wrote: > >> Hi! >> >> Just to make things clear, AXAnnouncements >> - is not "a port of the original announcement implementation" >> - is (more or less) based on Vassili Bykov's blog >> (http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Ann… >> ) >> just like the Announcements package in Pharo >> - is released under the MIT license (http://www.squeaksource.com/AXAnnouncements.html >> ). >> We implemented the framework as the blog entries came out and >> integrated >> it into our rudimentary ajax framework (that's where the AX prefix >> came >> from). Later we abandoned the ajax framework but found announcements >> really useful (especially with seaside components), so we extracted >> the >> code and moved it to squeaksource. Our ajax framework demo was >> available >> at http://axdemo.seasidehosting.st/. >> >> For a quick comparison: AXAnnouncements is bloated and has lower code >> quality than Announcements, but it implements more features, like >> suspension and interception of announcements, weak subscriptions and >> allows different base class for the announcements hierarchy per >> announcer. >> >> Cheers, >> Levente >> >> _______________________________________________ >> 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. 31, 2009

Re: [Pharo-project] method metaclass disappeared in RBAbstractClass and RBMetaclass

by StÃ©phane Ducasse

lukas could you deprecate the methods so that users get the time to update. Stef On Oct 30, 2009, at 4:17 PM, Lukas Renggli wrote: > I renamed the methods #metaclass and #nonMetaclass, because these > selectors are not polymorphic with what is standard in the Pharo class > hierarchy where #theMetaclass and #theNonMetaclass are used. > > Looks like O2-Refactory and other external users needs to be updated. > > I changed all senders OB-Refactory. > > Lukas > > 2009/10/30 FranÃ§ois Tanguy <francois.tanguy(a)gmail.com>: >> Hello, >> >> in pharo1.0-10492-rc1dev09.11.1, the method metaclass in >> RBAbstractClass and RBMetaclass is not there... >> Is that normal ? >> >> FranÃ§ois >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > 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

Oct. 31, 2009

Re: [Pharo-project] About AXAnnouncements (was: some Announcements related questions)

by StÃ©phane Ducasse

Levente what I would really love :) is if you could provide some extensions to the new version based on your experience. I think that Announcements are a bit limited right now. Then the core would be enhanced and we could clarified the license. Stef On Oct 30, 2009, at 1:25 AM, Levente Uzonyi wrote: > Hi! > > Just to make things clear, AXAnnouncements > - is not "a port of the original announcement implementation" > - is (more or less) based on Vassili Bykov's blog > (http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?searchCategory=Ann… > ) > just like the Announcements package in Pharo > - is released under the MIT license (http://www.squeaksource.com/AXAnnouncements.html > ). > We implemented the framework as the blog entries came out and > integrated > it into our rudimentary ajax framework (that's where the AX prefix > came > from). Later we abandoned the ajax framework but found announcements > really useful (especially with seaside components), so we extracted > the > code and moved it to squeaksource. Our ajax framework demo was > available > at http://axdemo.seasidehosting.st/. > > For a quick comparison: AXAnnouncements is bloated and has lower code > quality than Announcements, but it implements more features, like > suspension and interception of announcements, weak subscriptions and > allows different base class for the announcements hierarchy per > announcer. > > Cheers, > Levente > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 31, 2009

Re: [Pharo-project] some Announcements related questions

by StÃ©phane Ducasse

After lukas we can also read the blog and get some ideas for possible extensions. After all this is an object way to look at dependencies :) Stef On Oct 29, 2009, at 8:49 PM, Lukas Renggli wrote: > This concern was already raised elsewhere, but AXAnnoucnements is a > port of the original announcement implementation and likely a > copyright violation of the owners. The announcements in Pharo are a > minimal clean room MIT implementation coming from OmniBrowser. > > Cheers, > Lukas > > 2009/10/29 Igor Stasenko <siguctua(a)gmail.com>: >> 2009/10/29 CÃ©drick BÃ©ler <cdrick65(a)gmail.com>: >>> Hi Igor, >>> I'm not sure but I think the annoucment version that will be >>> included is >>> there : http://source.lukas-renggli.ch/announcements >>> Cheers, >>> >> And packages in that repository is already present in pharo-core >> image. >> But if you look at AXAnnouncements, you can see the difference - >> there are classes for subscriptions and >> registry, apart from the 'AX' naming prefix. >> >>> 2009/10/29 Igor Stasenko <siguctua(a)gmail.com> >>>> >>>> Hello, i loaded the >>>> Announcements package from SqS/AXAnnouncements, >>>> >>>> there are some tests failing because they explicitly comparing >>>> block >>>> closures class to be a BlockContext. >>>> But since new closure compiler, it should be BlockClosure instead. >>>> What is a proper test you think? >>>> isClosure or isBlock? >>>> >>>> And next question, that Pharo-core having a classes in >>>> Announcements-Core category, >>>> and comparing to AXAnnouncements there just very basic stuff and >>>> its >>>> quite useless. >>>> As i remember pharo is going to adopt announcements in base >>>> image, so >>>> the question, is AXAnnouncements is right >>>> thing to load, or there something made specifically for Pharo, >>>> but not >>>> loaded in core image? >>>> >>>> -- >>>> 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 >>> >>> >>> >>> -- >>> CÃ©drick >>> >>> _______________________________________________ >>> 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 > > > > -- > 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

Oct. 31, 2009