tcl-core — Tcl Core Team discussions about Tcl development

[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

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

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

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

Re: [TCLCORE] CFV: TIP 728, 730

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

TIP 730: YES (already voted)

TIP 728: YES

 

/Ashok

 

 

From: Donal Fellows <don...@ma...
<mailto:don...@ma...> > 
Sent: Monday, September 15, 2025 7:21 PM
To: Tcl Core <tcl...@li...
<mailto: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

 

  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.

Re: [TCLCORE] About TIPs 727 and 729

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

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.

Best regards,

Csaba


Am 13.09.25 um 14:38 schrieb Csaba Nemethi:
> I would like to thank all who have posted comments regarding TIP 727 
> ("Add a ttk::toggleswitch widget to the core") and TIP 729 ("Add a 
> tk_cargo procedure to the core").
> 
> I am now in a position to commit an updated implementation of the 
> ttk::toggleswitch widget very soon.  In the new version, the elements 
> for third-party themes will be created by generic procedures rather than 
> theme-specific ones.
> 
> After that I will start to rework the cargo-related stuff, taking into 
> account the comments posted by Emiliano and the others who have 
> expressed their opinions regarding this subject.  That work will 
> probably take somewhat longer.
> 
> Best regards,
> 
> Csaba
> 

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

Re: [TCLCORE] Add support for Copy/Cut/Paste keys in X11

[da S. P. J <pet...@fl...>]

Personally I would call this a no-brainer and an unqualified win. It breaks nothing and adds support for these legacy keycodes.

From: Yaacov Akiba Slama <ya...@sl...>
Date: Thursday, September 18, 2025 at 05:24
To: tcl...@li... <tcl...@li...>
Subject: [TCLCORE] Add support for Copy/Cut/Paste keys in X11
Hi, I created a ticket at https: //urldefense. us/v2/url?u=https-3A__core. tcl-2Dlang. org_tk_tktview_04e1735b86&d=DwICAg&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=7ILjDduFiRN-fWIOt63jGJiPzUS569BvCc8Zn84RA7Q0b5wu1ucYiHph3gHB_sxc&s=F4T9vhf7wvGda73G-eNGUwSJOhkyP4p7okyN-RXmUjY&e=


Hi,



I created a ticket at https://urldefense.us/v2/url?u=https-3A__core.tcl-2Dlang.org_tk_tktview_04e1735b86&d=DwICAg&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=7ILjDduFiRN-fWIOt63jGJiPzUS569BvCc8Zn84RA7Q0b5wu1ucYiHph3gHB_sxc&s=F4T9vhf7wvGda73G-eNGUwSJOhkyP4p7okyN-RXmUjY&e= to

support physical Copy/Cut/Paste keys but I am not sure that it's the

right way to contribute.



Do I have to do something else?



Thanks a lot.



--yas







_______________________________________________

Tcl-Core mailing list

Tcl...@li...

https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwICAg&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=7ILjDduFiRN-fWIOt63jGJiPzUS569BvCc8Zn84RA7Q0b5wu1ucYiHph3gHB_sxc&s=GumDLvI8vDx5-jBhUvcT_WmqW60bebYP7lzKhNb8juA&e=

Re: [TCLCORE] Merge intention for project uniform_test_file_structure

[Erik L. <el...@xs...>]

On 10/09/2025 14:28, Erik Leunissen via Tcl-Core wrote:
> 
> Unless someone raises founded objections in the meantime, I will carry 
> out the
> intended merge one week after the date of this post.
> 

Now done.

Erik Leunissen.
--

Re: [TCLCORE] CFV: TIP 728, 730

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

Op do 18 sep 2025 om 14:15 schreef Jan Nijtmans <jan...@gm...>:
>
> Op do 18 sep 2025 om 13:39 schreef apnmbx-public--- via Tcl-Core
> <tcl...@li...>:
> > One very, very minor nit. Clarify in manpage that “integer” means as in “string is wideinteger” and not “string is integer”.
>
> In Tcl9 “string is wideinteger” and “string is integer” are exactly the same ;-)

Hm ....   I'm mistaken.  Please ignore my comment

Regards,
         Jan Nijtmans

Re: [TCLCORE] CFV: TIP 728, 730

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

Op do 18 sep 2025 om 13:39 schreef apnmbx-public--- via Tcl-Core
<tcl...@li...>:
> One very, very minor nit. Clarify in manpage that “integer” means as in “string is wideinteger” and not “string is integer”.

In Tcl9 “string is wideinteger” and “string is integer” are exactly the same ;-)

Regards,
       Jan Nijtmans

Re: [TCLCORE] CFV: TIP 728, 730

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

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

 

  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.

[TCLCORE] Add support for Copy/Cut/Paste keys in X11

[Yaacov A. S. <ya...@sl...>]

Hi,

I created a ticket at https://core.tcl-lang.org/tk/tktview/04e1735b86 to 
support physical Copy/Cut/Paste keys but I am not sure that it's the 
right way to contribute.

Do I have to do something else?

Thanks a lot.

--yas

Re: [TCLCORE] CFV: TIP 728, 730

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

Got it. Thanks!
-Brian
(from mobile device)

On Sep 16, 2025, at 07:05, Donal Fellows <don...@ma...> wrote:


One of those values was the value that you're switching on, not the arm label. Whether you want those values to be equal or not is a semantic decision, and something the user should have control over.

These will print different things:
  switch -exact   -- 0x1f {0b111111 {puts foo} default {puts bar}}
  switch -integer -- 0x1f {0b111111 {puts foo} default {puts bar}}

Donal.

-------- Original message --------
From: Brian Griffin <bri...@ea...>
Date: 16/09/2025 13:48 (GMT+00:00)
To: Donal Fellows <don...@ma...>
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV: TIP 728, 730

The case where you have 0x1f and 0b11111, fails the uniqueness test, forcing the decision to use strings.

What am I missing?

Re: [TCLCORE] CFV: TIP 728, 730

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

On Sep 16, 2025, at 00:04, Donal Fellows <don...@ma...> wrote:


They're semantically different. In particular, having it explicit allows the use of other representations of integers while having them be equal, which the existing string comparison rules definitely forbid. (For example, 0x1f and 0b111111 are equal integers but different strings.) That in turn admits a different implementation strategy; the jump table uses integer keys rather than string keys.

Donal.

But if all the cases parse out as valid integer numbers, and all the cases are unique numbers, why not decide then to use number keys?

The case where you have 0x1f and 0b11111, fails the uniqueness test, forcing the decision to use strings.

What am I missing?
 -Brian


-------- Original message --------
From: Brian Griffin <bri...@ea...>
Date: 15/09/2025 22:10 (GMT+00:00)
To: Donal Fellows <don...@ma...>
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV: TIP 728, 730

Why is this not just an internal optimization performed the first time a switch is entered?  It would add a 1 time cost, but after that the gain should be good. Why must the coder decide?