tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Questions about Tcl{Get, Set}ProcessGlobalValue functions

[Donald P. <d.g...@co...>]

I have answers, but may I please offer them to you next month?

DGP


> On Sep 25, 2025, at 5:06 AM, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote:
> 
> I have a question about the TclGetProcessGlobalValue / TclSetProcessGlobalValue pair of functions that I hope someone can answer. These functions are supposed to store values or settings that are shared across all threads in the process.
>  
> TL;DR why do the above functions get/set values using the *system* encoding?
>  
> As currently implemented, TclSetProcessGlobalValue encodes the Tcl_Obj value passed in using the current system encoding and stores it in a global C struct. It also stores the *original* passed in Tcl_Obj in a thread-local cache so that its internal representation is not lost for that thread’s usage. Use of epochs ensure the stale values are not used.
>  
> When TclGetProcessGlobalValue is called, the encoded value in the global C struct is decoded using the system encoding and the result is passed back to the caller in a new Tcl_Obj which is also stored in that thread’s cache. If this function is called without TclSetProcessGlobalValue having previous set the value, an initializer function is called which returns the initial value along with encoding used. 
>  
> The code accounts for the fact that system encoding may change (generally only during initialization when all encodings are not immediately available) by tracking the encodings used and converting appropriately as needed.
>  
> My question is - what the purpose of this encoding / decoding pair when storing and retrieving values? The passed in values are (effectively) internal modified UTF-8 strings. Why not just store return those? This is not just a question of efficiency but correctness. There are several issues with the current implementation:
>  
> A value being stored may not be representable using the current system encoding. Since the encoding is done using TCL_ENCODING_PROFILE_TCL8, essentially a “corrupted” value is stored in the global struct and returned by 
> Likewise, there is potential for further corruption for similar reasons when the system encoding changes and the new system encoding does not support additional characters.
> Further, because the *original* Tcl_Obj remains in the thread that called TclSetProcessGlobalValue, that thread’s perception of the “global” value differs from all other threads (which see the “corrupted” value).
>  
> This seems broken to me if the whole purpose was to have global values shared across threads. It neither preserves values, nor shares them correctly. From my perspective, the global value should directly reflect he string representation of the Tcl_Obj passed in. It is the responsibility of the caller to ensure the value is correct. Once in Tcl’s internal representation, changes in system encoding should not matter.
>  
> And yet, because there is all this additional explicit machinery for encoding / decoding that has been added, I believe there was some purpose behind it. If so, what was it?
>  
> As an aside, I think there are bugs with the sequence of encoding operations as well, e.g. it assumes single byte nul terminators, epochs are checked without any thread synchronization etc. but those are secondary to the questions above.
>  
> Anybody know the answer to the above?
>  
> /Ashok 
>  
> PS The context for all this is TIP 732 – trying to fully understand Tcl initialization.
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li... <mailto:Tcl...@li...>
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] Questions about Tcl{Get, Set}ProcessGlobalValue functions

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

I have a question about the TclGetProcessGlobalValue /
TclSetProcessGlobalValue pair of functions that I hope someone can answer.
These functions are supposed to store values or settings that are shared
across all threads in the process.

 

TL;DR why do the above functions get/set values using the *system* encoding?

 

As currently implemented, TclSetProcessGlobalValue encodes the Tcl_Obj value
passed in using the current system encoding and stores it in a global C
struct. It also stores the *original* passed in Tcl_Obj in a thread-local
cache so that its internal representation is not lost for that thread's
usage. Use of epochs ensure the stale values are not used.

 

When TclGetProcessGlobalValue is called, the encoded value in the global C
struct is decoded using the system encoding and the result is passed back to
the caller in a new Tcl_Obj which is also stored in that thread's cache. If
this function is called without TclSetProcessGlobalValue having previous set
the value, an initializer function is called which returns the initial value
along with encoding used. 

 

The code accounts for the fact that system encoding may change (generally
only during initialization when all encodings are not immediately available)
by tracking the encodings used and converting appropriately as needed.

 

My question is - what the purpose of this encoding / decoding pair when
storing and retrieving values? The passed in values are (effectively)
internal modified UTF-8 strings. Why not just store return those? This is
not just a question of efficiency but correctness. There are several issues
with the current implementation:

 

*	A value being stored may not be representable using the current
system encoding. Since the encoding is done using TCL_ENCODING_PROFILE_TCL8,
essentially a "corrupted" value is stored in the global struct and returned
by 
*	Likewise, there is potential for further corruption for similar
reasons when the system encoding changes and the new system encoding does
not support additional characters.
*	Further, because the *original* Tcl_Obj remains in the thread that
called TclSetProcessGlobalValue, that thread's perception of the "global"
value differs from all other threads (which see the "corrupted" value).

 

This seems broken to me if the whole purpose was to have global values
shared across threads. It neither preserves values, nor shares them
correctly. From my perspective, the global value should directly reflect he
string representation of the Tcl_Obj passed in. It is the responsibility of
the caller to ensure the value is correct. Once in Tcl's internal
representation, changes in system encoding should not matter.

 

And yet, because there is all this additional explicit machinery for
encoding / decoding that has been added, I believe there was some purpose
behind it. If so, what was it?

 

As an aside, I think there are bugs with the sequence of encoding operations
as well, e.g. it assumes single byte nul terminators, epochs are checked
without any thread synchronization etc. but those are secondary to the
questions above.

 

Anybody know the answer to the above?

 

/Ashok 

 

PS The context for all this is TIP 732 - trying to fully understand Tcl
initialization.

[TCLCORE] TIP 733: Add accessibility/screen reader support to Tk

