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

Re: [Pharo-project] issue 496: Morph>>heading

by Laval Jannik

Yes, Marcus is right. But are there some behaviors that we want to keep and integrate in Core ? For example, the Rotate functionality in the halo. Cheers, Jannik On Oct 26, 2009, at 16:22 , Marcus Denker wrote: > >> >>> However, it would be a good idea to put all the interesting eToy >>> stuff in an external package so that those who want to load that >>> stuff, are able to do it. >> >> >> >> Because, make an external package of it needs a big work... >> >> I don't think so. > > Etoy is more complex than you think. It would be (nearly) impossible. > > >> You just need to create the package. And then, instead of removing >> code, you move it to that package. What can be a lot of work is to >> keep that package up to date and working, but that's not Pharo >> responsibility. >> > Nope. Etoy is programed in a way that makes things like this *a lot* > of work. > > > Marcus > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 26, 2009

Re: [Pharo-project] Traits composition question

by Alexandre Bergel

Hi Igor, > Trait named: #TraitGroup > uses: TraitA + TraitB + .... TraitN > category: 'foo' > > and suppose i want to use TraitGroup in one of my classes, but > excluding one of the traits in the list above.. i.e. something like: > > Object subclass: #Myclass > uses: TraitGroup - TraitA > .. > > but the above code don't seem to work.. > Any clues, how i can do that? The exclusion is specified between a trait and a set of selectors, not between two traits. You need to write for example: > Object subclass: #Myclass > uses: TraitGroup - {#m1 . #m2} If #m1 and #m2 are two methods of TraitA (i.e., defined on or acquired by TraitA). Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 26, 2009

Re: [Pharo-project] issue 496: Morph>>heading

by Marcus Denker

> >> However, it would be a good idea to put all the interesting eToy >> stuff in an external package so that those who want to load that >> stuff, are able to do it. > > > > Because, make an external package of it needs a big work... > > I don't think so. Etoy is more complex than you think. It would be (nearly) impossible. > You just need to create the package. And then, instead of removing > code, you move it to that package. What can be a lot of work is to > keep that package up to date and working, but that's not Pharo > responsibility. > Nope. Etoy is programed in a way that makes things like this *a lot* of work. Marcus

Oct. 26, 2009

Re: [Pharo-project] issue 496: Morph>>heading

by Mariano Martinez Peck

2009/10/26 Laval Jannik <jannik.laval(a)gmail.com> > > On Oct 26, 2009, at 15:21 , Mariano Martinez Peck wrote: > > > > On Mon, Oct 26, 2009 at 11:13 AM, Laval Jannik <jannik.laval(a)inria.fr>wrote: > >> Hi, >> >> I bring out a past message. >> And my question is more general. >> >> What do we want to keep from etoy ? >> > > I would said NOTHING in the core or even Pharo image. > > > I agree with you. > > However, it would be a good idea to put all the interesting eToy stuff in > an external package so that those who want to load that stuff, are able to > do it. > > > Is eToy maintained in Pharo ? > I don't know. Neither I care. I mean, why to put something specific in a generic language/enviroment ??? I see eToy as any other application. For example, my own (SqueakDBX), or magma, or XXX package. Why to put those specific packages in the core image? If you want, you load them. It is easy. And if they are maintained or not, it doesn't depends on Pharo developers, but in the external package developers. I decide if SqueakDBX works on Pharo or not, not Pharo developers. > Because, make an external package of it needs a big work... > I don't think so. You just need to create the package. And then, instead of removing code, you move it to that package. What can be a lot of work is to keep that package up to date and working, but that's not Pharo responsibility. > > So, do we want a different package ? or maybe something which come from the > etoy community, something up to date. > > Maybe the eToy community can even touch that external package. what do you think ? > Cheers, > Jannik > > > > >> >> Cheers, >> Jannik >> >> On Oct 22, 2009, at 09:33 , Laval Jannik wrote: >> >> > Hi, >> > >> > Morph>>heading is from eToy. >> > It is used to rotate a Morph. >> > If we remove it, we remove the possibility to rotate a morph. >> > >> > What are your positions about this behavior ? >> > Do we considere it as a system behavior or as an eToy thing which >> > must be removed ? >> > >> > Cheers, >> > >> > --- >> > Jannik Laval >> >> >> _______________________________________________ >> 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 > > > --- > Jannik Laval > PhD Student - Rmod Team - INRIA > Certified Project Management Associate (IPMA) > http://www.jannik-laval.eu > http://rmod.lille.inria.fr > --- > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 26, 2009

