tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Advice requested about support for "-singleproc 0" in the Tk test suite

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

I do find -singleproc useful in the Tcl test suite, both for uncovering bugs
and for isolation but I'm afraid I don't have enough familiarity with Tk to
opine.

The commit you referenced in [A] is curious though in that -singleproc is
not the only command line option that is overridden. Options -testdir and
-loadfile are also overridden. And the commit comment seems irrelevant.
Maybe you could remove the -singleproc override and see what errors crop up
that mandated the override ? If they are something not fixable, perhaps that
may be justification for simplification.

Sorry, can't provide any concrete feedback.

/Ashok

-----Original Message-----
From: Erik Leunissen via Tcl-Core <tcl...@li...> 
Sent: Sunday, July 27, 2025 12:42 AM
To: 'Tcl List Core' <tcl...@li...>
Subject: [TCLCORE] Advice requested about support for "-singleproc 0" in the
Tk test suite

L.S.

The tcltest harness provides an option "-singleproc", which enforces that
each
test file is evaluated in a separate process (and therefore in a separate
interpreter) if the option passes the value "0" along.

Currently the Tk test suite overrides any option "-singleproc" om the
command line
with "-singleproc 1" (in all.tcl). That makes "-singleproc 0" is
unsupported,
intentionally as it seems. For a history of the option "-singleproc" in
all.tcl,
please see [A].

While working on the Tk test suite, I see that considerable simplifications
can
be made to the initialization of each testfile [B]. But this is only so in
the
case of "-singleproc 1".

I would like to implement these simplifications. However, this only makes
sense
if support for mode "-singleproc 0" is indeed to be ruled out for the
foreseeable
future.

Could TCT-members / maintainers please advise me about that ?

Thanks in advance for your responses,
Erik Leunissen.
--

[A] The Tk test suite has always sourced test files into a single common
interpreter:
     1. in the very beginning, it didn't specify the option "-singleproc",
letting
        the default (-singleproc 1) prevail. This was allowed to be
overridden by
        a "-singleproc 0" on the command line.

     2. in 2002 (commit [c483179b915]) the option "singleproc 1" was
explicitly
        introduced in "all.tcl", but it was still allowed to be overridden
by a
        "-singleproc 0" on the command line:

	
[https://core.tcl-lang.org/tk/fdiff?v1=85629ca6e929932d&v2=caa64a2916c7f527]

     3. in 2007 (commit [38bf2cb83c]), using the command line to override
        "-singleproc 1" was disabled. This made the usage of a separate
interpreter
        for each test file unsupported:

	
[https://core.tcl-lang.org/tk/fdiff?v1=22b27e50675deec3&v2=5fd3e253a7d904de]

[B]  The most important simplification is the replacement of the
      -loadfile/loadTestedCommand mechanism. This mechanism, which is meant
for the
      mode "-singleproc 0", is somewhat involved by its nature, because it
needs to
      cross process boundaries. This mechanism can be replaced with a much
more simple
      alternative if we don't need to consider "-singleproc 0". Also, the
command to
      load package tcltest can be removed, because that has already been
done (in
      all.tcl, in the same process).
--


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

[TCLCORE] On namespace unknown and TIP 689

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

There has been an ongoing debate every few months about the behavior of
namespace unknown and TIP 689. Sergey recently also updated a ticket on the
matter (if I understood correctly) on benefits in performance through
delayed package loading.

 

I understand the pros of TIP 689 but am also cognizant of incompatibilities
in unforeseen ways, whether real or perceived.

 

I wonder if the following proposal would satisfy both parties by allowing
dynamic addition of commands to a namespace while greatly reducing (but
probably not completely eliminating) the chance of incompatibility.

 

A new command is introduced. ("expando" is a placeholder coming from COM
terminology)

 

namespace eval ns {

    namespace expando expandoProc

    proc expandoProc commandName {

        load or otherwise make commandName available and return 1

        otherwise return 0

    }

}

 

namespace ns2 {

   ::ns::someProc

}

 

The Tcl command resolution is modified as follows. 

*	The command ns::someProc is looked up in the current fashion
(namespace path etc.).
*	If not found, the *target* namespace ns is checked if it has defined
an expandoProc. Since it has, it is called. If it returns 1 indicating it
created a someProc command in its namespace, the original command is
re-executed. 
*	If the ns had not defined an expandoProc or if expandoProc returned
0, the current namespace unknown algorithm is followed.

 

With the clock command for example, no preloading needs to be done. The
first time clock::format is called, clock's expando proc will load the
implementation.

 

At the same time, since namespaces explicitly opt-in as expandable, the
incompatibilities will be intended and limited.

 

Obviously much hand-waving above and details to be sorted out.

 

But any obvious (or otherwise) flaws in the above? Thoughts?

 

/Ashok

Re: [TCLCORE] Biweekly telco on28th of July at 12:00 UTC

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

 

Hi.

(putting on an auditor hat)

Unfortunately, it doesn't - single-threaded applications are affected
almost in the same way,
just the possibility to create working exploit is lowered and would
depend on usage of affected APIs,
for example may require asynchronous or event-based handling or some
similar circumstances and 
the kind of further usage of "injured" objects.
However in open source world everything is open, so it'd be certainly
possible to find a vulnerable code,
even in single-threaded environment.
I won't try to provide any further explanation here (for obvious
reasons), also since there isn't even a CVE yet.

_(/taking off the auditor hat)_

But good to know that 8.6/9.0 would get the fix released soon. Thx! 

Regards,
Serg. 

28.07.2025 14:50, Harald Oehlmann wrote: 

> TOP4) Bug 61c01e: race condition in Windows thread file commands
> https://core.tcl-lang.org/tcl/info/61c01e0edb08a9ed [1]
> Sergey sees this as very critical.
> 
> Great work and great fix.
> Only affects multi-thread application, what lowers the attack surface.
 

