|
From: bch <bra...@gm...> - 2025-10-24 06:36:07
|
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Oct 21, 2025, at 01:55, Donal Fellows <don...@ma...> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <div class="_E_EBlockEntityContainer"><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Helvetica Neue", sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="entityDelimiterBefore"></span> <div style="width: 100%; display: inline-block;" class="_Entity _EType_Quote _EId_Quote _EReadonly_1"> <table id="ReplyWithQuote_Container" style="border: 1.5px solid rgb(237, 235, 233); border-radius: 4px; padding: 4px 0px 4px 4px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); margin-bottom: 4px;"> <tbody> <tr> <td rowspan="2" style="background-color: rgb(200, 198, 196); width: 3.5px; border-radius: 10px; padding: 0px;"> </td> <td style="font-size: 12px; border-left: 10px solid transparent; border-right: 10px solid transparent; padding: 0px;"> <div style="display: inline; color: rgb(50, 49, 48);">EricT</div> <div style="display: inline; padding-left: 10px; color: rgb(96, 94, 92);">2025-10-21 04:12</div> </td> </tr> <tr> <td style="font-size: 14px; color: rgb(50, 49, 48); border-left: 10px solid transparent; border-right: 10px solid transparent; padding: 0px;"> 1. Shell precedent: The $(command) syntax is well-established in bash/sh for command substitution. Tcl users familiar with shell scripting would find this natural, not confusing.</td> </tr> </tbody> </table> </div> <span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Helvetica Neue", sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="entityDelimiterAfter"></span></div> <div style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Helvetica Neue", sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="elementToProof"> Surely the better shell precedent would be the $((expression)) form? </div></div></blockquote><div><br></div><div><br></div><div>Fwiw, I don’t think looking up to bash/sh for inspiration is where we should be at all. We can do better for Tcl, regardless of how familiar it looks.</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Helvetica Neue", sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="elementToProof">That would also be quite a bit less likely to clash with existing use cases.<span style="color: rgb(0, 0, 0);"> Hmm, a quick search with <a href="https://github.com/search?q=%24%28%28+language%3ATcl&type=code">https://github.com/search?q=%24%28%28+language%3ATcl&type=code</a> gives 29 hits (most of which appear to be false positives; the real hits seem to be from one place in JimTcl itself), as opposed to 4k hits when looking for $( in Tcl code; two orders of magnitude less usage. One of the <i>really</i> nice things about a resource like GitHub is that one can <i>quickly</i> search for language syntax features across a lot of code and get a good feeling for practical compatibility.</span></div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> <br> </div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> While $(([llength $x] - 17)) is no shorter than {=}{[llength $x] - 17}, it's definitely easier to type!</div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> <br></div></div></blockquote><div><br></div><div>I already deal enough w [expr] that it’s not a big deal… but *imagining* typing either of the above, if I had to pick, I think I’d prefer Brian’s modification for the reason of the benefits pointed out by him and Kevin wrt “{*}” precedent in scripts and its adaptable parser implementation.</div><div><br></div><div>“Fixing” empty array w pragmas or similar is also not attractive sounding… it means it’s difficult to know what kind of runtime you’re stepping up to. At its worst, it leads to inscrutable envs like php.ini. This is a thin edge of the wedge we should be looking to avoid.</div><br><blockquote type="cite"><div dir="ltr"><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> </div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> (Eric: Don't lose heart! These discussions are a <i>lot</i> less acrimonious than the discussion over what became {*} was.) </div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> <br> </div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> Donal.</div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> <br> </div> <hr style="display: inline-block; width: 98%;"> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <b>From:</b> EricT <tw...@gm...><br> <b>Sent:</b> Tuesday, October 21, 2025 04:11<br> <b>To:</b> Brian Griffin <bri...@ea...><br> <b>Cc:</b> tc...@ro... <tc...@ro...>; Tcl Core List <tcl...@li...><br> <b>Subject:</b> Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax </div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style="direction: ltr;">Thanks for the feedback, Brian! I understand your concern about the semantic distinction between $ (value) and [ ] (execution).<br> <br> I'd offer a few thoughts:<br> <br> 1. Shell precedent: The $(command) syntax is well-established in bash/sh for command substitution. Tcl users familiar with shell scripting would find this natural, not confusing.<br> <br> 2. $ already involves execution: Even $var involves command execution internally (TclGetVar), it's just optimized. The distinction between "value substitution" and "command execution" is somewhat artificial at the implementation level.<br> <br> 3. expr is special and has historical precedent: Unlike arbitrary commands, expr is used so frequently that syntactic sugar makes sense - similar to how $var is sugar for [set var]. We optimize the common case. I believe there was a time in early Tcl before $var existed when [set var] was the only choice - if so, adding $var as syntactic sugar for variable substitution was a usability win. $(expr) follows the same pattern - sugar for the extremely common [expr {...}] case.<br> <br> 4. Consistency: $(expr) fits the pattern of "$ means substitute something here" - whether a variable, array element, or expression result. Modern languages like Python have embraced similar concepts with f-strings that allow {expression} for inline evaluation. $(expr) brings this convenience to Tcl while maintaining our substitution semantics.<br> <br> That said, I appreciate the philosophical consistency argument. Do you see the security benefits (auto-bracing) as compelling enough to outweigh the semantic concern?<br> <br> </div> <div style="direction: ltr;">Did you see the email I sent you about lseq? Maybe it landed in your spam folder - that happened once before as I recall.</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">Eric</div> <div style="direction: ltr;"><br> </div> <div><br> </div> <div style="direction: ltr;">On Mon, Oct 20, 2025 at 7:19 PM Brian Griffin <<a class="OWAAutoLink" id="OWA804178ca-19c0-2c1c-f2ba-089dcc6f3e84" href="mailto:bri...@ea...">bri...@ea...</a>> wrote:</div> <blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);"> <div>I like the idea of simplifying expression substitutions. The problem I have is that the '$' is defined to be a value substitution. Running a command (execution) is a [] substitution, not a '$' substitution. Conflating the two modes of substitution can cause confusion for newbies, and even experienced programmers. </div> <div><br> </div> <div>I recognize that this view is a very subtle distinction, but I think it's important.</div> <div><br> </div> <div>Think of it like conflating * vs & in C. (Maybe not that bad, but similar)</div> <div><br> </div> <div>-Brian</div> <div><br> </div> <blockquote> <div>On Oct 20, 2025, at 07:22, EricT <<a class="OWAAutoLink" id="OWA485216db-5c80-ecb7-38fe-a224c563294c" href="mailto:tw...@gm...">tw...@gm...</a>> wrote:</div> <div><br> </div> <div style="direction: ltr;">Regarding the discussion in the telco today. If the incompatibility discussed is the known empty array issue, then for that I would propose the following:</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">There could be a pragma or tcl_dollar_expr global variable with several settings.</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">1. Work in compatibility mode, i.e. as though the feature was not implemented at all. </div> <div style="direction: ltr;">2. Work in diagnostic mode, throw an error for any $(...) use</div> <div style="direction: ltr;">3. Work in full implementation mode</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">The code to do this, given a global C variable to check would be trivial. </div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">This value could default to 1. for at least 9.1 or 9.2 but there could be an option, similar to tclsh -encoding, that would allow the pragma variable to be set before any init script code is run. This would give developers the opportunity to set the variable to mode 2 in order to easily track down uses of $(index) before any code were to begin using $(expr). </div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">I think it would be quite rare if this syntax change would affect binary extensions, so it should be only with script level coding. </div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">The fix to any code that is using the empty array variable, is to change from,</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;"> set val $(index)</div> <div style="direction: ltr;"> set val $($var) - or any other valid index string</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">to</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;"> set val ${(index)}</div> <div style="direction: ltr;"> set val ${($var)}</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">Likewise for any other use of the $(...) substitution in current use.</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">This change can begin to be made right away, since it is a compatible syntax that does not change the semantics. Once all the init time script code or packages that use the un-braced syntax are found and changed, the feature could begin to be used by those who are interested.</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">On the other hand, if the incompatibility is something other than this empty array, I'd be most appreciative to know what it is.</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">thanks</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">Eric</div> <div style="direction: ltr;"><br> </div> <div><br> </div> <div style="direction: ltr;">On Sun, Oct 19, 2025 at 3:44 AM EricT <<a class="OWAAutoLink" id="OWA0301b487-6449-46f4-f565-a768f03d4ed8" href="mailto:tw...@gm...">tw...@gm...</a>> wrote:</div> <blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);"> <div style="direction: ltr;">Harald,<br> <br> Thank you for your willingness to sponsor!<br> <br> To clarify: I am not the author of Jim Tcl - I'm just a long-time Tcl user who, in retirement, wanted to give something back to the Tcl community. Jim Tcl's successful use of this syntax for years demonstrates that the concept is viable.<br> <br> Regarding the telco: I attempted to join previously but was unsuccessful with the setup. I won't be able to participate on Monday, but I'm available via email for any questions or clarifications that arise from the discussion.<br> <br> I don't currently have write access to either the Tcl Fossil repository or the TIP repository, so I'm unable to make changes directly. At nearly 80 years old, I'm not comfortable learning new version control systems on my own. If the TIP moves forward, I'd need guidance and assistance with the Fossil workflow, or perhaps someone from the core team who shares our interest in this TIP could handle the integration based on my GitHub prototype.<br> <br> I'm currently developing a comprehensive test suite in standard tcltest format, with particular focus on edge cases.<br> <br> Looking forward to hearing how Monday's discussion goes!<br> <br> Best regards,<br> Eric<br> <br> </div> <div><br> </div> <div style="direction: ltr;">On Sun, Oct 19, 2025 at 2:05 AM Harald Oehlmann <<a class="OWAAutoLink" id="OWA2fbb6158-6c45-6109-517a-ee2f2e870a8d" href="mailto:har...@el...">har...@el...</a>> wrote:</div> <blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);"> <div>Eric,<br> sponsoring is no problem. The point is to get positive votes.<br> This requires a positive discussion.<br> You are the Author of Jim?<br> Could you participate on the telco on Monday?<br> <br> Do you have write access to the tcl fossil? We would need the<br> implementation there.<br> <br> Thanks for all,<br> Harald<br> <br> Am 18.10.2025 um 22:58 schrieb EricT:<br> > Thank you for the positive feedback and for raising this in Monday's<br> > telco! I'm encouraged by your support.<br> ><br> > Regarding $(a) - you're right that reading an empty array element with a<br> > variable index is a valid construct. However, this is explicitly<br> > addressed in the TIP and the repository README. The workarounds are<br> > straightforward:<br> ><br> > ${(a)} # Braced form<br> > [set (a)] # Command substitution<br> ><br> > Both still work. In fact, code using $(varname) could be proactively<br> > modified to use ${(varname)} to indicate the clear intent of an empty<br> > array reference, which improves readability. The security, performance,<br> > and usability benefits of $(...) seemed to justify this trade-off for<br> > Tcl 9.x where some incompatibilities are expected.<br> ><br> > Given your interest in the feature, would you be willing to consider<br> > sponsoring TIP 672? The implementation is working and minimal (~100<br> > lines across two files), with the main open question being the preferred<br> > approach for tracking synthetic strings for cleanup. Your guidance on<br> > that architectural decision would be particularly valuable.<br> ><br> > The prototype repository with full implementation and examples is here:<br> ><br> > <a data-auth="NotApplicable" class="OWAAutoLink" id="OWAdaeb721a-2f2d-fd46-b16d-f7f9fa85487c" href="https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$"> https://github.com/rocketship88/tcl-tip-672-prototype [github.com]</a> <https://<br> > <a data-auth="NotApplicable" class="OWAAutoLink" id="OWA1c08f87f-3e1b-7345-47d1-f83e958ed390" href="https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$"> github.com/rocketship88/tcl-tip-672-prototype [github.com]</a>><br> ><br> > Looking forward to the results of the discussion on Monday! I won't be<br> > able to join the telco discussion, but I'm available via email for any<br> > questions or clarifications that arise.<br> ><br> ><br> > On Sat, Oct 18, 2025 at 1:09 PM Harald Oehlmann<br> > <<a class="OWAAutoLink" id="OWAd5fa5ee4-6688-a096-b39b-58044e2e7260" href="mailto:har...@el...">har...@el...</a> <mailto:<a class="OWAAutoLink" id="OWAf2861fb4-1b96-a647-8bf1-afd401700057" href="mailto:har...@el...">har...@el...</a>>> wrote:<br> ><br> > Am 17.10.2025 um 23:22 schrieb EricT:<br> > > Hello Tcl Core Team,<br> > ><br> > > I have developed a working prototype implementation of TIP 672,<br> > which<br> > > adds the $(expression) syntax as a more intuitive alternative to<br> > [expr<br> > > {expression}].<br> > ><br> > > Repository: <a data-auth="NotApplicable" class="OWAAutoLink" id="OWAce957dfa-015b-f49e-7f83-9d4c46409d16" href="https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$"> https://github.com/rocketship88/tcl-tip-672-prototype [github.com]</a><br> > <<a data-auth="NotApplicable" class="OWAAutoLink" id="OWA94372cbc-677c-140b-b1b9-19e6a24a6c78" href="https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$">https://github.com/rocketship88/tcl-tip-672-prototype [github.com]</a>><br> > > <<a data-auth="NotApplicable" class="OWAAutoLink" id="OWA40bf9571-1dc9-0b4c-1210-7d004ffe86fc" href="https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$">https://github.com/rocketship88/tcl-tip-672-prototype [github.com]</a> <https://<br> > <a data-auth="NotApplicable" class="OWAAutoLink" id="OWAbd5aac6c-e012-89e6-4559-05a1150d33b2" href="https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$">github.com/rocketship88/tcl-tip-672-prototype [github.com]</a>>><br> > ><br> > > The implementation is minimal, modifying only two files<br> > (tclParse.c and<br> > > tclNamesp.c) with approximately 100 lines of changes. The key<br> > > modification converts the existing two-way branch in<br> > Tcl_ParseVarName to<br> > > a three-way branch, with the new path handling $(...) by creating a<br> > > synthetic [expr {...}] command string.<br> > ><br> > > Key Accomplishments:<br> > ><br> > > Full bytecode compilation: The synthetic string approach integrates<br> > > seamlessly with the existing compiler, producing identical optimized<br> > > bytecode as [expr {...}]. The disassembler output (shown in the<br> > README)<br> > > demonstrates efficient variable loading with no runtime parsing<br> > overhead.<br> > ><br> > > Proven approach: Jim Tcl has used this syntax successfully for years<br> > ><br> > > Comprehensive testing: Works correctly with string interpolation,<br> > > variable scoping, error handling, and interactive mode<br> > ><br> > > Known Limitations:<br> > ><br> > > Memory leak: The synthetic string is allocated but not tracked for<br> > > cleanup in Tcl_FreeParse. This requires core team guidance on the<br> > > preferred solution (modify Tcl_Parse structure vs. thread-local<br> > tracking).<br> > ><br> > > Error messages: Currently show the synthetic command rather than the<br> > > original $(...) syntax, though this is arguably helpful for<br> > debugging.<br> > ><br> > > Questions for the Team:<br> > ><br> > > What is the preferred approach for tracking synthetic strings for<br> > cleanup?<br> > > Is this prototype architecture acceptable for Tcl 9.x?<br> > > Are there concerns with the synthetic string approach that I<br> > should address?<br> > ><br> > > The complete implementation with side-by-side diffs is available<br> > in the<br> > > repository. I'm happy to refine the code based on your feedback and<br> > > would appreciate any guidance on moving this forward.<br> > ><br> > > Best regards,<br> > > Eric<br> > Eric,<br> > great proposal, thank you !<br> ><br> > Perhaps, we may discuss this on Monday in the biweekly telco.<br> > I am also excited and in favor to this.<br> > Nevertheless, "$(a)" is to my knowledge a quite common syntax for<br> > arrays. We have already killed less disruptive proposals (see optional<br> > "- args") by endless discussions and getting nowhere.<br> > Hope, this will be fruitful.<br> ><br> > In addition, I would like to add the Tk test reform by the other<br> > Eric to<br> > the biweekly topics.<br> > Here is a revised agenda proposal proposal:<br> ><br> > Top 1) Release calender (TIP 713)<br> > - 9.0.3: October (2 weeks left)<br> > - 9.1a1: November (6 weeks left)<br> > Top 2) TIP 734 nested mutex (go or not)<br> > Top 3) TIP 733: accessability (test status)<br> > Top 4) TIP 732: TCL library path (discussion)<br> > Top 5) TIP 731: use C enums (no brainer?)<br> > Top 6) TIP 720: new bytecodes (final, great! Any issues?)<br> > Top 7) TIP 721: Tcl_AttemptGetString<br> > Top 8) TIP 715: supported build systems<br> > Top 9) $($a+$b) syntax for expressions<br> > Top 10) Tk test reform by Eric (Thanks !)<br> > Top 11) Tcl depot and awthemes ?<br> > Top 12) AOB<br> > Top 13) Next meeting:<br> > 3rd of November 12:00 UTC.<br> > Daytime saving time ends 2nd of November in US, 26th of<br> > October in<br> > Europe.<br> > Will we keep 12:00 UTC ? Or 13:00 UTC, so Don has 8:00 AM?<br> ><br> > Take care,<br> > Harald<br> _______________________________________________<br> Tcl-Core mailing list<br> <a class="OWAAutoLink" id="OWAf1cd5ec3-5d97-fbde-0c52-b7c698f69775" href="mailto:Tcl...@li...">Tcl...@li...</a><br> <a data-auth="NotApplicable" class="OWAAutoLink" id="OWAa4f4fc9a-55e5-a33e-f0a7-08748655b707" href="https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$">https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]</a></div> </blockquote> </blockquote> <div>_______________________________________________<br> Tcl-Core mailing list<br> <a class="OWAAutoLink" id="OWAf7715aa5-657f-5210-174d-19047f1ff76e" href="mailto:Tcl...@li...">Tcl...@li...</a><br> <a data-auth="NotApplicable" class="OWAAutoLink" id="OWA379eb571-ba61-7a7c-a12f-00064b6d4c0d" href="https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$">https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]</a></div> </blockquote> <div><br> </div> <div>_______________________________________________<br> Tcl-Core mailing list<br> <a class="OWAAutoLink" id="OWA03fcfbd3-f104-e894-3393-012223471655" href="mailto:Tcl...@li...">Tcl...@li...</a><br> <a data-auth="NotApplicable" class="OWAAutoLink" id="OWA370068aa-2027-2f72-9d23-2e57871abfcd" href="https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$">https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]</a></div> </blockquote> <span>_______________________________________________</span><br><span>Tcl-Core mailing list</span><br><span>Tcl...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/tcl-core</span><br></div></blockquote></body></html> |