tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] [EXTERNAL] Large files in repository

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

On 7/22/25 13:39, apnmbx-public--- via Tcl-Core wrote:
>
> Are there any issues with committing large (about 2MB each) files to the core repository? I want to add the Unicode character database files as test vectors. Have already added a couple before I looked at the size but wanted to ask whether this is not advisable before adding the remaining (3-4).
>
> (2MB is not very large by today’s standards but stil…)
>

The expected issue is with repository size in sandboxes and the time/bandwidth
needed to accomplish the initial clone operation?  Is that right?

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

[TCLCORE] Large files in repository

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

Are there any issues with committing large (about 2MB each) files to the
core repository? I want to add the Unicode character database files as test
vectors. Have already added a couple before I looked at the size but wanted
to ask whether this is not advisable before adding the remaining (3-4).

 

(2MB is not very large by today's standards but stil.)

 

/Ashok

Re: [TCLCORE] [EXTERNAL] Re: Tcl 9.1a0 Release Candidate

[Pietro C. <ga...@ga...>]

On Jul 21 2025, 15:30 +0000, Donald G Porter via Tcl-Core <tcl...@li...> wrote:
>
>More of a meta-comment...
>
>On 7/19/25 15:26, Pietro Cerutti via Tcl-Core wrote:
>>To me, it looks like the 9.0 -> 9.1 upgrade path is going to be smooth.
>>We all know that for 8.3, 8.4, 8.5, and 8.6, that wasn't the case.
>
>I think it's premature to make that judgment based only on the contents 
>of the first alpha release.
>
>If things still look that way in the first beta release (planned May 
>2026), then you'll have a better foundation for making this change.

Thanks Don, that's a good advice! I will hold off on upgrading the 
FreeBSD port / making a new one until further on in the release cycle.

Pietro

-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org

Re: [TCLCORE] [EXTERNAL] Re: Versioning and naming of libraries

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

On 7/21/25 08:46, Marc Culler wrote:
> My understanding was that the 9.0.X series was intended to be short-lived and transitional.  Once it ends there will be only one current Tcl/Tk 9 version at a time, namely 9.1.X.
>
> Maybe this discussion means that the time for ending 9.0.X is nearing.  But presumably there needs to be a 9.1 release before that can happen.

The TIP 713 plan calls for Tcl 9.0.7 to be the last Tcl 9.0.* release in December 2026.
The presumption is Tcl 9.0 users will be able to easily adopt Tcl 9.1, and we do not
need both branches of development to generate releases after that.

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

Re: [TCLCORE] [EXTERNAL] Re: Tcl 9.1a0 Release Candidate

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

More of a meta-comment...

On 7/19/25 15:26, Pietro Cerutti via Tcl-Core wrote:
> To me, it looks like the 9.0 -> 9.1 upgrade path is going to be smooth.
> We all know that for 8.3, 8.4, 8.5, and 8.6, that wasn't the case.

I think it's premature to make that judgment based only on the contents of the first alpha release.

If things still look that way in the first beta release (planned May 2026), then you'll have a better foundation for making this change.

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

Re: [TCLCORE] [EXTERNAL] Tcl 9.1a0 Release Candidate

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

On 7/17/25 14:05, Donald G Porter via Tcl-Core wrote:
> It is intended that the RC1 release will become the Tcl 9.1a0 release on July 21,
> unless some release-blocking flaw is discovered and reported.

The package sqlite 3.50.3 has been released.  We will need an RC2 to bring it into
the Tcl 9.1a0 release.  This will also open up the chance to bring other TEA improvements
to other bundled packages and to review some recent improvements on the trunk.

I should have RC2 for Tcl/Tk 9.1a0 later this week.  Revised release date target is
July 28.

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

Re: [TCLCORE] [Ext] Re: Tcl 9.0a1 Release Candidate

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

 

It sounds really similar, indeed. 

I found more potentially use-after-free (also another case in
TclpMatchInDirectory), so once if everything got fixed one could check
this issue again. 

But the question (3) from my initial mail remains, why it is so flashy
in 9.x (but not in 8.x), if that use-after-free is so old and exists
there since dozen years? 

Regards,
Serg. 

21.07.2025 08:36, Zaumseil René wrote: 

> Hello 
> 
> Could ticket "glob error" b0682c3c2497e8f27f18e91686031dda055ed19c 
> 
> also be a side effect? 
> 
> Regards 
> 
> Rene 
> 
> VON: Dipl. Ing. Sergey G. Brester via Tcl-Core <tcl...@li...> 
> GESENDET: Freitag, 18. Juli 2025 18:11
> AN: Porter, Don (Fed) <don...@ni...>
> CC: Tcl Core List <tcl...@li...>
> BETREFF: [Ext] Re: [TCLCORE] Tcl 9.0a1 Release Candidate 
> 
> Hi,
> 
> please don't release it (as well as other versions if some releases planned).
> 
> See my last comment [2] to ticket 61c01e0edb08a9ed. 
> 
> I think this use-after-free heisenbug could be considered as a blocker and the releases need to be paused at least till I fixed it (and review doesn't show similar bugs).
> 
> The issue is more worse as described in ticket (I don't want to publish there potential security issue), since it may be also a vulnerability (path traversal, data corruption etc),
> if object may get "valid" but different path, and this weakness can be viewed as exploitable in a practical way (e. g. there are several scenarios to write usable exploit for this, 
> depending on its usage in code). 
> 
> By the way (3 orthogonal subjects): 
> 
> * shall we create CVE or GH security advisory for this?
> * why "Private vulnerability reporting" is disabled in https://github.com/tcltk/tcl/security [3] ? (I can enable it there, but would like to ask TCT firstly)
> 
> * does anyone know why 9.x (and probably 8.7) may increase FS epoch often than 8.6/8.5...
> or especially why FS functions like Tcl_FSGetNativePath invalidate path-object more often now?
> Is it some effect of zipfs?.. However I speak about physical paths either. 
> 
> Regards,
> Serg. 
> 
> 06.11.2019 17:18, Porter, Don (Fed) via Tcl-Core wrote: 
> 
> Now available from 
> 
> https://sourceforge.net/projects/tcl/files/Tcl/9.0a1/ [4] 
> 
> is the first release candidate of the first alpha release of Tcl 9.0. 
> 
> Also included is a release candidate of package Thread 3.0a1 . Thread 2.8.5 rejects builds against Tcl 9, so this package is bundled so that Tcl 9 testers still have a working Thread package. 
> 
> There is no Tk 9. Tk 8.7a3 should build against Tcl 9.0a1. The binary built should then [load] or [package require] into the Tcl 9.0a1 interpreter. Likewise other package source code distributions included with Tcl 8.6.10 should compile against Tcl 9.0a1, producing installations that can [package require] into Tcl 9.0a1. If this fails, we will have found a migration puzzle to solve as Tcl 9.0 continues its alpha development. 
> 
> The expected release date is Nov. 21. Help us make that release high quality by testing this candidate and reporting any release-blocking failures in it. 
> 
> _______________________________________________
> 
> Tcl-Core mailing list
> 
> Tcl...@li...
> 
> https://lists.sourceforge.net/lists/listinfo/tcl-core [1]
 

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/tcl-core
[2] https://core.tcl-lang.org/tcl/info/e22d88bc21383820
[3] https://github.com/tcltk/tcl/security
[4] https://sourceforge.net/projects/tcl/files/Tcl/9.0a1/

Re: [TCLCORE] Versioning and naming of libraries

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

My understanding was that the 9.0.X series was intended to be short-lived
and transitional.  Once it ends there will be only one current Tcl/Tk 9
version at a time, namely 9.1.X.

Maybe this discussion means that the time for ending 9.0.X is nearing.  But
presumably there needs to be a 9.1 release before that can happen.

- Marc

On Mon, Jul 21, 2025 at 1:39 AM apnmbx-public--- via Tcl-Core <
tcl...@li...> wrote:

> (Changed subject line so as to not hijack the 9.1a0 release thread)
>
> From the point of view of an application writer, I would prefer to run
> against a specific MAJOR.MINOR version of a shared library - the one I have
> tested with. No matter the claims by library writers, there are always
> incompatibilities in corner cases introduced even in minor versions (as
> opposed to patchlevels). I've seen this with both libffi and libicu.
> Considering that, I think 9.0, 9.1... should be distinguished, and of
> course
> that means the naming of shared libraries should continue to include the
> minor version number.
>
> /Ashok
>
> -----Original Message-----
> From: Pietro Cerutti via Tcl-Core <tcl...@li...>
> Sent: Sunday, July 20, 2025 12:56 AM
> To: Tcl List Core <tcl...@li...>
> Cc: Pietro Cerutti <ga...@ga...>
> Subject: Re: [TCLCORE] Tcl 9.1a0 Release Candidate
>
> All,
>
> although TIP439 (Semantic Versioning) was never finalized, it seems
> clear to me that we're handling the middle number of our versioning
> scheme differently in 9.x than how we did it in 8.x.
>
> To me, it looks like the 9.0 -> 9.1 upgrade path is going to be smooth.
> We all know that for 8.3, 8.4, 8.5, and 8.6, that wasn't the case.
>
> As a downstream packager (I maintain a bunch of Tcl/Tk-related ports on
> FreeBSD), I used to maintain tcl84, tcl85, tcl86, and for a period tcl87
> as separate ports (same for their tk counterparts, except perhaps for
> tk87, which was never there, iirc).  I was eventually able to deprecate
> and remove 84, 85, and 87, and to add 90.
>
> So now I'm left with 86 and 90.
>
> I don't think it makes sense to keep both 90 and 91 as separate ports,
> and I think at this point I'm leaning towards having a single tcl9 port
> for the 9.x series.
>
> First question: does it makes sense? Do you see any drawbacks?
>
> Second question / remark: does it still make sense to name our shared
> library and executable as libtcl9.1.so and tclsh9.1? I don't see those
> coexist with any other 9.X for any meaningful reason, so why don't we
> stop doing that and name things simply by major version?
>
> I know I can do that on my side, but I want to gather feedback on
> whether this is something we might want to consider.
>
> Shall there be one true novem?
>
> Thanks,
>
> Pietro
>
> On Jul 16 2025, 16:49 +0000, Donald G Porter via Tcl-Core
> <tcl...@li...> wrote:
> >
> >Now available from
> >
> >https://sourceforge.net/projects/tcl/files/Tcl/9.1a0/
> >
> >is the RC0 release candidate of the first alpha release of Tcl 9.1.
> >
> >This is the first of a sequence of candidate releases leading to the
> release of
> >Tcl 9.1a0. Testing of builds and operations on multiple platforms is
> invited.  Open
> >tickets on any problems discovered, or raise the issue in a reply to this
> message.
> >
> >This candidate is not expected to become the release.  Some additional
> work
> on release notes and other supports is expected to appear in a subsequent
> candidate first.
> >
> >Thank you for your contributions and assistance.
> >
> >
> >
> >_______________________________________________
> >Tcl-Core mailing list
> >Tcl...@li...
> >https://lists.sourceforge.net/lists/listinfo/tcl-core
>
> --
> Pietro Cerutti
> I have pledged to give 10% of income to effective charities
> and invite you to join me - https://givingwhatwecan.org
>
>
> _______________________________________________
> 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] Versioning and naming of libraries

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

I am not sure about X.Y.Z but at l would be in favor of at least X.Y.

 

As a concrete case of where I run up against this, I was hoping my Tcl
libgit2 extension could assume some minimal version of libgit2 (say 1.8) and
build against that. Now the system installs libgit2 1.9 replacing 1.8 and
since 1.9 has ABI incompatible changes
<https://github.com/libgit2/libgit2/releases/tag/v1.9.0>  w.r.t. 1.8, the
extension starts crashing. Worse, it crashes only sporadically as 1.9 is
"mostly" compatible. It would be nice if the older versions were left in
place and applications (or extensions) could link against them. This
headache of having to keep the extension up with multiple libgit2 *minor*
releases was enough for me to abandon working on it.

 

I have also run into this installing other software as an end user where X
required one version of the library and Y required another (libssh2 I think
it was, or may be openssl). TBH, I am a bit surprised at this state of
affairs on Linux to the point that I wonder if I am managing my installation
wrong.

 

-----Original Message-----
From: Pietro Cerutti <ga...@ga...> 
Perhaps I should maintain a single tcl9, but install all flavours of 

versioned libs:

 

* libtcl9.so

* libtcl9.so.X

* libtcl9.so.X.Y

* libtcl9.so.X.Y.Z

 

 

Re: [TCLCORE] Versioning and naming of libraries

[Pietro C. <ga...@ga...>]

On Jul 21 2025, 06:38 +0000, apn...@ya... wrote:
>(Changed subject line so as to not hijack the 9.1a0 release thread)
>
>From the point of view of an application writer, I would prefer to run
>against a specific MAJOR.MINOR version of a shared library - the one I have
>tested with. No matter the claims by library writers, there are always
>incompatibilities in corner cases introduced even in minor versions (as
>opposed to patchlevels). I've seen this with both libffi and libicu.
>Considering that, I think 9.0, 9.1... should be distinguished, and of course
>that means the naming of shared libraries should continue to include the
>minor version number.

Interesting take... I have checked what libffi and libicu install on 
FreeBSD and Ubuntu (just to have two data points), and:

* libffi: libffi.so.X, libffi.so.X.Y.Z
* libicu: libicu.so.X, libicu.so.X.Y

For none of them, though, neither Ubuntu not FreeBSD maintain more than 
one minor version.

Perhaps I should maintain a single tcl9, but install all flavours of 
versioned libs:

* libtcl9.so
* libtcl9.so.X
* libtcl9.so.X.Y
* libtcl9.so.X.Y.Z

>-----Original Message-----
>From: Pietro Cerutti via Tcl-Core <tcl...@li...>
>Sent: Sunday, July 20, 2025 12:56 AM
>To: Tcl List Core <tcl...@li...>
>Cc: Pietro Cerutti <ga...@ga...>
>Subject: Re: [TCLCORE] Tcl 9.1a0 Release Candidate
>
>All,
>
>although TIP439 (Semantic Versioning) was never finalized, it seems
>clear to me that we're handling the middle number of our versioning
>scheme differently in 9.x than how we did it in 8.x.
>
>To me, it looks like the 9.0 -> 9.1 upgrade path is going to be smooth.
>We all know that for 8.3, 8.4, 8.5, and 8.6, that wasn't the case.
>
>As a downstream packager (I maintain a bunch of Tcl/Tk-related ports on
>FreeBSD), I used to maintain tcl84, tcl85, tcl86, and for a period tcl87
>as separate ports (same for their tk counterparts, except perhaps for
>tk87, which was never there, iirc).  I was eventually able to deprecate
>and remove 84, 85, and 87, and to add 90.
>
>So now I'm left with 86 and 90.
>
>I don't think it makes sense to keep both 90 and 91 as separate ports,
>and I think at this point I'm leaning towards having a single tcl9 port
>for the 9.x series.
>
>First question: does it makes sense? Do you see any drawbacks?
>
>Second question / remark: does it still make sense to name our shared
>library and executable as libtcl9.1.so and tclsh9.1? I don't see those
>coexist with any other 9.X for any meaningful reason, so why don't we
>stop doing that and name things simply by major version?
>
>I know I can do that on my side, but I want to gather feedback on
>whether this is something we might want to consider.
>
>Shall there be one true novem?
>
>Thanks,
>
>Pietro
>
>On Jul 16 2025, 16:49 +0000, Donald G Porter via Tcl-Core
><tcl...@li...> wrote:
>>
>>Now available from
>>
>>https://sourceforge.net/projects/tcl/files/Tcl/9.1a0/
>>
>>is the RC0 release candidate of the first alpha release of Tcl 9.1.
>>
>>This is the first of a sequence of candidate releases leading to the
>release of
>>Tcl 9.1a0. Testing of builds and operations on multiple platforms is
>invited.  Open
>>tickets on any problems discovered, or raise the issue in a reply to this
>message.
>>
>>This candidate is not expected to become the release.  Some additional work
>on release notes and other supports is expected to appear in a subsequent
>candidate first.
>>
>>Thank you for your contributions and assistance.
>>
>>
>>
>>_______________________________________________
>>Tcl-Core mailing list
>>Tcl...@li...
>>https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>-- 
>Pietro Cerutti
>I have pledged to give 10% of income to effective charities
>and invite you to join me - https://givingwhatwecan.org
>
>
>_______________________________________________
>Tcl-Core mailing list
>Tcl...@li...
>https://lists.sourceforge.net/lists/listinfo/tcl-core
>

-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org

Re: [TCLCORE] [Ext] Re: Tcl 9.0a1 Release Candidate

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

Hello

Could ticket "glob error" b0682c3c2497e8f27f18e91686031dda055ed19c
also be a side effect?

Regards
Rene

Von: Dipl. Ing. Sergey G. Brester via Tcl-Core <tcl...@li...>
Gesendet: Freitag, 18. Juli 2025 18:11
An: Porter, Don (Fed) <don...@ni...>
Cc: Tcl Core List <tcl...@li...>
Betreff: [Ext] Re: [TCLCORE] Tcl 9.0a1 Release Candidate


Hi,

please don't release it (as well as other versions if some releases planned).

See my last comment<https://core.tcl-lang.org/tcl/info/e22d88bc21383820> to ticket 61c01e0edb08a9ed.

I think this use-after-free heisenbug could be considered as a blocker and the releases need to be paused at least till I fixed it (and review doesn't show similar bugs).

The issue is more worse as described in ticket (I don't want to publish there potential security issue), since it may be also a vulnerability (path traversal, data corruption etc),
if object may get "valid" but different path, and this weakness can be viewed as exploitable in a practical way (e. g. there are several scenarios to write usable exploit for this,
depending on its usage in code).

By the way (3 orthogonal subjects):

  1.  shall we create CVE or GH security advisory for this?
  2.  why "Private vulnerability reporting" is disabled in https://github.com/tcltk/tcl/security ? (I can enable it there, but would like to ask TCT firstly)
  3.  does anyone know why 9.x (and probably 8.7) may increase FS epoch often than 8.6/8.5...
or especially why FS functions like Tcl_FSGetNativePath invalidate path-object more often now?
Is it some effect of zipfs?.. However I speak about physical paths either.

Regards,
Serg.

06.11.2019 17:18, Porter, Don (Fed) via Tcl-Core wrote:
Now available from

https://sourceforge.net/projects/tcl/files/Tcl/9.0a1/

is the first release candidate of the first alpha release of Tcl 9.0.

Also included is a release candidate of package Thread 3.0a1 . Thread 2.8.5 rejects builds against Tcl 9, so this package is bundled so that Tcl 9 testers still have a working Thread package.
There is no Tk 9. Tk 8.7a3 should build against Tcl 9.0a1. The binary built should then [load] or [package require] into the Tcl 9.0a1 interpreter. Likewise other package source code distributions included with Tcl 8.6.10 should compile against Tcl 9.0a1, producing installations that can [package require] into Tcl 9.0a1. If this fails, we will have found a migration puzzle to solve as Tcl 9.0 continues its alpha development.

The expected release date is Nov. 21. Help us make that release high quality by testing this candidate and reporting any release-blocking failures in it.


_______________________________________________

Tcl-Core mailing list

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

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

[TCLCORE] Versioning and naming of libraries

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

(Changed subject line so as to not hijack the 9.1a0 release thread)

>From the point of view of an application writer, I would prefer to run
against a specific MAJOR.MINOR version of a shared library - the one I have
tested with. No matter the claims by library writers, there are always
incompatibilities in corner cases introduced even in minor versions (as
opposed to patchlevels). I've seen this with both libffi and libicu.
Considering that, I think 9.0, 9.1... should be distinguished, and of course
that means the naming of shared libraries should continue to include the
minor version number.

/Ashok

-----Original Message-----
From: Pietro Cerutti via Tcl-Core <tcl...@li...> 
Sent: Sunday, July 20, 2025 12:56 AM
To: Tcl List Core <tcl...@li...>
Cc: Pietro Cerutti <ga...@ga...>
Subject: Re: [TCLCORE] Tcl 9.1a0 Release Candidate

All,

although TIP439 (Semantic Versioning) was never finalized, it seems 
clear to me that we're handling the middle number of our versioning 
scheme differently in 9.x than how we did it in 8.x.

To me, it looks like the 9.0 -> 9.1 upgrade path is going to be smooth.
We all know that for 8.3, 8.4, 8.5, and 8.6, that wasn't the case.

As a downstream packager (I maintain a bunch of Tcl/Tk-related ports on 
FreeBSD), I used to maintain tcl84, tcl85, tcl86, and for a period tcl87 
as separate ports (same for their tk counterparts, except perhaps for 
tk87, which was never there, iirc).  I was eventually able to deprecate 
and remove 84, 85, and 87, and to add 90.

So now I'm left with 86 and 90.

I don't think it makes sense to keep both 90 and 91 as separate ports, 
and I think at this point I'm leaning towards having a single tcl9 port 
for the 9.x series.

First question: does it makes sense? Do you see any drawbacks?

Second question / remark: does it still make sense to name our shared 
library and executable as libtcl9.1.so and tclsh9.1? I don't see those 
coexist with any other 9.X for any meaningful reason, so why don't we 
stop doing that and name things simply by major version?

I know I can do that on my side, but I want to gather feedback on 
whether this is something we might want to consider.

Shall there be one true novem?

Thanks,

Pietro

On Jul 16 2025, 16:49 +0000, Donald G Porter via Tcl-Core
<tcl...@li...> wrote:
>
>Now available from
>
>https://sourceforge.net/projects/tcl/files/Tcl/9.1a0/
>
>is the RC0 release candidate of the first alpha release of Tcl 9.1.
>
>This is the first of a sequence of candidate releases leading to the
release of
>Tcl 9.1a0. Testing of builds and operations on multiple platforms is
invited.  Open
>tickets on any problems discovered, or raise the issue in a reply to this
message.
>
>This candidate is not expected to become the release.  Some additional work
on release notes and other supports is expected to appear in a subsequent
candidate first.
>
>Thank you for your contributions and assistance.
>
>
>
>_______________________________________________
>Tcl-Core mailing list
>Tcl...@li...
>https://lists.sourceforge.net/lists/listinfo/tcl-core

-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org


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

Re: [TCLCORE] Tcl 9.1a0 Release Candidate

[Pietro C. <ga...@ga...>]

All,

although TIP439 (Semantic Versioning) was never finalized, it seems 
clear to me that we're handling the middle number of our versioning 
scheme differently in 9.x than how we did it in 8.x.

To me, it looks like the 9.0 -> 9.1 upgrade path is going to be smooth.
We all know that for 8.3, 8.4, 8.5, and 8.6, that wasn't the case.

As a downstream packager (I maintain a bunch of Tcl/Tk-related ports on 
FreeBSD), I used to maintain tcl84, tcl85, tcl86, and for a period tcl87 
as separate ports (same for their tk counterparts, except perhaps for 
tk87, which was never there, iirc).  I was eventually able to deprecate 
and remove 84, 85, and 87, and to add 90.

So now I'm left with 86 and 90.

I don't think it makes sense to keep both 90 and 91 as separate ports, 
and I think at this point I'm leaning towards having a single tcl9 port 
for the 9.x series.

First question: does it makes sense? Do you see any drawbacks?

Second question / remark: does it still make sense to name our shared 
library and executable as libtcl9.1.so and tclsh9.1? I don't see those 
coexist with any other 9.X for any meaningful reason, so why don't we 
stop doing that and name things simply by major version?

I know I can do that on my side, but I want to gather feedback on 
whether this is something we might want to consider.

Shall there be one true novem?

Thanks,

Pietro

On Jul 16 2025, 16:49 +0000, Donald G Porter via Tcl-Core <tcl...@li...> wrote:
>
>Now available from
>
>https://sourceforge.net/projects/tcl/files/Tcl/9.1a0/
>
>is the RC0 release candidate of the first alpha release of Tcl 9.1.
>
>This is the first of a sequence of candidate releases leading to the release of
>Tcl 9.1a0. Testing of builds and operations on multiple platforms is invited.  Open
>tickets on any problems discovered, or raise the issue in a reply to this message.
>
>This candidate is not expected to become the release.  Some additional work on release notes and other supports is expected to appear in a subsequent candidate first.
>
>Thank you for your contributions and assistance.
>
>
>
>_______________________________________________
>Tcl-Core mailing list
>Tcl...@li...
>https://lists.sourceforge.net/lists/listinfo/tcl-core

-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org

Re: [TCLCORE] Tcl 9.0a1 Release Candidate

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

 

Hi,

please don't release it (as well as other versions if some releases
planned).

See my last comment [3] to ticket 61c01e0edb08a9ed. 

I think this use-after-free heisenbug could be considered as a blocker
and the releases need to be paused at least till I fixed it (and review
doesn't show similar bugs).

The issue is more worse as described in ticket (I don't want to publish
there potential security issue), since it may be also a vulnerability
(path traversal, data corruption etc),
if object may get "valid" but different path, and this weakness can be
viewed as exploitable in a practical way (e. g. there are several
scenarios to write usable exploit for this, 
depending on its usage in code). 

By the way (3 orthogonal subjects): 

 	* shall we create CVE or GH security advisory for this?
 	* why "Private vulnerability reporting" is disabled in
https://github.com/tcltk/tcl/security ? (I can enable it there, but
would like to ask TCT firstly)

	* does anyone know why 9.x (and probably 8.7) may increase FS epoch
often than 8.6/8.5...
or especially why FS functions like Tcl_FSGetNativePath invalidate
path-object more often now?
Is it some effect of zipfs?.. However I speak about physical paths
either. 

Regards,
Serg. 

06.11.2019 17:18, Porter, Don (Fed) via Tcl-Core wrote: 

> Now available from 
> 
> https://sourceforge.net/projects/tcl/files/Tcl/9.0a1/ [2] 
> 
> is the first release candidate of the first alpha release of Tcl 9.0. 
> 
> Also included is a release candidate of package Thread 3.0a1 . Thread 2.8.5 rejects builds against Tcl 9, so this package is bundled so that Tcl 9 testers still have a working Thread package.
> 
> There is no Tk 9. Tk 8.7a3 should build against Tcl 9.0a1. The binary built should then [load] or [package require] into the Tcl 9.0a1 interpreter. Likewise other package source code distributions included with Tcl 8.6.10 should compile against Tcl 9.0a1, producing installations that can [package require] into Tcl 9.0a1. If this fails, we will have found a migration puzzle to solve as Tcl 9.0 continues its alpha development. 
> 
> The expected release date is Nov. 21. Help us make that release high quality by testing this candidate and reporting any release-blocking failures in it. 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [1]
 

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/tcl-core
[2] https://sourceforge.net/projects/tcl/files/Tcl/9.0a1/
[3] https://core.tcl-lang.org/tcl/info/e22d88bc21383820

[TCLCORE] sqlite3 3.50.3 released

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

The upstream SQLite project released 3.50.3 of SQLite recently

>From that, I derived the TEA-based Tcl package we layer
on top of it.

    http://cyqlite.sourceforge.net/cgi-bin/sqlite/timeline

That's now available as Tcl package sqlite3.50.3.tar.gz from

    https://sourceforge.net/projects/tcl/files/Tcl/8.6.16/
or
    https://sourceforge.net/projects/tcl/files/Tcl/9.0.2/
or
    https://sourceforge.net/projects/tcl/files/Tcl/9.1a0/

Unpack that source distribution in the "pkgs" subdir of your Tcl
8.6.x or 9.x.y source code distribution and run `make install`
again for your platform.
That will build and install the updated sqlite package.

Unless another SQLite release happens first, this package will be
bundled with Tcl 8.6.17 / Tcl 9.0.3. I'm not sure if this will
be in Tcl 9.1a0 (since sqlite3 3.50.2 is fine too). I leave that
up to Don Porter to decide.

Regards,
     Jan Nijtmans

Re: [TCLCORE] Tk 9.1a0 Release Candidate

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

Looks good to go to me. Tested make test and make install on following configs:

Ubuntu 20 x64 (WSL). No Tk. Running Tk tests crashes X server but I believe that is a WSL issue, not Tcl.
- shared (Tcl+pkgs)
- static (Tcl+pkgs)
- shared, nozipfs (Tcl+pkgs)

Windows x64 Visual C++
- shared (Tcl, Tk, pkgs)
- static (Tcl+Tk only)
- shared,nozipfs (Tcl+Tk only)
- static,nozipfs (Tcl+Tk only)

Only usual chmod failures for Tcl and usual clipboard failures for Tk on Windows.

The following failure continues to be seen on occasion on both Win and Ubuntu. Has been logged as a ticket since 9.0 alpha. Probably benign on test cleanup. Only occurs if Threads package is available.

==== Test with ThreadLevel 2 ====
Test file error: http.test bgerror
invalid command name "::http::104--SocketCoroutine"
invalid command name "::http::104--SocketCoroutine"
    while executing
"::http::104--SocketCoroutine"
    ("after" script)
http.test bgerror
invalid command name "::http::158--SocketCoroutine"
invalid command name "::http::158--SocketCoroutine"
    while executing
"::http::158--SocketCoroutine"
    ("after" script)
http11.test

-----Original Message-----
From: Donald G Porter via Tcl-Core <tcl...@li...> 
Sent: Thursday, July 17, 2025 11:36 PM
To: Tcl List Core <tcl...@li...>
Subject: [TCLCORE] Tk 9.1a0 Release Candidate



Now available from

https://sourceforge.net/projects/tcl/files/Tcl/9.1a0/

is the RC1 release candidate of the first alpha release of Tk 9.1.

This is the second of a sequence of candidate releases leading to the release of
Tk 9.1a0. Testing of builds and operations on multiple platforms is invited.  Open
tickets on any problems discovered, or raise the issue in a reply to this message.

It is intended that the RC1 release will become the Tk 9.1a0 release on July 21,
unless some release-blocking flaw is discovered and reported.

Release notes are also available for review and correction.

Thank you for your contributions and assistance.

-- 
| 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] NaviServer/OpenACS/Tcl/Tk conference in Bologna is over

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

I was wrong in two points:

a) this page links video and slides:

https://openacs.km.at/evaluate/org/129998253/companyhelp/schedule

b) Manfred is included.