[Kevin W. <kw...@co...>]

Hi all,

After 18 months of work, I am ready to invite review and testing of TIP 
733, adding accessibility/screen reader support to Tk: 
https://core.tcl-lang.org/tips/doc/trunk/tip/733.md. This TIP proposes 
to provide out-of-the-box accessibility in Tk on all three major 
platforms - X11, Windows and macOS. There is a detailed API for 
customization, but the design of the tk accessible command set is 
intended to make accessibility "just work" with little effort required 
by the developer.

This feature has long been requested in Tk - I found mailing list and 
Wiki entries going back two decades - but no one has implemented it. 
It's been a long-standing wish of mine to tackle this project, but I did 
not feel capable of completing the project until the past year because 
of its complexity. My experience level, understanding of Tk and various 
platform API's, and the emergence of new developer tools have made it 
possible for me to finally take this on.

The goal is to integrate this new command set into Tk 9.1, and I hope I 
have completed this project draft in time for consideration. Because 
this is a large addition to Tk, I am not looking for a rapid TIP process 
- I'd love feedback and, especially, suggestions (and code to implement 
suggested changes if possible).

Looking forward to your feedback.

Thanks,

Kevin

Re: [TCLCORE] About TIPs 727 and 729

[Emiliano <emi...@gm...>]

On Wed, 24 Sep 2025 09:52:59 +0200
Csaba Nemethi <csa...@t-...> wrote:

> This is still open, maybe we should see the opinion of further Community 
> members.  The current implementation is straightforward and works as 
> expected, but I can understand that you would prefer one in C only.

Fully agree. Thanks for your time and patience!

Regards
-- 
Emiliano <emi...@gm...>

Re: [TCLCORE] About TIPs 727 and 729

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

Le mer. 24 sept. 2025 à 09:53, Csaba Nemethi <csa...@t-...> a
écrit :

> Hi Emiliano,
>
> See my embedded comments below.
> ...
>
> >>> About the implementation: is there any technical advantage to do this
> >>> in Tcl and not C?
> >>>
> >>
> >> The implementation in Tcl is much simpler and easier to maintain.
> >> Currently it has no more than 228 LOC, of which 81 are comments or empty
> >> lines.
> >
> > Sorry, but I beg to differ on this point. A C implementation is not much
> > longer. tkcargo is 466 lines of C code and it actually have more
> functionality
> > than the one proposed here, using standard Tcl and Tk C API. It is also
> way
> > faster, mainly when the number of widgets and the number of tables become
> > quite large [1]. I've attached four files, three measuring test scripts
> and
> > a result csv file. The three test scripts are almost the same, one
> running
> > with plain Tk (not tables) to be the reference value, one with [tk
> attribtable]
> > and one with tkcargo. They are different as I just want to be sure I was
> > testing the right thing and be sure I didn't srew up things. While the
> results
> > seem somewhat noisy, the tendency is clear.
> >
> > Also, I'm not comfortable with the modification of Tk_DestroyWindow to
> > support this use case, based on two points. First, the cleanup script
> > will be forced to run even for widgets that are not in any table, a
> source
> > of slowdown. And the other is a matter of style: when introducing any
> other
> > functionality which needs to perform some cleanup when a widget is
> > destroyed, will we keep adding scripts to run?
> >
>
> This is still open, maybe we should see the opinion of further Community
> members.  The current implementation is straightforward and works as
> expected, but I can understand that you would prefer one in C only.
>
>
Since you ask... I agree with Emiliano on these two points.
This kind of code must be entirely written in C.
Invoking a specific script in Tk_DestroyWindow is not the way to go.
Also please use spaces in C code instead of tabs for indentation.

Regards,

Eric

Re: [TCLCORE] About TIPs 727 and 729

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

Hi Emiliano,

See my embedded comments below.


Am 23.09.25 um 03:06 schrieb Emiliano:
> On Mon, 22 Sep 2025 22:18:13 +0200
> Csaba Nemethi <csa...@t-...> wrote:
> 
>> Hi Emiliano,
>>
>> Many thanks for your comments!  See my answer embedded into your text.
> 
> Many thanks for taking the time to read them, and for moving this forward!
> See inline comments ...
> 
>>
>> It is common practice in Tk that commands by name are created in the
>> global namespace.  Example: image create <type> <name> ...  Here the
>> <name> command is always created in the global namespace.  Why should we
>> break this rule?
> 
> Tk predates namespaces, so compatibility plays an important role here.
> But this is not the case with this functionality, which is meant to be used
> primarily by package developers, so they are expected to put all their data
> inside a namespace.
> 
> That said, even the current docs recommends, in case of images, to use
> namespaces. image(n) reads "It is important to note that the image command
> will silently overwrite any procedure that may currently be defined by the
> given name, so choose the name wisely. It is recommended to use a separate
> namespace for image names (e.g., ::img::logo, ::img::large)."
> 
> I'll argue that, while *named* images should be created from the global
> scope (so they are easier to find), non-named images, as created by
> [image create $type -opt ...] should be created in the current namespace
> as the returned name will be assigned to a variable anyway. Just as
> [oo::object new] does.
> 

The new version creates the attribute table of a given name as a 
procedure in the namespace of the calling context if not fully qualified.

>> The implementation already makes sure that an already existing tableName
>> command will be overwritten.  This is explicitly mentioned in the manual:
>>
>>       "If an attribute table of the given name already exists then it is
>> replaced with the new one and all the attributes of all widgets set
>> using the old table instance will be unset."
> 
> Sorry, didn't read the docs, just the tip. My bad!
> 
>> Also, in all the tableName instance subcommands, if pathName doesn't
>> exist then the implementation already raises an error.  This is valid
>> for all op names (set|get|names|unset|clear|exists).  Why should the
>> "exists" case be handled differently?
> 
> For the same reason [winfo] returns an error when asked for info about a
> non-existing widget but doesn't when asked about whether it [winfo exists].
> It should return just true or false.
>   

