tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] CFV: TIP 726

[Andreas K. <and...@gm...>]

> This is a CFV for  <https://core.tcl-lang.org/tips/doc/trunk/tip/726.md> TIP
> 726: Commands for Unicode normalization 

> CFV ends 2025-08-29 00:00 UTC.
> My vote: Yes

#726: YES

-- 
Happy Tcling,
	Andreas Kupries <and...@gm...>
			<https://core.tcl-lang.org/akupries/>
			<https://akupries.tclers.tk/>
	Developer @	SUSE Software Solutions Germany GmbH
-------------------------------------------------------------------------------

[TCLCORE] Biweekly telco on 25th of August at 12:00 UTC

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

Dear Tcl/Tk team,

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

Agenda proposal:

Top 1) Celebrate Tcl/Tk 8.6.17 release
Top 2) TIP 713 release calender update
Top 3) Multi Threading and nested mutex
Ticket by Ashok:
https://core.tcl-lang.org/tcl/info/87b69745be
TIP#509: https://core.tcl-lang.org/tips/doc/trunk/tip/509.md
https://core.tcl-lang.org/tcl/tktview/893f8cc5

Top 4) TIP 726: Commands for Unicode normalization

Top 5) TIP 720: Byte code engine speedup
Action directly on the main branch, very impressive...

Top 6) TIP 700 Documentation

Top 7) TIP 723 monotonic time

Top 8) AOB

---

Next meeting:
8th of September 12:00: Bi-weekly Telco (I am available)

Note: in September and October, I will not be able to attend the meetings.

Thank you for all,
Harald

Re: [TCLCORE] Review of branch bug-87b69745be

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

@Jan

While a test case might be useful to give confidence a problem has been
fixed, I do not feel it is mandated to address an identified issue,
particularly in multithreaded scenarios.

First, multithreading bugs can be notoriously hard to reproduce so
reproducible test cases may not be feasible. Ignoring them means mysterious
hangs and crashes and heisenbugs in the field which we cannot reproduce.
Given they will be rare, the inclination is to ignore them assigning blame
to phase of the moon.

Second, multithreading is tricky enough that the default position should be
to assume there is a problem unless one can convince oneself the code
operates correctly. In this case, Christian and myself (independently, after
he pointed it out) conclude there is in fact an issue. I don't know if
anyone has looked at the code and is convinced there is no problem.

It may be that the final conclusion is that there is no issue or that the
problem occurs so very rarely, and is so hard to fix, that it is best left
alone. But that needs to be an explicit decision after investigation.

@Christian

I agree your fix, along with the system encoding MT issue Sergey logged, is
something that needs attention. Whether that means eliminating the recursive
mutex or fixing the condition variable code remains to be seen. While I am
wary of the former in a non-major release, since the API is new in Tcl 9, it
is likely few people will be using it so reverting may be a possibility. As
to the time frame, hopefully in a couple of weeks unless someone gets to it
sooner.

/Ashok

-----Original Message-----
From: Jan Nijtmans <jan...@gm...> 
Without a testcase demonstrating the problem,
it's not useful to discuss this further, IMHO,
however logical your proposed fix looks.

Regards,
       Jan Nijtmans


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

Re: [TCLCORE] Review of branch bug-87b69745be

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

Christian, Jan,

we will speak on this point in the biweekly telco next Monday.
Ashok had confirmed that there is an issue and may give some insight.

Thanks for all,
Harald

Am 22.08.2025 um 16:29 schrieb Christian Werner:
> On 08/22/2025 03:34 PM, Jan Nijtmans wrote:
> 
> Jan,
> 
>> If there is something wrong with the current recursive mutex
>> implementation, then it should be possible to prepare
>> a testcase demonstrating that. Currently, I don't think there
>> is code doing that, since Tcl 8.6 would create a deadlock
>> in that case (which is not a bug in Tcl 8.6).
> 
> The recursive mutexery isn't an 8.6 feature anyway, so 8.6 is out of scope.
> 
>> Without a testcase demonstrating the problem,
>> it's not useful to discuss this further, IMHO,
>> however logical your proposed fix looks.
> 
> Fine. So we have a catch22 here. And better forget my obvious fix now.
> 
> Jeez, it begins to remind me of task 8 in "The 12 Tasks of Asterix".
> 
> Best,
> Christian

Re: [TCLCORE] Review of branch bug-87b69745be

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

On 08/22/2025 03:34 PM, Jan Nijtmans wrote:

Jan,

