Smalltalk › Squeak › Squeak - Dev

Re: [Pharo-project] 16rff is looking for a fix :)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Eliot Miranda-2

Re: [Pharo-project] 16rff is looking for a fix :)

this in the thread spawned by Torsen's posting of Kent's most excellent rant:

ttp://www.threeriversinstitute.org/blog/?p=466

OK, fix is to two implementations of digitValue:. BTW, I haven't fixed Character class>>digitValue: which at least in my Teleplace image looks horribly broken, answering characters not integers. Check your distro, it may also be broken

These fixes attached:

'From Croquet1.0beta of 11 April 2006 [latest update: #1] on 11 February 2010 at 1:17:50 pm'!

!EncodedCharSet class methodsFor: 'class methods' stamp: 'eem 2/11/2010 13:13'!

digitValue: char

"Answer 0-9 if the receiver is $0-$9, 10-35 if it is $A-$Z, and < 0

otherwise. This is used to parse literal numbers of radix 2-36."

| value |

value := char charCode.

value <= $9 asciiValue ifTrue:

[^value - $0 asciiValue].

value >= $A asciiValue ifTrue:

[value <= $Z asciiValue ifTrue: [^value - $A asciiValue + 10].

(value >= $a asciiValue and: [value <= $z asciiValue]) ifTrue:

[^value - $a asciiValue + 10]].

^ -1

! !

!Unicode class methodsFor: 'class methods' stamp: 'eem 2/11/2010 13:17'!

digitValue: char

| value |

value := char charCode.

value <= $9 asciiValue ifTrue:

[^value - $0 asciiValue].

value >= $A asciiValue ifTrue:

[value <= $Z asciiValue ifTrue: [^value - $A asciiValue + 10].

(value >= $a asciiValue and: [value <= $z asciiValue]) ifTrue:

[^value - $a asciiValue + 10]].

value > (DecimalProperty size - 1) ifTrue: [^ -1].

^ (DecimalProperty at: value+1)

! !

2010/2/11 Stéphane Ducasse <[hidden email]>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

digitValue.st (1K) Download Attachment

Stéphane Ducasse

Re: [Pharo-project] 16rff is looking for a fix :)

Thanks

Stef

On Feb 11, 2010, at 10:21 PM, Eliot Miranda wrote:

> this in the thread spawned by Torsen's posting of Kent's most excellent rant:
> ttp://www.threeriversinstitute.org/blog/?p=466
>
> OK, fix is to two implementations of digitValue:. BTW, I haven't fixed Character class>>digitValue: which at least in my Teleplace image looks horribly broken, answering characters not integers. Check your distro, it may also be broken
>
> These fixes attached:
>
> 'From Croquet1.0beta of 11 April 2006 [latest update: #1] on 11 February 2010 at 1:17:50 pm'!
> !EncodedCharSet class methodsFor: 'class methods' stamp: 'eem 2/11/2010 13:13'!
> digitValue: char
> "Answer 0-9 if the receiver is $0-$9, 10-35 if it is $A-$Z, and < 0
> otherwise. This is used to parse literal numbers of radix 2-36."
>
> | value |
> value := char charCode.
> value <= $9 asciiValue ifTrue:
> [^value - $0 asciiValue].
> value >= $A asciiValue ifTrue:
> [value <= $Z asciiValue ifTrue: [^value - $A asciiValue + 10].
> (value >= $a asciiValue and: [value <= $z asciiValue]) ifTrue:
> [^value - $a asciiValue + 10]].
> ^ -1
> ! !
> !Unicode class methodsFor: 'class methods' stamp: 'eem 2/11/2010 13:17'!
> digitValue: char
>
> | value |
> value := char charCode.
> value <= $9 asciiValue ifTrue:
> [^value - $0 asciiValue].
> value >= $A asciiValue ifTrue:
> [value <= $Z asciiValue ifTrue: [^value - $A asciiValue + 10].
> (value >= $a asciiValue and: [value <= $z asciiValue]) ifTrue:
> [^value - $a asciiValue + 10]].
>
> value > (DecimalProperty size - 1) ifTrue: [^ -1].
> ^ (DecimalProperty at: value+1)
> ! !
>
> 2010/2/11 Stéphane Ducasse <[hidden email]>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> <digitValue.st>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Andreas.Raab

