tcl-core — Tcl Core Team discussions about Tcl development

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

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

apn...@ya...
2025-05-17 17:37
Re the compilation errors, I've no idea how they ended up in there, but they're fixed now.
Ugh, they were mainly caused by me not thinking too much when copying existing bits and pieces to make those TRACE calls. I'd tried the --symbols=all builds before, but that must have been prior to writing INST_DICT_PUT and INST_DICT_REMOVE. Removing the extra double quotes made things work as intended.

Donal.

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

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

Re the compilation errors, I've no idea how they ended up in there, but they're fixed now. If there's still MSVC errors, please let me know what the error message is; I'm having problems triggering it here. (I might just make that code path depend on recent enough standard C if I can't figure out any other alternative; this will be fixed prior to merging.)

Re the change to use IsEmptyToken, it's the intention that an empty body results in nothing happening, and that if IDEOGRAPHIC SPACE is now considered a space for the purpose of that function, then the code is now behaving correctly. [dict with] is very happy to delegate that decision. If IsEmptyToken is reporting tokens as empty when they could be compiled to code with side effects, that's definitely a bug... but not with the callers of IsEmptyToken. I'm not going to probe that further; I didn't write IsEmptyToken, but I need something that says "this token definitely doesn't generate code and so definitely doesn't generate errors".


  1.
Literal sharing is one of those things that I think we may have been doing a bit too much of, and which has caused unnecessary representation churn. OTOH, I'm not strongly invested in either sharing or not sharing those objects for the most part. My usage is on the basis of it being a convenient API; I have a Tcl_Obj and I want to arrange for it (or something remarkably similar) to get pushed onto the stack by the bytecode engine at that point.
  2.
I believe I checked the cases where I switched the code over to bounce the refcount; they're supposed to be places where the called code may take a reference or may not (typically on error) but definitely won't be decrementing the reference count. (It's the functions with an internal Tcl_DecrRefCount that you need to watch out for.)
  3.
The switch to use Tcl_ListObjReplace was indeed deliberate. It's so that appending a zero-length list works correctly, and that's necessary for the short lappend-expansion branch to work (which makes [lappend] do the right thing with {*}). Previously, [lappend foo] was an ugly special case precisely because the opcodes worked differently from the non-compiled [lappend]. So. Many. Edge. Cases.
  4.
Remove the clause, run append.test and appendComp.test (I forget which one) and see something very strange with some tests. I think it might be append-7.4 that triggers it, but I'm not sure as I've not poked at it for a few weeks (that have been very busy ones for me). The code before this branch (https://core.tcl-lang.org/tcl/file?name=generic/tclCompCmdsGR.c&ci=22313fe35a5e2956&ln=856,860) is also odd in this area; in a sane world, the first condition there would be be numWords<2 and the second would be without looking at the envPtr->procPtr at all (at that point; it should just be a concern for picking how to access a variable, such as in https://core.tcl-lang.org/tcl/file?name=generic/tclCompCmdsGR.c&ci=22313fe35a5e2956&ln=897,909 and https://core.tcl-lang.org/tcl/file?name=generic/tclCompCmdsGR.c&ci=22313fe35a5e2956&ln=923,935).
  5.
I'm generally supportive; the deprecated opcodes should be fairly easy to identify and remove with things as they stand. We do not generate any of them at this point, but there's still code that knows how to work with them (and execute them, of course). If backward compatibility is truly undesired, we can also remove the binding of the remaining opcodes to their current values. But technically out of scope right now. 😄

Donal.

________________________________
From: apn...@ya... <apn...@ya...> on behalf of apn...@ya... <apn...@ya...>
Sent: Saturday, May 17, 2025 17:37
To: Donal Fellows <don...@ma...>; 'Tcl Core' <tcl...@li...>
Subject: RE: [TCLCORE] TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)


Ok, having read the main components in tclComp*.c and tclExecute.c, I think I'm good to go on TIP 720. The code generation is much more readable making future development easier.



Even the minor beef I had with the INT_MAX/UINT_MAX limits is not an issue currently as two separate INT_MAX limits, one on the length of a script and the other on the number of arguments, make the point moot. The (INT_MAX..UINT_MAX] case will never actually occur afaict. At least until TIP 626 at which point it becomes Jan's problem :-)



There are some compilation errors still on Windows as mentioned earlier and also on Unix with --enable-symbols=all (works without that).



One little buglet, not actually related to TIP 720 but related to the changes in [dict with] arising from modification to using Unicode aware IsEmptyToken. Didn't check if [dict update] also had the same issue.



Tcl 9.0.1

% info patch

9.0.1

% writeFile space.tcl "proc \u3000 {} {puts IDEOGRAPHICSPACE}\n; set d \[dict create a 0];dict with d {\u3000}"

% source space.tcl

IDEOGRAPHICSPACE



TIP-720

% info patch

9.1a0

% writeFile space.tcl "proc \u3000 {} {puts IDEOGRAPHICSPACE}\n; set d \[dict create a 0];dict with d {\u3000}"

% source space.tcl

% (no output as the dict with script block is treated as an empty script)



Some more questions, as much for my own edification, as anything else…



(1) Code sequences of the form



Tcl_Size len;

const char *bytes = TclGetStringFromObj(objPtr, &len);

PushLiteral(envPtr, bytes, len)



have been replaced by



PUSH_OBJ(objPtr)



Whereas PushLiteral resolves to TclRegisterLiteral, PUSH_OBJ resolves to TclAddLiteralObj. The former adds the value to the global literal array, but the latter does not. Is this difference intentional? Since the literal is going to be in the local array anyways, doesn't it make sense to have it globally available as well for memory sharing as in 9.0.0?



(2) I also see sequences like



TclNewObj(objPtr);

Tcl_IncrRefCount(objPtr);

SomeFunction(...objPtr...);

Tcl_DecrRefCount(objPtr);



replaced by



TclNewObj(objPtr);

SomeFunction(...objPtr...);

Tcl_BounceRefCount(objPtr);



but the semantics of the above sequences are not the same as the latter does not guarantee objPtr is still accessible on return from SomeFunction. I have not looked into every such "SomeFunction" but presumably, they do not manipulate (e.g. incr+decr) the ref count of objPtr. Still, the original sequence seems safer unless all SomeFunction’s in this context are known to be safe in this respect.



(3) In the TEBCResume function, the under label lappendListPtr:, the call to TclListObjAppendElements has been replaced by Tcl_ListObjReplace. Why so? The latter is more general and therefore has to do a little more work to append. Clearly the change is intentional so I am curious as to the reason.



(4) There is the following comment somewhere in the code which I think you just added:



    /*

     * The weird cluster of bugs around INST_LAPPEND_STK without a LVT ought

     * to be sorted out. INST_LAPPEND_LIST_STK does the right thing.

     */"

What does this cluster of bugs refer to ? Are they recorded somewhere? I've worked on lappend and have not seen or noticed any. This is just my curiosity as to what I might have missed.



(5) As an RFE, not necessarily part of TIP 720, I would be tempted to expunge the deprecated opcodes from TEBC as well (not just disabled via macros). It would significantly reduce and simplify TEBCresume. I understand the potential incompatibility with respect to tbcload and possible the Tcl debugger/prodebug. However, I do not see any need to maintain 8.6 tbcload compat given we don't even maintain 8.6 compat at script or C API level. This is the time to eliminate that code (before people depend on tbcloaded 9.0 applications) else we would have to wait for 10.0. (As an aside, does tbcload work with Tcl 9? If not, is anyone even working on it?)



In summary, all looks good as far as I am concerned once the compiler errors with --enable-symbols=all are fixed.



/Ashok







From: Donal Fellows <don...@ma...>
Sent: Friday, May 9, 2025 5:47 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 [core.tcl-lang.org]<https://urldefense.com/v3/__https://core.tcl-lang.org/tips/doc/trunk/tip/720.md__;!!PDiH4ENfjr2_Jw!ALVTJ_a_6mdCvhJUS8w77mC9_5peSjdi7rDWwxWMs-J5kkF5N-WFyVR3RhRASZXkoY05xtNSr7c8mGrrzoP0wC2pvNCkBDRi034Z$>



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] TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)

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

