Smalltalk › Pharo › Pharo Smalltalk Developers

Pharo 1.1 failing tests testBlockNumbering

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Nicolas Cellier

Pharo 1.1 failing tests testBlockNumbering

The test is incompatible with new CompiledMethod trailer
Use generate rather than generate: #(0 0 0 0)

Then the method still fails because sending unimplemented
#blockExtentsToTempRefs

same for testBlockNumberingForInjectInto testTempNameAccessForInjectInto

Nicolas

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

Nicolas Cellier

Re: Pharo 1.1 failing tests testBlockNumbering

Correct message is blockExtentsToTempsMap rather than blockExtentsToTempRefs

But then, method still fails because keys does not answer a Set
anymore. Use keys asSet.

Nicolas

2010/1/16 Nicolas Cellier <[hidden email]>:

> The test is incompatible with new CompiledMethod trailer
> Use generate rather than generate: #(0 0 0 0)
>
> Then the method still fails because sending unimplemented
> #blockExtentsToTempRefs
>
> same for testBlockNumberingForInjectInto testTempNameAccessForInjectInto
>
> Nicolas
>

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

Nicolas Cellier

Re: Pharo 1.1 failing tests testBlockNumbering

Then blockExtentsToTempsMap values are Arrays of pairs, not exactly
what expected by the test...

Nicolas

2010/1/16 Nicolas Cellier <[hidden email]>:

> Correct message is blockExtentsToTempsMap rather than blockExtentsToTempRefs
>
> But then, method still fails because keys does not answer a Set
> anymore. Use keys asSet.
>
> Nicolas
>
> 2010/1/16 Nicolas Cellier <[hidden email]>:
>> The test is incompatible with new CompiledMethod trailer
>> Use generate rather than generate: #(0 0 0 0)
>>
>> Then the method still fails because sending unimplemented
>> #blockExtentsToTempRefs
>>
>> same for testBlockNumberingForInjectInto testTempNameAccessForInjectInto
>>
>> Nicolas
>>
>

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

Stéphane Ducasse

Re: Pharo 1.1 failing tests testBlockNumbering

I will check.

Stef

On Jan 16, 2010, at 5:14 PM, Nicolas Cellier wrote:

> Then blockExtentsToTempsMap values are Arrays of pairs, not exactly
> what expected by the test...
>
> Nicolas
>
> 2010/1/16 Nicolas Cellier <[hidden email]>:
>> Correct message is blockExtentsToTempsMap rather than blockExtentsToTempRefs
>>
>> But then, method still fails because keys does not answer a Set
>> anymore. Use keys asSet.
>>
>> Nicolas
>>
>> 2010/1/16 Nicolas Cellier <[hidden email]>:
>>> The test is incompatible with new CompiledMethod trailer
>>> Use generate rather than generate: #(0 0 0 0)
>>>
>>> Then the method still fails because sending unimplemented
>>> #blockExtentsToTempRefs
>>>
>>> same for testBlockNumberingForInjectInto testTempNameAccessForInjectInto
>>>
>>> Nicolas
>>>
>>
>
> _______________________________________________
> 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: Pharo 1.1 failing tests testBlockNumbering

By the way, I created
http://code.google.com/p/pharo/issues/detail?id=1837 for these tests

2010/1/16 Stéphane Ducasse <[hidden email]>:

> I will check.
>
> Stef
>
> On Jan 16, 2010, at 5:14 PM, Nicolas Cellier wrote:
>
>> Then blockExtentsToTempsMap values are Arrays of pairs, not exactly
>> what expected by the test...
>>
>> Nicolas
>>
>> 2010/1/16 Nicolas Cellier <[hidden email]>:
>>> Correct message is blockExtentsToTempsMap rather than blockExtentsToTempRefs
>>>
>>> But then, method still fails because keys does not answer a Set
>>> anymore. Use keys asSet.
>>>
>>> Nicolas
>>>
>>> 2010/1/16 Nicolas Cellier <[hidden email]>:
>>>> The test is incompatible with new CompiledMethod trailer
>>>> Use generate rather than generate: #(0 0 0 0)
>>>>
>>>> Then the method still fails because sending unimplemented
>>>> #blockExtentsToTempRefs
>>>>
>>>> same for testBlockNumberingForInjectInto testTempNameAccessForInjectInto
>>>>
>>>> Nicolas
>>>>
>>>
>>
>> _______________________________________________
>> 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

