On Wed, Jul 21, 2010 at 9:59 AM, St�phane Ducasse
<stephane.ducasse@inria.fr> wrote:
On Jul 21, 2010, at 6:49 PM, Nicolas Cellier wrote:
> I don't think Eliot changed that, he only changed Integer>>hex...
No he did
http://code.google.com/p/pharo/issues/detail?id=2705
Item was changed:
�----- Method: Character>>hex (in category 'printing') -----
�hex
+ � � � ^value printStringBase: 16!
- � � � ^value hex!
and that is a mistake. �It should stay the way it was and then Character hex would also have the 16r prefix.
But I'm caught between two stools, whether to move forward and make Character hex answer 16rXX or to move back and make Integer hex answer XX, and e.g. use phex for 16r... �Our��Teleplace images make heavy use of hex and assume it answers 16rXX so if we don't keep the 16r prefix I'll have to maintain a fork of the Cog VMMaker and that would make life even more difficult (I already have three forks, open-source Cog, production Teleplace and development Teleplace (threaded & separate ObjectMemory and Interpreter) but they all agree w.r.t. hex.
If you think adding the prefix to Character won't do too much harm then revert the change above so Character hex reads (as it does in our Teleplace images)
Character hex
�� �^value hex
> It seems that every implementation of hex did avoid to print the radix in Squeak 3.10. Was it intentional ?
>
> Anyway, it will be hard to reach homogeneity because:
> � Integer>>hex should print the radix for VMMaker compatibility
> � ByteArray>>hex shouldn't for cypto compatibility
but crypto could use printStringHex so yes we can reach it.