tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] How do we deprecate a command?

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

For a print-once-on-first-use, I'd probably use an enter execution trace on the command that unregisters itself when called as well as printing the message. The only real difficulty is in determining the correct route to write such messages where they'll be picked up by someone who can do something about them; there's a sense in which [tclLog] is just kicking the can down the road (though it might be the right way anyway).

Longer term, for a Tcl or Tk command the first thing would be to update its documentation to say that it is deprecated (as well as adding the warning message). The step beyond that (presumably with a release between to allow users to learn they should migrate) is to stop documenting the command. Final removal can come later. Those three phases probably ought to be announced.

If there's a recommended replacement, the deprecation message should mention it. If there is no replacement, the deprecation message should encourage users to contact us if they need the feature.

Donal.

________________________________
From: Steve Landers
Sent: Tuesday, March 25, 2025 02:43
To: Donald G Porter; Tcl Core List; Marc Culler
Subject: Re: [TCLCORE] How do we deprecate a command?

Does tclLog include a standard mechanism to flag deprecated code?  Does it ensure a deprecation message is only shown once and not every time the deprecated command is called?

Not trying to be argumentative I just don’t think your message was particularly helpful in the context of what Marc was asking.

-- Steve
On 25 Mar 2025 at 10:17 AM +0800, Steve Landers <st...@di...>, wrote:
FWIW I like the macOS approach of warning about the use of deprecated features with a message to stdout unlike macOS I would prefer seeing the message only once for each tcl “session” and only for one release before removal.  If we had a generic mechanism to do that I’m sure we could use it in a number of places.

-- Steve
On 25 Mar 2025 at 6:34 AM +0800, Marc Culler <cul...@gm...>, wrote:
Thanks, Don.  Could you give me a hint about where to look for that?

What I can see, by looking at generic/tclIOUtil.c, is that when a function becomes obsolete nothing is done other than to add a comment /* Obsolete */ in the source code.  Presumably it just vanishes one day.  Sometimes there are also comments suggesting a version in which a certain function should be removed.  But I don't see any sign of any effort to notify a user that they have used an obsolete function or command, e.g. by printing a message to stderr.

In the case of wm grid, nothing would really break when it becomes a no-op.  There is no evidence that there are any programs (other than the widget demo) which use it, but even if one did exist, the worst that would happen is that a toplevel would become smoothly resizable instead of being resizable only to multiples of a certain number of pixels in each direction.  And that is only on X11 - it is already a no-op  on Windows and Aqua, in the sense that it has no effect on the sizes that a toplevel can be resized to.  Nonetheless it causes dramatic breakage by corrupting the internal Tk window structures on all platforms, as can be seen in the "split windows" demo.  So there would be an overall reduction in breakage if that command were simply quietly removed from the language.

Still, it seems like it might be better if there were some sort of notification that the behavior has been changed intentionally.  But I am getting the impression that there is no expectation of such a thing, nor any standard way of doing it.

- Marc

On Mon, Mar 24, 2025 at 11:46 AM Donald G Porter via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote:

For an example (that you can follow or not), look at how the [case] command was
removed from the built-in command set of Tcl.

On 3/24/25 12:17, Marc Culler wrote:
> Suppose that a command, let's say the command "wm grid", is going to be removed from Tk.  Even though we suspect that no one is using it in any applications, we would like to do the removal in two stages.  First modify it so it is a no-op, then remove it.
>
> The natural thing to do when the command  becomes a no-op would be to generate a deprecation message which says that the command is deprecated and no longer has any effect.  What is the standard way to do that? Just print the message to stderr?  Or is there something better, perhaps built-in to Tcl, which is usually used in this situation?
>
> - Marc

--
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...<mailto:don...@ni...>             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ [math.nist.gov]<https://urldefense.com/v3/__http://math.nist.gov/*DPorter/__;fg!!PDiH4ENfjr2_Jw!BvU5DdXvtsizKifWaxJusXFv6B9WUS4W46jf7E7UkDhGPuYPxQx7C2wj2WKdCVDGFYZDw4WczHmYMyHTZFHkz4odzYHUwIPQ$>                                  NIST |
|______________________________________________________________________|



_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!BvU5DdXvtsizKifWaxJusXFv6B9WUS4W46jf7E7UkDhGPuYPxQx7C2wj2WKdCVDGFYZDw4WczHmYMyHTZFHkz4odzcpcSIAk$>
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!BvU5DdXvtsizKifWaxJusXFv6B9WUS4W46jf7E7UkDhGPuYPxQx7C2wj2WKdCVDGFYZDw4WczHmYMyHTZFHkz4odzcpcSIAk$>
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!BvU5DdXvtsizKifWaxJusXFv6B9WUS4W46jf7E7UkDhGPuYPxQx7C2wj2WKdCVDGFYZDw4WczHmYMyHTZFHkz4odzcpcSIAk$>

Re: [TCLCORE] How do we deprecate a command?

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

Hi all,

Below is an overview of how NaviServer handles deprecation in various parts of the codebase. 
Maybe this serves as useful food for thought for refining a common infrastructure in Tcl.

1. Deprecating a C Function: To mark a C function as deprecated, we add a specific attribute. The compiler then emits a warning when this function is used. For example:

   NS_EXTERN const char * Ns_ConnLocation(Ns_Conn *conn)
       NS_GNUC_DEPRECATED_FOR(Ns_ConnLocationAppend);

   This tells developers to use `Ns_ConnLocationAppend` instead.


2. Fine-Grained Deprecation (e.g. Options, Configuration Parameters, etc.): For more granular deprecation - such as individual options or configuration parameters — NaviServer uses:
   
   Ns_LogDeprecated(Tcl_Obj *const* objv, TCL_SIZE_T objc, const char *alternative, const char *explanation)
       NS_GNUC_NONNULL(1);

   This function logs deprecation warnings, optionally providing an alternative and an explanation.


3. Scripting-Level Deprecation: At the scripting level, NaviServer provides a procedure to mark features as deprecated:
   
   proc ns_deprecated {{alternative ""} {explanation ""}} {,,,}

   This allows script-level deprecation messages.


Compiler Deprecation Macro

The macro below defines the deprecation attribute for GNU C compilers (version 4.5 or newer), so that developers get a clear warning with an alternative suggestion:
   
   #if __GNUC_PREREQ(4,5)
   # define NS_GNUC_DEPRECATED_FOR(f) __attribute__((deprecated("Use " #f " instead")))
   #else
   # define NS_GNUC_DEPRECATED_FOR(f) NS_GNUC_DEPRECATED
   #endif


NaviServer 5 introduces a dedicated deprecation severity level, which can be easily toggled on or off (see [1] for details).

NSF follows the same patter: When used inside NaviServer, logging is directed to the NaviServer system log; when used externally, it writes to stderr. The logging procedure is designed to be redefined, for example, to route messages to a custom window.

Aside the coding side, NaviServer following the following policies
- NaviServer provides an optional macro NS_NO_DEPRECATED for compiling without deprecated code (this excludes the depreciation since the last release to give people a time window to adjust) - somewhat similar to TCL_NO_DEPRECATED
- deprecated Tcl-level calls are removed from the documentation, but the documentation still lists it.  We do no want to “advertise” deprecated functions.

all the best
-g

[1] https://naviserver.sourceforge.io/5.0/naviserver/files/ns_log.html
[2] https://naviserver.sourceforge.io/5.0/naviserver/files/commandlist.html


