When are 2 CompiledMethods = [incl: Float>>nan]

Klaus D. Witzel klaus.witzel at cobss.com
Sun Sep 9 10:17:51 UTC 2007


Hi Andreas,

on Sun, 09 Sep 2007 11:26:58 +0200, you wrote:

> Hi Klaus -
>
> Revert Association>>= to what it used to be and everything will be fine  
> (Association>>= is really, really badly broken; it causes problems all  
> over the places and this is one of them).

That's a very, very good one, thanks for reminding us of that open issue.

Since the compiler machinery (BytecodeGenerator) already uses  
#literalEqual: and I want Decompiler to use the same comparision for  
literals, it'll be easy to put #literalEqual: into Association without  
touching its current #= implementation. In a later step it's perhaps  
possible to really, really revert #= in Association.

Thanks again.

/Klaus

> Cheers,
>    - Andreas
>
> Klaus D. Witzel wrote:
>> Hi,
>>  Math and I discuss comparing two CompiledMethods whether or not they  
>> represent the same object when compiled from source. This is necessary  
>> for writing tests for the Decompiler.
>>  One of the obstacles are certainly the methods' literals, in  
>> particular Float>>#nan which have to be treated equal in the two  
>> compared methods, regardless of the fact that (Float nan = Float nan)  
>> == false :)
>>  Are there other cases which should be considered, for example does  
>> someone expect that Float>>#closeTo: is used for comparing Float  
>> literals of two methods? If that's not the case then Float literals  
>> other than nan, can be compared with good old fashioned #=.
>>  FWIW the two methods could have been compiled by different compilers  
>> and/or have literals (for example in class vars) created by different  
>> readers (think of Number#>>readFrom:), makes writing tests for the  
>> Decompiler not that easy :|
>>  TIA.
>>  /Klaus
>>  On Sat, 08 Sep 2007 17:30:37 +0200, Alejandro F. Reimondo wrote:
>>
>>>
>>>> Ok any reason for that?
>>> Yes. "nan" is not an object (it does not preserve identity),
>>>  it is something that can be named and that preserve
>>>  behavior (we can draw/attach an interface for/to it),
>>>  those properties does not make it an object.
>>>
>>> Ale.
>>>
>>>
>>>
>>> ----- Original Message ----- From: "Mathieu Suen" <mathk.sue at gmail.com>
>>> To: "The general-purpose Squeak developers list"  
>>> <squeak-dev at lists.squeakfoundation.org>
>>> Sent: Saturday, September 08, 2007 9:48 AM
>>> Subject: Re: Float>>nan
>>>
>>>
>>>> Ok any reason for that?
>>>>
>>>> Mth
>>>>
>>>>
>>>>
>>>> On Sep 8, 2007, at 12:24 PM, Lukas Renggli wrote:
>>>>
>>>>>> I have a strange bug:
>>>>>>
>>>>>> Float nan = Float nan -> false
>>>>>
>>>>> According to the standard NaN is not be equal to anything,   
>>>>> including itself.
>>>>>
>>>>> Check: http://en.wikipedia.org/wiki/IEEE_754
>>>>>
>>>>> Lukas
>>>>>
>>>>> -- Lukas Renggli
>>>>> http://www.lukas-renggli.ch
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>





More information about the Squeak-dev mailing list