tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] CFV: TIP #712: Add "positive" options to the subst command

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

TIP #712 : YES

I particularly like the clever implementation, congratulations!

Regards,

Francois

Le 02/06/2025 à 18:28, Reinhard Max a écrit :
> This is a Call For Votes for TIP 712:
> Add "positive" options to the subst command
>
> Please send your votes until Jun 15, 12:00 UTC
> [clock format 1749988800].
>
> My vote:
> TIP #712:   YES
>
> cu
> Reinhard
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] expose content of macOS' Info.plist

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

There are a few layers to this.

First, a quick experiment on my computer reveals that it would be easy to
make some parts of the Info.plist available within Tk.  There is no problem
accessing the data.  It could be stored, in some format, in a static
variable or in the NSApplication object.  And it would be straightforward
to add a command which returned some of the data in some form.  I don't
know whether ::tk::mac or ::tk::unsupported would be a better namespace for
such a command.

However, the next layer is quite a cesspool.  I guess everyone thinks it is
trivial to design a format for something which is basically a
dictionary with strings for keys and a limited set of value types, such as
strings, numbers, arrays of strings, arrays of numbers, and other
dictionaries which satisfy the same conditions.  The red flag pops up when
you list the different schemes that exist for doing this.  Restricting to
the most popular, we have at least the .ini format, the .json format, the
.toml format, the .yml format and the .plist format.  If this really were
such a simple thing, then why would people have tried so many different
ways of doing it, and still be completely unable to declare any one of
these to be s standard.  And one approach to doing this project would lead
to yet another such scheme.  (yayaml?)

So, while I think this is an easy thing to do at the first level, if this
project is going to go forward, the second level needs to be addressed.
What I think is needed is a very clear and specific list of exactly which
data need to be made available.  And that list should be very restrictive.
The existence of http://www.apple.com/DTDs/PropertyList-1.0.dtd is not very
helpful.  It does specify the allowed types for values, but that is obvious
(that is a reference to the "o" in "toml").  As far as I know, there does
not exist a comprehensive list of allowable keys.  Apple's documentation
lists some keys that are allowed but also makes it clear that the list is
incomplete and the descriptions of the keys that are documented are often
extremely vague.

So the starting point would be to (drastically) limit the scope.

- Marc



On Tue, Jun 3, 2025 at 11:05 AM Donal Fellows <
don...@ma...> wrote:

> I see no reason why there shouldn't be a small macOS-specific extension
> (along the lines of the Windows-specific dde and registry extensions)
> distributed with either Tcl or Tk (I'm not sure which would be the better
> home, but maybe Tk as that's already set up for working with ObjC and
> that's much easier to use for the native APIs from what I see), as long as
> it's doing read-only access to the bundle data.
>
> Read-write access would be something else entirely, and have a *lot* more
> complex questions involved (such as around Apple's security policies).
>
> Donal.
>
> ------------------------------
> *From:* Kevin Walzer <kw...@co...>
> *Sent:* Tuesday, June 03, 2025 15:05
> *To:* IOhannes m zmoelnig <zmo...@ie...>
> *Cc:* tcl...@li... <tcl...@li...>
> *Subject:* Re: [TCLCORE] expose content of macOS' Info.plist
>
> I ask about tdom because I myself don’t have time to implement a built-in
> solution.
>
> On Jun 3, 2025, at 9:20 AM, Kevin Walzer <kw...@co...> wrote:
>
> 
> A property list is just XML. Are you not able to use a Tcl library like
> tdom to parse it?
>
> > On Jun 3, 2025, at 8:36 AM, IOhannes m zmoelnig wrote:
> >
> > hi.
> >
> > thanks for your answer, however:
> >
> >> On 6/3/25 14:22, Kevin Walzer wrote:
> >> The usual solution is to manually edit Info.plist before deployment.
> It’s not really intended for modification at runtime.
> >
> > this is not at all what i have been asking for.
> >
> > what i want is a (read-only) view of the Info.plist within Tcl, so I can
> use that information - rather than having to duplicate the same data in
> Info.plist and my Tcl scripts.
> >
> > as I tried to explain: manually *reading* the Info.plist (via `exec
> defaults read .../Info`) works but is so slow that we practically cannot
> deploy it for a real application.
> >
> > otoh, Tk already does read this information (see [1]) via macOS native
> ways (which I think is zillions time faster).
> > however
> > - it only reads a few select keys (e.g. "CFBundleName")
> > and more importantly:
> > - it only uses the read keys internally, but does not make them
> available for Tcl scripts.
> >
> >
> > mgfadsr
> > IOhannes
> >
> >
> > PS: please CC me in any replies, as i'm not subscribed to this
> mailinglist.
> >
> >
> >
> > [1]
> >
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> [lists.sourceforge.net]
> <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!EKtX6hP8ah-qjpohdCMXTJlsmBhg_F_zQmx1LkUwMweWmrxs1woHrRoR1QOhuGZKwy_OhlSnd4DsgrjtVbCNhAyCAkA$>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] expose content of macOS' Info.plist

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

I see no reason why there shouldn't be a small macOS-specific extension (along the lines of the Windows-specific dde and registry extensions) distributed with either Tcl or Tk (I'm not sure which would be the better home, but maybe Tk as that's already set up for working with ObjC and that's much easier to use for the native APIs from what I see), as long as it's doing read-only access to the bundle data.

Read-write access would be something else entirely, and have a lot more complex questions involved (such as around Apple's security policies).

Donal.

________________________________
From: Kevin Walzer <kw...@co...>
Sent: Tuesday, June 03, 2025 15:05
To: IOhannes m zmoelnig <zmo...@ie...>
Cc: tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] expose content of macOS' Info.plist


I ask about tdom because I myself don’t have time to implement a built-in solution.

