tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] CFV Warning - TIP 733

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

Hello all,

This is a CFV warning for TIP 733, screen reader/accessibility support 
for Tk. I consider the project feature complete and as stable as I can 
make it at this point. I'd appreciate final reviews/comments, and then I 
will call for a formal vote in the next couple of weeks. My goal is to 
include TIP 733 in 9.1.a1, which I understand is by the end of November.

I've received detailed feedback from Ashok, Jan, and Nico. I'd like to 
address each point:

1. Nico reported a crash on startup. I am not able to reproduce this crash.

2. Jan noted that the test suite failed on all three platforms during 
automated Github runs. I added code to accessibility.tcl to return an 
empty namespace if a screen reader isn't running. That way there will be 
no unintended side effects from the accessibility commands conflicting 
with the test suite, which  now runs normally on all three platforms. 
Note: I am NOT including automated testing of accessibility within the 
test suite itself. Accessibility is best tested through interactive use 
of a screen reader.

3. Toggleswitch - Added and made accessible on all platforms. This 
implementation may be refined in the future as the widget is brand new, 
but for now I just wanted to ensure the widget's inclusion in accessibility.

4. "Set/get" balance in commands - complete.

5. Language issues/macOS - I have not received further feedback on my 
fix. This is not a showstopper for approving the TIP, in any case, but 
can be addressed later through bug reporting if needed.

6. Progress bars - I have opted for a simple implementation that returns 
a verbalized "busy" if the widget is running. This means that if a 
progress bar is visible, it will report "busy" even if it is not running 
- the best solution here would be to hide the widget when not active. 
(That's what I do in my apps.) There is no easy way to track the 
animation state of a running progress bar in real time, and I judged the 
complexity of supporting this to be not worth the effort. If anyone 
disagrees, they are welcome to submit a patch after the TIP is finalized.

7. Echoing keypresses and the prior word in text and entry widgets - 
done, on all three platforms. I think that is the most significant 
addition based on the prior feedback and brings Tk accessibility much 
more in line with expectations - thanks for that suggestion, Ashok.

8. Microsoft Narrator support - rudimentary. Ashok, I have been able to 
implement all your suggestions - but they only work well with NVDA. (I 
also assume they work with JAWS, but as it is an expensive proprietary 
product with a subscription licensing model similar to Adobe, I have not 
attempted to use it.) UI Automation is a significantly more complex API 
than Microsoft Active Accessibility, which is no lightweight API in 
itself. I have spent a great deal of time trying to make UIA and MSAA 
work together, but have not made any progress. The LegacyIAccessible 
pattern that I've implemented for UIA support does not do much,  and 
attempting to develop a complete UIA implementation has risked turning 
the Windows portion of this project into a mess. Unfortunately, the 
accessibility environment on Windows is quite fragmented, and requires 
the developer to make some choices. My choice has been to focus on MSAA, 
which lines up very well with Tk's widget set and overall UI design, and 
NVDA, which is an extremely robust, FOSS screen reader. Ashok, if you 
install NVDA and run the widget demo, you will see a significant 
difference. My decisions here also mean that we have to document that 
Narrator is not well-supported, which I have noted in the TIP. I am not 
happy with this, but those are the choices Windows presents. A proper 
UIA implementation is a project for another day, and given I have spent 
18 months on just this, I may opt to leave that for someone else to 
implement.

Looking forward to any further comments. Thanks to all.

--Kevin

Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax

[EricT <tw...@gm...>]

Thank you for the positive feedback and for raising this in Monday's telco!
I'm encouraged by your support.

Regarding $(a) - you're right that reading an empty array element with a
variable index is a valid construct. However, this is explicitly addressed
in the TIP and the repository README. The workarounds are straightforward:

  ${(a)}        # Braced form
  [set (a)]     # Command substitution

Both still work. In fact, code using $(varname) could be proactively
modified to use ${(varname)} to indicate the clear intent of an empty array
reference, which improves readability. The security, performance, and
usability benefits of $(...) seemed to justify this trade-off for Tcl 9.x
where some incompatibilities are expected.

Given your interest in the feature, would you be willing to consider
sponsoring TIP 672? The implementation is working and minimal (~100 lines
across two files), with the main open question being the preferred approach
for tracking synthetic strings for cleanup. Your guidance on that
architectural decision would be particularly valuable.

The prototype repository with full implementation and examples is here:

https://github.com/rocketship88/tcl-tip-672-prototype

Looking forward to the results of the discussion on Monday! I won't be able
to join the telco discussion, but I'm available via email for any questions
or clarifications that arise.


On Sat, Oct 18, 2025 at 1:09 PM Harald Oehlmann <har...@el...>
wrote:

> Am 17.10.2025 um 23:22 schrieb EricT:
> > Hello Tcl Core Team,
> >
> > I have developed a working prototype implementation of TIP 672, which
> > adds the $(expression) syntax as a more intuitive alternative to [expr
> > {expression}].
> >
> > Repository: https://github.com/rocketship88/tcl-tip-672-prototype
> > <https://github.com/rocketship88/tcl-tip-672-prototype>
> >
> > The implementation is minimal, modifying only two files (tclParse.c and
> > tclNamesp.c) with approximately 100 lines of changes. The key
> > modification converts the existing two-way branch in Tcl_ParseVarName to
> > a three-way branch, with the new path handling $(...) by creating a
> > synthetic [expr {...}] command string.
> >
> > Key Accomplishments:
> >
> > Full bytecode compilation: The synthetic string approach integrates
> > seamlessly with the existing compiler, producing identical optimized
> > bytecode as [expr {...}]. The disassembler output (shown in the README)
> > demonstrates efficient variable loading with no runtime parsing overhead.
> >
> > Proven approach: Jim Tcl has used this syntax successfully for years
> >
> > Comprehensive testing: Works correctly with string interpolation,
> > variable scoping, error handling, and interactive mode
> >
> > Known Limitations:
> >
> > Memory leak: The synthetic string is allocated but not tracked for
> > cleanup in Tcl_FreeParse. This requires core team guidance on the
> > preferred solution (modify Tcl_Parse structure vs. thread-local
> tracking).
> >
> > Error messages: Currently show the synthetic command rather than the
> > original $(...) syntax, though this is arguably helpful for debugging.
> >
> > Questions for the Team:
> >
> > What is the preferred approach for tracking synthetic strings for
> cleanup?
> > Is this prototype architecture acceptable for Tcl 9.x?
> > Are there concerns with the synthetic string approach that I should
> address?
> >
> > The complete implementation with side-by-side diffs is available in the
> > repository. I'm happy to refine the code based on your feedback and
> > would appreciate any guidance on moving this forward.
> >
> > Best regards,
> > Eric
> Eric,
> great proposal, thank you !
>
> Perhaps, we may discuss this on Monday in the biweekly telco.
> I am also excited and in favor to this.
> Nevertheless, "$(a)" is to my knowledge a quite common syntax for
> arrays. We have already killed less disruptive proposals (see optional
> "- args") by endless discussions and getting nowhere.
> Hope, this will be fruitful.
>
> In addition, I would like to add the Tk test reform by the other Eric to
> the biweekly topics.
> Here is a revised agenda proposal proposal:
>
> Top 1) Release calender (TIP 713)
> - 9.0.3: October (2 weeks left)
> - 9.1a1: November (6 weeks left)
> Top 2) TIP 734 nested mutex (go or not)
> Top 3) TIP 733: accessability (test status)
> Top 4) TIP 732: TCL library path (discussion)
> Top 5) TIP 731: use C enums (no brainer?)
> Top 6) TIP 720: new bytecodes (final, great! Any issues?)
> Top 7) TIP 721: Tcl_AttemptGetString
> Top 8) TIP 715: supported build systems
> Top 9) $($a+$b) syntax for expressions
> Top 10) Tk test reform by Eric (Thanks !)
> Top 11) Tcl depot and awthemes ?
> Top 12) AOB
> Top 13) Next meeting:
>      3rd of November 12:00 UTC.
>      Daytime saving time ends 2nd of November in US, 26th of October in
> Europe.
>      Will we keep 12:00 UTC ? Or 13:00 UTC, so Don has 8:00 AM?
>
> Take care,
> Harald
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax

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

