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

Re: [Pharo-project] HashTable vs Dictionary

by StÃ©phane Ducasse

Andres so that I understand clearly Dictionary is chaining or open? I do not remember and too busy to check. Stef On Oct 21, 2009, at 3:05 AM, Andres Valloud wrote: > In general terms, open addressing with linear probing should tie or > beat > chaining. For this to happen, the hash function used must be of high > quality. If chaining is beating open addressing with linear probing, > I'd strongly suspect that the hash function used is producing > significant collisions or unevenly distributed values for the data set > in question. You may want to take a look at the Hash Analysis Tool I > wrote for VW (it's in the public Store repository under a MIT > license). > For a more in-depth treatment of these matters, you may also want to > look at the hash book I wrote (www.lulu.com/avSmalltalkBooks) and its > matching Smalltalk Solutions 2008 presentation > (http://video.google.com/videoplay?docid=-7510297003494499688&hl=en#) > > Andres. > > > Lukas Renggli wrote: >> 2009/10/20 Laval Jannik <jannik.laval(a)gmail.com>: >> >>> Hi, >>> Since some weeks, >>> We use in our projects the project HashTable, available >>> at http://www.squeaksource.com/ht.html >>> It could be a good idea to integrate these collections to replace >>> Dictionary >>> and Set. >>> >> >> I don't think that this is generally a good idea. It might be >> beneficial in your situation, but certainly not for everybody in all >> situations. I've been using the HashTable implementation in several >> projects with great success. In other projects I've been using the >> BTree package on SqueakSource that provides similar functionality >> optimized for yet another context. These highly specialized data >> structures should only be applied if they make sense in the given >> context (and if you understand both, the cost and gain). I guess this >> was exactly the reason why SkipList was removed from the Pharo image. >> >> Lukas >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 21, 2009

Re: [Pharo-project] HashTable vs Dictionary

by StÃ©phane Ducasse

Yes but what jannik wants to say is that having slow dictionary in the image and fast outside is not really a good strategy. Stef On Oct 20, 2009, at 11:37 PM, Lukas Renggli wrote: > 2009/10/20 Laval Jannik <jannik.laval(a)gmail.com>: >> Hi, >> Since some weeks, >> We use in our projects the project HashTable, available >> at http://www.squeaksource.com/ht.html >> It could be a good idea to integrate these collections to replace >> Dictionary >> and Set. > > I don't think that this is generally a good idea. It might be > beneficial in your situation, but certainly not for everybody in all > situations. I've been using the HashTable implementation in several > projects with great success. In other projects I've been using the > BTree package on SqueakSource that provides similar functionality > optimized for yet another context. These highly specialized data > structures should only be applied if they make sense in the given > context (and if you understand both, the cost and gain). I guess this > was exactly the reason why SkipList was removed from the Pharo image. > > 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

Oct. 21, 2009

Re: [Pharo-project] Class and Metaclass explanation in PBE

by StÃ©phane Ducasse

Yeap BTW to get started with your new life :) I suggest you to implement objvlisp http://stephane.ducasse.free.fr/Teaching/Lille/0910-MetaModelisation/ObjVli… http://stephane.ducasse.free.fr/Teaching/Lille/0910-MetaModelisation/ObjVli… this way we are sure we are all in sync :) Stef On Oct 21, 2009, at 3:36 AM, Mariano Martinez Peck wrote: > > > On Tue, Oct 20, 2009 at 10:23 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > 2009/10/21 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi folks. I was reading chapter 13 of PBE and there is something I > don't > > understand. > > > > In page 283 it says: > > > > "Every metaclass is-a class, hence inherits from Class. Class in > turn > > inherits from its superclasses, ClassDescription and Behavior." > > > > page 278, rule 8, it says: > > > > "Every metaclass inherits from Class and Behavior." > > > > > > However, if I open a class browser, I see that Metaclass inherits > from > > ClassDescription, not Class. So, I don't understand :( > > > > Can anyone clarify me this? > > > > The topmost superclass of Metaclass is a ProtoObject class (as for any > other class). > You can see it yourself: > Metaclass superclass superclass superclass superclass > > now if you take a look, what is the class of the above object, > you'll see: > > (Metaclass superclass superclass superclass superclass) class > -> ProtoObject class > > and now: > > (ProtoObject class) superclass => Class > > > Thanks Igor. This was the part I was missing :) > > > so, lets roll things back.. > > ProtoObject class superclass => Class > > means that ProtoObject object is an instance of class, which inherits > from Class. > Or, since ProtoObject is class itself, then the 'ProtoObject class' > expression should return a metaclass, then you can see that > a most basic metaclass inherits from Class. > > and hence: "Every metaclass inherits from Class and Behavior." > > > Thanks > > > > Mariano > > > > > > _______________________________________________ > > 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

Oct. 21, 2009

Re: [Pharo-project] MC 1.6 status?

by StÃ©phane Ducasse

I would love to have that. I started to migrate some 1.5 code (fast loading) from MC15 to pharo MC15 but nobody have a look at the slice I published Stef > Hello people, > > i'd like to see some answers about the fate of MC 1.6. and its current > situation. > > 1. I think everyone wants to have an atomic loading. > But according to my knowledge, MC 1.6. has some problems with Traits, > which prevets us from using it & fully replace the older version. > > 2. Besides of that, are there any other reasons to not have it? > > So, please, can we disscuss (friendly & constructive), what we might > need to have it integrated in Squeak and in Pharo, so > we could benefit from having an atomic loading? > > > > -- > 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