Re: [Pharo-project] 16rff is looking for a fix :)

In reply to this post by Eliot Miranda-2

Eliot Miranda wrote:

> this in the thread spawned by Torsen's posting of Kent's most excellent
> rant:
> ttp://www.threeriversinstitute.org/blog/?p=466
> <http://www.threeriversinstitute.org/blog/?p=466>
>
> <http://www.threeriversinstitute.org/blog/?p=466>OK, fix is to two
> implementations of digitValue:. BTW, I haven't fixed Character
> class>>digitValue: which at least in my Teleplace image looks horribly
> broken, answering characters not integers. Check your distro, it may
> also be broken

It's not. It works precisely as advertised (rtfc). What's confusing is
that EncodedCharset and Unicode use the selector #digitValue: when the
selector should be called #digitValueOf: (i.e., returning the digit
value OF a character not creating a new character with a given digit
value in this character set).

Besides, I very much doubt that the change in hex literals (which I'm
very much in favor of btw!) will address Kent's issue. The reality is
that there's no way to address his issues because there's no single
owner of the brand. Balkanization (which is precisely the right term)
happens when you don't have a strong central power which can keep
everyone at bay (such as Yugoslavia did before it fell apart). Java for
example is owned by Sun and Sun went to court with Microsoft to ensure
brand integrity. Unless you have an owner of "Smalltalk" (whatever that
is) there isn't going to be a consistent set of libraries because
everyone can and will push into different directions.

Cheers,
- Andreas

Eliot Miranda-2

Re: [Pharo-project] 16rff is looking for a fix :)

On Thu, Feb 11, 2010 at 2:59 PM, Andreas Raab <[hidden email]> wrote:

Eliot Miranda wrote:

this in the thread spawned by Torsen's posting of Kent's most excellent rant:
ttp://www.threeriversinstitute.org/blog/?p=466 <http://www.threeriversinstitute.org/blog/?p=466>

<http://www.threeriversinstitute.org/blog/?p=466>OK, fix is to two implementations of digitValue:. BTW, I haven't fixed Character class>>digitValue: which at least in my Teleplace image looks horribly broken, answering characters not integers. Check your distro, it may also be broken

It's not. It works precisely as advertised (rtfc). What's confusing is that EncodedCharset and Unicode use the selector #digitValue: when the selector should be called #digitValueOf: (i.e., returning the digit value OF a character not creating a new character with a given digit value in this character set).

Doh!

Besides, I very much doubt that the change in hex literals (which I'm very much in favor of btw!) will address Kent's issue.

I agree. But every little bit helps :)

The reality is that there's no way to address his issues because there's no single owner of the brand. Balkanization (which is precisely the right term) happens when you don't have a strong central power which can keep everyone at bay (such as Yugoslavia did before it fell apart). Java for example is owned by Sun and Sun went to court with Microsoft to ensure brand integrity. Unless you have an owner of "Smalltalk" (whatever that is) there isn't going to be a consistent set of libraries because everyone can and will push into different directions.

I disagree. I think the community has managed to agree on the utility of several things. Many of the Squeak collection extensions have found their way into VisualWorks for example because they're clearly useful and convenient. I think the problem with the standard is architectural, and that that architectural limitation was built-in from the get-go It was intended to be something the vendors could agree upon, not a useful standard. The issue for the vendors was in having a check-box for Smalltalk compared to other languages; C had a standard, C++ had a standard, so Smalltalk needed one. ut the standard wasn't useful for the community, and I think as a result hasn't been that useful for the vendors. Being x3j20-compatible didn't mean enough.

