tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

[Harald O. <har...@el...>]

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

Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

[Keith N. <k.j...@us...>]

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

[TCLCORE] New Bytecode Branch Ready for Review

[Donal F. <don...@ma...>]

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.

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Jan N. <jan...@gm...>]

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

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Harald O. <har...@el...>]

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

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Jan N. <jan...@gm...>]

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

Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

[Steve L. <st...@di...>]

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

Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

[Harald O. <har...@el...>]

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

Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

[Steve L. <st...@di...>]

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

[TCLCORE] TCL/Tk biweekly telco on 5th of May, 2025 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

[Harald O. <har...@el...>]

Dear Tcl/Tk team,

please allow me to invite anybody to the telco:
Where: https://meet.jit.si/TclMonthlyMeetup
When: 2025-05-05 12:00 UTC

Possible agenda:
1) TIP 715: platforms for 9.1
2) TIP 717: Tcl_AttemptCreateHashEntry
3) TIP 716: encoding user and MS-Windows manifest removal
4) TIP 698: Negative screen distances
5) TIP 715: photo image format information
6) TIP 626: Command argument count > INT_MAX (2^31)
7) TIP 302: after independent on current time
8) TclLog2 improvements: https://core.tcl-lang.org/tcl/info/fd1585e2a1a8f890
9) Floating point numbers overflow: 
https://core.tcl-lang.org/tcl/info/42d14c495a096159
10) Block cursor: https://core.tcl-lang.org/tk/info/5d0bc3cfec7c1adb
11) Conference status

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)

Thank you all,
Harald

Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

[Harald O. <har...@el...>]

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
>>> (https://core.tcl-lang.org/tips/doc/trunk/tip/715.md) 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 

Re: [TCLCORE] CFV warning: TIP #698: Handle negative screen distances

[Emiliano <emi...@gm...>]

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...>

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Kevin W. <kw...@co...>]

<div><img width="1" height="1" src='https://fedbdhd.r.af.d.sendibt2.com/tr/op/hHMNplihRQsARzBjgIoWuxuDX-QKGeLfNptgsgzIm0XrTE-5VzUaEhF6VkAE896ecjCCvnVmitpHMQXgH71bHpPEYmebGk0kLV9TGPrCh0CECZ5Itm1mMsmXzIFYaCtRnJZ5Nm1r2SO8CG9Bscan2CtT3lQQOkFPt9ZX8tDuMR7v8KesuYA_lCRBAXJ7pf3zopI0kwEHQ9QsXFoP5xECPS4Soy9xCxNR' style='mso-hide:all'/></div>On 5/1/25 10:50 AM, Jan Nijtmans wrote:<br/><br/>> There are 112 Tcl_CreateHashEntry() calls in Tcl<br/>> and 111 in Tk. Are you willing to help me with this<br/>> immense task?<br/><br/>My hands are full with a different project, so I will be unable to <br/>assist here.<br/><br/>I get it - the functions are too deeply enmeshed in the core to address <br/>in a feasible manner and the separate function is the cleaner approach. <br/>Just needed to better understand the scope.<br/><br/>

Re: [TCLCORE] TIP 716 ready for comments

[Ashok N. <apn...@ya...>]

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=2604
    https://github.com/auriocus/VecTcl/blame/master/WavReader/generic/wavreader.c
(line 88)

Regards,
       Jan Nijtmans

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Ashok N. <apn...@ya...>]

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.

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Jan N. <jan...@gm...>]

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

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Kevin W. <kw...@co...>]

<div><img width="1" height="1" src='https://fedbdhd.r.tsp1-brevo.net/tr/op/xokGaM53R3py87aMryrHPrvrDwzYlVacjzxk01SjcXQS1SdZBPTHeVvq9dBS8BXjWShpF3lAt7Eg1Up_EE7d7RotHOszTSXuHcahqxd3gdwDYqiHYr5A-WqJRFomyp2pg8o4V9iIL2p_pDW2geqhvpc7KvcjV8wMc1ueVktvXg8NNkbAdByPpkAXfxpGKqfLPZHzJyQFQCWOAu93aPJqBOHiY0t_' style='mso-hide:all'/></div>On 5/1/25 8:29 AM, Jan Nijtmans wrote:<br/><br/>> The reason for this is that are many calls to Tcl_CreateHashEntry in <br/>> the Tcl code<br/>> which don't check for NULL values. In stead of panicing, those will crash<br/>> without any clue what happened.<br/><br/>Why not fix those then? Adding a NEW function to serve this purpose just <br/>seems like added complexity to the Tcl core.<br/><br/>

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Jan N. <jan...@gm...>]

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

Re: [TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Kevin W. <kw...@co...>]

