tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] valgrind exceptions

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

In a recent check-in related to zipfs initialization, I allocate a string
holding a path. This is global, initialized once, shared by threads. I have
not bothered to deallocate it as I do not see it worth the added machinery
required to delete at runtime (you have to be careful all threads exited
etc.).

 

Valgrind of course shows a leak of a 100 bytes or so.

 

Anybody object to adding a valgrind exception for such cases?

 

/Ashok

Re: [TCLCORE] CFV: TIP 726

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

Not looked in detail. Rushing to finish off a few things before I leave for a couple of weeks on unexpected travel with sporadic connectivity, but ...

I agree with changing 0x323c0 -> 0x110000. I had noticed that but did not know the reason for picking the last assigned character as opposed to last valid code point so left it alone.

Regarding invalid code points, I do not have strong opinions and would not object to any changes. As Harald commented in one of the tickets Tcl does not check for validity for strings passed through the C API and it should be up to the application or extension to ensure only valid data comes in (I think we already do this at the script level except possibly for surrogates). Tcl currently may interpret these as Cp1252, replace with U+FFFD, or leave as is depending on the API and specific code point. Garbage in, garbage out... I would prefer Tcl be consistent in handling but other than that any changes should be viewed as something applications should not have relied on anyways (invalid data is undefined behavior).



-----Original Message-----
From: Jan Nijtmans <jan...@gm...> 
Sent: Sunday, August 31, 2025 3:11 PM
To: apn...@ya...
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV: TIP 726

Op za 30 aug 2025 om 06:43 schreef Ashok:
> Regarding (1) -
>
> As a matter of principle, I prefer to check validity of data before being passed to external libraries (I treat utf8proc as such). When evaluating various libraries, some, like the very fast SIMD based library, expect valid data, others don't, and some differ in their treatment depending on function being called (including utf8proc). I don't think we want to be in the business of revisiting the Tcl implementation on a library change.
>
> But aside from those general principles, there are specific 9.0 compatibility issues with your implementation that I see looking at the code. For example, 9.0 Tcl_UniCharToUpper (and similar) map 0xFFFFFF to 0x1FFFFF while your code seemingly maps it to 0xFFFFFF. On a tangential note, utf8proc definitions of character classifications are not exactly the same as Tcl's historical classifications (including 9.0). I happen to think utf8proc is more appropriate and in line with the Unicode standard but as stated before, TIP 726 strives for full compatibility with Tcl 9.0. Any changes to character classification would be a compatibility change (no matter how small) and require a separate TIP.

You have a point here. The Tcl core only calls those
Tcl_UniCharToXXX() functions with values <= 0x10FFFF
(since that's the maximum number that Tcl_UtfToUnichar() can produce).
There are 3 ranges to consider
closer:
  1)  0xD800 - 0xDFFF.    Since Tcl 8.6 outputs the same value as
input, for compatibility
        we want 9.1 to do the same. It does.
  2) 0x110000 and 0x1FFFFF. Personally, I don't mind much what
Tcl_UniCharToXXX()
        does for values between 0x110000 and 0x1FFFFF. But since 9.0 outputs the
        same value as input, it makes sense to keep doing this in 9.1.
If utf8proc
        does something different (like returning -1), yes we should do
a range check.
   3) Values above 0xFFFFF. There are currently no testcases for that
(those should
       be added, but that's not TIP #726's fault).

Just one more remark for now. In tclUtf.c, I see:
    #define UNICODE_OUT_OF_RANGE(ch) (((ch) & 0x1FFFFF) >= 0x323C0)
Why 0x323C0? In Tcl 8.6 and 9.0, this number was generated from
the UnicodeData.txt file. It was simply the last character present
in the table. It is dangerous to keep this number: What if a future Unicode
version has more characters than that in the 3th plane (or adds a 4th plane)?

So I suggest to change this value to 0x110000 (or 0x40000, with the
remark that this should be increased if the 4th plane gets any characters)

