This loop is designed to read a file and print the contents.

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

However nothing is printed. Ideas why?

Mark

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

In article <87wmsdierk.fsf@turtle-trading.net>,
Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net> 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.

On Saturday 13 January 2024 at 12:44:58 UTC, Benjamin Riefenstahl 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

That's what I expected to happen. One print of 'Hello World' and then a lot of
nothings. I'm using WISH and nothing is printed in the
console window. I did mean to use read and not gets. This is supposed to be a precursor
to a program that does something more useful.

Mark

The more useful is

proc loop {} {
set fd [open "test.txt"]
while { 1 } {
set i [read $fd]
<if $i is not empty ;; pseudocode
evaluate $i
else skip>
}}
I wonder if the output is being buffered in some ay and that's why I am not seeing anything.

Mark

This is odd.

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?

Mark

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

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.

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.
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. So there is some form of buffering going on. If so, is there a way of flushing this buffer?

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 }
}}

proc newcommand? {File} {
set Source [open $File r]
set Data [read $Source]
set Verdict [eot? $Data]
close $Source
return $Verdict}

proc eot? {S} {
return [ string match *eot $S ]
}

proc enact {File} {
set Source [open $File r]
set Data [read $Source]
set Command [trim $Data]
overwrite $File
eval $Command
close $Source}

proc overwrite {File} {
set Sink [open $File w]
puts -nonewline $Sink ""
flush $Sink
close $Sink}

proc trim {S} {
return [string map {"eot" ""} $S]
}

proc send {String} {
set Sink [open $out w]
puts [concat String "eot"] Sink
close $Sink}

eventloop $in

On Monday 15 January 2024 at 11:54:46 UTC, Mark Tarver 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.
> 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. So there is some form of buffering going on. If so, is there a way of flushing this buffer?
>
> 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 }
> }}
>
> proc newcommand? {File} {
> set Source [open $File r]
> set Data [read $Source]
> set Verdict [eot? $Data]
> close $Source
> return $Verdict}
>
> proc eot? {S} {
> return [ string match *eot $S ]
> }
>
> proc enact {File} {
> set Source [open $File r]
> set Data [read $Source]
> set Command [trim $Data]
> overwrite $File
> eval $Command
> close $Source}
>
> proc overwrite {File} {
> set Sink [open $File w]
> puts -nonewline $Sink ""
> flush $Sink
> close $Sink}
>
> proc trim {S} {
> return [string map {"eot" ""} $S]
> }
>
> proc send {String} {
> set Sink [open $out w]
> puts [concat String "eot"] Sink
> close $Sink}
>
> eventloop $in

For example, is it possible to embed an event loop in a thread as a background process and solve the problem that way?

Mark

Mark Tarver <dr.mtarver@gmail.com> 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.

On Monday 15 January 2024 at 13:52:02 UTC, Rich wrote:
> Mark Tarver <dr.mt...@gmail.com> 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.

Thanks 'update' was a great help.

Mark

Mark Tarver <dr.mtarver@gmail.com> wrote:
> On Monday 15 January 2024 at 13:52:02 UTC, Rich wrote:
>> Mark Tarver <dr.mt...@gmail.com> 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.