tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Update of macosx/Readme

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

On Tue, Jun 17, 2025 at 9:21 AM Harald Oehlmann <har...@el...>
wrote:

> Marc,
> thanks for updating the macos readme on the main branch:
>
> When looking to:
> https://core.tcl-lang.org/tips/doc/trunk/tip/715.md
>
> there is the requirement of Mac-OS 11 for arm64 silicon.
> May this information be added?
>

I guess so.  It is a vacuous requirement since macOS 11 was the earliest
version of macOS which ran on arm64.

As 9.0.2 is knocking on the door: are there any correction for this branch?
>

The changes are appropriate for 9.0.2 as well.  Feel free to do a cherry
pick.

- Marc

Re: [TCLCORE] Update of macosx/Readme

[Alexander S. <a.s...@gm...>]

Maybe a bit pedantic, but formally better:

The minimum macOS versions supported by Tcl differ for the x86_64 and arm64 architectures because macOS 11 was the first OS version that supported arm64 (Apple Silicon).


> Am 17.06.2025 um 16:20 schrieb Harald Oehlmann <har...@el...>:
> 
> Marc,
> thanks for updating the macos readme on the main branch:
> 
> When looking to:
> https://core.tcl-lang.org/tips/doc/trunk/tip/715.md
> 
> there is the requirement of Mac-OS 11 for arm64 silicon.
> May this information be added?
> 
> As 9.0.2 is knocking on the door: are there any correction for this branch?
> 
> Thanks for all,
> Harald
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] Update of macosx/Readme

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

Marc,
thanks for updating the macos readme on the main branch:

When looking to:
https://core.tcl-lang.org/tips/doc/trunk/tip/715.md

there is the requirement of Mac-OS 11 for arm64 silicon.
May this information be added?

As 9.0.2 is knocking on the door: are there any correction for this branch?

Thanks for all,
Harald

[TCLCORE] TIP #712 accepted and merged

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

Vote-Summary: Accepted 8/0/0

Votes-For: RM, BG, HO, AN, FV, MC, RA, SL

Votes-Against: none

Votes-Present: none

TIP #712 accepted.

https://core.tcl-lang.org/tcl/info/f41248f05784051a

Thanks,
Reinhard

Re: [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...>]

Am 17.06.2025 um 11:23 schrieb Torsten Berg:
> Having said that: if the TCT finds it a valuable contribution to have obvious errors corrected or changes I propose in the tip-700 branch implemented already in the upcoming 9.0.2 version, then I can propose some of my changes for version 9.0.2 and backport those manually.
Thanks, Torsten, for your effort and plan.
I have losely followed your activity.
The changes are mostly formatting.
If you have any content change, it would be great to have it in the 
release. But there is no hurry.

Arange it, as you like it and also give instructions to others what may 
help you, e.g. not modify main doc etc.

It would also be great, if you may author the 9.1.0 web page on 
tcl-lang.org.
As you mentioned, that you are working on a revision, that would be 
great. IMHO, just go on.

Feel supported and appreciated,
Harald

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

[Torsten B. <be...@ty...>]

Hi,

thanks for your continued effort to always document the discussions going on at the meeting. This is highly appreciated as I typically are too much involved in my daily work to participate despite trying to get a free slot every time!

As for the documentation: yes, the idea is to  backport the changes/corrections. The procedure would, however, not be that I just randomly change the original nroff files from time to time. I would rather collect all changes in the branch where I am currently working, then bring the TIP to a vote when time has come and merge everything back to trunk then if the vote is successful.

At that point, the original nroff files will go away and the changes would be contained in the new markdown files from which a set of nroff files will again be auto-generated. The markdown files will then be the source files for all other formats to produce.

Cheers, Torsten


> Am 16.06.2025 um 14:55 schrieb Harald Oehlmann <Har...@El...>:
> 
> Signierter PGP-Teil
> 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] Report of TCL/Tk biweekly telco on 2nd of June, 2025 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

[Torsten B. <be...@ty...>]

Having said that: if the TCT finds it a valuable contribution to have obvious errors corrected or changes I propose in the tip-700 branch implemented already in the upcoming 9.0.2 version, then I can propose some of my changes for version 9.0.2 and backport those manually.

Torsten


> Am 17.06.2025 um 11:11 schrieb Torsten Berg <be...@ty...>:
> 
> Hi,
> 
> thanks for your continued effort to always document the discussions going on at the meeting. This is highly appreciated as I typically are too much involved in my daily work to participate despite trying to get a free slot every time!
> 
> As for the documentation: yes, the idea is to  backport the changes/corrections. The procedure would, however, not be that I just randomly change the original nroff files from time to time. I would rather collect all changes in the branch where I am currently working, then bring the TIP to a vote when time has come and merge everything back to trunk then if the vote is successful.
> 
> At that point, the original nroff files will go away and the changes would be contained in the new markdown files from which a set of nroff files will again be auto-generated. The markdown files will then be the source files for all other formats to produce.
> 
> Cheers, Torsten
> 
> 
>> Am 16.06.2025 um 14:55 schrieb Harald Oehlmann <Har...@El...>:
>> 
>> Signierter PGP-Teil
>> 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
>> 
>> 
> 

[TCLCORE] tclx, tktreectrl and tkpath repositories and a request

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

tclx, tktreectrl and tkpath have been added to the Tcl/Tk "orphaned
extensions" repository at https://github.com/tcltk-depot.

 

Thanks to Brian Griffin for tclx.

 

Thanks to @egavilan (Emiliano) for the porting tktreectrl to Tcl/Tk 9 and
@bandito for updating the build system to the latest tclconfig.

 

tkpath comes from the fork used in HammerDB and updates from Steve Shaw
(@sm-shaw) for tkpath. It has been updated for Tcl/Tk 9 but may need work to
build for Tcl 8.6.

 

Looking for volunteers to take ownership of the above (merge other forks as
necessary, review pull requests and bug reports etc.) If you can help, let
Harald, Emiliano or me know and we can add you as a member.

 

For tkpath in particular, there are at least a couple of forks - Rene's on
chiselapp and Christian's Androwish. I could not tell the temporal relation
with the above tkpath so it would help if Rene, Christian or someone
familiar could see what, if anything, might need to be merged.

 

tktreectrl and tkpath have been tested on Windows and Linux. Someone testing
on macOS would be helpful.

 

As a reminder, tcltk-depot needs to be a collective effort.

 

Thanks,

 

/Ashok

Re: [TCLCORE] TIP 649

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

Warning: CFV for TIP 649 coming up this week. Please review and comment,
particularly with regard to the reference counting protocol summarized
below.

 

/Ashok

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Sunday, June 8, 2025 10:47 PM
To: tcl...@li...
Subject: [TCLCORE] TIP 649

 

TIP 649 is ready for review. It merely exposes some list functionality at
the C level that was already available at the script level. Benefits are
both programmer convenience and efficiency.

 

However, the semantics in terms of reference counting might be worthy of
review.

 

First, unlike Tcl_ListObjReplace which requires an unshared Tcl_Obj to be
passed in, the new functions permit shared objects as input. Conversely,
they never modify the passed in object even if unshared.

 

Second, the returned Tcl_Obj is *always* different from the one passed in.

 

Third, the returned Tcl_Obj is not guaranteed to have a reference count of
0.

 

See the TIP Discussion section for the rationale for the above.

 

I plan on a CFV in two weeks as the TIP is mostly about exposing existing
internal API's.

 

/Ashok

Re: [TCLCORE] Accurate info about Tcl

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

Great, you have my mandate !
Harald

Am 17.06.2025 um 07:46 schrieb Torsten Berg:
> Hi,
> 
> thanks for pushing the macOS side of Tcl!
> 
> I have never built Tcl using the Xcode IDE. However, the install 
> instructions (macosx/README) in the core distribution implicitly and 
> between the lines suggest this should be possible. It says "To build 
> universal binaries outside of the Xcode IDE ..." as if it should be 
> possible to also build it with the IDE. There are, nonetheless, no 
> instructions on how to do this. Maybe the wording could be enhanced or 
> rather it can be made explicit that this is not the case.
> 
> (Actually, the README file also still used the outdated "MAC OS X" and I 
> always wonder whether the information is correct saying that you need 
> "at least Mac OS X 10.3 [...] to build Tcl" and "At a minimum, Mac OS X 
> 10.3 is required to run Tcl". I remember the discussion leading to 
> https://core.tcl-lang.org/tips/doc/trunk/tip/715.md <https://core.tcl- 
> lang.org/tips/doc/trunk/tip/715.md> where macOS 10.15 for Intel and 
> macOS 11 for Apple Silicon machines are documented ... oh, and "Intel 
> silicon" on that page seems a wrong term as it is about the x86 
> architecture)
> 
> As to the term "Mac OS X" on the website (and elsewhere). I have already 
> made the necessary changes to the files for the web pages a while ago. 
> Unfortunately, Steve (who initiated this process) has too much real life 
> work on his desk to actually review my changes and publish them. Should 
> this perhaps be delegated to someone else? My changes also include many 
> more clarifications etc., deleting outdated stuff, suggesting additions 
> and clarifications and so on. Someone from the TCT (?) just needs to 
> take the time and dedication to go through it all.
> 
> I am willing to help updating documentation if I get a mandate.
> 
> Regards, Torsten
> 
> 
>> Am 17.06.2025 um 00:50 schrieb Marc Culler <cul...@gm...>:
>>
>> Sorry for nitpicking and harping on this general subject, but ...
>>
>> On the page https://www.tcl-lang.org/software/tcltk/download.html 
>> <https://www.tcl-lang.org/software/tcltk/download.html> one finds the 
>> statement (with emphasis added by me):
>>
>>     The source releases include make files for Windows, Unix and Xcode
>>     project files for Mac OS X.
>>
>>
>> There are no Xcode project files that I can find.  I don't think 
>> anyone builds Tcl or Tk as an Xcode project anymore.  People either 
>> use the Command Line Tools or a compiler, linker and SDK provided with 
>> the Xcode app.  But I don't think anyone uses the Xcode IDE, and there 
>> is no support for doing that in the source archive.
>>
>> Also, the Apple OS has been named macOS since 2016.
>>
>> - Marc
>>
>>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core


-- 
ELMICRON Dr. Harald Oehlmann GmbH
Koesener Str. 85
06618 NAUMBURG - Germany
Phone: +49 3445 781120
Direct: +49 3445 781127
www.Elmicron.de
German legal references:
Geschaeftsfuehrer: Dr. Harald Oehlmann
UST Nr. / VAT ID No.: DE206105272
HRB 212803 Stendal

Re: [TCLCORE] Accurate info about Tcl

[Torsten B. <be...@ty...>]

Hi,

thanks for pushing the macOS side of Tcl!

I have never built Tcl using the Xcode IDE. However, the install instructions (macosx/README) in the core distribution implicitly and between the lines suggest this should be possible. It says "To build universal binaries outside of the Xcode IDE ..." as if it should be possible to also build it with the IDE. There are, nonetheless, no instructions on how to do this. Maybe the wording could be enhanced or rather it can be made explicit that this is not the case.

