tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Issue report: tcl9.0b3 build fails on Windows/aarch64

[Jan M. <0x...@gm...>]

When trying to build tcl9.0b3 on Windows 10/aarch64.

Invoking ./configure and make fails after a while with this message
(many preceding lines omitted):

gcc -c -I"." -I"C:/Users/jnml/src/modernc.org/tk9.0/tcl9.0b3/generic"
-I"C:/Users/jnml/src/modernc.org/tk9.0/tcl9.0b3/libtommath"
-I"C:/Users/jnml/src/modernc.org/tk9.0/tcl9.0b3/compat/zlib"
-I"C:/Users/jnml/src/modernc.org/tk9.0/tcl9.0b3/win" -O2
-fomit-frame-pointer -DMP_FIXED_CUTOFFS -D__USE_MINGW_ANSI_STDIO=0
-Wall -Wextra -Wshadow -
Wundef -Wwrite-strings -Wpointer-arith -Wc++-compat
-fextended-identifiers  -DMP_PREC=4 -pipe -DHAVE_CPUID=1
-finput-charset=UTF-8 -DPACKAGE_NAME=\"tcl\" -DPACKAGE_TARNAME=\"tcl\"
-DPACKAGE_VERSION=\"9.0\" -DPACKAGE_STRING=\"tcl\ 9.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\"
-DTCL_CFGVAL_ENCODING=\"utf-8\" -DHAVE_STDIO_H=1 -DHAVE_STD
LIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DMODULE_SCOPE=extern
-DHAVE_NO_SEH=1 -DHAVE_STDBOOL_H=1 -DHAVE_CAST_TO_UNION=1
-DTCL_WITH_EXTERNAL_TOMMATH=1 -DHAVE_ZLIB=1 -DHAVE_INTPTR_T=1
-DHAVE_UINTPTR_T=1 -DZIPFS_BUILD=1 -DH
AVE_INTRIN_H=1 -DHAVE_WSPIAPI_H=1 -DNDEBUG=1 -DTCL_CFG_OPTIMIZED=1
-DBUILD_tcl "tclWin32Dll.c" -o tclWin32Dll.o
tclWin32Dll.c:442:5: error: call to undeclared function '__cpuid'; ISO
C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
  442 |     __cpuid((int *)regsPtr, index);
      |     ^
1 error generated.
make: *** [Makefile:758: tclWin32Dll.o] Error 1

jnml@pi64 CLANGARM64 ~/src/modernc.org/tk9.0/tcl9.0b3/win (dev)
$ gcc --version
clang version 19.1.0-rc3 (https://github.com/llvm/llvm-project.git
437434df21d839becb453f6821564662e9824f02)
Target: aarch64-w64-windows-gnu
Thread model: posix
InstalledDir: C:/mingw/bin

jnml@pi64 CLANGARM64 ~/src/modernc.org/tk9.0/tcl9.0b3/win (dev)
$

FTR: Tcl build of the same Tcl version works with no issues using
mingw on Windows 10/{amd64,386}. As well as tk9.0b3.

-j

[TCLCORE] Tk and thread safety

[Christian W. <Chr...@t-...>]

Hello all,

few days ago an interesting discussion was on c.l.t. regarding Itcl
and Tk used to present an Itk button per dynamically created and
destroyed thread. It uncovered a long standing bug in Itcl regarding
thread safety, which got quickly fixed by sebres.

Now for the windowing system(s): it seems that Win32 is ready for this
use case, whereas X11 and macos are not. I'm not very familiar and
competent with macos, so let's focus on X11:

* There are two possible font renderers in the X11 port of Tk:
the plain old XDrawString() and libxft using Xrender and freetype.

* While the XDrawString() way is as thread safe as the whole Xlib,
the libxft is not at all. Maybe you remember that I initially proposed a
central mutex for various libxft calls in order to overcome this issue.

* The central mutex seems to work but only as long as there's no
dynamic regarding opening and closing display connections (which is
the essence of the use case discussed on c.l.t.). When display connections
are XOpenDisplay()'ed and XCloseDisplay()'ed randomly through the life
time of a Tk program I observed very early crashes at various places
in Xrender/Xft but not when using plain old XDrawString().

* After days of debugging I found a simple non-solution: on thread
exit all X resources pertaining to the Tk applications of the thread
are released, but the final XCloseDisplay() is not carried out. Instead
the display connection is hold back (parked) on a process wide
table to be re-used later. Final XCloseDisplay()s of all display
connections are carried out per process exit handler.

* Nevertheless, the XSetErrorHandler() is a mess and most likely
the final nail in Xlib's coffin, see https://www.remlab.net/op/xlib.shtml
so the best option would be to switch everything to XCB. But this
is a huuuge undertaking.

The result of these findings can be reviewed in this check-in

   https://www.androwish.org/home/info/9b0450622edec074

in the hope that it is useful for later adoption in Tk > 9.0.

Best regards,
Christian

[TCLCORE] Commit block to tcl/tk-core-8-6-branch and main branch on TCL for non documentation and serious bug fix changes

