VMMaker override? Yeesh. So it's a prim then? I say, revert it; Cogit ergo go-fast is worth breaking a few packages when I'm trying to convince my boss to let me solve problems in Smalltalk.<div><br></div><div>Can we just add a (not primitive) method #terseHex that uses the old #hex mechanism, and strips off the base and leading zeroes? That would at least give folks depending on it a quick fix for any breakage that might occur.<br>
<br><div class="gmail_quote">On Sat, Jul 17, 2010 at 2:21 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi All,<div><br></div><div> in creating the Cog VMMaker image from Squeak 4.1 that is in the svn 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 revert a change made to Integer>>hex. I don't want to point fingers but it was IMO an unnecessary change; one can always add a new selector if one wants new behaviour and existing code (in this case VMMaker) depended on the old behaviour. BTW, the difference is that originally Integer>>hex (& Integer>>hex8) prefixed their hex output with the base so that 123 hex is '16r7B' and 123 hex8 '16r0000007B', whereas the new semantics omits the prefix so that 123 hex is '7B'. The old semantics is depended on by various tests as well it providing the convenience of being able to select and print the result. I would like to revert the behavior, essentially because a) one should not unnecessarily break backwards-compatibility and b) Cog is potentially useful to a lot of the community. So views for or against? Or should I make it, gack, a VMMaker override (gack, please nooooo)?</div>
<div><br></div><div>best</div><div>Eliot</div>
<br><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Casey Ransberger<br>
</div>