Hello,

I have noticed a strange behavior by tcl/tk shells that I would like to
avoid. This happens with tclsh, wish, and tkcon. I say shell but it
may just be the text widget behind the scenes causing this:

Whenever the shell needs to display back a slightly large amount of
text, it locks up. I am not talking about 10's of megabytes of text
either. Just a few kilobytes maybe. The larger the text, the longer
the wait. Sometimes, you just end up terminating the whole session
because the wait is so long.

Does anyone have a solution for this?

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

Robert Heller <[email protected]> wrote:

At Wed, 20 Apr 2022 11:07:35 -0400 [email protected] wrote:

Hello,

I have noticed a strange behavior by tcl/tk shells that I would like
to avoid. This happens with tclsh, wish, and tkcon. I say shell
but it may just be the text widget behind the scenes causing this:

Whenever the shell needs to display back a slightly large amount of
text, it locks up. I am not talking about 10's of megabytes of text
either. Just a few kilobytes maybe. The larger the text, the
longer the wait. Sometimes, you just end up terminating the whole
session because the wait is so long.

Does anyone have a solution for this?

I've never noticed this (at least not on Linux).

I've seen it on windows machines with the default wish console, but
not with "a few kilobytes", the text had to be quite large (i.e.,
significantly larger than "a few kilobytes", bordering on megabytes or
so).

Two (maybe) solutions to the OP:

