tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

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

I decided to look at the crash report produced when you run /usr/bin/wish
on macOS 15.  It turns out to add some interesting emphasis to what I was
saying earlier about the structure of frameworks.  The crash report says:

Exception Type:  EXC_CRASH (SIGKILL (Code Signature Invalid))
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: CODESIGNING 4 Launch Constraint Violation

Note that /usr/bin/wish is a shell script which calls the main executable
in Apple's Wish.app.  So this is really an issue with signing a macOS app.

Codesigning and, to a lesser extent, notarization really have become huge
considerations for macOS developers.  And Apple can't even get it right on
their own code, although I would expect them to try to blame it on Tcl.

- Marc

On Mon, Jun 16, 2025 at 9:46 AM Marc Culler <cul...@gm...> wrote:

> On Mon, Jun 16, 2025 at 5:26 AM Kevin Walzer <kw...@co...> wrote:
>
>> For better or worse, the Mac does have a large batch of platform specific
>> bits that are included in the tk::mac namespace but are core. There isn’t a
>> tk::win namespace or tk::unix. Not sure how that evolved, but it’s there.
>
>
> In particular, the command *::tk::mac::GetAppPath*
> <https://www.tcl-lang.org/man/tcl9.0/TkCmd/tk_mac.html#M18> has been part
> of the core for a long time.  I considered ::tk::mac::GetInfoAsJSON to be
> completely analogous to ::tk::mac::GetAppPath.
>
> I can only speculate about the history of ::tk::mac, but my speculation
> would be that its existence is related to the fact that Apple Inc. is
> listed as a copyright holder for most of the files in the macosx
> directory.  Of course that does not explain the lack of a ::tk::sun
> namespace, but my guess is that ::tk::mac appeared when Apple was actually
> involved with the Tcl project.
>
> What a different time that must have been!
>
> Nowadays Apple distributes a program called /usr/bin/wish with their macOS
> 15 operating system which instantly segfaults if you attempt to run it.
> They can't even be bothered to fix the segfault by removing Tcl from their
> OS, which would at least avoid all of the nightmares that can happen when
> the Tcl build system finds /System/Library/Frameworks/Tcl.framework.
>
> - Marc
>
>

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

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

On Mon, Jun 16, 2025 at 5:26 AM Kevin Walzer <kw...@co...> wrote:

> For better or worse, the Mac does have a large batch of platform specific
> bits that are included in the tk::mac namespace but are core. There isn’t a
> tk::win namespace or tk::unix. Not sure how that evolved, but it’s there.


In particular, the command *::tk::mac::GetAppPath*
<https://www.tcl-lang.org/man/tcl9.0/TkCmd/tk_mac.html#M18> has been part
of the core for a long time.  I considered ::tk::mac::GetInfoAsJSON to be
completely analogous to ::tk::mac::GetAppPath.

I can only speculate about the history of ::tk::mac, but my speculation
would be that its existence is related to the fact that Apple Inc. is
listed as a copyright holder for most of the files in the macosx
directory.  Of course that does not explain the lack of a ::tk::sun
namespace, but my guess is that ::tk::mac appeared when Apple was actually
involved with the Tcl project.

What a different time that must have been!

Nowadays Apple distributes a program called /usr/bin/wish with their macOS
15 operating system which instantly segfaults if you attempt to run it.
They can't even be bothered to fix the segfault by removing Tcl from their
OS, which would at least avoid all of the nightmares that can happen when
the Tcl build system finds /System/Library/Frameworks/Tcl.framework.

- Marc

Re: [TCLCORE] More on TEA packages for macOS

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

