tcl-core

[TCLCORE] Report of biweekly telco on 3rd of November at 12:00 UTC

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

Dear Tcl/Tk team,

here is the report of the Tcl/Tk biweekly telco:
3rd of November at 12:00 UTC
At: https://meet.jit.si/TclMonthlyMeetup

Top 1) Release calender (TIP 713)
- 9.0.3: October (this week)
- 9.1a1: November (4 weeks left)

Don still in non working block.
Wait for new SQLite, for TDBC.
A lot of bug fixes for Tk in the pipline.
New Tk focused TCT members would be great and are available.
Interrim release manager Jan will take care and make rc's.
We will wait for SQLite + Tk tickets.

Top 2) TIP 672: $(1+1)
Great feature. Agreement on the option selection.
Will probably not be mature in 1 month.
Still a lot of implementation issues.
$((1+1)) is fully backward compatible what is great.

Top 3) TIP 561: Console command for Linux/Unix
Big support, low problem scope.
Question is stdin: system and console window both go to the same 
interpreter stdin.
stdout only goes to the console.
Linux testing required!
Loading by source should be fixed.

Top 4) TIP 733: accessability (test status)
Great plan. Legal requirements.

Top 5) TIP 732: TCL library path (discussion)
Great support and to include to 9.1a0
Confused about official MacOS and Linux setup.
Also ARM/Intel differences.

TOP 6) TIP 615: string is index
Implementation not ready jet.
Feedback welcome!
Tk accepts the empty string as an index to make bindings easier.
The "-strict" makes the difference, if enpty string is accepted.
Tip text is ready.
Aim is 6.1a0

TOP 7) TIP 735: lfilter: "dict filter" for lists, but expr instead eval
Great tool!
High overlap to lmap.
Handling of additional variable proposed.
Would be great as an ensemble, but "list" is taken.

Top 8) TIP 721: Tcl_AttemptGetString
Welcome. No news. Some additional functions on the list.

Top 9) TIP 715: supported build systems
TCL 9.0 already requests C11, or VS2015.
C11 is required for 9.1 to build TCL.
The public headers are more conservative (C99).
bool is a feature of C11. It is now used internally, not in public headers.
Here is the first proposal to use bool in a public API:
https://core.tcl-lang.org/tcl/timeline?r=tip-711-bis
With a new API, this might be ok.
But C bool is different to C++ bool. Compatibality issues to investigate.

Top 10) TIP 734 nested mutex (go or not)
Discussion with Ashok

Speed is ok, as no additional lock.
Counter is already locked.
All problems are solved now.
No use case in the core.

We keep track of all mutexes, which adds overhead.
I don't understand why there is a global table with all mutextes.
A caller is responsible to free mutexes.

Inconsistency was on Win/Linux. Now, there is consistency.
A panic would be better, but needs additional wrapper code.

Benchmark from Gustaf would be great, as we loose performance.

Top 11) European conference
Will be in July 2025 in Vienna. No alternative on the radar.

Top 12) AOB
None

Top 13) Next meeting:
        17th of November 12:00 UTC.
Ok for every body.

Other dates: (sorry, Harald can not attend to any of them, travelling a 
lot in November)
4th of November German speaking user meeting 19:00 UTC
11th of November: Monthly TCL meetup 19:00UTC

Thank you for all,
Harald

Re: [TCLCORE] Report of biweekly telco on 3rd of November at 12:00 UTC

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

Hi Harald:

Regarding,  TIP 561: Console command for Linux/Unix

In my testing, via a source console.tcl, it does in fact allow input both
from the console and the terminal. It even works with rlwrap. What I fixed
in the most recent version is the opening and closing of the console
window. While the console window is open, no prompts go to the terminal,
however. But you can type in commands and the output will go to the console
window.

On closing, stdout, and stderr both revert to the terminal, and a prompt
returns in the terminal window. On issuing another console show, it will
now re-open, just where it was and further output to stderr (in red) and
stdout go to the console again. That was in my latest fix. Prior to that I
was deleting the console window on closing it, which was a mistake. Please
try the latest code.

