tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Tcl/Tk 8.6.18 Release Candidates

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

I've fixed the exec-bug-4f0b5767ac test (test itself, not any Tcl code) in core-8-6-branch. The gcc failure was not having the LocalApps/Microsoft... directory in PATH under msys. The MSVC failure was due to assuming output was English. failure is benign and in the test case, not Tcl itself so picking up the change is optional.

Cannot reproduce the fCmd-9.5,9.7 failures but IMO any tests that use testchmod on Windows in *8.6* are flaky. They depend on the directory where they are run and inherited permissions.

-----Original Message-----
From: Paul Obermeier <pa...@po...> 
Sent: Saturday, May 2, 2026 2:55 AM
To: tcl...@li...
Subject: Re: [TCLCORE] Tcl/Tk 8.6.18 Release Candidates

Here are my test results using Tcl/Tk 8.6.18rc0:

Operating system    Arch.    Compiler Tcl-errors Tk-errors
---------------------------------------------------------------
MacOS 15.7.5        M2       clang 17.0.0    0          0
Suse 15.6           x86_64   gcc 7.5.0       0          64
Raspberry Pi OS     arm64    gcc 12.2.0      0          56
Windows 11          x86      gcc 14.2.0      6          0
Windows 11          x86_64   gcc 14.2.0      6          0
Windows 11          x86_64   VS2022          6          0

The usual 3 Windows failures:
==== fCmd-9.3 file rename: comprehensive: file to new name FAILED
==== fCmd-9.10 file rename: comprehensive: file to new name and dir FAILED
==== winFCmd-3.10 TclpDeleteFile: path is readonly FAILED

Additional Windows errors:
==== fCmd-9.5 file rename: comprehensive: file to self FAILED
==== fCmd-9.7 file rename: comprehensive: file to existing file FAILED

Windows error using gcc:
==== exec-bug-4f0b5767ac exec App Execution Alias FAILED
     errorInfo: couldn't execute "winget": no such file or directory
Windows error using VS:
==== exec-bug-4f0b5767ac exec App Execution Alias FAILED
     Language dependent error. Should be solved like in Tcl9: Compare result against "Windows*" only.

The usual multiple Tk failures on Linux.


Warnings during compilation:

Windows 64-bit (VS2017 VS2019 VS2022):

Tcl\pkgs\tdbcodbc1.1.13\win\..\generic\tdbcodbc.c(899): warning C4267: '=': conversion from 'size_t' to 'Tcl_Size', possible loss of data
Tcl\pkgs\tdbcodbc1.1.13\win\..\generic\tdbcodbc.c(4016): warning C4267: '=': conversion from 'size_t' to 'Tcl_Size', possible loss of data
Tcl\pkgs\tdbcodbc1.1.13\win\..\generic\tdbcodbc.c(4710): warning C4267: 'function': conversion from 'size_t' to 'Tcl_Size', possible loss of data

macOS 15.7.5 (using -mmacosx-version-min=11.0):

Tcl:

In file included from ./generic/tclsqlite3.c:4:
./generic/../compat/sqlite3/sqlite3.c:32679:13: warning: 'strchrnul' is only available on macOS 15.4 or newer [-Wunguarded-availability-new]
  32679 |       fmt = strchrnul(fmt, '%');

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_string.h:198:9: note: 'strchrnul' has been marked as being introduced in macOS 15.4 here, but the deployment target is macOS 11.0.0
   198 |         strchrnul(const char *__s, int __c);

./generic/../compat/sqlite3/sqlite3.c:32679:13: note: enclose 'strchrnul' in a __builtin_available check to silence this warning
  32679 |       fmt = strchrnul(fmt, '%');