The exists subcommand no longer checks whether the path name specifies 
an existing widget.

>>> * tableName set
>>>
>>> Preference to return the full key-value pair for pathName in
>>> tableName, just as [dict set] does.
>>>
>>
>> What would this be good for?  Do you have a convincing use case?  Would
>> it have any benefit over retrieving this information via "tableName get" ?
> 
> No. As said, just consistency with [dict set]. While I like consistency, this
> can be left out. Fine with me.
> 

No action here.

>>> * tableName names
>>>
>>> Preferred API
>>>
>>>     ** tableName names ?pathName?
>>>
>>> returning the list of path names in tableName if pathName is not
>>> specified. Otherwise, it returns the list of keys already set for
>>> pathName in tableName.
>>>
>>
>> Here, the word "names" always refers to attribute names, aka keys.  Your
>> proposal would add a second meaning to it.  What about a new subcommand
>> "tableName pathnames" instead?
> 
> Also fine with me. This is also for the sake of consistency. When some
> functionality in Tcl or Tk uses a handle or any kind of mapping, the "names"
> subcommand (array names, image names ...) usually is a list of keys.
> In this case, we have two cascade mappings in play: window -> attributes
> dictionary and attribute (or key, or name ... ) -> value. I simply thought
> in collapsing both in a single command.
> 

Now I have added a pathnames subcommand.

>>> About the implementation: is there any technical advantage to do this
>>> in Tcl and not C?
>>>
>>
>> The implementation in Tcl is much simpler and easier to maintain.
>> Currently it has no more than 228 LOC, of which 81 are comments or empty
>> lines.
> 
> Sorry, but I beg to differ on this point. A C implementation is not much
> longer. tkcargo is 466 lines of C code and it actually have more functionality
> than the one proposed here, using standard Tcl and Tk C API. It is also way
> faster, mainly when the number of widgets and the number of tables become
> quite large [1]. I've attached four files, three measuring test scripts and
> a result csv file. The three test scripts are almost the same, one running
> with plain Tk (not tables) to be the reference value, one with [tk attribtable]
> and one with tkcargo. They are different as I just want to be sure I was
> testing the right thing and be sure I didn't srew up things. While the results
> seem somewhat noisy, the tendency is clear.
> 
> Also, I'm not comfortable with the modification of Tk_DestroyWindow to
> support this use case, based on two points. First, the cleanup script
> will be forced to run even for widgets that are not in any table, a source
> of slowdown. And the other is a matter of style: when introducing any other
> functionality which needs to perform some cleanup when a widget is
> destroyed, will we keep adding scripts to run?
> 

This is still open, maybe we should see the opinion of further Community 
members.  The current implementation is straightforward and works as 
expected, but I can understand that you would prefer one in C only.

> Regards
> 
> Emiliano
> 

Thanks again for your feedback!

Best regards,

Csaba

> [1] Result also show something that looks like O(n^2) when detroying large
> number of widgets, for example a frame with several thousand children. But
> this has to be investigated independently of the ongoing discussion.
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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

Re: [TCLCORE] About TIPs 727 and 729

[bch <bra...@gm...>]

> On Sep 23, 2025, at 09:01, Donal Fellows <don...@ma...> wrote:
> 
> 
> Emiliano wrote:
> That said, even the current docs recommends, in case of images, to use namespaces. image(n) reads "It is important to note that the image command will silently overwrite any procedure that may currently be defined by the given name, so choose the name wisely. It is recommended to use a separate namespace for image names (e.g., ::img::logo, ::img::large)."
> 
> I remember writing that. It was based on the experience of doing [image create photo open ...] to make the icon for a button used to open files, and then wondering why my program broke! The important thing is avoiding overwriting existing commands.
> 
> The actual workaround I originally used (in Tk 4.0, so a good while ago) was using default-named images and storing their handles in an array indexed by the names I really wanted.

