[Pharo-project] about the closure
hi guys we discussed a bit with marcus and we arrived to the conclusion that we want to push the changes in the stream and that we will fix the problems when they show up. Now what it means is that - we will do probably today -> produce a new image with non dirty packages -> produce some fixes to check if we can load them with MC. and make it roll :) BTW having closure is really great. the code is so much nicer. Stef
Hi stef Apart from kicking the tyres, how best do we test the closure integration? Thanks Mike On 3/30/09, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
hi guys
we discussed a bit with marcus and we arrived to the conclusion that we want to push the changes in the stream and that we will fix the problems when they show up. Now what it means is that - we will do probably today -> produce a new image with non dirty packages
-> produce some fixes to check if we can load them with MC.
and make it roll :)
BTW having closure is really great. the code is so much nicer.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
- do all kind of things with the system - checking the tests that failed Stef On Mar 30, 2009, at 11:17 PM, Michael Roberts wrote:
Hi stef Apart from kicking the tyres, how best do we test the closure integration?
Thanks Mike
On 3/30/09, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
hi guys
we discussed a bit with marcus and we arrived to the conclusion that we want to push the changes in the stream and that we will fix the problems when they show up. Now what it means is that - we will do probably today -> produce a new image with non dirty packages
-> produce some fixes to check if we can load them with MC.
and make it roll :)
BTW having closure is really great. the code is so much nicer.
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
Eliots code comes with additional tests. Furthermore I wrote an set of tests (see attachement). These tests especially make sure that none of the optimizations destroy the closure behavior. All existing Smalltalk implementations have some bugs, even the commercial ones. Another test is that the image can be completely recompiled and no additional test fails. Then the Seaside tests are another good candidate, they depend heavily on block behavior. And continuations extensively stress the context implementation. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Thanks! On Mar 30, 2009, at 11:40 PM, Lukas Renggli wrote:
Eliots code comes with additional tests.
Furthermore I wrote an set of tests (see attachement). These tests especially make sure that none of the optimizations destroy the closure behavior. All existing Smalltalk implementations have some bugs, even the commercial ones.
Another test is that the image can be completely recompiled and no additional test fails.
Then the Seaside tests are another good candidate, they depend heavily on block behavior. And continuations extensively stress the context implementation.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch <ClosureTests.st>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Furthermore I wrote an set of tests (see attachement). These tests especially make sure that none of the optimizations destroy the closure behavior. All existing Smalltalk implementations have some bugs, even the commercial ones.
I should note that these tests were written after a long discussion with Oscar on the exact ANSI Smalltalk block semantics. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
I really want to see that :) Because the semantics of Smalltalk block is far from clear to me. Do you write something on it :)? for DSL? for ESUG workshop? Stef On Mar 31, 2009, at 12:20 AM, Lukas Renggli wrote:
Furthermore I wrote an set of tests (see attachement). These tests especially make sure that none of the optimizations destroy the closure behavior. All existing Smalltalk implementations have some bugs, even the commercial ones.
I should note that these tests were written after a long discussion with Oscar on the exact ANSI Smalltalk block semantics.
Lukas
-- Lukas Renggli http://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
Hi, Very cool! Attached is a third set of tests, those where written by Rob Wither and Boris Gaertner years ago. And: they don't file in. I think because Eliot's compiler does not support shadowing of variables in some cases. But I did not look to deeply. On 30.03.2009, at 23:40, Lukas Renggli wrote:
Eliots code comes with additional tests.
Furthermore I wrote an set of tests (see attachement). These tests especially make sure that none of the optimizations destroy the closure behavior. All existing Smalltalk implementations have some bugs, even the commercial ones.
Another test is that the image can be completely recompiled and no additional test fails.
Then the Seaside tests are another good candidate, they depend heavily on block behavior. And continuations extensively stress the context implementation.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch <ClosureTests.st>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
Attached is a third set of tests, those where written by Rob Wither and Boris Gaertner years ago.
And: they don't file in. I think because Eliot's compiler does not support shadowing of variables in some cases. But I did not look to deeply.
I fixed the loading, see attachement. The tests all pass :-) Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Ok cool. Good stuff! Mike On 3/31/09, Lukas Renggli <renggli@gmail.com> wrote:
Attached is a third set of tests, those where written by Rob Wither and Boris Gaertner years ago.
And: they don't file in. I think because Eliot's compiler does not support shadowing of variables in some cases. But I did not look to deeply.
I fixed the loading, see attachement. The tests all pass :-)
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
So the semantics you describe is that the closure refers to variables until it is valued and not their values And of course there is a difference whether the variable is a closure temporary or whether it is a enclosing scope one. lukas is it normal that we get 3 tests yellow - did you get the same in your image? Did you say it to eliot? The tests of boris remind me some of my lisp cps-iterator :) Ugly in smalltalk :) Stef
lukas is it normal that we get 3 tests yellow - did you get the same in your image?
#testToDoOutsideTemp and #testWhileModificationBefore are broken. I don't think that should stop us from integrating the closures into Pharo. Most "industrial strength" Smalltalk implementations have many more closure bugs than Pharo.
Did you say it to eliot?
Eliot already fixed the third failure you are observing. Load the attached change-set and recompile the tests. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
On Apr 1, 2009, at 11:12 AM, Lukas Renggli wrote:
lukas is it normal that we get 3 tests yellow - did you get the same in your image?
#testToDoOutsideTemp and #testWhileModificationBefore are broken. I don't think that should stop us from integrating the closures into Pharo. Most "industrial strength" Smalltalk implementations have many more closure bugs than Pharo.
This is integrated already and this is good to have such great test suites. I will integrate them this evening.
Did you say it to eliot?
Eliot already fixed the third failure you are observing. Load the attached change-set and recompile the tests.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch <TempVariableNode- analyseClosure.st>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 01.04.2009, at 11:31, Stéphane Ducasse wrote:
On Apr 1, 2009, at 11:12 AM, Lukas Renggli wrote:
lukas is it normal that we get 3 tests yellow - did you get the same in your image?
#testToDoOutsideTemp and #testWhileModificationBefore are broken. I don't think that should stop us from integrating the closures into Pharo. Most "industrial strength" Smalltalk implementations have many more closure bugs than Pharo.
This is integrated already and this is good to have such great test suites. I will integrate them this evening.
Lukas' teste should be already in, I think. Marcus -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
It would be good to document this knowledge of what is expected in our test suites. Especially if some are known to fail. Is there a pattern already in use? E.g. Method comment, pragma, wiki page entry? If not what should we adopt? Thanks mike On 4/1/09, Marcus Denker <denker@acm.org> wrote:
On 01.04.2009, at 11:31, Stéphane Ducasse wrote:
On Apr 1, 2009, at 11:12 AM, Lukas Renggli wrote:
lukas is it normal that we get 3 tests yellow - did you get the same in your image?
#testToDoOutsideTemp and #testWhileModificationBefore are broken. I don't think that should stop us from integrating the closures into Pharo. Most "industrial strength" Smalltalk implementations have many more closure bugs than Pharo.
This is integrated already and this is good to have such great test suites. I will integrate them this evening.
Lukas' teste should be already in, I think.
Marcus
-- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I would like to see the pattern "all tests always green" (except for expected failures, see below). Maybe this is too rigorous in practice since not everybody seems to care that much about tests. It would mean that no new updates are pushed in the stream until all tests that were broken by the previous update are fixed. Or even better, we would not integrate any code as long as it breaks a test. Anyway, I see the following two possibilities: - use SUnit's expected failures feature (see implementors of #expectedFailures) to marke tests we know are broken - create a wiki page to document currently broken tests I would use the former only for tests that document a bug that we don't know how to fix within the foreseeable future. The drawback of the wiki page is that it is prone to get out of date. Cheers, Adrian On Apr 1, 2009, at 19:00 , Michael Roberts wrote:
It would be good to document this knowledge of what is expected in our test suites. Especially if some are known to fail. Is there a pattern already in use? E.g. Method comment, pragma, wiki page entry? If not what should we adopt?
Thanks mike
On 4/1/09, Marcus Denker <denker@acm.org> wrote:
On 01.04.2009, at 11:31, Stéphane Ducasse wrote:
On Apr 1, 2009, at 11:12 AM, Lukas Renggli wrote:
lukas is it normal that we get 3 tests yellow - did you get the same in your image?
#testToDoOutsideTemp and #testWhileModificationBefore are broken. I don't think that should stop us from integrating the closures into Pharo. Most "industrial strength" Smalltalk implementations have many more closure bugs than Pharo.
This is integrated already and this is good to have such great test suites. I will integrate them this evening.
Lukas' teste should be already in, I think.
Marcus
-- Marcus Denker -- denker@acm.org http://www.marcusdenker.de
_______________________________________________ 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
I definitely care about the tests all green ;-) I just don't want to debug into tests when there is no point. I'm not in favour of the wiki idea either. So I'll have a look at expected failures. sounds like we need to mark those two of Lukas' if they are not already thanks, Mike On Wed, Apr 1, 2009 at 6:29 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
I would like to see the pattern "all tests always green" (except for expected failures, see below). Maybe this is too rigorous in practice since not everybody seems to care that much about tests. It would mean that no new updates are pushed in the stream until all tests that were broken by the previous update are fixed. Or even better, we would not integrate any code as long as it breaks a test.
Anyway, I see the following two possibilities: - use SUnit's expected failures feature (see implementors of #expectedFailures) to marke tests we know are broken - create a wiki page to document currently broken tests
I would use the former only for tests that document a bug that we don't know how to fix within the foreseeable future. The drawback of the wiki page is that it is prone to get out of date.
Cheers, Adrian
On Apr 1, 2009, at 19:00 , Michael Roberts wrote:
It would be good to document this knowledge of what is expected in our test suites. Especially if some are known to fail. Is there a pattern already in use? E.g. Method comment, pragma, wiki page entry? If not what should we adopt?
Thanks mike
On 4/1/09, Marcus Denker <denker@acm.org> wrote:
On 01.04.2009, at 11:31, Stéphane Ducasse wrote:
On Apr 1, 2009, at 11:12 AM, Lukas Renggli wrote:
lukas is it normal that we get 3 tests yellow - did you get the same in your image?
#testToDoOutsideTemp and #testWhileModificationBefore are broken. I don't think that should stop us from integrating the closures into Pharo. Most "industrial strength" Smalltalk implementations have many more closure bugs than Pharo.
This is integrated already and this is good to have such great test suites. I will integrate them this evening.
Lukas' teste should be already in, I think.
   Marcus
