the "after" command behaviour

[bvdang]

I am a little bit confused about the after command.

For instance, in the following code:

after 1000; puts 1; after 1000; puts 2; after 1000; puts 3

I want to wait a second then print 1 then wait another second then print 2 and so on. But when I tried it out on WISH83 console, it waits 3 seconds then prints out

1
2
3

Is this behaviour correct?

 

[marsd]

Try this:

proc staggered {} {
after 1000 ; puts "1"
after 1000 ; puts "2"
after 1000 ; puts "3"
}

after 500 {staggered}

Avia or Ulis could explain the theory
here I'm sure, I just refer you to the command documentation where it states that
the commands are evaluated in a concatenated manner.

HTH

 

[AviaTraining]

Good guess, marsd, but that's not what's going on in this case. An unquoted, unescaped semicolon is treated as an "end-of-command" indicator, so the Tcl interpreter reads and parses up to the first semicolon, then executes the result; reads and parses up to the second semicolon, then executes the result; etc. Thus, the line shown by bvdang is actually treated as 6 separate commands. On the other hand:

[tt]after 1000 puts 1\; after 1000\; puts 2\; after 1000\; puts 3[/tt]

is treated as a single command that schedules the following 5 commands to be executed after a pause of 1 second:

puts 1; after 1000; puts 2; after 1000; puts 3

Anyway, the problem observed by bvdang is a bit more subtle. I'm willing to lay odds that bvdang tried this on a Windows wish interpreter.

The code sample posted by bvdang works as expected in a tclsh interpreter, or in a wish interpreter on Unix (I tested both). The reason it doesn't work as expected on a Windows wish has to do with the way the Windows wish interpreter is implemented.

Windows doesn't have quite the same concept of standard IO channels as Unix. When you start a program from the Windows command prompt, Windows can run the program as a console-based application, so puts and gets commands work fine. However, when you run a GUI application on Windows, it can't run as a console-based application. From the point of view of the program, there is no real standard input to read from or standard output to write to.

So, on Windows Tcl creates a special console window (created with a standard Tk text widget) and redefines the puts command to send output to that console. However, the console is part of the application, and makes use of the application's event loop.

Now we get to the crux of what bvdang observed. Screen refreshes are handled as part of the event loop operation. Your application isn't in the event loop when it's executing Tcl code. You gave Tcl a sequence of 6 commands to execute, so the interpreter must complete all 6 before it enters the event loop. The puts commands contained in the sequence each tries to update the console's text widget, but those updates are deferred until the interpreter gets to the event loop. And so once the interpreter gets to the event loop, it finally gets the opportunity to refresh the console, displaying the output of all three puts commands at once.

You can verify that this is what's happening by inserting an update command after the intermediate puts commands, giving the interpreter the opportunity to dip into the event loop and refresh the screen:

after 1000; puts 1; update; after 1000; puts 2; update; after 1000; puts 3

So, this behavior is only an artifact of the special console window provided with the Windows wish. - Ken Jones, President, ken@avia-training.com
Avia Training and Consulting,

http://www.avia-training.com

866-TCL-HELP (866-825-4357) US Toll free
415-643-8692 Voice
415-643-8697 Fax