[Pharo-project] about hex
If I recall hex was removed because it was used for html related thing. Stef Looks like the hex method will be changed in Squeak and we should keep track using this issue to see if Pharo has to follow to keep compatible (also for Cog). See http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151949.html
Levente Now what hex should returns? On Jul 19, 2010, at 9:33 PM, stephane ducasse wrote:
If I recall hex was removed because it was used for html related thing.
Stef
Looks like the hex method will be changed in Squeak and we should keep track using this issue to see if Pharo has to follow to keep compatible (also for Cog).
See
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151949.html
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 19 Jul 2010, Stéphane Ducasse wrote:
Levente Now what hex should returns?
If you mean Integer >> #hex then see here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151957.html Levente
On Jul 19, 2010, at 9:33 PM, stephane ducasse wrote:
If I recall hex was removed because it was used for html related thing.
Stef
Looks like the hex method will be changed in Squeak and we should keep track using this issue to see if Pharo has to follow to keep compatible (also for Cog).
See
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151949.html
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
**Tx** http://code.google.com/p/pharo/issues/detail?id=2699 Stef On Jul 19, 2010, at 10:07 PM, Levente Uzonyi wrote:
On Mon, 19 Jul 2010, Stéphane Ducasse wrote:
Levente Now what hex should returns?
If you mean Integer >> #hex then see here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151957.html
Levente
On Jul 19, 2010, at 9:33 PM, stephane ducasse wrote:
If I recall hex was removed because it was used for html related thing.
Stef
Looks like the hex method will be changed in Squeak and we should keep track using this issue to see if Pharo has to follow to keep compatible (also for Cog).
See
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151949.html
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Iirc, it was reintroduced in Pharo in relation to SqueakDBX, might want to check with Mariano that changes will be compatible/SqueakDBX is updated. Cheers, Henry Den 19. juli 2010 kl. 23:05 skrev Stéphane Ducasse <stephane.ducasse@inria.fr>:
**Tx** http://code.google.com/p/pharo/issues/detail?id=2699
Stef
On Jul 19, 2010, at 10:07 PM, Levente Uzonyi wrote:
On Mon, 19 Jul 2010, Stéphane Ducasse wrote:
Levente Now what hex should returns?
If you mean Integer >> #hex then see here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151957.html
Levente
On Jul 19, 2010, at 9:33 PM, stephane ducasse wrote:
If I recall hex was removed because it was used for html related thing.
Stef
Looks like the hex method will be changed in Squeak and we should keep track using this issue to see if Pharo has to follow to keep compatible (also for Cog).
See
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151949.html
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
thanks! Stef On Jul 20, 2010, at 2:46 AM, Henrik Johansen wrote:
Iirc, it was reintroduced in Pharo in relation to SqueakDBX, might want to check with Mariano that changes will be compatible/SqueakDBX is updated.
Cheers, Henry
Den 19. juli 2010 kl. 23:05 skrev Stéphane Ducasse <stephane.ducasse@inria.fr>:
**Tx** http://code.google.com/p/pharo/issues/detail?id=2699
Stef
On Jul 19, 2010, at 10:07 PM, Levente Uzonyi wrote:
On Mon, 19 Jul 2010, Stéphane Ducasse wrote:
Levente Now what hex should returns?
If you mean Integer >> #hex then see here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151957.html
Levente
On Jul 19, 2010, at 9:33 PM, stephane ducasse wrote:
If I recall hex was removed because it was used for html related thing.
Stef
Looks like the hex method will be changed in Squeak and we should keep track using this issue to see if Pharo has to follow to keep compatible (also for Cog).
See
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151949.html
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, Jul 20, 2010 at 2:46 AM, Henrik Johansen < henrik.s.johansen@veloxit.no> wrote:
Iirc, it was reintroduced in Pharo in relation to SqueakDBX, might want to check with Mariano that changes will be compatible/SqueakDBX is updated.
Hi Henrik. Indeed, it was included for SqueakDBX. Actually, not for itself, but the NATIVE postgresql driver used to depends in the chripto package. Then, the MD5 class was put in PharoCore so it didn't depend anymore. But the hex was missing. Now...if you ask me if this change will affect the postgres native driver, I HAVE NO IDEA. The only thing I can do is to run the tests. But for that I need a postgres with encrypthion running handly. Do you know Yanni? Cheers Mariano
Cheers, Henry
Den 19. juli 2010 kl. 23:05 skrev Stéphane Ducasse < stephane.ducasse@inria.fr>:
**Tx** http://code.google.com/p/pharo/issues/detail?id=2699
Stef
On Jul 19, 2010, at 10:07 PM, Levente Uzonyi wrote:
On Mon, 19 Jul 2010, Stéphane Ducasse wrote:
Levente Now what hex should returns?
If you mean Integer >> #hex then see here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151957.html
Levente
On Jul 19, 2010, at 9:33 PM, stephane ducasse wrote:
If I recall hex was removed because it was used for html related
thing.
Stef
Looks like the hex method will be changed in Squeak and we should keep track using this issue to see if Pharo has to follow to keep compatible (also for Cog).
See
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/151949.html
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Originally, the NATIVE postgresql driver was (somewhat?) ANSI ST incompatible. I had it working in VAST. Along the way, the Cryptography package was added as a dependency to support MD5 passwords. If #hex is not ANSI ST, then the postgres native driver is likely unaffected by changes to #hex, other than its effect on MD5. I can verify this later today. -- Yanni Mariano Martinez Peck wrote:
On Tue, Jul 20, 2010 at 2:46 AM, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote:
Iirc, it was reintroduced in Pharo in relation to SqueakDBX, might want to check with Mariano that changes will be compatible/SqueakDBX is updated.
Hi Henrik. Indeed, it was included for SqueakDBX. Actually, not for itself, but the NATIVE postgresql driver used to depends in the chripto package. Then, the MD5 class was put in PharoCore so it didn't depend anymore. But the hex was missing. Now...if you ask me if this change will affect the postgres native driver, I HAVE NO IDEA. The only thing I can do is to run the tests. But for that I need a postgres with encrypthion running handly.
Do you know Yanni?
Cheers
Mariano
tx! I was thinking that we could keep old hex as hexDigits Stef On Jul 20, 2010, at 4:42 PM, Yanni Chiu wrote:
Originally, the NATIVE postgresql driver was (somewhat?) ANSI ST incompatible. I had it working in VAST. Along the way, the Cryptography package was added as a dependency to support MD5 passwords.
If #hex is not ANSI ST, then the postgres native driver is likely unaffected by changes to #hex, other than its effect on MD5. I can verify this later today.
-- Yanni
Mariano Martinez Peck wrote:
On Tue, Jul 20, 2010 at 2:46 AM, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: Iirc, it was reintroduced in Pharo in relation to SqueakDBX, might want to check with Mariano that changes will be compatible/SqueakDBX is updated. Hi Henrik. Indeed, it was included for SqueakDBX. Actually, not for itself, but the NATIVE postgresql driver used to depends in the chripto package. Then, the MD5 class was put in PharoCore so it didn't depend anymore. But the hex was missing. Now...if you ask me if this change will affect the postgres native driver, I HAVE NO IDEA. The only thing I can do is to run the tests. But for that I need a postgres with encrypthion running handly. Do you know Yanni? Cheers Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, 20 Jul 2010, Yanni Chiu wrote:
Originally, the NATIVE postgresql driver was (somewhat?) ANSI ST incompatible. I had it working in VAST. Along the way, the Cryptography package was added as a dependency to support MD5 passwords.
If #hex is not ANSI ST, then the postgres native driver is likely unaffected by changes to #hex, other than its effect on MD5. I can verify this later today.
It's a totally different #hex. The original issue is about Integer >> #hex. PostgresV2 uses ByteArray >> #hex which is in the Cryptography package and is independent of Integer >> #hex. Levente
-- Yanni
Mariano Martinez Peck wrote:
On Tue, Jul 20, 2010 at 2:46 AM, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote:
Iirc, it was reintroduced in Pharo in relation to SqueakDBX, might want to check with Mariano that changes will be compatible/SqueakDBX is updated.
Hi Henrik. Indeed, it was included for SqueakDBX. Actually, not for itself, but the NATIVE postgresql driver used to depends in the chripto package. Then, the MD5 class was put in PharoCore so it didn't depend anymore. But the hex was missing. Now...if you ask me if this change will affect the postgres native driver, I HAVE NO IDEA. The only thing I can do is to run the tests. But for that I need a postgres with encrypthion running handly.
Do you know Yanni?
Cheers
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Levente /Eliot I noticed that $A hex on squeak -> 41 and in pharo -> '16r41' I would like to have both consistent what do you think to have $A hex -> '16r41' $A printStringHex -> '41' like that this is consistent with the behavior on integer. Eliot I saw that to change the behavior on characters and I would like to know why. I thought that it was for debugging purpose. Stef
I don't think Eliot changed that, he only changed Integer>>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 Nicolas 2010/7/21 Stéphane Ducasse <stephane.ducasse@inria.fr>
Levente /Eliot
I noticed that
$A hex on squeak -> 41 and in pharo -> '16r41'
I would like to have both consistent what do you think to have
$A hex -> '16r41'
$A printStringHex -> '41'
like that this is consistent with the behavior on integer. Eliot I saw that to change the behavior on characters and I would like to know why. I thought that it was for debugging purpose.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, 21 Jul 2010, Nicolas Cellier wrote:
I don't think Eliot changed that, he only changed Integer>>hex...
He didn't change it compared to the previous implementation, but he didn't restore the pre 3.9 state.
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
ByteArray >> #hex is in the Cryptography package, and IMHO it should stay there. Levente
Nicolas
2010/7/21 Stéphane Ducasse <stephane.ducasse@inria.fr>
Levente /Eliot
I noticed that
$A hex on squeak -> 41 and in pharo -> '16r41'
I would like to have both consistent what do you think to have
$A hex -> '16r41'
$A printStringHex -> '41'
like that this is consistent with the behavior on integer. Eliot I saw that to change the behavior on characters and I would like to know why. I thought that it was for debugging purpose.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
This is not the answer to my question. I talked about character>>hex, please reread my mail. Stef
On Wed, 21 Jul 2010, Nicolas Cellier wrote:
I don't think Eliot changed that, he only changed Integer>>hex...
He didn't change it compared to the previous implementation, but he didn't restore the pre 3.9 state.
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
ByteArray >> #hex is in the Cryptography package, and IMHO it should stay there.
Levente
Nicolas
2010/7/21 Stéphane Ducasse <stephane.ducasse@inria.fr>
Levente /Eliot
I noticed that
$A hex on squeak -> 41 and in pharo -> '16r41'
I would like to have both consistent what do you think to have
$A hex -> '16r41'
$A printStringHex -> '41'
like that this is consistent with the behavior on integer. Eliot I saw that to change the behavior on characters and I would like to know why. I thought that it was for debugging purpose.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, 21 Jul 2010, Stéphane Ducasse wrote:
This is not the answer to my question. I talked about character>>hex, please reread my mail.
Well, it is. :) For Character >> #hex : In Squeak 3.8: $a hex -> '16r61' In Squeak 3.9: $a hex -> MNU SmallInteger >> #hex In Squeak 3.10: $a hex -> '61' In Squeak 4.0: $a hex -> '61' In Squeak 4.1: $a hex -> '61' In Squeak 4.2-alpha: $a hex -> '61' For Integer >> #hex : In Squeak 3.8: 97 hex -> '16r61' In Squeak 3.9: 97 hex -> MNU SmallInteger >> #hex In Squeak 3.10: 97 hex -> '61' In Squeak 4.0: 97 hex -> '61' In Squeak 4.1: 97 hex -> '61' In Squeak 4.2-alpha: 97 hex -> '16r61' So Character >> #hex returns the same in Squeak 4.1 and 4.2, while Integer >> #hex doesn't. Levente
Stef
On Wed, 21 Jul 2010, Nicolas Cellier wrote:
I don't think Eliot changed that, he only changed Integer>>hex...
He didn't change it compared to the previous implementation, but he didn't restore the pre 3.9 state.
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
ByteArray >> #hex is in the Cryptography package, and IMHO it should stay there.
Levente
Nicolas
2010/7/21 Stéphane Ducasse <stephane.ducasse@inria.fr>
Levente /Eliot
I noticed that
$A hex on squeak -> 41 and in pharo -> '16r41'
I would like to have both consistent what do you think to have
$A hex -> '16r41'
$A printStringHex -> '41'
like that this is consistent with the behavior on integer. Eliot I saw that to change the behavior on characters and I would like to know why. I thought that it was for debugging purpose.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks Cool analysis now my point is that it would make sense to have hex always returning 16rXX and printStringHex XX Stef
Well, it is. :)
My question is about having a consistent API accross Character>>hex and Integer>>hex not about whether the behavior changed.
For Character >> #hex : In Squeak 3.8: $a hex -> '16r61' In Squeak 3.9: $a hex -> MNU SmallInteger >> #hex In Squeak 3.10: $a hex -> '61' In Squeak 4.0: $a hex -> '61' In Squeak 4.1: $a hex -> '61' In Squeak 4.2-alpha: $a hex -> '61'
I got confused because since Character did a simple value hex and hex got changed when I reverted I captured the new behavior Still my question is valid.
$a hex -> '16r61'
In Squeak 4.1: 97 hex -> '61' In Squeak 4.2-alpha: 97 hex -> '16r61'
So Character >> #hex returns the same in Squeak 4.1 and 4.2, while Integer >> #hex doesn't.
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!
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.
Nicolas
2010/7/21 Stéphane Ducasse <stephane.ducasse@inria.fr> Levente /Eliot
I noticed that
$A hex on squeak -> 41 and in pharo -> '16r41'
I would like to have both consistent what do you think to have
$A hex -> '16r41'
$A printStringHex -> '41'
like that this is consistent with the behavior on integer. Eliot I saw that to change the behavior on characters and I would like to know why. I thought that it was for debugging purpose.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
Nicolas
2010/7/21 Stéphane Ducasse <stephane.ducasse@inria.fr> Levente /Eliot
I noticed that
$A hex on squeak -> 41 and in pharo -> '16r41'
I would like to have both consistent what do you think to have
$A hex -> '16r41'
$A printStringHex -> '41'
like that this is consistent with the behavior on integer. Eliot I saw that to change the behavior on characters and I would like to
know why.
I thought that it was for debugging purpose.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks eliot I was thinking that having the same consistent behavior is cool. What we could do is snapshot, for example, we say that Cog will only for 1.2Pharo and like that this may help you.
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.
ok I thought you had a specific need. So now I understand :)
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...
I like 16r for hex and printStringHex for XX
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.
For me this is good I like hex 16rXX but I would like Character hex to be consistent.
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
I really suggest that we (pharo and squeak) do that $A hex '16r41' and we can add printString hex to character Character>>printStringHex ^value printStringBase: 16 Stef
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.
Nicolas
2010/7/21 Stéphane Ducasse <stephane.ducasse@inria.fr> Levente /Eliot
I noticed that
$A hex on squeak -> 41 and in pharo -> '16r41'
I would like to have both consistent what do you think to have
$A hex -> '16r41'
$A printStringHex -> '41'
like that this is consistent with the behavior on integer. Eliot I saw that to change the behavior on characters and I would like to know why. I thought that it was for debugging purpose.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (8)
-
Eliot Miranda -
Henrik Johansen -
Levente Uzonyi -
Mariano Martinez Peck -
Nicolas Cellier -
stephane ducasse -
Stéphane Ducasse -
Yanni Chiu