Given the age of new implementation, reversion consequences should be low.<br>I'd say please update Scanner>>xIllegal accordingly (otherwise 16r is displayed twice)<br> <br>There is also a bit of history in the tracker<br>
<a href="http://bugs.squeak.org/view.php?id=6441">http://bugs.squeak.org/view.php?id=6441</a><br><a href="http://bugs.squeak.org/view.php?id=6339">http://bugs.squeak.org/view.php?id=6339</a><br><a href="http://bugs.squeak.org/view.php?id=6558">http://bugs.squeak.org/view.php?id=6558</a><br>
<a href="http://bugs.squeak.org/view.php?id=987">http://bugs.squeak.org/view.php?id=987</a><br><br>The 3 other implementors don't print any 16r, was it the motivation of new hex implementation?<br>Anyway, hex is not that important, I doubt much squeakers will care.<br>
<br>What is more interesting is how to proceed with future changes, because some have to break compatibility.<br>I think it would be good to have a tracker logging<br>- a list of uncompatible changes<br>- a good rationale justifying the change<br>
- some guidelines for porting old packages (eventually automated RB rewrite rules?)<br>If some change is rejected or reverted, it is good to have the rationale logged too<br>(a link to mailing list thread is the least thing to do).<br>
<br>It is not really clear to me yet how the final decision is taken in case of disagreement.<br>For example, I forced the selectors change (answering an Array rather than a Set) despite negative advices from Bert and Eliot.<br>
Andreas forced the 16r3e0 (lowercase hex) change despite having a minority of support.<br>Jerome failed to impose his sound extension.<br><br>We don't need to define the decision process now, as long as trunk process is going smoothly...<br>
<br>But a track of changes is important to any one wishing to update production images, isn't it?<br><br>Nicolas<br><br><div class="gmail_quote">2010/7/18 Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Thanks for the history. My vote is for restoring the original behavior of #hex and document it via tests.<br>
<br>
Cheers,<br><font color="#888888">
- Andreas</font><div><div></div><div class="h5"><br>
<br>
On 7/17/2010 3:03 PM, Levente Uzonyi wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Sat, 17 Jul 2010, Eliot Miranda wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi All,<br>
<br>
in creating the Cog VMMaker image from Squeak 4.1 that is in the svn<br>
tree for Cog (<a href="http://www.squeakvm.org/svn/squeak/branches/Cog" target="_blank">http://www.squeakvm.org/svn/squeak/branches/Cog</a>) I had to<br>
revert a change made to Integer>>hex. I don't want to point fingers<br>
but it<br>
was IMO an unnecessary change; one can always add a new selector if one<br>
wants new behaviour and existing code (in this case VMMaker) depended<br>
on the<br>
old behaviour. BTW, the difference is that originally Integer>>hex (&<br>
Integer>>hex8) prefixed their hex output with the base so that 123 hex is<br>
'16r7B' and 123 hex8 '16r0000007B', whereas the new semantics omits the<br>
prefix so that 123 hex is '7B'. The old semantics is depended on by<br>
various<br>
tests as well it providing the convenience of being able to select and<br>
print<br>
the result. I would like to revert the behavior, essentially because<br>
a) one<br>
should not unnecessarily break backwards-compatibility and b) Cog is<br>
potentially useful to a lot of the community. So views for or against? Or<br>
should I make it, gack, a VMMaker override (gack, please nooooo)?<br>
</blockquote>
<br>
The story of #hex is a bit more complicated. It was deprecated in 3.8,<br>
removed in 3.9 and was reintroduced in 3.10 with different semantics.<br>
The last decision was definitely bad. But what about the removal? Why<br>
was it removed in 3.9? The idea was to use #printStringHex and<br>
#storeStringHex instead of #hex. The problem with the removal was that<br>
it wasn't done properly. There were senders of the removed #hex method<br>
in the 3.9 image and the external packages weren't updated.<br>
<br>
If we want to follow the decision of removing #hex from the image, then<br>
#hex should be an extension method in VMMaker or #storeStringHex should<br>
be used (yeah, it's a long name).<br>
If we want to keep #hex in the image, then I think we should restore the<br>
original semantics.<br>
<br>
<br>
Levente<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
best<br>
Eliot<br>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br>