A couple of small problems

Andy/Blair,

The expression

   Float fromString:'.4'

evalutes to 0.0 on 4.01.3 (perhaps sooner) but not on 4.0, which gets 0.4.
Users probably should reflexively add the leading zero, but, they don't :(

My first thought on seeing the downstream result of this was that
#fromString: had changed.  So, I typed the expression, put the cursor at the
end, and hit control-d - I got a long selection followed by the correct
result.  4.0 gave me a walkback.  My machine had been running for a while so
I rebooted, with the same results.  Something about the new compiler maybe??
Or was it my uninstall-reinstall?  Anybody else seeing this?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

the same here 0.0 !

Ingo

"Bill Schwab" <[hidden email]> schrieb im Newsbeitrag
news:9hdnf9$df7j2$[hidden email]... the
> end, and hit control-d - I got a long selection followed by the correct
> result.  4.0 gave me a walkback.  My machine had been running for a while
so
> I rebooted, with the same results.  Something about the new compiler
maybe??

Ingo,

> the same here 0.0 !

Not surprising, though I haven't yet had a chance to debug into it, it just
_feels_ like a change in Dolphin :)   However, are you seeing the
control-d/big selection business?  That one could be more on my end only.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:9hdnf9$df7j2$[hidden email]... the
> end, and hit control-d - I got a long selection followed by the correct
> result.  4.0 gave me a walkback.  My machine had been running for a while
so
> I rebooted, with the same results.  Something about the new compiler
maybe??
> Or was it my uninstall-reinstall?  Anybody else seeing this?

Well, it seems to work OK on 4.01.2 (I didn't realize I hadn't applied the
latest patch until just now.  Lucky me!).  It looks like Float>>fromString:
falls through to Number>>fromString: which is just a wrapper around
Number>>readFrom: which looks like this:

readFrom: aStream
 "Instantiate a new sub-instance of the receiver from aStream and answer it.
 Any numbers in the stream are expected to obey Smalltalk syntax
 rather than any locale specific formatting, i.e. this is not intended for
reading
 user input. WARNING: If you modify this method you may break the compiler.
 Implementation Note: The basic idea is to read the initial integer part and
 then proceed to read a Float if a decimal point is found, a Fraction is a
 slash is found, etc. "

 | neg integerPart next answer |
 neg := aStream peekFor: $-.
 integerPart := Integer readFrom: aStream radix: 10.

 "The type of number is determined by what we find next"
 next := aStream peek.

 answer := ('.edqs' includes: next)  "Although, e.g., 1e5 not ANSI, we test
for e,E, &c for ST-80 compatibility."
  ifTrue: [self readSmalltalkRealFrom: aStream initialInteger: integerPart]
  ifFalse: [
   next == $/
    ifTrue: [
     "Skip over the $/"
     aStream next.
     aStream peek isDigit
      ifTrue: [
       Fraction
        numerator: integerPart
        denominator: (Integer readFrom: aStream radix: 10)]
      ifFalse: [
       aStream pop. "Pop the $/ we skipped over thinking it was a literal
fraction"
       Integer readFrom: aStream initialInteger: integerPart]]
    ifFalse: [
     "Otherwise Integer - we must test for radix though"
     Integer readFrom: aStream initialInteger: integerPart]].
 ^neg
  ifTrue: [answer negated]
  ifFalse: [answer]

What's it look like in 4.01.3?
--
Bob Jarvis

Hello all,

> > the same here 0.0 !

The problem is at least partly that Number class>>fromString: is not meant
to read user input - the comment says so.  However,
NumberToText>>rightToLeft: falls back on it, so something is missing for GUI
purposes.  At least that's my read on it at the end (I hope<g>) of a long
day.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

.4 ctrl-d gives no walkback, but an "invalid expression start" signaled
in the status bar.

By the way, user input dealing with real numbers causes me getting
allergic...
The only way around is IMHO either a masked input field, or a _strict_
plausibility control. You can use a FDA algorithm to do that.

Ingo

"Bill Schwab" <[hidden email]> schrieb im Newsbeitrag
news:9he18u$d6sr8$[hidden email]...
> Ingo,
>
> > the same here 0.0 !
>
> Not surprising, though I haven't yet had a chance to debug into it, it
just