TIP #720: YES

- Marc

On Fri, May 9, 2025 at 7:17 AM Donal Fellows <
don...@ma...> wrote:

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

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

TIP #720: YES

 

A final note, using the tcltest and tcltests packages as a sample, there is
roughly 60% increase in bytecode size. That is acceptable in my view as
bytecode is a small component in memory usage.

 

TIP 720

Number of procs: 200

Code size: 88280

 

Trunk:

Number of procs: 200

Code size: 54169

 

From: Donal Fellows <don...@ma...> 
Sent: Friday, May 9, 2025 5:47 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] TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)

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

Ok, having read the main components in tclComp*.c and tclExecute.c, I think
I'm good to go on TIP 720. The code generation is much more readable making
future development easier.

 

Even the minor beef I had with the INT_MAX/UINT_MAX limits is not an issue
currently as two separate INT_MAX limits, one on the length of a script and
the other on the number of arguments, make the point moot. The
(INT_MAX..UINT_MAX] case will never actually occur afaict. At least until
TIP 626 at which point it becomes Jan's problem :-)

 

There are some compilation errors still on Windows as mentioned earlier and
also on Unix with --enable-symbols=all (works without that).

 

One little buglet, not actually related to TIP 720 but related to the
changes in [dict with] arising from modification to using Unicode aware
IsEmptyToken. Didn't check if [dict update] also had the same issue.

 

