[Vm-dev] Re: [Pharo-dev] How was BoxedFloat64 integrated into the
image ?
Nicolai Hess
nicolaihess at gmail.com
Wed Feb 24 20:16:07 UTC 2016
2016-02-24 18:08 GMT+01:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:
>
>
>
> 2016-02-24 17:18 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:
>
>>
>> Hi Nicolai,
>>
>> On Wed, Feb 24, 2016 at 3:28 AM, Nicolai Hess <nicolaihess at gmail.com>
>> wrote:
>>
>>>
>>>
>>>
>>> 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 ?
>>>
>>
>> I would write either
>>
>> self assert: ({Float. BoxedFloat64. SmallFloat64 } includes: tally
>> receivers second theClass)
>>
>> or
>>
>> self assert: (tally receivers second theClass includesBehavior: Float)
>>
>> I much prefer the second.
>>
>> I don't like isFloatClass just for a test. Introducing protocol just for
>> tests is suspect.
>>
>
> Yes, I was thinking to send isFloat to the instance and let the class
> alone.
> If you really want to assert the class, then all you can safely/portably
> test is the class hierarchy as I tried to tell with superclass, but as
> Eliot much more accurately expressed with includesBehavior:
>
Thanks Eliot and Nicolas,
Yes this sounds good!
>
>
>
>>
>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160224/129045f4/attachment.htm
More information about the Vm-dev
mailing list