tcl-core — Tcl Core Team discussions about Tcl development

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

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

On 8/16/25 08:12, Erik Leunissen via Tcl-Core wrote:

> 
> I've filed a fossil bug ticket (#9ba9729ef1) that addresses these tests and the lack
> of documentation regarding the limitation on macOS. I'll propose fixes/improvements
> there.
> 

Hi Marc,

I believe banch bug-9ba9729ef1 is now complete and in order.
Github CI is now happy on macOS too.

I'd like to merge this into trunk (and from there into the branch
simplify_test_file_init_for_singleproc_1, to be able to continue there).

Do you care to review there?

If so, here are the handy links:

Ticket:

     https://core.tcl-lang.org/tk/tktview/9ba9729ef1

Resulting changes in that branch w.r.t. trunk:

     https://core.tcl-lang.org/tk/vdiff?branch=bug-9ba9729ef1


Please let me know,
Erik.
--

B.t.w. I filed a separate ticket for the awkward matters involved with:

> Related to this matter: I noticed (in a debug statement issued by me for execution at Github) that 
> interpreters in another process are not returned by [winfo interps] on macOS. (See the script below 
> to verify that). I'm suspecting that this is for the
> very same reason/cause. Can you please give your view about that (confirm/deny if
> possible) ?
> 
> If my suspicion is right, then I can piggyback a correction for the "winfo interps"
> behaviour on macOS in the same bug ticket/patch, and also make testing of this command in 
> "winfo.test" more complete.

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

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

On 8/17/25 16:18, Marc Culler wrote:
> Why not just install fossil on the old mac and build yourself? 

Because I remeber to have read somewhere that on a mac, one needs to install
and wield XCode, which is something I have an aversion for.
(I vaguely recall having tried that anyway in the past, without luck.)
I just want to use make, auto-tools, and a gcc compiler toolchain,
best pre-installed. (But I'm prepared to get them from macPorts or Homebrew.
The whole mac/apple software ecosystem is an awkward fit to my brain).

  We support down to OSX 10.13.
> Building Tk or Tcl only takes 2 commands in the terminal:
> 
> make -C macosx
> sudo make -C macosx install
> 

But this is exactly what I want. I'm going to check whether this works (without installing XCode or 
other apple-specific build tools).

Erik.
--

> The phenomenon of tests changing outcomes due to completely unrelated changes is very common.  It is 
> the most frustrating part of working on the test suite.  Thanks for confronting it.
> 
> - Marc
> 
> On Sun, Aug 17, 2025 at 8:56 AM Erik Leunissen <el...@xs... <mailto:el...@xs...>> wrote:
> 
>     By the way: I've revived an old macOS laptop, onto which I installed a macPorts Tcl/Tk 8.6.16. I
>     can
>     now exercise scripts, run Tcl/Tk applications.
> 
>     But no further dev capabilities.
> 
>     Erik.
> 

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

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

Why not just install fossil on the old mac and build yourself?  We support
down to OSX 10.13.  Building Tk or Tcl only takes 2 commands in the
terminal:

make -C macosx
sudo make -C macosx install

The phenomenon of tests changing outcomes due to completely unrelated
changes is very common.  It is the most frustrating part of working on the
test suite.  Thanks for confronting it.

- Marc

On Sun, Aug 17, 2025 at 8:56 AM Erik Leunissen <el...@xs...> wrote:

> By the way: I've revived an old macOS laptop, onto which I installed a
> macPorts Tcl/Tk 8.6.16. I can
> now exercise scripts, run Tcl/Tk applications.
>
> But no further dev capabilities.
>
> Erik.
>

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

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

By the way: I've revived an old macOS laptop, onto which I installed a macPorts Tcl/Tk 8.6.16. I can 
now exercise scripts, run Tcl/Tk applications.

But no further dev capabilities.

Erik.

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

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

On 8/17/25 05:39, Marc Culler wrote:
> 
> I now think that much of what I said about the consequences of having a unique NSApplication object 
> is wrong.  I think there is actually no obstacle to implementing a send command on macOS which can 
> send commands to interpreters in a different Wish process.  The only problem is that no one 
> ever wrote such an implementation.
> 

OK Marc.

But, I sincerely hope that I didn't lead you onto a side-track.

My point isn't that I consider [send]'s limitation on macOS a problem. And I don't
have any plans to write an implementation of [send] that does work across process
boundaries.

The problem that I am trying to solve(*) is that quite some tests in test file
"send.test" disregard the current limitation on macOS. And some of these suddenly
fail (as they should) after a change to something that is not directly related.

I believe that I solved that particular problem now in branch bug-9ba9729ef1 by
constraining the relevant tests using test constraint "notAqua". The test failures
in test file send.test are now gone.

B.t.w. I've abandoned this idea in my previous post:

 >	If my suspicion is right, then I can piggyback a correction for the
 >	"winfo interps" behaviour on macOS in the same bug ticket/patch, and
 >	also make testing of this command in "winfo.test" more complete.

But that's a whole different story (to put it politely). See:

	https://core.tcl-lang.org/tk/tktview/ff2ca8b34c