"Ingo Blank" <[hidden email]> wrote in message news:<3b3aa686$0$29369$[hidden email]>...
> Bill,
>
> .4 ctrl-d gives no walkback, but an "invalid expression start" signaled
> in the status bar.
>
> By the way, user input dealing with real numbers causes me getting
> allergic...
> The only way around is IMHO either a masked input field, or a _strict_
> plausibility control. You can use a FDA algorithm to do that.

This works OK in 4.01.2.  It looks like the number parsing stuff was
substantially rewritten for 4.01.3, and now Float>>readFrom:
expects/requires that a float string have an integer before the
decimal point.  This appears to conform to the standard, which has the
following BNF for float constants:

        float ::= mantissa [exponentLetter exponent]
        mantissa ::= digits '.' digits
        exponent ::= ['-']decimalInteger
        exponentLetter ::= 'e' | 'd' | 'q'

I think this is a hole in the standard, and that the mantissa
specification should be

        mantissa ::= [digits] '.' digits

Otherwise you have to write something like

        floatString := something floatString.
        [floatString at: 1] = '.' ifTrue: [ floatString := '0',
floatString ].
        floatValue := Float fromString: floatString.

which is a horribly ugly kludge.
--
Bob Jarvis

Andy/Blair,

> My first thought on seeing the downstream result of this was that
> #fromString: had changed.  So, I typed the expression, put the cursor at
the
> end, and hit control-d - I got a long selection followed by the correct
> result.  4.0 gave me a walkback.  My machine had been running for a while
so
> I rebooted, with the same results.  Something about the new compiler
maybe??
> Or was it my uninstall-reinstall?  Anybody else seeing this?

I've discovered that my machine at home responds correctly to control-d.  No
great surprise, but, any sugestions on why the other machine is having
trouble?  Perhaps relevant is that I tried to install the 4.01.3 .msi file
over the existing install in my office, and here I went directly to
uninstall/install.

The machine at work is a relatively recent addition the herd.  It was kind
enough to take over the duties of a K6-2 that has gone on to its reward -
and none too soon! :)  So far, I'm happy with the replacement.  It's
technically slower than the other machine, but, you would suspect the
opposite after using both of them (that's if the old one would still boot).
Still, I can't say that "it's been running fine for nn months" because I
just pressed it into service.

Sadly, I can't say with certainty what the new machine did prior to my
re/un/install efforts.  It's possible that it was broken from the beginning
and I never noticed it.  Could it be an old copy of the rich text control?
If so, how would I upgrade it? I think I put IE 5.5 on it, but, I'll check
later today.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill


You wrote in message news:9hdnf9$df7j2$[hidden email]...
> Andy/Blair,
>
> The expression
>
>    Float fromString:'.4'
>
> evalutes to 0.0 on 4.01.3 (perhaps sooner) but not on 4.0, which gets 0.4.

That is because Number>>fromString: is implemented (ultimately) in terms of
Number>>readSmalltalkSyntaxFrom:, and that will only read a Float point
number formatted in correct Smalltalk floating point syntax. I think it
should give an error though (at least for Number>>fromString:,
Number>>readFrom: has traditionally returned 0 if there is no valid number
at the current position in the stream).

> Users probably should reflexively add the leading zero, but, they don't :(

User input should really be routed via a different number parser so it takes
account of locale differences too (e.g. in many european countries a comma
is used in place of the decimal point). This exists as a longstanding todo,
but I've added it to the defect tracking system so that it doesn't get
overlooked in a future release.

> My first thought on seeing the downstream result of this was that
> #fromString: had changed.  So, I typed the expression, put the cursor at
the
> end, and hit control-d - I got a long selection followed by the correct
> result.  4.0 gave me a walkback.  My machine had been running for a while
so
> I rebooted, with the same results.  Something about the new compiler
maybe??
> Or was it my uninstall-reinstall?  Anybody else seeing this?

Hmmm, that sounds like the behaviour one tends to see when the resulting
strings contains nulls (try evaluating
(String new: 100) with some other text below the expression in the
workspace.

Regards

Blair