Am 17.10.2025 um 23:22 schrieb EricT:
> Hello Tcl Core Team,
> 
> I have developed a working prototype implementation of TIP 672, which 
> adds the $(expression) syntax as a more intuitive alternative to [expr 
> {expression}].
> 
> Repository: https://github.com/rocketship88/tcl-tip-672-prototype 
> <https://github.com/rocketship88/tcl-tip-672-prototype>
> 
> The implementation is minimal, modifying only two files (tclParse.c and 
> tclNamesp.c) with approximately 100 lines of changes. The key 
> modification converts the existing two-way branch in Tcl_ParseVarName to 
> a three-way branch, with the new path handling $(...) by creating a 
> synthetic [expr {...}] command string.
> 
> Key Accomplishments:
> 
> Full bytecode compilation: The synthetic string approach integrates 
> seamlessly with the existing compiler, producing identical optimized 
> bytecode as [expr {...}]. The disassembler output (shown in the README) 
> demonstrates efficient variable loading with no runtime parsing overhead.
> 
> Proven approach: Jim Tcl has used this syntax successfully for years
> 
> Comprehensive testing: Works correctly with string interpolation, 
> variable scoping, error handling, and interactive mode
> 
> Known Limitations:
> 
> Memory leak: The synthetic string is allocated but not tracked for 
> cleanup in Tcl_FreeParse. This requires core team guidance on the 
> preferred solution (modify Tcl_Parse structure vs. thread-local tracking).
> 
> Error messages: Currently show the synthetic command rather than the 
> original $(...) syntax, though this is arguably helpful for debugging.
> 
> Questions for the Team:
> 
> What is the preferred approach for tracking synthetic strings for cleanup?
> Is this prototype architecture acceptable for Tcl 9.x?
> Are there concerns with the synthetic string approach that I should address?
> 
> The complete implementation with side-by-side diffs is available in the 
> repository. I'm happy to refine the code based on your feedback and 
> would appreciate any guidance on moving this forward.
> 
> Best regards,
> Eric
Eric,
great proposal, thank you !

Perhaps, we may discuss this on Monday in the biweekly telco.
I am also excited and in favor to this.
Nevertheless, "$(a)" is to my knowledge a quite common syntax for 
arrays. We have already killed less disruptive proposals (see optional 
"- args") by endless discussions and getting nowhere.
Hope, this will be fruitful.

In addition, I would like to add the Tk test reform by the other Eric to 
the biweekly topics.
Here is a revised agenda proposal proposal:

Top 1) Release calender (TIP 713)
- 9.0.3: October (2 weeks left)
- 9.1a1: November (6 weeks left)
Top 2) TIP 734 nested mutex (go or not)
Top 3) TIP 733: accessability (test status)
Top 4) TIP 732: TCL library path (discussion)
Top 5) TIP 731: use C enums (no brainer?)
Top 6) TIP 720: new bytecodes (final, great! Any issues?)
Top 7) TIP 721: Tcl_AttemptGetString
Top 8) TIP 715: supported build systems
Top 9) $($a+$b) syntax for expressions
Top 10) Tk test reform by Eric (Thanks !)
Top 11) Tcl depot and awthemes ?
Top 12) AOB
Top 13) Next meeting:
     3rd of November 12:00 UTC.
     Daytime saving time ends 2nd of November in US, 26th of October in 
Europe.
     Will we keep 12:00 UTC ? Or 13:00 UTC, so Don has 8:00 AM?

Take care,
Harald

[TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax

[EricT <tw...@gm...>]

Hello Tcl Core Team,

I have developed a working prototype implementation of TIP 672, which adds
the $(expression) syntax as a more intuitive alternative to [expr
{expression}].

Repository: https://github.com/rocketship88/tcl-tip-672-prototype

The implementation is minimal, modifying only two files (tclParse.c and
tclNamesp.c) with approximately 100 lines of changes. The key modification
converts the existing two-way branch in Tcl_ParseVarName to a three-way
branch, with the new path handling $(...) by creating a synthetic [expr
{...}] command string.

Key Accomplishments:

Full bytecode compilation: The synthetic string approach integrates
seamlessly with the existing compiler, producing identical optimized
bytecode as [expr {...}]. The disassembler output (shown in the README)
demonstrates efficient variable loading with no runtime parsing overhead.

Proven approach: Jim Tcl has used this syntax successfully for years

Comprehensive testing: Works correctly with string interpolation, variable
scoping, error handling, and interactive mode

Known Limitations:

Memory leak: The synthetic string is allocated but not tracked for cleanup
in Tcl_FreeParse. This requires core team guidance on the preferred
solution (modify Tcl_Parse structure vs. thread-local tracking).

Error messages: Currently show the synthetic command rather than the
original $(...) syntax, though this is arguably helpful for debugging.

Questions for the Team:

What is the preferred approach for tracking synthetic strings for cleanup?
Is this prototype architecture acceptable for Tcl 9.x?
Are there concerns with the synthetic string approach that I should address?

The complete implementation with side-by-side diffs is available in the
repository. I'm happy to refine the code based on your feedback and would
appreciate any guidance on moving this forward.

Best regards,
Eric

Re: [TCLCORE] Merge intention for project simplify_test_file_init

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

On 10/13/25 13:34, Erik Leunissen via Tcl-Core wrote:

> 
> Unless someone raises founded objections in the meantime, I will carry out the
> intended merge on next Friday, or the first opportunity for me thereafter.
> 

Now done.

Erik Leunissen.
--

[TCLCORE] Biweekly telco on 20th of October at 12:00 UTC

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

Dear Tcl/Tk team,

please feel invited to the next Tcl/Tk beweekly telco:
20th of October at 12:00 UTC
At: https://meet.jit.si/TclMonthlyMeetup

Agenda proposal:

Top 1) Release calender (TIP 713)
- 9.0.3: October (2 weeks left)
- 9.1a1: November (6 weeks left)
Top 2) TIP 734 nested mutex (go or not)
Top 3) TIP 733: accessability (test status)
Top 4) TIP 732: TCL library path (discussion)
Top 5) TIP 731: use C enums (no brainer?)
Top 6) TIP 720: new bytecodes (final, great! Any issues?)
Top 7) TIP 721: Tcl_AttemptGetString
Top 8) TIP 715: supported build systems
Top 9) AOB
Top 10) Next meeting:
     3rd of November 12:00 UTC.
     Daytime saving time ends 2nd of November in US, 26th of October in 
Europe.
     Will we keep 12:00 UTC ? Or 13:00 UTC, so Don has 8:00 AM?

Thank you for all,
Harald

[TCLCORE] Toggleswitch

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

Hi Csaba,

I’m adding accessibility support for the  toggleswitch since it’s been merged to trunk. What are the correct semantics to query its on/off state? Same as a checkbutton?

Thanks,
Kevin

Re: [TCLCORE] ANNOUNCE: TclTLS 2.0b2 Release

[Brian O’H. <bri...@co...>]

Since I had to redo the whole build system, there is likely still some issues with static builds on the Mac since  don’t have a Mac to test with. Look at the end of acinclude.m4 file for the add static libraries code.

Sent from my iPad

> On Oct 14, 2025, at 7:04 AM, Paul Obermeier <pa...@po...> wrote:
> 
> Has anybody succeeded in compiling tcltls 2.0b2 on macOS?
> 
> I tried several configure options, but always get the following linker errors:
> ld: unknown options: -Bstatic -Bdynamic
> 
> I'm using a static build of OpenSSL 3.5.4 on a M2 Mac running Sequoia 15.6.1.
> gcc --version prints 17.0.0 (clang-1700.3.19.1)
> 
> The new tcltls version works fine on Windows and Linux.
> 
> Thanks,
> Paul
> 
>> Am 13.10.2025 um 09:24 schrieb Harald Oehlmann:
>> Brian did post this epic message on clt newsgroup.
>> Please allow me to forward it to the core list.
>> Harald
>> ---
>> This is the beta 2 release of the TclTLS v2.0 package. There have been numerous bug fixes since the beta 1 release. The plan is to do the final release in a week, so please test and file any bug reports at the below sites. See below for links to the files and the release notes. Thanks.
>> 
>> 
>>     TclTLS 2.0 Release Notes:
>> 
>> 
>>       *Notable New Features:*
>> 
>> - Fully TEA compliant build system has been added back. Supports Windows, Linux, Mac, BSD, etc.
>> - Compatible with OpenSSL 3.0+ and TCL 9.0 including build-info command.
>> - Can use MS Windows Certificate Store on OpenSSL 3.2 or later.
>> - Greatly expanded the status returned by the tls::status command and also added the new tls::connection command. The former returns SSL and certificate status while the latter returns the SSL status, cipher, and session info.
>> - Added missing TLS 1.3 functionality, set cipher suites, ALPN, SNI, security level, etc.
>> - Error handing improvements, more specific error status, more connection status via callbacks.
>> - Replaced separate Diffie-Hellman (DH) header file build process with auto select.
>> - Add new tls::protocols command to list available SSL and TLS protocols.
>> - Now can load CA certificates, key files, etc. from virtual file systems (VFS).
>> 
>> See https://chiselapp.com/user/bohagan/repository/TCLTLS/home for more info.
>> 
>> 
>>       *Documentation Updates:*
>> 
>> - Documentation was extensively updated and converted to man page and HTML format.
>> - Updated the examples in the documentation and added an examples directory.
>> - Expanded the documentation and added a Certificate Validation section with info on how PKI and certificates work and the related TclTLS args.
>> - Extensive code documentation updates.
>> 
>> 
>>       *Notable Bug Fixes:*
>> 
>> (Some of these issues have been around for 15-20 years.)
>> - Many bugs, patches, etc. submitted to sourceforge.net and core.tcl.tk have been fixed or implemented.
>> - Unexpected EOF: Added fix to correct OpenSSL issue where some sessions can result in an unexpected EOF.
>> - Empty reads: These have been eliminated the extent possible, but may still occur. See demos for how to handle this.
>> - Lock-ups and Stalling connections: These have been fixed to the extent possible with a more robust event checking process.
>> - Manual certificate validation is no longer needed. OpenSSL will do this for you if -require 1 is specified. You can see results via -validatecommand callback and in tls::status verifyResult.
>> - Will only call bgerror if the -command, -password, or -validatecommand callbacks throw an error.
>> - Will send proper close_notify message to peer on channel closure.
>> 
>> See the documentation for a complete list of changes.
>> 
>> 
>>       *Tested with: *
>> 
>>   * TCL 8.6.14 and 9.0.2
>>   * OpenSSL 1.1.1w, 3.0.18, 3.5.4, and 3.6.0
>>   * Windows 7, Windows 10, Msys64, OpenSuSE Linux Leap 15.6 and 16.0,
>>     and FreeBSD
>> 
>> 
>> 
>>     *Potential Compatibility Issues:*
>> 
>> 
>>       *Option default changes:*
>> 
>> - The -autoservername option defaults to true if -servername is not specified.
>> - The -castore option defaults to "org.openssl.winstore://" on MS Windows with OpenSSL 3.2+ if-cadir, -cadir, and -castore are not specified.
>> - The -request option defaults to true for clients.
>> - The -require option defaults to true for clients. This may be an issue if the Certificate Authority (CA) certificates are not available.
>> - The -servername option defaults to socket host when used with tls::socket. So -autoservername is no longer required.
>> - The -ssl2 option is no longer supported by OpenSSL 1.1+.
>> - The -ssl3 option doesn't have any effect by default. Use --enable-ssl3 compile time option to enable SSL3 first.
>> - The -tls1 and tls1.1 options default to false (not enabled).
>> - The -tls1.2 and tls1.3 options default to true (enabled).
>> 
>> 
>>       *Callback changes:*
>> 
>> - Only status/error message use the -command handler now. There are several new types and the 'verify' type was moved to -validatecommand.
>> - Validation of certificates, client values, etc. use the new -validatecommand handler.
>> - Password inputs use -password handler, but it now passes 3 arguments.
>> 
>> See the documentation for all compatibility changes.
>> 
>> 
>>       *Open Issues:*
>> 
>> - May not be compatible with LibreSSL anymore.
>> - Warnings for deprecated OpenSSL API usage. Will be fixed in a future release.
>> - Some BadSSL test cases may still fail due to platform specific certificate checking defaults.
>> 
>> 
>>     *Download links:*
>> 
>> 
>> Source code is available at https://core.tcl-lang.org/tcltls/home in the tls-2.0 branch or in the following release files:
>> 
>>   * https://core.tcl-lang.org/tcltls/uv/tcltls-2.0b2.tar.gz
>>   * https://github.com/bohagan1/TclTLS/archive/refs/tags/tls-2.0b2.tar.gz
>> 
>> 
>> Windows library file link (TCL 8.6 & 9.0 with OpenSSL 3.6.0):
>> 
>>   * https://chiselapp.com/user/bohagan/repository/TCLTLS/uv/tls2.0b2_win64_msvc.zip
>>   * https://github.com/bohagan1/TclTLS/releases/download/tls-2.0b2/tls2.0b2_win64_msvc.zip
>> 
>> 
>> Certificate Authority (CA) certificates:
>> 
>> Please read the documentation "Certificate Validation" section if you don't have OpenSSL or the Certificate Authority (CA) certificates in PEM format installed on your system. If not, they can be obtained from:
>> https://core.tcl-lang.org/tcltls/file?name=doc/tls.html&ci=tls-2.0 <https://core.tcl-lang.org/tcltls/file?name=doc/tls.html&ci=tls-2.0>
>> 
>> 
>>     How to use this release:
>> 
>> 
>> package prefer latest
>> package require tls ?2.0b2?
>> 
>> See the README.txt file for the build steps.
>> See the documentation "Examples" section for usage examples.
>> More detailed examples can be found in the demos directory.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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] ANNOUNCE: TclTLS 2.0b2 Release

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