But at the time things were very different. Test suites were not in widespread use and no one had developed one yet. A good thing to come out of x3j20 and the first CampSmalltalk was a test suite. The web was in its infancy; there was no javadoc or www.python.org/doc/. Squeak was very young. So it's not surprising that the standard failed to be that useful. The world changed very quickly soon there-after.

A differently-architected standard could be useful and a gently unifying force. But it needs to address the challenges of standardising Smalltalk as it exists in its current context, not as it was in the early 90's.

Cheers,
- Andreas

Andreas.Raab

Re: [Pharo-project] 16rff is looking for a fix :)

Eliot Miranda wrote:

> I disagree. I think the community has managed to agree on the utility
> of several things. Many of the Squeak collection extensions have found
> their way into VisualWorks for example because they're clearly useful
> and convenient. I think the problem with the standard is architectural,
> and that that architectural limitation was built-in from the get-go It
> was intended to be something the vendors could agree upon, not a useful
> standard. The issue for the vendors was in having a check-box for
> Smalltalk compared to other languages; C had a standard, C++ had a
> standard, so Smalltalk needed one. ut the standard wasn't useful for
> the community, and I think as a result hasn't been that useful for the
> vendors. Being x3j20-compatible didn't mean enough.

As much as I agree with the standard being problematic in itself, I'd
still think that the main issue is elsewhere. In its shortest form, this
comment on Ken's blog sums it up nicely: "what if we do not like VW
Namespace?"

The point is that your assumption of universal agreement on what "the
standard" entails is simply naive. There will be things that some people
like and others that they don't. If you want them all to agree and to
actually implement what the standard says, you'll end up with a watered
down version like ANSI Smalltalk (which is weak enough that people can
pick and choose and still claim to be "compliant"). But if you want a
strong, consistent, meaningful standard then you'll face resistance
(i.e., "what if we do not like feature xyz"). And then the question
becomes: What'cha gonna do about it?

As it stands it's a no-win situation and the only way to break out of it
is to write new libraries that can be used anywhere. Seaside / Grease is
one interesting direction, perhaps Xtreams can become another one. Throw
in a portable and free collections, numerics, and network package and
you're halfways there.

To me, that's the only way to get this done. Don't write a standard -
write code instead! Make it portable, get other projects to use it, and
just leave the vendors in the dust. Define a brand, perhaps "Common
Smalltalk Libraries" that a group can own and control and define that
you can call yourself "CSL compliant" if you pass the tests provided by
CSL. All of them.

Cheers,
- Andreas

Bert Freudenberg

Re: 16rff is looking for a fix :)

In reply to this post by Eliot Miranda-2

On 11.02.2010, at 13:21, Eliot Miranda wrote:
> this in the thread spawned by Torsen's posting of Kent's most excellent rant:
> ttp://www.threeriversinstitute.org/blog/?p=466
>
> OK, fix is to two implementations of digitValue:.

"fix"?

We had this discussion, err, about 10 years ago. Pops up from time to time but we can refer to the definitive answer:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-March/013368.html

So, get Kent to use 16rFF which reads nicer anyway.

- Bert -

Andreas.Raab

Re: 16rff is looking for a fix :)

Bert Freudenberg wrote:
> "fix"?
>
> We had this discussion, err, about 10 years ago. Pops up from time to time but we can refer to the definitive answer:
>
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-March/013368.html

Heh. I remember that discussion. I disagreed with Dan then and I
disagree now. My take on this is still the same: The usage of exponents
with a radix other than ten may be educational but is otherwise
*completely* pointless. So I say: Allow radix syntax (r) only WITHOUT
exponent modifier (e) in literal numbers in which case none of this is
an issue, i.e.,

16r1e5 => 485
1e5 => 10000
10r34e5 => ERROR! needs to be written as 10r34 * 1e5

So the exponent is always decimal in literal numbers. Simple, consisten,
*and* convenient.

Cheers,
- Andreas