Links:
------
[1] https://core.tcl-lang.org/tcl/info/61c01e0edb08a9ed

[TCLCORE] Biweekly telco on28th of July at 12:00 UTC

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

Dear Tcl/Tk team,

here is the report of the meeting of today:

TOP1) Points with TCL/Tk 9.1a0
All ok, to be published.
Great work!

TOP2) TIP 726: Unicode normalization

Great work !
Are 300KB extra size for executable ok?

Missing byte compilation is seen as relatively easy to add.

TOP3) TIP 700: Documentation reform: Torsten hat processed all TCL 
documentation files!

Great work!
It would also be ok to have 50% automatic conversion.
The community may rework manually.
It is more important to get it out.

TOP4) Bug 61c01e: race condition in Windows thread file commands
https://core.tcl-lang.org/tcl/info/61c01e0edb08a9ed
Sergey sees this as very critical.

Great work and great fix.
Only affects multi-thread application, what lowers the attack surface.
TCL 8.6 will have it in August.
TCL 9.0 will be later, which may be investigated.

The more often invalidating of the native path in 9.0 may also be 
tracked down.

TOP5) Late loading of commands to speed-up thread creation time
https://core.tcl-lang.org/tcl/info/62019f8aa9f5ec73
Sergey again.

Seen as great work. No detailed opinion.
Should "namespace unknown" search path be revised?

TOP6) Various Tk MAC-OS issues
Mark et al in action.

Great work, no detailed discussion here.

TOP7) Any other business.

7.1) TCLPro tools start to be in the orphaned git.
Ashok works on the debugger.
Not sure, if the debugger handles coroutines.
Cross dependencies are dissolved to have distinct tools.

7.2) Core corruption by malformed UTF-8 strings.
It may happen, that the core sees malformed internal utf-8 strings and 
may react badly. Extensions may pass invalid strings but other sources 
may be possible.
A discussion about this some time ago was remembered, that the 
additional time impact of checking them is not seen as beneficial.
It is advised to use "ExternalToUtf8" for any external string.

7.3) State of TCL for SuSE
The build of bundled packages for 9.0 and 8.6 automatically at the same 
time is an issue and is to solve. Proposal is to copy the bundled 
packages out.

7.4) Reinhard: X11.org or X11.free ?
Asks his expert in parallel.
Expert does not expect any distribution to distribute the XFree fork, as 
the forking person is not seen as reliable.
For the time being, it is advisable to ignore the fork.
Many distributions switch to Wayland.
For SuSE Enterprise, in future only Wayland.
Tk might still run trough XWayland.

---

Next meeting:
11th of August 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

Thank you for all,
Harald

Re: [TCLCORE] Biweekly telco on28th of July at 12:00 UTC

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

