tcl-core Mailing List for Tcl (Page 9)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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

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

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

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

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

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

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

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

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

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

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

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

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

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://ak...@co.../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://ak...@co.../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
> -------------------------------------------------------------------------------

> 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://ak...@co.../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://ak...@co.../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
-------------------------------------------------------------------------------

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

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

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

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

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!

Csaba

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

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

Hi Brian,

Thank you. I will take a closer look at your work here. Much appreciated!

—Kevin

> On Aug 27, 2025, at 1:03 AM, Brian Griffin <bri...@ea...> wrote:
> 
>  Hi Kevin,
> 
> I don't know anything about GLib event loop, but I did learn something important when integrating the Qt event loop with Tcl. The lesson learned is that there can only be one event loop master. Everything else is just responding to the events when the master says so. 
> Qt was interesting because it doesn't really have main loop per se, but it still needed to know about *all* events. So, I put Tcl as the top "loop"er (i.e. DoOneEvent). Then translated all Tcl events into Qt events. Qt would handle it's own events directly, and the "tcl" events were Qt events, but the callbacks went to Tcl for actual handling.
> I ended up here because any other way lead to a hang or ignored events.
> 
> Only one master loop!
> 
> (Note: my work was before the switch to the new (epoll?) event loop system.)
> 
> I hope this gives you some insight.
> -Brian
> 
>> On Aug 26, 2025, at 20:09, Kevin Walzer <kw...@co...> wrote:
>> 
>> Hi all,
>> 
>> As you may be aware, for the past year I’ve been working on a project to introduce accessibility / screen reader support to Tk. I’m almost done, but there’s one obstacle I can’t seem to work through - integrating the Tcl and GLib event loops on Linux. This is required because the ATK accessibility API communicates with accessibility clients via the at-spi protocol, which is controlled by GLib.
>> 
>> Put simply, Wish hangs. My latest commits take a bit longer, but eventually Wish freezes. 
>> 
>> Looking at the example of the gnocl project, I’ve created a custom Tcl event source that consumes events from GLib. It seems straightforward but is anything but. 
>> 
>> Here is my current code, based on a suggestion from one of the many AI assistants I’ve consulted:  
>> /* Configure event loop. */
>> static void Atk_Event_Setup(ClientData clientData, int flags)
>> {
>>     (void)clientData;
>> 
>>   
>>     static Tcl_Time block_time;
>> 
>>     if (!(flags & TCL_WINDOW_EVENTS)) {
>> 	return;
>>     }
>> 
>>     /* Ask GLib how long it wants to sleep. */
>>     gint timeout = g_main_context_iteration(NULL, FALSE);
>>     if (timeout > 0) {
>> 	block_time.sec = timeout / 1000;
>> 	block_time.usec = (timeout % 1000) * 1000;
>>     } else {
>> 	/* If GLib has pending events, don't block. */
>> 	block_time.sec = 0;
>> 	block_time.usec = 0;
>>     }
>> 
>>     Tcl_SetMaxBlockTime(&block_time);
>> }
>> 
>> 
>> /* Check event queue. */
>> static void Atk_Event_Check(ClientData clientData, int flags) {
>>     (void)clientData;
>>     (void)flags;
>> 
>>     /* No-op. The real work is done in Atk_Event_Setup. */
>> }
>> Tcl_CreateEventSource (Atk_Event_Setup, Atk_Event_Check, 0);
>>     Tcl_SetServiceMode (TCL_SERVICE_ALL);
>> I’d be grateful for any suggestions. 
>> Thanks,
>> Kevin
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 

Reminder - vote ends in less than 48 hours.

-----Original Message-----
From: Andreas Kupries <and...@gm...> 
Sent: Sunday, August 24, 2025 3:53 PM
To: apn...@ya...; 'Tcl Core List'
<tcl...@li...>
Subject: Re: [TCLCORE] CFV: TIP 726

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

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

#726: YES

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

Hi Kevin,