[Harald O. <har...@el...>]

Dear TCL/Tk team,
we are approaching TCL/Tk 9.0.0 and TCL/Tk 8.6.15 releases.

Please keep any new features in own branches and please only merge 
considerable documentation and bug fixes to the main and core-8-6-branches.

Thank you for your cooperation,
Harald

Re: [TCLCORE] Tk_GetColor and Tk_Uid

[Christian W. <Chr...@t-...>]

On 09/01/2024 11:32 PM, Jan Nijtmans wrote:
> Op zo 1 sep 2024 om 06:07 schreef Christian Werner:
>
>     I'm puzzled and unhappy over the ongoing changes regarding Tk_GetColor() ...
>
> See ticket:
>     <https://core.tcl-lang.org/tk/tktview/0189a9ae39>

I see. Indeed this ship has sailed last century. The problem with the signature
of e.g. Tk_Color() should have been solved when the underlaying color hashtable
was changed from TCL_ONE_WORD_KEYS to TCL_STRING_KEYS. Seems that would have been
in late 1998 if it had happened ever.

A fine reason to power up the flux capacitor.

Best regards,
Christian

Re: [TCLCORE] Tk_GetColor and Tk_Uid

[Jan N. <jan...@gm...>]

Op zo 1 sep 2024 om 06:07 schreef Christian Werner:

> I'm puzzled and unhappy over the ongoing changes regarding Tk_GetColor()
> invocations within Tk, which do not pass the color name string as an
> explicit Tk_Uid but a string, although Tk_GetColor()'s signature states
> this being a Tk_Uid.
>

See ticket:
    <https://core.tcl-lang.org/tk/tktview/0189a9ae39>

Hope this helps,
     Jan Nijtmans

[TCLCORE] Wrong link in my previous post

[Jan M. <0x...@gm...>]

It should be https://pkg.go.dev/modernc.org/tk9.0

Sorry for the noise.

Jan

[TCLCORE] tk9.0b3: tk_library not mounted in zipfs

[Jan M. <0x...@gm...>]

Hi list.

I'm working on the Go port of Tcl/Tk:
https://pkg.go.dev/modernc.org/tk9.0@v0.15.4
(Work in progress, parts of the API are still missing.)

Now, I want to add support for Windows. After failed attempts to
transpile all of the C code
to Go, as is done for other platforms, I'm trying an alternative approach.

I am compiling tcl9.0b3 and tk9.0b3 using mingw64 on Windows/amd64.

Here's the Makefile target:

dlls: download
        rm -rf ~/tmp/tcl9* ~/tmp/tk9*
        tar xf tcl9.0b3-src.tar.gz -C ~/tmp
        tar xf tk9.0b3-src.tar.gz -C ~/tmp
        sh -c "cd ~/tmp/tcl9.0b3/win ; ./configure"
        make -C ~/tmp/tcl9.0b3/win
        cp -v \
                ~/tmp/tcl9.0b3/win/libtommath.dll \
                ~/tmp/tcl9.0b3/win/tcl90.dll \
                embed_$(shell go env GOOS)_$(shell go env GOARCH)/
        sh -c "cd ~/tmp/tk9.0b3/win ; ./configure
--with-tcl=$$HOME/tmp/tcl9.0b3/win"
        make -C ~/tmp/tk9.0b3/win
        cp -v \
                ~/tmp/tk9.0b3/win/tcl9tk90.dll \
                embed_$(shell go env GOOS)_$(shell go env GOARCH)/

This works well, both of the produced binaries, tclsh90 and wish90
seem to work. For example, if I execute
in the Windows box '$ ./wish90 ../library/demos/widget' in the
~/tmp/tk9.0b3/win directory, I get the showcase
application window and it responds to all mouse events as expected.

In the initialization of the package, I'm doing _at runtime_:

- Change the current directory to the one where libtommath.dll,
tcl90.dll and tcl9tk90.dll are.
- Load the tcl90.dll and tcl9tk90.dll, in that order.
- Find the dll procedures I will use: Tcl_CreateInterp, Tcl_Init and
Tk_Init and a few others. All are found successfully.
- Call Tcl_CreateInterp, get back a new non-NULL interpreter.
- Call Tcl_Init(interp), get back TCL_OK.
- Call Tk_Init(interp), get back TCL_ERROR. The interpreter result says:

""""
Can't find a usable tk.tcl in the following directories:
    //zipfs:/app/tk_library //zipfs:/lib/tk/tk_library //zipfs:/lib/tk
//zipfs:/lib/tcl/tcl_library/tk9.0 //zipfs:/lib/tcl/tk9.0 ./lib/tk9.0
./lib/tk9.0 ./lib/tk9.0 ./library



This probably means that tk wasn't installed properly.
""""

If I use Tcl_EvalEx, after Tcl_Init, to evaluate "zipfs list" I get a
list of 874 files, all with a common prefix:
'//zipfs:/lib/tcl/tcl_library/'.
So the earlier error message is correct, none of the search paths
could have worked in the zipfs.

