[Pharo-project] testWhileModificationBeforeNotInlined
Doing some test fixing I noticed that testWhileModificationBeforeNotInlined not fail.... but I think it should be: Here is the code: testWhileModificationBeforeNotInlined | index block | index := 0. block := [ index := index + 1. collection add: [ index ] ]. [ index < 5 ] whileTrue: block. self assertValues: #(5 5 5 5 5) I think this should produce in collection: #(1 2 3 4 5) ... there's another tests with the block directly as collaborator of the whileTrue: (without temp assignment) that produces the expected output... I'm missing something? Thanks Gabriel
Well, the bloks collected in collection should all refer to the same temporary variable | index | in the context of execution of testWhileModificationBeforeNotInlined When these get executed by assertValues:, we can expect they all return the current value of this | index | temp, that is 5. That is not the case, because BlockClosure implementation creates a copy of outside temporaries it accesses (this is for optimization purposes). You can try to fool the compiler with this code: | index block | index := 0. block := [ index := index + 1. collection add: [ 1>2 ifTrue: [index:=0]. index ] ]. [ index < 5 ] whileTrue: block. There you get #(5 5 5 5 5) as expected... I suggest this test be moved in known failures. Lukas ? Nicolas 2009/6/17 Gabriel Cotelli <g.cotelli@gmail.com>
Doing some test fixing I noticed that testWhileModificationBeforeNotInlined not fail.... but I think it should be:
Here is the code:
testWhileModificationBeforeNotInlined
| index block | index := 0. block := [ index := index + 1. collection add: [ index ] ]. [ index < 5 ] whileTrue: block. self assertValues: #(5 5 5 5 5)
I think this should produce in collection: #(1 2 3 4 5) ... there's another tests with the block directly as collaborator of the whileTrue: (without temp assignment) that produces the expected output...
I'm missing something?
Thanks Gabriel
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I suggest this test be moved in known failures. Lukas ?
I don't get it ;-) This looks fine to me. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Ah, yes, I don't understand neither. For me, the non inlined version seems to work already and gives #(5 5 5 5 5). The inlined version fails and gives #(1 2 3 4 5), except if you fool the Compiler with the trick I have indicated: testWhileModificationBefore | index | index := 0. [ index < 5 ] whileTrue: [ index := index + 1. collection add: [1>2 ifTrue: [index:=0]. index ] ]. self assertValues: #(5 5 5 5 5) The point remains:some well known failing tests that won't be solved should go in known failures. Nicolas 2009/6/17 Lukas Renggli <renggli@gmail.com>
I suggest this test be moved in known failures. Lukas ?
I don't get it ;-)
This looks fine to me.
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
The point remains:some well known failing tests that won't be solved should go in known failures.
Yes, agreed. I thought a fix would soon be available, but that doesn't seem the case. Anyway, most Smalltalk choke on these tests. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
I would really like that we do not lose it. May be lukas we should tagged them We should check the SunitExtension of keith to see if he has something to support supposed to fail tests. On Jun 17, 2009, at 12:19 PM, Lukas Renggli wrote:
The point remains:some well known failing tests that won't be solved should go in known failures.
Yes, agreed. I thought a fix would soon be available, but that doesn't seem the case.
Anyway, most Smalltalk choke on these tests.
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
On Jun 17, 2009, at 13:37 , Stéphane Ducasse wrote:
I would really like that we do not lose it. May be lukas we should tagged them We should check the SunitExtension of keith to see if he has something to support supposed to fail tests.
We have this already: #expectedFailures. Adrian
On Jun 17, 2009, at 12:19 PM, Lukas Renggli wrote:
The point remains:some well known failing tests that won't be solved should go in known failures.
Yes, agreed. I thought a fix would soon be available, but that doesn't seem the case.
Anyway, most Smalltalk choke on these tests.
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/6/17 Adrian Lienhard <adi@netstyle.ch>
On Jun 17, 2009, at 13:37 , Stéphane Ducasse wrote:
I would really like that we do not lose it. May be lukas we should tagged them We should check the SunitExtension of keith to see if he has something to support supposed to fail tests.
We have this already: #expectedFailures.
Adrian
Stephane was maybe thinking of an Annotation rewrite...
On Jun 17, 2009, at 12:19 PM, Lukas Renggli wrote:
The point remains:some well known failing tests that won't be solved should go in known failures.
Yes, agreed. I thought a fix would soon be available, but that doesn't seem the case.
Anyway, most Smalltalk choke on these tests.
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
_______________________________________________ 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
Sorry... I didn't notice the [] after the add: ... (so tired tonight :( ) in that case this test is Ok.. but the inlined version is failing.... 2009/6/17 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>
Ah, yes, I don't understand neither. For me, the non inlined version seems to work already and gives #(5 5 5 5 5). The inlined version fails and gives #(1 2 3 4 5), except if you fool the Compiler with the trick I have indicated:
testWhileModificationBefore | index | index := 0. [ index < 5 ] whileTrue: [ index := index + 1. collection add: [1>2 ifTrue: [index:=0]. index ] ]. self assertValues: #(5 5 5 5 5)
The point remains:some well known failing tests that won't be solved should go in known failures.
+1 for the inlined version of the test... (unless we want to fix it in the short term)....
Nicolas
2009/6/17 Lukas Renggli <renggli@gmail.com>
I suggest this test be moved in known failures.
Lukas ?
I don't get it ;-)
This looks fine to me.
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Adrian Lienhard -
Gabriel Cotelli -
Lukas Renggli -
Nicolas Cellier -
Stéphane Ducasse