tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Bytecode compiler and monotonic time

[Arjen M. <Arj...@de...>]

Hi Christian,

The explanation of that absolute time seems to be this text (taken from Tcl 8.6, as that was the easiest for me 😉):

Every interpreter has two kinds of resource limits that may be imposed by any master interpreter upon its slaves. Command limits (of type command) restrict the total number of Tcl commands that may be executed by an interpreter (as can be inspected via the info cmdcount command), and time limits (of type time) place a limit by which execution within the interpreter must complete. Note that time limits are expressed as absolute times (as in clock seconds) and not relative times (as in after) because they may be modified after creation.
When a limit is exceeded for an interpreter, first any handler callbacks defined by master interpreters are called. If those callbacks increase or remove the limit,

(Paragpaph from RESOURCE LIMITS)

Regards,

Arjen

-----Original Message-----
From: Christian Werner <Chr...@t-...>
Sent: woensdag 14 mei 2025 09:03
To: tcl...@li...
Subject: Re: [TCLCORE] Bytecode compiler and monotonic time

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de..." as an attachment.


On 05/14/2025 08:39 AM, Harald Oehlmann wrote:

> ...
> Are you speaking about the modifications in generic/tclInterp.c in the bug branch ?
> https://core/
> .tcl-lang.org%2Ftcl%2Ftimeline%3Fr%3Dtkt3328635-posix-monotonic-clock%
> 26c%3D2025-05-14%2B06%253A30%253A15&data=05%7C02%7Carjen.markus%40delt
> ares.nl%7C7757c6162a59424519a408dd92b56b9c%7C15f3fe0ed7124981bc7cfe949
> af215bb%7C0%7C0%7C638828030079849378%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e
> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld
> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RHvOcEUT6JGQ77Iq6bVDfjSBQ2m8YA6a6qIjq
> KndzQM%3D&reserved=0
>
> You can also see it in this diff:
> https://core/
> .tcl-lang.org%2Ftcl%2Finfo%2F8ea9c4081c39b8bf&data=05%7C02%7Carjen.mar
> kus%40deltares.nl%7C7757c6162a59424519a408dd92b56b9c%7C15f3fe0ed712498
> 1bc7cfe949af215bb%7C0%7C0%7C638828030079877245%7CUnknown%7CTWFpbGZsb3d
> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiT
> WFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dXKkQgsGa0XDZgn79zhNNd%2FMz
> vRCPMgEiGSJVfOx8CQ%3D&reserved=0
>
> When I look to "interp limit" man page, there, the limit is documented as milliseconds and seconds, and not as a fix time.
>
> So, this is a bug and not a design change?
>
> I see the usage of the monotonic clock in the branch for the following commands:
>
> - interpreter limit
> - time
> - after
>
> For me, all those are documented in time difference (e.g. monotonic clock) and not in wall clock difference.
> So, the delay/speedup by a wall clock change is IMHO a bug and not a documented feature.

Please read the "RESOURCE LIMITS" section in interp.n carefully especially for the description of the "-seconds" option.

For me as non native speaker the description sounds misleading but in fact that "-seconds" option is an absolute time in wall clock units.

BR,
Christian



_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [TCLCORE] Bytecode compiler and monotonic time

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

On 05/14/2025 08:39 AM, Harald Oehlmann wrote:

> ...
> Are you speaking about the modifications in generic/tclInterp.c in the bug branch ?
> https://core.tcl-lang.org/tcl/timeline?r=tkt3328635-posix-monotonic-clock&c=2025-05-14+06%3A30%3A15
>
> You can also see it in this diff:
> https://core.tcl-lang.org/tcl/info/8ea9c4081c39b8bf
>
> When I look to "interp limit" man page, there, the limit is documented as milliseconds and seconds, and not as a fix time.
>
> So, this is a bug and not a design change?
>
> I see the usage of the monotonic clock in the branch for the following commands:
>
> - interpreter limit
> - time
> - after
>
> For me, all those are documented in time difference (e.g. monotonic clock) and not in wall clock difference.
> So, the delay/speedup by a wall clock change is IMHO a bug and not a documented feature.

Please read the "RESOURCE LIMITS" section in interp.n carefully especially for the description of
the "-seconds" option.