I also changed the font size shortcuts to also allow for control-keypad +
and - and also control = which is a non-shifted + for convenience.

The wrapper code in the tip would provide backward compatibility, i.e. no
console would open automatically when running wish, since linux/unix users
wouldn't expect that. On the first console show command the wrapper will
invoke the contents of console.tcl and then remove itself.

Eric


On Mon, Nov 3, 2025 at 5:06 AM Harald Oehlmann <har...@el...>
wrote:

> Dear Tcl/Tk team,
>
> here is the report of the Tcl/Tk biweekly telco:
> 3rd of November at 12:00 UTC
> At: https://meet.jit.si/TclMonthlyMeetup
>
> Top 1) Release calender (TIP 713)
> - 9.0.3: October (this week)
> - 9.1a1: November (4 weeks left)
>
> Don still in non working block.
> Wait for new SQLite, for TDBC.
> A lot of bug fixes for Tk in the pipline.
> New Tk focused TCT members would be great and are available.
> Interrim release manager Jan will take care and make rc's.
> We will wait for SQLite + Tk tickets.
>
> Top 2) TIP 672: $(1+1)
> Great feature. Agreement on the option selection.
> Will probably not be mature in 1 month.
> Still a lot of implementation issues.
> $((1+1)) is fully backward compatible what is great.
>
> Top 3) TIP 561: Console command for Linux/Unix
> Big support, low problem scope.
> Question is stdin: system and console window both go to the same
> interpreter stdin.
> stdout only goes to the console.
> Linux testing required!
> Loading by source should be fixed.
>
> Top 4) TIP 733: accessability (test status)
> Great plan. Legal requirements.
>
> Top 5) TIP 732: TCL library path (discussion)
> Great support and to include to 9.1a0
> Confused about official MacOS and Linux setup.
> Also ARM/Intel differences.
>
> TOP 6) TIP 615: string is index
> Implementation not ready jet.
> Feedback welcome!
> Tk accepts the empty string as an index to make bindings easier.
> The "-strict" makes the difference, if enpty string is accepted.
> Tip text is ready.
> Aim is 6.1a0
>
> TOP 7) TIP 735: lfilter: "dict filter" for lists, but expr instead eval
> Great tool!
> High overlap to lmap.
> Handling of additional variable proposed.
> Would be great as an ensemble, but "list" is taken.
>
> Top 8) TIP 721: Tcl_AttemptGetString
> Welcome. No news. Some additional functions on the list.
>
> Top 9) TIP 715: supported build systems
> TCL 9.0 already requests C11, or VS2015.
> C11 is required for 9.1 to build TCL.
> The public headers are more conservative (C99).
> bool is a feature of C11. It is now used internally, not in public headers.
> Here is the first proposal to use bool in a public API:
> https://core.tcl-lang.org/tcl/timeline?r=tip-711-bis
> With a new API, this might be ok.
> But C bool is different to C++ bool. Compatibality issues to investigate.
>
> Top 10) TIP 734 nested mutex (go or not)
> Discussion with Ashok
>
> Speed is ok, as no additional lock.
> Counter is already locked.
> All problems are solved now.
> No use case in the core.
>
> We keep track of all mutexes, which adds overhead.
> I don't understand why there is a global table with all mutextes.
> A caller is responsible to free mutexes.
>
> Inconsistency was on Win/Linux. Now, there is consistency.
> A panic would be better, but needs additional wrapper code.
>
> Benchmark from Gustaf would be great, as we loose performance.
>
> Top 11) European conference
> Will be in July 2025 in Vienna. No alternative on the radar.
>
> Top 12) AOB
> None
>
> Top 13) Next meeting:
>         17th of November 12:00 UTC.
> Ok for every body.
>
> Other dates: (sorry, Harald can not attend to any of them, travelling a
> lot in November)
> 4th of November German speaking user meeting 19:00 UTC
> 11th of November: Monthly TCL meetup 19:00UTC
>
> Thank you for all,
> Harald
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Report of biweekly telco on 3rd of November at 12:00 UTC

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