Hope this helps,
    Jan Nijtmans

Re: [TCLCORE] Tcl_RegisterObjType(&tclIntType)

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

Sorry, ignore my question below. Had missed your earlier post about 9.0.2.

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Monday, September 1, 2025 10:45 AM
To: 'Miguel Bañón' <ba...@gm...>; 'Donal Fellows' <don...@ma...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] Tcl_RegisterObjType(&tclIntType)

 

Miguel,

 

Just to clarify as to current state, does this mean the tbcload committed to tcltk-depot still needs work to support 9.0? Or is the failure to load specific to 9.1?

 

/Ashok

 

From: Miguel Bañón <ba...@gm... <mailto:ba...@gm...> > 
Sent: Monday, August 4, 2025 9:59 PM
To: Donal Fellows <don...@ma... <mailto:don...@ma...> >
Cc: tcl...@li... <mailto:tcl...@li...> 
Subject: Re: [TCLCORE] Tcl_RegisterObjType(&tclIntType)

 

Thank you both for your answers. 

 

I got tdbcload from https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9

 

https://www.tcl3d.org/bawt/download/InputLibs/tbcload-1.7.2.7z claims to be ported, but fails to load because of this issue

 

Is there any other source for a 9-ready tbcload?

 

Best regards,

 

Miguel

 

 

On Aug 4, 2025, at 5:50 PM, Donal Fellows <don...@ma... <mailto:don...@ma...> > wrote:

 

A bigger practical change for tbcload in 9.1 is that there's a new aux data type (for the new kind of jump table index type); those require extra handling. The changes for 8.6 to 9.0 should be trivial. There may be new opcodes (I forget if this is so) but they should be trivial extensions; the semantic differences don't affect the ability of the engine to serialise. (A rebuild is still necessary, but should be trivial.)

 

9.1 currently is expected to be able to read bytecode created with 9.0, but the reverse is definitely not true.

 

Donal.

 

-------- Original message --------

From: Harald Oehlmann <har...@el... <mailto:har...@el...> > 

Date: 04/08/2025 15:26 (GMT+00:00) 

To: Miguel Bañón <ba...@gm... <mailto:ba...@gm...> > 

Cc: tcl...@li... <mailto:tcl...@li...>  

Subject: Re: [TCLCORE] Tcl_RegisterObjType(&tclIntType) 

 

AFAIK there is already a 9.0 ready tdbcload. I don't remember where.
Remark, that 9.1 will be considerably different, as there are a lot of 
new byte codes.
Andreas reported about this in one of the biweekly meetings.

 

Re: [TCLCORE] Tcl_RegisterObjType(&tclIntType)

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

Miguel,

 

Just to clarify as to current state, does this mean the tbcload committed to tcltk-depot still needs work to support 9.0? Or is the failure to load specific to 9.1?

 

/Ashok

 

From: Miguel Bañón <ba...@gm...> 
Sent: Monday, August 4, 2025 9:59 PM
To: Donal Fellows <don...@ma...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] Tcl_RegisterObjType(&tclIntType)

 

Thank you both for your answers. 

 

I got tdbcload from https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9

 

https://www.tcl3d.org/bawt/download/InputLibs/tbcload-1.7.2.7z claims to be ported, but fails to load because of this issue

 

Is there any other source for a 9-ready tbcload?

 

Best regards,

 

Miguel

 





On Aug 4, 2025, at 5:50 PM, Donal Fellows <don...@ma... <mailto:don...@ma...> > wrote:

 

A bigger practical change for tbcload in 9.1 is that there's a new aux data type (for the new kind of jump table index type); those require extra handling. The changes for 8.6 to 9.0 should be trivial. There may be new opcodes (I forget if this is so) but they should be trivial extensions; the semantic differences don't affect the ability of the engine to serialise. (A rebuild is still necessary, but should be trivial.)

 

