tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP 716 ready for comments

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

Kevin,

I'm afraid I don't really know the answer to your concern about the impact of dropping MSVCRT support. My impression is that most devs are migrating to UCRT but that is only an impression, not hard evidence.

/Ashok
________________________________
From: Kevin Kenny <kev...@gm...>
Sent: Tuesday, May 6, 2025 11:58 PM
To: Ashok Nadkarni <apn...@ya...>
Cc: Jan Nijtmans <jan...@gm...>; Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] TIP 716 ready for comments

I do worry a bit about Tcl extensions whose purpose it is to wrap third-party code that may be linked with a different C runtime. While I know - or rather can relearn when I must - how to manage different runtimes within the same process, I've certainly seen a lot of third-party libraries that demand that the whole process use the same runtime (usually MSVCRT) because otherwise memory corruption results - many programmers are unaware of the possibility that malloc() and free() may be coming from different runtimes if the respective callers were built in different DLLs.  Would we want to continue supporting MSVCRT(D) and statically linked LIBC's for that reason?

On Tue, May 6, 2025 at 3:48 AM Ashok Nadkarni via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote:
Jan,

It occurs to me that 9.1 will stop supporting Windows releases prior to Win 10. Given that, we can simply drop support for MinGW/MSVCRT as all Windows systems will have UCRT installed. If that is agreeable, we can drop the discussion around MSVCRT and focus on other points of contention in 716/718.

/Ashok


________________________________
From: Ashok Nadkarni via Tcl-Core
Sent: Tuesday, May 6, 2025 10:17 AM
To: Jan Nijtmans
Cc: Tcl Core List
Subject: Re: [TCLCORE] TIP 716 ready for comments

No, I'm afraid your post below does not clarify at all. That link you gave pertains to UCRT, not MSVCRT which, unless I read with my blinders on, is not mentioned anywhere on that page. Adding UCRT to the discussion, first with passing of FILE* between runtimes, and now to discussion of setlocale(), only serves to obfuscate further.

Further,  given the link you gave has no discussion of MSVCRT, what was the source of your statement <MSVCRT supports the "utf-8" _encoding_, not the "utf-8" _locale_,> ? If you can provide the basis for your conclusion, that would really help.

/Ashok


________________________________
From: Jan Nijtmans
Sent: Tuesday, May 6, 2025 3:08 AM
To: Ashok Nadkarni
Cc: Tcl Core List
Subject: Re: [TCLCORE] TIP 716 ready for comments

Op ma 5 mei 2025 om 19:22 schreef Ashok Nadkarni:
> Now, with regard to the mingw msvcrt comment...
>
> It seems to me from your comment about GetACP() in MingW that you think I was suggesting the manifest would not work in MingW. That is not so. GetACP() will work the same way and return utf-8 in the presence of a manifest but the problem is MSVCRT does not support UTF-8.
>
> I do not know if you read the link that I had referenced in the TIP https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt
>
> To quote from there - It doesn't support the UTF-8 locale ("It" being MSVCRT)
>
> When the official release document says MSVCRT does not support UTF-8, I take that at face value.

Let me clarify then. See:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale?view=msvc-170

With msvcrt, you cannot do a setlocale("en_US.UTF8"), with UCRT it works;

Tcl doesn't support that either. The only setlocale() call is here:
    <https://core.tcl-lang.org/tcl/file?name=win/tclAppInit.c&ci=ead995eddf5fff98&ln=111>

MSVCRT supports the "utf-8" _encoding_, not the "utf-8" _locale_,
that's a different thing

Hope this clarifies enough.

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


--
73 de ke9tv/2, Kevin

Re: [TCLCORE] To the best of my recollection regarding TIP#302

[Gustaf N. (sslmail) <ne...@wu...>]

> On 07.05.2025, at 15:51, Dipl. Ing. Sergey G. Brester via Tcl-Core <tcl...@li...> wrote:
> Sure, if one'd consider it as a pure enhancement...
> I see it rather as a bug-fix 
> 
I’ve nothing to say, but I do agree with Sergey on that matter. NaviServer is full of timeouts, time-trigger procs, etc. 
Being able to rely on a monotonic clock will improve my sleep.

-g

Re: [TCLCORE] To the best of my recollection regarding TIP#302

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

 

Sure, if one'd consider it as a pure enhancement...
I see it rather as a bug-fix (and an additional `after at` just to give
the user the possibility to handle, if the bug-fix would affect his
"cron" similar timers and they must match the wall clock as closely as
possible.

As already said, the factors of deviations are not comparable at all
(the mentioned 300000% and 0.03%). 

For instance, remaining by Donals example with hibernation (but also
another scenarios like suspending or pausing of VM, e. g. to temporary
free resources for some other tasks, to create offline-snapshot, to move
VM to other host, etc) - even the forward jumps may be an issue. So an
example code like this: 

 set timeout_ev [after 10000 { set ::state "TIMEOUT" }]
# do some very short async work (and timeout in 10 secs as very
unexpected): 
vwait ::state 
IF { $::state eq "TIMEOUT" } { error "BOOM: timeout occurred" } 
after cancel $timeout_ev 

or simplified variant like this (implementation of my RFE): 

 # do some very short async work (and timeout in 10 secs as very
unexpected): 
IF { [vwait 10000 ::state] } { error "BOOM: timeout occurred" } 

WOULD ALMOST ALWAYS FAIL with the timeout on such suspended
interruptions, IF THEY ARE USING WALL- INSTEAD OF MONOTONIC TIMERS and
the time gets synchronized immediately by resume (although otherwise the
issue becomes simply delayed).
While vice versa, with mono-clock (as implemented in my RFE), they would
run as expected, however the "opposite" timers (like cron-similar events
expecting wall-near time) could be executed just a bit later, but in
case of hibernation or long pause, it is anyway unclear (e. g. if the
end of the hibernation phase gets longer than the time of trigger, and
the VM would be resumed later it'd happen in any case delayed)... 
Anyway the injury potential is not comparable at all. I think it is
obvious to everyone, isn't it? 

Regards,
Sergey. 

06.05.2025 20:34, Kevin Kenny wrote: 

> On Tue, May 6, 2025 at 2:25 PM Dipl. Ing. Sergey G. Brester via Tcl-Core <tcl...@li...> wrote: 
> 
>> But, especially following your arguments, one can then say - lets switch `after` to mono-time by default (and provide `after -at` or `after -wall` or whatever for wall time)... Just because related to your assumptions, it wouldn't affect anything anyway (because "no long way jumps" is equal to "mono-time runs almost synchronous with wall-time").
> 
> My inclination is 'let's reserve script-breaking changes for major releases, preparing them with 'retroforward compatibility'. On the other hand, let's not go a quarter-century between major releases ever again. I don't know how we wound up trapped in that mind set; it was toxic. -- 
> 
> 73 de ke9tv/2, Kevin
 

[TCLCORE] CFV TIP's #698, #704, #717, #719

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

This is a CFV for 4 TIP's:
1) TIP #698: Handle negative screen distances
    <https://core.tcl-lang.org/tips/doc/trunk/tip/698.md>
2) TIP #704: extend Tk_CanvasTextInfo
   <https://core.tcl-lang.org/tips/doc/trunk/tip/704.md>
3) TIP #717: New function: Tcl_AttemptCreateHashEntry()
   <https://core.tcl-lang.org/tips/doc/trunk/tip/717.m>
4) TIP #719: Add new states to make images of ttk::treeview and
ttk::notebook customable
   <https://core.tcl-lang.org/tips/doc/trunk/tip/719.md>

Please send me your votes by May 17, 12:00 UTC.
[clock format 1747483200]

