tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP 714: image driver photo formats

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

My general take is simple enough: try to imagine what would be an ideal interface from Tcl, and adjust the real interface to be as much like that as possible, bearing in mind the realities of what is possible. It can be better to do a larger change while retaining a legacy API (see [trace]) than to struggle on with something less than perfect for the sake of minimalism in changes.

Donal.

-------- Original message --------
From: Harald Oehlmann <har...@el...>
Date: 01/04/2025 11:56 (GMT+00:00)
To: tcl...@li...
Subject: Re: [TCLCORE] TIP 714: image driver photo formats

I understand that the name of the new subcommand is not optimal.
The TIP contains all current proposals.

In addition, the TIP contains a drafted specification of the
capabilities subcommand.
Any opinions welcome, if this makes sense or may just be removed.
The returned list item names are not beautiful neither.
Please comment and I will change the specification.

Re: [TCLCORE] TIP 714: image driver photo formats

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

Dear Tk team,

thanks for the feed-back by Ashok, Paul and Emiliano.
There are no comments rejecting this TIP.

TIP 714 is now updated.

I understand that the name of the new subcommand is not optimal.
The TIP contains all current proposals.

In addition, the TIP contains a drafted specification of the 
capabilities subcommand.
Any opinions welcome, if this makes sense or may just be removed.
The returned list item names are not beautiful neither.
Please comment and I will change the specification.

I have thought two days on the proposal by Emiliano.
Thanks for the pointer to BLT's "picture" image type handler.
This is awesome work.
It may also be possible that this type may by enhanced by this TIP like 
configuring default values or querying option lists like dither methods, 
which may be used in selection boxes later on.

I think, more generic options may later be created on the script level.
For example, a formats method for all image types:

set formats {}
foreach type [image types] {
     if {![catch {image handler $type formats} myFormats]} {
         lappend formats {*}$myFormats
     }
}

Or a photo ensemble, which returns the capabilities:
proc photo {option format} {
     switch -exact $option {
         writesupported {
             return [expr {"write" in [image handler photo capabilities]}]
         }
     }
}

As modifying a C structure is expensive, I like most general interfaces 
on the C level. Any specific function may then be added on the script level.

And of cause, I am not insisting in implementing or proposing this.
I started it, as I see the usage and I already know the code a bit due 
to the metadata extension. Any opinion "stop now, this is useless" is 
welcome!

Thanks for all,
Harald

[TCLCORE] handling loops interruption within a 'try'

[Massimo M. <mas...@ri...>]

I apologize for (ab)using this mailing list to ask a question that maybe 
has a trivial answer.

I just can't have the 'on break' clause be triggered in a loop 
controlled by a 'try' construct

try {
     while {[some_expensive_query]} {

         # ....

         if {[some_intervening_condition]} {
             return -code break -level 0
         }

         # ....
     }
} on break {} {
     puts " ---- break ----"
     puts "Loop interrupted by break"
} on ok {} {
     puts "Loop completed normally"
} finally {
     puts "done"
}

and you have a normal termination even though the loop was interrupted 
prematurely by [some_intervening_condition]

I can get what I want by raising an exception with 'throw' and then 
using the trap clause which allows extra control over the cause of the 
exception (-errorcode receives no special treatment unless the option 
-code error is passed) but what is the purpose of the 'on break' clause 
if it's not handling a break?

  -- Massimo

Re: [TCLCORE] Announcing the tcltk-depot Github organization for extensions

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

Two additional notes:

 

Thanks to Clif for support through TCA.

 

Also, in case anyone is wondering, the existing tcltk organization was also
considered to host the extensions. It was thought better to have a separate
organization for a couple of reasons. First, hosting extensions under tcltk
could possibly imply the extensions were under the control / responsibility
of the TCT. That is very much not the case. Second, tcltk is a mirror of the
source hosted on core fossil and not the primary location for pull requests,
tickets etc. It would be a point of confusion if some repositories under
tcltk were primary and others were not.

 

/Ashok 

 

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Monday, March 31, 2025 4:51 PM
To: tcl...@li...
Subject: [TCLCORE] Announcing the tcltk-depot Github organization for
extensions

 

Announcing the tcltk-depot organization https://github.com/tcltk-depot .

 

TL;DR a central repository for "orphaned" extensions under the auspices of
TCA and maintained by the community. Details as per the README below.

 

(Brian, your TclX update for Tcl 9 could be a candidate.)

 

Current admins are Clif, Harald and myself. Note this is not under the
purview of the TCT.

 

The org has just been set up and is currently empty. Orphaned packages will
be added over time. Please raise a ticket for candidate packages that might
be added following the procedure in the README. Active contributors would be
most welcome.

 

README.md

 

This Github organization, owned by the Tcl Community Association, hosts
repositories for Tcl/Tk packages and applications, in particular those that
are no longer maintained by the original author(s). The intent is to avoid
proliferation of forks by providing a centralized location for users to
download as well as provide patches.

See Repositories
<https://github.com/orgs/tcltk-depot/repositories?q=visibility%3Apublic+arch
ived%3Afalse>  for a list of currently hosted packages.

Requesting an addition

To request addition of a package, please raise a ticket
<https://github.com/tcltk-depot/.github/issues>  with a public URL of the
repository to be added along with contact information of the original
owner/maintainer if available. Ideally, this source repository would have
merged any existing patches or forks.

Note that addition of a repository here does not change the license or
copyright of the package.

Contributing

The tcltk-depot administrators are not responsible for maintenance and
upkeep of the hosted packages. The intent is that this will be a community
effort. If willing to help in this regard,

*         for a one-time contribution to a specific package, create a pull
request (preferred) or create a ticket with an attached patch in that
package's repository

*         for ongoing contributions to one (or a few) repositories, raise a
ticket <https://github.com/tcltk-depot/.github/issues>  in the organization
(not package) to become a collaborator on those repositories

*         for contributing to multiple repositories, it would be easiest to
join tcltk-depot as a member, again by raising a ticket
<https://github.com/tcltk-depot/.github/issues>  in the organization.

 

[TCLCORE] Announcing the tcltk-depot Github organization for extensions

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

Announcing the tcltk-depot organization https://github.com/tcltk-depot .

 

TL;DR a central repository for "orphaned" extensions under the auspices of
TCA and maintained by the community. Details as per the README below.

 

(Brian, your TclX update for Tcl 9 could be a candidate.)

 

Current admins are Clif, Harald and myself. Note this is not under the
purview of the TCT.

 