I don't know anything about GLib event loop, but I did learn something important when integrating the Qt event loop with Tcl. The lesson learned is that there can only be one event loop master. Everything else is just responding to the events when the master says so.
Qt was interesting because it doesn't really have main loop per se, but it still needed to know about *all* events. So, I put Tcl as the top "loop"er (i.e. DoOneEvent). Then translated all Tcl events into Qt events. Qt would handle it's own events directly, and the "tcl" events were Qt events, but the callbacks went to Tcl for actual handling.
I ended up here because any other way lead to a hang or ignored events.

Only one master loop!

(Note: my work was before the switch to the new (epoll?) event loop system.)

I hope this gives you some insight.
-Brian

On Aug 26, 2025, at 20:09, Kevin Walzer <kw...@co...> wrote:

Hi all,

As you may be aware, for the past year I’ve been working on a project to introduce accessibility / screen reader support to Tk. I’m almost done, but there’s one obstacle I can’t seem to work through - integrating the Tcl and GLib event loops on Linux. This is required because the ATK accessibility API communicates with accessibility clients via the at-spi protocol, which is controlled by GLib.

Put simply, Wish hangs. My latest commits take a bit longer, but eventually Wish freezes.

Looking at the example of the gnocl project, I’ve created a custom Tcl event source that consumes events from GLib. It seems straightforward but is anything but.

Here is my current code, based on a suggestion from one of the many AI assistants I’ve consulted:

/* Configure event loop. */
static void Atk_Event_Setup(ClientData clientData, int flags)
{
    (void)clientData;

    static Tcl_Time block_time;

    if (!(flags & TCL_WINDOW_EVENTS)) {
        return;
    }

    /* Ask GLib how long it wants to sleep. */
    gint timeout = g_main_context_iteration(NULL, FALSE);
    if (timeout > 0) {
        block_time.sec = timeout / 1000;
        block_time.usec = (timeout % 1000) * 1000;
    } else {
        /* If GLib has pending events, don't block. */
        block_time.sec = 0;
        block_time.usec = 0;
    }

    Tcl_SetMaxBlockTime(&block_time);
}

/* Check event queue. */
static void Atk_Event_Check(ClientData clientData, int flags) {
    (void)clientData;
    (void)flags;

    /* No-op. The real work is done in Atk_Event_Setup. */
}

Tcl_CreateEventSource (Atk_Event_Setup, Atk_Event_Check, 0);
    Tcl_SetServiceMode (TCL_SERVICE_ALL);

I’d be grateful for any suggestions.

Thanks,

Kevin

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