(Actually, the README file also still used the outdated "MAC OS X" and I always wonder whether the information is correct saying that you need "at least Mac OS X 10.3 [...] to build Tcl" and "At a minimum, Mac OS X 10.3 is required to run Tcl". I remember the discussion leading to https://core.tcl-lang.org/tips/doc/trunk/tip/715.md where macOS 10.15 for Intel and macOS 11 for Apple Silicon machines are documented ... oh, and "Intel silicon" on that page seems a wrong term as it is about the x86 architecture)

As to the term "Mac OS X" on the website (and elsewhere). I have already made the necessary changes to the files for the web pages a while ago. Unfortunately, Steve (who initiated this process) has too much real life work on his desk to actually review my changes and publish them. Should this perhaps be delegated to someone else? My changes also include many more clarifications etc., deleting outdated stuff, suggesting additions and clarifications and so on. Someone from the TCT (?) just needs to take the time and dedication to go through it all.

I am willing to help updating documentation if I get a mandate.

Regards, Torsten


> Am 17.06.2025 um 00:50 schrieb Marc Culler <cul...@gm...>:
> 
> Sorry for nitpicking and harping on this general subject, but ...
> 
> On the page https://www.tcl-lang.org/software/tcltk/download.html one finds the statement (with emphasis added by me):
> 
>> The source releases include make files for Windows, Unix and Xcode project files for Mac OS X.
> 
> There are no Xcode project files that I can find.  I don't think anyone builds Tcl or Tk as an Xcode project anymore.  People either use the Command Line Tools or a compiler, linker and SDK provided with the Xcode app.  But I don't think anyone uses the Xcode IDE, and there is no support for doing that in the source archive.
> 
> Also, the Apple OS has been named macOS since 2016.
> 
> - Marc
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] Accurate info about Tcl

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

Sorry for nitpicking and harping on this general subject, but ...

On the page https://www.tcl-lang.org/software/tcltk/download.html one finds
the statement (with emphasis added by me):

The source releases include make files for Windows, Unix and Xcode project
> files for Mac OS X.


There are no Xcode project files that I can find.  I don't think anyone
builds Tcl or Tk as an Xcode project anymore.  People either use the
Command Line Tools or a compiler, linker and SDK provided with the Xcode
app.  But I don't think anyone uses the Xcode IDE, and there is no support
for doing that in the source archive.

Also, the Apple OS has been named macOS since 2016.

- Marc

Re: [TCLCORE] More on TEA packages for macOS

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

Right.  It would be a correct answer to a different, largely unrelated
question.

But the point is that these things spend millions of cpu hours munching on
the entire internet.  So their answers reflect the information about this
topic which is potentially available to users who don't have
special knowledge about where to look.

- Marc

On Mon, Jun 16, 2025 at 2:23 PM Kevin Walzer <kw...@54...>
wrote:

> This is correct for the frameworks themselves, but not external packages.
>
> On Jun 16, 2025, at 3:10 PM, Marc Culler <cul...@gm...> wrote:
>
> 
> Of course we all expect wrong and missing information from AI
> assistants, and expect different people to get different answers.  But I
> think many people depend on those critters.  So it may be relevant to
> report what google's "AI overview" said when I asked "What is the standard
> location for a Tcl package on macOS?".
>
> *AI Overview*
> On macOS, Tcl packages can be found in several standard locations,
> primarily within the system's framework directories
> . The main directories where you'll find them are:
>
>    - */Library/Frameworks*: This is the default location for third-party
>    or built-from-source frameworks, including ActiveTcl releases.
>    - */System/Library/Frameworks*: This directory contains Apple-supplied
>    frameworks that come with macOS. *Note:* You should generally avoid
>    modifying or deleting files in this directory.
>    - *$HOME/Library/Frameworks*: You might also find Tcl and Tk
>    frameworks in your user's Library directory.
>
> - Marc
>
> PS The stupidest part is warning people against modifying files in
> /System/Library/Frameworks, as if that were even possible.
>
> On Mon, Jun 16, 2025 at 1:36 PM Marc Culler <cul...@gm...> wrote:
>
>> On Mon, Jun 16, 2025 at 12:31 PM Kevin Walzer <kw...@54...>
>> wrote:
>>
>> You can pass —libdir as a flag to configure to set the install dir.
>>>
>>
>> I guess you mean that you can do that when configuring an extension that
>> you build locally?
>>
>>
>>> I think the default directory is /usr/local if not otherwise defined.
>>> Either way, I’m not a fan of putting external stuff in the frameworks.
>>>
>>
>> I still don't know why you are not a fan.  However, the issue of what
>> should be the default install location actually runs pretty deep at the
>> moment, as I explain below.
>>
>> I recently committed a change to the tcllib repository to fix ticket [
>> e5f3dfc055
>> <https://fedbdhd.r.af.d.sendibt2.com/tr/cl/Ft28etyuAswveDuhHepGdF2VamfIZgnfmqtyPnoxSESmIm1oI69CPRO6r5YbfO9K5AMRXxaUYI95oegCeFwMQeSjZ8ZZwdw0_9KMtqdJ9Rr6JoNYgu-YtoMC2TiFtKk0gsG9gtvEKEWekt3tvFtmGhIIrmnGXibWJ8y5WkJ5s78CQiew4aNqOBbk0QzIJ5j7hmV0bLG3CyIiw5dIvSW1HvYN4N-Hg9jGO5d1RLk0Un5UTBdXHi_g5R7cCRIYFGimbkrn5bhFOpvAoHK9xLx9IlfibdREQ7cAChwHWME1GqrYiMU>],
>> posted by Ashok a year ago, which was reporting that the Tcllib installer
>> does not work "out of the box".  That means that the installer script would
>> fail if you used its default install path, although you could edit the path
>> if you happened to know where you wanted to install Tcllib. I think it is
>> pretty clear that the default path for the Tcllib installer **should** be
>> the "standard location" for Tcl packages, whatever that is.
>>
>> The reason that the installer script did not work was that it was
>> choosing the zipfs as the install location on Windows and Linux, and the
>> path /Library/Frameworks/Tk.framework/Versions on macOS.  It makes no sense
>> to install a package in the zipfs and it also makes no sense to install a
>> pure Tcl package in the Tk framework.  Moreover installing it in the
>> Versions directory completely corrupts the structure of the Tk framework.
>>
>> The fix was to take the default install path to be the first item on the
>> auto_path which does not begin with '//zipfs:'.  That works on all
>> systems.  But it also means that on macOS the default location for
>> installing Tcllib
>> becomes /Library/Frameworks/Tcl.framework/Versions/X.Y/Resources/Scripts.
>>
>> I am trying to argue that we need a *real* (documented) standard location
>> and that we should actually think hard about what it should be.
>>
>> I am also trying to argue that we should make package installation
>> cleaner and easier.
>>
>> Comment for Schelte:  It if were as easy to install a Tcl package as it
>> is to install a Python or Ruby package, then it would be much easier to
>> declare that useful additions should be extensions rather than part of the
>> core.  But I claim that only an elite subset of Tcl/Tk experts actually
>> know how to successfully install a Tcl/Tk package.  And I claim that there
>> is currently no standard way to do that.
>>
>> - Marc
>>
>> PS I have learned a lot from wiki pages, but only when someone has
>> provided me with a direct link to a specific wiki page.  I don't have much
>> luck finding anyting useful on the wiki by starting at the top, and I
>> suspect that I am not alone in that respect.  So I don't consider the wiki
>> to be real documentation nor a place for a specification of something like
>> what the default paths for installing Tcl packages should be on various
>> operating systems.
>>
>>
>>
>>>
>>> —Kevin
>>>
>>> On Jun 16, 2025, at 12:13 PM, Marc Culler <cul...@gm...> wrote:
>>>
>>> 
>>> Hi Kevin,
>>>
>>> I am not sure that convention makes sense anymore, given that
>>> /usr/bin/tclsh could not load any extension built for a currently supported
>>> version of Tcl and that /usr/bin/wish crashes.  Also the fact that the path
>>> is buried deep in the auto_path suggests that we are not really supporting
>>> it now.  (I realize that different versions of Tcl could be supported in
>>> subdirectories of /Library/Tcl, but I still think that, de facto, we are
>>> not really supporting it.)  Supporting multiple versions is also a feature
>>> of a framework.
>>>
>>> I think that being self-contained is a very good feature of a binary
>>> distribution.  And I think it would be a good thing for Tcl/Tk to once
>>> again be installable by downloading a single .pkg file and clicking on it.
>>> And it would be good for such an installation to be able to add packages
>>> without losing the property of being self-contained.  So I think we should
>>> do what we can to facilitate moving in that direction.
>>>
>>> I note that this sort of installation scheme works well for Python,
>>> which now embeds framework builds of Tcl and Tk within the
>>> Python.framework. (Nested frameworks are allowed and encouraged by Apple,
>>> but not as Resources.)
>>>
>>> - Marc
>>>
>>> On Mon, Jun 16, 2025 at 10:40 AM Kevin Walzer <kw...@54...>
>>> wrote:
>>>
>>>> Marc,
>>>>
>>>> It’s an older convention from the early days of macOS when Tcl/Tk was
>>>> included and actively maintained in the system. The /Library/Tcl path was
>>>> picked up by both the system installation and a locally installed build.
>>>> Same principle applies to Perl, Python etc.
>>>>
>>>> The wiki FAQ I wrote also references this in build instructions for
>>>> extensions:
>>>>
>>>> New Tcl/TkAqua FAQ
>>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/-qHmKle1ibswH8orx3osh8GCWd4hiabuwNDWBn70VcNduYG_EDfT4--yBS8DOPFGut_y_IOMB4fEPkG-XAnHexzJc2TqdCx3D9qST2w4JCNaqE76ZFrkt7NElwHKUzrNpr5N0LaPOVaN6Fm_0dj95xZPpvbujSuYWiVj9lBG8_ZpwqSDCzHqINe1_fZN7q6Rq3yTZaIU9UfkWIXMoAR-SRpiuhiytbsWCUeNjeK0bNTzXi8pKie8etYYMg6HcULsxiRIaLcPRgcZmyDNoomcOzcpP2m5aVCsu0vrsKE2p1ykMYiaLOBIPI31QfY59YPug221kpRzgOGJ9aUfOoC_v0CexUV_IMbQ8oWSntR4ta5ozE7NKH-eyfSizyjzXHXOoS2boizsig>
>>>> wiki.tcl-lang.org
>>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/5BwlY0r0K9DNwUAiGGsZBwzsHWb0MesGVOkR0OdGkoYfgE3j7ZDb4DrKi5x5WgQrJsBKDj0lg32vJUHSim0QUvEJdXVFA0LXGhnnvvFdWYd-R51tGBNOipkh2lRMDj4jGX9GhnGxsoAJGQMa8biLnOaGtS1lIIwCO6ZiaYHwp6SCHeK2-qEjpmDm1f9cxJc2ZJUALm6sln2x8F0JIRXtsLZ-_N0e3OC7ZbDNnzVJTN8JOH-LPxq91VgjNsjsmmoePKNCmamfIqctaY9vuMJcK1aJs8g5wonjIhthoOeu0G1BFVdnkKDrynvL3eINcOGNpVKgtGmGTePl3vG5RaHPKtNeuSxHWG1wHnS-8CX3oycetiARsDfemNUjRTMpDdk5UvLe7DHzzw>
>>>> <favicon.ico>
>>>>
>>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/lxvQ6_aT5r7TcByC5StYaup3Nv8Fn40zD6FfucTZUyTzmvB0gg5B4vr2WuSyFG63uEKCp_TMAmaVVBGLwzhb3s5l8PETMmMhxnSzS8qtrVZ6FxT5fvv3AdAh4iKTpEblSLsMJNQWhf5EDdSEyiyJAO_X_A5NCt_-buiSKU9hjsqrrZ9IAjNEtKL5wXVpeKe30-3nboYyLYIiiVcwz18XDoDLgL7fMTLBWFbxueCUFNwNOk24d3NKvJDp4KbFLO6szups2KR87TxOJFfqUUDeIhtYElooF63MYQyrR3tCs-7Q8L87R4wPp4ZphMLN8wDJiT1WW1umrLkepPBExjs2l0iQHmbRUYb_1v0ZQqOwWBAkPHfEdnkhHgUIESh5cgODABbT_uM2hg>
>>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/tyvp7ZUxHNRTfOsWvImAy8OKkwfsfNFQdIp3uLq_ZFo1ZzkCrMZhhHRtEgqAsdhHFVR0M5Oipep3ZSDzesyrplFPnznfVK4RCBACHOtG0vnIS_ctN_HKcX-SJiyp-ltLaIkm5V8YiXbiwx-Ngj2Eu2d-oiUveiRrpsoUvtWeV0IGR1VaHxrfxatdmDHT8ECUGC8vyNPi4WbeR1etEf1zzfdafVfK0iRWvZo7yMsy0YlFZeLhrom5h9R3hnkplzZnz1nsEbWJxhw2ABc-hIzZ_nF-xONHj2TVB0zCFyQzN0UM2wcY3vqVBAoDYR-4wuwhwvLyLJDeWmaeHSJOL8gNhJAf7RZo16QswzAct9Qucf5aBlApHemtciZJrVFGvdKPiIeEUfi8lA>
>>>>
>>>> —Kevin
>>>>
>>>> On Jun 16, 2025, at 11:17 AM, Marc Culler <cul...@gm...> wrote:
>>>>
>>>> 
>>>> On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer <kw...@54...>
>>>> wrote:
>>>>
>>>>> The canonical installation location for extension packages is
>>>>> /Library/Tcl. They shouldn’t go in the framework although it is supported.
>>>>>
>>>>
>>>> Hi Kevin,
>>>>
>>>> Where do you find that canonical location specified?  And why shouldn't
>>>> they go in the framework?
>>>>
>>>> Using that location seems to destroy one of the great advantages of
>>>> using a framework - namely that all dependencies are contained in the
>>>> framework.  Removing a framework should not involve hunting throughout the
>>>> system for hidden dependencies which should be removed along with the
>>>> framework because they become useless once the framework is gone.
>>>>
>>>> My system does not have a /Library/Tcl directory, nor does it have a
>>>> /Library/Python directory.  (Those two languages get installed as
>>>> frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl
>>>> and /Library/Java.
>>>>
>>>> - Marc
>>>>
>>>>

Re: [TCLCORE] More on TEA packages for macOS

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

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><img width="1" height="1" src="https://fedbdhd.r.bh.d.sendibt3.com/tr/op/MJpZV5DnKeOWbyDCpTy8cxxJSBke-yShUVBCcAi7uDisbUYnPYmfm5MSgxhgL4THDBDNLQZ5JzcF0ERa_ysLEGemdInIGAga45cr108WLnUo3t1WT4bGrEHRnLC_aj0z66NLSfmjkOHlrpckj9gflu3XxRpbWxIbBGcnfst7HYWkWKKzUzbIQ9Dt2o8diZOMRV8Tavtj_VIk4ivxa6vO104aPUhlT48o" style="mso-hide:all"/><div dir="ltr"></div><div dir="ltr">This is correct for the frameworks themselves, but not external packages.&nbsp;</div><div dir="ltr"><br><blockquote type="cite">On Jun 16, 2025, at 3:10 PM, Marc Culler &lt;cul...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Of course we all expect wrong and missing information from AI assistants,&nbsp;and expect different people to get&nbsp;different answers.&nbsp; But I think many people depend on those critters.&nbsp; So it may be relevant to report what google's "AI overview" said when I asked "What is the standard location for a Tcl package on macOS?".</div><div><br></div><div><div class="gmail-nk9vdc" style="flex-grow: 1;"><div class="gmail-Fzsovc gmail-cwYVJe gmail-RJPOee" role="heading" style="animation: none;"><strong>AI Overview</strong></div></div><div class="gmail-nk9vdc"><div class="gmail-QZvcUb"><div><div><div><div><div><div class="gmail-H4fljf" aria-label="About this result" role="button" tabindex="0"><span class="gmail-xC2q7c gmail-z1asCe gmail-SaPW2b" style="height:18px;line-height:18px;width:18px"></span></div></div></div></div></div></div></div></div><div class="gmail-EyBRub gmail-jUja0e gmail-aPfNm"><div class="gmail-Pqkn2e gmail-rNSxBe"><div class="gmail-jloFI gmail-GkDqAd"><div><div><div><div class="gmail-scm-c"><div class="gmail-UxeQfc"><div class="gmail-LT6XE"><div class="gmail-RJPOee gmail-EIJn2" style="animation: none;"><div><div><span></span> <div>  <div> <div class="gmail-qRuFed"><div class="gmail-Zkbeff"><div class="gmail-pWvJNd"><div class="gmail-mZJni"><div class="gmail-Y3BBE"><div style="display:contents">On macOS, Tcl packages can be found in several standard locations, primarily within the system's framework directories</div>.  The main directories where you'll find them are:<span class="gmail-"><span class="gmail-vKEkVd">&nbsp;</span></span></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><div class="gmail-Y3BBE"><span class="gmail-"></span></div><ul class="gmail-U6u95"><li><span class="gmail-T286Pc"><b class="gmail-Yjhzub">/Library/Frameworks</b>: This is the default location for third-party or built-from-source frameworks, including ActiveTcl releases.</span></li><li><span class="gmail-T286Pc"><b class="gmail-Yjhzub">/System/Library/Frameworks</b>:  This directory contains Apple-supplied frameworks that come with macOS. <b class="gmail-Yjhzub">Note:</b> You should generally avoid modifying or deleting files in this directory.</span></li><li><span class="gmail-T286Pc"><b class="gmail-Yjhzub">$HOME/Library/Frameworks</b>: You might also find Tcl and Tk frameworks in your user's Library directory.</span><span class="gmail-"><span class="gmail-vKEkVd">&nbsp;</span></span></li></ul>- Marc</div><div><br></div><div>PS The stupidest&nbsp;part is warning people against modifying files in /System/Library/Frameworks, as if that were even possible.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jun 16, 2025 at 1:36 PM Marc Culler &lt;<a href="mailto:cul...@gm...">cul...@gm...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Jun 16, 2025 at 12:31 PM Kevin Walzer &lt;<a href="mailto:kw...@54..." target="_blank">kw...@54...</a>&gt; wrote:</div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr">You can pass —libdir as a flag to configure to set the install dir.</div></div></blockquote><div><br></div><div>I guess you mean that you can do that when configuring an extension that you build locally?</div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"> I think the default directory is /usr/local if not otherwise defined. Either way, I’m not a fan of putting external stuff in the frameworks.</div></div></blockquote><div><br></div><div>I still don't know why you are not a fan.&nbsp; However, the issue of what should be the default install location actually runs pretty deep at the moment, as I explain below.</div><div><br></div><div>I recently committed a change to the tcllib repository to fix ticket [<a href="https://fedbdhd.r.bh.d.sendibt3.com/tr/cl/LhZ8QeqimXUgr3xhpE5sRa_F2b9dZRaB5hKOtVB6bYmigyHzSvBXo-77hCnUUq9oU-9ieTefRBjRyvLaxTqd-T0ZdvyRJ4LyZ2sQQ2_S6-NJ-0FWIXRLi7tJoCmDLeorZTd_vXgPSdSSzdP5OXJEisXZ3U1sP04CC67EIbz3marLZkQDYzUG6J9U5ng0ydILik92XxUc6Cv7rYUt4ltinkO2jIrpNIvB6MtmMuFeMPwXQW-NyFUV0J93pKV063RgaFAwmLq-nRq6hlNEJdAriRST5E708qOKNchUNAjiKEmhEeArhjAJ1vv7cXq5Dl0" target="_blank">e5f3dfc055</a>], posted by Ashok a year ago, which was reporting that the Tcllib installer does not work "out of the box".&nbsp; That means that the installer script would fail if you used its default install path, although you could edit the path if you happened to know where you wanted to install Tcllib. I think it is pretty clear that the default path for the Tcllib installer **should** be the "standard location" for Tcl packages, whatever that is.&nbsp;</div><div><br></div><div>The reason that the installer script did not work was that it was choosing the zipfs as the install location on Windows and Linux, and the path /Library/Frameworks/Tk.framework/Versions on macOS.&nbsp; It makes no sense to install a package in the zipfs and it also makes no sense to install a pure Tcl package in the Tk framework.&nbsp; Moreover installing it in the Versions directory completely corrupts the structure of the Tk framework.</div><div><br></div><div>The fix was to take the default install path to be the first item on the auto_path which does not begin with '//zipfs:'.&nbsp; That works on all systems.&nbsp; But it also means that on macOS the default location for installing Tcllib becomes&nbsp;/Library/Frameworks/Tcl.framework/Versions/X.Y/Resources/Scripts.</div><div><br></div><div>I am trying to argue that we need a *real* (documented) standard location and that we should actually think hard about what it should be.</div><div><br></div><div>I am also trying to argue that we should make package installation cleaner and easier.</div><div><br></div><div>Comment for Schelte:&nbsp; It if were as easy to install a Tcl package as it is to install a Python or Ruby package, then it would be much easier to declare that useful additions should be extensions rather than part of the core.&nbsp; But I claim that only an elite subset of Tcl/Tk experts actually know how to successfully install a Tcl/Tk package.&nbsp; And I claim that there is currently no standard way to do that.</div><div><br></div><div>- Marc</div><div><br></div><div>PS I have learned a lot from wiki pages, but only when someone has provided me with a direct link to a specific wiki page.&nbsp; I don't have much luck finding anyting useful on the wiki by starting at the top, and I suspect that I am not alone in that respect.&nbsp; So I don't consider the wiki to be real documentation nor a place for a specification of something like what the default paths for installing Tcl packages should be on various operating systems.</div><div><br></div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><br></div><div dir="ltr">—Kevin</div><div dir="ltr"><br><blockquote type="cite">On Jun 16, 2025, at 12:13 PM, Marc Culler &lt;<a href="mailto:cul...@gm..." target="_blank">cul...@gm...</a>&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Hi Kevin,</div><div><br></div><div>I am not sure that convention makes sense anymore, given that /usr/bin/tclsh could not load any extension built for a currently supported version of Tcl and that /usr/bin/wish crashes.&nbsp; Also the fact that the path is buried deep in the auto_path suggests that we are not really supporting it now.&nbsp; (I realize that different versions of Tcl could be supported in subdirectories of /Library/Tcl, but I still think that, de facto, we are not really supporting it.)&nbsp; Supporting multiple versions is also a feature of a framework.</div><div><br></div><div>I think that being self-contained is a very good feature of a binary distribution.&nbsp; And I think it would be a good thing for Tcl/Tk to once again be installable by downloading a single .pkg file and clicking on it.&nbsp; And it would be good for such an installation to be able to add packages without losing the property of being self-contained.&nbsp; So I think we should do what we can to facilitate moving in that direction.</div><div><br></div><div>I note that this sort of installation scheme works well for Python, which now embeds framework builds of Tcl and Tk within the Python.framework. (Nested frameworks are allowed and encouraged by Apple, but not as Resources.)</div><div><br></div><div>- Marc</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 16, 2025 at 10:40 AM Kevin Walzer &lt;<a href="mailto:kw...@54..." target="_blank">kw...@54...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><img width="1" height="1" src="https://fedbdhd.r.tsp1-brevo.net/tr/op/xa8VgqvLmExlO5-JONNIHss6ysMVM1eWnXcAINJD2YKpu3HSpkjmYTo6BPc3p47Jp3o0FkV7ox0n_26J6MLmQ1BF-uVPK7CuzoOy28ZD27hqPzXEeCKJLhsCWc_jSWg7UqDC7g2KH1RJ0P1qMo8V8168IiwHngtT1ZQzSrf1t_oRTkwID00Z8L1C4LW8vfg169wfw2zch1vn" data-unique-identifier=""><div dir="ltr"></div><div dir="ltr">Marc,</div><div dir="ltr"><br></div><div dir="ltr">It’s an older convention from the early days of macOS when Tcl/Tk was included and actively maintained in the system. The /Library/Tcl path was picked up by both the system installation and a locally installed build. Same principle applies to Perl, Python etc. &nbsp;</div><div dir="ltr"><br></div><div dir="ltr">The wiki FAQ I wrote also references this in build instructions for extensions:&nbsp;</div><div dir="ltr"><br></div><div dir="ltr"><div style="display:block"><div style="display:inline-block" role="link"><a style="border-radius:10px;font-family:-apple-system,Helvetica,Arial,sans-serif;display:block;width:300px;overflow:hidden;text-decoration:none" rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/tyvp7ZUxHNRTfOsWvImAy8OKkwfsfNFQdIp3uLq_ZFo1ZzkCrMZhhHRtEgqAsdhHFVR0M5Oipep3ZSDzesyrplFPnznfVK4RCBACHOtG0vnIS_ctN_HKcX-SJiyp-ltLaIkm5V8YiXbiwx-Ngj2Eu2d-oiUveiRrpsoUvtWeV0IGR1VaHxrfxatdmDHT8ECUGC8vyNPi4WbeR1etEf1zzfdafVfK0iRWvZo7yMsy0YlFZeLhrom5h9R3hnkplzZnz1nsEbWJxhw2ABc-hIzZ_nF-xONHj2TVB0zCFyQzN0UM2wcY3vqVBAoDYR-4wuwhwvLyLJDeWmaeHSJOL8gNhJAf7RZo16QswzAct9Qucf5aBlApHemtciZJrVFGvdKPiIeEUfi8lA" dir="ltr" role="button" width="300" target="_blank"><table style="table-layout:fixed;border-collapse:collapse;width:300px;background-color:rgb(161,159,156);font-family:-apple-system,Helvetica,Arial,sans-serif" cellpadding="0" cellspacing="0" border="0" width="300"><tbody><tr><td><table bgcolor="#A19F9C" cellpadding="0" cellspacing="0" width="300" style="table-layout:fixed;font-family:-apple-system,Helvetica,Arial,sans-serif;background-color:rgb(161,159,156)"><tbody><tr><td style="padding:8px 0px"><div style="max-width:100%;margin:0px 16px;overflow:hidden"><div style="font-weight:500;font-size:12px;overflow:hidden;text-overflow:ellipsis;text-align:left"><a rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/-qHmKle1ibswH8orx3osh8GCWd4hiabuwNDWBn70VcNduYG_EDfT4--yBS8DOPFGut_y_IOMB4fEPkG-XAnHexzJc2TqdCx3D9qST2w4JCNaqE76ZFrkt7NElwHKUzrNpr5N0LaPOVaN6Fm_0dj95xZPpvbujSuYWiVj9lBG8_ZpwqSDCzHqINe1_fZN7q6Rq3yTZaIU9UfkWIXMoAR-SRpiuhiytbsWCUeNjeK0bNTzXi8pKie8etYYMg6HcULsxiRIaLcPRgcZmyDNoomcOzcpP2m5aVCsu0vrsKE2p1ykMYiaLOBIPI31QfY59YPug221kpRzgOGJ9aUfOoC_v0CexUV_IMbQ8oWSntR4ta5ozE7NKH-eyfSizyjzXHXOoS2boizsig" style="text-decoration:none" target="_blank"><font color="#FFFFFF" style="color:rgb(255,255,255)">New Tcl/TkAqua FAQ</font></a></div><div style="font-weight:400;font-size:11px;overflow:hidden;text-overflow:ellipsis;text-align:left"><a rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/5BwlY0r0K9DNwUAiGGsZBwzsHWb0MesGVOkR0OdGkoYfgE3j7ZDb4DrKi5x5WgQrJsBKDj0lg32vJUHSim0QUvEJdXVFA0LXGhnnvvFdWYd-R51tGBNOipkh2lRMDj4jGX9GhnGxsoAJGQMa8biLnOaGtS1lIIwCO6ZiaYHwp6SCHeK2-qEjpmDm1f9cxJc2ZJUALm6sln2x8F0JIRXtsLZ-_N0e3OC7ZbDNnzVJTN8JOH-LPxq91VgjNsjsmmoePKNCmamfIqctaY9vuMJcK1aJs8g5wonjIhthoOeu0G1BFVdnkKDrynvL3eINcOGNpVKgtGmGTePl3vG5RaHPKtNeuSxHWG1wHnS-8CX3oycetiARsDfemNUjRTMpDdk5UvLe7DHzzw" style="text-decoration:none" target="_blank"><font color="#FFFFFF" style="color:rgba(235,235,245,0.6)">wiki.tcl-lang.org</font></a></div></div></td><td style="padding:6px 12px 6px 0px" width="30"><a rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/lxvQ6_aT5r7TcByC5StYaup3Nv8Fn40zD6FfucTZUyTzmvB0gg5B4vr2WuSyFG63uEKCp_TMAmaVVBGLwzhb3s5l8PETMmMhxnSzS8qtrVZ6FxT5fvv3AdAh4iKTpEblSLsMJNQWhf5EDdSEyiyJAO_X_A5NCt_-buiSKU9hjsqrrZ9IAjNEtKL5wXVpeKe30-3nboYyLYIiiVcwz18XDoDLgL7fMTLBWFbxueCUFNwNOk24d3NKvJDp4KbFLO6szups2KR87TxOJFfqUUDeIhtYElooF63MYQyrR3tCs-7Q8L87R4wPp4ZphMLN8wDJiT1WW1umrLkepPBExjs2l0iQHmbRUYb_1v0ZQqOwWBAkPHfEdnkhHgUIESh5cgODABbT_uM2hg" target="_blank"><div>&lt;favicon.ico&gt;</div></a></td></tr></tbody></table></td></tr></tbody></table></a></div></div><br></div><div dir="ltr">—Kevin</div><div dir="ltr"><br><blockquote type="cite">On Jun 16, 2025, at 11:17 AM, Marc Culler &lt;<a href="mailto:cul...@gm..." target="_blank">cul...@gm...</a>&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer &lt;<a href="mailto:kw...@54..." target="_blank">kw...@54...</a>&gt; wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><img width="1" height="1" src="https://fedbdhd.r.tsp1-brevo.net/tr/op/0rJGz8a-GZcLwfiuXHRXFKgO1by8S_61Z31B3A4zOaYK-SmjMHR1Lc_ly81ohzIKV3cnJCy7So6l1SZzBfCf2LmDUJuQiZPSMneed-7IuwcL3LrvQctBGg_SxXxyrhdr6eYRbbP1PoZwmHt9_zaOWXN1jz2hySSeoy6az3T32jEJAlkAE_SobNC09ixj9XqsvF309m8ylmXc" data-unique-identifier=""></div>The canonical installation location for extension packages is /Library/Tcl. They shouldn’t go in the framework although it is supported. <br></blockquote><div><br></div><div>Hi Kevin,</div><div><br></div><div>Where do you find that canonical location specified?&nbsp; And why shouldn't they go in the framework?</div><div>&nbsp;</div><div>Using that location seems to destroy one of the great advantages of using a framework - namely that all dependencies are contained in the framework.&nbsp; Removing a framework should not involve&nbsp;hunting throughout the system for hidden dependencies which should be removed along with the framework because they become useless once the framework is gone.</div><div><br></div><div>My system does not have a /Library/Tcl directory, nor does it have a /Library/Python directory.&nbsp; (Those two languages get installed as frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl and /Library/Java.</div><div><br></div><div>- Marc</div></div></div>
</div></blockquote></div>

</blockquote></div>
</div></blockquote></div>

</blockquote></div></div>
</blockquote></div>
</div></blockquote></body></html>

Re: [TCLCORE] More on TEA packages for macOS

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

Of course we all expect wrong and missing information from AI
assistants, and expect different people to get different answers.  But I
think many people depend on those critters.  So it may be relevant to
report what google's "AI overview" said when I asked "What is the standard
location for a Tcl package on macOS?".

*AI Overview*
On macOS, Tcl packages can be found in several standard locations,
primarily within the system's framework directories
. The main directories where you'll find them are:

   - */Library/Frameworks*: This is the default location for third-party or
   built-from-source frameworks, including ActiveTcl releases.
   - */System/Library/Frameworks*: This directory contains Apple-supplied
   frameworks that come with macOS. *Note:* You should generally avoid
   modifying or deleting files in this directory.
   - *$HOME/Library/Frameworks*: You might also find Tcl and Tk frameworks
   in your user's Library directory.

- Marc

PS The stupidest part is warning people against modifying files in
/System/Library/Frameworks, as if that were even possible.

On Mon, Jun 16, 2025 at 1:36 PM Marc Culler <cul...@gm...> wrote:

> On Mon, Jun 16, 2025 at 12:31 PM Kevin Walzer <kw...@54...>
> wrote:
>
> You can pass —libdir as a flag to configure to set the install dir.
>>
>
> I guess you mean that you can do that when configuring an extension that
> you build locally?
>
>
>> I think the default directory is /usr/local if not otherwise defined.
>> Either way, I’m not a fan of putting external stuff in the frameworks.
>>
>
> I still don't know why you are not a fan.  However, the issue of what
> should be the default install location actually runs pretty deep at the
> moment, as I explain below.
>
> I recently committed a change to the tcllib repository to fix ticket [
> e5f3dfc055 <https://core.tcl-lang.org/tcllib/tktview/e5f3dfc055>], posted
> by Ashok a year ago, which was reporting that the Tcllib installer does not
> work "out of the box".  That means that the installer script would fail if
> you used its default install path, although you could edit the path if you
> happened to know where you wanted to install Tcllib. I think it is pretty
> clear that the default path for the Tcllib installer **should** be the
> "standard location" for Tcl packages, whatever that is.
>
> The reason that the installer script did not work was that it was choosing
> the zipfs as the install location on Windows and Linux, and the path
> /Library/Frameworks/Tk.framework/Versions on macOS.  It makes no sense to
> install a package in the zipfs and it also makes no sense to install a pure
> Tcl package in the Tk framework.  Moreover installing it in the Versions
> directory completely corrupts the structure of the Tk framework.
>
> The fix was to take the default install path to be the first item on the
> auto_path which does not begin with '//zipfs:'.  That works on all
> systems.  But it also means that on macOS the default location for
> installing Tcllib
> becomes /Library/Frameworks/Tcl.framework/Versions/X.Y/Resources/Scripts.
>
> I am trying to argue that we need a *real* (documented) standard location
> and that we should actually think hard about what it should be.
>
> I am also trying to argue that we should make package installation cleaner
> and easier.
>
> Comment for Schelte:  It if were as easy to install a Tcl package as it is
> to install a Python or Ruby package, then it would be much easier to
> declare that useful additions should be extensions rather than part of the
> core.  But I claim that only an elite subset of Tcl/Tk experts actually
> know how to successfully install a Tcl/Tk package.  And I claim that there
> is currently no standard way to do that.
>
> - Marc
>
> PS I have learned a lot from wiki pages, but only when someone has
> provided me with a direct link to a specific wiki page.  I don't have much
> luck finding anyting useful on the wiki by starting at the top, and I
> suspect that I am not alone in that respect.  So I don't consider the wiki
> to be real documentation nor a place for a specification of something like
> what the default paths for installing Tcl packages should be on various
> operating systems.
>
>
>
>>
>> —Kevin
>>
>> On Jun 16, 2025, at 12:13 PM, Marc Culler <cul...@gm...> wrote:
>>
>> 
>> Hi Kevin,
>>
>> I am not sure that convention makes sense anymore, given that
>> /usr/bin/tclsh could not load any extension built for a currently supported
>> version of Tcl and that /usr/bin/wish crashes.  Also the fact that the path
>> is buried deep in the auto_path suggests that we are not really supporting
>> it now.  (I realize that different versions of Tcl could be supported in
>> subdirectories of /Library/Tcl, but I still think that, de facto, we are
>> not really supporting it.)  Supporting multiple versions is also a feature
>> of a framework.
>>
>> I think that being self-contained is a very good feature of a binary
>> distribution.  And I think it would be a good thing for Tcl/Tk to once
>> again be installable by downloading a single .pkg file and clicking on it.
>> And it would be good for such an installation to be able to add packages
>> without losing the property of being self-contained.  So I think we should
>> do what we can to facilitate moving in that direction.
>>
>> I note that this sort of installation scheme works well for Python, which
>> now embeds framework builds of Tcl and Tk within the Python.framework.
>> (Nested frameworks are allowed and encouraged by Apple, but not as
>> Resources.)
>>
>> - Marc
>>
>> On Mon, Jun 16, 2025 at 10:40 AM Kevin Walzer <kw...@54...>
>> wrote:
>>
>>> Marc,
>>>
>>> It’s an older convention from the early days of macOS when Tcl/Tk was
>>> included and actively maintained in the system. The /Library/Tcl path was
>>> picked up by both the system installation and a locally installed build.
>>> Same principle applies to Perl, Python etc.
>>>
>>> The wiki FAQ I wrote also references this in build instructions for
>>> extensions:
>>>
>>> New Tcl/TkAqua FAQ
>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/-qHmKle1ibswH8orx3osh8GCWd4hiabuwNDWBn70VcNduYG_EDfT4--yBS8DOPFGut_y_IOMB4fEPkG-XAnHexzJc2TqdCx3D9qST2w4JCNaqE76ZFrkt7NElwHKUzrNpr5N0LaPOVaN6Fm_0dj95xZPpvbujSuYWiVj9lBG8_ZpwqSDCzHqINe1_fZN7q6Rq3yTZaIU9UfkWIXMoAR-SRpiuhiytbsWCUeNjeK0bNTzXi8pKie8etYYMg6HcULsxiRIaLcPRgcZmyDNoomcOzcpP2m5aVCsu0vrsKE2p1ykMYiaLOBIPI31QfY59YPug221kpRzgOGJ9aUfOoC_v0CexUV_IMbQ8oWSntR4ta5ozE7NKH-eyfSizyjzXHXOoS2boizsig>
>>> wiki.tcl-lang.org
>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/5BwlY0r0K9DNwUAiGGsZBwzsHWb0MesGVOkR0OdGkoYfgE3j7ZDb4DrKi5x5WgQrJsBKDj0lg32vJUHSim0QUvEJdXVFA0LXGhnnvvFdWYd-R51tGBNOipkh2lRMDj4jGX9GhnGxsoAJGQMa8biLnOaGtS1lIIwCO6ZiaYHwp6SCHeK2-qEjpmDm1f9cxJc2ZJUALm6sln2x8F0JIRXtsLZ-_N0e3OC7ZbDNnzVJTN8JOH-LPxq91VgjNsjsmmoePKNCmamfIqctaY9vuMJcK1aJs8g5wonjIhthoOeu0G1BFVdnkKDrynvL3eINcOGNpVKgtGmGTePl3vG5RaHPKtNeuSxHWG1wHnS-8CX3oycetiARsDfemNUjRTMpDdk5UvLe7DHzzw>
>>> <favicon.ico>
>>>
>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/lxvQ6_aT5r7TcByC5StYaup3Nv8Fn40zD6FfucTZUyTzmvB0gg5B4vr2WuSyFG63uEKCp_TMAmaVVBGLwzhb3s5l8PETMmMhxnSzS8qtrVZ6FxT5fvv3AdAh4iKTpEblSLsMJNQWhf5EDdSEyiyJAO_X_A5NCt_-buiSKU9hjsqrrZ9IAjNEtKL5wXVpeKe30-3nboYyLYIiiVcwz18XDoDLgL7fMTLBWFbxueCUFNwNOk24d3NKvJDp4KbFLO6szups2KR87TxOJFfqUUDeIhtYElooF63MYQyrR3tCs-7Q8L87R4wPp4ZphMLN8wDJiT1WW1umrLkepPBExjs2l0iQHmbRUYb_1v0ZQqOwWBAkPHfEdnkhHgUIESh5cgODABbT_uM2hg>
>>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/tyvp7ZUxHNRTfOsWvImAy8OKkwfsfNFQdIp3uLq_ZFo1ZzkCrMZhhHRtEgqAsdhHFVR0M5Oipep3ZSDzesyrplFPnznfVK4RCBACHOtG0vnIS_ctN_HKcX-SJiyp-ltLaIkm5V8YiXbiwx-Ngj2Eu2d-oiUveiRrpsoUvtWeV0IGR1VaHxrfxatdmDHT8ECUGC8vyNPi4WbeR1etEf1zzfdafVfK0iRWvZo7yMsy0YlFZeLhrom5h9R3hnkplzZnz1nsEbWJxhw2ABc-hIzZ_nF-xONHj2TVB0zCFyQzN0UM2wcY3vqVBAoDYR-4wuwhwvLyLJDeWmaeHSJOL8gNhJAf7RZo16QswzAct9Qucf5aBlApHemtciZJrVFGvdKPiIeEUfi8lA>
>>>
>>> —Kevin
>>>
>>> On Jun 16, 2025, at 11:17 AM, Marc Culler <cul...@gm...> wrote:
>>>
>>> 
>>> On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer <kw...@54...>
>>> wrote:
>>>
>>>> The canonical installation location for extension packages is
>>>> /Library/Tcl. They shouldn’t go in the framework although it is supported.
>>>>
>>>
>>> Hi Kevin,
>>>
>>> Where do you find that canonical location specified?  And why shouldn't
>>> they go in the framework?
>>>
>>> Using that location seems to destroy one of the great advantages of
>>> using a framework - namely that all dependencies are contained in the
>>> framework.  Removing a framework should not involve hunting throughout the
>>> system for hidden dependencies which should be removed along with the
>>> framework because they become useless once the framework is gone.
>>>
>>> My system does not have a /Library/Tcl directory, nor does it have a
>>> /Library/Python directory.  (Those two languages get installed as
>>> frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl
>>> and /Library/Java.
>>>
>>> - Marc
>>>
>>>

Re: [TCLCORE] More on TEA packages for macOS

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

On Mon, Jun 16, 2025 at 12:31 PM Kevin Walzer <kw...@54...>
wrote:

You can pass —libdir as a flag to configure to set the install dir.
>

I guess you mean that you can do that when configuring an extension that
you build locally?


> I think the default directory is /usr/local if not otherwise defined.
> Either way, I’m not a fan of putting external stuff in the frameworks.
>

I still don't know why you are not a fan.  However, the issue of what
should be the default install location actually runs pretty deep at the
moment, as I explain below.

I recently committed a change to the tcllib repository to fix ticket [
e5f3dfc055 <https://core.tcl-lang.org/tcllib/tktview/e5f3dfc055>], posted
by Ashok a year ago, which was reporting that the Tcllib installer does not
work "out of the box".  That means that the installer script would fail if
you used its default install path, although you could edit the path if you
happened to know where you wanted to install Tcllib. I think it is pretty
clear that the default path for the Tcllib installer **should** be the
"standard location" for Tcl packages, whatever that is.

The reason that the installer script did not work was that it was choosing
the zipfs as the install location on Windows and Linux, and the path
/Library/Frameworks/Tk.framework/Versions on macOS.  It makes no sense to
install a package in the zipfs and it also makes no sense to install a pure
Tcl package in the Tk framework.  Moreover installing it in the Versions
directory completely corrupts the structure of the Tk framework.

The fix was to take the default install path to be the first item on the
auto_path which does not begin with '//zipfs:'.  That works on all
systems.  But it also means that on macOS the default location for
installing Tcllib
becomes /Library/Frameworks/Tcl.framework/Versions/X.Y/Resources/Scripts.

I am trying to argue that we need a *real* (documented) standard location
and that we should actually think hard about what it should be.

I am also trying to argue that we should make package installation cleaner
and easier.

Comment for Schelte:  It if were as easy to install a Tcl package as it is
to install a Python or Ruby package, then it would be much easier to
declare that useful additions should be extensions rather than part of the
core.  But I claim that only an elite subset of Tcl/Tk experts actually
know how to successfully install a Tcl/Tk package.  And I claim that there
is currently no standard way to do that.

- Marc

PS I have learned a lot from wiki pages, but only when someone has provided
me with a direct link to a specific wiki page.  I don't have much luck
finding anyting useful on the wiki by starting at the top, and I suspect
that I am not alone in that respect.  So I don't consider the wiki to be
real documentation nor a place for a specification of something like what
the default paths for installing Tcl packages should be on various
operating systems.



>
> —Kevin
>
> On Jun 16, 2025, at 12:13 PM, Marc Culler <cul...@gm...> wrote:
>
> 
> Hi Kevin,
>
> I am not sure that convention makes sense anymore, given that
> /usr/bin/tclsh could not load any extension built for a currently supported
> version of Tcl and that /usr/bin/wish crashes.  Also the fact that the path
> is buried deep in the auto_path suggests that we are not really supporting
> it now.  (I realize that different versions of Tcl could be supported in
> subdirectories of /Library/Tcl, but I still think that, de facto, we are
> not really supporting it.)  Supporting multiple versions is also a feature
> of a framework.
>
> I think that being self-contained is a very good feature of a binary
> distribution.  And I think it would be a good thing for Tcl/Tk to once
> again be installable by downloading a single .pkg file and clicking on it.
> And it would be good for such an installation to be able to add packages
> without losing the property of being self-contained.  So I think we should
> do what we can to facilitate moving in that direction.
>
> I note that this sort of installation scheme works well for Python, which
> now embeds framework builds of Tcl and Tk within the Python.framework.
> (Nested frameworks are allowed and encouraged by Apple, but not as
> Resources.)
>
> - Marc
>
> On Mon, Jun 16, 2025 at 10:40 AM Kevin Walzer <kw...@54...>
> wrote:
>
>> Marc,
>>
>> It’s an older convention from the early days of macOS when Tcl/Tk was
>> included and actively maintained in the system. The /Library/Tcl path was
>> picked up by both the system installation and a locally installed build.
>> Same principle applies to Perl, Python etc.
>>
>> The wiki FAQ I wrote also references this in build instructions for
>> extensions:
>>
>> New Tcl/TkAqua FAQ
>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/-qHmKle1ibswH8orx3osh8GCWd4hiabuwNDWBn70VcNduYG_EDfT4--yBS8DOPFGut_y_IOMB4fEPkG-XAnHexzJc2TqdCx3D9qST2w4JCNaqE76ZFrkt7NElwHKUzrNpr5N0LaPOVaN6Fm_0dj95xZPpvbujSuYWiVj9lBG8_ZpwqSDCzHqINe1_fZN7q6Rq3yTZaIU9UfkWIXMoAR-SRpiuhiytbsWCUeNjeK0bNTzXi8pKie8etYYMg6HcULsxiRIaLcPRgcZmyDNoomcOzcpP2m5aVCsu0vrsKE2p1ykMYiaLOBIPI31QfY59YPug221kpRzgOGJ9aUfOoC_v0CexUV_IMbQ8oWSntR4ta5ozE7NKH-eyfSizyjzXHXOoS2boizsig>
>> wiki.tcl-lang.org
>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/5BwlY0r0K9DNwUAiGGsZBwzsHWb0MesGVOkR0OdGkoYfgE3j7ZDb4DrKi5x5WgQrJsBKDj0lg32vJUHSim0QUvEJdXVFA0LXGhnnvvFdWYd-R51tGBNOipkh2lRMDj4jGX9GhnGxsoAJGQMa8biLnOaGtS1lIIwCO6ZiaYHwp6SCHeK2-qEjpmDm1f9cxJc2ZJUALm6sln2x8F0JIRXtsLZ-_N0e3OC7ZbDNnzVJTN8JOH-LPxq91VgjNsjsmmoePKNCmamfIqctaY9vuMJcK1aJs8g5wonjIhthoOeu0G1BFVdnkKDrynvL3eINcOGNpVKgtGmGTePl3vG5RaHPKtNeuSxHWG1wHnS-8CX3oycetiARsDfemNUjRTMpDdk5UvLe7DHzzw>
>> <favicon.ico>
>>
>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/lxvQ6_aT5r7TcByC5StYaup3Nv8Fn40zD6FfucTZUyTzmvB0gg5B4vr2WuSyFG63uEKCp_TMAmaVVBGLwzhb3s5l8PETMmMhxnSzS8qtrVZ6FxT5fvv3AdAh4iKTpEblSLsMJNQWhf5EDdSEyiyJAO_X_A5NCt_-buiSKU9hjsqrrZ9IAjNEtKL5wXVpeKe30-3nboYyLYIiiVcwz18XDoDLgL7fMTLBWFbxueCUFNwNOk24d3NKvJDp4KbFLO6szups2KR87TxOJFfqUUDeIhtYElooF63MYQyrR3tCs-7Q8L87R4wPp4ZphMLN8wDJiT1WW1umrLkepPBExjs2l0iQHmbRUYb_1v0ZQqOwWBAkPHfEdnkhHgUIESh5cgODABbT_uM2hg>
>> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/tyvp7ZUxHNRTfOsWvImAy8OKkwfsfNFQdIp3uLq_ZFo1ZzkCrMZhhHRtEgqAsdhHFVR0M5Oipep3ZSDzesyrplFPnznfVK4RCBACHOtG0vnIS_ctN_HKcX-SJiyp-ltLaIkm5V8YiXbiwx-Ngj2Eu2d-oiUveiRrpsoUvtWeV0IGR1VaHxrfxatdmDHT8ECUGC8vyNPi4WbeR1etEf1zzfdafVfK0iRWvZo7yMsy0YlFZeLhrom5h9R3hnkplzZnz1nsEbWJxhw2ABc-hIzZ_nF-xONHj2TVB0zCFyQzN0UM2wcY3vqVBAoDYR-4wuwhwvLyLJDeWmaeHSJOL8gNhJAf7RZo16QswzAct9Qucf5aBlApHemtciZJrVFGvdKPiIeEUfi8lA>
>>
>> —Kevin
>>
>> On Jun 16, 2025, at 11:17 AM, Marc Culler <cul...@gm...> wrote:
>>
>> 
>> On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer <kw...@54...>
>> wrote:
>>
>>> The canonical installation location for extension packages is
>>> /Library/Tcl. They shouldn’t go in the framework although it is supported.
>>>
>>
>> Hi Kevin,
>>
>> Where do you find that canonical location specified?  And why shouldn't
>> they go in the framework?
>>
>> Using that location seems to destroy one of the great advantages of using
>> a framework - namely that all dependencies are contained in the framework.
>> Removing a framework should not involve hunting throughout the system for
>> hidden dependencies which should be removed along with the framework
>> because they become useless once the framework is gone.
>>
>> My system does not have a /Library/Tcl directory, nor does it have a
>> /Library/Python directory.  (Those two languages get installed as
>> frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl
>> and /Library/Java.
>>
>> - Marc
>>
>>

Re: [TCLCORE] More on TEA packages for macOS

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

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><img width="1" height="1" src="https://fedbdhd.r.bh.d.sendibt3.com/tr/op/HlFSLVMbTqXRTQofhhbSwty-Og3w7cLdiFl7qfp-BtGffzKJPhI4m10-YVaPJJ37JwBri4UgTmidtKoqytW2fwDYdA45LpqQ9FtwjibW_m8q1CDYZjlred9Jvk99ZE3iDlr0WVOTOfIKHG9DkC8VW4KF-_s9CrXxrjzLO7HnbE_plsxN8hGusJwJat9M2uqruAI_98HFNUUYvHnAN-jYKzi7uF0pZOCj" style="mso-hide:all"/><div dir="ltr"></div><div dir="ltr">Marc,</div><div dir="ltr"><br></div><div dir="ltr">You can pass —libdir as a flag to configure to set the install dir. I think the default directory is /usr/local if not otherwise defined. Either way, I’m not a fan of putting external stuff in the frameworks.</div><div dir="ltr"><br></div><div dir="ltr">—Kevin</div><div dir="ltr"><br><blockquote type="cite">On Jun 16, 2025, at 12:13 PM, Marc Culler &lt;cul...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>Hi Kevin,</div><div><br></div><div>I am not sure that convention makes sense anymore, given that /usr/bin/tclsh could not load any extension built for a currently supported version of Tcl and that /usr/bin/wish crashes.&nbsp; Also the fact that the path is buried deep in the auto_path suggests that we are not really supporting it now.&nbsp; (I realize that different versions of Tcl could be supported in subdirectories of /Library/Tcl, but I still think that, de facto, we are not really supporting it.)&nbsp; Supporting multiple versions is also a feature of a framework.</div><div><br></div><div>I think that being self-contained is a very good feature of a binary distribution.&nbsp; And I think it would be a good thing for Tcl/Tk to once again be installable by downloading a single .pkg file and clicking on it.&nbsp; And it would be good for such an installation to be able to add packages without losing the property of being self-contained.&nbsp; So I think we should do what we can to facilitate moving in that direction.</div><div><br></div><div>I note that this sort of installation scheme works well for Python, which now embeds framework builds of Tcl and Tk within the Python.framework. (Nested frameworks are allowed and encouraged by Apple, but not as Resources.)</div><div><br></div><div>- Marc</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Jun 16, 2025 at 10:40 AM Kevin Walzer &lt;<a href="mailto:kw...@54...">kw...@54...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><img width="1" height="1" src="https://fedbdhd.r.tsp1-brevo.net/tr/op/xa8VgqvLmExlO5-JONNIHss6ysMVM1eWnXcAINJD2YKpu3HSpkjmYTo6BPc3p47Jp3o0FkV7ox0n_26J6MLmQ1BF-uVPK7CuzoOy28ZD27hqPzXEeCKJLhsCWc_jSWg7UqDC7g2KH1RJ0P1qMo8V8168IiwHngtT1ZQzSrf1t_oRTkwID00Z8L1C4LW8vfg169wfw2zch1vn" data-unique-identifier=""><div dir="ltr"></div><div dir="ltr">Marc,</div><div dir="ltr"><br></div><div dir="ltr">It’s an older convention from the early days of macOS when Tcl/Tk was included and actively maintained in the system. The /Library/Tcl path was picked up by both the system installation and a locally installed build. Same principle applies to Perl, Python etc. &nbsp;</div><div dir="ltr"><br></div><div dir="ltr">The wiki FAQ I wrote also references this in build instructions for extensions:&nbsp;</div><div dir="ltr"><br></div><div dir="ltr"><div style="display:block"><div style="display:inline-block" role="link"><a style="border-radius:10px;font-family:-apple-system,Helvetica,Arial,sans-serif;display:block;width:300px;overflow:hidden;text-decoration:none" rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/tyvp7ZUxHNRTfOsWvImAy8OKkwfsfNFQdIp3uLq_ZFo1ZzkCrMZhhHRtEgqAsdhHFVR0M5Oipep3ZSDzesyrplFPnznfVK4RCBACHOtG0vnIS_ctN_HKcX-SJiyp-ltLaIkm5V8YiXbiwx-Ngj2Eu2d-oiUveiRrpsoUvtWeV0IGR1VaHxrfxatdmDHT8ECUGC8vyNPi4WbeR1etEf1zzfdafVfK0iRWvZo7yMsy0YlFZeLhrom5h9R3hnkplzZnz1nsEbWJxhw2ABc-hIzZ_nF-xONHj2TVB0zCFyQzN0UM2wcY3vqVBAoDYR-4wuwhwvLyLJDeWmaeHSJOL8gNhJAf7RZo16QswzAct9Qucf5aBlApHemtciZJrVFGvdKPiIeEUfi8lA" dir="ltr" role="button" width="300" target="_blank"><table style="table-layout:fixed;border-collapse:collapse;width:300px;background-color:rgb(161,159,156);font-family:-apple-system,Helvetica,Arial,sans-serif" cellpadding="0" cellspacing="0" border="0" width="300"><tbody><tr><td><table bgcolor="#A19F9C" cellpadding="0" cellspacing="0" width="300" style="table-layout:fixed;font-family:-apple-system,Helvetica,Arial,sans-serif;background-color:rgb(161,159,156)"><tbody><tr><td style="padding:8px 0px"><div style="max-width:100%;margin:0px 16px;overflow:hidden"><div style="font-weight:500;font-size:12px;overflow:hidden;text-overflow:ellipsis;text-align:left"><a rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/-qHmKle1ibswH8orx3osh8GCWd4hiabuwNDWBn70VcNduYG_EDfT4--yBS8DOPFGut_y_IOMB4fEPkG-XAnHexzJc2TqdCx3D9qST2w4JCNaqE76ZFrkt7NElwHKUzrNpr5N0LaPOVaN6Fm_0dj95xZPpvbujSuYWiVj9lBG8_ZpwqSDCzHqINe1_fZN7q6Rq3yTZaIU9UfkWIXMoAR-SRpiuhiytbsWCUeNjeK0bNTzXi8pKie8etYYMg6HcULsxiRIaLcPRgcZmyDNoomcOzcpP2m5aVCsu0vrsKE2p1ykMYiaLOBIPI31QfY59YPug221kpRzgOGJ9aUfOoC_v0CexUV_IMbQ8oWSntR4ta5ozE7NKH-eyfSizyjzXHXOoS2boizsig" style="text-decoration:none" target="_blank"><font color="#FFFFFF" style="color:rgb(255,255,255)">New Tcl/TkAqua FAQ</font></a></div><div style="font-weight:400;font-size:11px;overflow:hidden;text-overflow:ellipsis;text-align:left"><a rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/5BwlY0r0K9DNwUAiGGsZBwzsHWb0MesGVOkR0OdGkoYfgE3j7ZDb4DrKi5x5WgQrJsBKDj0lg32vJUHSim0QUvEJdXVFA0LXGhnnvvFdWYd-R51tGBNOipkh2lRMDj4jGX9GhnGxsoAJGQMa8biLnOaGtS1lIIwCO6ZiaYHwp6SCHeK2-qEjpmDm1f9cxJc2ZJUALm6sln2x8F0JIRXtsLZ-_N0e3OC7ZbDNnzVJTN8JOH-LPxq91VgjNsjsmmoePKNCmamfIqctaY9vuMJcK1aJs8g5wonjIhthoOeu0G1BFVdnkKDrynvL3eINcOGNpVKgtGmGTePl3vG5RaHPKtNeuSxHWG1wHnS-8CX3oycetiARsDfemNUjRTMpDdk5UvLe7DHzzw" style="text-decoration:none" target="_blank"><font color="#FFFFFF" style="color:rgba(235,235,245,0.6)">wiki.tcl-lang.org</font></a></div></div></td><td style="padding:6px 12px 6px 0px" width="30"><a rel="nofollow" href="https://fedbdhd.r.tsp1-brevo.net/tr/cl/lxvQ6_aT5r7TcByC5StYaup3Nv8Fn40zD6FfucTZUyTzmvB0gg5B4vr2WuSyFG63uEKCp_TMAmaVVBGLwzhb3s5l8PETMmMhxnSzS8qtrVZ6FxT5fvv3AdAh4iKTpEblSLsMJNQWhf5EDdSEyiyJAO_X_A5NCt_-buiSKU9hjsqrrZ9IAjNEtKL5wXVpeKe30-3nboYyLYIiiVcwz18XDoDLgL7fMTLBWFbxueCUFNwNOk24d3NKvJDp4KbFLO6szups2KR87TxOJFfqUUDeIhtYElooF63MYQyrR3tCs-7Q8L87R4wPp4ZphMLN8wDJiT1WW1umrLkepPBExjs2l0iQHmbRUYb_1v0ZQqOwWBAkPHfEdnkhHgUIESh5cgODABbT_uM2hg" target="_blank"><div>&lt;favicon.ico&gt;</div></a></td></tr></tbody></table></td></tr></tbody></table></a></div></div><br></div><div dir="ltr">—Kevin</div><div dir="ltr"><br><blockquote type="cite">On Jun 16, 2025, at 11:17 AM, Marc Culler &lt;<a href="mailto:cul...@gm..." target="_blank">cul...@gm...</a>&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer &lt;<a href="mailto:kw...@54..." target="_blank">kw...@54...</a>&gt; wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><img width="1" height="1" src="https://fedbdhd.r.tsp1-brevo.net/tr/op/0rJGz8a-GZcLwfiuXHRXFKgO1by8S_61Z31B3A4zOaYK-SmjMHR1Lc_ly81ohzIKV3cnJCy7So6l1SZzBfCf2LmDUJuQiZPSMneed-7IuwcL3LrvQctBGg_SxXxyrhdr6eYRbbP1PoZwmHt9_zaOWXN1jz2hySSeoy6az3T32jEJAlkAE_SobNC09ixj9XqsvF309m8ylmXc" data-unique-identifier=""></div>The canonical installation location for extension packages is /Library/Tcl. They shouldn’t go in the framework although it is supported. <br></blockquote><div><br></div><div>Hi Kevin,</div><div><br></div><div>Where do you find that canonical location specified?&nbsp; And why shouldn't they go in the framework?</div><div>&nbsp;</div><div>Using that location seems to destroy one of the great advantages of using a framework - namely that all dependencies are contained in the framework.&nbsp; Removing a framework should not involve&nbsp;hunting throughout the system for hidden dependencies which should be removed along with the framework because they become useless once the framework is gone.</div><div><br></div><div>My system does not have a /Library/Tcl directory, nor does it have a /Library/Python directory.&nbsp; (Those two languages get installed as frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl and /Library/Java.</div><div><br></div><div>- Marc</div></div></div>
</div></blockquote></div>

</blockquote></div>
</div></blockquote></body></html>

Re: [TCLCORE] More on TEA packages for macOS

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

Hi Kevin,

I am not sure that convention makes sense anymore, given that
/usr/bin/tclsh could not load any extension built for a currently supported
version of Tcl and that /usr/bin/wish crashes.  Also the fact that the path
is buried deep in the auto_path suggests that we are not really supporting
it now.  (I realize that different versions of Tcl could be supported in
subdirectories of /Library/Tcl, but I still think that, de facto, we are
not really supporting it.)  Supporting multiple versions is also a feature
of a framework.

I think that being self-contained is a very good feature of a binary
distribution.  And I think it would be a good thing for Tcl/Tk to once
again be installable by downloading a single .pkg file and clicking on it.
And it would be good for such an installation to be able to add packages
without losing the property of being self-contained.  So I think we should
do what we can to facilitate moving in that direction.

I note that this sort of installation scheme works well for Python, which
now embeds framework builds of Tcl and Tk within the Python.framework.
(Nested frameworks are allowed and encouraged by Apple, but not as
Resources.)

- Marc

On Mon, Jun 16, 2025 at 10:40 AM Kevin Walzer <kw...@54...>
wrote:

> Marc,
>
> It’s an older convention from the early days of macOS when Tcl/Tk was
> included and actively maintained in the system. The /Library/Tcl path was
> picked up by both the system installation and a locally installed build.
> Same principle applies to Perl, Python etc.
>
> The wiki FAQ I wrote also references this in build instructions for
> extensions:
>
> New Tcl/TkAqua FAQ
> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/-qHmKle1ibswH8orx3osh8GCWd4hiabuwNDWBn70VcNduYG_EDfT4--yBS8DOPFGut_y_IOMB4fEPkG-XAnHexzJc2TqdCx3D9qST2w4JCNaqE76ZFrkt7NElwHKUzrNpr5N0LaPOVaN6Fm_0dj95xZPpvbujSuYWiVj9lBG8_ZpwqSDCzHqINe1_fZN7q6Rq3yTZaIU9UfkWIXMoAR-SRpiuhiytbsWCUeNjeK0bNTzXi8pKie8etYYMg6HcULsxiRIaLcPRgcZmyDNoomcOzcpP2m5aVCsu0vrsKE2p1ykMYiaLOBIPI31QfY59YPug221kpRzgOGJ9aUfOoC_v0CexUV_IMbQ8oWSntR4ta5ozE7NKH-eyfSizyjzXHXOoS2boizsig>
> wiki.tcl-lang.org
> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/5BwlY0r0K9DNwUAiGGsZBwzsHWb0MesGVOkR0OdGkoYfgE3j7ZDb4DrKi5x5WgQrJsBKDj0lg32vJUHSim0QUvEJdXVFA0LXGhnnvvFdWYd-R51tGBNOipkh2lRMDj4jGX9GhnGxsoAJGQMa8biLnOaGtS1lIIwCO6ZiaYHwp6SCHeK2-qEjpmDm1f9cxJc2ZJUALm6sln2x8F0JIRXtsLZ-_N0e3OC7ZbDNnzVJTN8JOH-LPxq91VgjNsjsmmoePKNCmamfIqctaY9vuMJcK1aJs8g5wonjIhthoOeu0G1BFVdnkKDrynvL3eINcOGNpVKgtGmGTePl3vG5RaHPKtNeuSxHWG1wHnS-8CX3oycetiARsDfemNUjRTMpDdk5UvLe7DHzzw>
> [image: favicon.ico]
> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/lxvQ6_aT5r7TcByC5StYaup3Nv8Fn40zD6FfucTZUyTzmvB0gg5B4vr2WuSyFG63uEKCp_TMAmaVVBGLwzhb3s5l8PETMmMhxnSzS8qtrVZ6FxT5fvv3AdAh4iKTpEblSLsMJNQWhf5EDdSEyiyJAO_X_A5NCt_-buiSKU9hjsqrrZ9IAjNEtKL5wXVpeKe30-3nboYyLYIiiVcwz18XDoDLgL7fMTLBWFbxueCUFNwNOk24d3NKvJDp4KbFLO6szups2KR87TxOJFfqUUDeIhtYElooF63MYQyrR3tCs-7Q8L87R4wPp4ZphMLN8wDJiT1WW1umrLkepPBExjs2l0iQHmbRUYb_1v0ZQqOwWBAkPHfEdnkhHgUIESh5cgODABbT_uM2hg>
> <https://fedbdhd.r.tsp1-brevo.net/tr/cl/tyvp7ZUxHNRTfOsWvImAy8OKkwfsfNFQdIp3uLq_ZFo1ZzkCrMZhhHRtEgqAsdhHFVR0M5Oipep3ZSDzesyrplFPnznfVK4RCBACHOtG0vnIS_ctN_HKcX-SJiyp-ltLaIkm5V8YiXbiwx-Ngj2Eu2d-oiUveiRrpsoUvtWeV0IGR1VaHxrfxatdmDHT8ECUGC8vyNPi4WbeR1etEf1zzfdafVfK0iRWvZo7yMsy0YlFZeLhrom5h9R3hnkplzZnz1nsEbWJxhw2ABc-hIzZ_nF-xONHj2TVB0zCFyQzN0UM2wcY3vqVBAoDYR-4wuwhwvLyLJDeWmaeHSJOL8gNhJAf7RZo16QswzAct9Qucf5aBlApHemtciZJrVFGvdKPiIeEUfi8lA>
>
> —Kevin
>
> On Jun 16, 2025, at 11:17 AM, Marc Culler <cul...@gm...> wrote:
>
> 
> On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer <kw...@54...>
> wrote:
>
>> The canonical installation location for extension packages is
>> /Library/Tcl. They shouldn’t go in the framework although it is supported.
>>
>
> Hi Kevin,
>
> Where do you find that canonical location specified?  And why shouldn't
> they go in the framework?
>
> Using that location seems to destroy one of the great advantages of using
> a framework - namely that all dependencies are contained in the framework.
> Removing a framework should not involve hunting throughout the system for
> hidden dependencies which should be removed along with the framework
> because they become useless once the framework is gone.
>
> My system does not have a /Library/Tcl directory, nor does it have a
> /Library/Python directory.  (Those two languages get installed as
> frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl
> and /Library/Java.
>
> - Marc
>
>

Re: [TCLCORE] More on TEA packages for macOS

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

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><img width="1" height="1" src="https://fedbdhd.r.af.d.sendibt2.com/tr/op/o_2sUSHBd-gHy8JA1Kzsnhx0AbIg5SfE0G1pE5nX-e7kaB8WWxqObkB7bSxhJ_wyWDY6HjtXPbgJA0gx4b9ViOvC5wpWG-cRP7bZpZ5fgGv452ZOQ7kbOQts7YG0nkUY6CP6uvLFIzWw-it-Rds5eCiqE4miNzO3oVNn-wYvlcLnP3hwOU-kfJQ5DnrYx4lYJc8w2oDvr-uq5z_Zwzo5AYd8_yRCjZzj" style="mso-hide:all"/><div dir="ltr"></div><div dir="ltr">Marc,</div><div dir="ltr"><br></div><div dir="ltr">It’s an older convention from the early days of macOS when Tcl/Tk was included and actively maintained in the system. The /Library/Tcl path was picked up by both the system installation and a locally installed build. Same principle applies to Perl, Python etc. &nbsp;</div><div dir="ltr"><br></div><div dir="ltr">The wiki FAQ I wrote also references this in build instructions for extensions:&nbsp;</div><div dir="ltr"><br></div><div dir="ltr"><div style="display: block;" class=""><div style="-webkit-user-select: all; -webkit-user-drag: element; display: inline-block;" class="apple-rich-link" draggable="true" role="link" data-url="https://wiki.tcl-lang.org/page/New+Tcl%2FTkAqua+FAQ#6750c6b3086fb0aa6ce057ec7f101d06bd7ca242075c233f54c38591e1f3502d"><a style="border-radius:10px;font-family:-apple-system, Helvetica, Arial, sans-serif;display:block;-webkit-user-select:none;width:300px;user-select:none;-webkit-user-modify:read-only;user-modify:read-only;overflow:hidden;text-decoration:none;" class="lp-rich-link" rel="nofollow" href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/1ft9tLulb5VMtCeNNS7itGeuWDQ88w1U9HyIKwv6QLGHxhkh1SSJWLmzA-9QL1Ge0waMMMyFgjkTh2hLtTHRL1crs8ol9p1KotIsuH764BhCoW_WdoHlH3tBx1ySt51LM-vsGbfH5crtGhAhS4mgaUdtIGp_YFoMOo6-gW2E2On7gt6XDKwVQG6nw-xZLuOzMB6syLaGFI6CLDBJgdfs-Po43TxcOdnG0lzN8cYgDChapC53NeItngqIMUxSNCdlP-ovX2xiwiZD34xT11neJ63AzB94zjETLtSiM_RkZhakINoim991lVgcItXUYRnJWjOmIXDWgNECq3h7vx1e1YONHG6ywZkobaA-66mQNi5Lzm5L-fmPmYRYaQejnRAEzlpr4IINvHtnxecoopRrTcR8teG95g" dir="ltr" role="button" draggable="false" width="300"><table style="table-layout:fixed;border-collapse:collapse;width:300px;background-color:#A19F9C;font-family:-apple-system, Helvetica, Arial, sans-serif;" class="lp-rich-link-emailBaseTable" cellpadding="0" cellspacing="0" border="0" width="300"><tbody><tr><td vertical-align="center"><table bgcolor="#A19F9C" cellpadding="0" cellspacing="0" width="300" style="table-layout:fixed;font-family:-apple-system, Helvetica, Arial, sans-serif;background-color:rgba(161, 159, 156, 1);-apple-color-filter:initial;" class="lp-rich-link-captionBar"><tbody><tr><td style="padding:8px 0px 8px 0px;" class="lp-rich-link-captionBar-textStackItem"><div style="max-width:100%;margin:0px 16px 0px 16px;overflow:hidden;" class="lp-rich-link-captionBar-textStack"><div style="word-wrap:break-word;font-weight:500;font-size:12px;overflow:hidden;text-overflow:ellipsis;text-align:left;" class="lp-rich-link-captionBar-textStack-topCaption-leading"><a rel="nofollow" href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/g1LFEPqnCrFbQjRfcqRo6CIklb44r9JoBpYB3zUoHVZh81pSe28plhESI0S4YntjU8WehJheBEidnkSwSLije1wqvpX7KcGmtPCwU7c7ah3JnIoHmjHHFya_k3RGfZQQid-HFx632ZJ0tMzogAR5PdNbF__LuxYNpe5P_YApcM-vvUvO0jrUwVBVKNWEasFp3SqTPUNxMFxhzib2FPk5uN2xKHDMGSKS4vTrySUAT3ZB9-i-1uK8uFzU1DSkDyZ70akCy0dBSgcd7sXNXDO07J3s1-8bnZSfQGV6QvuqMGdtJ0vaG2op9xeANQjH8BMYm2FuWO3RSEkCLGaA_SHtzAZtDO3iZXf6tZvD2DwngdN9ab6X3r0r13ufQeBAFC-WNk48azyVDwAFct7i8JvR2ygVE1LGWA" style="text-decoration: none" draggable="false"><font color="#FFFFFF" style="color: rgba(255, 255, 255, 1);">New Tcl/TkAqua FAQ</font></a></div><div style="word-wrap:break-word;font-weight:400;font-size:11px;overflow:hidden;text-overflow:ellipsis;text-align:left;" class="lp-rich-link-captionBar-textStack-bottomCaption-leading"><a rel="nofollow" href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/6D58jhCtbSO1_0QevgACukvYsjN4mKvqeaFEDuSpeJg7TwKoLGFjE7meklt66ocdg-m0xUiTrdH31Ki6UcXCaFssIEcFZaGHN2mLe42kqnpwaOlBKtkEmX71gvGYyrDxf2LAAtIy3LtrAZmLLvYViVzWirzq-YcM3X9-AJ_SmqFneLfm0tjR4x3umaj8xO1oQbuZ_6zhvuRqSVt4weRZ6Z_kOxETUatFZ96kdKJBHn6_Bn9RtpW21SCKyuZw8_NFFP2OVhW2JFz5TWU9FmyJJVkk-WQQ-H8lh6577gYeVgxGT1qEGX539cuRdwb3uGrWC0ZMIJwyFUIfEL48Qny8zY5kb3umGmCmXct1J1eVTJaKsDQ97QijA9Bw-1e0WiQoQ51SUzESY9GMYr6cCHeSYWyh16ZYSA" style="text-decoration: none" draggable="false"><font color="#FFFFFF" style="color: rgba(235, 235, 245, 0.6);">wiki.tcl-lang.org</font></a></div></div></td><td style="padding:6px 12px 6px 0px;" class="lp-rich-link-captionBar-rightIconItem" width="30"><a rel="nofollow" href="https://fedbdhd.r.af.d.sendibt2.com/tr/cl/Vn-GEWluY9N2aUfSyg1ERXYktdLcZonZ9RMKOKP25bKKIosnYrBolTLpPbr-MbqdrMRWjLh3BDRtBvPqcxX-2WhBhWBmNvWk2mUORPpKsrXoXybTuJo1dXX5CGEGo7QVToQcFowfTnS2a8xGqe0uBwoOFxLfNkxbAJjfliAsWDgcsUbk8pOUfYO3bR5X3aCuicHitsWVhtzW4YSjl9S0ifaXVCbzUfNhJoDOGvls1aH6_9qXGrfbekG-L_v9Zblwrgi62K7zsFBn4593LrUTKVL8Qkl2mDYNjiFp101SPvqWUZCnUJNxJnmFz5BfZLo1mj2L4G2hsODwRTfbbAqPIk7oR1oRmrKqAx0hDVIm9AFdmoLZJj-uXnT0oBrvZUsjmLAfLao4AIgAxowHZttGTerAmHnRmw" draggable="false"><img style="pointer-events:none !important;display:inline-block;width:30px;height:30px;border-radius:3px;" width="30" height="30" draggable="false" class="lp-rich-link-captionBar-rightIcon" alt="favicon.ico" src="cid:2A21B6D8-D465-4B05-8877-D255CF4233B4"></a></td></tr></tbody></table></td></tr></tbody></table></a></div></div><br></div><div dir="ltr">—Kevin</div><div dir="ltr"><br><blockquote type="cite">On Jun 16, 2025, at 11:17 AM, Marc Culler &lt;cul...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer &lt;<a href="mailto:kw...@54...">kw...@54...</a>&gt; wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><img width="1" height="1" src="https://fedbdhd.r.tsp1-brevo.net/tr/op/0rJGz8a-GZcLwfiuXHRXFKgO1by8S_61Z31B3A4zOaYK-SmjMHR1Lc_ly81ohzIKV3cnJCy7So6l1SZzBfCf2LmDUJuQiZPSMneed-7IuwcL3LrvQctBGg_SxXxyrhdr6eYRbbP1PoZwmHt9_zaOWXN1jz2hySSeoy6az3T32jEJAlkAE_SobNC09ixj9XqsvF309m8ylmXc" data-unique-identifier=""></div>The canonical installation location for extension packages is /Library/Tcl. They shouldn’t go in the framework although it is supported. <br></blockquote><div><br></div><div>Hi Kevin,</div><div><br></div><div>Where do you find that canonical location specified?&nbsp; And why shouldn't they go in the framework?</div><div>&nbsp;</div><div>Using that location seems to destroy one of the great advantages of using a framework - namely that all dependencies are contained in the framework.&nbsp; Removing a framework should not involve&nbsp;hunting throughout the system for hidden dependencies which should be removed along with the framework because they become useless once the framework is gone.</div><div><br></div><div>My system does not have a /Library/Tcl directory, nor does it have a /Library/Python directory.&nbsp; (Those two languages get installed as frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl and /Library/Java.</div><div><br></div><div>- Marc</div></div></div>
</div></blockquote></body></html>

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

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

Hi Alexander,

I am not sure what you mean by v14.  Can you elaborate?

- Marc

On Mon, Jun 16, 2025 at 10:32 AM Alexander Schöpe <a.s...@gm...> wrote:

> I have also just tried this out. This is interesting in that it still ran
> under v14.
>
> > Am 16.06.2025 um 16:59 schrieb Marc Culler <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.
>
>
>

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

[Alexander S. <a.s...@gm...>]

I have also just tried this out. This is interesting in that it still ran under v14.

> Am 16.06.2025 um 16:59 schrieb Marc Culler <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.

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

[Alexander S. <a.s...@gm...>]

I think that's fine, because otherwise it's very complex to access this data.

> Am 16.06.2025 um 16:46 schrieb Marc Culler <cul...@gm...>:
> 
> In particular, the command ::tk::mac::GetAppPath has been part of the core for a long time.  I considered ::tk::mac::GetInfoAsJSON to be completely analogous to ::tk::mac::GetAppPath.
> 

Re: [TCLCORE] More on TEA packages for macOS

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

Also, /Library/Tcl is pretty deep in the auto_path for tclsh9.0:

$ tclsh9.0
% puts $auto_path
/Library/Frameworks/Tcl.framework/Versions/9.0/Resources/Scripts
/Library/Frameworks/Tcl.framework/Versions/9.0/Resources /usr/local/lib
/Users/culler/Library/Tcl /Library/Tcl /Users/culler/Library/Frameworks
/Library/Frameworks /Library/Frameworks/Tk.framework/Versions

If it really were the canonical location, I would expect it to be the first
directory in the default auto_path.

- Marc

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

> On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer <kw...@54...>
> wrote:
>
>> The canonical installation location for extension packages is
>> /Library/Tcl. They shouldn’t go in the framework although it is supported.
>>
>
> Hi Kevin,
>
> Where do you find that canonical location specified?  And why shouldn't
> they go in the framework?
>
> Using that location seems to destroy one of the great advantages of using
> a framework - namely that all dependencies are contained in the framework.
> Removing a framework should not involve hunting throughout the system for
> hidden dependencies which should be removed along with the framework
> because they become useless once the framework is gone.
>
> My system does not have a /Library/Tcl directory, nor does it have a
> /Library/Python directory.  (Those two languages get installed as
> frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl
> and /Library/Java.
>
> - Marc
>

Re: [TCLCORE] More on TEA packages for macOS

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

On Mon, Jun 16, 2025 at 9:46 AM Kevin Walzer <kw...@54...>
wrote:

> The canonical installation location for extension packages is
> /Library/Tcl. They shouldn’t go in the framework although it is supported.
>

Hi Kevin,

Where do you find that canonical location specified?  And why shouldn't
they go in the framework?

Using that location seems to destroy one of the great advantages of using a
framework - namely that all dependencies are contained in the framework.
Removing a framework should not involve hunting throughout the system for
hidden dependencies which should be removed along with the framework
because they become useless once the framework is gone.

My system does not have a /Library/Tcl directory, nor does it have a
/Library/Python directory.  (Those two languages get installed as
frameworks in /Library/Frameworks.) I do have /Library/Ruby, /Library/Perl
and /Library/Java.

- Marc

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