-- Marcus Denker  --  denker@acm.org http://www.marcusdenker.de
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
yeap you re right
I definitely care about the tests all green ;-) I just don't want to debug into tests when there is no point. I'm not in favour of the wiki idea either. So I'll have a look at expected failures. sounds like we need to mark those two of Lukas' if they are not already
thanks,
Mike
About troll^Wtesting closures: http://math.andrej.com/2009/04/09/pythons-lambda-is-broken/ -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
did you try it in pharo. The tests of lukas are gorgeous BTW On Apr 9, 2009, at 9:39 PM, Damien Pollet wrote:
About troll^Wtesting closures: http://math.andrej.com/2009/04/09/pythons-lambda-is-broken/
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, Apr 9, 2009 at 21:48, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
did you try it in pharo.
making an array of adder blocks, yes, works as intended :)
The tests of lukas are gorgeous BTW
On Apr 9, 2009, at 9:39 PM, Damien Pollet wrote:
About troll^Wtesting closures: http://math.andrej.com/2009/04/09/pythons-lambda-is-broken/
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
_______________________________________________ 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
-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
2009/4/1 Lukas Renggli <renggli@gmail.com>:
#testToDoOutsideTemp and #testWhileModificationBefore are broken.
I was going to say they happen to test the same behavior as the python blog post I sent yesterday, but I missed a pair of brackets :) The python thing is equivalent to #testDoArgument, which passes. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
participants (6)
-
Adrian Lienhard -
Damien Pollet -
Lukas Renggli -
Marcus Denker -
Michael Roberts -
Stéphane Ducasse