Re: Bug in spinbox

On 2006-02-26, bgd <bgd73@verizon.net> wrote:
> Aren't you friendly. Take it to Mr.Ousterhout...

Hmmmm, well, my observations might have been a little harsh, but they're
still true. It's also ironic that you mentioned JO -- I've often been
accused of being pedantic. 8-)

> Do you know who that is ?
> RTFM
>>>>> foreach {day mon year} [clock format [clock seconds] -format "%e %B
>>>>> %Y"]

Actually, the full command line that Ulrich posted is:

  foreach {day mon year} [clock format [clock seconds] -format "%e %B %Y"] break

Try it in your tclsh.

> The above code is so obviously incorrect it jumped at me. 3 variables same
> value. I say no more.

No, it's correct. I described Ulrich's algorithm earlier, and here it is
again, broken down to better illustrate it:

>> it takes a single timestamp,

ie. one call to [clock seconds] = <A>

>> formats it into a list-compatible string,

[clock format <A> -format "%e %B %Y"]
--> "26 February 2006"
which is equivalent for most purposes (and definitely in this case) to:
--> [list 26 February 2006]

Oh, and you don't have to take my word for it. Try this in your tclsh:

  puts [llength [clock format [clock seconds] -format "%e %B %Y"]]

For [foreach] to assign the same value to each of day/mon/year, the
result of [clock format] must be a list of 1 element. But the above
command prints "3"...

>> and uses [foreach] to assign the string-list's elements into the
>> appropriate variables.

foreach {day mon year} {26 February 2006} break
Iteration 1:
  set day 26
  set mon February
  set year 2006
  break (no more iterations)

> As far as time changing a second after you get it...... In the name of God
> Allmighty...... Time does in fact keep moving along.

Which is exactly the reason why it's possible to get clearly erroneous
results using your code. Again, starting at 31 Dec 2006 23:59:59...

>> day=31 mon=December year=2007 # Error = 1 year
happens if your third [clock seconds] call (for year) falls on
1 Jan 2007 00:00:00

>> day=31 mon=January year=2007 # Error = 1 month
happens if your second [clock seconds] call (for mon) falls on
1 Jan 2007 00:00:00

(Note that the first error can only happen once a year, but the second
can happen every month.)

Ulrich's code cannot trigger these errors because it only takes a single
timestamp, so the time used to generate day/mon/year is *guaranteed* to
be the same for all three values (in fact, all three values are
generated simultaneously).

> If you'd like to box it out to relieve a bit of pressure unrelated, I'll let
> you throw first.

I apologize if you feel insulted by my previous analysis, but I hope
it's clear now that your code is broken. It may work most of the time,
but it doesn't make it correct code.

> Have A nice Day, and clean your damn bifocals.

Now that you mention it, I may be approaching the bifocal point. 8-)

- Adrian
Received on Sun Apr 30 02:16:02 2006