1. Forum
  2. Usenet
  3. COMP.LANG.TCL

  • Re: simple loop

    From Benjamin Riefenstahl@21:1/5 to Mark Tarver on Sat Jan 13 13:44:47 2024
    Hi Mark,

    Mark Tarver writes:
    proc loop {} {
    set fd [open "test.txt"]
    while { 1 } {
    set i [read $fd]
    puts $i
    }}

    However nothing is printed. Ideas why?

    Works fine here. In the first run through the loop "read" without the
    "size" parameter reads the whole file and "puts" prints it. For the
    rest of your infinite loop, "read" does not have anything to read, but
    "puts" continues to write empty lines. So if you run this proc in a
    terminal or Windows console, while the screen is empty in fact the
    program is busy printing newlines all the time.

    HTH, benny

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Kenny McCormack@21:1/5 to [email protected] on Sat Jan 13 13:01:25 2024
    In article <[email protected]>,
    Benjamin Riefenstahl <[email protected]> wrote:
    Hi Mark,

    Mark Tarver writes:
    proc loop {} {
    set fd [open "test.txt"]
    while { 1 } {
    set i [read $fd]
    puts $i
    }}

    However nothing is printed. Ideas why?

    Works fine here. In the first run through the loop "read" without the
    "size" parameter reads the whole file and "puts" prints it. For the
    rest of your infinite loop, "read" does not have anything to read, but
    "puts" continues to write empty lines. So if you run this proc in a
    terminal or Windows console, while the screen is empty in fact the
    program is busy printing newlines all the time.

    HTH, benny

    OP probably meant to use "gets" instead of "read", and to make the "gets" command be the condition of the while loop, so that it exits when it hits
    EOF.

    --
    He continues to assert that 2 plus 2 equals 4, despite being repeatedly
    told otherwise.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Benjamin Riefenstahl@21:1/5 to Mark Tarver on Sat Jan 13 16:16:52 2024
    Hi Mark.

    Mark Tarver writes:
    proc loop {} {
    set fd [open "C:/Users/shend/OneDrive/Desktop/test.txt"]
    while { 1 } {
    set i [read $fd]
    puts "hello"
    }}

    should just keep printing 'hello'. This works under the console only
    TCL/tk but not under WISH. Any ideas?

    You are using the graphical Tk console. A graphical console will not do anything unless you start a message loop ("vwait"). An endless loop is
    not usefull here, because the message loop can not run at the same time.

    HTH, benny

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From et99@21:1/5 to Benjamin Riefenstahl on Sun Jan 14 21:19:23 2024
    On 1/13/2024 7:16 AM, Benjamin Riefenstahl wrote:
    Hi Mark.

    Mark Tarver writes:
    proc loop {} {
    set fd [open "C:/Users/shend/OneDrive/Desktop/test.txt"]
    while { 1 } {
    set i [read $fd]
    puts "hello"
    }}

    should just keep printing 'hello'. This works under the console only
    TCL/tk but not under WISH. Any ideas?

    You are using the graphical Tk console. A graphical console will not do anything unless you start a message loop ("vwait"). An endless loop is
    not usefull here, because the message loop can not run at the same time.

    HTH, benny

    The OP didn't mention how he ran this program. Did he put that code in a file and

    wish <file>

    or did he run with an interactive wish, type in the proc etc.

    Ordinarily, if you wish <file> it won't open the console, just a toplevel of . (dot).

    To see what is going on, I suggest changing the puts to,

    puts "[incr count] hello";update

    And add a [console show] at the top.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Mark Tarver on Mon Jan 15 13:51:57 2024
    Mark Tarver <[email protected]> wrote:
    OK; a bit further on. I've not really looked at TLC/tk for a long time.

    Basically I want TCL/tk to enter a loop and read a file. When the
    file contains a TCL/tk command, This command should be read and
    executed.

    Are you looking for the existing [source] command?

    It works fine for commands like 'bell' and 'puts' and fails for
    widget commands. However when the event loop is existed, the missing
    widgets appear.

    This is normal. Most of the work of displaying widgets is performed on
    the event loop as a background task. So if your Tcl code never returns
    to the event loop, that work does not get performed.

    Note that [bell] and [puts] are Tcl commands, not Tk commands, so they
    do not interact with the event loop.

    So there is some form of buffering going on.

    Yes, much of the work is deferred to be run during "idle time" (time
    when your Tcl script code is not running) of the GUI program.

    If so, is there a way of flushing this buffer?

    The [update] command is provided for just this purpose, but can have
    other side effects (https://wiki.tcl-lang.org/page/Update%20considered%20harmful).

    I cite the program below.

    Mark

    set in {C:/Users/shend/OneDrive/Desktop/Shen/S37.2/shen-to-tcl.txt}
    set out {C:/Users/shend/OneDrive/Desktop/Shen/S37.2/tcl-to-shen.txt}

    proc eventloop {File} {
    while { 1 } {
    after 10
    if { [newcommand? $File] } {
    enact $File }
    }}

    Never returns, and contains no calls to [update] no the event loop
    never gets to run, and all the deferred work is never performed.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Mark Tarver on Mon Jan 15 17:40:11 2024
    Mark Tarver <[email protected]> wrote:
    On Monday 15 January 2024 at 13:52:02 UTC, Rich wrote:
    Mark Tarver <[email protected]> wrote:
    proc eventloop {File} {
    while { 1 } {
    after 10
    if { [newcommand? $File] } {
    enact $File }
    }}
    Never returns, and contains no calls to [update] no the event loop
    never gets to run, and all the deferred work is never performed.

    Thanks 'update' was a great help.

    Do read https://wiki.tcl-lang.org/page/Update%20considered%20harmful

    Forcibly calling update can cause issues in some instances. If you are
    truly trying to make a proper GUI (as opposed to just experimenting
    with ideas) then letting the event loop run normally, and structuring
    your code to react to events (i.e., don't sit in an endless loop), will
    produce more robust code and avoid many of the bad side effects.

    That 'endless loop' example you gave looks an awful lot like the
    general structure of traditional Win32 programs. If you are trying to
    write the same code structure you'd write for a Win32 program, then it
    is better to rethink that structure. The endless loop method is not
    only unnecessary for Tk, it is detrimental to the basic way Tk works.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)