[Vm-dev] Re: [Pharo-dev] How was BoxedFloat64 integrated into the image ?

[Nicolas Cellier]

2016-02-24 11:15 GMT+01:00 Nicolai Hess <nicolaihess at gmail.com>:

>
>
>
> 2016-02-24 11:01 GMT+01:00 Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com>:
>
>>
>>
>>
>> 2016-02-24 10:02 GMT+01:00 Nicolai Hess <nicolaihess at gmail.com>:
>>
>>>
>>>
>>>
>>> 2016-02-24 9:31 GMT+01:00 Nicolai Hess <nicolaihess at gmail.com>:
>>>
>>>>
>>>>
>>>> 2016-02-23 8:48 GMT+01:00 Nicolai Hess <nicolaihess at gmail.com>:
>>>>
>>>>>
>>>>>
>>>>> 2016-02-23 3:55 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:
>>>>>
>>>>>> Hi Nicolai,
>>>>>>
>>>>>>     there is a hairy script that moves methods around the hierarchy.
>>>>>> IIRC Float is renamed to BoxedFloat64, then a new Float is introduced, then
>>>>>> BoxedFloat64 made to inherit from it.  It's likely that the last step of
>>>>>> this script, which replaces the methodClassAssociations in the moved
>>>>>> methods (makes those BoxedFloat64 methods that used to be Float or maybe
>>>>>> vice verse) with the right association, didn't work.
>>>>>>
>>>>>> I don't know how the Pharo 5 image is built.  If it is incremental
>>>>>> then just write a script to fix the associations.  But if the image is
>>>>>> produced by a bootstrap you'll need to track down the script that creates
>>>>>> the revised Float hierarchy and fix it to work properly in Pharo.
>>>>>>
>>>>>> _,,,^..^,,,_ (phone)
>>>>>>
>>>>>
>>>>> Thanks Eliot,
>>>>>
>>>>> The methods for c lass Float and BoxedFloat are looking fine. Whats
>>>>> wrong is, that some other methods referring to class Float in there source,
>>>>> now having
>>>>> BoxedFloat in its compiled method literal array,
>>>>> #BoxedFloat64->BoxedFloat64 instead of #Float->Float.
>>>>>
>>>>> But it looks like recompiling the whole image fixes this.
>>>>>
>>>>> nicolai
>>>>>
>>>>
>>>>
>>>> Would it makes sense if
>>>> BoxedFloat64 species returns Float ?
>>>>
>>>
>>> This is because I am about to fix some failing tests in pharo.
>>> Tests like
>>>
>>> self assert: result class = Float
>>> can be replaced by
>>>
>>> self assert: result isFloat
>>>
>>>
>> Yes good.
>>
>>
>>> But for tests like
>>>
>>> self assert: resultClass = Float
>>> I don't want to write
>>> self assert: resultClass = BoxedFloat64
>>>
>>
>>
>> What's this test about???
>> Is it for testing that extreme exponent (very big and very small Float)
>> cannot be represented by an immediate float?
>>
>>
>>>
>>> and looking for an easy way to check if the result class is "like" Float
>>>
>>> self assert: resultClass species = Float species ?
>>> self assert: resultClass isFloatClass ?
>>> self assert: resultClass new isFloat ?
>>>
>>>
>> No because not all floats will be represented as a BoxedFloat64
>> Some will be represented by an immediate float (it depends both on VM
>> Spur-64 bits/ and float range)
>>
>> any ideas
>>>
>>>
>> Not without the intention of the test...
>>
>
> One failing test is about completion and the "context" for searching
> possible completions for messages, for example
>
> #(1 2 3) anMessage...
>
> would recognize #(1 2 3) as an array and search completions starting with
> "anMessage" in class (and superclasses) of Array
>
> 2r1.1e2 anMessage
> would recognize "2r1.1e2" as a Float, but this test now fails because the
> class for the literal 2r1.1e2 is not Float but BoxedFloat64.
> As I consider BoxedFloat64 as an implementation detail, I would like to
> make this test independent of the actual Float class and
> just make an assert that the context class, is "like a " Float. (The
> completion menu would still show BoxedFloat64, but thats ok)
>
> The second test  is
> tally := MessageTally
>                 tallySendsTo: nil
>                 inBlock:  [ 3.14159 printString ]
>                 showTree: true
>                 closeAfter: false
>                 openResultWindow: false
>
> self assert: (tally receivers second theClass == Float).
>
> which is now BoxedFloat64 instead of Float
>
>
>
For these usages, testing class = BoxedFloat64 will fail in a 64 bit Spur
But isFloat sounds OK for me.
Because if it quakes like a Float...

All Float subclasses should support the same public API.

If you fear a fake isFloat (defensive programming?) then you could
eventually test superclass = Float, but it's more fragile than isFloat
(your test is entering into the implementation details).


>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> On Feb 18, 2016, at 2:47 AM, Nicolai Hess <nicolaihess at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> Because we have compiled methods with BoxedFloat64 associations in the
>>>>>> methods literals, but the source code still shows only "Float".
>>>>>>
>>>>>> 17638
>>>>>> <https://pharo.fogbugz.com/f/cases/17638/Browsing-calls-on-BoxedFloat64-shows-methods-with-reference-to-BoxedFloat64-in-the-code>
>>>>>> Browsing calls on BoxedFloat64 shows methods with reference to BoxedFloat64
>>>>>> in the code
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160224/e6ddfa2a/attachment-0001.htm