> If there is something wrong with the current recursive mutex
> implementation, then it should be possible to prepare
> a testcase demonstrating that. Currently, I don't think there
> is code doing that, since Tcl 8.6 would create a deadlock
> in that case (which is not a bug in Tcl 8.6).

The recursive mutexery isn't an 8.6 feature anyway, so 8.6 is out of scope.

> Without a testcase demonstrating the problem,
> it's not useful to discuss this further, IMHO,
> however logical your proposed fix looks.

Fine. So we have a catch22 here. And better forget my obvious fix now.

Jeez, it begins to remind me of task 8 in "The 12 Tasks of Asterix".

Best,
Christian

Re: [TCLCORE] Review of branch bug-87b69745be

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

Op do 21 aug 2025 om 22:20 schreef Christian Werner:
> On 08/21/2025 10:00 PM, Christian Werner wrote:
> > So we can discuss until we'll meet again in the restaurant at the end
> > of the universe, but we desperately need to resolve both the nestery
> > of mutexes and the waitery on a condition variable in a monotonic clock
> > domain.
>
> No. We don't. We drop recursive mutexes. We drop timeouts on waiting on
> condition variables. And we are fine then.

If there is something wrong with the current recursive mutex
implementation, then it should be possible to prepare
a testcase demonstrating that. Currently, I don't think there
is code doing that, since Tcl 8.6 would create a deadlock
in that case (which is not a bug in Tcl 8.6).

Without a testcase demonstrating the problem,
it's not useful to discuss this further, IMHO,
however logical your proposed fix looks.

Regards,
       Jan Nijtmans

Re: [TCLCORE] Change from "&&" to "&" without ticket

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

 

It was a clearly a typo in previous code (thus was obviously a bug),
because 

(flags && CMD_IS_DELETED) is basically the same than (flags) 

whereas 

(flags & CMD_IS_DELETED) is checking whether the bit CMD_IS_DELETED is
set. 

That in turn caused that Tcl_DeleteCommandFromToken in else-scope 
was previously executed rarer (and never if any command flag was set). 
And now only if CMD_IS_DELETED is not yet set. 

And it'd not change the behavior at all, if that command only gets the
flag CMD_IS_DELETED(and later CMD_DEAD).
(mostly the case, if command has no traces, extern command resolver in
NS, etc).

Regards,
Sergey. 

22.08.2025 08:21, Harald Oehlmann wrote: 

> Dear Jan, dear Don,
> 
> thanks for great commit
> https://core.tcl-lang.org/tcl/info/d03831556853988c [1]
> This looks quite disruptive, as "&" and "&&" are very different operations, which highly change the behaviour.
> Is there a use-case to trigger this code path and to go the wrong way?
> Would it be an idea to have a ticket and a changelog line ?
 

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

Re: [TCLCORE] Change from "&&" to "&" without ticket

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

Am 22.08.2025 um 09:10 schrieb Jan Nijtmans:
> Op vr 22 aug 2025 om 08:22 schreef Harald Oehlmann:
>>
>> Dear Jan, dear Don,
>>
>> thanks for great commit
>> https://core.tcl-lang.org/tcl/info/d03831556853988c
>> This looks quite disruptive, as "&" and "&&" are very different
>> operations, which highly change the behaviour.
>> Is there a use-case to trigger this code path and to go the wrong way?
>> Would it be an idea to have a ticket and a changelog line ?
> 
> I don't think anyone would notice the difference. In the old
> situation, the Tcl_DeleteCommandFromToken() function
> call would be - mistakenly - being skipped, which would
> lead to a memory-leak, that's all. You would need
> valgrind to notice that. That's corrected now.
> 
> A clang compiler warning was what made me aware
> of this mistake. One of the rare cases a compiler-
> warning indicates a real problem ......
> 
> I wouldn't know what else to write in a ticket.
> 
> Hope this helps,
>         Jan Nijtmans

Thanks for the explanation, great!
Fixing a memory leak is also an achevement.

Thanks for all,
Harald

Re: [TCLCORE] Change from "&&" to "&" without ticket

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

Op vr 22 aug 2025 om 08:22 schreef Harald Oehlmann:
>
> Dear Jan, dear Don,
>
> thanks for great commit
> https://core.tcl-lang.org/tcl/info/d03831556853988c
> This looks quite disruptive, as "&" and "&&" are very different
> operations, which highly change the behaviour.
> Is there a use-case to trigger this code path and to go the wrong way?
> Would it be an idea to have a ticket and a changelog line ?

