tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Report of Tcl/Tk biweekly telco on 2025-02-25

[Reinhard M. <rei...@m4...>]

Am 25.02.2025 13:08, schrieb Harald Oehlmann:

> IMHO, UDP support should be in the core.

Shall we try to polish my new socket stuff to the point that it can go 
into 9.1 at least as a preview under tcl::unsupported?

 From my POV all functionality is there to give it a try as an add-on 
that is not meant to replace the [socket] command in the first run. But 
I would like to have some discussion about design decisions for stuff 
like the handling of symbolic constants.

cu
Reinhard

Re: [TCLCORE] Report of Tcl/Tk biweekly telco on 2025-02-25

[Schelte B. <tc...@tc...>]

On 25/02/2025 02:41, Brian O'hagan via Tcl-Core wrote:
> While I'm at it, I need for someone to add the "f" and "y" permissions to my
> TCLTLS account so I can create wiki pages and do releases. Thanks.

Done.


Schelte.

Re: [TCLCORE] Report of Tcl/Tk biweekly telco on 2025-02-25

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

Brian,
thanks for the message. Yes, the answer on bundling TCLTLS was "mostly 
positive".
IMHO, UDP support should be in the core. Some action here would be great.
Great, that you plan to do further enhancements to TCLTLS.
I can not help with fossil. I only have a user account (see section 
fossil of the report to have a smile).
It would be great, if user "bohagan" would get the requested rights and 
if Schelte could also make some action here.

Thank you for all,
Harald

Am 25.02.2025 um 02:41 schrieb Brian O'hagan:
> Good to hear bundling TCLTLS will be happening. BTW, I have it in my long-term
> plan to add QUIC and UDP support which is needed for HTTP/3. That won't be any
> time soon since I need to finish the crypto functions first, then
> certificates.
> 
> I've also started updating TCLUDP to add the needed functionality for TLS and
> a few other things on my list. I can merge that into
> https://core.tcl-lang.org/tcludp if folks want. I have a few more things to
> finish before it's ready. You may want to consider bundling it with TCL too.
> If so, you should also decide whether to use it or the proposal in TIP 409.
> 
> https://chiselapp.com/user/bohagan/repository/TclUDP/index or
> https://github.com/bohagan1/TclUDP
> 
> While I'm at it, I need for someone to add the "f" and "y" permissions to my
> TCLTLS account so I can create wiki pages and do releases. Thanks.

Re: [TCLCORE] Report of Tcl/Tk biweekly telco on 2025-02-25

[Brian O'h. <bri...@co...>]

Good to hear bundling TCLTLS will be happening. BTW, I have it in my long-term 
plan to add QUIC and UDP support which is needed for HTTP/3. That won't be any 
time soon since I need to finish the crypto functions first, then 
certificates.

I've also started updating TCLUDP to add the needed functionality for TLS and 
a few other things on my list. I can merge that into 
https://core.tcl-lang.org/tcludp if folks want. I have a few more things to 
finish before it's ready. You may want to consider bundling it with TCL too. 
If so, you should also decide whether to use it or the proposal in TIP 409.

https://chiselapp.com/user/bohagan/repository/TclUDP/index or 
https://github.com/bohagan1/TclUDP

While I'm at it, I need for someone to add the "f" and "y" permissions to my 
TCLTLS account so I can create wiki pages and do releases. Thanks.


-----Original Message-----
From: Harald Oehlmann [mailto:har...@el...]
Sent: Monday, February 24, 2025 8:04 AM
To: Tcl Core List
Subject: [TCLCORE] Report of Tcl/Tk biweekly telco on 2025-02-25

Dear Tcl/Tk folks,
the biweekly Tcl/Tk telco happened today with great participation.
Here are the notes:

1) Release calender.

Published by Don Porter as informal TIP:
https://core.tcl-lang.org/tips/doc/trunk/tip/713.md
Thanks for this. This is highly appreciated.

Discussed in the meeting with no objections.
Last 8.6 and 9.0 version are announced.
This is a call for comments.
There is no vote of the TIP planned.
It would be great to spread this out to other projects depending on it.

2) Ticket : crash on epol when page is reloaded 
https://core.tcl-lang.org/tcl/tktview/010d8f3885642212cf2c
There was no opinion on this.
Steve will make a branch for review of the current solution/workaround.