Tcl 9.0.1

% info patch

9.0.1

% writeFile space.tcl "proc \u3000 {} {puts IDEOGRAPHICSPACE}\n; set d
\[dict create a 0];dict with d {\u3000}"

% source space.tcl

IDEOGRAPHICSPACE

 

TIP-720

% info patch

9.1a0

% writeFile space.tcl "proc \u3000 {} {puts IDEOGRAPHICSPACE}\n; set d
\[dict create a 0];dict with d {\u3000}"

% source space.tcl

% (no output as the dict with script block is treated as an empty script)

 

Some more questions, as much for my own edification, as anything else.

 

(1) Code sequences of the form

 

Tcl_Size len;

const char *bytes = TclGetStringFromObj(objPtr, &len);

PushLiteral(envPtr, bytes, len)

 

have been replaced by

 

PUSH_OBJ(objPtr)

 

Whereas PushLiteral resolves to TclRegisterLiteral, PUSH_OBJ resolves to
TclAddLiteralObj. The former adds the value to the global literal array, but
the latter does not. Is this difference intentional? Since the literal is
going to be in the local array anyways, doesn't it make sense to have it
globally available as well for memory sharing as in 9.0.0?

 

(2) I also see sequences like

 

TclNewObj(objPtr);

Tcl_IncrRefCount(objPtr);

SomeFunction(...objPtr...);

Tcl_DecrRefCount(objPtr);

 

replaced by

 

TclNewObj(objPtr);

SomeFunction(...objPtr...);

Tcl_BounceRefCount(objPtr);

 

but the semantics of the above sequences are not the same as the latter does
not guarantee objPtr is still accessible on return from SomeFunction. I have
not looked into every such "SomeFunction" but presumably, they do not
manipulate (e.g. incr+decr) the ref count of objPtr. Still, the original
sequence seems safer unless all SomeFunction's in this context are known to
be safe in this respect.

 

(3) In the TEBCResume function, the under label lappendListPtr:, the call to
TclListObjAppendElements has been replaced by Tcl_ListObjReplace. Why so?
The latter is more general and therefore has to do a little more work to
append. Clearly the change is intentional so I am curious as to the reason.

 

(4) There is the following comment somewhere in the code which I think you
just added: 

 

    /*

     * The weird cluster of bugs around INST_LAPPEND_STK without a LVT ought

     * to be sorted out. INST_LAPPEND_LIST_STK does the right thing.

     */"

What does this cluster of bugs refer to ? Are they recorded somewhere? I've
worked on lappend and have not seen or noticed any. This is just my
curiosity as to what I might have missed.

 

(5) As an RFE, not necessarily part of TIP 720, I would be tempted to
expunge the deprecated opcodes from TEBC as well (not just disabled via
macros). It would significantly reduce and simplify TEBCresume. I understand
the potential incompatibility with respect to tbcload and possible the Tcl
debugger/prodebug. However, I do not see any need to maintain 8.6 tbcload
compat given we don't even maintain 8.6 compat at script or C API level.
This is the time to eliminate that code (before people depend on tbcloaded
9.0 applications) else we would have to wait for 10.0. (As an aside, does
tbcload work with Tcl 9? If not, is anyone even working on it?)

 

In summary, all looks good as far as I am concerned once the compiler errors
with --enable-symbols=all are fixed.

 

/Ashok

 

 

 

From: Donal Fellows <don...@ma...> 
Sent: Friday, May 9, 2025 5:47 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] TIP 233 inquiry, from long in the past

[Jeff H. <jef...@gm...>]