Oct. 21, 2009

Re: [Pharo-project] scriptloader>>loadComanche

by StÃ©phane Ducasse

> I like the idea that a build-server determines that automatically even > better. :) yes we could really have a metacello database package and the buildserver can validate the entries :) Stef

Oct. 21, 2009

Re: [Pharo-project] Question about PBE book by newbie, instance variables

by Oscar Nierstrasz

Yes. They key difference is that the abstraction boundary is the object, not the class. In Java, another instance of the same class can access your "private" instance variables. In Smalltalk, it cannot (unless reflection is used). - on On Oct 21, 2009, at 14:59, Gerben van de Wiel wrote: > Thank you very much, if i understand it correctly then instance vars > in SmallTalk are "kind of" protected members in languages like Java > and C#? > > Regards, > Gerben > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 21, 2009

Re: [Pharo-project] Question about PBE book by newbie, instance variables

by Gerben van de Wiel

Thank you very much, if i understand it correctly then instance vars in SmallTalk are "kind of" protected members in languages like Java and C#? Regards, Gerben

Oct. 21, 2009

Re: [Pharo-project] Question about PBE book by newbie, instance variables

by Gabriel Cotelli

As Oscar said, it's an style question. I prefer to reference directly the instance variable in this context and don't expose private state, and also prefer to put the instance variables definition in the concrete classes and not in the abstract ones. Regards, Gabriel On Wed, Oct 21, 2009 at 6:45 AM, Gerben van de Wiel <gerben.fds(a)gmail.com>wrote: > Hi, > > I am very new to Pharo and Smalltalk in general. When reading through > the excellent PBE book i was wondering about something on page 32. > In that piece of code the LOCell class is using some instance > variables from it's super classes, and i was wondering if it isn't > best practice to use > message to self using the accessing methods so instead of. > > bounds := 0@0 corner: 16@16. using self bounds: (0@0 corner: 16@16). > > or is good to use both or is there something i don't know (maybe it is > faster to use instance vars then sending a new message and traverse > the inheritance tree). > > regards, > > Gerben van de Wiel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 21, 2009

Re: [Pharo-project] Question about PBE book by newbie, instance variables

by Oscar Nierstrasz

Hi Gerben, It is really a question of style. Some people promote the use of accessors aggressively for all instance variable access. The down sides are (i) proliferation of accessor methods, and (ii) exposure of private state to other objects. If you do decide to use accessors, you should be sure to put them in a protocol called "private" to make clear that they are only intended for use by the object itself. I am curious what other people tend to do -- do you use accessors for inherited ivars, or access them directly? - on On 21 Oct 2009, at 11:45, Gerben van de Wiel wrote: > Hi, > > I am very new to Pharo and Smalltalk in general. When reading through > the excellent PBE book i was wondering about something on page 32. > In that piece of code the LOCell class is using some instance > variables from it's super classes, and i was wondering if it isn't > best practice to use > message to self using the accessing methods so instead of. > > bounds := 0@0 corner: 16@16. using self bounds: (0@0 corner: 16@16). > > or is good to use both or is there something i don't know (maybe it is > faster to use instance vars then sending a new message and traverse > the inheritance tree). > > regards, > > Gerben van de Wiel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 21, 2009

Re: [Pharo-project] Question about deepCopy,

by arnaud Jean Baptiste

Hi, at the beginning, it is a simply question, not a suggest of features. And have a answer to my question, why we keep that, for performance? In this case when perform a #deepCopy how ensure, in the system we don't have cycle between self and instance var (recursively)? the behavior of #deepCopy is it really relevant (not the name) ? Then, I don't suggest to rename #deepCopy, i suggest to replace the behavior of #deepCopy by #veryDeepCopy behavior. Finally i just want to understand the reason, why we keep that? If we keep, it certainly for good reason, which? I just want to have a better understanding of the system. PS: I ask this question because i search about issue 521. And #deepCopy create infinite loop because there are a cycle. On Oct 21, 2009, at 1:26 AM, Schwab,Wilhelm K wrote: > I'm going to briefly be a wise-guy to a (well intentioned) purpose. > You appear to be suggesting that we call #deepCopy something else, > and then fix it. > > One might drag the fix into #deepCopy?? But years ago now, > #deepCopy fell from grace, perhaps for good reason. What I recall > seeing in its place was #postCopy that can be overriden to ensure a > distinct copy; that seemed to be in contrast to #shallowCopy. > > This deserves some attention to ensure that we do the correct thing. > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- > project-bounces(a)lists.gforge.inria.fr] On Behalf Of arnaud Jean > Baptiste > Sent: Tuesday, October 20, 2009 10:07 AM > To: Pharo Development > Subject: [Pharo-project] Question about deepCopy, > > > question: > > deepCopy have this behavior : > - copy self. > - then send deepCopy on all instance var. > > this behavior, make infinite loop when a object have instance > variable which reference to himself or more longer cycle. > > Why don't replace deepCopy by veryDeepCopy, same behavior but copy > each object only once (create collection and keep reference). > performance issue ? > > > > > > _______________________________________________ > 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. 21, 2009