Regards,
Erik.
--
(*) in this ticket: https://core.tcl-lang.org/tk/tktview/9ba9729ef1

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

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

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Who uses send on macOS? I thought it was no-op on Aqua. And wasn’t send disabled on win32 because its COM-based implementation wa deemed a security risk?&nbsp;</div><div dir="ltr"><br><blockquote type="cite">On Aug 16, 2025, at 11:40 PM, Marc Culler &lt;cul...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Erik,</div><div><br></div><div>I now think that much of what I said about the consequences of having a unique NSApplication object is wrong.&nbsp; I think there is actually&nbsp;no obstacle&nbsp;to implementing a send command on macOS which can send commands to interpreters in a different Wish process.&nbsp; The only problem is that no one ever&nbsp;wrote such an implementation.</div><div><br></div><div>- Marc</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sat, Aug 16, 2025 at 7:17 AM Marc Culler &lt;<a href="mailto:cul...@gm...">cul...@gm...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Apple does provide IPC mechanisms.&nbsp; I don't know whether they would be suitable, but I am pretty sure they would.&nbsp; However, the current implementation&nbsp;of [send] does not attempt to use them.&nbsp; If you look at the top of macosx/TkMacOSXSend.c you will see this very old comment (note that "gestalts" no longer exist in macOS):</div><div><br></div><div>&nbsp;* &nbsp; &nbsp; &nbsp;This file provides procedures that implement the "send" command,<br>&nbsp;* &nbsp; &nbsp; &nbsp;allowing commands to be passed from interpreter to interpreter. This<br>&nbsp;* &nbsp; &nbsp; &nbsp;current implementation for the Mac has most functionality stubbed out.<br>&nbsp;*<br>&nbsp;* &nbsp; &nbsp; &nbsp;The current plan, which we have not had time to implement, is for the<br>&nbsp;* &nbsp; &nbsp; &nbsp;first Wish app to create a gestalt of type 'WIsH'. This gestalt will<br>&nbsp;* &nbsp; &nbsp; &nbsp;point to a table, in system memory, of Tk apps. Each Tk app, when it<br>&nbsp;* &nbsp; &nbsp; &nbsp;starts up, will register their name, and process ID, in this table.<br>&nbsp;* &nbsp; &nbsp; &nbsp;This will allow us to implement "tk appname".<br>&nbsp;*<br>&nbsp;* &nbsp; &nbsp; &nbsp;Then the send command will look up the process id of the target app in<br>&nbsp;* &nbsp; &nbsp; &nbsp;this table, and send an AppleEvent to that process. The AppleEvent<br>&nbsp;* &nbsp; &nbsp; &nbsp;handler is much like the do script handler, except that you have to<br>&nbsp;* &nbsp; &nbsp; &nbsp;specify the name of the tk app as well, since there may be many<br>&nbsp;* &nbsp; &nbsp; &nbsp;interps in one wish app, and you need to send it to the right one.<br>&nbsp;*<br>&nbsp;* &nbsp; &nbsp; &nbsp;Implementing this has been on our list of things to do, but what with<br>&nbsp;* &nbsp; &nbsp; &nbsp;the demise of Tcl at Sun, and the lack of resources at Scriptics it<br>&nbsp;* &nbsp; &nbsp; &nbsp;may not get done for awhile. So this sketch is offered for the brave<br>&nbsp;* &nbsp; &nbsp; &nbsp;to attempt if they need the functionality...</div><div><br></div><div>- Marc</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 16, 2025 at 1:17 AM Donal Fellows &lt;<a href="mailto:don...@ma..." target="_blank">don...@ma...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>




<div dir="ltr">
<div style="font-size:11pt;color:rgb(0,0,0)">
I would be very startled if it <i>isn't</i>&nbsp;the exact same issue, a combination of needing a suitable IPC mechanism for doing the discovery and communications, and system policy restricting access to such things even if they exist.</div>
<div id="m_1999416157882977360m_-833440576428981616appendonsend"></div>
<div><br>
</div>
<div style="font-size:11pt;color:rgb(0,0,0)">
Donal.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<hr style="display:inline-block;width:98%">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<b>From:</b>&nbsp;Erik Leunissen via Tcl-Core &lt;<a href="mailto:tcl...@li..." target="_blank">tcl...@li...</a>&gt;<br>
<b>Sent:</b>&nbsp;Saturday, August 16, 2025 07:12<br>
<b>To:</b>&nbsp;Marc Culler &lt;<a href="mailto:cul...@gm..." target="_blank">cul...@gm...</a>&gt;<br>
<b>Cc:</b>&nbsp;<a href="mailto:tcl...@li..." target="_blank">tcl...@li...</a> &lt;<a href="mailto:tcl...@li..." target="_blank">tcl...@li...</a>&gt;<br>
<b>Subject:</b>&nbsp;Re: [TCLCORE] Advice requested regarding [send] on macOS </div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-size:11pt">Related to this matter: I noticed (in a debug statement issued by me for execution at Github) that<br>
interpreters in another process are not returned by [winfo interps] on macOS. (See the script below<br>
to verify that). I'm suspecting that this is for the<br>
very same reason/cause. Can you please give your view about that (confirm/deny if<br>
possible) ?<br>
<br>
</div>
</div>

</div></blockquote></div>
</blockquote></div>
<span>_______________________________________________</span><br><span>Tcl-Core mailing list</span><br><span>Tcl...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/tcl-core</span><br></div></blockquote></body></html>

Re: [TCLCORE] RFE: lazy loading of TclOO

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

Yes, both interp clone and a “clean” interp as Don suggested would be nice. I’ve looked this some time back and concluded it was too much work, not just in implementation but in design (which of the internal interp structures will be cloned?) and test at well. I am not entirely sure cloning is even feasible in the presence of extensions that need their init functions to be called.

 

It would be an interesting project to take on if someone has the time.

 

/Ashok

 

From: Brian O’Hagan <bri...@co...> 
Sent: Saturday, August 16, 2025 6:58 PM
To: Donald Porter <d.g...@co...>
Cc: apn...@ya...; Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] RFE: lazy loading of TclOO

 

 

What about an interpreter clone command? It would have options for the user to decide what to include or not include. For example, -noprocs, -nolibs, -nochans, -novars, etc. This way you can config an interp as you need it, then just keep making copies of it. If done right, I would think this is the most efficient way to get new configured interpreters. Probably not the easiest option to implement though.





On Aug 16, 2025, at 7:07 AM, Donald Porter via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > wrote:



 

Interp creation establishes a new interpreter initialized with the complete built-in command set, and includes the task of finding and sourcing the init.tcl file of the script library.  That’s a fine default.

 

Ashok’s proposal preserves an illusion of that, with some commands not fully realized, but still functional.  Lazy loading or autoloading have long been part of the Tcl baseline.  This is just a shift of that implementation detail.

 