Re: [Pharo-project] issue 496: Morph>>heading

by Laval Jannik

On Oct 26, 2009, at 15:21 , Mariano Martinez Peck wrote: > > > On Mon, Oct 26, 2009 at 11:13 AM, Laval Jannik > <jannik.laval(a)inria.fr> wrote: > Hi, > > I bring out a past message. > And my question is more general. > > What do we want to keep from etoy ? > > I would said NOTHING in the core or even Pharo image. I agree with you. > However, it would be a good idea to put all the interesting eToy > stuff in an external package so that those who want to load that > stuff, are able to do it. Is eToy maintained in Pharo ? Because, make an external package of it needs a big work... So, do we want a different package ? or maybe something which come from the etoy community, something up to date. Cheers, Jannik > > > > Cheers, > Jannik > > On Oct 22, 2009, at 09:33 , Laval Jannik wrote: > > > Hi, > > > > Morph>>heading is from eToy. > > It is used to rotate a Morph. > > If we remove it, we remove the possibility to rotate a morph. > > > > What are your positions about this behavior ? > > Do we considere it as a system behavior or as an eToy thing which > > must be removed ? > > > > Cheers, > > > > --- > > Jannik Laval > > > _______________________________________________ > 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 --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

Oct. 26, 2009

Re: [Pharo-project] (a = b) => (a hash = b hash)

by Nicolas Cellier

2009/10/26 Andrew P. Black <black(a)cs.pdx.edu>: > I agree with Nicolas, but I think that it's really important that we have > this discussion, reach a consensus, and them implement it! > That's why I posted the message here rather than just posting a bug report. > There used to be a method called hasSameElementsAs: (now called, > inexplicably, sameElements:) that could be pressed into service so that two > intervals, or an array and and interval, can have the same elements but > still be unequal. Â But the role of species was to define when things could > be equal... > Maybe we need a method "hasSameSequenceOfElementsAs:" which would be > applicable to any pair of Â sequenceable collections, as well as being faster > to implement, than sameElements: (which is currently quadratic). > This is exactly SequenceableCollection>>#hasEqualElements: I have no #sameElements: in core. Nicolas > On 25 Oct 2009, at 06:53, Nicolas Cellier wrote: > > IMO, we should not let Array hash ~= Interval hash coexist with Array = > Interval > Because it's like putting some traps on programmers path. > One day or the other an application will exhibit a non repeatable > error, just because the size of a Set was different and caused a > collision. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 26, 2009

Re: [Pharo-project] issue 496: Morph>>heading

by Mariano Martinez Peck

On Mon, Oct 26, 2009 at 11:13 AM, Laval Jannik <jannik.laval(a)inria.fr>wrote: > Hi, > > I bring out a past message. > And my question is more general. > > What do we want to keep from etoy ? > I would said NOTHING in the core or even Pharo image. However, it would be a good idea to put all the interesting eToy stuff in an external package so that those who want to load that stuff, are able to do it. > > Cheers, > Jannik > > On Oct 22, 2009, at 09:33 , Laval Jannik wrote: > > > Hi, > > > > Morph>>heading is from eToy. > > It is used to rotate a Morph. > > If we remove it, we remove the possibility to rotate a morph. > > > > What are your positions about this behavior ? > > Do we considere it as a system behavior or as an eToy thing which > > must be removed ? > > > > Cheers, > > > > --- > > Jannik Laval > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 26, 2009

Re: [Pharo-project] issue 496: Morph>>heading

by Laval Jannik

Hi, I bring out a past message. And my question is more general. What do we want to keep from etoy ? Cheers, Jannik On Oct 22, 2009, at 09:33 , Laval Jannik wrote: > Hi, > > Morph>>heading is from eToy. > It is used to rotate a Morph. > If we remove it, we remove the possibility to rotate a morph. > > What are your positions about this behavior ? > Do we considere it as a system behavior or as an eToy thing which > must be removed ? > > Cheers, > > --- > Jannik Laval

