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

2016-02-24 10:02 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:

2016-02-24 9:31 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:

2016-02-23 8:48 GMT+01:00 Nicolai Hess <nicolaihess@gmail.com>:

2016-02-23 3:55 GMT+01:00 Eliot Miranda <eliot.miranda@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

On Feb 18, 2016, at 2:47 AM, Nicolai Hess <nicolaihess@gmail.com> wrote:

Because we have compiled methods with BoxedFloat64 associations in the
methods literals, but the source code still shows only "Float".

17638 Browsing calls on BoxedFloat64 shows methods with reference to BoxedFloat64 in the code