Harald,

Thanks for the summary as always.

I wanted to clarify, for the benefit of those not present, my stance with respect to (10) TIP 734 nested mutex as it is still a somewhat controversial issue. I think it may not have been entirely clear from the summary that the comments

>Speed is ok, as no additional lock.
>Counter is already locked.
>All problems are solved now.
>No use case in the core. 

as well as need for consistency were from Jan, not me.

I am still not convinced, for lack of data, whether there is a performance loss or not from implementing our own wrappers that implement recursive mutexes. My comment was that since the original code (as I understood the conversation) was derived from NaviServer, it might be educational to run any benchmarks that Gustaf may have with both the current Tcl implementation (recursive wrappers) versus native (non-recursive) mutexes to see if there is an observed difference.

Aside from the performance issue, I am philosophically disinclined to implement our own synchronization primitives without a concrete use case or need (which we do not have within the Tcl core or any extensions I know of). I would therefore have been favourably disposed towards 734 except that it reverts a currently released "feature". However, given that recursive mutexes were not available in 8.6 (afaik) and did not work correctly even in 9.0.2, I doubt anyone is actually using that capability and reversion might be acceptable.

/Ashok

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Monday, November 3, 2025 6:36 PM
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] Report of biweekly telco on 3rd of November at 12:00 UTC

Dear Tcl/Tk team,

here is the report of the Tcl/Tk biweekly telco:
3rd of November at 12:00 UTC
At: https://meet.jit.si/TclMonthlyMeetup

Top 1) Release calender (TIP 713)
- 9.0.3: October (this week)
- 9.1a1: November (4 weeks left)

Don still in non working block.
Wait for new SQLite, for TDBC.
A lot of bug fixes for Tk in the pipline.
New Tk focused TCT members would be great and are available.
Interrim release manager Jan will take care and make rc's.
We will wait for SQLite + Tk tickets.

Top 2) TIP 672: $(1+1)
Great feature. Agreement on the option selection.
Will probably not be mature in 1 month.
Still a lot of implementation issues.
$((1+1)) is fully backward compatible what is great.

Top 3) TIP 561: Console command for Linux/Unix
Big support, low problem scope.
Question is stdin: system and console window both go to the same 
interpreter stdin.
stdout only goes to the console.
Linux testing required!
Loading by source should be fixed.

Top 4) TIP 733: accessability (test status)
Great plan. Legal requirements.

Top 5) TIP 732: TCL library path (discussion)
Great support and to include to 9.1a0
Confused about official MacOS and Linux setup.
Also ARM/Intel differences.

TOP 6) TIP 615: string is index
Implementation not ready jet.
Feedback welcome!
Tk accepts the empty string as an index to make bindings easier.
The "-strict" makes the difference, if enpty string is accepted.
Tip text is ready.
Aim is 6.1a0

TOP 7) TIP 735: lfilter: "dict filter" for lists, but expr instead eval
Great tool!
High overlap to lmap.
Handling of additional variable proposed.
Would be great as an ensemble, but "list" is taken.

Top 8) TIP 721: Tcl_AttemptGetString
Welcome. No news. Some additional functions on the list.

Top 9) TIP 715: supported build systems
TCL 9.0 already requests C11, or VS2015.
C11 is required for 9.1 to build TCL.
The public headers are more conservative (C99).
bool is a feature of C11. It is now used internally, not in public headers.
Here is the first proposal to use bool in a public API:
https://core.tcl-lang.org/tcl/timeline?r=tip-711-bis
With a new API, this might be ok.
But C bool is different to C++ bool. Compatibality issues to investigate.

Top 10) TIP 734 nested mutex (go or not)
Discussion with Ashok

Speed is ok, as no additional lock.
Counter is already locked.
All problems are solved now.
No use case in the core.

We keep track of all mutexes, which adds overhead.
I don't understand why there is a global table with all mutextes.
A caller is responsible to free mutexes.

