[Newcompiler] Re: 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 Newcompiler
mailing list