- Pharo-dev - lists.pharo.org

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

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