Has anybody succeeded in compiling tcltls 2.0b2 on macOS?

I tried several configure options, but always get the following linker errors:
ld: unknown options: -Bstatic -Bdynamic

I'm using a static build of OpenSSL 3.5.4 on a M2 Mac running Sequoia 15.6.1.
gcc --version prints 17.0.0 (clang-1700.3.19.1)

The new tcltls version works fine on Windows and Linux.

Thanks,
Paul

Am 13.10.2025 um 09:24 schrieb Harald Oehlmann:
> Brian did post this epic message on clt newsgroup.
> Please allow me to forward it to the core list.
> Harald
> ---
> This is the beta 2 release of the TclTLS v2.0 package. There have been numerous bug fixes since the beta 1 release. The plan is to do the final release in a week, so please test and file any bug reports at the below sites. See below for links to the files and the release notes. Thanks.
>
>
>     TclTLS 2.0 Release Notes:
>
>
>       *Notable New Features:*
>
> - Fully TEA compliant build system has been added back. Supports Windows, Linux, Mac, BSD, etc.
> - Compatible with OpenSSL 3.0+ and TCL 9.0 including build-info command.
> - Can use MS Windows Certificate Store on OpenSSL 3.2 or later.
> - Greatly expanded the status returned by the tls::status command and also added the new tls::connection command. The former returns SSL and certificate status while the latter returns the SSL status, cipher, and session info.
> - Added missing TLS 1.3 functionality, set cipher suites, ALPN, SNI, security level, etc.
> - Error handing improvements, more specific error status, more connection status via callbacks.
> - Replaced separate Diffie-Hellman (DH) header file build process with auto select.
> - Add new tls::protocols command to list available SSL and TLS protocols.
> - Now can load CA certificates, key files, etc. from virtual file systems (VFS).
>
> See https://chiselapp.com/user/bohagan/repository/TCLTLS/home for more info.
>
>
>       *Documentation Updates:*
>
> - Documentation was extensively updated and converted to man page and HTML format.
> - Updated the examples in the documentation and added an examples directory.
> - Expanded the documentation and added a Certificate Validation section with info on how PKI and certificates work and the related TclTLS args.
> - Extensive code documentation updates.
>
>
>       *Notable Bug Fixes:*
>
> (Some of these issues have been around for 15-20 years.)
> - Many bugs, patches, etc. submitted to sourceforge.net and core.tcl.tk have been fixed or implemented.
> - Unexpected EOF: Added fix to correct OpenSSL issue where some sessions can result in an unexpected EOF.
> - Empty reads: These have been eliminated the extent possible, but may still occur. See demos for how to handle this.
> - Lock-ups and Stalling connections: These have been fixed to the extent possible with a more robust event checking process.
> - Manual certificate validation is no longer needed. OpenSSL will do this for you if -require 1 is specified. You can see results via -validatecommand callback and in tls::status verifyResult.
> - Will only call bgerror if the -command, -password, or -validatecommand callbacks throw an error.
> - Will send proper close_notify message to peer on channel closure.
>
> See the documentation for a complete list of changes.
>
>
>       *Tested with: *
>
>   * TCL 8.6.14 and 9.0.2
>   * OpenSSL 1.1.1w, 3.0.18, 3.5.4, and 3.6.0
>   * Windows 7, Windows 10, Msys64, OpenSuSE Linux Leap 15.6 and 16.0,
>     and FreeBSD
>
>
>
>     *Potential Compatibility Issues:*
>
>
>       *Option default changes:*
>
> - The -autoservername option defaults to true if -servername is not specified.
> - The -castore option defaults to "org.openssl.winstore://" on MS Windows with OpenSSL 3.2+ if-cadir, -cadir, and -castore are not specified.
> - The -request option defaults to true for clients.
> - The -require option defaults to true for clients. This may be an issue if the Certificate Authority (CA) certificates are not available.
> - The -servername option defaults to socket host when used with tls::socket. So -autoservername is no longer required.
> - The -ssl2 option is no longer supported by OpenSSL 1.1+.
> - The -ssl3 option doesn't have any effect by default. Use --enable-ssl3 compile time option to enable SSL3 first.
> - The -tls1 and tls1.1 options default to false (not enabled).
> - The -tls1.2 and tls1.3 options default to true (enabled).
>
>
>       *Callback changes:*
>
> - Only status/error message use the -command handler now. There are several new types and the 'verify' type was moved to -validatecommand.
> - Validation of certificates, client values, etc. use the new -validatecommand handler.
> - Password inputs use -password handler, but it now passes 3 arguments.
>
> See the documentation for all compatibility changes.
>
>
>       *Open Issues:*
>
> - May not be compatible with LibreSSL anymore.
> - Warnings for deprecated OpenSSL API usage. Will be fixed in a future release.
> - Some BadSSL test cases may still fail due to platform specific certificate checking defaults.
>
>
>     *Download links:*
>
>
> Source code is available at https://core.tcl-lang.org/tcltls/home in the tls-2.0 branch or in the following release files:
>
>   * https://core.tcl-lang.org/tcltls/uv/tcltls-2.0b2.tar.gz
>   * https://github.com/bohagan1/TclTLS/archive/refs/tags/tls-2.0b2.tar.gz
>
>
> Windows library file link (TCL 8.6 & 9.0 with OpenSSL 3.6.0):
>
>   * https://chiselapp.com/user/bohagan/repository/TCLTLS/uv/tls2.0b2_win64_msvc.zip
>   * https://github.com/bohagan1/TclTLS/releases/download/tls-2.0b2/tls2.0b2_win64_msvc.zip
>
>
> Certificate Authority (CA) certificates:
>
> Please read the documentation "Certificate Validation" section if you don't have OpenSSL or the Certificate Authority (CA) certificates in PEM format installed on your system. If not, they can be obtained from:
> https://core.tcl-lang.org/tcltls/file?name=doc/tls.html&ci=tls-2.0 <https://core.tcl-lang.org/tcltls/file?name=doc/tls.html&ci=tls-2.0>
>
>
>     How to use this release:
>
>
> package prefer latest
> package require tls ?2.0b2?
>
> See the README.txt file for the build steps.
> See the documentation "Examples" section for usage examples.
> More detailed examples can be found in the demos directory.
>
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Update - tka11y/

