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

Nicolai Hess nicolaihess at gmail.com
Wed Feb 24 11:28:07 UTC 2016


2016-02-24 12:04 GMT+01:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

>
>
>
> 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).
>

So, you mean, put isFloat on the class side of BoxedFloat64 (and
SmallFloat64)? Or maybe isFloatClass ?



>
>
>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 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/6b4dc910/attachment.htm


More information about the Vm-dev mailing list