<div><img width="1" height="1" src="https://fedbdhd.r.af.d.sendibt2.com/tr/op/sLNRu7ZQMGhr6nitiyonRjn0wAt1e-inYA5jI3dJB1eQYlaklfv7x0wPvAOd2wnWcBhqs-gpPSdq8N3103fO8bCbABW0m941SOSl9OcDGzzVNrskPmmgJsXi4So-_gzDM_q-m5VTstF73ocob1Ak8DFJwWkztOEVftWnk3_YRn0tA5imhUOrQSVt4mww8frxFMO5JFHm7NQjxUiWLUqk4PawwZnRxCNY" style="mso-hide:all"/></div>The canonical installation location for extension packages is /Library/Tcl. They shouldn’t go in the framework although it is supported. <br/><br/>> On Jun 16, 2025, at 10:11 AM, Marc Culler <cul...@gm...> wrote:<br/>> <br/>> <br/>> My second question (which is more of a topic than a question, and is really a request for comments) is: where should Tcl and Tk extensions be installed in macOS?<br/>> <br/>> I have a proposal, and it is different from the current scheme.<br/>> <br/>> First some background ...<br/>> <br/>> There are two ways to install Tcl on macOS:<br/>> - a traditional unix "prefix" installation, usually with prefix /usr/local<br/>> - a "framework" install, usually in /Library/Frameworks<br/>> <br/>> I am talking about the "framework" install only.  Note that this is the most common way of installing Tcl and Tk on macOS, and is also how Active State used to distribute Tcl and Tk.<br/>> <br/>> It turns out that there are two critical, but non-obvious, components related to frameworks: codesigning and notarization.  It is now required on Apple Silicon that every binary, i.e. executable or shared library, be signed (although ad-hoc signatures are allowed).  If an executable is not signed it is instantly killed by Apple's gatekeeper.  Distributing non-notarized macOS apps outside of the app store is possible but presents unpleasant UX which is a barrier to usefulness.  Ad-hoc signatures are not allowed for notarized apps, and notarization is required for the app store.<br/>> <br/>> Codesigning and notarization are related to frameworks because Apple has a specification for the structure of a framework, albeit a very loose one, which is enforced primarily by threat.  The threat is that if you do not follow the spec, vague as it may be, you can expect issues with codesigning and notarization.<br/>> <br/>> Next, about TEA packages:<br/>> <br/>> Currently the standard location for a Tcl or Tk extension package is:<br/>>   /Library/Frameworks/Tcl.framework/Versions/X.Y/Resources/Scripts<br/>> or<br/>>   /Library/Frameworks/Tk.framework/Versions/X.Y/Resources/Scripts<br/>> <br/>> I don't think that is such a good choice.<br/>> <br/>> First, at the most basic level, binary packages are not scripts.  Even a pure Tcl package is more than a script.  A tcl module could be viewed as a script,<br/>> but, in my opinion, it would be better to call it what it is, a module.<br/>> <br/>> Putting shared libraries into the Resources directory, even within a package subdirectory, is problematic with respect to Apple's framework "spec".<br/>> Apple says that the Resources directory should contain all of the resources, where "a resource is anything which is not code".  They then go on to try to explain what code is.  Code is NOT a file which can be executed.  In particular a Tcl script (or a Python script, to use Apple's example) is not code even though it can be executed.  If you work your way through their tortured explanation, what you eventually learn is that the definition of "code" depends on codesigning.<br/>> <br/>> A file is "code" if it has a code signature embedded in the file.  (A text file can be signed, but the signature gets embedded in the "extended attributes" which are not preserved by most archiving formats, including zip and tar.  (They are preserved by .dmg).  A directory is "code" if it has a standard location for a code signature file.  So apps and frameworks are code.<br/>> <br/>> This means that we are currently breaking the so-called rules by putting binary extensions into the Resources directory, since such an extension contains a .dylib file, which can (and must, on Arm hardware) have an embedded signature.  Also, a package is not a "Script".  However a package would be a resource, if it did not contain a shared library.<br/>> <br/>> The format of the pkgIndex.tcl file does not require that the shared library be a sibling of the pkgIndex.tcl.  Any location can be specified, relative to the directory containing the pkgIndex.tcl file.<br/>> <br/>> So here is my proposal (where Z is Tcl or Tk, and where frameworks can either be installed in /Library/Frameworks or somewhere else):<br/>> <br/>> 1. Packages should be installed in<br/>>   /path/to/Frameworks/Z.framework/Versions/X.Y/Resources/Packages<br/>> <br/>> 2. Modules should be installed in<br/>>   /path/to/Frameworks/Z.framework/Versions/X.Y/Resources/Modules<br/>> <br/>> 3. BUT, for binary extensions, the .dylib file should not be installed in<br/>> Resources.  Instead it should be installed in<br/>>   /path/to/Frameworks/Z.framework/Versions/X.Y/dylibs<br/>> and the load command in the pkgIndex.tcl file should look like:<br/>>     load [file join $dir .. .. dylibs libtcl9blahblah.dylib]<br/>> <br/>> I would welcome any comments<br/>> <br/>> - Marc<br/>> <br/>> <br/>> <br/>> <br/>> <br/>> <br/>> _______________________________________________<br/>> Tcl-Core mailing list<br/>> Tcl...@li...<br/>> https://lists.sourceforge.net/lists/listinfo/tcl-core<br/>

[TCLCORE] More on TEA packages for macOS

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

My second question (which is more of a topic than a question, and is really
a request for comments) is: where should Tcl and Tk extensions be installed
in macOS?

I have a proposal, and it is different from the current scheme.

First some background ...

There are two ways to install Tcl on macOS:
- a traditional unix "prefix" installation, usually with prefix /usr/local
- a "framework" install, usually in /Library/Frameworks

I am talking about the "framework" install only.  Note that this is the
most common way of installing Tcl and Tk on macOS, and is also how Active
State used to distribute Tcl and Tk.

It turns out that there are two critical, but non-obvious, components
related to frameworks: codesigning and notarization.  It is now required on
Apple Silicon that every binary, i.e. executable or shared library, be
signed (although ad-hoc signatures are allowed).  If an executable is not
signed it is instantly killed by Apple's gatekeeper.  Distributing
non-notarized macOS apps outside of the app store is possible but presents
unpleasant UX which is a barrier to usefulness.  Ad-hoc signatures are not
allowed for notarized apps, and notarization is required for the app store.

Codesigning and notarization are related to frameworks because Apple has a
specification for the structure of a framework, albeit a very loose one,
which is enforced primarily by threat.  The threat is that if you do not
follow the spec, vague as it may be, you can expect issues with
codesigning and notarization.

Next, about TEA packages:

Currently the standard location for a Tcl or Tk extension package is:
  /Library/Frameworks/Tcl.framework/Versions/X.Y/Resources/Scripts
or
  /Library/Frameworks/Tk.framework/Versions/X.Y/Resources/Scripts

I don't think that is such a good choice.

First, at the most basic level, binary packages are not scripts.  Even a
pure Tcl package is more than a script.  A tcl module could be viewed as a
script,
but, in my opinion, it would be better to call it what it is, a module.

Putting shared libraries into the Resources directory, even within a
package subdirectory, is problematic with respect to Apple's framework
"spec".
Apple says that the Resources directory should contain all of the
resources, where "a resource is anything which is not code".  They then go
on to try to explain what code is.  Code is NOT a file which can be
executed.  In particular a Tcl script (or a Python script, to use Apple's
example) is not code even though it can be executed.  If you work your way
through their tortured explanation, what you eventually learn is that the
definition of "code" depends on codesigning.

A file is "code" if it has a code signature embedded in the file.  (A text
file can be signed, but the signature gets embedded in the "extended
attributes" which are not preserved by most archiving formats, including
zip and tar.  (They are preserved by .dmg).  A directory is "code" if it
has a standard location for a code signature file.  So apps and frameworks
are code.

This means that we are currently breaking the so-called rules by putting
binary extensions into the Resources directory, since such an extension
contains a .dylib file, which can (and must, on Arm hardware) have an
embedded signature.  Also, a package is not a "Script".  However a package
would be a resource, if it did not contain a shared library.

The format of the pkgIndex.tcl file does not require that the shared
library be a sibling of the pkgIndex.tcl.  Any location can be specified,
relative to the directory containing the pkgIndex.tcl file.

So here is my proposal (where Z is Tcl or Tk, and where frameworks can
either be installed in /Library/Frameworks or somewhere else):

1. Packages should be installed in
  /path/to/Frameworks/Z.framework/Versions/X.Y/Resources/Packages

2. Modules should be installed in
  /path/to/Frameworks/Z.framework/Versions/X.Y/Resources/Modules

3. BUT, for binary extensions, the .dylib file should not be installed in
Resources.  Instead it should be installed in
  /path/to/Frameworks/Z.framework/Versions/X.Y/dylibs
and the load command in the pkgIndex.tcl file should look like:
    load [file join $dir .. .. dylibs libtcl9blahblah.dylib]

I would welcome any comments

- Marc

[TCLCORE] Report of TCL/Tk biweekly telco on 2nd of June, 2025 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

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

Dear Tcl/Tk team,

thank you for your participation at the telco.

An old agenda was followed. Sorry.
But it was a great meeting !

Here is my report:
1) Release items for TCL/Tk 9.0.2
Branch will start today.
Testing is clean.
RC0 is ready soon.

Ashok has some bug-fixes, which may only go to 9.1.
Only important on heavy load, use after free.
Not for 9.0.2, as there are risks.

lseq corner cases will probably also not in 9.0.2, currently only in 
9.1. Donal Fellows has taken over with new test cases.

2) Release items for Tcl/Tk 9.1.0a0
www.tcl-lang.org
-> new page needed for 9.1 as this one:
https://www.tcl-lang.org/software/tcltk/9.0.html
-> Copy the .tml template file.
-> include input from "changes.md".