Sorry for the wrong information and take care,
Harald

Am 18.07.2025 um 11:54 schrieb Harald Oehlmann:
> Dear Tcl/Tk fans,
> 
> the conference is over and I plan to write a resumee with all the 
> panels. No time at the moment, TCL9.1a0 has priority...
> 
> Here are the presentations (so far, some are pending):
> 
> https://openacs.km.at/evaluate/org/129998253/companyhelp/schedule
> 
> Here are the recording videos. Thanks Antonio, would have needed one 
> full day to cut all this.
> 
> ttps://learn.wu.ac.at/eurotcl2025/
> 
> You should look Jim Davidson for fun, also Antonios AI speech is great.
> 
> The quality is surprisingly good. You can hear the audience. Even low 
> voice speakers are well on the recording. You can see the chat too.
> 
> The remote contribution by Manfred Rosenberger was not recorded.
> 
> Enjoy so far, more will come !
> 
> I want to thank all the volunteers to invest into the conference 
> organization - It was great and a hard work.
> 
> Thanks for all,
> Harald


-- 
ELMICRON Dr. Harald Oehlmann GmbH
Koesener Str. 85
06618 NAUMBURG - Germany
Phone: +49 3445 781120
Direct: +49 3445 781127
www.Elmicron.de
German legal references:
Geschaeftsfuehrer: Dr. Harald Oehlmann
UST Nr. / VAT ID No.: DE206105272
HRB 212803 Stendal