I think it is worth pursuing an additional option.  Give programmers the option to create an empty interpreter — one with no commands, no variables, and only the global namespace.  This would be a “create and fill with what you want” to be offered alongside the existing “create the standard and hack away what you find useless or dangerous”.

 

I *think* that option would create interpreters faster, but a working implementation would need to demonstrate that.





On Aug 16, 2025, at 1:59 AM, apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > wrote:

 

I’ve logged a  <https://core.tcl-lang.org/tcl/tktview/effa2e2346> RFE to improve interp creation times by lazy loading oo. Obviously, this only benefits applications that do not use oo but I believe many, and quite possibly the majority, do not. (Most of mine do so sadly would not benefit ☹). There is an accompanying branch apn-oo-lazy-init as proof of concept.

 

>From my perspective, motivation comes from applications like web servers, where client isolation using separate interpreters would be both safer and more elegant than other approaches but suffers a significant performance loss.

 

Looking for comments and opinions on the utility of improving interp creation times as well as the lazy implementation itself.

 

/Ashok

 

 

 

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

 

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

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

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

Erik,

I now think that much of what I said about the consequences of having a
unique NSApplication object is wrong.  I think there is actually no
obstacle to implementing a send command on macOS which can send commands to
interpreters in a different Wish process.  The only problem is that no one
ever wrote such an implementation.

- Marc

On Sat, Aug 16, 2025 at 7:17 AM Marc Culler <cul...@gm...> wrote:

> Apple does provide IPC mechanisms.  I don't know whether they would be
> suitable, but I am pretty sure they would.  However, the current
> implementation of [send] does not attempt to use them.  If you look at the
> top of macosx/TkMacOSXSend.c you will see this very old comment (note that
> "gestalts" no longer exist in macOS):
>
>  *      This file provides procedures that implement the "send" command,
>  *      allowing commands to be passed from interpreter to interpreter.
> This
>  *      current implementation for the Mac has most functionality stubbed
> out.
>  *
>  *      The current plan, which we have not had time to implement, is for
> the
>  *      first Wish app to create a gestalt of type 'WIsH'. This gestalt
> will
>  *      point to a table, in system memory, of Tk apps. Each Tk app, when
> it
>  *      starts up, will register their name, and process ID, in this table.
>  *      This will allow us to implement "tk appname".
>  *
>  *      Then the send command will look up the process id of the target
> app in
>  *      this table, and send an AppleEvent to that process. The AppleEvent
>  *      handler is much like the do script handler, except that you have to
>  *      specify the name of the tk app as well, since there may be many
>  *      interps in one wish app, and you need to send it to the right one.
>  *
>  *      Implementing this has been on our list of things to do, but what
> with
>  *      the demise of Tcl at Sun, and the lack of resources at Scriptics it
>  *      may not get done for awhile. So this sketch is offered for the
> brave
>  *      to attempt if they need the functionality...
>
> - Marc
>
>
> On Sat, Aug 16, 2025 at 1:17 AM Donal Fellows <
> don...@ma...> wrote:
>
>> I would be very startled if it *isn't* the exact same issue, a
>> combination of needing a suitable IPC mechanism for doing the discovery and
>> communications, and system policy restricting access to such things even if
>> they exist.
>>
>> Donal.
>>
>> ------------------------------
>> *From:* Erik Leunissen via Tcl-Core <tcl...@li...>
>> *Sent:* Saturday, August 16, 2025 07:12
>> *To:* Marc Culler <cul...@gm...>
>> *Cc:* tcl...@li... <tcl...@li...>
>> *Subject:* Re: [TCLCORE] Advice requested regarding [send] on macOS
>>
>> Related to this matter: I noticed (in a debug statement issued by me for
>> execution at Github) that
>> interpreters in another process are not returned by [winfo interps] on
>> macOS. (See the script below
>> to verify that). I'm suspecting that this is for the
>> very same reason/cause. Can you please give your view about that
>> (confirm/deny if
>> possible) ?
>>
>>

Re: [TCLCORE] RFE: lazy loading of TclOO

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

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br id="lineBreakAtBeginningOfSignature"><div dir="ltr">What about an interpreter clone command? It would have options for the user to decide what to include or not include. For example, -noprocs, -nolibs, -nochans, -novars, etc. This way you can config an interp as you need it, then just keep making copies of it. If done right, I would think this is the most efficient way to get new configured interpreters. Probably not the easiest option to implement though.</div><div dir="ltr"><br><blockquote type="cite">On Aug 16, 2025, at 7:07 AM, Donald Porter via Tcl-Core &lt;tcl...@li...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div>Interp creation establishes a new interpreter initialized with the complete built-in command set, and includes the task of finding and sourcing the init.tcl file of the script library. &nbsp;That’s a fine default.<div><br></div><div>Ashok’s proposal preserves an illusion of that, with some commands not fully realized, but still functional. &nbsp;Lazy loading or autoloading have long been part of the Tcl baseline. &nbsp;This is just a shift of that implementation detail.</div><div><br></div><div>I think it is worth pursuing an additional option. &nbsp;Give programmers the option to create an empty interpreter — one with no commands, no variables, and only the global namespace. &nbsp;This would be a “create and fill with what you want” to be offered alongside the existing “create the standard and hack away what you find useless or dangerous”.</div><div><br></div><div>I *think* that option would create interpreters faster, but a working implementation would need to demonstrate that.<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Aug 16, 2025, at 1:59 AM, apnmbx-public--- via Tcl-Core &lt;tcl...@li...&gt; wrote:</div><br class="Apple-interchange-newline"><div><meta charset="UTF-8"><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;">I’ve logged a<span class="Apple-converted-space">&nbsp;</span><a href="https://core.tcl-lang.org/tcl/tktview/effa2e2346" style="color: rgb(70, 120, 134); text-decoration: underline;">RFE</a><span class="Apple-converted-space">&nbsp;</span>to improve interp creation times by lazy loading oo. Obviously, this only benefits applications that do not use oo but I believe many, and quite possibly the majority, do not. (Most of mine do so sadly would not benefit<span class="Apple-converted-space">&nbsp;</span><span style="font-family: &quot;Segoe UI Emoji&quot;, sans-serif;">☹</span>). There is an accompanying branch apn-oo-lazy-init as proof of concept.<o:p></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><o:p>&nbsp;</o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;">From my perspective, motivation comes from applications like web servers, where client isolation using separate interpreters would be both safer and more elegant than other approaches but suffers a significant performance loss.<o:p></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><o:p>&nbsp;</o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;">Looking for comments and opinions on the utility of improving interp creation times as well as the lazy implementation itself.<o:p></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><o:p>&nbsp;</o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;">/Ashok<o:p></o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><o:p>&nbsp;</o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><o:p>&nbsp;</o:p></div><div style="margin: 0in; font-size: 11pt; font-family: Aptos, sans-serif;"><o:p>&nbsp;</o:p></div></div><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">_______________________________________________</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;">Tcl-Core mailing list</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><a href="mailto:Tcl...@li..." style="color: rgb(70, 120, 134); text-decoration: underline; font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Tcl...@li...</a><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><a href="https://lists.sourceforge.net/lists/listinfo/tcl-core" style="color: rgb(70, 120, 134); text-decoration: underline; font-family: Helvetica; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">https://lists.sourceforge.net/lists/listinfo/tcl-core</a></div></blockquote></div><br></div><span>_______________________________________________</span><br><span>Tcl-Core mailing list</span><br><span>Tcl...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/tcl-core</span><br></div></blockquote></body></html>

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

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

