tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] CFV: TIP 728, 730

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

Donal,

 

As a point of clarification, I certainly did not say, or at least mean to
say, that CFV's should be held up while other TIP's are in discussion. That
would be.absurd! My point was 5 days between announcement of a TIP to a CFV
was too short (for 730, a couple of days more for 728) even in an absolute
sense. The reference to the other TIP's was only to point out that the
limited time people have for OSS was further reduced by discussions already
ongoing and other work that might be in progress. I didn't think any TIP
could get anything more than a cursory review in such a short time frame.

 

No matter, folks will review to the extent they feel necessary to form an
opinion and vote accordingly.

 

/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.

Re: [TCLCORE] CFV: TIP 728, 730

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

On Sep 15, 2025, at 06:50, 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

I should have comment on this earlier.

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?

-Brian


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...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] we are moving core away from Roy's infrastructure

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

> It looks like the sync of Tk from 12/09 onwards hasn't run (or has
> failed), and all commits to normally-buildable branches in the past
> week have been since then.
 
> Andreas runs the sync, IIRC. He'll have to investigate; it's
> probably a fairly trivial fix.

Re-added the gh credentials to the ssh-agent of the www user. That
should have fixed it.

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

[TCLCORE] CFV: TIP 728, 730

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

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] we are moving core away from Roy's infrastructure

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

It looks like the sync of Tk from 12/09 onwards hasn't run (or has failed), and all commits to normally-buildable branches in the past week have been since then.

Andreas runs the sync, IIRC. He'll have to investigate; it's probably a fairly trivial fix.

Donal.

-------- Original message --------
From: Jan Nijtmans <jan...@gm...>
Date: 15/09/2025 09:49 (GMT+00:00)
To: Steve Landers <st...@di...>
Cc: "Porter, Don (Fed) via Tcl-Core" <tcl...@li...>
Subject: Re: [TCLCORE] we are moving core away from Roy's infrastructure

Note also that there haven't been any Tk builds last week, even though
there were
commits to the Tk repository. No hurry, but can someone have a look at that too
(if it's runrelated)?  (Tcl builds are fine, it's only Tk)

Re: [TCLCORE] we are moving core away from Roy's infrastructure

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

Op ma 15 sep 2025 om 03:23 schreef Steve Landers <st...@di...>:
> I write to inform you that this is going on and that the transfer will be largely transparent nor should it involve any effort from you.

Great to hear that!

Note also that there haven't been any Tk builds last week, even though
there were
commits to the Tk repository. No hurry, but can someone have a look at that too
(if it's runrelated)?  (Tcl builds are fine, it's only Tk)

Thanks!
      Jan Nijtmans

[TCLCORE] we are moving core away from Roy's infrastructure

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

Hi Don,

Last week the core server was unavailable for extended periods of time.  I contacted Roy Keene but, as always, was ignored.  Richard Hipp kindly took a look and couldn't figure out what was going on, but the problem seemed to resolve over time.  My theory is that we were hit with a new type of DDoS caused by AI scrapers where millions of individual hosts make a single request  - you can read about this type of problem here https://blog.cloudflare.com/perplexity-is-using-stealth-undeclared-crawlers-to-evade-website-no-crawl-directives/.   It seems that Cloudflare's AI-based bot mitigation kicked in and started blocking connections because the core server became responsive again part way through the attached graph from Thu/Fri last and concurrently note that the number of verified bots increased significantly.

In my opinion it is untenable that we have a core Tcl community resource dependent on a single person who goes absent for extended periods of time.  So for the last few days several of us have been discussing moving core.tcl-lang.org from Roy's infrastructure to a Linode owned by the Tcl Community Association, and concurrently building a team of people around the world who can manage it.   We will eventually consolidate www.tcl-lang.org and wiki.tcl-lang.org onto the same Linode.  Those involved in the discussions include myself, Philip Brooks (the new TCA chair), Clif Flynt, Donal Fellows, Andreas Kupries and Richard Hipp.

I write to inform you that this is going on and that the transfer will be largely transparent nor should it involve any effort from you. Since you are the release manager we will try to time the switchover for a period that isn't going to clash with your efforts.

I'm happy to discuss this at any time if you wish.

-- Steve

[TCLCORE] About TIPs 727 and 729

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

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

[TCLCORE] tclcompiler / tbcload

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

Miguel Bagnon’s port of tclcompiler and tbcload to Tcl 9 are now in the tcltk-depot <https://github.com/tcltk-depot>  repository and have been updated to support both Tcl 8 and 9. Note however, byte code compiled under Tcl 8 will be rejected in Tcl 9 and vice versa. There is a special check added for this as Tcl8 byte compiled files will crash Tcl9. This still means there is a bug somewhere that does not do sufficient validation to guard against possible corrupted files and needs to be fixed.

 

Github workflows have been set up for CI.

 

Pending work:

 

- Support for Tcl 9.1 (I believe Miguel is working on this but with uncertain schedule)

- Test suite is very parse. I could not locate any more extensive tests in older repositories.

- Documentation relies on an old ActiveState PDF. It would be nice to bring this up to date.

 

Hope someone (in addition to Miguel) who uses these packages will volunteer to finish up and maintain these packages. I do not use them and do not have time to work on them further.

 