On Jun 3, 2025, at 9:20 AM, Kevin Walzer <kw...@co...> wrote:



A property list is just XML. Are you not able to use a Tcl library like tdom to parse it?

> On Jun 3, 2025, at 8:36 AM, IOhannes m zmoelnig wrote:
>
> hi.
>
> thanks for your answer, however:
>
>> On 6/3/25 14:22, Kevin Walzer wrote:
>> The usual solution is to manually edit Info.plist before deployment. It’s not really intended for modification at runtime.
>
> this is not at all what i have been asking for.
>
> what i want is a (read-only) view of the Info.plist within Tcl, so I can use that information - rather than having to duplicate the same data in Info.plist and my Tcl scripts.
>
> as I tried to explain: manually *reading* the Info.plist (via `exec defaults read .../Info`) works but is so slow that we practically cannot deploy it for a real application.
>
> otoh, Tk already does read this information (see [1]) via macOS native ways (which I think is zillions time faster).
> however
> - it only reads a few select keys (e.g. "CFBundleName")
> and more importantly:
> - it only uses the read keys internally, but does not make them available for Tcl scripts.
>
>
> mgfadsr
> IOhannes
>
>
> PS: please CC me in any replies, as i'm not subscribed to this mailinglist.
>
>
>
> [1]
>
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!EKtX6hP8ah-qjpohdCMXTJlsmBhg_F_zQmx1LkUwMweWmrxs1woHrRoR1QOhuGZKwy_OhlSnd4DsgrjtVbCNhAyCAkA$>

Re: [TCLCORE] expose content of macOS' Info.plist

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

I ask about tdom because I myself don’t have time to implement a built-in solution. 

> On Jun 3, 2025, at 9:20 AM, Kevin Walzer <kw...@co...> wrote:
> 
> 
> 
> A property list is just XML. Are you not able to use a Tcl library like tdom to parse it?
> 
> > On Jun 3, 2025, at 8:36 AM, IOhannes m zmoelnig wrote:
> >
> > hi.
> >
> > thanks for your answer, however:
> >
> >> On 6/3/25 14:22, Kevin Walzer wrote:
> >> The usual solution is to manually edit Info.plist before deployment. It’s not really intended for modification at runtime.
> >
> > this is not at all what i have been asking for.
> >
> > what i want is a (read-only) view of the Info.plist within Tcl, so I can use that information - rather than having to duplicate the same data in Info.plist and my Tcl scripts.
> >
> > as I tried to explain: manually *reading* the Info.plist (via `exec defaults read .../Info`) works but is so slow that we practically cannot deploy it for a real application.
> >
> > otoh, Tk already does read this information (see [1]) via macOS native ways (which I think is zillions time faster).
> > however
> > - it only reads a few select keys (e.g. "CFBundleName")
> > and more importantly:
> > - it only uses the read keys internally, but does not make them available for Tcl scripts.
> >
> >
> > mgfadsr
> > IOhannes
> >
> >
> > PS: please CC me in any replies, as i'm not subscribed to this mailinglist.
> >
> >
> >
> > [1]
> >
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] expose content of macOS' Info.plist

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

<div><img width="1" height="1" src="https://fedbdhd.r.tsp1-brevo.net/tr/op/4zA7yZaAuMzK1CfZxm53ldtOHWBlQPYS0l-RWX-lxsIRT0oo9o3zhPuOqd3tw94vxYRfA3gZMj-Dl_ymZZlm2emLQF5oLVXSdu9GIgC6syJFkhuhpsappbxXts0JOEIYD3ZLn_KmlzJ-L0d8U1Q9YJRLgQFBwHHJsKxv8Cl5ZbCm_0klodGzGeD34GiG8yhe8aFosr3PoLUHrwytkRZGD1fJGhYi" style="mso-hide:all"/></div>A property list is just XML. Are you not able to use a Tcl library like tdom to parse it? <br/><br/>> On Jun 3, 2025, at 8:36 AM, IOhannes m zmoelnig <zmo...@ie...> wrote:<br/>> <br/>> hi.<br/>> <br/>> thanks for your answer, however:<br/>> <br/>>> On 6/3/25 14:22, Kevin Walzer wrote:<br/>>> The usual solution is to manually edit Info.plist before deployment. It’s not really intended for modification at runtime.<br/>> <br/>> this is not at all what i have been asking for.<br/>> <br/>> what i want is a (read-only) view of the Info.plist within Tcl, so I can use that information - rather than having to duplicate the same data in Info.plist and my Tcl scripts.<br/>> <br/>> as I tried to explain: manually *reading* the Info.plist (via `exec defaults read .../Info`) works but is so slow that we practically cannot deploy it for a real application.<br/>> <br/>> otoh, Tk already does read this information (see [1]) via macOS native ways (which I think is zillions time faster).<br/>> however<br/>> - it only reads a few select keys (e.g. "CFBundleName")<br/>> and more importantly:<br/>> - it only uses the read keys internally, but does not make them available for Tcl scripts.<br/>> <br/>> <br/>> mgfadsr<br/>> IOhannes<br/>> <br/>> <br/>> PS: please CC me in any replies, as i'm not subscribed to this mailinglist.<br/>> <br/>> <br/>> <br/>> [1] <https://core.tcl-lang.org/tk/file?ci=tip&name=macosx/tkMacOSXMenus.c&ln=32-33><br/>> <OpenPGP_signature.asc><br/>

Re: [TCLCORE] expose content of macOS' Info.plist

[IOhannes m z. <zmo...@ie...>]

hi.

thanks for your answer, however:

On 6/3/25 14:22, Kevin Walzer wrote:
> The usual solution is to manually edit Info.plist before deployment. 
> It’s not really intended for modification at runtime.

