From Newsgroup: comp.lang.tcl

It seems that the ms argument to the after command has a limit. If it
is sufficiently large, it locks up the script and you can't do anything
until you cancel the after command.

Further checking seems to point at "2037" or thereabouts as the critical
time point. Any ms argument that puts it past that point causes the
error. But there is no info on this in the docs so perhaps it is
something else altogether.

% after [expr 14*365*24*60*60*1000] puts "gui locked up?"


This is on 64-bit Windows running 32-bit tclsh.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

On 3/4/24 14:50, saitology9 wrote:

It seems that the ms argument to the after command has a limit.  If it
is sufficiently large, it locks up the script and you can't do anything until you cancel the after command.

Further checking seems to point at "2037" or thereabouts as the critical time point.  Any ms argument that puts it past that point causes the
error. But there is no info on this in the docs so perhaps it is
something else altogether.

% after [expr 14*365*24*60*60*1000]  puts "gui locked up?"

First off the correct syntax would be:
after [expr {14*365*24*60*60*1000}] {puts "gui locked up?"}


Second off, is it realistic that the same process will be running in 14
years?

Thirdly, it does not seem to cause an issue on Linux (Ubuntu to be
precise) -- so this may be a MS Windows bug.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

Gerald Lester <Gerald.Lester@gmail.com> wrote:

On 3/4/24 14:50, saitology9 wrote:

It seems that the ms argument to the after command has a limit.  If it
is sufficiently large, it locks up the script and you can't do anything
until you cancel the after command.

Further checking seems to point at "2037" or thereabouts as the critical
time point.  Any ms argument that puts it past that point causes the
error. But there is no info on this in the docs so perhaps it is
something else altogether.

% after [expr 14*365*24*60*60*1000]  puts "gui locked up?"

First off the correct syntax would be:
after [expr {14*365*24*60*60*1000}] {puts "gui locked up?"}

Second off, is it realistic that the same process will be running in 14 years?

Not really. That would be some very serious "nines" there (as in the
supposed "5 nines" reliability of IBM mainframes).

This is on 64-bit Windows running 32-bit tclsh.

Thirdly, it does not seem to cause an issue on Linux (Ubuntu to be
precise) -- so this may be a MS Windows bug.

It sounds like 32-bit Tcl on Windows is using a 32-bit time value that
can't represent time past the overflow point of a 32-bit time value.
I.e., it may be suffering from the year 2038 problem:

https://en.wikipedia.org/wiki/Year_2038_problem
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

On 3/4/2024 4:17 PM, Gerald Lester wrote:

First off the correct syntax would be:
  after [expr {14*365*24*60*60*1000}]  {puts "gui locked up?"}

Copy/paste mistake.

Second off, is it realistic that the same process will be running in 14 years?

LOL, no, not really :-) But then again, people did spend millions on Y2K.

Thirdly, it does not seem to cause an issue on Linux (Ubuntu to be
precise) -- so this may be a MS Windows bug.

More than likely I guess.

Thanks for the reply.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

On 3/4/2024 4:26 PM, Rich wrote:

It sounds like 32-bit Tcl on Windows is using a 32-bit time value that
can't represent time past the overflow point of a 32-bit time value.
I.e., it may be suffering from the year 2038 problem:

https://en.wikipedia.org/wiki/Year_2038_problem

I think this is it! Thanks.


--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.tcl

Am 04.03.2024 um 22:29 schrieb saitology9:

On 3/4/2024 4:26 PM, Rich wrote:

It sounds like 32-bit Tcl on Windows is using a 32-bit time value that
can't represent time past the overflow point of a 32-bit time value.
I.e., it may be suffering from the year 2038 problem:

https://en.wikipedia.org/wiki/Year_2038_problem

I think this is it!      Thanks.

"after" on MS-Windows also relies on the fact, that the clock is not
changed. I have a gui written in TCL to change the clock of an embedded system. Then, all after events are delayed by this time.

It may be, that all year 2038 issues with Windows are fixed in more
recent versions of TCL. I tested it one day by advancing the clock of my machine and it worked, if I remember right.

Take care,
Harald


--- Synchronet 3.20a-Linux NewsLink 1.114