<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-02-23 8:48 GMT+01:00 Nicolai Hess <span dir="ltr">&lt;<a href="mailto:nicolaihess@gmail.com" target="_blank">nicolaihess@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2016-02-23 3:55 GMT+01:00 Eliot Miranda <span dir="ltr">&lt;<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>Hi Nicolai,</div><div><br></div><div>    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&#39;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&#39;t work.  </div><div><br></div><div>I don&#39;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&#39;ll need to track down the script that creates the revised Float hierarchy and fix it to work properly in Pharo.<br><br><span style="background-color:rgba(255,255,255,0)">_,,,^..^,,,_ (phone)</span></div></div></blockquote><div><br></div></span><div>Thanks Eliot,<br><br></div><div>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<br></div><div>BoxedFloat in its compiled method literal array, <br>#BoxedFloat64-&gt;BoxedFloat64 instead of #Float-&gt;Float.<br><br></div><div>But it looks like recompiling the whole image fixes this.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>nicolai<br></div></font></span></div></div></div></blockquote><div><br><br></div><div>Would it makes sense if <br></div><div>BoxedFloat64 species returns Float ?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div></div></font></span><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div><div><br>On Feb 18, 2016, at 2:47 AM, Nicolai Hess &lt;<a href="mailto:nicolaihess@gmail.com" target="_blank">nicolaihess@gmail.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>Because we have compiled methods with BoxedFloat64 associations in the<br></div>methods literals, but the source code still shows only &quot;Float&quot;.<br><br><a href="https://pharo.fogbugz.com/f/cases/17638/Browsing-calls-on-BoxedFloat64-shows-methods-with-reference-to-BoxedFloat64-in-the-code" target="_blank">17638</a> Browsing calls on BoxedFloat64 shows methods with reference to BoxedFloat64 in the code<br><br><br><br></div>
</div></blockquote></div></div></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>