Re: [TCLCORE] Tcl 9.1a0 Release Candidate

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

Op do 17 jul 2025 om 21:33 schreef Paul Obermeier <pa...@po...>:
> Also note, that rc1 does not compile using gcc <= 8, because of the introduction of option --disable-high-entropy-va,
> which is not available in these gcc versions.

Worse, the option --disable-high-entropy-va is only implemented for 64-bit gcc,
not for 32-bit. Therefore, I added a test whether it is supported or not:
        <https://core.tcl-lang.org/tcl/info/a23639>
This works in all situations.

Thanks!
       Jan Nijtmans

[TCLCORE] NaviServer/OpenACS/Tcl/Tk conference in Bologna is over

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

Dear Tcl/Tk fans,

the conference is over and I plan to write a resumee with all the 
panels. No time at the moment, TCL9.1a0 has priority...

Here are the presentations (so far, some are pending):

https://openacs.km.at/evaluate/org/129998253/companyhelp/schedule

Here are the recording videos. Thanks Antonio, would have needed one 
full day to cut all this.

ttps://learn.wu.ac.at/eurotcl2025/

You should look Jim Davidson for fun, also Antonios AI speech is great.

The quality is surprisingly good. You can hear the audience. Even low 
voice speakers are well on the recording. You can see the chat too.