On May 14, 2025, at 8:32 AM, Andreas Kupries <and...@gm...> wrote:
>> [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:
> 
>> What I recall about the ticket was what I posted on tcl-core a few
>> days ago.
> 
> My apologies for the repeated query, I missed that mail.
> 
>> 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.
> 
> I do not even recall the NDA anymore.
> I wonder if it may have run out after all this time.
> 
> Looped Jeff in now.
> 
>> 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.
> 
> Ok.
> 
> As I said in the meeting itself, I will not object to removing this if
> it stands in the way monotonic.

Did a deep dive on my email and couldn’t find directly what customer/user need this may have been related to. Kevin’s guesses are likely on point, as both were publicly notable ActiveState customers at the time and each had custom code requests. Cisco’s were more exotic, as it was using Tcl embedded in various interesting ways. I don’t know who one would reach out to to see if a change in that area would impact them.

Jeff

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

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

TIP 717: YES

Donal.
________________________________
From: Jan Nijtmans
Sent: Thursday, May 15, 2025 21:39
To: Francois Vogel
Cc: Tcl Core List
Subject: Re: [TCLCORE] CFV TIP's #698, #704, #717, #719

Op do 15 mei 2025 om 22:28 schreef Francois Vogel:
>
> I'm dropping my votes here and now, that is more or less two days before the end of the CFV, but who cares since Jan already merged everything today...

Well, I care!  Thanks for your vote. I take full responsibility for the early
merge, before the vote ends. It means that if any of them will be rejected,
I will revert the corresponding implementation from trunk. Since there are
already various YES votes, it's a risk I'm willing to take.

> Please send me your votes by May 17, 12:00 UTC.
> [clock format 1747483200]
>
> Where is my mistake? Anyway.

No mistake at all. Again, thanks!

All votes until Saturday will be counted in the end result.

          Jan Nijtmans


_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!ERkRrKw2xMMn0TbFoakKfTe5t80ggTbkok4W4ZjiqdC-BV9eEV94RiS6d26exezc04YNVHbpaEZhk99GPEwib3wErce13yWNtO0$ [lists[.]sourceforge[.]net]

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

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

I cannot comment on the complexity of fixing the BCE, don’t know enough but to be on the safer side, I would have favored an approach that fixed the BCE before changing the INT_MAX limit to UINT_MAX. Conceptually, check immediate operands against BCE_MAX, set to INT_MAX for now and changed to UINT_MAX when the BCE was fixed.
I can comment on that now from a position of a little authority: the tebc-opnd-types branch fixes the issue there (and passes tests at least on Windows/Msys). That branch is independent of the alterations in the branch for TIP 720, though the two interact a bit (with there being new opcodes, that's unsurprising).

In the process, the branch does away with the generic opnd variable; it carried too little semantics and was conflating different things; things like variable indices, aux table indices and jump offsets are now their own things. Note that mostly the actual variables that are used are of type Tcl_Size even though the values in the bytecode are naturally unsigned because otherwise we get weird crashes (due to negation being needed to access things relative to the stack top). I've checked that the operands are read correctly from the bytecode stream so that they're meaningful; there were a few places where things that were semantically unsigned were being read as signed, and nobody had ever checked.

I didn't want this particular fix (which I thought needed anyway) to be mixed with the improvements to bytecode issuing.

Donal.
________________________________
From: apn...@ya... on behalf of apn...@ya...
Sent: Friday, May 16, 2025 03:38
To: Donal Fellows; 'Tcl Core'
Subject: RE: TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)


Donal,



I think we are in agreement that the byte code engine has issues with type correctness and mixed signed/unsigned usage. Additionally, it does not support 8 byte immediate values in the byte stream (which I would not classify as a bug but a RFE). The former has implications for values in the range (INT_MAX, UINT_MAX]. The latter has implications for (UINT_MAX, TCL_SIZE_MAX].



9.0.{0,1} dealt with both these by checking values against INT_MAX  in the compile phase and punting if necessary. This ensures correct operation of the byte code engine at the cost of slower execution via invokeStk (I think?).



By changing the limit to UINT_MAX, values in (INT_MAX, UINT_MAX] can now also be passed within the byte stream (though not UINT_MAX:TCL_SIZE_MAX). However, now the byte code engine will not operate correctly (potentially and admittedly in very rare cases) *unless its type-correctness issues are fixed*. If I understood you correctly, your view is that fixing the BCE is not within the purview of your branch but a task for some later branch.



I cannot comment on the complexity of fixing the BCE, don’t know enough but to be on the safer side, I would have favored an approach that fixed the BCE before changing the INT_MAX limit to UINT_MAX. Conceptually, check immediate operands against BCE_MAX, set to INT_MAX for now and changed to UINT_MAX when the BCE was fixed.



But that’s only because of *my* preference for not introducing regression into the main branch.



/Ashok





From: Donal Fellows <don...@ma...>
Sent: Thursday, May 15, 2025 4:27 PM
To: apn...@ya...; 'Tcl Core' <tcl...@li...>
Subject: Re: TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)



In this case, the branch is effectively starting from the point where the conversion to Tcl_Size has already taken place internally in the compiler; it's just renaming some of them so that I could better see what was going on. The aim was that I'd be able to look up the definition of a variable being used as, say, a jump offset and see that it isn't also being used for variable indices and/or aux data indices.