Oct. 26, 2009

Re: [Pharo-project] question about results of MessageTally

by Laval Jannik

Thanks Henry. I push in pharoInbox a new method. MessageTally>>spyOn:cutoff: which allows us to specify an appropriate filter. I will see the TimeProfileBrowser. Cheers, Jannik On Oct 26, 2009, at 00:26 , Henrik Sperre Johansen wrote: > Personally, I always change to 0.1 in spyOn: (my experience in VW > was that doing 0.0 makes the tree building take a long time). > You'd probably also want to try out > TimeProfileBrowser onBlock: > instead of MessageTally spyOn:, > while not a huge improvement, it's nice to have the method source > accessible directly. > I had a dream of making a new one, with a proper treeview of the > tally (and a button for auto-expand to certain %, no need to worry > if you'd set the cutoff correctly before starting the tally), color- > coding of the hotspots in the method view, and store/compare of > tallies, but never seem to get around to it. > Well, I did start once, but my head started hurting too soon from > the total lack of separation between result production/storage/ > presentation responsibilities in MT. > > Cheers, > Henry > > > On 25.10.2009 21:00, Laval Jannik wrote: >> >> yes, with 0 it works. >> >> But, in some cases, we would like to have all branches. >> So, I will do the method spyOn:cutoff:, and keep the 1% threshold for >> spyOn:. >> >> Cheers, >> Jannik >> >> >> On Oct 25, 2009, at 20:54 , Adrian Lienhard wrote: >> >> >>> Have you tried with 0? I guess you get way too much in the tree >>> (especially when you trace a larger part of your application and not >>> only adding elements to a dictionary). It seems that 1% is a >>> sensible >>> default as usually it does not make sense to look into these >>> branches >>> more closely as you cannot optimize them much. >>> >>> Adrian >>> >>> On Oct 25, 2009, at 19:42 , Laval Jannik wrote: >>> >>> >>>> Hi Adrian, >>>> >>>> Now I understand the "problem". >>>> So we can use "report:cutoff:" which allows us to give a specific >>>> value for the threshold. >>>> >>>> I will create a new method, spyOn:cutoff:. >>>> >>>> I think the method "spyOn:" must have the threshold equals to 0. >>>> No ? >>>> >>>> Cheers, >>>> Jannik >>>> >>>> >>>> On Oct 24, 2009, at 12:08 , Adrian Lienhard wrote: >>>> >>>> >>>>> Hi Jannik, >>>>> >>>>> Interesting question! >>>>> >>>>> You left out an important part oft the tally: the part about GC >>>>> activity. >>>>> >>>>> For the large dictionary I get: >>>>> >>>>> **GCs** >>>>> full 9 totalling 1,696ms (1.0% uptime), avg 188.0ms >>>>> incr 3776 totalling 186,310ms (94.0% uptime), avg 49.0ms >>>>> >>>>> That is, 95% of time is spent in GC! A lot of incremental GC >>>>> cycles >>>>> are triggered because for each at:put: a new association >>>>> instance is >>>>> created. The larger the dictionary, the larger is the new memory >>>>> space >>>>> and hence the incremental GC takes longer to complete. In the >>>>> above >>>>> tally the average was 49ms compared to >>>>> >>>>> incr 275 totalling 1,113ms (58.0% uptime), avg 4.0ms >>>>> >>>>> for the smaller dictionary. Therefore, the ratio between actual >>>>> method >>>>> execution time and GC time differs significantly between the two >>>>> runs. >>>>> As a result, a lot of branches of the tally are below a total of >>>>> 1% >>>>> runtime in the second case. Message tally has a threshold that >>>>> cuts >>>>> off branches with less than 1% runtime. Therefore you see less >>>>> details. >>>>> >>>>> Cheers, >>>>> Adrian >>>>> >>>>> >>>>> On Oct 24, 2009, at 07:21 , Laval Jannik wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> when I use MassageTally>>spyOn: on the creation of a Dictionary, >>>>>> results have not the same details according to the size of >>>>>> Dictionary. >>>>>> >>>>>> For example: >>>>>> === >>>>>> |n| >>>>>> MessageTally spyOn:[ >>>>>> n := Dictionary new. >>>>>> 1 to: 400000 do:[:each | n at: each put:each]. >>>>>> ] >>>>>> === >>>>>> >>>>>> returns this results: >>>>>> >>>>>> ==== >>>>>> - 1745 tallies, 1751 msec. >>>>>> >>>>>> **Tree** >>>>>> -------------------------------- >>>>>> Process: (40s) 1964: nil >>>>>> -------------------------------- >>>>>> 45.8% {802ms} Dictionary(Set)>>atNewIndex:put: >>>>>> |43.6% {763ms} Dictionary(Set)>>fullCheck >>>>>> | |39.4% {690ms} Dictionary(Set)>>grow >>>>>> | | |27.2% {476ms} Dictionary>>noCheckAdd: >>>>>> | | | |25.2% {441ms} Dictionary(Set)>>findElementOrNil: >>>>>> | | | | |23.6% {413ms} Dictionary>>scanFor: >>>>>> | | | | |1.6% {28ms} primitives >>>>>> | | | |2.0% {35ms} primitives >>>>>> | | |9.2% {161ms} primitives >>>>>> | | |3.0% {53ms} Array(SequenceableCollection)>>do: >>>>>> | |2.4% {42ms} primitives >>>>>> | |1.8% {32ms} SmallInteger(Magnitude)>>max: >>>>>> |2.2% {39ms} primitives >>>>>> 22.4% {392ms} Association class>>key:value: >>>>>> |18.9% {331ms} Association class(LookupKey class)>>key: >>>>>> | |16.3% {285ms} Association(LookupKey)>>key: >>>>>> | |2.6% {46ms} primitives >>>>>> |1.9% {33ms} Association>>value: >>>>>> |1.6% {28ms} primitives >>>>>> 4.4% {77ms} Dictionary(Set)>>findElementOrNil: >>>>>> |2.3% {40ms} primitives >>>>>> |2.1% {37ms} Dictionary>>scanFor: >>>>>> 1.9% {33ms} primitives >>>>>> ==== >>>>>> >>>>>> But, if I do: >>>>>> === >>>>>> |n| >>>>>> MessageTally spyOn:[ >>>>>> n := Dictionary new. >>>>>> 1 to: 4000000 do:[:each | n at: each put:each]. >>>>>> ] >>>>>> === >>>>>> >>>>>> results are: >>>>>> ==== >>>>>> - 179772 tallies, 180312 msec. >>>>>> >>>>>> **Tree** >>>>>> -------------------------------- >>>>>> Process: (40s) 1964: nil >>>>>> -------------------------------- >>>>>> 3.1% {5590ms} Dictionary(Set)>>atNewIndex:put: >>>>>> |2.8% {5049ms} Dictionary(Set)>>fullCheck >>>>>> | 2.3% {4147ms} Dictionary(Set)>>grow >>>>>> | 1.3% {2344ms} Dictionary>>noCheckAdd: >>>>>> 1.0% {1803ms} Association class>>key:value: >>>>>> ==== >>>>>> >>>>>> Where are the rest of the process ? >>>>>> Does anybody understand this behavior ? can you explain ? >>>>>> >>>>>> >>>>>> Cheers, >>>>>> Jannik >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> --- >>>> Jannik Laval >>>> PhD Student - Rmod Team - INRIA >>>> Certified Project Management Associate (IPMA) >>>> http://www.jannik-laval.eu >>>> http://rmod.lille.inria.fr >>>> --- >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> --- >> Jannik Laval >> PhD Student - Rmod Team - INRIA >> Certified Project Management Associate (IPMA) >> http://www.jannik-laval.eu >> http://rmod.lille.inria.fr >> --- >> >> >> _______________________________________________ >> 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 --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

Oct. 26, 2009

Re: [Pharo-project] Dynamic Traits

by Damien Cassou

2009/10/26 John Toohey <jt(a)parspro.com>: > Is is possible to apply a Trait to an object after it has been created? I > have a situation where I have a collection of object that have been > populated from a database, and depending on a typeId property, I would like > to apply different Traits to that object. Each Trait would have the same > method signatures, but the calculations performs by those methods would be > different in each case. It's not possible. A design pattern might better suit your needs. Have a look at State or Strategy. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Oct. 26, 2009