May 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by csrabak＠bol.com.br

Em 26/05/2010 07:07, Henrik Johansen < henrik.s.johansen(a)veloxit.no > escreveu: > On May 26, 2010, at 11:58 51AM, StÃ©phane Ducasse wrote: > > > hi richard > > > >> WTF?! > > If you have a real argument we are really open to discussion. > > > >> These are the only reasons? I think that they are sufficient > +1 > > Because we could have and:or: or:and: and:and:or: and a couple of > others in that case. > No we could not :) Because of ambiguity: a and: (b or: c) is not > the same as (a and: b) or: c Henry, I disagree. Since to implement this in Smalltalk you'll need a specific method the ambiguity can be removed by specifying the API and using the appropriate implementation: Boolean>> and: x or: y ^(self and: x) or: y

May 26, 2010

Re: [Pharo-project] Gettext package in PharoNonCorePackages

by Mariano Martinez Peck

Thanks Hilaire. Do you think this should be added to PharoDev? Because most of PharoNonCorePackages do. Cheers Mariano On Wed, May 26, 2010 at 9:11 PM, Hilaire Fernandes < hilaire.fernandes(a)gmail.com> wrote: > I move the gettext package there, as it is the right place for long term > support for this package. > > Please, from now, commit any change there. > > http://www.squeaksource.com/PharoNonCorePackages > > Hilaire > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 26, 2010

Re: [Pharo-project] About CodeMorph and Styler dependency

by StÃ©phane Ducasse