> On 25.03.2025, at 08:04, Harald Oehlmann <har...@el...> wrote:
> 
> Hi Mark,
> to my knowledge:
> 
> - author a TIP and vote it
> 
> - modify functionality (in case of "wm grid": make it a no-op or modify it)
> 
> - put the functionality to remove in:
> #ifdef TK_NO_DEPRECATED
> 
> - put a note in the man page that it is a deprecated feature.
> This is the nroff file in the doc folder.
> 
> Take care,
> Harald
> 
> Am 24.03.2025 um 23:33 schrieb Marc Culler:
>> Thanks, Don.  Could you give me a hint about where to look for that?
>> What I can see, by looking at generic/tclIOUtil.c, is that when a function becomes obsolete nothing is done other than to add a comment /* Obsolete */ in the source code.  Presumably it just vanishes one day.  Sometimes there are also comments suggesting a version in which a certain function should be removed.  But I don't see any sign of any effort to notify a user that they have used an obsolete function or command, e.g. by printing a message to stderr.
>> In the case of wm grid, nothing would really break when it becomes a no- op.  There is no evidence that there are any programs (other than the widget demo) which use it, but even if one did exist, the worst that would happen is that a toplevel would become smoothly resizable instead of being resizable only to multiples of a certain number of pixels in each direction.  And that is only on X11 - it is already a no-op  on Windows and Aqua, in the sense that it has no effect on the sizes that a toplevel can be resized to.  Nonetheless it causes dramatic breakage by corrupting the internal Tk window structures on all platforms, as can be seen in the "split windows" demo.  So there would be an overall reduction in breakage if that command were simply quietly removed from the language.
>> Still, it seems like it might be better if there were some sort of notification that the behavior has been changed intentionally.  But I am getting the impression that there is no expectation of such a thing, nor any standard way of doing it.
>> - Marc
>> On Mon, Mar 24, 2025 at 11:46 AM Donald G Porter via Tcl-Core <tcl- co...@li... <mailto:tcl...@li...>> wrote:
>>    For an example (that you can follow or not), look at how the [case]
>>    command was
>>    removed from the built-in command set of Tcl.
>>    On 3/24/25 12:17, Marc Culler wrote:
>>     > Suppose that a command, let's say the command "wm grid", is going
>>    to be removed from Tk.  Even though we suspect that no one is using
>>    it in any applications, we would like to do the removal in two
>>    stages.  First modify it so it is a no-op, then remove it.
>>     >
>>     > The natural thing to do when the command  becomes a no-op would
>>    be to generate a deprecation message which says that the command is
>>    deprecated and no longer has any effect.  What is the standard way
>>    to do that? Just print the message to stderr?  Or is there something
>>    better, perhaps built-in to Tcl, which is usually used in this
>>    situation?
>>     >
>>     > - Marc
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] How do we deprecate a command?

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

Hi Mark,
to my knowledge:

- author a TIP and vote it

- modify functionality (in case of "wm grid": make it a no-op or modify it)

- put the functionality to remove in:
#ifdef TK_NO_DEPRECATED

- put a note in the man page that it is a deprecated feature.
This is the nroff file in the doc folder.

Take care,
Harald

Am 24.03.2025 um 23:33 schrieb Marc Culler:
> Thanks, Don.  Could you give me a hint about where to look for that?
> 
> What I can see, by looking at generic/tclIOUtil.c, is that when a 
> function becomes obsolete nothing is done other than to add a comment /* 
> Obsolete */ in the source code.  Presumably it just vanishes one day.  
> Sometimes there are also comments suggesting a version in which a 
> certain function should be removed.  But I don't see any sign of any 
> effort to notify a user that they have used an obsolete function or 
> command, e.g. by printing a message to stderr.
> 
> In the case of wm grid, nothing would really break when it becomes a no- 
> op.  There is no evidence that there are any programs (other than the 
> widget demo) which use it, but even if one did exist, the worst that 
> would happen is that a toplevel would become smoothly resizable instead 
> of being resizable only to multiples of a certain number of pixels in 
> each direction.  And that is only on X11 - it is already a no-op  on 
> Windows and Aqua, in the sense that it has no effect on the sizes that a 
> toplevel can be resized to.  Nonetheless it causes dramatic breakage by 
> corrupting the internal Tk window structures on all platforms, as can be 
> seen in the "split windows" demo.  So there would be an overall 
> reduction in breakage if that command were simply quietly removed from 
> the language.
> 
> Still, it seems like it might be better if there were some sort of 
> notification that the behavior has been changed intentionally.  But I am 
> getting the impression that there is no expectation of such a thing, nor 
> any standard way of doing it.
> 
> - Marc
> 
> On Mon, Mar 24, 2025 at 11:46 AM Donald G Porter via Tcl-Core <tcl- 
> co...@li... <mailto:tcl...@li...>> wrote:
> 
> 
>     For an example (that you can follow or not), look at how the [case]
>     command was
>     removed from the built-in command set of Tcl.
> 
>     On 3/24/25 12:17, Marc Culler wrote:
>      > Suppose that a command, let's say the command "wm grid", is going
>     to be removed from Tk.  Even though we suspect that no one is using
>     it in any applications, we would like to do the removal in two
>     stages.  First modify it so it is a no-op, then remove it.
>      >
>      > The natural thing to do when the command  becomes a no-op would
>     be to generate a deprecation message which says that the command is
>     deprecated and no longer has any effect.  What is the standard way
>     to do that? Just print the message to stderr?  Or is there something
>     better, perhaps built-in to Tcl, which is usually used in this
>     situation?
>      >
>      > - Marc

Re: [TCLCORE] How do we deprecate a command?

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

Does tclLog include a standard mechanism to flag deprecated code?  Does it ensure a deprecation message is only shown once and not every time the deprecated command is called?

Not trying to be argumentative I just don’t think your message was particularly helpful in the context of what Marc was asking.

-- Steve
On 25 Mar 2025 at 10:17 AM +0800, Steve Landers <st...@di...>, wrote:
> FWIW I like the macOS approach of warning about the use of deprecated features with a message to stdout unlike macOS I would prefer seeing the message only once for each tcl “session” and only for one release before removal.  If we had a generic mechanism to do that I’m sure we could use it in a number of places.
>
> -- Steve
> On 25 Mar 2025 at 6:34 AM +0800, Marc Culler <cul...@gm...>, wrote:
> > Thanks, Don.  Could you give me a hint about where to look for that?
> >
> > What I can see, by looking at generic/tclIOUtil.c, is that when a function becomes obsolete nothing is done other than to add a comment /* Obsolete */ in the source code.  Presumably it just vanishes one day.  Sometimes there are also comments suggesting a version in which a certain function should be removed.  But I don't see any sign of any effort to notify a user that they have used an obsolete function or command, e.g. by printing a message to stderr.
> >
> > In the case of wm grid, nothing would really break when it becomes a no-op.  There is no evidence that there are any programs (other than the widget demo) which use it, but even if one did exist, the worst that would happen is that a toplevel would become smoothly resizable instead of being resizable only to multiples of a certain number of pixels in each direction.  And that is only on X11 - it is already a no-op  on Windows and Aqua, in the sense that it has no effect on the sizes that a toplevel can be resized to.  Nonetheless it causes dramatic breakage by corrupting the internal Tk window structures on all platforms, as can be seen in the "split windows" demo.  So there would be an overall reduction in breakage if that command were simply quietly removed from the language.
> >
> > Still, it seems like it might be better if there were some sort of notification that the behavior has been changed intentionally.  But I am getting the impression that there is no expectation of such a thing, nor any standard way of doing it.
> >
> > - Marc
> >
> > > On Mon, Mar 24, 2025 at 11:46 AM Donald G Porter via Tcl-Core <tcl...@li...> wrote:
> > > >
> > > > For an example (that you can follow or not), look at how the [case] command was
> > > > removed from the built-in command set of Tcl.
> > > >
> > > > On 3/24/25 12:17, Marc Culler wrote:
> > > > > Suppose that a command, let's say the command "wm grid", is going to be removed from Tk.  Even though we suspect that no one is using it in any applications, we would like to do the removal in two stages.  First modify it so it is a no-op, then remove it.
> > > > >
> > > > > The natural thing to do when the command  becomes a no-op would be to generate a deprecation message which says that the command is deprecated and no longer has any effect.  What is the standard way to do that? Just print the message to stderr?  Or is there something better, perhaps built-in to Tcl, which is usually used in this situation?
> > > > >
> > > > > - Marc
> > > >
> > > > --
> > > > | Don Porter            Applied and Computational Mathematics Division |
> > > > | don...@ni...             Information Technology Laboratory |
> > > > | http://math.nist.gov/~DPorter/                                  NIST |
> > > > |______________________________________________________________________|
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] How do we deprecate a command?

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

See [tclLog].