9.1 currently is expected to be able to read bytecode created with 9.0, but the reverse is definitely not true.

 

Donal.

 

-------- Original message --------

From: Harald Oehlmann <har...@el... <mailto:har...@el...> > 

Date: 04/08/2025 15:26 (GMT+00:00) 

To: Miguel Bañón <ba...@gm... <mailto:ba...@gm...> > 

Cc: tcl...@li... <mailto:tcl...@li...>  

Subject: Re: [TCLCORE] Tcl_RegisterObjType(&tclIntType) 

 

AFAIK there is already a 9.0 ready tdbcload. I don't remember where.
Remark, that 9.1 will be considerably different, as there are a lot of 
new byte codes.
Andreas reported about this in one of the biweekly meetings.



 

Re: [TCLCORE] Need help with Tcl-GLib event integration

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

A quick follow up...

As it turns out, my C code was plenty robust - in fact, I threw out a 
lot of the modifications suggested by AI and went with a simple custom 
event source as suggested at the Tcl wiki. There's even an example there 
of Gtk event loop integration; it was trivial to swap the Gtk calls for 
GLib.

Additional debugging showed that the event flood was happening on focus 
events. After turning over every stone in the C code, I checked the 
script-level implementation and found a {bind all <FocusIn> 
::blah::blah::} that was intended for Windows. Turns out that was not 
only unnecessary on X11, it was downright destructive. Limiting that 
call to Windows seems to have fixed the problem.

This has been holding me up for weeks, and it turns out it's one line of 
code at the script level! Never underestimate Tcl/Tk's power. :-)

I have more polishing and fine-tuning to do on the X11 accessibility 
code, but now the foundation is solid. I'll be able to ask for review 
and a TIP in the near future.

Brian, thanks for your input! It got me thinking about this in different 
ways and I was able to find a solution.

All best,

Kevin

On 8/27/25 7:32 AM, Kevin Walzer wrote:
> 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
>>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV: TIP 726

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

Op za 30 aug 2025 om 06:43 schreef Ashok:
> Regarding (1) -
>
> As a matter of principle, I prefer to check validity of data before being passed to external libraries (I treat utf8proc as such). When evaluating various libraries, some, like the very fast SIMD based library, expect valid data, others don't, and some differ in their treatment depending on function being called (including utf8proc). I don't think we want to be in the business of revisiting the Tcl implementation on a library change.
>
> But aside from those general principles, there are specific 9.0 compatibility issues with your implementation that I see looking at the code. For example, 9.0 Tcl_UniCharToUpper (and similar) map 0xFFFFFF to 0x1FFFFF while your code seemingly maps it to 0xFFFFFF. On a tangential note, utf8proc definitions of character classifications are not exactly the same as Tcl's historical classifications (including 9.0). I happen to think utf8proc is more appropriate and in line with the Unicode standard but as stated before, TIP 726 strives for full compatibility with Tcl 9.0. Any changes to character classification would be a compatibility change (no matter how small) and require a separate TIP.

You have a point here. The Tcl core only calls those
Tcl_UniCharToXXX() functions with values <= 0x10FFFF
(since that's the maximum number that Tcl_UtfToUnichar() can produce).
There are 3 ranges to consider
closer:
  1)  0xD800 - 0xDFFF.    Since Tcl 8.6 outputs the same value as
input, for compatibility
        we want 9.1 to do the same. It does.
  2) 0x110000 and 0x1FFFFF. Personally, I don't mind much what
Tcl_UniCharToXXX()
        does for values between 0x110000 and 0x1FFFFF. But since 9.0 outputs the
        same value as input, it makes sense to keep doing this in 9.1.
If utf8proc
        does something different (like returning -1), yes we should do
a range check.
   3) Values above 0xFFFFF. There are currently no testcases for that
(those should
       be added, but that's not TIP #726's fault).

