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

[Nicolai Hess]

2016-02-23 3:55 GMT+01:00 Eliot Miranda :

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

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

[Eliot Miranda]

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

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

[wernerk]

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



--
View this message in context: 
http://forum.world.st/How-was-BoxedFloat64-integrated-into-the-image-tp4878411p4879438.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

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

[Yuriy Tymchuk]

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  wrote:
> 
> On Thu, Feb 18, 2016 at 8:52 PM, Nicolas Cellier
>  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 :
>>> 
>>> 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
>>> 
>>> 
>>> 
>> 
> 

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

[Ben Coman]

On Thu, Feb 18, 2016 at 8:52 PM, Nicolas Cellier
 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 :
>>
>> 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
>>
>>
>>
>

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

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

2016-02-18 11:47 GMT+01:00 Nicolai Hess :

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

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

[Nicolai Hess]

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