> On Mar 24, 2025, at 7:52 PM, Steve Landers <st...@di...> wrote:
> 
> FWIW I like the macOS approach of warning about the use of deprecated features with a message to stdout unlike macOS I would prefer seeing the message only once for each tcl “session” and only for one release before removal.  If we had a generic mechanism to do that I’m sure we could use it in a number of places.
> 
> -- Steve
> On 25 Mar 2025 at 6:34 AM +0800, Marc Culler <cul...@gm...>, wrote:
>> Thanks, Don.  Could you give me a hint about where to look for that?
>> 
>> What I can see, by looking at generic/tclIOUtil.c, is that when a function becomes obsolete nothing is done other than to add a comment /* Obsolete */ in the source code.  Presumably it just vanishes one day.  Sometimes there are also comments suggesting a version in which a certain function should be removed.  But I don't see any sign of any effort to notify a user that they have used an obsolete function or command, e.g. by printing a message to stderr.
>> 
>> In the case of wm grid, nothing would really break when it becomes a no-op.  There is no evidence that there are any programs (other than the widget demo) which use it, but even if one did exist, the worst that would happen is that a toplevel would become smoothly resizable instead of being resizable only to multiples of a certain number of pixels in each direction.  And that is only on X11 - it is already a no-op  on Windows and Aqua, in the sense that it has no effect on the sizes that a toplevel can be resized to.  Nonetheless it causes dramatic breakage by corrupting the internal Tk window structures on all platforms, as can be seen in the "split windows" demo.  So there would be an overall reduction in breakage if that command were simply quietly removed from the language.
>> 
>> Still, it seems like it might be better if there were some sort of notification that the behavior has been changed intentionally.  But I am getting the impression that there is no expectation of such a thing, nor any standard way of doing it.
>> 
>> - Marc
>> 
>> On Mon, Mar 24, 2025 at 11:46 AM Donald G Porter via Tcl-Core <tcl...@li... <mailto:tcl...@li...>> wrote:
>>> 
>>> For an example (that you can follow or not), look at how the [case] command was
>>> removed from the built-in command set of Tcl.
>>> 
>>> On 3/24/25 12:17, Marc Culler wrote:
>>> > Suppose that a command, let's say the command "wm grid", is going to be removed from Tk.  Even though we suspect that no one is using it in any applications, we would like to do the removal in two stages.  First modify it so it is a no-op, then remove it.
>>> >
>>> > The natural thing to do when the command  becomes a no-op would be to generate a deprecation message which says that the command is deprecated and no longer has any effect.  What is the standard way to do that? Just print the message to stderr?  Or is there something better, perhaps built-in to Tcl, which is usually used in this situation?
>>> >
>>> > - Marc
>>> 
>>> --
>>> | Don Porter            Applied and Computational Mathematics Division |
>>> | don...@ni... <mailto:don...@ni...>             Information Technology Laboratory |
>>> | http://math.nist.gov/~DPorter/                                  NIST |
>>> |______________________________________________________________________|
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Tcl-Core mailing list
>>> Tcl...@li... <mailto:Tcl...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>> _______________________________________________
>> 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] How do we deprecate a command?

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

FWIW I like the macOS approach of warning about the use of deprecated features with a message to stdout unlike macOS I would prefer seeing the message only once for each tcl “session” and only for one release before removal.  If we had a generic mechanism to do that I’m sure we could use it in a number of places.

-- Steve
On 25 Mar 2025 at 6:34 AM +0800, Marc Culler <cul...@gm...>, wrote:
> Thanks, Don.  Could you give me a hint about where to look for that?
>
> What I can see, by looking at generic/tclIOUtil.c, is that when a function becomes obsolete nothing is done other than to add a comment /* Obsolete */ in the source code.  Presumably it just vanishes one day.  Sometimes there are also comments suggesting a version in which a certain function should be removed.  But I don't see any sign of any effort to notify a user that they have used an obsolete function or command, e.g. by printing a message to stderr.
>
> In the case of wm grid, nothing would really break when it becomes a no-op.  There is no evidence that there are any programs (other than the widget demo) which use it, but even if one did exist, the worst that would happen is that a toplevel would become smoothly resizable instead of being resizable only to multiples of a certain number of pixels in each direction.  And that is only on X11 - it is already a no-op  on Windows and Aqua, in the sense that it has no effect on the sizes that a toplevel can be resized to.  Nonetheless it causes dramatic breakage by corrupting the internal Tk window structures on all platforms, as can be seen in the "split windows" demo.  So there would be an overall reduction in breakage if that command were simply quietly removed from the language.
>
> Still, it seems like it might be better if there were some sort of notification that the behavior has been changed intentionally.  But I am getting the impression that there is no expectation of such a thing, nor any standard way of doing it.
>
> - Marc
>
> > On Mon, Mar 24, 2025 at 11:46 AM Donald G Porter via Tcl-Core <tcl...@li...> wrote:
> > >
> > > For an example (that you can follow or not), look at how the [case] command was
> > > removed from the built-in command set of Tcl.
> > >
> > > On 3/24/25 12:17, Marc Culler wrote:
> > > > Suppose that a command, let's say the command "wm grid", is going to be removed from Tk.  Even though we suspect that no one is using it in any applications, we would like to do the removal in two stages.  First modify it so it is a no-op, then remove it.
> > > >
> > > > The natural thing to do when the command  becomes a no-op would be to generate a deprecation message which says that the command is deprecated and no longer has any effect.  What is the standard way to do that? Just print the message to stderr?  Or is there something better, perhaps built-in to Tcl, which is usually used in this situation?
> > > >
> > > > - Marc
> > >
> > > --
> > > | Don Porter            Applied and Computational Mathematics Division |
> > > | don...@ni...             Information Technology Laboratory |
> > > | http://math.nist.gov/~DPorter/                                  NIST |
> > > |______________________________________________________________________|
> > >
> > >
> > >
> > > _______________________________________________
> > > 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] How do we deprecate a command?

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

Thanks, Don.  Could you give me a hint about where to look for that?

What I can see, by looking at generic/tclIOUtil.c, is that when a function
becomes obsolete nothing is done other than to add a comment /* Obsolete */
in the source code.  Presumably it just vanishes one day.  Sometimes there
are also comments suggesting a version in which a certain function should
be removed.  But I don't see any sign of any effort to notify a user that
they have used an obsolete function or command, e.g. by printing a message
to stderr.

In the case of wm grid, nothing would really break when it becomes a
no-op.  There is no evidence that there are any programs (other than the
widget demo) which use it, but even if one did exist, the worst that would
happen is that a toplevel would become smoothly resizable instead of being
resizable only to multiples of a certain number of pixels in each
direction.  And that is only on X11 - it is already a no-op  on Windows and
Aqua, in the sense that it has no effect on the sizes that a toplevel can
be resized to.  Nonetheless it causes dramatic breakage by corrupting the
internal Tk window structures on all platforms, as can be seen in the
"split windows" demo.  So there would be an overall reduction in breakage
if that command were simply quietly removed from the language.

Still, it seems like it might be better if there were some sort of
notification that the behavior has been changed intentionally.  But I am
getting the impression that there is no expectation of such a thing, nor
any standard way of doing it.

- Marc

On Mon, Mar 24, 2025 at 11:46 AM Donald G Porter via Tcl-Core <
tcl...@li...> wrote:

>
> For an example (that you can follow or not), look at how the [case]
> command was
> removed from the built-in command set of Tcl.
>
> On 3/24/25 12:17, Marc Culler wrote:
> > Suppose that a command, let's say the command "wm grid", is going to be
> removed from Tk.  Even though we suspect that no one is using it in any
> applications, we would like to do the removal in two stages.  First modify
> it so it is a no-op, then remove it.
> >
> > The natural thing to do when the command  becomes a no-op would be to
> generate a deprecation message which says that the command is deprecated
> and no longer has any effect.  What is the standard way to do that? Just
> print the message to stderr?  Or is there something better, perhaps
> built-in to Tcl, which is usually used in this situation?
> >
> > - Marc
>
> --
> | Don Porter            Applied and Computational Mathematics Division |
> | don...@ni...             Information Technology Laboratory |
> | http://math.nist.gov/~DPorter/                                  NIST |
> |______________________________________________________________________|
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Report of biweekly Tcl/Tk telco of 2025-03-24

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