For me as non native speaker the description sounds misleading but in fact that "-seconds" option
is an absolute time in wall clock units.

BR,
Christian

Re: [TCLCORE] Bytecode compiler and monotonic time

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

Am 14.05.2025 um 07:03 schrieb Christian Werner:
> On 05/13/2025 10:18 PM, Harald Oehlmann wrote:
> 
> Howdy Harald, all,
> 
>> ...
>> I am in the monotonic after event issue and I am amazed by the 
>> solution now in this ticket: https://core.tcl-lang.org/tcl/ 
>> info/1e2c6ce4c8a883c9
>>
>> TIP 233 is aparrently in the way of such a solution. Are there any 
>> comments on this? Andreas gave insights within the Telco and asks 
>> Kevin for his opinion. The use-case may be outdated and the TIP may be 
>> eventually removed.
> 
> while we're at the longstanding monotony issue wouldn't this be a good 
> opportunity
> to repair the per slave interpreter time limits? Those are currently 
> expressed as
> an absolute point in time in the wall clock domain. My more natural 
> thinking is to
> give that interp a certain amount of fuel in form of an interval 
> expressed in the
> time domain which the after command uses, in contrast to say tomorrow at 
> midnight
> your tank is empty.
> 
> BR,
> Christian
Thanks, Christian,

Are you speaking about the modifications in generic/tclInterp.c in the 
bug branch ?
https://core.tcl-lang.org/tcl/timeline?r=tkt3328635-posix-monotonic-clock&c=2025-05-14+06%3A30%3A15

You can also see it in this diff:
https://core.tcl-lang.org/tcl/info/8ea9c4081c39b8bf

When I look to "interp limit" man page, there, the limit is documented 
as milliseconds and seconds, and not as a fix time.

So, this is a bug and not a design change?

I see the usage of the monotonic clock in the branch for the following 
commands:

- interpreter limit
- time
- after

For me, all those are documented in time difference (e.g. monotonic 
clock) and not in wall clock difference.
So, the delay/speedup by a wall clock change is IMHO a bug and not a 
documented feature.

My own use-case does not cover "time" and "interpreter limit", but I 
see, that this is a bug. I never use slave interpreters. The image photo 
command has issues with it (as reported by Emiliano) and this is another 
story to dig in...

Thanks,
Harald

Re: [TCLCORE] Bytecode compiler and monotonic time

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

On 05/13/2025 10:18 PM, Harald Oehlmann wrote:

Howdy Harald, all,

> ...
> I am in the monotonic after event issue and I am amazed by the solution now in this ticket: https://core.tcl-lang.org/tcl/info/1e2c6ce4c8a883c9
>
> TIP 233 is aparrently in the way of such a solution. Are there any comments on this? Andreas gave insights within the Telco and asks Kevin for his opinion. The use-case may be outdated and the TIP may be eventually removed.

while we're at the longstanding monotony issue wouldn't this be a good opportunity
to repair the per slave interpreter time limits? Those are currently expressed as
an absolute point in time in the wall clock domain. My more natural thinking is to
give that interp a certain amount of fuel in form of an interval expressed in the
time domain which the after command uses, in contrast to say tomorrow at midnight
your tank is empty.

BR,
Christian

Re: [TCLCORE] TIP 233 inquiry, from long in the past

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

[Adding a cc: to tcl-core so that we don't have to repeat the discussion
there.]

On Tue, May 13, 2025 at 4:32 PM Andreas Kupries <and...@gm...>
wrote:

> Harald asked me today about
>
> https://core.tcl-lang.org/tips/doc/trunk/tip/233.md
>
> which virtualized Tcl's sense of wall clock time.
>
> Given that the work was done 21 years ago I do not remember anymore
> the purpose behind the reasons stated in the TIP.
>
> While I am pretty sure that this was asked for by a customer of
> ActiveState, I do not truly remember which, and what use they had for
> this feature.
>
> My mind seems to be thinking Cisco, but also throws out Synopsys.
> Both are sensible possibilities (Network and other simulation stuff).
>
> As the TIP's link to the reference implementation,
> https://sourceforge.net/p/tcl/patches/393,
>
> references you as owner of that patch/ticket, I hope that you may also
> remember things about this feature, beyond my own recollection.
>
> This topic has come up because this virtual time interferes with
> current efforts towards monotonic time for the core.