/Ashok

Re: [TCLCORE] Ticket [6c149127]

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

On 09/12/2025 02:59 AM, Marc Culler wrote:
> Christian,
>
> Would you please explain why your patch adds two null characters at the ends of those strings, instead of just 1?

Pure paranoia, the DString is made up of Win32 wchar_t items, not chars. So a NUL termination
consists of two 0 bytes, isn't it?

BR,
Christian

Re: [TCLCORE] TIP 730: Switching by Integers

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

While both 728 and730 feel like no-brainers, please allow more time for
review. A few days is not enough given real life commitments, one's own
ongoing Tcl projects, and in the current situation, five TIP's in
discussion.

 

From: Donal Fellows <don...@ma...> 
Sent: Wednesday, September 10, 2025 1:33 AM
To: Tcl Core <tcl...@li...>
Subject: [TCLCORE] TIP 730: Switching by Integers

 

Another TIP, this for the feature I've been muttering about doing for ages;
adding a -integer option to switch. It does what it says on the tin. I'm
pretty happy with how this one's come together; it feels like a natural
extension of what we had and took little code to bring to fruition, so I'll
probably call a vote on it at the same time as 728.

 

Donal.

Re: [TCLCORE] About tip#729

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

Irrespective of the comments below, the general proposal is useful and I would be in favor of adding it in some form.

 

Names: Some alternatives to “cargo” (I don’t know if Tk already uses these in other contexts)

 

tk_datum

tk_property

 

Prefix vs namespace: I don’t think in this context namespaces offer any significant advantages over prefixes. In my mind, the primary purpose of namespaces was not to reduce conflicts. After all, two package developers could each decide to use the same namespace (examples: csv, www, http). The main benefit of namespaces is to permit use of the shorter form of names within that namespace scope. I don’t think that is very valuable in this context. Caveat: I have not looked at Emiliano’s proposal in detail as yet to know if there are other benefits to namespace use.

 

tk_cargo vs tk::cargo vs “tk cargo”: Tk seems to have all three forms so none seem to have a leg up in terms of consistency. I do feel that for the most part the tk command ensemble mostly deals with information that is not window specific (with exceptions). However, I didn’t see mention of *winfo* which seems like the best fit as it pertains to retrieving window-specific information. Some possibilities to consider,

 

winfo propertyget $path PROPERTYNAME, or

winfo property get $path PROPERTYNAME, 

 

or even, flattening the commands,

 

winfo set $path PROPERTYNAME …

winfo unset $path PROPERTYNAME …

…

 

etc.

 

Regarding TIP functionality itself,

 

I find the ability to specify a default with dicts (in Tcl 9) very convenient. Correspondingly, I would like the equivalent here as well. So (with DEFAULT defaulting to empty string),

 

tk_cargo set $path ?KEY ?DEFAULT??

 

Also, the idiom of no arguments meaning *all* keys in unset is not intuitive to me, even if it mirrors the set behavior. It has potential for surprises when used with expansion

 

tcl_cargo unset $path {*}$keysToUnset

 

and keysToUnset is empty. If needed, I’d rather see an “unsetall” or “clear” command instead to delete all content.

 

/Ashok

 

From: Emiliano <emi...@gm...> 
Sent: Thursday, September 11, 2025 5:32 AM
To: tcl...@li...
Subject: Re: [TCLCORE] About tip#729

 

+1

Finding a good name is still one of the hardest problems in programming. I've thought 'widgetdata' or 'widgetstore', but I'll leave this to native speakers.

Regards

Emiliano

 

El 10 de septiembre de 2025 5:56:26 p. m. GMT-03:00, Marc Culler <cul...@gm... <mailto:cul...@gm...> > escribió:

When I see the word "cargo" it does not bring to mind setting extra attributes for widgets. It brings to mind the package manager for the Rust language.

 

Any chance that "cargo" could be changed, maybe to "attributes" or "attrs"?

 

-Marc

 

 

 

On Wed, Sep 10, 2025, 9:25 AM Csaba Nemethi <csa...@t-... <mailto:csa...@t-...> > wrote:

Hi Emiliano,

Many thanks for your comments!  Right now I am about to leave, but 
tomorrow I will send you (and the list) a detailed answer.

Best regards,

Csaba


