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
(259) |
Dec
(276) |
| 2026 |
Jan
(207) |
Feb
(180) |
Mar
(303) |
Apr
(361) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Brian O’H. <bri...@co...> - 2026-04-28 22:46:06
|
Thanks. I’ll look these over and get back to you. I’m in the process of fighting with fossil to get this into a Tk branch. Hopefully I will have that done in the next day or two.
> On Apr 28, 2026, at 12:55 PM, Csaba Nemethi <csa...@t-...> wrote:
>
> Hi Brian,
>
> I have a few more remarks regarding the enhanced treeview widget:
>
> 1. In the files ttkClassicTheme.c, ttkDefaultTheme.c, and ttkTreeview.c you set the default value of the "-indicatormargin" option of the Heading element to {3p 1.5p 1.5p 1.5p}. OTOH, in altTheme.tcl, clamTheme.tcl, classicTheme.tcl, defaults.tcl, and winTheme.tcl you override this value by {3 1 2 1}. This is confusing and IMHO not OK, because {3 1 2 1} is not scalable.
>
> 2. In the files ttkTreeview.c and winTheme.tcl you set the default value of the "-indicatorsize" option of the Heading element to 3.5p, contrary to the other above-mentioned C and Tcl files, where it is set to 3p. Apart from being confusing, I wonder why you chose 3.5p, which on an unscaled screen translates to 4.666... px, i.e., 5 px. BTW, on an unscaled screen, 5 px corresponds to exactly 3.75p. My proposal: Eliminate these inconsistencies by using exclusively the value 3p.
>
> 3. There are several similar issues regarding the default value of the "-indicatorsize" option of the Item element. My proposal: (a) In ttkClassicTheme.c, ttkDefaultTheme.c, altTheme.tcl, classicTheme.tcl, and winTheme.tcl use the value 6.75p, and (b) in ttkTreeview.c, clamTheme.tcl, and defaults.tcl use the value 3p.
>
> 4. The item indicators of the themes alt, classic, and winnative don't look as expected: their height is larger than their width. This is caused by the last 5 lines of the body of the TreeitemIndicatorSize() function in the files ttkDefaultTheme.c and ttkClassicTheme.c. Please remove these lines. In addition, re-add the line
>
> if (size % 2 == 0) --size; /* An odd size is better for the indicator. */
>
> just after line 1473 of ttkDefaultTheme.c and after line 970 of ttkClassicTheme.c.
>
> 5. In ttkTreeview.c, the body of the function TreeitemIndicatorDraw() should be free of occurrences of ARROW_DOWN and ARROW_RIGHT. Please replace them with CHEVRON_DOWN and CHEVRON_RIGHT.
>
> 6. With the "default" theme the selected items become invisible when the treeview loses the focus. This is caused by the identical lines 209 and 213 of the file defaults.tcl. To fix this, please replace these lines with
>
> background $colors(-darker) \
>
> and
>
> background $colors(-selectfg) \
>
> respectively.
>
> Best regards,
>
> Csaba
>
> --
> Csaba Nemethi https://www.nemethi.de mailto:csa...@t-...
>
|
|
From: Kevin W. <kw...@co...> - 2026-04-28 22:27:58
|
<html class="apple-mail-supports-explicit-dark-mode"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Haven’t seen any feedback yet. I plan to merge the branch next week and call it done if no concerns are raised. <div><br></div><div>- Kevin<br id="lineBreakAtBeginningOfSignature"><div dir="ltr"><div>—</div>Kevin Walzer kw...@co...</div><div dir="ltr"><br><blockquote type="cite">On Apr 25, 2026, at 9:29 PM, Kevin Walzer <kw...@co...> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8">One additional note. There are two remaining bugs with bidi text on Tk X11 that we probably need to document as known issues that cannot be corrected at this time:. <div><br></div><div> 1. Harfbuzz badly renders CJK fonts with spacing that is too tight. Christian Werner has reported this, and I can reproduce it. This appears to be an upstream bug in Harfbuzz that will not be addressed: <a href="https://github.com/harfbuzz/harfbuzz/issues/4651?utm_source=copilot.com">https://github.com/harfbuzz/harfbuzz/issues/4651</a></div><div><br></div><div> 2. RTL text gets subtly darker when I click the cursor through it then gets lighter when the cursor leaves. This is probably an upstream Xft drawing bug involving partial vs. full redraws in the XRender pipeline. I am not aware of a solution. </div><div><br></div><div>-Kevin<br id="lineBreakAtBeginningOfSignature"><div dir="ltr"><div>—</div>Kevin Walzer kw...@co...</div><div dir="ltr"><br><blockquote type="cite">On Apr 25, 2026, at 7:33 PM, Kevin Walzer <kw...@co...> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>Quick update:</span><br><span></span><br><span>1. I have modified "configure" to run "--enable-bidi" by default on X11. Bidi support is already the default on macOS and Windows.</span><br><span></span><br><span>2. I've spent a couple of days working on updating the test suite. I've modified six or seven tests to recognize different results because of the internal changes to bidi, set a win32 constraint on one test, and made a few tweaks to C code.</span><br><span></span><br><span>I think this is as good as I can make it, and I'd like to request some testing. I will be AFK next week for work, so this will give everyone some time to review the changes.</span><br><span></span><br><span>-Kevin</span><br><span></span><br><span>On 4/24/26 9:23 AM, Kevin Walzer wrote:</span><br><blockquote type="cite"><span>The test failures may come later IMHO. Of cause, it is important.</span><br></blockquote><blockquote type="cite"><span>But I would prefer first a comment by other experts, if they agree with the proposed change. </span><br></blockquote><span></span><br><span>-- </span><br><span>Kevin Walzer kw...@co...</span><br><span></span><br><span></span><br><span></span><br><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></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></div></body></html> |
|
From: Marc C. <cul...@gm...> - 2026-04-28 21:35:30
|
TIP 735: yes TIP 745: yes - Marc On Sun, Apr 26, 2026 at 6:03 AM Donal Fellows < don...@ma...> wrote: > Hi everyone > > This is a call for votes on two self-contained TIPs that I've been sitting > on for far too long. > > TIP 735: Simpler List Filtering > <https://core.tcl-lang.org/tips/doc/trunk/tip/735.md> > This adds a global *lfilter *command, because the current idiom for > filtering out items of a list (when *lsearch -inline -all -not* can't do > it) is weird. I've tried using an expression for the filter (that was the > initial version of the TIP *but not the current one*), which works but > feels more annoying to me than using a script (with expressions available > by calling *expr*). I can be talked round to doing this the other way, > but the current way is marginally simpler to implement (on the interpreted > side; the compiled version is pretty much identically complex). > > TIP 745: Functions from C99 > <https://core.tcl-lang.org/tips/doc/trunk/tip/745.md> > This imports virtually all the remaining math functions from C99 > <https://en.cppreference.com/w/c/numeric/math.html> into Tcl, pretty much > as-is (bearing in mind that some "return" multiple values, which maps > differently in Tcl; see below) with most just going into the > *::tcl::mathfunc* namespace and so having limited global impact. > Implementation bugs in the functions' C implementations are exactly bugs in > the corresponding Tcl functions; I do not propose we reimplement them > (except for *signbit*, which is extended to directly cover all Tcl > numeric values). > *NB:* Introduces four new global commands for the > multiple-value-returners: * divmod*, *frexp*, *modf*, *remquo*. They > don't sit nicely as standard functions. > > Implementation branches exist for both TIPs (tip-735 > <https://core.tcl-lang.org/tcl/timeline?r=tip-735>, c11-functions > <https://core.tcl-lang.org/tcl/timeline?r=c11-functions>). > > Votes in the standard form to this mailing list. Vote closes at 12:00 my > time, 4 May 2026, *[clock format 1777892400]*. My votes follow: > > TIP 735: YES > TIP 745: YES > > Donal. > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: Florent M. <flo...@gm...> - 2026-04-28 20:55:46
|
Hi Peter, Harald, Kevin, Hi All With my expr shorthand <https://github.com/florentis/tcl90-exprSH/tree/core-9-0-branch/install_SH> you can choose between : - either enclosing*the lmap script* into parenthesis to take it as an expression : set values {1 2 3 4 5 6 7 8} set goodOnes [lmap x /$values/ {( /$x/ % 2 == 0 ? /$x/ : [continue] )}] - either enclosing*the then body *into parenthesis to take it as an expression (there is no need to use set or return) : set goodOnes [lmap x /$values/ { if {/$x/ % 2 == 0} then *(/$x/)* else continue }] Furthermore, if command with (*$x*) is not only shorter, but also/faster/ than if command with {set x}. Anyway, obviously, that makes the code a lot more clear, isn't it ? Regards, Florent Le 28/04/2026 à 17:30, da Silva, Peter J via Tcl-Core a écrit : > set values {1 2 3 4 5 6 7 8} > proc isEven {n} {expr {($n % 2) == 0}} > set goodOnes [lmap x $values {expr { [isEven $x] ? $x : [continue] }}] > > Any particular reason this is expr {[isEven $x] ? $x : [continue]} > rather than if {[isEven $x]} {return $x} {continue} which seems a lot > more idiomatic, readable, and comprehensible to me. > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core -- <center> <hr/> <b>Florent MERLET</b><br/> <i>4 rue Johann Strauss<br/> Logement 7<br/> 86180 BUXEROLLES</i><br/> <hr/> <b>Mél.</b> : <i>flo...@gm...</i><br/> <b>Tél.</b> : <i>06 70 00 63 48</i> </center> |
|
From: Florent M. <flo...@gm...> - 2026-04-28 19:44:29
|
Hi Donal, Does such a limited use case justify introducing a new command ? In particular, reducing the program body to be only returning the first variable is a definite limitation. Moreover, it is not difficult to create a generic script which include this behaviour, and add a lot more : For instance (in my wish <https://github.com/florentis/tcl90-exprSH/tree/core-9-0-branch/install_SH>, with my script expr shorthand) proc predicate_each {vars L switch} { append script \{( foreach {predicat body} $switch { append script [format { [%s] ? [%s] : } $predicat $body ] } append script \[continue\] append script )\} lmap $vars $L {*}$script } Not only that script works like lfilter : predicate_eachx [lseq 100] { (round($x**0.5)**2==$x) ($x) } -> 0 1 4 9 16 25 36 49 64 81 predicate_eachs {abc foo dad} { { # Is the string exactly equal to itself when reversed string equal $s [string reverse $s] } ($s) } -> dad But it can also : - apply many tests (but exclusives from each other) to any mapped vars, - apply many transformations to any mapped vars to produce the value For example : set L [list bold hello italic tcl underlined world ] predicate_each {x y} $L { {( $x eq "bold" )} {( "<b>$y</b>" )} {regexp "italic" $x} {( "<i>$y</i>" )} {string match under* $x} {( "<u>$y</u>" )} } <b>hello</b> <i>tcl</i> <u>world</u> The synopsis is : *predicate_each */varlist list/ {/test body /?/test body /...?} You'll find a complete set of procs about the common operations you were mentioning before in attachement. They are all very tiny script. lmap is very powerfull indeed. Regards Florent Le 27/04/2026 à 17:32, Donal Fellows a écrit : > I tend to feel that operations shouldn't just be justified by a grand > plan. A wall is not just built by imagining it's totality, but also by > the placing of each brick where it belongs. > > For the operations you list: > > * > Fold is obviated by variadic operators; we just do an expanded > application. It's a slightly different generalisation. > * > Take and Drop are just simple applications of *lrange*. > * > Nth is exactly within what *lindex *does. > * > Iota is *lseq*. > > > Thinking about the other common operations in Python: > > * > We could perhaps do with enumerate > <https://docs.python.org/3/library/functions.html#enumerate>(), > all <https://docs.python.org/3/library/functions.html#all>() and > any <https://docs.python.org/3/library/functions.html#any>() > sometime; they can be useful. > * > We don't have zip > <https://docs.python.org/3/library/functions.html#zip>(), but > don't need it so much either (again, that variadicity). > * > We don't agonise over the difference between tuples and lists, and > don't have /user-defined/ generators for various reasons at the > moment. > * > Sorting and searching by a collation key are annoying operations > right now, nor do we support min() or max() with a measure function. > > > Thinking about operations from Java's List and ArrayList (similarly > for C# but with different names): > > * > We've nothing like containsAll > <https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/List.html#containsAll(java.util.Collection)>() > or removeAll > <https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/List.html#removeAll(java.util.Collection)>()/retainAll(). > > > We could perhaps do with something like partition > <https://smlfamily.github.io/Basis/list.html#SIG:LIST.partition:VAL><https://smlfamily.github.io/Basis/list.html#SIG:LIST.partition:VAL>from > SML, though it might be low priority. You can probably list other > things from other languages, but I believe the above cover all the > common cases that we don't already have. > > We could also perhaps do with some operations more like those for > (insertion-time ordered, much as dicts are insertion-time ordered) > sets. They're reasonably useful. Linked lists and actual balanced > trees... not so useful except in special circumstances. I've never > missed having them! > > But this is a /huge /scope-creep relative to my TIP, so others may > pursue it, but I'll not do so here. I believe that *lfilter* is useful > in itself. > > Donal. > > ------------------------------------------------------------------------ > *From:* Pietro Cerutti > *Sent:* Monday, April 27, 2026 09:54 > *To:* Donal Fellows > *Cc:* Tcl Core > *Subject:* Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP > 745 "Functions from C99" > > wouldn't it be better if we drafted a TIP for a complete > set of list operations? Some of the functions of tcllib's struct::list > such as reverse and map are already part of core (lreverse, lmap). > > How about we draft a set of function that we recognize being generally > useful for lists and provide a complete set. I can think of, e.g., > fold, take, drop, nth, iota. > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Kevin K. <kev...@gm...> - 2026-04-28 19:25:51
|
If you wanted to use [return], it would be [return -level 0] - deliver the
value to the immediate context, not to the caller of the proc. But [set x]
would be more concise than [return -level 0 $x].
On Tue, Apr 28, 2026 at 11:46 AM Harald Oehlmann <
har...@el...> wrote:
> Am 28.04.2026 um 17:30 schrieb da Silva, Peter J via Tcl-Core:
> > set values {1 2 3 4 5 6 7 8}
> > proc isEven {n} {expr {($n % 2) == 0}}
> > set goodOnes [lmap x $values {expr { [isEven $x] ? $x : [continue] }}]
> >
> > Any particular reason this is expr {[isEven $x] ? $x : [continue]}
> > rather than if {[isEven $x]} {return $x} {continue} which seems a lot
> > more idiomatic, readable, and comprehensible to me.
> Great proposal! I would write it like:
> if {[isEven $x]} {set x} {continue}The "return" directly stops and sets
> the return value to "2".
>
> Try:
> catch {lmap a {1 2} {set a}} r
> -> 0
> r=1 2
>
> catch {lmap a {1 2} {return $a}} r
> -> 2 ( due to return, may raise error or other side-effects)
> r=2
>
> This is very strange, isn't it ;-)...
>
> Thanks for all,
> Harald
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
--
73 de ke9tv/2, Kevin
|
|
From: da S. P. J <pet...@fl...> - 2026-04-28 19:19:20
|
That's what I get for not testing my code. 😊
From: Harald Oehlmann <har...@el...>
Date: Tuesday, April 28, 2026 at 10:46
To: tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] Side question about the lmap documentation ... Re: CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99"
Am 28.04.2026 um 17:30 schrieb da Silva, Peter J via Tcl-Core:
> set values {1 2 3 4 5 6 7 8}
> proc isEven {n} {expr {($n % 2) == 0}}
> set goodOnes [lmap x $values {expr { [isEven $x] ? $x : [continue] }}]
>
> Any particular reason this is expr {[isEven $x] ? $x : [continue]}
> rather than if {[isEven $x]} {return $x} {continue} which seems a lot
> more idiomatic, readable, and comprehensible to me.
Great proposal! I would write it like:
if {[isEven $x]} {set x} {continue}The "return" directly stops and sets
the return value to "2".
Try:
catch {lmap a {1 2} {set a}} r
-> 0
r=1 2
catch {lmap a {1 2} {return $a}} r
-> 2 ( due to return, may raise error or other side-effects)
r=2
This is very strange, isn't it ;-)...
Thanks for all,
Harald
|
|
From: Csaba N. <csa...@t-...> - 2026-04-28 17:55:09
|
Hi Brian,
I have a few more remarks regarding the enhanced treeview widget:
1. In the files ttkClassicTheme.c, ttkDefaultTheme.c, and ttkTreeview.c
you set the default value of the "-indicatormargin" option of the
Heading element to {3p 1.5p 1.5p 1.5p}. OTOH, in altTheme.tcl,
clamTheme.tcl, classicTheme.tcl, defaults.tcl, and winTheme.tcl you
override this value by {3 1 2 1}. This is confusing and IMHO not OK,
because {3 1 2 1} is not scalable.
2. In the files ttkTreeview.c and winTheme.tcl you set the default value
of the "-indicatorsize" option of the Heading element to 3.5p, contrary
to the other above-mentioned C and Tcl files, where it is set to 3p.
Apart from being confusing, I wonder why you chose 3.5p, which on an
unscaled screen translates to 4.666... px, i.e., 5 px. BTW, on an
unscaled screen, 5 px corresponds to exactly 3.75p. My proposal:
Eliminate these inconsistencies by using exclusively the value 3p.
3. There are several similar issues regarding the default value of the
"-indicatorsize" option of the Item element. My proposal: (a) In
ttkClassicTheme.c, ttkDefaultTheme.c, altTheme.tcl, classicTheme.tcl,
and winTheme.tcl use the value 6.75p, and (b) in ttkTreeview.c,
clamTheme.tcl, and defaults.tcl use the value 3p.
4. The item indicators of the themes alt, classic, and winnative don't
look as expected: their height is larger than their width. This is
caused by the last 5 lines of the body of the TreeitemIndicatorSize()
function in the files ttkDefaultTheme.c and ttkClassicTheme.c. Please
remove these lines. In addition, re-add the line
if (size % 2 == 0) --size; /* An odd size is better for the
indicator. */
just after line 1473 of ttkDefaultTheme.c and after line 970 of
ttkClassicTheme.c.
5. In ttkTreeview.c, the body of the function TreeitemIndicatorDraw()
should be free of occurrences of ARROW_DOWN and ARROW_RIGHT. Please
replace them with CHEVRON_DOWN and CHEVRON_RIGHT.
6. With the "default" theme the selected items become invisible when the
treeview loses the focus. This is caused by the identical lines 209 and
213 of the file defaults.tcl. To fix this, please replace these lines with
background $colors(-darker) \
and
background $colors(-selectfg) \
respectively.
Best regards,
Csaba
--
Csaba Nemethi https://www.nemethi.de mailto:csa...@t-...
|
|
From: <apn...@ya...> - 2026-04-28 17:46:35
|
> Sorry, what is the limitation? It does not work for child processes?
The App Paths mechanism allows for the environment (PATH in particular) passed to the child process to be specified to be different than that of the current process.
What I meant was that Tcl's exec will always pass on the current process' environment (including PATH) to the child. There is no way for the auto_exec to tell exec to run the child process but with the new PATH environment. Perhaps some future enhancement by adding a -env option to exec might help but right now this limitation remains.
> (proposals for rewording)
Noted, will change accordingly.
> I am not happy, that files not having an executable extension are flagged as executable by "file executable".
Just to be clear on this, even in 9.0, if you rename foo.exe to foo.xyz, "exec foo.xyz" will still work and run the renamed application. However, "file executable foo.xyz" will return 0. This is wrong in imo. If exec can run it, file executable should return 1. As an aside, file executable is not very reliable in any case as it never considers architecture etc. But nevertheless, it should be accurate to the extent possible.
Also note this is different from *finding* the executable. If you type "exec foo", neither 9.0 nor TIP 753 will find and run the executable, even it if is in the PATH, unless .xyz is included in PATHEXT.
> This means: "test\run.exe" is checked for each PATH item, if folder
> "test" exists and "run.exe" exists in the folder?
Yes. This is both Tcl 9.0 and Windows behaviour (I was also surprised and will recheck this). There also seems to be a difference between treatment of "test\run.exe" versus ".\test\run.exe". If indeed Windows behaves this way consistently, we need to decide whether to be consistent with it or not.
> All this is really at the border of bug-fixing...
Indeed so, and like in the case of long path support, I debated a TIP. But in addition to support for app paths, other changes do affect behavior compared to 9.0 so decided a TIP was warranted. If folks are in agreement the changes are acceptable without a TIP, I'm happy to not have a vote and withdraw the TIP :-)
>-> registry "safe search"? I think, it is the user expectation to follow this.
No issues doing this though it makes behavior less predictable across systems. However, in that case if we follow the Windows user expectations, one can argue we should do that even in the case of the relative path searches as discussed above.
All in all, I don't think most folks will care one way or another but I do want fix those long outstanding tickets.
Thanks for the detailed feedback.
/Ashok
-----Original Message-----
From: Harald Oehlmann <har...@el...>
Sent: Tuesday, April 28, 2026 7:55 PM
To: tcl...@li...
Subject: Re: [TCLCORE] TIP 753: Windows auto_execok enhancements and reform
Hi Ashok,
thanks again for this very fundamental work!
When reading the TIP, I have the following questions. It is me, no
doubt, but anyway:
Chapter "Support for App Paths (Windows only)", last paragraph:
<cite>
One limitation of this support is that while the underlying Windows
mechanism allows modification of the process environment passed to the
child process, this is not possible due to the lack of such a capability
within both exec and the auto_execok to exec "interface".
</cite>
Sorry, what is the limitation? It does not work for child processes?
E.g. exec {tclsh exec}?
English Grammer to complicated for my capability...
Chapter "Handling of PATHEXT extensions (Windows only)", first
paragraph, 2nd phrase:
<cite>
Currently auto_execok looks up this environment variable but depending
on the extension, the returned command is not in a form cannot be
executed by exec.
</cite>
<proposal>
Current auto_execok implementation looks up this environment variable.
For some extensions, the returned command is not in a form which can be
executed by exec directly. The command "exec {*}[auto_execok my.vbs]"
will fail (but will work with the modification below).
</proposal>
Chapter "NOTE"
<cite>
Unlike auto_execok, exec in 9.0 only searches for exe, com and bat not
the extensions in PATHEXT.
</cite>
<proposal>
"exec" in 9.0 only searches for the extensions "exe", "com", "bat" and
not the extensions listed in PATHEXT. This is a difference to "auto_execok".
</proposal>
Chapter "Changes to file executable (Windows only)"
I am not happy, that files not having an executable extension are
flagged as executable by "file executable".
If I rename an exe from "run.exe" to "run.exe.disabled", I don't want it
executed. Same for "run.bat" to "run.bat.disabled".
If this is documented, we may change the documentation?
Chapter "Maintenance inconsistencies", 2nd paragraph
<cite>
Windows exec searches PATH when passed a relative path unlike Unix exec
and auto_execok on all platforms. Windows itself exhibits this
difference between CreateProcess, `ShellExecute** and the command line.
</cite>
I had to read 3 times to get the English.
This means: "test\run.exe" is checked for each PATH item, if folder
"test" exists and "run.exe" exists in the folder?
I am not happy with this neither, sorry. For me, relative paths are
always relative to pwd...
All this is really at the border of bug-fixing...
Chapter "Reminders (for self)"
-> build-ins? like "echo" ?
-> registry "safe search"? I think, it is the user expectation to follow
this.
Thanks for the great work and take care,
Harald
Am 28.04.2026 um 15:53 schrieb apnmbx-public--- via Tcl-Core:
> TIP 753: Windows auto_execok enhancements and reform <https://core.tcl-
> lang.org/tips/doc/trunk/tip/753.md> is ready for initial review.
>
> Mainly directed towards Windows users with some enhancements and to
> clean up some bugs/warts in behavior.
>
> CFV planned to start May 13^th , ending May 20^th .
>
> /Ashok
>
|
|
From: Harald O. <har...@el...> - 2026-04-28 17:24:58
|
Dear Tcl/Tk team, Please feel invited to the next Tcl/Tk biweekly telco: 4th of May at 12:00 UTC Duration: 1 hour At: https://meet.jit.si/TclMonthlyMeetup Agenda proposal: Top 1) Release calender (TIP 713) Current release calender: April 8.6.18 Final Tcl 8.6 release May 9.0.4 June 9.1b0 Tcl 9.1 Feature Freeze August 9.1b1 September 9.1.0, 9.0.5 New stable release sequence October November 9.1.1 December 9.0.6 Final Tcl 9.0 release Top 2) TIP 753: auto_execok on MS-Win Top 3) Timer_API with long long Top 4..6 will for sure come on Sunday... Top 7) AOB Top 8) next meeting: 18th of May 2026 (perhaps later at the day (Don)) Thank you for all, Harald |
|
From: Harald O. <har...@el...> - 2026-04-28 17:20:50
|
Dear TCT members, this is a call for vote for TIP 751 "rotated text for labels". The vote is until 6th of May 12:00 UTC I am AFK from now til Monday. If there is additional discussion or a contribution on "ttk::label -textangle 90 -width 10", I am ready to delay or to enlarge the period. My vote: yes --- TIP 751 END --- --- TIP 750 --- TIP 750 vote ends tomorrow. There are 3 yes and no other votes at the moment. I am not available tomorrow. Marc may merge this one, if he likes. Otherwise, I will do it next week. I want to thank Emiliano and Mark to have implemented the auto mode on MS-Windows. Now, we have a really consistent solution ! A theme may detect by: winfo isdark . if dark mode is active on both platforms. And they are automatically set. Thanks for all! --- Donal has called two TIPS and this one goes in addition. Ashok 753 and Jan 752 will follow. Great work, guys, I appreciate ! Harald |
|
From: <apn...@ya...> - 2026-04-28 16:44:24
|
TIP 745: YES. No brainer, new functionality. TIP 735: YES. Not new functionality but convenient for one of the most common uses of lmap. Being faster is a bonus. An idle comment a little bit along the lines of what Pietro was saying ... at this point I presume we have abandoned the idea of a "list" ensemble command a la string. "lutil filter|zip" etc. Unlike Donal (if I understood him correctly), I do see a use for additional list commands beyond what Donal listed from Python. Presumably they will be all added as global commands if accepted. Otherwise, this might have been a good time to introduce an "lutil" ensemble with filter as a subcommand. /Ashok From: Donal Fellows <don...@ma...> Sent: Monday, April 27, 2026 9:03 PM To: Tcl Core <tcl...@li...> Subject: Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99" I tend to feel that operations shouldn't just be justified by a grand plan. A wall is not just built by imagining it's totality, but also by the placing of each brick where it belongs. For the operations you list: * Fold is obviated by variadic operators; we just do an expanded application. It's a slightly different generalisation. * Take and Drop are just simple applications of lrange. * Nth is exactly within what lindex does. * Iota is lseq. Thinking about the other common operations in Python: * We could perhaps do with enumerate <https://docs.python.org/3/library/functions.html#enumerate> (), all <https://docs.python.org/3/library/functions.html#all> () and any <https://docs.python.org/3/library/functions.html#any> () sometime; they can be useful. * We don't have zip <https://docs.python.org/3/library/functions.html#zip> (), but don't need it so much either (again, that variadicity). * We don't agonise over the difference between tuples and lists, and don't have user-defined generators for various reasons at the moment. * Sorting and searching by a collation key are annoying operations right now, nor do we support min() or max() with a measure function. Thinking about operations from Java's List and ArrayList (similarly for C# but with different names): * We've nothing like containsAll <https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/List .html#containsAll(java.util.Collection)> () or removeAll <https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/List .html#removeAll(java.util.Collection)> ()/retainAll(). We could perhaps do with something like partition <https://smlfamily.github.io/Basis/list.html#SIG:LIST.partition:VAL> <https://smlfamily.github.io/Basis/list.html#SIG:LIST.partition:VAL> from SML, though it might be low priority. You can probably list other things from other languages, but I believe the above cover all the common cases that we don't already have. We could also perhaps do with some operations more like those for (insertion-time ordered, much as dicts are insertion-time ordered) sets. They're reasonably useful. Linked lists and actual balanced trees... not so useful except in special circumstances. I've never missed having them! But this is a huge scope-creep relative to my TIP, so others may pursue it, but I'll not do so here. I believe that lfilter is useful in itself. Donal. _____ From: Pietro Cerutti Sent: Monday, April 27, 2026 09:54 To: Donal Fellows Cc: Tcl Core Subject: Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99" wouldn't it be better if we drafted a TIP for a complete set of list operations? Some of the functions of tcllib's struct::list such as reverse and map are already part of core (lreverse, lmap). How about we draft a set of function that we recognize being generally useful for lists and provide a complete set. I can think of, e.g., fold, take, drop, nth, iota. |
|
From: Jan N. <jan...@gm...> - 2026-04-28 16:11:12
|
Op ma 27 apr 2026 om 10:11 schreef Harald Oehlmann:
> Hi Brad,
>
> thanks for the message. Generally, anything is possible. It would
> nevertheless be great, to author a TIP. Even, if only the documentation
> is changed. If it is not a breaking change, we can do it for Tk 9.1/9.2...
>
I don't think there's a problem, not even in the documentation. The
last documented field in Tk_ImageType is the deleteProc. Not even
the postscriptProc was ever documented. Since the normal use is a
single Tk_CreateImageType (there is no Tk_DeleteImageType) after
which the data is available as long as the thread is available. So, if
you make sure the clientData is not accessed any more after the
thread is gone, all is OK.
Proposal:
<https://core.tcl-lang.org/tk/info/6111d606861ad116>
If there are no objections, I'm OK to commit this to trunk.
Regards,
Jan Nijtmans
|
|
From: Harald O. <har...@el...> - 2026-04-28 15:45:38
|
Am 28.04.2026 um 17:30 schrieb da Silva, Peter J via Tcl-Core:
> set values {1 2 3 4 5 6 7 8}
> proc isEven {n} {expr {($n % 2) == 0}}
> set goodOnes [lmap x $values {expr { [isEven $x] ? $x : [continue] }}]
>
> Any particular reason this is expr {[isEven $x] ? $x : [continue]}
> rather than if {[isEven $x]} {return $x} {continue} which seems a lot
> more idiomatic, readable, and comprehensible to me.
Great proposal! I would write it like:
if {[isEven $x]} {set x} {continue}The "return" directly stops and sets
the return value to "2".
Try:
catch {lmap a {1 2} {set a}} r
-> 0
r=1 2
catch {lmap a {1 2} {return $a}} r
-> 2 ( due to return, may raise error or other side-effects)
r=2
This is very strange, isn't it ;-)...
Thanks for all,
Harald
|
|
From: da S. P. J <pet...@fl...> - 2026-04-28 15:31:06
|
set values {1 2 3 4 5 6 7 8}
proc isEven {n} {expr {($n % 2) == 0}}
set goodOnes [lmap x $values {expr { [isEven $x] ? $x : [continue] }}]
Any particular reason this is expr {[isEven $x] ? $x : [continue]} rather than if {[isEven $x]} {return $x} {continue} which seems a lot more idiomatic, readable, and comprehensible to me.
|
|
From: Harald O. <har...@el...> - 2026-04-28 14:25:04
|
Hi Ashok,
thanks again for this very fundamental work!
When reading the TIP, I have the following questions. It is me, no
doubt, but anyway:
Chapter "Support for App Paths (Windows only)", last paragraph:
<cite>
One limitation of this support is that while the underlying Windows
mechanism allows modification of the process environment passed to the
child process, this is not possible due to the lack of such a capability
within both exec and the auto_execok to exec "interface".
</cite>
Sorry, what is the limitation? It does not work for child processes?
E.g. exec {tclsh exec}?
English Grammer to complicated for my capability...
Chapter "Handling of PATHEXT extensions (Windows only)", first
paragraph, 2nd phrase:
<cite>
Currently auto_execok looks up this environment variable but depending
on the extension, the returned command is not in a form cannot be
executed by exec.
</cite>
<proposal>
Current auto_execok implementation looks up this environment variable.
For some extensions, the returned command is not in a form which can be
executed by exec directly. The command "exec {*}[auto_execok my.vbs]"
will fail (but will work with the modification below).
</proposal>
Chapter "NOTE"
<cite>
Unlike auto_execok, exec in 9.0 only searches for exe, com and bat not
the extensions in PATHEXT.
</cite>
<proposal>
"exec" in 9.0 only searches for the extensions "exe", "com", "bat" and
not the extensions listed in PATHEXT. This is a difference to "auto_execok".
</proposal>
Chapter "Changes to file executable (Windows only)"
I am not happy, that files not having an executable extension are
flagged as executable by "file executable".
If I rename an exe from "run.exe" to "run.exe.disabled", I don't want it
executed. Same for "run.bat" to "run.bat.disabled".
If this is documented, we may change the documentation?
Chapter "Maintenance inconsistencies", 2nd paragraph
<cite>
Windows exec searches PATH when passed a relative path unlike Unix exec
and auto_execok on all platforms. Windows itself exhibits this
difference between CreateProcess, `ShellExecute** and the command line.
</cite>
I had to read 3 times to get the English.
This means: "test\run.exe" is checked for each PATH item, if folder
"test" exists and "run.exe" exists in the folder?
I am not happy with this neither, sorry. For me, relative paths are
always relative to pwd...
All this is really at the border of bug-fixing...
Chapter "Reminders (for self)"
-> build-ins? like "echo" ?
-> registry "safe search"? I think, it is the user expectation to follow
this.
Thanks for the great work and take care,
Harald
Am 28.04.2026 um 15:53 schrieb apnmbx-public--- via Tcl-Core:
> TIP 753: Windows auto_execok enhancements and reform <https://core.tcl-
> lang.org/tips/doc/trunk/tip/753.md> is ready for initial review.
>
> Mainly directed towards Windows users with some enhancements and to
> clean up some bugs/warts in behavior.
>
> CFV planned to start May 13^th , ending May 20^th .
>
> /Ashok
>
|
|
From: Kevin W. <kw...@co...> - 2026-04-28 13:57:26
|
TIP 735: yes TIP 745: yes — Kevin Walzer kw...@co... > On Apr 28, 2026, at 5:26 AM, Jan Nijtmans <jan...@gm...> wrote: > > TIP 735: yes > TIP 745: yes |
|
From: <apn...@ya...> - 2026-04-28 13:54:11
|
TIP 753: Windows auto_execok enhancements and reform <https://core.tcl-lang.org/tips/doc/trunk/tip/753.md> is ready for initial review. Mainly directed towards Windows users with some enhancements and to clean up some bugs/warts in behavior. CFV planned to start May 13th, ending May 20th. /Ashok |
|
From: Donal F. <don...@ma...> - 2026-04-28 13:38:10
|
Once we have a full standard idiom for generators (which I'd encourage work to be done on) then we can worry about folding, but it's possible that the right thing is to make left fold a method of a generator object rather than a global function. (I'm not 100% sure how right-fold works with potentially-unbounded data, assuming one isn't eager to hold the whole computation tree in memory at once.) Out of scope. Something for another day... Donal. ________________________________ From: av...@lo... <av...@lo...> Sent: Tuesday, April 28, 2026 10:48 To: tcl...@li... <tcl...@li...> Subject: Re: [TCLCORE] CFV: TIP 735 "Simpler List Filtering", TIP 745 "Functions from C99" And regarding another topic raised within that thread: "folding": I think that is more relevant with generators, where the complete list might be "theoretically" infinite (with termination happening through exceptions from the operator) or just too large to fit completely in memory, and thus needs to be processed item by item. |
|
From: Jan N. <jan...@gm...> - 2026-04-28 10:26:24
|
Op zo 26 apr 2026 om 13:03 schreef Donal Fellows <
don...@ma...>:
> This is a call for votes on two self-contained TIPs that I've been sitting
> on for far too long.
>
> TIP 735: yes
TIP 745: yes
Regards,
Jan Nijtmans
|
|
From: <av...@lo...> - 2026-04-28 09:48:36
|
Hello Florent,
lfilter is meant just for filtering...
If you want to process the elements, then lmap is the tool.
The difference between
{(...)} and {expr {...}} is not so overwhelming to
justify the big change you propose.
And regarding another topic raised within that thread:
"folding": I think that is more relevant with generators,
where the complete list might be "theoretically" infinite
(with termination happening through exceptions from the
operator) or just too large to fit completely in memory,
and thus needs to be processed item by item.
--
avl
Am 2026-04-28 07:42, schrieb Florent Merlet:
> Hi Mason, hi Donal,
>
> Compared to lmap, there is a need for a test, to know if the result
> must be collected,
> but there is also a need of a body : we may not just want to return
> the first var.
|
|
From: Florent M. <flo...@gm...> - 2026-04-28 05:42:38
|
Hi Mason, hi Donal,
Compared to lmap, there is a need for a test, to know if the result must
be collected,
but there is also a need of a body : we may not just want to return the
first var.
So the interface would be more generic like this :
lfilter var List test body
The "test" script indicating if we must collect or not, the body the
transformation to apply.
But it could even be more general, because we may want to make many
tests, and apply a different transformation for each.
Then it would look more like a switch :
lfilter var List {
{test1} { body1}
{test 2} { body 2}
default {}
}
An empty body would means : don't collect.
a filled body would apply a transform before appending.
lfilter x [lseq 100] {
{(round($x*0.5)*2 == $x)} ($x)
}
Regards
Le 27/04/2026 à 21:28, Mason McParlane a écrit :
> Florent,
>
> Please don’t spam the thread this should stay focused on simple list
> filtering and not other requested features. That is a lot to read
> through and frankly unrelated to the proposed change.
>
>
> Thanks,
> Mason
>
> On Mon, Apr 27, 2026, at 4:01 PM, Florent Merlet wrote:
>> Hi Donal,
>>
>> Le 26/04/2026 à 13:02, Donal Fellows a écrit :
>>>
>>> TIP 735: Simpler List Filtering
>>> <https://core.tcl-lang.org/tips/doc/trunk/tip/735.md>
>>> This adds a global *lfilter *command, because the current idiom for
>>> filtering out items of a list (when *lsearch -inline -all
>>> -not* can't do it) is weird. /I've tried using an expression for the
>>> filter/ (that was the initial version of the TIP /but not the
>>> current one/), which works but feels more annoying to me than using
>>> a script (with expressions available by calling *expr*). I can be
>>> talked round to doing this the other way, but the current way is
>>> marginally simpler to implement (on the interpreted side; the
>>> compiled version is pretty much identically complex).
>>
>> With my proposal
>> <https://github.com/florentis/tcl90-exprSH/tree/core-9-0-branch/install_SH>,
>> you wouldn't have to worry about this existential question :
>> /expression or not expression/ ?
>>
>> Just use {( ... )} to parse any body as an expression.
>> |% lfilter x [lseq 100] {( # Is this value a square number?
>> round($x**0.5)**2 == $x )} 0 1 4 9 16 25 36 49 64 81|
>>
>> Command interface has a prefix notation, while expression interface
>> has infix notation. Both interfaces are producing the same bytecode,
>> which has globally a postfix notation.
>>
>> Command interface is more convenient for strings and list. Expression
>> interface is more convenient for numbers and arithmetic. That's why
>> we may want to choose between the two interfaces, depending on what
>> we like to do.
>>
>> Hence this idea to introduce a syntactical mark, like enclosing a
>> body into parentheses, to quickly access to the expression interface
>> when it is more convenient.
>>
>> This works fine in my prototype :
>>
>> |% lmap x [lseq 100] {( round($x**0.5)**2 == $x ? $x : [continue])}
>> 0 1 4 9 16 25 36 49 64 81
>>
>> % lmap ||s|{abc foo dad} {( [|string equal $s [string reverse $s]|] ?
>> $s : [continue] )}
>> |dad
>>
>> |A lfilter script is :
>>
>> proc lfilter {args} {
>> set body [lindex $args end]
>> set var [lindex $args 0 0]
>> uplevel [list lmap {*}[lrange $args 0 end-1] [format {( [%s] ?
>> "${%s}" : [continue] )} $body $var]]
>> }
>>
>> (bin) 2 % lfilter x [lseq 100] {(
>> # Is this value a square number?
>> round($x**0.5)**2 == $x
>> )}
>> 0 1 4 9 16 25 36 49 64 81
>> |(bin) 3 % lfilter s {abc foo dad} { # Is the string exactly equal to
>> itself when reversed string equal $s [string reverse $s] } dad|
>> Measurements :
>> 1° expr :
>> % timerate {lfilter x [lseq 100] {(
>> # Is this value a square number?
>> round($x**0.5)**2 == $x
>> )}}
>> 246.161 µs/# 4062 # 4062.4 #/sec 999.906 net-ms
>>
>> timerate {
>> lmap x [lseq 100] {(
>> round($x**0.5)**2 == $x ? $x : [continue]
>> )}
>> }
>> 243.434 µs/# 4107 # 4107.9 #/sec 999.782 net-ms
>>
>> timerate {
>> lmap x [lseq 100] {
>> expr {round($x**0.5)**2 == $x ? $x : [continue]}
>> }
>> }
>> 244.795 µs/# 4085 # 4085.1 #/sec 999.987 net-ms
>> |(bin) 3 % lfilter s {abc foo dad} { # Is the string exactly equal to
>> itself when reversed string equal $s [string reverse $s] } dad|
>> 2° String :
>> timerate {lfilter s {abc foo dad} { string equal $s [string reverse
>> $s] }}
>> 31.9969 µs/# 31253 # 31253.0 #/sec 999.999 net-ms
>>
>> timerate {
>> lmap s {abc foo dad} {(
>> [string equal $s [string reverse $s]] ? $s : [continue]
>> )}
>> }
>> 9.166193 µs/# 109096 # 109096 #/sec 999.995 net-ms
>>
>> timerate {lmap s {abc foo dad} {
>> if {[string equal $s [string reverse $s]]} {
>> set s
>> } else continue
>> }}
>> 9.574369 µs/# 104445 # 104445 #/sec 999.995 net-ms
>>
>>
>> About the discussion with Pietro :
>> > while it's neat that we can filter lists with [lmap], the _how_ of
>> it isn't
>> > so nice and _many_ other languages have some sort of filter()
>> > operation, so this felt like a neglected corner.
>> First : the script expr shorthand by itself would imporve the situation.
>>
>> |lmap x [lseq 100] {( round($x**0.5)**2 == $x ? $x : [continue])}
>> is quite clear.
>> ||
>> Second. What is the intend ? It is to build a list thanks to a
>> predicate <https://en.wikipedia.org/wiki/Predicate_(logic)>
>> ||
>> round($x**0.5)**2 == $x
>> |[string equal $s [string reverse $s]]
>> are predicates
>>
>> Third : what is annoying here ? The need to add "[continue]".
>>
>> Historically, Before lmap, we would have used foreach for this|,
>> building a new list piece by piece.
>> When ||the predicate is true, then append|, else nothing
>>
>> set L {}
>> foreach |x [lseq 100] {(
>> ||round($x**0.5)**2 == $x ? [lappend L $x] :;|
>> |)}
>> ||set L
>> 0 1 4 9 16 25 36 49 64 81
>>
>> lmap is build on foreach, it's a collecting foreach.
>>
>> |lmap |x [lseq 100] {(
>> ||round($x**0.5)**2 == $x ? $x : ""|
>> |)}
>> |||0 1 {} {} 4 {} {} {} {} 9 {} {} {} {} {} {} 16 {} {} {} {} {} {}
>> {} {} 25 {} {} {} {} {} {} {} {} {} {} 36 {} {} {} {} {} {} {} {} {}
>> {} {} {} 49 {} {} {} {} {} {} {} {} {} {} {} {} {} {} 64 {} {} {} {}
>> {} {} {} {} {} {} {} {} {} {} {} {} 81 {} {} {} {} {} {} {} {} {} {}
>> {} {} {} {} {} {} {} {} 100
>>
>> lmap collect every value, it doesn't select it.
>> We have to explicitly use the continue command skip what is not wanted.
>>
>> What you seem to expect is a projection (in database language)
>>
>> select $L {(|round($x**0.5)**2)}
>>
>> lmap is more done to "transform" the data, so naturally, the arity
>> remains the same. With this We can lmap Test to get the trace of the
>> predicate on the list.
>>
>> set L [lmap x [lseq 0 100] {(
>> round($x**0.5)**2 == $x
>> )}]
>> 1 1 0 0 1 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0
>> 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0
>> 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
>>
>> To select elements from a list, there is allready a command :
>>
>> lsearch -all $L 1
>> 0 1 4 9 16 25 36 49 64 81 100
>>
>> So maybe it is in this command the interface should be more obvious :
>>
>> lsearch -all -command {{x} {(||round($x**0.5)**2 == $x)}} ||$L
>> ||lsearch -all -command {|{s} {string equal $s [string reverse
>> $s]}|}||||$L|
>> |
>> Regards
>>
>> Florent
>> |
>> |
>> |
>>
>>
>> _______________________________________________
>> 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: Emiliano <emi...@gm...> - 2026-04-27 21:51:49
|
On Fri, 24 Apr 2026 12:28:30 -0700 B Harder <bra...@gm...> wrote: Tk image types are visible at thread level; calling Tk_CreateImageType makes the registerd type to be visible on all intepreters in that thread. If an application needs to maintain a data structure associated with an image type, it can use Tcl_GetThreadData and associated functions without having to resort to using spare fields in a structure. Regards > Hello Tclers. > > I've been working in Tk, specifically w image, and would like run a proposal passed Core. > > In struct Tk_ImageType, generic/tk.h L1257 there is a "char *reserved", which was last updated by Brent Welch nearly 30 (c. 1998) years ago, is semantically marked as a placeholder for some future expansion, and as far as i can tell, not actually referenced anywhere. > > Proposal: can we take this and formally give it to developers as a ClientData clientData entry in the struct? As far as i can tell, it would functionally be a documentation update, not breaking any public APIs or ABIs. > > Best, > -bch -- Emiliano <emi...@gm...> |
|
From: Pietro C. <ga...@ga...> - 2026-04-27 20:00:33
|
On Apr 27 2026, 15:32 +0000, Donal Fellows <don...@ma...> wrote: [-- Type: text/html; charset=iso-8859-1, Encoding: quoted-printable, Size: 11K --] >I tend to feel that operations shouldn't just be justified by a grand plan. A >wall is not just built by imagining it's totality, but also by the placing of >each brick where it belongs. >But this is a huge scope-creep relative to my TIP, so others may pursue >it, but I'll not do so here. I believe that lfilter is useful in >itself. Thanks for taking the time to address my comments, Donal. This is a fair enough conclusion. I might have different preferences and opinions on how to build a consistent and cohesive experience, and we might not even be in agreement that those properties are something worth pursuing at all, but ultimately you're the one doing the job here :) -- Pietro Cerutti I have pledged to give 10% of income to effective charities and invite you to join me - https://givingwhatwecan.org |
|
From: Mason M. <ma...@ba...> - 2026-04-27 19:28:34
|
Florent, Please don’t spam the thread this should stay focused on simple list filtering and not other requested features. That is a lot to read through and frankly unrelated to the proposed change. Thanks, Mason On Mon, Apr 27, 2026, at 4:01 PM, Florent Merlet wrote: > Hi Donal, > > Le 26/04/2026 à 13:02, Donal Fellows a écrit : >> >> TIP 735: Simpler List Filtering <https://core.tcl-lang.org/tips/doc/trunk/tip/735.md> >> This adds a global *lfilter *command, because the current idiom for filtering out items of a list (when *lsearch -inline -all -not* can't do it) is weird. *I've tried using an expression for the filter* (that was the initial version of the TIP *but not the current one*), which works but feels more annoying to me than using a script (with expressions available by calling *expr*). I can be talked round to doing this the other way, but the current way is marginally simpler to implement (on the interpreted side; the compiled version is pretty much identically complex). > > With my proposal <https://github.com/florentis/tcl90-exprSH/tree/core-9-0-branch/install_SH>, > you wouldn't have to worry about this existential question : *expression or not expression* ? > > Just use {( ... )} to parse any body as an expression. > `% lfilter x [lseq 100] {( > # Is this value a square number? > round($x**0.5)**2 == $x > )} > 0 1 4 9 16 25 36 49 64 81` > Command interface has a prefix notation, while expression interface has infix notation. Both interfaces are producing the same bytecode, which has globally a postfix notation. > > Command interface is more convenient for strings and list. Expression interface is more convenient for numbers and arithmetic. That's why we may want to choose between the two interfaces, depending on what we like to do. > > Hence this idea to introduce a syntactical mark, like enclosing a body into parentheses, to quickly access to the expression interface when it is more convenient. > > This works fine in my prototype : > > `% lmap x [lseq 100] {( round($x**0.5)**2 == $x ? $x : [continue])} > 0 1 4 9 16 25 36 49 64 81 > > % lmap ``s` {abc foo dad} {( [`string equal $s [string reverse $s]`] ? $s : [continue] )} > `dad > `A lfilter script is : > > proc lfilter {args} { > set body [lindex $args end] > set var [lindex $args 0 0] > uplevel [list lmap {*}[lrange $args 0 end-1] [format {( [%s] ? "${%s}" : [continue] )} $body $var]] > } > > (bin) 2 % lfilter x [lseq 100] {( > # Is this value a square number? > round($x**0.5)**2 == $x > )} > 0 1 4 9 16 25 36 49 64 81 > `(bin) 3 % lfilter s {abc foo dad} { > # Is the string exactly equal to itself when reversed > string equal $s [string reverse $s] > } > dad` > Measurements : > 1° expr : > % timerate {lfilter x [lseq 100] {( > # Is this value a square number? > round($x**0.5)**2 == $x > )}} > 246.161 µs/# 4062 # 4062.4 #/sec 999.906 net-ms > > timerate { > lmap x [lseq 100] {( > round($x**0.5)**2 == $x ? $x : [continue] > )} > } > 243.434 µs/# 4107 # 4107.9 #/sec 999.782 net-ms > > timerate { > lmap x [lseq 100] { > expr {round($x**0.5)**2 == $x ? $x : [continue]} > } > } > 244.795 µs/# 4085 # 4085.1 #/sec 999.987 net-ms > ` > (bin) 3 % lfilter s {abc foo dad} { > # Is the string exactly equal to itself when reversed > string equal $s [string reverse $s] > } > dad` > 2° String : > timerate {lfilter s {abc foo dad} { string equal $s [string reverse $s] }} > 31.9969 µs/# 31253 # 31253.0 #/sec 999.999 net-ms > > timerate { > lmap s {abc foo dad} {( > [string equal $s [string reverse $s]] ? $s : [continue] > )} > } > 9.166193 µs/# 109096 # 109096 #/sec 999.995 net-ms > > timerate {lmap s {abc foo dad} { > if {[string equal $s [string reverse $s]]} { > set s > } else continue > }} > 9.574369 µs/# 104445 # 104445 #/sec 999.995 net-ms > > > About the discussion with Pietro : > > while it's neat that we can filter lists with [lmap], the _how_ of it isn't > > so nice and _many_ other languages have some sort of filter() > > operation, so this felt like a neglected corner. > First : the script expr shorthand by itself would imporve the situation. > > `lmap x [lseq 100] {( round($x**0.5)**2 == $x ? $x : [continue])} > is quite clear. `` > Second. What is the intend ? It is to build a list thanks to a predicate <https://en.wikipedia.org/wiki/Predicate_(logic)> `` > round($x**0.5)**2 == $x `[string equal $s [string reverse $s]] > are predicates > > Third : what is annoying here ? The need to add "[continue]". > > Historically, Before lmap, we would have used foreach for this`, building a new list piece by piece. > When ``the predicate is true, then append`, else nothing > > set L {} > foreach `x [lseq 100] {( > ``round($x**0.5)**2 == $x ? [lappend L $x] :;` > `)} ``set L > 0 1 4 9 16 25 36 49 64 81 > > lmap is build on foreach, it's a collecting foreach. > `lmap `x [lseq 100] {( > ``round($x**0.5)**2 == $x ? $x : ""` > `)} ```0 1 {} {} 4 {} {} {} {} 9 {} {} {} {} {} {} 16 {} {} {} {} {} {} {} {} 25 {} {} {} {} {} {} {} {} {} {} 36 {} {} {} {} {} {} {} {} {} {} {} {} 49 {} {} {} {} {} {} {} {} {} {} {} {} {} {} 64 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} 81 {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} {} 100 > > lmap collect every value, it doesn't select it. > We have to explicitly use the continue command skip what is not wanted. > > What you seem to expect is a projection (in database language) > > select $L {(`round($x**0.5)**2)} > > lmap is more done to "transform" the data, so naturally, the arity remains the same. With this We can lmap Test to get the trace of the predicate on the list. > > set L [lmap x [lseq 0 100] {( > round($x**0.5)**2 == $x > )}] > 1 1 0 0 1 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 > > To select elements from a list, there is allready a command : > > lsearch -all $L 1 > 0 1 4 9 16 25 36 49 64 81 100 > > So maybe it is in this command the interface should be more obvious : > > lsearch -all -command {{x} {(``round($x**0.5)**2 == $x)}} ``$L ``lsearch -all -command {`{s} {string equal $s [string reverse $s]}`}`` ``$L` > ` > Regards > > Florent ` > ` ` > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
26 messages has been excluded from this view by a project administrator.