Apple does provide IPC mechanisms.  I don't know whether they would be
suitable, but I am pretty sure they would.  However, the current
implementation of [send] does not attempt to use them.  If you look at the
top of macosx/TkMacOSXSend.c you will see this very old comment (note that
"gestalts" no longer exist in macOS):

 *      This file provides procedures that implement the "send" command,
 *      allowing commands to be passed from interpreter to interpreter. This
 *      current implementation for the Mac has most functionality stubbed
out.
 *
 *      The current plan, which we have not had time to implement, is for
the
 *      first Wish app to create a gestalt of type 'WIsH'. This gestalt will
 *      point to a table, in system memory, of Tk apps. Each Tk app, when it
 *      starts up, will register their name, and process ID, in this table.
 *      This will allow us to implement "tk appname".
 *
 *      Then the send command will look up the process id of the target app
in
 *      this table, and send an AppleEvent to that process. The AppleEvent
 *      handler is much like the do script handler, except that you have to
 *      specify the name of the tk app as well, since there may be many
 *      interps in one wish app, and you need to send it to the right one.
 *
 *      Implementing this has been on our list of things to do, but what
with
 *      the demise of Tcl at Sun, and the lack of resources at Scriptics it
 *      may not get done for awhile. So this sketch is offered for the brave
 *      to attempt if they need the functionality...

- Marc


On Sat, Aug 16, 2025 at 1:17 AM Donal Fellows <
don...@ma...> wrote:

> I would be very startled if it *isn't* the exact same issue, a
> combination of needing a suitable IPC mechanism for doing the discovery and
> communications, and system policy restricting access to such things even if
> they exist.
>
> Donal.
>
> ------------------------------
> *From:* Erik Leunissen via Tcl-Core <tcl...@li...>
> *Sent:* Saturday, August 16, 2025 07:12
> *To:* Marc Culler <cul...@gm...>
> *Cc:* tcl...@li... <tcl...@li...>
> *Subject:* Re: [TCLCORE] Advice requested regarding [send] on macOS
>
> Related to this matter: I noticed (in a debug statement issued by me for
> execution at Github) that
> interpreters in another process are not returned by [winfo interps] on
> macOS. (See the script below
> to verify that). I'm suspecting that this is for the
> very same reason/cause. Can you please give your view about that
> (confirm/deny if
> possible) ?
>
>

Re: [TCLCORE] RFE: lazy loading of TclOO

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

Interp creation establishes a new interpreter initialized with the complete built-in command set, and includes the task of finding and sourcing the init.tcl file of the script library.  That’s a fine default.

Ashok’s proposal preserves an illusion of that, with some commands not fully realized, but still functional.  Lazy loading or autoloading have long been part of the Tcl baseline.  This is just a shift of that implementation detail.

I think it is worth pursuing an additional option.  Give programmers the option to create an empty interpreter — one with no commands, no variables, and only the global namespace.  This would be a “create and fill with what you want” to be offered alongside the existing “create the standard and hack away what you find useless or dangerous”.

I *think* that option would create interpreters faster, but a working implementation would need to demonstrate that.

> On Aug 16, 2025, at 1:59 AM, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote:
> 
> I’ve logged a RFE <https://core.tcl-lang.org/tcl/tktview/effa2e2346> to improve interp creation times by lazy loading oo. Obviously, this only benefits applications that do not use oo but I believe many, and quite possibly the majority, do not. (Most of mine do so sadly would not benefit ☹). There is an accompanying branch apn-oo-lazy-init as proof of concept.
>  
> From my perspective, motivation comes from applications like web servers, where client isolation using separate interpreters would be both safer and more elegant than other approaches but suffers a significant performance loss.
>  
> Looking for comments and opinions on the utility of improving interp creation times as well as the lazy implementation itself.
>  
> /Ashok
>  
>  
>  
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li... <mailto:Tcl...@li...>
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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

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

On 8/16/25 08:12, Erik Leunissen via Tcl-Core wrote:
> 
> Related to this matter: I noticed (in a debug statement issued by me for execution at Github) that 
> interpreters in another process are not returned by [winfo interps] on macOS.

  (See the script below to verify that).

Forgot that, sorry. Here it is, to be used with wish (not tclsh):