Am 10.09.25 um 16:08 schrieb Emiliano G:
> Csaba, all:
> 
> I think the functionality proposed in TIP 729 "Add a tk_cargo procedure
> to the core" is welcomed but I think it falls short for the reasons explained
> below.
> 
> Consider this scenario: programmer 1 implements a fancy widget as
> a megawidget, a graph widget, using a canvas. The fancy graph widget
> has a -title option. "Fine", she says, "I'll use tk_cargo to store my
> fancy graph title, as well as all other widget specific data".
> She goes ahead and use
> 
> tk_cargo $graph set -title $graphtitle ...
> 
> Unknowingly, programmer 2 is implementing just another fancy tooltip
> with all the bells and whistles all modern tooltips are supposed to
> have, including a title. Of course it uses tk_cargo to store its data!
> So she wrotes
> 
> tk_cargo $widget set -title $title ...
> 
> Now, programmer 1 discovers the Fancytooltip package and decides to
> use it along with his own Fancygraph. She will be very puzzled when
> setting the tooltip changes its graph title upon redraw ...
> 
> This is why tkcargo[1] implements tk_cargo as, well, cargotables.
> This way each megawidget author can use his own table without fear to
> step into each other toes. They just create the table (or tables) they
> need in his private namespace and get along with them. No more
> Average Joe Programmer being puzzled (or worse, upset).
> 
> Now, some points about the functionality that are worth considering
> IMHO (here, tk_cargo is the name of the cargo command):
> 
> * Optionally set, on creation, a list of valid keys for a given
>    cargo table for automatic validation. This is already implemented
>    in tkcargo (the exact API can be adjusted).
> 
>    % tk::cargotable tk_cargo {-title -foo -bar}
>    ::tk_cargo
>    % tk_cargo set . -title foo
>    -title foo
>    tk_cargo set . -wrongswitch foo
>    bad key "-wrongswitch": must be -title, -foo, or -bar
> 
> * Optionally set a command prefix to run when a value is set, get or
>    unset (traces). An (unbaked) example can be
> 
>    tk_cargo trace $window $cmdprefix
> 
>    and when the data is modified call
> 
>    {*}$cmdprefix $window $operation
> 
>    This allows for automatic actions when the values are modified.
> 
> * Perhaps a bit too complex, but a "would be nice to have": a binding
>    table. Another unbaked example
> 
>    tk_cargo bind $window $sequence $script
> 
>    The implementation will rely on Tk_CreateBindingTable and friends.
>    This will allow private bindings not interacting with the more general
>    [bind] mechanism.
> 
> 
> Regards
> 
> Emiliano
> 
> [1] https://chiselapp.com/user/egavilan/repository/tkcargo
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li... <mailto:Tcl...@li...> 
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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



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

-- 
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

Re: [TCLCORE] Ticket [6c149127]

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

Christian,

Would you please explain why your patch adds two null characters at the
ends of those strings, instead of just 1?

- Marc

On Thu, Sep 11, 2025 at 2:50 PM Christian Werner <
Chr...@t-...> wrote:

> May I bring the Tk experts this ticket to attention:
>
>    https://core.tcl-lang.org/tk/info/6c149127b59e968b
>
> The "tk sysnotify" things amongst the tray things could be
> a cause of crashes caused by stack smashing. Only triggered
> by a slightly longer string presented to a command.
>
> Not good,
> Christian
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Ticket [6c149127]

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

I will try to take a look next week. 

> On Sep 11, 2025, at 4:50 PM, Christian Werner <Chr...@t-...> wrote:
> 
> May I bring the Tk experts this ticket to attention:
> 
>  https://core.tcl-lang.org/tk/info/6c149127b59e968b
> 
> The "tk sysnotify" things amongst the tray things could be
> a cause of crashes caused by stack smashing. Only triggered
> by a slightly longer string presented to a command.
> 
> Not good,
> Christian
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] Ticket [6c149127]

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

May I bring the Tk experts this ticket to attention:

   https://core.tcl-lang.org/tk/info/6c149127b59e968b

The "tk sysnotify" things amongst the tray things could be
a cause of crashes caused by stack smashing. Only triggered
by a slightly longer string presented to a command.

Not good,
Christian

Re: [TCLCORE] About tip#729

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

Csaba, all

Se inline answers below

El jue, 11 sept 2025 a las 7:53, Csaba Nemethi
(<csa...@t-...>) escribió:
>
> Hi Emilano,
>
> I have been using an attrib subcommand for all my mega-widgets for
> decades now, and it has always worked as expected without the need for
> several tables.

And they are great. I use them everyday. But the problem here is using
code from several packages, with different programmers, each one using
different coding conventions and techniques, without stepping on each
other.

> In your example it is sufficient to use prefixes to avoid name collisions:
>
>   tk_cargo $graph set graph-title $graphtitle ... ;# programmer 1
>
>   tk_cargo $widget set tooltip-title $title ...  ;# programmer 2
>
> And even if programmer 2 doesn't use the "tooltip" prefix, programmer 1
> won't experience any name collision if he or she does use the "graph"
> prefix. For safety, it is recommended to always prepend some prefix to
> the attribute names, as shown above.

A naming convention can take things far, as long as everyone follows such
convention. That's why Tcl has namespaces, so people is not forced to
follow someone else's. Instead, as is recommended elsewhere in several
places[1][2], a package should provide a namespace as a child of the global
namespace and put all of its commands and variables inside that namespace.
This is what is desired where: each package creates his table(s) inside
their own namespace.

> You are stating that the better solution is to use several cargo tables.
>  But what if in your example both programmers use the same table, say
>
>   tk::cargotable table1
>
> If programmer 1 doesn't know that programmer 2 has already created a
> table of the name "table1" then his or her invocation of the above
> command will again create a table of the name "table1". However, by
> doing this, all the data contained it table1 will get lost (I have
> tested this)! Instead of name collisions there will be a fatal data
> loss! IMHO, this is much worse than an incidental name collision (which
> can be avoided by using a prefix).

Well, the same happens with [proc], and several other command creating
commands. IMO this is a good thing. If I write