this is not at all what i have been asking for.

what i want is a (read-only) view of the Info.plist within Tcl, so I can 
use that information - rather than having to duplicate the same data in 
Info.plist and my Tcl scripts.

as I tried to explain: manually *reading* the Info.plist (via `exec 
defaults read .../Info`) works but is so slow that we practically cannot 
deploy it for a real application.

otoh, Tk already does read this information (see [1]) via macOS native 
ways (which I think is zillions time faster).
however
- it only reads a few select keys (e.g. "CFBundleName")
and more importantly:
- it only uses the read keys internally, but does not make them 
available for Tcl scripts.


mgfadsr
IOhannes


PS: please CC me in any replies, as i'm not subscribed to this mailinglist.



[1] 
<https://core.tcl-lang.org/tk/file?ci=tip&name=macosx/tkMacOSXMenus.c&ln=32-33>

Re: [TCLCORE] expose content of macOS' Info.plist

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

<div><img width="1" height="1" src="https://fedbdhd.r.tsp1-brevo.net/tr/op/CptJIxViEcN3unEtubkdy4fKyiDcUXVz7kmPtrDtpsUYgr7ih8OJRPNkxbCGDcF4a-BSCibYgCK8Tq0CqHOYzqnDZ8m-agAidrGWdmg_mEolP59bZBr3glzRKbGrTGFd0slDj5L7NPl3vV7SLcGs5hiCN-Pd-Rvl9qJFr8tb6SccL7rW9QVy0beyJcERNxob24XfkqnGoduKZhXQ1FotZlfF0njU" style="mso-hide:all"/></div>The usual solution is to manually edit Info.plist before deployment. It’s not really intended for modification at runtime. <br/><br/>> On Jun 3, 2025, at 4:31 AM, IOhannes m zmoelnig via Tcl-Core <tcl...@li...> wrote:<br/>> <br/>> (please CC me, as i'm not subscribed to this mailinglist)<br/>> <br/>> <br/>> i recently asked a question on stackoverflow[1], and donal kindly suggested to bring it to the tcl-core ml (if there's a more appropriate ml, please do not hesitate to tell me)<br/>> <br/>> TL;DR: it would be great if there was some way to expose the contents of the embedded Info.plist of a Tcl/Tk application on the Tcl side. an obvious candidate is `::tk::mac`<br/>> <br/>> <br/>> context: we are building a cross-platform application based on Tcl/Tk (that is: Wish). on macOS we ship an app-bundle.<br/>> Some people build applications on top of ours, and it would be great if they only need to do minimally invasive changes to create an all-new app.<br/>> <br/>> one of the (seemingly trivial) problems we have identified is the application *name*, as displayed by the OS, but also within some dialogs.<br/>> <br/>> on macOS, a lot of meta-information about an application is embedded in `Content/Info.plist` of the app bundle.<br/>> the `CFBundleName` and `CFBundleDisplayName` keys of the info.plist is automatically used by macOS for displaying the application's title.<br/>> <br/>> now i would like to access this dictionary from within my Tcl/Tk code, so I can use those values in my custom dialogs and menus and whatnot.<br/>> (and in order to build a downstream app, I only need to change the Info.plist and the rest happens automatically).<br/>> <br/>> we tried reading the Info.plist with macOS's `defaults` tool (which is able to read both binary and XML plist files), but this turned out to be *absymally* slow (we did this at application startup, and people complained verbosely about a 3-5 times longer startup)<br/>> afair, the reason for the slow startup is that macOS gatekeeper needs to check whether they are actually allowed to access this file - after all, `defaults read` just reads some random application's Info.plist which might be a security problem or i dunno...)<br/>> anyhow, I think that this would not be a problem when accessing the info on the ObjectiveC side (`[NSBundle mainBundle]`)<br/>> <br/>> so I would like to suggest to expose the information stored in `Info.plist` to my Tcl/Tk scripts.<br/>> I don't really care how (dicts, arrays, getter procs)<br/>> <br/>> <br/>> (sidenote: i can already access the `CFBundleIdentifier` via an env-var "__CFBundleIdentifier"; afaict this is something that macOS does on its own; it also appears to be the only value from Info.plist that is exposed like this)<br/>> <br/>> <br/>> thanks for considering.<br/>> <br/>> gfmad<br/>> IOhannes<br/>> <br/>> PS: please CC me in any replies, as i'm not subscribed to this mailinglist.<br/>> <br/>> <br/>> [1] https://stackoverflow.com/questions/79628543/<br/>> _______________________________________________<br/>> Tcl-Core mailing list<br/>> Tcl...@li...<br/>> https://lists.sourceforge.net/lists/listinfo/tcl-core<br/>> <OpenPGP_signature.asc><br/>

Re: [TCLCORE] CFV: TIP #712: Add "positive" options to the subst command

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

TIP #712: Yes

Yahoo Mail: Search, organise, conquer 
 
  On Tue, 3 Jun 2025 at 11:55 am, Harald Oehlmann<har...@el...> wrote:   Am 02.06.2025 um 18:28 schrieb Reinhard Max:
> This is a Call For Votes for TIP 712:
> Add "positive" options to the subst command
> 
> Please send your votes until Jun 15, 12:00 UTC
> [clock format 1749988800].

My vote: yes
Harald
  

Re: [TCLCORE] CFV: TIP #712: Add "positive" options to the subst command

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

Am 02.06.2025 um 18:28 schrieb Reinhard Max:
> This is a Call For Votes for TIP 712:
> Add "positive" options to the subst command
> 
> Please send your votes until Jun 15, 12:00 UTC
> [clock format 1749988800].

My vote: yes
Harald

Re: [TCLCORE] CFV: TIP #712: Add "positive" options to the subst command

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