The org has just been set up and is currently empty. Orphaned packages will
be added over time. Please raise a ticket for candidate packages that might
be added following the procedure in the README. Active contributors would be
most welcome.

 

README.md

 

This Github organization, owned by the Tcl Community Association, hosts
repositories for Tcl/Tk packages and applications, in particular those that
are no longer maintained by the original author(s). The intent is to avoid
proliferation of forks by providing a centralized location for users to
download as well as provide patches.

See Repositories
<https://github.com/orgs/tcltk-depot/repositories?q=visibility%3Apublic+arch
ived%3Afalse>  for a list of currently hosted packages.

Requesting an addition

To request addition of a package, please raise a ticket
<https://github.com/tcltk-depot/.github/issues>  with a public URL of the
repository to be added along with contact information of the original
owner/maintainer if available. Ideally, this source repository would have
merged any existing patches or forks.

Note that addition of a repository here does not change the license or
copyright of the package.

Contributing

The tcltk-depot administrators are not responsible for maintenance and
upkeep of the hosted packages. The intent is that this will be a community
effort. If willing to help in this regard,

*	for a one-time contribution to a specific package, create a pull
request (preferred) or create a ticket with an attached patch in that
package's repository
*	for ongoing contributions to one (or a few) repositories, raise a
ticket <https://github.com/tcltk-depot/.github/issues>  in the organization
(not package) to become a collaborator on those repositories
*	for contributing to multiple repositories, it would be easiest to
join tcltk-depot as a member, again by raising a ticket
<https://github.com/tcltk-depot/.github/issues>  in the organization.

 

[TCLCORE] State of experimental bytecode branch

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

Hi everyone

The state of the experimental branch is that it now builds (with consistent wider bytecode usage) and passes all tests... except for three in assemble.test where I can't see how I tipped them into failure or even why they ever worked. Which is a bit annoying! The failures are wrong line numbers in error messages, so not horribly incorrect code, just off by one in a normally insignificant location.