Tcl/unix/tclLoadDyld.c:106:1: warning: unused function 'DyldOFIErrorMsg' [-Wunused-function]
   106 | DyldOFIErrorMsg(

ld: warning: -single_module is obsolete
ld: warning: ignoring duplicate libraries: '-ltdbcstub1.1.13'

Tk:

Tk/unix/../macosx/tkMacOSXDraw.c:1159:8: warning: 'scrollRect:by:' is deprecated: first deprecated in macOS 10.14 - Use NSScrollView to achieve scrolling views. [-Wdeprecated-declarations]
  1159 |         [view scrollRect:viewSrcRect by:NSMakeSize(dx, -dy)];

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSView.h:217:1: note: 'scrollRect:by:' has been explicitly marked deprecated here
   217 | - (void)scrollRect:(NSRect)rect by:(NSSize)delta API_DEPRECATED("Use NSScrollView to achieve scrolling views.", macos(10.0,10.14));

ld: warning: -single_module is obsolete
ld: warning: ignoring duplicate libraries: '-lpthread'

Regards,
Paul

Am 30.04.2026 um 20:32 schrieb Donald G Porter via Tcl-Core:
>
> Now available at
>
> https://sourceforge.net/projects/tcl/files/Tcl/8.6.18/
>
> are RC0 candidate source code distribution pre-releases of Tcl and Tk 8.6.18.
>
> These are the first candidate releases leading to the release of Tcl/Tk 8.6.18.
> The target date for release is May 11, 2026.
>
> The Tcl pre-release includes a pre-release of the package Thread 2.8.13,
> The released packages Itcl 4.3.7, TDBC* 1.1.13, and sqlite3 3.53.0 are also included.
>
> Please test these candidates on your platforms and report any blocking issues
> you discover.
>
> Thank you for your contributions and assistance.
>



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

Re: [TCLCORE] Tcl/Tk 8.6.18 Release Candidates

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

Here are my test results using Tcl/Tk 8.6.18rc0:

Operating system    Arch.    Compiler Tcl-errors Tk-errors
---------------------------------------------------------------
MacOS 15.7.5        M2       clang 17.0.0    0          0
Suse 15.6           x86_64   gcc 7.5.0       0          64
Raspberry Pi OS     arm64    gcc 12.2.0      0          56
Windows 11          x86      gcc 14.2.0      6          0
Windows 11          x86_64   gcc 14.2.0      6          0
Windows 11          x86_64   VS2022          6          0

The usual 3 Windows failures:
==== fCmd-9.3 file rename: comprehensive: file to new name FAILED
==== fCmd-9.10 file rename: comprehensive: file to new name and dir FAILED
==== winFCmd-3.10 TclpDeleteFile: path is readonly FAILED

Additional Windows errors:
==== fCmd-9.5 file rename: comprehensive: file to self FAILED
==== fCmd-9.7 file rename: comprehensive: file to existing file FAILED

Windows error using gcc:
==== exec-bug-4f0b5767ac exec App Execution Alias FAILED
     errorInfo: couldn't execute "winget": no such file or directory
Windows error using VS:
==== exec-bug-4f0b5767ac exec App Execution Alias FAILED
     Language dependent error. Should be solved like in Tcl9: Compare result against "Windows*" only.

The usual multiple Tk failures on Linux.


Warnings during compilation:

Windows 64-bit (VS2017 VS2019 VS2022):

Tcl\pkgs\tdbcodbc1.1.13\win\..\generic\tdbcodbc.c(899): warning C4267: '=': conversion from 'size_t' to 'Tcl_Size', possible loss of data
Tcl\pkgs\tdbcodbc1.1.13\win\..\generic\tdbcodbc.c(4016): warning C4267: '=': conversion from 'size_t' to 'Tcl_Size', possible loss of data
Tcl\pkgs\tdbcodbc1.1.13\win\..\generic\tdbcodbc.c(4710): warning C4267: 'function': conversion from 'size_t' to 'Tcl_Size', possible loss of data

macOS 15.7.5 (using -mmacosx-version-min=11.0):

Tcl:

In file included from ./generic/tclsqlite3.c:4:
./generic/../compat/sqlite3/sqlite3.c:32679:13: warning: 'strchrnul' is only available on macOS 15.4 or newer [-Wunguarded-availability-new]
  32679 |       fmt = strchrnul(fmt, '%');

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_string.h:198:9: note: 'strchrnul' has been marked as being introduced in macOS 15.4 here, but the deployment target is macOS 11.0.0
   198 |         strchrnul(const char *__s, int __c);

./generic/../compat/sqlite3/sqlite3.c:32679:13: note: enclose 'strchrnul' in a __builtin_available check to silence this warning
  32679 |       fmt = strchrnul(fmt, '%');

Tcl/unix/tclLoadDyld.c:106:1: warning: unused function 'DyldOFIErrorMsg' [-Wunused-function]
   106 | DyldOFIErrorMsg(

ld: warning: -single_module is obsolete
ld: warning: ignoring duplicate libraries: '-ltdbcstub1.1.13'

Tk:

Tk/unix/../macosx/tkMacOSXDraw.c:1159:8: warning: 'scrollRect:by:' is deprecated: first deprecated in macOS 10.14 - Use NSScrollView to achieve scrolling views. [-Wdeprecated-declarations]
  1159 |         [view scrollRect:viewSrcRect by:NSMakeSize(dx, -dy)];

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSView.h:217:1: note: 'scrollRect:by:' has been explicitly marked deprecated here
   217 | - (void)scrollRect:(NSRect)rect by:(NSSize)delta API_DEPRECATED("Use NSScrollView to achieve scrolling views.", macos(10.0,10.14));

ld: warning: -single_module is obsolete
ld: warning: ignoring duplicate libraries: '-lpthread'

Regards,
Paul

Am 30.04.2026 um 20:32 schrieb Donald G Porter via Tcl-Core:
>
> Now available at
>
> https://sourceforge.net/projects/tcl/files/Tcl/8.6.18/
>
> are RC0 candidate source code distribution pre-releases of Tcl and Tk 8.6.18.
>
> These are the first candidate releases leading to the release of Tcl/Tk 8.6.18.
> The target date for release is May 11, 2026.
>
> The Tcl pre-release includes a pre-release of the package Thread 2.8.13,
> The released packages Itcl 4.3.7, TDBC* 1.1.13, and sqlite3 3.53.0 are also included.
>
> Please test these candidates on your platforms and report any blocking issues
> you discover.
>
> Thank you for your contributions and assistance.
>

[TCLCORE] Bug Fix: ttkImage.c performance degradation on Windows

[Mason M. <ma...@ba...>]

Tcl Core Members,

I am submitting a patch—only impacting generic/ttk/ttkImage.c—for a performance issue when rendering on Windows. I tested using Tcl/Tk 9.0.3.

*Summary*

Custom Ttk scrollbar elements created with ttk::style element create ... image
exhibit severe performance degradation on Windows due to per-tile GDI object
creation/destruction in the image rendering pipeline.

This can be seen when resizing any Tk window using a custom theme which sets the scrollbar image elements. For example, to reproduce before and after applying the enclosed patch, the test_scrollbar_perf.tcl may be used (see attached).

*The Fix*

Add a per-element rendered-pixmap cache to ImageElementDraw so that repeated
draws at the same (width, height, state) blit a single pre-composed bitmap
instead of tiling via hundreds of individual Tk_RedrawImage calls. Also fix
the off-by-one in the Ttk_Fill tiling loop (to eliminate wasted zero-height
Tk_RedrawImage calls).


Please let me know if more information is required or if there are further steps to help get this fix into core.

Thanks,
Mason


Disclaimer: root-cause analysis and subsequent fix were created with the help of Claude Opus 4.6.

Re: [TCLCORE] Tcl/Tk 8.6.18 Release Candidates

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

For which platforms do we require building with C90 to work?

I thought the requirement to put all declarations at the top of a block had
disappeared decades ago.  The current code base has lots of declarations in
the middle of a block (for the obvious reason that it improves readability
and is much more convenient).

- Marc

On Fri, May 1, 2026 at 11:35 AM Jan Nijtmans <jan...@gm...> wrote:

> Op do 30 apr 2026 om 20:48 schreef Donald G Porter via Tcl-Core <
> tcl...@li...>:
>
>>
>> Please test these candidates on your platforms and report any blocking
>> issues
>> you discover.
>>
>
> Unfortunately:
>     tclNamesp.c: In function ‘TclEnsureNamespace’:
>     tclNamesp.c:2397:5: warning: ISO C90 forbids mixed declarations and
> code [-Wdeclaration-after-statement]
>      2397 |     Tcl_Namespace *nsPtr2 = Tcl_FindNamespace(interp,
> nsPtr->fullName, NULL, 0);
>           |     ^~~~~~~~~~~~~
>
> Introduced by this commit:
>     <Tcl Source Code: Check-in [24c2db3ce5]
> <https://core.tcl-lang.org/tcl/info/24c2db3ce5cb9552>>
>
> In Tk as well:
>     ttkWinXPTheme.c: In function ‘TabElementDraw’:
>     ttkWinXPTheme.c:831:5: warning: ISO C90 forbids mixed declarations and
> code [-Wdeclaration-after-statement]
>       831 |     RECT rc = BoxToRect(b);
>           |     ^~~~
> Introduced by this commit:
>     <Tk Source Code: Check-in [d64f145a]
> <https://core.tcl-lang.org/tk/info/d64f145af19d5b00>>
>
> Fixed now in core-8-6-branch (for both Tcl and Tk). That's all
>
> Regards,
>      Jan Nijtmans
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Tcl/Tk 8.6.18 Release Candidates

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

Op do 30 apr 2026 om 20:48 schreef Donald G Porter via Tcl-Core <
tcl...@li...>:

>
> Please test these candidates on your platforms and report any blocking
> issues
> you discover.
>

Unfortunately:
    tclNamesp.c: In function ‘TclEnsureNamespace’:
    tclNamesp.c:2397:5: warning: ISO C90 forbids mixed declarations and
code [-Wdeclaration-after-statement]
     2397 |     Tcl_Namespace *nsPtr2 = Tcl_FindNamespace(interp,
nsPtr->fullName, NULL, 0);
          |     ^~~~~~~~~~~~~

Introduced by this commit:
    <Tcl Source Code: Check-in [24c2db3ce5]
<https://core.tcl-lang.org/tcl/info/24c2db3ce5cb9552>>

In Tk as well:
    ttkWinXPTheme.c: In function ‘TabElementDraw’:
    ttkWinXPTheme.c:831:5: warning: ISO C90 forbids mixed declarations and
code [-Wdeclaration-after-statement]
      831 |     RECT rc = BoxToRect(b);
          |     ^~~~
Introduced by this commit:
    <Tk Source Code: Check-in [d64f145a]
<https://core.tcl-lang.org/tk/info/d64f145af19d5b00>>

Fixed now in core-8-6-branch (for both Tcl and Tk). That's all

Regards,
     Jan Nijtmans

Re: [TCLCORE] Bidi text

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

Hi Benny,

Thank you again for the feedback. 

As I mentioned previously, what you are asking for is not in scope at the moment and will not be implemented at this time. The current objective is to bring Tk in line with Mousepad, not Emacs. It’s been a LOT of work just to reach this modest milestone. 

If you want, please open a ticket with a list of requested future enhancements. I would love to revisit this in the future, after the Wayland port is done. 

-Kevin
—
Kevin Walzer kw...@co...

> On May 1, 2026, at 6:05 AM, Benjamin Riefenstahl <b.r...@tu...> wrote:
> 
> HI Kevin,
> 
>> Kevin Walzer writes:
>>> Correct word wrap, RTL cursor movement, [...] are out of scope.
> 
> Benjamin Riefenstahl writes:
>> Those are serious limitations.  I consider these aspects essential.
> 
> That is, essential for writing.  The code can probably already be used
> fine for read-only display, like browsing pre-existing texts or for a
> newsreader.  OTOH, the placement of the cursor with the mouse would
> still be important to implement, so that marking for copy-and-paste
> works.
> 
>> * Composition with Hebrew combining marks does not work.  (I haven't
>> tested Latin combining characters yet.)
> 
> This seems to be a font selection issue.  When I explicitly select the
> font that Emacs uses for the text, than it works.  The default font
> selection was probably selecting different fonts for base and combining
> characters.  So this is a separate problem.
> 
>> * RTL lines are not left-aligned automatically.
> 
> This is probably a feature for the text widget to implement.
> 
> I have a new one:
> 
> * The cursor does not seem to be where it appears to be.  Movement is
> irregular and when I press Space, it gets inserted somewhere on the
> other side of the line.  And here I was wondering how you managed to get
> the cursor going in the correct direction ;-) (This is a rather gnarly
> problem, I think).  If the cursor position is measured from the left
> widget border, when the text actually starts from the right side, that
> explains the way it looks and behaves.
> 
> benny

Re: [TCLCORE] Bidi text

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

Thank you! I will work on the test failures in the coming days. 
—
Kevin Walzer kw...@co...

> On May 1, 2026, at 7:05 AM, Jan Nijtmans <jan...@gm...> wrote:
> 
> Op vr 1 mei 2026 om 12:40 schreef Kevin Walzer:
>> Jan,
>> 
>> I've reviewed the test suite failures on GH. I can address the actual test suite issues, and can also address the build failure for "--disable-aqua." "linux-with-tcl9-build.yml" and "linux - build binaries" appear to be failing because harfbuzz isn't found. Because this branch makes harfbuzz the default mode, build failure because harfbuzz isn't found is the correct outcome, and I am not sure how to address this. Please advise. 
>> 
> 
> With pleasure!   I think this should help:
>      <https://core.tcl-lang.org/tk/info/cbc9f5cdfd11dcb6>
>  
> Still work to do for the other testcase failures :-(
> 
> I hope the bidi changes will be good enough soon to be included in the
> 9.1 release. Keep up the good work!
> 
> Regards,
>       Jan Nijtmans

Re: [TCLCORE] Bidi text

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

Op vr 1 mei 2026 om 12:40 schreef Kevin Walzer:

> Jan,
>
> I've reviewed the test suite failures on GH. I can address the actual test
> suite issues, and can also address the build failure for
> "--disable-aqua." "linux-with-tcl9-build.yml" and "linux - build binaries"
> appear to be failing because harfbuzz isn't found. Because this branch
> makes harfbuzz the default mode, build failure because harfbuzz isn't found
> is the correct outcome, and I am not sure how to address this. Please
> advise.
>

With pleasure!   I think this should help:
     <https://core.tcl-lang.org/tk/info/cbc9f5cdfd11dcb6>

Still work to do for the other testcase failures :-(

I hope the bidi changes will be good enough soon to be included in the
9.1 release. Keep up the good work!

Regards,
      Jan Nijtmans

Re: [TCLCORE] Bidi text

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

Jan,

I've reviewed the test suite failures on GH. I can address the actual 
test suite issues, and can also address the build failure for 
"--disable-aqua." "linux-with-tcl9-build.yml" and "linux - build 
binaries" appear to be failing because harfbuzz isn't found. Because 
this branch makes harfbuzz the default mode, build failure because 
harfbuzz isn't found is the correct outcome, and I am not sure how to 
address this. Please advise.

-Kevin

On 4/30/26 3:30 PM, Kevin Walzer wrote:
> I ran the test suite against rtl_text and trunk on my machine and 
> here's what I see:
>
> rtl_text:
> Files with failing tests: event.test focus.test pack.test place.test 
> send.test unixEmbed.test unixWm.test winfo.test wm.test
>
> Trunk:
> Files with failing tests: focus.test pack.test place.test send.test 
> unixEmbed.test unixWm.test winfo.test wm.test
>
> Same failures on both, all pertaining to Wayland restrictions, except 
> for one: event.test also fails on X11.  These tests pertain to events 
> in the text widget, which makes sense. Clearly I'll need to review 
> them in regards to X11, and possibly Windows and macOS  as well - 
> let's see what the Github test runner shows.
>
> No merging will happen until the test suite is clean.
>
> - Kevin
> --
> Kevin Walzer kw...@co...
>
> On Thu, Apr 30 2026 at 10:56:03 AM -04:00:00, Kevin Walzer 
> <kw...@co...> wrote:
>> I am developing on Debian Trixie with Gnome, which has Wayland. 
>>  Running the test suite in the normal DE generates a TON of wm errors 
>> because Wayland doesn’t let Tk do things that X11 does. Most of those 
>> errors are Wayland noise unrelated to any changes I am making. 
>>  Running under xvfb gives a more accurate assessment of the test 
>> suite. I’ve fixed all the text widget failures we were seeing. I will 
>> review again when I am able.
>> —
>> Kevin Walzer kw...@co...
>>
>>> On Apr 30, 2026, at 10:44 AM, Jan Nijtmans <jan...@gm...> 
>>> wrote:
>>>
>>> 
>>> Op do 30 apr 2026 om 16:36 schreef Kevin Walzer <kw...@co...>:
>>>
>>>     Jan,
>>>
>>>     The rtl_text branch has not been tested on Github. Where are you
>>>     seeing these failures?
>>>
>>>
>>> Just running on Ubuntu 26-04 LTS locally.
>>>
>>> Hope this helps,
>>>      Jan Nijtmans
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

-- 
Kevin Wal...@co...

Re: [TCLCORE] Bidi text

[Benjamin R. <b.r...@tu...>]

HI Kevin,

> Kevin Walzer writes:
>> Correct word wrap, RTL cursor movement, [...] are out of scope.

Benjamin Riefenstahl writes:
> Those are serious limitations.  I consider these aspects essential.

That is, essential for writing.  The code can probably already be used
fine for read-only display, like browsing pre-existing texts or for a
newsreader.  OTOH, the placement of the cursor with the mouse would
still be important to implement, so that marking for copy-and-paste
works.

> * Composition with Hebrew combining marks does not work.  (I haven't
> tested Latin combining characters yet.)

This seems to be a font selection issue.  When I explicitly select the
font that Emacs uses for the text, than it works.  The default font
selection was probably selecting different fonts for base and combining
characters.  So this is a separate problem.

> * RTL lines are not left-aligned automatically.

This is probably a feature for the text widget to implement.

I have a new one:

* The cursor does not seem to be where it appears to be.  Movement is
irregular and when I press Space, it gets inserted somewhere on the
other side of the line.  And here I was wondering how you managed to get
the cursor going in the correct direction ;-) (This is a rather gnarly
problem, I think).  If the cursor position is measured from the left
widget border, when the text actually starts from the right side, that
explains the way it looks and behaves.

benny

Re: [TCLCORE] Bidi text

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

I ran the test suite against rtl_text and trunk on my machine and 
here's what I see:

rtl_text:
Files with failing tests: event.test focus.test pack.test place.test 
send.test unixEmbed.test unixWm.test winfo.test wm.test

Trunk:
Files with failing tests: focus.test pack.test place.test send.test 
unixEmbed.test unixWm.test winfo.test wm.test

Same failures on both, all pertaining to Wayland restrictions, except 
for one: event.test also fails on X11.  These tests pertain to events 
in the text widget, which makes sense. Clearly I'll need to review them 
in regards to X11, and possibly Windows and macOS  as well - let's see 
what the Github test runner shows.

No merging will happen until the test suite is clean.

- Kevin
--
Kevin Walzer kw...@co...

On Thu, Apr 30 2026 at 10:56:03 AM -04:00:00, Kevin Walzer 
<kw...@co...> wrote:
> I am developing on Debian Trixie with Gnome, which has Wayland.  
> Running the test suite in the normal DE generates a TON of wm errors 
> because Wayland doesn’t let Tk do things that X11 does. Most of 
> those errors are Wayland noise unrelated to any changes I am making.  
> Running under xvfb gives a more accurate assessment of the test 
> suite. I’ve fixed all the text widget failures we were seeing. I 
> will review again when I am able.
> —
> Kevin Walzer kw...@co...
> 
>> On Apr 30, 2026, at 10:44 AM, Jan Nijtmans 
>> <jan...@gm...> wrote:
>> 
>> 
>> Op do 30 apr 2026 om 16:36 schreef Kevin Walzer <kw...@co... 
>> <mailto:kw...@co...>>:
>>> Jan,
>>> 
>>> The rtl_text branch has not been tested on Github. Where are you 
>>> seeing these failures?
>> 
>> Just running on Ubuntu 26-04 LTS locally.
>> 
>> Hope this helps,
>>      Jan Nijtmans

[TCLCORE] Tcl/Tk 8.6.18 Release Candidates

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

Now available at

https://sourceforge.net/projects/tcl/files/Tcl/8.6.18/

are RC0 candidate source code distribution pre-releases of Tcl and Tk 8.6.18.

These are the first candidate releases leading to the release of Tcl/Tk 8.6.18.
The target date for release is May 11, 2026.

The Tcl pre-release includes a pre-release of the package Thread 2.8.13,
The released packages Itcl 4.3.7, TDBC* 1.1.13, and sqlite3 3.53.0 are also included.

Please test these candidates on your platforms and report any blocking issues
you discover.

Thank you for your contributions and assistance.

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

Re: [TCLCORE] Bidi text

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

<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">I am developing on Debian Trixie with Gnome, which has Wayland. &nbsp;Running the test suite in the normal DE generates a TON of wm errors because Wayland doesn’t let Tk do things that X11 does. Most of those errors are Wayland noise unrelated to any changes I am making. &nbsp;Running under xvfb gives a more accurate assessment of the test suite. I’ve fixed all the text widget failures we were seeing. I will review again when I am able.&nbsp;<br id="lineBreakAtBeginningOfSignature"><div dir="ltr"><div>—</div>Kevin Walzer kw...@co...</div><div dir="ltr"><br><blockquote type="cite">On Apr 30, 2026, at 10:44 AM, Jan Nijtmans &lt;jan...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">Op do 30 apr 2026 om 16:36 schreef Kevin Walzer &lt;<a href="mailto:kw...@co...">kw...@co...</a>&gt;:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Jan,<div><br></div><div>The rtl_text branch has not been tested on Github. Where are you seeing these failures?</div></div></blockquote><div><br></div><div>Just running on Ubuntu 26-04 LTS locally.</div><div><br></div><div>Hope this helps,</div><div>&nbsp; &nbsp; &nbsp;Jan Nijtmans</div></div></div>
</div></blockquote></body></html>

Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

[da S. P. J <pet...@fl...>]

I want to say that I don't remember when chan was introduced but I was very happy to discover it when I learned about it.

From: Massimo Manghi <mas...@ri...>
Date: Thursday, April 30, 2026 at 04:05
To: Steve Landers <st...@di...>; 'Donal Fellows' <don...@ma...>; 'Tcl Core' <tcl...@li...>; apn...@ya... <apn...@ya...>
Subject: Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

CAUTION - EXTERNAL EMAIL:
This message originated from outside of your organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


My (less than) 2 cents

I do not remember exactly when the `chan` command was introduced, but
the individual commands it brought together into an ensemble — and in
some cases replaced — had already existed for quite a long time.

I understand that in many cases, and in most day-to-day use, `puts` is
more convenient than `chan puts`. Still, chan is valuable because it
gathers much of the channel-related functionality under a single
ensemble, including the global commands that were already existing at
the time of its introduction. When thinking about the future of Tcl, I
would not give up on the idea of bringing that ship safely into harbor.

There are 12 list-related commands, not counting `list` itself, and
together they make up a significant portion of Tcl’s base command set
which sounds to me as not entirely justifiable

  -- Massimo

On 4/30/26 04:40, Steve Landers wrote:
> I fear the list ensemble ship sailed decades ago, but I still see
> value.  From my perspective, a general principle is an ensemble command
> is better than a namespace command which is better than a global command
> which is better than new syntax.
>
> -- Steve
> On 29 Apr 2026 at 12:45 AM +0800, apnmbx-public--- via Tcl-Core <tcl-
> co...@li...>, wrote:
>>
>> An idle comment a little bit along the lines of what Pietro was
>> saying ... at this point I presume we have abandoned the idea of a
>> “list” ensemble command a la string. “lutil filter|zip” etc. Unlike
>> Donal (if I understood him correctly), I do see a use for additional
>> list commands beyond what Donal listed from Python. Presumably they
>> will be all added as global commands if accepted. Otherwise, this
>> might have been a good time to introduce an “lutil” ensemble with
>> filter as a subcommand.
>>
>> /Ashok
>>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwIGaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=PVRdKcuZI9OGim2pBXVs9DinZEGfgTQNd2_j5REEgvUGOKpaBCaDlen85fy02R2t&s=VDFhKChRTQUlWNTYcDRaG35SVwv35bchaLBOB1f-Hd0&e=



_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwIGaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=PVRdKcuZI9OGim2pBXVs9DinZEGfgTQNd2_j5REEgvUGOKpaBCaDlen85fy02R2t&s=VDFhKChRTQUlWNTYcDRaG35SVwv35bchaLBOB1f-Hd0&e=

Re: [TCLCORE] Bidi text

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

Op do 30 apr 2026 om 16:36 schreef Kevin Walzer <kw...@co...>:

> Jan,
>
> The rtl_text branch has not been tested on Github. Where are you seeing
> these failures?
>

Just running on Ubuntu 26-04 LTS locally.

Hope this helps,
     Jan Nijtmans

Re: [TCLCORE] Bidi text

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

Jan,

The rtl_text branch has not been tested on Github. Where are you seeing these failures?

-Kevin
—
Kevin Walzer kw...@co...

> On Apr 30, 2026, at 9:49 AM, Jan Nijtmans <jan...@gm...> wrote:
> 
> 
> Op wo 29 apr 2026 om 17:37 schreef apnmbx-public--- via Tcl-Core:
>> Kevin,
>> 
>>  
>> 
>> Please hold off on the merge for a couple of days. It sounds like a significant enough feature that it deserves a closer look and feedback. I will try to do that by the weekend (though I’m not sure I’m qualified to review, hopefully others will!).
>> 
> 
> I'm seeing test failures like:
> === unixWm-59.1 exit processing FAILED
> ==== Contents of test case:
> 
>     set script [makeFile {
> update
> exit
>     } script]
>     if {[catch {exec [interpreter] $script -geometry 10x10+0+0} msg]} {
> set error 1
>     } else {
> set error 0
>     }
>     removeFile script
>     list $error $msg
> 
> ---- Result was:
> 1 {Fontconfig warning: using without calling FcInit()}
> ---- Result should have been (exact matching):
> 0 {}
> 
> Zo, could you hold off the merge until the test-suite is failure-free? It's
> OK to disable some tests (or - better -restrict them for the no-bidi case),
> but it's not OK to turn Github Actions red for more than a few days.
> 
> Regards,
>        Jan Nijtmans
> 

Re: [TCLCORE] Bidi text

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

Op wo 29 apr 2026 om 17:37 schreef apnmbx-public--- via Tcl-Core:

> Kevin,
>
>
>
> Please hold off on the merge for a couple of days. It sounds like a
> significant enough feature that it deserves a closer look and feedback. I
> will try to do that by the weekend (though I’m not sure I’m qualified to
> review, hopefully others will!).
>

I'm seeing test failures like:
=== unixWm-59.1 exit processing FAILED
==== Contents of test case:

    set script [makeFile {
update
exit
    } script]
    if {[catch {exec [interpreter] $script -geometry 10x10+0+0} msg]} {
set error 1
    } else {
set error 0
    }
    removeFile script
    list $error $msg

---- Result was:
1 {Fontconfig warning: using without calling FcInit()}
---- Result should have been (exact matching):
0 {}

Zo, could you hold off the merge until the test-suite is failure-free? It's
OK to disable some tests (or - better -restrict them for the no-bidi case),
but it's not OK to turn Github Actions red for more than a few days.

Regards,
       Jan Nijtmans

Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

[Florent M. <flo...@gm...>]

Hi Steve,

Le 30/04/2026 à 04:40, Steve Landers a écrit :
> I fear the list ensemble ship sailed decades ago, but I still see 
> value.  From my perspective, a general principle is an ensemble 
> command is better than a namespace command which is better than a 
> global command which is better than new syntax.
>
This is a far too generic assertion.

Here is a example of the usefullness that can give a new syntax, taken 
form a little parser I'm writing now, with the help of the expr shortand 
new syntax whose prototype can be found at : 
https://github.com/florentis/tcl90-exprSH/tree/core-9-0-branch/install_SH

The shorthand expr version is 796 chars :

timerate {
namespace eval lex {(
     NODE_TYPE  = 0xC0;
     BINARY     = 0x40;
     UNARY      = 0x80;
     LEAF       = 0xC0;

# Ambigous lexemes
     PLUS       = 1;
     MINUS      = 2;
     BAREWORD   = 3;
     INCOMPLETE = 4;
     INVALID    = 5;
     COMMENT    = 6;

# leaf lexemes
     NUMBER    = $LEAF | 1;
     SCRIPT    = $LEAF | 2;
     BRACED    = $LEAF | 4;
     VARIABLE  = $LEAF | 5;
     QUOTED    = $LEAF | 6;
     EMPTY     = $LEAF | 7;

# unary operator lexemes
     UNARY_PLUS   = $UNARY | $PLUS;
     UNARY_MINUS  = $UNARY | $MINUS;
     START        = $UNARY | 4;
     OPEN_PAREN   = $UNARY | 5;

# binary operators lexemes
     COMMA        = $BINARY | 3; # list of index
     DOT          = $BINARY | 4; # nested level
     CLOSE_PAREN  = $BINARY | 5;
     RANGE        = $BINARY | 6;
)}
}
# 15.0767 µs/# 66327 # 66327.5 #/sec 999.992 net-ms

The normal version is 950 chars :

timerate {
namespace eval lex {
set NODE_TYPE  0xC0
set BINARY     0x40
set UNARY      0x80
set LEAF       0xC0

# Ambigous lexemes
set PLUS       1
set MINUS      2
set BAREWORD   3
set INCOMPLETE 4
set INVALID    5
set COMMENT    6

# leaf lexemes
set NUMBER    [expr {$LEAF | 1}]
set SCRIPT    [expr {$LEAF | 2}]
set BRACED    [expr {$LEAF | 4}]
set VARIABLE  [expr {$LEAF | 5}]
set QUOTED    [expr {$LEAF | 6}]
set EMPTY     [expr {$LEAF | 7}]

# unary operator lexemes
set UNARY_PLUS   [expr {$UNARY | $PLUS}]
set UNARY_MINUS  [expr {$UNARY | $MINUS}]
set START        [expr {$UNARY | 4}]
set OPEN_PAREN   [expr {$UNARY | 5}]

# binary operators lexemes
set COMMA        [expr {$BINARY | 3}]; # list of index
set DOT          [expr {$BINARY | 4}]; # nested level
set CLOSE_PAREN  [expr {$BINARY | 5}]
set RANGE        [expr {$BINARY | 6}]
}
}
# 15.5551 µs/# 77961 # 64287.7 #/sec 1212.689 net-ms

16 % chars less to write,
more clear,
more clean,
less error prone,
and at the end : exactly the same bytecode, so as fast as the original !

A richest syntax isn't an ennemy then, but an allie.

Regards,

Florent

> -- Steve
> On 29 Apr 2026 at 12:45 AM +0800, apnmbx-public--- via Tcl-Core 
> <tcl...@li...>, wrote:
>>
>> An idle comment a little bit along the lines of what Pietro was 
>> saying ... at this point I presume we have abandoned the idea of a 
>> “list” ensemble command a la string. “lutil filter|zip” etc. Unlike 
>> Donal (if I understood him correctly), I do see a use for additional 
>> list commands beyond what Donal listed from Python. Presumably they 
>> will be all added as global commands if accepted. Otherwise, this 
>> might have been a good time to introduce an “lutil” ensemble with 
>> filter as a subcommand.
>>
>> /Ashok
>>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

[Massimo M. <mas...@ri...>]

My (less than) 2 cents

I do not remember exactly when the `chan` command was introduced, but 
the individual commands it brought together into an ensemble — and in 
some cases replaced — had already existed for quite a long time.

I understand that in many cases, and in most day-to-day use, `puts` is 
more convenient than `chan puts`. Still, chan is valuable because it 
gathers much of the channel-related functionality under a single 
ensemble, including the global commands that were already existing at 
the time of its introduction. When thinking about the future of Tcl, I 
would not give up on the idea of bringing that ship safely into harbor.

There are 12 list-related commands, not counting `list` itself, and 
together they make up a significant portion of Tcl’s base command set 
which sounds to me as not entirely justifiable

  -- Massimo

On 4/30/26 04:40, Steve Landers wrote:
> I fear the list ensemble ship sailed decades ago, but I still see 
> value.  From my perspective, a general principle is an ensemble command 
> is better than a namespace command which is better than a global command 
> which is better than new syntax.
> 
> -- Steve
> On 29 Apr 2026 at 12:45 AM +0800, apnmbx-public--- via Tcl-Core <tcl- 
> co...@li...>, wrote:
>>
>> An idle comment a little bit along the lines of what Pietro was 
>> saying ... at this point I presume we have abandoned the idea of a 
>> “list” ensemble command a la string. “lutil filter|zip” etc. Unlike 
>> Donal (if I understood him correctly), I do see a use for additional 
>> list commands beyond what Donal listed from Python. Presumably they 
>> will be all added as global commands if accepted. Otherwise, this 
>> might have been a good time to introduce an “lutil” ensemble with 
>> filter as a subcommand.
>>
>> /Ashok
>>
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

[Arjen M. <Arj...@de...>]

TIP 735: YES
As Donal described, a script to return the decision gives more freedom, so in my opinion that is a good change. The alternative of an expression might be syntactically more elegant, but only in certain cases, like the [lseq] example in the TIP.

TIP 745: YES
This TIP adds new mathematical functions for use in [expr]. There could be a clash with extensions that already define such functions, but such an extension would override the new function, rather than the other way around.

Regards,

Arjen

From: Steve Landers <st...@di...>
Sent: 30 April 2026 04:36
To: Donal Fellows <don...@ma...>
Cc: Tcl Core <tcl...@li...>
Subject: Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de...<mailto:Ser...@de...>" as an attachment.

TIP 735:   YES
TIP 745:   YES

On 26 Apr 2026 at 1:03 PM +0800, schreef Donal Fellows <don...@ma...<mailto:don...@ma...>>, wrote:

This is a call for votes on two self-contained TIPs that I've been sitting on for far too long.


-- Steve
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

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

I fear the list ensemble ship sailed decades ago, but I still see value.  From my perspective, a general principle is an ensemble command is better than a namespace command which is better than a global command which is better than new syntax.

-- Steve
On 29 Apr 2026 at 12:45 AM +0800, apnmbx-public--- via Tcl-Core <tcl...@li...>, wrote:
	An idle comment a little bit along the lines of what Pietro was saying ... at this point I presume we have abandoned the idea of a “list” ensemble command a la string. “lutil filter|zip” etc. Unlike Donal (if I understood him correctly), I do see a use for additional list commands beyond what Donal listed from Python. Presumably they will be all added as global commands if accepted. Otherwise, this might have been a good time to introduce an “lutil” ensemble with filter as a subcommand.
/Ashok

Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"

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

TIP 735:   YES
TIP 745:   YES

On 26 Apr 2026 at 1:03 PM +0800, schreef Donal Fellows <don...@ma...>, wrote:
>
> This is a call for votes on two self-contained TIPs that I've been sitting on for far too long.


-- Steve

Re: [TCLCORE] Bidi text

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

On Apr 29, 2026, at 1:25 PM, Benjamin Riefenstahl <b.r...@tu...> wrote:
> 
> I'm comparing with Emacs.  I also just checked GEdit.  Both handle the
> problems I noticed.
> 
>> Correct word wrap, RTL cursor movement, [...] are out of scope.
> 
> Those are serious limitations.  I consider these aspects essential.  I
> don't think I could not actually use it without.  OTOH, I am sure
> somebody (TM) can fix them later, if you can't do it now.

Emacs and Gedit have completely different architectures that provide a full bidi editing stack. My work is focused more on clean display of bidi text. Tk’s support for SVG implements a subset of the spec. Same logic applies here. 
—
Kevin Walzer kw...@co...

Re: [TCLCORE] Bidi text

[Benjamin R. <b.r...@tu...>]

Hi Kevin,

Kevin Walzer writes:
> What platform are you testing on?

This is Debian 13, Harfbuzz 10.2.0.

> It may be necessary to document that bidi support is limited. There is
> wide variation in how it’s supported across platforms and apps. On
> macOS, the benchmark is NSTextView (TextEdit); on X11, it’s
> GtkTextView (Mousepad); and on Windows, it’s Notepad++. Tk has rough
> parity with these apps.

I'm comparing with Emacs.  I also just checked GEdit.  Both handle the
problems I noticed.

> Correct word wrap, RTL cursor movement, [...] are out of scope.

Those are serious limitations.  I consider these aspects essential.  I
don't think I could not actually use it without.  OTOH, I am sure
somebody (TM) can fix them later, if you can't do it now.

Thanks again, benny

Re: [TCLCORE] Bidi text

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

And finally, THANK YOU for testing!  I will see what we can do. 
—
Kevin Walzer kw...@co...

> On Apr 29, 2026, at 12:06 PM, Kevin Walzer <kw...@co...> wrote:
> 
> Having said this, I will run your test sample when I am back at the keyboard.
> —
> Kevin Walzer kw...@co...
> 
>> On Apr 29, 2026, at 12:04 PM, Kevin Walzer <kw...@co...> wrote:
>> 
>> Hi Benny,
>> 
>> What platform are you testing on?
>> 
>> It may be necessary to document that  bidi support is limited. There is wide variation in how it’s supported across platforms and apps. On macOS, the benchmark is NSTextView (TextEdit); on X11, it’s GtkTextView (Mousepad); and on Windows, it’s Notepad++. Tk has rough parity with these apps.
>> 
>> This means:
>> 
>> 1.  Correct visual RTL rendering and shaping.
>> 2. Logical (LTR) cursor placement without visual artifacts.
>> 3. Nothing else.
>> 
>> Correct word wrap, RTL cursor movement, and other components of complete BiDi support are out of scope. We will never match LibreOffice or Chrome/Webkit in this regard. Some prior feedback suggested that these were showstopper bugs, but I disagree.
>> 
>> Implementation of full BiDi support at this level would require a full re-write of the text widget. That is not in scope.
>> 
>> - Kevin
>> 
>> —
>> Kevin Walzer kw...@co...
>> 
>>>> On Apr 29, 2026, at 11:46 AM, Benjamin Riefenstahl <b.r...@tu...> wrote:
>>> 
>>> Another one:
>>> 
>>> * I can not place the cursor in the middle of an RTL line with the
>>> mouse.  The cursor goes to the beginning of the line.
>> 
>> 
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core