Tip #712: Yes

-Brian
(from mobile device)

> On Jun 2, 2025, at 09:49, Reinhard Max <rei...@m4...> wrote:
> 
> This is a Call For Votes for TIP 712:
> Add "positive" options to the subst command
> 
> Please send your votes until Jun 15, 12:00 UTC
> [clock format 1749988800].
> 
> My vote:
> TIP #712:   YES
> 
> cu
> Reinhard
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 

[TCLCORE] Fw: Re: tk-print-fixes branch ready for review

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

Sorry, sent this mail to Francois instead of tcl-core. Resending

On Sat, 31 May 2025 21:59:22 +0200
Francois Vogel <fvo...@fr...> wrote:

> Hi Emiliano,
> 
> I had a look at the diff between tk_print_fixes and trunk. This is pure code review, I didn't try running the branch. Here are a few observations:

Many thanks for taking the time !!

> - On Windows, printing a text widget now always uses {{Courier New} 11} as font. The font used before your fixes was {Arial 12}, this makes a difference I think. I believe this is what you mention in the first bullet below. Question: why not using the -font of the text widget? The printed output could then be closer from what the user sees on screen (despite tagged text could still render differently, yes).

The intent here is cross platform consistency. On free unices, Openprinting's cups + cups-filters uses a monospaced font for printing plain text, and only a few parameters can be configured: chars per inch, lines per inch and margins. You can't select the font face. I don't know about macos (the only supported system I don't have access to) but I guess its filters are no different in this regard. I choose Courier New as it is a widely available monospaced font on Windows platforms.

> - There is a debug puts remaining in print.tcl line 241.

Yes. That file is subject to further cleanup, and the same can be said about win/tkWinGDI.c. More on this below.

> - In print.tcl, proc _print_widget only supports canvas widgets. Therefore you have added an early exit is the widget received is not a canvas. So why testing on the widget class line 387 and provide an else clause lines 397-400? This is dead code. In contrast, you have properly removed the switch on [winfo class $wid] a few lines after.

Another candidate for cleanup. My guess is that existing code is based on a work which was meant to print more than just canvas or text widgets. That's why _print_widget is called when _print_canvas should have been called directly from the ::tk::print command at the bottom of the file. I think the best option is to move the relevant [_gdi map] code to [_print_canvas] and delete [_print_widget] altoghether.

> - print.tcl, proc _print_canvas.text: couldn't we remove the commented checks on "white"? I understand the intent but since this is commented out, let's replace this by a comment saying "<TODO>: We might have a problem if $color is white".

This code was already there and I've not yet reviewed it. And since the final goal is to get output across platforms as similar as possible, I think Windows should do the same as unix (whatever this be). Again, not yet reviewed, just left as is.

> - print.tcl, proc _print_canvas.bitmap: you have added a return statement as the first instruction, explaining that bitmaps are not supported. However there is (lots of) code after this 'return'. Didn't this work before your changes? Moreover, there seems to be attempts at making it work (you made changes there), what is the status?

Bitmaps are not supported. They never were. Whether they are bitmap canvas items or image canvas items with bitmap image type. Only image canvas items with images of type photo are supported on canvas. See the code here: https://core.tcl-lang.org/tk/file?ci=trunk&name=win/tkWinGDI.c&ln=302-348

> - tkWinGDI.c:248 : what makes it necessary to have font size in points for text widget but in pixels for canvas?

Coordinate transformation. Canvas printing transforms the page coordinate system so it maps to the printable area of the page here: https://core.tcl-lang.org/tk/file?ci=trunk&name=library/print.tcl&ln=312 . In order to scale the text along with all other canvas items the size needs to be in pixels, not points. On the other hand, text printing doesn't perform any coordinate transformation, so it uses points for font size. The code that selects the font based on the sign of the size is this https://core.tcl-lang.org/tk/file?ci=trunk&name=win/tkWinGDI.c&ln=2530 .

> - tkWinGDI.c:1747-1781 : Copying the structs from tkFont.c is not very robust to changes there. Code duplication is rarely good. For instance there is zero chances that changes in the structs in tkFont.c get propagated in tkWinGDI.c. I would be strongly in favour of including and upgraded tkFont.h instead. Can we do this or not in a minor or patch release ? I think so but am not 100% sure.

Fully agree that this is *bad*, and the right thing to do is to move those to a header that can be used by other code inside Tk. I think this is doable since nothing private is being made public, just making it available to other source files inside Tk itself. Or maybe anyone knows an alternative way to access the line breaking decisions Tk_ComputeTextLayout made?

> - General question: do you think it would be possible to have tests in the test suite for the printing features? I don't think there are any at this stage.

Ahh, tests !! Last but not least, I also think about how these features can be tested with automated tests, but right now I can't really offer any clever idea. Or, better said, I can't offer any idea at all. We depend heavily on the host system, which can have no printer attached. So far, the only "tests" performed (at least by me) was printing to a virtual PDF printer both on windows native and linux with wine (using the Generic-CUPS-PDF-Printer printer) and compare visually with the expected output. Not scalable, nor automated.