The range checks are for ensuring that the value read by TclGetUInt4AtPtr (widespread in the bytecode engine) is matched by the range checks in the compiler (where the values are [0,UINT_MAX] plus -1 for no index, which fits Tcl_Size nicely). Fixing the opnd variable usage within the bytecode engine is something for another branch I think; there's a lot of mixed usage where we ought to do something a bit more type-correct. But that's a bug already in the bytecode engine so I'm not condemning this branch to resolve it!



Donal.

________________________________

From: apn...@ya...<mailto:apn...@ya...> on behalf of apn...@ya...<mailto:apn...@ya...>
Sent: Wednesday, May 14, 2025 17:31
To: Donal Fellows; 'Tcl Core'
Subject: RE: TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)



I’m really not worried about LVT indices, it just happened to be the first (and only) range check that showed up in the diffs. The bigger issue is that these range checks appear in lots of places and any of them could have similar repercussions. I feel changing the limit to UINT_MAX from INT_MAX has limited value and not worth the risk of fiddling with TEBCResume to *selectively* split the signed and unsigned use cases. And as discussed ad naseum in the Tcl_Size discussion, modifying types from signed->unsigned is not to be taken lightly.

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

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

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

- Marc

On Wed, May 7, 2025 at 5:50 AM Jan Nijtmans <jan...@gm...> wrote:

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

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

Donal,

 

I think we are in agreement that the byte code engine has issues with type
correctness and mixed signed/unsigned usage. Additionally, it does not
support 8 byte immediate values in the byte stream (which I would not
classify as a bug but a RFE). The former has implications for values in the
range (INT_MAX, UINT_MAX]. The latter has implications for (UINT_MAX,
TCL_SIZE_MAX].

 

9.0.{0,1} dealt with both these by checking values against INT_MAX  in the
compile phase and punting if necessary. This ensures correct operation of
the byte code engine at the cost of slower execution via invokeStk (I
think?).

 

By changing the limit to UINT_MAX, values in (INT_MAX, UINT_MAX] can now
also be passed within the byte stream (though not UINT_MAX:TCL_SIZE_MAX).
However, now the byte code engine will not operate correctly (potentially
and admittedly in very rare cases) *unless its type-correctness issues are
fixed*. If I understood you correctly, your view is that fixing the BCE is
not within the purview of your branch but a task for some later branch.

 

I cannot comment on the complexity of fixing the BCE, don't know enough but
to be on the safer side, I would have favored an approach that fixed the BCE
before changing the INT_MAX limit to UINT_MAX. Conceptually, check immediate
operands against BCE_MAX, set to INT_MAX for now and changed to UINT_MAX
when the BCE was fixed.

 

But that's only because of *my* preference for not introducing regression
into the main branch.

 

/Ashok

 

 

From: Donal Fellows <don...@ma...> 
Sent: Thursday, May 15, 2025 4:27 PM
To: apn...@ya...; 'Tcl Core' <tcl...@li...>
Subject: Re: TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)

 

In this case, the branch is effectively starting from the point where the
conversion to Tcl_Size has already taken place internally in the compiler;
it's just renaming some of them so that I could better see what was going
on. The aim was that I'd be able to look up the definition of a variable
being used as, say, a jump offset and see that it isn't also being used for
variable indices and/or aux data indices.

 

The range checks are for ensuring that the value read by TclGetUInt4AtPtr
(widespread in the bytecode engine) is matched by the range checks in the
compiler (where the values are [0,UINT_MAX] plus -1 for no index, which fits
Tcl_Size nicely). Fixing the opnd variable usage within the bytecode engine
is something for another branch I think; there's a lot of mixed usage where
we ought to do something a bit more type-correct. But that's a bug already
in the bytecode engine so I'm not condemning this branch to resolve it!

 

Donal.

  _____  

From: apn...@ya... <mailto:apn...@ya...>  on behalf of
apn...@ya... <mailto:apn...@ya...> 
Sent: Wednesday, May 14, 2025 17:31
To: Donal Fellows; 'Tcl Core'
Subject: RE: TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY) 

 

I'm really not worried about LVT indices, it just happened to be the first
(and only) range check that showed up in the diffs. The bigger issue is that
these range checks appear in lots of places and any of them could have
similar repercussions. I feel changing the limit to UINT_MAX from INT_MAX
has limited value and not worth the risk of fiddling with TEBCResume to
*selectively* split the signed and unsigned use cases. And as discussed ad
naseum in the Tcl_Size discussion, modifying types from signed->unsigned is
not to be taken lightly.

 

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

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

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

-- Steve
On 7 May 2025 at 6:51 PM +0800, Jan Nijtmans <jan...@gm...>, wrote:
> 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] CFV TIP's #698, #704, #717, #719

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