Just one more remark for now. In tclUtf.c, I see:
    #define UNICODE_OUT_OF_RANGE(ch) (((ch) & 0x1FFFFF) >= 0x323C0)
Why 0x323C0? In Tcl 8.6 and 9.0, this number was generated from
the UnicodeData.txt file. It was simply the last character present
in the table. It is dangerous to keep this number: What if a future Unicode
version has more characters than that in the 3th plane (or adds a 4th plane)?

So I suggest to change this value to 0x110000 (or 0x40000, with the
remark that this should be increased if the 4th plane gets any characters)

Hope this helps,
    Jan Nijtmans

Re: [TCLCORE] CFV: TIP 726

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

And to one more point (yeah, I know I said this is not a productive use of my time!) ...

 

> I object to making such a change in existing code,

 

I didn’t just randomly make changes in existing code. I was modifying those lines to call the utf8proc functions and used the expression forms that I saw as natural.

 

Now really ‘nuff said from my side.

 

/Ashok

 

-----Original Message-----
From: Jan Nijtmans <jan...@gm...> 
Sent: Saturday, August 30, 2025 8:14 PM
To: apn...@ya...
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV: TIP 726

 

Op za 30 aug 2025 om 06:43 schreef Ashok:

> Regarding (1) -

 

I'll come back later on this one.

 

> Regarding (2) -

> 

> It is not clear what you mean by more efficient when the compiled instruction stream is identical at least for clang x64 and gcc arm64. See  <https://godbolt.org/z/8afa54eh3> https://godbolt.org/z/8afa54eh3.  I wrote in the style I did because (in my mind of course) it was more natural and clearer to look up the bit in the mask than shifting the mask to look at the bit. I verified with only two compilers and architectures but see no reason to claim either shift would be more efficient. Compilers are smarter than me.

 

More efficient means more efficient, so less instructions. Try the

same experiment

without the "-O2", an you will see that the non-optimized version is longer than

the optimized one. The optimizer is smart enough to realize that a right-shift

is better here, so it changes the left shift to a right-shift.

The original author of the code in tclUtf.c was smart enough

to realize this, and I realize it too. We don't want less efficient code in

debug mode (in which the optimizer is disabled).

 

I object to making such a change in existing code, without

realizing what was behind it. You could have asked before.

 

Sorry,

       Jan Nijtmans

Re: [TCLCORE] CFV: TIP 726

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

> We don't want less efficient code in debug mode (in which the optimizer is disabled).

 

So if I understand you correctly, the generated code in a release build is identical but your objection is that the debug builds are not?

 

This is just absurd. Sorry.

 

Turning off optimization generates so much rubbish code (from an efficiency point of view) that a couple of instructions are completely immaterial. Worrying about speed in a non-optimized build is something I have never ever heard of and that too in interpreters that are never really speed demons in any case.

 

Being smart is not about bit twiddling any more. That time passed with the compilers that arrived about the turn of the century or before.

 

Do as you please now that the code has been merged into the trunk. Revert the shifts, or not, whatever. Not a productive use of my time to go back and forth on this.

 

/Ashok

 

 

-----Original Message-----
From: Jan Nijtmans <jan...@gm...> 
Sent: Saturday, August 30, 2025 8:14 PM
To: apn...@ya...
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV: TIP 726

 

Op za 30 aug 2025 om 06:43 schreef Ashok:

> Regarding (1) -

 

I'll come back later on this one.

 

> Regarding (2) -

> 

> It is not clear what you mean by more efficient when the compiled instruction stream is identical at least for clang x64 and gcc arm64. See  <https://godbolt.org/z/8afa54eh3> https://godbolt.org/z/8afa54eh3.  I wrote in the style I did because (in my mind of course) it was more natural and clearer to look up the bit in the mask than shifting the mask to look at the bit. I verified with only two compilers and architectures but see no reason to claim either shift would be more efficient. Compilers are smarter than me.

 