> Overall, your work look like a real big progress. It's too big a change for me to test in details though, but given your long record of very high quality work I have no doubts it can be merged without any worries. That said, automatic tests would be a big win IMO.
> 
> Just one last point about style perhaps: continuation lines are supposed to be indented 8 spaces in C code (see TIP #247), you seem to be using 4 spaces (mostly - it's not always consistent). Also I thought it should be the same for Tcl code.

Sorry, I was not paying attention to the style, and wasn't aware of TIP #247. Time to cleanup!!

Thanks again for the review.

-- 
Emiliano <emi...@gm...>

[TCLCORE] CFV: TIP #712: Add "positive" options to the subst command

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

This is a Call For Votes for TIP 712:
Add "positive" options to the subst command

Please send your votes until Jun 15, 12:00 UTC
[clock format 1749988800].

My vote:
TIP #712:   YES

cu
Reinhard

[TCLCORE] TIP #716 accepted

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

Vote-Summary: Accepted 6/0/0

Votes-For: AN, HO, JN, KW, MC, SL

Votes-Against: none

Votes-Present:

 

TIP #716 accepted.

 

Thanks all,

 

/Ashok

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Monday, May 26, 2025 11:33 PM
To: tcl...@li...
Subject: [TCLCORE] CFV: TIP #716

 

This is a Call For Votes for TIP 716: New command "encoding user", remove
UTF-8 manifest setting on Windows

 

TIP - https://core.tcl-lang.org/tips/doc/trunk/tip/716.md

Branch - tip-716

 

Note the TIP targets 9.0.2 because I think it is important to have it
released while 9.0 is still relatively young. As the TIP mentions, the
changes to the stubs table will however only target 9.1 for stubs
compatibility reasons.

 

Special thanks to Jan for his thorough critique and fixes.

 

Since there has been plenty of discussion already, voting period is limited
to one week. Voting ends Monday, June 2, 12PM UTC.

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

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

Dear Tcl/Tk team,
thanks for your participation at the telco today.
Here is the report:

1) Release items for TCL/Tk 9.0.2
- Wait for TIP 716 -> Is just committed
- Some activity soon

2) Release items for Tcl/Tk 9.1.0a0
- Internal list representation change
   Check if TIP 445 used, as it is the tool for better usage.
- Some crashes on the main branch. Not discovered by the Github action, 
as SQLite and Thread package not available.
   This was disappointing, as main branch is not supposed to crash.
   As we now have review by 4 eyes on main, this should not happen.
   Ready branches are waiting for review and nothing moves.
   The situation is felt as disappointing.
   All issues arised with TIP 720 (Bytecode update).
   Open Tickets about memory leaks are waiting for Donal.
   -> It would be sad to put it in a branch for first bug-fixing, as 
other commits happened. It is seen as great work.

3) TIP 723: monotonic clock: is it a bug? Platform solutions

The Linux part changes the event part which feels unrelated.
after is used for two applications:
- time interval
- time point

A new command is seen as the better way to be backward compatible.
Nevertheless, it is seen as a bug and the "time point usage" is seen as 
a necessary usage, as there is currently no alternative.

The solution would be to have a new timer command with both possibilities:
timer at ...
timer after ...
timer periodic ...

-> not for tcl 9.1.0a0...

4) TIP 712: positive options to the subst command
Ready for vote, do it Reinhard !

5) Reinhards new socket stuff
Schelte looks for HTTP3 / Quick protocol and found it easier to directly 
implement it. The openssl library has anything included.

6) tk print enhancements
Great stuff!
It is bugfix, may go in at any time when ready.

7) text widget glyph line break using ICU or not? 
https://core.tcl-lang.org/tk/info/5d0bc3cfec7c1adb
ICU is used for cursor movement. The text widget may use that.
ICU is seen as the way to go.

8) TIP 720: TCL compiler reform
Discussed above

9) Documentation

Will attempt to make it easier for others to get involved in the next 
few weeks.
This will include moving code from the chisel app repository to a branch 
in the main repo plus moving more onto the wiki.

-> not for TCL 9.1.0a0

10) Orphan packages repository

Many requests, few people doing the work.

11) Conference status

US university people can not travel, which are a big part of the OpenACS 
community. Thus, the conference will mainly be Tcl/Tk.
Payment for the conference fee is possible via the Vienna University or 
directly to the sponsor "Knowledge Market". Use the E-Mail 
"con...@op..." to request an invoice.

Other meetings:
10th of June 10:00 UTC: monthly meetup
16th of June 12:00 UTC: UTC Monthly Virtual Meetup on same jitsi

Thanks for all,
Harald

Re: [TCLCORE] CFV: TIP #716

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

On 2025-05-31 23:22, Jan Mercl wrote:

> There's no good reason for Tcl 9 to support anything other than UTF-8.
> Supporting legacy encodings forever only complicates everything while
> removing the support creates useful motivation, for those who want to
> use Tcl 9, to update their code and/or dependencies.


Tcl 9 has to support iso8859-1 for sure.  "binary" files will always be
a thing. Tcl is going to continue to support all the encodings it has
always supported, regardless of TIP 716.

-- 
Yorick

Re: [TCLCORE] CFV: TIP #716

[Jan M. <0x...@gm...>]

On Sat, May 31, 2025 at 10:10 PM Poor Yorick
<org...@po...> wrote:

> Calling it "reverting to 8.6 behavior" is a shady attempt to market it
> as something undesirable.  Restoring the intended meaning of [system
> encoding] wouldn't be some regression from 8.6. into 9.x.  In this case
>   it is 9.0 that is buggy, not 8.6.

I have no voting rights, please feel free to ignore my opinions below.

The encoding wars, that's not about this ML, are long over. UTF-8 won.
Tcl 8 supports legacy encodings and anyone who needs to run legacy
code can still use Tcl 8 with no changes in behavior.

There's no good reason for Tcl 9 to support anything other than UTF-8.
Supporting legacy encodings forever only complicates everything while
removing the support creates useful motivation, for those who want to
use Tcl 9, to update their code and/or dependencies.

-j

Re: [TCLCORE] CFV: TIP #716

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

Calling it "reverting to 8.6 behavior" is a shady attempt to market it
as something undesirable.  Restoring the intended meaning of [system
encoding] wouldn't be some regression from 8.6. into 9.x.  In this case
  it is 9.0 that is buggy, not 8.6.

-- 
Yorick