3) TIP 723: monotonic clock: is it a bug? Platform solutions
New specification, no implementation jet, is for later.

4) TIP 712: positive options to the subst command
TIP merged, all ok.

5) Reinhards new socket stuff
May start as an extension and then go to the core.

QUICK WIP by Schelte.
Link to new socket stuff is not clear.

6) tk print enhancements
Great part of 9.0.2 - thank you.
Very careful work - test cases present, great work.

7) TIP 725: JSON PLIST access
Ok to have platform specific things as long as they are commonly useful.

It would be great if JSON data would be natively supported by 9.1.
We need more people in the core to make dreams reality.

8) TIP 720: TCL compiler reform
Great work, try, lseq,...

We need duplicate the test cases for compiled, semi-compiled and not 
compiled for each newly compiled command: try, lseq, ...

9) Documentation
Great work, thanks Torsten!
Back-porting of corrections would be great.

Troff-file corrections may be merged before md merge, but no hurry.

10) Bundled packages

- SQLite: February Version will be distributed. Current update from 
SQLite is pending, but not in 9.0.2.
- TDBC: there are changes, but no reason to hurry for 9.0.2.

Massimo, what about a release of TDBC?

10) Orphan packages repository

tkpath added from Steve Shaw, which is the latested.
Others are in Androwish and from René and BAWT.
Contributions welcome !

11) Conference status
Deadline soon.

12) Init functions.
I have to add something to the Init on Windows.
Which are the calls for Init?
Tcl_FindExecutable(NULL)
Once per process should be sufficient.
Tcl_CreateInterp()

13) tclconfig project
The project has a couple of changes.
This would change all bundled packages.

14) TIP 649: List API TIP
Vote warning soon.
Nobody commented the question about reference count details.
Input welcome!

Other meetings:
30th of June 12:00 UTC: UTC Monthly Virtual Meetup on same jitsi

Thank you all,
Harald

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

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