I've not yet done any performance testing, either of compilation or execution speed; that's next. (I'm currently configured for detailed memory testing so absolutely not a performance build...)

Donal.

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

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

Thanks much, Harald.

/Ashok

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Saturday, March 29, 2025 4:59 PM
To: tcl...@li...
Subject: Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

Op problem, I will take over.

Thanks for all the work,
Harald

Am 29.03.2025 um 07:34 schrieb apnmbx-public--- via Tcl-Core:
> All,
> 
> Even after the discussions in the last meet-up, I’m struggling to 
> progress on TIP 715 due to a lack of clarity in my own mind with regards 
> to platform support definitions, requirements and the rest.
> 
> If someone wants to take it over and drive it, please let me know 
> (Harald, I noticed you had made some updates that seem reasonable).
> 
> Otherwise, I plan to withdraw the TIP.
> 
> /Ashok
> 
> *From:*apnmbx-public--- via Tcl-Core <tcl...@li...>
> *Sent:* Thursday, March 13, 2025 5:23 PM
> *To:* tcl...@li...
> *Subject:* [TCLCORE] TIP 715 - Supported platforms and build 
> environments for Tcl/Tk 9.1
> 
> 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 <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.
> 
> Please review and fill in the ???  for the platforms you are familiar 
> with. Or (less preferable) comment here in the mailing list.
> 
> Note as per the discussion, the TIP also proposes C11 as a requirement 
> for 9.1. I am neutral / ambivalent on that and also not sure if it 
> should be included in this particular TIP.
> 
> /Ashok
> 
> 
> 
> _______________________________________________
> 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

Re: [TCLCORE] TIP 714: image driver photo formats

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

Am 29.03.2025 um 18:16 schrieb Emiliano:
> On Fri, 28 Mar 2025 19:04:58 +0100
> Harald Oehlmann <har...@el...> wrote:
> 
>> Dear Tk team,
>>
>> please allow me to ask for your opinion on TIP714 and its implementation.
>>
>> Is this command seen as valuable?
>> Is the framework extension seen as valuable?
>> Is the chosen backward compatibility feasable?
>> Any other comments.
>>
>> I still plan to implement "image driver photo capabilities format""
>> command, to list the image photo subcommands, which work for a given format.
>> Nevertheless, I would be glad, if the command may be ok in the current form.
>>
>> Thank you all,
>> Harald
> 
> On Fri, 28 Mar 2025 19:04:58 +0100
> Harald Oehlmann <har...@el...> wrote:
> 
>> Dear Tk team,
>>
>> please allow me to ask for your opinion on TIP714 and its implementation.
>>
>> Is this command seen as valuable?
>> Is the framework extension seen as valuable?
>> Is the chosen backward compatibility feasable?
>> Any other comments.
>>
>> I still plan to implement "image driver photo capabilities format""
>> command, to list the image photo subcommands, which work for a given format.
>> Nevertheless, I would be glad, if the command may be ok in the current form.
>>
>> Thank you all,
>> Harald
> 
> A few comments about the terminology and the current image infrastructure.
> 
> Photo and bitmap are image types, not handlers. We already have a command to list those
> 
> % image types
> photo bitmap
> 
> and a command to identify which type an instance image belongs to
> 
> % image type [lindex [image names] 0]
> photo
> 
> The type is the first abstraction below Tk images, and if any further info on image types is required (such as what image formats it supports, color spaces, transparency, etc), I think is better to make this explicit in the command name. While I don't like it completely, [image typeinfo $type] might be more intuitive on what the command does.
> 
> And here is where things goes awry. Image managers are not required to provide an API for querying information about the type. While they indeed keep a lot of information in the type manager, there's no standard way to get such information through the type.
> 
> If we are talking specifically about the photo type (which Tk core owns) feels like cheating to extract information about it without a proper infrastructure in place. Should other type managers be creative and provide info through non-standard methods?
> 
> So my opinion is that what is needed is a proper infrastructure to extract type information from type managers themselves and not skip the type to provide direct access to a piece of information from a particular type.
> 
> Note that I'm not speaking hypotetically. There are other image types in the wild. The current version of the Blt toolkit implements a "picture" image type, with a lot of formats and image operations that we would love to have. For some info see
> 
> https://sourceforge.net/p/blt/src/ci/master/tree/doc/picture.rst
> 
> In conclusion, I think this functionality is valuable but also think we need more machinery in place to get this right. Something to discuss is the format in which such information is returned. If a dictionary is agreed upon, then a key such as "formats" or "-format" might be used to retrieve such info.
> 
> In the meantime, Tk could implement it in some unsupported way, like [tk::unsupported::typeinfo photo formats]. This way it can be trivially converted to the proper infrastructure when (if) it becomes available.
> 


Thanks Emiliano,
you have great insight, I appreciate !
That sounds great.
Please allow me to pass the wheel to you here, as I am a total novice.

Please write the TIP and the implementation, this will be GREAT !

Thanks for all,
Harald

Re: [TCLCORE] TIP 714: image driver photo formats

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

On Fri, 28 Mar 2025 19:04:58 +0100
Harald Oehlmann <har...@el...> wrote:

> Dear Tk team,
> 
> please allow me to ask for your opinion on TIP714 and its implementation.
> 
> Is this command seen as valuable?
> Is the framework extension seen as valuable?
> Is the chosen backward compatibility feasable?
> Any other comments.
> 
> I still plan to implement "image driver photo capabilities format"" 
> command, to list the image photo subcommands, which work for a given format.
> Nevertheless, I would be glad, if the command may be ok in the current form.
> 
> Thank you all,
> Harald

On Fri, 28 Mar 2025 19:04:58 +0100
Harald Oehlmann <har...@el...> wrote:

> Dear Tk team,
> 
> please allow me to ask for your opinion on TIP714 and its implementation.
> 
> Is this command seen as valuable?
> Is the framework extension seen as valuable?
> Is the chosen backward compatibility feasable?
> Any other comments.
> 
> I still plan to implement "image driver photo capabilities format"" 
> command, to list the image photo subcommands, which work for a given format.
> Nevertheless, I would be glad, if the command may be ok in the current form.
> 
> Thank you all,
> Harald

A few comments about the terminology and the current image infrastructure.

Photo and bitmap are image types, not handlers. We already have a command to list those

% image types
photo bitmap

and a command to identify which type an instance image belongs to

% image type [lindex [image names] 0]
photo

The type is the first abstraction below Tk images, and if any further info on image types is required (such as what image formats it supports, color spaces, transparency, etc), I think is better to make this explicit in the command name. While I don't like it completely, [image typeinfo $type] might be more intuitive on what the command does.

And here is where things goes awry. Image managers are not required to provide an API for querying information about the type. While they indeed keep a lot of information in the type manager, there's no standard way to get such information through the type.

If we are talking specifically about the photo type (which Tk core owns) feels like cheating to extract information about it without a proper infrastructure in place. Should other type managers be creative and provide info through non-standard methods?

So my opinion is that what is needed is a proper infrastructure to extract type information from type managers themselves and not skip the type to provide direct access to a piece of information from a particular type.

Note that I'm not speaking hypotetically. There are other image types in the wild. The current version of the Blt toolkit implements a "picture" image type, with a lot of formats and image operations that we would love to have. For some info see

https://sourceforge.net/p/blt/src/ci/master/tree/doc/picture.rst

In conclusion, I think this functionality is valuable but also think we need more machinery in place to get this right. Something to discuss is the format in which such information is returned. If a dictionary is agreed upon, then a key such as "formats" or "-format" might be used to retrieve such info.

In the meantime, Tk could implement it in some unsupported way, like [tk::unsupported::typeinfo photo formats]. This way it can be trivially converted to the proper infrastructure when (if) it becomes available.

-- 
Emiliano

Re: [TCLCORE] TIP 714: image driver photo formats

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

Paul,
thanks a lot for the test, that is great news.

Renaming it to handler is great.
I did that now.

It was me speaking about driver in the metadata extension. It is also in 
error messages. That may be unfortune.

Yes, the default format is always the last format.
If this is not like that, it is an error.
As the default format takes any data, there can not be a following 
format in the test order.

Thanks for all,
Harald

Am 29.03.2025 um 11:25 schrieb Paul Obermeier:
> The new command works fine on Windows and Linux.
> I tried it in conjunction with the Img and imgjp2 extension.
> 
> Two remarks:
> I would call it "image handler" instead of "image driver".
> The photo man page (see section ImageFormats) calls it handler in Tk8.6 
> and Tk9.
> The name "driver" was introduced in Tk9 describing the metadata dictionary.
> In section "Example" another name "image loader" is used.
> So I suggest to call it consistently "handler".
> 
> The format handler match order has changed.
> The default handler is now always the last one, but I think, this was 
> intended.
> See https://tkimg.sourceforge.net/RefMan/files/img.html#section6 on how the
> match order was previously: All Format2 before Format3 handlers.
> 
> Regards,
> Paul
> 
> Am 28.03.2025 um 19:04 schrieb Harald Oehlmann:
>> Dear Tk team,
>>
>> please allow me to ask for your opinion on TIP714 and its implementation.
>>
>> Is this command seen as valuable?
>> Is the framework extension seen as valuable?
>> Is the chosen backward compatibility feasable?
>> Any other comments.
>>
>> I still plan to implement "image driver photo capabilities format"" 
>> command, to list the image photo subcommands, which work for a given 
>> format.
>> Nevertheless, I would be glad, if the command may be ok in the current 
>> form.
>>
>> Thank you all,
>> Harald
>>
>>
>> _______________________________________________
>> 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


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

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

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

Op problem, I will take over.

Thanks for all the work,
Harald

Am 29.03.2025 um 07:34 schrieb apnmbx-public--- via Tcl-Core:
> All,
> 
> Even after the discussions in the last meet-up, I’m struggling to 
> progress on TIP 715 due to a lack of clarity in my own mind with regards 
> to platform support definitions, requirements and the rest.
> 
> If someone wants to take it over and drive it, please let me know 
> (Harald, I noticed you had made some updates that seem reasonable).
> 
> Otherwise, I plan to withdraw the TIP.
> 
> /Ashok
> 
> *From:*apnmbx-public--- via Tcl-Core <tcl...@li...>
> *Sent:* Thursday, March 13, 2025 5:23 PM
> *To:* tcl...@li...
> *Subject:* [TCLCORE] TIP 715 - Supported platforms and build 
> environments for Tcl/Tk 9.1
> 
> 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 <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.
> 
> Please review and fill in the ???  for the platforms you are familiar 
> with. Or (less preferable) comment here in the mailing list.
> 
> Note as per the discussion, the TIP also proposes C11 as a requirement 
> for 9.1. I am neutral / ambivalent on that and also not sure if it 
> should be included in this particular TIP.
> 
> /Ashok
> 
> 
> 
> _______________________________________________
> 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

Re: [TCLCORE] TIP 714: image driver photo formats

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

Ashok,
thanks for the comment.

I added the forgotten specification, thanks pointing this out.

We have two image type drivers: photo and bitmap.

I don't know, if bitmap is still used anywhere.
But as we must always walk up the call hirarchy, we must follow this:
Image type registration.
Within photo image: image format registration.

Basically, only the photo image type is concerned.
Thats why there are no definitions for all.

This would change, if the new "handler command is used to access image 
format drivers. There are many and many extensions possible.

Thanks for all,
Harald

Am 29.03.2025 um 06:19 schrieb apn...@ya...:
> Harald,
> 
> Don't know enough about either Tk or image processing to comment in depth, but where is the new Tcl_ImageDriverProc API defined? I don't see it in the TIP. And assuming there is a standard set of command values shared amongst all drivers, those should also be listed along with their semantics.
> 
> /Ashok
> 
> -----Original Message-----
> From: Harald Oehlmann <har...@el...>
> Sent: Friday, March 28, 2025 11:35 PM
> To: Tcl Core List <tcl...@li...>
> Subject: [TCLCORE] TIP 714: image driver photo formats
> 
> Dear Tk team,
> 
> please allow me to ask for your opinion on TIP714 and its implementation.
> 
> Is this command seen as valuable?
> Is the framework extension seen as valuable?
> Is the chosen backward compatibility feasable?
> Any other comments.
> 
> I still plan to implement "image driver photo capabilities format""
> command, to list the image photo subcommands, which work for a given format.
> Nevertheless, I would be glad, if the command may be ok in the current form.
> 
> Thank you all,
> Harald
> 


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

Re: [TCLCORE] TIP 714: image driver photo formats

[Paul O. <pa...@po...>]

The new command works fine on Windows and Linux.
I tried it in conjunction with the Img and imgjp2 extension.

Two remarks:
I would call it "image handler" instead of "image driver".
The photo man page (see section ImageFormats) calls it handler in Tk8.6 and Tk9.
The name "driver" was introduced in Tk9 describing the metadata dictionary.
In section "Example" another name "image loader" is used.
So I suggest to call it consistently "handler".

The format handler match order has changed.
The default handler is now always the last one, but I think, this was intended.
See https://tkimg.sourceforge.net/RefMan/files/img.html#section6 on how the
match order was previously: All Format2 before Format3 handlers.

Regards,
Paul

Am 28.03.2025 um 19:04 schrieb Harald Oehlmann:
> Dear Tk team,
>
> please allow me to ask for your opinion on TIP714 and its implementation.
>
> Is this command seen as valuable?
> Is the framework extension seen as valuable?
> Is the chosen backward compatibility feasable?
> Any other comments.
>
> I still plan to implement "image driver photo capabilities format"" command, to list the image photo subcommands, which work for a given format.
> Nevertheless, I would be glad, if the command may be ok in the current form.
>
> Thank you all,
> 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

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

All,

 

Even after the discussions in the last meet-up, I'm struggling to progress
on TIP 715 due to a lack of clarity in my own mind with regards to platform
support definitions, requirements and the rest.

 

If someone wants to take it over and drive it, please let me know (Harald, I
noticed you had made some updates that seem reasonable).

 

Otherwise, I plan to withdraw the TIP.

 

/Ashok

 

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Thursday, March 13, 2025 5:23 PM
To: tcl...@li...
Subject: [TCLCORE] TIP 715 - Supported platforms and build environments for
Tcl/Tk 9.1

 

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.

 

Please review and fill in the ???  for the platforms you are familiar with.
Or (less preferable) comment here in the mailing list.

 

Note as per the discussion, the TIP also proposes C11 as a requirement for
9.1. I am neutral / ambivalent on that and also not sure if it should be
included in this particular TIP.

 

/Ashok

Re: [TCLCORE] TIP 714: image driver photo formats

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

Harald,

Don't know enough about either Tk or image processing to comment in depth, but where is the new Tcl_ImageDriverProc API defined? I don't see it in the TIP. And assuming there is a standard set of command values shared amongst all drivers, those should also be listed along with their semantics.

/Ashok

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Friday, March 28, 2025 11:35 PM
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] TIP 714: image driver photo formats