Thanks Paul,

I have downloaded tktreectrl and will work through it eventually.  Still working on tclx. There's also some build issues here with tkImg, probably a local environment or configuration issue; won't know until I get to it.

At some point, the changes I make will need an official home. I have 2 different sources for Tclx, but there aren't any significant differences between them.

-Brian

> On Mar 24, 2025, at 13:17, Paul Obermeier <pa...@po...> wrote:
> 
> Hi Brian,
> 
> Regarding external packages, the following official versions seem to work with Tcl 9 and Tcl 8.6:
> 
> Tcllib       2.0 https://core.tcl-lang.org/tcllib/doc/trunk/embedded/index.md
> Tklib        0.9 https://core.tcl-lang.org/tklib/doc/trunk/embedded/index.md
> Tktable      2.12   https://github.com/bohagan1/TkTable
> tkcon        2.8    https://github.com/bohagan1/TkCon
> tkImg        2.0.1  https://sourceforge.net/projects/tkimg/
> BWidget      1.10.1 https://core.tcl-lang.org/bwidget/timeline?t=bwidget-1-10-1
> 
> Note, that there is no offical Tcl9-ready tktreectrl. Version 2.4.2 is based on 2.4.1 and ported by me.
> tktreectrl   2.4.2 https://www.tcl3d.org/bawt/download/InputLibs/treectrl-2.4.2.7z
> 
> Regarding tclxml and TclX I do not know about Tcl9-ready versions.
> 
> Paul
> 
> Am 24.03.2025 um 17:01 schrieb Brian Griffin:
>> For a project I’m working on, these are the packages I’ll need in Tcl 9 compatible versions.
>> The list would be longer if all the used Tcllib and Tklib modules were enumerated.
>> Most of these already have Tcl9 versions.
>> 
>> Currently used with Tcl 8.6.16:
>> Package name	Version
>> iTcl		4.2.2
>> Thread		2.8.7
>> http		2.9.5
>> msgcat		1.6.1
>> tcltest		2.5.3
>> sqlite		3.40.0
>> Tcllib		1.20   (20 different modules)
>> Tk		8.6.16
>> Tklib		0.9    (5 different modules)
>> Tktable		2.11
>> tkcon		2.7.10
>> tclxml
>> 	dom	3.2
>> 	xml	3.2
>> tkImg		1.4.6
>> tktreectrl	2.4.1
>> Tclx		8.6.3
>> BWidget		1.9.16
>> 
>> There are other internal Tcl/Tk packages as well.
>> 
>> I’m currently working on Tclx.
>> I have questions about this package. For example, I've "removed"
>> (depricated) the math functions. These are redundant with what is
>> provided in Tcl 8 already. There's probably more of this I haven't got
>> to yet.
>> 
>> -Brian
>> 
>> 
>>> On Mar 24, 2025, at 06:40, Harald Oehlmann <har...@el...> wrote:
>>> 
>>> Dear TCL/Tk team,
>>> 
>>> please allow me to report from the telco of today. I was 15 minuites late. Others may contribute on the starting phase.
>>> We also ran 10 minutes late, where some people already left.
>>> 
>>> This is a non-binding report and only contains personal opinions.
>>> 
>>> Agenda and comments:
>>> 
>>> 1) TIP 715 - platform support definitions for 9.1.
>>> 
>>> Ashok is modifying the TIP but may need help for Linux and Mac-OS (Steve).
>>> 
>>> Put on the wiki, which platform is tested.
>>> Mark others as untested
>>> 
>>> Where do we accept bugfixes?
>>> -> Supported platforms, for others may be rejected
>>> 
>>> 32 bit time_t structure is not year 2038 save.
>>> Thus:
>>> - don't support Linux without 64 bit time_t (Linux 32 bit before Kernel 5.1, libc version, etc.)
>>> 
>>> There was a question on Wayland support.
>>> Ubuntu 24.04 and recent Debian uses it as default.
>>> Undroidwish has support, no window decorations, as they are client painted, best in full-screen mode. Christian is asking for tests since many years...
>>> 
>>> Tk is supported with XWayland.
>>> 
>>> Keep Tk and TCL in sync of requirements. There are use-cases without Tk, so a Tk blocker may not be relevant for those use-cases.
>>> 
>>> 2) TIP 710 - development workflow and TIP process which seems to have stalled.
>>> 
>>> Many features makes codebase very complex.
>>> In the past, nobody reviewed and features got easily into the core.
>>> Change to 3 yes votes? Debated with no real result.
>>> -> more reviews is the issue
>>> 
>>> -> procedure for merging? -> should be published. -> Steve looks into it but may take time
>>> 
>>> 3) TIP 700: Documentation
>>> 
>>> WIP
>>> 
>>> 4) Stop Tcl/Tk 8.7 ?
>>> 
>>> No request for comatibility issues.
>>> Abadon 8.7 is mostly seen as ok.
>>> 
>>> Brian is converting a big code base to Tcl9 for a company. TclX is challenging as it has lots of structures
>>> -> customers have hit 32bit list length size -> go to 9 -> 9 is a gift and not a problem.
>>> 8.7 is not a solution in this case.
>>> 
>>> 5) decision on the "orphaned extensions"
>>> 
>>> Central place would be great for packagers.
>>> Offline Ashok-Harald for github
>>> 
>>> 6) Possible Incompatible changes for 9.1 in Tk
>>> - "tk grid" https://core.tcl-lang.org/tk/info/7c51624a96ab2092
>>> - "tk_getOpenFile -xpstyle 1" https://core.tcl-lang.org/tk/tktview/441c526c0d
>>> 
>>> Mark is doing great work: ok to get rid of it. TIP required.
>>> -xpstyle -> remove it and raise an error -> put to release notes
>>> 
>>> 7) coroutine traces symetry (Sergey calls for comments): https://core.tcl-lang.org/tcl/info/5bd41844e62aceb2
>>> 
>>> Expert lacking, one may do a test.
>>> 
>>> 8) bytecode compiler optimization by Donal Fellows
>>> 
>>> See the core E-Mail.
>>> 
>>> 9) Next meeting time: Europe will move to daytime saving time -> keep 12:00 UTC ? Date will be 7th of April 2025
>>> 
>>> Stays at 12:00 UTC
>>> 
>>> 10) Conference news
>>> 
>>> Andreas and Brian will come! Hotel is an issue. Harald pointed out, that any hotel or accomodation (RBnB) may be used, not necessarily the conference hotel. Harald is in "Mercure Bologna Centro" for 140Euro/night member rate.
>>> 
>>> Next telcos:
>>> 
>>> 7th of April 2025 12:00 UTC Biweekly telco
>>> 8th of April 2025 1:00 UTC Montly virtual meetup
>>> 
>>> -> will we skip again the biweekly in favour of the monthly telco ?
>>> 
>>> Thanks for all,
>>> Harald
>>> 
>>> 
>>> _______________________________________________
>>> 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
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Report of biweekly Tcl/Tk telco of 2025-03-24

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

Hi Brian,

Regarding external packages, the following official versions seem to work with Tcl 9 and Tcl 8.6:

Tcllib       2.0 https://core.tcl-lang.org/tcllib/doc/trunk/embedded/index.md
Tklib        0.9 https://core.tcl-lang.org/tklib/doc/trunk/embedded/index.md
Tktable      2.12   https://github.com/bohagan1/TkTable
tkcon        2.8    https://github.com/bohagan1/TkCon
tkImg        2.0.1  https://sourceforge.net/projects/tkimg/
BWidget      1.10.1 https://core.tcl-lang.org/bwidget/timeline?t=bwidget-1-10-1

Note, that there is no offical Tcl9-ready tktreectrl. Version 2.4.2 is based on 2.4.1 and ported by me.
tktreectrl   2.4.2 https://www.tcl3d.org/bawt/download/InputLibs/treectrl-2.4.2.7z

Regarding tclxml and TclX I do not know about Tcl9-ready versions.

Paul