<div><img width="1" height="1" src="https://fedbdhd.r.tsp1-brevo.net/tr/op/CVHAVkZ8imDqLveq37xtgGUOATl88X1Lf3eTViPQa9GfENYvVdVb_QKtLYRUpem-R3eI_40iTaR3vH9SCsehVuPiHFf7gdUOv-kY3QgjFmQ9RvbsuOq2z60L-YYA9V1Bx0pPOP9iBGJcr7AAjtN-3iydAeGMFt102Q6Kf74v4bnxQlL3JWd_n06FW3fVOHv6iNHDgDlt2_EQsuYibM1MrW7tcipi" style="mso-hide:all"/></div>For better or worse, the Mac does have a large batch of platform specific bits that are included in the tk::mac namespace but are core. There isn’t a tk::win namespace or tk::unix. Not sure how that evolved, but it’s there. <br/><br/>> On Jun 16, 2025, at 5:30 AM, Schelte Bron <tc...@tc...> wrote:<br/>> <br/>> Harald,<br/>> <br/>> There is no issue for me. I think it's a reasonable policy to avoid unnecessary core bloat. So I generally tend to make my contributions as extensions, not TIPs. That has the added bonus that the new features can already be used with existing Tcl/Tk versions.<br/>> <br/>> GetInfoAsJSON looks to me like something that might also better be done as an extension. Not least because the extent of its usefulness is quite questionable to me. I don't have the impression this is a feature that has been requested frequently. To my knowledge only one person asked about it and Marc just took up the challenge. It seems to me more like a weekend fun project than something that definitely needs to be present in the core.<br/>> <br/>> But that's just my impression. I don't have a vote, so by all means feel free to ignore my opinion.<br/>> <br/>> <br/>> Schelte.<br/>> <br/>> <br/>>> On 16/06/2025 10:44, Harald Oehlmann wrote:<br/>>> Schelte,<br/>>> if you have time today 2pm European time for the biweekly telco, we may discuss your case. Perhaps, you may distribute background information prior to the meeting.<br/>>> Thanks for all,<br/>>> Harald<br/>>>> Am 16.06.2025 um 10:29 schrieb Harald Oehlmann:<br/>>>> Am 16.06.2025 um 09:54 schrieb Schelte Bron:<br/>>>>> I'm a bit puzzled why this is considered for inclusion into the core. When a linux-only feature was suggested in the past, the feedback was that it didn't need to be in the core, it could be done as an extension. Sure, fair enough. But why doesn't the same reasoning apply to this feature? Is there a valid reason this cannot be done as an extension? Or is it just a double standard: Windows-only and Mac- only features can be added to the core, while unix-only features should be done as an extension?<br/>>>>> <br/>>>>> <br/>>>>> Schelte.<br/>>>> Schelte,<br/>>>> <br/>>>> thanks for the comment.<br/>>>> I am sorry that you got a negative answer on a Linux-only core extension. It was hopefully not me, as I normally try to get anything in what has a use-case and a supporter.<br/>>>> <br/>>>> I am personally against not including useful features to the core.<br/>>>> And if they are platform dependent, than this is as it is.<br/>>>> I am personally use-case driven.<br/>>>> So here, is a use-case.<br/>>>> <br/>>>> In addition, someone should do the work. The MAC platform is the most advanced platform with most platform specific features due to the fact, that Mark cares.<br/>>>> On Windows, we have no care-person for Tk (on Tcl, we have Ashok).<br/>>>> Linux/Unix is to my perception very difficult, as the platform has many variants and we have only little supporters.<br/>>>> When I asked about the monotonic patch on Linux, only a Windows only guy answered. It was impossible to get a review on Linux. This disqualified the patch on Linux.<br/>>>> <br/>>>> On Windows, we have most annoying bugs since 20 years in Tk and nobody cares. We all would love to have someone like Mark !<br/>>>> <br/>>>> I hope, we will solve the issue for you !<br/>>>> <br/>>>> Take care,<br/>>>> Harald<br/>> <br/>> <br/>> <br/>> _______________________________________________<br/>> Tcl-Core mailing list<br/>> Tcl...@li...<br/>> https://lists.sourceforge.net/lists/listinfo/tcl-core<br/>

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

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

Harald,

There is no issue for me. I think it's a reasonable policy to avoid 
unnecessary core bloat. So I generally tend to make my contributions as 
extensions, not TIPs. That has the added bonus that the new features can 
already be used with existing Tcl/Tk versions.

GetInfoAsJSON looks to me like something that might also better be done 
as an extension. Not least because the extent of its usefulness is quite 
questionable to me. I don't have the impression this is a feature that 
has been requested frequently. To my knowledge only one person asked 
about it and Marc just took up the challenge. It seems to me more like a 
weekend fun project than something that definitely needs to be present 
in the core.

But that's just my impression. I don't have a vote, so by all means feel 
free to ignore my opinion.


Schelte.


On 16/06/2025 10:44, Harald Oehlmann wrote:
> Schelte,
> if you have time today 2pm European time for the biweekly telco, we may 
> discuss your case. Perhaps, you may distribute background information 
> prior to the meeting.
> 
> Thanks for all,
> Harald
> 
> Am 16.06.2025 um 10:29 schrieb Harald Oehlmann:
>> Am 16.06.2025 um 09:54 schrieb Schelte Bron:
>>> I'm a bit puzzled why this is considered for inclusion into the core. 
>>> When a linux-only feature was suggested in the past, the feedback was 
>>> that it didn't need to be in the core, it could be done as an 
>>> extension. Sure, fair enough. But why doesn't the same reasoning 
>>> apply to this feature? Is there a valid reason this cannot be done as 
>>> an extension? Or is it just a double standard: Windows-only and Mac- 
>>> only features can be added to the core, while unix-only features 
>>> should be done as an extension?
>>>
>>>
>>> Schelte.
>> Schelte,
>>
>> thanks for the comment.
>> I am sorry that you got a negative answer on a Linux-only core 
>> extension. It was hopefully not me, as I normally try to get anything 
>> in what has a use-case and a supporter.
>>
>> I am personally against not including useful features to the core.
>> And if they are platform dependent, than this is as it is.
>> I am personally use-case driven.
>> So here, is a use-case.
>>
>> In addition, someone should do the work. The MAC platform is the most 
>> advanced platform with most platform specific features due to the 
>> fact, that Mark cares.
>> On Windows, we have no care-person for Tk (on Tcl, we have Ashok).
>> Linux/Unix is to my perception very difficult, as the platform has 
>> many variants and we have only little supporters.
>> When I asked about the monotonic patch on Linux, only a Windows only 
>> guy answered. It was impossible to get a review on Linux. This 
>> disqualified the patch on Linux.
>>
>> On Windows, we have most annoying bugs since 20 years in Tk and nobody 
>> cares. We all would love to have someone like Mark !
>>
>> I hope, we will solve the issue for you !
>>
>> Take care,
>> Harald

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

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

