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.

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.

On Sat, Jul 17, 2010 at 2:21 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

> Hi All,
>
>     in creating the Cog VMMaker image from Squeak 4.1 that is in the svn
> tree for Cog (http://www.squeakvm.org/svn/squeak/branches/Cog) 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)?
>
> best
> Eliot
>
>
>
>


-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100717/55907f1f/attachment.htm