Am 24.03.2025 um 17:01 schrieb Brian Griffin:
> For a project I’m working on, these are the packages I’ll need in Tcl 9 compatible versions.
> The list would be longer if all the used Tcllib and Tklib modules were enumerated.
> Most of these already have Tcl9 versions.
>
> Currently used with Tcl 8.6.16:
> Package name	Version
> iTcl		4.2.2
> Thread		2.8.7
> http		2.9.5
> msgcat		1.6.1
> tcltest		2.5.3
> sqlite		3.40.0
> Tcllib		1.20   (20 different modules)
> Tk		8.6.16
> Tklib		0.9    (5 different modules)
> Tktable		2.11
> tkcon		2.7.10
> tclxml
> 	dom	3.2
> 	xml	3.2
> tkImg		1.4.6
> tktreectrl	2.4.1
> Tclx		8.6.3
> BWidget		1.9.16
>
> There are other internal Tcl/Tk packages as well.
>
> I’m currently working on Tclx.
> I have questions about this package. For example, I've "removed"
> (depricated) the math functions. These are redundant with what is
> provided in Tcl 8 already. There's probably more of this I haven't got
> to yet.
>
> -Brian
>
>
>> On Mar 24, 2025, at 06:40, Harald Oehlmann <har...@el...> wrote:
>>
>> Dear TCL/Tk team,
>>
>> please allow me to report from the telco of today. I was 15 minuites late. Others may contribute on the starting phase.
>> We also ran 10 minutes late, where some people already left.
>>
>> This is a non-binding report and only contains personal opinions.
>>
>> Agenda and comments:
>>
>> 1) TIP 715 - platform support definitions for 9.1.
>>
>> Ashok is modifying the TIP but may need help for Linux and Mac-OS (Steve).
>>
>> Put on the wiki, which platform is tested.
>> Mark others as untested
>>
>> Where do we accept bugfixes?
>> -> Supported platforms, for others may be rejected
>>
>> 32 bit time_t structure is not year 2038 save.
>> Thus:
>> - don't support Linux without 64 bit time_t (Linux 32 bit before Kernel 5.1, libc version, etc.)
>>
>> There was a question on Wayland support.
>> Ubuntu 24.04 and recent Debian uses it as default.
>> Undroidwish has support, no window decorations, as they are client painted, best in full-screen mode. Christian is asking for tests since many years...
>>
>> Tk is supported with XWayland.
>>
>> Keep Tk and TCL in sync of requirements. There are use-cases without Tk, so a Tk blocker may not be relevant for those use-cases.
>>
>> 2) TIP 710 - development workflow and TIP process which seems to have stalled.
>>
>> Many features makes codebase very complex.
>> In the past, nobody reviewed and features got easily into the core.
>> Change to 3 yes votes? Debated with no real result.
>> -> more reviews is the issue
>>
>> -> procedure for merging? -> should be published. -> Steve looks into it but may take time
>>
>> 3) TIP 700: Documentation
>>
>> WIP
>>
>> 4) Stop Tcl/Tk 8.7 ?
>>
>> No request for comatibility issues.
>> Abadon 8.7 is mostly seen as ok.
>>
>> Brian is converting a big code base to Tcl9 for a company. TclX is challenging as it has lots of structures
>> -> customers have hit 32bit list length size -> go to 9 -> 9 is a gift and not a problem.
>> 8.7 is not a solution in this case.
>>
>> 5) decision on the "orphaned extensions"
>>
>> Central place would be great for packagers.
>> Offline Ashok-Harald for github
>>
>> 6) Possible Incompatible changes for 9.1 in Tk
>> - "tk grid" https://core.tcl-lang.org/tk/info/7c51624a96ab2092
>> - "tk_getOpenFile -xpstyle 1" https://core.tcl-lang.org/tk/tktview/441c526c0d
>>
>> Mark is doing great work: ok to get rid of it. TIP required.
>> -xpstyle -> remove it and raise an error -> put to release notes
>>
>> 7) coroutine traces symetry (Sergey calls for comments): https://core.tcl-lang.org/tcl/info/5bd41844e62aceb2
>>
>> Expert lacking, one may do a test.
>>
>> 8) bytecode compiler optimization by Donal Fellows
>>
>> See the core E-Mail.
>>
>> 9) Next meeting time: Europe will move to daytime saving time -> keep 12:00 UTC ? Date will be 7th of April 2025
>>
>> Stays at 12:00 UTC
>>
>> 10) Conference news
>>
>> Andreas and Brian will come! Hotel is an issue. Harald pointed out, that any hotel or accomodation (RBnB) may be used, not necessarily the conference hotel. Harald is in "Mercure Bologna Centro" for 140Euro/night member rate.
>>
>> Next telcos:
>>
>> 7th of April 2025 12:00 UTC Biweekly telco
>> 8th of April 2025 1:00 UTC Montly virtual meetup
>>
>> -> will we skip again the biweekly in favour of the monthly telco ?
>>
>> Thanks for all,
>> Harald
>>
>>
>> _______________________________________________
>> 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] Report of biweekly Tcl/Tk telco of 2025-03-24

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

For a project I’m working on, these are the packages I’ll need in Tcl 9 compatible versions.
The list would be longer if all the used Tcllib and Tklib modules were enumerated.
Most of these already have Tcl9 versions.

Currently used with Tcl 8.6.16:
Package name	Version
iTcl		4.2.2
Thread		2.8.7
http		2.9.5
msgcat		1.6.1
tcltest		2.5.3
sqlite		3.40.0
Tcllib		1.20   (20 different modules)
Tk		8.6.16
Tklib		0.9    (5 different modules)
Tktable		2.11
tkcon		2.7.10
tclxml
	dom	3.2
	xml	3.2
tkImg		1.4.6
tktreectrl	2.4.1
Tclx		8.6.3
BWidget		1.9.16

There are other internal Tcl/Tk packages as well.

I’m currently working on Tclx.
I have questions about this package. For example, I've "removed"
(depricated) the math functions. These are redundant with what is
provided in Tcl 8 already. There's probably more of this I haven't got
to yet.

-Brian


> On Mar 24, 2025, at 06:40, Harald Oehlmann <har...@el...> wrote:
> 
> Dear TCL/Tk team,
> 
> please allow me to report from the telco of today. I was 15 minuites late. Others may contribute on the starting phase.
> We also ran 10 minutes late, where some people already left.
> 
> This is a non-binding report and only contains personal opinions.
> 
> Agenda and comments:
> 
> 1) TIP 715 - platform support definitions for 9.1.
> 
> Ashok is modifying the TIP but may need help for Linux and Mac-OS (Steve).
> 
> Put on the wiki, which platform is tested.
> Mark others as untested
> 
> Where do we accept bugfixes?
> -> Supported platforms, for others may be rejected
> 
> 32 bit time_t structure is not year 2038 save.
> Thus:
> - don't support Linux without 64 bit time_t (Linux 32 bit before Kernel 5.1, libc version, etc.)
> 
> There was a question on Wayland support.
> Ubuntu 24.04 and recent Debian uses it as default.
> Undroidwish has support, no window decorations, as they are client painted, best in full-screen mode. Christian is asking for tests since many years...
> 
> Tk is supported with XWayland.
> 
> Keep Tk and TCL in sync of requirements. There are use-cases without Tk, so a Tk blocker may not be relevant for those use-cases.
> 
> 2) TIP 710 - development workflow and TIP process which seems to have stalled.
> 
> Many features makes codebase very complex.
> In the past, nobody reviewed and features got easily into the core.
> Change to 3 yes votes? Debated with no real result.
> -> more reviews is the issue
> 
> -> procedure for merging? -> should be published. -> Steve looks into it but may take time
> 
> 3) TIP 700: Documentation
> 
> WIP
> 
> 4) Stop Tcl/Tk 8.7 ?
> 
> No request for comatibility issues.
> Abadon 8.7 is mostly seen as ok.
> 
> Brian is converting a big code base to Tcl9 for a company. TclX is challenging as it has lots of structures
> -> customers have hit 32bit list length size -> go to 9 -> 9 is a gift and not a problem.
> 8.7 is not a solution in this case.
> 
> 5) decision on the "orphaned extensions"
> 
> Central place would be great for packagers.
> Offline Ashok-Harald for github
> 
> 6) Possible Incompatible changes for 9.1 in Tk
> - "tk grid" https://core.tcl-lang.org/tk/info/7c51624a96ab2092
> - "tk_getOpenFile -xpstyle 1" https://core.tcl-lang.org/tk/tktview/441c526c0d
> 
> Mark is doing great work: ok to get rid of it. TIP required.
> -xpstyle -> remove it and raise an error -> put to release notes
> 
> 7) coroutine traces symetry (Sergey calls for comments): https://core.tcl-lang.org/tcl/info/5bd41844e62aceb2
> 
> Expert lacking, one may do a test.
> 
> 8) bytecode compiler optimization by Donal Fellows
> 
> See the core E-Mail.
> 
> 9) Next meeting time: Europe will move to daytime saving time -> keep 12:00 UTC ? Date will be 7th of April 2025
> 
> Stays at 12:00 UTC
> 
> 10) Conference news
> 
> Andreas and Brian will come! Hotel is an issue. Harald pointed out, that any hotel or accomodation (RBnB) may be used, not necessarily the conference hotel. Harald is in "Mercure Bologna Centro" for 140Euro/night member rate.
> 
> Next telcos:
> 
> 7th of April 2025 12:00 UTC Biweekly telco
> 8th of April 2025 1:00 UTC Montly virtual meetup
> 
> -> will we skip again the biweekly in favour of the monthly telco ?
> 
> Thanks for all,
> Harald
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] How do we deprecate a command?