3) fossil settings
Schelte has looked into it. Thanks a lot for this !!!

With TCL and Tk, the E-Mail notification is now working.
You may activate notification by clicking on your name in the upper right 
corner, if logged in. Then, click on "Email Alerts".

It would be great to have an administrator contact: There is a well hidden 
page informing about the administrator.
There is only one possible.

Most fossils are differently configured. I would love, if Schelte would take 
care for configuration.

My own ones (tclws,bwidget) even do not allow user registration.
I tried to change this and succeeded on tclws. I encourage Schelte to create a 
login now.
On bwidget, I have no administrator rights and login creation is not 
activated. I am not sure if this is due to the login group...

4) TCLTLS as bundled package
Thanks to Brian O'Hagan and team for the great release.
Fine to adopt this as a bundled package.
Ask Ashok for Windows build.
TIP to do so. Make directly criterias to unbundle (example: no maintainer). 
Proposal is to target 9.1.
HTTP Version 3 (udp based) is not supported and requires another solution. A 
ready-made library would be great.

5) Orphaned packages

Torsten, Ashok and Steve will take care of a list.
It may be hosted at any place.

Andreas has this list:
https://akupries.tclers.tk/hoard/tcl/index_bychange.html

6) European Conference Update

Will take place in Bologna/Italy 10/11th of July 2025.
The hotel is close to the train station in the town center.
Webside may be ready next Monday.

7) Docker to run TCL
Public docker image planned.
- Tcl/Tk/SQLite/TCLLib/CloudTk
Might get a Batteries Included version
Easy to use, was demonstrated on the Mac platform.

8) Next meeting in two weeks
10th of March, 2025 12:00 UTC

Thank you all !
Harald

[TCLCORE] Report of Tcl/Tk biweekly telco on 2025-02-25

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

Dear Tcl/Tk folks,
the biweekly Tcl/Tk telco happened today with great participation.
Here are the notes:

1) Release calender.

Published by Don Porter as informal TIP:
https://core.tcl-lang.org/tips/doc/trunk/tip/713.md
Thanks for this. This is highly appreciated.

Discussed in the meeting with no objections.
Last 8.6 and 9.0 version are announced.
This is a call for comments.
There is no vote of the TIP planned.
It would be great to spread this out to other projects depending on it.

2) Ticket : crash on epol when page is reloaded
https://core.tcl-lang.org/tcl/tktview/010d8f3885642212cf2c
There was no opinion on this.
Steve will make a branch for review of the current solution/workaround.

3) fossil settings
Schelte has looked into it. Thanks a lot for this !!!

With TCL and Tk, the E-Mail notification is now working.
You may activate notification by clicking on your name in the upper 
right corner, if logged in. Then, click on "Email Alerts".

It would be great to have an administrator contact: There is a well 
hidden page informing about the administrator.
There is only one possible.

Most fossils are differently configured. I would love, if Schelte would 
take care for configuration.

My own ones (tclws,bwidget) even do not allow user registration.
I tried to change this and succeeded on tclws. I encourage Schelte to 
create a login now.
On bwidget, I have no administrator rights and login creation is not 
activated. I am not sure if this is due to the login group...

4) TCLTLS as bundled package
Thanks to Brian O'Hagan and team for the great release.
Fine to adopt this as a bundled package.
Ask Ashok for Windows build.
TIP to do so. Make directly criterias to unbundle (example: no 
maintainer). Proposal is to target 9.1.
HTTP Version 3 (udp based) is not supported and requires another 
solution. A ready-made library would be great.

5) Orphaned packages

Torsten, Ashok and Steve will take care of a list.
It may be hosted at any place.

Andreas has this list:
https://akupries.tclers.tk/hoard/tcl/index_bychange.html

6) European Conference Update

Will take place in Bologna/Italy 10/11th of July 2025.
The hotel is close to the train station in the town center.
Webside may be ready next Monday.

7) Docker to run TCL
Public docker image planned.
- Tcl/Tk/SQLite/TCLLib/CloudTk
Might get a Batteries Included version
Easy to use, was demonstrated on the Mac platform.