If there are some suggestions how the Panic in TIP #717
should look like, please let me know.

My votes:
TIP #698:   YES
TIP #704:   YES
TIP #717:   YES
TIP #719:   YES

Regards,
         Jan Nijtmans

Re: [TCLCORE] To the best of my recollection regarding TIP#302

[Kevin K. <kev...@gm...>]

On Tue, May 6, 2025 at 2:25 PM Dipl. Ing. Sergey G. Brester via Tcl-Core <
tcl...@li...> wrote:

> But, especially following your arguments, one can then say - lets switch
> `after` to mono-time by default (and provide `after -at` or `after -wall`
> or whatever for wall time)... Just because related to your assumptions, it
> wouldn't affect anything anyway (because "no long way jumps" is equal to
> "mono-time runs almost synchronous with wall-time").
>
My inclination is 'let's reserve script-breaking changes for major
releases, preparing them with 'retroforward compatibility'.   On the other
hand, let's not go a quarter-century between major releases ever again. I
don't know how we wound up trapped in that mind set; it was toxic.
-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] TIP 716 ready for comments

[Kevin K. <kev...@gm...>]

I do worry a bit about Tcl extensions whose purpose it is to wrap
third-party code that may be linked with a different C runtime. While I
know - or rather can relearn when I must - how to manage different runtimes
within the same process, I've certainly seen a lot of third-party libraries
that demand that the whole process use the same runtime (usually MSVCRT)
because otherwise memory corruption results - many programmers are unaware
of the possibility that malloc() and free() may be coming from different
runtimes if the respective callers were built in different DLLs.  Would we
want to continue supporting MSVCRT(D) and statically linked LIBC's for that
reason?

On Tue, May 6, 2025 at 3:48 AM Ashok Nadkarni via Tcl-Core <
tcl...@li...> wrote:

> Jan,
>
> It occurs to me that 9.1 will stop supporting Windows releases prior to
> Win 10. Given that, we can simply drop support for MinGW/MSVCRT as all
> Windows systems will have UCRT installed. If that is agreeable, we can drop
> the discussion around MSVCRT and focus on other points of contention in
> 716/718.
>
> /Ashok
>
>
> ------------------------------
> *From:* Ashok Nadkarni via Tcl-Core
> *Sent:* Tuesday, May 6, 2025 10:17 AM
> *To:* Jan Nijtmans
> *Cc:* Tcl Core List
> *Subject:* Re: [TCLCORE] TIP 716 ready for comments
>
> No, I'm afraid your post below does not clarify at all. That link you gave
> pertains to UCRT, not MSVCRT which, unless I read with my blinders on, is
> not mentioned anywhere on that page. Adding UCRT to the discussion, first
> with passing of FILE* between runtimes, and now to discussion of
> setlocale(), only serves to obfuscate further.
>
> Further,  given the link you gave has no discussion of MSVCRT, what was
> the source of your statement <*MSVCRT supports the "utf-8" _encoding_,
> not the "utf-8" _locale_*,> ? If you can provide the basis for your
> conclusion, that would really help.
>
> /Ashok
>
>
> ------------------------------
> *From:* Jan Nijtmans
> *Sent:* Tuesday, May 6, 2025 3:08 AM
> *To:* Ashok Nadkarni
> *Cc:* Tcl Core List
> *Subject:* Re: [TCLCORE] TIP 716 ready for comments
>
> Op ma 5 mei 2025 om 19:22 schreef Ashok Nadkarni:
> > Now, with regard to the mingw msvcrt comment...
> >
> > It seems to me from your comment about GetACP() in MingW that you think
> I was suggesting the manifest would not work in MingW. That is not so.
> GetACP() will work the same way and return utf-8 in the presence of a
> manifest but the problem is MSVCRT does not support UTF-8.
> >
> > I do not know if you read the link that I had referenced in the TIP
> https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt
> >
> > To quote from there - It doesn't support the UTF-8 locale ("It" being
> MSVCRT)
> >
> > When the official release document says MSVCRT does not support UTF-8, I
> take that at face value.
>
> Let me clarify then. See:
>
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale?view=msvc-170
>
> With msvcrt, you cannot do a setlocale("en_US.UTF8"), with UCRT it works;
>
> Tcl doesn't support that either. The only setlocale() call is here:
>     <
> https://core.tcl-lang.org/tcl/file?name=win/tclAppInit.c&ci=ead995eddf5fff98&ln=111
> >
>
> MSVCRT supports the "utf-8" _encoding_, not the "utf-8" _locale_,
> that's a different thing
>
> Hope this clarifies enough.
>
> Happy hacking,
>      Jan Nijtmans
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>


-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] To the best of my recollection regarding TIP#302

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

 

Few minutes is not really a long way for "normal" wall clock (and
validation of certs is mostly redundant here, because nobody really
waiting to the last minutes to prolong the certs)... But it may be the
long way for internal stuff like timeouts, lock-attempts or whatever
acting normally in few milli-, micro-, or even nano-second ranges, let
alone real-time near infrastructure.

As for the scenarios - I saw it verifiably in our (tcl-based)
application server on the VMs of customers sometimes, where the time
running faster for some reason (so NTP adjusted the time backwards)...
Sure it is probably not regular case and goes to some issues with the
host system's clock or VMs time-sync settings and could be "solved" or
workarounded at least by increased NTP periodicity... But in enterprise
world one must firstly prove the issue and justify such change and even
then, it may takes longer as one could assume to get in production.
But even smaller jumps are "bad", especially if some handling of some
facilities freezes abrupt (due to "longer" lock-attempt or whatever
taking few milliseconds in regular case) - timing issues are the worse
thing ever, especially because sometimes it behaves like a snowball (for
instance the longer it takes, the more clicks impatient users doing, the
more requests the service get in the queue, ..., the longer it'd take
till everything would calm down till it becomes normalized).

Regarding "modern operating systems" - exactly therefore many of them
are moving to use monotonic time instead of "wall" time, even because it
is not really worthy of trust and may jump. This is basically the reason
why monotonic time exists. 

>From my point of view, everything (like `after`) expecting interval and
not the end-time, has to use monotonic time.
Everything else (like cron with fixed end-time) is rather an exception,
and people used `after` only because there was noting else to achieve
this.

But, especially following your arguments, one can then say - lets switch
`after` to mono-time by default (and provide `after -at` or `after
-wall` or whatever for wall time)... Just because related to your
assumptions, it wouldn't affect anything anyway (because "no long way
jumps" is equal to "mono-time runs almost synchronous with wall-time"). 

Hope this helps,
Serg. 

06.05.2025 18:16, Donal Fellows wrote: 