Schelte,
if you have time today 2pm European time for the biweekly telco, we may 
discuss your case. Perhaps, you may distribute background information 
prior to the meeting.

Thanks for all,
Harald

Am 16.06.2025 um 10:29 schrieb Harald Oehlmann:
> Am 16.06.2025 um 09:54 schrieb Schelte Bron:
>> I'm a bit puzzled why this is considered for inclusion into the core. 
>> When a linux-only feature was suggested in the past, the feedback was 
>> that it didn't need to be in the core, it could be done as an 
>> extension. Sure, fair enough. But why doesn't the same reasoning apply 
>> to this feature? Is there a valid reason this cannot be done as an 
>> extension? Or is it just a double standard: Windows-only and Mac-only 
>> features can be added to the core, while unix-only features should be 
>> done as an extension?
>>
>>
>> Schelte.
> Schelte,
> 
> thanks for the comment.
> I am sorry that you got a negative answer on a Linux-only core 
> extension. It was hopefully not me, as I normally try to get anything in 
> what has a use-case and a supporter.
> 
> I am personally against not including useful features to the core.
> And if they are platform dependent, than this is as it is.
> I am personally use-case driven.
> So here, is a use-case.
> 
> In addition, someone should do the work. The MAC platform is the most 
> advanced platform with most platform specific features due to the fact, 
> that Mark cares.
> On Windows, we have no care-person for Tk (on Tcl, we have Ashok).
> Linux/Unix is to my perception very difficult, as the platform has many 
> variants and we have only little supporters.
> When I asked about the monotonic patch on Linux, only a Windows only guy 
> answered. It was impossible to get a review on Linux. This disqualified 
> the patch on Linux.
> 
> On Windows, we have most annoying bugs since 20 years in Tk and nobody 
> cares. We all would love to have someone like Mark !
> 
> I hope, we will solve the issue for you !
> 
> Take care,
> Harald

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

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

Am 16.06.2025 um 09:54 schrieb Schelte Bron:
> I'm a bit puzzled why this is considered for inclusion into the core. 
> When a linux-only feature was suggested in the past, the feedback was 
> that it didn't need to be in the core, it could be done as an extension. 
> Sure, fair enough. But why doesn't the same reasoning apply to this 
> feature? Is there a valid reason this cannot be done as an extension? Or 
> is it just a double standard: Windows-only and Mac-only features can be 
> added to the core, while unix-only features should be done as an extension?
> 
> 
> Schelte.
Schelte,

thanks for the comment.
I am sorry that you got a negative answer on a Linux-only core 
extension. It was hopefully not me, as I normally try to get anything in 
what has a use-case and a supporter.

I am personally against not including useful features to the core.
And if they are platform dependent, than this is as it is.
I am personally use-case driven.
So here, is a use-case.

In addition, someone should do the work. The MAC platform is the most 
advanced platform with most platform specific features due to the fact, 
that Mark cares.
On Windows, we have no care-person for Tk (on Tcl, we have Ashok).
Linux/Unix is to my perception very difficult, as the platform has many 
variants and we have only little supporters.
When I asked about the monotonic patch on Linux, only a Windows only guy 
answered. It was impossible to get a review on Linux. This disqualified 
the patch on Linux.

On Windows, we have most annoying bugs since 20 years in Tk and nobody 
cares. We all would love to have someone like Mark !

I hope, we will solve the issue for you !

Take care,
Harald

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV Warning

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

I'm a bit puzzled why this is considered for inclusion into the core. 
When a linux-only feature was suggested in the past, the feedback was 
that it didn't need to be in the core, it could be done as an extension. 
Sure, fair enough. But why doesn't the same reasoning apply to this 
feature? Is there a valid reason this cannot be done as an extension? Or 
is it just a double standard: Windows-only and Mac-only features can be 
added to the core, while unix-only features should be done as an extension?


Schelte.


On 15/06/2025 17:01, Marc Culler wrote:
> This TIP was discussed quite a bit on this list, and the discussion now 
> seems to have run its course without any objections having been raised.  
> So I intend to call for a vote in a day or two.
> 
> - Marc

Re: [TCLCORE] TEA packages on macOS

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

On 15/06/2025 21:55, Marc Culler wrote:
> Well, yeah.  If it had been documented then I might have avoided quite a 
> few painful hours (since every interaction with autoconf is painful) of 
> hacking my own tcl.m4.  Knowing about this will be extremely useful to me.

Next to the documentation, the wiki is a useful source of information:
https://wiki.tcl-lang.org/page/SampleExtension


Schelte.

Re: [TCLCORE] TEA packages on macOS

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

Confirming that using the tcl.m4 from the tip of the tclconfig repository
(once you know that repository exists) works perfectly.  It generates a
configure file that is exactly the same as the one in the
sampleextension repository.  Bravo!

- Marc

On Sun, Jun 15, 2025 at 2:55 PM Marc Culler <cul...@gm...> wrote:

> On Sun, Jun 15, 2025 at 1:06 PM Jan Nijtmans <jan...@gm...>
> wrote:
>
> The idea behind this is not duplicating the content of the "tclconfig"
>> repository in every extension. Building the sampleextension is done
>> like this:
>>     cd <path_to>/sampleextension
>>     mkdir tclconfig
>>     cd tclconfig
>>     fossil open --nested <path_to>/tclconfig.fossil
>>     cd ..
>>     touch configure.ac
>>     autoconf (should be autoconf-2.72, but 2.69 works as well)
>>     ./configure ....
>>     make
>> Looks like this should be documented somewhere ...
>>
>
> Well, yeah.  If it had been documented then I might have avoided quite a
> few painful hours (since every interaction with autoconf is painful) of
> hacking my own tcl.m4.  Knowing about this will be extremely useful to me.
>
> > The difference is that a "dynamic library" can also be used by the
>> static linker ld.
>>
>> That's it!   In Tcl, you can adapt tclAppInit.c, and add calls to
>> Xxx_Init() for whatever
>> extension you like, and link all libraries with "ld". Would that
>> possibility be lost
>> when we change to use the "bundle" format?
>>
>
> If you would need to link the Tcl library against the extension's shared
> library then, yes, it would need to be a .dylib file, not a .so file.
> That must be the reason for this design.  Thanks for answering my first
> question!
>
> That is not the whole story, of course.  A "shared library" (.dylib) has
> an "install name" which is supposed to be a path to the shared library, and
> which gets used by the linker to create a load path for the shared
> library.  So the extension library would need to be installed in the
> location indicated by its install name in order for the resulting
> tclAppInit.o to be usable.  The install name is flexible, however.  It can
> have the form "@rpath/x/y".  In that case you can specify an rpath when
> doing the link, and that rpath can even be relative to the location of the
> Tcl library which includes the modified tclAppInit (i.e. the rpath can have
> the form "@loader_path/u/v").
>
> Is there a good example of one of these Tcl's with an adapted tclAppInit?
>
> - Marc
>

Re: [TCLCORE] TEA packages on macOS

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

On Sun, Jun 15, 2025 at 1:06 PM Jan Nijtmans <jan...@gm...> wrote:

The idea behind this is not duplicating the content of the "tclconfig"
> repository in every extension. Building the sampleextension is done
> like this:
>     cd <path_to>/sampleextension
>     mkdir tclconfig
>     cd tclconfig
>     fossil open --nested <path_to>/tclconfig.fossil
>     cd ..
>     touch configure.ac
>     autoconf (should be autoconf-2.72, but 2.69 works as well)
>     ./configure ....
>     make
> Looks like this should be documented somewhere ...
>

Well, yeah.  If it had been documented then I might have avoided quite a
few painful hours (since every interaction with autoconf is painful) of
hacking my own tcl.m4.  Knowing about this will be extremely useful to me.

> The difference is that a "dynamic library" can also be used by the static
> linker ld.
>
> That's it!   In Tcl, you can adapt tclAppInit.c, and add calls to
> Xxx_Init() for whatever
> extension you like, and link all libraries with "ld". Would that
> possibility be lost
> when we change to use the "bundle" format?
>

If you would need to link the Tcl library against the extension's shared
library then, yes, it would need to be a .dylib file, not a .so file.
That must be the reason for this design.  Thanks for answering my first
question!

That is not the whole story, of course.  A "shared library" (.dylib) has an
"install name" which is supposed to be a path to the shared library, and
which gets used by the linker to create a load path for the shared
library.  So the extension library would need to be installed in the
location indicated by its install name in order for the resulting
tclAppInit.o to be usable.  The install name is flexible, however.  It can
have the form "@rpath/x/y".  In that case you can specify an rpath when
doing the link, and that rpath can even be relative to the location of the
Tcl library which includes the modified tclAppInit (i.e. the rpath can have
the form "@loader_path/u/v").

Is there a good example of one of these Tcl's with an adapted tclAppInit?

- Marc

Re: [TCLCORE] TEA packages on macOS

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

Op zo 15 jun 2025 om 19:32 schreef Marc Culler <cul...@gm...>:
>
> I have a lot of questions on this topic.  I will ask them one at a time, to try to avoid overload.
>
> Before I ask the first one, I would like to draw attention to ticket c397574993 on the sample extension repository.  (I am not sure if anyone monitors that repository.) It is a glaring indication that the TEA sample extension is not really in a state where it can be used.

The idea behind this is not duplicating the content of the "tclconfig"
repository in every extension. Building the sampleextension is done
like this:
    cd <path_to>/sampleextension
    mkdir tclconfig
    cd tclconfig
    fossil open --nested <path_to>/tclconfig.fossil
    cd ..
    touch configure.ac
    autoconf (should be autoconf-2.72, but 2.69 works as well)
    ./configure ....
    make
Looks like this should be documented somewhere ...

> Here is my first question.  When you build a TEA compliant binary Tcl extension, say the sample extension, you end up with a .dylib file.  The question is: Why????

    $ tclsh9.0
    % info sharedlibextension
    .dylib

Note that, if we change this, we should change "info
sharedlibextension" as well.

> ....
> The difference is that a "dynamic library" can also be used by the static linker ld.

That's it!   In Tcl, you can adapt tclAppInit.c, and add calls to
Xxx_Init() for whatever
extension you like, and link all libraries with "ld". Would that
possibility be lost
when we change to use the "bundle" format?

Therefore, I don't see a good reason to change this.

Hope this helps,
    Jan Nijtmans

[TCLCORE] TEA packages on macOS

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

I have a lot of questions on this topic.  I will ask them one at a time, to
try to avoid overload.

Before I ask the first one, I would like to draw attention to ticket
c397574993 <https://core.tcl-lang.org/sampleextension/tktview/c397574993> on
the sample extension repository.  (I am not sure if anyone monitors that
repository.) It is a glaring indication that the TEA sample extension is
not really in a state where it can be used.

Here is my first question.  When you build a TEA compliant binary Tcl
extension, say the sample extension, you end up with a .dylib file.  The
question is:* Why????*

I don't think it makes sense.  There are two types of shared libraries on
macOS.  They normally have different file extensions: *.so *for a so-called
"bundle" and *.dylib* for a so-called "dynamic library".  Both of these
file types can be dynamically loaded by *dyld*.  So either type should work
for a binary Tcl extension.  The difference is that a "dynamic library" can
also be used by the static linker* ld*.

