tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] CFV: TIP 726

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

Op di 19 aug 2025 om 10:49 schreef Jan Nijtmans:
> My vote.
>
> TIP #726   YES

Some more minor review remarks:
1)  UNICODE_OUT_OF_RANGE can be completely eliminated, because
     utf8proc_category() already checks if its parameter is out of range.
2)  Right-shifts are more efficient here than left-shifts: It saves a
     '!='-operator in the implementation. The original code did
     that already. You removed a comment saying that :-)

See:
      https://core.tcl-lang.org/tcl/info/453ab178cb1751b7

Regards,
       Jan Nijtmans

Re: [TCLCORE] Thanks for great toggleswitch widget

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

Hi Csaba,
thanks, great, I appreciate.
Have tested all this, looks great! Corrected a bit the manpage syntax.

Thanks for all,
Harald

Am 29.08.2025 um 10:59 schrieb Csaba Nemethi:
> Hi Harald,
> 
> Many thanks for your comments!
> 
> what you wrote regarding the -size option is probably worth mentioning 
> both in the TIP and in the manual.  I will add it to both.
> 
> To the internal commands:  The ttk_scrollbar man page documents the 
> delta and fraction subcommands in an "INTERNAL COMMANDS" section and 
> mentions that they are used internally by the TScrollbar widget class 
> bindings.  The ttk_toggleswitch man page does the same with the internal 
> commands get, send, and xcoord: it describes them in an "INTERNAL 
> COMMANDS" section and mentions that they are used internally by the 
> Toggleswitch widget class bindings.  Consequently, I don't see the need 
> for any change in this respect.
> 
> Best regards,
> 
> Csaba
> 
> 
> Am 29.08.25 um 09:44 schrieb Harald Oehlmann:
>> Dear Csaba,
>> thanks for the great toggleswitch proposal in the core, I really 
>> appreciate. A dream gets true !
>>
>> Please allow me to add some information from the conference:
>>
>> The size 1,2,3 options are quite common on other platforms.
>> The MAC has this on the native widgets. That is the reason why it is 
>> in the proposal.
>>
>> Questions from my side on the TIP:
>>
>> The internal commands: "get, set, xcoord" are probably also useful 
>> from the outside and are probably used in the bindings.
>> Does the following proposal makes sense:
>> - wether have them in "public" state, documented etc
>> - or have them clearly marked as internal, for example by a leading 
>> "_" in the function name.
>>
>> I am ready at any time to sponsor this TIP.
>>
>> Thanks for all,
>> Harald

Re: [TCLCORE] Thanks for great toggleswitch widget

[Csaba N. <csa...@t-...>]

Hi Harald,

Many thanks for your comments!

what you wrote regarding the -size option is probably worth mentioning 
both in the TIP and in the manual.  I will add it to both.

To the internal commands:  The ttk_scrollbar man page documents the 
delta and fraction subcommands in an "INTERNAL COMMANDS" section and 
mentions that they are used internally by the TScrollbar widget class 
bindings.  The ttk_toggleswitch man page does the same with the internal 
commands get, send, and xcoord: it describes them in an "INTERNAL 
COMMANDS" section and mentions that they are used internally by the 
Toggleswitch widget class bindings.  Consequently, I don't see the need 
for any change in this respect.

Best regards,

Csaba


Am 29.08.25 um 09:44 schrieb Harald Oehlmann:
> Dear Csaba,
> thanks for the great toggleswitch proposal in the core, I really 
> appreciate. A dream gets true !
> 
> Please allow me to add some information from the conference:
> 
> The size 1,2,3 options are quite common on other platforms.
> The MAC has this on the native widgets. That is the reason why it is in 
> the proposal.
> 
> Questions from my side on the TIP:
> 
> The internal commands: "get, set, xcoord" are probably also useful from 
> the outside and are probably used in the bindings.
> Does the following proposal makes sense:
> - wether have them in "public" state, documented etc
> - or have them clearly marked as internal, for example by a leading "_" 
> in the function name.
> 
> I am ready at any time to sponsor this TIP.
> 
> Thanks for all,
> Harald
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

-- 
Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...

[TCLCORE] Thanks for great toggleswitch widget

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

Dear Csaba,
thanks for the great toggleswitch proposal in the core, I really 
appreciate. A dream gets true !

Please allow me to add some information from the conference:

The size 1,2,3 options are quite common on other platforms.
The MAC has this on the native widgets. That is the reason why it is in 
the proposal.

Questions from my side on the TIP:

The internal commands: "get, set, xcoord" are probably also useful from 
the outside and are probably used in the bindings.
Does the following proposal makes sense:
- wether have them in "public" state, documented etc
- or have them clearly marked as internal, for example by a leading "_" 
in the function name.

I am ready at any time to sponsor this TIP.

Thanks for all,
Harald

Re: [TCLCORE] New implementation of send for macOS

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

Hi Kevin,

Thanks for testing!  I can't explain why I did not see that crash when I
was running those commands, but I was able to reproduce it and I have
pushed a fix.  Would you please pull the fix and try again?

Thanks.

- Marc

On Thu, Aug 28, 2025 at 9:23 PM Kevin Walzer <kw...@co...> wrote:

