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

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

by Igor Stasenko

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. > > 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.

May 26, 2010

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

by Levente Uzonyi

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. 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 >

May 26, 2010

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

by Dale Henrichs

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

May 26, 2010

Re: [Pharo-project] plan for 1.1

by StÃ©phane Ducasse

I know that luc is using it for the network rewrite he is doing talking direclty to low level socket without using Socket pluging On May 26, 2010, at 4:12 PM, Schwab,Wilhelm K wrote: > Stef, > > I am more concerned about Alien on Linux, which is not working. Beyond that, I want to learn more about how to make calls using Alien; the more I read, the more I have my doubts about its ease of use. I will gladly eat those words if it's easy to use. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Wednesday, May 26, 2010 10:04 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] plan for 1.1 > > yes this is good point. > I would like to have alien or ffi in 1.1. Now I do not know the status of Alien on windows. > > On May 26, 2010, at 2:52 PM, Schwab,Wilhelm K wrote: > >> Stef, >> >> My initial reaction to 1.1's approaching release was "where are the callbacks/aliens?" Sig appears to be offering some competition to Alien. If he/we can provide a comprehensive and convenient way to make calls, do callbacks, additionally put calls onto other OS threads, and do all of this on the three major platforms, then it could easily turn out the best option for external interfacing. >> >> I am happy to see us take time to get it right. My only concern would be that we not fall into a pattern of leaving out the difficult things that we set out to accomplish with a given release. Since 1.1 is approaching releasable form and FFI/Alien/NB is unclear at present, a release makes sense. >> >> Short answer: sure, whatever you say :) >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] >> Sent: Wednesday, May 26, 2010 4:20 AM >> To: Pharo Development >> Subject: [Pharo-project] plan for 1.1 >> >> Hi guys >> >> we were discussing how we can handle 1.1 and the flux of good changes. >> Here is the proposal: >> we take two or three weeks to let people try their code in 1.1 beta >> we integrate fixes that are important or easy >> then we wait one week >> then we launch 1.1 rc and 1.2 unstable >> >> does this plan look ok for you? >> The key point is that we want to avoid to have a pile of changes pending because they can rot easily. >> >> Stef >> _______________________________________________ >> 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 StÃ©phane Ducasse

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) On May 26, 2010, at 6:49 PM, Eliot Miranda wrote: > | 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)]] }

May 26, 2010

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

by StÃ©phane Ducasse

>> In general (but it often does not work :)) having a lot of conditions in OOP >> means that you are missing class to dispatch on then. >> > Yup. Another argument to kill and:and:and: > It reminds me > isKindOf:orOf: lol next one on my radar would be findA: or friends in morph findAThat:

May 26, 2010

Re: [Pharo-project] ReferenceStream, tree or graph?

by Lukas Renggli

ReferenceStream can store cycles. > "This is a way of serializing a tree of objects into disk file. A > ReferenceStream can store one or more objects in a persistent form, > including sharing and cycles." ReferenceStream does a pre-order traversal of the object graph. Whenever it encounters an object that has been already serialized it puts a special back-reference to that object. With this strategy you essentially end up with a tree, if you do not look at these back-references. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 26, 2010

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

by Eliot Miranda

2010/5/26 Peter Hugosson-Miller <oldmanlink(a)gmail.com> > Thanks, Lucas! > > I like nice clear concise lists of logical reasons like this :-) > > Not that I disagree with Stef in any way at all, but can you think of > reasons - other than the historical ones - why #value:value:value: and > friends are to be preferred over #valueWithArguments: ? > The fundamental ones are that value[:value:]* a) avoid consing up the array to hold the arguments and b) avoid determining the array's size and dereferencing it when evaluating. The value[:value:]* primitives are as a result usefully more streamlined than the valueWithArguments: primitive. That may still be a historical argument but I still find it compelling: | 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)]] } Squeak 4.1.1beta2: #(1357 2129 1457) Cog: #(141 844 568) (2.66 GHz Intel Core i7) > -- > Cheers, > Peter > > > On Wed, May 26, 2010 at 1:20 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >> > not right to me. I wanted to express the feeling that, for me, the one >> > of the best things about Smalltalk is its readability in difference to >> > C, which is very fast. The Â»new compiler optimizeÂ« both, anyway. >> >> - The "New Compiler" does not yet work. >> >> - The optimized #and:and:and: code never decompiled correctly. >> >> - 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. >> >> - The #and:and:and: constructs are very confusing to newbies, I have >> seen that numerous times. >> >> - The use of #and:and:and: doesn't shorten code. >> >> - #and:and:and: is not necessary from a language point of view. >> >> - And most important for me: #and:and:and: is incompatible with the >> rest of the world. >> >> 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 >