proc ::foo::bar::baz {} {#some code}

I want ::foo::bar::baz to be the one I created.

If what's desired is a way to create a table whose name doesn't clash with any
other, it can be implemented easily. It can be modeled after [image create]
or [oo::object new]. My position here is that when a name is given, it should
overwrite whatever is there[3]. If an arbitrary, non clashing name is desired,
it must be generated in the current namespace (preferable) or in a well known
namespace (as TclOO does).

Regards

Emiliano

[1] https://wiki.tcl-lang.org/page/Tcl+Tutorial+Lesson+31
[2] http://www.wjduquette.com/tcl/namespaces.html - It is sad that it is now
    offline. I remember this to be a great document.
[3] Yes, I'm in disagreement with TclOO behaviour here, but such is life.

Re: [TCLCORE] About tip#729

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

Hi,

I think using a prefix or a specific cargo table is similar, both are used
to prevent name clashes between different users.
The prefix doesn't avoid collision if different users use the same prefix.
Also, "tk::cargotable table1" can be changed to raise an error if table1 is
already defined (and a "-force" option added :-)).
The advantage of having different tables is that it is enforced by the API,
unlike the prefix method, and also seems cleaner to me.

Eric

Le jeu. 11 sept. 2025 à 12:53, Csaba Nemethi <csa...@t-...> a
écrit :

> Hi Emilano,
>
> I have been using an attrib subcommand for all my mega-widgets for
> decades now, and it has always worked as expected without the need for
> several tables.
>
> In your example it is sufficient to use prefixes to avoid name collisions:
>
>      tk_cargo $graph set graph-title $graphtitle ...  ;# programmer 1
>
>      tk_cargo $widget set tooltip-title $title ...    ;# programmer 2
>
> And even if programmer 2 doesn't use the "tooltip" prefix, programmer 1
> won't experience any name collision if he or she does use the "graph"
> prefix.  For safety, it is recommended to always prepend some prefix to
> the attribute names, as shown above.
>
> You are stating that the better solution is to use several cargo tables.
>   But what if in your example both programmers use the same table, say
>
>      tk::cargotable table1
>
> If programmer 1 doesn't know that programmer 2 has already created a
> table of the name "table1" then his or her invocation of the above
> command will again create a table of the name "table1".  However, by
> doing this, all the data contained it table1 will get lost (I have
> tested this)!  Instead of name collisions there will be a fatal data
> loss!  IMHO, this is much worse than an incidental name collision (which
> can be avoided by using a prefix).
>
> Best regards,
>
> Csaba
>
>
> Am 10.09.25 um 16:08 schrieb Emiliano G:
> > Csaba, all:
> >
> > I think the functionality proposed in TIP 729 "Add a tk_cargo procedure
> > to the core" is welcomed but I think it falls short for the reasons
> explained
> > below.
> >
> > Consider this scenario: programmer 1 implements a fancy widget as
> > a megawidget, a graph widget, using a canvas. The fancy graph widget
> > has a -title option. "Fine", she says, "I'll use tk_cargo to store my
> > fancy graph title, as well as all other widget specific data".
> > She goes ahead and use
> >
> > tk_cargo $graph set -title $graphtitle ...
> >
> > Unknowingly, programmer 2 is implementing just another fancy tooltip
> > with all the bells and whistles all modern tooltips are supposed to
> > have, including a title. Of course it uses tk_cargo to store its data!
> > So she wrotes
> >
> > tk_cargo $widget set -title $title ...
> >
> > Now, programmer 1 discovers the Fancytooltip package and decides to
> > use it along with his own Fancygraph. She will be very puzzled when
> > setting the tooltip changes its graph title upon redraw ...
> >
> > This is why tkcargo[1] implements tk_cargo as, well, cargotables.
> > This way each megawidget author can use his own table without fear to
> > step into each other toes. They just create the table (or tables) they
> > need in his private namespace and get along with them. No more
> > Average Joe Programmer being puzzled (or worse, upset).
> >
> > Now, some points about the functionality that are worth considering
> > IMHO (here, tk_cargo is the name of the cargo command):
> >
> > * Optionally set, on creation, a list of valid keys for a given
> >    cargo table for automatic validation. This is already implemented
> >    in tkcargo (the exact API can be adjusted).
> >
> >    % tk::cargotable tk_cargo {-title -foo -bar}
> >    ::tk_cargo
> >    % tk_cargo set . -title foo
> >    -title foo
> >    tk_cargo set . -wrongswitch foo
> >    bad key "-wrongswitch": must be -title, -foo, or -bar
> >
> > * Optionally set a command prefix to run when a value is set, get or
> >    unset (traces). An (unbaked) example can be
> >
> >    tk_cargo trace $window $cmdprefix
> >
> >    and when the data is modified call
> >
> >    {*}$cmdprefix $window $operation
> >
> >    This allows for automatic actions when the values are modified.
> >
> > * Perhaps a bit too complex, but a "would be nice to have": a binding
> >    table. Another unbaked example
> >
> >    tk_cargo bind $window $sequence $script
> >
> >    The implementation will rely on Tk_CreateBindingTable and friends.
> >    This will allow private bindings not interacting with the more general
> >    [bind] mechanism.
> >
> >
> > Regards
> >
> > Emiliano
> >
> > [1] https://chiselapp.com/user/egavilan/repository/tkcargo
> >
> >
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
>
> --
> Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] [Ext] Re: About tip#729

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