Dear Tk team,

please allow me to ask for your opinion on TIP714 and its implementation.

Is this command seen as valuable?
Is the framework extension seen as valuable?
Is the chosen backward compatibility feasable?
Any other comments.

I still plan to implement "image driver photo capabilities format"" 
command, to list the image photo subcommands, which work for a given format.
Nevertheless, I would be glad, if the command may be ok in the current form.

Thank you all,
Harald

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

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

I like the concept of a public "Tcl_List" type. However, given it requires significantly more changes to make use of it, it feels more like a Tcl 10 thing (whenever that comes to be!)

/Ashok

-----Original Message-----
From: Donald G Porter via Tcl-Core <tcl...@li...> 
Sent: Monday, March 24, 2025 7:16 PM
To: tcl...@li...
Subject: Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

On 3/20/25 11:50, Jan Nijtmans wrote:
> This is a CFV warning for TIP #626. for Tcl 9.1+:
>      Command arguments > 2^31 elements
>      <https://core.tcl-lang.org/tips/doc/trunk/tip/626.md>
>
> If you think this is a bad idea, speak up now. If not,
> I'll start the vote in a few days.
I regret that I did not notice this unfinished business before the release of Tcl 9.

Tcl has long defined the Tcl_ObjCmdProc type for extensions to define their own command procedures.  TIP 626 adds a new TclObjCmdProc2 type which is nearly the same, but accepts a Tcl_Size number of command words, instead of an int number.  The same thing, but bigger.  But different enough to need some disruption to achieve the transition.

Several Tcl users see the disruption, and don't see the value provided by it, thinking they have no interest in their extension commands being able to process such large numbers of arguments.

Consider this alternative conception.  We create a new command procedure type, but not just "the same but bigger".  Instead, the new type is "more generalized and powerful".

The connection between commands and lists has always been important in Tcl.  Starting with the introduction of the {*} syntax, Tcl lists became fundamental to the very definition of the language.  Yet, Tcl has no public feature in its C interface to represent lists. Whenever Tcl lists must pass as arguments in C, we either choose to pass a (Tcl_Obj *) and then check that the value is a usable list, or we pass an array of Tcl_Obj*.

Imagine we add a public Tcl_List type, so that a single argument can be passed in C that represents a Tcl list.  Imagine its functions and operations are kept abstract enough that it can accommodate lists larger than INT_MAX elements.  Imagine further that the abstract interface doesn't force data structures of a single array, so that the innovations already present in [lseq] and its internal supports can also be passed freely through Tcl interfaces.  Many alternative supporting internals can be conceived.