Stéphane Ducasse

Re: Pharo 1.1 failing tests testBlockNumbering

Thanks! I will integrate all that tomorrow morning.

Stef

On Jan 16, 2010, at 7:51 PM, Nicolas Cellier wrote:

> By the way, I created
> http://code.google.com/p/pharo/issues/detail?id=1837 for these tests
>
> 2010/1/16 Stéphane Ducasse <[hidden email]>:
>> I will check.
>>
>> Stef
>>
>> On Jan 16, 2010, at 5:14 PM, Nicolas Cellier wrote:
>>
>>> Then blockExtentsToTempsMap values are Arrays of pairs, not exactly
>>> what expected by the test...
>>>
>>> Nicolas
>>>
>>> 2010/1/16 Nicolas Cellier <[hidden email]>:
>>>> Correct message is blockExtentsToTempsMap rather than blockExtentsToTempRefs
>>>>
>>>> But then, method still fails because keys does not answer a Set
>>>> anymore. Use keys asSet.
>>>>
>>>> Nicolas
>>>>
>>>> 2010/1/16 Nicolas Cellier <[hidden email]>:
>>>>> The test is incompatible with new CompiledMethod trailer
>>>>> Use generate rather than generate: #(0 0 0 0)
>>>>>
>>>>> Then the method still fails because sending unimplemented
>>>>> #blockExtentsToTempRefs
>>>>>
>>>>> same for testBlockNumberingForInjectInto testTempNameAccessForInjectInto
>>>>>
>>>>> Nicolas
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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

Eliot Miranda-2

Re: Pharo 1.1 failing tests testBlockNumbering

In reply to this post by Nicolas Cellier

On Sat, Jan 16, 2010 at 8:14 AM, Nicolas Cellier <[hidden email]> wrote:

Then blockExtentsToTempsMap values are Arrays of pairs, not exactly
what expected by the test...

The keys are ranges, the values are arrays of arrays of name, index, e.g.

a Dictionary(

(0 to: 6)->#(#('thisValue' 1) #('binaryBlock' 2) #('nextValue' #(3 1)))

(2 to: 4)->#(#('each' 1) #('binaryBlock' 2) #('nextValue' #(3 1))) )

self assert: tempRefs keys = method startpcsToBlockExtents values asSet.

needs to become

self assert: tempRefs keys asSet = method startpcsToBlockExtents values asSet.

if keys no longer returns a set.

Here's the (working) test in my image:

testBlockNumberingForInjectInto

"Test that the compiler and CompiledMethod agree on the block numbering of Collection>>inject:into:

and that temp names for inject:into: are recorded."

"self new testBlockNumberingForInjectInto"

| methodNode method tempRefs |

methodNode := Parser new

encoderClass: EncoderForV3PlusClosures;

parse: (Collection sourceCodeAt: #inject:into:)

class: Collection.

method := methodNode generate: #(0 0 0 0).

tempRefs := methodNode encoder blockExtentsToTempsMap.

self assert: tempRefs keys = method startpcsToBlockExtents values asSet.

self assert: ((tempRefs includesKey: (0 to: 6))

and: [(tempRefs at: (0 to: 6)) hasEqualElements: #(('thisValue' 1) ('binaryBlock' 2) ('nextValue' (3 1)))]).

self assert: ((tempRefs includesKey: (2 to: 4))

and: [(tempRefs at: (2 to: 4)) hasEqualElements: #(('each' 1) ('binaryBlock' 2) ('nextValue' (3 1)))])

Nicolas

2010/1/16 Nicolas Cellier <[hidden email]>:
> Correct message is blockExtentsToTempsMap rather than blockExtentsToTempRefs
>
> But then, method still fails because keys does not answer a Set
> anymore. Use keys asSet.
>
> Nicolas
>
> 2010/1/16 Nicolas Cellier <[hidden email]>:
>> The test is incompatible with new CompiledMethod trailer
>> Use generate rather than generate: #(0 0 0 0)
>>
>> Then the method still fails because sending unimplemented
>> #blockExtentsToTempRefs
>>
>> same for testBlockNumberingForInjectInto testTempNameAccessForInjectInto
>>
>> Nicolas
>>
>

_______________________________________________
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