What I recall about the ticket was what I posted on tcl-core a few days
ago. I understood what virtual time was about - allowing a production
script to run in simulated time rather than real time, while continuing to
interact with real I/O devices.  (It's also used in some highly secure
systems to avoid certain timing-dependent covert channels for data
exfiltration.)

I never knew the details of the intended application - you and Jeff were
under an NDA with the customer, and were not at liberty to disclose them.
My name was on the ticket, because I was the maintainer of the time system
at the time.  I allowed it in primarily because it had no effect on a build
that didn't use it.  The TIP was approved at a time when we were not
extremely formal about the process. My reasoning was "it's something an
ActiveState customer needs, and can't be done without surgery on the Core -
and this particular surgery is relatively minimal, since the functionality
is activated only by invoking an unusual API."

I never knew the identity of the customer, and as far as I know, nobody
else has ever demanded virtualization of the clock.

-- 
73 de ke9tv/2, Kevin

[TCLCORE] Bytecode compiler and monotonic time

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

We had a great telco today.
Apparently, there is less need on a chat-style of meeting and more need 
on agenda-focused-time limited meetings. I am normally doing this, but 
will not do for the next bi-weekly meeting, as I am not there.
Or I do the agenda and others will moderate the meeting.

It is release time! 9.0.2 may be born this month and 9.1a0 directly 
after its release! So, get your contributions ready.
To get ideas, here is a structured proposal list: 
https://wiki.tcl-lang.org/page/Where%20Tcl%20Needs%20Work%2FWorkers

Donal, we all appreciate your efforts on the bytecode compiler. At 
least, Jan, Ashok and Andreas want to have a deep look and eventually 
contribute to improve it. Andreas reported, that Miquel Sofer had 
similar ideas to use words instead bytes as the minimum unit.
The last github action run showed a memory leek on a dict test and Jan 
will eventually look into it.
We are surprised by the quick call for vote. Some are not ready to 
accept non reviewed code in the main branch.
It is expected, that there is a call for comments first and the vote 
after there are no comments pending.
May you rethink to put the TIP back in "review" phase and do the vote 
later on?

I am in the monotonic after event issue and I am amazed by the solution 
now in this ticket: https://core.tcl-lang.org/tcl/info/1e2c6ce4c8a883c9

TIP 233 is aparrently in the way of such a solution. Are there any 
comments on this? Andreas gave insights within the Telco and asks Kevin 
for his opinion. The use-case may be outdated and the TIP may be 
eventually removed.

Thanks for all comments,
Harald

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

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

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

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

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

[TCLCORE] glob problem

[Zaumseil R. <RZa...@kk...>]

Hello

I have the following strange behaviour under Windows 10 with tcl_patchLevel=9.0.0

(bin) 1 % set tcl_patchLevel
9.0.0
(bin) 2 % glob Z:/Basistests/200*
Z:/Basistests/2000_00_00 {Z:/Basistests/2000_00_00 - Test}
(bin) 3 % glob -types d Z:/Basistests/200*
Z:/Basistests/2000_00_00 {Z:/Basistests/2000_00_00 - Test}
(bin) 4 % glob -types d -directory Z:/Basistests -tails Z:/Basistests 200*
Z:Basistests 2000_00_00 {2000_00_00 - Test}
(bin) 5 % glob -types d -directory Z:/Basistests -tails Z:/Basistests Z:/Basistests/200*
couldn't read directory "Z:/Basistests/Z:Basistests/200*": not a directory

Under tcl8 I got:

(ABS) 1 % glob -types d -directory Z:/Basistests -tails Z:/Basistests 200*
2000_00_00 {2000_00_00 - Test}
(ABS) 2 % glob -types d -directory Z:/Basistests -tails Z:/Basistests Z:/Basistests/200*
no files matched glob patterns "Z:/Basistests Z:/Basistests/200*"

The additional string "Z:Basistests" on command 4 is wrong.

Even more perplexing is the following (under Tcl/Tk 9.0.0):