> Hi Marc,
>
> Trying your tests below I am getting a segfault:  Thread 0 Crashed::
> Dispatch queue: com.apple.main-thread
> 0   Tcl                                      0x101232820 TclpFree + 60
> 1   Tcl                                      0x10123d344 Tcl_DStringFree +
> 36
> 2   Tk                                       0x100b9cb20 0x100aa8000 +
> 1002272
> 3   Tcl                                      0x101145d18 0x101128000 +
> 122136
> 4   Tcl                                      0x101144448 Tcl_EvalObjEx +
> 112
> 5   Tcl                                      0x1011dfa98
> Tcl_RecordAndEvalObj + 484
> 6   Tcl                                      0x1011df878 Tcl_RecordAndEval
> + 76
> 7   Tk                                       0x100ad1ab0 0x100aa8000 +
> 170672
> 8   Tcl                                      0x1011f0820 Tcl_NotifyChannel
> + 304
> 9   Tcl                                      0x101277c10 0x101128000 +
> 1375248
> 10  Tcl                                      0x1012100f8 Tcl_ServiceEvent
> + 180
> 11  Tcl                                      0x1012103f8 Tcl_DoOneEvent +
> 316
> 12  Tk                                       0x100ac2f10 Tk_MainLoop + 48
> 13  Tk                                       0x100ad1910 Tk_MainEx + 1448
> 14  Wish                                     0x100a9b988 0x100a98000 +
> 14728
> 15  dyld                                     0x194e4ab98 start + 6076
>
> Sorry,
>
> Kevin
> On 8/28/25 11:15 AM, Marc Culler wrote:
>
> Thanks Kevin.  No rush.
>
> - Marc
>
> On Thu, Aug 28, 2025 at 9:18 AM Kevin Walzer <kw...@co...> wrote:
>
>> Hi Marc- I will review this weekend. Knee-deep in the accessibility work
>> ATM.
>>
>> On Aug 27, 2025, at 2:12 PM, Marc Culler <cul...@gm...> wrote:
>>
>> 
>> I have just pushed a new branch, *mac_send*, containing a nearly
>> complete full implementation of the send command for macOS.  In particular,
>> it allows sending commands to interpreters in other processes.  I think it
>> is now in a state where it can be tested, and I hope people will do that.
>>
>> *Two key points:*
>>
>> 1. (ATTN: Kevin Walzer). The implementation uses AppleEvents.  In fact,
>> it uses the current DoScript handler when sending commands to
>> other processes.  Essentially, the send command is providing a Tk-based
>> tool for sending AppleEvents (specifically, DoScript events) without
>> depending external tools like Script Editor or osascript.  So it is
>> simplifying access to native IPC methods.
>>
>> 2. (ATTN: Peter da Silva and Christian Werner) While commands can be sent
>> to other processes, they can only be sent to processes owned by the same
>> user on the same host.)
>>
>> *A simple test:*
>> * Open three Terminals and start wish9.,1 in each terminal.
>> * In the last Terminal, which has appname Wish #3, run these commands:
>> % tk appname
>> Wish #3
>> % send Wish {wm geometry . +500+100}
>> % send Wish {wm geometryxx . +600+100}
>> % send Wish {send {Wish #2} {wm geometry . +900+100}}
>> % send Wish {puts hello}
>> % send Wish {send {Wish #2} {puts hello}}
>>
>>
>> *What is missing: *Error handling is incomplete.  Also, after running
>> the tests above you will not that when sending {puts hello} the word
>> "hello" is printed twice in the basic case and four times when sending the
>> command recursively through two interpreters.  This is not a bug in the
>> send implementation.  The same happens with osascript.
>>
>>
>> *Implementation details: *Besides the use of AppleEvents, the main
>> difference is that the registry of appnames is stored in a file in the
>> user's /Library/Caches directory while the unix implementation stores the
>> registry in an XProperty.  The file simply contains a JSON serialization of
>> an NSMutableDictionary mapping appnames to pids.  The unix implementation
>> contains a lot of code for parsing custom serialization formats in the
>> XProperty byte sequence.  The mac implementation can use higher level tools
>> provided in the Objective C runtime.
>>
>> - Marc
>>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>>

Re: [TCLCORE] New implementation of send for macOS

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

Hi Marc,

Trying your tests below I am getting a segfault:  Thread 0 Crashed::  
Dispatch queue: com.apple.main-thread
0   Tcl                                      0x101232820 TclpFree + 60
1   Tcl                                      0x10123d344 Tcl_DStringFree 
+ 36
2   Tk                                       0x100b9cb20 0x100aa8000 + 
1002272
3   Tcl                                      0x101145d18 0x101128000 + 
122136
4   Tcl                                      0x101144448 Tcl_EvalObjEx + 112
5   Tcl                                      0x1011dfa98 
Tcl_RecordAndEvalObj + 484
6   Tcl                                      0x1011df878 
Tcl_RecordAndEval + 76
7   Tk                                       0x100ad1ab0 0x100aa8000 + 
170672
8   Tcl                                      0x1011f0820 
Tcl_NotifyChannel + 304
9   Tcl                                      0x101277c10 0x101128000 + 
1375248
10  Tcl                                      0x1012100f8 
Tcl_ServiceEvent + 180
11  Tcl                                      0x1012103f8 Tcl_DoOneEvent 
+ 316
12  Tk                                       0x100ac2f10 Tk_MainLoop + 48
13  Tk                                       0x100ad1910 Tk_MainEx + 1448
14  Wish                                     0x100a9b988 0x100a98000 + 14728
15  dyld                                     0x194e4ab98 start + 6076

Sorry,

Kevin

On 8/28/25 11:15 AM, Marc Culler wrote:
> Thanks Kevin.  No rush.
>
> - Marc
>
> On Thu, Aug 28, 2025 at 9:18 AM Kevin Walzer <kw...@co...> wrote:
>
>     Hi Marc- I will review this weekend. Knee-deep in the
>     accessibility work ATM.
>
>>     On Aug 27, 2025, at 2:12 PM, Marc Culler <cul...@gm...> wrote:
>>
>>     
>>     I have just pushed a new branch, /mac_send/, containing a nearly
>>     complete full implementation of the send command for macOS.  In
>>     particular, it allows sending commands to interpreters in
>>     other processes.  I think it is now in a state where it can be
>>     tested, and I hope people will do that.
>>
>>     *Two key points:*
>>
>>     1. (ATTN: Kevin Walzer). The implementation uses AppleEvents.  In
>>     fact, it uses the current DoScript handler when sending commands
>>     to other processes. Essentially, the send command is providing a
>>     Tk-based tool for sending AppleEvents (specifically, DoScript
>>     events) without depending external tools like Script Editor or
>>     osascript.  So it is simplifying access to native IPC methods.
>>
>>     2. (ATTN: Peter da Silva and Christian Werner) While commands can
>>     be sent to other processes, they can only be sent to processes
>>     owned by the same user on the same host.)
>>
>>     *A simple test:*
>>     * Open three Terminals and start wish9.,1 in each terminal.
>>     * In the last Terminal, which has appname Wish #3, run these
>>     commands:
>>     % tk appname
>>     Wish #3
>>     % send Wish {wm geometry . +500+100}
>>     % send Wish {wm geometryxx . +600+100}
>>     % send Wish {send {Wish #2} {wm geometry . +900+100}}
>>     % send Wish {puts hello}
>>     % send Wish {send {Wish #2} {puts hello}}
>>
>>     *What is missing:
>>     *Error handling is incomplete.  Also, after running the tests
>>     above you will not that when sending {puts hello} the word
>>     "hello" is printed twice in the basic case and four times when
>>     sending the command recursively through two interpreters.  This
>>     is not a bug in the send implementation.  The same happens with
>>     osascript.
>>
>>     *Implementation details:
>>     *Besides the use of AppleEvents, the main difference is that the
>>     registry of appnames is stored in a file in the user's
>>     /Library/Caches directory while the unix implementation stores
>>     the registry in an XProperty.  The file simply contains a JSON
>>     serialization of an NSMutableDictionary mapping appnames to
>>     pids.  The unix implementation contains a lot of code for parsing
>>     custom serialization formats in the XProperty byte sequence.  The
>>     mac implementation can use higher level tools provided in the
>>     Objective C runtime.
>>
>>     - Marc
>>
>>
>>     _______________________________________________
>>     Tcl-Core mailing list
>>     Tcl...@li...
>>     https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Crash with fossil pull

[Richard H. <dr...@sq...>]

A more detailed explanation of the Fossil bug that caused the
resent Tk sync problem can be seen at <https://fossil-scm.org/forum/forumpost/58bfd733d6>.

--
D. Richard Hipp
dr...@sq...

Re: [TCLCORE] CFV: TIP 726

[Rolf A. <tcl...@po...>]

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


My vote: Yes

Basically.

rolf

Re: [TCLCORE] New implementation of send for macOS

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

Hi Marc- I will review this weekend. Knee-deep in the accessibility work ATM. 

> On Aug 27, 2025, at 2:12 PM, Marc Culler <cul...@gm...> wrote:
> 
> 
> I have just pushed a new branch, mac_send, containing a nearly complete full implementation of the send command for macOS.  In particular, it allows sending commands to interpreters in other processes.  I think it is now in a state where it can be tested, and I hope people will do that.
> 
> Two key points:
> 
> 1. (ATTN: Kevin Walzer). The implementation uses AppleEvents.  In fact, it uses the current DoScript handler when sending commands to other processes.  Essentially, the send command is providing a Tk-based tool for sending AppleEvents (specifically, DoScript events) without depending external tools like Script Editor or osascript.  So it is simplifying access to native IPC methods.
> 
> 2. (ATTN: Peter da Silva and Christian Werner) While commands can be sent to other processes, they can only be sent to processes owned by the same user on the same host.)
> 
> A simple test:
> * Open three Terminals and start wish9.,1 in each terminal.
> * In the last Terminal, which has appname Wish #3, run these commands:
> % tk appname
> Wish #3
> % send Wish {wm geometry . +500+100}
> % send Wish {wm geometryxx . +600+100}
> % send Wish {send {Wish #2} {wm geometry . +900+100}}
> % send Wish {puts hello}
> % send Wish {send {Wish #2} {puts hello}}
> 
> What is missing:
> Error handling is incomplete.  Also, after running the tests above you will not that when sending {puts hello} the word "hello" is printed twice in the basic case and four times when sending the command recursively through two interpreters.  This is not a bug in the send implementation.  The same happens with osascript.
> 
> Implementation details:
> Besides the use of AppleEvents, the main difference is that the registry of appnames is stored in a file in the user's /Library/Caches directory while the unix implementation stores the registry in an XProperty.  The file simply contains a JSON serialization of an NSMutableDictionary mapping appnames to pids.  The unix implementation contains a lot of code for parsing custom serialization formats in the XProperty byte sequence.  The mac implementation can use higher level tools provided in the Objective C runtime.
> 
> - Marc
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Crash with fossil pull

[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">Thanks Marc. I will definitely be more careful about this.&nbsp;</div><div dir="ltr"><br><blockquote type="cite">On Aug 28, 2025, at 9:22 AM, Marc Culler &lt;cul...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>The time warp which got fixed is not the only time warp in the Tk timeline.&nbsp; For example, commit&nbsp;<span class="gmail-timelineModernDetail">&nbsp;<a href="https://core.tcl-lang.org/tk-timewarp/info/c79d493f5ad704cd">c79d493f</a>&nbsp;is also older than its parent.&nbsp; Do we need to worry about the other time warps?</span></div><div><span class="gmail-timelineModernDetail"><br></span></div><div><span class="gmail-timelineModernDetail">- Marc</span></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Aug 28, 2025 at 2:35 AM Richard Hipp &lt;<a href="mailto:dr...@sq...">dr...@sq...</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">I have fixed the problem on the main Tk repository now, by resolving the timewarp using tags to changes the timestamp on the two out-of-order check-ins.&nbsp; The sync of Tk is working now.<br>
<br>
For completeness, before the timestamp fix: &lt;<a href="https://core.tcl-lang.org/tk-timewarp/timeline?y=ci&amp;b=20250828&amp;n=20" rel="noreferrer" target="_blank">https://core.tcl-lang.org/tk-timewarp/timeline?y=ci&amp;b=20250828&amp;n=20</a>&gt;.&nbsp; After applying the timestamp fixes: &lt;<a href="https://core.tcl-lang.org/tk/timeline?y=ci&amp;b=20250828&amp;n=20" rel="noreferrer" target="_blank">https://core.tcl-lang.org/tk/timeline?y=ci&amp;b=20250828&amp;n=20</a>&gt;<br>
<br>
I tried this fix before, but it didn't take.&nbsp; I don't know why. Perhaps I changed the timestamps on my local copy (by mistake) rather than on the server.&nbsp; I'm not sure.<br>
<br>
The bug in Fossil that was causing this sync failure due to a timewarp remains unfixed.&nbsp; I have capture both server-side and client-side copies of the tk.fossil databases that won't sync, so that the Fossil devs can repro the problem, and hopefully fix it.&nbsp; We can do this at a more civilized hour now that the sync problem with Tk has been resolved.<br>
<br>
<br>
--<br>
D. Richard Hipp<br>
<a href="mailto:dr...@sq..." target="_blank">dr...@sq...</a><br>
<br>
<br>
On Thursday, August 28th, 2025 at 3:18 AM, Richard Hipp &lt;<a href="mailto:dr...@sq..." target="_blank">dr...@sq...</a>&gt; wrote:<br>
<br>
&gt; Here I have captured a read-only snapshot of the timewarp: <a href="https://core.tcl-lang.org/tk-timewarp/timeline" rel="noreferrer" target="_blank">https://core.tcl-lang.org/tk-timewarp/timeline</a>.<br>
&gt; <br>
&gt; <br>
&gt; I'm trying to fix it now...<br>
&gt; <br>
&gt; --<br>
&gt; D. Richard Hipp<br>
&gt; <a href="mailto:dr...@sq..." target="_blank">dr...@sq...</a><br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; <br>
&gt; On Thursday, August 28th, 2025 at 3:04 AM, Richard Hipp <a href="mailto:dr...@sq..." target="_blank">dr...@sq...</a> wrote:<br>
&gt; <br>
&gt; &gt; Check-in 33d1d57acabba44f has a timestamp of 2025-08-26T13:44. It's parent, check-in cd3c8209bd20941f, has a timestamp of 2025-08-27T02:02 So the child was born more than 12 hours before the parent.<br>
&gt; &gt; <br>
&gt; &gt; See the graph: <a href="https://core.tcl-lang.org/tk/timeline?y=ci" rel="noreferrer" target="_blank">https://core.tcl-lang.org/tk/timeline?y=ci</a><br>
&gt; &gt; <br>
&gt; &gt; The problem is the unix/tkUnixAccessibility.c file: &lt;<a href="https://core.tcl-lang.org/tk/finfo?name=unix/tkUnixAccessibility.c" rel="noreferrer" target="_blank">https://core.tcl-lang.org/tk/finfo?name=unix/tkUnixAccessibility.c</a><br>
&gt; &gt; <br>
&gt; &gt; --<br>
&gt; &gt; D. Richard Hipp<br>
&gt; &gt; <a href="mailto:dr...@sq..." target="_blank">dr...@sq...</a><br>
&gt; &gt; <br>
&gt; &gt; On Thursday, August 28th, 2025 at 12:07 AM, Kevin Walzer <a href="mailto:kw...@co..." target="_blank">kw...@co...</a> wrote:<br>
&gt; &gt; <br>
&gt; &gt; &gt; I’m sorry - time warp?<br>
&gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; On Aug 27, 2025, at 10:52 PM, Richard Hipp <a href="mailto:dr...@sq..." target="_blank">dr...@sq...</a> wrote:<br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; I'm sorry - I do not yet know what is wrong. I suspect that it has something to do with the massive time-warp that Kevin Waltzer checked in. I tried fixing the time-warp, but that does not cure the problem.<br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; There is nothing wrong with the repo on the server. You can clone a new copy and the new clone will work fine. That is your work-around until the problem is resolved. No work has been lost.<br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; I suspect that the time-warp is tricking the server into sending a delta loop when it tries to sync. Probably somebody (maybe me) made an optimization to the sync protocol that has an implicit assumption that child check-ins occur later in time than their parents. Such an assumption would result in a delta loop in the sync following a time-warp like the one Kevin made. Fossil shouldn't malfunction that way. It is clearly a bug. But I can't find it yet.<br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; I seem to recall that I had a way to force a sync that used not deltas, just for this kind of problem. But I can't find that mechanism right now.<br>
&gt; &gt; &gt; &gt; --<br>
&gt; &gt; &gt; &gt; D. Richard Hipp<br>
&gt; &gt; &gt; &gt; <a href="mailto:dr...@sq..." target="_blank">dr...@sq...</a><br>
&gt; &gt; &gt; &gt; <br>
&gt; &gt; &gt; &gt; _______________________________________________<br>
&gt; &gt; &gt; &gt; Tcl-Core mailing list<br>
&gt; &gt; &gt; &gt; <a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a><br>
&gt; &gt; &gt; &gt; <a href="https://lists.sourceforge.net/lists/listinfo/tcl-core" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><br>
<br>
<br>
_______________________________________________<br>
Tcl-Core mailing list<br>
<a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/tcl-core" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><br>
</blockquote></div>
</div></blockquote></body></html>

Re: [TCLCORE] Crash with fossil pull

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

The time warp which got fixed is not the only time warp in the Tk
timeline.  For example, commit  c79d493f
<https://core.tcl-lang.org/tk-timewarp/info/c79d493f5ad704cd> is also older
than its parent.  Do we need to worry about the other time warps?

- Marc

On Thu, Aug 28, 2025 at 2:35 AM Richard Hipp <dr...@sq...> wrote:

> I have fixed the problem on the main Tk repository now, by resolving the
> timewarp using tags to changes the timestamp on the two out-of-order
> check-ins.  The sync of Tk is working now.
>
> For completeness, before the timestamp fix: <
> https://core.tcl-lang.org/tk-timewarp/timeline?y=ci&b=20250828&n=20>.
> After applying the timestamp fixes: <
> https://core.tcl-lang.org/tk/timeline?y=ci&b=20250828&n=20>
>
> I tried this fix before, but it didn't take.  I don't know why. Perhaps I
> changed the timestamps on my local copy (by mistake) rather than on the
> server.  I'm not sure.
>
> The bug in Fossil that was causing this sync failure due to a timewarp
> remains unfixed.  I have capture both server-side and client-side copies of
> the tk.fossil databases that won't sync, so that the Fossil devs can repro
> the problem, and hopefully fix it.  We can do this at a more civilized hour
> now that the sync problem with Tk has been resolved.
>
>
> --
> D. Richard Hipp
> dr...@sq...
>
>
> On Thursday, August 28th, 2025 at 3:18 AM, Richard Hipp <dr...@sq...>
> wrote:
>
> > Here I have captured a read-only snapshot of the timewarp:
> https://core.tcl-lang.org/tk-timewarp/timeline.
> >
> >
> > I'm trying to fix it now...
> >
> > --
> > D. Richard Hipp
> > dr...@sq...
> >
> >
> >
> >
> > On Thursday, August 28th, 2025 at 3:04 AM, Richard Hipp dr...@sq...
> wrote:
> >
> > > Check-in 33d1d57acabba44f has a timestamp of 2025-08-26T13:44. It's
> parent, check-in cd3c8209bd20941f, has a timestamp of 2025-08-27T02:02 So
> the child was born more than 12 hours before the parent.
> > >
> > > See the graph: https://core.tcl-lang.org/tk/timeline?y=ci
> > >
> > > The problem is the unix/tkUnixAccessibility.c file: <
> https://core.tcl-lang.org/tk/finfo?name=unix/tkUnixAccessibility.c
> > >
> > > --
> > > D. Richard Hipp
> > > dr...@sq...
> > >
> > > On Thursday, August 28th, 2025 at 12:07 AM, Kevin Walzer
> kw...@co... wrote:
> > >
> > > > I’m sorry - time warp?
> > > >
> > > > > On Aug 27, 2025, at 10:52 PM, Richard Hipp dr...@sq... wrote:
> > > > >
> > > > > I'm sorry - I do not yet know what is wrong. I suspect that it has
> something to do with the massive time-warp that Kevin Waltzer checked in. I
> tried fixing the time-warp, but that does not cure the problem.
> > > > >
> > > > > There is nothing wrong with the repo on the server. You can clone
> a new copy and the new clone will work fine. That is your work-around until
> the problem is resolved. No work has been lost.
> > > > >
> > > > > I suspect that the time-warp is tricking the server into sending a
> delta loop when it tries to sync. Probably somebody (maybe me) made an
> optimization to the sync protocol that has an implicit assumption that
> child check-ins occur later in time than their parents. Such an assumption
> would result in a delta loop in the sync following a time-warp like the one
> Kevin made. Fossil shouldn't malfunction that way. It is clearly a bug. But
> I can't find it yet.
> > > > >
> > > > > I seem to recall that I had a way to force a sync that used not
> deltas, just for this kind of problem. But I can't find that mechanism
> right now.
> > > > > --
> > > > > D. Richard Hipp
> > > > > dr...@sq...
> > > > >
> > > > > _______________________________________________
> > > > > Tcl-Core mailing list
> > > > > Tcl...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Crash with fossil pull

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

I think I know what happened. I am working in a VirtualBox Linux install and sometimes the system clock is off if I sleep my laptop—the VBox image keeps its state and the clock loses alignment with the host OS clock.  I remember seeing a warning in Fossil but committed with the “—allow-older” flag. Not something I’d do with trunk, but this branch is under heavy development and I didn’t think it would cause problems. 

What should I do going forward?

> On Aug 28, 2025, at 3:04 AM, Richard Hipp <dr...@sq...> wrote:
> 
> Check-in 33d1d57acabba44f has a timestamp of 2025-08-26T13:44.  It's parent, check-in cd3c8209bd20941f, has a timestamp of 2025-08-27T02:02  So the child was born more than 12 hours before the parent.
> 
> See the graph:  <https://core.tcl-lang.org/tk/timeline?y=ci>
> 
> The problem is the unix/tkUnixAccessibility.c file: <https://core.tcl-lang.org/tk/finfo?name=unix/tkUnixAccessibility.c
> 
> --
> D. Richard Hipp
> dr...@sq...
> 
> 
>> On Thursday, August 28th, 2025 at 12:07 AM, Kevin Walzer <kw...@co...> wrote:
>> 
>> I’m sorry - time warp?
>> 
>>>> On Aug 27, 2025, at 10:52 PM, Richard Hipp dr...@sq... wrote:
>>> 
>>> I'm sorry - I do not yet know what is wrong. I suspect that it has something to do with the massive time-warp that Kevin Waltzer checked in. I tried fixing the time-warp, but that does not cure the problem.
>>> 
>>> There is nothing wrong with the repo on the server. You can clone a new copy and the new clone will work fine. That is your work-around until the problem is resolved. No work has been lost.
>>> 
>>> I suspect that the time-warp is tricking the server into sending a delta loop when it tries to sync. Probably somebody (maybe me) made an optimization to the sync protocol that has an implicit assumption that child check-ins occur later in time than their parents. Such an assumption would result in a delta loop in the sync following a time-warp like the one Kevin made. Fossil shouldn't malfunction that way. It is clearly a bug. But I can't find it yet.
>>> 
>>> I seem to recall that I had a way to force a sync that used not deltas, just for this kind of problem. But I can't find that mechanism right now.
>>> --
>>> D. Richard Hipp
>>> dr...@sq...
>>> 
>>> _______________________________________________
>>> Tcl-Core mailing list
>>> Tcl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV: TIP 726

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

TIP #726:  YES

-- Steve
On 19 Aug 2025 at 10:20 AM +0800, apnmbx-public--- via Tcl-Core <tcl...@li...>, wrote:
> This is a CFV for TIP 726: Commands for Unicode normalization
>
> CFV ends 2025-08-29 00:00 UTC.
>
> My vote: Yes
>
> /Ashok
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Crash with fossil pull

[Richard H. <dr...@sq...>]

I have fixed the problem on the main Tk repository now, by resolving the timewarp using tags to changes the timestamp on the two out-of-order check-ins.  The sync of Tk is working now.

For completeness, before the timestamp fix: <https://core.tcl-lang.org/tk-timewarp/timeline?y=ci&b=20250828&n=20>.  After applying the timestamp fixes: <https://core.tcl-lang.org/tk/timeline?y=ci&b=20250828&n=20>

I tried this fix before, but it didn't take.  I don't know why. Perhaps I changed the timestamps on my local copy (by mistake) rather than on the server.  I'm not sure.

The bug in Fossil that was causing this sync failure due to a timewarp remains unfixed.  I have capture both server-side and client-side copies of the tk.fossil databases that won't sync, so that the Fossil devs can repro the problem, and hopefully fix it.  We can do this at a more civilized hour now that the sync problem with Tk has been resolved.


--
D. Richard Hipp
dr...@sq...


On Thursday, August 28th, 2025 at 3:18 AM, Richard Hipp <dr...@sq...> wrote:

> Here I have captured a read-only snapshot of the timewarp: https://core.tcl-lang.org/tk-timewarp/timeline.
> 
> 
> I'm trying to fix it now...
> 
> --
> D. Richard Hipp
> dr...@sq...
> 
> 
> 
> 
> On Thursday, August 28th, 2025 at 3:04 AM, Richard Hipp dr...@sq... wrote:
> 
> > Check-in 33d1d57acabba44f has a timestamp of 2025-08-26T13:44. It's parent, check-in cd3c8209bd20941f, has a timestamp of 2025-08-27T02:02 So the child was born more than 12 hours before the parent.
> > 
> > See the graph: https://core.tcl-lang.org/tk/timeline?y=ci
> > 
> > The problem is the unix/tkUnixAccessibility.c file: <https://core.tcl-lang.org/tk/finfo?name=unix/tkUnixAccessibility.c
> > 
> > --
> > D. Richard Hipp
> > dr...@sq...
> > 
> > On Thursday, August 28th, 2025 at 12:07 AM, Kevin Walzer kw...@co... wrote:
> > 
> > > I’m sorry - time warp?
> > > 
> > > > On Aug 27, 2025, at 10:52 PM, Richard Hipp dr...@sq... wrote:
> > > > 
> > > > I'm sorry - I do not yet know what is wrong. I suspect that it has something to do with the massive time-warp that Kevin Waltzer checked in. I tried fixing the time-warp, but that does not cure the problem.
> > > > 
> > > > There is nothing wrong with the repo on the server. You can clone a new copy and the new clone will work fine. That is your work-around until the problem is resolved. No work has been lost.
> > > > 
> > > > I suspect that the time-warp is tricking the server into sending a delta loop when it tries to sync. Probably somebody (maybe me) made an optimization to the sync protocol that has an implicit assumption that child check-ins occur later in time than their parents. Such an assumption would result in a delta loop in the sync following a time-warp like the one Kevin made. Fossil shouldn't malfunction that way. It is clearly a bug. But I can't find it yet.
> > > > 
> > > > I seem to recall that I had a way to force a sync that used not deltas, just for this kind of problem. But I can't find that mechanism right now.
> > > > --
> > > > D. Richard Hipp
> > > > dr...@sq...
> > > > 
> > > > _______________________________________________
> > > > Tcl-Core mailing list
> > > > Tcl...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Crash with fossil pull

[Richard H. <dr...@sq...>]

Here I have captured a read-only snapshot of the timewarp:  <https://core.tcl-lang.org/tk-timewarp/timeline>.

I'm trying to fix it now...
--
D. Richard Hipp
dr...@sq...


On Thursday, August 28th, 2025 at 3:04 AM, Richard Hipp <dr...@sq...> wrote:

> Check-in 33d1d57acabba44f has a timestamp of 2025-08-26T13:44. It's parent, check-in cd3c8209bd20941f, has a timestamp of 2025-08-27T02:02 So the child was born more than 12 hours before the parent.
> 
> See the graph: https://core.tcl-lang.org/tk/timeline?y=ci
> 
> 
> The problem is the unix/tkUnixAccessibility.c file: <https://core.tcl-lang.org/tk/finfo?name=unix/tkUnixAccessibility.c
> 
> --
> D. Richard Hipp
> dr...@sq...
> 
> 
> 
> 
> On Thursday, August 28th, 2025 at 12:07 AM, Kevin Walzer kw...@co... wrote:
> 
> > I’m sorry - time warp?
> > 
> > > On Aug 27, 2025, at 10:52 PM, Richard Hipp dr...@sq... wrote:
> > > 
> > > I'm sorry - I do not yet know what is wrong. I suspect that it has something to do with the massive time-warp that Kevin Waltzer checked in. I tried fixing the time-warp, but that does not cure the problem.
> > > 
> > > There is nothing wrong with the repo on the server. You can clone a new copy and the new clone will work fine. That is your work-around until the problem is resolved. No work has been lost.
> > > 
> > > I suspect that the time-warp is tricking the server into sending a delta loop when it tries to sync. Probably somebody (maybe me) made an optimization to the sync protocol that has an implicit assumption that child check-ins occur later in time than their parents. Such an assumption would result in a delta loop in the sync following a time-warp like the one Kevin made. Fossil shouldn't malfunction that way. It is clearly a bug. But I can't find it yet.
> > > 
> > > I seem to recall that I had a way to force a sync that used not deltas, just for this kind of problem. But I can't find that mechanism right now.
> > > --
> > > D. Richard Hipp
> > > dr...@sq...
> > > 
> > > _______________________________________________
> > > Tcl-Core mailing list
> > > Tcl...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Crash with fossil pull

[Richard H. <dr...@sq...>]

Check-in 33d1d57acabba44f has a timestamp of 2025-08-26T13:44.  It's parent, check-in cd3c8209bd20941f, has a timestamp of 2025-08-27T02:02  So the child was born more than 12 hours before the parent.

See the graph:  <https://core.tcl-lang.org/tk/timeline?y=ci>

The problem is the unix/tkUnixAccessibility.c file: <https://core.tcl-lang.org/tk/finfo?name=unix/tkUnixAccessibility.c

--
D. Richard Hipp
dr...@sq...


On Thursday, August 28th, 2025 at 12:07 AM, Kevin Walzer <kw...@co...> wrote:

> I’m sorry - time warp?
> 
> > On Aug 27, 2025, at 10:52 PM, Richard Hipp dr...@sq... wrote:
> > 
> > I'm sorry - I do not yet know what is wrong. I suspect that it has something to do with the massive time-warp that Kevin Waltzer checked in. I tried fixing the time-warp, but that does not cure the problem.
> > 
> > There is nothing wrong with the repo on the server. You can clone a new copy and the new clone will work fine. That is your work-around until the problem is resolved. No work has been lost.
> > 
> > I suspect that the time-warp is tricking the server into sending a delta loop when it tries to sync. Probably somebody (maybe me) made an optimization to the sync protocol that has an implicit assumption that child check-ins occur later in time than their parents. Such an assumption would result in a delta loop in the sync following a time-warp like the one Kevin made. Fossil shouldn't malfunction that way. It is clearly a bug. But I can't find it yet.
> > 
> > I seem to recall that I had a way to force a sync that used not deltas, just for this kind of problem. But I can't find that mechanism right now.
> > --
> > D. Richard Hipp
> > dr...@sq...
> > 
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Question on TCL_BROKEN_MAINARGS

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

Op wo 27 aug 2025 om 22:23 schreef Jan Nijtmans <jan...@gm...>:
>
> Op wo 27 aug 2025 om 17:39 schreef Ashok:
> >
> > There are code fragments covered by #ifdef TCL_BROKEN_MAINARGS that is present only in the win subdirectory that I would like to eliminate to reduce clutter. Anyone know under what circumstances this is needed? Is this obsolete Win95 stuff or something else?

Review remarks for "apn-broken-mainargs":

1) The _CRT_glob variable is still needed, otherwise tclsh on Windows
    starts to do its own wildcard expansion. See:
        <https://stackoverflow.com/questions/60947192/c-main-parameter>
2) Please update to autoconf-2.72. The diff becomes so large ....

Otherwise, everything looks good.

Hope this helps,
       Jan Nijtmans

Re: [TCLCORE] Crash with fossil pull

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

I’m sorry - time warp?

> On Aug 27, 2025, at 10:52 PM, Richard Hipp <dr...@sq...> wrote:
> 
> I'm sorry - I do not yet know what is wrong.  I suspect that it has something to do with the massive time-warp that Kevin Waltzer checked in.  I tried fixing the time-warp, but that does not cure the problem.
> 
> There is nothing wrong with the repo on the server.  You can clone a new copy and the new clone will work fine.  That is your work-around until the problem is resolved.  No work has been lost.
> 
> I suspect that the time-warp is tricking the server into sending a delta loop when it tries to sync.  Probably somebody (maybe me) made an optimization to the sync protocol that has an implicit assumption that child check-ins occur later in time than their parents.  Such an assumption would result in a delta loop in the sync following a time-warp like the one Kevin made.  Fossil shouldn't malfunction that way.  It is clearly a bug.  But I can't find it yet.
> 
> I seem to recall that I had a way to force a sync that used not deltas, just for this kind of problem.  But I can't find that mechanism right now.
> --
> D. Richard Hipp
> dr...@sq...
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Crash with fossil pull

[Richard H. <dr...@sq...>]

I'm sorry - I do not yet know what is wrong.  I suspect that it has something to do with the massive time-warp that Kevin Waltzer checked in.  I tried fixing the time-warp, but that does not cure the problem.

There is nothing wrong with the repo on the server.  You can clone a new copy and the new clone will work fine.  That is your work-around until the problem is resolved.  No work has been lost.

I suspect that the time-warp is tricking the server into sending a delta loop when it tries to sync.  Probably somebody (maybe me) made an optimization to the sync protocol that has an implicit assumption that child check-ins occur later in time than their parents.  Such an assumption would result in a delta loop in the sync following a time-warp like the one Kevin made.  Fossil shouldn't malfunction that way.  It is clearly a bug.  But I can't find it yet.

I seem to recall that I had a way to force a sync that used not deltas, just for this kind of problem.  But I can't find that mechanism right now.
--
D. Richard Hipp
dr...@sq...

Re: [TCLCORE] New implementation of send for macOS

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

Thanks Marc, this is great.  Being able to use tools like tkinspect again (securely) will be a definite win.

-- Steve
On 28 Aug 2025 at 5:02 AM +0800, Kevin Walzer <kw...@co...>, wrote:
> Thanks Mark!  I am excited to take a look. More to come.
>
> > On Aug 27, 2025, at 2:12 PM, Marc Culler <cul...@gm...> wrote:
> >
> > I have just pushed a new branch, mac_send, containing a nearly complete full implementation of the send command for macOS.  In particular, it allows sending commands to interpreters in other processes.  I think it is now in a state where it can be tested, and I hope people will do that.
> >
> > Two key points:
> >
> > 1. (ATTN: Kevin Walzer). The implementation uses AppleEvents.  In fact, it uses the current DoScript handler when sending commands to other processes.  Essentially, the send command is providing a Tk-based tool for sending AppleEvents (specifically, DoScript events) without depending external tools like Script Editor or osascript.  So it is simplifying access to native IPC methods.
> >
> > 2. (ATTN: Peter da Silva and Christian Werner) While commands can be sent to other processes, they can only be sent to processes owned by the same user on the same host.)
> >
> > A simple test:
> > * Open three Terminals and start wish9.,1 in each terminal.
> > * In the last Terminal, which has appname Wish #3, run these commands:
> > % tk appname
> > Wish #3
> > % send Wish {wm geometry . +500+100}
> > % send Wish {wm geometryxx . +600+100}
> > % send Wish {send {Wish #2} {wm geometry . +900+100}}
> > % send Wish {puts hello}
> > % send Wish {send {Wish #2} {puts hello}}
> >
> > What is missing:
> > Error handling is incomplete.  Also, after running the tests above you will not that when sending {puts hello} the word "hello" is printed twice in the basic case and four times when sending the command recursively through two interpreters.  This is not a bug in the send implementation.  The same happens with osascript.
> >
> > Implementation details:
> > Besides the use of AppleEvents, the main difference is that the registry of appnames is stored in a file in the user's /Library/Caches directory while the unix implementation stores the registry in an XProperty.  The file simply contains a JSON serialization of an NSMutableDictionary mapping appnames to pids.  The unix implementation contains a lot of code for parsing custom serialization formats in the XProperty byte sequence.  The mac implementation can use higher level tools provided in the Objective C runtime.
> >
> > - Marc
> >
> >
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Crash with fossil pull

[Richard H. <dr...@sq...>]

I'm on a client site and cannot debug right now.  Make the repo read-only so that it doesn't change any more and I'll address the issue as soon as I can get to it.



--
D. Richard Hipp
dr...@sq...


On Wednesday, August 27th, 2025 at 6:05 PM, Andreas Kupries <and...@gm...> wrote:

> > There must be something critical with the current version of the Tk
> > repository. Any attempt to pull the changes from it via
> > 
> > fossil pull https://core.tcl-lang.org/tk
> > 
> > throws the error message
> > 
> > "infinite loop in DELTA table"
> > 
> > and causes a crash with core dump.
> > 
> > Can anybody help? Many thanks in advance!
> 
> 
> I confirm for
> % fossil version
> This is fossil version 2.24 [8be0372c10] 2024-04-23 13:25:26 UTC
> 
> % fossil pull
> Pull from https://aku@core.tcl-lang.org/tk
> Round-trips: 1 Artifacts sent: 0 received: 33
> infinite loop in DELTA table
> Aborted (core dumped)
> 
> Ditto confirm for
> This is fossil version 2.27 [a403e11b6f] 2025-07-09 14:16:49 UTC
> 
> This is the current latest release.
> 
> Cloning works (v 2.24)
> 
> % fossil clone https://aku@core.tcl-lang.org/tk tk.fossil
> password [...]
> Round-trips: 155 Artifacts sent: 0 received: 134855
> Clone done, wire bytes sent: 50423 received: 194719989 remote:
> 2606:4700::6813:f344
> Rebuilding repository meta-data...
> 100.0% complete...
> Extra delta compression... 626 deltas save 5,590,670 bytes
> Vacuuming the database...
> [...]
> 
> Pull from the new clone works.
> 
> Richard, do you have any thoughts about this ?
> 
> Is that delta issue something in the core repo, or in the local clone ?
> 
> Is this something which can be recovered from without performing a full clone ?
> 
> Regardless of the answers, a full new clone op seems to be a workaround.
> 
> --
> Happy Tcling,
> Andreas Kupries and...@gm...
> 
> https://core.tcl-lang.org/akupries/
> 
> https://akupries.tclers.tk/
> 
> Developer @ SUSE Software Solutions Germany GmbH
> -------------------------------------------------------------------------------

Re: [TCLCORE] Crash with fossil pull

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

> There must be something critical with the current version of the Tk 
> repository.  Any attempt to pull the changes from it via
> 
>      fossil pull https://core.tcl-lang.org/tk
> 
> throws the error message
> 
>      "infinite loop in DELTA table"
> 
> and causes a crash with core dump.
> 
> Can anybody help?  Many thanks in advance!

I confirm for
	% fossil version
	This is fossil version 2.24 [8be0372c10] 2024-04-23 13:25:26 UTC

	% fossil pull
	Pull from https://aku@core.tcl-lang.org/tk
	Round-trips: 1   Artifacts sent: 0  received: 33
	infinite loop in DELTA table
	Aborted (core dumped)

Ditto confirm for
	This is fossil version 2.27 [a403e11b6f] 2025-07-09 14:16:49 UTC

This is the current latest release.

Cloning works (v 2.24)

	% fossil clone https://aku@core.tcl-lang.org/tk tk.fossil
	password [...]
	Round-trips: 155   Artifacts sent: 0  received: 134855
	Clone done, wire bytes sent: 50423  received: 194719989  remote: 
2606:4700::6813:f344
	Rebuilding repository meta-data...
	  100.0% complete...
	  Extra delta compression... 626 deltas save 5,590,670 bytes
	Vacuuming the database... 
	[...]

Pull from the new clone works.

Richard, do you have any thoughts about this ?

Is that delta issue something in the core repo, or in the local clone ?

Is this something which can be recovered from without performing a full clone ?

Regardless of the answers, a full new clone op seems to be a workaround.

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

Re: [TCLCORE] New implementation of send for macOS

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

Thanks Mark!  I am excited to take a look. More to come. 

> On Aug 27, 2025, at 2:12 PM, Marc Culler <cul...@gm...> wrote:
> 
> 
> I have just pushed a new branch, mac_send, containing a nearly complete full implementation of the send command for macOS.  In particular, it allows sending commands to interpreters in other processes.  I think it is now in a state where it can be tested, and I hope people will do that.
> 
> Two key points:
> 
> 1. (ATTN: Kevin Walzer). The implementation uses AppleEvents.  In fact, it uses the current DoScript handler when sending commands to other processes.  Essentially, the send command is providing a Tk-based tool for sending AppleEvents (specifically, DoScript events) without depending external tools like Script Editor or osascript.  So it is simplifying access to native IPC methods.
> 
> 2. (ATTN: Peter da Silva and Christian Werner) While commands can be sent to other processes, they can only be sent to processes owned by the same user on the same host.)
> 
> A simple test:
> * Open three Terminals and start wish9.,1 in each terminal.
> * In the last Terminal, which has appname Wish #3, run these commands:
> % tk appname
> Wish #3
> % send Wish {wm geometry . +500+100}
> % send Wish {wm geometryxx . +600+100}
> % send Wish {send {Wish #2} {wm geometry . +900+100}}
> % send Wish {puts hello}
> % send Wish {send {Wish #2} {puts hello}}
> 
> What is missing:
> Error handling is incomplete.  Also, after running the tests above you will not that when sending {puts hello} the word "hello" is printed twice in the basic case and four times when sending the command recursively through two interpreters.  This is not a bug in the send implementation.  The same happens with osascript.
> 
> Implementation details:
> Besides the use of AppleEvents, the main difference is that the registry of appnames is stored in a file in the user's /Library/Caches directory while the unix implementation stores the registry in an XProperty.  The file simply contains a JSON serialization of an NSMutableDictionary mapping appnames to pids.  The unix implementation contains a lot of code for parsing custom serialization formats in the XProperty byte sequence.  The mac implementation can use higher level tools provided in the Objective C runtime.
> 
> - Marc
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Question on TCL_BROKEN_MAINARGS

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

Op wo 27 aug 2025 om 17:39 schreef Ashok:
>
> There are code fragments covered by #ifdef TCL_BROKEN_MAINARGS that is present only in the win subdirectory that I would like to eliminate to reduce clutter. Anyone know under what circumstances this is needed? Is this obsolete Win95 stuff or something else?

It was needed, in order to be able to cross-compile with the original
"mingw" toolchain. Since "mingw" is dead now (superseded by
mingw_w64, which works fine), it can be removed.

The original mingw had a bug in the command-line parsing, and
it also lacked the -municode flag. You can compile tclAppInit
without -municode and without TCL_BROKEN_MAINARGS
just fine, so yes we can remove it now.

Regards,
     Jan Nijtmans

Re: [TCLCORE] Question on TCL_BROKEN_MAINARGS

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

 

IIRC, it is only set in configure by impossibility or unwillingness to
build tcl for windows as unicode binary (using unicode-capable runtime
library), e. g. without -municode in LDFLAGS. 

I think it is only the case using some special toolchains (not gcc/clang
or visual studio). No idea whether newer versions like 9.x are still
buildable with that.

Regards,
Sergey 

Am 27.08.2025 17:38, schrieb apnmbx-public--- via Tcl-Core: 

> There are code fragments covered by #ifdef TCL_BROKEN_MAINARGS that is present only in the win subdirectory that I would like to eliminate to reduce clutter. Anyone know under what circumstances this is needed? Is this obsolete Win95 stuff or something else? 
> 
> /Ashok 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [1]
 

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/tcl-core