Smalltalk › Pharo › Pharo Smalltalk Developers

testWhileModificationBeforeNotInlined

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

gcotelli

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nicolas Cellier

Re: testWhileModificationBeforeNotInlined

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 <[hidden email]>

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Lukas Renggli

Re: testWhileModificationBeforeNotInlined

> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nicolas Cellier

Re: testWhileModificationBeforeNotInlined

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 <[hidden email]>

> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Lukas Renggli

Re: testWhileModificationBeforeNotInlined

> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse

Re: testWhileModificationBeforeNotInlined

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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

gcotelli

Re: testWhileModificationBeforeNotInlined

In reply to this post by Nicolas Cellier

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 <[hidden email]>

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 <[hidden email]>

> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Adrian Lienhard

Re: testWhileModificationBeforeNotInlined

In reply to this post by Stéphane Ducasse

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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nicolas Cellier

Re: testWhileModificationBeforeNotInlined

2009/6/17 Adrian Lienhard <[hidden email]>

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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project