I don't think anyone would notice the difference. In the old
situation, the Tcl_DeleteCommandFromToken() function
call would be - mistakenly - being skipped, which would
lead to a memory-leak, that's all. You would need
valgrind to notice that. That's corrected now.

A clang compiler warning was what made me aware
of this mistake. One of the rare cases a compiler-
warning indicates a real problem ......

I wouldn't know what else to write in a ticket.

Hope this helps,
       Jan Nijtmans

[TCLCORE] Change from "&&" to "&" without ticket

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

Dear Jan, dear Don,

thanks for great commit
https://core.tcl-lang.org/tcl/info/d03831556853988c
This looks quite disruptive, as "&" and "&&" are very different 
operations, which highly change the behaviour.
Is there a use-case to trigger this code path and to go the wrong way?
Would it be an idea to have a ticket and a changelog line ?

Thanks for all,
Harald

Re: [TCLCORE] Review of branch bug-87b69745be

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

Dear TCT and all who might be concerned,

I hope that my last postings made some fact clear: we had
a potential overlooked small design problem which slipped
into a major, point, or whatever release. Are we able to
step back? Or are we required to invent more logic to follow
the TIP we ought to have implemented into such release?
Not easily and generally be answered, of course. But I've
outlined a pressing example and am pretty curious about
it's future.

BR,
Christian

Re: [TCLCORE] Review of branch bug-87b69745be

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

On 08/21/2025 10:00 PM, Christian Werner wrote:

> So we can discuss until we'll meet again in the restaurant at the end
> of the universe, but we desperately need to resolve both the nestery
> of mutexes and the waitery on a condition variable in a monotonic clock
> domain.

No. We don't. We drop recursive mutexes. We drop timeouts on waiting on
condition variables. And we are fine then.

Enjoy,
Christian

--
“For a moment, nothing happened. Then, after a second or so, nothing continued to happen.”
― Douglas Adams, The Hitchhiker’s Guide to the Galaxy

Re: [TCLCORE] Review of branch bug-87b69745be

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

On 08/13/2025 08:01 PM, Christian Werner wrote:

> For the record: the Win32 implementation of wait on condition seems
> broken, too. Due to Win32 critical sections supporting nesting, the
> logical unlock before the wait on condition *must* leave the critical
> section as many times as it was entered and restore this afterwards.
> Otherwise the mutex is locked during the wait, and that violates the
> contract.

Lemme pour some gasoline into this little wild fire. Now we have the
"wait on condition" operation, which in the POSIX sense can be timely
limited to an absolute point of time, when it is to time out. Why the
heck you might ask? Dude, due to the spuriously wakeupery, when you've
raced and won not. This is not reflected in any current implementation
of the Tcl wrappers. And the fine problem in POSIX was, that absolute
meant wall clock in the early days. Until POSIX condition variables
learned about CLOCK_MONOTONIC. Which IMO is the only usable way to
operate "waiting on condition". Since wall clockery might do things
under the hood and out of control.

So we can discuss until we'll meet again in the restaurant at the end
of the universe, but we desperately need to resolve both the nestery
of mutexes and the waitery on a condition variable in a monotonic clock
domain.

Enjoy,
Christian

--
“Would it save you a lot of time if I just gave up and went mad now?”
― Douglas Adams, The Hitchhiker’s Guide to the Galaxy

[TCLCORE] Proposed revisions to 9.1* release calendar (TIP 713)

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

I have updated TIP 713 to the revised release dates.


On 8/4/25 09:49, Donald G Porter via Tcl-Core wrote:
>
> The 9.1 release calendar originally recorded in TIP 713 called for:
>
> May 25    9.1a0
> Sep 25    9.1a1
> Jan 26    9.1a2
> May 26    9.1b0
> Jul 26    9.1b1
> Aug 26    9.1b2
> Sep 26    9.1.0
>
> The release of 9.1a0 did not get completed until late July.  This leaves
> the time between 9.1a0 and 9.1a1 compressed and rushed, with less ability
> to add features, which is the point of alpha development.
>
> What do interested parties think about this revision:
>
> Jul 25    9.1a0
> Nov 25    9.1a1
> Feb 26    9.1a2
> May 26    9.1b0
> Jul 26    9.1b1
> Aug 26    9.1b2
> Sep 26    9.1.0
>
> Still aiming for the same date of feature freeze.  Just spreading the
> alpha releases more evenly through the remaining time.
>


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

Re: [TCLCORE] Pain points as a distro maintainer

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