tk appname foo
set fd [open "|[info nameofexecutable]" r+]
puts $fd {tk appname bar; puts [tk appname]; flush stdout}; flush $fd
set otherApp [gets $fd]
puts [winfo interps]
puts [expr {$otherApp in [winfo interps]}]

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

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

I would be very startled if it isn't the exact same issue, a combination of needing a suitable IPC mechanism for doing the discovery and communications, and system policy restricting access to such things even if they exist.

Donal.

________________________________
From: Erik Leunissen via Tcl-Core <tcl...@li...>
Sent: Saturday, August 16, 2025 07:12
To: Marc Culler <cul...@gm...>
Cc: tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] Advice requested regarding [send] on macOS

Related to this matter: I noticed (in a debug statement issued by me for execution at Github) that
interpreters in another process are not returned by [winfo interps] on macOS. (See the script below
to verify that). I'm suspecting that this is for the
very same reason/cause. Can you please give your view about that (confirm/deny if
possible) ?

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

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

On 8/15/25 19:53, Marc Culler wrote:

> Hi Erik,
> 
> Yes, I think it is correct that macOS does not support sending to a different process.  It supports 
> sending to a different interpreter running in the same process.  On macOS a Tk "application" is an 
> interpreter, not a process.
> 

Hi Marc,

Thanks for the response/clarity,

This means to me that tests send-8.18 and send-8.19 ought be skipped for macOS (at
least for aqua), and that development of the project where the test failures
showed up can proceed. But, I think, best after importing a bug ticket/fix for this
issue.

I've filed a fossil bug ticket (#9ba9729ef1) that addresses these tests and the lack
of documentation regarding the limitation on macOS. I'll propose fixes/improvements
there.

Related to this matter: I noticed (in a debug statement issued by me for execution at Github) that 
interpreters in another process are not returned by [winfo interps] on macOS. (See the script below 
to verify that). I'm suspecting that this is for the
very same reason/cause. Can you please give your view about that (confirm/deny if
possible) ?

If my suspicion is right, then I can piggyback a correction for the "winfo interps"
behaviour on macOS in the same bug ticket/patch, and also make testing of this command in 
"winfo.test" more complete.

For follow-up (fixes/proposals and the remaining question about XQuartz), please see
the ticket. I hope you're willing to partake in review/considerations there.

Thanks in advance,
Erik.
--

> When Tk starts it must create an NSApplication object in order to be able to process events and draw 
> on the screen.  There is only one instance of the NSApplication class allowed per process.  Its 
> address is stored in a global variable NSApp.  There are also restrictions requiring some methods of 
> Cocoa objects to be called only from the main thread.  I believe that only the main thread has 
> access to Apple's NSEvent queue.
> 
> Apple says "The main thread of the application is responsible for handling events. Although the 
> Application Kit continues to work if other threads are involved in the event path, operations can 
> occur out of sequence."
> 

 From the pure logic of this text I understand that this further explains/corroborates the observed 
limitation on macOS. But I don't have enough macOS context (or maybe it's objective C context) to be 
able to slot in the specific NS* terminology. Which
simply means that your help in the matter is most welcome/needed !


> - Marc
> 

[TCLCORE] RFE: lazy loading of TclOO

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

I’ve logged a RFE <https://core.tcl-lang.org/tcl/tktview/effa2e2346>  to improve interp creation times by lazy loading oo. Obviously, this only benefits applications that do not use oo but I believe many, and quite possibly the majority, do not. (Most of mine do so sadly would not benefit ☹). There is an accompanying branch apn-oo-lazy-init as proof of concept.

 

>From my perspective, motivation comes from applications like web servers, where client isolation using separate interpreters would be both safer and more elegant than other approaches but suffers a significant performance loss.

 

Looking for comments and opinions on the utility of improving interp creation times as well as the lazy implementation itself.

 

/Ashok

 

 

 

[TCLCORE] Tcl/Tk 8.6.17 RELEASED

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

Tcl/Tk 8.6.17 Release Announcement
August 15, 2025

The Tcl Core Team is pleased to announce the 8.6.17 releases of the Tcl
dynamic language and the Tk toolkit.  This is the seventeenth patch release
of Tcl/Tk 8.6.  More details can be found below.

We would like to express our gratitude to all those who submit bug
reports and patches.  This information is invaluable in enabling us
to identify and eliminate problems in the core. Such reports can be
submitted here.

         https://core.tcl-lang.org/tcl/ticket
         https://core.tcl-lang.org/tk/ticket

We ask that you log in (anonymous if you wish) to create tickets.
This deters abuse of the ticketing system:

         https://core.tcl-lang.org/tcl/login
         https://core.tcl-lang.org/tcl/login

Where to get the new releases:
------------------------------

Tcl/Tk 8.6.17 sources are freely available as open source from the Tcl
SourceForge project's file distribution area:

         http://sourceforge.net/projects/tcl/files/

This distribution is source code only.  We keep links to some third
parties offering pre-built binaries for various systems here:

         http://www.tcl-lang.org/software/tcltk/bindist.html

Tcl/Tk 9 releases:
------------------

The latest stable releases of Tcl and Tk are versions 9.0.2, released
July 2, 2025.  Users of Tcl/Tk 8.6 are encouraged to migrate to the
new releases, where continued development efforts are focused.

For additional information:
---------------------------

Please visit the Tcl Developer Xchange web site:

         http://www.tcl-lang.org/

This site contains a variety of information about Tcl/Tk in general, the
core Tcl and Tk distributions, Tcl development tools, and much more.

Summary of Changes since Tcl/Tk 8.6.16:
--------------------------------------