> What are the scenarios in which the clock jumps backwards a long way, except via manual manipulation? That matters because many modern operating systems are moving to not giving users the ability to manipulate the clock in that way as the clock is essential for the proper operation of some of their security measures (such as validation of certificates). If this is all a huge fight over an edge case, I'm going to suggest we don't get excited about it. 
> 
> Forward jumps are different (because they can happen because the machine was hibernated) as are small jumps back (an NTP update fixing a clock that's a bit fast). But there shouldn't be any large reverse clock changes from normal user operations. (Changing the timezone shouldn't affect the clock we care about. Despite Windows being Windows.) 
> 
> Donal. 
> 
> -------------------------
> 
> FROM: Dipl. Ing. Sergey G. Brester via Tcl-Core
> SENT: Tuesday, May 06, 2025 12:53
> TO: Harald Oehlmann
> CC: tcl...@li...
> SUBJECT: Re: [TCLCORE] To the best of my recollection regarding TIP#302 
> 
> Comments inlined... 
> 
> 06.05.2025 10:34, Harald Oehlmann wrote: 
> 
>> Christian, Sergey, thank you for your valuable contributions. We need that!
>> It is an absolute requirement for an integration system to work.
>> 
>> Yesterday, in the meeting, there was a strong objection to:
>> - change current after in using the wall clock
> 
> And they are?
> The thing is: 
> 
> * one can consider the change of current `after` to monotonic time as a bug-fix, because otherwise it can unexpectedly take too long by possible time jumps backwards (or too short by forwards jumps), e. g. abrupt the timer `after 100 ...` will be triggered in 1 hour instead of few milliseconds. With other words it is not a feature (only), but rather a bugfix in my opinion.
> * mostly (probably 99%) `after` will be used for short intervals, so the monotonic time is not only better suitable in this case, but absolute necessary; In event-driven application it is mandatory to handle any kind of timeout properly. For instance, before switch the implementation to mono-base we observed sporadic large "hangs" of whole system (distributed computing).
> 
> * 
> even for the case where `after` is used for long playing timers (like cron tasks, etc), it is not a big issue, because in this case it'd be only affected (and the difference becomes visible) by the time adjustments, and by such long timers it is not so flashy as by the short timers, because would only take a small fraction compared to whole interval.
> Just compare: 
> 
> after-base 
> timer 
> time jumps back for 5 min 
> deviation 
> 
> wall clock 
> after 100ms (timeout) 
> execution delayed for 5 minutes 
> 300000% 
> 
> after 1day (cron-time) 
> execution happens as "expected" 
> - 
> 
> monotonic 
> after 100ms (timeout) 
> execution happens as expected 
> - 
> 
> after 1day (cron-time) 
> execution happens 5 minutes earlier 
> 0.3% 
> 
> The issue is obvious, isn't it?
> Let alone if the "expected" behaviour of cron-time really to be as precise as possible (by wall time),
> it could be relative fast rewritten using new handler (after -at or whatever);
> Sure not well backwards compatible, but considering the deviation factor surely justified and only correct in this way. * the change of after is not enough at all, to handle everything properly we need to replace several timeouts with monotonic time (otherwise same issue as mentioned above with the hangs are unavoidable and especially evil by locks, up to absolute "no go" by conditional cross-process locks).
> 
>> - not use a command switch, but a new command for the new monolitic after, as this is seen as the future.
>> 
>> The way is not so important. Important is to get it. But sematics is always good for discussions ;-).
> 
> Sure. However in my case it is important, since already used dozen years. 
> But it is indeed a matter of discussion, however I am sure the implementation of both (mono-time and `after -at`) needs to be done simultaneously (and released together). 
> 
>> Christian, I am probably blind. Where is your "after -at" patch ?
> 
>> Sergey, would it possible to extract the monolitic clock part of your big code contributions ?
> 
> Well, it is a bit complex - some changes (timers rewrite, event handling, etc) are strict necessary, another (vwait, options for vwait/after for event masks, higher resolution, etc) are pure features fewer related to the monotonic clock, but depend on it... 
> We have already discussed the subject several times in tclchat. For example with Kevin Kenny, and IIRC the last conclusion was: 
> 
> - either to write several TIPs to discuss the RFE in parts (but let the code as is and adjust it later if expected);
> - or to split the code in few parts from scratch; 
> 
> Since the latter would also expect the same TIPs as in the former, possibly the right way is to start with the former. 
> 
> Regards,
> Serg. 
> 
> P.S. @Christian: your rude t-online provider rejected my mail on you yesterday with following error:
> 554 IP=... - None/bad reputation. Ask your postmaster for help or to contact to...@rx... for reset. (NOWL)
> Just to inform you, that they censor the customer's emails without their knowledge (I guess you were not notified about the mail or its reject). That "none" lets assume that they reject any mail from relays without reputation... I must admit, I never saw such a stupid block reason before.
 

Re: [TCLCORE] To the best of my recollection regarding TIP#302

[Kevin K. <kev...@gm...>]

On Mon, May 5, 2025 at 2:46 PM Christian Werner <
Chr...@t-...> wrote:

> Hello all,
>
> some points to discuss:
>
> * the clock domain should be switched from wall clock to a monotonic clock
> source in POSIX speak
> * this should ideally not have an impact on time computations in Tcl core
> * however, POSIX monotonic clock must be used in both clock_gettime() and
> condition variables
> * maybe it's a good idea to detect availability of monotonic clock and
> fall back to wall clock if not available
> * the time bound on slave interp evaluations is unfortunately in wall time
> which is IMO a failure in design
> * what about virtual time, can this be ditched entirely, there ain't no
> test cases and no examples
> * the "after -at" form is a special case to allow for cron like
> requirements, is this ever a use case?
> * what is the resolution of "after -at", when it's like cron one second
> seems enough
> * for symmetry another "after -mono" can be imagined which is like "after
> -at" but in the monotonic clock domain
> * the resolution of "after -mono" should be near the tick rates of
> contemporary OSes (e.g. milliseconds)
>

 Let me address some of the issues as I understand them.  (I know that I
don't have a vote - but I hope that I still know a thing or two about time.)

Tcl doesn't use a monotonic clock because at the time the [clock] system
was designed, there was no portable monotonic clock. In fact, available
high-resolution clocks were neither monotonic nor synchronized with civil
time - all the complexity of TIP 7 was to attempt to make a sane clock for
[after] to use on Windows.

Tcl also historically lacks a means for [after] to awaken a process at a
particular civil time.  This functionality was essential to applications
such as the NBC control system that I worked on. Television programming
needed a carefully, millisecond-level timed sequence of events moving
according to the civil clock. (This means that there is, indeed, a use case
for [after -at] or however we want to spell it. I would gladly have used
such functionality at the time, had it existed.  (Instead, a lot of the
timing was regulated by the timecode reader interrupting the host system
29.97 times a second.) The events on the NBC system were scheduled for
hours:minutes:seconds:frames, and so used 33.67 millisecond intervals for
standard definition, and 16.67 millisecond intervals for high definition.
One-second precision would not have sufficed.

It appears to me that the overwhelming majority of uses of [after] are
intended to provide fixed time intervals, for which a monotonic clock is
appropriate.  In fact, the use of [after] for civil time has always been
fraught, because the time interval passed in to select(), poll(), or
WaitForMultipleObjjects() refers to a hypothetical monotonic clock. If the
civil clock changes during the waiting period, it can result in weird
postponements of events. (The NBC system had a workaround for this, with a
time code appearing on a separate I/O device providing interrupts to allow
the Tcl clock to resynchronize itself.)

I don't know of any of the supported platforms, any more, that lack a
suitable monotonic clock. Even platforms like QNX or VxWorks, if they have
a clock at all, have a monotonic one available.

Having slave interp time bounds expressed in wall clock time is an obvious
bug. I know of no application that depends on clearing out a slave interp
by a particular time on the wall clock.

Virtual time is something for which I don't understand a Tcl-specific use
case. It was added to serve a particular ActiveState customer, and the
Activators were not at liberty to divulge details of the application. (I
suspect that the customer needed to test Tcl scripts in simulation, and
adjust the clock to replicate timing conditions for regression-testing
embedded systems.)  The change entered the code base in a way that today we
would consider somewhat irregular; we exercised rather looser control at
the time. Andreas Kupries might remember more.

Providing [after -at] and [after -mono] would be a good idea, since we
missed the boat for script incompatibilities in Tcl 9.  [after] without a
designation could be deprecated formally, or at least bear a warning that
the default interpretation will change to monotonic time in a future
release. Making ordinary [after] default to monotonic, like the 'creative
writing' fix and 'death to octal' is the sort of thing that is likely to
fix more bugs than it introduces, even if it were to be introduced without
warning.

[after] has always allowed the time to be specified in milliseconds, and
the only promise it has ever made is that events will not be delivered
early (with an implication that best efforts will be made to deliver them
on time). From time to time, I've seen requests for higher resolution, but
even millisecond resolution is challenging if you aren't on an RTOS.

In short:  monotonic [after] and a separate way to schedule events at
particular civil times (to a moderately high resolution) were always what I
wanted in the clock system, but the last time I made major changes, the
machinery to attain that goal didn't exist portably. (The idea of time on
Windows was quite benighted at the time, with the hardware clock being set
to local time for compatibility with DOS.)

As far as scenarios jumping the clock backward a long way,  if leap seconds
aren't a 'long way', there should be only act of God (hardware clock
failure, etc.), act of the operator, and Act of the Legislature. (If, for
instance, a hypothetical isolationist government were to degree that UTC
within a nation's control should follow whatever irregular clock rules that
nation has adopted.  There are certain governments for which such idiocy
wouldn't astonish me). To all three, I think we can get away with 'Nope!'
as an answer.



-- 
73 de ke9tv/2, Kevin

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

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

>
> I still have my suspicions about all the accreted special hooks in hash tables.  Will
> check as I can when I can.
>
It looks like the things I was recalling have mostly been cleared away in more recent
years of development.  A welcome discovery.  The main remaining wart is keeping
the Tcl_HashTable struct definition open and unable to resize or otherwise evolve
without breaking extensions.

I didn't find anything to cause me to reject TIP 717.

One nitpick is the error messages "memory error" and "Memory overflow".  Improve
those as you reasonably can.

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

Re: [TCLCORE] To the best of my recollection regarding TIP#302

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

What are the scenarios in which the clock jumps backwards a long way, except via manual manipulation? That matters because many modern operating systems are moving to not giving users the ability to manipulate the clock in that way as the clock is essential for the proper operation of some of their security measures (such as validation of certificates). If this is all a huge fight over an edge case, I'm going to suggest we don't get excited about it.

Forward jumps are different (because they can happen because the machine was hibernated) as are small jumps back (an NTP update fixing a clock that's a bit fast). But there shouldn't be any large reverse clock changes from normal user operations. (Changing the timezone shouldn't affect the clock we care about. Despite Windows being Windows.)

Donal.

________________________________
From: Dipl. Ing. Sergey G. Brester via Tcl-Core
Sent: Tuesday, May 06, 2025 12:53
To: Harald Oehlmann
Cc: tcl...@li...
Subject: Re: [TCLCORE] To the best of my recollection regarding TIP#302


Comments inlined...

06.05.2025 10:34, Harald Oehlmann wrote:

Christian, Sergey, thank you for your valuable contributions. We need that!
It is an absolute requirement for an integration system to work.

Yesterday, in the meeting, there was a strong objection to:
- change current after in using the wall clock

And they are?
The thing is:

  *   one can consider the change of current `after` to monotonic time as a bug-fix, because otherwise it can unexpectedly take too long by possible time jumps backwards (or too short by forwards jumps), e. g. abrupt the timer `after 100 ...` will be triggered in 1 hour instead of few milliseconds. With other words it is not a feature (only), but rather a bugfix in my opinion.
  *   mostly (probably 99%) `after` will be used for short intervals, so the monotonic time is not only better suitable in this case, but absolute necessary; In event-driven application it is mandatory to handle any kind of timeout properly. For instance, before switch the implementation to mono-base we observed sporadic large "hangs" of whole system (distributed computing).
  *
even for the case where `after` is used for long playing timers (like cron tasks, etc), it is not a big issue, because in this case it'd be only affected (and the difference becomes visible) by the time adjustments, and by such long timers it is not so flashy as by the short timers, because would only take a small fraction compared to whole interval.
Just compare:
after-base
timer
time jumps back for 5 min
deviation
wall clock
after 100ms (timeout)
execution delayed for 5 minutes
300000%
after 1day (cron-time)
execution happens as "expected"
-
monotonic
after 100ms (timeout)
execution happens as expected
-
after 1day (cron-time)
execution happens 5 minutes earlier
0.3%
The issue is obvious, isn't it?
Let alone if the "expected" behaviour of cron-time really to be as precise as possible (by wall time),
it could be relative fast rewritten using new handler (after -at or whatever);
Sure not well backwards compatible, but considering the deviation factor surely justified and only correct in this way.
  *   the change of after is not enough at all, to handle everything properly we need to replace several timeouts with monotonic time (otherwise same issue as mentioned above with the hangs are unavoidable and especially evil by locks, up to absolute "no go" by conditional cross-process locks).

- not use a command switch, but a new command for the new monolitic after, as this is seen as the future.

The way is not so important. Important is to get it. But sematics is always good for discussions ;-).

Sure. However in my case it is important, since already used dozen years.

But it is indeed a matter of discussion, however I am sure the implementation of both (mono-time and `after -at`) needs to be done simultaneously (and released together).

Christian, I am probably blind. Where is your "after -at" patch ?
Sergey, would it possible to extract the monolitic clock part of your big code contributions ?

Well, it is a bit complex - some changes (timers rewrite, event handling, etc) are strict necessary, another (vwait, options for vwait/after for event masks, higher resolution, etc) are pure features fewer related to the monotonic clock, but depend on it...

We have already discussed the subject several times in tclchat. For example with Kevin Kenny, and IIRC the last conclusion was:

- either to write several TIPs to discuss the RFE in parts (but let the code as is and adjust it later if expected);
- or to split the code in few parts from scratch;

Since the latter would also expect the same TIPs as in the former, possibly the right way is to start with the former.

Regards,
Serg.

P.S. @Christian: your rude t-online provider rejected my mail on you yesterday with following error:
554 IP=... - None/bad reputation. Ask your postmaster for help or to contact to...@rx... for reset. (NOWL)
Just to inform you, that they censor the customer's emails without their knowledge (I guess you were not notified about the mail or its reject). That "none" lets assume that they reject any mail from relays without reputation... I must admit, I never saw such a stupid block reason before.

Re: [TCLCORE] TIP 716 ready for comments

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

Jan,

I specifically said the issue is about  MSVCRT, not UCRT and you respond again with UCRT docs from the same page!

 :shrug:
________________________________
From: Jan Nijtmans <jan...@gm...>
Sent: Tuesday, May 6, 2025 3:26 PM
To: Ashok Nadkarni <apn...@ya...>
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] TIP 716 ready for comments

Op di 6 mei 2025 om 06:47 schreef Ashok Nadkarni:
> Further,  given the link you gave has no discussion of MSVCRT, what was the source of your statement <MSVCRT supports the "utf-8" _encoding_, not the "utf-8" _locale_,> ? If you can provide the basis for your conclusion, that would really help.

Start reading the "UTF-8 support" chapter, Quoting:
"Starting in Windows 10 version 1803 (10.0.17134.0), the Universal C
Runtime supports using a UTF-8 code page. The change means that char
strings passed to C runtime functions can expect strings in the UTF-8
encoding. To enable UTF-8 mode, use ".UTF8" as the code page when
using setlocale"

Then realize that Tcl uses setlocale(), by setting the locale to "C".
That means for
the C runtime that everything is just bytes, no interpretation to the
bytes is done.
That's the mode Tcl uses. Microsoft only implemented the ".UTF8" locale in
UCR > 1803, not in any earlier runtimes. Since Tcl doesn't use this mode
anyway, who cares! The C runtime only knows about bytes then.

Hope this helps,
       Jan Nijtmans

Re: [TCLCORE] To the best of my recollection regarding TIP#302

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

 

Comments inlined... 

06.05.2025 10:34, Harald Oehlmann wrote: 

> Christian, Sergey, thank you for your valuable contributions. We need that!
> It is an absolute requirement for an integration system to work. 
> 
> Yesterday, in the meeting, there was a strong objection to:
> - change current after in using the wall clock

And they are?
The thing is:

 	* one can consider the change of current `after` to monotonic time as
a bug-fix, because otherwise it can unexpectedly take too long by
possible time jumps backwards (or too short by forwards jumps), e. g.
abrupt the timer `after 100 ...` will be triggered in 1 hour instead of
few milliseconds. With other words it is not a feature (only), but
rather a bugfix in my opinion.
 	* mostly (probably 99%) `after` will be used for short intervals, so
the monotonic time is not only better suitable in this case, but
absolute necessary; In event-driven application it is mandatory to
handle any kind of timeout properly. For instance, before switch the
implementation to mono-base we observed sporadic large "hangs" of whole
system (distributed computing).

	* even for the case where `after` is used for long playing timers (like
cron tasks, etc), it is not a big issue, because in this case it'd be
only affected (and the difference becomes visible) by the time
adjustments, and by such long timers it is not so flashy as by the short
timers, because would only take a small fraction compared to whole
interval. 
Just compare:

		AFTER-BASE
		TIMER
		TIME JUMPS BACK FOR 5 MIN
		DEVIATION

 		wall clock
 		after 100ms (timeout)
 		execution delayed for 5 minutes
 		300000%

 		after 1day (cron-time)
 		execution happens as "expected"
 		-

 		monotonic
 		after 100ms (timeout)
 		execution happens as expected
 		-

 		after 1day (cron-time)
 		execution happens 5 minutes earlier
 		0.3%

 The issue is obvious, isn't it?
Let alone if the "expected" behaviour of cron-time really to be as
precise as possible (by wall time),
it could be relative fast rewritten using new handler (after -at or
whatever);
Sure not well backwards compatible, but considering the deviation factor
surely justified and only correct in this way. 	* the change of after is
not enough at all, to handle everything properly we need to replace
several timeouts with monotonic time (otherwise same issue as mentioned
above with the hangs are unavoidable and especially evil by locks, up to
absolute "no go" by conditional cross-process locks).

> - not use a command switch, but a new command for the new monolitic after, as this is seen as the future. 
> 
> The way is not so important. Important is to get it. But sematics is always good for discussions ;-).

Sure. However in my case it is important, since already used dozen
years.

But it is indeed a matter of discussion, however I am sure the
implementation of both (mono-time and `after -at`) needs to be done
simultaneously (and released together). 

> Christian, I am probably blind. Where is your "after -at" patch ?

> Sergey, would it possible to extract the monolitic clock part of your big code contributions ?

Well, it is a bit complex - some changes (timers rewrite, event
handling, etc) are strict necessary, another (vwait, options for
vwait/after for event masks, higher resolution, etc) are pure features
fewer related to the monotonic clock, but depend on it... 

We have already discussed the subject several times in tclchat. For
example with Kevin Kenny, and IIRC the last conclusion was:

- either to write several TIPs to discuss the RFE in parts (but let the
code as is and adjust it later if expected);
- or to split the code in few parts from scratch; 

Since the latter would also expect the same TIPs as in the former,
possibly the right way is to start with the former. 

Regards,
Serg. 

P.S. @Christian: your rude t-online provider rejected my mail on you
yesterday with following error:
554 IP=... - None/bad reputation. Ask your postmaster for help or to
contact to...@rx... for reset. (NOWL)
Just to inform you, that they censor the customer's emails without their
knowledge (I guess you were not notified about the mail or its reject).
That "none" lets assume that they reject any mail from relays without
reputation... I must admit, I never saw such a stupid block reason
before.

 

Re: [TCLCORE] TIP 719: ready for vote "new states to customize ttk::treeview and ttk::notebook widget images in dependency of the state of items"

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

I fully agree with both the TIP and the proposed implementation.

Just a small correction proposal in the TIP: Instead of "tab image" 
(twice) it would be better to speak of "tab shape".

Best regards,

Csaba


Am 05.05.25 um 16:05 schrieb Harald Oehlmann:
> Dear Tk team,
> TIP 719:
> https://core.tcl-lang.org/tips/doc/trunk/tip/719.md
> was seen as ready in the bi-weekly telco.
> 
> Purpose:
> - new tk states to customize ttk::treeview and ttk::notebook images.
> In Tk 8.6, the states user1/2 were used are abused. This was removed in 
> Tk9.0, and now comes back in an extended way to allow:
> 
> ttk::style element create Treeitem.indicator \
>                image [list $image_for_closed \
>                    open $image_for_open \
>                    leaf $image_for_no_children \
>                ]
> 
> So, this is a kind request for comments.
> I would specially appreciate a review by Csaba and Francois.
> 
> If there are no issues, expect a vote on:
> 12th of May for one week.
> So, that it may be in Tk9.1a0.
> 
> Take care,
> Harald
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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

Re: [TCLCORE] TIP 716 ready for comments

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

Op di 6 mei 2025 om 06:47 schreef Ashok Nadkarni:
> Further,  given the link you gave has no discussion of MSVCRT, what was the source of your statement <MSVCRT supports the "utf-8" _encoding_, not the "utf-8" _locale_,> ? If you can provide the basis for your conclusion, that would really help.

Start reading the "UTF-8 support" chapter, Quoting:
"Starting in Windows 10 version 1803 (10.0.17134.0), the Universal C
Runtime supports using a UTF-8 code page. The change means that char
strings passed to C runtime functions can expect strings in the UTF-8
encoding. To enable UTF-8 mode, use ".UTF8" as the code page when
using setlocale"

Then realize that Tcl uses setlocale(), by setting the locale to "C".
That means for
the C runtime that everything is just bytes, no interpretation to the
bytes is done.
That's the mode Tcl uses. Microsoft only implemented the ".UTF8" locale in
UCR > 1803, not in any earlier runtimes. Since Tcl doesn't use this mode
anyway, who cares! The C runtime only knows about bytes then.

Hope this helps,
       Jan Nijtmans

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

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

Op di 6 mei 2025 om 06:34 schreef Ashok:
>
> Just for the record, I would still prefer a stub entry even if the panic gives more useful information with the macro.

I now changed the implementation, using 2 new stub entries.

@Ashok, thanks for the testcase, I fully see your point!

@Don, do you have anything more to add?

Thanks for all the feedback.
       Jan Nijtmans

Re: [TCLCORE] Notes of biweekly telco of 2025-05-05

[Schelte B. <tc...@tc...>]

On 06/05/2025 10:20, Harald Oehlmann wrote:
> please update in core-9-0-branch - changes.md file.
> 

Done.

On 06/05/2025 10:25, Harald Oehlmann wrote:
> Please consider to reopen the ticket and put the comment there.

Done.

Re: [TCLCORE] To the best of my recollection regarding TIP#302

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

Am 05.05.2025 um 20:45 schrieb Christian Werner:
> Hello all,
> 
> some points to discuss:
> 
> * the clock domain should be switched from wall clock to a monotonic 
> clock source in POSIX speak
> * this should ideally not have an impact on time computations in Tcl core
> * however, POSIX monotonic clock must be used in both clock_gettime() 
> and condition variables
> * maybe it's a good idea to detect availability of monotonic clock and 
> fall back to wall clock if not available
> * the time bound on slave interp evaluations is unfortunately in wall 
> time which is IMO a failure in design
> * what about virtual time, can this be ditched entirely, there ain't no 
> test cases and no examples
> * the "after -at" form is a special case to allow for cron like 
> requirements, is this ever a use case?
> * what is the resolution of "after -at", when it's like cron one second 
> seems enough
> * for symmetry another "after -mono" can be imagined which is like 
> "after -at" but in the monotonic clock domain
> * the resolution of "after -mono" should be near the tick rates of 
> contemporary OSes (e.g. milliseconds)
> 
> Best regards,
> Christian
Christian, Sergey,
thank you for your valuable contributions.
We need that!
It is an absolute requirement for an integration system to work.

Yesterday, in the meeting, there was a strong objection to:
- change current after in using the wall clock
- not use a command switch, but a new command for the new monolitic 
after, as this is seen as the future.

The way is not so important. Important is to get it. But sematics is 
always good for discussions ;-).