(ABS) 1 % glob -types d -directory Z:/Basistests -tails Z:/Basistests 200*
Z:Basistests 2000_00_00 {2000_00_00 - Test}
(ABS) 2 % cd Z:Basistests
(Basistests) 3 % pwd
Z:/Basistests
(Basistests) 4 % cd C:
() 5 % cd Z:Basistests
(Basistests) 6 % cd 2000_00_00
(2000_00_00) 7 % cd Z:Basistests
couldn't change working directory to "Z:Basistests": no such file or directory
(2000_00_00) 8 %


Any ideas?

Regards
Rene

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

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

<div><img width="1" height="1" src="https://fedbdhd.r.af.d.sendibt2.com/tr/op/mA12RGr2s9qqTD_1BF87mmuSFlTH8ZweKx1LaiGg3dQGMjRWWXQiR3o7ZimhBnTrw3VQn7DoTAkquc0eivhOJDtGeC1OmDmAonuyCVFu9wy9bKxKIOET3BMlm9x_9bAJgIXELc8K1o1IeEl5V-fXIGUTIOVY1-aK1LJ0ChXpcpn1qefjkeTHwVBQHRguBivmJN7mYCIxkSCKpl4G9l4spR7UTVLd4Khu" style="mso-hide:all"/></div>On Wed, 7 May 2025 12:49:28 +0200<br/>Jan Nijtmans <jan...@gm...> wrote:<br/><br/>> This is a CFV for 4 TIP's:<br/>> 1) TIP #698: Handle negative screen distances<br/>>     <a href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/CVwDJCsuy3a-ERTB9kRdASgO14rCSBblocSxe3EhAl0ODlwhOODxWeTfALnahar3NPJv6kJfed3GlPqVWH4Ec_YIgtSbtA0T3MWowAFhYgLN6lN8u7LIs_qMEY60gHXTpRaeKp9yDUTJ03_VrFFlSKmZJicUCAjalSQeLBGdF5xOgULmGaQUNuDhJiTJTUh3LFUfVqzDGeaaIOJvAHt0LC8G6iWXyG7Zz7u5uEbrM1zniUEd3elTNRChwe9wd47WpAisrwXVWqMW31D1Rs8k3E3gtF8RzUZECOiK1WmCJ-ft5HvfQnzZ94hnDVHisMR9YFYj">https://core.tcl-lang.org/tips/doc/trunk/tip/698.md</a><br/><br/>TIP 698: YES<br/><br/>> 2) TIP #704: extend Tk_CanvasTextInfo<br/>>    <a href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/zJ1v2G1_HxRV-AYJF_NKWEf32ONG1ulDztjgWK1Nc5Obwv5I1S4Zx7VJJZBH1u8Ti02W7BiAg6wYfWPpWfG2Ou_TDya3pj_O6rxZcdPxKFRU-h2OsJx6g3inRMfE1E_-dILsnom7oNk_5qvWSqsUiWbqUXAg6UO0L6RddDtS0piuWJnPmlbODwnePjk8LyiIgPV6b1zWXyYT46JQI5k7J7l9U8Z3Vq0BlfwKSUNpE3ZCOmkbnDfiwZtPrpsORFBdLzetDNPWgrCj3DY38ZFYfFgIujyMsHrAG-b2-_PQDN2n1UGmvlRxnkA9uCmwaZHCzbjy">https://core.tcl-lang.org/tips/doc/trunk/tip/704.md</a><br/><br/>TIP 704: YES<br/>> 3) TIP #717: New function: Tcl_AttemptCreateHashEntry()<br/>>    <a href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/TjjMC6ZVoOHn33jCOm6fEnJeFIZIqevYVeLKTgkQwwxROADSeJQ3ZWu_KYNlRYCfgI8A-8bZafsegJw6Ty7juW1UXnOKcjQOI69s56UW4C0kKHfJKky3pa1PKsMPXdx2T28FQlonP_BzaGjdC-2FjRO7ZyPdDNwUDlSz8FzJWwtXgEzysrGNNuzAal165QI1J9s1E483rGWQqdXSWjoaQW3NglMFZWVxQLJcTm8zFyOK-osWiJTqTre5vF6gMZxY9ZxUVPLBP2Vcg96W8jwr9RwQhTaJ2Tsb9aNQzG5vfwp95DVE4hfG2fk1qzJUVyDuJVY">https://core.tcl-lang.org/tips/doc/trunk/tip/717.m</a><br/><br/>TIP 717: A reluctant YES. I am not persuaded that adding a new function<br/>is the best solution for what is essentially code cleanup, but I<br/>understand that constraints of developer time prevent that deep dive<br/>into the code base.<br/><br/>> 4) TIP #719: Add new states to make images of ttk::treeview and<br/>> ttk::notebook customable<br/>>    <a href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/_AZ8MXpzsuKFgy0sZmBziJQg3u5ppqyll5fdSQgBuZVxr3YOqshtEZsTM3Xs_HP8LrcANHN3FGLO0rMEBnheDtajW9WFly2wqHcCOqkjVzNIhUfhYxE_RNKBOKp_VauV7lgvPoZ3nwcXksRCfiCjdkV7KXx4Lho-lLlCw5wr2Cp5yHu00vZZ86QLsYhcWLX0aBIVoHVcBMrFeeuoCDFyIYHPzvJ0gzXgPZJ9vPIfHNauDD7p1CYjQMGpJwjk4HBLlgf-5n8BO9Mgf1hJvN11PlPILfKI-olh2EVurHFJyixJ_t82kWNMg3GPLsuf9QfO3_mQ">https://core.tcl-lang.org/tips/doc/trunk/tip/719.md</a><br/><br/>TIP 719: YES<br/><br/>Thanks,<br/>Kevin<br/>

