From: Harald O. <har...@el...> - 2025-05-05 13:51:35
Dear Tcl/Tk team ! It is release time. TCL/Tk 9.0.2 and TCL/Tk 9.1a0 are planned this month. Please get your input ready now! Thanks for participating at the great telco of today. Here are the notes, which are mostly opinions and no decisions. 1) TIP 715: platforms for 9.1 Make a living document. Vote on it when TCL9.1.0 is released. Add comment in the beginning: This is an active discussion. Finalisation planned with release of the version. Maintainers ok. 2) TIP 717: Tcl_AttemptCreateHashEntry In favor. Implementation ready. Please review. 3) TIP 716: encoding user and MS-Windows manifest removal "Make the elephant back a mouse". Many linked issues, partly bugs. May have a switch solution with/without manifest Proposed "exec -encoding xxx" is eventually not needed, if utf-8 is given in manifest. 4) TIP 698: Negative screen distances Most positive, comes from TkInter 5) TIP 714: photo image format information Clean way is new registration function. Much work. 6) TIP 626: Command argument count > INT_MAX (2^31) Most remarks are mostly bugs. Many linked issues are WIP. Great, that it is looked into. Also, memory error instead panic is linked. TIP 717 is a consequence of this work. May be voted later. 7) TIP 302: after independent on current time It is a TIP for 20 years. Technically it is a bugfix, but it has many consequences. Don't disturb the function of a long time command. A fully new command would be appreciated, not a new switch. TIP: 302: new switch: after -robust New command: intime (this is an example) 8) TIP 719: New tk states for ttk::treeview and ttk::notebook images TIP ok. Warning for vote to send. 9) TclLog2 improvements: https://core.tcl-lang.org/tcl/info/fd1585e2a1a8f890 Moving foreward just fine. I don't like undefined behaviour? Define output for 0 input on all platforms. Aim is performence. It is internal to TCL. 10) New bytecodes (Donal): https://core.tcl-lang.org/tcl/tktview/aa10216459cdfe0fd3eab0bbab949e611bd7336e I like it! It is more useful than I thought! Performance boost is supposed. Aim is not only performance but clearness. It is for 9.1. It should be in 9.1a0 to find issues. It is an extension. Concurring byte-codes are deprecated, but not removed. 11) Floating point numbers overflow: https://core.tcl-lang.org/tcl/info/42d14c495a096159 May be a bug in Libtommath and may go there. Free to merge. 12) Block cursor: https://core.tcl-lang.org/tk/info/5d0bc3cfec7c1adb Others may test. 13) Orphan packages repository Ongoing. Seen as good aproach. 13a) Release plan Release this month. 9.0.2 first Then 9.1a0 9.1a0 candidates: - New bytecode is a good candidate - TIP 712: Positive switches for subst -> pos/neg together? Error message prefered. 14) Conference status 15 participants. COnference will take place. Other meetings: 13th of May 18:00 UTC: mothly meetup (I am available and may start) 19th of May 12:00 UTC: UTC Monthly Virtual Meetup on same jitsi (I am eventually not available) --- Off meeting: as sqlite was present: - latest tickets were discussed - Christian Werners dict proposal for tdbc::swqlite3 was discussed: https://core.tcl-lang.org/tdbcsqlite3/info/7822a89cdahttps://sqlite.org/forum/forumpost/585ebac2c48f1411a81bb1e428bce3caf734e7c352521044bc383802cf734fb5 More understanding is required. --- Thanks for all ! Harald
From: Jan N. <jan...@gm...> - 2025-05-05 09:51:35
Op ma 14 apr 2025 om 06:52 schreef Ashok: > > TIP 716: New command "encoding user", remove UTF-8 manifest setting on Windows is ready for comments. It proposes reversion of a change made in 9.0 to tclsh and wish Windows manifests while keeping compatibility with 9.0.{0,1}. Let me share two more reservations on the TIP text: 1) Two times in the TIP, "MingW msvcrt" builds are mentioned as behaving differently from ucrt builds. Quoting: "The key difference with respect to the current implementation issue that this does not impact extensions that call GetACP solving the first issue listed above, or using MingW msvcrt builds." "An example is components built with MingW64 gcc using the msvcrt runtime" This is not correct. I did test that (see ticket https://core.tcl-lang.org/tcl/tktview/8ffd8cabd1) which was done using a MingW msvcrt build. The The GetACP() function functions exactly the same. There is an issue mixing different runtimes, but that's related to using stdin/stdout: different runtimes each have their own FILE implementation. So, opening a FILE in an extension using UCRT and writing it from other extension using MSVCRT is expected to crash. My suggestion: remove it from the TIP text (or provide a testcase proving your point, I will be happy to try it in my environment) 2) There is no usecase for exporting Tcl_GetEncodingNameForUser() I tried to use it, but the way it is now it's a bad idea. I am thinking about a separate TIP for a more useful approach. Stay tuned. The reason I suspect that you didn't do any tests in the MinGW msvcrt environment is that compilation in this environment failed: <https://github.com/tcltk/tcl/actions/runs/14725688360> I corrected that here, as a free service ;-) <https://core.tcl-lang.org/tcl/info/479fc6ad0dff8cdd> Hope this helps, Jan Nijtmans
From: Harald O. <har...@el...> - 2025-05-05 08:34:03
Donal, I allowed me to put the provided information into a ticket: https://core.tcl-lang.org/tcl/tktview/aa10216459cdfe0fd3eab0bbab949e611bd7336e I just fear that we loose information when this stays in the core list. It is IMHO important reference information. Testers may contribute to the ticket... THanks for all, Harald Am 04.05.2025 um 17:06 schrieb Donal Fellows: > A side note: the INST_JUMP_TABLE_NUM instruction will enable the > addition of a new mode of operation for [switch] that I've been thinking > about for a while: switching on /integer /equality, which I've seen the > need for in handling things like switching on the number of arguments > passed to a procedure. (It can't be safely done now because we use the > wrong sort of equality testing.) I'll TIP that up once the instruction > to make it practical hits the trunk. > > Donal. > > ------------------------------------------------------------------------ > *From:* Donal Fellows > *Sent:* Friday, May 02, 2025 17:24 > *To:* Tcl Core > *Subject:* [TCLCORE] New Bytecode Branch Ready for Review > > The branch for the new bytecodes (with the wonderfully wieldy name no- > variable-width-instruction-issue) is ready for someone to give it a bit > of a review. It's quite a large one, so here's a summary: > > [...] > > The replacement for INST_RETURN_CODE_BRANCH is INST_JUMP_TABLE_NUM that > is a general numeric-keyed jump table. (Take note for the Tcl Compiler > and TBCLoad: there's a new AUX type). > > [...] > > Some of the operations are made available to > [tcl::unsupported::assemble]. Only the error prefix comparator isn't; > that's got safety requirements on its argument that I'm not bothering to > make the assembler understand. >
From: Donal F. <don...@ma...> - 2025-05-04 15:07:11
A side note: the INST_JUMP_TABLE_NUM instruction will enable the addition of a new mode of operation for [switch] that I've been thinking about for a while: switching on integer equality, which I've seen the need for in handling things like switching on the number of arguments passed to a procedure. (It can't be safely done now because we use the wrong sort of equality testing.) I'll TIP that up once the instruction to make it practical hits the trunk. Donal. ________________________________ From: Donal Fellows Sent: Friday, May 02, 2025 17:24 To: Tcl Core Subject: [TCLCORE] New Bytecode Branch Ready for Review The branch for the new bytecodes (with the wonderfully wieldy name no-variable-width-instruction-issue) is ready for someone to give it a bit of a review. It's quite a large one, so here's a summary: [...] The replacement for INST_RETURN_CODE_BRANCH is INST_JUMP_TABLE_NUM that is a general numeric-keyed jump table. (Take note for the Tcl Compiler and TBCLoad: there's a new AUX type). [...] Some of the operations are made available to [tcl::unsupported::assemble]. Only the error prefix comparator isn't; that's got safety requirements on its argument that I'm not bothering to make the assembler understand.
From: Harald O. <har...@el...> - 2025-05-03 15:04:36
Am 03.05.2025 um 01:53 schrieb Keith Nash: > After 2033-01-01, Tcl 9.1 must write a warning to the system log and to > stderr whenever Tcl starts, and also if commands such as [clock], [file > mtime] are called with arguments corresponding to negative time_t or > return a result with this property, in the following circumstances: > > * On a host that has no system calls for 64-bit time (e.g. 32-bit Linux > kernels earlier than 5.6) > > * On a system on which the length of time_t has been tested and found > to be 32-bit (N.B. even a libc that is nominally compliant may have > been built with a compatibility option to use 32-bit time_t). > > * On a system on which a 64-bit time operation has been tested at > startup and has failed (e.g. creating a file and changing its mtime to > a date in 2040). Dear Keith, thanks for volontaring to maintain, that is highly appreciated. I have removed the 32 bit time_t requirement to 9.1. I see also those points to make the code easier and to remove code for 32 bit and 64 bit. If it is not the moment, that is ok. I have put your text for a future version of TCL, as 9.1 will probably out of maintenance in 2033. Dear Steve, thanks for your contribution about tested Linux systems. Could you correct the list? Dear Pietro, can you give me some wordings to describe the "FreeBSD" ? I have never heard this system, sorry. Is this the same as "BSD" ? Well, stupid questions, sorry. Or "Debian" ? My Proxmox server is running "Debian", another mystic Linux variant... Do I need a version/platform with "FreeBSD", like Arm64 or 12.0 ? Or can you directly correct the TIP? Thanks for all, Harald
From: Keith N. <k.j...@us...> - 2025-05-02 23:53:54
Hi All, 1. MAINTAINERS On a different aspect of maintenance: the default assignees for Tcl tickets could be updated. The aim is that when a ticket is created, an email is sent to an appropriate person. I volunteer to be the default assignee for these Tcl categories: [29] http Package [33] Safe Base If the ticket is more appropriate for somebody else (e.g. DKF for cookies in [29], namespace ensembles in [33]) I will redirect the ticket to them. 2. 2038 and 64-bit time_t My main concern is to not make non-compliant systems unusable (yet). We have 13 years until the 2038 rollover, and for comparison we did not decide to eliminate all Y2K-non-compliant systems as early as 1987. I do not mind if the language is changed to avoid "may". I suggest the following for Tcl/Tk on Linux/UNIX/BSD systems: { After 2033-01-01, Tcl 9.1 must write a warning to the system log and to stderr whenever Tcl starts, and also if commands such as [clock], [file mtime] are called with arguments corresponding to negative time_t or return a result with this property, in the following circumstances: * On a host that has no system calls for 64-bit time (e.g. 32-bit Linux kernels earlier than 5.6) * On a system on which the length of time_t has been tested and found to be 32-bit (N.B. even a libc that is nominally compliant may have been built with a compatibility option to use 32-bit time_t). * On a system on which a 64-bit time operation has been tested at startup and has failed (e.g. creating a file and changing its mtime to a date in 2040). We shall review this policy in 2032. } It is clearly a good thing to start thinking early about 2038, but I hope that we do not yet need to exclude systems that use glibc older than 2.34, or a 32-bit Linux kernel older than 5.6: the age of suchsystems can be less than four years or five years respectively. Best wishes, Keith. On Fri, 2025-05-02 at 08:15 +0200, Harald Oehlmann wrote: > I think, the main point is a maintainer, which commits to test > releases > and to check failure tickets. > > I have changed the TIP in this way and propose a wiki page with > maintainers. > > Is this a good idea? > > About the time_t 64 bit, I did not do any modifications. For me, the > post had to many "may" like "a warning may be issued". Is this > warning > implemented? Or shall a warning be required? > I have no opinion on Linux and understand that it is a very moving > target. It may disqualify small platforms like controllers which > eventually do not have a RTC at all and the time is irrelevant. > > Thanks for all, > Harald > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core
From: Donal F. <don...@ma...> - 2025-05-02 16:24:53
Hi everyone, The branch for the new bytecodes (with the wonderfully wieldy name no-variable-width-instruction-issue) is ready for someone to give it a bit of a review. It's quite a large one, so here's a summary: The branch deprecates all operations that have a single byte for a jump offset, a variable index or an argument count (except for string concatenation). These are replaced with versions that use four-byte offsets/indices/counts. The affected instructions are: * INST_PUSH1 * INST_INVOKE_STK1 * INST_LOAD_SCALAR1 * INST_LOAD_SCALAR_STK (wasn't issues by our compiler anyway) * INST_LOAD_ARRAY1 * INST_STORE_SCALAR1 * INST_STORE_SCALAR_STK (another never-generated one) * INST_STORE_ARRAY1 * INST_INCR_SCALAR1 * INST_INCR_ARRAY1 * INST_INCR_SCALAR1_IMM * INST_INCR_ARRAY1_IMM * INST_APPEND_SCALAR1 * INST_APPEND_ARRAY1 * INST_LAPPEND_SCALAR1 * INST_LAPPEND_ARRAY1 * INST_RETURN_CODE_BRANCH * INST_TAILCALL * INST_TCLOO_NEXT * INST_TCLOO_NEXT_CLASS Some of these are replaced with their existing 4-byte versions. Some have new versions (now with 4-byte args): * INST_INCR_SCALAR * INST_INCR_ARRAY * INST_INCR_SCALAR_IMM * INST_INCR_ARRAY_IMM * INST_TAILCALL * INST_TCLOO_NEXT * INST_TCLOO_NEXT_CLASS The replacement for INST_RETURN_CODE_BRANCH is INST_JUMP_TABLE_NUM that is a general numeric-keyed jump table. (Take note for the Tcl Compiler and TBCLoad: there's a new AUX type). I also add these new opcodes: * INST_SWAP - Swap the top two items on the stack. * INST_ERROR_PREFIX_EQ - Special equality for [try/trap] * INST_TCLOO_ID - Get the creation ID of an object; not common, but easy * INST_DICT_PUT - [dict replace] as an opcode, simplifying [try] * INST_DICT_REMOVE - [dict remove] as an opcode, to fill out the suite available * INST_IS_EMPTY - access to Tcl_IsEmpty (and enhancements to bytecode optimiser to use it) Some of the operations are made available to [tcl::unsupported::assemble]. Only the error prefix comparator isn't; that's got safety requirements on its argument that I'm not bothering to make the assembler understand. As far as I can tell, the test suite is passing. At least on Windows and excluding some tests that don't run on this laptop. I have not performance-tested the code! This machine has aggressive speed-stepping forced on by institutional group policy. Sorry about that. Donal.
From: Jan N. <jan...@gm...> - 2025-05-02 12:13:26
Op vr 2 mei 2025 om 14:05 schreef Harald Oehlmann: > Nevertheless, Tcl_InitStringRep: > * is not documented in the docs > * the introducing TIP 445 documents the NULL as return on memory > error. > > So, I think that this is ok and no "attempt" version of this call is > required. If the function currently paniced, it was an error following > the TIP. ... > Does this sounds right? Yes, that sounds right. I'll leave the TIP as it was. Thanks for the insight! Jan Nijtmans
From: Harald O. <har...@el...> - 2025-05-02 12:05:29
Am 02.05.2025 um 13:22 schrieb Jan Nijtmans: > Op do 1 mei 2025 om 11:22 schreef Jan Nijtmans: >> >> This is a CFV warning for TIP #717. for Tcl 9.1+: >> New function: Tcl_AttemptCreateHashEntry() >> <https://core.tcl-lang.org/tips/doc/trunk/tip/717.md> > > Since it turns out that Tcl_InitStringRep() has the > same problem, and can benefit from the same > solution, the title changed: > New functions: Tcl_AttemptCreateHashEntry(), Tcl_AttemptInitStringRep() > <https://core.tcl-lang.org/tips/doc/trunk/tip/717.md> > > If you think this is a bad idea, speak up now. If not, > I'll start the vote in a few days. > > Regards, > Jan Nijtmans Jan, I generally appreciate the "attempt" functions to get fails instead panic on memory issues. Nevertheless, Tcl_InitStringRep: * is not documented in the docs * the introducing TIP 445 documents the NULL as return on memory error. So, I think that this is ok and no "attempt" version of this call is required. If the function currently paniced, it was an error following the TIP. Tcl_CreateHashEntry is different. It existed in Tcl 8.6 and a NULL-return on memory issues is not documented. So, this is a good candidate to be member of the Atempt family. Does this sounds right? Harald
From: Steve L. <st...@di...> - 2025-05-02 10:31:32
I think the wiki page adds value. Let’s see what others think. -- Steve On 2 May 2025 at 6:02 PM +0800, Harald Oehlmann <har...@el...>, wrote: > Am 02.05.2025 um 11:53 schrieb Steve Landers: > > On 2 May 2025 at 2:17 PM +0800, Harald Oehlmann > > <har...@el... mailto:har...@el...>, wrote: > > > > I think, the main point is a maintainer, which commits to test releases > > and to check failure tickets. > > > > I have changed the TIP in this way and propose a wiki page with > > maintainers. > > > > Is this a good idea? > > > > Yes, but let’s do it now instead of waiting for 9.1 > > > > -- Steve > > As the TIP defines primary the supported platforms and build systems for > 9.1, I would leave this for 9.1. > > I would say, that the listed maintainers are not limited to 9.1, but for > all supported versions. > Is this ok? > > Thanks, > Harald > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core
From: Harald O. <har...@el...> - 2025-05-02 10:01:08
Am 02.05.2025 um 11:53 schrieb Steve Landers: > On 2 May 2025 at 2:17 PM +0800, Harald Oehlmann > <har...@el... mailto:har...@el...>, wrote: > > I think, the main point is a maintainer, which commits to test releases > and to check failure tickets. > > I have changed the TIP in this way and propose a wiki page with > maintainers. > > Is this a good idea? > > Yes, but let’s do it now instead of waiting for 9.1 > > -- Steve As the TIP defines primary the supported platforms and build systems for 9.1, I would leave this for 9.1. I would say, that the listed maintainers are not limited to 9.1, but for all supported versions. Is this ok? Thanks, Harald
From: Steve L. <st...@di...> - 2025-05-02 09:54:01
On 2 May 2025 at 2:17 PM +0800, Harald Oehlmann <har...@el...>, wrote: > I think, the main point is a maintainer, which commits to test releases > and to check failure tickets. > > I have changed the TIP in this way and propose a wiki page with maintainers. > > Is this a good idea? Yes, but let’s do it now instead of waiting for 9.1 -- Steve
From: Harald O. <har...@el...> - 2025-05-02 06:15:48
I think, the main point is a maintainer, which commits to test releases and to check failure tickets. I have changed the TIP in this way and propose a wiki page with maintainers. Is this a good idea? About the time_t 64 bit, I did not do any modifications. For me, the post had to many "may" like "a warning may be issued". Is this warning implemented? Or shall a warning be required? I have no opinion on Linux and understand that it is a very moving target. It may disqualify small platforms like controllers which eventually do not have a RTC at all and the time is irrelevant. Thanks for all, Harald Am 01.05.2025 um 04:41 schrieb Ashok Nadkarni via Tcl-Core: > I had originally suggested the two developer requirement. My thought at > the time was that any future enhancement on the platform, such as TIP > 458 on *ix or some future support of IOCP on Windows, would have at > least one reviewer with competency on that platform, as well as someone > who could fix related bugs in case of unavailability of the original > implementor for whatever reason. > > The TIP is now focused on what is tested for a release rather than > future development. In that case, the developer requirement could be > dropped completely. As long as someone signs up to test a platform > before release, that should suffice as a tested platform for that release. > > /Ashok > ------------------------------------------------------------------------ > *From:* Steve Landers <st...@di...> > *Sent:* Wednesday, April 30, 2025 2:43 PM > *To:* apn...@ya... <apn...@ya...>; tcl- > co...@li... <tcl...@li...> > *Cc:* Pietro Cerutti <ga...@ga...> > *Subject:* Re: [TCLCORE] TIP 715 - Supported platforms and build > environments for Tcl/Tk 9.1 > Further to what Pietro has said, I cannot see why a *nix variant (or > even a Linux distro) should require two maintainers when that is the > same number are required for Windows and macOS, both of which are quite > different from a *nix/X11 platform. > > Surely it is enough for the test suite for a release to pass for a > platform to be considered tested, irrespective of the number of developers? > > -- Steve > On 30 Apr 2025 at 4:21 PM +0800, Pietro Cerutti via Tcl-Core <tcl- > co...@li...>, wrote: >> On Mar 13 2025, 11:53 +0000, apnmbx-public--- via Tcl-Core <tcl- >> co...@li...> wrote: >> [-- Type: text/plain; charset=US-ASCII, Encoding: 7bit, Size: 0.7K --] >>> All, >>> >>> In Tuesday's online meet, the need for formally defining supported >>> platforms >>> was raised (triggered by Francois' post regarding macOS/XQuartz). As >>> suggested by Harald, I've committed TIP 715 >>> <%28https://core.tcl-lang.org/tips/doc/trunk/tip/715.md%29> as a starting point >>> for discussion. I have no idea what to include for platforms other than >>> Windows. >> >> I regularly test Tcl/Tk, and several other extensions on FreeBSD. I am >> the one behind tc...@Fr..., and I maintain a lot of Tcl/Tk-related >> ports on FreeBSD. >> >> I don't qualify as "At least two developers committing to development >> and testing for that item", but I think as long as I'm around, we can >> consider FreeBSD as "tested". >> >> As for CI, there's https://cirrus-ci.com/ which offers FreeBSD platforms >> and can be integrated in GitHub, or we could use >> https://github.com/vmactions/freebsd-vm/. Happy to help out setting that >> up. >> >> -- >> Pietro Cerutti >> I have pledged to give 10% of income to effective charities >> and invite you
Hello, Jan > This is a CFV warning for TIP #698. for Tk 9.1+: > Handle negative screen distances > <https://core.tcl-lang.org/tips/doc/trunk/tip/698.md> > > If you think this is a bad idea, speak up now. If not, > I'll start the vote in a few days. The functionality is fine. My only concern is the potential incompatibility you mention in the TIP. Blt solved this problem with new option types, with suffix _NNEG for non negative values and _POS for positive values. It also implemented an extended version of Tk_GetPixelsFromObj() which receives an additional flag (PIXELS_ANY, PIXELS_NNEG or PIXEL_POS) to avoid such checks like the ones you mention in the TIP. My 0.02 -- Emiliano <emi...@gm...>
From: Ashok N. <apn...@ya...> - 2025-05-01 15:06:06
Jan, First, thanks for the considerable time you have spent on poking at 716. It is appreciated. I will summarize the discussion and points you brought up in the TIP. In any case, I do not plan on a CFV until the options for proceeding are discussed in the next meeting. Regarding your comment below, regarding 9.0.0/9.0.1 because it is not true for all Windows platforms supported by 9.0 and not all Windows API's, I would hesitate to say it works fine. /Ashok ________________________________ From: Jan Nijtmans Sent: Wednesday, April 30, 2025 4:13 PM To: Ashok Nadkarni Cc: Tcl Core List Subject: Re: [TCLCORE] TIP 716 ready for comments Op wo 30 apr 2025 om 09:43 schreef Jan Nijtmans: > > The following idiom I presume you are referring to, > > > > Tcl_UtfToExternalDString(NULL,...,&ds); > > CreateFileA(Tcl_Value(&ds)...); For completeness, another idiom I'm referring to: const char *str = Tcl_GetStringFromObj(....) CreateFileA(str, ...) Surprisingly many extensions use that. In 8.x it works fine, as long as the filename is restricted to ASCII. In 9.0.0/9.0.1 it works fine as long as the filename is restricted to UTF-8 ;-). With TIP #716 it works fine as long as the filename is restricted to ASCII (which is the same brokenness as 8.x ...) It's up to you how to incorporate this information in the TIP text, or - if you want - leave it out. Some examples: https://sqlite.org/src/file?name=src/tclsqlite.c&ci=ba7d5bad32ad6aac&ln=2604https://github.com/auriocus/VecTcl/blame/master/WavReader/generic/wavreader.c (line 88) Regards, Jan Nijtmans
From: Ashok N. <apn...@ya...> - 2025-05-01 14:54:47
The allocation functions and their calls are not so easy to change for at least two reasons. It breaks the contract with extensions that expect either a panic or a non-NULL return. It is next to impossible to fix all extensions. The other reason is that, even within the core, in some cases the caller itself has no means of returning an error. The most common example is the "UpdateString" procedure of various Tcl_ObjType which generate string representations. These have no status return so if their allocation attempts fail, they have no way to percolate the error up to their caller. Changing the signatures of all functions in the call chain is not feasible. /Ashok ________________________________ From: Kevin Walzer Sent: Thursday, May 1, 2025 7:33 PM To: Jan Nijtmans Cc: Tcl Core List Subject: Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry() On 5/1/25 8:29 AM, Jan Nijtmans wrote: > The reason for this is that are many calls to Tcl_CreateHashEntry in > the Tcl code > which don't check for NULL values. In stead of panicing, those will crash > without any clue what happened. Why not fix those then? Adding a NEW function to serve this purpose just seems like added complexity to the Tcl core.
From: Jan N. <jan...@gm...> - 2025-05-01 14:50:48
Op do 1 mei 2025 om 16:03 schreef Kevin Walzer: > Why not fix those then? There are 112 Tcl_CreateHashEntry() calls in Tcl and 111 in Tk. Are you willing to help me with this immense task? > Adding a NEW function to serve this purpose just > seems like added complexity to the Tcl core. > Actually, I took the opportunity to simplify the hashtable implementation a bit, combining functions as much as possible, moving the Tcl_Panic() out of the low-level routines. I think the complexity is reduced this way. Hope this helps, Jan Nijtmans
From: Jan N. <jan...@gm...> - 2025-05-01 12:30:20
Op do 1 mei 2025 om 13:12 schreef Kevin Walzer: > I’m not clear on why this simply isn’t a bug fix for Tcl_CreateHashEntry > that allow more graceful failure in memory-intensive situations? > The reason for this is that are many calls to Tcl_CreateHashEntry in the Tcl code which don't check for NULL values. In stead of panicing, those will crash without any clue what happened. Actually, I thought about this, and - at the same time - do the same for Tcl_Malloc and friends as well: <https://core.tcl-lang.org/tips/doc/trunk/tip/668.md> but I don't think this will get sufficient support. Better first improve the error-handling in the core. Hope this helps, Jan Nijtmans
26 messages has been excluded from this view by a project administrator.
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
