2016-02-24 18:08 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2016-02-24 17:18 GMT+01:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Nicolai,
On Wed, Feb 24, 2016 at 3:28 AM, Nicolai Hess nicolaihess@gmail.com wrote:
2016-02-24 12:04 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
2016-02-24 11:15 GMT+01:00 Nicolai Hess nicolaihess@gmail.com:
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
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@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