This is a patch release, so it primarily includes bug fixes and corrections
to erratic behavior.  Highlighted changes are noted below.  The changes file
at the root of the source tree contains a more complete list.  The Timelines
of all changes are online.

     http://core.tcl-lang.org/tcl/timeline
     http://core.tcl-lang.org/tk/timeline

    * Win: support PNG images in icon files.

    * Aqua: dark mode improvements.

    * Aqua: interop with clipboard managers.

    * Win: [exec] now dispatches App Execution Aliases.

    * Win: [auto_execok] recognizes more shell commands.

    * encoding cp864: missing Euro/Tail-sign.

    * Corrections to zh_cn message catalog for Tk console menu.

    * Fix crashes or hangs or undefined behavior in...
       - Tcl_SplitList on string that exceeds max list size
       - Win: Use-after-free memory corruption in multi-thread [glob].
       - macOs: Pointer alignment in file attribute functions
       - Aqua: tk_getOpenFile
       - div by zero in [$scale get $x $y] when trough resized to invisibility.

    * Correct failure in [namespace children $ns $nonGlob].

    * Number parsing failure: [scan "1.[string repeat 1 191]e-321" %g]

    * block cursor size on a tab is too large.

    * Win: incorrect system menu entries for transient toplevels

    * Win: withdrawn transient windows can reappear in taskbar preview.

    * Win: misplaced underline in menu entry

    * Aqua: cannot iconify all windows.

    * Aqua: wm-iconbitmap-{1.4,2.1}, uniwWm-22.3

    * Nested [return -options], cmdMZ-return-2.{19,20,21}.

    * errorline into errorinfo from [$interp eval $script], interp-26.9.

    * Updated bundled packages, libraries, standards, data
       - Itcl 4.3.4
       - sqlite3 3.50.4
       - Thread 2.8.12
       - TDBC* 1.1.12
       - tcltest 2.5.10
       - dde 1.4.5
       - tzdata 2025b
--
Tcl Core Team and Maintainers
Don Porter, Tcl Core Release Manager

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

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

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

Hi Erik,

Yes, I think it is correct that macOS does not support sending to a
different process.  It supports sending to a different interpreter running
in the same process.  On macOS a Tk "application" is an interpreter, not a
process.

When Tk starts it must create an NSApplication object in order to be able
to process events and draw on the screen.  There is only one instance of
the NSApplication class allowed per process.  Its address is stored in a
global variable NSApp.  There are also restrictions requiring some methods
of Cocoa objects to be called only from the main thread.  I believe that
only the main thread has access to Apple's NSEvent queue.

Apple says "The main thread of the application is responsible for handling
events. Although the Application Kit continues to work if other threads are
involved in the event path, operations can occur out of sequence."

- Marc

On Fri, Aug 15, 2025 at 5:19 AM Erik Leunissen via Tcl-Core <
tcl...@li...> wrote:

> L.S.
>
> My direct question is:
>
> Does macOS support communicating between two interpreters that exist in
> different
> processes, using the Tk command [send] ?
> a. under aqua
> b. under XQuartz
>
>
> Here is the background:
>
> While working on the Tk test suite in project
> simplify_test_utils_for_singleproc_1,
> I made a change that involves the creation of child interpreters in a new
> process.
> That change works fine on all platforms, and doesn't affect the many tests
> that
> use this code.
>
> However, after this change the tests send-8.18 and send-8.19 suddenly fail,
> on macOS only. See at Github [*]:
>
>      https://github.com/tcltk/tk/actions/runs/16958125071/job/48064317915
>
> Please note that the change that I made does not affect [send] or the
> ability
> to use [send] in general [**]. It's just these two extra failing tests on
> macOS.
>
> While searching for the cause of the issue (and already having started a
> first
> debug session), I stumbled over this comment in the test file send.test:
>
>       "#macOS does not send to other processes"
>
> See:
>
> https://core.tcl-lang.org/tk/file?ci=24113d640afeebe2&name=tests%2Fsend.test&ln=185
>
> If that statement is true, than that explains the test failures [***],
> because
> indeed, the two problematic tests do attempt to send to an interpreter in
> another
> process.
>
> However, being unfamiliar with macOS, I'm unsure, especially about the
> difference
> between aqua and XQuartz in this respect. Regarding the latter, the Tcl
> Wiki [****]
> says:
>
>      "The Tk send command depends on working with an X server and thus
> does not
>       work normally on Windows or MacOS."
>
> But this statement doesn't address the case of interpreters in different
> processes.
>
> The answer to my question would be most important to me because I have no
> macOS
> machine available at home to exercise or run tests on. So I'm not in a
> position
> to find such things out for myself.
>
> I'd appreciate very much the your insight,
> Erik Leunissen
>
> --
> [*]    You need to be logged in there.
> [**]   As witnessed by the flawless passing of the many relevant tests
> under
>         Linux, Windows (and macOS at Github).
> [***]  What I don't understand in that case, is that these tests have
> always passed
>         before I changed the code. But I'll gladly forget about that.
> [****] https://wiki.tcl-lang.org/page/send
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

[TCLCORE] Advice requested regarding [send] on macOS

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

L.S.

My direct question is:

Does macOS support communicating between two interpreters that exist in different
processes, using the Tk command [send] ?
a. under aqua
b. under XQuartz


Here is the background:

While working on the Tk test suite in project simplify_test_utils_for_singleproc_1,
I made a change that involves the creation of child interpreters in a new process.
That change works fine on all platforms, and doesn't affect the many tests that
use this code.

However, after this change the tests send-8.18 and send-8.19 suddenly fail,
on macOS only. See at Github [*]:

     https://github.com/tcltk/tk/actions/runs/16958125071/job/48064317915

Please note that the change that I made does not affect [send] or the ability
to use [send] in general [**]. It's just these two extra failing tests on macOS.

While searching for the cause of the issue (and already having started a first
debug session), I stumbled over this comment in the test file send.test:

      "#macOS does not send to other processes"

See:
         https://core.tcl-lang.org/tk/file?ci=24113d640afeebe2&name=tests%2Fsend.test&ln=185

If that statement is true, than that explains the test failures [***], because
indeed, the two problematic tests do attempt to send to an interpreter in another
process.

However, being unfamiliar with macOS, I'm unsure, especially about the difference
between aqua and XQuartz in this respect. Regarding the latter, the Tcl Wiki [****]
says:

     "The Tk send command depends on working with an X server and thus does not
      work normally on Windows or MacOS."

