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
(137) |
Dec
|
|
From: Paul O. <pa...@po...> - 2025-11-12 16:24:45
|
Builds and tests run fine on my BAWT environments. Thanks, Paul Am 11.11.2025 um 18:19 schrieb Jan Nijtmans: > Now available at > > https://sourceforge.net/projects/tcl/files/Tcl/9.0.3/ > > are RC2 candidate source code distribution pre-releases of Tcl/Tk 9.0.3 > > This is the third candidate release leading to the release of Tcl/Tk > 9.0.3. Testing of builds > and operations on multiple platforms is invited. Any critical problem > that should block > the release should be reported immediately. > > Only the full *-src.tar.gz files are there, the zip-files and the stripped-down > versions will follow. > > Preliminary release notes are available as well. Please report any > suggestions/improvements you may find. > > I intend to rename those files to the final release in 2 days, > thursday Nov 13. > > > Thank you for your contributions and assistance. > Jan Nijtmans > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: <apn...@ya...> - 2025-11-12 10:19:39
|
Mea culpa then! Would not be the first time I am in disagreement with my younger self.
That Vote line was likely left over inadvertently from using an existing TIP as template. The TIP itself was originally intended as an Informational TIP documenting what *is* as opposed to what *will be*. Somewhere in the discussion in gravitated to the latter.
I'm going to fix the TIP as a Draft but it should be revisited in the next biweekly meeting.
/Ashok
-----Original Message-----
From: Jan Nijtmans <jan...@gm...>
Vote was set as "Done" at the first commit already:
<https://core.tcl-lang.org/tips/info/2e9525916c2047f>
Which was done by ........ Ashok ;-)
Hope this helps,
Jan Nijtmans
>
>
>
> Amongst other things, it requires C11 support in compilers and drops support for Windows versions prior to Windows 10.
>
>
>
> I don’t object to either of these (though the requirement for C11 gives me a bit of pause for users of embedded platforms) but I am curious to know when this vote/decision was explicitly made. I know it was discussed more than once in the online meetings but was not aware of a final decision.
>
>
>
> /Ashok
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
|
|
From: Donal F. <don...@ma...> - 2025-11-12 10:11:51
|
The algorithm for cross references (except in SEE ALSO sections) is to treat every sequence of bold characters as a candidate for being a cross-reference, with the target being the page that contains the command/term that is in bold. Some of those are then suppressed, depending on what page they're in and where they're targeting (see exclude_refs_map — and exclude_when_followed_by_map for the real special cases — in tcltk-man2html.tcl for the suppressions). That's horribly manual, but produces reasonable output. The rewrite to Markdown is generally a good idea, as it will be much more able to get things right in this area. (We also ought to make sure that the target anchors are more sensible than what we had in the old style; I loathe the #M123 stuff in the old pages for just how opaque it is...) Donal. ________________________________ From: Torsten Berg <be...@ty...> Sent: Tuesday, November 11, 2025 23:31 To: Pietro Cerutti <ga...@ga...> Cc: Tcl Core List <tcl...@li...> Subject: Re: [TCLCORE] Manpage updates for review Hi, if TIP 700 will be accepted we will have more freedom and possibilities to make cross-references. So, for now I think it is OK to have duplications. This can be changed later. Right now, the cross-references are generated when the HTML is Right now, the cross-references are generated when the HTML is rendered. They are not explicitly in the nroff but the rendering code guesses what would be a good cross-reference and then renders it as such in the HTML output. This fails at times and is of course not fool-proof. |
|
From: Harald O. <har...@el...> - 2025-11-12 10:03:57
|
Thanks, Donal, the difference public Headers/Code is not in the TIP. It should not be in voted state to my understanding. Thanks, Harald Am 12.11.2025 um 10:48 schrieb Donal Fellows: > Tcl 9.0 and 8.6 remain exactly as they were (for people who are > stuck), /and/ we are being quite a bit more conservative with our public > headers, at least for now. This is literally for building Tcl 9.1 itself. > > Also, embedded platforms may actually benefit from using a newer > compiler. There's a definite non-zero chance that stopping insisting on > remaining in the Century of the Fruitbat will lead to benefits. (When > one searches online for the state of such things, it turns out that the > platforms that have a problem with upgrading tend to be 8-bit and 16-bit > platforms, or older; Tcl's /never /been supported on sub-32-bit anyway.) > > Note that we can't quite go full in on C11 as MSVC has failed to > implement some parts, and has done some other parts poorly; you need to > poke around quite a bit to find those (hint: *max_align_t*). But > variadic macros are just so thoroughly useful for reducing the ugliness > (especially when paired with for-loop-scoping, though that's not this > change) and that's something that MSVC (and gcc and clang) supports. > > Donal. > > ------------------------------------------------------------------------ > *From:* Marc Culler <cul...@gm...> > *Sent:* Wednesday, November 12, 2025 08:09 > *To:* apn...@ya... <apn...@ya...> > *Cc:* tcl...@li... <tcl...@li...> > *Subject:* Re: [TCLCORE] TIP 715 approved? > > > My recollection is that we "decided" that no vote was needed on the TIP, > as it is only providing information, and that the information it > contains would need to be revised over time. > > - Marc > > On Wed, Nov 12, 2025 at 4:54 AM apnmbx-public--- via Tcl-Core <tcl- > co...@li... <mailto:tcl...@li...>> wrote: > > TIP 715 [core.tcl-lang.org] <https://urldefense.com/v3/__https:// > core.tcl-lang.org/tips/doc/trunk/tip/715.md__;!!PDiH4ENfjr2_Jw!Hq- > wn_CkmqWjlb7HPkKP3kxqJBijcx95Yy5-kVaVOopU- > OiErFpBdlSHkp8VizI6kr2pQkjoRGlcn-fAdk8zOm6a8Z6rrw$> /Supported > platforms and build environments for Tcl/Tk 9.1/ shows Vote as Done. > When did this happen? > > Amongst other things, it requires C11 support in compilers and drops > support for Windows versions prior to Windows 10. > > I don’t object to either of these (though the requirement for C11 > gives me a bit of pause for users of embedded platforms) but I am > curious to know when this vote/decision was explicitly made. I know > it was discussed more than once in the online meetings but was not > aware of a final decision. > > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core -- ELMICRON Dr. Harald Oehlmann GmbH Koesener Str. 85 06618 NAUMBURG - Germany Phone: +49 3445 781120 Direct: +49 3445 781127 www.Elmicron.de German legal references: Geschaeftsfuehrer: Dr. Harald Oehlmann UST Nr. / VAT ID No.: DE206105272 HRB 212803 Stendal |
|
From: Donal F. <don...@ma...> - 2025-11-12 09:59:21
|
Tcl 9.0 and 8.6 remain exactly as they were (for people who are stuck), and we are being quite a bit more conservative with our public headers, at least for now. This is literally for building Tcl 9.1 itself. Also, embedded platforms may actually benefit from using a newer compiler. There's a definite non-zero chance that stopping insisting on remaining in the Century of the Fruitbat will lead to benefits. (When one searches online for the state of such things, it turns out that the platforms that have a problem with upgrading tend to be 8-bit and 16-bit platforms, or older; Tcl's never been supported on sub-32-bit anyway.) Note that we can't quite go full in on C11 as MSVC has failed to implement some parts, and has done some other parts poorly; you need to poke around quite a bit to find those (hint: max_align_t). But variadic macros are just so thoroughly useful for reducing the ugliness (especially when paired with for-loop-scoping, though that's not this change) and that's something that MSVC (and gcc and clang) supports. Donal. ________________________________ From: Marc Culler <cul...@gm...> Sent: Wednesday, November 12, 2025 08:09 To: apn...@ya... <apn...@ya...> Cc: tcl...@li... <tcl...@li...> Subject: Re: [TCLCORE] TIP 715 approved? My recollection is that we "decided" that no vote was needed on the TIP, as it is only providing information, and that the information it contains would need to be revised over time. - Marc On Wed, Nov 12, 2025 at 4:54 AM apnmbx-public--- via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote: TIP 715 [core.tcl-lang.org]<https://urldefense.com/v3/__https://core.tcl-lang.org/tips/doc/trunk/tip/715.md__;!!PDiH4ENfjr2_Jw!Hq-wn_CkmqWjlb7HPkKP3kxqJBijcx95Yy5-kVaVOopU-OiErFpBdlSHkp8VizI6kr2pQkjoRGlcn-fAdk8zOm6a8Z6rrw$> Supported platforms and build environments for Tcl/Tk 9.1 shows Vote as Done. When did this happen? Amongst other things, it requires C11 support in compilers and drops support for Windows versions prior to Windows 10. I don’t object to either of these (though the requirement for C11 gives me a bit of pause for users of embedded platforms) but I am curious to know when this vote/decision was explicitly made. I know it was discussed more than once in the online meetings but was not aware of a final decision. |
|
From: Jan N. <jan...@gm...> - 2025-11-12 08:22:49
|
Op wo 12 nov 2025 om 03:54 schreef apnmbx-public--- via Tcl-Core
<tcl...@li...>:
>
> TIP 715 Supported platforms and build environments for Tcl/Tk 9.1 shows Vote as Done. When did this happen?
Vote was set as "Done" at the first commit already:
<https://core.tcl-lang.org/tips/info/2e9525916c2047f>
Which was done by ........ Ashok ;-)
Hope this helps,
Jan Nijtmans
>
>
>
> Amongst other things, it requires C11 support in compilers and drops support for Windows versions prior to Windows 10.
>
>
>
> I don’t object to either of these (though the requirement for C11 gives me a bit of pause for users of embedded platforms) but I am curious to know when this vote/decision was explicitly made. I know it was discussed more than once in the online meetings but was not aware of a final decision.
>
>
>
> /Ashok
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
|
|
From: Marc C. <cul...@gm...> - 2025-11-12 08:09:36
|
My recollection is that we "decided" that no vote was needed on the TIP, as it is only providing information, and that the information it contains would need to be revised over time. - Marc On Wed, Nov 12, 2025 at 4:54 AM apnmbx-public--- via Tcl-Core < tcl...@li...> wrote: > TIP 715 <https://core.tcl-lang.org/tips/doc/trunk/tip/715.md> *Supported > platforms and build environments for Tcl/Tk 9.1* shows Vote as Done. When > did this happen? > > > > Amongst other things, it requires C11 support in compilers and drops > support for Windows versions prior to Windows 10. > > > > I don’t object to either of these (though the requirement for C11 gives me > a bit of pause for users of embedded platforms) but I am curious to know > when this vote/decision was explicitly made. I know it was discussed more > than once in the online meetings but was not aware of a final decision. > > > > /Ashok > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: <apn...@ya...> - 2025-11-12 07:55:27
|
Verified default build + test on Win10 x64 with VS 2022 -----Original Message----- From: Jan Nijtmans <jan...@gm...> Sent: Tuesday, November 11, 2025 10:50 PM To: Tcl Core List <tcl...@li...> Subject: [TCLCORE] Tcl/Tk 9.0.3 Release Candidate Now available at https://sourceforge.net/projects/tcl/files/Tcl/9.0.3/ are RC2 candidate source code distribution pre-releases of Tcl/Tk 9.0.3 This is the third candidate release leading to the release of Tcl/Tk 9.0.3. Testing of builds and operations on multiple platforms is invited. Any critical problem that should block the release should be reported immediately. Only the full *-src.tar.gz files are there, the zip-files and the stripped-down versions will follow. Preliminary release notes are available as well. Please report any suggestions/improvements you may find. I intend to rename those files to the final release in 2 days, thursday Nov 13. Thank you for your contributions and assistance. Jan Nijtmans _______________________________________________ Tcl-Core mailing list Tcl...@li... https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: <apn...@ya...> - 2025-11-12 02:54:29
|
TIP 715 <https://core.tcl-lang.org/tips/doc/trunk/tip/715.md> Supported platforms and build environments for Tcl/Tk 9.1 shows Vote as Done. When did this happen? Amongst other things, it requires C11 support in compilers and drops support for Windows versions prior to Windows 10. I don't object to either of these (though the requirement for C11 gives me a bit of pause for users of embedded platforms) but I am curious to know when this vote/decision was explicitly made. I know it was discussed more than once in the online meetings but was not aware of a final decision. /Ashok |
|
From: Torsten B. <be...@ty...> - 2025-11-11 23:32:22
|
Hi, if TIP 700 will be accepted we will have more freedom and possibilities to make cross-references. So, for now I think it is OK to have duplications. This can be changed later. Right now, the cross-references are generated when the HTML is rendered. They are not explicitly in the nroff but the rendering code guesses what would be a good cross-reference and then renders it as such in the HTML output. This fails at times and is of course not fool-proof. When using markdown (TIP 700), cross-references will be made explicitly in the markdown sources already. (Unfortunately, I did not have the time to work further on TIP 700 lately but will hopefully soon be able to pick that up again!) Regards, Torsten > Am 12.11.2025 um 01:42 schrieb Pietro Cerutti via Tcl-Core <tcl...@li...>: > > The Tcl.n manpage references at least the set command. In general, our man pages are full of cross references, at least when they are rendered to html. > > Here's a section referencing [set]: > https://www.tcl-lang.org/man/tcl9.1/TclCmd/Tcl.html#M15 > > -- > Pietro Cerutti > I've pledged to give 10% of income to effective charities and invite you to join me. > https://givingwhatwecan.org > > Sent from a small device - please excuse brevity and typos. > > >> On 11 Nov 2025, at 16:34, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote: >> >> I thought about that, or putting in the Tcl.n manpage. Both would be easier to maintain. But felt it's easier to reference if it's right on top of affected pages. It would be different if there was a way to link across pages but I don't think that's possible in nroff, even for generated HTML. >> >> We'll see what others think but in any case the wording is more important right now. The layout/structure can be changed. >> >> /Ashok >> >> -----Original Message----- >> From: Pietro Cerutti <ga...@ga...> >> >> Would it make sense to descibe TUTF-8 in its own dedicated man page and >> referent to it, instead of duplicating the description across different >> man pages? >> >> >> >> >> >> _______________________________________________ >> 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: Jan N. <jan...@gm...> - 2025-11-11 17:20:12
|
Now available at https://sourceforge.net/projects/tcl/files/Tcl/9.0.3/ are RC2 candidate source code distribution pre-releases of Tcl/Tk 9.0.3 This is the third candidate release leading to the release of Tcl/Tk 9.0.3. Testing of builds and operations on multiple platforms is invited. Any critical problem that should block the release should be reported immediately. Only the full *-src.tar.gz files are there, the zip-files and the stripped-down versions will follow. Preliminary release notes are available as well. Please report any suggestions/improvements you may find. I intend to rename those files to the final release in 2 days, thursday Nov 13. Thank you for your contributions and assistance. Jan Nijtmans |
|
From: Pietro C. <ga...@ga...> - 2025-11-11 16:45:31
|
The Tcl.n manpage references at least the set command. In general, our man pages are full of cross references, at least when they are rendered to html. Here's a section referencing [set]: https://www.tcl-lang.org/man/tcl9.1/TclCmd/Tcl.html#M15 -- Pietro Cerutti I've pledged to give 10% of income to effective charities and invite you to join me. https://givingwhatwecan.org Sent from a small device - please excuse brevity and typos. > On 11 Nov 2025, at 16:34, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote: > > I thought about that, or putting in the Tcl.n manpage. Both would be easier to maintain. But felt it's easier to reference if it's right on top of affected pages. It would be different if there was a way to link across pages but I don't think that's possible in nroff, even for generated HTML. > > We'll see what others think but in any case the wording is more important right now. The layout/structure can be changed. > > /Ashok > > -----Original Message----- > From: Pietro Cerutti <ga...@ga...> > > Would it make sense to descibe TUTF-8 in its own dedicated man page and > referent to it, instead of duplicating the description across different > man pages? > > > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Pietro C. <ga...@ga...> - 2025-11-11 16:42:30
|
The Tcl.n manpage references at least the set command. In general, our man pages are full of cross references, at least when they are rendered to html. Here's a section referencing [set]: https://www.tcl-lang.org/man/tcl9.1/TclCmd/Tcl.html#M15 -- Pietro Cerutti I've pledged to give 10% of income to effective charities and invite you to join me. https://givingwhatwecan.org Sent from a small device - please excuse brevity and typos. > On 11 Nov 2025, at 16:34, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote: > > I thought about that, or putting in the Tcl.n manpage. Both would be easier to maintain. But felt it's easier to reference if it's right on top of affected pages. It would be different if there was a way to link across pages but I don't think that's possible in nroff, even for generated HTML. > > We'll see what others think but in any case the wording is more important right now. The layout/structure can be changed. > > /Ashok > > -----Original Message----- > From: Pietro Cerutti <ga...@ga...> > > Would it make sense to descibe TUTF-8 in its own dedicated man page and > referent to it, instead of duplicating the description across different > man pages? > > > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: <apn...@ya...> - 2025-11-11 15:37:32
|
I noticed it too, in CrtCommand.3 I do know the encoding is actually expected to be TUTF-8 but had no idea what the term "normalized" refers to so I left it unchanged. -----Original Message----- Side note: At one point, the documentation speaks about "normalized (T)UTF-8". I only saw it in the diff. Normalized utf-8 is a big word... |
|
From: <apn...@ya...> - 2025-11-11 15:33:59
|
I thought about that, or putting in the Tcl.n manpage. Both would be easier to maintain. But felt it's easier to reference if it's right on top of affected pages. It would be different if there was a way to link across pages but I don't think that's possible in nroff, even for generated HTML. We'll see what others think but in any case the wording is more important right now. The layout/structure can be changed. /Ashok -----Original Message----- From: Pietro Cerutti <ga...@ga...> Would it make sense to descibe TUTF-8 in its own dedicated man page and referent to it, instead of duplicating the description across different man pages? |
|
From: Torsten B. <be...@ty...> - 2025-11-11 15:24:01
|
Great, will test this tomorrow! Regards, Torsten > Am 11.11.2025 um 22:38 schrieb Jan Nijtmans <jan...@gm...>: > > Op di 11 nov 2025 om 12:37 schreef Torsten Berg <be...@ty...>: >> I keep getting this error on macOS (Ventrua 13.7.8) > .... >> ld: Undefined symbols: >> >> _Tcl_GetBoolFromObj, referenced from: >> >> _DbMain in tclsqlite3.o > > I managed to reproduce this. The problem was in tclDecls.h. The macro > deciding between Tcl_GetBooleanFromObj and Tcl_GetBoolFromObj > only works as intended in optimized builds: The linker will discover > that Tcl_GetBoolFromObj is never used in a Tcl8 build, and simply > removes the call. In non-optimized builds, that doesn't happen. > > Fix committed. This means there will be a rc2 > <https://core.tcl-lang.org/tcl/info/44c0681b3b238ae7> > >> I had trouble compiling SQLite 3.51.0 from its sources too, until a user fixed a problem: >> https://sqlite.org/forum/forumpost/389916bad5 > > This is a different thing. My recommendation is always to build > with stubs (USE_TCL_STUBS=1) and link with the stubs library. > The default SQLite build doesn't do that, it just keeps the > symbols undefined, hoping they can be found at runtime. > Most platforms can do that, but at least Windows and AIX cannot. > > Thanks! > Jan Nijtmans |
|
From: <apn...@ya...> - 2025-11-11 15:16:32
|
Not true any more though it was true for Tcl 8. Java MUTF-8 encodes non-BMP code points as pair of surrogates encoded into two 3-byte UTF-8 units. Tcl 9 encodes as it as standard 4 byte UTF8 sequence. Nor does it use CESU-8 for external data. Someone should correct Wikipedia 😊 From: Andreas Kupries <aku...@su...> Sent: Tuesday, November 11, 2025 6:36 PM To: Pietro Cerutti <ga...@ga...>; apn...@ya...; Tcl Core List <tcl...@li...> Subject: Re: [TCLCORE] Manpage updates for review Note https://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8 > Java <https://en.wikipedia.org/wiki/Java_(programming_language)> internally uses UTF-16 for the char data type and, consequentially, > the Character, String, and the StringBuffer classes, <https://en.wikipedia.org/wiki/UTF-8#cite_note-61> [61] but > for I/O uses Modified UTF-8 (MUTF-8), in which the null character <https://en.wikipedia.org/wiki/Null_character> U+0000 > uses the two-byte overlong encoding 0xC0, 0x80, instead of just 0x00. <https://en.wikipedia.org/wiki/UTF-8#cite_note-:2-18> [18] And: > Tcl <https://en.wikipedia.org/wiki/Tcl> also uses the same modified UTF-8 <https://en.wikipedia.org/wiki/UTF-8#cite_note-68> [68] as Java for internal > representation of Unicode data, but uses strict CESU-8 for external data. (https://en.wikipedia.org/wiki/CESU-8) On Tue, Nov 11, 2025 at 2:00 PM Pietro Cerutti via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > wrote: On Nov 11 2025, 05:33 +0000, apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > wrote: [-- Type: text/html; charset=utf-8, Encoding: quoted-printable, Size: 4.9K --] >The branch [1]apn-doc-update contains manpage updates addressing two areas – > > > > ● added a section in Tcl.n that defines Tcl string value as a sequence of > Unicode code points. > ● updates to various command and C API pages that wrongly identify Tcl’s > internal format as UTF-8. For this purpose the encoding name TUTF-8 has > been introduced to reference Tcl’s internal modified UTF-8 format. > > > >Reviews appreciated and improvements welcome. Both have been a pet peeve with >me for a long time (and probably no one else!) in that the first is important >missing information and the second is misinformation. Would it make sense to descibe TUTF-8 in its own dedicated man page and referent to it, instead of duplicating the description across different man pages? -- Pietro Cerutti I have pledged to give 10% of income to effective charities and invite you to join me - https://givingwhatwecan.org _______________________________________________ Tcl-Core mailing list Tcl...@li... <mailto:Tcl...@li...> https://lists.sourceforge.net/lists/listinfo/tcl-core -- Andreas Kupries - SUSE Software Solutions Germany GmbH, Frankenstr. 146, 90461 Nürnberg, Germany, <http://www.suse.com/> www.suse.com, Geschäftsführer: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg) |
|
From: <apn...@ya...> - 2025-11-11 15:02:51
|
Hi Harald, Please see files tclMutexTest.c and mutex.test starting with commit https://core.tcl-lang.org/tcl/info/d23568f2a326fa04. It covers both mutexes and condition variables. -----Original Message----- From: Harald Oehlmann <har...@el...> Can you give a hint how this may be tested? |
|
From: <apn...@ya...> - 2025-11-11 14:56:14
|
Tcl’s internal objPtr->bytes is still modified UTF-8 with 0x00 mapped to 0xC0 0x80. A standard UTF-8 with embedded nuls (potentially) would break too much of existing code (both in core and extensions) that relies on C string functions to manipulate values. The only thing that has changed with respect to Tcl 8 is the entire assigned Unicode range is covered (sizeof(Tcl_UniChar) == 4 and TCL_UTF_MAX == 4 instead of 2 and 3 respectively as in stock Tcl 8) so non-BMP code points are directly encoded as opposed to using surrogates. From: da Silva, Peter J <pet...@fl...> Sent: Tuesday, November 11, 2025 7:38 PM To: apn...@ya...; 'Tcl Core List' <tcl...@li...> Subject: Re: [TCLCORE] Manpage updates for review > updates to various command and C API pages that wrongly identify Tcl’s internal format as UTF-8. For this purpose the encoding name TUTF-8 has been introduced to reference Tcl’s internal modified UTF-8 format. I thought Tcl 9 finally made TCL strings into UTF-8 internally and obviated the need to convert them to and from UTF-8 when calling other environments (like Python or Postgresql)... is this not the case? From: apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > Date: Monday, November 10, 2025 at 23:34 To: 'Tcl Core List' <tcl...@li... <mailto:tcl...@li...> > Subject: [TCLCORE] Manpage updates for review CAUTION - EXTERNAL EMAIL: This message originated from outside of your organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. The branch <https://urldefense.us/v2/url?u=https-3A__core.tcl-2Dlang.org_tcl_timeline-3Fr-3Dapn-2Ddoc-2Dupdate&d=DwMFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=JPydYc3WmchrVER3ue-o7QYYU-lFKvlPTkt9jqpcIUTK3-kQm_LGZzaHSdPoQuyg&s=47_85xjE6jLPvhw3Rzitublogw6LJMdDREHzwqi3c14&e=> apn-doc-update contains manpage updates addressing two areas – * added a section in Tcl.n that defines Tcl string value as a sequence of Unicode code points. * updates to various command and C API pages that wrongly identify Tcl’s internal format as UTF-8. For this purpose the encoding name TUTF-8 has been introduced to reference Tcl’s internal modified UTF-8 format. Reviews appreciated and improvements welcome. Both have been a pet peeve with me for a long time (and probably no one else!) in that the first is important missing information and the second is misinformation. I plan to merge in a couple of weeks. Silence will be construed as approval 😊 /Ashok |
|
From: da S. P. J <pet...@fl...> - 2025-11-11 14:08:00
|
> updates to various command and C API pages that wrongly identify Tcl’s internal format as UTF-8. For this purpose the encoding name TUTF-8 has been introduced to reference Tcl’s internal modified UTF-8 format. I thought Tcl 9 finally made TCL strings into UTF-8 internally and obviated the need to convert them to and from UTF-8 when calling other environments (like Python or Postgresql)... is this not the case? From: apnmbx-public--- via Tcl-Core <tcl...@li...> Date: Monday, November 10, 2025 at 23:34 To: 'Tcl Core List' <tcl...@li...> Subject: [TCLCORE] Manpage updates for review CAUTION - EXTERNAL EMAIL: This message originated from outside of your organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. The branch apn-doc-update<https://urldefense.us/v2/url?u=https-3A__core.tcl-2Dlang.org_tcl_timeline-3Fr-3Dapn-2Ddoc-2Dupdate&d=DwMFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=JPydYc3WmchrVER3ue-o7QYYU-lFKvlPTkt9jqpcIUTK3-kQm_LGZzaHSdPoQuyg&s=47_85xjE6jLPvhw3Rzitublogw6LJMdDREHzwqi3c14&e=> contains manpage updates addressing two areas – * added a section in Tcl.n that defines Tcl string value as a sequence of Unicode code points. * updates to various command and C API pages that wrongly identify Tcl’s internal format as UTF-8. For this purpose the encoding name TUTF-8 has been introduced to reference Tcl’s internal modified UTF-8 format. Reviews appreciated and improvements welcome. Both have been a pet peeve with me for a long time (and probably no one else!) in that the first is important missing information and the second is misinformation. I plan to merge in a couple of weeks. Silence will be construed as approval 😊 /Ashok |
|
From: Colin M. <col...@ya...> - 2025-11-11 14:02:49
|
I did consider something like that myself - perhaps `setexpr a
{expression}`. But that does not help with writing a simple expression
as one of the arguments to another command. On the other hand, if you
have [= expression] then you can easily write `set a [= expr] which is
just as short, so a new [=] command helps both cases.
Colin.
On 11/11/2025 13:46, da Silva, Peter J wrote:
> I can't edit the wiki but I have to say that I really like the idea of
> making "set a = {expr}" a special case since it doesn't conflict with
> any legal code.
>
> *From: *Phillip Brooks <phi...@um...>
> *Date: *Friday, November 7, 2025 at 15:43
> *To: *Tcl Core List <tcl...@li...>
> *Subject: *Re: [TCLCORE] [Ext] Re: [=] for concise expressions (was
> Re: TIP 672 Implementation Complete - Ready for Sponsorship)
>
> CAUTION - EXTERNAL EMAIL:
> This message originated from outside of your organization. Do not
> click links or open attachments unless you recognize the sender and
> know the content is safe.
> Hi all,
> I started a wiki page that tries to summarize the various proposals
> under discussion:
> https://wiki.tcl-lang.org/page/A+Better+way+to+do+calculations
> <https://urldefense.us/v2/url?u=https-3A__wiki.tcl-2Dlang.org_page_A-2BBetter-2Bway-2Bto-2Bdo-2Bcalculations&d=DwMFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=TGv7ND_9Tnu15M7Z5KWhrcLWCUL2jQqdaUdwpmzPjmDh4DSXn21OWV7U9xfZVx5x&s=hT7sO8qd7IUadbeHgZWmIMUHP5wcGPwP2RdfHOhQj7w&e=>.
> Please contribute by adding to and modifying the page with concise
> descriptions. Let's not try to carry out debates there, but,
> rather, make it a clear and concise description of the alternatives
> that we are considering. I have sort of lost track of where we are
> with this right now.
>
> Regarding the last few emails concerning exposing the
> tcl::unsupported::assemble command, I think the hesitancy there will
> be with what users do with retrieved assembly code once they have it.
> Will they store it and expect it to work across Tcl versions? Will
> they attempt to modify it and expect the modifications to work across
> Tcl versions? Those are very real reasons for proceeding with caution
> in that regard. I think we are much better off concluding a useful
> syntax and going with that in the Tcl core rather than trying to make
> this a toolkit that allows everyone to solve the underlying problem on
> their own.
>
> Phil
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: da S. P. J <pet...@fl...> - 2025-11-11 13:46:52
|
I can't edit the wiki but I have to say that I really like the idea of making "set a = {expr}" a special case since it doesn't conflict with any legal code.
From: Phillip Brooks <phi...@um...>
Date: Friday, November 7, 2025 at 15:43
To: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] [Ext] Re: [=] for concise expressions (was Re: TIP 672 Implementation Complete - Ready for Sponsorship)
CAUTION - EXTERNAL EMAIL:
This message originated from outside of your organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi all,
I started a wiki page that tries to summarize the various proposals under discussion: https://wiki.tcl-lang.org/page/A+Better+way+to+do+calculations<https://urldefense.us/v2/url?u=https-3A__wiki.tcl-2Dlang.org_page_A-2BBetter-2Bway-2Bto-2Bdo-2Bcalculations&d=DwMFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=TGv7ND_9Tnu15M7Z5KWhrcLWCUL2jQqdaUdwpmzPjmDh4DSXn21OWV7U9xfZVx5x&s=hT7sO8qd7IUadbeHgZWmIMUHP5wcGPwP2RdfHOhQj7w&e=>. Please contribute by adding to and modifying the page with concise descriptions. Let's not try to carry out debates there, but, rather, make it a clear and concise description of the alternatives that we are considering. I have sort of lost track of where we are with this right now.
Regarding the last few emails concerning exposing the tcl::unsupported::assemble command, I think the hesitancy there will be with what users do with retrieved assembly code once they have it. Will they store it and expect it to work across Tcl versions? Will they attempt to modify it and expect the modifications to work across Tcl versions? Those are very real reasons for proceeding with caution in that regard. I think we are much better off concluding a useful syntax and going with that in the Tcl core rather than trying to make this a toolkit that allows everyone to solve the underlying problem on their own.
Phil
|
|
From: Jan N. <jan...@gm...> - 2025-11-11 13:39:10
|
Op di 11 nov 2025 om 12:37 schreef Torsten Berg <be...@ty...>:
> I keep getting this error on macOS (Ventrua 13.7.8)
....
> ld: Undefined symbols:
>
> _Tcl_GetBoolFromObj, referenced from:
>
> _DbMain in tclsqlite3.o
I managed to reproduce this. The problem was in tclDecls.h. The macro
deciding between Tcl_GetBooleanFromObj and Tcl_GetBoolFromObj
only works as intended in optimized builds: The linker will discover
that Tcl_GetBoolFromObj is never used in a Tcl8 build, and simply
removes the call. In non-optimized builds, that doesn't happen.
Fix committed. This means there will be a rc2
<https://core.tcl-lang.org/tcl/info/44c0681b3b238ae7>
> I had trouble compiling SQLite 3.51.0 from its sources too, until a user fixed a problem:
> https://sqlite.org/forum/forumpost/389916bad5
This is a different thing. My recommendation is always to build
with stubs (USE_TCL_STUBS=1) and link with the stubs library.
The default SQLite build doesn't do that, it just keeps the
symbols undefined, hoping they can be found at runtime.
Most platforms can do that, but at least Windows and AIX cannot.
Thanks!
Jan Nijtmans
|
|
From: Harald O. <har...@el...> - 2025-11-11 13:25:43
|
Am 08.11.2025 um 04:41 schrieb apnmbx-public--- via Tcl-Core: > The apn-win-native-cv branch contains a patch to use native condition > variables on Windows instead of Tcl’s homegrown version. There are no > functional or API changes so not planning on a TIP. > > Reviews welcome, else will merge in a couple of weeks. > > /Ashok Dear Ashok, thanks for the work. I am always in favour to use native code. The advantage is, that eventual bugs are fixed in the operating system and we get the bug fixing for free. That is also the reason for me, not to use OpenSSL on Windows. Then, I have to care about bug fixing, as I have to provide the library. Can you give a hint how this may be tested? Thanks for all, Harald |
|
From: Harald O. <har...@el...> - 2025-11-11 13:17:54
|
Hi Andreas, thank you for the pointer. The Wiki page is not correct any more, as TCL9 does not use CESU-8 internally any more. Neverhteless, the name "TUTF-8" is great for clarification in our documentation. In the case that the documentation change gets to 8.6, the CESU-8 issue should also be evaluated. Take care, Harald Am 11.11.2025 um 14:06 schrieb Andreas Kupries via Tcl-Core: > Note https://en.wikipedia.org/wiki/UTF-8#Modified_UTF-8 <https:// > en.wikipedia.org/wiki/UTF-8#Modified_UTF-8> > > Java <https://en.wikipedia.org/wiki/Java_(programming_language)> > internally uses UTF-16 for the /char/ data type and, consequentially, > > the /Character/, /String/, and the /StringBuffer/ classes,^[61] > <https://en.wikipedia.org/wiki/UTF-8#cite_note-61> but > > for I/O uses /Modified UTF-8/ (MUTF-8), in which the null character > <https://en.wikipedia.org/wiki/Null_character> U+0000 > > uses the two-byte overlong encoding 0xC0, 0x80, instead of just > 0x00.^[18] <https://en.wikipedia.org/wiki/UTF-8#cite_note-:2-18> > And: > > Tcl <https://en.wikipedia.org/wiki/Tcl> also uses the same modified > UTF-8^[68] <https://en.wikipedia.org/wiki/UTF-8#cite_note-68> as Java > for internal > > representation of Unicode data, but uses strict CESU-8 for external data. > > (https://en.wikipedia.org/wiki/CESU-8 <https://en.wikipedia.org/wiki/ > CESU-8>) > > On Tue, Nov 11, 2025 at 2:00 PM Pietro Cerutti via Tcl-Core <tcl- > co...@li... <mailto:tcl...@li...>> wrote: > > On Nov 11 2025, 05:33 +0000, apnmbx-public--- via Tcl-Core <tcl- > co...@li... <mailto:tcl...@li...>> > wrote: > [-- Type: text/html; charset=utf-8, Encoding: quoted-printable, > Size: 4.9K --] > >The branch [1]apn-doc-update contains manpage updates addressing > two areas – > > > > > > > > ● added a section in Tcl.n that defines Tcl string value as a > sequence of > > Unicode code points. > > ● updates to various command and C API pages that wrongly > identify Tcl’s > > internal format as UTF-8. For this purpose the encoding name > TUTF-8 has > > been introduced to reference Tcl’s internal modified UTF-8 format. > > > > > > > >Reviews appreciated and improvements welcome. Both have been a pet > peeve with > >me for a long time (and probably no one else!) in that the first > is important > >missing information and the second is misinformation. > > Would it make sense to descibe TUTF-8 in its own dedicated man page and > referent to it, instead of duplicating the description across different > man pages? > |