which one I could not find it? On May 25, 2010, at 2:22 PM, Fernando olivero wrote: > Oh! my mistake, sorry. > i will add the bug entry now. > > Fernando > > > On May 25, 2010, at 2:11 PM, StÃ©phane Ducasse wrote: > >> ok I forgot it. :( Please add a bug entry else we forgot. >> >> Stef >> >> On May 25, 2010, at 9:01 AM, Fernando olivero wrote: >> >>> Hi Stef, regarding some recent mails about CodeMorph and Shout dependency i don't know if you got this email. >>> But i've removed the dependency from Shout and Styler. >>> >>> I'm still thinking about using Lukas petit parser to do the styling, or separating the Shout package in two different packages. >>> One that deals with TextMorph and the other just for Styling text. >>> >>> Fernando >>> >>> >>> Begin forwarded message: >>> >>>> From: Fernando olivero <oliverof(a)lu.unisi.ch> >>>> Date: May 17, 2010 5:51:30 PM GMT+02:00 >>>> To: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)lists.gforge.inria.fr> >>>> Subject: Re: [Pharo-project] TextEditor and NewTextMorph merges and fixes >>>> >>>> De nada ! >>>> >>>> Actually i just published another version of the CodeMorph. >>>> I found no need for subclassing CodeMorph, since the accepting behavior is on the announcements now, having specific ClassDescriptionMorph and MethodMorph wouldn't be beneficial. >>>> Also removed the dependency with the Shout ( and the styler). >>>> >>>> >>>> Name: Morphic-FernandoOlivero.589 >>>> Rethought the CodeMorph class hierarchy, removed the subclasses and added CodeMorph class methods for creating >>>> "MethodMorph" and "ClassDefinitionMorph" >>>> >>>> >>>> Fernando >>>> >>>> On May 17, 2010, at 3:35 PM, StÃ©phane Ducasse wrote: >>>> >>>>> Tx!!!! >>>>> Gaucho man >>>>> >>>>> On May 17, 2010, at 3:32 PM, Fernando olivero wrote: >>>>> >>>>>> Issue: 2375 >>>>>> >>>>>> Name: System-Text-FernandoOlivero.8 >>>>>> Author: FernandoOlivero >>>>>> Time: 17 May 2010, 3:22:14 pm >>>>>> >>>>>> >>>>>> >>>>>> ###################################### >>>>>> Issue: -- >>>>>> >>>>>> Name: Morphic-FernandoOlivero.588 >>>>>> Author: FernandoOlivero >>>>>> Time: 17 May 2010, 1:42:04 pm >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Mariano Abel Coca

They do not behave different. The problem is that you cannot assume that by just looking at the message send. They could behave different, they do not, but you don't know that until you look at the method implementation. You cannot assume that #and:and:and: will or wont evaluate the second block and then compare the results. In fact, it's almost suggested in the declaration that it will by hierarchically organizing the blocks in the same logical level. And that is a lack of expressiveness. For that, is preferred the second option. Besides, #and:and:and: implementation is horrible :) Cheers, Mariano. On Wed, May 26, 2010 at 4:18 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Wed, 26 May 2010, Igor Stasenko wrote: > > On 26 May 2010 20:47, Levente Uzonyi <leves(a)elte.hu> wrote: >> >>> On Wed, 26 May 2010, Lukas Renggli wrote: >>> >>> - The exact semantics of #and:and:and: is not clear without knowing >>>>>> how it is implemented. >>>>>> >>>>>> - There are subtle semantic differences between "a and: [ b ] and: [ c >>>>>> ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the >>>>>> conditions have side-effects. >>>>>> >>>>> >>>>> That's not true. Both #and: and #and:and:and: (and friends) are >>>>> short-circuit, so they'll cause exactly the same side effects. >>>>> >>>> >>>> I know that and this is *not* what I am talking about. What you point >>>> out is already discussed above, it is absolutely unclear what >>>> #and:and:and: does without looking at the implementation. >>>> >>>> The point is that blocks that are lexically nested "a and: [ b and: [ >>>> c ] ]" and blocks that are in a lexical sequence "a and: [ b ] and: [ >>>> c ]" do not have the same expressive power (temps, state) and do not >>>> necessarily behave the same. >>>> >>> >>> Maybe i'm just narrow-minded, but I can't see the difference except for >>> the >>> scope of temporaries defined inside blocks. >>> >>> >> For pushing a closure on stack, an interpreter makes a copy of closure >> literal, from method's literal frame. >> For expressions like: >> a and: [ b ] and: [ c ] >> >> it should prepare and push 2 closures. >> >> and for expression like: >> >> a and: [ b and: [ c ] ] >> >> just one. >> So it is faster, for cases when outer block is not activated, because >> a is false. >> > > I understand this. And I know that the current compiler will inline the > blocks in the second case which gives the real difference in speed. > > What I don't understand is: how can these two expressions behave > differently. Can you provide a, b and c which will behave differently if > evaluated as: > 1) a and: [ b ] and: [ c ] > and > 2) a and: [ b and: [ c ] ] > ? > > > Levente > > > >> >>> Levente >>> >>> >>>> Lukas >>>> >>>> -- >>>> Lukas Renggli >>>> 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 >>>> >>>> >>> _______________________________________________ >>> 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 >

May 26, 2010

[Pharo-project] [update 1.1] #11373

by stephane ducasse

11373 ----- - Issue2317: FasterGrayPNGs. Thanks Squeak/Henrik - Issue 2468: Better method trailer method creation. Part two. Thanks Igor - Issue2242: FormConversionGeneralization. Henrik - Better ScriptLoader comment to explain our process. - Issue 1377: Senders of and implementers of does not work when symbol selected. Thanks Guile. - Issue 2074: Creating classes with Strings as the key in Smalltalk. Thanks marcus. - Issue 2480: prepare deprecation of and:and: + deprecated and:and:and:and: Stef

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Igor Stasenko

On 26 May 2010 22:18, Levente Uzonyi <leves(a)elte.hu> wrote: > On Wed, 26 May 2010, Igor Stasenko wrote: > >> On 26 May 2010 20:47, Levente Uzonyi <leves(a)elte.hu> wrote: >>> >>> On Wed, 26 May 2010, Lukas Renggli wrote: >>> >>>>>> - The exact semantics of #and:and:and: is not clear without knowing >>>>>> how it is implemented. >>>>>> >>>>>> - There are subtle semantic differences between "a and: [ b ] and: [ c >>>>>> ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the >>>>>> conditions have side-effects. >>>>> >>>>> That's not true. Both #and: and #and:and:and: (and friends) are >>>>> short-circuit, so they'll cause exactly the same side effects. >>>> >>>> I know that and this is *not* what I am talking about. What you point >>>> out is already discussed above, it is absolutely unclear what >>>> #and:and:and: does without looking at the implementation. >>>> >>>> The point is that blocks that are lexically nested "a and: [ b and: [ >>>> c ] ]" and blocks that are in a lexical sequence "a and: [ b ] and: [ >>>> c ]" do not have the same expressive power (temps, state) and do not >>>> necessarily behave the same. >>> >>> Maybe i'm just narrow-minded, but I can't see the difference except for >>> the >>> scope of temporaries defined inside blocks. >>> >> >> For pushing a closure on stack, an interpreter makes a copy of closure >> literal, from method's literal frame. >> For expressions like: >> a and: [ b ] and: [ c ] >> >> it should prepare and push 2 closures. >> >> and for expression like: >> >> a and: [ b and: [ c ] ] >> >> just one. >> So it is faster, for cases when outer block is not activated, because >> a is false. > > I understand this. And I know that the current compiler will inline the > blocks in the second case which gives the real difference in speed. > > What I don't understand is: how can these two expressions behave > differently. Can you provide a, b and c which will behave differently if > evaluated as: > 1) a and: [ b ] and: [ c ] > and > 2) a and: [ b and: [ c ] ] > ? > Trivial. I could implement own #and: method in my class. And there's no way how #and:and: could provide similar behavior. > > Levente > >> >>> >>> Levente >>> >>>> >>>> Lukas >>>> >>>> -- >>>> Lukas Renggli >>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 > -- Best regards, Igor Stasenko AKA sig.

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Levente Uzonyi

On Wed, 26 May 2010, Igor Stasenko wrote: > On 26 May 2010 20:47, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Wed, 26 May 2010, Lukas Renggli wrote: >> >>>>> - The exact semantics of #and:and:and: is not clear without knowing >>>>> how it is implemented. >>>>> >>>>> - There are subtle semantic differences between "a and: [ b ] and: [ c >>>>> ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the >>>>> conditions have side-effects. >>>> >>>> That's not true. Both #and: and #and:and:and: (and friends) are >>>> short-circuit, so they'll cause exactly the same side effects. >>> >>> I know that and this is *not* what I am talking about. What you point >>> out is already discussed above, it is absolutely unclear what >>> #and:and:and: does without looking at the implementation. >>> >>> The point is that blocks that are lexically nested "a and: [ b and: [ >>> c ] ]" and blocks that are in a lexical sequence "a and: [ b ] and: [ >>> c ]" do not have the same expressive power (temps, state) and do not >>> necessarily behave the same. >> >> Maybe i'm just narrow-minded, but I can't see the difference except for the >> scope of temporaries defined inside blocks. >> > > For pushing a closure on stack, an interpreter makes a copy of closure > literal, from method's literal frame. > For expressions like: > a and: [ b ] and: [ c ] > > it should prepare and push 2 closures. > > and for expression like: > > a and: [ b and: [ c ] ] > > just one. > So it is faster, for cases when outer block is not activated, because > a is false. I understand this. And I know that the current compiler will inline the blocks in the second case which gives the real difference in speed. What I don't understand is: how can these two expressions behave differently. Can you provide a, b and c which will behave differently if evaluated as: 1) a and: [ b ] and: [ c ] and 2) a and: [ b and: [ c ] ] ? Levente > >> >> Levente >> >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> 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 >>> >> >> _______________________________________________ >> 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 >

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Eliot Miranda

On Wed, May 26, 2010 at 11:41 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > but I was comparing with squeak :) > > I'm on 2.53 intel core 2 duo so may be the difference is that. > Indeed that's one difference. Only the ratios matter. Different machines have different performance at different times of the day. e.g. run another performance-intensive program while you're collecting results and you've just collected some useless results. > > Squeak 4.1.1beta2: #(1357 2129 1457) > Cog: #(141 844 568) > > (2.66 GHz Intel Core i7) > > > On May 26, 2010, at 7:30 PM, Dale Henrichs wrote: > > > StÃ©phane Ducasse wrote: > >> any idea why on pharo 1.1 > >> | b n | > >> b := [:aa :ab| ]. > >> n := 10000000. > >> { Time millisecondsToRun: [1 to: n do: [:i| b value: 0 value: 0]]. > >> Time millisecondsToRun: [1 to: n do: [:i| b valueWithArguments: {0. > 0}]]. > >> Time millisecondsToRun: [1 to: n do: [:i| b valueWithArguments: #(0 > 0)]] } #(1597 2606 1696) > > > > Presumably the Array constructor {...} is more costly than a literal > Array, which makese sense. > > > > Dale > > > > _______________________________________________ > > 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 >

May 26, 2010

[Pharo-project] Gettext package in PharoNonCorePackages

by Hilaire Fernandes

I move the gettext package there, as it is the right place for long term support for this package. Please, from now, commit any change there. http://www.squeaksource.com/PharoNonCorePackages Hilaire

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by StÃ©phane Ducasse

but I was comparing with squeak :) I'm on 2.53 intel core 2 duo so may be the difference is that. Squeak 4.1.1beta2: #(1357 2129 1457) Cog: #(141 844 568) (2.66 GHz Intel Core i7) On May 26, 2010, at 7:30 PM, Dale Henrichs wrote: > StÃ©phane Ducasse wrote: >> any idea why on pharo 1.1 >> | b n | >> b := [:aa :ab| ]. >> n := 10000000. >> { Time millisecondsToRun: [1 to: n do: [:i| b value: 0 value: 0]]. >> Time millisecondsToRun: [1 to: n do: [:i| b valueWithArguments: {0. 0}]]. >> Time millisecondsToRun: [1 to: n do: [:i| b valueWithArguments: #(0 0)]] } #(1597 2606 1696) > > Presumably the Array constructor {...} is more costly than a literal Array, which makese sense. > > Dale > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 26, 2010