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