Hello

To avoid collisions you could also save internally to p.e. ${graph}-title

-----Ursprüngliche Nachricht-----
Von: Csaba Nemethi <csa...@t-...> 
Gesendet: Donnerstag, 11. September 2025 12:53
An: tcl...@li...
Betreff: [Ext] Re: [TCLCORE] About tip#729

Hi Emilano,

I have been using an attrib subcommand for all my mega-widgets for decades now, and it has always worked as expected without the need for several tables.

In your example it is sufficient to use prefixes to avoid name collisions:

     tk_cargo $graph set graph-title $graphtitle ...  ;# programmer 1

     tk_cargo $widget set tooltip-title $title ...    ;# programmer 2

And even if programmer 2 doesn't use the "tooltip" prefix, programmer 1 won't experience any name collision if he or she does use the "graph" 
prefix.  For safety, it is recommended to always prepend some prefix to the attribute names, as shown above.

You are stating that the better solution is to use several cargo tables. 
  But what if in your example both programmers use the same table, say

     tk::cargotable table1

If programmer 1 doesn't know that programmer 2 has already created a table of the name "table1" then his or her invocation of the above command will again create a table of the name "table1".  However, by doing this, all the data contained it table1 will get lost (I have tested this)!  Instead of name collisions there will be a fatal data loss!  IMHO, this is much worse than an incidental name collision (which can be avoided by using a prefix).

Best regards,

Csaba


Am 10.09.25 um 16:08 schrieb Emiliano G:
> Csaba, all:
> 
> I think the functionality proposed in TIP 729 "Add a tk_cargo 
> procedure to the core" is welcomed but I think it falls short for the 
> reasons explained below.
> 
> Consider this scenario: programmer 1 implements a fancy widget as a 
> megawidget, a graph widget, using a canvas. The fancy graph widget has 
> a -title option. "Fine", she says, "I'll use tk_cargo to store my 
> fancy graph title, as well as all other widget specific data".
> She goes ahead and use
> 
> tk_cargo $graph set -title $graphtitle ...
> 
> Unknowingly, programmer 2 is implementing just another fancy tooltip 
> with all the bells and whistles all modern tooltips are supposed to 
> have, including a title. Of course it uses tk_cargo to store its data!
> So she wrotes
> 
> tk_cargo $widget set -title $title ...
> 
> Now, programmer 1 discovers the Fancytooltip package and decides to 
> use it along with his own Fancygraph. She will be very puzzled when 
> setting the tooltip changes its graph title upon redraw ...
> 
> This is why tkcargo[1] implements tk_cargo as, well, cargotables.
> This way each megawidget author can use his own table without fear to 
> step into each other toes. They just create the table (or tables) they 
> need in his private namespace and get along with them. No more Average 
> Joe Programmer being puzzled (or worse, upset).
> 
> Now, some points about the functionality that are worth considering 
> IMHO (here, tk_cargo is the name of the cargo command):
> 
> * Optionally set, on creation, a list of valid keys for a given
>    cargo table for automatic validation. This is already implemented
>    in tkcargo (the exact API can be adjusted).
> 
>    % tk::cargotable tk_cargo {-title -foo -bar}
>    ::tk_cargo
>    % tk_cargo set . -title foo
>    -title foo
>    tk_cargo set . -wrongswitch foo
>    bad key "-wrongswitch": must be -title, -foo, or -bar
> 
> * Optionally set a command prefix to run when a value is set, get or
>    unset (traces). An (unbaked) example can be
> 
>    tk_cargo trace $window $cmdprefix
> 
>    and when the data is modified call
> 
>    {*}$cmdprefix $window $operation
> 
>    This allows for automatic actions when the values are modified.
> 
> * Perhaps a bit too complex, but a "would be nice to have": a binding
>    table. Another unbaked example
> 
>    tk_cargo bind $window $sequence $script
> 
>    The implementation will rely on Tk_CreateBindingTable and friends.
>    This will allow private bindings not interacting with the more general
>    [bind] mechanism.
> 
> 
> Regards
> 
> Emiliano
> 
> [1] https://chiselapp.com/user/egavilan/repository/tkcargo
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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



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

Re: [TCLCORE] About tip#729

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

Hi Emilano,

I have been using an attrib subcommand for all my mega-widgets for 
decades now, and it has always worked as expected without the need for 
several tables.

In your example it is sufficient to use prefixes to avoid name collisions:

     tk_cargo $graph set graph-title $graphtitle ...  ;# programmer 1

     tk_cargo $widget set tooltip-title $title ...    ;# programmer 2

And even if programmer 2 doesn't use the "tooltip" prefix, programmer 1 
won't experience any name collision if he or she does use the "graph" 
prefix.  For safety, it is recommended to always prepend some prefix to 
the attribute names, as shown above.

You are stating that the better solution is to use several cargo tables. 
  But what if in your example both programmers use the same table, say

     tk::cargotable table1