Inconsistency was on Win/Linux. Now, there is consistency.
A panic would be better, but needs additional wrapper code.

Benchmark from Gustaf would be great, as we loose performance.

Top 11) European conference
Will be in July 2025 in Vienna. No alternative on the radar.

Top 12) AOB
None

Top 13) Next meeting:
        17th of November 12:00 UTC.
Ok for every body.

Other dates: (sorry, Harald can not attend to any of them, travelling a 
lot in November)
4th of November German speaking user meeting 19:00 UTC
11th of November: Monthly TCL meetup 19:00UTC

Thank you for all,
Harald

Re: [TCLCORE] Report of biweekly telco on 3rd of November at 12:00 UTC

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

Eric,

 

That was my question – the fact that stdin comes from both console and terminal. Whether that could cause confusion for users and also for event driven async io from stdin?

 

BTW, I like the model better than the current Windows implementation as the latter is not a real channel and missing event driven io for one. May be worth moving Windows to this implementation as well.

 

Did you consider use of reflected channels instead of reflected transforms?

 

/Ashok 

 

From: EricT <tw...@gm...> 

 

In my testing, via a source console.tcl, it does in fact allow input both from the console and the terminal. It even works with rlwrap. What I fixed in the most recent version is the opening and closing of the console window. While the console window is open, no prompts go to the terminal, however. But you can type in commands and the output will go to the console window.

 

 

Re: [TCLCORE] Report of biweekly telco on 3rd of November at 12:00 UTC

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

Hi Ashok,

Thank you for the positive feedback and the excellent questions.

I should clarify - I did not write this code originally. It has been
available on the Tcl wiki for quite some time. The original version
worked via a puts rename and wrapper. After Tcl 8.6, someone (whose
name I unfortunately don't know) added a two-way branch: one using
channel transforms for 8.6+, and the legacy puts rename method for
earlier versions.

For years, I would force the rename method after discovering the
channel code wouldn't correctly handle Unicode which breaks some of my
debugging tools. When I wrote the TIP, I had forgotten about the
Unicode problem and so didn't pursue it further. When I finally hit on
the fix (the encoding convertfrom), I shared it here, and then through
some recent testing fixed the open/close cycling issues. That's where
we stand today.

Regarding stdin from both terminal and console: I hadn't considered
potential confusion for users or issues with event-driven async I/O
from stdin. That's a good point worth investigating. In my testing, it
simply worked as a convenience - type in either place - but I haven't
tested complex async scenarios.

As for reflected channels instead of transforms - my only knowledge of
channel transforms comes from your book, but that's a rather advanced
subject and I don't claim to understand it fully. My contribution was
essentially finding and fixing the Unicode bug through trial and
error. If reflected channels would be a better approach, I'd be happy
to learn more, though implementing that would likely be beyond my
current expertise.

The main reason I wrote this TIP was to address the concern in the
original code comments: it uses "semi-public" Tk internals with "some
risk that future versions of Tk will no longer support this." Making
it official would protect this functionality going forward.

I'm very encouraged that you see potential for improving the Windows
implementation as well!

Eric






On Mon, Nov 3, 2025 at 9:05 AM apnmbx-public--- via Tcl-Core <
tcl...@li...> wrote:

> Eric,
>
>
>
> That was my question – the fact that stdin comes from both console and
> terminal. Whether that could cause confusion for users and also for event
> driven async io from stdin?
>
>
>
> BTW, I like the model better than the current Windows implementation as
> the latter is not a real channel and missing event driven io for one. May
> be worth moving Windows to this implementation as well.
>
>
>
> Did you consider use of reflected channels instead of reflected transforms?
>
>
>
> /Ashok
>
>
>
> *From:* EricT <tw...@gm...>
>
>
>
> In my testing, via a source console.tcl, it does in fact allow input both
> from the console and the terminal. It even works with rlwrap. What I fixed
> in the most recent version is the opening and closing of the console
> window. While the console window is open, no prompts go to the terminal,
> however. But you can type in commands and the output will go to the console
> window.
>
>
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>