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

[Eliot Miranda]

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.


>>>>>>>> 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/55268f29/attachment-0001.htm