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

[Nicolas Cellier]

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



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