On Wed, Jul 21, 2010 at 9:59 AM, Stéphane Ducasse stephane.duca...@inria.fr
wrote:
On Jul 21, 2010, at 6:49 PM, Nicolas Cellier wrote:
I don't think Eliot changed that, he only changed Integerhex...
No he did
http://code.google.com/p/pharo/issues/detail?id=2705
Item was changed:
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 Integerhex...
No he did
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
I don't think Eliot changed that, he only changed Integerhex...
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:
Integerhex should print the radix for VMMaker compatibility
On Wed, 21 Jul 2010, Nicolas Cellier wrote:
I don't think Eliot changed that, he only changed Integerhex...
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
On Jul 21, 2010, at 6:49 PM, Nicolas Cellier wrote:
I don't think Eliot changed that, he only changed Integerhex...
No he did
http://code.google.com/p/pharo/issues/detail?id=2705
Item was changed:
- Method: Characterhex (in category 'printing') -
hex
+ ^value printStringBase:
This is not the answer to my question.
I talked about characterhex, please reread my mail.
Stef
On Wed, 21 Jul 2010, Nicolas Cellier wrote:
I don't think Eliot changed that, he only changed Integerhex...
He didn't change it compared to the previous implementation, but he didn't
On Wed, 21 Jul 2010, Stéphane Ducasse wrote:
This is not the answer to my question.
I talked about characterhex, 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
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 Characterhex and
Integerhex
not about whether the behavior changed.
For Character #hex :
In
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
On Tue, Jul 20, 2010 at 2:46 AM, Henrik Johansen
henrik.s.johan...@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,
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,
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
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
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
Levente
Now whathex 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
On Mon, 19 Jul 2010, Stéphane Ducasse wrote:
Levente
Now whathex 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
**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:
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.duca...@inria.fr:
**Tx**
19 matches
Mail list logo