The remote contribution by Manfred Rosenberger was not recorded.

Enjoy so far, more will come !

I want to thank all the volunteers to invest into the conference 
organization - It was great and a hard work.

Thanks for all,
Harald

Re: [TCLCORE] Tcl 9.1a0 Release Candidate

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

These are almost all related to changing limit checks from INT_MAX to
UINT_MAX. I don't want to sound like a broken record about this change ...

Still, they're probably harmless other than degrading the S/N ratio.

-----Original Message-----
From: Emiliano <emi...@gm...> 
There are a lot of warnings compiling Tcl on Linux 32bit. I pasted them
here:

http://paste.tclers.tk/6112

Build completes and tests pass with 0 errors.

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


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

Re: [TCLCORE] Tcl 9.1a0 Release Candidate

[Donald A. <as...@tr...>]

On Thu, 17 Jul 2025, Jan Nijtmans <jan...@gm...> wrote

>Op do 17 jul 2025 om 21:33 schreef Paul Obermeier <pa...@po...>:
>>
>> Please note, that rc0 does not compile using gcc 4.9.2 (SUSE 42.3). It does work with gcc 7 and newer.
>...
>> Also note, that rc1 does not compile using gcc <= 8, because of the introduction of option --disable-high-entropy-va,
>> which is not available in these gcc versions.