With that innovation, it is far more natural to offer to extensions a new command procedure format that lets their commands directly pull the parsed words of an executing command from an abstract list argument, so that extension operations can gain any efficiencies better internal list representations offer.

Consider

typedef int (Tcl_CmdProcList) (void *clientData, Tcl_Interp *interp, Tcl_List list);

Now this is a new public interface offering all extensions improved access to efficiencies of operation current and future, and the expansion to Tcl_Size number of words in an executing command also comes in almost as an afterthought.

This new mechanism for extension-defined commands rests more comfortably alongside Tcl_ObjCmdProc, so I see less urgency with deprecating that older mechanism out of existence.  People happy with its limitations could just continue being happy with its limitations, with no need to change anything.  An extension can do nothing, or embrace the new capabilities fully, or write very trivial wrappers around their existing Tcl_ObjCmdProcs.

Taking this approach, we can immediately fully test these interfaces, even on systems without large memory, by testing with the existing [lseq] machinery which represents very large lists without using very large amounts of memory.

This approach should also mesh well (and hopefully accelerate) the innovations brought in with [lseq] and develop tools we will need anyway to improve efficiencies of non-shimmering access to list operations on extension-provided Tcl_ObjTypes.  Since this new mechanism would be the only way to create an extension command accepting more than INT_MAX arguments, that would accelerate making use of the new Tcl_List interfaces generally.

All I currently offer are ideas, not implementations.  But it's another way to go.  At least in concept I like it better, but I recognize that at some point working code beats dreamy concept.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|



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

[TCLCORE] TIP 714: image driver photo formats

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

Dear Tk team,

please allow me to ask for your opinion on TIP714 and its implementation.

Is this command seen as valuable?
Is the framework extension seen as valuable?
Is the chosen backward compatibility feasable?
Any other comments.

I still plan to implement "image driver photo capabilities format"" 
command, to list the image photo subcommands, which work for a given format.
Nevertheless, I would be glad, if the command may be ok in the current form.

Thank you all,
Harald

Re: [TCLCORE] TclX for 9.0

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

Thanks Donal, this looks like an appropriate home for it. I should start by forking the flightaware repo, then rebase my changes to the tcltk based fork.
There’s still more bits to finish yet.

-Brian
(from mobile device)

On Mar 27, 2025, at 22:42, Donal Fellows <don...@ma...> wrote:


I'm sure this could be a repository within https://github.com/tcltk/ without any fuss. We "have the keys" to that organisation, and TclX would be a reasonable candidate for hosting there.

Donal.

-------- Original message --------
From: Brian Griffin <bri...@ea...>
Date: 27/03/2025 23:33 (GMT+00:00)
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] TclX for 9.0

I have a good part of Tclx passing tests on linux.
I would like to establish an "official"? home repository for this.

Re: [TCLCORE] TclX for 9.0

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

I'm sure this could be a repository within https://github.com/tcltk/ without any fuss. We "have the keys" to that organisation, and TclX would be a reasonable candidate for hosting there.

Donal.

-------- Original message --------
From: Brian Griffin <bri...@ea...>
Date: 27/03/2025 23:33 (GMT+00:00)
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] TclX for 9.0

I have a good part of Tclx passing tests on linux.
I would like to establish an "official"? home repository for this.

[TCLCORE] TclX for 9.0

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

I have a good part of Tclx passing tests on linux.
I would like to establish an "official"? home repository for this. This work is based on https://github.com/flightaware/tclx master. (There is a TCL9 branch, but it contains no changes from trunk)

If anyone can point me to a repo and grant me access, I'll upload the changes. (flightaware, are you listening?)

My current state as I've documented in the ChangeLog file:

                **** Ported to Tcl 9.0 ****

                * TCLX 9.0.0
                * tclXmath.c deprecated. Redundant behavior with Tcl core
                * int -> Tcl_Size throughout (i.e. 32-bit to 64-bit sizes)
                * chmod: argument change from decimal to octal
                * dup: not yet working
                * profile: not yet working
                * TclX_RelativeExpr: partially done.
                * convlib: Is this useful? "parsing" tcl scripts is
                *          rudementary. no longer relevant for Tcl 9.
                *          Needs rewrite.
                * tests: tests are passing where appropriate.


Thanks,
-Brian

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

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

Jan Nijtmans writes:
> Op ma 24 mrt 2025 om 13:35 schreef Rolf Ade <tcl...@pu...>:
>> > I confirm what Ashok reports here; I get the same. If I haven't missed
>> > something watching top during the test run you'll need around 60 GByte
>> > free memory to reproduce by yourself.
>>
>> Digging a bit this gets stranger. If run interactivly in a tip-626
>> branch tclsh I see what Ashok reports.
>
> The root cause is - probably - that somewhere in the code 'int'
> is still used in stead of Tcl_Size. I now used the C4244 warning
> in Visual Studio to find such places, and found some. Can
> you re-try with the latest "tip-626" branch?

 ~/tcltk/bin/tip-626-default/bin/tclsh9.1 
% set s [string cat {*}[lrepeat 0x100000000 x]]; string length $s              
4294967296

Yes, this seems to work now.

rolf

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

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

Op ma 24 mrt 2025 om 13:35 schreef Rolf Ade <tcl...@po...>:
> > I confirm what Ashok reports here; I get the same. If I haven't missed
> > something watching top during the test run you'll need around 60 GByte
> > free memory to reproduce by yourself.
>
> Digging a bit this gets stranger. If run interactivly in a tip-626
> branch tclsh I see what Ashok reports.

The root cause is - probably - that somewhere in the code 'int'
is still used in stead of Tcl_Size. I now used the C4244 warning
in Visual Studio to find such places, and found some. Can
you re-try with the latest "tip-626" branch?

I'm getting (on a Windows machine with 16 Gb memory:
>tclsh91s.exe
% set s [string cat {*}[lrepeat 0x100000000 x]]; string length $s
unable to alloc 67108864040 bytes
>tclsh91s.exe
% set s [list abc {*}[lrepeat 0x100000000 x]]; lrange $s 0 1
list construction failed: unable to alloc 34359738416 bytes
% set s [lrepeat 0x100000000 x]; lrange $s 0 1
x x

My machine doesn't have enough memory for
such experiments.

Note that the last example doesn't crash the interpreter,
but cleans-up and gives an error-message. That should
be done in more places ....