[Stuart C. <exo...@ya...>]

Really great and important work. Thank you.






On Sunday, October 12, 2025 at 03:54:44 p.m. EDT, Kevin Walzer <kw...@co...> wrote: 





Hi all,

I've received quite a bit of feedback on TIP 733, screen reader support 
for Tk. Thank you. I wanted to provide an update on how I am taking 
action on the input:

1. Language issues / macOS: I have committed a fix that appears to 
address the issue. Please test and let me know if it works.

2. Adding "set" command prefixes to balance out "get" - done.

3. Verbalizing each keypress and prior word in text/entry widgets - In 
process.

4. Wrong error on progress bars - Need to investigate further. The 
intended behavior at this point for active progress bars is simply to 
return "busy" as the value to indicate it is running. If we are getting 
"0.0," does that mean it is inactive?

5. Microsoft Narrator support - Mixed results. Narrator now correctly 
reads button labels. But overall, support for Narrator is proving very 
difficult to implement. After spending months perfecting the Microsoft 
Active Accessibility implementation, which works very well, I do not 
want to have to reinvent the wheel with a full UI Automation 
implementation to support Narrator. After a lot of work, I have settled 
on using the LegacyIAccessible pattern for UIA, which theoretically 
allows MSAA data to drive UIA queries. However, there are significant 
differences in some aspects of the two API's, and the impedance mismatch 
may make it difficult to provide robust support for Narrator. I 
understand that this is the screen reader bundled with Windows, but 
Narrator generally is regarded as inferior to NVDA and JAWS, the two 
major apps in this area. I will keep working on this, but ultimately may 
have to defer perfection in this area to someone who might have more 
expertise with these API's.

6. Crash reports in test suite - on my to-do list once Narrator is 
addressed.

Let me know if you have any questions.

Thanks,

Kevin



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

Re: [TCLCORE] The ongoing dispute over TIP#509

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

On 10/14/2025 11:14 AM, Jan Nijtmans wrote:
> Op di 14 okt 2025 om 11:01 schreef Christian Werner:
>> Lesson learned: you cannot wait in a signal handler, it's that simple.
>>
>> Thank you for your attention to this matter.
>
> YW. Conclusion: TIP #509 didn't fix the deadlock on TclX, but TIP #511
> did. Conclusion 2: You cannot wait in a signal handler. Agreed too.
>
> You didn't answer my question about the "consistent behavior"

The "consistent behaviour" is a quote of the TIP#509 text, so unfortunately not my own invention.
And yes, when we now want to start bean counting, the Win32 CRITICAL_SECTIONS are reentrant but
will of course spectacularly fail when combined with Tcl_Condition. We just could add a prominent
note regarding this fact, and live on like we did the 15+ years before TIP#509, since obviously
nobody cared about consistency at all. Alternatively, could we add code for Win32 to enforce
consistency. But the fine question then must be consequently, how could we survive 15+ years
without big problems in this regard?

Christian

PS: While at bean counting: the path which lead to TIP#509 introduced a deadlock in TclX.
TIP#511 didn't fix it but delivered the right tool for dealing with POSIX signals. And to pour
even more fire accelerant, multi threaded Tcl's Tcl_AsyncHandler infrastructure was entirely
in tatters until the advent of TIP#511.