What I do in my command-generating-code is test ( if(NULL!=Tcl_GetCommandFromObj(interp, objv[objc-1]){…; return TCL_ERROR}) - if overwriting is warranted, a “-force bool” switch can be used, but otherwise, it seems dangerous/disrespectful to blindly nuke another command. Or test the objProc and only nuke the packages own types…

% bch_pkg mk -foo 8 -bar mars puts ;# “puts” == name to be generated

Is a typical test in my development that has better fail.

-bch


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

Re: [TCLCORE] About TIPs 727 and 729

[Donal F. <don...@ma...>]

Emiliano wrote:
That said, even the current docs recommends, in case of images, to use namespaces. image(n) reads "It is important to note that the image command will silently overwrite any procedure that may currently be defined by the given name, so choose the name wisely. It is recommended to use a separate namespace for image names (e.g., ::img::logo, ::img::large)."

I remember writing that. It was based on the experience of doing [image create photo open ...] to make the icon for a button used to open files, and then wondering why my program broke! The important thing is avoiding overwriting existing commands.

The actual workaround I originally used (in Tk 4.0, so a good while ago) was using default-named images and storing their handles in an array indexed by the names I really wanted.

Donal.

[TCLCORE] tcl/tk 9.0.2 build error

[Zaumseil R. <RZa...@kk...>]

Hello

Building tcl/tk under windows msys/mingw is successful.
The created binaries, tclsh90s.exe and wish90s.exe, are running.

But when I try to append an additional directory to build a BI executable
I got an error when running the zip command: "file structure invalid"

I could verify with renaming the .exe files to .zip an trying to open in zip.
This fails on both, tclsh and wish.

After inserting the following line (it was removed in 9.0.2) in the tcl/win/Makefile.in and tk/win/makefile.in
in the TCLSH and WISH targets everything is working as before:

                       ${NATIVE_ZIP} -A ${TCLSH} \
                          || echo 'ignore zip-error by adjust sfx process (not executable?)'; \

Is this an error or intended behaviour?
Do I have to change something?

Regards
Rene

Re: [TCLCORE] About TIPs 727 and 729

[nicolas b. <sl1...@gm...>]

Hi Csaba,
about TIP 727 (ttk::toggleswitch), I've tried your code with my app on both
macOS and Windows.
I had to remove package require tsw and replace tsw::toggleswitch with
ttk::toggleswitch in my code.
it works very fine on both platforms (on Windows I do use the awdark theme)

best regards,
Nicolas

Le mar. 23 sept. 2025 à 03:08, Emiliano <emi...@gm...> a écrit :

> On Mon, 22 Sep 2025 22:18:13 +0200
> Csaba Nemethi <csa...@t-...> wrote:
>
> And, as usual, forgot to attach the files!! Sorry.
>
> Regards
>
> Emiliano
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

[TCLCORE] Summary of online meet 2025-09-22

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

Summary of yesterday's online meeting.

 

Attendees: Reinhard, Rolf, Steve, Jan, Schelte, Don, Ashok

 

1. The first topic covered in the meeting was the creation of "official"
batteries-included binary distributions for the three major platforms. There
was general agreement from those who have used it that Paul's BAWT build
system would form a good basis for the effort. While the initial suggestion
was to use GitHub actions for the purpose, Steve suggested that having
volunteers for each platform would be an alternative given possible issues
with usage limits on GitHub actions and requirement for additional steps
such as MacOS binary signatures. The question of the packaging mechanisms
for Linux binaries was raised with suggested solutions including static
binaries, SNAP, Flatpack and Docker. The decision is best left to whoever
volunteers for the Linux platform. With regards to signing, Steve will talk
to Phil Brooks about obtaining signing certificates. Paul clarified that
BAWT cannot currently pull from source repositories but downloads release
archives. Ashok commented that the package authors have the responsibility
for creating official releases of their packages if they are to be included
in the official distribution.

 

Next steps: need volunteers for each of the platforms - Windows, Linux and
MacOS - and someone to oversee / drive the project. The build process using
BAWT as well as its internal design is very well documented, so prospective
volunteers are encouraged to try it out. Without platform volunteers, this
project will go nowhere.

 

2. The second topic of discussion was the ticket regarding implementation of
recursive mutexes already under discussion in
https://core.tcl-lang.org/tcl/info/893f8cc5db3ba8bd. Jan said he had a
working fix for Unix that he was satisfied with but the Windows equivalent
was still crashing and needed further work. [Editorial comment: as discussed
in the previous ticket link, both Sergey and Ashok are still of the opinion
that Tcl should stick to non-reentrant mutexes so the matter is not entirely
closed but for now there is a partial fix in place.]

 

3. Ashok introduced TIP 732 which seeks to formalize and streamline Tcl
interpreter creation and search for its libraries. The TIP is still work in
progress but it was the general opinion this was an area worth addressing.

 

4. Steve provided an update on the effort to move core to TCT controlled
infrastructure on linode for the reasons he cited in his earlier email to
the core mailing list. The transition is targeted for some time next month
and should hopefully be transparent to users. As part of the transition, 2FA
will be introduced and a team of maintainers will be formed.

 

5. Schelte raised the issue of core notifications being broken after the
reboot a few days ago. There was a fair amount of discussion around this but
I'm afraid I could not follow the technical details to be able to summarize
this. 

 

6. Andreas raised similar issue with the Slack bridge to the chat. It
appears Roy has now fixed this.

 

 

[TCLCORE] Looking for help getting a widget's CGContext on MacOS

[Andrew C. <and...@gm...>]

Hello everyone!

I've been working on a Tk widget that uses Cairo for more complex drawings
rather than the standard Tk functions.

I've had great success on Windows and Linux, but not so much on MacOS. I'm
able to get the widget's's associated NSView using TkMacOSXGetRootControl,
but as far as I can tell I still need to somehow derive a CGContext to pass
to Cairo's cairo_quartz_surface_create_for_gc_context.

I was just wondering if anyone would have any thoughts on simple ways to
bridge an NSView to a CGContext? Hopefully I am attacking this problem from
the right angle and asking in the right place.

Any thoughts would be greatly appreciated.

Many thanks in advance!
Andrew

Re: [TCLCORE] About TIPs 727 and 729

[Emiliano <emi...@gm...>]

On Mon, 22 Sep 2025 22:18:13 +0200
Csaba Nemethi <csa...@t-...> wrote:

And, as usual, forgot to attach the files!! Sorry.

Regards

Emiliano

Re: [TCLCORE] About TIPs 727 and 729

[Emiliano <emi...@gm...>]

On Mon, 22 Sep 2025 22:18:13 +0200
Csaba Nemethi <csa...@t-...> wrote:

> Hi Emiliano,
> 
> Many thanks for your comments!  See my answer embedded into your text.

Many thanks for taking the time to read them, and for moving this forward!
See inline comments ...

> 
> It is common practice in Tk that commands by name are created in the 
> global namespace.  Example: image create <type> <name> ...  Here the 
> <name> command is always created in the global namespace.  Why should we 
> break this rule?

Tk predates namespaces, so compatibility plays an important role here.
But this is not the case with this functionality, which is meant to be used
primarily by package developers, so they are expected to put all their data
inside a namespace.

That said, even the current docs recommends, in case of images, to use
namespaces. image(n) reads "It is important to note that the image command
will silently overwrite any procedure that may currently be defined by the
given name, so choose the name wisely. It is recommended to use a separate
namespace for image names (e.g., ::img::logo, ::img::large)."

I'll argue that, while *named* images should be created from the global
scope (so they are easier to find), non-named images, as created by
[image create $type -opt ...] should be created in the current namespace
as the returned name will be assigned to a variable anyway. Just as
[oo::object new] does.

> The implementation already makes sure that an already existing tableName 
> command will be overwritten.  This is explicitly mentioned in the manual:
> 
>      "If an attribute table of the given name already exists then it is 
> replaced with the new one and all the attributes of all widgets set 
> using the old table instance will be unset."

Sorry, didn't read the docs, just the tip. My bad!

> Also, in all the tableName instance subcommands, if pathName doesn't 
> exist then the implementation already raises an error.  This is valid 
> for all op names (set|get|names|unset|clear|exists).  Why should the 
> "exists" case be handled differently?

For the same reason [winfo] returns an error when asked for info about a
non-existing widget but doesn't when asked about whether it [winfo exists].
It should return just true or false.
 
> > * tableName set
> > 
> > Preference to return the full key-value pair for pathName in
> > tableName, just as [dict set] does.
> > 
> 
> What would this be good for?  Do you have a convincing use case?  Would 
> it have any benefit over retrieving this information via "tableName get" ?

No. As said, just consistency with [dict set]. While I like consistency, this
can be left out. Fine with me.

> > * tableName names
> > 
> > Preferred API
> > 
> >    ** tableName names ?pathName?
> > 
> > returning the list of path names in tableName if pathName is not
> > specified. Otherwise, it returns the list of keys already set for
> > pathName in tableName.
> > 
> 
> Here, the word "names" always refers to attribute names, aka keys.  Your 
> proposal would add a second meaning to it.  What about a new subcommand 
> "tableName pathnames" instead?

Also fine with me. This is also for the sake of consistency. When some
functionality in Tcl or Tk uses a handle or any kind of mapping, the "names"
subcommand (array names, image names ...) usually is a list of keys.
In this case, we have two cascade mappings in play: window -> attributes
dictionary and attribute (or key, or name ... ) -> value. I simply thought
in collapsing both in a single command.

> > About the implementation: is there any technical advantage to do this
> > in Tcl and not C?
> > 
> 
> The implementation in Tcl is much simpler and easier to maintain. 
> Currently it has no more than 228 LOC, of which 81 are comments or empty 
> lines.

Sorry, but I beg to differ on this point. A C implementation is not much
longer. tkcargo is 466 lines of C code and it actually have more functionality
than the one proposed here, using standard Tcl and Tk C API. It is also way
faster, mainly when the number of widgets and the number of tables become
quite large [1]. I've attached four files, three measuring test scripts and
a result csv file. The three test scripts are almost the same, one running
with plain Tk (not tables) to be the reference value, one with [tk attribtable]
and one with tkcargo. They are different as I just want to be sure I was
testing the right thing and be sure I didn't srew up things. While the results
seem somewhat noisy, the tendency is clear.

Also, I'm not comfortable with the modification of Tk_DestroyWindow to
support this use case, based on two points. First, the cleanup script
will be forced to run even for widgets that are not in any table, a source
of slowdown. And the other is a matter of style: when introducing any other
functionality which needs to perform some cleanup when a widget is
destroyed, will we keep adding scripts to run?

Regards

Emiliano

[1] Result also show something that looks like O(n^2) when detroying large
number of widgets, for example a frame with several thousand children. But
this has to be investigated independently of the ongoing discussion.

Re: [TCLCORE] About TIPs 727 and 729

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

Hi Emiliano,

Many thanks for your comments!  See my answer embedded into your text.

Am 22.09.25 um 17:48 schrieb Emiliano G:
> El jue, 18 sept 2025 a las 16:24, Csaba Nemethi
> (<csa...@t-...>) escribió:
>>
>> As announced below, a few days ago I committed a thoroughly updated
>> implementation of the element creation for ttk::toggleswitch widgets
>> (TIP 727).  The new version contains both generic code for arbitrary
>> themes and theme-specific one for a few built-in themes.
>>
>> Today I committed a revisited version of TIP 729, whose title now reads
>> "Add a tk attribtable command to the core" (the initial one was "Add a
>> tk_cargo procedure to the core").  The new version made it necessary to
>> rework large parts of the implementation, which I committed today, too.
>>
>> Comments on both TIPs are highly appreciated.
> 
> Some comments about tip 729, most of which are personal preferences:
> 
> * tk attribtable tableName
> 
> My preference for the tableName command to be created in the current
> namespace if not fully qualified. This will ease the handling of
> attribute tables when implemented as TclOO objects. If tableName
> already exists, it is overwritten. Also, in all the tableName instance
> subcommands, if pathName doesn't exist my preference is to raise an
> error, except in [tableName exists].
> 

It is common practice in Tk that commands by name are created in the 
global namespace.  Example: image create <type> <name> ...  Here the 
<name> command is always created in the global namespace.  Why should we 
break this rule?

The implementation already makes sure that an already existing tableName 
command will be overwritten.  This is explicitly mentioned in the manual:

     "If an attribute table of the given name already exists then it is 
replaced with the new one and all the attributes of all widgets set 
using the old table instance will be unset."

Also, in all the tableName instance subcommands, if pathName doesn't 
exist then the implementation already raises an error.  This is valid 
for all op names (set|get|names|unset|clear|exists).  Why should the 
"exists" case be handled differently?

> * tableName set
> 
> Preference to return the full key-value pair for pathName in
> tableName, just as [dict set] does.
> 

What would this be good for?  Do you have a convincing use case?  Would 
it have any benefit over retrieving this information via "tableName get" ?

> * tableName get
> 
> Preferred API
> 
>    ** tableName get pathName ?key? ?defaultvalue?
> 
> If there's no such "key" entry, "defaultvalue" is returned if
> specified, or an empty string otherwise, just as [ttk::style lookup]
> does.
> 

OK, this is a decent proposal, I will implement it.

> * tableName names
> 
> Preferred API
> 
>    ** tableName names ?pathName?
> 
> returning the list of path names in tableName if pathName is not
> specified. Otherwise, it returns the list of keys already set for
> pathName in tableName.
> 

Here, the word "names" always refers to attribute names, aka keys.  Your 
proposal would add a second meaning to it.  What about a new subcommand 
"tableName pathnames" instead?

> * tableName clear
> 
> I prefer the description "Unsets all attributes *and removes pathName*
> from tableName. Returns an empty string."
> 

OK, I will add this to the man page.

> About the implementation: is there any technical advantage to do this
> in Tcl and not C?
> 

The implementation in Tcl is much simpler and easier to maintain. 
Currently it has no more than 228 LOC, of which 81 are comments or empty 
lines.

> Regards
> Emiliano
> 

Best regards,

Csaba

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

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

[TCLCORE] TIPs 728 and 730 Accepted

[Donal F. <don...@ma...>]

Thanks to everyone who voted. 728 and 730 are now Accepted.

TIP 728: 6/0/0
  For: HO, DKF, APN, SL, AK, MC
  Against: none
  Present: none
TIP 730: 6/0/0
  For: HO, DKF, APN, SL, AK, MC
  Against: none
  Present: none

Donal.

Re: [TCLCORE] CFV: TIP 728, 730

[Donal F. <don...@ma...>]

Does that mean in order to get a byte compiled switch one should always specify “—” ?
No. Due to technical changes (I forget exactly when), [switch] with just a value and a list of pattern/bodies is also bytecode compiled (using exact string matching). This is justified by the fact that any other interpretation results in a syntax error.

But with [switch -integer], no such luck. You need the double-hyphen to get bytecode compilation, just as with -glob. Or maybe we could if there were exactly three arguments... but it's an ambiguous case so we just punt. The bytecode compiler is very conservative.

Donal.
________________________________
From: apn...@ya... <apn...@ya...> on behalf of apn...@ya... <apn...@ya...>
Sent: Thursday, September 18, 2025 12:38
To: Donal Fellows <don...@ma...>; 'Tcl Core' <tcl...@li...>
Subject: RE: [TCLCORE] CFV: TIP 728, 730


TIP 730: Yes. Long awaited.



One very, very minor nit. Clarify in manpage that “integer” means as in “string is wideinteger” and not “string is integer”.



And one question arising from experimentation (actually nothing to do with 730, applies to -glob etc. as well). Consider the following disassembly. The following is not bytecompiled:



% 'dis script {switch -integer  $x {0 {puts 0} 1 {puts 1}}}

ByteCode 0x2c7743e0750, refCt 1, epoch 21, interp 0x2c774362be0 (epoch 21)

  Source "switch -integer  $x {0 {puts 0} 1 {puts 1}}"

  Cmds 1, src 43, inst 27, litObjs 4, aux 0, stkDepth 4, code/src 0.00

  Commands 1:

      1: pc 0-25, src 0-42

  Command 1: "switch -integer  $x {0 {puts 0} 1 {puts 1}}"

    (0) push 0  # "switch"

    (5) push 1  # "-integer"

    (10) push 2         # "x"

    (15) loadStk

    (16) push 3         # "0 {puts 0} 1 {puts 1}"

    (21) invokeStk 4

    (26) done



while on the other hand the following is:



% 'dis script {switch -integer -- $x {0 {puts 0} 1 {puts 1}}}

ByteCode 0x2c7743e0550, refCt 1, epoch 21, interp 0x2c774362be0 (epoch 21)

  Source "switch -integer -- $x {0 {puts 0} 1 {puts 1}}"

  Cmds 3, src 45, inst 62, litObjs 5, aux 1, stkDepth 2, code/src 0.00

  Commands 3:

      1: pc 0-60, src 0-44        2: pc 16-30, src 26-31

      3: pc 36-50, src 37-42

  Command 1: "switch -integer -- $x {0 {puts 0} 1 {puts 1}}"

    (0) push 0  # "x"

    (5) loadStk

    (6) jumpTableNum 0

                [1->pc 36, 0->pc 16]

    (11) jump +45       # pc 56

  Command 2: "puts 0..."

    (16) push 1         # "puts"

    (21) push 2         # "0"

    (26) invokeStk 2

    (31) jump +30       # pc 61

  Command 3: "puts 1..."

    (36) push 1         # "puts"

    (41) push 3         # "1"

    (46) invokeStk 2

    (51) jump +10       # pc 61

    (56) push 4         # ""

    (61) done



The difference is the presence of “—” and presumably arises because of ambiguity. Does that mean in order to get a byte compiled switch one should always specify “—” ?



/Ashok



From: Donal Fellows <don...@ma...>
Sent: Monday, September 15, 2025 7:21 PM
To: Tcl Core <tcl...@li...>
Subject: [TCLCORE] CFV: TIP 728, 730



Hi everyone



This a CFV on two small feature TIPs:



  TIP 728: Reliable Read and Write of Child Interpreter Variables (aka interp set)

    https://core.tcl-lang.org/tips/doc/trunk/tip/728.md [core.tcl-lang.org]<https://urldefense.com/v3/__https://core.tcl-lang.org/tips/doc/trunk/tip/728.md__;!!PDiH4ENfjr2_Jw!DEng-7V61ptn5PNVuFfqQDfMXQ43sRknMy_5vewRapsnki6mLfPvPViFB67i7K2GEOYBgii4FbzglPhC5-6VgCfszehZnA3GN6cu$>



  TIP 730: Switching by Integers (aka switch -integer)

    https://core.tcl-lang.org/tips/doc/trunk/tip/730.md [core.tcl-lang.org]<https://urldefense.com/v3/__https://core.tcl-lang.org/tips/doc/trunk/tip/730.md__;!!PDiH4ENfjr2_Jw!DEng-7V61ptn5PNVuFfqQDfMXQ43sRknMy_5vewRapsnki6mLfPvPViFB67i7K2GEOYBgii4FbzglPhC5-6VgCfszehZnLP0o85E$>



Please send your votes to this list (preferably in reply to this message so I stand a chance of finding them in my inbox!) by [clock format 1758538800] (12:00 my time, next Monday).



My votes follow:



TIP 728: YES

TIP 730: YES



Also, let it be known that I have seen Harald's votes for both of these, and that I've seen Ashok's concerns, but aren't going to delay; I feel quite strongly that having some TIPs in discussion shouldn't be a reason for blocking votes on other TIPs, as that would be a recipe for stasis just by having a discussion open.



I've added some compatibility notes to the TIPs. (They were originally in this email, but I think they're better in the TIPs themselves.)



Donal.

Re: [TCLCORE] CFV: TIP 728, 730

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

TIP #728: YES
TIP #730: YES

- Marc

On Mon, Sep 15, 2025 at 7:51 AM Donal Fellows <
don...@ma...> wrote:

> Hi everyone
>
> This a CFV on two small feature TIPs:
>
>   TIP 728: *Reliable Read and Write of Child Interpreter Variables* (aka *
> interp set*)
>     https://core.tcl-lang.org/tips/doc/trunk/tip/728.md
>
>   TIP 730: *Switching by Integers* (aka *switch -integer*)
>     https://core.tcl-lang.org/tips/doc/trunk/tip/730.md
>
> Please send your votes to this list (preferably in reply to this message
> so I stand a chance of finding them in my inbox!) by [clock format
> 1758538800] (12:00 my time, next Monday).
>
> My votes follow:
>
> TIP 728: YES
> TIP 730: YES
>
> Also, let it be known that I have seen Harald's votes for both of these,
> and that I've seen Ashok's concerns, but aren't going to delay; I feel
> quite strongly that having some TIPs in discussion shouldn't be a reason
> for blocking votes on other TIPs, as that would be a recipe for stasis just
> by having a discussion open.
>
> I've added some compatibility notes to the TIPs. (They were originally in
> this email, but I think they're better in the TIPs themselves.)
>
> Donal.
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] About TIPs 727 and 729

