Menu
▾
▴
tcl-core — Tcl Core Team discussions about Tcl development
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(19) |
Jul
(96) |
Aug
(144) |
Sep
(222) |
Oct
(496) |
Nov
(171) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(4) |
Feb
(4) |
Mar
(9) |
Apr
(4) |
May
(12) |
Jun
(6) |
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(52) |
Aug
(47) |
Sep
(47) |
Oct
(95) |
Nov
(56) |
Dec
(34) |
| 2003 |
Jan
(99) |
Feb
(116) |
Mar
(125) |
Apr
(99) |
May
(123) |
Jun
(69) |
Jul
(110) |
Aug
(130) |
Sep
(289) |
Oct
(211) |
Nov
(98) |
Dec
(140) |
| 2004 |
Jan
(85) |
Feb
(87) |
Mar
(342) |
Apr
(125) |
May
(101) |
Jun
(60) |
Jul
(151) |
Aug
(118) |
Sep
(162) |
Oct
(117) |
Nov
(125) |
Dec
(95) |
| 2005 |
Jan
(141) |
Feb
(54) |
Mar
(79) |
Apr
(83) |
May
(74) |
Jun
(125) |
Jul
(63) |
Aug
(89) |
Sep
(130) |
Oct
(89) |
Nov
(34) |
Dec
(39) |
| 2006 |
Jan
(98) |
Feb
(62) |
Mar
(56) |
Apr
(94) |
May
(169) |
Jun
(41) |
Jul
(34) |
Aug
(35) |
Sep
(132) |
Oct
(722) |
Nov
(381) |
Dec
(36) |
| 2007 |
Jan
(34) |
Feb
(174) |
Mar
(15) |
Apr
(35) |
May
(74) |
Jun
(15) |
Jul
(8) |
Aug
(18) |
Sep
(39) |
Oct
(125) |
Nov
(89) |
Dec
(129) |
| 2008 |
Jan
(176) |
Feb
(91) |
Mar
(69) |
Apr
(178) |
May
(310) |
Jun
(434) |
Jul
(171) |
Aug
(73) |
Sep
(187) |
Oct
(132) |
Nov
(259) |
Dec
(292) |
| 2009 |
Jan
(27) |
Feb
(54) |
Mar
(35) |
Apr
(54) |
May
(93) |
Jun
(10) |
Jul
(36) |
Aug
(36) |
Sep
(93) |
Oct
(52) |
Nov
(45) |
Dec
(74) |
| 2010 |
Jan
(20) |
Feb
(120) |
Mar
(165) |
Apr
(101) |
May
(56) |
Jun
(12) |
Jul
(73) |
Aug
(306) |
Sep
(154) |
Oct
(82) |
Nov
(63) |
Dec
(42) |
| 2011 |
Jan
(176) |
Feb
(86) |
Mar
(199) |
Apr
(86) |
May
(237) |
Jun
(50) |
Jul
(26) |
Aug
(56) |
Sep
(42) |
Oct
(62) |
Nov
(62) |
Dec
(52) |
| 2012 |
Jan
(35) |
Feb
(33) |
Mar
(128) |
Apr
(152) |
May
(133) |
Jun
(21) |
Jul
(74) |
Aug
(423) |
Sep
(165) |
Oct
(129) |
Nov
(387) |
Dec
(276) |
| 2013 |
Jan
(105) |
Feb
(30) |
Mar
(130) |
Apr
(42) |
May
(60) |
Jun
(79) |
Jul
(101) |
Aug
(46) |
Sep
(81) |
Oct
(14) |
Nov
(43) |
Dec
(4) |
| 2014 |
Jan
(25) |
Feb
(32) |
Mar
(30) |
Apr
(80) |
May
(42) |
Jun
(23) |
Jul
(68) |
Aug
(127) |
Sep
(112) |
Oct
(72) |
Nov
(29) |
Dec
(69) |
| 2015 |
Jan
(35) |
Feb
(49) |
Mar
(95) |
Apr
(10) |
May
(70) |
Jun
(64) |
Jul
(93) |
Aug
(85) |
Sep
(43) |
Oct
(38) |
Nov
(124) |
Dec
(29) |
| 2016 |
Jan
(253) |
Feb
(181) |
Mar
(132) |
Apr
(419) |
May
(68) |
Jun
(90) |
Jul
(52) |
Aug
(142) |
Sep
(131) |
Oct
(80) |
Nov
(84) |
Dec
(192) |
| 2017 |
Jan
(329) |
Feb
(842) |
Mar
(248) |
Apr
(85) |
May
(247) |
Jun
(186) |
Jul
(37) |
Aug
(73) |
Sep
(98) |
Oct
(108) |
Nov
(143) |
Dec
(143) |
| 2018 |
Jan
(155) |
Feb
(139) |
Mar
(72) |
Apr
(112) |
May
(82) |
Jun
(119) |
Jul
(24) |
Aug
(33) |
Sep
(179) |
Oct
(295) |
Nov
(111) |
Dec
(34) |
| 2019 |
Jan
(20) |
Feb
(29) |
Mar
(49) |
Apr
(89) |
May
(185) |
Jun
(131) |
Jul
(9) |
Aug
(59) |
Sep
(30) |
Oct
(44) |
Nov
(118) |
Dec
(53) |
| 2020 |
Jan
(70) |
Feb
(108) |
Mar
(50) |
Apr
(9) |
May
(70) |
Jun
(24) |
Jul
(103) |
Aug
(82) |
Sep
(132) |
Oct
(119) |
Nov
(174) |
Dec
(169) |
| 2021 |
Jan
(75) |
Feb
(51) |
Mar
(76) |
Apr
(73) |
May
(53) |
Jun
(120) |
Jul
(114) |
Aug
(73) |
Sep
(70) |
Oct
(18) |
Nov
(26) |
Dec
|
| 2022 |
Jan
(26) |
Feb
(63) |
Mar
(64) |
Apr
(64) |
May
(48) |
Jun
(74) |
Jul
(129) |
Aug
(106) |
Sep
(238) |
Oct
(169) |
Nov
(149) |
Dec
(111) |
| 2023 |
Jan
(110) |
Feb
(47) |
Mar
(82) |
Apr
(106) |
May
(168) |
Jun
(101) |
Jul
(155) |
Aug
(35) |
Sep
(51) |
Oct
(55) |
Nov
(134) |
Dec
(202) |
| 2024 |
Jan
(103) |
Feb
(129) |
Mar
(154) |
Apr
(89) |
May
(60) |
Jun
(162) |
Jul
(201) |
Aug
(61) |
Sep
(167) |
Oct
(111) |
Nov
(133) |
Dec
(141) |
| 2025 |
Jan
(122) |
Feb
(88) |
Mar
(106) |
Apr
(113) |
May
(203) |
Jun
(185) |
Jul
(124) |
Aug
(202) |
Sep
(176) |
Oct
(206) |
Nov
(258) |
Dec
(137) |
|
From: Kevin W. <kw...@co...> - 2025-12-08 12:58:51
|
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">TIP 739: YES</div><div dir="ltr"><br><blockquote type="cite">On Dec 8, 2025, at 7:47 AM, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="Generator" content="Microsoft Word 15 (filtered medium)"><style>@font-face { font-family: "Cambria Math"; }
@font-face { font-family: Aptos; }
p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif; }
a:link, span.MsoHyperlink { color: blue; text-decoration: underline; }
span.EmailStyle18 { font-family: Aptos, sans-serif; color: windowtext; }
.MsoChpDefault { font-size: 11pt; }
@page WordSection1 { size: 8.5in 11in; margin: 1in; }
div.WordSection1 { page: WordSection1; }</style><div class="WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">TIP 739: Yes<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p><p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p><div><div><p class="MsoNormal" style="margin-left:.5in">On Fri, Dec 5, 2025 at 11:16<span style="font-family:"Arial",sans-serif"> </span>AM Csaba Nemethi <<a href="mailto:csa...@t-...">csa...@t-...</a>> wrote:<o:p></o:p></p></div><blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><p class="MsoNormal" style="margin-left:.5in">Attn. TCT members,<br><br>This is a CFV for TIP 739: Add a Wide.TSpinbox style to the core.<br><br> <a href="https://core.tcl-lang.org/tips/doc/trunk/tip/739.md" target="_blank">https://core.tcl-lang.org/tips/doc/trunk/tip/739.md</a><br><br>The TIP is kindly sponsored by Harald. Many thanks, Harald!<br><br>Please send your votes to this list until Monday, 2025-12-15 20:00 UTC.<br><br>Best regards,<br><br>Csaba<br><br>-- <br>Csaba Nemethi <a href="https://www.nemethi.de" target="_blank">https://www.nemethi.de</a> mailto:<a href="mailto:csa...@t-..." target="_blank">csa...@t-...</a><br><br><br><br>_______________________________________________<br>Tcl-Core mailing list<br><a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a><br><a href="https://lists.sourceforge.net/lists/listinfo/tcl-core" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><o:p></o:p></p></blockquote></div></div><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> |
|
From: <apn...@ya...> - 2025-12-08 12:56:24
|
Sergey,
I ran your performance benchmark code below (I’ve preserved it as a generally useful benchmark) comparing trunk with TIP 626 and see no measurable difference at all. Your point is noted but I believe it has more to do with the int->Tcl_Size(64bit) change than TIP 626. That change is not something that can be reverted (not that we would want to).
/Ashok
From: Dipl. Ing. Sergey G. Brester via Tcl-Core <tcl...@li...>
…stuff deleted…
The impact on memory usage (by replacing int32 with int64) is not interesting per se (as I said the memory is cheap), but must be considered in conjunction with CPU cache/granularity/coherence, rather as possible cause for performance deterioration.
The issue with the performance is obvious without to measure something:
* the usage of extra layer (cmdWrapperProc) would make it already slower directly. How can it be otherwise if still one function gets involved per invocation of any command (invokeStk instructions and co)?
* the few extra bytes in tcls internal structures wouldn't show it direct with simple measurements, but would surely play a role, because CPU cache is not endless and every single byte (added en masse), can cause more washouts, cache invalidations, etc.
And if in case of L3 it is not so grave, in case of L1 or L2 we'd speak about factor 100x (0.33ns L1- vs. 33.33ns MEM-access)
* the measurement would be complex, but as already mentioned - totally unneeded, because it's basically obvious.
However if you really want - here is even though artificial construct, but it can illustrate the regression:
timerate -calibrate {};
proc test k {
upvar cmd cmd body body
if {![info exists cmd($k)]} {
# just a lot of procs with dummy bodies (if called with 0):
set pbody [string repeat "if {\$a} {" 100][string repeat "}" 100]
set i 0; while {$i<=$k} {
proc [set cmd($i) test$i] {a args} $pbody
incr i
}
# reorder it additionally to array hash buckets arbitrary but deterministic,
# (so they are "random" in the same way - able to use it in different shells):
set i 0; set s $k; set seed 16807; while {$i<=$k/2} {
set seed [expr {($i + $seed / (1 + $s<<3) + 2**($i % 64) * 3**($seed % 39) % 0x17A311E02F4623 + 1) % $k}]
set s [expr {$seed % $k}]
set p [lindex $cmd($i)]; set cmd($i) $cmd($s); set cmd($s) $p; incr i
}
}
# body calling all the procs at once (in specific "random" order, targeting different mem-blocks):
if {![info exists body($k)]} {
set body(k) {}
set i 0; while {$i<=$k} { append body(k) "$cmd($i) 0 0 0 0 0; "; incr i }
timerate $body(k) 100; # warm-up this body
}
timerate $body(k) 5000; # measure 5 seconds
}
green - 9.1 without TIPs 627/626 & no 64-bit counters in Command- and other structs (Tcl_Size <-> int),
red - 9.1 with TIPs 627/626 & 64-bit counters
% test 10000
+ 7488.61 µs/# 667 # 133.54 #/sec 4994.904 net-ms
- 9769.15 µs/# 511 # 102.36 #/sec 4992.038 net-ms
% test 1000
+ 362.284 µs/# 13800 # 2760.3 #/sec 4999.517 net-ms
- 415.089 µs/# 12044 # 2409.1 #/sec 4999.330 net-ms
% test 100
+ 29.7158 µs/# 168078 # 33652.2 #/sec 4994.565 net-ms
- 31.1066 µs/# 160574 # 32147.6 #/sec 4994.904 net-ms
…more stuff deleted…
|
|
From: Donal F. <don...@ma...> - 2025-12-08 12:50:31
|
I'm so tempted to suggest we add an undocumented clock cuckoo command to control whether the Tcl interpreter plays sounds every hour on the hour. Maybe that's something to write a TIP for next April... Donal. ________________________________ From: Harald Oehlmann <har...@el...> Sent: Friday, December 05, 2025 15:02 To: Marc Culler <cul...@gm...> Cc: tcl...@li... <tcl...@li...> Subject: Re: [TCLCORE] TIP-723 "timer" ready for review For my German perception, "Wall clock" sounds a bit like a very historic device like a "cuckoo clock". |
|
From: <apn...@ya...> - 2025-12-08 12:46:46
|
TIP 739: Yes
On Fri, Dec 5, 2025 at 11:16 AM Csaba Nemethi <csa...@t-... <mailto:csa...@t-...> > wrote:
Attn. TCT members,
This is a CFV for TIP 739: Add a Wide.TSpinbox style to the core.
https://core.tcl-lang.org/tips/doc/trunk/tip/739.md
The TIP is kindly sponsored by Harald. Many thanks, Harald!
Please send your votes to this list until Monday, 2025-12-15 20:00 UTC.
Best regards,
Csaba
--
Csaba Nemethi https://www.nemethi.de mailto:csa...@t-... <mailto:csa...@t-...>
_______________________________________________
Tcl-Core mailing list
Tcl...@li... <mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core
|
|
From: Harald O. <har...@el...> - 2025-12-08 12:07:46
|
TIP 723 is from my side in the final testing state: % clock microseconds ?-wallclock|-monotonic? % timer info $id cmd wallclock 12345 cmd monotonic 45678is in the repository and TIP. clock.test core dumps for me with stack error. Investigation eventually tomorrow, sorry for this. Anybody invited to modify my low engineering level work. Thanks for any modification ! Harald |
|
From: <apn...@ya...> - 2025-12-08 11:04:21
|
Jan,
I already said, more than once (including in the mail you quoted), that it will be up to someone else who thinks clean up is important enough to request a vote on 741. I also said in that same mail that " The only reason I proposed 741 was because Jan put forth CFV for 709 and one of the arguments he made was no alternative was available.". So, you're pretty much repeating what I already stated.
And as far as being a "game" (whatever that means), I specifically pointed out the actual problems, not easily solvable and not conjecture or "future issues", in your implementation. Something you have not bothered to address at all, either by fixing them or making a case for it's acceptable for Win32 API's to fail in 709 loaded DLL's. Instead, you still think 709 is a solution despite those failures!
And just for the record, for those who are not clear on this, writing of files to disk is not a 741 thing. It already exists in 9.0. 741 only proposes clean up.
/Ashok
-----Original Message-----
From: Jan Nijtmans <jan...@gm...>
Sent: Monday, December 8, 2025 2:46 PM
To: tcl...@li...
Subject: Re: [TCLCORE] Announce: TIP 741: Cleanup of temporary Windows DLL's loaded from zipfs archives
Op vr 5 dec 2025 om 12:09 schreef Ashok:
>Depending on what happens with 709, I won’t even bring 741 to a vote unless someone else feels the cleanup is an issue important enough to solve.
I fear that - if you bring up the vote - people will think this is an
urgent issue to
solve. It isn't. The effect - if 741 is accepted - will be that people
either are forced
even more to link in statically their extension (which they should do anyway, if
possible, so that's a good thing). The other effect will be that people move to
a forked version of Tcl, which works as expected. That's what Christian Werner
is doing. Do we really want that to happen? I don't.
I see TIP #741 as part of a game, with the sole intention of ranting
the TIP #709
implementation. Not as a serious solution which _should_ be in the core.
Sergey wrote:
> But if we speak about deletion, I'd do that in totally different way, like start special deletion child, wait there for parent process end, and only then delete them.
> Better alternative could be a reusable DLL - so creation of DLL in common temporary directory (in cross process mutex) on demand, so it'd be available for all processes of the same version/build-id and don't delete them > at all on exit. That would be a much more sane and faster solution than recreating and deleting DLLs per process every time they start.
That would be my third-best solution (after statically linking and TIP #709)
Let's see what happens.
Regards,
Jan Nijtmans
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core
|
|
From: <apn...@ya...> - 2025-12-08 10:28:11
|
Ho Torsten, Please go ahead and do what you deem necessary in terms of content and file naming. I thought I did check both the manpage and HTML generation on trunk but perhaps I was mistaken. /Ashok -----Original Message----- From: Torsten Berg <be...@ty...> Sent: Monday, December 8, 2025 12:31 PM To: tcl...@li... Subject: [TCLCORE] New "Unicode" manual page for Tcl 9.1 Hi Ashok, the manual page of the new "unicode" command now landed in the tip-700 branch and threw errors. I would update the nroff in trunk and add the closing "?" for the optional "-profile" option, if that is OK for you. Also, I would like to rename the nroff file to start with a lower case letter. This is how all other files in the n section are spelled (only section 3 uses upper case (with the exception of Tcl.n)). OK? Regards, Torsten _______________________________________________ Tcl-Core mailing list Tcl...@li... https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Steve L. <st...@di...> - 2025-12-08 10:07:45
|
The next meetup will be on Tuesday 9 December 2025 at [clock format 1765270800] - Tuesday 1am US West, 3am US Central, 4am US East, 9am UTC, 9am UK, 10am Western Europe, 2:30pm India, 5pm Australia West / Singapore / China, 6pm Japan, 8pm Australia East, 10pm New Zealand. Details (including how to connect) are available via https://wiki.tcl-lang.org/page/Monthly+Virtual+Meetup -- Steve |
|
From: Jan N. <jan...@gm...> - 2025-12-08 09:16:23
|
Op vr 5 dec 2025 om 12:09 schreef Ashok:
>Depending on what happens with 709, I won’t even bring 741 to a vote unless someone else feels the cleanup is an issue important enough to solve.
I fear that - if you bring up the vote - people will think this is an
urgent issue to
solve. It isn't. The effect - if 741 is accepted - will be that people
either are forced
even more to link in statically their extension (which they should do anyway, if
possible, so that's a good thing). The other effect will be that people move to
a forked version of Tcl, which works as expected. That's what Christian Werner
is doing. Do we really want that to happen? I don't.
I see TIP #741 as part of a game, with the sole intention of ranting
the TIP #709
implementation. Not as a serious solution which _should_ be in the core.
Sergey wrote:
> But if we speak about deletion, I'd do that in totally different way, like start special deletion child, wait there for parent process end, and only then delete them.
> Better alternative could be a reusable DLL - so creation of DLL in common temporary directory (in cross process mutex) on demand, so it'd be available for all processes of the same version/build-id and don't delete them > at all on exit. That would be a much more sane and faster solution than recreating and deleting DLLs per process every time they start.
That would be my third-best solution (after statically linking and TIP #709)
Let's see what happens.
Regards,
Jan Nijtmans
|
|
From: Harald O. <har...@el...> - 2025-12-08 09:05:50
|
Am 05.12.2025 um 16:56 schrieb Harald Oehlmann: > Am 05.12.2025 um 16:38 schrieb Dipl. Ing. Sergey G. Brester: >> I would try to review the TIP and its implementation much closer and/ >> or check whether one can take best from both. Sergey, all, I will now start a train ride and work on the following points: > clock microseconds ?-wallclock|-monotonic? > > timer info $id > cmd wallclock 12345 > cmd monotonic 45678 Commit tomorrow morning, if successful. Then, I will not modify any more and you may change anything. THanks for ALL, Harald |
|
From: Torsten B. <be...@ty...> - 2025-12-08 07:01:53
|
Hi Ashok, the manual page of the new "unicode" command now landed in the tip-700 branch and threw errors. I would update the nroff in trunk and add the closing "?" for the optional "-profile" option, if that is OK for you. Also, I would like to rename the nroff file to start with a lower case letter. This is how all other files in the n section are spelled (only section 3 uses upper case (with the exception of Tcl.n)). OK? Regards, Torsten |
|
From: Steve L. <st...@di...> - 2025-12-08 00:53:04
|
It is with fear and trepidation I wade into this morass ... but nevertheless here I go. I am not an active Windows developer, let alone expert. However I do deploy on Windows and in that environment being able to deliver applications as a single file executable (i.e. a Starpack) including dependent DLLs has a lot of value. In fact I have applications deployed this way over two decades ago and they still work with zero maintenance load. So I see the value, however it has always been a problem with Starkits / packs on Windows that those DLLs are copied to temporary storage and may not be cleaned up. And that has become worse with 9.0 and zipfs in the core. On the other hand I am also acutely aware of the problems with both proposals. It is all very well saying dynamic or static linking is much better (even though it is) because not everyone is in a position to build on Windows and the ability to generate self-contained single file executables without compiling and linking is a real and significant benefit for many. This is not to devalue anyone's opinions one way or the other but we have a need and we have two proposals (each with its own pros and cons). To me the worst outcome would be to do nothing. So in the absence of a better proposal I favour the suboptimal solution with least surprises. To me that is TIP 741 (Ashok) not TIP 709 (Jan) and I will be voting accordingly. -- Steve On 5 Dec 2025 at 7:09 PM +0800, apnmbx-public--- via Tcl-Core <tcl...@li...>, wrote: > Sergey, see inline below. > Free of risks?! > Start of foreign executable on exit of tcl-process (or on invocation of Tcl_Finalize()) for clean-up purposes?!.. using command processor?!.. with timeout and rmdir?! > > I presume you are objecting to execing a shell for security reasons? I am not a big fan of exec’ing programs either but from a security perspective, consider that these risks come from > 1. Exec’ing an unknown program (or unqualified) > 2. Exec’ing a known program that is not protected and therefore susceptible to being overwritten by trojans > 3. Passing potentially dangerous arguments from unknown sources (user, script etc.) > In the case of TIP 741, the programs are specifically from the Windows system directory. So 1. does not apply. The Windows directory is protected and if compromised, I’m afraid the system is already gonzo and TIP 741 behaviour is completely irrelevant! So 2. matters not. > That leaves 3. The arguments passed via exec are completely static (constant) except for the full path to the temp dll directory. This path is a NEW directory generated and created within Tcl, not exposed at the script level and not based on any user input for the final directory component. If the path is modified by malware executing within the process, the process is already compromised, the malware does not need this mechanism to wipe out the disk! > So I am not sure what attack vector you are thinking of. > > Do you really think this is better solution?! (Regardless how one consider TIP 709) > Yes. Better. Much better. No undocumented API’s, minimal code. > > Offhand, possible RC (too short timeout)? possible unexpected sharing of handles by child clean-up process (and too long timeout)? antivirus issues? etc pp. > Worst case issue with short timeout (3s should be generally enough, making it 10s does no harm) is that the directory does not get cleaned up. Big deal. Too long timeout? Directory gets cleaned up after a longer delay than necessary. Again, big deal. > The case of AV, I don’t think 741 adds any *additional* risk. The issue with tclkits in 8.6 and potentially zipkits in 9.0 was that some AV would see the sequence of steps writing a DLL to disk and immediately loading it as asymptomatic of malware downloading a remote DLL. I have not seen AV trigger on this recently on tclkits, maybe they have better heuristics or malware is now directly loading DLL’s from memory a la 709! In any case, this action is not something new with 741. The only additional step that 741 does is start a cmd.exe to cleanup. Is that additional trigger for AV? I cannot say for sure except I’ll point out cmd and shells are exec’ed all the time by applications ranging from editors and development tools to NMS systems. > Don't get me wrong, I don't like both solutions. I think dynamic or static link on compilation phase is much better than any attempt to put DLLs into tcl_library. > I don’t think anyone is debating this point, certainly not me. The issue originally came up because the 9.0 betas were cluttering temp files with the registry and dde dll’s every time tclsh/wish ran. Since those were removed from zipfs, the issue has much less importance. The remaining use case is for users who cannot build for one reason or another. I don’t myself see this case as hugely important. The only reason I proposed 741 was because Jan put forth CFV for 709 and one of the arguments he made was no alternative was available. Depending on what happens with 709, I won’t even bring 741 to a vote unless someone else feels the cleanup is an issue important enough to solve. > But if we speak about deletion, I'd do that in totally different way, like start special deletion child, wait there for parent process end, and only then delete them. > Better alternative could be a reusable DLL - so creation of DLL in common temporary directory (in cross process mutex) on demand, so it'd be available for all processes of the same version/build-id and don't delete them at all on exit. That would be a much more sane and faster solution than recreating and deleting DLLs per process every time they start. > Regards, > Serg. > I don’t necessarily disagree but it’s hard to comment or compare without a concrete implementation. Just like 709 would be a good idea until implementation reveals issues. Why wouldn’t the (first time) write-and-read dll trigger AV just like the current implementation, etc. > Tx > /Ashok > 03.12.2025 13:39, apnmbx-public--- via Tcl-Core wrote: > > quote_type > > TIP 741: Cleanup of temporary Windows DLL’s loaded from zipfs archives is ready for review. > > Both the TIP specification and implementation are very simple and should not need much time for review. There are no changes to the public API at either the C or script level. > > This is a direct alternative to TIP 709 and therefore I will be calling a vote at the same time as the CFV for 709. > > I will add a section detailing this TIP vs 709 later today or tomorrow but TL;DR .. it does not make sense in my estimation to use a third-party library that has been abandoned since 2018, is based on reverse engineered, complex and undocumented interfaces in Windows that are subject to change, when the simpler mechanism in 741 free of the complexity and risks associated with the former is available. > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Steve L. <st...@di...> - 2025-12-08 00:41:51
|
TIP #626: YES -- Steve On 3 Dec 2025 at 5:56 PM +0800, Jan Nijtmans <jan...@gm...>, wrote: > Attn. TCT members, > > This is a CFV for TIP 626: > https://core.tcl-lang.org/tips/doc/trunk/tip/626.md > > Please send your votes to this list until Friday, Dec 12, 12:00 gmt, > or [clock format 1765540800] > > Best regards, > Jan Nijtmans > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: Steve L. <st...@di...> - 2025-12-08 00:41:14
|
TIP #709: NO -- Steve On 4 Dec 2025 at 4:39 PM +0800, Jan Nijtmans <jan...@gm...>, wrote: > Attn. TCT members, > > This is a CFV for TIP 709: > https://core.tcl-lang.org/tips/doc/trunk/tip/709.md > > I'm aware of TIP #741, and Ashoks desire to vote on it > together with this TIP. However, I don't think TIP #741 is > going anywhere, but i'll leave that up to Ashok to handle it. > > I also agree with Sergey's remark that "dynamic or static link > on compilation phase is much better than any attempt to put > DLLs into tcl_library". This TIP is meant for use-cases where > you cannot do that. Christian Werner's LUCK framework > is one of those. > > Please send your votes to this list until Friday, Dec 19, 12:00 gmt, > or [clock format 1766145600] > > Best regards, > Jan Nijtmans > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: Steve L. <st...@di...> - 2025-12-08 00:39:25
|
TIP #739: YES -- Steve On 6 Dec 2025 at 1:16 AM +0800, Csaba Nemethi <csa...@t-...>, wrote: > Attn. TCT members, > > This is a CFV for TIP 739: Add a Wide.TSpinbox style to the core. > > https://core.tcl-lang.org/tips/doc/trunk/tip/739.md > > The TIP is kindly sponsored by Harald. Many thanks, Harald! > > Please send your votes to this list until Monday, 2025-12-15 20:00 UTC. > > Best regards, > > Csaba > > -- > Csaba Nemethi https://www.nemethi.de mailto:csa...@t-... > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: Marc C. <cul...@gm...> - 2025-12-08 00:19:57
|
Eric, I fixed your fork by moving your work to a branch named tip_742. I think that is probably what you had intended to do. Please pull and update to that branch before continuing. - Marc On Sun, Dec 7, 2025 at 6:11 PM Marc Culler <cul...@gm...> wrote: > Eric, > > You created a fork in the main branch when you merged the code for TIP > #742. Please close it. > > - Marc > > On Fri, Dec 5, 2025 at 2:10 PM EricT <tw...@gm...> wrote: > >> Harald, >> >> Thanks for sponsoring the TIP 742. >> >> I've created a local implementation branch for TIP #742 (Add Mouse Wheel >> Zoom Support to Tk Console), but I don't have write access to push it to >> the core repository. >> >> Attached is the patch file with the implementation. The changes are >> minimal - just adding a Control+MouseWheel binding to library/console.tcl >> that generates the existing <<Console_FontSizeIncr>> and >> <<Console_FontSizeDecr>> virtual events. >> >> Could someone with write access please create the implementation branch >> tip-742-mousewheel-zoom and apply this patch? >> >> >> Regards, the console freezing. Yes, it is a definite no-no to create very >> long lines, as for example, [string repeat xyz 25000] will pretty much >> kill the console. However, this is not very common for debugging output. In >> that case, when I would output quite a bit of text, from say a trace, the >> console killer then would be when the text widget would try to do the "see" >> operation on each line to position to the end of the text widget. >> >> This I avoid by only doing a single "see" every 100 ms or so. Then in >> that context, I have good performance. But it only addresses the one >> problem where I'm doing thousands of relatively short lines (100 chars or >> less per line). >> >> I would consider this more of a hack, not a real solution to address >> console performance. >> >> Thanks >> Eric >> >> >> On Fri, Dec 5, 2025 at 2:04 AM Harald Oehlmann < >> har...@el...> wrote: >> >>> Eric has authored this TIP: >>> >>> https://core.tcl-lang.org/tips/doc/trunk/tip/742.md >>> >>> I think, this is a good idea. >>> Is the unix console ready? Any action there? >>> >>> Eric, I sponsor your TIP. >>> Can you make an implementation branch and a call for discussion, then >>> vote? >>> >>> There was the discussion on the revised text widget on c.l.t. The >>> console uses the text widget. >>> You had a contribution there. >>> >>> What I see with the console: >>> - lots of content with very long lines. >>> - You resize the widget or scale the font >>> - The widget freezes as the line break algorithm has to run. To my >>> knowledge, this is very fast with the revised text widget. >>> >>> You had a proposal on c.l.t. Perhaps, this may also be added here. >>> >>> Thanks, >>> Harald >>> >>> _______________________________________________ >>> Tcl-Core mailing list >>> Tcl...@li... >>> https://lists.sourceforge.net/lists/listinfo/tcl-core >>> >> _______________________________________________ >> Tcl-Core mailing list >> Tcl...@li... >> https://lists.sourceforge.net/lists/listinfo/tcl-core >> > |
|
From: Marc C. <cul...@gm...> - 2025-12-08 00:11:52
|
Eric, You created a fork in the main branch when you merged the code for TIP #742. Please close it. - Marc On Fri, Dec 5, 2025 at 2:10 PM EricT <tw...@gm...> wrote: > Harald, > > Thanks for sponsoring the TIP 742. > > I've created a local implementation branch for TIP #742 (Add Mouse Wheel > Zoom Support to Tk Console), but I don't have write access to push it to > the core repository. > > Attached is the patch file with the implementation. The changes are > minimal - just adding a Control+MouseWheel binding to library/console.tcl > that generates the existing <<Console_FontSizeIncr>> and > <<Console_FontSizeDecr>> virtual events. > > Could someone with write access please create the implementation branch > tip-742-mousewheel-zoom and apply this patch? > > > Regards, the console freezing. Yes, it is a definite no-no to create very > long lines, as for example, [string repeat xyz 25000] will pretty much > kill the console. However, this is not very common for debugging output. In > that case, when I would output quite a bit of text, from say a trace, the > console killer then would be when the text widget would try to do the "see" > operation on each line to position to the end of the text widget. > > This I avoid by only doing a single "see" every 100 ms or so. Then in that > context, I have good performance. But it only addresses the one problem > where I'm doing thousands of relatively short lines (100 chars or less per > line). > > I would consider this more of a hack, not a real solution to address > console performance. > > Thanks > Eric > > > On Fri, Dec 5, 2025 at 2:04 AM Harald Oehlmann < > har...@el...> wrote: > >> Eric has authored this TIP: >> >> https://core.tcl-lang.org/tips/doc/trunk/tip/742.md >> >> I think, this is a good idea. >> Is the unix console ready? Any action there? >> >> Eric, I sponsor your TIP. >> Can you make an implementation branch and a call for discussion, then >> vote? >> >> There was the discussion on the revised text widget on c.l.t. The >> console uses the text widget. >> You had a contribution there. >> >> What I see with the console: >> - lots of content with very long lines. >> - You resize the widget or scale the font >> - The widget freezes as the line break algorithm has to run. To my >> knowledge, this is very fast with the revised text widget. >> >> You had a proposal on c.l.t. Perhaps, this may also be added here. >> >> Thanks, >> Harald >> >> _______________________________________________ >> Tcl-Core mailing list >> Tcl...@li... >> https://lists.sourceforge.net/lists/listinfo/tcl-core >> > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: Brian O'H. <bri...@co...> - 2025-12-07 23:12:10
|
It''s good to hear you haven't had any crashes. It's been stable for me too.
I incorporated the disabled state changes. The existing bindings only
used -selectmode none instead of the disabled state. So to properly use
the disabled state will take some work. For #2, I incorporated it but
changed it to check if the font exists and if not then create it. For
#3, I went with the 4 pixel wide version. It can always be changed
later. Thanks for the help getting this in shape.
Something else you may want to look at is the zoom function seems to
trigger adding extra ns padding to the entry-type widgets, but doesn't
always remove it when its set back to 100%. Either that or the text is
drawn at the wrong offset so it's shifted up or down (ie at top or
bottom of entry-area instead centered) and sometimes cut-off. It's most
noticeable in the status message area, but others do it occasionally
too. Also the character positions don't line up with the font characters
while zoomed. You can see it by selecting text in the entry or by moving
the cursor to the end. Hopefully it's just me and not a larger issue.
On 12/7/25 1:00 PM, Csaba Nemethi wrote:
> Hi Brian,
>
> First off a good news: I haven't experienced any crashes for several
> days!
>
> A few further improvement proposals:
>
> 1. In the disabled state the checkbutton indicators of the
> CheckTreeview style should have different colors, just like the
> ttk::checkbutton indicators. Please find attached the "diff -u"
> outputs showing the necessary changes in three files contained in the
> folder library/ttk.
>
> Apropos disabled state: In this state several interactive operations
> (e.g., changing the selection) should be disabled.
>
> 2. Line #647 of the file library/demos/treeview.tcl should be enclosed
> in "catch {...}", to enable a clean restart of the enhanced treeview
> demo.
>
> 3. For consistency, line #785 of the file library/demos/treeview.tcl
> should read
>
> <svg width="16" height="8" version="1.1"
> xmlns="http://www.w3.org/2000/svg">
>
> Or, if the arrowBlank image shall only create a *small* gap between
> the text and the right edge of the heading:
>
> <svg width="4" height="8" version="1.1"
> xmlns="http://www.w3.org/2000/svg">
>
> I am not sure which variant is better.
>
> Best regards,
>
> Csaba
>
>
> Am 06.12.25 um 23:51 schrieb Brian O'Hagan:
>> Thanks. I've incorporated #1 and #3. The sort arrows are much nicer now.
>>
>> For #2, no it's not intentional but instead a side effect of the
>> button states. The Check and Radio buttons use the alternate state to
>> denote the no value (aka tri-state or no on/off value is defined)
>> state. Since we don't set a value (we only use the selection state),
>> then all items get the alternate state. The current logic in
>> ttkButton.c (see CheckbuttonVariableChanged) doesn't allow a bypass
>> for this without setting an on/off value or defining a variable. It's
>> open work to see if there is another option.
>
> |
|
From: Csaba N. <csa...@t-...> - 2025-12-07 19:00:44
|
Hi Brian,
First off a good news: I haven't experienced any crashes for several days!
A few further improvement proposals:
1. In the disabled state the checkbutton indicators of the CheckTreeview
style should have different colors, just like the ttk::checkbutton
indicators. Please find attached the "diff -u" outputs showing the
necessary changes in three files contained in the folder library/ttk.
Apropos disabled state: In this state several interactive operations
(e.g., changing the selection) should be disabled.
2. Line #647 of the file library/demos/treeview.tcl should be enclosed
in "catch {...}", to enable a clean restart of the enhanced treeview demo.
3. For consistency, line #785 of the file library/demos/treeview.tcl
should read
<svg width="16" height="8" version="1.1"
xmlns="http://www.w3.org/2000/svg">
Or, if the arrowBlank image shall only create a *small* gap between the
text and the right edge of the heading:
<svg width="4" height="8" version="1.1"
xmlns="http://www.w3.org/2000/svg">
I am not sure which variant is better.
Best regards,
Csaba
Am 06.12.25 um 23:51 schrieb Brian O'Hagan:
> Thanks. I've incorporated #1 and #3. The sort arrows are much nicer now.
>
> For #2, no it's not intentional but instead a side effect of the button
> states. The Check and Radio buttons use the alternate state to denote
> the no value (aka tri-state or no on/off value is defined) state. Since
> we don't set a value (we only use the selection state), then all items
> get the alternate state. The current logic in ttkButton.c (see
> CheckbuttonVariableChanged) doesn't allow a bypass for this without
> setting an on/off value or defining a variable. It's open work to see if
> there is another option.
--
Csaba Nemethi https://www.nemethi.de mailto:csa...@t-...
|
|
From: Colin M. <col...@ya...> - 2025-12-07 14:14:58
|
P.S. You also say that `=` doesn't support "usage of functions". It does
support all the same mathfunc functions as `expr`. Perhaps you meant
command substitutions? If so, these can also be used, and can even be
compiled efficiently as long as they are separated by spaces from the
rest of the expression. :-/
On 07/12/2025 09:47, Colin Macleod via Tcl-Core wrote:
>
> Hi Sergey,
>
> Yes I think you are right to call my proposal a workaround. The Tcl
> community has spent many years trying to find an ideal solution to the
> awkwardness of `expr` with no result. The point of `=` is that it's
> just one command, with no impact on anything else. If you don't like
> it you can just not use it. This is in contrast to all the proposals
> which involve changing the dodekalogue rules, which have much
> further-reaching impact.
>
> Yes `=` does not support everything `expr` does, this is a deliberate
> trade-off to allow simple calculations to be written simply.
>
> You say *[= a < "b"]* is confusing, but one can already write *set "b"
> aaa* - I wouldn't say this means the `set` command is confusing.
>
> I don't really understand why you say that the compilation "quasi
> forces the devs to write not effective code". Simple cases compile to
> code that runs as fast as `expr`. Of course `expr` is still available
> for complex cases.
>
> Best regards,
> Colin.
>
> On 07/12/2025 01:11, Dipl. Ing. Sergey G. Brester wrote:
>>
>> My pleasure...
>>
>> The issue with "don't like" is - it is not tclish enough to me.
>> Or rather it is a bit strange sugar in my opinion, because:
>>
>> * it doesn't support many things what expression does, like
>> comparison with strings/literals or usage of functions;
>> * does weird subst of literal parameters as variables without
>> dollar at every offset (commands like set, (l)append etc, do that
>> with single variable only, and it is absolutely justified);
>> * therefore confusing or else wrong interpreting of the tcl code by
>> reading, for instance what happens here?
>> [= a < "b"]
>> or rather although "b" and b are the same literals in tcl, it is
>> completely weird here to handle "b" as variable name IMHO (I know
>> why, but it is confusing for reading);
>> * or even here (double subst of var, but if $b "resolves" a
>> literal, not number, otherwise not at all)?
>> [= a < $b]
>> * all of this objectively makes this sugar in context of TCL to
>> Malbolge (esoteric programming language that humans hardly
>> understand);
>> * the way how it is compiled (and it cannot be compiled differently
>> and optimal) quasi forces the devs to write not effective code;
>> * etc (I can continue here with further arguments).
>>
>> As already said, I am also for some sugar to simplify [expr {...}]
>> writing, but it must be well thought-out, clearly discernible as such
>> and ideally parse-able in that form at level of tcl-parser.
>> Even if basic rules of tcl-parser get modified for that purposes, e.
>> g. like it was done with args expansion {*}.
>> All the attempts I've seen so far looked more like a workaround to
>> me, sorry guys.
>>
>> Regards,
>> Serg.
>>
>> 06.12.2025 13:43, Colin Macleod wrote:
>>
>>> Hello All,
>>>
>>> I have now fixed this crash and updated the patch file. I had
>>> assumed that if EnvHasLVT() was true then AnonymousLocal() would
>>> always succeed, which is not the case. Thanks very much to Sergey
>>> for picking this up, even though he doesn't like the proposal.
>>>
>>> Colin.
>>>
>>> On 05/12/2025 18:17, Colin Macleod via Tcl-Core wrote:
>>>>
>>>> Hi Sergey,
>>>>
>>>> Thanks very much for this report. I'll dig into it tomorrow.
>>>>
>>>> Colin.
>>>>
>>>> On 05/12/2025 15:09, Dipl. Ing. Sergey G. Brester wrote:
>>>>>
>>>>> I already said everything I want about the proposal.
>>>>> And I still don't think it'd be good idea at all to introduce such
>>>>> sugar without to modify tcl parser
>>>>> (e. g. to behave different on certain things like it was with args
>>>>> expansion {*}, or without to consider [= ...] as an expression
>>>>> without braces or something similar).
>>>>> But...
>>>>>
>>>>> Just to point to an issue in case of compilation like concat with
>>>>> invokeStk for [=] at end:
>>>>> neither it looks like good idea to me, nor it is safe, because
>>>>> could segfault in certain constellations.
>>>>>
>>>>> Simplified PoC (thereby it is irrelevant what [] contains, it'd be
>>>>> anything else, e. g. [set s], and used here to avoid pure literal
>>>>> compilation):
>>>>>
>>>>> % proc test {} { set s 0; timerate { = s + [] } }; test
>>>>>
>>>>> Thread 1 received signal SIGSEGV, Segmentation fault.
>>>>> 0x00007ff9e48120f8 in FollowLinks (varPtr=0x100074a210) at
>>>>> ./generic/tclExecute.c:2067
>>>>> 2067 while (TclIsVarLink(varPtr)) {
>>>>> (gdb) where
>>>>> #0 0x00007ff9e48120f8 in FollowLinks (varPtr=0x100074a210) at
>>>>> ./generic/tclExecute.c:2067
>>>>> #1 0x00007ff9e48170da in TEBCresume (data=0x798178,
>>>>> interp=0x7460c0, result=0) at ./generic/tclExecute.c:3340
>>>>> #2 0x00007ff9e4775f15 in TclNRRunCallbacks (interp=0x7460c0,
>>>>> result=0, rootPtr=0x797270) at ./generic/tclBasic.c:4668
>>>>> #3 0x00007ff9e47b4c60 in Tcl_TimeRateObjCmd (dummy4169=0x0,
>>>>> interp=0x7460c0, objc=2, objv=0x74a2b0) at ./generic/tclCmdMZ.c:4453
>>>>> #...
>>>>>
>>>>> It is surely TEBC, because It'd work as expected if would fallback
>>>>> to direct invocation (variable `s` doesn't compiled in the frame yet):
>>>>>
>>>>> % proc test {} { timerate { = s + [] } }; test
>>>>> = Expected start of expression but found ''
>>>>>
>>>>> Regards,
>>>>> Serg.
>>>>>
>>>>> Am 03.12.2025 16:49, schrieb Colin Macleod via Tcl-Core:
>>>>>
>>>>> Hi again,
>>>>>
>>>>> I decided to treat "NaN", "Inf" & "Infinity" (any
>>>>> capitalisation) as variable names, eliminating that special
>>>>> case. Does anyone actually write expressions, other than test
>>>>> cases, using these values? If so they will need to stick to
>>>>> `expr`. I have updated the code, tests and man page to
>>>>> reflect this, and updated the patch at
>>>>> https://cmacleod.me.uk/tcl/tip676.patch.txt.
>>>>>
>>>>> I have also added an equals.test file of tests. Some of these
>>>>> I have adapted from the existing tests for `expr`, but more
>>>>> than half were contributed by Eric, which is extremely helpful.
>>>>>
>>>>> I now need to update the TIP to match the implementation.
>>>>> Once that is done I think it will be ready for formal
>>>>> consideration.
>>>>>
>>>>> Colin.
>>>>>
>>>>> On 02/12/2025 17:10, Colin Macleod wrote:
>>>>>
>>>>> Hi again all,
>>>>>
>>>>> I'm now working on creating tests for the `=` command, by
>>>>> adapting the tests for `expr` which are relevant. This
>>>>> has highlighted a few edge cases which I'm not sure how
>>>>> best to handle, so I would like to ask what other people
>>>>> think.
>>>>>
>>>>> When given a single number as the expression, `expr`
>>>>> always rewrites it to decimal form. At present `=` leaves
>>>>> it unchanged unless it's used in a calculation:
>>>>>
>>>>> % expr 0xff
>>>>> 255
>>>>> % = 0xff
>>>>> 0xff
>>>>> % = 0xff + 0
>>>>> 255
>>>>>
>>>>> So in this case `=` behaves differently from `expr` - I
>>>>> don't think this is really a problem and I would rather
>>>>> not introduce an unnecessary conversion here. Is this
>>>>> acceptable?
>>>>>
>>>>> I'm not allowing the non-numeric representations of
>>>>> boolean values: true, false, yes, no, etc. The `expr`
>>>>> code also accepts any abbreviations of these, doing this
>>>>> in `=` would make it impossible to use variables called t,
>>>>> f, y or n, which I think is unacceptable. However the
>>>>> current `=` does accept Inf and NaN (with any
>>>>> capitalisation, but not abbreviated) as numeric constants,
>>>>> which makes it impossible to use variables with those
>>>>> names. I'm not very happy about this being a special
>>>>> case, so I'm wondering about disallowing those also. If
>>>>> so, someone who really wanted to use such a value in a
>>>>> computation could still do so by assigning it to a
>>>>> variable first and using that variable in the `=` command:
>>>>> *set nan NaN; = nan + 0 *. What do others think?
>>>>>
>>>>> Combining these two issues, we get the following:
>>>>>
>>>>> % expr nan
>>>>> domain error: argument not in valid range
>>>>> % = nan
>>>>> nan
>>>>> % = nan + 0
>>>>> cannot use non-numeric floating-point value "nan" as
>>>>> left operand of "+"
>>>>>
>>>>> Acceptable or not?
>>>>>
>>>>> If anyone would like to experiment, I think the code at
>>>>> https://cmacleod.me.uk/tcl/tip676.patch.txt is now fairly
>>>>> solid. It would be good to get feedback, not just on
>>>>> these specific issues but on the whole approach.
>>>>>
>>>>> Best regards,
>>>>> Colin.
>>>>>
>>>>> On 30/11/2025 12:45, Colin Macleod via Tcl-Core wrote:
>>>>>
>>>>> Hello again,
>>>>>
>>>>> I have updated the patch now, adding a man page for
>>>>> `=` and fixing some bugs which Eric reported. I had to
>>>>> make a little tweak to installManPage to prevent it
>>>>> mangling the name.
>>>>>
>>>>> Colin.
>>>>>
>>>>> On 29/11/2025 13:57, Colin Macleod via Tcl-Core wrote:
>>>>>
>>>>> Hello All,
>>>>>
>>>>> I have now implemented compilation of the case
>>>>> where pre-substitutions are purely numeric,
>>>>> falling back to the non-compiled code where this
>>>>> turns out not to be the case. This added about
>>>>> 100 lines more code. I also added an optimisation
>>>>> for accessing local variables, which Eric pointed
>>>>> out. Both these improvements are only possible
>>>>> when we have a local variable table, which may not
>>>>> be the case for one-off code, but is always the
>>>>> case within a proc. Again the updated code can be
>>>>> found in patch form at
>>>>> https://cmacleod.me.uk/tcl/tip676.patch.txt.
>>>>>
>>>>> Timings of simple expressions:
>>>>>
>>>>> Proc using [expr]:
>>>>>
>>>>> % proc fred1 {a b} {expr {$a*2-$b}}
>>>>> % fred1 4 6
>>>>> 2
>>>>> % timerate {fred1 [incr c] 7}
>>>>> 0.292607 µs/# 3417549 # 3417549 #/sec 1000.000
>>>>> net-ms
>>>>>
>>>>> Same proc using [=]:
>>>>>
>>>>> % proc fred2 {a b} {= a*2-b}
>>>>> % fred2 4 6
>>>>> 2
>>>>> % timerate {fred2 [incr c] 7}
>>>>> 0.291969 µs/# 3425016 # 3425016 #/sec 1000.000
>>>>> net-ms
>>>>>
>>>>> Timings of expressions including an array reference:
>>>>>
>>>>> Proc using [expr]:
>>>>>
>>>>> % array set nums {one 1 two 2 three 3 four IIII}
>>>>> %
>>>>> % proc ada1 name {expr {sin($::nums($name))+1}}
>>>>> % ada1 two
>>>>> 1.9092974268256817
>>>>> % timerate {ada1 three}
>>>>> 0.411508 µs/# 2430088 # 2430088 #/sec 1000.000
>>>>> net-ms
>>>>>
>>>>> Proc using [=], array reference not a separate
>>>>> argument, so compilation fails:
>>>>>
>>>>> % proc ada2 name {= sin($::nums($name))+1}
>>>>> % ada2 two
>>>>> 1.9092974268256817
>>>>> % timerate {ada2 three}
>>>>> 1.346676 µs/# 742569 # 742569 #/sec 1000.000
>>>>> net-ms
>>>>>
>>>>> Proc using [=], array reference is a separate
>>>>> argument, so compilation succeeds:
>>>>>
>>>>> % proc ada2a name {= sin( $::nums($name) )+1}
>>>>> % ada2a two
>>>>> 1.9092974268256817
>>>>> % timerate {ada2a three}
>>>>> 0.468546 µs/# 2134260 # 2134260 #/sec 1000.000
>>>>> net-ms
>>>>>
>>>>> But note of course that [expr] and [=] do not fail
>>>>> in the same way here:
>>>>>
>>>>> % ada1 four
>>>>> expected floating-point number but got "IIII"
>>>>> % ada2 four
>>>>> can't read "IIII": no such variable
>>>>> % ada2a four
>>>>> can't read "IIII": no such variable
>>>>>
>>>>> I think the code is now pretty much complete. I
>>>>> have not worked in the Tcl core before, apart from
>>>>> a few little fixes a very long time ago, so I
>>>>> would be glad if other people could take a look at
>>>>> my code.
>>>>>
>>>>> I still need to create a man page and some tests.
>>>>> Eric has contributed a set of tests but I haven't
>>>>> found time to look at them yet.
>>>>>
>>>>> Colin.
>>>>>
>>>>> On 25/11/2025 03:19, Colin Macleod via Tcl-Core wrote:
>>>>>
>>>>> Thanks Eric,
>>>>>
>>>>> I think it may be possible to take compilation
>>>>> one step further, to handle the common case
>>>>> where pre-substitutions are purely numeric.
>>>>> This would work similarly to the
>>>>> extract_numbers step I added in the Tcl
>>>>> prototype. The compilation step would
>>>>> generate code like:
>>>>>
>>>>> For any pre-substituted words,
>>>>> generate runtime code to check that the
>>>>> actual value is numeric (how?)
>>>>> and stash each value somewhere.
>>>>> If any of these tests fail,
>>>>> branch to code which pushes all the
>>>>> arguments on the stack
>>>>> and invokes the non-compiled `=`
>>>>> implementation.
>>>>> If all tests ok,
>>>>> run the compiled code,
>>>>> which can be generated assuming that the
>>>>> pre-substituted values are numeric,
>>>>> and will pull in the stashed values where
>>>>> the corresponding arguments are required.
>>>>>
>>>>> I'm not sure about the details of this, it may
>>>>> turn out not to be practical.
>>>>>
>>>>> Colin.
>>>>>
>>>>> On 24/11/2025 21:18, EricT wrote:
>>>>>
>>>>> Hi Colin,
>>>>>
>>>>> Congratulations on getting the = command
>>>>> to this level of quality! The compilation
>>>>> optimization is particularly impressive -
>>>>> you've integrated it cleanly into Tcl's
>>>>> proc compilation system.
>>>>>
>>>>> I added a few more proc tests with
>>>>> variable substitutions to round out the
>>>>> test coverage. They all passed. These can
>>>>> be added to the end of calc.test:
>>>>>
>>>>> # ---------- Pre-Substitution in Procs
>>>>> ----------
>>>>>
>>>>> test calc-39.1 {variable substitution in
>>>>> proc} -constraints hasCalcCmd -body {
>>>>> proc test_var_subst {a b} {
>>>>> = $a + $b
>>>>> }
>>>>> test_var_subst 10 20
>>>>> } -result 30 -cleanup {
>>>>> rename test_var_subst {}
>>>>> }
>>>>>
>>>>> test calc-39.2 {mixed literal and
>>>>> substitution} -constraints hasCalcCmd -body {
>>>>> proc test_mixed {n} {
>>>>> = $n * 2 + 5
>>>>> }
>>>>> test_mixed 10
>>>>> } -result 25 -cleanup {
>>>>> rename test_mixed {}
>>>>> }
>>>>>
>>>>> test calc-39.3 {command substitution in
>>>>> proc} -constraints hasCalcCmd -body {
>>>>> proc test_cmd_subst {x} {
>>>>> = [expr {$x * 2}] + 10
>>>>> }
>>>>> test_cmd_subst 5
>>>>> } -result 20 -cleanup {
>>>>> rename test_cmd_subst {}
>>>>> }
>>>>>
>>>>> I also verified an important safety
>>>>> advantage of your implementation - it
>>>>> doesn't suffer from expr's
>>>>> double-evaluation security issue:
>>>>>
>>>>> set xxx {[cd a:/]}
>>>>> expr $xxx + 1
>>>>> # Changes directory! expr evaluates the
>>>>> string as code
>>>>>
>>>>> = $xxx + 1
>>>>> # Error: "Expected start of expression but
>>>>> found '['"
>>>>> # Does NOT execute the command - safer!
>>>>>
>>>>> Your parser treats the value as data, not
>>>>> code, which is the correct behavior.
>>>>>
>>>>> Great work!
>>>>>
>>>>> Best regards,
>>>>> Eric
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Tcl-Core mailing list
>>>>> Tcl...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Tcl-Core mailing list
>>>>> Tcl...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Tcl-Core mailing list
>>>>> Tcl...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Tcl-Core mailing list
>>>> Tcl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Colin M. <col...@ya...> - 2025-12-07 09:47:48
|
Hi Sergey,
Yes I think you are right to call my proposal a workaround. The Tcl
community has spent many years trying to find an ideal solution to the
awkwardness of `expr` with no result. The point of `=` is that it's
just one command, with no impact on anything else. If you don't like it
you can just not use it. This is in contrast to all the proposals which
involve changing the dodekalogue rules, which have much further-reaching
impact.
Yes `=` does not support everything `expr` does, this is a deliberate
trade-off to allow simple calculations to be written simply.
You say *[= a < "b"]* is confusing, but one can already write *set "b"
aaa* - I wouldn't say this means the `set` command is confusing.
I don't really understand why you say that the compilation "quasi forces
the devs to write not effective code". Simple cases compile to code
that runs as fast as `expr`. Of course `expr` is still available for
complex cases.
Best regards,
Colin.
On 07/12/2025 01:11, Dipl. Ing. Sergey G. Brester wrote:
>
> My pleasure...
>
> The issue with "don't like" is - it is not tclish enough to me.
> Or rather it is a bit strange sugar in my opinion, because:
>
> * it doesn't support many things what expression does, like
> comparison with strings/literals or usage of functions;
> * does weird subst of literal parameters as variables without dollar
> at every offset (commands like set, (l)append etc, do that with
> single variable only, and it is absolutely justified);
> * therefore confusing or else wrong interpreting of the tcl code by
> reading, for instance what happens here?
> [= a < "b"]
> or rather although "b" and b are the same literals in tcl, it is
> completely weird here to handle "b" as variable name IMHO (I know
> why, but it is confusing for reading);
> * or even here (double subst of var, but if $b "resolves" a literal,
> not number, otherwise not at all)?
> [= a < $b]
> * all of this objectively makes this sugar in context of TCL to
> Malbolge (esoteric programming language that humans hardly
> understand);
> * the way how it is compiled (and it cannot be compiled differently
> and optimal) quasi forces the devs to write not effective code;
> * etc (I can continue here with further arguments).
>
> As already said, I am also for some sugar to simplify [expr {...}]
> writing, but it must be well thought-out, clearly discernible as such
> and ideally parse-able in that form at level of tcl-parser.
> Even if basic rules of tcl-parser get modified for that purposes, e.
> g. like it was done with args expansion {*}.
> All the attempts I've seen so far looked more like a workaround to me,
> sorry guys.
>
> Regards,
> Serg.
>
> 06.12.2025 13:43, Colin Macleod wrote:
>
>> Hello All,
>>
>> I have now fixed this crash and updated the patch file. I had
>> assumed that if EnvHasLVT() was true then AnonymousLocal() would
>> always succeed, which is not the case. Thanks very much to Sergey
>> for picking this up, even though he doesn't like the proposal.
>>
>> Colin.
>>
>> On 05/12/2025 18:17, Colin Macleod via Tcl-Core wrote:
>>>
>>> Hi Sergey,
>>>
>>> Thanks very much for this report. I'll dig into it tomorrow.
>>>
>>> Colin.
>>>
>>> On 05/12/2025 15:09, Dipl. Ing. Sergey G. Brester wrote:
>>>>
>>>> I already said everything I want about the proposal.
>>>> And I still don't think it'd be good idea at all to introduce such
>>>> sugar without to modify tcl parser
>>>> (e. g. to behave different on certain things like it was with args
>>>> expansion {*}, or without to consider [= ...] as an expression
>>>> without braces or something similar).
>>>> But...
>>>>
>>>> Just to point to an issue in case of compilation like concat with
>>>> invokeStk for [=] at end:
>>>> neither it looks like good idea to me, nor it is safe, because
>>>> could segfault in certain constellations.
>>>>
>>>> Simplified PoC (thereby it is irrelevant what [] contains, it'd be
>>>> anything else, e. g. [set s], and used here to avoid pure literal
>>>> compilation):
>>>>
>>>> % proc test {} { set s 0; timerate { = s + [] } }; test
>>>>
>>>> Thread 1 received signal SIGSEGV, Segmentation fault.
>>>> 0x00007ff9e48120f8 in FollowLinks (varPtr=0x100074a210) at
>>>> ./generic/tclExecute.c:2067
>>>> 2067 while (TclIsVarLink(varPtr)) {
>>>> (gdb) where
>>>> #0 0x00007ff9e48120f8 in FollowLinks (varPtr=0x100074a210) at
>>>> ./generic/tclExecute.c:2067
>>>> #1 0x00007ff9e48170da in TEBCresume (data=0x798178,
>>>> interp=0x7460c0, result=0) at ./generic/tclExecute.c:3340
>>>> #2 0x00007ff9e4775f15 in TclNRRunCallbacks (interp=0x7460c0,
>>>> result=0, rootPtr=0x797270) at ./generic/tclBasic.c:4668
>>>> #3 0x00007ff9e47b4c60 in Tcl_TimeRateObjCmd (dummy4169=0x0,
>>>> interp=0x7460c0, objc=2, objv=0x74a2b0) at ./generic/tclCmdMZ.c:4453
>>>> #...
>>>>
>>>> It is surely TEBC, because It'd work as expected if would fallback
>>>> to direct invocation (variable `s` doesn't compiled in the frame yet):
>>>>
>>>> % proc test {} { timerate { = s + [] } }; test
>>>> = Expected start of expression but found ''
>>>>
>>>> Regards,
>>>> Serg.
>>>>
>>>> Am 03.12.2025 16:49, schrieb Colin Macleod via Tcl-Core:
>>>>
>>>> Hi again,
>>>>
>>>> I decided to treat "NaN", "Inf" & "Infinity" (any
>>>> capitalisation) as variable names, eliminating that special
>>>> case. Does anyone actually write expressions, other than test
>>>> cases, using these values? If so they will need to stick to
>>>> `expr`. I have updated the code, tests and man page to reflect
>>>> this, and updated the patch at
>>>> https://cmacleod.me.uk/tcl/tip676.patch.txt.
>>>>
>>>> I have also added an equals.test file of tests. Some of these
>>>> I have adapted from the existing tests for `expr`, but more
>>>> than half were contributed by Eric, which is extremely helpful.
>>>>
>>>> I now need to update the TIP to match the implementation. Once
>>>> that is done I think it will be ready for formal consideration.
>>>>
>>>> Colin.
>>>>
>>>> On 02/12/2025 17:10, Colin Macleod wrote:
>>>>
>>>> Hi again all,
>>>>
>>>> I'm now working on creating tests for the `=` command, by
>>>> adapting the tests for `expr` which are relevant. This has
>>>> highlighted a few edge cases which I'm not sure how best to
>>>> handle, so I would like to ask what other people think.
>>>>
>>>> When given a single number as the expression, `expr` always
>>>> rewrites it to decimal form. At present `=` leaves it
>>>> unchanged unless it's used in a calculation:
>>>>
>>>> % expr 0xff
>>>> 255
>>>> % = 0xff
>>>> 0xff
>>>> % = 0xff + 0
>>>> 255
>>>>
>>>> So in this case `=` behaves differently from `expr` - I
>>>> don't think this is really a problem and I would rather not
>>>> introduce an unnecessary conversion here. Is this acceptable?
>>>>
>>>> I'm not allowing the non-numeric representations of boolean
>>>> values: true, false, yes, no, etc. The `expr` code also
>>>> accepts any abbreviations of these, doing this in `=` would
>>>> make it impossible to use variables called t, f, y or n,
>>>> which I think is unacceptable. However the current `=` does
>>>> accept Inf and NaN (with any capitalisation, but not
>>>> abbreviated) as numeric constants, which makes it
>>>> impossible to use variables with those names. I'm not very
>>>> happy about this being a special case, so I'm wondering
>>>> about disallowing those also. If so, someone who really
>>>> wanted to use such a value in a computation could still do
>>>> so by assigning it to a variable first and using that
>>>> variable in the `=` command: *set nan NaN; = nan + 0 *.
>>>> What do others think?
>>>>
>>>> Combining these two issues, we get the following:
>>>>
>>>> % expr nan
>>>> domain error: argument not in valid range
>>>> % = nan
>>>> nan
>>>> % = nan + 0
>>>> cannot use non-numeric floating-point value "nan" as
>>>> left operand of "+"
>>>>
>>>> Acceptable or not?
>>>>
>>>> If anyone would like to experiment, I think the code at
>>>> https://cmacleod.me.uk/tcl/tip676.patch.txt is now fairly
>>>> solid. It would be good to get feedback, not just on these
>>>> specific issues but on the whole approach.
>>>>
>>>> Best regards,
>>>> Colin.
>>>>
>>>> On 30/11/2025 12:45, Colin Macleod via Tcl-Core wrote:
>>>>
>>>> Hello again,
>>>>
>>>> I have updated the patch now, adding a man page for `=`
>>>> and fixing some bugs which Eric reported. I had to
>>>> make a little tweak to installManPage to prevent it
>>>> mangling the name.
>>>>
>>>> Colin.
>>>>
>>>> On 29/11/2025 13:57, Colin Macleod via Tcl-Core wrote:
>>>>
>>>> Hello All,
>>>>
>>>> I have now implemented compilation of the case
>>>> where pre-substitutions are purely numeric, falling
>>>> back to the non-compiled code where this turns out
>>>> not to be the case. This added about 100 lines
>>>> more code. I also added an optimisation for
>>>> accessing local variables, which Eric pointed out.
>>>> Both these improvements are only possible when
>>>> we have a local variable table, which may not be
>>>> the case for one-off code, but is always the case
>>>> within a proc. Again the updated code can be found
>>>> in patch form at
>>>> https://cmacleod.me.uk/tcl/tip676.patch.txt.
>>>>
>>>> Timings of simple expressions:
>>>>
>>>> Proc using [expr]:
>>>>
>>>> % proc fred1 {a b} {expr {$a*2-$b}}
>>>> % fred1 4 6
>>>> 2
>>>> % timerate {fred1 [incr c] 7}
>>>> 0.292607 µs/# 3417549 # 3417549 #/sec 1000.000
>>>> net-ms
>>>>
>>>> Same proc using [=]:
>>>>
>>>> % proc fred2 {a b} {= a*2-b}
>>>> % fred2 4 6
>>>> 2
>>>> % timerate {fred2 [incr c] 7}
>>>> 0.291969 µs/# 3425016 # 3425016 #/sec 1000.000
>>>> net-ms
>>>>
>>>> Timings of expressions including an array reference:
>>>>
>>>> Proc using [expr]:
>>>>
>>>> % array set nums {one 1 two 2 three 3 four IIII}
>>>> %
>>>> % proc ada1 name {expr {sin($::nums($name))+1}}
>>>> % ada1 two
>>>> 1.9092974268256817
>>>> % timerate {ada1 three}
>>>> 0.411508 µs/# 2430088 # 2430088 #/sec 1000.000
>>>> net-ms
>>>>
>>>> Proc using [=], array reference not a separate
>>>> argument, so compilation fails:
>>>>
>>>> % proc ada2 name {= sin($::nums($name))+1}
>>>> % ada2 two
>>>> 1.9092974268256817
>>>> % timerate {ada2 three}
>>>> 1.346676 µs/# 742569 # 742569 #/sec 1000.000 net-ms
>>>>
>>>> Proc using [=], array reference is a separate
>>>> argument, so compilation succeeds:
>>>>
>>>> % proc ada2a name {= sin( $::nums($name) )+1}
>>>> % ada2a two
>>>> 1.9092974268256817
>>>> % timerate {ada2a three}
>>>> 0.468546 µs/# 2134260 # 2134260 #/sec 1000.000
>>>> net-ms
>>>>
>>>> But note of course that [expr] and [=] do not fail
>>>> in the same way here:
>>>>
>>>> % ada1 four
>>>> expected floating-point number but got "IIII"
>>>> % ada2 four
>>>> can't read "IIII": no such variable
>>>> % ada2a four
>>>> can't read "IIII": no such variable
>>>>
>>>> I think the code is now pretty much complete. I
>>>> have not worked in the Tcl core before, apart from
>>>> a few little fixes a very long time ago, so I would
>>>> be glad if other people could take a look at my code.
>>>>
>>>> I still need to create a man page and some tests.
>>>> Eric has contributed a set of tests but I haven't
>>>> found time to look at them yet.
>>>>
>>>> Colin.
>>>>
>>>> On 25/11/2025 03:19, Colin Macleod via Tcl-Core wrote:
>>>>
>>>> Thanks Eric,
>>>>
>>>> I think it may be possible to take compilation
>>>> one step further, to handle the common case
>>>> where pre-substitutions are purely numeric.
>>>> This would work similarly to the
>>>> extract_numbers step I added in the Tcl
>>>> prototype. The compilation step would generate
>>>> code like:
>>>>
>>>> For any pre-substituted words,
>>>> generate runtime code to check that the
>>>> actual value is numeric (how?)
>>>> and stash each value somewhere.
>>>> If any of these tests fail,
>>>> branch to code which pushes all the
>>>> arguments on the stack
>>>> and invokes the non-compiled `=`
>>>> implementation.
>>>> If all tests ok,
>>>> run the compiled code,
>>>> which can be generated assuming that the
>>>> pre-substituted values are numeric,
>>>> and will pull in the stashed values where
>>>> the corresponding arguments are required.
>>>>
>>>> I'm not sure about the details of this, it may
>>>> turn out not to be practical.
>>>>
>>>> Colin.
>>>>
>>>> On 24/11/2025 21:18, EricT wrote:
>>>>
>>>> Hi Colin,
>>>>
>>>> Congratulations on getting the = command to
>>>> this level of quality! The compilation
>>>> optimization is particularly impressive -
>>>> you've integrated it cleanly into Tcl's
>>>> proc compilation system.
>>>>
>>>> I added a few more proc tests with variable
>>>> substitutions to round out the test
>>>> coverage. They all passed. These can be
>>>> added to the end of calc.test:
>>>>
>>>> # ---------- Pre-Substitution in Procs
>>>> ----------
>>>>
>>>> test calc-39.1 {variable substitution in
>>>> proc} -constraints hasCalcCmd -body {
>>>> proc test_var_subst {a b} {
>>>> = $a + $b
>>>> }
>>>> test_var_subst 10 20
>>>> } -result 30 -cleanup {
>>>> rename test_var_subst {}
>>>> }
>>>>
>>>> test calc-39.2 {mixed literal and
>>>> substitution} -constraints hasCalcCmd -body {
>>>> proc test_mixed {n} {
>>>> = $n * 2 + 5
>>>> }
>>>> test_mixed 10
>>>> } -result 25 -cleanup {
>>>> rename test_mixed {}
>>>> }
>>>>
>>>> test calc-39.3 {command substitution in
>>>> proc} -constraints hasCalcCmd -body {
>>>> proc test_cmd_subst {x} {
>>>> = [expr {$x * 2}] + 10
>>>> }
>>>> test_cmd_subst 5
>>>> } -result 20 -cleanup {
>>>> rename test_cmd_subst {}
>>>> }
>>>>
>>>> I also verified an important safety
>>>> advantage of your implementation - it
>>>> doesn't suffer from expr's
>>>> double-evaluation security issue:
>>>>
>>>> set xxx {[cd a:/]}
>>>> expr $xxx + 1
>>>> # Changes directory! expr evaluates the
>>>> string as code
>>>>
>>>> = $xxx + 1
>>>> # Error: "Expected start of expression but
>>>> found '['"
>>>> # Does NOT execute the command - safer!
>>>>
>>>> Your parser treats the value as data, not
>>>> code, which is the correct behavior.
>>>>
>>>> Great work!
>>>>
>>>> Best regards,
>>>> Eric
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Tcl-Core mailing list
>>>> Tcl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Tcl-Core mailing list
>>>> Tcl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>>
>>>>
>>>> _______________________________________________
>>>> Tcl-Core mailing list
>>>> Tcl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>>
>>>
>>>
>>> _______________________________________________
>>> Tcl-Core mailing list
>>> Tcl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Dipl. I. S. G. B. <se...@us...> - 2025-12-07 01:12:04
|
My pleasure...
The issue with "don't like" is - it is not tclish enough to me.
Or rather it is a bit strange sugar in my opinion, because:
* it doesn't support many things what expression does, like comparison
with strings/literals or usage of functions;
* does weird subst of literal parameters as variables without dollar
at every offset (commands like set, (l)append etc, do that with single
variable only, and it is absolutely justified);
* therefore confusing or else wrong interpreting of the tcl code by
reading, for instance what happens here?
[= a < "b"]
or rather although "b" and b are the same literals in tcl, it is
completely weird here to handle "b" as variable name IMHO (I know why,
but it is confusing for reading);
* or even here (double subst of var, but if $b "resolves" a literal,
not number, otherwise not at all)?
[= a < $b] * all of this objectively makes this sugar in context of TCL
to Malbolge (esoteric programming language that humans hardly
understand);
* the way how it is compiled (and it cannot be compiled differently
and optimal) quasi forces the devs to write not effective code;
* etc (I can continue here with further arguments).
As already said, I am also for some sugar to simplify [expr {...}]
writing, but it must be well thought-out, clearly discernible as such
and ideally parse-able in that form at level of tcl-parser.
Even if basic rules of tcl-parser get modified for that purposes, e. g.
like it was done with args expansion {*}.
All the attempts I've seen so far looked more like a workaround to me,
sorry guys.
Regards,
Serg.
06.12.2025 13:43, Colin Macleod wrote:
> Hello All,
>
> I have now fixed this crash and updated the patch file. I had assumed that if EnvHasLVT() was true then AnonymousLocal() would always succeed, which is not the case. Thanks very much to Sergey for picking this up, even though he doesn't like the proposal.
>
> Colin.
> On 05/12/2025 18:17, Colin Macleod via Tcl-Core wrote:
>
> Hi Sergey,
>
> Thanks very much for this report. I'll dig into it tomorrow.
>
> Colin.
> On 05/12/2025 15:09, Dipl. Ing. Sergey G. Brester wrote:
>
> I already said everything I want about the proposal.
> And I still don't think it'd be good idea at all to introduce such sugar without to modify tcl parser
> (e. g. to behave different on certain things like it was with args expansion {*}, or without to consider [= ...] as an expression without braces or something similar).
> But...
>
> Just to point to an issue in case of compilation like concat with invokeStk for [=] at end:
> neither it looks like good idea to me, nor it is safe, because could segfault in certain constellations.
>
> Simplified PoC (thereby it is irrelevant what [] contains, it'd be anything else, e. g. [set s], and used here to avoid pure literal compilation):
>
> % proc test {} { set s 0; timerate { = s + [] } }; test
>
> Thread 1 received signal SIGSEGV, Segmentation fault.
> 0x00007ff9e48120f8 in FollowLinks (varPtr=0x100074a210) at ./generic/tclExecute.c:2067
> 2067 while (TclIsVarLink(varPtr)) {
> (gdb) where
> #0 0x00007ff9e48120f8 in FollowLinks (varPtr=0x100074a210) at ./generic/tclExecute.c:2067
> #1 0x00007ff9e48170da in TEBCresume (data=0x798178, interp=0x7460c0, result=0) at ./generic/tclExecute.c:3340
> #2 0x00007ff9e4775f15 in TclNRRunCallbacks (interp=0x7460c0, result=0, rootPtr=0x797270) at ./generic/tclBasic.c:4668
> #3 0x00007ff9e47b4c60 in Tcl_TimeRateObjCmd (dummy4169=0x0, interp=0x7460c0, objc=2, objv=0x74a2b0) at ./generic/tclCmdMZ.c:4453
> #...
>
> It is surely TEBC, because It'd work as expected if would fallback to direct invocation (variable `s` doesn't compiled in the frame yet):
>
> % proc test {} { timerate { = s + [] } }; test
> = Expected start of expression but found ''
>
> Regards,
> Serg.
>
> Am 03.12.2025 16:49, schrieb Colin Macleod via Tcl-Core:
>
> Hi again,
>
> I decided to treat "NaN", "Inf" & "Infinity" (any capitalisation) as variable names, eliminating that special case. Does anyone actually write expressions, other than test cases, using these values? If so they will need to stick to `expr`. I have updated the code, tests and man page to reflect this, and updated the patch at https://cmacleod.me.uk/tcl/tip676.patch.txt [1].
>
> I have also added an equals.test file of tests. Some of these I have adapted from the existing tests for `expr`, but more than half were contributed by Eric, which is extremely helpful.
>
> I now need to update the TIP to match the implementation. Once that is done I think it will be ready for formal consideration.
>
> Colin.
> On 02/12/2025 17:10, Colin Macleod wrote:
>
> Hi again all,
>
> I'm now working on creating tests for the `=` command, by adapting the tests for `expr` which are relevant. This has highlighted a few edge cases which I'm not sure how best to handle, so I would like to ask what other people think.
>
> When given a single number as the expression, `expr` always rewrites it to decimal form. At present `=` leaves it unchanged unless it's used in a calculation:
>
> % expr 0xff
> 255
> % = 0xff
> 0xff
> % = 0xff + 0
> 255
>
> So in this case `=` behaves differently from `expr` - I don't think this is really a problem and I would rather not introduce an unnecessary conversion here. Is this acceptable?
>
> I'm not allowing the non-numeric representations of boolean values: true, false, yes, no, etc. The `expr` code also accepts any abbreviations of these, doing this in `=` would make it impossible to use variables called t, f, y or n, which I think is unacceptable. However the current `=` does accept Inf and NaN (with any capitalisation, but not abbreviated) as numeric constants, which makes it impossible to use variables with those names. I'm not very happy about this being a special case, so I'm wondering about disallowing those also. If so, someone who really wanted to use such a value in a computation could still do so by assigning it to a variable first and using that variable in the `=` command: SET NAN NAN; = NAN + 0 . What do others think?
>
> Combining these two issues, we get the following:
>
> % expr nan
> domain error: argument not in valid range
> % = nan
> nan
> % = nan + 0
> cannot use non-numeric floating-point value "nan" as left operand of "+"
>
> Acceptable or not?
>
> If anyone would like to experiment, I think the code at https://cmacleod.me.uk/tcl/tip676.patch.txt [1] is now fairly solid. It would be good to get feedback, not just on these specific issues but on the whole approach.
>
> Best regards,
> Colin.
> On 30/11/2025 12:45, Colin Macleod via Tcl-Core wrote:
>
> Hello again,
>
> I have updated the patch now, adding a man page for `=` and fixing some bugs which Eric reported. I had to make a little tweak to installManPage to prevent it mangling the name.
>
> Colin.
> On 29/11/2025 13:57, Colin Macleod via Tcl-Core wrote:
>
> Hello All,
>
> I have now implemented compilation of the case where pre-substitutions are purely numeric, falling back to the non-compiled code where this turns out not to be the case. This added about 100 lines more code. I also added an optimisation for accessing local variables, which Eric pointed out. Both these improvements are only possible when we have a local variable table, which may not be the case for one-off code, but is always the case within a proc. Again the updated code can be found in patch form at https://cmacleod.me.uk/tcl/tip676.patch.txt [1].
>
> Timings of simple expressions:
>
> Proc using [expr]:
>
> % proc fred1 {a b} {expr {$a*2-$b}}
> % fred1 4 6
> 2
> % timerate {fred1 [incr c] 7}
> 0.292607 µs/# 3417549 # 3417549 #/sec 1000.000 net-ms
>
> Same proc using [=]:
>
> % proc fred2 {a b} {= a*2-b}
> % fred2 4 6
> 2
> % timerate {fred2 [incr c] 7}
> 0.291969 µs/# 3425016 # 3425016 #/sec 1000.000 net-ms
>
> Timings of expressions including an array reference:
>
> Proc using [expr]:
>
> % array set nums {one 1 two 2 three 3 four IIII}
> %
> % proc ada1 name {expr {sin($::nums($name))+1}}
> % ada1 two
> 1.9092974268256817
> % timerate {ada1 three}
> 0.411508 µs/# 2430088 # 2430088 #/sec 1000.000 net-ms
>
> Proc using [=], array reference not a separate argument, so compilation fails:
>
> % proc ada2 name {= sin($::nums($name))+1}
> % ada2 two
> 1.9092974268256817
> % timerate {ada2 three}
> 1.346676 µs/# 742569 # 742569 #/sec 1000.000 net-ms
>
> Proc using [=], array reference is a separate argument, so compilation succeeds:
>
> % proc ada2a name {= sin( $::nums($name) )+1}
> % ada2a two
> 1.9092974268256817
> % timerate {ada2a three}
> 0.468546 µs/# 2134260 # 2134260 #/sec 1000.000 net-ms
>
> But note of course that [expr] and [=] do not fail in the same way here:
>
> % ada1 four
> expected floating-point number but got "IIII"
> % ada2 four
> can't read "IIII": no such variable
> % ada2a four
> can't read "IIII": no such variable
>
> I think the code is now pretty much complete. I have not worked in the Tcl core before, apart from a few little fixes a very long time ago, so I would be glad if other people could take a look at my code.
>
> I still need to create a man page and some tests. Eric has contributed a set of tests but I haven't found time to look at them yet.
>
> Colin.
> On 25/11/2025 03:19, Colin Macleod via Tcl-Core wrote:
>
> Thanks Eric,
>
> I think it may be possible to take compilation one step further, to handle the common case where pre-substitutions are purely numeric. This would work similarly to the extract_numbers step I added in the Tcl prototype. The compilation step would generate code like:
>
> For any pre-substituted words,
> generate runtime code to check that the actual value is numeric (how?)
> and stash each value somewhere.
> If any of these tests fail,
> branch to code which pushes all the arguments on the stack
> and invokes the non-compiled `=` implementation.
> If all tests ok,
> run the compiled code,
> which can be generated assuming that the pre-substituted values are numeric,
> and will pull in the stashed values where the corresponding arguments are required.
>
> I'm not sure about the details of this, it may turn out not to be practical.
>
> Colin.
> On 24/11/2025 21:18, EricT wrote:
> Hi Colin,
>
> Congratulations on getting the = command to this level of quality! The compilation optimization is particularly impressive - you've integrated it cleanly into Tcl's proc compilation system.
>
> I added a few more proc tests with variable substitutions to round out the test coverage. They all passed. These can be added to the end of calc.test:
>
> # ---------- Pre-Substitution in Procs ----------
>
> test calc-39.1 {variable substitution in proc} -constraints hasCalcCmd -body {
> proc test_var_subst {a b} {
> = $a + $b
> }
> test_var_subst 10 20
> } -result 30 -cleanup {
> rename test_var_subst {}
> }
>
> test calc-39.2 {mixed literal and substitution} -constraints hasCalcCmd -body {
> proc test_mixed {n} {
> = $n * 2 + 5
> }
> test_mixed 10
> } -result 25 -cleanup {
> rename test_mixed {}
> }
>
> test calc-39.3 {command substitution in proc} -constraints hasCalcCmd -body {
> proc test_cmd_subst {x} {
> = [expr {$x * 2}] + 10
> }
> test_cmd_subst 5
> } -result 20 -cleanup {
> rename test_cmd_subst {}
> }
>
> I also verified an important safety advantage of your implementation - it doesn't suffer from expr's double-evaluation security issue:
>
> set xxx {[cd a:/]}
> expr $xxx + 1
> # Changes directory! expr evaluates the string as code
>
> = $xxx + 1
> # Error: "Expected start of expression but found '['"
> # Does NOT execute the command - safer!
>
> Your parser treats the value as data, not code, which is the correct behavior.
>
> Great work!
>
> Best regards,
>
> Eric
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core [2]
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core [2]
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core [2]
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core [2]
Links:
------
[1] https://cmacleod.me.uk/tcl/tip676.patch.txt
[2] https://lists.sourceforge.net/lists/listinfo/tcl-core
|
|
From: Brian O'H. <bri...@co...> - 2025-12-06 22:51:20
|
Thanks. I've incorporated #1 and #3. The sort arrows are much nicer now.
For #2, no it's not intentional but instead a side effect of the button
states. The Check and Radio buttons use the alternate state to denote
the no value (aka tri-state or no on/off value is defined) state. Since
we don't set a value (we only use the selection state), then all items
get the alternate state. The current logic in ttkButton.c (see
CheckbuttonVariableChanged) doesn't allow a bypass for this without
setting an on/off value or defining a variable. It's open work to see if
there is another option.
On 12/5/25 10:32 AM, Csaba Nemethi wrote:
> Hi Brian,
>
> 1. To make sure that with the CheckTreeview style the checkbutton
> indicators in the default and classic themes will be visible, please
> proceed as follows:
>
> - Insert the lines
>
> ttk::style map Item -indicatorbackground \
> [list selected $colors(-indicator)]
>
> just before line #187 of the file library/ttk/defaults.tcl.
>
> - Insert the lines
>
> ttk::style map Item \
> -indicatorcolor [list selected $colors(-indicator)] \
> -indicatorrelief {selected sunken}
>
> just before line #113 of the file library/ttk/classicTheme.tcl.
>
> 2. Is it intentional that with the CheckTreeview style the -striped
> option has no effect?
>
> 3. I am still not happy with the appearance of the sort arrows. I
> have looked into this issue again and found a much better solution,
> which takes into account a few details of the way polygons are
> rendered by the SVG engine. Here is the new version; I can guarantee
> you that it improves the look of the sort arrows quite significantly:
>
> set upArrowData [format {
> <?xml version="1.0" encoding="UTF-8"?>
> <svg width="16" height="8" version="1.1"
> xmlns="http://www.w3.org/2000/svg">
> <path d="m3.5 6.5 4.5 -4.5 4.5 4.5z" stroke="%s"
> stroke-width="1" stroke-linejoin="round" fill="none"/>
> </svg>} $fgColor]
> image create photo arrowUp -format $::tk::svgFmt -data $upArrowData
>
> set downArrowData [format {
> <?xml version="1.0" encoding="UTF-8"?>
> <svg width="16" height="8" version="1.1"
> xmlns="http://www.w3.org/2000/svg">
> <path d="m3.5 2.5 4.5 4.5 4.5 -4.5z" stroke="%s"
> stroke-width="1" stroke-linejoin="round" fill="none"/>
> </svg>} $fgColor]
> image create photo arrowDown -format $::tk::svgFmt -data
> $downArrowData
>
> Best regards,
>
> Csaba
>
>
> Am 05.12.25 um 02:37 schrieb Brian O'Hagan:
>> Thanks for tracking that down. I'll get it fixed, though if you see
>> my email to Torsten it should be a 1 pixel black focus ring.
>>
>> I could add the sort arrows to the widget like how is done on the
>> Mac. That uses the user1 state as a flag for whether to show the
>> built-in sort indicators. I could do the same for the other themes
>> and it would be backwards compatible since people would need to add
>> the user1 state to see the built-in indicators. Another benefit is it
>> would free up the -image option for something else. I know some
>> widgets have a filter image when a column has been filtered.
>>
>>
>> On 12/4/25 12:38 PM, Csaba Nemethi wrote:
>>> Hi Brian,
>>>
>>> 1. Regarding the "classic" theme: The reason for the missing focus
>>> ring around the rows is the "-focuswidth 0" setting for the root
>>> style ".". This mustn't be changed, but it should be overridden for
>>> the Row style by inserting
>>>
>>> ttk::style configure Row -focuswidth 2
>>>
>>> just before line #110 of the file library/ttk/classicTheme.tcl. I
>>> have tested it, it works as expected.
>>>
>>> 2. Regarding the sort arrows: In the file
>>> library/demos/treeview.tcl I have changed the lines 695-696 to
>>>
>>> <svg width="16" height="4" version="1.1" xmlns="http://
>>> www.w3.org/2000/svg">
>>> <path d="m4 4 4 -4 4 4z" stroke="%s" stroke-width="1"
>>> fill="none"/>
>>>
>>> and the lines 702-703 to
>>>
>>> <svg width="16" height="4" version="1.1" xmlns="http://
>>> www.w3.org/2000/svg">
>>> <path d="m4 0 4 4 4 -4z" stroke="%s" stroke-width="1"
>>> fill="none"/>
>>>
>>> The resulting arrows appear vertically centered and look better than
>>> before. Note that with this patch there is a padding *on both
>>> sides* of the arrows. This makes sure that there will be a small
>>> gap between the text and the arrows, even if the column's width
>>> becomes smaller.
>>>
>>> BTW: IMHO, the support for sort arrows should be a built-in
>>> functionality of the treeview widget.
>>>
>>> Best regards,
>>>
>>> Csaba
>>>
> |
|
From: Marc C. <cul...@gm...> - 2025-12-06 19:07:52
|
YES on TIP #739 - Marc On Fri, Dec 5, 2025 at 11:16 AM Csaba Nemethi <csa...@t-...> wrote: > Attn. TCT members, > > This is a CFV for TIP 739: Add a Wide.TSpinbox style to the core. > > https://core.tcl-lang.org/tips/doc/trunk/tip/739.md > > The TIP is kindly sponsored by Harald. Many thanks, Harald! > > Please send your votes to this list until Monday, 2025-12-15 20:00 UTC. > > Best regards, > > Csaba > > -- > Csaba Nemethi https://www.nemethi.de mailto:csa...@t-... > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: Harald O. <har...@el...> - 2025-12-06 18:37:25
|
Am 05.12.2025 um 18:15 schrieb Csaba Nemethi: > Attn. TCT members, > > This is a CFV for TIP 739: Add a Wide.TSpinbox style to the core. > > https://core.tcl-lang.org/tips/doc/trunk/tip/739.md > > The TIP is kindly sponsored by Harald. Many thanks, Harald! > > Please send your votes to this list until Monday, 2025-12-15 20:00 UTC. > > Best regards, > > Csaba > Vote: yes. THank you, Harald |
26 messages has been excluded from this view by a project administrator.