Re: [TCLCORE] TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)

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

<div><img width="1" height="1" src="https://fedbdhd.r.tsp1-brevo.net/tr/op/T7cpJ2BKlExOJKk94-7WBovV94VgHkGj1hYlnByOwfyXs3KedNwoZzo0RRa5cikWXOodzVvKRx_NnRUvBYjCT2k2xl-gkDoSyVQwP00ni8DI2WJuBGUVsLXf6Y3yENaiak88ypS0XvJaSi6Xfd47J5KCjjsuHysm94l11k3hk7qdDcBoPxiGti1gAED57z91XCzRsPk69CPgLWxBEwdDgZt_cuhf" style="mso-hide:all"/></div>On Mon, 12 May 2025 15:27:44 +0200<br/>Harald Oehlmann <har...@el...> wrote:<br/><br/>> Am 09.05.2025 um 14:16 schrieb Donal Fellows:<br/>> > Votes to here by [clock format 1747393200] (Fri May 16 12:00:00 BST <br/>> > 2025) in the usual form.<br/>> > <br/>> > TIP 720: YES<br/>> > <br/>> > Donal.  <br/>> Donal,<br/>> thanks for all the work. I don't feel qualified to vote and I<br/>> suppose, most of us are just not qualified.<br/>> Nevertheless, I want to support the project and your enthusiasm to<br/>> work on it.<br/>> I also see future "switch -integer" reasonable functionality.<br/>> <br/>> As Jan has voted "yes", the TIP will probably be accepted without any <br/>> other vote. Otherwise, I may re-think and cast a vote. Sorry for this <br/>> strategic movement.<br/>> <br/>> Thanks for all,<br/>> Harald<br/><br/>TIP 720: YES<br/><br/>

Re: [TCLCORE] TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)

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

Donal,

While I'm all for improvements in the byte code compiler and engine, even if only for clarity, I feel the TIP is so substantial as needing more time for people to digest.

Some preliminary performance tests (only based on the very limited tests in the perf-tests directory) indicate performance difference is in statistical noise, marginally faster in some cases, slower in others. Nevertheless, I would agree that simplification is desirable even for clarity/readability purposes.

A couple of implementation related comments...

Does not build with MS VC++ because the [[deprecated]] attribute is only available in C++14  onwards and not part of any C standard. Additionally, even for C++, VC++ does not support the attribute for enum values. Just making the defining macro a no-op fixes this at the loss of deprecation warnings in VC++. Not a big deal I feel.

The other question I have is with the numerous "value > INT_MAX" error checks during compilation being changed to "value > UINT_MAX". The "value" in question is generally Tcl_Size so on 64-bit platforms the change means that value in the range [INT_MAX+1, UINT_MAX] can now enter the bytecode stream. My impression of the byte code engine is that there are many implicit assumptions about integer value ranges and some byte codes can handle that range, and some cannot, despite the use of TclGetUInt4AtPtr implying unsigned values.