On 2025-05-31 19:43, apnmbx-public--- via Tcl-Core wrote:
> And a footnote for posterity...
> 
> I am mostly in agreement with what you said below. The difference I 
> think is
> you wanted to revert 9.0.x to 8.6 semantics and I was not willing to 
> make
> 9.0.2's [encoding system] break compatibility with 9.0.0|1. When I 
> brought
> this up on the core late last year, absolutely no one was is favour of 
> going
> back from utf-8 as the default encoding on new Windows platforms.
> 
> C'est la vie. We move on
> 
> /Ashok
> 
> -----Original Message-----
> From: Poor Yorick <org...@po...>
> 
> A statement to clarify things for posterity:  [encoding system]
> traditionally meant "the encoding of the system hosting the Tcl
> interpreter process".  At some point in the last year or so, the 
> meaning
> shifted to "the encoding of the Tcl system".  Then it was discovered
> that the original functionality was still needed, so TIP 716 introduces
> [encoding user] to mean what [encoding system] used to mean.
> 
> [editorial on the wisdom of all this elided]
> 
> --
> Yorick
> 
> 
> 
> _______________________________________________
> 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] tk-print-fixes branch ready for review

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

Hi Emiliano,

I had a look at the diff between tk_print_fixes and trunk. This is pure 
code review, I didn't try running the branch. Here are a few observations:

- On Windows, printing a text widget now always uses {{Courier New} 11} 
as font. The font used before your fixes was {Arial 12}, this makes a 
difference I think. I believe this is what you mention in the first 
bullet below. Question: why not using the -font of the text widget? The 
printed output could then be closer from what the user sees on screen 
(despite tagged text could still render differently, yes).

- There is a debug puts remaining in print.tcl line 241.

- In print.tcl, proc _print_widget only supports canvas widgets. 
Therefore you have added an early exit is the widget received is not a 
canvas. So why testing on the widget class line 387 and provide an else 
clause lines 397-400? This is dead code. In contrast, you have properly 
removed the switch on [winfo class $wid] a few lines after.

- print.tcl, proc _print_canvas.text: couldn't we remove the commented 
checks on "white"? I understand the intent but since this is commented 
out, let's replace this by a comment saying "<TODO>: We might have a 
problem if $color is white".

- print.tcl, proc _print_canvas.bitmap: you have added a return 
statement as the first instruction, explaining that bitmaps are not 
supported. However there is (lots of) code after this 'return'. Didn't 
this work before your changes? Moreover, there seems to be attempts at 
making it work (you made changes there), what is the status?

- tkWinGDI.c:248 : what makes it necessary to have font size in points 
for text widget but in pixels for canvas?

- tkWinGDI.c:1747-1781 : Copying the structs from tkFont.c is not very 
robust to changes there. Code duplication is rarely good. For instance 
there is zero chances that changes in the structs in tkFont.c get 
propagated in tkWinGDI.c. I would be strongly in favour of including and 
upgraded tkFont.h instead. Can we do this or not in a minor or patch 
release ? I think so but am not 100% sure.

- General question: do you think it would be possible to have tests in 
the test suite for the printing features? I don't think there are any at 
this stage.

Overall, your work look like a real big progress. It's too big a change 
for me to test in details though, but given your long record of very 
high quality work I have no doubts it can be merged without any worries. 
That said, automatic tests would be a big win IMO.