Christian, I am probably blind. Where is your "after -at" patch ?

Sergey, would it possible to extract the monolitic clock part of your 
big code contributions ?

Thanks for all, this discussion rocks! Lets get it fly!
Harald

Re: [TCLCORE] Notes of biweekly telco of 2025-05-05

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

Am 06.05.2025 um 09:59 schrieb Schelte Bron:
> On 06/05/2025 09:42, Ashok Nadkarni via Tcl-Core wrote:
>>    - [Better error-message than "interpreter uses an incompatible stubs
>> mechanism"](https://core.tcl-lang.org/tcl/tktview/fc3509)
> 
> Looking in detail at this fix, I see that it just always reports that 
> "this extension is compiled for Tcl 8.x" when it encounters an 
> incompatible stubs mechanism. While that is currently the only reason 
> this could happen, I can imagine that at some point in the future there 
> may be a Tcl 10 with yet another change to the stubs mechanism. Loading 
> an extension compiled for Tcl 10 into Tcl 9 would then also give the 
> (misleading) indication that the extension was compiled for Tcl 8.x.
Schelte,
great observations!
Please consider to reopen the ticket and put the comment there.
And consider to provide a better patch.

Thanks for all !
Harald

Re: [TCLCORE] Notes of biweekly telco of 2025-05-05

[Schelte B. <tc...@tc...>]

On 06/05/2025 09:42, Ashok Nadkarni via Tcl-Core wrote:
>    - [Better error-message than "interpreter uses an incompatible stubs
> mechanism"](https://core.tcl-lang.org/tcl/tktview/fc3509)

Looking in detail at this fix, I see that it just always reports that 
"this extension is compiled for Tcl 8.x" when it encounters an 
incompatible stubs mechanism. While that is currently the only reason 
this could happen, I can imagine that at some point in the future there 
may be a Tcl 10 with yet another change to the stubs mechanism. Loading 
an extension compiled for Tcl 10 into Tcl 9 would then also give the 
(misleading) indication that the extension was compiled for Tcl 8.x.


Schelte

Re: [TCLCORE] Notes of biweekly telco of 2025-05-05

[Schelte B. <tc...@tc...>]

On 06/05/2025 08:47, Harald Oehlmann wrote:
>   - [$interp eval $lambda] after [eval $lambda] or vice versa fails] 
> (https://core.tcl-lang.org/tcl/tktview/98006f)

I was interested in this bug report because I ran into the same issue in 
the weekend. But the link points to very different bug. The correct link 
seems to be https://core.tcl-lang.org/tcl/tktview/67d5f7.


Schelte.

Re: [TCLCORE] TIP 716 ready for comments

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

Jan,

It occurs to me that 9.1 will stop supporting Windows releases prior to Win 10. Given that, we can simply drop support for MinGW/MSVCRT as all Windows systems will have UCRT installed. If that is agreeable, we can drop the discussion around MSVCRT and focus on other points of contention in 716/718.

/Ashok


________________________________
From: Ashok Nadkarni via Tcl-Core
Sent: Tuesday, May 6, 2025 10:17 AM
To: Jan Nijtmans
Cc: Tcl Core List
Subject: Re: [TCLCORE] TIP 716 ready for comments

No, I'm afraid your post below does not clarify at all. That link you gave pertains to UCRT, not MSVCRT which, unless I read with my blinders on, is not mentioned anywhere on that page. Adding UCRT to the discussion, first with passing of FILE* between runtimes, and now to discussion of setlocale(), only serves to obfuscate further.

Further,  given the link you gave has no discussion of MSVCRT, what was the source of your statement <MSVCRT supports the "utf-8" _encoding_, not the "utf-8" _locale_,> ? If you can provide the basis for your conclusion, that would really help.

/Ashok


________________________________
From: Jan Nijtmans
Sent: Tuesday, May 6, 2025 3:08 AM
To: Ashok Nadkarni
Cc: Tcl Core List
Subject: Re: [TCLCORE] TIP 716 ready for comments

Op ma 5 mei 2025 om 19:22 schreef Ashok Nadkarni:
> Now, with regard to the mingw msvcrt comment...
>
> It seems to me from your comment about GetACP() in MingW that you think I was suggesting the manifest would not work in MingW. That is not so. GetACP() will work the same way and return utf-8 in the presence of a manifest but the problem is MSVCRT does not support UTF-8.
>
> I do not know if you read the link that I had referenced in the TIP https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt
>
> To quote from there - It doesn't support the UTF-8 locale ("It" being MSVCRT)
>
> When the official release document says MSVCRT does not support UTF-8, I take that at face value.

Let me clarify then. See:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale?view=msvc-170

With msvcrt, you cannot do a setlocale("en_US.UTF8"), with UCRT it works;

Tcl doesn't support that either. The only setlocale() call is here:
    <https://core.tcl-lang.org/tcl/file?name=win/tclAppInit.c&ci=ead995eddf5fff98&ln=111>

MSVCRT supports the "utf-8" _encoding_, not the "utf-8" _locale_,
that's a different thing

Hope this clarifies enough.

Happy hacking,
     Jan Nijtmans

Re: [TCLCORE] Notes of biweekly telco of 2025-05-05

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

Hi Harald,

Thanks for the list of changes. I had not realized so many updates were pending. It was also a reminder for me to update changes.md. Mea culpa.

/Ashok

________________________________________
From: Harald Oehlmann
Sent: Tuesday, May 6, 2025 12:17 PM
To: Ashok Nadkarni; Tcl Core List
Subject: Re: [TCLCORE] Notes of biweekly telco of 2025-05-05

Ashok,
thanks for the comment.
For changes in 9.0.2: the "changes.md" files are nowday maintained and
give an overview:

TCL:

  - [Better error-message than "interpreter uses an incompatible stubs
mechanism"](https://core.tcl-lang.org/tcl/tktview/fc3509)
  - [$interp eval $lambda] after [eval $lambda] or vice versa
fails](https://core.tcl-lang.org/tcl/tktview/98006f)
  - [tcl::mathfunc::isunordered inconsistency with some integer
values](https://core.tcl-lang.org/tcl/tktview/67d5f7)
  - [test lseq hangs with -Os](https://core.tcl-lang.org/tcl/tktview/d2a3c5)
  - [exec does not handle app execution aliases on
Windows](https://core.tcl-lang.org/tcl/tktview/4f0b57)
  - [auto_execok does not find several built-in cmd
commands](https://core.tcl-lang.org/tcl/tktview/4e2c8b)
  - [Panic "Buffer Underflow, BUFFER_PADDING not
enough"](https://core.tcl-lang.org/tcl/tktview/73bb42)
  - [MS-VS build system: pckIndex.tcl when building for 9 misses "t" for
TCL 8.6 part](https://core.tcl-lang.org/tcl/tktview/a77029)
  - [clock format -locale does not look up locale children if parent
locale used first](https://core.tcl-lang.org/tcl/tktview/2c0f49)
  - [Missing libtcl?.?.dll.a in
Cygwin](https://core.tcl-lang.org/tcl/tktview/dcedba)
  - [tclEpollNotfy PlatformEventsControl panics if websocket
disconnected](https://core.tcl-lang.org/tcl/tktview/010d8f)
  - [Tcl_InitStubs compatibility for
9.1](https://core.tcl-lang.org/tcl/tktview/fd8341)
  - [proc with more than 2**31
variables](https://core.tcl-lang.org/tcl/tktview/92aeb8)
  - [scan "long mantissa" %g](https://core.tcl-lang.org/tcl/tktview/42d14c)

Tk:
  - [inaccurate scrollbar
error-message](https://core.tcl-lang.org/tk/tktview/f88118)
  - [Build tk 9.0.1 failed on macos
10.13](https://core.tcl-lang.org/tk/tktview/cb5d77)
  - [image svg upstream out of bound read
nanosvg#262](https://core.tcl-lang.org/tk/tktview/121786)
  - [wm iconbitmap does not correctly set the icon pixmap hint on
macOS](https://core.tcl-lang.org/tk/tktview/13ac26)
  - [Backspace crashes 9.0 interpreter on
FreeBSD](https://core.tcl-lang.org/tk/tktview/1da19a)
  - [Bug in the ttk::scale widget of the "default"
theme](https://core.tcl-lang.org/tk/tktview/126d07)
  - [Wrong appearance of the ttk::menubutton indicator of the "xpnative"
theme](https://core.tcl-lang.org/tk/tktview/525536)
  - [English shortcuts for Chinese
locale](https://core.tcl-lang.org/tk/tktview/c99266)
  - [No grip element in ttk::panedwindow sashes of most built-in
themes](https://core.tcl-lang.org/tk/tktview/9902d8)
  - [Tk_Get3DBorderColors broken by
design](https://core.tcl-lang.org/tk/tktview/517165)
  - [MS-Win: Incorrect system menu entries for transient
toplevels](https://core.tcl-lang.org/tk/tktview/159aa5)
  - [MS-Win: Withdrawn Tk transient windows can reappear in Windows
taskbar preview](https://core.tcl-lang.org/tk/tktview/91d0e9)
  - [Aqua windows don't always move focus
correctly](https://core.tcl-lang.org/tkview/28d33f)

IMHO those bugfixes are reasons for a release.

About 9.1a0, there is not much. I hope, there will be some items coming.
But the new bytecode is seen as great.

Thanks for all,
Harald

Am 06.05.2025 um 07:53 schrieb Ashok Nadkarni:
> Harald,
>
> Thanks for the summary.
>
> With regards to releases, have any decisions been made about what
> constitutes 9.0.2 and 9.1a0? I ask because, imo only, given the effort
> involved, particularly for Don but others as well to a lesser extent,
> there has to be some worthwhile benefit. For 9.1a0, I can see the byte
> code as the motivator. What about for 9.0.2? Are there any critical bug
> fixes ready for delivery? If not, there is no immediate need.
>
> I did not follow the comments below on TIP 716. Sorry I missed the
> meeting as would have liked to close on this but had to escort my FIL to
> the hospital. IMO, *if* TIP 716 or 718 or a full rollback is at all
> accepted, it should go out as early as possible, i.e. in 9.0.2. Of
> course, if the decision is to keep things the way they are in 9.0.1 the
> point is moot.
>
> /Ashok

Re: [TCLCORE] Notes of biweekly telco of 2025-05-05

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

Ashok,
thanks for the comment.
For changes in 9.0.2: the "changes.md" files are nowday maintained and 
give an overview:

TCL:

  - [Better error-message than "interpreter uses an incompatible stubs 
mechanism"](https://core.tcl-lang.org/tcl/tktview/fc3509)
  - [$interp eval $lambda] after [eval $lambda] or vice versa 
fails](https://core.tcl-lang.org/tcl/tktview/98006f)
  - [tcl::mathfunc::isunordered inconsistency with some integer 
values](https://core.tcl-lang.org/tcl/tktview/67d5f7)
  - [test lseq hangs with -Os](https://core.tcl-lang.org/tcl/tktview/d2a3c5)
  - [exec does not handle app execution aliases on 
Windows](https://core.tcl-lang.org/tcl/tktview/4f0b57)
  - [auto_execok does not find several built-in cmd 
commands](https://core.tcl-lang.org/tcl/tktview/4e2c8b)
  - [Panic "Buffer Underflow, BUFFER_PADDING not 
enough"](https://core.tcl-lang.org/tcl/tktview/73bb42)
  - [MS-VS build system: pckIndex.tcl when building for 9 misses "t" for 
TCL 8.6 part](https://core.tcl-lang.org/tcl/tktview/a77029)
  - [clock format -locale does not look up locale children if parent 
locale used first](https://core.tcl-lang.org/tcl/tktview/2c0f49)
  - [Missing libtcl?.?.dll.a in 
Cygwin](https://core.tcl-lang.org/tcl/tktview/dcedba)
  - [tclEpollNotfy PlatformEventsControl panics if websocket 
disconnected](https://core.tcl-lang.org/tcl/tktview/010d8f)
  - [Tcl_InitStubs compatibility for 
9.1](https://core.tcl-lang.org/tcl/tktview/fd8341)
  - [proc with more than 2**31 
variables](https://core.tcl-lang.org/tcl/tktview/92aeb8)
  - [scan "long mantissa" %g](https://core.tcl-lang.org/tcl/tktview/42d14c)

Tk:
  - [inaccurate scrollbar 
error-message](https://core.tcl-lang.org/tk/tktview/f88118)
  - [Build tk 9.0.1 failed on macos 
10.13](https://core.tcl-lang.org/tk/tktview/cb5d77)
  - [image svg upstream out of bound read 
nanosvg#262](https://core.tcl-lang.org/tk/tktview/121786)
  - [wm iconbitmap does not correctly set the icon pixmap hint on 
macOS](https://core.tcl-lang.org/tk/tktview/13ac26)
  - [Backspace crashes 9.0 interpreter on 
FreeBSD](https://core.tcl-lang.org/tk/tktview/1da19a)
  - [Bug in the ttk::scale widget of the "default" 
theme](https://core.tcl-lang.org/tk/tktview/126d07)
  - [Wrong appearance of the ttk::menubutton indicator of the "xpnative" 
theme](https://core.tcl-lang.org/tk/tktview/525536)
  - [English shortcuts for Chinese 
locale](https://core.tcl-lang.org/tk/tktview/c99266)
  - [No grip element in ttk::panedwindow sashes of most built-in 
themes](https://core.tcl-lang.org/tk/tktview/9902d8)
  - [Tk_Get3DBorderColors broken by 
design](https://core.tcl-lang.org/tk/tktview/517165)
  - [MS-Win: Incorrect system menu entries for transient 
toplevels](https://core.tcl-lang.org/tk/tktview/159aa5)
  - [MS-Win: Withdrawn Tk transient windows can reappear in Windows 
taskbar preview](https://core.tcl-lang.org/tk/tktview/91d0e9)
  - [Aqua windows don't always move focus 
correctly](https://core.tcl-lang.org/tkview/28d33f)

IMHO those bugfixes are reasons for a release.

About 9.1a0, there is not much. I hope, there will be some items coming.
But the new bytecode is seen as great.

Thanks for all,
Harald

Am 06.05.2025 um 07:53 schrieb Ashok Nadkarni:
> Harald,
> 
> Thanks for the summary.
> 
> With regards to releases, have any decisions been made about what 
> constitutes 9.0.2 and 9.1a0? I ask because, imo only, given the effort 
> involved, particularly for Don but others as well to a lesser extent, 
> there has to be some worthwhile benefit. For 9.1a0, I can see the byte 
> code as the motivator. What about for 9.0.2? Are there any critical bug 
> fixes ready for delivery? If not, there is no immediate need.
> 
> I did not follow the comments below on TIP 716. Sorry I missed the 
> meeting as would have liked to close on this but had to escort my FIL to 
> the hospital. IMO, *if* TIP 716 or 718 or a full rollback is at all 
> accepted, it should go out as early as possible, i.e. in 9.0.2. Of 
> course, if the decision is to keep things the way they are in 9.0.1 the 
> point is moot.
> 
> /Ashok

Re: [TCLCORE] Notes of biweekly telco of 2025-05-05

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

Harald,

Thanks for the summary.

With regards to releases, have any decisions been made about what constitutes 9.0.2 and 9.1a0? I ask because, imo only, given the effort involved, particularly for Don but others as well to a lesser extent, there has to be some worthwhile benefit. For 9.1a0, I can see the byte code as the motivator. What about for 9.0.2? Are there any critical bug fixes ready for delivery? If not, there is no immediate need.

I did not follow the comments below on TIP 716. Sorry I missed the meeting as would have liked to close on this but had to escort my FIL to the hospital. IMO, if TIP 716 or 718 or a full rollback is at all accepted, it should go out as early as possible, i.e. in 9.0.2. Of course, if the decision is to keep things the way they are in 9.0.1 the point is moot.

/Ashok
________________________________
From: Harald Oehlmann <har...@el...>
Sent: Monday, May 5, 2025 7:21 PM
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] Notes of biweekly telco of 2025-05-05

Dear Tcl/Tk team !

It is release time. TCL/Tk 9.0.2 and TCL/Tk 9.1a0 are planned this
month. Please get your input ready now!

Thanks for participating at the great telco of today.
Here are the notes, which are mostly opinions and no decisions.

1) TIP 715: platforms for 9.1
Make a living document.
Vote on it when TCL9.1.0 is released.

Add comment in the beginning:
This is an active discussion.
Finalisation planned with release of the version.
Maintainers ok.

2) TIP 717: Tcl_AttemptCreateHashEntry
In favor.
Implementation ready. Please review.

3) TIP 716: encoding user and MS-Windows manifest removal
"Make the elephant back a mouse".
Many linked issues, partly bugs.
May have a switch solution with/without manifest

Proposed "exec -encoding xxx" is eventually not needed, if utf-8 is
given in manifest.

4) TIP 698: Negative screen distances
Most positive, comes from TkInter

5) TIP 714: photo image format information
Clean way is new registration function.
Much work.

6) TIP 626: Command argument count > INT_MAX (2^31)
Most remarks are mostly bugs.
Many linked issues are WIP.
Great, that it is looked into.
Also, memory error instead panic is linked. TIP 717 is a consequence of
this work.
May be voted later.

7) TIP 302: after independent on current time
It is a TIP for 20 years.
Technically it is a bugfix, but it has many consequences.

Don't disturb the function of a long time command.
A fully new command would be appreciated, not a new switch.
TIP: 302: new switch: after -robust
New command: intime (this is an example)

8) TIP 719: New tk states for ttk::treeview and ttk::notebook images
TIP ok.
Warning for vote to send.

9) TclLog2 improvements: https://core.tcl-lang.org/tcl/info/fd1585e2a1a8f890
Moving foreward just fine.
I don't like undefined behaviour? Define output for 0 input on all
platforms.
Aim is performence. It is internal to TCL.

10) New bytecodes (Donal):
https://core.tcl-lang.org/tcl/tktview/aa10216459cdfe0fd3eab0bbab949e611bd7336e
I like it!
It is more useful than I thought!
Performance boost is supposed.
Aim is not only performance but clearness.
It is for 9.1.
It should be in 9.1a0 to find issues.
It is an extension. Concurring byte-codes are deprecated, but not removed.

11) Floating point numbers overflow:
https://core.tcl-lang.org/tcl/info/42d14c495a096159
May be a bug in Libtommath and may go there.
Free to merge.

12) Block cursor: https://core.tcl-lang.org/tk/info/5d0bc3cfec7c1adb
Others may test.

13) Orphan packages repository
Ongoing. Seen as good aproach.

13a) Release plan
Release this month.
9.0.2 first
Then 9.1a0

9.1a0 candidates:
- New bytecode is a good candidate
- TIP 712: Positive switches for subst
   -> pos/neg together? Error message prefered.

14) Conference status
15 participants. COnference will take place.

Other meetings:
13th of May 18:00 UTC: mothly meetup (I am available and may start)
19th of May 12:00 UTC: UTC Monthly Virtual Meetup on same jitsi (I am
eventually not available)

---
Off meeting:

as sqlite was present:
- latest tickets were discussed
- Christian Werners dict proposal for tdbc::swqlite3 was discussed:
   https://core.tcl-lang.org/tdbcsqlite3/info/7822a89cda

https://sqlite.org/forum/forumpost/585ebac2c48f1411a81bb1e428bce3caf734e7c352521044bc383802cf734fb5
   More understanding is required.

---
Thanks for all !
Harald

Re: [TCLCORE] TIP 716 ready for comments

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

No, I'm afraid your post below does not clarify at all. That link you gave pertains to UCRT, not MSVCRT which, unless I read with my blinders on, is not mentioned anywhere on that page. Adding UCRT to the discussion, first with passing of FILE* between runtimes, and now to discussion of setlocale(), only serves to obfuscate further.

Further,  given the link you gave has no discussion of MSVCRT, what was the source of your statement <MSVCRT supports the "utf-8" _encoding_, not the "utf-8" _locale_,> ? If you can provide the basis for your conclusion, that would really help.

/Ashok


________________________________
From: Jan Nijtmans
Sent: Tuesday, May 6, 2025 3:08 AM
To: Ashok Nadkarni
Cc: Tcl Core List
Subject: Re: [TCLCORE] TIP 716 ready for comments

Op ma 5 mei 2025 om 19:22 schreef Ashok Nadkarni:
> Now, with regard to the mingw msvcrt comment...
>
> It seems to me from your comment about GetACP() in MingW that you think I was suggesting the manifest would not work in MingW. That is not so. GetACP() will work the same way and return utf-8 in the presence of a manifest but the problem is MSVCRT does not support UTF-8.
>
> I do not know if you read the link that I had referenced in the TIP https://www.msys2.org/docs/environments/#msvcrt-vs-ucrt
>
> To quote from there - It doesn't support the UTF-8 locale ("It" being MSVCRT)
>
> When the official release document says MSVCRT does not support UTF-8, I take that at face value.

Let me clarify then. See:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setlocale-wsetlocale?view=msvc-170

With msvcrt, you cannot do a setlocale("en_US.UTF8"), with UCRT it works;

Tcl doesn't support that either. The only setlocale() call is here:
    <https://core.tcl-lang.org/tcl/file?name=win/tclAppInit.c&ci=ead995eddf5fff98&ln=111>

MSVCRT supports the "utf-8" _encoding_, not the "utf-8" _locale_,
that's a different thing

Hope this clarifies enough.

Happy hacking,
     Jan Nijtmans