To work through the first incidence on a diff as an example, in TclCompCmds.c->TclCompileArrayExistsCmd, the fragment

    if (localIndex >= 0) {
      OP4(              ARRAY_EXISTS_IMM, localIndex);
    } else {
      OP(               ARRAY_EXISTS_STK);
    }

can now push the immediate value localIndex=0x80000000 onto the stack which it would not do before.

The INST_ARRAY_EXISTS_IMM case in TEBCResume does

      opnd = TclGetUInt4AtPtr(pc + 1);
      ...
      varPtr = LOCAL(opnd);

The macro LOCAL expands to

   #define LOCAL(i)     (&compiledLocals[(i)])

The problem I see is that opnd is typed as an "int", so 0x80000000 will be treated as a large negative index into compiledLocals with obvious consequences.

Perhaps this particular case could be fixed by changing LOCAL to cast i as unsigned but I seem to recall other similar cases as well when I last looked at the code during the signed/unsigned Tcl_Size debate and I'm personally not comfortable with such casts without a complete code review.

It is quite possible I have overlooked something but I do not think the INT_MAX->UINT_MAX changes are worth making unless there is certainty the TEBCExecute can handle unsigned ints in all cases and that is likely quite tricky and not worth the effort or risk imo.

Of course, values greater than INT_MAX will likely never occur in practice but in that case why make the change at all.

But again, I think folks (certainly me) need more time to look at it.

/Ashok
________________________________
From: Donal Fellows <don...@ma...>
Sent: Friday, May 9, 2025 5:46 PM
To: Tcl Core <tcl...@li...>
Subject: [TCLCORE] TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)

As promised, I've done a TIP for the updates to the bytecode compiler. It's largely there to document the notable features of a substantial changeset.

https://core.tcl-lang.org/tips/doc/trunk/tip/720.md

It covers the essentials; of particular note is that no true public API is affected. That said, tcl::unsupported::assemble is affected, but via enhancement (it gets new opcodes), and tdkcompiler/tbcload will definitely need more work due to the new auxiliary structure type (for a numeric jump table).

Given the lack of public surface changes - if you're not messing with compilation guts, you shouldn't need to care - I'm going to call a vote on this TIP immediately.

Votes to here by [clock format 1747393200] (Fri May 16 12:00:00 BST 2025) in the usual form.

TIP 720: YES

Donal.

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

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

#698 - PRESENT.  Cleans up a lot of code but do not know Tk details enough to judge effect of the stated incompatibility.
#704 - YES
#717 - YES
#719 - YES


________________________________
From: Jan Nijtmans
Sent: Wednesday, May 7, 2025 4:19 PM
To: Tcl Core List
Subject: [TCLCORE] CFV TIP's #698, #704, #717, #719

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


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

Re: [TCLCORE] TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)

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

Am 09.05.2025 um 14:16 schrieb Donal Fellows:
> Votes to here by [clock format 1747393200] (Fri May 16 12:00:00 BST 
> 2025) in the usual form.
> 
> TIP 720: YES
> 
> Donal.
Donal,
thanks for all the work. I don't feel qualified to vote and I suppose, 
most of us are just not qualified.
Nevertheless, I want to support the project and your enthusiasm to work 
on it.
I also see future "switch -integer" reasonable functionality.

As Jan has voted "yes", the TIP will probably be accepted without any 
other vote. Otherwise, I may re-think and cast a vote. Sorry for this 
strategic movement.

Thanks for all,
Harald

[TCLCORE] May 13 2025 Tcl monthly virtual meetup notice

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

A reminder that the next meetup will be held Tuesday May 13 2025 at [clock format 1747159200] -
Tuesday 11am US West, 1pm US Central, 2pm US East, 6pm UTC, 7pm UK, 8pm Western Europe, 11:30pm India, Wednesday 2am Australia West / Singapore / China, 3am Japan, 4am Australia East, 6am New Zealand

Details (including how to connect) are available via
https://wiki.tcl-lang.org/page/Monthly+Virtual+Meetup

-- Steve

Re: [TCLCORE] TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)

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