[Donald G P. <don...@ni...>]

For an example (that you can follow or not), look at how the [case] command was
removed from the built-in command set of Tcl.

On 3/24/25 12:17, Marc Culler wrote:
> Suppose that a command, let's say the command "wm grid", is going to be removed from Tk.  Even though we suspect that no one is using it in any applications, we would like to do the removal in two stages.  First modify it so it is a no-op, then remove it.
>
> The natural thing to do when the command  becomes a no-op would be to generate a deprecation message which says that the command is deprecated and no longer has any effect.  What is the standard way to do that? Just print the message to stderr?  Or is there something better, perhaps built-in to Tcl, which is usually used in this situation?
>
> - Marc

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] How do we deprecate a command?

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

On Mon, Mar 24, 2025 at 5:18 PM Marc Culler <cul...@gm...> wrote:

> First modify it so it is a no-op, ...

That can _silently_ break existing programs.

-j

[TCLCORE] How do we deprecate a command?

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

Suppose that a command, let's say the command "wm grid", is going to be
removed from Tk.  Even though we suspect that no one is using it in any
applications, we would like to do the removal in two stages.  First modify
it so it is a no-op, then remove it.

The natural thing to do when the command  becomes a no-op would be to
generate a deprecation message which says that the command is deprecated
and no longer has any effect.  What is the standard way to do that? Just
print the message to stderr?  Or is there something better, perhaps
built-in to Tcl, which is usually used in this situation?

- Marc

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

[Donald G P. <don...@ni...>]

On 3/20/25 11:50, Jan Nijtmans wrote:
> This is a CFV warning for TIP #626. for Tcl 9.1+:
>      Command arguments > 2^31 elements
>      <https://core.tcl-lang.org/tips/doc/trunk/tip/626.md>
>
> If you think this is a bad idea, speak up now. If not,
> I'll start the vote in a few days.
I regret that I did not notice this unfinished business before the release of Tcl 9.

Tcl has long defined the Tcl_ObjCmdProc type for extensions to define their own command procedures.  TIP 626 adds a new TclObjCmdProc2 type which is nearly the same, but accepts a Tcl_Size number of command words, instead of an int number.  The same thing, but bigger.  But different enough to need some disruption to achieve the transition.

Several Tcl users see the disruption, and don't see the value provided by it, thinking they have no interest in their extension commands being able to process such large numbers of arguments.

Consider this alternative conception.  We create a new command procedure type, but not just "the same but bigger".  Instead, the new type is "more generalized and powerful".

The connection between commands and lists has always been important in Tcl.  Starting with the introduction of the {*} syntax, Tcl lists became fundamental to the very definition of the language.  Yet, Tcl has no public feature in its C interface to represent lists. Whenever Tcl lists must pass as arguments in C, we either choose to pass a (Tcl_Obj *) and then check that the value is a usable list, or we pass an array of Tcl_Obj*.

Imagine we add a public Tcl_List type, so that a single argument can be passed in C that represents a Tcl list.  Imagine its functions and operations are kept abstract enough that it can accommodate lists larger than INT_MAX elements.  Imagine further that the abstract interface doesn't force data structures of a single array, so that the innovations already present in [lseq] and its internal supports can also be passed freely through Tcl interfaces.  Many alternative supporting internals can be conceived.

With that innovation, it is far more natural to offer to extensions a new command procedure format that lets their commands directly pull the parsed words of an executing command from an abstract list argument, so that extension operations can gain any efficiencies better internal list representations offer.

Consider

typedef int (Tcl_CmdProcList) (void *clientData, Tcl_Interp *interp, Tcl_List list);

Now this is a new public interface offering all extensions improved access to efficiencies of operation current and future, and the expansion to Tcl_Size number of words in an executing command also comes in almost as an afterthought.

This new mechanism for extension-defined commands rests more comfortably alongside Tcl_ObjCmdProc, so I see less urgency with deprecating that older mechanism out of existence.  People happy with its limitations could just continue being happy with its limitations, with no need to change anything.  An extension can do nothing, or embrace the new capabilities fully, or write very trivial wrappers around their existing Tcl_ObjCmdProcs.

Taking this approach, we can immediately fully test these interfaces, even on systems without large memory, by testing with the existing [lseq] machinery which represents very large lists without using very large amounts of memory.

This approach should also mesh well (and hopefully accelerate) the innovations brought in with [lseq] and develop tools we will need anyway to improve efficiencies of non-shimmering access to list operations on extension-provided Tcl_ObjTypes.  Since this new mechanism would be the only way to create an extension command accepting more than INT_MAX arguments, that would accelerate making use of the new Tcl_List interfaces generally.

All I currently offer are ideas, not implementations.  But it's another way to go.  At least in concept I like it better, but I recognize that at some point working code beats dreamy concept.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

[TCLCORE] Report of biweekly Tcl/Tk telco of 2025-03-24

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

Dear TCL/Tk team,

please allow me to report from the telco of today. I was 15 minuites 
late. Others may contribute on the starting phase.
We also ran 10 minutes late, where some people already left.

This is a non-binding report and only contains personal opinions.

Agenda and comments:

1) TIP 715 - platform support definitions for 9.1.

Ashok is modifying the TIP but may need help for Linux and Mac-OS (Steve).

Put on the wiki, which platform is tested.
Mark others as untested

Where do we accept bugfixes?
-> Supported platforms, for others may be rejected

32 bit time_t structure is not year 2038 save.
Thus:
- don't support Linux without 64 bit time_t (Linux 32 bit before Kernel 
5.1, libc version, etc.)

There was a question on Wayland support.
Ubuntu 24.04 and recent Debian uses it as default.
Undroidwish has support, no window decorations, as they are client 
painted, best in full-screen mode. Christian is asking for tests since 
many years...

Tk is supported with XWayland.

Keep Tk and TCL in sync of requirements. There are use-cases without Tk, 
so a Tk blocker may not be relevant for those use-cases.

2) TIP 710 - development workflow and TIP process which seems to have 
stalled.

Many features makes codebase very complex.
In the past, nobody reviewed and features got easily into the core.
Change to 3 yes votes? Debated with no real result.
-> more reviews is the issue

-> procedure for merging? -> should be published. -> Steve looks into it 
but may take time

3) TIP 700: Documentation

WIP

4) Stop Tcl/Tk 8.7 ?

No request for comatibility issues.
Abadon 8.7 is mostly seen as ok.

Brian is converting a big code base to Tcl9 for a company. TclX is 
challenging as it has lots of structures
-> customers have hit 32bit list length size -> go to 9 -> 9 is a gift 
and not a problem.
8.7 is not a solution in this case.

5) decision on the "orphaned extensions"

Central place would be great for packagers.
Offline Ashok-Harald for github