Stu,

That was very helpful for me to wrap my head around Unix installs.

One item that was left out (question for both Stu and Pietro) was where do
third party packages like tcllib, critcl etc. get installed? Note these
packages may have Tcl script libraries, shared libraries as well as
"applications" like critcl. Do they go into a common system directory or a
Tcl version-specific location?

/Ashok

-----Original Message-----
From: Stuart Cassoff via Tcl-Core <tcl...@li...> 
Sent: Tuesday, August 19, 2025 12:14 AM
To: tcl...@li...; Pietro Cerutti <ga...@ga...>
Subject: Re: [TCLCORE] Pain points as a distro maintainer

Hi,

On OpenBSD:

My only real concern would be the Thread extension, which, if not made to
work in 8 and 9, would have to be separate extension: tclthread and
tcl9thread. Not great, not terrible.

Right now, everything 8/9 is as integrated as possible but separated where
necessary.

Tcl/Tk 8.5 and 8.6 are installed under dir names "8.5" and "8.6".

Tcl/Tk 9 will simply be "9". When 9.1 is released, it will replace 9.0.

The paths and dirs for 9 will be similar, but I'll be keeping the older
naming convention for libs and maybe other things, ie: libtk90.so instead of
libtcl9tk90.so.

These are the default auto_path and tm paths:
$ tclsh8.6
% set auto_path
/usr/local/lib/tcl/tcl8.6 /usr/local/lib/tcl
% tcl::tm::path list
/usr/local/lib/tcl/modules/85 /usr/local/lib/tcl/modules/86
/usr/local/lib/tcl/tcl8.6/modules

Here's the packing list for 8.6:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/tcl/8.6/pkg/
PLIST?rev=1.17&content-type=text/plain

Here's a snip of the most important bits of the package readme:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/tcl/8.6/pkg/
README?rev=1.8&content-type=text/plain

Tclsh and Wish
--------------
normally
/usr/local/lib/tclsh, /usr/local/lib/wish
now
/usr/local/bin/tclsh8.6, /usr/local/bin/wish8.6

Library files
-------------
scripts, encoding files, etc.
normally in
/usr/local/lib/tcl8.6, /usr/local/lib/tk8.6
now in
/usr/local/lib/tcl/tcl8.6, /usr/local/lib/tcl/tk8.6

Configuration Files
-------------------
tclConfig.sh, tkConfig.sh
normally in
/usr/local/lib
now in
/usr/local/lib/tcl/tcl8.6, /usr/local/lib/tcl/tk8.6

Header Files
------------
*.h
normally in
/usr/local/include
now in
/usr/local/include/tcl8.6, /usr/local/include/tk8.6

Manual Pages
------------
*.1, *.3, *.n
normally in
/usr/local/man
now in
/usr/local/lib/tcl/tcl8.6/man, /usr/local/lib/tcl/tk8.6/man

Demos
-----
*.tcl, *
normally in
/usr/local/lib/tk8.6/demos
now in
/usr/local/share/examples/tk8.6

Bundled Tcl Modules
-------------------
*.tm
normally in
/usr/local/lib/tcl8/...
now in
/usr/local/lib/tcl/tcl8.6/modules

Tcl Module Paths
----------------
normally
/usr/local/lib/tcl8/...
now
/usr/local/lib/tcl/modules/{85,86}

Manual Page Configuration
=========================
Adding the following lines to /etc/man.conf wil enable man(1)
and related commands can find the Tcl and Tk manual pages.

manpath /usr/local/lib/tcl/tcl8.6/man
manpath /usr/local/lib/tcl/tk8.6/man


Stu


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

Re: [TCLCORE] Advice requested regarding [send] on macOS

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

> And, incidentally, if you attempt to read the manual you will encounter many instances of the word "application" but you will not find a definition of what a Tk "application" is anywhere.  I wish I knew what people think that means.

Before I started using Mac OS X, I would have used it to mean any computer program all the way down to “cat”. Apple means “Application” to be a program with a full on GUI, and that’s spread to iOS and thence Android. I don’t know if Apple coined this distinction, but that’s where I became aware of it.

Re: [TCLCORE] Advice requested regarding [send] on macOS

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

On 08/20/2025 03:17 PM, Marc Culler wrote:
  
> And an /application/ is supposed to be able to *send* commands to any other /application/ running on the same host.

Marc, not quite. The driving force is the display, i.e. "applications" which share the display. The code can run
elsewhere due to the networked characteristic of X11.

