[Pharo-project] #and:and:and: deprecated on 1.1, why?
that methods is marked like "deprecated": 'Use self deprecated: 'Use and: instead'. ' But curiosly the method #and:and:and:and: appears normal, without deprecation. That behavior is correct? Thanks -- View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2230786.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Ohhh, my mistake, I will change it as deprecated. Thank you for the report. On May 25, 2010, at 23:51 , nullPointer wrote:
that methods is marked like "deprecated": 'Use self deprecated: 'Use and: instead'. '
But curiosly the method #and:and:and:and: appears normal, without deprecation. That behavior is correct?
Thanks -- View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2230786.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--- Jannik Laval
But I don´t understand why the methods #and:and:and: AND #and:and:and:and: must be deprecateds... what is the equivalence now for that messages? is possible create a #&& and #|| messages? Regards -- View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231198.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
reasons - and:and:and: is only used in squeak totally not portable. (we could live with that) - and: is optimized by the compiler - and:and: are not optimized is it ok? Stef On May 26, 2010, at 10:10 AM, nullPointer wrote:
But I don´t understand why the methods #and:and:and: AND #and:and:and:and: must be deprecateds... what is the equivalence now for that messages? is possible create a #&& and #|| messages?
Regards -- View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231198.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
http://forum.world.st/about-and-and-and-and-and-or-or-tp1477719p1477719.html On Wed, May 26, 2010 at 11:53 AM, Richard Durr <richard.durr@googlemail.com>wrote:
WTF?! These are the only reasons?
Why do we have #value:value:value: then?
- and: is optimized by the compiler We could use C, where "everything" is optimized by the compiler.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 but again we are not saying that we know everything and that any solutions could not be rollback. We are doing and learning. Now having clean, lean and fast core classes are important.
Because we could have and:or: or:and: and:and:or: and a couple of others in that case.
Why do we have #value:value:value: then?
Because this is part of block protocol in the ANSI and because you cannot do it only with value:
- and: is optimized by the compiler We could use C, where "everything" is optimized by the compiler.
I think that your point is out of scope but if you want you can use C. Stef
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 Cheers, Henry
Em 26/05/2010 07:07, Henrik Johansen < henrik.s.johansen@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
Thanks for the response. I don't have a "real" argument â I wanted to point out my bewilderment: Why is #value:value: and the like in the ansi protocol, when #valueWithArguments: would be enough in any case? Of cause the answer is semantically clarity, readability, expressiveness and convenience. Doing something because it is "optimized by the compiler" instead of choosing a less optimized, but clearer and more expressive way seems 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. On Wed, May 26, 2010 at 11:58 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 but again we are not saying that we know everything and that any solutions could not be rollback. We are doing and learning. Now having clean, lean and fast core classes are important.
Because we could have and:or: or:and: and:and:or: and a couple of others in that case.
Why do we have #value:value:value: then?
Because this is part of block protocol in the ANSI and because you cannot do it only with value:
- and: is optimized by the compiler We could use C, where "everything" is optimized by the compiler.
I think that your point is out of scope but if you want you can use C.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On May 26, 2010, at 12:31 PM, Richard Durr wrote:
Thanks for the response. I don't have a "real" argument â I wanted to point out my bewilderment:
Why is #value:value: and the like in the ansi protocol, when #valueWithArguments: would be enough in any case? Of cause the answer is semantically clarity, readability, expressiveness and convenience. Doing something because it is "optimized by the compiler" instead of choosing a less optimized, but clearer and more expressive way seems 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.
I understand now I think that and:and:and: is not nice nor necessary, especially since each time a message is optimized it means a lot more work for the decompiler and friends. It is different to value:value: since this is more historical. Now the main reason is to have a nice and clean core. Booleans do not really need and:and:and:. Stef
On Wed, May 26, 2010 at 11:58 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 but again we are not saying that we know everything and that any solutions could not be rollback. We are doing and learning. Now having clean, lean and fast core classes are important.
Because we could have and:or: or:and: and:and:or: and a couple of others in that case.
Why do we have #value:value:value: then?
Because this is part of block protocol in the ANSI and because you cannot do it only with value:
- and: is optimized by the compiler We could use C, where "everything" is optimized by the compiler.
I think that your point is out of scope but if you want you can use C.
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
thanks butcher :) You worked too much with philippe :))))) Stef On May 26, 2010, at 1:20 PM, Lukas Renggli 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: ? -- Cheers, Peter On Wed, May 26, 2010 at 1:20 PM, Lukas Renggli <renggli@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: ?
They serve different purpose: - #valueWithArguments: is useful only if you have a collection of arguments. If you have individual arguments you have to create a collection first. - #value:value:value: is useful only if you have individual arguments. If you have a collection of arguments you have to take them apart first. Lukas -- Lukas Renggli www.lukas-renggli.ch
tx! I found the traits bug :) Stef On May 26, 2010, at 1:38 PM, Lukas Renggli wrote:
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: ?
They serve different purpose:
- #valueWithArguments: is useful only if you have a collection of arguments. If you have individual arguments you have to create a collection first.
- #value:value:value: is useful only if you have individual arguments. If you have a collection of arguments you have to take them apart first.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
But then which is the equivalence to #and:and:and: when I have many conditions? Perhaps I will say a stupidity... but , not is valid the implementation of #&& and #|| messages instead of #and:... #or: .....? ( aCondition1 && aCondition2 && aCondition3 ) ifTrue: [ <something> ] Regards -- View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231486.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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.
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.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ah okay, I am much relieved now, thanks :) On Wed, May 26, 2010 at 2:16 PM, Stéphane Ducasse <stephane.ducasse@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.
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.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Well, I understand than #&& and #|| must be equivalents to #and: AND #or: . Lazy comparison I want say. Regards -- View this message in context: http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231539.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 26 May 2010 15:16, Stéphane Ducasse <stephane.ducasse@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.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Yup. Another argument to kill and:and:and: It reminds me isKindOf:orOf:
Ah ah ah! #isKindOf:orOf: Woooaaaa.... Your email made me laugh. Thanks Igor :-) Cheers, Alexandre
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.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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@gmail.com>: > On 26 May 2010 15:16, Stéphane Ducasse <stephane.ducasse@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.html >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project@lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project@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@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@gmail.com>:
On 26 May 2010 15:16, Stéphane Ducasse <stephane.ducasse@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.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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:
2010/5/26 Peter Hugosson-Miller <oldmanlink@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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)]] }
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, May 26, 2010 at 11:41 AM, Stéphane Ducasse < stephane.ducasse@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, 26 May 2010, Lukas Renggli 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.
That's not true. Both #and: and #and:and:and: (and friends) are short-circuit, so they'll cause exactly the same side effects. Levente
- 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
- 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. Lukas -- Lukas Renggli www.lukas-renggli.ch
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 26 May 2010 20:47, Levente Uzonyi <leves@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Wed, 26 May 2010, Igor Stasenko wrote:
On 26 May 2010 20:47, Levente Uzonyi <leves@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 26 May 2010 22:18, Levente Uzonyi <leves@elte.hu> wrote:
On Wed, 26 May 2010, Igor Stasenko wrote:
On 26 May 2010 20:47, Levente Uzonyi <leves@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Wed, 26 May 2010, Igor Stasenko wrote:
On 26 May 2010 22:18, Levente Uzonyi <leves@elte.hu> wrote:
On Wed, 26 May 2010, Igor Stasenko wrote:
On 26 May 2010 20:47, Levente Uzonyi <leves@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.
Nice idea, but there's no a, b or c in it (which evaluate to a Boolean). Anyway if you implement a method named #and:, you won't be able to use it, since #and: is inlined. (Which means that it's like a keyword, you can't reuse it without changing the compiler. This is another reason why inlining more methods is a bad idea.) Levente
Levente
Levente
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 27 May 2010 01:57, Levente Uzonyi <leves@elte.hu> wrote:
On Wed, 26 May 2010, Igor Stasenko wrote:
On 26 May 2010 22:18, Levente Uzonyi <leves@elte.hu> wrote:
On Wed, 26 May 2010, Igor Stasenko wrote:
On 26 May 2010 20:47, Levente Uzonyi <leves@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.
Nice idea, but there's no a, b or c in it (which evaluate to a Boolean). Anyway if you implement a method named #and:, you won't be able to use it, since #and: is inlined. (Which means that it's like a keyword, you can't reuse it without changing the compiler. This is another reason why inlining more methods is a bad idea.)
I know. But all optimizations should follow a rule: you can cheat, but not get caught. Isnt? :) In smalltalk, i can send #and: message to any object. And from this point , there is no way how #and:and: could provide similar behavior, unless my class also implements it.
Levente
Levente
Levente
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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@elte.hu> wrote:
On Wed, 26 May 2010, Igor Stasenko wrote:
On 26 May 2010 20:47, Levente Uzonyi <leves@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (17)
-
Alexandre Bergel -
Alexandre Bergel -
csrabak＠bol.com.br -
Dale Henrichs -
Eliot Miranda -
Henrik Johansen -
Igor Stasenko -
Laval Jannik -
Levente Uzonyi -
Lukas Renggli -
Mariano Abel Coca -
Mariano Martinez Peck -
Nicolas Cellier -
nullPointer -
Peter Hugosson-Miller -
Richard Durr -
Stéphane Ducasse