But this statement doesn't address the case of interpreters in different processes.

The answer to my question would be most important to me because I have no macOS
machine available at home to exercise or run tests on. So I'm not in a position
to find such things out for myself.

I'd appreciate very much the your insight,
Erik Leunissen

--
[*]    You need to be logged in there.
[**]   As witnessed by the flawless passing of the many relevant tests under
        Linux, Windows (and macOS at Github).
[***]  What I don't understand in that case, is that these tests have always passed
        before I changed the code. But I'll gladly forget about that.
[****] https://wiki.tcl-lang.org/page/send

Re: [TCLCORE] Tcl/Tk 8.6.17 Release Candidates

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

Everything fine using macOS and Linux (Suse 15.5, Debian 12.0).
Sorry, no Windows results this time. My Windows machine is dead .-(

Paul

Am 13.08.2025 um 22:02 schrieb Donald G Porter via Tcl-Core:
>
> Now available at
>
> https://sourceforge.net/projects/tcl/files/Tcl/8.6.17/
>
> are RC1 candidate source code distribution pre-releases of Tcl and Tk 8.6.17.
>
> These are the second candidate releases leading to the release of Tcl/Tk 8.6.17.
> The target date for release is August 15, 2025.
>
> The Tcl pre-release includes a pre-release of the package Thread 2.8.12,
> The released packages Itcl 4.3.4, TDBC* 1.1.12, and sqlite3 3.50.4 are also included.
>
> Compared to the previous release candidates, both Tcl and Tk include a handful of
> new bug and build fixes.
>
> Please test these candidates on your platforms and report any blocking issues
> you discover.
>
> Thank you for your contributions and assistance.
>

Re: [TCLCORE] Tcl/Tk 8.6.17 Release Candidates

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

Summary
=======
No blocking issues, just some compile-stage warnings:

- regular build for x86_64-linux on x86_64-linux: 2 compile warnings for Tk (when using optimization 
-O3). Build completed.
- cross-build for x86_64-mingw32 on x86_64-linux: 2 compile warnings for Tk (when using optimization 
-O3). Build completed.

Compile warnings appended.

Regards,
Erik.
--
Compile warnings

For Tk 2 compiler warnings, x86_64-linux:

/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c: In function ‘TkPostscriptImage’:
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1197:37: warning: ‘cdata.blue_mask’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetBValue(rgb) ((rgb & cdata->blue_mask) >> cdata->blue_shift)
                                      ^~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1275:20: note: ‘cdata.blue_mask’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1196:37: warning: ‘cdata.green_mask’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetGValue(rgb) ((rgb & cdata->green_mask) >> cdata->green_shift)
                                      ^~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1275:20: note: ‘cdata.green_mask’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1195:37: warning: ‘cdata.red_mask’ may be 
used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetRValue(rgb) ((rgb & cdata->red_mask) >> cdata->red_shift)
                                      ^~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1275:20: note: ‘cdata.red_mask’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1197:50: warning: ‘cdata.blue_shift’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetBValue(rgb) ((rgb & cdata->blue_mask) >> cdata->blue_shift)
                                                   ^~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1275:20: note: ‘cdata.blue_shift’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1195:49: warning: ‘cdata.red_shift’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetRValue(rgb) ((rgb & cdata->red_mask) >> cdata->red_shift)
                                                  ^~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1275:20: note: ‘cdata.red_shift’ was 
declared here
      TkColormapData cdata;
                     ^~~~~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1196:51: warning: ‘cdata.green_shift’ may 
be used uninitialized in this function [-Wmaybe-uninitialized]
  #define GetGValue(rgb) ((rgb & cdata->green_mask) >> cdata->green_shift)
                                                    ^~
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkCanvPs.c:1275:20: note: ‘cdata.green_shift’ was 
declared here
      TkColormapData cdata;
                     ^~~~~

-- AND --

/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkTextImage.c: In function ‘EmbImageDisplayProc’:
/usr/local/src/SOURCES/tk8.6.17/unix/../generic/tkTextImage.c:669:5: warning: ‘imageY’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
      Tk_RedrawImage(image, 0, 0, width, height, dst, imageX, imageY);
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- end compiler warnings, Tk, for x86_64-linux on x86_64-linux --

/usr/local/src/SOURCES/tk8.6.17/generic/tkImgGIF.c: In function 'Compress.constprop':
cc1: warning: '__builtin_memset' offset [-25769803700, -64] is out of the bounds [0, 40360] of 
object 'state' with type 'GIFState_t' {aka 'struct <anonymous>'} [-Warray-bounds]
/usr/local/src/SOURCES/tk8.6.17/generic/tkImgGIF.c:1999:16: note: 'state' declared here
  1999 |     GIFState_t state;
       |                ^~~~~
cc1: warning: '__builtin_memset' offset [-25769803700, -64] is out of the bounds [0, 40360] of 
object 'state' with type 'GIFState_t' {aka 'struct <anonymous>'} [-Warray-bounds]

-- AND --

/usr/local/src/SOURCES/tk8.6.17/generic/tkTextImage.c: In function 'EmbImageDisplayProc':
/usr/local/src/SOURCES/tk8.6.17/generic/tkTextImage.c:669:5: warning: 'imageY' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
   669 |     Tk_RedrawImage(image, 0, 0, width, height, dst, imageX, imageY);
       |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- end compiler warnings, Tk, for x86_64-mingw32 on x86_64-linux --

Re: [TCLCORE] TIP 726 - looking for comments

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

Heads up: CFV for TIP 726 coming up in a couple of days.

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Sunday, July 27, 2025 11:03 PM
To: tcl...@li...
Subject: Re: [TCLCORE] TIP 726 - looking for comments

 

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

 

/Ashok

 

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

 

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

 

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

 

/Ashok

 

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

 

Hi Ashok,

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

For me, this all sounds reasonable.

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

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

languages.

Also, the reasoning for the library choice looks good.

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

 

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

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

alternatives in an own section at the bottom.

 

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

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

syntax is the main point of the TIP.

 

Thanks for all, GREAT !

Harald

 

 

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

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

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

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

> 

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

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

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

> utf8proc library from Julia.

> 

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

> placement are preferred sooner than later.

> 

> /Ashok

> 

> 

> 

> _______________________________________________

> Tcl-Core mailing list

>  <mailto:Tcl...@li...> Tcl...@li...

>  <https://lists.sourceforge.net/lists/listinfo/tcl-core> https://lists.sourceforge.net/lists/listinfo/tcl-core

 

 

-- 

ELMICRON Dr. Harald Oehlmann GmbH

Koesener Str. 85

06618 NAUMBURG - Germany

Phone: +49 3445 781120

Direct: +49 3445 781127

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

German legal references:

Geschaeftsfuehrer: Dr. Harald Oehlmann

UST Nr. / VAT ID No.: DE206105272

HRB 212803 Stendal

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

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

On 08/14/2025 08:47 AM, apn...@ya... wrote:

> Not commenting on the pros and cons of 509, but rather that it exchanges
> deadlocks for corruption. Am I incorrect ?

Yes, indeedly. We had to choose between a rock and a hard place.

BR,
Christian

Re: [TCLCORE] Tcl/Tk 8.6.17 Release Candidates

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

Am 13.08.2025 um 22:02 schrieb Donald G Porter via Tcl-Core:
> 
> Now available at
> 
> https://sourceforge.net/projects/tcl/files/Tcl/8.6.17/
> 
> are RC1 candidate source code distribution pre-releases of Tcl and Tk 
> 8.6.17.

Thanks Don & Team,here is the report on archaic MS-VC6 32 bit on MS-WS 
11 64 bit.
As in the past, some people cared, here is the report.
It can be ignored as always.
There are compilation warnings and one test failure below

Thanks for all,
Harald

Compilation:

C:\test\tcl8.6.17\tcl8.6.17\win\..\generic\tclProc.c(2275) : warning 
C4550: expression evaluates to a function which is missing an argument list

C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(2720) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(4050) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(4095) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(1474) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(4530) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(4550) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(4588) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(4646) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(5297) 
: warning C4761: integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tcl8.6.17\pkgs\tdbcodbc1.1.12\win\..\generic\tdbcodbc.c(5489) 
: warning C4761: integral size mismatch in argument; conversion supplied

C:\test\tcl8.6.17\tk8.6.17\win\..\generic\tkCanvas.c(4241) : warning 
C4022: 'memcpy' : pointer mismatch for actual parameter 1

C:\test\tcl8.6.17\tk8.6.17\win\..\win\tkWinFont.c(1499) : warning C4761: 
integral size mismatch in argument; conversion supplied
C:\test\tcl8.6.17\tk8.6.17\win\..\win\tkWinFont.c(1521) : warning C4761: 
integral size mismatch in argument; conversion supplied

C:\test\tcl8.6.17\tk8.6.17\win\..\generic\ttk\ttkFrame.c(175) : warning 
C4005: 'DEFAULT_BORDERWIDTH' : macro redefinition
  
C:\test\tcl8.6.17\tk8.6.17\win\..\generic\ttk\ttkClassicTheme.c(0) : see 
previous definition of 'DEFAULT_BORDERWIDTH'



SQLite does not compile. This is known and ok.

Tests:
Test failures: "exec-bug-4f0b5767ac exec App Execution Alias"

==== exec-bug-4f0b5767ac exec App Execution Alias FAILED
==== Contents of test case:

     exec winget --info

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: couldn't execute "winget": no such file or directory
     while executing
"exec winget --info"
     ("uplevel" body line 2)
     invoked from within
"uplevel 1 $script"
---- errorCode: POSIX ENOENT {no such file or directory}
==== exec-bug-4f0b5767ac FAILED

Re: [TCLCORE] Tcl/Tk 8.6.17 Release Candidates

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

Win 10, Visual Studio 2022, x64, x86 Tcl+pkgs, Tk - passed
Ubuntu 20 x64 Tcl+pkgs - passed

-----Original Message-----
From: Donald G Porter via Tcl-Core <tcl...@li...> 
Sent: Thursday, August 14, 2025 1:32 AM
To: Tcl List Core <tcl...@li...>
Subject: [TCLCORE] Tcl/Tk 8.6.17 Release Candidates


Now available at

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

are RC1 candidate source code distribution pre-releases of Tcl and Tk
8.6.17.

These are the second candidate releases leading to the release of Tcl/Tk
8.6.17.
The target date for release is August 15, 2025.

The Tcl pre-release includes a pre-release of the package Thread 2.8.12,
The released packages Itcl 4.3.4, TDBC* 1.1.12, and sqlite3 3.50.4 are also
included.

Compared to the previous release candidates, both Tcl and Tk include a
handful of
new bug and build fixes.

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



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

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

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

chw wrote:
> Let me politely express my impressions: TIP#509 although positively voted,
was a mistake.

Can't comment on introduction of recursive mutexes as to whether useful or
not, but reading the TIP it seems to me it did not serve the original
purpose of solving deadlocks with respect to signal handlers.

Or to be precise, hasn't the deadlock problem been solved at the expense of
data corruption?

The main thread holds a mutex to ensure exclusive access to the protected
data while it is being manipulated. If the signal handler runs while the
main thread is still in the process of modifying it, and gets the recursive
lock, isn't that presumption of exclusive access broken leading to potential
corruption with the signal handler working with data that may not be in a
consistent state?

Not commenting on the pros and cons of 509, but rather that it exchanges
deadlocks for corruption. Am I incorrect ?

/Ashok

-----Original Message-----
From: Christian Werner <Chr...@t-...> 
Sent: Wednesday, August 13, 2025 11:31 PM
To: tcl...@li...
Subject: Re: [TCLCORE] Review of branch bug-87b69745be

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.

Just some thoughts of a Windows noob,
Christian


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