Jan Nijtmans <jan...@pu...>
writes:
> 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>

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

rolf

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

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

Op do 15 mei 2025 om 22:28 schreef Francois Vogel:
>
> I'm dropping my votes here and now, that is more or less two days before the end of the CFV, but who cares since Jan already merged everything today...

Well, I care!  Thanks for your vote. I take full responsibility for the early
merge, before the vote ends. It means that if any of them will be rejected,
I will revert the corresponding implementation from trunk. Since there are
already various YES votes, it's a risk I'm willing to take.

> Please send me your votes by May 17, 12:00 UTC.
> [clock format 1747483200]
>
> Where is my mistake? Anyway.

No mistake at all. Again, thanks!

All votes until Saturday will be counted in the end result.

          Jan Nijtmans

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

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

I'm dropping my votes here and now, that is more or less two days before 
the end of the CFV, but who cares since Jan already merged everything 
today...
> 1) TIP #698: Handle negative screen distances
>      <https://core.tcl-lang.org/tips/doc/trunk/tip/698.md>

TIP #698: YES

> 2) TIP #704: extend Tk_CanvasTextInfo
>     <https://core.tcl-lang.org/tips/doc/trunk/tip/704.md>
TIP #704: YES
> 3) TIP #717: New function: Tcl_AttemptCreateHashEntry()
>     <https://core.tcl-lang.org/tips/doc/trunk/tip/717.m>
TIP #717: PRESENT
> 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 #719: YES

(I had asked for test cases to be able to test before merging, these 
didn't show up but, again, who cares!)

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

Where is my mistake? Anyway.

Regards,

Francois

[TCLCORE] New internal list representations

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

https://core.tcl-lang.org/tcl/wiki?name=New+abstract+list+representations
<https://core.tcl-lang.org/tcl/wiki?name=New+abstract+list+representations&p
> &p is a proposal to implement some list operations using new internal list
representations enabled by Brian's TIP 636. The wiki post has the full
details but TL;DR memory efficiency at a small (probably fixable) cost in
iteration speed for large lists. The post has the numbers.

 

The apn-tip636-appl branch contains the implementation of the proposal. The
listTypes.test file contains the test cases to exercise the three new
internal list types as well as the existing ones. Passes -enable-symbols=mem
and valgrind OMM. gcov shows 91% code and 100% function coverage of the new
implementation. Missing coverage is for "panic blocks" and validation which
is not exercised as it is already done by upper callers.

 

Not planning a TIP as there are no changes at the script or C API level.

 

Please review (both proposal and code) and raise any objections you may
have. (It's not that much code to review and pretty isolated thanks to 636).

 

/Ashok

 

 

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

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

I believe I've now fixed those two issues.

The memory leak was a real and serious one; two opcodes weren't deleting a duplicated value on error. (I've also checked the other new opcodes: they all either were minor variants of existing ones where the reference count management was not part of the altered instruction sequence, or were operations that didn't need to create any duplicates anyway. I'm sure they don't leak.)

The control for the deprecation warning is now set to require MSVC 19.0 or later; if that's an insufficient constraint (or GCC or Clang need more), I'm happy to adjust it or you can just put the right #if bits in. (It's always correct for there to be no deprecation warnings; I've tracked down all the places where I had to fix them inside Tcl itself.)

Donal.
________________________________
From: Jan Nijtmans
Sent: Thursday, May 15, 2025 08:58
To: Donal Fellows
Cc: Ashok Nadkarni; Tcl Core
Subject: Re: [TCLCORE] TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)

Op wo 14 mei 2025 om 17:20 schreef Donal Fellows:
> If MSVC can't deprecate an enum element, we'll just make that a no-op. It's just a tweak to the conditions on how to define the macro. (It's formally a C++17/C23 feature when applied to an enumerator.)

Donal, are you aware that test dict-19.2 is failing in --enable-symbols=mem
builds? One rule we have is that merges to trunk MUST not result
in breakage, no matter whether a TIP is accepted or not, no matter
what platform/compiler. This means that those 2 problems MUST
be solved _before_ merging the branch to trunk.

With my YES vote, I assume those two problems will be fixed
before the merge.

To me, any additional review is appreciated! Do we need to
wait for such a review to do the merge? For a merge to
"9.0", my answer is Yes: Anything we can do to prevent a
breakage is worth the wait. For a merge to trunk, my
answer would be No: The review can still be done when
the code is already on trunk (assuming no major breakage).
If problems are found they still can be fixed. The more eyes
the better, and having it on trunk means that more eyes see
it, so there are more chances to find any problems before
9.1 is released. With 9.0 we don't have that luxury.

