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

Wed Feb 24 17:08:25 UTC 2016

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:

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