2000	Jan	Feb	Mar	Apr	May	Jun (19)	Jul (96)	Aug (144)	Sep (222)	Oct (496)	Nov (171)	Dec (6)
2001	Jan (4)	Feb (4)	Mar (9)	Apr (4)	May (12)	Jun (6)	Jul	Aug	Sep (1)	Oct (2)	Nov	Dec
2002	Jan	Feb	Mar	Apr	May	Jun (1)	Jul (52)	Aug (47)	Sep (47)	Oct (95)	Nov (56)	Dec (34)
2003	Jan (99)	Feb (116)	Mar (125)	Apr (99)	May (123)	Jun (69)	Jul (110)	Aug (130)	Sep (289)	Oct (211)	Nov (98)	Dec (140)
2004	Jan (85)	Feb (87)	Mar (342)	Apr (125)	May (101)	Jun (60)	Jul (151)	Aug (118)	Sep (162)	Oct (117)	Nov (125)	Dec (95)
2005	Jan (141)	Feb (54)	Mar (79)	Apr (83)	May (74)	Jun (125)	Jul (63)	Aug (89)	Sep (130)	Oct (89)	Nov (34)	Dec (39)
2006	Jan (98)	Feb (62)	Mar (56)	Apr (94)	May (169)	Jun (41)	Jul (34)	Aug (35)	Sep (132)	Oct (722)	Nov (381)	Dec (36)
2007	Jan (34)	Feb (174)	Mar (15)	Apr (35)	May (74)	Jun (15)	Jul (8)	Aug (18)	Sep (39)	Oct (125)	Nov (89)	Dec (129)
2008	Jan (176)	Feb (91)	Mar (69)	Apr (178)	May (310)	Jun (434)	Jul (171)	Aug (73)	Sep (187)	Oct (132)	Nov (259)	Dec (292)
2009	Jan (27)	Feb (54)	Mar (35)	Apr (54)	May (93)	Jun (10)	Jul (36)	Aug (36)	Sep (93)	Oct (52)	Nov (45)	Dec (74)
2010	Jan (20)	Feb (120)	Mar (165)	Apr (101)	May (56)	Jun (12)	Jul (73)	Aug (306)	Sep (154)	Oct (82)	Nov (63)	Dec (42)
2011	Jan (176)	Feb (86)	Mar (199)	Apr (86)	May (237)	Jun (50)	Jul (26)	Aug (56)	Sep (42)	Oct (62)	Nov (62)	Dec (52)
2012	Jan (35)	Feb (33)	Mar (128)	Apr (152)	May (133)	Jun (21)	Jul (74)	Aug (423)	Sep (165)	Oct (129)	Nov (387)	Dec (276)
2013	Jan (105)	Feb (30)	Mar (130)	Apr (42)	May (60)	Jun (79)	Jul (101)	Aug (46)	Sep (81)	Oct (14)	Nov (43)	Dec (4)
2014	Jan (25)	Feb (32)	Mar (30)	Apr (80)	May (42)	Jun (23)	Jul (68)	Aug (127)	Sep (112)	Oct (72)	Nov (29)	Dec (69)
2015	Jan (35)	Feb (49)	Mar (95)	Apr (10)	May (70)	Jun (64)	Jul (93)	Aug (85)	Sep (43)	Oct (38)	Nov (124)	Dec (29)
2016	Jan (253)	Feb (181)	Mar (132)	Apr (419)	May (68)	Jun (90)	Jul (52)	Aug (142)	Sep (131)	Oct (80)	Nov (84)	Dec (192)
2017	Jan (329)	Feb (842)	Mar (248)	Apr (85)	May (247)	Jun (186)	Jul (37)	Aug (73)	Sep (98)	Oct (108)	Nov (143)	Dec (143)
2018	Jan (155)	Feb (139)	Mar (72)	Apr (112)	May (82)	Jun (119)	Jul (24)	Aug (33)	Sep (179)	Oct (295)	Nov (111)	Dec (34)
2019	Jan (20)	Feb (29)	Mar (49)	Apr (89)	May (185)	Jun (131)	Jul (9)	Aug (59)	Sep (30)	Oct (44)	Nov (118)	Dec (53)
2020	Jan (70)	Feb (108)	Mar (50)	Apr (9)	May (70)	Jun (24)	Jul (103)	Aug (82)	Sep (132)	Oct (119)	Nov (174)	Dec (169)
2021	Jan (75)	Feb (51)	Mar (76)	Apr (73)	May (53)	Jun (120)	Jul (114)	Aug (73)	Sep (70)	Oct (18)	Nov (26)	Dec
2022	Jan (26)	Feb (63)	Mar (64)	Apr (64)	May (48)	Jun (74)	Jul (129)	Aug (106)	Sep (238)	Oct (169)	Nov (149)	Dec (111)
2023	Jan (110)	Feb (47)	Mar (82)	Apr (106)	May (168)	Jun (101)	Jul (155)	Aug (35)	Sep (51)	Oct (55)	Nov (134)	Dec (202)
2024	Jan (103)	Feb (129)	Mar (154)	Apr (89)	May (60)	Jun (162)	Jul (201)	Aug (61)	Sep (167)	Oct (111)	Nov (133)	Dec (141)
2025	Jan (122)	Feb (88)	Mar (106)	Apr (113)	May (203)	Jun (185)	Jul (124)	Aug (202)	Sep (176)	Oct (11)	Nov	Dec

tcl-core Mailing List for Tcl (Page 9)

The Tool Command Language implementation

tcl-core — Tcl Core Team discussions about Tcl development