> You are talking about Windows only, are you? For 9.1, I would say that's OK
> to support  gcc versions >= 9.1 (May 2019) only. But for 8.6 and 9.0, we still should still
> support older compilers on Windows.
>
> Note that gcc versions < 11 are no longer supported by the gcc maintainers.

Opensuse Leap 15.6  has gcc  version 7.5.0.
Leap 15.6 is the most recent version, release a year ago and supported until December 2025.

There must be LTS releases of Linux systems that have older gcc still.



Donald Arseneau             TRIUMF CMMS           604-222-1047 x6295

Re: [TCLCORE] Tcl 9.1a0 Release Candidate

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

On Thu, 17 Jul 2025 14:05:38 -0400
Donald G Porter via Tcl-Core <tcl...@li...> wrote:

> 
> Now available from
> 
> https://sourceforge.net/projects/tcl/files/Tcl/9.1a0/
> 
> is the RC1 release candidate of the first alpha release of Tcl 9.1.
> 
> This is the second of a sequence of candidate releases leading to the release of
> Tcl 9.1a0. Testing of builds and operations on multiple platforms is invited.  Open
> tickets on any problems discovered, or raise the issue in a reply to this message.
> 
> It is intended that the RC1 release will become the Tcl 9.1a0 release on July 21,
> unless some release-blocking flaw is discovered and reported.
> 
> Release notes are also available for review and correction.
> 
> Thank you for your contributions and assistance.