Thanks!
      Jan Nijtmans

Re: [TCLCORE] How do we deprecate a command?

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

Thank you, Gustaf.  That was very helpful!

When I poked around in the Tcl and Tk code I discovered that the identical
mechanism for deprecating C code is alread in place.  In the file
generic/tcl.h there are macros
  # define TCL_DEPRECATED(msg) EXTERN TCL_DEPRECATED_API(msg)
and
  #define TCL_DEPRECATED_API(msg)  __attribute__ ((__deprecated__ (msg)))
There is also a macro Tk_DEPRECATED(msg) which uses the Tcl version.

There are conditional directives that prevent those macros from being
defined for versions of gcc which are too old to support the attribute
(which means very old).  Also it turns out that clang supports the same
attribute with the same syntax and MSVC has an equivalent construction
which is (of course) slightly different.  (They use __declspec(deprecated.)

Also, the script tools/genStubs.tcl is aware of those macros and will use
them under certain conditions which can be discovered by carefully reading
the script and deciphering the code:

if {[info exists stubs($name,deprecated,$index)]} {
        append text "[string toupper
$libraryName]_DEPRECATED(\"$stubs($name,deprecated,$index)\")\n"
        set line "$rtype"
    }

One of my goals is to deprecate the stub Tk_SetGrid, so this is good news
for me, once I figure out how to make it work.

I should mention that the macro definitions are preceded by the comment:

/*
 * Allow a part of Tcl's API to be explicitly marked as deprecated.
 *
 * Used to make TIP 330/336 generate moans even if people use the
 * compatibility macros. Change your code, guys! We won't support you
forever.
 */

So it looks to me like Tcl and Tk have already addressed the issue of how
to create compiler warnings when people use deprecated parts of the C API.
(Except it was only done for gcc and clang.)  However, I could find no
cases where either of those macros were being used in the current code, nor
any stubs which are currently deprecated.

Deprecation has become a lost art, it seems..

Incidentally, TIP #330 (from 2008) is  Eliminate interp->result from the
Public Headers <https://core.tcl-lang.org/tips/doc/trunk/tip/330.md>.

- Marc

On Tue, Mar 25, 2025 at 3:51 AM Gustaf Neumann (sslmail) <ne...@wu...>
wrote:

> Hi all,
>
> Below is an overview of how NaviServer handles deprecation in various
> parts of the codebase.
> Maybe this serves as useful food for thought for refining a common
> infrastructure in Tcl.
>
> 1. *Deprecating a C Function:* To mark a C function as deprecated, we add
> a specific attribute. The compiler then emits a warning when this function
> is used. For example:
>
>    NS_EXTERN const char * Ns_ConnLocation(Ns_Conn *conn)
>        NS_GNUC_DEPRECATED_FOR(Ns_ConnLocationAppend);
>
>
>    This tells developers to use `Ns_ConnLocationAppend` instead.
>
>
> 2. *Fine-Grained Deprecation (e.g. Options, Configuration Parameters,
> etc.): *For more granular deprecation - such as individual options or
> configuration parameters — NaviServer uses:
>
>
>    Ns_LogDeprecated(Tcl_Obj *const* objv, TCL_SIZE_T objc, const char
> *alternative, const char *explanation)
>        NS_GNUC_NONNULL(1);
>
>
>    This function logs deprecation warnings, optionally providing an
> alternative and an explanation.
>
>
> 3. *Scripting-Level Deprecation:* At the scripting level, NaviServer
> provides a procedure to mark features as deprecated:
>
>
>    proc ns_deprecated {{alternative ""} {explanation ""}} {,,,}
>
>
>    This allows script-level deprecation messages.
>
>
> *Compiler Deprecation Macro*
>
> The macro below defines the deprecation attribute for GNU C compilers
> (version 4.5 or newer), so that developers get a clear warning with an
> alternative suggestion:
>
>
>    #if __GNUC_PREREQ(4,5)
>    # define NS_GNUC_DEPRECATED_FOR(f) __attribute__((deprecated("Use " #f
> " instead")))
>    #else
>    # define NS_GNUC_DEPRECATED_FOR(f) NS_GNUC_DEPRECATED
>    #endif
>
>
>
> NaviServer 5 introduces a dedicated deprecation severity level, which can
> be easily toggled on or off (see [1] for details).
>
> NSF follows the same patter: When used inside NaviServer, logging is
> directed to the NaviServer system log; when used externally, it writes to
> stderr. The logging procedure is designed to be redefined, for example, to
> route messages to a custom window.
>
> Aside the coding side, NaviServer following the following policies
> - NaviServer provides an optional macro NS_NO_DEPRECATED for compiling
> without deprecated code (this excludes the depreciation since the last
> release to give people a time window to adjust) - somewhat similar
> to TCL_NO_DEPRECATED
> - deprecated Tcl-level calls are removed from the documentation, but the
> documentation still lists it.  We do no want to “advertise” deprecated
> functions.
>
> all the best
> -g
>
> [1] https://naviserver.sourceforge.io/5.0/naviserver/files/ns_log.html
> [2]
> https://naviserver.sourceforge.io/5.0/naviserver/files/commandlist.html
>
>
> On 25.03.2025, at 08:04, Harald Oehlmann <har...@el...>
> wrote:
>
> Hi Mark,
> to my knowledge:
>
> - author a TIP and vote it
>
> - modify functionality (in case of "wm grid": make it a no-op or modify it)
>
> - put the functionality to remove in:
> #ifdef TK_NO_DEPRECATED
>
> - put a note in the man page that it is a deprecated feature.
> This is the nroff file in the doc folder.
>
> Take care,
> Harald
>
> Am 24.03.2025 um 23:33 schrieb Marc Culler:
>
> Thanks, Don.  Could you give me a hint about where to look for that?
> What I can see, by looking at generic/tclIOUtil.c, is that when a function
> becomes obsolete nothing is done other than to add a comment /* Obsolete */
> in the source code.  Presumably it just vanishes one day.  Sometimes there
> are also comments suggesting a version in which a certain function should
> be removed.  But I don't see any sign of any effort to notify a user that
> they have used an obsolete function or command, e.g. by printing a message
> to stderr.
> In the case of wm grid, nothing would really break when it becomes a no-
> op.  There is no evidence that there are any programs (other than the
> widget demo) which use it, but even if one did exist, the worst that would
> happen is that a toplevel would become smoothly resizable instead of being
> resizable only to multiples of a certain number of pixels in each
> direction.  And that is only on X11 - it is already a no-op  on Windows and
> Aqua, in the sense that it has no effect on the sizes that a toplevel can
> be resized to.  Nonetheless it causes dramatic breakage by corrupting the
> internal Tk window structures on all platforms, as can be seen in the
> "split windows" demo.  So there would be an overall reduction in breakage
> if that command were simply quietly removed from the language.
> Still, it seems like it might be better if there were some sort of
> notification that the behavior has been changed intentionally.  But I am
> getting the impression that there is no expectation of such a thing, nor
> any standard way of doing it.
> - Marc
> On Mon, Mar 24, 2025 at 11:46 AM Donald G Porter via Tcl-Core <tcl-
> co...@li... <mailto:tcl...@li...>> wrote:
>    For an example (that you can follow or not), look at how the [case]
>    command was
>    removed from the built-in command set of Tcl.
>    On 3/24/25 12:17, Marc Culler wrote:
>     > Suppose that a command, let's say the command "wm grid", is going
>    to be removed from Tk.  Even though we suspect that no one is using
>    it in any applications, we would like to do the removal in two
>    stages.  First modify it so it is a no-op, then remove it.
>     >
>     > The natural thing to do when the command  becomes a no-op would
>    be to generate a deprecation message which says that the command is
>    deprecated and no longer has any effect.  What is the standard way
>    to do that? Just print the message to stderr?  Or is there something
>    better, perhaps built-in to Tcl, which is usually used in this
>    situation?
>     >
>     > - Marc
>
> _______________________________________________
> 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
>