Re: [TCLCORE] The ongoing dispute over TIP#509

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

Op di 14 okt 2025 om 11:01 schreef Christian Werner:
> Lesson learned: you cannot wait in a signal handler, it's that simple.
>
> Thank you for your attention to this matter.

YW. Conclusion: TIP #509 didn't fix the deadlock on TclX, but TIP #511
did. Conclusion 2: You cannot wait in a signal handler. Agreed too.

You didn't answer my question about the "consistent behavior"

Thanks!
       Jan Nijtmans

Re: [TCLCORE] The ongoing dispute over TIP#509

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

On 10/14/2025 09:28 AM, Jan Nijtmans wrote:

> My interpretation is that using recursive mutexes fixed a rare deadlock in TclX.
> Reverting TIP #509 will bring back this possible deadlock.

Once again, the FlightAware problem was unfixable by using reentrant mutexes
due to only very few system calls being signal safe (and surprise, surprise,
the mutexes neither the normal nor the reentrant ones are part of that set).
Consequently, the above mentioned deadlock (which would be back again) was
a bug in the first place. Bummer!

Then there was a rather long discussion which finally led to TIP#511,
which solved the signal problem without the mutex blues (see the TclX fork
on www.androwish.org regarding the signal subsystem of TclX).

Further reading: https://man7.org/linux/man-pages/man7/signal-safety.7.html

Lesson learned: you cannot wait in a signal handler, it's that simple.

Thank you for your attention to this matter.
Christian

Re: [TCLCORE] The ongoing dispute over TIP#509

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

Op ma 13 okt 2025 om 12:17 schreef Harald Oehlmann:
> A clear warning "breaking backward compatibility of a never working
> feature" would also be great for formal reasons.

Well, the feature worked well, as long as it was not used in combination
with Tcl_Condition's. See here:
     <https://github.com/flightaware/Tcl-bounties/issues/32>
My interpretation is that using recursive mutexes fixed a rare deadlock in TclX.
Reverting TIP #509 will bring back this possible deadlock.

The motivation for TIP #509 was:
      "... enforcing a consistent behavior on all core-supported
platforms regarding reentrancy"
So, accepting this TIP means the "consistent behavior" will be gone:
On Windows using
Tcl_Mutex recursively will appear to work, on UNIX it will give a deadlock.

I think the TIP should mention the relation with this flightaware issue, and
define what "consistent" behavior we expect.

Hope this helps,
       Jan Nijtmans

Re: [TCLCORE] Merge intention for project simplify_test_file_init

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

Op ma 13 okt 2025 om 13:34 schreef Erik Leunissen via Tcl-Core:
> Unless someone raises founded objections in the meantime, I will carry out the
> intended merge on next Friday, or the first opportunity for me thereafter.

No objection from me, on the contrary ....

Thanks!
        Jan Nijtmans

[TCLCORE] 14 October Tcl monthly virtual meetup notice

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

A reminder that the next meetup will be held Tuesday 14 October 2025 at [clock format 1760490000] - Tuesday 6pm US West, 8pm US Central, 9pm US East, Wednesday 1am UTC, 2am UK, 3am Western Europe, 6:30am India, 9am Australia West / Singapore / China, 10am Japan, 12pm Australia East, 2pm New Zealand

Details (including how to connect) are available via https://wiki.tcl-lang.org/page/Monthly+Virtual+Meetup

-- Steve

[TCLCORE] Merge intention for project simplify_test_file_init

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

L.S.

The development branch for the project "simplify_test_file_init" is now ready
for merging into the target branches trunk and core-9-0-branch. [*]

Unless someone raises founded objections in the meantime, I will carry out the
intended merge on next Friday, or the first opportunity for me thereafter.

Regards,
Erik Leunissen.
--
[*] Notes
     -----
     - The previous post in this thread holds a summary of the project's results.

       Please note that the following result in that summary has been modified
       in the meantime:

          • Write error message to stderr and exit when passing options that
            the Tk test suite sets for itself

        Instead, in that situation, a warning is written to stderr and the process
        continues.

     - No comments were received during the stage of final review, either on this
       mailing list or at the project's ticket.
     - Github CI is OK with the changes on the development branch
     - Useful links:
       * the project's ticket:

           https://core.tcl-lang.org/tk/tktview/4f9946f4f3

       * the complete diff w.r.t. trunk:

           https://core.tcl-lang.org/tk/vdiff?branch=simplify_test_file_init

       * the timeline of the development branch:

           https://core.tcl-lang.org/tk/timeline?r=simplify_test_file_init

       * the results of Tk test suite runs on Github CI:

           https://github.com/tclt/tk/actions?query=branch%3Asimplify_test_file_init

Re: [TCLCORE] The ongoing dispute over TIP#509

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

Thanks, TIP is online.
We would need an implementation in the main branch.

A clear warning "breaking backward compatibility of a never working 
feature" would also be great for formal reasons.

Thanks for all,
Harald

Am 13.10.2025 um 11:38 schrieb Christian Werner:
> On 10/13/2025 11:04 AM, Harald Oehlmann wrote:
> 
> Harald,
> 
>> ...
>> I will sponsor with pleasure.
> 
> fine, here we go. Please add this markdown to the TIP repo.
> 
> -----8><-----8><-----
> # TIP 734: Revert TIP 509
>          Author:         Christian Werner <und...@go...>
>          State:
>          Type:           Project
>          Vote:
>          Created:        13-Oct-2025
>          Post-History:
>          Keywords:       Tcl,threads
>          Tcl-Version:    9.1
>          Vote-Results:
>          Votes-For
>          Votes-Against:
>          Votes-Present:
>          Tcl-Branch:
> -----
> 
> # Abstract
> 
> This TIP proposes to revert TIP 509 which introduced reentrant
> mutexes on all core-supported platforms.
> 
> # Context
> 
> The original TIP 509 was invented to improve POSIX signal handling
> in multi-threaded Tcl and later overcome by TIP 511 which solved
> POSIX signal handling without requiring mutex reform.
> 
> # Rationale
> 
> Making all Tcl_Mutexes reentrant interacts bad with Tcl_Conditions
> since in order to successfully (legally) wait on a condition requires
> the associated mutex to be unlocked exactly before the condition
> is waited on and re-locked exactly afterwards. However, a deadlock
> is most likely due when the mutex was (reentrant) locked more than
> once. To overcome this situation additional code would be needed in
> the Tcl_Mutex lock and unlock operations as well as in the wait on
> condition operation to prevent from this potential deadlock situation.
> Effectively, more logic is needed around synchronization operations,
> i.e. it is not possible anymore on the theoretical ideal POSIX platform
> to just wrap the native APIs for the Tcl_Mutex and Tcl_Condition
> synchronization objects.
> 
> Moreover, currently there are zero places in the Tcl core which
> require Tcl_Mutexes to be reentrant, so this feature can be regarded
> as superfluous anyway.
> 
> # Specifications
> 
> This TIP proposes to revert all TIP 509 changes and bring the Tcl_Mutex
> system back to its 8.6 state.
> 
> # Alternatives
> 
> Should there be real demand in having reentrant mutexes in Tcl
> a better alternative would introduce a new type, e.g. Tcl_ReentrantMutex,
> which provides this feature and simultaneously prevents from the
> above mentioned potential deadlocks since it cannot be used for
> conditions.
> 
> # Copyright
> 
> This document has been placed in the public domain.
> -----8><-----8><-----
> 
> Thank you,
> Christian