Hope this helps,
           Jan Nijtmans

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

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

In this case, the branch is effectively starting from the point where the conversion to Tcl_Size has already taken place internally in the compiler; it's just renaming some of them so that I could better see what was going on. The aim was that I'd be able to look up the definition of a variable being used as, say, a jump offset and see that it isn't also being used for variable indices and/or aux data indices.

The range checks are for ensuring that the value read by TclGetUInt4AtPtr (widespread in the bytecode engine) is matched by the range checks in the compiler (where the values are [0,UINT_MAX] plus -1 for no index, which fits Tcl_Size nicely). Fixing the opnd variable usage within the bytecode engine is something for another branch I think; there's a lot of mixed usage where we ought to do something a bit more type-correct. But that's a bug already in the bytecode engine so I'm not condemning this branch to resolve it!

Donal.
________________________________
From: apn...@ya... on behalf of apn...@ya...
Sent: Wednesday, May 14, 2025 17:31
To: Donal Fellows; 'Tcl Core'
Subject: RE: TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)


I’m really not worried about LVT indices, it just happened to be the first (and only) range check that showed up in the diffs. The bigger issue is that these range checks appear in lots of places and any of them could have similar repercussions. I feel changing the limit to UINT_MAX from INT_MAX has limited value and not worth the risk of fiddling with TEBCResume to *selectively* split the signed and unsigned use cases. And as discussed ad naseum in the Tcl_Size discussion, modifying types from signed->unsigned is not to be taken lightly.

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

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

Op wo 14 mei 2025 om 17:20 schreef Donal Fellows:
> If MSVC can't deprecate an enum element, we'll just make that a no-op. It's just a tweak to the conditions on how to define the macro. (It's formally a C++17/C23 feature when applied to an enumerator.)

Donal, are you aware that test dict-19.2 is failing in --enable-symbols=mem
builds? One rule we have is that merges to trunk MUST not result
in breakage, no matter whether a TIP is accepted or not, no matter
what platform/compiler. This means that those 2 problems MUST
be solved _before_ merging the branch to trunk.

With my YES vote, I assume those two problems will be fixed
before the merge.

To me, any additional review is appreciated! Do we need to
wait for such a review to do the merge? For a merge to
"9.0", my answer is Yes: Anything we can do to prevent a
breakage is worth the wait. For a merge to trunk, my
answer would be No: The review can still be done when
the code is already on trunk (assuming no major breakage).
If problems are found they still can be fixed. The more eyes
the better, and having it on trunk means that more eyes see
it, so there are more chances to find any problems before
9.1 is released. With 9.0 we don't have that luxury.

Hope this helps,
           Jan Nijtmans

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

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

> (I shudder to think what code that makes a stack frame with that
> many local variable entries would look like, and it will certainly
> take quite a while to compile.)

While I can't serve an example of that I know that some EDA generated
code ran into trouble with pre-compiling code containing more than 255
proc definitions. Which I had to fix. See

https://github.com/ActiveState/tdk/blob/master/lib/tclcompiler/cmpWrite.c#L3480
-L3794

for that particular horror. Code which your changes make moot,
removable, and good bye to it, do not let the door hit you on the way
out.

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

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

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

Donal wrote:

 

> In general, this was on the verge of not being TIPped at all; it's only there really because of the impact on the TDK compiler/tbcload. Because of this, I'm pushing it through the process faster than normal.

 

Yes, I understand the borderline need for a TIP. My request for time was not so much about the TIP process as the conclusion from a previous discussion in the online meet that any substantial implementation changes should be reviewed by a second pair of eyes before acceptance (with the full understanding that very few folks will have the required byte code competence!). With the absolute greatest respect for your technical smarts, it’s a slippery slope if we selectively ignore that requirement.

 

> If MSVC can't deprecate an enum element…

 

Right, that’s what I was suggesting.

 

> I wish we could use <stdint.h> (and <stdbool.h> as well).

 

Can’t we? I thought that was part of C99 which is a requirement for 9.1?

 

> Re the range checks, I guess we'll need to fix the type of unsigned operands (as part of the Tcl_Size project). The bytecode compiler is now matching the usage, but the usage in TEBC is itself wrong. (I shudder to think what code that makes a stack frame with that many local variable entries would look like, and it will certainly take quite a while to compile.) This particular branch isn't meant to touch LOCAL meaningfully, but LVT indices are definitely intended to be positive (with -1 being "no LVT entry") so the assumption that they're able to be handled as unsigned int within TEBC is likely a good one; the -1 should never result in an issue of opcodes that use LVT entries. 

 