8) Next meeting in two weeks
10th of March, 2025 12:00 UTC

Thank you all !
Harald

Re: [TCLCORE] CFV - TIP 711: New function: Tcl_IsEmpty()

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

Op ma 10 feb 2025 om 18:37 schreef Jan Nijtmans:

> This is a CFV for TIP 711. Let's have the vote in by
> noon 2025/02/21 UTC [clock format 1740139200]
>

Here are the results:

	Vote-Summary:	Accepted 8/0/0	Votes-For:	AK, AN, HO, JN, MC, RA, RM,
SL	Votes-Against:	none

	Votes-Present:  none


This means, TIP #711 was accepted.

There is a "core-9-0-branch" now from which Tcl 9.0.x will
be derived. The "trunk" is now open for Tcl 9.1 development.
The TIP #711 implementation can now be found on "trunk".

Regards,
          Jan Nijtmans

Re: [TCLCORE] CFV - TIP 711: New function: Tcl_IsEmpty()

[Marc C. <cul...@gm...>]

TIP #711: YES

- Marc

On Mon, Feb 10, 2025 at 11:38 AM Jan Nijtmans <jan...@gm...>
wrote:

> Hi all,
>
> This is a CFV for TIP 711. Let's have the vote in by
> noon 2025/02/21 UTC [clock format 1740139200]
>
> My vote:
>
> TP #711: YES.
>
> Thanks,
>     Jan Nijtmans
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] CFV - TIP 711: New function: Tcl_IsEmpty()

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

On 11 Feb 2025 at 1:39 AM +0800, Jan Nijtmans <jan...@gm...>, wrote:
> This is a CFV for TIP 711. Let's have the vote in by
> noon 2025/02/21 UTC [clock format 1740139200]
TIP #711: YES

It is sufficient but perhaps not ideal.

-- Steve

Re: [TCLCORE] CFV - TIP 711: New function: Tcl_IsEmpty()

[Reinhard M. <rei...@m4...>]

Hi,

Am 10.02.2025 18:37, schrieb Jan Nijtmans:

> This is a CFV for TIP 711. Let's have the vote in by
> noon 2025/02/21 UTC [clock format 1740139200]

My (first) vote:
TP #711: YES.

cu
Reinhard

Re: [TCLCORE] CFV - TIP 711: New function: Tcl_IsEmpty()

[Rolf A. <tcl...@po...>]

Jan Nijtmans writes:
> Hi all,
>
> This is a CFV for TIP 711. Let's have the vote in by
> noon 2025/02/21 UTC [clock format 1740139200]

My vote:

TP #711: YES.


After the change from tri-state to 0/1 return this is an acceptable
minor improvement, although I would have preferred a more ambitious
approach along the line of Ashoks proposal.

rolf

[TCLCORE] Bi-Weekly TCL/Tk Telco on 24th of February 2025, 12:00 UTC

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

Dear TCL/Tk team,
please allow me to invite you to the BiWeekly Tcl/Tk Telco on:
Date: 2025-02-24
Time: 12:00 UTC
URL: https://meet.jit.si/TclMonthlyMeetup

Possible discussion points:

- Tcl/Tk release calender
- fossil settings
- TCLTLS as bundled package
- Orphaned packages
- European Conference Update

Happy to meet you there,
Harald

Re: [TCLCORE] core.tcl-lang.org tarballs

[Brian G. <bri...@ea...>]

I don’t see any reason not to move the tag. 

-Brian
(from mobile device)

> On Feb 19, 2025, at 19:40, Steve Landers <st...@di...> wrote:
> 
> 
> I just noticed the release tag hasn’t been moved to Tcl 9.0.1 and Tk 9.01 in the respective repositories. The consequence is the Download page still points to 8.6.
> 
> Does anyone object to moving the release tag (which currently points to 8.6.13) up to 9.0.1 ?
> 
> -- Steve
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] core.tcl-lang.org tarballs

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

I just noticed the release tag hasn’t been moved to Tcl 9.0.1 and Tk 9.01 in the respective repositories. The consequence is the Download page still points to 8.6.

Does anyone object to moving the release tag (which currently points to 8.6.13) up to 9.0.1 ?

-- Steve