Re: [TCLCORE] The ongoing dispute over TIP#509

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

On 10/13/2025 11:04 AM, Harald Oehlmann wrote:

Harald,

> ...
> I will sponsor with pleasure.

fine, here we go. Please add this markdown to the TIP repo.

-----8><-----8><-----
# TIP 734: Revert TIP 509
         Author:         Christian Werner <und...@go...>
         State:
         Type:           Project
         Vote:
         Created:        13-Oct-2025
         Post-History:
         Keywords:       Tcl,threads
         Tcl-Version:    9.1
         Vote-Results:
         Votes-For
         Votes-Against:
         Votes-Present:
         Tcl-Branch:
-----

# Abstract

This TIP proposes to revert TIP 509 which introduced reentrant
mutexes on all core-supported platforms.

# Context

The original TIP 509 was invented to improve POSIX signal handling
in multi-threaded Tcl and later overcome by TIP 511 which solved
POSIX signal handling without requiring mutex reform.

# Rationale

Making all Tcl_Mutexes reentrant interacts bad with Tcl_Conditions
since in order to successfully (legally) wait on a condition requires
the associated mutex to be unlocked exactly before the condition
is waited on and re-locked exactly afterwards. However, a deadlock
is most likely due when the mutex was (reentrant) locked more than
once. To overcome this situation additional code would be needed in
the Tcl_Mutex lock and unlock operations as well as in the wait on
condition operation to prevent from this potential deadlock situation.
Effectively, more logic is needed around synchronization operations,
i.e. it is not possible anymore on the theoretical ideal POSIX platform
to just wrap the native APIs for the Tcl_Mutex and Tcl_Condition
synchronization objects.

Moreover, currently there are zero places in the Tcl core which
require Tcl_Mutexes to be reentrant, so this feature can be regarded
as superfluous anyway.

# Specifications

This TIP proposes to revert all TIP 509 changes and bring the Tcl_Mutex
system back to its 8.6 state.

# Alternatives

Should there be real demand in having reentrant mutexes in Tcl
a better alternative would introduce a new type, e.g. Tcl_ReentrantMutex,
which provides this feature and simultaneously prevents from the
above mentioned potential deadlocks since it cannot be used for
conditions.

# Copyright

This document has been placed in the public domain.
-----8><-----8><-----

Thank you,
Christian

Re: [TCLCORE] The ongoing dispute over TIP#509

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

Am 13.10.2025 um 10:44 schrieb Christian Werner:
> On 10/13/2025 09:19 AM, Harald Oehlmann wrote:
>> Am 12.10.2025 um 22:51 schrieb Christian Werner:
> 
> Harald, all,
> 
>>> would you please like to follow the debate on https://core.tcl- 
>>> lang.org/ tcl/tktview/893f8cc5db3ba8bd6bed80ce89a0a75c6088a37c
>>> and explain to me please, if it is possible to revert an already 
>>> positively voted TIP due to technical needlessness instead
>>> of due pure existence to try to force things to work like this TIP 
>>> mandates?
>>
>> On the formal side, a TIP may be reverted by another TIP.
> 
> So far so good. What are the opinions then on the necessity (not) of 
> TIP#509?
> Is there anyone willing to sponsor the respective counter tip?
> 
> Christian

Christian,
thank you for your insistence, to clean-up points. That is great and 
highly appreciated.
I will sponsor with pleasure.

Take care,
Harald

Re: [TCLCORE] The ongoing dispute over TIP#509

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

On 10/13/2025 09:19 AM, Harald Oehlmann wrote:
> Am 12.10.2025 um 22:51 schrieb Christian Werner:

Harald, all,

>> would you please like to follow the debate on https://core.tcl-lang.org/ tcl/tktview/893f8cc5db3ba8bd6bed80ce89a0a75c6088a37c
>> and explain to me please, if it is possible to revert an already positively voted TIP due to technical needlessness instead
>> of due pure existence to try to force things to work like this TIP mandates?
>
> On the formal side, a TIP may be reverted by another TIP.

So far so good. What are the opinions then on the necessity (not) of TIP#509?
Is there anyone willing to sponsor the respective counter tip?

Christian

Re: [TCLCORE] The ongoing dispute over TIP#509

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

Am 12.10.2025 um 22:51 schrieb Christian Werner:
> Hello TCT,
> 
> would you please like to follow the debate on https://core.tcl-lang.org/ 
> tcl/tktview/893f8cc5db3ba8bd6bed80ce89a0a75c6088a37c
> and explain to me please, if it is possible to revert an already 
> positively voted TIP due to technical needlessness instead
> of due pure existence to try to force things to work like this TIP 
> mandates?

On the formal side, a TIP may be reverted by another TIP.
Harald

[TCLCORE] ANNOUNCE: TclTLS 2.0b2 Release

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

Brian did post this epic message on clt newsgroup.
Please allow me to forward it to the core list.
Harald
---
This is the beta 2 release of the TclTLS v2.0 package. There have been 
numerous bug fixes since the beta 1 release. The plan is to do the final 
release in a week, so please test and file any bug reports at the below 
sites. See below for links to the files and the release notes. Thanks.


     TclTLS 2.0 Release Notes:


       *Notable New Features:*