Other languages, e.g. Python, use .so files for binary extension modules
which are loaded by dyld.  Tcl could do that as well.  The only reason not
to do that would be if you needed to statically link against the shared
library in a Tcl binary extension.  And that is why the Tk extension, i.e.
the dynamic library named Tk (the .dylib filename extension is optional),
uses the "dynamic library" format.  Other extensions need to link against
it.  But for a normal TEA extension, the simpler "bundle" format would seem
to make more sense.

Does anyone here know anything about why TEA is doing this?

- Marc

Re: [TCLCORE] TIP #725 (::tk::mac:GetInfoAsJSON): CFV Warning

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

Typo: the command name is ::tk::mac::GetInfoAsJSON, with three pairs of
colons, of course.

- Marc

On Sun, Jun 15, 2025 at 10:01 AM Marc Culler <cul...@gm...> wrote:

> This TIP was discussed quite a bit on this list, and the discussion now
> seems to have run its course without any objections having been raised.  So
> I intend to call for a vote in a day or two.
>
> - Marc
>

[TCLCORE] TIP #725 (::tk::mac:GetInfoAsJSON): CFV Warning

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

This TIP was discussed quite a bit on this list, and the discussion now
seems to have run its course without any objections having been raised.  So
I intend to call for a vote in a day or two.

- Marc

Re: [TCLCORE] New TIP #725: Add command ::tk::mac:GetInfoAsJSON

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

Harald,

Comments are  welcome!  That was the point of my message.

I did a little more research and I can report that there is, in fact, an
Info.plist template in the Tcl/macosx directory.  It is used when Tcl is
built as a framework.  That is because every macOS framework must include
an Info.plist file.  (Frameworks and Applications are both subclasses of
Bundles, and Bundles have Info.plist files.) It is conceivable that an
Objective C library which is within a framework could access an
infoDictionary for the framework.  I don't know if that is the case or not.

Also, there is a file tclMacOSXBundle.c which claims:
*      This file implements functions that inspect CFBundle structures on
 *      MacOS X.

That file contains a function Tcl_MacOSXOpenVersionedBundleResources.  But
the purpose of that command seems to be to find the path to the
Resources/Scripts directory for the current version of Tcl within the
bundle.  (That is the directory where packages are installed.)

However,  I still don't see any evidence that there could be an analogous
command for tclsh.  Also, I don't know of a use case for such a thing.

- Marc

On Fri, Jun 13, 2025 at 11:10 AM Harald Oehlmann <
har...@el...> wrote:

> Am 13.06.2025 um 18:04 schrieb Marc Culler:
> > On Fri, Jun 13, 2025 at 10:30 AM Harald Oehlmann
> > <har...@el... <mailto:har...@el...>>
> wrote:
> >
> >     - why tk::mac and not tcl::mac namespace ? As this applies probably
> to
> >     tclsh also, no?
> >
> >
> > I don't think it applies to tclsh. unless the Tk package has been
> > loaded.  There is no NSApplication created by tclsh, and hence no
> > Info.plist file and no mainBundle object available.  The NSApplication
> > object is instantiated in tkMacOSXInit.c which does not get run when
> > tclsh starts.
> >
> > - Marc
>
> Marc,
> thanks for the clarification. If you ask, you get comments, sorry for that.
> I appreciate your always brilliant initiative to make the Mac platform
> support better and that one small requests leads to action, which may
> have needed some nights of work.
>
> Cudos,
> Harald
>

Re: [TCLCORE] New TIP #725: Add command ::tk::mac:GetInfoAsJSON

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

Am 13.06.2025 um 18:04 schrieb Marc Culler:
> On Fri, Jun 13, 2025 at 10:30 AM Harald Oehlmann 
> <har...@el... <mailto:har...@el...>> wrote:
> 
>     - why tk::mac and not tcl::mac namespace ? As this applies probably to
>     tclsh also, no?
> 
> 
> I don't think it applies to tclsh. unless the Tk package has been 
> loaded.  There is no NSApplication created by tclsh, and hence no 
> Info.plist file and no mainBundle object available.  The NSApplication 
> object is instantiated in tkMacOSXInit.c which does not get run when 
> tclsh starts.
> 
> - Marc

Marc,
thanks for the clarification. If you ask, you get comments, sorry for that.
I appreciate your always brilliant initiative to make the Mac platform 
support better and that one small requests leads to action, which may 
have needed some nights of work.

Cudos,
Harald

Re: [TCLCORE] New TIP #725: Add command ::tk::mac:GetInfoAsJSON

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

On Fri, Jun 13, 2025 at 10:30 AM Harald Oehlmann <
har...@el...> wrote:

- why tk::mac and not tcl::mac namespace ? As this applies probably to
> tclsh also, no?
>

I don't think it applies to tclsh. unless the Tk package has been loaded.
There is no NSApplication created by tclsh, and hence no Info.plist file
and no mainBundle object available.  The NSApplication object is
instantiated in tkMacOSXInit.c which does not get run when tclsh starts.

- Marc

Re: [TCLCORE] New TIP #725: Add command ::tk::mac:GetInfoAsJSON

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

Am 13.06.2025 um 17:07 schrieb Marc Culler:
> This is an announcement of a new tip #725 and an invitation for 
> discussion of the TIP.  There is already a thread on this list which 
> discusses the new command in some detail.  That discussion began with a 
> request from Iohannes Zmölnig to expose the contents of the Info.plist 
> file of a Tk-based macOS app at the Tcl level.
> 
> There is a complete implementation (including a manual entry ) in the
> fossil branch.  There seem to be no non-regression tests for commands in 
> the ::tk::mac namespace, and I did not add one for this command.
> 
> - Marc
Looks great, thank you. It is a bit like accessing the Manifest on 
Windows executables.