If programmer 1 doesn't know that programmer 2 has already created a 
table of the name "table1" then his or her invocation of the above 
command will again create a table of the name "table1".  However, by 
doing this, all the data contained it table1 will get lost (I have 
tested this)!  Instead of name collisions there will be a fatal data 
loss!  IMHO, this is much worse than an incidental name collision (which 
can be avoided by using a prefix).

Best regards,

Csaba


Am 10.09.25 um 16:08 schrieb Emiliano G:
> Csaba, all:
> 
> I think the functionality proposed in TIP 729 "Add a tk_cargo procedure
> to the core" is welcomed but I think it falls short for the reasons explained
> below.
> 
> Consider this scenario: programmer 1 implements a fancy widget as
> a megawidget, a graph widget, using a canvas. The fancy graph widget
> has a -title option. "Fine", she says, "I'll use tk_cargo to store my
> fancy graph title, as well as all other widget specific data".
> She goes ahead and use
> 
> tk_cargo $graph set -title $graphtitle ...
> 
> Unknowingly, programmer 2 is implementing just another fancy tooltip
> with all the bells and whistles all modern tooltips are supposed to
> have, including a title. Of course it uses tk_cargo to store its data!
> So she wrotes
> 
> tk_cargo $widget set -title $title ...
> 
> Now, programmer 1 discovers the Fancytooltip package and decides to
> use it along with his own Fancygraph. She will be very puzzled when
> setting the tooltip changes its graph title upon redraw ...
> 
> This is why tkcargo[1] implements tk_cargo as, well, cargotables.
> This way each megawidget author can use his own table without fear to
> step into each other toes. They just create the table (or tables) they
> need in his private namespace and get along with them. No more
> Average Joe Programmer being puzzled (or worse, upset).
> 
> Now, some points about the functionality that are worth considering
> IMHO (here, tk_cargo is the name of the cargo command):
> 
> * Optionally set, on creation, a list of valid keys for a given
>    cargo table for automatic validation. This is already implemented
>    in tkcargo (the exact API can be adjusted).
> 
>    % tk::cargotable tk_cargo {-title -foo -bar}
>    ::tk_cargo
>    % tk_cargo set . -title foo
>    -title foo
>    tk_cargo set . -wrongswitch foo
>    bad key "-wrongswitch": must be -title, -foo, or -bar
> 
> * Optionally set a command prefix to run when a value is set, get or
>    unset (traces). An (unbaked) example can be
> 
>    tk_cargo trace $window $cmdprefix
> 
>    and when the data is modified call
> 
>    {*}$cmdprefix $window $operation
> 
>    This allows for automatic actions when the values are modified.
> 
> * Perhaps a bit too complex, but a "would be nice to have": a binding
>    table. Another unbaked example
> 
>    tk_cargo bind $window $sequence $script
> 
>    The implementation will rely on Tk_CreateBindingTable and friends.
>    This will allow private bindings not interacting with the more general
>    [bind] mechanism.
> 
> 
> Regards
> 
> Emiliano
> 
> [1] https://chiselapp.com/user/egavilan/repository/tkcargo
> 
> 
> _______________________________________________
> 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] fossil server down?

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

The server seems to be working again.

- Marc

On Wed, Sep 10, 2025 at 4:45 PM Kevin Walzer <kw...@co...> wrote:

> Yes, I am seeing the same thing.
>
> > On Sep 10, 2025, at 6:19 PM, Marc Culler <cul...@gm...> wrote:
> >
> > 
> > When I try to pull the Tk repo I am getting a status code of 521, which
> is  a Cloudflare-specific code meaning that Cloudflare cannot contact the
> origin server.
> >
> > - Marc
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] About tip#729

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

+1

Finding a good name is still one of the hardest problems in programming. I've thought 'widgetdata' or 'widgetstore', but I'll leave this to native speakers.

Regards

Emiliano