There are a lot of warnings compiling Tcl on Linux 32bit. I pasted them here:

http://paste.tclers.tk/6112

Build completes and tests pass with 0 errors.

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

Re: [TCLCORE] Tcl 9.1a0 Release Candidate

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

Op do 17 jul 2025 om 21:33 schreef Paul Obermeier <pa...@po...>:
>
> Please note, that rc0 does not compile using gcc 4.9.2 (SUSE 42.3). It does work with gcc 7 and newer.
...
> Also note, that rc1 does not compile using gcc <= 8, because of the introduction of option --disable-high-entropy-va,
> which is not available in these gcc versions.

You are talking about Windows only, are you? For 9.1, I would say
that's OK to support
gcc versions >= 9.1 (May 2019) only. But for 8.6 and 9.0, we still should still
support older compilers on Windows.

Note that gcc versions < 11 are no longer supported by the gcc maintainers.

Hope this helps,

Thanks!
   Jan Nijtmans

Re: [TCLCORE] Tcl 9.1a0 Release Candidate

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

Please note, that rc0 does not compile using gcc 4.9.2 (SUSE 42.3). It does work with gcc 7 and newer.

In file included from /home/obermeier/poSoft/BawtBuild-9.1.0-9.1.0-Release/Linux/x64/Release/Build/Tcl/generic/tclAssembly.c:32:0:
/home/obermeier/poSoft/BawtBuild-9.1.0-9.1.0-Release/Linux/x64/Release/Build/Tcl/generic/tclCompile.h:612:10: error: expected ‘,’ or ‘}’ before ‘__attribute__’
      name __attribute__((deprecated ("use 4-byte operand version instead")))
           ^