I’m really not worried about LVT indices, it just happened to be the first (and only) range check that showed up in the diffs. The bigger issue is that these range checks appear in lots of places and any of them could have similar repercussions. I feel changing the limit to UINT_MAX from INT_MAX has limited value and not worth the risk of fiddling with TEBCResume to *selectively* split the signed and unsigned use cases. And as discussed ad naseum in the Tcl_Size discussion, modifying types from signed->unsigned is not to be taken lightly.

 

At the end of the day, I think everyone is supportive of the TIP. My post was regarding (a) affording a little more time for review before merge, and (b) reconsidering the change from INT_MAX to UINT_MAX as not worth the risk.

 

/Ashok

 

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

[Andreas K. <and...@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:
 
> What I recall about the ticket was what I posted on tcl-core a few
> days ago.

My apologies for the repeated query, I missed that mail.

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

I do not even recall the NDA anymore.
I wonder if it may have run out after all this time.

Looped Jeff in now.

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

Ok.

As I said in the meeting itself, I will not object to removing this if
it stands in the way monotonic.

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

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

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

In general, this was on the verge of not being TIPped at all; it's only there really because of the impact on the TDK compiler/tbcload. Because of this, I'm pushing it through the process faster than normal.

Re performance being noise, that's about what I'd hope for. It's not a branch where performance is a primary focus (though some paths may be significantly better, especially around [try]).

If MSVC can't deprecate an enum element, we'll just make that a no-op. It's just a tweak to the conditions on how to define the macro. (It's formally a C++17/C23 feature when applied to an enumerator.)

Re the range checks, I guess we'll need to fix the type of unsigned operands (as part of the Tcl_Size project). The bytecode compiler is now matching the usage, but the usage in TEBC is itself wrong. (I shudder to think what code that makes a stack frame with that many local variable entries would look like, and it will certainly take quite a while to compile.) This particular branch isn't meant to touch LOCAL meaningfully, but LVT indices are definitely intended to be positive (with -1 being "no LVT entry") so the assumption that they're able to be handled as unsigned int within TEBC is likely a good one; the -1 should never result in an issue of opcodes that use LVT entries.

I wish we could use <stdint.h> (and <stdbool.h> as well).

________________________________
From: Ashok Nadkarni
Sent: Monday, May 12, 2025 14:59
To: Donal Fellows; Tcl Core
Subject: Re: TIP 720: Updated Tcl Bytecode Opcodes CFV (NOTE: NO DELAY)

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 [core.tcl-lang.org]<https://urldefense.com/v3/__https://core.tcl-lang.org/tips/doc/trunk/tip/720.md__;!!PDiH4ENfjr2_Jw!AZYcnp0vbPAsnExo4ZBiiFXx1UOLBYeTN1c8BqoZfUYc96p9LQop1KOylIPhICp-0gsz7c_3Xe76k5_1w3RPHKL9WELa1b7uZmXl$>

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] Bytecode compiler and monotonic time

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

On 05/14/2025 09:29 AM, Harald Oehlmann wrote:

> I will back-out this part from the patch and only keep "after" and "time".

No, don't do this. The patch already deals with that problem by converting the wall time
given to the "-seconds" option to the corresponding value in monotonic time.

> To change a documented feature is nearly impossible...

Hmm, that's debatable at least for a major release. We should not be bound to repeat
our ancient faults ad nauseam, cf.

   Time is heavy sometimes; imagine how heavy eternity must be. -- E.M.Cioran, The Book of Delusions, 1936

BR,
Christian

Re: [TCLCORE] Bytecode compiler and monotonic time

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

Am 14.05.2025 um 09:16 schrieb Colin Macleod via Tcl-Core:
> On 14/05/2025 08:02, Christian Werner wrote:
>> 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.
> 
> That's correct, and somewhat surprising.  I've never used this in real 
> code, but I did dig into it recently to respond to a programming 
> challenge on Mastodon: https://mastodon.scot/@CGM/114375791583866744
> 
> Colin.
Thanks for that. There is a rationale in the documentation, that the 
limit may be changed. This is reasonable. It would be better to give a 
"clock seconds" value instead an offset from now, but never mind.

I will back-out this part from the patch and only keep "after" and "time".

To change a documented feature is nearly impossible...

Thanks for all,
Harald

Re: [TCLCORE] Bytecode compiler and monotonic time

[Colin M. <col...@ya...>]

On 14/05/2025 08:02, Christian Werner wrote:
> 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.

That's correct, and somewhat surprising.  I've never used this in real 
code, but I did dig into it recently to respond to a programming 
challenge on Mastodon: https://mastodon.scot/@CGM/114375791583866744

Colin.