Re: [TCLCORE] How do we deprecate a command?

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

Yes, we have relatively well established methods of working for C (getting better as we adopt more features like [[deprecated]] attributes there). I was thinking more about the Tcl level, where the final removal of [case] and the old [puts] form happened a very long time after it ceased to be documented, and there wasn't a habit of telling users if they used something they shouldn't any more.

We might want to make a command to help with this so that we can deprecate ensemble subcommands more easily. It wouldn't help with all scenarios, but would with many of them (including [wm grid], which inspired this discussion, providing [wm] became a true ensemble).

Donal.


-------- Original message --------
From: Donald G Porter <don...@ni...>
Date: 25/03/2025 17:27 (GMT+00:00)
To: Donal Fellows <don...@ma...>, Steve Landers <st...@di...>, Tcl Core List <tcl...@li...>, Marc Culler <cul...@gm...>
Subject: Re: [TCLCORE] How do we deprecate a command?


A few more examples...

     Replacing Tcl_SaveResult() and friends with Tcl_SaveInterpState() and friends

     Replacing Tcl_CreateMathFunc() and friends with definition of math functions as commands.

Create the replacement first, then favor it, then stop documenting the old, then destroy it.

On 3/25/25 05:30, Donal Fellows wrote:
> For a print-once-on-first-use, I'd probably use an enter execution trace on the command that unregisters itself when called as well as printing the message. The only real difficulty is in determining the correct route to write such messages where they'll be picked up by someone who can do something about them; there's a sense in which [tclLog] is just kicking the can down the road (though it might be the right way anyway).
>
> Longer term, for a Tcl or Tk command the first thing would be to update its documentation to say that it is deprecated (as well as adding the warning message). The step beyond that (presumably with a release between to allow users to learn they should migrate) is to stop documenting the command. Final removal can come later. Those three phases probably ought to be announced.
>
> If there's a recommended replacement, the deprecation message should mention it. If there is no replacement, the deprecation message should encourage users to contact us if they need the feature.
>
> Donal.
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Steve Landers
> *Sent:* Tuesday, March 25, 2025 02:43
> *To:* Donald G Porter; Tcl Core List; Marc Culler
> *Subject:* Re: [TCLCORE] How do we deprecate a command?
>
> Does tclLog include a standard mechanism to flag deprecated code?  Does it ensure a deprecation message is only shown once and not every time the deprecated command is called?
>
> Not trying to be argumentative I just don’t think your message was particularly helpful in the context of what Marc was asking.
>
> -- Steve
> On 25 Mar 2025 at 10:17 AM +0800, Steve Landers <st...@di...>, wrote:
>
>     FWIW I like the macOS approach of warning about the use of deprecated features with a message to stdout unlike macOS I would prefer seeing the message only once for each tcl “session” and only for one release before removal.  If we had a generic mechanism to do that I’m sure we could use it in a number of places.
>
>     -- Steve
>     On 25 Mar 2025 at 6:34 AM +0800, Marc Culler <cul...@gm...>, wrote:
>
>         Thanks, Don.  Could you give me a hint about where to look for that?
>
>         What I can see, by looking at generic/tclIOUtil.c, is that when a function becomes obsolete nothing is done other than to add a comment /* Obsolete */ in the source code.  Presumably it just vanishes one day.  Sometimes there are also comments suggesting a version in which a certain function should be removed.  But I don't see any sign of any effort to notify a user that they have used an obsolete function or command, e.g. by printing a message to stderr.
>
>         In the case of wm grid, nothing would really break when it becomes a no-op.  There is no evidence that there are any programs (other than the widget demo) which use it, but even if one did exist, the worst that would happen is that a toplevel would become smoothly resizable instead of being resizable only to multiples of a certain number of pixels in each direction.  And that is only on X11 - it is already a no-op  on Windows and Aqua, in the sense that it has no effect on the sizes that a toplevel can be resized to.  Nonetheless it causes dramatic breakage by corrupting the internal Tk window structures on all platforms, as can be seen in the "split windows" demo.  So there would be an overall reduction in breakage if that command were simply quietly removed from the language.
>
>         Still, it seems like it might be better if there were some sort of notification that the behavior has been changed intentionally.  But I am getting the impression that there is no expectation of such a thing, nor any standard way of doing it.
>
>         - Marc
>
>         On Mon, Mar 24, 2025 at 11:46 AM Donald G Porter via Tcl-Core <tcl...@li... <mailto:tcl...@li...>> wrote:
>
>
>             For an example (that you can follow or not), look at how the [case] command was
>             removed from the built-in command set of Tcl.
>
>             On 3/24/25 12:17, Marc Culler wrote:
>             > Suppose that a command, let's say the command "wm grid", is going to be removed from Tk.  Even though we suspect that no one is using it in any applications, we would like to do the removal in two stages.  First modify it so it is a no-op, then remove it.
>             >
>             > The natural thing to do when the command  becomes a no-op would be to generate a deprecation message which says that the command is deprecated and no longer has any effect.  What is the standard way to do that? Just print the message to stderr?  Or is there something better, perhaps built-in to Tcl, which is usually used in this situation?
>             >
>             > - Marc
>
>             --
>             | Don Porter            Applied and Computational Mathematics Division |
>             | don...@ni... <mailto:don...@ni...>             Information Technology Laboratory |
>             | https://urldefense.com/v3/__http://math.nist.gov/*DPorter/__;fg!!PDiH4ENfjr2_Jw!H9XrViOXpHrYjVSS8tUlH2WUxzxRNzttKChgkNwCW94GIq7MuB1IRxTfnFwZ7koGUq3ORAD66h7kkFXVXHL61FZT6Pbo7jaiu3alJQ$ [math[.]nist[.]gov] [math.nist.gov] <https://urldefense.com/v3/__http://math.nist.gov/*DPorter/__;fg!!PDiH4ENfjr2_Jw!BvU5DdXvtsizKifWaxJusXFv6B9WUS4W46jf7E7UkDhGPuYPxQx7C2wj2WKdCVDGFYZDw4WczHmYMyHTZFHkz4odzYHUwIPQ$>                           NIST |
>             |______________________________________________________________________|
>
>
>
>             _______________________________________________
>             Tcl-Core mailing list
>             Tcl...@li... <mailto:Tcl...@li...>
>             https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!H9XrViOXpHrYjVSS8tUlH2WUxzxRNzttKChgkNwCW94GIq7MuB1IRxTfnFwZ7koGUq3ORAD66h7kkFXVXHL61FZT6Pbo7jYbE7ir6Q$ [lists[.]sourceforge[.]net] [lists.sourceforge.net] <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!BvU5DdXvtsizKifWaxJusXFv6B9WUS4W46jf7E7UkDhGPuYPxQx7C2wj2WKdCVDGFYZDw4WczHmYMyHTZFHkz4odzcpcSIAk$>
>
>         _______________________________________________
>         Tcl-Core mailing list
>         Tcl...@li...
>         https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!H9XrViOXpHrYjVSS8tUlH2WUxzxRNzttKChgkNwCW94GIq7MuB1IRxTfnFwZ7koGUq3ORAD66h7kkFXVXHL61FZT6Pbo7jYbE7ir6Q$ [lists[.]sourceforge[.]net] [lists.sourceforge.net] <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!BvU5DdXvtsizKifWaxJusXFv6B9WUS4W46jf7E7UkDhGPuYPxQx7C2wj2WKdCVDGFYZDw4WczHmYMyHTZFHkz4odzcpcSIAk$>
>
>     _______________________________________________
>     Tcl-Core mailing list
>     Tcl...@li...
>     https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!H9XrViOXpHrYjVSS8tUlH2WUxzxRNzttKChgkNwCW94GIq7MuB1IRxTfnFwZ7koGUq3ORAD66h7kkFXVXHL61FZT6Pbo7jYbE7ir6Q$ [lists[.]sourceforge[.]net] [lists.sourceforge.net] <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!BvU5DdXvtsizKifWaxJusXFv6B9WUS4W46jf7E7UkDhGPuYPxQx7C2wj2WKdCVDGFYZDw4WczHmYMyHTZFHkz4odzcpcSIAk$>
>