Op vr 9 mei 2025 om 14:17 schreef Donal Fellows:
> Given the lack of public surface changes - if you're not messing with compilation guts, you shouldn't need to care - I'm going to call a vote on this TIP immediately.
>
> Votes to here by [clock format 1747393200] (Fri May 16 12:00:00 BST 2025) in the usual form.

My vote:

    TIP 720: YES

Regards,
       Jan Nijtmans

[TCLCORE] TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)

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

As promised, I've done a TIP for the updates to the bytecode compiler. It's largely there to document the notable features of a substantial changeset.

https://core.tcl-lang.org/tips/doc/trunk/tip/720.md

It covers the essentials; of particular note is that no true public API is affected. That said, tcl::unsupported::assemble is affected, but via enhancement (it gets new opcodes), and tdkcompiler/tbcload will definitely need more work due to the new auxiliary structure type (for a numeric jump table).

Given the lack of public surface changes - if you're not messing with compilation guts, you shouldn't need to care - I'm going to call a vote on this TIP immediately.

Votes to here by [clock format 1747393200] (Fri May 16 12:00:00 BST 2025) in the usual form.

TIP 720: YES

Donal.

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

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

Not read all the TIPs yet. 

Yahoo Mail: Search, organise, conquer 
 
  On Thu, 8 May 2025 at 4:52 pm, Jan Nijtmans<jan...@gm...> wrote:  

I didn't see your vote yet.

Regards,
    Jan Nijtmans
  

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

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

I am very comfortable with the notion that the first point release can also contain breaking changes, especially if they fix bugs (either introduced in the major release or ones that failed to make the cut off).  In fact I’d prefer to see *any* change able to be reversed or amended in the first point release after it drops.  Perhaps that would go some way towards reducing the chance of “not quite ready” changes getting into the major release.

-- Steve
On 8 May 2025 at 11:22 PM +0800, Kevin Kenny <kev...@gm...>, wrote:
> I'm willing to concede the point if the consensus runs against me, because to me it's a close call.  It does, as I mentioned, fall in my mental category of 'script-breaking changes that, if implemented, would probably fix more bugs than they introduce.'
>
> On Wed, May 7, 2025 at 9:51 AM Dipl. Ing. Sergey G. Brester <se...@us...> wrote:
> > 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
>
>
> --
> 73 de ke9tv/2, Kevin
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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

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

I'm willing to concede the point if the consensus runs against me, because
to me it's a close call.  It does, as I mentioned, fall in my mental
category of 'script-breaking changes that, if implemented, would probably
fix more bugs than they introduce.'

On Wed, May 7, 2025 at 9:51 AM Dipl. Ing. Sergey G. Brester <
se...@us...> wrote:

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

-- 
73 de ke9tv/2, Kevin

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

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

Op do 8 mei 2025 om 11:56 schreef Ashok Nadkarni:
> In fact, by that logic, there really is no need for 717 and Tcl_AttemptHashEntry at all. You can just change Tcl_CreateHashEntry semantics to allow NULL returns. Callers that check can take appropriate action and those that don't will crash instead of panic'ing. But the "shit already happened" so how does it matter 🙂

At least TIP #717 gives much better panic messages, especially with
-DTCL_MEM_DEBUG. Did you note that?

> Having said all that, this does not change my vote on 717 because of the (a) above - it will only happen for the case I laid out, not for an extension built against 9.1.

I didn't see your vote yet.

Regards,
     Jan Nijtmans

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

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

Yes, I mistakenly said 9.0.2 when I should have said 9.1. That was not (clearly, I think) the core of my post though and not really relevant. The rest of my query still applies.

A Tcl extension built against 9.0 was assured Tcl_CreateHashEntry returned non-NULL. The same binary loaded into 9.1 is no longer offers that assurance.

To me that is an incompatibility. Whether it matters or not is a separate point discussed next.

Perhaps an incompatibility can be ignored because (a) it only occurs in very rare situations or (b) because in your words "shit already happened" in failures like memory allocation. The reason for preferring Tcl_Panic as opposed to just crashing at some later point on null pointer access is that the former gives a clear reason for failure on a crash as opposed to a null pointer at some random point in further execution. If that was not the case, Tcl would never do allocation checks and explicitly panic! Just continue and let the crash happen on the next attempted access to the returned null pointer!