Interestingly, the wish90.exe program built previously produces the
same list, with no mentions of the tk library. But it works
so it probably does something differently. I have not yet tried to
dive into the C code for wish and how it initializes itself
as I'm not really a C programmer.

I tried this:

jnml@3900x:~/src/modernc.org/tk9.0$ grep -la 'button.tcl'
embed_windows_amd64/*.dll
embed_windows_amd64/tcl9tk90.dll
jnml@3900x:~/src/modernc.org/tk9.0$ grep -la 'Africa' embed_windows_amd64/*.dll
embed_windows_amd64/tcl90.dll
jnml@3900x:~/src/modernc.org/tk9.0$

The first grep looks for the file name that's in the Tk library and it
seems tcl9tk90.dll has it. The second grep looks for a part of a path
from the tzdata directory and finds it in tcl90.dll.

So the working hypothesis is that the zipfs in tcl90.dll is getting
mounted correctly and automatically, but the one in tcl9tk90.dll does
not.
Which actually seems logical as tcl90.dll does not really know about
the existence of tcl9tk90.dll existing in the same process
when Tcl_Init is executed.

My questions:

- Does the reasoning above make any sense or am I missing something important?
- If it makes sense, is there a way and/or what is the way to mount
the tk_library zipfs in tcl9tk90.dll _before_ calling Tk_Init, so it
will succeed?

Thanks in advance for any help.

Best regards,

Jan

[TCLCORE] Tk_GetColor and Tk_Uid

[Christian W. <Chr...@t-...>]

Hello TCT, all,

I'm puzzled and unhappy over the ongoing changes regarding Tk_GetColor()
invocations within Tk, which do not pass the color name string as an
explicit Tk_Uid but a string, although Tk_GetColor()'s signature states
this being a Tk_Uid.

Why is Tk_GetColor(...Tk_Uid name...)? In olden Tk <= 8.0 times the
lookup was made per Tk_Uid (address of an interned string) combined
with Colormap and X11 Display pointer instead of a direct string.
Later Tk versions use a string for the name lookup and manage other
properties (the display etc.) by chaining the color table entries
independent of the name hash table.

My point now is: either we thoroughly follow the current Tk_GetColor()
signature and use proper Tk_Uids for the name parameter, or we change
the signature to take a const char pointer for the name. The former
option would allow for later revision of the lookup to possibly gain
from using an integer hash lookup instead of a string hash lookup.

But in any case: both described alternatives are at least consistent in
themselves whereas the current tip and core-8-branch of Tk's repository
with the ongoing changes are not.

Best regards,
Christian

Re: [TCLCORE] Tcl9 and library in zipfs

[Jan N. <jan...@gm...>]

Op do 22 aug 2024 om 16:18 schreef Eric Boudaillier:

> Hi,
>
> I've built Tcl and Tk 9.0b3 under Windows 10 with tcl_library embedded in
> the DLL (the default build).
>
> A problem with this build is that the dde and registry packages are also
> embedded inside the tcl DLL and, when [load]ed, fills the temporary
> directory with the DLL.
> Also, both packages are also present in the lib directory, which seems
> useless.
>

This doesn't sound like a real problem. You have the choice to either
    1) Remove the dll's and the pkgIndex.tcl file from the dll
    2) Remove the dll's from the lib directory
Either way, having them in both should not really hurt. The
gcc build on Windows, builds both 8.6 and 9.0 versions of
the registry and dde dll's. Then it makes sense to install
them in the lib directory, for Tcl 8.6's use. That should be
added to makefile.vc too.


> Could it be possible to statically build these packages within the Tcl DLL?
> Or leave them outside the embedded tcl_library?
>

Yes, that should be possible. There are no options for this available
in makefile.vc, but that could be added.

Hope this helps,
       Jan Nijtmans

[TCLCORE] Tcl9 and library in zipfs

[Eric B. <eri...@gm...>]

Hi,

I've built Tcl and Tk 9.0b3 under Windows 10 with tcl_library embedded in
the DLL (the default build).

A problem with this build is that the dde and registry packages are also
embedded inside the tcl DLL and, when [load]ed, fills the temporary
directory with the DLL.
Also, both packages are also present in the lib directory, which seems
useless.
Could it be possible to statically build these packages within the Tcl DLL?
Or leave them outside the embedded tcl_library?

Another problem is in the tk_library embedded archive, which contains the
"demos" and "images" directories, not needed for the runtime.

Eric

Re: [TCLCORE] Frequency of github pushes and actions

[Dipl. I. S. G. B. <se...@us...>]

 

If the mentioned costs are about GHA (CI), then it is correct...
(however one could surely speed-up several tests and make the test-suite
fewer expensive). 

If the costs means the fossil2git process - well, it is also possible to
optimize. 
Just use export- & import-marks on fossil and git side. Then the whole
export/import stuff is thousand times faster and generates a lot fewer
traffic. 

The simplest script for the latter looks like this: 

{fossil export --git --import-marks .git/.fossil2git-fssl --export-marks
.git/.fossil2git-fssl.tmp 
 | git fast-import $@ --import-marks=.git/.fossil2git-git
--export-marks=.git/.fossil2git-git.tmp 
} && {mv .git/.fossil2git-fssl.tmp .git/.fossil2git-fssl; mv
.git/.fossil2git-git.tmp .git/.fossil2git-git} 

This would firstly create marks in *.tmp and if gets ready and succeeds
would replace last marks from that tmp-state.

To do first export creating initial marks state, simply use it without
--import-marks ... for both sides, 
so it'd generate initial export-marks, that can be used by further runs.


Besides performance this has additional pros, the important one is - it
guarantees persistence of the tree - already processed revisions will be
untouched anymore, so the tree remain unchanged, even if fossil, for
example after update (as already few times happened), abrupt starts to
generate a bit different stream/hash/whatever by some revision, so
causing a tree rebuilt without marks from that ancestor. 

$@ in git args allows to supply additional arguments, e. g. --force to
overwrite branches/tags like mistake (which are non unique on fossil). 

By the way, if this marks become public, everyone can use them to push
it to GH from local repository (whole diff or single branch). 

Hope this helps,
Serg. 

21.08.2024 19:36, Brian Griffin wrote: 

> From what I recall, it is limited due to cost. 
> 
> My development process uses a MacBookPro, running two virtual machines, Linux and Windows 10. The source files are shared from the mac file system. I run only one at a time for performance reasons. Once done, I feel confident checking in. 
> 
> -Brian 
> (from mobile device) 
> 
>> On Aug 21, 2024, at 12:05, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote:
> 
>> Would if be possible to increase the frequency of github pushes (and correspondingly the action runs) to at least twice a day? 
>> 
>> I find the turnaround time to ensure commits work on all platforms before merging into trunk to be an impendiment. By the time Github actions verify the branch, the trunk has often moved on significantly. 
>> 
>> Of course, an alternative would be to commit to trunk after local verification on one platform for one build type 😊 
>> 
>> /Ashok _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [1]
 

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Frequency of github pushes and actions

[Brian G. <bri...@ea...>]

From what I recall, it is limited due to cost.

My development process uses a MacBookPro, running two virtual machines, Linux and Windows 10. The source files are shared from the mac file system. I run only one at a time for performance reasons. Once done, I feel confident checking in.

-Brian
(from mobile device)

On Aug 21, 2024, at 12:05, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote:


Would if be possible to increase the frequency of github pushes (and correspondingly the action runs) to at least twice a day?

I find the turnaround time to ensure commits work on all platforms before merging into trunk to be an impendiment. By the time Github actions verify the branch, the trunk has often moved on significantly.

Of course, an alternative would be to commit to trunk after local verification on one platform for one build type 😊

/Ashok
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] Frequency of github pushes and actions

[<apn...@ya...>]

Would if be possible to increase the frequency of github pushes (and correspondingly the action runs) to at least twice a day?

 

I find the turnaround time to ensure commits work on all platforms before merging into trunk to be an impendiment. By the time Github actions verify the branch, the trunk has often moved on significantly.

 

Of course, an alternative would be to commit to trunk after local verification on one platform for one build type 😊

 

/Ashok

Re: [TCLCORE] Call for contributions: Tk 9 migration wiki pages

[Paul O. <pa...@po...>]

Hi Harald,

there are several obsolete Tk_* and Tkp* functions, as well as obsolete TK_* constants.
These are described in section "Changes in C" on my porting experience page https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9.

You may either add these obsolete functions and constants or just add a link to that section:
https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9#f87714755b201b40e03a7e705d8847363e6f6437b52305dd3493920ebe097584

Paul

Am 20.08.2024 um 11:31 schrieb Harald Oehlmann:
> Dear Tk team,
>
> the TCL 9 fossil wiki features TCL 9 migration pages for scripts and C level.
>
> This is now also available for Tk:
>
> https://core.tcl-lang.org/tk/wiki?name=Migrating+scripts+to+Tk+9
>
> https://core.tcl-lang.org/tk/wiki?name=Migrating+C+extensions+to+Tk+9
>
> Please feel free to add items which are special when migrating Tk from Tk 8.6 to Tk 9.0.
>
> I did not find the TIP that options (like -underline) now take the empty string instead "-1" for no underline.
> This is definitively missing.
>
> As a side note, I had issues to access the wiki due to missing permissions. Feel free to speak up if this is the case.
>
> Thanks for all,
> Harald
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Call for contributions: Tk 9 migration wiki pages

[Harald O. <har...@el...>]

Am 20.08.2024 um 13:30 schrieb Csaba Nemethi:
>  From TIP 577: Enhanced index values for Tk:
> 
> "... the empty string is accepted in Tk as valid index. It means the 
> same as -1 so not available. ... The default value of the -underline 
> option becomes the empty string. Setting -underline to the empty string 
> means no underlining. ..."
> 
> Best regards,
> 
> Csaba
> 
> 
> Am 20.08.24 um 11:31 schrieb Harald Oehlmann:
> 
>> I did not find the TIP that options (like -underline) now take the 
>> empty string instead "-1" for no underline.
>> This is definitively missing.
> 

Great !
I just changed the wiki page. Is this ok like that?

Thanks for all,
Harald

Re: [TCLCORE] Call for contributions: Tk 9 migration wiki pages

[Csaba N. <csa...@t-...>]

 From TIP 577: Enhanced index values for Tk:

"... the empty string is accepted in Tk as valid index. It means the 
same as -1 so not available. ... The default value of the -underline 
option becomes the empty string. Setting -underline to the empty string 
means no underlining. ..."

Best regards,

Csaba


Am 20.08.24 um 11:31 schrieb Harald Oehlmann:

> I did not find the TIP that options (like -underline) now take the empty 
> string instead "-1" for no underline.
> This is definitively missing.

-- 
Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...

Re: [TCLCORE] Tcl user forum?

[Gustaf N. (sslmail) <ne...@wu...>]

> On 17.08.2024, at 10:18, Colin Macleod via Tcl-Core <tcl...@li...> wrote:
> 
> Nice - I have competition  :-)

we have to spread the word….. 

i made the interaction like it is such it works on easily with my fingers on the smartphone…
-g

[TCLCORE] Call for contributions: Tk 9 migration wiki pages

[Harald O. <har...@el...>]

Dear Tk team,

the TCL 9 fossil wiki features TCL 9 migration pages for scripts and C 
level.

This is now also available for Tk:

https://core.tcl-lang.org/tk/wiki?name=Migrating+scripts+to+Tk+9

https://core.tcl-lang.org/tk/wiki?name=Migrating+C+extensions+to+Tk+9

Please feel free to add items which are special when migrating Tk from 
Tk 8.6 to Tk 9.0.

I did not find the TIP that options (like -underline) now take the empty 
string instead "-1" for no underline.
This is definitively missing.

As a side note, I had issues to access the wiki due to missing 
permissions. Feel free to speak up if this is the case.

Thanks for all,
Harald

[TCLCORE] macOS Sequoia and Tk

[Marc C. <cul...@gm...>]

I installed the beta version of macOS Sequioa, along with XCode 16.1beta
and I built and tested the main branch of Tk.

There were new test failures.   The failing tests are:
WnixWm-59.2-59.3 and window-2.5-2,11

I think that all of them are caused by messages which Apple prints to
stderr.  These messages also appear in the terminal when you run wisn.
There are two of them. They seem to only occur when an interpreter is
created.  They look like this:

+[IMKClient subclass]: chose IMKClient_Legacy
+[IMKInputSession subclass]: chose IMKInputSession_Legacy

I believe that this is related to the fact that Aqua Tk implements the
NSTextInputClient protocol, which is the thing that causes a pop-up menu
with accented versions of a letter to appear when you hold down the key for
the letter in a Text or Entry widget.

I don't know of any Tk code which chooses a legacy subclass, and I don't
know why this message is being printed.  If we are lucky the message will
go away when the OS is actually released.  But Apple tends to forget to
remove these things.  They did finally remove the annoying message that
would be printed to stderr whenever a file dialog was opened.  That took a
year and a new OS release before it happened.  It was reported as a bug,
and Apple never responded to the report or acknowledged the bug, as is
typical for them.  If someone would like to report this to Apple, that
would be great.  (I have stopped bothering to do that, after many bug
reports that were completely ignored.)

- Marc

[TCLCORE] Dropping into standard repl from script - piperepl patch

[<jul...@pr...>]

Hi All,
There are occasionally requests for how to drop into the tclsh repl from 
a script - perhaps after an error for debugging.
The usual advice seems to be to create a small repl in script. This is 
at least inconvenient and probably not compatible with uparrow history 
etc(?)

The first inclination probably is to play with ::tcl_interactive to see 
if that will help - but it doesn't.
In Tcl_MainEx - ::tcl_interactive is mapped via Tcl_Linkvar to the 
is.tty c value  - but unfortunately (namewise at least) this isn't a 
direct  correspondence to what people would consider isatty.
This is because in Tcl it is set to zero when a script is run (as 
documented)  - even though (when not part of a pipeline) there can still 
be a terminal.

As I also have a usecase for dropping into the *real* repl - I've 
developed a patch for tclMain.c to experiment with this. (developed 
against latest tcl9)

I'm referring to this patch project as: piperepl
It is only active if ::env(TCLSH_PIPEREPL) is set true. (with minor 
effects re tclsh array noted below)

It uses some linked variables in  a global ::tclsh array to allow a 
script to very simply set whether the repl should run after the script. 
(and possibly whether stdin should be evaluated as commands)

In the standard 'tclsh <script>' case It does this by dropping through 
to the normal repl code, and in the case of a pipeline, by reopening 
stdin on the console after we get eof on stdin.
For example error.tcl  - the first 2 lines enable the behaviour.

    ------- error.tcl -------
    set ::tclsh(dorepl) 1
    set ::tcl_interactive 1 ;#Not required - but not as pretty without it
    set myval whatever
    error "something is wrong"
    --------------------------

With ::env(TCLSH_PIPEREPL) = 1 you can now drop straight into the repl 
and examine variables errors etc.

If you use:
printf "puts test" | tclsh
Like standard tclsh it will just evaluate "puts test"

printf "set ::tclsh(dorepl) 1; puts test" | tclsh
will evaluate the script from stdin and also drop into the repl - but 
unless you also set ::tcl_interactive 1 in the printf statement - you'll 
get it without prompts.

For security reasons.. (and consistency with standard tclsh)
printf "puts test" | tclsh <script>
will not evaluate the printf script from stdin - and in this case you 
can't of course influence it with ::tclsh(dorepl) in the piped in value
This makes sense because the data being piped in to a script shouldn't 
be assumed to be commands for evaluation anyway
The data on stdin may or may not be read by the script - but any 
remaining unconsumed is currently just stored in ::tclsh(inputbuffer)
A script can decide it does want the stdin from the pipeline to be 
evaled  by setting ::tclsh(evalinput)  (but there is deliberately no way 
to set that from the stdin pipeline in this case)

In the above error.tcl case - it may be inconvienent to have 
tclsh(dorepl) true and always drop into the shell
By setting tclsh(evalinput) 1 in the .tcl script instead of 
tclsh(dorepl) - you can run tclsh error.tcl  in the normal terminating 
manner - and call it as printf "set tclsh(dorepl) 1; set tcl_interactive 
1" | tclsh error.tcl  when you want the full repl.


I believe the result is that even with the TCLSH_PIPEREPL environment 
variable enabled - when the tclsh(x) vars aren't set in scripts it 
should be consistent with standard tclsh - aside from creating the 
global ::tclsh array
Which I understand may be an issue - and am open to renaming/namespacing 
if that is possible - although I think it's quite reasonable for the 
functionality.
The tclsh(istty) variable is I think a useful addition at the script 
level anyway - as tcl_interactive doesn't serve this purpose.

Only tested on windows (but when reopening to console, a line to open 
/dev/tty is included when not on windows - so maybe that works?)

Is anyone interested in this feature - and does anyone here have any 
comments regarding feasibility/desirability for something like this to 
be included in future?

I believe, but haven't tested; that it shouldn't have any impact on Tk 
startup or other custom startup but note that I'm not experienced with c 
programming or Tcl internals.
I've read about refcounts and various bits and pieces - and tried to use 
examples from elsewhere in the source to get close to doing the right 
thing - but it definitely needs scrutiny
Code review/comments would be most welcome even if this doesn't look 
like a candidate for inclusion in Tcl proper.

There is a somewhat ugly debugging message in the attached patch to show 
when console reopen is about to happen - left in for evaluation purposes 
show what it's doing.

I've tried to use the same tab/space conventions as the rest of the file 
- but I'm not entirely sure I got that right.
Patch made from cmd.exe with diff -u --binary tclMain.c tclMain_piperepl.c
lineendings are unix lf

Cheers,
Julian (JMN on wiki)

Re: [TCLCORE] TIP #552 changes to ttk::treeview

[Francois V. <fvo...@fr...>]

Le 18/08/2024 à 12:35, Schelte Bron a écrit :
>> Can you please show what the unmerged changes are? It's hard to tell 
>> what to do without seeing what this is about.
>>
> Apparently I failed to notice that I did merge the same changes from 
> core-8-6-branch to core-8-branch. The advantage of that is that it 
> makes it very easy to identify them:
>
> tcl/tk87/tests> fossil diff -ci 5f6a8efaea .
> Index: tests/entry.test
> ==================================================================
> --- tests/entry.test
> +++ tests/entry.test
> @@ -1009,11 +1009,11 @@
>  } -body {
>      .e index 0
>  } -cleanup {
>      destroy .e
>  } -returnCodes {ok} -match glob -result {*}
> -test entry-3.35 {EntryWidgetCmd procedure, "index" widget command} 
> -setup {
> +test entry-3.35 {EntryWidgetCmd procedure, "index" widget command} 
> -constraints failsOnXQuarz -setup {
>      entry .e
>      pack .e ; update idletasks
>      update
>  } -body {
>  # UTF
>
> Index: tests/spinbox.test
> ==================================================================
> --- tests/spinbox.test
> +++ tests/spinbox.test
> @@ -9,10 +9,12 @@
>  package require tcltest 2.2
>  namespace import ::tcltest::*
>  eval tcltest::configure $argv
>  tcltest::loadTestedCommands
>
> +testConstraint failsOnXQuarz [expr {$tcl_platform(os) ne "Darwin" || 
> [tk windowingsystem] ne "x11" }]
> +
>  # For xscrollcommand
>  set scrollInfo {}
>  proc scroll args {
>         global scrollInfo
>         set scrollInfo $args
> @@ -1227,11 +1229,11 @@
>      .e delete 6
>      .e get
>  } -cleanup {
>      destroy .e
>  } -result 0123457890
> -test spinbox-3.24 {SpinboxWidgetCmd procedure, "delete" widget 
> command} -setup {
> +test spinbox-3.24 {SpinboxWidgetCmd procedure, "delete" widget 
> command} -constraints failsOnXQuarz -setup {
>      spinbox .e
>      pack .e
>      update
>      set x {}
>  } -body {
> @@ -1345,11 +1347,11 @@
>  } -body {
>      .e index 0
>  } -cleanup {
>      destroy .e
>  } -returnCodes {ok} -match glob -result {*}
> -test spinbox-3.35 {SpinboxWidgetCmd procedure, "index" widget 
> command} -setup {
> +test spinbox-3.35 {SpinboxWidgetCmd procedure, "index" widget 
> command} -constraints failsOnXQuarz -setup {
>      spinbox .e
>      pack .e
>      update
>  } -body {
>  # UTF
>
> So I guess these must either be removed again from 8.7 or added to 
> 9.0. If someone can inform me which direction to go, I can take care 
> of that.

Oh, right, this comes from this commit:

     https://core.tcl-lang.org/tk/info/fe177b079984eadd

Jan, please correct me if I'm wrong: These changes should have been 
merged forward. What this commit tries to address is the following 
ticket, which applies to all branches:

     https://core.tcl-lang.org/tk/tktview/36e379c01b

Currently, because of this problem, the CI runners have been totally 
disabled for macOS with XQuartz. There is an identification effort of 
the affected tests going on (and which seems to be over just now, see 
Github Actions) in branch:

     https://core.tcl-lang.org/tk/timeline?r=bug-36e379c01b

I also have a work in progress with a slightly different approach in my 
less_tests_constraints branch but never mind.

Regards,

Francois

Re: [TCLCORE] TIP #552 changes to ttk::treeview

[Schelte B. <tc...@tc...>]

Hello Francois,

Thanks for looking into this.

On 17/08/2024 17:43, Francois Vogel wrote:
> I can't manage to show any performance difference between current 
> core-8-6-branch and trunk with, say, the following script:
> 
> package require Tk
> ttk::treeview .t
> for {set i 1} {$i <= 1000000} {incr i} {
>      set val "This is item $i"
>      .t insert {} end -text "Item # $i" -values $val
> }
> pack .t -expand true -fill both
> time [.t see I100]
> 
> The last 'time' command (which exercises DrawForest()) returns a small 
> number of microseconds with both core-8-6-branch and trunk.
> 
> Moreover, with both core-8-6-branch and trunk, adding a printf in 
> DrawItem() shows that not all treeview items are drawn by DrawForest(), 
> contrary to your claim. Only a small number of items are drawn.
> 
The reason your time command doesn't show any difference between 
core-8-6-branch and trunk is because the actual drawing doesn't happen 
until idle time. This is confirmed by a printf() in DrawForest(), which 
prints after `time` reports its results.

I changed your script to:

package require Tk
ttk::treeview .t
for {set i 1} {$i <= 1000000} {incr i} {
     set val "This is item $i"
     .t insert {} end -text "Item # $i" -values $val
}
pack .t -expand true -fill both
update idletasks
.t see I100
set us [clock microseconds]
update idletasks
puts [expr {[clock microseconds] - $us}]

This reports a time that is over twice as long on trunk (around 100ms on 
my machine) as it is on core-8-6-branch (around 50ms).

But when I took a closer look based on your remark that only a small 
number of items are drawn, I see that DisplayRow() prevents items that 
are off screen from actually being drawn. Still, it seems that things 
could be done more efficient than checking every item. I may give that a 
try when I have some time.

I also noticed that 8.6 starts looping from the top item. The only 
difference is that it stops after it has done the visible items. As a 
result scrolling gets more sluggish the further down the list you go. 
The 9.0 version doesn't have that issue. It is equally sluggish 
everywhere. So maybe there's a reason it is not possible to just start 
at tv->tree.yscroll.first (after any title rows) and only do the visible 
rows that I don't see right now. I guess I'll find out when I try to 
improve things.

> Can you please show what the unmerged changes are? It's hard to tell 
> what to do without seeing what this is about.
> 
Apparently I failed to notice that I did merge the same changes from 
core-8-6-branch to core-8-branch. The advantage of that is that it makes 
it very easy to identify them:

tcl/tk87/tests> fossil diff -ci 5f6a8efaea .
Index: tests/entry.test
==================================================================
--- tests/entry.test
+++ tests/entry.test
@@ -1009,11 +1009,11 @@
  } -body {
      .e index 0
  } -cleanup {
      destroy .e
  } -returnCodes {ok} -match glob -result {*}
-test entry-3.35 {EntryWidgetCmd procedure, "index" widget command} -setup {
+test entry-3.35 {EntryWidgetCmd procedure, "index" widget command} 
-constraints failsOnXQuarz -setup {
      entry .e
      pack .e ; update idletasks
      update
  } -body {
  # UTF

Index: tests/spinbox.test
==================================================================
--- tests/spinbox.test
+++ tests/spinbox.test
@@ -9,10 +9,12 @@
  package require tcltest 2.2
  namespace import ::tcltest::*
  eval tcltest::configure $argv
  tcltest::loadTestedCommands

+testConstraint failsOnXQuarz [expr {$tcl_platform(os) ne "Darwin" || 
[tk windowingsystem] ne "x11" }]
+
  # For xscrollcommand
  set scrollInfo {}
  proc scroll args {
         global scrollInfo
         set scrollInfo $args
@@ -1227,11 +1229,11 @@
      .e delete 6
      .e get
  } -cleanup {
      destroy .e
  } -result 0123457890
-test spinbox-3.24 {SpinboxWidgetCmd procedure, "delete" widget command} 
-setup {
+test spinbox-3.24 {SpinboxWidgetCmd procedure, "delete" widget command} 
-constraints failsOnXQuarz -setup {
      spinbox .e
      pack .e
      update
      set x {}
  } -body {
@@ -1345,11 +1347,11 @@
  } -body {
      .e index 0
  } -cleanup {
      destroy .e
  } -returnCodes {ok} -match glob -result {*}
-test spinbox-3.35 {SpinboxWidgetCmd procedure, "index" widget command} 
-setup {
+test spinbox-3.35 {SpinboxWidgetCmd procedure, "index" widget command} 
-constraints failsOnXQuarz -setup {
      spinbox .e
      pack .e
      update
  } -body {
  # UTF

So I guess these must either be removed again from 8.7 or added to 9.0. 
If someone can inform me which direction to go, I can take care of that.


Schelte

Re: [TCLCORE] TIP #552 changes to ttk::treeview

[Francois V. <fvo...@fr...>]

Le 16/08/2024 à 18:06, Schelte Bron a écrit :
> While merging the fix for bug d82fa2953a into Tk 8.7 and 9.0, I 
> noticed that a change had been made where now all treeview items are 
> always drawn by DrawForest() when in the past (i.e. Tk 8.6) only the 
> visible items would be drawn. This seems like it may cause some 
> performance degradation on treeview widgets with a lot of items. 
> Especially since the widget is redrawn quite frequently in response to 
> mouse or keyboard activity. I did not measure how much of a 
> performance degradation this causes, but I couldn't help but wonder if 
> it is really necessary to redraw lots of items over and over when they 
> aren't visible anyway.

I can't manage to show any performance difference between current 
core-8-6-branch and trunk with, say, the following script:

package require Tk
ttk::treeview .t
for {set i 1} {$i <= 1000000} {incr i} {
     set val "This is item $i"
     .t insert {} end -text "Item # $i" -values $val
}
pack .t -expand true -fill both
time [.t see I100]

The last 'time' command (which exercises DrawForest()) returns a small 
number of microseconds with both core-8-6-branch and trunk.

Moreover, with both core-8-6-branch and trunk, adding a printf in 
DrawItem() shows that not all treeview items are drawn by DrawForest(), 
contrary to your claim. Only a small number of items are drawn.


> I also found that some changes to entry.test and spinbox.test had not 
> been merged from Tk core-8-branch to trunk. As I was unsure why that 
> was omitted, I excluded them from my merge. I don't know if that means 
> they are now being ignored by fossil for future merges. If that is the 
> case and these changes should make it into 9.0, manual action may be 
> needed.
Yes, from now on these changes will be ignored by fossil for future merges.

Can you please show what the unmerged changes are? It's hard to tell 
what to do without seeing what this is about.

Regards,

Francois

Re: [TCLCORE] Tcl user forum?

[Colin M. <col...@ya...>]

Nice - I have competition  :-)

On 16/08/2024 14:43, Gustaf Neumann (sslmail) wrote:
> Dear all,
>
> many thanks to the good suggestions!
>
> I’ve put a copy of the newsgroup to the demos of openacs.org
>
>      https://openacs.org/demo/comp.lang.tcl
>
> It seems to work well .... So far, it is read-only, posting is not implemented jet. It is synched all 5 minutes.
>
> All the best
> -g
>
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] TIP #552 changes to ttk::treeview

[Schelte B. <tc...@tc...>]

All,

While merging the fix for bug d82fa2953a into Tk 8.7 and 9.0, I noticed 
that a change had been made where now all treeview items are always 
drawn by DrawForest() when in the past (i.e. Tk 8.6) only the visible 
items would be drawn. This seems like it may cause some performance 
degradation on treeview widgets with a lot of items. Especially since 
the widget is redrawn quite frequently in response to mouse or keyboard 
activity. I did not measure how much of a performance degradation this 
causes, but I couldn't help but wonder if it is really necessary to 
redraw lots of items over and over when they aren't visible anyway.

I also found that some changes to entry.test and spinbox.test had not 
been merged from Tk core-8-branch to trunk. As I was unsure why that was 
omitted, I excluded them from my merge. I don't know if that means they 
are now being ignored by fossil for future merges. If that is the case 
and these changes should make it into 9.0, manual action may be needed.


Schelte