<div><img width="1" height="1" src='https://fedbdhd.r.tsp1-brevo.net/tr/op/liYal1EKUFDOz3-r7ZFcGBeDIZYWfWYg0ZLEbuWTGCzqjDLD3ORyMhmMpP8AoFhDMuc8O_08RvfRZaZczZOt3UIAXGSuufF5kPXMQktlMCAbOmGCjsGfrpZfbK88SJwNDnZ9dRRYmYGHrBxPQjdJZ0WzCbwnaBowJnCEBM-LVLvZS23gHNbOAwlkLTTwfjNreGtKVqHHmHLKy8phDQUg2Z2UuWkx' style='mso-hide:all'/></div>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? <br/><br/>> On May 1, 2025, at 5:23 AM, Jan Nijtmans <jan...@gm...> wrote:<br/>> <br/>> This is a CFV warning for TIP #717. for Tcl 9.1+:<br/>>    New function: Tcl_AttemptCreateHashEntry()<br/>>    <a href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/g8U8uHxLLTzmCG8tqq_qtjuk6IUk5vvLnO4CXOAxfHp0okBguVbl7NkJlGP9UoUV-Lp0QtSmB4KJPhtdmGjUP73V49wBA-LY3LBQ_BKL5xgZXMYTZ_DMtljX_QFe084XwzPO7HGXUnMHBAC5Hd0inQbP8x8lKUKyHLqZQt8qUS8u6y2Tg-bFYJYylH6lg4UI4VSQwSMjAAADY2U9hZZevJHV5oH7AYacbV4XWoZYGHhd82Lm4_vcQYrGzqkpu4p4pHEi10yV8zYe19sdw34oW-Fy184Dc8-9Tx5pCfbsdk1zbzieBZqHFI6BK6iAmJCw">https://core.tcl-lang.org/tips/doc/trunk/tip/717.md</a><br/>> <br/>> If you think this is a bad idea, speak up now. If not,<br/>> I'll start the vote in a few days.<br/>> <br/>> Regards,<br/>>         Jan Nijtmans<br/>> <br/>> <br/>> _______________________________________________<br/>> Tcl-Core mailing list<br/>> Tcl...@li...<br/>> https://lists.sourceforge.net/lists/listinfo/tcl-core<br/>

[TCLCORE] CFV warning: TIP #717: New function: Tcl_AttemptCreateHashEntry()

[Jan N. <jan...@gm...>]

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>

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

Re: [TCLCORE] CFV warning: TIP #698: Handle negative screen distances

[Jan N. <jan...@gm...>]

Op wo 30 apr 2025 om 22:06 schreef Francois Vogel:
> Thanks. Note that in addition to the -offset tag option, the TIP also tells about the -padx, -pady options for embedded windows.

I forgot that the revised_text widget already has support for the
TK_OPTION_NEG_OK flag since this commit:
        <https://core.tcl-lang.org/tk/info/68fa9a67c0f027f0>

I already added it, so I could test the TIP #698 implementation
together with an external revised_widget.

All of -offset, -padx and -pady are handled, nothing more needs to be done.

Hope this helps,
        Jan Nijtmans

Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

[Ashok N. <apn...@ya...>]

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...@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...@li...>, wrote:
On Mar 13 2025, 11:53 +0000, apnmbx-public--- via Tcl-Core <tcl...@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
(https://core.tcl-lang.org/tips/doc/trunk/tip/715.md) 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 to join me - https://givingwhatwecan.org


_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV warning: TIP #698: Handle negative screen distances

[Francois V. <fvo...@fr...>]

Le 30/04/2025 à 20:24, Jan Nijtmans a écrit :
> Op wo 30 apr 2025, 19:51 schreef Francois Vogel <fvo...@fr...>:
>
>     Hi Jan,
>
>     My concern, as often, is regarding the revised text widget. When this
>     will get merged into trunk, will you also make the necessary
>     changes in
>     branch revised_text?
>
>
> For the revised_text widget, only the -offset tag is affected (see 
> TIP). I will make the necessary change for this single option. All 
> other options dont need modification.

Thanks. Note that in addition to the -offset tag option, the TIP also 
tells about the -padx, -pady options for embedded windows.

F.

Re: [TCLCORE] CFV warning: TIP #698: Handle negative screen distances

[Jan N. <jan...@gm...>]

Op wo 30 apr 2025, 19:51 schreef Francois Vogel <fvo...@fr...>:

> Hi Jan,
>
> My concern, as often, is regarding the revised text widget. When this
> will get merged into trunk, will you also make the necessary changes in
> branch revised_text?
>

For the revised_text widget, only the -offset tag is affected (see TIP). I
will make the necessary change for this single option. All other options
dont need modification.

Hope this helps
        Jan Nijtmans

>

Re: [TCLCORE] CFV warning: TIP #698: Handle negative screen distances

[Francois V. <fvo...@fr...>]

Hi Jan,

My concern, as often, is regarding the revised text widget. When this 
will get merged into trunk, will you also make the necessary changes in 
branch revised_text?

Regards,

Francois

Le 30/04/2025 à 14:14, Jan Nijtmans a écrit :
> 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.
>
> Regards,
>           Jan Nijtmans
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core