In fact, by that logic, there really is no need for 717 and Tcl_AttemptHashEntry at all. You can just change Tcl_CreateHashEntry semantics to allow NULL returns. Callers that check can take appropriate action and those that don't will crash instead of panic'ing. But the "shit already happened" so how does it matter 🙂

Having said all that, this does not change my vote on 717 because of the (a) above - it will only happen for the case I laid out, not for an extension built against 9.1.

/Ashok
________________________________
From: Jan Nijtmans <jan...@gm...>
Sent: Thursday, May 8, 2025 1:18 PM
To: Ashok Nadkarni <apn...@ya...>
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

Op do 8 mei 2025 om 06:40 schreef Ashok Nadkarni:
> Now when the binary extension, *compiled against 9.0.0*, is loaded into 9.0.2 (with TIP 717), that will directly call CreateHashEntry which will then (potentially) return NULL instead of panicing thereby breaking the contract.
>
> Am I right or what am I missing?

You are missing 2 things:
1) TIP #717 is for Tcl 9.1, _not_ for 9.0.2. It's not a good idea to
add a stub entry in a patch release.
2) The difference in behavior only occurs in case of a memory
overflow, so the shit already happened.

Does that help? Or do you want me to explain through a realistic scenario?
What exactly is your worry?

Regards,
       Jan Nijtmans

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

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

Op do 8 mei 2025 om 06:40 schreef Ashok Nadkarni:
> Now when the binary extension, *compiled against 9.0.0*, is loaded into 9.0.2 (with TIP 717), that will directly call CreateHashEntry which will then (potentially) return NULL instead of panicing thereby breaking the contract.
>
> Am I right or what am I missing?

You are missing 2 things:
1) TIP #717 is for Tcl 9.1, _not_ for 9.0.2. It's not a good idea to
add a stub entry in a patch release.
2) The difference in behavior only occurs in case of a memory
overflow, so the shit already happened.

Does that help? Or do you want me to explain through a realistic scenario?
What exactly is your worry?

Regards,
       Jan Nijtmans

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

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

Jan,
thanks for the group call. Here is my vote:

Am 07.05.2025 um 12:49 schrieb Jan Nijtmans:
> 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>

Yes

> 2) TIP #704: extend Tk_CanvasTextInfo
>     <https://core.tcl-lang.org/tips/doc/trunk/tip/704.md>

Yes
Sounds reasonable

> 3) TIP #717: New function: Tcl_AttemptCreateHashEntry()
>     <https://core.tcl-lang.org/tips/doc/trunk/tip/717.m>

Present
To complex for me

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

Yes
Even if there are test cases missing, I thinkm this is an improvement.

I have no idea how to test this. We change an image.
Perhaps, we can put a large image and detect the widget size change?

Thanks for all,
Harald

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

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

Jan,

I'm afraid after reviewing the latest 717 implementation, I still have some doubts around compatibility.

Assuming I've followed the macros and stubs correctly...

If an extension is compiled against 9.0.0, the macro

Tcl_CreateHashEntry(tablePtr, key, newPtr)

will expand to

(*((tablePtr)->createProc))(tablePtr, (const char *)(key), newPtr)

Now when the binary extension, *compiled against 9.0.0*, is loaded into 9.0.2 (with TIP 717), that will directly call CreateHashEntry which will then (potentially) return NULL instead of panicing thereby breaking the contract.

Am I right or what am I missing?

/Ashok
________________________________
From: Jan Nijtmans <jan...@gm...>
Sent: Tuesday, May 6, 2025 2:42 PM
To: Ashok Nadkarni <apn...@ya...>
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

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] TIP 719: ready for vote "new states to customize ttk::treeview and ttk::notebook widget images in dependency of the state of items"

[Francois V. <fvo...@fr...>]

I had a look at the TIP and proposed implementation. I think it's indeed 
needed in order to unbreak the collateral damage that happened when fixing:

     https://core.tcl-lang.org/tk/info/527cb3cd5d

It appeared that someone used those (previously) internal states, see:

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

So I'm all for the TIP.

However the first thing I see in the implementation is that there is no 
new test exercising the feature. This should be added before merging.

Also, I didn't test the implementation, I miss a proper complete 
testcase to run.

Thanks,

Francois

Le 05/05/2025 à 16:05, Harald Oehlmann a écrit :
> 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