6) Possible Incompatible changes for 9.1 in Tk
- "tk grid" https://core.tcl-lang.org/tk/info/7c51624a96ab2092
- "tk_getOpenFile -xpstyle 1" 
https://core.tcl-lang.org/tk/tktview/441c526c0d

Mark is doing great work: ok to get rid of it. TIP required.
-xpstyle -> remove it and raise an error -> put to release notes

7) coroutine traces symetry (Sergey calls for comments): 
https://core.tcl-lang.org/tcl/info/5bd41844e62aceb2

Expert lacking, one may do a test.

8) bytecode compiler optimization by Donal Fellows

See the core E-Mail.

9) Next meeting time: Europe will move to daytime saving time -> keep 
12:00 UTC ? Date will be 7th of April 2025

Stays at 12:00 UTC

10) Conference news

Andreas and Brian will come! Hotel is an issue. Harald pointed out, that 
any hotel or accomodation (RBnB) may be used, not necessarily the 
conference hotel. Harald is in "Mercure Bologna Centro" for 
140Euro/night member rate.

Next telcos:

7th of April 2025 12:00 UTC Biweekly telco
8th of April 2025 1:00 UTC Montly virtual meetup

-> will we skip again the biweekly in favour of the monthly telco ?

Thanks for all,
Harald

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

[Rolf A. <tcl...@po...>]

Rolf Ade writes:
> Jan Nijtmans writes:
>> Op zo 23 mrt 2025 om 18:28 schreef <apnmbx-public-/E15...@pu...>:
>> [...]
>>> I did not see any test cases.
>
> Ashok is for sure right with that this needs test cases.
>
>>>
>>> % set s [string cat {*}[lrepeat 0x100000000 x]]; string length $s
>>>
>>> can't read "s": no such variable
>
> I confirm what Ashok reports here; I get the same. If I haven't missed
> something watching top during the test run you'll need around 60 GByte
> free memory to reproduce by yourself.

Digging a bit this gets stranger. If run interactivly in a tip-626
branch tclsh I see what Ashok reports.

If run as script it works as expected. Perhaps this observation triggers
some idea about the root cause.

rolf

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

[Rolf A. <tcl...@po...>]

Count me into the camp with mixed feelings.

Jan Nijtmans writes:
> Op zo 23 mrt 2025 om 18:28 schreef <apnmbx-public-/E15...@pu...>:
> [...]
>> I did not see any test cases.

Ashok is for sure right with that this needs test cases.

> Since ALL of the commands are modified to use Tcl_Size objc, all
> current testcases
> test the new behavior. All current extensions (like thread or Itcl)
> still use the "int objc"
> functions, that's how you can verify that the original functions still
> work OK too.
>
>> Does the TIP only address the generic framework for passing
>> arguments or are all core commands expected to also work? I ask
>> because just my second attempt to exercise the functionality failed
>> (I am not sure how to practically generate a large number of
>> arguments other than use of {*}):
>>
>> % set s [string cat {*}[lrepeat 0x100000000 x]]; string length $s
>>
>> can't read "s": no such variable

I confirm what Ashok reports here; I get the same. If I haven't missed
something watching top during the test run you'll need around 60 GByte
free memory to reproduce by yourself.

> You already wrote a testcase for that, see:
>      <https://core.tcl-lang.org/tcl/info/eb734aab392c0b31>
> This testcase should be modified now to no longer give an error.
>
> All core commands and extensions are expected to work as they do now.

Given the example above, this doesn't seem to be fully true even for the
core commands.

First step would be to ensure that the core commands in fact work as
expected. If that is done then the next step should be to have a closer
look at what this does to the extensions ecosphare.

> The only exception I am aware of is "nsf", since it pokes into the
> internal structures.
>
> Hope this helps,
>     Jan Nijtmans

rolf

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

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

Op ma 24 mrt 2025 om 10:52 schreef Gustaf Neumann:
> In my opinion, a better approach might have been to move directly to a 64-bit objc interface for Tcl9 to eliminate the need for a wrapper altogether.
> Perhaps the decision was influenced by the incremental nature of the tips, or there might be other reasons I’m not aware of. But maybe, it is not too late.

The main reason was that doing this ALL extensions have to be modified
using "Tcl_Size objc". I
tried that with extensions like Itcl and Itk, and encountered crashes,
which were only fixed
a few weeks ago. I didn't want to delay Tcl 9.0 for this.

> * The wrapper introduces a slight performance overhead for each invocation, even if it is likely negligible in most cases.
That's why the TIP proposes to deprecate all "int argc"and "int objc"
functions, in favor of
the Tcl_Size objc ones. The wrapper then can be phased out, and
removed in Tcl 10 ;-)

The maintenance win, no conversions from Tcl_Size <-> int any more,
is, IMHO worth
much more than the cost of this tiny wrapper. I already converted Tk, Itcl andTk
(in a separate branch) to use the new routines, so the cost of the wrapper then
becomes 0 (apart from a little code bloat). All extensions can do the same.

So, I agree that it would have been better to move directly to a
64-bit objc-interface,
but that would have caused a delay in Tcl 9.0.

Hope this helps,
        Jan Nijtmans

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

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

> If you think this is a bad idea, speak up now. If not,
> I'll start the vote in a few days.

Since you asked for comments… 

- “bad idea” is strong word, but I do have some reservations

- I appreciate the symmetry in the design, and I believe that allowing a large number of elements is a step in the right direction.

- however, i am not full happy with the implementation:

   * having to use the wrapper in the standard case does not look right to me

   * The wrapper introduces a slight performance overhead for each invocation, even if it is likely negligible in most cases.

   * The wrapper can break extensions that require a tight coupling with the Tcl core. Currently, NSF is not wrapper-aware and still uses the legacy interfaces for NSF methods, even when compiled with Tcl9. While this issue can be fixed, it involves some work and adds complexity to support both types of interfaces.

In my opinion, a better approach might have been to move directly to a 64-bit objc interface for Tcl9 to eliminate the need for a wrapper altogether. 
Perhaps the decision was influenced by the incremental nature of the tips, or there might be other reasons I’m not aware of. But maybe, it is not too late.

All the best
-g

Re: [TCLCORE] TCL/Tk biweekly telco on 24th of Mars, 2025 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

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

Apologies, but I cannot make this one due to a family event.

Re the bytecode changes, they are experimental (for now at least) but I'm looking at how to get rid of the 1-byte indices and offsets (in part because that will support the large programs agenda), and whether that makes code issuing simpler. It certainly seems to help with jump handling. Of course, I'll need to test things prior to any merge.

Not that much to report about it right now though; I keep getting interrupted when settling down to to write code...

Donal.


-------- Original message --------
From: Harald Oehlmann <har...@el...>
Date: 24/03/2025 07:45 (GMT+00:00)
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] TCL/Tk biweekly telco on 24th of Mars, 2025 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

Resend: Ashok has contributed discussion points, now on the agenda

Dear Tcl/Tk team,
please allow me to invite anybody to the telco:
Where: https://meet.jit.si/TclMonthlyMeetup
When: 2025-03-24 12:00 UTC

Possible discussion points:

1) TIP 715 - platform support definitions.

2) TIP 710 - development workflow and TIP process which seems to have
stalled.

3) TIP 700: Documentation

4) Stop Tcl/Tk 8.7 ?

5) decision on the "orphaned extensions"

6) Possible Incompatible changes for 9.1 in Tk
- "tk grid" https://core.tcl-lang.org/tk/info/7c51624a96ab2092
- "tk_getOpenFile -xpstyle 1"
https://core.tcl-lang.org/tk/tktview/441c526c0d

7) coroutine traces symetry (Sergey calls for comments):
https://core.tcl-lang.org/tcl/info/5bd41844e62aceb2

8) bytecode compiler optimization by Donal Fellows

9) Next meeting time: Europe will move to daytime saving time -> keep
12:00 UTC ? Date will be 7th of April 2025

10) Conference news

11) Any other business

Thank you all,
Harald

[TCLCORE] TCL/Tk biweekly telco on 24th of Mars, 2025 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

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

Resend: Ashok has contributed discussion points, now on the agenda