- Fully TEA compliant build system has been added back. Supports 
Windows, Linux, Mac, BSD, etc.
- Compatible with OpenSSL 3.0+ and TCL 9.0 including build-info command.
- Can use MS Windows Certificate Store on OpenSSL 3.2 or later.
- Greatly expanded the status returned by the tls::status command and 
also added the new tls::connection command. The former returns SSL and 
certificate status while the latter returns the SSL status, cipher, and 
session info.
- Added missing TLS 1.3 functionality, set cipher suites, ALPN, SNI, 
security level, etc.
- Error handing improvements, more specific error status, more 
connection status via callbacks.
- Replaced separate Diffie-Hellman (DH) header file build process with 
auto select.
- Add new tls::protocols command to list available SSL and TLS protocols.
- Now can load CA certificates, key files, etc. from virtual file 
systems (VFS).

See https://chiselapp.com/user/bohagan/repository/TCLTLS/home for more info.


       *Documentation Updates:*

- Documentation was extensively updated and converted to man page and 
HTML format.
- Updated the examples in the documentation and added an examples directory.
- Expanded the documentation and added a Certificate Validation section 
with info on how PKI and certificates work and the related TclTLS args.
- Extensive code documentation updates.


       *Notable Bug Fixes:*

(Some of these issues have been around for 15-20 years.)
- Many bugs, patches, etc. submitted to sourceforge.net and core.tcl.tk 
have been fixed or implemented.
- Unexpected EOF: Added fix to correct OpenSSL issue where some sessions 
can result in an unexpected EOF.
- Empty reads: These have been eliminated the extent possible, but may 
still occur. See demos for how to handle this.
- Lock-ups and Stalling connections: These have been fixed to the extent 
possible with a more robust event checking process.
- Manual certificate validation is no longer needed. OpenSSL will do 
this for you if -require 1 is specified. You can see results via 
-validatecommand callback and in tls::status verifyResult.
- Will only call bgerror if the -command, -password, or -validatecommand 
callbacks throw an error.
- Will send proper close_notify message to peer on channel closure.

See the documentation for a complete list of changes.


       *Tested with: *

   * TCL 8.6.14 and 9.0.2
   * OpenSSL 1.1.1w, 3.0.18, 3.5.4, and 3.6.0
   * Windows 7, Windows 10, Msys64, OpenSuSE Linux Leap 15.6 and 16.0,
     and FreeBSD



     *Potential Compatibility Issues:*


       *Option default changes:*

- The -autoservername option defaults to true if -servername is not 
specified.
- The -castore option defaults to "org.openssl.winstore://" on MS 
Windows with OpenSSL 3.2+ if-cadir, -cadir, and -castore are not specified.
- The -request option defaults to true for clients.
- The -require option defaults to true for clients. This may be an issue 
if the Certificate Authority (CA) certificates are not available.
- The -servername option defaults to socket host when used with 
tls::socket. So -autoservername is no longer required.
- The -ssl2 option is no longer supported by OpenSSL 1.1+.
- The -ssl3 option doesn't have any effect by default. Use --enable-ssl3 
compile time option to enable SSL3 first.
- The -tls1 and tls1.1 options default to false (not enabled).
- The -tls1.2 and tls1.3 options default to true (enabled).


       *Callback changes:*

- Only status/error message use the -command handler now. There are 
several new types and the 'verify' type was moved to -validatecommand.
- Validation of certificates, client values, etc. use the new 
-validatecommand handler.
- Password inputs use -password handler, but it now passes 3 arguments.

See the documentation for all compatibility changes.


       *Open Issues:*

- May not be compatible with LibreSSL anymore.
- Warnings for deprecated OpenSSL API usage. Will be fixed in a future 
release.
- Some BadSSL test cases may still fail due to platform specific 
certificate checking defaults.


     *Download links:*


Source code is available at https://core.tcl-lang.org/tcltls/home in the 
tls-2.0 branch or in the following release files:

   * https://core.tcl-lang.org/tcltls/uv/tcltls-2.0b2.tar.gz
   * https://github.com/bohagan1/TclTLS/archive/refs/tags/tls-2.0b2.tar.gz


Windows library file link (TCL 8.6 & 9.0 with OpenSSL 3.6.0):

   * 
https://chiselapp.com/user/bohagan/repository/TCLTLS/uv/tls2.0b2_win64_msvc.zip
   * 
https://github.com/bohagan1/TclTLS/releases/download/tls-2.0b2/tls2.0b2_win64_msvc.zip


Certificate Authority (CA) certificates:

Please read the documentation "Certificate Validation" section if you 
don't have OpenSSL or the Certificate Authority (CA) certificates in PEM 
format installed on your system. If not, they can be obtained from:
https://core.tcl-lang.org/tcltls/file?name=doc/tls.html&ci=tls-2.0 
<https://core.tcl-lang.org/tcltls/file?name=doc/tls.html&ci=tls-2.0>


     How to use this release:


package prefer latest
package require tls ?2.0b2?

See the README.txt file for the build steps.
See the documentation "Examples" section for usage examples.
More detailed examples can be found in the demos directory.

Re: [TCLCORE] The ongoing dispute over TIP#509

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

On 10/12/2025 10:51 PM, Christian Werner wrote:

> would you please like to follow the debate on https://core.tcl-lang.org/tcl/tktview/893f8cc5db3ba8bd6bed80ce89a0a75c6088a37c
> and explain to me please, if it is possible to revert an already positively voted TIP due to technical needlessness instead
> of due pure existence to try to force things to work like this TIP mandates?
> …

Recently while dealing with a "send" alternative, Marc Culler brought up another newer feature of the POSIX signal magic,

   pthread_sigqueue(3)

which allows real time signal information to be passed. This would indeed require to revise TIP 511 to have another public
function going further than Tcl_AsyncMarkFromSignal()  to deal with the "const union sigval" element of this pthread function.

Thank you for your attention to this matter,
Christian

[TCLCORE] The ongoing dispute over TIP#509

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

Hello TCT,

would you please like to follow the debate on https://core.tcl-lang.org/tcl/tktview/893f8cc5db3ba8bd6bed80ce89a0a75c6088a37c
and explain to me please, if it is possible to revert an already positively voted TIP due to technical needlessness instead
of due pure existence to try to force things to work like this TIP mandates?

Thank you for your attention to this matter,
Christian

PS: This TIP became in most of its own rationale obsolete by TIP 511.