[TCLCORE] CFV warning: TIP #704: extend Tk_CanvasTextInfo

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

This is a CFV warning for TIP #704:
    extend Tk_CanvasTextInfo
    <https://core.tcl-lang.org/tips/doc/trunk/tip/704.md>

This is the first TIP targeting Tk 9.1, a useful
simple one to make a start.

This extension is needed to fully support scaled
text in external widget types. It should have been
part of Tk 9.0, but it wasn't in time before TIP
closure and it was too small to force it in then.

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

[TCLCORE] Manpage change and TIP 462 (tcl::process purge, status)

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

As noted in ticket https://core.tcl-lang.org/tcl/tktview/f5d0e75a49, the 9.0
process purge|status command implementation is at odds with the manpage and
TIP 462. Harald, Jan and I are in agreement that the implementation is the
desired behavior and that the manpage be modified accordingly along with an
addendum update to the TIP.

 

Please see the ticket for details and let me know if you disagree.
Otherwise, I will merge in the manpage and TIP change.

 

/Ashok

Re: [TCLCORE] CFV - TIP 711: New function: Tcl_IsEmpty()

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

Am 10.02.2025 um 18:37 schrieb Jan Nijtmans:
> Hi all,
> 
> This is a CFV for TIP 711. Let's have the vote in by
> noon 2025/02/21 UTC [clock format 1740139200]
> 
> My vote:
> 
> TP #711: YES.
> 
> Thanks,
>      Jan Nijtmans
My vote: yes

Thanks for the continuous work and engagement,
Harald

Re: [TCLCORE] CFV - TIP 711: New function: Tcl_IsEmpty()

[Andreas K. <and...@gm...>]

> Hi all,
> 
> This is a CFV for TIP 711. Let's have the vote in by
> noon 2025/02/21 UTC [clock format 1740139200]

TIP#711: YES

-- 
Happy Tcling,
	Andreas Kupries <and...@gm...>
			<https://core.tcl-lang.org/akupries/>
			<https://akupries.tclers.tk/>
	Developer @	SUSE Software Solutions Germany GmbH
-------------------------------------------------------------------------------

[TCLCORE] sqlite3 3.49.0 released

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

The upstream SQLite project released 3.49.0 of SQLite recently

>From that, I derived the TEA-based Tcl package we layer
on top of it.

    http://cyqlite.sourceforge.net/cgi-bin/sqlite/timeline

That's now available as Tcl package sqlite3.49.0.tar.gz from

    https://sourceforge.net/projects/tcl/files/Tcl/8.6.16/
or
    https://sourceforge.net/projects/tcl/files/Tcl/9.0.1/

Unpack that source distribution in the "pkgs" subdir of your Tcl
8.6.x or 9.0.x source code distribution and run `make install`
again for your platform.
That will build and install the updated sqlite package.

Unless another SQLite release happens first, this package will be
bundled with Tcl 8.6.17 / Tcl 9.0.2

Regards,
     Jan Nijtmans

Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

[Poor Y. <org...@po...>]

On 2025-02-12 10:42, Jan Nijtmans wrote:
> Op wo 12 feb 2025 om 09:26 schreef Donal Fellows <
> don...@ma...>:
>> 
>> 
>> While I see no particular reason a dict couldn't have a LengthProc 
>> (the
> length is just twice its size)
> 
> 
> Unfortunately, it's not that simple. How about a dict with duplicates, 
> like
> {a 0 a 1}?  It's dict length
> is 1, but as list length it should return 4, not 2.
> 
> Dict had a lengthProc in the past, it created a lot of problems. That's 
> why
> it was removed.
> See: <Tcl Source Code: View Ticket
> <https://core.tcl-lang.org/tcl/tktview/28cc67a606a7ab771af4>>

FWIW, in the unchained branch these problems were resolved and the 
length
method reinstated for the dict type.  Also worth noting is that a 
dictionary
with duplicate keys always has a string representation.

-- 
yorick

Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

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