Thanks, Torsten, I appreciate !
Thanks for all,
Harald

Am 28.07.2025 um 10:36 schrieb Torsten Berg:
> Hi,
> 
> I will not be available today either as I am traveling.
> 
> Regarding TIP 700, please note that the conversion of all nroff files in 
> the Tcl repository does not mean, this part is finished. It is, as I 
> wrote in the commit message, an initial conversion. Yes, we now have 
> markdown files, but they still have issues and some nroff macros are 
> still not handled. That is what the fourth column in the table in this 
> file is for, counting both the number of initial conversions and final 
> conversions.
> 
> https://core.tcl-lang.org/tcl/file?name=tools/man2markdown- 
> README.md&ci=a2dd66906f2bfaeb <https://core.tcl-lang.org/tcl/file? 
> name=tools/man2markdown-README.md&ci=a2dd66906f2bfaeb>
> 
> 
> I am now working on the remaining issues for the Tcl pages. When that is 
> done, I will start with the manual pages for Tk which have not been 
> touched yet.
> 
> Cheers, Torsten
> 
> 
>> Am 28.07.2025 um 10:23 schrieb Harald Oehlmann 
>> <har...@el...>:
>>
>> Signierter PGP-Teil
>> Dear Tcl/Tk team,
>>
>> I am sorry, I am late with the announcement, was on holiday.
>> Don Porter announced, that he will not be part of the meeting today.
>>
>> He has sent the following message:
>>
>> Revised plan is to make the current tips of the release branches into 
>> RC2 on Tuesday,
>> Targeting release date of Wednesday.
>>
>> Topics for the meeting of today:
>>
>> TOP 1) Points with TCL/Tk 9.1a0
>>
>> TOP2) TIP 726: Unicode mornalization
>>
>> TOP3) TIP 700: Documentation reform: Torsten hat processed all TCL 
>> documentation files!
>>
>> TOP4) Bug 61c01e: race codition in Windows thread file commands
>> https://core.tcl-lang.org/tcl/info/61c01e0edb08a9ed <https://core.tcl- 
>> lang.org/tcl/info/61c01e0edb08a9ed>
>> Sergey sees this as very critical.
>>
>> TOP5) Late loading of commands to speed-up thread creation time
>> https://core.tcl-lang.org/tcl/info/62019f8aa9f5ec73 <https://core.tcl- 
>> lang.org/tcl/info/62019f8aa9f5ec73>
>> Sergey again.
>>
>> TOP6) Various Tk MAC-OS issues
>> Mark et al in action.
>>
>> TOP7) Any other business.
>>
>> ---
>>
>> Next meeting:
>> 11th of August 12:00 UTC onhttps://meet.jit.si/TclMonthlyMeetup 
>> <https://meet.jit.si/TclMonthlyMeetup>
>>
>> Thank you for all,
>> Harald
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li... <mailto:Tcl...@li...>
>> https://lists.sourceforge.net/lists/listinfo/tcl-core <https:// 
>> lists.sourceforge.net/lists/listinfo/tcl-core>
> 
> --
> 
> Torsten Berg
> Großer Belt 30
> 23560 Lübeck
> 
> be...@ty...
> 

Re: [TCLCORE] Biweekly telco on28th of July at 12:00 UTC

[Torsten B. <be...@ty...>]

Hi,

I will not be available today either as I am traveling.

Regarding TIP 700, please note that the conversion of all nroff files in the Tcl repository does not mean, this part is finished. It is, as I wrote in the commit message, an initial conversion. Yes, we now have markdown files, but they still have issues and some nroff macros are still not handled. That is what the fourth column in the table in this file is for, counting both the number of initial conversions and final conversions.

https://core.tcl-lang.org/tcl/file?name=tools/man2markdown-README.md&ci=a2dd66906f2bfaeb


I am now working on the remaining issues for the Tcl pages. When that is done, I will start with the manual pages for Tk which have not been touched yet. 

Cheers, Torsten