El 10 de septiembre de 2025 5:56:26 p. m. GMT-03:00, Marc Culler <cul...@gm...> escribió:
>When I see the word "cargo" it does not bring to mind setting extra
>attributes for widgets. It brings to mind the package manager for the Rust
>language.
>
>Any chance that "cargo" could be changed, maybe to "attributes" or "attrs"?
>
>-Marc
>
>
>
>On Wed, Sep 10, 2025, 9:25 AM Csaba Nemethi <csa...@t-...>
>wrote:
>
>> Hi Emiliano,
>>
>> Many thanks for your comments!  Right now I am about to leave, but
>> tomorrow I will send you (and the list) a detailed answer.
>>
>> Best regards,
>>
>> Csaba
>>
>>
>> Am 10.09.25 um 16:08 schrieb Emiliano G:
>> > Csaba, all:
>> >
>> > I think the functionality proposed in TIP 729 "Add a tk_cargo procedure
>> > to the core" is welcomed but I think it falls short for the reasons
>> explained
>> > below.
>> >
>> > Consider this scenario: programmer 1 implements a fancy widget as
>> > a megawidget, a graph widget, using a canvas. The fancy graph widget
>> > has a -title option. "Fine", she says, "I'll use tk_cargo to store my
>> > fancy graph title, as well as all other widget specific data".
>> > She goes ahead and use
>> >
>> > tk_cargo $graph set -title $graphtitle ...
>> >
>> > Unknowingly, programmer 2 is implementing just another fancy tooltip
>> > with all the bells and whistles all modern tooltips are supposed to
>> > have, including a title. Of course it uses tk_cargo to store its data!
>> > So she wrotes
>> >
>> > tk_cargo $widget set -title $title ...
>> >
>> > Now, programmer 1 discovers the Fancytooltip package and decides to
>> > use it along with his own Fancygraph. She will be very puzzled when
>> > setting the tooltip changes its graph title upon redraw ...
>> >
>> > This is why tkcargo[1] implements tk_cargo as, well, cargotables.
>> > This way each megawidget author can use his own table without fear to
>> > step into each other toes. They just create the table (or tables) they
>> > need in his private namespace and get along with them. No more
>> > Average Joe Programmer being puzzled (or worse, upset).
>> >
>> > Now, some points about the functionality that are worth considering
>> > IMHO (here, tk_cargo is the name of the cargo command):
>> >
>> > * Optionally set, on creation, a list of valid keys for a given
>> >    cargo table for automatic validation. This is already implemented
>> >    in tkcargo (the exact API can be adjusted).
>> >
>> >    % tk::cargotable tk_cargo {-title -foo -bar}
>> >    ::tk_cargo
>> >    % tk_cargo set . -title foo
>> >    -title foo
>> >    tk_cargo set . -wrongswitch foo
>> >    bad key "-wrongswitch": must be -title, -foo, or -bar
>> >
>> > * Optionally set a command prefix to run when a value is set, get or
>> >    unset (traces). An (unbaked) example can be
>> >
>> >    tk_cargo trace $window $cmdprefix
>> >
>> >    and when the data is modified call
>> >
>> >    {*}$cmdprefix $window $operation
>> >
>> >    This allows for automatic actions when the values are modified.
>> >
>> > * Perhaps a bit too complex, but a "would be nice to have": a binding
>> >    table. Another unbaked example
>> >
>> >    tk_cargo bind $window $sequence $script
>> >
>> >    The implementation will rely on Tk_CreateBindingTable and friends.
>> >    This will allow private bindings not interacting with the more general
>> >    [bind] mechanism.
>> >
>> >
>> > Regards
>> >
>> > Emiliano
>> >
>> > [1] https://chiselapp.com/user/egavilan/repository/tkcargo
>> >
>> >
>> > _______________________________________________
>> > Tcl-Core mailing list
>> > Tcl...@li...
>> > https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>> --
>> Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...
>>
>>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>

-- 
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

Re: [TCLCORE] About tip#729

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

My reaction too.

-- Steve
On 11 Sep 2025 at 4:57 AM +0800, Marc Culler <cul...@gm...>, wrote:
> When I see the word "cargo" it does not bring to mind setting extra attributes for widgets. It brings to mind the package manager for the Rust language.
>
> Any chance that "cargo" could be changed, maybe to "attributes" or "attrs"?
>
> -Marc
>
>
>
> On Wed, Sep 10, 2025, 9:25 AM Csaba Nemethi <csa...@t-...> wrote:
> > Hi Emiliano,
> >
> > Many thanks for your comments!  Right now I am about to leave, but
> > tomorrow I will send you (and the list) a detailed answer.
> >
> > Best regards,
> >
> > Csaba
> >
> >
> > Am 10.09.25 um 16:08 schrieb Emiliano G:
> > > Csaba, all:
> > >
> > > I think the functionality proposed in TIP 729 "Add a tk_cargo procedure
> > > to the core" is welcomed but I think it falls short for the reasons explained
> > > below.
> > >
> > > Consider this scenario: programmer 1 implements a fancy widget as
> > > a megawidget, a graph widget, using a canvas. The fancy graph widget
> > > has a -title option. "Fine", she says, "I'll use tk_cargo to store my
> > > fancy graph title, as well as all other widget specific data".
> > > She goes ahead and use
> > >
> > > tk_cargo $graph set -title $graphtitle ...
> > >
> > > Unknowingly, programmer 2 is implementing just another fancy tooltip
> > > with all the bells and whistles all modern tooltips are supposed to
> > > have, including a title. Of course it uses tk_cargo to store its data!
> > > So she wrotes
> > >
> > > tk_cargo $widget set -title $title ...
> > >
> > > Now, programmer 1 discovers the Fancytooltip package and decides to
> > > use it along with his own Fancygraph. She will be very puzzled when
> > > setting the tooltip changes its graph title upon redraw ...
> > >
> > > This is why tkcargo[1] implements tk_cargo as, well, cargotables.
> > > This way each megawidget author can use his own table without fear to
> > > step into each other toes. They just create the table (or tables) they
> > > need in his private namespace and get along with them. No more
> > > Average Joe Programmer being puzzled (or worse, upset).
> > >
> > > Now, some points about the functionality that are worth considering
> > > IMHO (here, tk_cargo is the name of the cargo command):
> > >
> > > * Optionally set, on creation, a list of valid keys for a given
> > >    cargo table for automatic validation. This is already implemented
> > >    in tkcargo (the exact API can be adjusted).
> > >
> > >    % tk::cargotable tk_cargo {-title -foo -bar}
> > >    ::tk_cargo
> > >    % tk_cargo set . -title foo
> > >    -title foo
> > >    tk_cargo set . -wrongswitch foo
> > >    bad key "-wrongswitch": must be -title, -foo, or -bar
> > >
> > > * Optionally set a command prefix to run when a value is set, get or
> > >    unset (traces). An (unbaked) example can be
> > >
> > >    tk_cargo trace $window $cmdprefix
> > >
> > >    and when the data is modified call
> > >
> > >    {*}$cmdprefix $window $operation
> > >
> > >    This allows for automatic actions when the values are modified.
> > >
> > > * Perhaps a bit too complex, but a "would be nice to have": a binding
> > >    table. Another unbaked example
> > >
> > >    tk_cargo bind $window $sequence $script
> > >
> > >    The implementation will rely on Tk_CreateBindingTable and friends.
> > >    This will allow private bindings not interacting with the more general
> > >    [bind] mechanism.
> > >
> > >
> > > Regards
> > >
> > > Emiliano
> > >
> > > [1] https://chiselapp.com/user/egavilan/repository/tkcargo
> > >
> > >
> > > _______________________________________________
> > > Tcl-Core mailing list
> > > Tcl...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tcl-core
> >
> > --
> > Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...
> >
> >
> >
> > _______________________________________________
> > 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