The only way a dict can have such a thing would be for it to have a string rep. If there is no such thing, it cannot have duplicate keys. It's equivalent to how lists can have all sorts of crazy formatting, but canonical lists don't (and pure lists provably can't).

In any case, an IsEmptyProc for use when there is no string rep will not have this issue; if there is a string rep already, the emptiness check can just use its known length directly.

Donal.

-------- Original message --------
From: Jan Nijtmans <jan...@gm...>
Date: 12/02/2025 08:42 (GMT+00:00)
To: Donal Fellows <don...@ma...>
Cc: apn...@ya..., Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

Op wo 12 feb 2025 om 09:26 schreef Donal Fellows <don...@ma...<mailto:don...@ma...>>:
>
>
> While I see no particular reason a dict couldn't have a LengthProc (the length is just twice its size)


Unfortunately, it's not that simple. How about a dict with duplicates, like {a 0 a 1}?  It's dict length
is 1, but as list length it should return 4, not 2.


Dict had a lengthProc in the past, it created a lot of problems. That's why it was removed.
See: <Tcl Source Code: View Ticket [core.tcl-lang.org]<https://urldefense.com/v3/__https://core.tcl-lang.org/tcl/tktview/28cc67a606a7ab771af4__;!!PDiH4ENfjr2_Jw!CHl2UDHb277bnwTFmzCrJLgj4H69hkwd-TQYUDzKXLs_u7So_PQHMnHNEAA5-y7TzBvPiaXknP6ki5JlqXPjYfFSOicb_eKQ5qI$>>

Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

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

Op wo 12 feb 2025 om 09:26 schreef Donal Fellows <
don...@ma...>:
>
>
> While I see no particular reason a dict couldn't have a LengthProc (the
length is just twice its size)


Unfortunately, it's not that simple. How about a dict with duplicates, like
{a 0 a 1}?  It's dict length
is 1, but as list length it should return 4, not 2.

Dict had a lengthProc in the past, it created a lot of problems. That's why
it was removed.
See: <Tcl Source Code: View Ticket
<https://core.tcl-lang.org/tcl/tktview/28cc67a606a7ab771af4>>

> In particular, we have types (integers and doubles) for which it can
trivially be defined, and yet where computing the string representation
might be unwanted.

That's why integers and doubles have a lengthProc, which always return 1.

Hope this helps,
        Jan Nijtmans

Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

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

While I see no particular reason a dict couldn't have a LengthProc (the length is just twice its size), I still think an IsEmptyProc makes sense. In particular, we have types (integers and doubles) for which it can trivially be defined, and yet where computing the string representation might be unwanted.

Donal.


-------- Original message --------
From: apnmbx-public--- via Tcl-Core <tcl...@li...>
Date: 12/02/2025 05:27 (GMT+00:00)
To: 'Tcl Core List' <tcl...@li...>
Subject: Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

I don’t think LengthProc always serves the purpose, partly for reasons Nathan also alluded to. Your comment about dict being the only such type having no LengthProc holds only for the Tcl core. It may not hold for extensions where there may be no LengthProc or expensive to calculate (e.g. the database example in TIP 636 abstract list where check for an empty table / query result is a lot faster than calculating the length).

But as you said, that can be futures.

/Ashok

From: Jan Nijtmans <jan...@gm...>
Sent: Tuesday, February 11, 2025 3:59 PM
To: apn...@ya...
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

Op do 6 feb 2025 om 19:04 schreef Ashok:
A design related comment - make Tcl_IsEmpty a part of the Tcl_ObjType (like abstract lists). That immediately makes available the same quick check and avoidance of shimmering for new Tcl_Obj types defined within extensions. It is the same exact reason for having the LengthProc method in Tcl_ObjType.

The reason why I didn't propose it because the LengthProc already serves this purpose: If the object
has no string representation and LengthProc exists and returns 0, we are already sure the obj
is empty. The only type which doesn't have a LengthProc is the "dict", implementing
a IsEmpty() would be overkill for only one type (IMHO).

I could imagine a new TIP adding more procs to the Tcl_ObjType (like GetDouble or GetWideInt or
maybe combined as GetNumber). A new function like IsEmpty() is overkill, IMHO, but - hey -
that's only one opinion ;-)

Hope this helps,
       Jan Nijtmans

Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

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

Op wo 12 feb 2025 om 08:16 schreef Francois Voge:

> In the implementation, I believe the comment in the "Side effects" section
> of Tcl_IsEmpty to be inaccurate.
>
Is this better?
    <Tcl Source Code: Check-in [98e788fbcd]