> Am 28.07.2025 um 10:23 schrieb Harald Oehlmann <har...@el...>:
> 
> Signierter PGP-Teil
> Dear Tcl/Tk team,
> 
> I am sorry, I am late with the announcement, was on holiday.
> Don Porter announced, that he will not be part of the meeting today.
> 
> He has sent the following message:
> 
> Revised plan is to make the current tips of the release branches into RC2 on Tuesday,
> Targeting release date of Wednesday.
> 
> Topics for the meeting of today:
> 
> TOP 1) Points with TCL/Tk 9.1a0
> 
> TOP2) TIP 726: Unicode mornalization
> 
> TOP3) TIP 700: Documentation reform: Torsten hat processed all TCL documentation files!
> 
> TOP4) Bug 61c01e: race codition in Windows thread file commands
> https://core.tcl-lang.org/tcl/info/61c01e0edb08a9ed
> Sergey sees this as very critical.
> 
> TOP5) Late loading of commands to speed-up thread creation time
> https://core.tcl-lang.org/tcl/info/62019f8aa9f5ec73
> Sergey again.
> 
> TOP6) Various Tk MAC-OS issues
> Mark et al in action.
> 
> TOP7) Any other business.
> 
> ---
> 
> Next meeting:
> 11th of August 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup
> 
> Thank you for all,
> Harald
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li... <mailto:Tcl...@li...>
> https://lists.sourceforge.net/lists/listinfo/tcl-core

--

Torsten Berg
Großer Belt 30
23560 Lübeck

be...@ty...

[TCLCORE] Biweekly telco on28th of July at 12:00 UTC

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

Dear Tcl/Tk team,

I am sorry, I am late with the announcement, was on holiday.
Don Porter announced, that he will not be part of the meeting today.

He has sent the following message:

Revised plan is to make the current tips of the release branches into 
RC2 on Tuesday,
Targeting release date of Wednesday.

Topics for the meeting of today:

TOP 1) Points with TCL/Tk 9.1a0

TOP2) TIP 726: Unicode mornalization

TOP3) TIP 700: Documentation reform: Torsten hat processed all TCL 
documentation files!

TOP4) Bug 61c01e: race codition in Windows thread file commands
https://core.tcl-lang.org/tcl/info/61c01e0edb08a9ed
Sergey sees this as very critical.

TOP5) Late loading of commands to speed-up thread creation time
https://core.tcl-lang.org/tcl/info/62019f8aa9f5ec73
Sergey again.

TOP6) Various Tk MAC-OS issues
Mark et al in action.

TOP7) Any other business.

---

Next meeting:
11th of August 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

Thank you for all,
Harald

Re: [TCLCORE] TIP 726 - looking for comments

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