[Emiliano G <emi...@gm...>]

El jue, 18 sept 2025 a las 16:24, Csaba Nemethi
(<csa...@t-...>) escribió:
>
> As announced below, a few days ago I committed a thoroughly updated
> implementation of the element creation for ttk::toggleswitch widgets
> (TIP 727).  The new version contains both generic code for arbitrary
> themes and theme-specific one for a few built-in themes.
>
> Today I committed a revisited version of TIP 729, whose title now reads
> "Add a tk attribtable command to the core" (the initial one was "Add a
> tk_cargo procedure to the core").  The new version made it necessary to
> rework large parts of the implementation, which I committed today, too.
>
> Comments on both TIPs are highly appreciated.

Some comments about tip 729, most of which are personal preferences:

* tk attribtable tableName

My preference for the tableName command to be created in the current
namespace if not fully qualified. This will ease the handling of
attribute tables when implemented as TclOO objects. If tableName
already exists, it is overwritten. Also, in all the tableName instance
subcommands, if pathName doesn't exist my preference is to raise an
error, except in [tableName exists].

* tableName set

Preference to return the full key-value pair for pathName in
tableName, just as [dict set] does.

* tableName get

Preferred API

  ** tableName get pathName ?key? ?defaultvalue?

If there's no such "key" entry, "defaultvalue" is returned if
specified, or an empty string otherwise, just as [ttk::style lookup]
does.

* tableName names

Preferred API

  ** tableName names ?pathName?

returning the list of path names in tableName if pathName is not
specified. Otherwise, it returns the list of keys already set for
pathName in tableName.

* tableName clear

I prefer the description "Unsets all attributes *and removes pathName*
from tableName. Returns an empty string."

About the implementation: is there any technical advantage to do this
in Tcl and not C?

Regards
Emiliano

[TCLCORE] CFV planned for TIPs 727 and 729

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

This is to announce that I plan to submit a CFV for TIPs 727 and 729 
towards the middle of this week.

TIP 727: Add a ttk::toggleswitch widget to the core

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

TIP 729: Add a tk attribtable command to the core (formerly: Add a 
tk_cargo procedure to the core).

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

Both TIPs have a complete, ready-to-use implementation, inclusive 
documentation and tests.  For a review, just check out the branches 
"toggleswitch" and "cargo".  Any feedback is welcomed.

Csaba

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

Re: [TCLCORE] Reminder : online meetup 9/22 12:00PM UTC

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

Paul, sure, we can start with BAWT.

 

/Ashok

 

From: Paul Obermeier <pa...@po...> 
Sent: Monday, September 22, 2025 12:02 AM
To: tcl...@li...
Subject: Re: [TCLCORE] Reminder : online meetup 9/22 12:00PM UTC

 

I can join, but with limited time only (we have to take care of our grandchildren tomorrow).
So it would be best to talk about the BAWT topic first.

Paul

Am 21.09.2025 um 19:56 schrieb apnmbx-public--- via Tcl-Core:

The biweekly meetup is tomorrow, Monday at 12:00PM UTC. Folks forgot last one. If we miss this one, we’ll hear about it from Harald when he returns 😊

 

Open agenda. Points of discussion of my interest:

 

1.      Recursive mutex status

2.      Streamlining Tcl initialization

3.      Binary repository for extensions using Github actions and BAWT (Paul O. it would be great if you could join as your input would be crucial)

 

/Ashok






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

 

Re: [TCLCORE] CFV: TIP 728, 730

[Steve L. <st...@di...>]

TIP #728: YES
TIP #730: YES

-- Steve
On 15 Sep 2025 at 9:52 PM +0800, Donal Fellows <don...@ma...>, wrote:
> Hi everyone
> This a CFV on two small feature TIPs:
>   TIP 728: Reliable Read and Write of Child Interpreter Variables (aka interp set)    https://core.tcl-lang.org/tips/doc/trunk/tip/728.md
>   TIP 730: Switching by Integers (aka switch -integer)    https://core.tcl-lang.org/tips/doc/trunk/tip/730.md
> Please send your votes to this list (preferably in reply to this message so I stand a chance of finding them in my inbox!) by [clock format 1758538800] (12:00 my time, next Monday).

Re: [TCLCORE] Reminder : online meetup 9/22 12:00PM UTC

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

On 09/21/2025 07:56 PM, apnmbx-public--- via Tcl-Core wrote:

> ...
> Open agenda. Points of discussion of my interest:
>
>   * Recursive mutex status
> ...

and once again am I unable to attend. Nervingtheless, I'd like to pour even more fuel into the flames of our currently
ongoing mutexing recursiveness:

* Reading https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_12
   and citing

   "Applications shall ensure that access to any memory location by more than one thread of control (threads or processes)
     is restricted such that no thread of control can read or modify a memory location while another thread of control may
    be modifying it. Such access is restricted using functions that synchronize thread execution and also synchronize memory
    with respect to other threads. The following functions synchronize memory with respect to other threads:

    ... pthread_mutex_lock() ... pthread_mutex_unlock() ...
   "

   The consequence is then logically: if the memory is modified within the locked section it must be under some circumstances
   read-consistent out of the section, when all modifications take place only inside of the locked section. Here I refer to the
   storage for the thread identifier and the lock counter. And the test is for equality of the current thread identifier against
   the stored identifier (which stays consistent, since only change within the locked region) and the counter being zero (which
   might be changing).

* This means, if my logic is correct, that the initial implementation is correct and we should not waste energy in thinking
   over atomic operations, spin locks, cache coherency, and whatnot.

* But: we then have the thread identifier, see https://pubs.opengroup.org/onlinepubs/9799919799/functions/pthread_equal.html
   and we shall need PTHREAD_NULL, if we want to assign something different. Then we get per
   https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/pthread.h.html citing:

   "Since pthread_t is an opaque type, a definition of PTHREAD_NULL was added to allow for a null value of that type.
    Some conforming definitions of PTHREAD_NULL could be:

     For a pointer type:

     #define PTHREAD_NULL ((pthread_t)NULL)

     For an integer type:

     #define PTHREAD_NULL ((pthread_t)-42)

     For a struct type:

     #define PTHREAD_NULL ((const pthread_t){ .__foo = -1 })
   "

* Now we might have a problem: is our Tcl_ThreadId always ever, ever able to fulfill this contract on every even unborn
   platform? And what about testing two Tcl_ThreadIds for being (not) the same? Is this eventually the elephant in the room?
   So far I see "typedef struct Tcl_ThreadId_ *Tcl_ThreadId;", but can this ever map to the third kind of pthread_t's?

All the best,
Christian

Re: [TCLCORE] CFV: TIP 728, 730

[Andreas K. <and...@gm...>]

> Hi everyone
> 
> This a CFV on two small feature TIPs:
> 
>   TIP 728: Reliable Read and Write of Child Interpreter Variables (aka interp set)
>   TIP 730: Switching by Integers (aka switch -integer)

TIP#728	YES
TIP#730 YES

-- 
Happy Tcling,
	Andreas Kupries <and...@gm...>
			<https://core.tcl-lang.org/akupries/>
			<https://akupries.tclers.tk/>
	Developer @	SUSE Software Solutions Germany GmbH
-------------------------------------------------------------------------------

Re: [TCLCORE] Reminder : online meetup 9/22 12:00PM UTC

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

I can join, but with limited time only (we have to take care of our grandchildren tomorrow).
So it would be best to talk about the BAWT topic first.

Paul

Am 21.09.2025 um 19:56 schrieb apnmbx-public--- via Tcl-Core:
>
> The biweekly meetup is tomorrow, Monday at 12:00PM UTC. Folks forgot last one. If we miss this one, we’ll hear about it from Harald when he returns 😊
>
> Open agenda. Points of discussion of my interest:
>
>   * Recursive mutex status
>   * Streamlining Tcl initialization
>   * Binary repository for extensions using Github actions and BAWT (Paul O. it would be great if you could join as your input would be crucial)
>
> /Ashok
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core