May 26, 2010

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

by Alexandre Bergel

Another point that I feel is important for banning and:and:... is that it makes code harder to refactor. Consider: #1: exp1 and: [exp2] and: [exp3] and #2: (exp1 and: [exp2]) and: [exp3] In #2, I can select what is inside (...) and press extract to method. In #1, I cannot select "exp1 and: [exp2]" and extract. The rb engine will not like it. And I would not expect the rb engine to extract piece of a message call into a new method. Cheers, Alexandre On 26 May 2010, at 12:16, Nicolas Cellier wrote: > Lukas already answered very well. > From core designer point of view, the questions is what additionnal > value is brought by #and:and:and: ? > - does it add expressiveness against nested and: [and: [ and: [ ] ] ] ? Not much > - does it shorten code ? No > - does it enable some optimization ? No > If it has no value, then we should better remove it and simplify the API. > > Nicolas > > 2010/5/26 Igor Stasenko <siguctua(a)gmail.com>: >> On 26 May 2010 15:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> In general (but it often does not work :)) having a lot of conditions in OOP >>> means that you are missing class to dispatch on then. >>> >> Yup. Another argument to kill and:and:and: >> It reminds me >> isKindOf:orOf: >> >>>> But then which is the equivalence to #and:and:and: when I have many >>>> conditions? >>> >>> a and: [b] and: [c] >>> >>> if a and c do not have side effect that may change the condition are equivalent >>> to >>> a and: [ b and: [c]] >>> >>> so you have express what you want >>> >>>> Perhaps I will say a stupidity... but , not is valid the implementation of >>>> #&& and #|| messages instead of #and:... #or: .....? >>> >>> >>> & and | are executing all their arguments while >>> true & error -> error >>> true and: [error] -> true but it is more costly >>> >>> >>>> >>>> ( aCondition1 && aCondition2 && aCondition3 ) ifTrue: [ <something> ] >>>> >>>> >>>> Regards >>>> -- >>>> View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231486.h… >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> 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

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

by Nicolas Cellier

Lukas already answered very well. >From core designer point of view, the questions is what additionnal value is brought by #and:and:and: ? - does it add expressiveness against nested and: [and: [ and: [ ] ] ] ? Not much - does it shorten code ? No - does it enable some optimization ? No If it has no value, then we should better remove it and simplify the API. Nicolas 2010/5/26 Igor Stasenko <siguctua(a)gmail.com>: > On 26 May 2010 15:16, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> In general (but it often does not work :)) having a lot of conditions in OOP >> means that you are missing class to dispatch on then. >> > Yup. Another argument to kill and:and:and: > It reminds me > isKindOf:orOf: > >>> But then which is the equivalence to #and:and:and: when I have many >>> conditions? >> >> a and: [b] and: [c] >> >> if a and c do not have side effect that may change the condition are equivalent >> to >> a and: [ b and: [c]] >> >> so you have express what you want >> >>> Perhaps I will say a stupidity... but , not is valid the implementation of >>> #&& and #|| messages instead of #and:... Â #or: .....? >> >> >> & and | are executing all their arguments while >> Â Â Â Â true & error -> error >> Â Â Â Â true and: [error] -> true but it is more costly >> >> >>> >>> ( aCondition1 && aCondition2 && aCondition3 ) ifTrue: [ <something> ] >>> >>> >>> Regards >>> -- >>> View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231486.h… >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> 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