Dear Tcl/Tk team,
please allow me to invite anybody to the telco:
Where: https://meet.jit.si/TclMonthlyMeetup
When: 2025-03-24 12:00 UTC

Possible discussion points:

1) TIP 715 - platform support definitions.

2) TIP 710 - development workflow and TIP process which seems to have 
stalled.

3) TIP 700: Documentation

4) Stop Tcl/Tk 8.7 ?

5) decision on the "orphaned extensions"

6) Possible Incompatible changes for 9.1 in Tk
- "tk grid" https://core.tcl-lang.org/tk/info/7c51624a96ab2092
- "tk_getOpenFile -xpstyle 1" 
https://core.tcl-lang.org/tk/tktview/441c526c0d

7) coroutine traces symetry (Sergey calls for comments): 
https://core.tcl-lang.org/tcl/info/5bd41844e62aceb2

8) bytecode compiler optimization by Donal Fellows

9) Next meeting time: Europe will move to daytime saving time -> keep 
12:00 UTC ? Date will be 7th of April 2025

10) Conference news

11) Any other business

Thank you all,
Harald

Re: [TCLCORE] TCL/Tk biweekly telco on 24th of Mars, 2025 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

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

Harald, sorry, one more topic - decision on the "orphaned extensions"
repository

-----Original Message-----
From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Monday, March 24, 2025 7:08 AM
To: 'Tcl Core List' <tcl...@li...>
Subject: Re: [TCLCORE] TCL/Tk biweekly telco on 24th of Mars, 2025 12:00 UTC
on https://meet.jit.si/TclMonthlyMeetup

Harald,

I'd like to add the following topics -

TIP 715 - platform support definitions. 

TIP 710 - development workflow and TIP process which seems to have stalled.

/Ashok 

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Friday, March 21, 2025 2:56 PM
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] TCL/Tk biweekly telco on 24th of Mars, 2025 12:00 UTC on
https://meet.jit.si/TclMonthlyMeetup

Dear Tcl/Tk team,
please allow me to invite anybody to the telco:
Where: https://meet.jit.si/TclMonthlyMeetup
When: 2025-03-24 12:00 UTC

Possible discussion points:

1) Possible Incompatible changes for 9.1 in Tk
- "tk grid" https://core.tcl-lang.org/tk/info/7c51624a96ab2092
- "tk_getOpenFile -xpstyle 1" 
https://core.tcl-lang.org/tk/tktview/441c526c0d

2) Stop Tcl/Tk 8.7 ?

3) coroutine traces symetry (Sergey calls for comments): 
https://core.tcl-lang.org/tcl/info/5bd41844e62aceb2

4) bytecode compiler optimization by Donal Fellows

5) TIP 700: Documentation

6) Next meeting time: Europe will move to daytime saving time -> keep 
12:00 UTC ? Date will be 7th of April 2025

7) Conference news

8) Any other business

Thank you all,
Harald



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

Re: [TCLCORE] TCL/Tk biweekly telco on 24th of Mars, 2025 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

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

Harald,

I'd like to add the following topics -

TIP 715 - platform support definitions. 

TIP 710 - development workflow and TIP process which seems to have stalled.

/Ashok 

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Friday, March 21, 2025 2:56 PM
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] TCL/Tk biweekly telco on 24th of Mars, 2025 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

Dear Tcl/Tk team,
please allow me to invite anybody to the telco:
Where: https://meet.jit.si/TclMonthlyMeetup
When: 2025-03-24 12:00 UTC

Possible discussion points:

1) Possible Incompatible changes for 9.1 in Tk
- "tk grid" https://core.tcl-lang.org/tk/info/7c51624a96ab2092
- "tk_getOpenFile -xpstyle 1" 
https://core.tcl-lang.org/tk/tktview/441c526c0d

2) Stop Tcl/Tk 8.7 ?

3) coroutine traces symetry (Sergey calls for comments): 
https://core.tcl-lang.org/tcl/info/5bd41844e62aceb2

4) bytecode compiler optimization by Donal Fellows

5) TIP 700: Documentation

6) Next meeting time: Europe will move to daytime saving time -> keep 
12:00 UTC ? Date will be 7th of April 2025

7) Conference news

8) Any other business

Thank you all,
Harald

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

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

Jan,

 

Sorry, I understood neither of the points you made.

 

> Since ALL of the commands are modified to use Tcl_Size objc, all current
testcases test the new behavior.

 

This means nothing. The new behavior defined by the TIP requires commands to
accept > 2**31 arguments. Nothing in the test suite verifies this. I'll
point out again that the same exact logic could be applied to the 32-bit ->
64bit transition for 9.0. "All structures now use Tcl_Size so all current
testcases test..". And this thinking was probably why tests were not added
there either. And yet in reality most commands did not work with lengths >
2**31 even in beta 1 until the implementation was specifically tested in
bigdata.test.

 

If you were in fact right about the current test suite being adequate, why
would the simple test I did fail?

 

> You already wrote a testcase for that, see:.

 

The test you mention verifies that 9.0 raises an error instead of crashing
when argument lengths are exceeded. It does not verify correct operation of
commands. I am not sure I see the relevance to the "no such variable"
failure example I gave.

 

 

 

-----Original Message-----
From: Jan Nijtmans <jan...@gm...> 
Sent: Monday, March 24, 2025 12:24 AM
To: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31
elements

 

Op zo 23 mrt 2025 om 18:28 schreef < <mailto:apn...@ya...>
apn...@ya...>:

> Jan,

> Having had only a cursory look so far, I only have a few preliminary
comments and questions.

> 

> The implementation touches a lot of files and although most are nominal
size changes, it will take some time to review. Please wait at least a
couple of weeks, if not more, before calling for a vote.

 

That's OK. You will see the pattern soon.

 

> I did not see any test cases.

 

Since ALL of the commands are modified to use Tcl_Size objc, all

current testcases

test the new behavior. All current extensions (like thread or Itcl)

still use the "int objc"

functions, that's how you can verify that the original functions still

work OK too.

 

> Does the TIP only address the generic framework for passing arguments or
are all core commands expected to also work? I ask because just my second
attempt to exercise the functionality failed (I am not sure how to
practically generate a large number of arguments other than use of {*}):

> 

> % set s [string cat {*}[lrepeat 0x100000000 x]]; string length $s

> 

> can't read "s": no such variable

 

You already wrote a testcase for that, see:

     < <https://core.tcl-lang.org/tcl/info/eb734aab392c0b31>
https://core.tcl-lang.org/tcl/info/eb734aab392c0b31>

This testcase should be modified now to no longer give an error.

 

All core commands and extensions are expected to work as they do now.

The only exception I am aware of is "nsf", since it pokes into the

internal structures.

 

Hope this helps,

    Jan Nijtmans

 

 

_______________________________________________

Tcl-Core mailing list

 <mailto:Tcl...@li...> Tcl...@li...

 <https://lists.sourceforge.net/lists/listinfo/tcl-core>
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

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

Op zo 23 mrt 2025 om 18:28 schreef <apn...@ya...>:
> Jan,
> Having had only a cursory look so far, I only have a few preliminary comments and questions.
>
> The implementation touches a lot of files and although most are nominal size changes, it will take some time to review. Please wait at least a couple of weeks, if not more, before calling for a vote.

That's OK. You will see the pattern soon.

> I did not see any test cases.

Since ALL of the commands are modified to use Tcl_Size objc, all
current testcases
test the new behavior. All current extensions (like thread or Itcl)
still use the "int objc"
functions, that's how you can verify that the original functions still
work OK too.

> Does the TIP only address the generic framework for passing arguments or are all core commands expected to also work? I ask because just my second attempt to exercise the functionality failed (I am not sure how to practically generate a large number of arguments other than use of {*}):
>
> % set s [string cat {*}[lrepeat 0x100000000 x]]; string length $s
>
> can't read "s": no such variable

You already wrote a testcase for that, see:
     <https://core.tcl-lang.org/tcl/info/eb734aab392c0b31>
This testcase should be modified now to no longer give an error.

All core commands and extensions are expected to work as they do now.
The only exception I am aware of is "nsf", since it pokes into the
internal structures.

Hope this helps,
    Jan Nijtmans