/home/obermeier/poSoft/BawtBuild-9.1.0-9.1.0-Release/Linux/x64/Release/Build/Tcl/generic/tclCompile.h:629:5: note: in expansion of macro ‘DEPRECATED_OPCODE’
      DEPRECATED_OPCODE(INST_PUSH1),

Also note, that rc1 does not compile using gcc <= 8, because of the introduction of option --disable-high-entropy-va,
which is not available in these gcc versions.

9.0.2 does compile and work using these old systems and compilers.

Paul


Am 17.07.2025 um 20:05 schrieb Donald G Porter via Tcl-Core:
>
> Now available from
>
> https://sourceforge.net/projects/tcl/files/Tcl/9.1a0/
>
> is the RC1 release candidate of the first alpha release of Tcl 9.1.
>
> This is the second of a sequence of candidate releases leading to the release of
> Tcl 9.1a0. Testing of builds and operations on multiple platforms is invited.  Open
> tickets on any problems discovered, or raise the issue in a reply to this message.
>
> It is intended that the RC1 release will become the Tcl 9.1a0 release on July 21,
> unless some release-blocking flaw is discovered and reported.
>
> Release notes are also available for review and correction.
>
> Thank you for your contributions and assistance.
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] Tcl 9.1a0 Release Candidate

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

Now available from

https://sourceforge.net/projects/tcl/files/Tcl/9.1a0/

is the RC1 release candidate of the first alpha release of Tcl 9.1.

This is the second of a sequence of candidate releases leading to the release of
Tcl 9.1a0. Testing of builds and operations on multiple platforms is invited.  Open
tickets on any problems discovered, or raise the issue in a reply to this message.

It is intended that the RC1 release will become the Tcl 9.1a0 release on July 21,
unless some release-blocking flaw is discovered and reported.

Release notes are also available for review and correction.

Thank you for your contributions and assistance.