<https://core.tcl-lang.org/tcl/info/98e788fbcdace290>>

Hope this helps,
       Jan Nijtmans

Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

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

In the implementation, I believe the comment in the "Side effects" 
section of Tcl_IsEmpty to be inaccurate. It says:

* Side effects: * String representation is generated if the obj has no 
lengthProc

But looking at the implementation, this does not seem to be correct for 
dicts (which have no length proc, and the string rep is nevertheless not 
generated, right?).

Also the "Results" section describes tri-states result, which I believe 
to not be reflected in the implementation. When given a NULL objPtr the 
function panics whereas the code documentation (but not the man page) 
says it returns -1.

Regards,

Francois

Le 12/02/2025 à 06:26, apnmbx-public--- via Tcl-Core a écrit :
>
> I don’t think LengthProc always serves the purpose, partly for reasons 
> Nathan also alluded to. Your comment about dict being the only such 
> type having no LengthProc holds only for the Tcl core. It may not hold 
> for extensions where there may be no LengthProc or expensive to 
> calculate (e.g. the database example in TIP 636 abstract list where 
> check for an empty table / query result is a lot faster than 
> calculating the length).
>
> But as you said, that can be futures.
>
> /Ashok
>
> *From:*Jan Nijtmans <jan...@gm...>
> *Sent:* Tuesday, February 11, 2025 3:59 PM
> *To:* apn...@ya...
> *Cc:* Tcl Core List <tcl...@li...>
> *Subject:* Re: [TCLCORE] CFV warning: TIP #711: New function: 
> Tcl_IsEmpty()
>
> Op do 6 feb 2025 om 19:04 schreef Ashok:
>
>     A design related comment - make Tcl_IsEmpty a part of the
>     Tcl_ObjType (like abstract lists). That immediately makes
>     available the same quick check and avoidance of shimmering for new
>     Tcl_Obj types defined within extensions. It is the same exact
>     reason for having the LengthProc method in Tcl_ObjType.
>
> The reason why I didn't propose it because the LengthProc already 
> serves this purpose: If the object
>
> has no string representation and LengthProc exists and returns 0, we 
> are already sure the obj
>
> is empty. The only type which doesn't have a LengthProc is the "dict", 
> implementing
>
> a IsEmpty() would be overkill for only one type (IMHO).
>
> I could imagine a new TIP adding more procs to the Tcl_ObjType (like 
> GetDouble or GetWideInt or
>
> maybe combined as GetNumber). A new function like IsEmpty() is 
> overkill, IMHO, but - hey -
>
> that's only one opinion ;-)
>
> Hope this helps,
>
>        Jan Nijtmans
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

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

I don’t think LengthProc always serves the purpose, partly for reasons Nathan also alluded to. Your comment about dict being the only such type having no LengthProc holds only for the Tcl core. It may not hold for extensions where there may be no LengthProc or expensive to calculate (e.g. the database example in TIP 636 abstract list where check for an empty table / query result is a lot faster than calculating the length).

 

But as you said, that can be futures.

 

/Ashok

 

From: Jan Nijtmans <jan...@gm...> 
Sent: Tuesday, February 11, 2025 3:59 PM
To: apn...@ya...
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV warning: TIP #711: New function: Tcl_IsEmpty()

 

Op do 6 feb 2025 om 19:04 schreef Ashok:

A design related comment - make Tcl_IsEmpty a part of the Tcl_ObjType (like abstract lists). That immediately makes available the same quick check and avoidance of shimmering for new Tcl_Obj types defined within extensions. It is the same exact reason for having the LengthProc method in Tcl_ObjType.

 

The reason why I didn't propose it because the LengthProc already serves this purpose: If the object

has no string representation and LengthProc exists and returns 0, we are already sure the obj

is empty. The only type which doesn't have a LengthProc is the "dict", implementing

a IsEmpty() would be overkill for only one type (IMHO).

 

I could imagine a new TIP adding more procs to the Tcl_ObjType (like GetDouble or GetWideInt or

maybe combined as GetNumber). A new function like IsEmpty() is overkill, IMHO, but - hey -

that's only one opinion ;-)

 

Hope this helps,

       Jan Nijtmans