TIP 726 (https://core.tcl-lang.org/tips/doc/trunk/tip/726.md), implementation, test cases and manpages are ready for review. Will target a CFV in about two weeks.

 

/Ashok

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Tuesday, July 8, 2025 11:26 AM
To: 'Harald Oehlmann' <har...@el...>; tcl...@li...
Subject: Re: [TCLCORE] TIP 726 - looking for comments

 

Harald, Thanks for the comments. Yes, agree the TIP needs to be restructured. Its current form was meant primarily for discussion purposes. I'll rearrange accordingly.

 

All, the utf8proc library is covered under multiple "MIT" licenses. See https://github.com/JuliaStrings/utf8proc/blob/master/LICENSE.md  The Unicode data license is something Tcl is already subject to as the currently used encoding tables are derived from there. So with respect to TIP 705, I presume no separate TIP is needed to permit code licensed under those terms to be added to the repository. If anyone disagrees, please speak up now.

 

/Ashok

 

-----Original Message-----
From: Harald Oehlmann <har...@el... <mailto:har...@el...> > 
Sent: Monday, July 7, 2025 7:25 PM
To: tcl...@li... <mailto:tcl...@li...> 
Subject: Re: [TCLCORE] TIP 726 - looking for comments

 

Hi Ashok,

great work. This is long time awaited feature, very helpful.

For me, this all sounds reasonable.

I am ok with the "unicode" ensemble and the mode names.

It may be added, that those names are also used in other programming 

languages.

Also, the reasoning for the library choice looks good.

It is great to ship the source with TCL to be build together.

 

On the TIP organization, I would prefer a clear and short specification 

at the top (e.g. command, c-api, libraqry choice) and to move all 

alternatives in an own section at the bottom.

 

I am also the opinion, that the used library may vary due to its 

availability, even over platforms or use-cases. For me, the command 

syntax is the main point of the TIP.

 

Thanks for all, GREAT !

Harald

 

 

Am 06.07.2025 um 10:09 schrieb apnmbx-public--- via Tcl-Core:

> I am looking for preliminary comments on TIP 726 ( <https://core.tcl-> https://core.tcl- 

> lang.org/tips/doc/trunk/tip/726.md <https://core.tcl-lang.org/tips/doc/ 

> trunk/tip/726.md>) – commands for Unicode normalization.

> 

> In order to avoid wasted effort in re-implementation I’d appreciate 

> early comments on the choice of libraries in particular. For reasons 

> stated in the TIP, the plan is to implement normalization using the 

> utf8proc library from Julia.

> 

> Also, comments on various choices presented for command naming and 

> placement are preferred sooner than later.

> 

> /Ashok

> 

> 

> 

> _______________________________________________

> 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

 

 

-- 

ELMICRON Dr. Harald Oehlmann GmbH

Koesener Str. 85

06618 NAUMBURG - Germany

Phone: +49 3445 781120

Direct: +49 3445 781127

 <http://www.Elmicron.de> www.Elmicron.de

German legal references:

Geschaeftsfuehrer: Dr. Harald Oehlmann

UST Nr. / VAT ID No.: DE206105272

HRB 212803 Stendal

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

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

> On Jul 21, 2025, at 11:06 AM, Donald G Porter via Tcl-Core <tcl...@li...> wrote:
> I should have RC2 for Tcl/Tk 9.1a0 later this week.  Revised release date target is
> July 28.

Revised plan is to make the current tips of the release branches into RC2 on Tuesday,
Targeting release date of Wednesday.

Thanks for your patience.

DGP

Re: [TCLCORE] Report of biweekly telco on14th of July at 12:00 UTC

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

> On Jul 14, 2025, at 9:10 AM, Harald Oehlmann <har...@el...> wrote:
> Next meeting:
> 28th of July 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup
> wiki.

FYI, I’ve had some family obligations arise, and will not be able to attend the meeting.

DGP

[TCLCORE] Advice requested about support for "-singleproc 0" in the Tk test suite

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

L.S.

The tcltest harness provides an option "-singleproc", which enforces that each
test file is evaluated in a separate process (and therefore in a separate
interpreter) if the option passes the value "0" along.

Currently the Tk test suite overrides any option "-singleproc" om the command line
with "-singleproc 1" (in all.tcl). That makes "-singleproc 0" is unsupported,
intentionally as it seems. For a history of the option "-singleproc" in all.tcl,
please see [A].

While working on the Tk test suite, I see that considerable simplifications can
be made to the initialization of each testfile [B]. But this is only so in the
case of "-singleproc 1".

I would like to implement these simplifications. However, this only makes sense
if support for mode "-singleproc 0" is indeed to be ruled out for the foreseeable
future.

Could TCT-members / maintainers please advise me about that ?

Thanks in advance for your responses,
Erik Leunissen.
--

[A] The Tk test suite has always sourced test files into a single common interpreter:
     1. in the very beginning, it didn't specify the option "-singleproc", letting
        the default (-singleproc 1) prevail. This was allowed to be overridden by
        a "-singleproc 0" on the command line.

     2. in 2002 (commit [c483179b915]) the option "singleproc 1" was explicitly
        introduced in "all.tcl", but it was still allowed to be overridden by a
        "-singleproc 0" on the command line:

	  [https://core.tcl-lang.org/tk/fdiff?v1=85629ca6e929932d&v2=caa64a2916c7f527]

     3. in 2007 (commit [38bf2cb83c]), using the command line to override
        "-singleproc 1" was disabled. This made the usage of a separate interpreter
        for each test file unsupported:

	  [https://core.tcl-lang.org/tk/fdiff?v1=22b27e50675deec3&v2=5fd3e253a7d904de]

[B]  The most important simplification is the replacement of the
      -loadfile/loadTestedCommand mechanism. This mechanism, which is meant for the
      mode "-singleproc 0", is somewhat involved by its nature, because it needs to
      cross process boundaries. This mechanism can be replaced with a much more simple
      alternative if we don't need to consider "-singleproc 0". Also, the command to
      load package tcltest can be removed, because that has already been done (in
      all.tcl, in the same process).
--

Re: [TCLCORE] Large files in repository

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

That's not too different to the current size of clock.test; provided they're text, they should be fine.

Donal.

-------- Original message --------
From: apnmbx-public--- via Tcl-Core <tcl...@li...>
Date: 22/07/2025 18:40 (GMT+00:00)
To: 'Tcl List Core' <tcl...@li...>
Subject: [TCLCORE] Large files in repository

> Are there any issues with committing large (about 2MB each) files to the core repository?

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

[elns <el...@xs...>]

On 7/23/25 04:58, apnmbx-public--- via Tcl-Core wrote:

> ... The Tcl/Tk fossil repo is already at 1.2GB or thereabouts. Another static 
> 10MB or so should not hurt.
> 

I guess that the Tcl fossil repo then.
(The reasoning for Tk may be different; its fossil repo is 253 MB.)

Erik.
-- 

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

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

Colin, I do want these to be part of checkouts as string.test, encoding.test will all use them so unversioned files are not an option I think.

 

Sergey, Files are not binary, just plain text test vectors, so AV etc should not be an issue. I am hesitant to introduce submodules, even it such a thing exists in fossil, particularly if as the link you gave suggests there are not a lot of docs for it. Also, it does not really help with the issue of work tree storage.

 

I thought about downloading on the fly when the test is run but that opens a whole another can of worms.

 

As an aside, this is independent of any TIP’s. Just more robust verification of Tcl encodings and character classification.

 

I think I will commit the files. As Don said, it’s not that different from the storage for the long histories of source files. The Tcl/Tk fossil repo is already at 1.2GB or thereabouts. Another static 10MB or so should not hurt.

 

/Ashok

 

From: Dipl. Ing. Sergey G. Brester via Tcl-Core <tcl...@li...> 
Sent: Tuesday, July 22, 2025 11:31 PM
To: Donald G Porter <don...@ni...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] [EXTERNAL] Large files in repository

 

+ size increase on every working copy;
+ extra time some rude AV/IDS/whatever-security-tools could "inspect" that large (binary?) files.
I already had similar question about binaries, e. g. https://sourceforge.net/p/tcl/mailman/tcl-core/thread/b188cde91320bc49b964c5f1e6147c08%40sebres.de/ 
and IIRC, in the discussion Donal F. (dkf) said that fossil seems to have something like gits submodules, 
so may be this would the option?

Regards,
Serg.

22.07.2025 19:44, Donald G Porter via Tcl-Core wrote:

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?

Re: [TCLCORE] Large files in repository

[Poor Y. <org...@po...>]

On 2025-07-22 20: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.)

A 2MB text file in the repository is far preferable to a 25Kb binary 
file.

-- 
Yorick

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

[Colin M. <col...@ya...>]

Perhaps the "unversioned files" feature in Fossil would be suitable for 
this, see https://fossil-scm.org/home/doc/trunk/www/unvers.wiki. These 
do not get included when you clone or sync the repository unless you 
give it the -u flag, so that would be needed to run the tests that use 
these files, but checkouts that did not need that would not get bigger.

Colin.

On 22/07/2025 19:00, Dipl. Ing. Sergey G. Brester via Tcl-Core wrote:
>
> + size increase on every working copy;
> + extra time some rude AV/IDS/whatever-security-tools could "inspect" 
> that large (binary?) files.
> I already had similar question about binaries, e. g. 
> https://sourceforge.net/p/tcl/mailman/tcl-core/thread/b188cde91320bc49b964c5f1e6147c08%40sebres.de/ 
>
> and IIRC, in the discussion Donal F. (dkf) said that fossil seems to 
> have something like gits submodules,
> so may be this would the option?
>
> Regards,
> Serg.
>
> 22.07.2025 19:44, Donald G Porter via Tcl-Core wrote:
>
>> 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?
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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

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

 

+ size increase on every working copy;
+ extra time some rude AV/IDS/whatever-security-tools could "inspect"
that large (binary?) files.
I already had similar question about binaries, e. g.
https://sourceforge.net/p/tcl/mailman/tcl-core/thread/b188cde91320bc49b964c5f1e6147c08%40sebres.de/
[1] 
and IIRC, in the discussion Donal F. (dkf) said that fossil seems to
have something like gits submodules, 
so may be this would the option?

Regards,
Serg. 

22.07.2025 19:44, Donald G Porter via Tcl-Core wrote: 

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

Links:
------
[1]
https://sourceforge.net/p/tcl/mailman/tcl-core/thread/b188cde91320bc49b964c5f1e6147c08%40sebres.de/

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
>