--
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| https://urldefense.com/v3/__http://math.nist.gov/*DPorter/__;fg!!PDiH4ENfjr2_Jw!H9XrViOXpHrYjVSS8tUlH2WUxzxRNzttKChgkNwCW94GIq7MuB1IRxTfnFwZ7koGUq3ORAD66h7kkFXVXHL61FZT6Pbo7jaiu3alJQ$ [math[.]nist[.]gov]                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] "Old" tk image type interface

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

Dear Don,
thanks for the quick answer, great.

That was a great hint. Indeed, it depends on USE_OLD_IMAGE and it is 
removed in Tk9.0.

The old image has and char * argv argument, instead of TCL_OBJ.

So, Tk 8.6 contains:
#ifdef USE_OLD_IMAGE
#undef Tk_CreateImageType
#define Tk_CreateImageType		Tk_CreateOldImageType
#undef Tk_CreatePhotoImageFormat
#define Tk_CreatePhotoImageFormat	Tk_CreateOldPhotoImageFormat
#endif /* USE_OLD_IMAGE */

and
Tk_CreateOldImageType(

is defined there.

All this is gone in 9.0.

So, we may remove those leftovers for 9.0 and main.

THanks for the insights, I appreciate !
Harald


Am 25.03.2025 um 18:11 schrieb Donald G Porter via Tcl-Core:
> This is code that supports the use of
> 
> #define USE_OLD_IMAGE
> 
> in extensions and apps, right?
> 
> The boundary is that Tk 8.6 allows for this and Tk 9.0 does not.
> 
> Please please please don't tinkertoy with this in a very late Tk 8.6.* 
> patchlevel
> The curtain has already been drawn in and orderly way.  Dont' move it.
> 
> If there are lingering bits and pieces in Tk 9 that didn't get cleared 
> away, lets take care of it.
> 
> On 3/25/25 10:43, Harald Oehlmann wrote:
>> Dear Tk experts,
>> its me again, tomatos on my eyes or real question?
>>
>> File generic/tkImage.c
>>
>> has an "old" and a "normal" list of image types (image types are 
>> bitmap or photo currently).
>>
>> The thread specific data is:
>> typedef struct {
>>     Tk_ImageType *imageTypeList;/* First in a list of all known image
>>                  * types. */
>>     Tk_ImageType *oldImageTypeList;
>>                 /* First in a list of all known old-style
>>                  * image types. */
>>     int initialized;        /* Set to 1 if we've initialized the
>>                  * structure. */
>> } ThreadSpecificData;
>>
>> I don't see any way to add an item to "oldImageTypeList.
>>
>> For the normal "imageTypeList", there is the exported API: 
>> "Tk_CreateImageType".
>>
>> But there is nothing for the old one.
>>
>> My question is: may the old one be removed (with lost of dependent 
>> code) or are I am missing something?
>>
>> I suppose, this may also removed in 8.6...
>>
>> Thanks for any light...
>>
>> Harald
>>
>> P.S.: if you try branch "tip-714-image-driver-info", you get:
>> % image format photo list
>> svg ppm default png gif
>>
>> The side-effect of this TIP is, that we have a command interface to 
>> the image type code and it may expose functionality.
>>
>> Ideas are:
>> % image format photo capabilities gif
>> read write data
>>
>> % image format photo configure gif -interpolation 1
>>