1) when running commands that would return a lot of text -- but you do
not really need the text printed, append a "; list" to the end before
executing the command. The text that would return will not show
(because what you'll see is the return from 'list', which is an empty
list.

2) try TkCon (https://wiki.tcl-lang.org/page/Tkcon). It might cope
better, but it might not, as it uses the text widget behind the scenes
as well.

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

I've never noticed this (at least not on Linux).

Is there anything special about the text? Hugely long lines? Strange character sets? How are you inserting this text?

At Wed, 20 Apr 2022 11:07:35 -0400 [email protected] wrote:

Hello,

I have noticed a strange behavior by tcl/tk shells that I would like to avoid. This happens with tclsh, wish, and tkcon. I say shell but it
may just be the text widget behind the scenes causing this:

Whenever the shell needs to display back a slightly large amount of
text, it locks up. I am not talking about 10's of megabytes of text
either. Just a few kilobytes maybe. The larger the text, the longer
the wait. Sometimes, you just end up terminating the whole session
because the wait is so long.

Does anyone have a solution for this?

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
[email protected] -- Webhosting Services

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

On 4/20/22 12:13 PM, Rich wrote:

I've seen it on windows machines with the default wish console, but
not with "a few kilobytes", the text had to be quite large (i.e., significantly larger than "a few kilobytes", bordering on megabytes or
so).

Hello,

Yes, this is on a Windows machine too. I checked the actual size of the
data and you are right: it is over 100-200 Kbyte raange. The data is in
an array and while the array itself is small in terms of entries, some
of its data consists of coordinates of canvas line segments, which to my surprise were quite long.

Two (maybe) solutions to the OP:

1) when running commands that would return a lot of text -- but you do
not really need the text printed, append a "; list" to the end before executing the command. The text that would return will not show
(because what you'll see is the return from 'list', which is an empty
list.

This is a good trick. I use "; set x" where x does not exist. But list
is a nicer solution.

2) try TkCon (https://wiki.tcl-lang.org/page/Tkcon). It might cope
better, but it might not, as it uses the text widget behind the scenes
as well.

I see it with wish and tkcon, but not tclsh. I suspect it has to do with coloring for some reason.

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

On 4/20/22 11:43 AM, Robert Heller wrote:

I've never noticed this (at least not on Linux).

Is there anything special about the text? Hugely long lines? Strange character sets? How are you inserting this text?

Hello,

Inserting the text is not a problem but displaying it back is. Or when
you enter something and want to edit it inline using up-arrow key.

Most of the time it is an array and I use "parray" to print it. Some of
the data consists of canvas coordinates.

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

Am 20.04.22 um 17:07 schrieb [email protected]:

Hello,

I have noticed a strange behavior by tcl/tk shells that I would like to avoid.  This happens with tclsh, wish, and tkcon.  I say shell but it
may just be the text widget behind the scenes causing this:

Whenever the shell needs to display back a slightly large amount of
text, it locks up.  I am not talking about 10's of megabytes of text either.  Just a few kilobytes maybe.

This is a known issue with the current text widget, it scales very badly
with the length of the lines. When you have a lot of text and the line
length is limited, like e.g.

string repeat "a\n" 10000

there is no problem - 10,000 lines with just one char display fine. When
you have a single long line like


string repeat "a " 10000

the display takes ages, and also scrolling (each redisplay) is
unbearably slow due to high CPU load for each display. There is
currently an alternative implementation of the text widget under
development, which does not have this problem - see here:

https://core.tcl-lang.org/tips/doc/trunk/tip/466.md

Unfortunately, that will become reality only in Tk 8.7+, and due to
limited capacity of the core team, the release cycle is also slow.

Christian

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

[email protected] wrote:

On 4/20/22 12:13 PM, Rich wrote:

I've seen it on windows machines with the default wish console, but
not with "a few kilobytes", the text had to be quite large (i.e.,
significantly larger than "a few kilobytes", bordering on megabytes or
so).

Hello,

Yes, this is on a Windows machine too. I checked the actual size of the
data and you are right: it is over 100-200 Kbyte raange. The data is in
an array and while the array itself is small in terms of entries, some
of its data consists of coordinates of canvas line segments, which to my surprise were quite long.

The console configures its text widget to perform line wrap. Part of
the slowness may be the work necessary to decide the line wrap points
for very long lines. And your "canvas line segments" may very well be
"very long lines".

Two (maybe) solutions to the OP:

1) when running commands that would return a lot of text -- but you do
not really need the text printed, append a "; list" to the end before
executing the command. The text that would return will not show
(because what you'll see is the return from 'list', which is an empty
list.

This is a good trick. I use "; set x" where x does not exist. But list
is a nicer solution.

Plain 'list' avoids having to see "can't read "x": no such variable"
errors all the time.

2) try TkCon (https://wiki.tcl-lang.org/page/Tkcon). It might cope
better, but it might not, as it uses the text widget behind the scenes
as well.

I see it with wish and tkcon, but not tclsh. I suspect it has to do with coloring for some reason.

Because windows has no 'console' (in the Unix/Linux sense) wish has to
simulate one. The wish console is that simulation.

With tclsh, the 'console' it uses is the windows cmd shell window (or
power shell window) that it runs within, so it does not need to
"provide a console". It just pushes data out the stdout file channel
and is done. The cmd shell or power shell window handles the display
of that data.

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

On 4/20/22 2:22 PM, Rich wrote:

With tclsh, the 'console' it uses is the windows cmd shell window (or
power shell window) that it runs within, so it does not need to
"provide a console". It just pushes data out the stdout file channel
and is done. The cmd shell or power shell window handles the display
of that data.

Ah, that makes sense. Thank you; good info.

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

On 4/20/22 2:27 PM, Christian Gollwitzer wrote:

This is a known issue with the current text widget, it scales very badly
with the length of the lines. When you have a lot of text and the line
length is limited, like e.g.

Hello,

Thank you! I suppose as long as it is fixed and is scheduled for
release, that is OK.

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

On 4/20/2022 12:45 PM, [email protected] wrote:

On 4/20/22 2:27 PM, Christian Gollwitzer wrote:

This is a known issue with the current text widget, it scales very
badly with the length of the lines. When you have a lot of text and
the line length is limited, like e.g.

Hello,

Thank you! I suppose as long as it is fixed and is scheduled for
release, that is OK.

If you are just using the windows console for debugging, and don't mind
using a little hack, try typing the following:


% string repeat abcdef 10000

This will take over 10 seconds on my computer.
Then clear the console and paste this in:

console eval {

set ::tk::console_flag 0

proc ::tk::console_hack {} {

if {$::tk::console_flag } {
.console mark set insert end
.console see insert
set ::tk::console_flag 0
}
after 200 ::tk::console_hack
}
proc ::tk::ConsoleOutput {dest string} {
set w .console
$w insert output $string $dest
::tk::console::ConstrainBuffer $w $::tk::console::maxLines
set ::tk::console_flag 1
}
after 200 ::tk::console_hack

}



Then run the string repeat again, and for me, it then takes under 1
second. But scrolling is still very slow, so clear the console afterwards.

The problem it addresses is the code normally does a

.console see insert

for every line output through the :tk::ConsoleOutput code. This hack
will cause it to do that at most 5 times a second.



If you really want to play with the console, you can check out the wiki page

https://wiki.tcl-lang.org/page/console

I have added several buttons and menu commands to the standard console
since it is my primary debugging device.

On Androwish, the console was really slow, and so I use the above hack
in all my programs that output anything to the console.

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

On 4/20/22 8:14 PM, jtyler wrote:

The problem it addresses is the code normally does a

.console see insert

for every line output through the :tk::ConsoleOutput code. This hack
will cause it to do that at most 5 times a second.

Hello,

Interesting - it works from the wish console. The same amount of output
that locks up normal wish console is now instantaneous. However, there
seems to be a side effect: it seems to slow down everything. Opening my application window, I can see widgets appearing one by one (i.e., very
slowly). Even dragging the console window by its title bar (from MS
Windows) is slow and jumpy. Ideally it could have a way to turn it on
and off depending on the amount of text.

In any case, as annoying as it could be at times, the original issue is
no big deal really.

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

On 4/20/2022 6:50 PM, [email protected] wrote:

On 4/20/22 8:14 PM, jtyler wrote:

The problem it addresses is the code normally does a

.console see insert

for every line output through the :tk::ConsoleOutput code. This hack
will cause it to do that at most 5 times a second.

Hello,

Interesting - it works from the wish console.  The same amount of output that locks up normal wish console is now instantaneous.  However, there seems to be a side effect: it seems to slow down everything.  Opening my application window, I can see widgets appearing one by one (i.e., very slowly).  Even dragging the console window by its title bar (from MS Windows) is slow and jumpy.  Ideally it could have a way to turn it on
and off depending on the amount of text.

In any case, as annoying as it could be at times, the original issue is
no big deal really.

Are you outputting a *whole lot of stuff* to the console? The code kinda
turns itself off if there's no output. The variable ::tk::console_flag
is only set to 1 if there is output thru ::tk::ConsoleOutput. If there's
no output, then all it would do is wake up every 200 ms check the flag
and schedule the next time in 200 ms.

If it's slowing you down, are you seeing a ton of output to the console? Otherwise, I'm stumped.

There's one other item you could add:

console eval {
set ::tk::console::maxLines 500
}

which would limit the size of the console text to 500 chars, to see if
that makes a difference. Normally, I bump this up since I don't want to
lose anything.

Another surprising thing is that it helps to do something like,

puts "......" ; update

It keeps things moving through. I use it when I want to see everything
coming out fast like an old time terminal, rather than in chunks.

And if you don't need 5000 char lines coming out, you can use [string
range] to limit your output to a shorter line length. As mentioned by
others, it's the really long lines that are the slowest.

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