Smalltalk › Pharo › Pharo Smalltalk Developers

How was BoxedFloat64 integrated into the image ?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Nicolai Hess-3-2

How was BoxedFloat64 integrated into the image ?

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

Nicolas Cellier

Re: How was BoxedFloat64 integrated into the image ?

Beware, most client code should only refer to the visible façade Float and its API.
BoxedFloat64 is an implementation detail and is VM dependent.

We don't want client code to be VM dependent, do we?

I hope those references to BoxedFloat64 are rare.

2016-02-18 11:47 GMT+01:00 Nicolai Hess <[hidden email]>:

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

Ben Coman

Re: How was BoxedFloat64 integrated into the image ?

On Thu, Feb 18, 2016 at 8:52 PM, Nicolas Cellier
<[hidden email]> wrote:
> Beware, most client code should only refer to the visible façade Float and
> its API.
> BoxedFloat64 is an implementation detail and is VM dependent.
> We don't want client code to be VM dependent, do we?
> I hope those references to BoxedFloat64 are rare.

Should there be a Quality Assistant rule for this?
cheers -ben

>
> 2016-02-18 11:47 GMT+01:00 Nicolai Hess <[hidden email]>:
>>
>> 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
>>
>>
>>
>

Uko2

Re: How was BoxedFloat64 integrated into the image ?

Hi, I can add it, but can you give me a bit of context? Are we talking about references to BoxedFloat64 class?

Cheers.
Uko

> On 18 Feb 2016, at 13:55, Ben Coman <[hidden email]> wrote:
>
> On Thu, Feb 18, 2016 at 8:52 PM, Nicolas Cellier
> <[hidden email]> wrote:
>> Beware, most client code should only refer to the visible façade Float and
>> its API.
>> BoxedFloat64 is an implementation detail and is VM dependent.
>> We don't want client code to be VM dependent, do we?
>> I hope those references to BoxedFloat64 are rare.
>
> Should there be a Quality Assistant rule for this?
> cheers -ben
>
>>
>> 2016-02-18 11:47 GMT+01:00 Nicolai Hess <[hidden email]>:
>>>
>>> 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
>>>
>>>
>>>
>>
>

wernerk

Re: How was BoxedFloat64 integrated into the image ?

In reply to this post by Nicolas Cellier

<quote author="Nicolas Cellier">
Beware, most client code should only refer to the visible façade Float and
its API.
BoxedFloat64 is an implementation detail and is VM dependent.
We don't want client code to be VM dependent, do we?
I hope those references to BoxedFloat64 are rare.

Hi Nicolas,
Of course i agree that making client code dependent on the vm is a bad idea and generally i agree with everything you said. but i do have some experience with using BoxedFloat64 and this experience showed me that relying simply on Float occasionaly just is not posssible (that 'implementation detail' does have an effect on one of my programs). i for one would appreciate it, if BoxedFloat64 would _not_ be hidden behind Float in the source code.
werner

Eliot Miranda-2

Re: How was BoxedFloat64 integrated into the image ?

In reply to this post by Nicolai Hess-3-2

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)

On Feb 18, 2016, at 2:47 AM, Nicolai Hess <[hidden email]> 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

Nicolai Hess-3-2

Re: How was BoxedFloat64 integrated into the image ?

2016-02-23 3:55 GMT+01:00 Eliot Miranda <[hidden email]>:

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

On Feb 18, 2016, at 2:47 AM, Nicolai Hess <[hidden email]> 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

Nicolai Hess-3-2

Re: How was BoxedFloat64 integrated into the image ?

2016-02-23 8:48 GMT+01:00 Nicolai Hess <[hidden email]>:

2016-02-23 3:55 GMT+01:00 Eliot Miranda <[hidden email]>:
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 ?

On Feb 18, 2016, at 2:47 AM, Nicolai Hess <[hidden email]> 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

Nicolai Hess-3-2

Re: How was BoxedFloat64 integrated into the image ?

2016-02-24 9:31 GMT+01:00 Nicolai Hess <[hidden email]>:

2016-02-23 8:48 GMT+01:00 Nicolai Hess <[hidden email]>:

2016-02-23 3:55 GMT+01:00 Eliot Miranda <[hidden email]>:
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

But for tests like

self assert: resultClass = Float

I don't want to write

self assert: resultClass = BoxedFloat64

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 ?

any ideas

On Feb 18, 2016, at 2:47 AM, Nicolai Hess <[hidden email]> 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