More efficient means more efficient, so less instructions. Try the

same experiment

without the "-O2", an you will see that the non-optimized version is longer than

the optimized one. The optimizer is smart enough to realize that a right-shift

is better here, so it changes the left shift to a right-shift.

The original author of the code in tclUtf.c was smart enough

to realize this, and I realize it too. We don't want less efficient code in

debug mode (in which the optimizer is disabled).

 

I object to making such a change in existing code, without

realizing what was behind it. You could have asked before.

 

Sorry,

       Jan Nijtmans

Re: [TCLCORE] CFV: TIP 726

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

Op za 30 aug 2025 om 06:43 schreef Ashok:
> Regarding (1) -

I'll come back later on this one.

> Regarding (2) -
>
> It is not clear what you mean by more efficient when the compiled instruction stream is identical at least for clang x64 and gcc arm64. See https://godbolt.org/z/8afa54eh3.  I wrote in the style I did because (in my mind of course) it was more natural and clearer to look up the bit in the mask than shifting the mask to look at the bit. I verified with only two compilers and architectures but see no reason to claim either shift would be more efficient. Compilers are smarter than me.

More efficient means more efficient, so less instructions. Try the
same experiment
without the "-O2", an you will see that the non-optimized version is longer than
the optimized one. The optimizer is smart enough to realize that a right-shift
is better here, so it changes the left shift to a right-shift.
The original author of the code in tclUtf.c was smart enough
to realize this, and I realize it too. We don't want less efficient code in
debug mode (in which the optimizer is disabled).

I object to making such a change in existing code, without
realizing what was behind it. You could have asked before.

Sorry,
       Jan Nijtmans

Re: [TCLCORE] CFV: TIP 726

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

TIP 726 has been accepted and merged into main.

Vote-Summary:	Accepted 6/0/0
Votes-For:	AK, AN, HO, KW, JN, MC, RA, SL
Votes-Against:	none
Votes-Present:

Thank you all for review and comments.

/Ashok


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

Re: [TCLCORE] CFV: TIP 726

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

Jan,

I've moved your changes to the tip-726-jan branch for the reasons below. I do not plan to merge them as part of TIP 726.

Regarding (1) - 

As a matter of principle, I prefer to check validity of data before being passed to external libraries (I treat utf8proc as such). When evaluating various libraries, some, like the very fast SIMD based library, expect valid data, others don't, and some differ in their treatment depending on function being called (including utf8proc). I don't think we want to be in the business of revisiting the Tcl implementation on a library change. 

But aside from those general principles, there are specific 9.0 compatibility issues with your implementation that I see looking at the code. For example, 9.0 Tcl_UniCharToUpper (and similar) map 0xFFFFFF to 0x1FFFFF while your code seemingly maps it to 0xFFFFFF. On a tangential note, utf8proc definitions of character classifications are not exactly the same as Tcl's historical classifications (including 9.0). I happen to think utf8proc is more appropriate and in line with the Unicode standard but as stated before, TIP 726 strives for full compatibility with Tcl 9.0. Any changes to character classification would be a compatibility change (no matter how small) and require a separate TIP.

Regarding (2) - 

It is not clear what you mean by more efficient when the compiled instruction stream is identical at least for clang x64 and gcc arm64. See https://godbolt.org/z/8afa54eh3.  I wrote in the style I did because (in my mind of course) it was more natural and clearer to look up the bit in the mask than shifting the mask to look at the bit. I verified with only two compilers and architectures but see no reason to claim either shift would be more efficient. Compilers are smarter than me.

As always, thanks a lot for reviewing but with a (mild) request to make future proposed changes to TIP's on separate branches once the vote is done and the branch is about to be merged.

/Ashok

-----Original Message-----
From: Jan Nijtmans <jan...@gm...> 
Sent: Friday, August 29, 2025 7:05 PM
To: apn...@ya...
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV: TIP 726

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