Just one last point about style perhaps: continuation lines are supposed 
to be indented 8 spaces in C code (see TIP #247), you seem to be using 4 
spaces (mostly - it's not always consistent). Also I thought it should 
be the same for Tcl code.

Many thanks for this very very valuable contribution!

Regards,

Francois

Le 26/05/2025 à 17:26, Emiliano G a écrit :
> As some of you might already know, I was working in the tk-print-fixes
> branch trying to fix some issues I've found while converting a custom
> printing solution (involving ghostscript on windows) to the new 9.0
> feature. As I kept finding issues, and reporting them (see the list at
> https://core.tcl-lang.org/tk/ticket?s=tk+print ), soon this workflow
> proved to be cumbersome, so this was the motivation for this branch.
> It has reached a point where I'm satisfied with the current state.
>
> The changed files are win/tkWinGDI.c and generic/print.tcl , and it
> addresses specifically windows printing, both in [text] and [canvas]
> widget printing. Nothing was modified from the user POV, besides
> output. The only documented API is still [tk print $widget], and the
> rest are implementation details.
>
> A short, non-comprehensive list of changes, divided in two categories:
>
> User visible changes:
> * Plain text printing for non-latin characters. This is the main
> visible change for the [text] widget printing, along with the change
> of default font, now being monospaced (Courier New), which makes it
> consistent with *nix printing.
> * Rotated text on canvas now works (with a caveat, see code changes).
> * Correct joinstyle and capstyle for lines.
> * Correct capstyle for arcs (arc style). While not configurable, it
> uses (fixed) butt style.
> * Correct joinstyle for polygon, rectangle and arcs (pieslice and
> chord style); while only polygon accepts a -joinstyle option,
> rectangles use (fixed) miter and arcs use bevel.
> * Correct arrows on lines.
> * Smooth lines support complete, both bezier and raw.
> * Correct management of -outline and -fill color specification. If
> it's specified as {}, it means "don't draw this element".
> * Don't draw items with "hidden" state (consistency with *nix printing).
>
> Code changes (non visible to users):
> * Fixed memory leaks (ckalloc without ckfree).
> * Protect internal commands from being called with a NULL device context.
> * Rewrite most parsing stages to use Tcl_ParseArgsObjv(). The parsing
> style of item options was both inconsistent (strcmp, strncmp, check of
> correct number of args, etc) and repetitive (same code replicated
> everywhere). IMO this improves maintainability in the long run. Yes,
> I'm being opinionated here :-)
> * Plain text printing (text widget) now uses a different, simpler code
> path than canvas text items. This should be faster for long documents.
> * Moved global state to an interp specific state. Code is now multi-interp safe.
> * Rotated text on canvas uses Tk_ComputeTextLayout() to get the same
> line breaks as the canvas text item with the -width option different
> from zero. I had to copy the relevant struct definitions from
> generic/tkFont.c in order to access its fields. If those definitions
> are moved to generic/tkFont.h , they can be removed and replaced with
> an #include.
>
> There's still an issue I want to fix: dashes are not implemented
> (yet). Other missing features, like stipples, bitmaps or embedded
> windows are not on my TODO list. Further work involves matching
> expected output of canvas printing between different platforms. Right
> now there's a difference between Windows and *nix (not MacOS) output.
>
> Please review and test. Thank you all.
>
> Regards
>
> Emiliano
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV: TIP #716

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

And a footnote for posterity...

I am mostly in agreement with what you said below. The difference I think is
you wanted to revert 9.0.x to 8.6 semantics and I was not willing to make
9.0.2's [encoding system] break compatibility with 9.0.0|1. When I brought
this up on the core late last year, absolutely no one was is favour of going
back from utf-8 as the default encoding on new Windows platforms.

C'est la vie. We move on

/Ashok

-----Original Message-----
From: Poor Yorick <org...@po...> 

A statement to clarify things for posterity:  [encoding system]
traditionally meant "the encoding of the system hosting the Tcl
interpreter process".  At some point in the last year or so, the meaning
shifted to "the encoding of the Tcl system".  Then it was discovered
that the original functionality was still needed, so TIP 716 introduces
[encoding user] to mean what [encoding system] used to mean.

[editorial on the wisdom of all this elided]

-- 
Yorick



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

Re: [TCLCORE] CFV: TIP #716

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

On 2025-05-28 23:14, Poor Yorick wrote:
> On 2025-05-28 14:22, apnmbx-public--- via Tcl-Core wrote:
>> Nathan,
>> 
>>> The addition of [encoding user] leaks platform-specific details 
>>> (Windows in this case) into a layer that is supposed to abstract such 
>>> details away.
>> 
>> Au contraire, it abstracts the concept of "default encoding used by 
>> Tcl" (as returned by [encoding system]) from the user's encoding 
>> preference (returned by [encoding user]). This applies equally well to 
>> Unix and other platforms, not just Windows. In Tcl 9.1 for instance, 
>> [encoding system] may return utf-8 on all platforms (*if* we decide to 
>> force utf-8 default). [encoding user] will return the user setting, 
>> based on the registry in Windows, LANG on Unix or whatever platform 
>> specific means it is determined. The two are distinct, applications 
>> (whether at script or C level) may be interested in either, and just 
>> reusing the existing command/function not only raises compatibility 
>> issues, it also loses functionality.
>> 
>> Be as it may, my last post on this.
> 
> I maintain that this take represents a misunderstanding of the purpose
> and use of [encoding system] across platforms.  [encoding system] was
> never about the "Tcl" system, but about the environment Tcl finds 
> itself
> in.  The fact that it *can* be used to force utf-8 as the default
> everywhere does not mean that it was ever a good idea to use it for 
> that
> purpose.  It doesn't matter what combination of user and default
> configuration settings lead to the current actual platform encoding.
> All that matters is that a Tcl script may need to know what that
> platform encoding is.  [encoding system] would remain sufficient for
> this purpose if it wasn't being hijacked for "clever" tricks.

A statement to clarify things for posterity:  [encoding system]
traditionally meant "the encoding of the system hosting the Tcl
interpreter process".  At some point in the last year or so, the meaning
shifted to "the encoding of the Tcl system".  Then it was discovered
that the original functionality was still needed, so TIP 716 introduces
[encoding user] to mean what [encoding system] used to mean.

[editorial on the wisdom of all this elided]

-- 
Yorick

Re: [TCLCORE] CFV: TIP #716

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

TIP #716: YES

-- Steve
On 27 May 2025 at 2:04 AM +0800, apnmbx-public--- via Tcl-Core <tcl...@li...>, wrote:
> This is a Call For Votes for TIP 716: New command ”encoding user”, remove UTF-8 manifest setting on Windows
>
> TIP - https://core.tcl-lang.org/tips/doc/trunk/tip/716.md
> Branch – tip-716
>
> Note the TIP targets 9.0.2 because I think it is important to have it released while 9.0 is still relatively young. As the TIP mentions, the changes to the stubs table will however only target 9.1 for stubs compatibility reasons.
>
> Special thanks to Jan for his thorough critique and fixes.
>
> Since there has been plenty of discussion already, voting period is limited to one week. Voting ends Monday, June 2, 12PM UTC.
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV: TIP #716

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

On 2025-05-28 14:22, apnmbx-public--- via Tcl-Core wrote:
> Nathan,
> 
>> The addition of [encoding user] leaks platform-specific details 
>> (Windows in this case) into a layer that is supposed to abstract such 
>> details away.
> 
> Au contraire, it abstracts the concept of "default encoding used by 
> Tcl" (as returned by [encoding system]) from the user's encoding 
> preference (returned by [encoding user]). This applies equally well to 
> Unix and other platforms, not just Windows. In Tcl 9.1 for instance, 
> [encoding system] may return utf-8 on all platforms (*if* we decide to 
> force utf-8 default). [encoding user] will return the user setting, 
> based on the registry in Windows, LANG on Unix or whatever platform 
> specific means it is determined. The two are distinct, applications 
> (whether at script or C level) may be interested in either, and just 
> reusing the existing command/function not only raises compatibility 
> issues, it also loses functionality.
> 
> Be as it may, my last post on this.

I maintain that this take represents a misunderstanding of the purpose
and use of [encoding system] across platforms.  [encoding system] was
never about the "Tcl" system, but about the environment Tcl finds itself
in.  The fact that it *can* be used to force utf-8 as the default
everywhere does not mean that it was ever a good idea to use it for that
purpose.  It doesn't matter what combination of user and default
configuration settings lead to the current actual platform encoding.
All that matters is that a Tcl script may need to know what that
platform encoding is.  [encoding system] would remain sufficient for
this purpose if it wasn't being hijacked for "clever" tricks.

-- 
Yorick

Re: [TCLCORE] CFV: TIP #716

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

Nathan,

> The addition of [encoding user] leaks platform-specific details (Windows in this case) into a layer that is supposed to abstract such details away.

Au contraire, it abstracts the concept of "default encoding used by Tcl" (as returned by [encoding system]) from the user's encoding preference (returned by [encoding user]). This applies equally well to Unix and other platforms, not just Windows. In Tcl 9.1 for instance, [encoding system] may return utf-8 on all platforms (*if* we decide to force utf-8 default). [encoding user] will return the user setting, based on the registry in Windows, LANG on Unix or whatever platform specific means it is determined. The two are distinct, applications (whether at script or C level) may be interested in either, and just reusing the existing command/function not only raises compatibility issues, it also loses functionality.

Be as it may, my last post on this. 

-----Original Message-----
From: Poor Yorick <org...@po...> 
Sent: Tuesday, May 27, 2025 8:12 PM
To: tcl...@li...
Cc: apn...@ya...
Subject: Re: [TCLCORE] CFV: TIP #716

On 2025-05-27 16:35, apnmbx-public--- via Tcl-Core wrote:
> Nathan,
> 
> You're coming fashionably late to a party that has been going on for 
> months and guests are already leaving 😊 but anyways ...

I like shouting at clouds too.

> 
> Sorry, but I have no idea what "fallout" you are talking about.
> 
> [encoding system] returns the default encoding used for channels, exec 
> etc.
> 
> [encoding user] returns the encoding as configured by the user in his 
> platform-specific manner (registry on Windows). This allows correct 
> setting of channels that communicate with programs that use the user's 
> settings (e.g. findstr, icacls etc command line programs that come with 
> Windows).
> 
> The two may or may not be the same.
> 
> The C API parallels the above.
> 
> What is the fallout that users will have to suffer forever?

The addition of [encoding user] leaks platform-specific details (Windows 
in
this case) into a layer that is supposed to abstract such details away.
*nix programmers aren't going to be familiar with the situation, and are 
going
to have to figure out why there is both an [encoding system] and an 
[encoding
user], only to come to the conclusion that on their own platform there's 
no
sensible difference, and [encoding system] now obsolete, but then 
[encoding
user] may or may not be obsolete since it was just added, and who really 
knows
anymore, and even at the C level there's now 
Tcl_GetEncodingNameForUser() and
so we should probably just use Tcl_GetEncodingNameForUser() now and 
never use
Tcl_GetEncodingNameFromEnvironment(), but then why didn't the core team 
just
fix Tcl_GetEncodingNameFromEnvironment() instead of adding a new 
function while
making the old function completely useless?

What we're seeing here is the suboptimal results of design by committee. 
  I
think the vote on TIP 816 should be called off to avoid creating yet 
another
mess.


-- 
Yorick

Re: [TCLCORE] TIP 723: monotomic clock for after, independent of TIP 233 (Tcl_SetTimeProc/Tcl_QueryTimeProc), MS-Windows only

[Christian W. <Chr...@t-...>]

On 05/27/2025 07:58 AM, apnmbx-public--- via Tcl-Core wrote:

> Regardless of what we decide in terms of a new command or a “fix” to after, we should absolutely be consistent across platforms in what exactly we are measuring. In my opinion, that includes whether time in suspension is counted or not.
> …
> Sorry, not offering a solution but a plea for consistency.

IMO, it is sufficient to have monotonic consistency since absolute consistency would require
the absolute assurance to have uniform clock vs. nap behavior on all (even future) systems.

What are the outcomes of a timer to expire at some future (monotonic) clock value on

   * a system which naps without clock increment?
   * a system which naps but still ticks?

The difference is the time the system was in suspended state. Or a bit more graphic: in
the first case, the laptop might catch fire a certain amount of time after the lid is opened.
In the latter case it might already glow while the lid is opened.

But the common denominator is that the timer took at least the programmed number of
(monotonically increasing) time units. And that was the contract anyway since the timer
is based on a monotonic clock.

Time will tell,
Christian

Re: [TCLCORE] CFV: TIP #716

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

<div><img width="1" height="1" src="https://fedbdhd.r.bh.d.sendibt3.com/tr/op/U3P1DSR_yMkk6hi5VIYRCR89sTPuJvRW0fUBcZAJau9LCfBYG29pH4zfIfJKKR4C7GTzEtiisB1wMHrR2Llp4aZ5YLDiy8MYYFspvoPVeG-W-NtLvZF2vTmjJ67BaqtUHI2fcZRhKACoLbqzF2rvLG5mp215MmIe1vpnJoH4VMQ86IcPxLArw8Ipeka29CbgR_iCjVc9RTb3etjn3XtD1MuP9rMgLRnO" style="mso-hide:all"/></div><br/>On 5/27/25 10:41 AM, Poor Yorick wrote:<br/>> What we're seeing here is the suboptimal results of design by <br/>> committee.  I<br/>> think the vote on TIP 816 should be called off to avoid creating yet <br/>> another<br/>> mess. <br/><br/>We're voting on TIP 716, not 816.<br/><br/>