HTH,
Christian

Re: [TCLCORE] Advice requested regarding [send] on macOS

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

On Tue, Aug 19, 2025 at 5:09 PM Christian Werner <
Chr...@t-...> wrote:

> On 08/19/2025 11:18 PM, Marc Culler wrote:
>
> > … but you will not find a definition of what a Tk "application" is
> anywhere.  I wish I knew what people think that means.
>
> My best guess in X11 sense (where the "send" command initially originated)
> is that a "Tk application" is the thing hosting
> the "." topmost toplevel. This can be a process of its own, or an interp
> which has loaded Tk, or in theory an interp in
> another thread which also has loaded Tk. All these are endpoints in the
> "send" sense, i.e. theoretically able to consume
> commands originating from some "send".
>

So you are saying that:
     An *application* is a Tcl interpreter which has loaded the Tk package.
(Loading Tk always provides the interpreter with a window named '.'.)

And an *application* is supposed to be able to *send* commands to any other
*application* running on the same host.

I will take that as my working definition.

- Marc

Re: [TCLCORE] Advice requested regarding [send] on macOS

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

On Wed, Aug 20, 2025 at 5:59 AM Donal Fellows <
don...@ma...> wrote:

> It'll comply if we say it complies. It would be just another PLATFORM
> LIMITATION note, which we have done in the past. The heart of [send] is
> this two part atatement:
>
>    - App makes itself available for "remote" (same system, another
>    process) control, with a name.
>
>
On the mac it currently must be an interpreter *in the same process.*

- Marc

Re: [TCLCORE] Advice requested regarding [send] on macOS

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

It'll comply if we say it complies. It would be just another PLATFORM LIMITATION note, which we have done in the past. The heart of [send] is this two part atatement:

  *   App makes itself available for "remote" (same system, another process) control, with a name.
  *   App gets to be able to discover other apps that have done that, and to send commands to them.

The platform may limit the discovery mechanism; it was ever thus (and I remember having to tune the local X11 security model to use [send] back in 1995). Apps should have to volunteer to join the discoverability setup, and should only communicate if they're a part of the group (because responses are "sent" back).

Donal.

-------- Original message --------
From: Marc Culler <cul...@gm...>
Date: 19/08/2025 22:19 (GMT+00:00)
To: Kevin Walzer <kw...@co...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] Advice requested regarding [send] on macOS

I was about to say that implementation of `send` on the mac would be simpler and more natural if it could be limited to sending commands between Wish apps (by which I mean running instances of Wish.app).  That is apparently what the authors of the current version had in mind, since they were planning to use AppleEvents, and as far as I know that would not work with a tclsh shell which has loaded the Tk package.  But it is hard for me to see how that would comply with the manual page.

Re: [TCLCORE] Advice requested regarding [send] on macOS

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

On 08/19/2025 11:18 PM, Marc Culler wrote:

> … but you will not find a definition of what a Tk "application" is anywhere.  I wish I knew what people think that means.

My best guess in X11 sense (where the "send" command initially originated) is that a "Tk application" is the thing hosting
the "." topmost toplevel. This can be a process of its own, or an interp which has loaded Tk, or in theory an interp in
another thread which also has loaded Tk. All these are endpoints in the "send" sense, i.e. theoretically able to consume
commands originating from some "send".

HTH,
Christian

Re: [TCLCORE] Advice requested regarding [send] on macOS

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

speaking of broken `send` commands, my gmail interface has a habit of
sending my mail before I finish writing it.

I was about to say that implementation of `send` on the mac would be
simpler and more natural if it could be limited to sending commands between
Wish apps (by which I mean running instances of Wish.app).  That is
apparently what the authors of the current version had in mind, since they
were planning to use AppleEvents, and as far as I know that would not work
with a tclsh shell which has loaded the Tk package.  But it is hard for me
to see how that would comply with the manual page.

And, incidentally, if you attempt to read the manual you will encounter
many instances of the word "application" but you will not find a definition
of what a Tk "application" is anywhere.  I wish I knew what people think
that means.

- Marc

On Tue, Aug 19, 2025 at 4:10 PM Marc Culler <cul...@gm...> wrote:

> I don't think that you seem out of step at all.
>
> Here is the problem which I am facing.  The `send` command is a documented
> part of Tk, at the moment anyway.  But. the macOS implementation is
> extremely incomplete and does not behave the way the manual says it should
> in many ways.  That could be ignored, were it not for the fact that it also
> causes crashes with segfaults.
>
> The crash is due to a big missing piece of the implementation - the
> deleteProc.  There seem to be two choices.  Either come up with some hack
> which avoids the crash, but still leaves an incomplete non-compliant
> implementation, or upgrade the implementation to something which behaves as
> advertised.
>
> On the face of it, one would guess that the first choice is much less work
> than the second.  But I don't think that is the case.  The deleteProc is
> missing because the design choices made in the current implementation ended
> up painting the author into a corner from which there was no obvious way to
> implement a deleteProc.  But the second choice would be a lot of work, as
> well as a colossal waste of time if we are on the verge of removing the
> `send` command altogether.
>
> Also, implementation of `send
> - Marc
>
> On Tue, Aug 19, 2025 at 2:42 PM Kevin Walzer <kw...@co...> wrote:
>
>>
>> > On Aug 19, 2025, at 12:50 PM, Marc Culler <cul...@gm...> wrote:
>> >
>> > I think these are overlapping, but distinct, application domains.
>>
>> I understand the distinction. I’m surprised that my interest in IPC
>> across apps seems so out of step.
>
>

Re: [TCLCORE] Advice requested regarding [send] on macOS

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

I don't think that you seem out of step at all.

Here is the problem which I am facing.  The `send` command is a documented
part of Tk, at the moment anyway.  But. the macOS implementation is
extremely incomplete and does not behave the way the manual says it should
in many ways.  That could be ignored, were it not for the fact that it also
causes crashes with segfaults.

The crash is due to a big missing piece of the implementation - the
deleteProc.  There seem to be two choices.  Either come up with some hack
which avoids the crash, but still leaves an incomplete non-compliant
implementation, or upgrade the implementation to something which behaves as
advertised.

On the face of it, one would guess that the first choice is much less work
than the second.  But I don't think that is the case.  The deleteProc is
missing because the design choices made in the current implementation ended
up painting the author into a corner from which there was no obvious way to
implement a deleteProc.  But the second choice would be a lot of work, as
well as a colossal waste of time if we are on the verge of removing the
`send` command altogether.

Also, implementation of `send
- Marc

On Tue, Aug 19, 2025 at 2:42 PM Kevin Walzer <kw...@co...> wrote:

>
> > On Aug 19, 2025, at 12:50 PM, Marc Culler <cul...@gm...> wrote:
> >
> > I think these are overlapping, but distinct, application domains.
>
> I understand the distinction. I’m surprised that my interest in IPC across
> apps seems so out of step.

Re: [TCLCORE] Pain points as a distro maintainer

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

Op di 19 aug 2025, 21:55 schreef Pietro Cerutti via Tcl-Core <
tcl...@li...>:

> On Aug 11 2025, 11:09 +0000, Pietro Cerutti via Tcl-Core <
> tcl...@li...> wrote:
> >I have the feeling that the people doing the work (and thanks for
> >that!) are sometimes disconnected from the people who are supposed to
> >integrate and use the result of the work.
>
....

> Now even extensions that are
> perfectly source-compatible with both 8 and 9 will need to be
> special-cased and produce a slightly different packaging list.
>

I'm sorry you feel that way. But - indeed - every change however
well-intended means extra work for package integrators.

Regards,
     Jan Nijtmans

>

Re: [TCLCORE] Pain points as a distro maintainer

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

On Aug 11 2025, 11:09 +0000, Pietro Cerutti via Tcl-Core <tcl...@li...> wrote:
>Hi,
>
>I have the feeling that the people doing the work (and thanks for 
>that!) are sometimes disconnected from the people who are supposed to 
>integrate and use the result of the work.

Here's a data point:

https://core.tcl-lang.org/tclconfig/info/381985d331b96ba9

There's no TIP, no rationale, no ticket being referenced, nothing 
whatsoever.  Just a breaking change.  Now even extensions that are 
perfectly source-compatible with both 8 and 9 will need to be 
special-cased and produce a slightly different packaging list. Practical 
case: TDBC.

TIP595 is just as bad: shared libraries built for 9 now have a tcl9 
prefix.  The rationale provided was that this would allow Tk 8.7 to be 
built against both 8.7 and 9.0, and installed alongside. But downstreams 
providing this option (I don't know any), will have to install those two 
builds in different directories already, becase of *all other files* 
clashing... as a malus, *all* extensions now have their .so files called 
libtcl9foo.so when built against 9 and libfoo.so when built against 8.
For TIP595, I am guilty as charged of not having reacted when it was the 
time.


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