Re: [TCLCORE] fossil server down?

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

Yes, I am seeing the same thing. 

> On Sep 10, 2025, at 6:19 PM, Marc Culler <cul...@gm...> wrote:
> 
> 
> When I try to pull the Tk repo I am getting a status code of 521, which is  a Cloudflare-specific code meaning that Cloudflare cannot contact the origin server.
> 
> - Marc
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] fossil server down?

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

When I try to pull the Tk repo I am getting a status code of 521, which is
a Cloudflare-specific code meaning that Cloudflare cannot contact the
origin server.

- Marc

Re: [TCLCORE] About tip#729

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

When I see the word "cargo" it does not bring to mind setting extra
attributes for widgets. It brings to mind the package manager for the Rust
language.

Any chance that "cargo" could be changed, maybe to "attributes" or "attrs"?

-Marc



On Wed, Sep 10, 2025, 9:25 AM Csaba Nemethi <csa...@t-...>
wrote:

> Hi Emiliano,
>
> Many thanks for your comments!  Right now I am about to leave, but
> tomorrow I will send you (and the list) a detailed answer.
>
> Best regards,
>
> Csaba
>
>
> Am 10.09.25 um 16:08 schrieb Emiliano G:
> > Csaba, all:
> >
> > I think the functionality proposed in TIP 729 "Add a tk_cargo procedure
> > to the core" is welcomed but I think it falls short for the reasons
> explained
> > below.
> >
> > Consider this scenario: programmer 1 implements a fancy widget as
> > a megawidget, a graph widget, using a canvas. The fancy graph widget
> > has a -title option. "Fine", she says, "I'll use tk_cargo to store my
> > fancy graph title, as well as all other widget specific data".
> > She goes ahead and use
> >
> > tk_cargo $graph set -title $graphtitle ...
> >
> > Unknowingly, programmer 2 is implementing just another fancy tooltip
> > with all the bells and whistles all modern tooltips are supposed to
> > have, including a title. Of course it uses tk_cargo to store its data!
> > So she wrotes
> >
> > tk_cargo $widget set -title $title ...
> >
> > Now, programmer 1 discovers the Fancytooltip package and decides to
> > use it along with his own Fancygraph. She will be very puzzled when
> > setting the tooltip changes its graph title upon redraw ...
> >
> > This is why tkcargo[1] implements tk_cargo as, well, cargotables.
> > This way each megawidget author can use his own table without fear to
> > step into each other toes. They just create the table (or tables) they
> > need in his private namespace and get along with them. No more
> > Average Joe Programmer being puzzled (or worse, upset).
> >
> > Now, some points about the functionality that are worth considering
> > IMHO (here, tk_cargo is the name of the cargo command):
> >
> > * Optionally set, on creation, a list of valid keys for a given
> >    cargo table for automatic validation. This is already implemented
> >    in tkcargo (the exact API can be adjusted).
> >
> >    % tk::cargotable tk_cargo {-title -foo -bar}
> >    ::tk_cargo
> >    % tk_cargo set . -title foo
> >    -title foo
> >    tk_cargo set . -wrongswitch foo
> >    bad key "-wrongswitch": must be -title, -foo, or -bar
> >
> > * Optionally set a command prefix to run when a value is set, get or
> >    unset (traces). An (unbaked) example can be
> >
> >    tk_cargo trace $window $cmdprefix
> >
> >    and when the data is modified call
> >
> >    {*}$cmdprefix $window $operation
> >
> >    This allows for automatic actions when the values are modified.
> >
> > * Perhaps a bit too complex, but a "would be nice to have": a binding
> >    table. Another unbaked example
> >
> >    tk_cargo bind $window $sequence $script
> >
> >    The implementation will rely on Tk_CreateBindingTable and friends.
> >    This will allow private bindings not interacting with the more general
> >    [bind] mechanism.
> >
> >
> > Regards
> >
> > Emiliano
> >
> > [1] https://chiselapp.com/user/egavilan/repository/tkcargo
> >
> >
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
>
> --
> Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>