Here are my dump questions:
- why tk::mac and not tcl::mac namespace ? As this applies probably to 
tclsh also, no?
- might this be a start of a platform independent 
"platform::exeparameter" command, which may, in future, return the plist 
on Mac and the Windows manifest on the Windows platform?

Thanks for all,
Harald

[TCLCORE] New TIP #725: Add command ::tk::mac:GetInfoAsJSON

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

This is an announcement of a new tip #725 and an invitation for discussion
of the TIP.  There is already a thread on this list which discusses the new
command in some detail.  That discussion began with a request from Iohannes
Zmölnig to expose the contents of the Info.plist file of a Tk-based macOS
app at the Tcl level.

There is a complete implementation (including a manual entry ) in the
fossil branch.  There seem to be no non-regression tests for commands in
the ::tk::mac namespace, and I did not add one for this command.

- Marc

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

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

Dear Tcl/Tk team,

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

Possible agenda:
1) Release items for TCL/Tk 9.0.2
Are we ready?

2) Release items for Tcl/Tk 9.1.0a0
What gets in?

3) TIP 649: list API for lreverse ....
4) TIP 700: documentation reform
5) TIP 723: monotonic clock
6) TIP 720: TCL compiler reform
7) lseq corner cases
8) Conference status

Other meetings:
30th of June 12:00 UTC: UTC Monthly Virtual Meetup on same jitsi

Thank you all,
Harald

Re: [TCLCORE] Question on C casts

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

With apologies to all for the continued pedantry... 😊

> From: Dipl. Ing. Sergey G. Brester <se...@us...> 
> Nope. 
> It was not about addition but about multiplication, so "aDouble * aDouble" (explicit) vs "aDouble * anInteger" (without cast).

My example was exactly that - an *example*. The implicit promotion of *any* integer type to double takes place for all arithmetic operations when the other operand is a double, no matter whether it is multiplication, addition or anything else.

> Sure, as already written, the result of this is always double, but the accuracy may depend on compiler, platform/cpu, level of optimization etc.
> And your assumption it shall always be the same is quite incorrect - IIRC, there are several tickets already,
> for instance - in https://core.tcl-lang.org/tcl/tktview/d2a3c5f80b it behaves different for ARM.

I never said the accuracy is the same on all platforms, compilers, architectures or even the same combination with different switches so I don't know why you bring that up. What I said was the implicit promotion will happen regardless and will have the same result as an explicit cast. The actual value may differ between platforms, compilers, phase of the moon, whatever but will be the same for a given compiler/arch/switches/optimization combination no matter whether the type conversion is implicit or explicit.

The fixes in the link you gave pertain to (a) floating point stability, (b) the fact that conversion of long (wides) greater than 53 bits to doubles may give implementation-dependent non-exact results (as *permitted* by the standard), and (c) guarding against UB. All of which are true but not the point of my question. Even with (b), which is implementation dependent values, a particular implementation must give the same value for implicit and explicit conversion.

So, sorry, not convinced but as I said, if it adds clarity to what's happening, the same way that (2*3)+1 adds clarity to 2*3+1 , that's fine.

/Ashok

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

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

Ignorant of macOS, but I would say returning the data as json, while perhaps not ideal, is reasonable the same way that the http package relies on tcllib or equivalent to parse HTTP content.

 

/Ashok

 

From: Marc Culler <cul...@gm...> 
Sent: Thursday, June 12, 2025 7:57 PM
To: IOhannes m zmoelnig <zmo...@ie...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] expose content of macOS' Info.plist

 

On Thu, Jun 12, 2025 at 6:49 AM IOhannes m zmoelnig <zmo...@ie... <mailto:zmo...@ie...> > wrote:

i finally got around to build and test your branch, and so far it does 
indeed everything I've asked for.

 

Great! 

 

just a tiny nitpick: i find it a bit weird that i have to resort to an 
external library ("tcllib") in order to do something meaningful with the 
data returned by a core function ("::tk::mac::getInfoAsJSON").

 

Real life intrudes here as well!  A .plist file is a serialized dictionary.  Tcl does not support decoding the plist format.  But Apple does support serializing an Objective C dictionary as JSON.  So my choices seemed to be:

 

1. Write a plist serializer for Tcl.  (Big project, prone to errors, not very useful in general.)

2. Write C code to directly convert an Objective C dictionary to a Tcl dict.  (Big project, prone to errors, not very useful in general.)

3. Use existing Apple code to serialize an Objective C dict as JSON and use existing, tested, easily available and lightweight Tcl code to decode a json-encoded dict.  (Easy, low impact, fast, uses tested code in a straightforward way, so very likely to be correct.)

 

I chose 3.

 

of course tcllib is pure Tcl, and if i only include the "json" package, 
the (size) overhead is marginal.
and i totally see the beauty of the simplicity of the current 
implementation.

 

Indeed, that was my rationale.

 

but it feels a bit weird nevertheless.

but then, i'm not a deep diver in the Tcl seas, and the community as 
such might find this a totally normal approach, in which case please 
ignore my feeling.

 

I can't speak for the community, but I think this would be considered acceptable. We will find out when I write the TIP to add the new command ::tk::mac::getInfoAsJSON to the ::tk::mac namespace.

 

anyhow: thanks a lot for the very quick response/implementation/help
(and special thanks for giving me instructions off-list on how to build 
from fossil)

 

You are very welcome.

 

- Marc