tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Adding a "zipfs" tag to the build-info command

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

Jan,

Thanks for your comments.

First, with regards to your suggestion about checking for the existence of the init.tcl file within the zipfs file system - that is exactly how the test suite currently does the detection. However, it does not help with the test case I was targeting where the init.tcl is supposed to exist but does not. In other words, what you suggested is a "circular" test. I want the test case to fail if the init.tcl does not exist when it is expected to. This "expected to" is when the build is done with --enable-zipfs. But there is currently no way at runtime to know if it was built that way. That was the reason to add the no-zipfs indicator to build-info. This failure mode threw me off on macos for a week. As Marc pointed out recently, the --enable-zipfs does not actually work on macos/arm but the test suite checks for init.tcl, does not find it and so assumes a build without zipfs and skips those tests. That left me thinking zipfs worked on macos sending me down a wild goose chase.

I understand about no-zipfs only working with tclsh (it works with both static and shared builds) but not with other executables. I was targeting test scenarios for Tcl where this suffices but your point is taken and would add confusion as a general runtime indicator so won't add it.

Still not happy about the test suite not detecting --enable-zipfs failures and continuing to run successfully with TCL_LIBRARY set to the source directory but shrug...

/Ashok

-----Original Message-----
From: Jan Nijtmans <jan...@gm...> 
Sent: Monday, August 11, 2025 3:07 PM
To: apn...@ya...
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] Adding a "zipfs" tag to the build-info command

Op vr 8 aug 2025 om 03:52 schreef <apn...@ya...>:
>
> Will do. Both no-zipfs and TIP 726 await your return and review!

Regarding no-zipfs, let's do the following. Compile tclsh with
--disable-shared and Tk with "--disable-shared --disable-zipfs"
Then tclsh9.0 will have a zip-file attached which contains
everything in tcl_library:
    $ ./tclsh
    % set tcl_library
    //zipfs:/app/tcl_library
    %  tcl::build-info
    9.0.3+011bd6147b19e73dc45fc523d672079aec402cff8f0780ce6bd40deb59c4764f.gcc-1304.static
Everything as expected. Now run wish:
    $ ./wish
    % set tcl_library
    /home/jan.nijtmans/workspace/tcl9.0/library
    % tcl::build-info
    9.0.3+011bd6147b19e73dc45fc523d672079aec402cff8f0780ce6bd40deb59c4764f.gcc-1304.static
We see that wish is built with --disable-zipfs, which means that
neither tcl_library
neither tk_library will be available from an attached zip-file. There's no way
tclsh's "no-zipfs" tag can know this for other executables than tclsh.

tcl::build-info for a shared-library build gives information how
libtcl.so is built. A
"no-zipfs" tag would inform us that libtcl.so doesn't have a zip-file attached.
But static libraries cannot have a zip-file attached. So, should we set the
"no-zipfs" tag always for static libraries? I don't think we should do that,
since we already have the "static" tag too.

All in all, testing whether there is a zip-file attached which
provides "init.tcl", can be done as follows:
    if {[file exists //zipfs:/app/tcl_library/init.tcl]
            || [file exists //zipfs:/lib/tcl/tcl_library/init.tcl]}
Unfortunately, the test is different for a static and a shared build, but
there are no other variations than those two. Since your use-case
is for test purposes only, that should do.

Hope this helps,
           Jan Nijtmans

Re: [TCLCORE] (No subject)

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

Brian,

Moving an existing github repository to tcltk-depot is very simple, probably less than 5 minutes.

Instructions are at https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository#transferring-a-repository-owned-by-your-personal-account

Not meaning to rush you, but just so you are aware.

/Ashok

-----Original Message-----
From: Brian O’Hagan via Tcl-Core <tcl...@li...> 
Sent: Sunday, August 10, 2025 6:51 PM
To: Harald Oehlmann <har...@el...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] (No subject)

Yes I’m good with that, I’ve just been too busy to get to it. Tktable 3.0 will be worth the wait.


> On Aug 10, 2025, at 3:27 AM, Harald Oehlmann <har...@el...> wrote:
> 
> Brian,
> would it be ok for you to put tktable to the orphaned package repository?
> It would be great to have one repository for it, so we join forces.
> The Astrology guys are also interested and have a copy (if it is not you).
> 
> THanks for a,,
> Harald
> 
>> Am 09.08.2025 um 18:58 schrieb Brian O’Hagan:
>> I’ll fix it in my fork of TkTable.
>>>> On Aug 9, 2025, at 9:36 AM, Harald Oehlmann <har...@el...> wrote:
>>> 
>>> Am 08.08.2025 um 18:56 schrieb Christian Werner:
>>>>> On 08/08/2025 05:42 PM, Harald Oehlmann wrote:
>>>>> ...
>>>>> - Sarcastic E-Mail by Christian Werner on the release
>>>> Well, for me it seems acceleration is in high demand. Here's another
>>>> little annoyance (not in Tcl not in Tk but in tkTable) but 20 years old
>>>> at least it is. A grown up bug so to speak:
>>>>   https://androwish.org/home/fdiff?v1=578db587e6eb6019&v2=dcfe9657bea31256
>>>> And I'm still unsure about my workaroundery being correct.
>>>> Lemme point out: I am not against progress, future, and the rest.
>>>> But from time to time it seems to me that speed isn't the solution.
>>>> Cheers,
>>>> Christian
>>> Dear Christian,
>>> yes, there is so much to do.
>>> 
>>> Thanks for the hint on TkTable. We may ask Jeffrey Hobbs about it, who is still around ;-).
>>> 
>>> I added this point as it is often a challenge to differenciate sarcasm and critism in the intercultural context.
>>> The best way is to speak.
>>> 
>>> My challenge is to link the Wizard level (Christian, Sergery, ...) with a common consensus, basically to get great results from whichever source.
>>> 
>>> Thank you all, you guys rock !
>>> Harald
> <OpenPGP_signature.asc>



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

[TCLCORE] Report of Biweekly telco on 11th of August at 12:00 UTC

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

Dear Tcl/Tk team,

Schelte notified me, that I use the word "eventually" in the German 
sense, which is "possibly". Sorry for that.

Top 1) Celebrate Tcl/Tk 9.1a0 release
What is next?
- TIP 713 revision of the next steps proposed
Jul 25    9.1a0
Nov 25    9.1a1
Feb 26    9.1a2
May 26    9.1b0
Jul 26    9.1b1
Aug 26    9.1b2
Sep 26    9.1.0

Thoughts:
- New timeline approved.
- Minor features should not wait for 2 years.
   Major things, like the Accessability may go to 9.2.
- We were occupied by 9.0 implementation for 1 year. Now, we have more 
time for new features, so 9.2 may come one year after 9.1.
- we can not make happy anybody. No resources for fast track projects.

- Question by Kevin Waltzer on Tk accessibility support TIP
May 2026 is the deadline.

- Sarcastic E-Mail by Christian Werner on the release

Top 2) Tcl 8.6.17

New SQLite may be included in rc1.

This is the fore-last release of 8.6.
Then it is end of life.
Messaging about the last release should be careful.
2038 is the physical limit.

Top 3) TIP 726: Commands for Unicode normalization

Jan will have a look on it.
ICU would be better, but does not exist on Mac.
So, this solution is seen as better.
Something basic in the core is great.
An extension would be harder.

Top 4) TIP 722: Return loaded packages by "package present"

Packaging system is fragile. Any modification is critical.
No objection, but is there a use-case?
The TIP returns the package names. Than, the package command may be used.
If this exists at C level, it may be exposed.

Currently, "package names" and "package present" may be used to find all 
loaded packages.
But this tool is quicker in time.
It has no practical advantage.

Top 5) TIP 689: Namespace unknown resolves in caller or target?

Ashoks proposal is to have 2 commands.
The use case "caller namespace" is not seen as having a use-case.
The case "called namespace" has the late loading use-case.

A work-around is to use full qualified path.

Ask Donal Fellows...

Top 6) TCLCompile for 9.0/9.1
Miguel Bañón is active
To orphaned packages?

Top 7) Tk dialogs on small screens:
https://core.tcl-lang.org/tk/info/e19f1d8914442195
https://core.tcl-lang.org/tk/info/7c28f8351e3cebeb

Ok to put SDL specific code to Tk.

Top 8) TkTable
Fix by Christian.
Orphaned packages?



Top 9) FreeBSD
Pietro Cerutti's E-Mail.
- TIP 439

There were so many issues and discussion.
Other projects (Java) use semantic versioning, but publish a major each 
year to get rid of the restrictions.

Tcl package system can support different versions, for different 
versions of Tcl. This interfears with the packagers view.

Thread package was cleaned up with 3.0. This is seen as an improvement.
Sorry, that it does not work with older versions.
Tk is the same...

- TIP 486
Not discussed.

Pietro accepted to be in the meeting in two weeks.
Perhaps, Reinhard may also participate.

Top 10) Remove virtual screen support in Tk?


Top 11) Each interpreter looks for TCL library

In TCL 9 , interpeter creation time is much higher.
But why does each interpreter looks for a tcl library on his own?

In TCL 8.6, the main point was the encoding, as the source command 
needed it.

In 9.0, we always use utf-8, so this problem does not exist any more.

New interpreter needs 2ms. TclOO loading needs 1.4ms. Is lazy loading of 
TclOO a good idea?

The main point is the Tcl_Init environment variable with the path to 
Tcl_Init.
An interpreter may change this for its slave interpreters, which may use 
a different Tcl_Init file.

---

Next meeting:
12th of August 18:00 UTC: TCL Meetup (I am not available)
25th of August 12:00: Bi-weekly Telco (I am available)

Note: in September and October, I will not be able to attend the meetings.

Thank you for all,
Harald

Re: [TCLCORE] Pain points as a distro maintainer

[Brian O’H. <bri...@co...>]

I’ve been busy at work, so I’m a little behind schedule. I should have an updated TkTable in a few weeks, then I’ll finish up TclTLS 2.0 after that. 

> On Aug 11, 2025, at 6:47 AM, Harald Oehlmann <har...@el...> wrote:
> 
> Hi Peitro,
> yes, communication and clear words are the main points.
> I always try to keep Reinhard Max in the loop, the SuSE maintainer, who also has issues, but different ones.
> 
> On the practical side, I only see a need for a branch for tcl8 and tcl9.
> tcl9.1 is backward compatible to 9.0, but not the other way round.
> 
> TCLTLS is a long story. I am very happy, that Brian o'Hagan has made technical improvements and taken the maintainership.
> I already asked him for a release and he said: end of the month (of July). Brian, a release would be great! Even, if it is not perfect and not all issues are solved. There are so many improvements, that it is better than anything else. Even for 8.6, the new version is a big step.
> 
> About the Thread package: maintainer pending, sorry. The long time goal is to include parts of it into the core.
> 
> Thanks for all,
> Harald
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> <OpenPGP_signature.asc>

Re: [TCLCORE] Pain points as a distro maintainer

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

Hi Peitro,
yes, communication and clear words are the main points.
I always try to keep Reinhard Max in the loop, the SuSE maintainer, who 
also has issues, but different ones.

On the practical side, I only see a need for a branch for tcl8 and tcl9.
tcl9.1 is backward compatible to 9.0, but not the other way round.

TCLTLS is a long story. I am very happy, that Brian o'Hagan has made 
technical improvements and taken the maintainership.
I already asked him for a release and he said: end of the month (of 
July). Brian, a release would be great! Even, if it is not perfect and 
not all issues are solved. There are so many improvements, that it is 
better than anything else. Even for 8.6, the new version is a big step.

About the Thread package: maintainer pending, sorry. The long time goal 
is to include parts of it into the core.

Thanks for all,
Harald

Re: [TCLCORE] Pain points as a distro maintainer

[Pietro C. <ga...@ga...>]

On Aug 11 2025, 11:24 +0000, Harald Oehlmann <har...@el...> wrote:
>Hi Pietro,
>thanks for the great post.
>Would you be available for the telco today 12:00 UTC (in 26 minuites) ?

Unfortunately not, sorry. I can try to be available for the next one, 
though! Thanks!


-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org

Re: [TCLCORE] Pain points as a distro maintainer

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

Hi Pietro,
thanks for the great post.
Would you be available for the telco today 12:00 UTC (in 26 minuites) ?

Thanks for all,
Harald

Am 11.08.2025 um 13:09 schrieb Pietro Cerutti via Tcl-Core:
> Hi,
> 
> I main a number of Tcl/Tk ports on FreeBSD, under the umbrella of the 
> tcltk@ team: https://portscout.freebsd.org/tc...@fr...ml.
> 
> I would like to express my pain points and concerns when it comes to 
> maintain Tcl/Tk as a downstream packager, particularly in light of the 
> upcoming 9.1 release. I think I have expressed some (most?) of these 
> concerns in the past, in a way or another, either on this ML and/or on IRC.
> 
> What I say below is only partially specific to how the FreeBSD ports 
> work.  I expect different downstreams to have intersecting but not 
> identical sets of concerns.
> 
> 1. versioning
> 
> Problem:
> We used to maintain flavours of Tcl/Tk for 8.4, 8.5, 8.6, 8.7, and 9.0. 
> Right now we only have 8.6 and 9.0 in the tree. I'd like to keep it that 
> way, i.e., one port per major version. We need to figure out sooner than 
> later whether it's going to be a pain to upgrade from 9.0 to 9.1. Better 
> yet: we need to make sure that it's *not* going to be a pain.
> Ideally, I'd like to have one port for tcl8 and one for tcl9. Ideally, I 
> wouldn't have to care about minor versions.
> 
> Proposal:
> I propose that we TIP specifics about our versioning schema, and we 
> abide to the post-conditions we set forward. TIP 439 (Semantic 
> Versioning) is marked as obsoleted. We should resurrect it. I think we 
> should state that any 9.x is going to be source/binary compatible with 
> 9.0. Only backwards compatibile enhancements should be included.
> 
> 2. file provenance
> 
> Problem:
> One of the problems that package managers solve for users is to answer 
> the question: which package installs /usr/local/foo/bar? Each file must 
> come from a unique 3rd party package. When two different packages 
> install the same file, they are marked as conflicting, and the user 
> cannot have them both installed at the same time.
> Tcl 8.x doesn't have disjoint sets of installation files for different 
> values of x. The only versioned things are the shared library and tclsh.
> This is true also for 8.x and 9.x.
> We go through a lot of gymnics in FreeBSD to make sure people can 
> install 8.6 and 9.0 together, e.g., by suffixing man pages with .tcl86 
> and .tcl90, and by installing header files to ${prefix}/include/tcl${ver}.
> 
> Proposal:
> This is linked to the previous item: if we can't seamlessy upgrade from 
> one version to another, we need to make sure people can keep both at the 
> same time. If we want that to be a painless process, we need to make 
> sure the packages don't install overlapping files.
> I propose that we adopt a solution similar to what it's done on FreeBSD, 
> where every files is installed under a path that contains the version in 
> a way or another. Here's how we do it on FreeBSD, where %%TCL_VER%% is 
> expanded to e.g., 8.6 and %%SHORT_TCL_VERSION%% to e.g., 86:
> https://cgit.freebsd.org/ports/tree/lang/tcl86/pkg-plist
> 
> 3. source-level compatibility between Tcl8 and Tcl9, Thread
> 
> Problem:
> The Thread package now comes in two branches, 2.x for Tcl8 and 3.x for 
> Tcl9. This was a major pain point and required me to split the previous 
> tclthread port into two separate ports, tcl8-thread and tcl9-thread.
> I hope this won't be the case for many extensions.
> To me, not providing a Thread extension that's buildable with both Tcl8 
> and Tcl9 is a very bad message to give to downstream and extension 
> implementors.  TIP 486 suggested it, but it was never discussed / voted.
> 
> Proposal:
> I fear the ship has sailed on this one, but it would be great if the 3.x 
> branch could be made buildable with both Tcl8 and Tcl9.
> 
> 4. tcltls
> 
> Problem:
> We now have 9.0 out of the door and work is already underways for 9.1. 
> However, it's 2025 and we don't have a way to talk https, as the 
> currently released tcltls extension doesn't build with Tcl9.  I know 
> there's a tcltls 1.8 tagged, but not released; I am testing it right now 
> and it seems to work fine for my use caess. I also see that work is 
> being done (is it?) for 2.0.  But no matter what happens in the future, 
> they're missing *now*, as 9.x is supposed to be adopted by users.
> 
> Solution:
> Some packages are A-class citizens and get distributed together with 
> Tcl: https://sourceforge.net/projects/tcl/files/Tcl/9.0.2/.
> I suggest that tcltls be upgraded to A-class.
> 
> Conclusion
> 
> I have the feeling that the people doing the work (and thanks for that!) 
> are sometimes disconnected from the people who are supposed to integrate 
> and use the result of the work.
> 
> For example, to reiterate, I don't see how 9.1 can be a priority when 
> 9.0 can't talk on the web because of a missing TLS solution.
> 
> I understand that this is opensource and people get to work on whatever 
> pleases them. But I also think that if we don't want to become 
> irrelevant on the landscape of programming languages, we should offer 
> more of an integrated solution and less of individual pieces. For a 
> parallel, in OCaml land, there's this concept of an OCaml platform from 
> some years now: https://ocaml.org/platform. I think we could draw some 
> inspriration.
> 
> I ask the people putting in the hours and the efforts to try to connect 
> with the users base and the downstream pacakgers to offer a viable, 
> usable, and maintainable Tcl solution.
> 
> I ask that big changes, especially those affecting users, be TIP'd and 
> not just implemented, merged, and forgotten.
> 
> I am willing to put hours in, if people agree on the general direction.
> 
> I am happy to start multiple threads on the different subjects, too.
> 
> Thanks,
> 
> Pietro
> 


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

[TCLCORE] Pain points as a distro maintainer

[Pietro C. <ga...@ga...>]

Hi,

I main a number of Tcl/Tk ports on FreeBSD, under the umbrella of the 
tcltk@ team: https://portscout.freebsd.org/tc...@fr...ml.

I would like to express my pain points and concerns when it comes to 
maintain Tcl/Tk as a downstream packager, particularly in light of the 
upcoming 9.1 release. I think I have expressed some (most?) of these 
concerns in the past, in a way or another, either on this ML and/or on 
IRC.

What I say below is only partially specific to how the FreeBSD ports 
work.  I expect different downstreams to have intersecting but not 
identical sets of concerns.

1. versioning

Problem:
We used to maintain flavours of Tcl/Tk for 8.4, 8.5, 8.6, 8.7, and 9.0.  
Right now we only have 8.6 and 9.0 in the tree. I'd like to keep it that 
way, i.e., one port per major version. We need to figure out sooner than 
later whether it's going to be a pain to upgrade from 9.0 to 9.1. Better 
yet: we need to make sure that it's *not* going to be a pain.
Ideally, I'd like to have one port for tcl8 and one for tcl9. Ideally, I 
wouldn't have to care about minor versions.

Proposal:
I propose that we TIP specifics about our versioning schema, and we 
abide to the post-conditions we set forward. TIP 439 (Semantic 
Versioning) is marked as obsoleted. We should resurrect it. I think we 
should state that any 9.x is going to be source/binary compatible with 
9.0. Only backwards compatibile enhancements should be included.

2. file provenance

Problem:
One of the problems that package managers solve for users is to answer 
the question: which package installs /usr/local/foo/bar? Each file must 
come from a unique 3rd party package. When two different packages 
install the same file, they are marked as conflicting, and the user 
cannot have them both installed at the same time.
Tcl 8.x doesn't have disjoint sets of installation files for different 
values of x. The only versioned things are the shared library and tclsh.
This is true also for 8.x and 9.x.
We go through a lot of gymnics in FreeBSD to make sure people can 
install 8.6 and 9.0 together, e.g., by suffixing man pages with .tcl86 
and .tcl90, and by installing header files to ${prefix}/include/tcl${ver}.

Proposal:
This is linked to the previous item: if we can't seamlessy upgrade from 
one version to another, we need to make sure people can keep both at the 
same time. If we want that to be a painless process, we need to make 
sure the packages don't install overlapping files.
I propose that we adopt a solution similar to what it's done on FreeBSD, 
where every files is installed under a path that contains the version in 
a way or another. Here's how we do it on FreeBSD, where %%TCL_VER%% is 
expanded to e.g., 8.6 and %%SHORT_TCL_VERSION%% to e.g., 86:
https://cgit.freebsd.org/ports/tree/lang/tcl86/pkg-plist

3. source-level compatibility between Tcl8 and Tcl9, Thread

Problem:
The Thread package now comes in two branches, 2.x for Tcl8 and 3.x for 
Tcl9. This was a major pain point and required me to split the previous 
tclthread port into two separate ports, tcl8-thread and tcl9-thread.
I hope this won't be the case for many extensions.
To me, not providing a Thread extension that's buildable with both Tcl8 
and Tcl9 is a very bad message to give to downstream and extension 
implementors.  TIP 486 suggested it, but it was never discussed / voted.

Proposal:
I fear the ship has sailed on this one, but it would be great if the 3.x 
branch could be made buildable with both Tcl8 and Tcl9.

4. tcltls

Problem:
We now have 9.0 out of the door and work is already underways for 9.1.  
However, it's 2025 and we don't have a way to talk https, as the 
currently released tcltls extension doesn't build with Tcl9.  I know 
there's a tcltls 1.8 tagged, but not released; I am testing it right now 
and it seems to work fine for my use caess. I also see that work is 
being done (is it?) for 2.0.  But no matter what happens in the future, 
they're missing *now*, as 9.x is supposed to be adopted by users.

Solution:
Some packages are A-class citizens and get distributed together with 
Tcl: https://sourceforge.net/projects/tcl/files/Tcl/9.0.2/.
I suggest that tcltls be upgraded to A-class.

Conclusion

I have the feeling that the people doing the work (and thanks for that!) 
are sometimes disconnected from the people who are supposed to integrate 
and use the result of the work.

For example, to reiterate, I don't see how 9.1 can be a priority when 
9.0 can't talk on the web because of a missing TLS solution.

I understand that this is opensource and people get to work on whatever 
pleases them. But I also think that if we don't want to become 
irrelevant on the landscape of programming languages, we should offer 
more of an integrated solution and less of individual pieces. For a 
parallel, in OCaml land, there's this concept of an OCaml platform from 
some years now: https://ocaml.org/platform. I think we could draw some 
inspriration.

I ask the people putting in the hours and the efforts to try to connect 
with the users base and the downstream pacakgers to offer a viable, 
usable, and maintainable Tcl solution.

I ask that big changes, especially those affecting users, be TIP'd and 
not just implemented, merged, and forgotten.

I am willing to put hours in, if people agree on the general direction.

I am happy to start multiple threads on the different subjects, too.

Thanks,

Pietro

-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org

Re: [TCLCORE] Adding a "zipfs" tag to the build-info command

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

Op vr 8 aug 2025 om 03:52 schreef <apn...@ya...>:
>
> Will do. Both no-zipfs and TIP 726 await your return and review!

Regarding no-zipfs, let's do the following. Compile tclsh with
--disable-shared and Tk with "--disable-shared --disable-zipfs"
Then tclsh9.0 will have a zip-file attached which contains
everything in tcl_library:
    $ ./tclsh
    % set tcl_library
    //zipfs:/app/tcl_library
    %  tcl::build-info
    9.0.3+011bd6147b19e73dc45fc523d672079aec402cff8f0780ce6bd40deb59c4764f.gcc-1304.static
Everything as expected. Now run wish:
    $ ./wish
    % set tcl_library
    /home/jan.nijtmans/workspace/tcl9.0/library
    % tcl::build-info
    9.0.3+011bd6147b19e73dc45fc523d672079aec402cff8f0780ce6bd40deb59c4764f.gcc-1304.static
We see that wish is built with --disable-zipfs, which means that
neither tcl_library
neither tk_library will be available from an attached zip-file. There's no way
tclsh's "no-zipfs" tag can know this for other executables than tclsh.

tcl::build-info for a shared-library build gives information how
libtcl.so is built. A
"no-zipfs" tag would inform us that libtcl.so doesn't have a zip-file attached.
But static libraries cannot have a zip-file attached. So, should we set the
"no-zipfs" tag always for static libraries? I don't think we should do that,
since we already have the "static" tag too.

All in all, testing whether there is a zip-file attached which
provides "init.tcl", can be done as follows:
    if {[file exists //zipfs:/app/tcl_library/init.tcl]
            || [file exists //zipfs:/lib/tcl/tcl_library/init.tcl]}
Unfortunately, the test is different for a static and a shared build, but
there are no other variations than those two. Since your use-case
is for test purposes only, that should do.

Hope this helps,
           Jan Nijtmans

[TCLCORE] 12 August Tcl monthly virtual meetup notice

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

A reminder that the next meetup will be held Tuesday 12 August 2025 at [clock format 1755021600] - Tuesday 11am US West, 1pm US Central, 2pm US East, 6pm UTC, 7pm UK, 8pm Western Europe, 11:30pm India, Wednesday 2am Australia West / Singapore / China, 3am Japan, 4am Australia East, 6am New Zealand

Details (including how to connect) are available via https://wiki.tcl-lang.org/page/Monthly+Virtual+Meetup

-- Steve

Re: [TCLCORE] Advice requested about support for "-singleproc 0" in the Tk test suite

[Erik L. <el...@xs...>]

I've decided to implement the testfile simplifications for "-singleproc 1", without removing support 
for "-singleproc 0". So both -singleproc modes will be supported
by testfiles.

A separate issue is that all.tcl currently disables support for "-singleproc 0".
Given the questions about the commit that disabled that support, I'm going to
restore support for "-singleproc 0", but keep "-singleproc 1" as the default.

All of this will be tested at Github CI for all major platforms. Any reasons to not  support 
"-singleproc 0" should become visible there. So, lacking better information/ideas, I'm going to let 
the Github results decide.

An RFE ticket to this effect has been posted to the fossil repository for Tk here:

     https://core.tcl-lang.org/tk/tktview/4f9946f4f3fcdd9d30ced2f816e963dc18e124c9

Erik Leunissen.
--

Re: [TCLCORE] (No subject)

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

Wrong Brian. My mistake. 
Never mind. 

-Brian
(from mobile device)

> On Aug 10, 2025, at 06:22, Brian Griffin <bri...@ea...> wrote:
> 
> This should be possible. I appear to have two sources for tktable. I’ll take a closer look.
> 
> -Brian
> (from mobile device)
> 
>> On Aug 10, 2025, at 01:28, Harald Oehlmann <har...@el...> wrote:
>> 
>> Brian,
>> would it be ok for you to put tktable to the orphaned package repository?
>> It would be great to have one repository for it, so we join forces.
>> The Astrology guys are also interested and have a copy (if it is not you).
>> 
>> THanks for a,,
>> Harald
>> 
>>>> Am 09.08.2025 um 18:58 schrieb Brian O’Hagan:
>>> I’ll fix it in my fork of TkTable.
>>>>> On Aug 9, 2025, at 9:36 AM, Harald Oehlmann <har...@el...> wrote:
>>>> 
>>>> Am 08.08.2025 um 18:56 schrieb Christian Werner:
>>>>>> On 08/08/2025 05:42 PM, Harald Oehlmann wrote:
>>>>>> ...
>>>>>> - Sarcastic E-Mail by Christian Werner on the release
>>>>> Well, for me it seems acceleration is in high demand. Here's another
>>>>> little annoyance (not in Tcl not in Tk but in tkTable) but 20 years old
>>>>> at least it is. A grown up bug so to speak:
>>>>>  https://androwish.org/home/fdiff?v1=578db587e6eb6019&v2=dcfe9657bea31256
>>>>> And I'm still unsure about my workaroundery being correct.
>>>>> Lemme point out: I am not against progress, future, and the rest.
>>>>> But from time to time it seems to me that speed isn't the solution.
>>>>> Cheers,
>>>>> Christian
>>>> Dear Christian,
>>>> yes, there is so much to do.
>>>> 
>>>> Thanks for the hint on TkTable. We may ask Jeffrey Hobbs about it, who is still around ;-).
>>>> 
>>>> I added this point as it is often a challenge to differenciate sarcasm and critism in the intercultural context.
>>>> The best way is to speak.
>>>> 
>>>> My challenge is to link the Wizard level (Christian, Sergery, ...) with a common consensus, basically to get great results from whichever source.
>>>> 
>>>> Thank you all, you guys rock !
>>>> Harald
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>> <OpenPGP_signature.asc>

Re: [TCLCORE] (No subject)

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

This should be possible. I appear to have two sources for tktable. I’ll take a closer look. 

-Brian
(from mobile device)

> On Aug 10, 2025, at 01:28, Harald Oehlmann <har...@el...> wrote:
> 
> Brian,
> would it be ok for you to put tktable to the orphaned package repository?
> It would be great to have one repository for it, so we join forces.
> The Astrology guys are also interested and have a copy (if it is not you).
> 
> THanks for a,,
> Harald
> 
>> Am 09.08.2025 um 18:58 schrieb Brian O’Hagan:
>> I’ll fix it in my fork of TkTable.
>>>> On Aug 9, 2025, at 9:36 AM, Harald Oehlmann <har...@el...> wrote:
>>> 
>>> Am 08.08.2025 um 18:56 schrieb Christian Werner:
>>>>> On 08/08/2025 05:42 PM, Harald Oehlmann wrote:
>>>>> ...
>>>>> - Sarcastic E-Mail by Christian Werner on the release
>>>> Well, for me it seems acceleration is in high demand. Here's another
>>>> little annoyance (not in Tcl not in Tk but in tkTable) but 20 years old
>>>> at least it is. A grown up bug so to speak:
>>>>   https://androwish.org/home/fdiff?v1=578db587e6eb6019&v2=dcfe9657bea31256
>>>> And I'm still unsure about my workaroundery being correct.
>>>> Lemme point out: I am not against progress, future, and the rest.
>>>> But from time to time it seems to me that speed isn't the solution.
>>>> Cheers,
>>>> Christian
>>> Dear Christian,
>>> yes, there is so much to do.
>>> 
>>> Thanks for the hint on TkTable. We may ask Jeffrey Hobbs about it, who is still around ;-).
>>> 
>>> I added this point as it is often a challenge to differenciate sarcasm and critism in the intercultural context.
>>> The best way is to speak.
>>> 
>>> My challenge is to link the Wizard level (Christian, Sergery, ...) with a common consensus, basically to get great results from whichever source.
>>> 
>>> Thank you all, you guys rock !
>>> Harald
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> <OpenPGP_signature.asc>

Re: [TCLCORE] (No subject)

[Brian O’H. <bri...@co...>]

Yes I’m good with that, I’ve just been too busy to get to it. Tktable 3.0 will be worth the wait.


> On Aug 10, 2025, at 3:27 AM, Harald Oehlmann <har...@el...> wrote:
> 
> Brian,
> would it be ok for you to put tktable to the orphaned package repository?
> It would be great to have one repository for it, so we join forces.
> The Astrology guys are also interested and have a copy (if it is not you).
> 
> THanks for a,,
> Harald
> 
>> Am 09.08.2025 um 18:58 schrieb Brian O’Hagan:
>> I’ll fix it in my fork of TkTable.
>>>> On Aug 9, 2025, at 9:36 AM, Harald Oehlmann <har...@el...> wrote:
>>> 
>>> Am 08.08.2025 um 18:56 schrieb Christian Werner:
>>>>> On 08/08/2025 05:42 PM, Harald Oehlmann wrote:
>>>>> ...
>>>>> - Sarcastic E-Mail by Christian Werner on the release
>>>> Well, for me it seems acceleration is in high demand. Here's another
>>>> little annoyance (not in Tcl not in Tk but in tkTable) but 20 years old
>>>> at least it is. A grown up bug so to speak:
>>>>   https://androwish.org/home/fdiff?v1=578db587e6eb6019&v2=dcfe9657bea31256
>>>> And I'm still unsure about my workaroundery being correct.
>>>> Lemme point out: I am not against progress, future, and the rest.
>>>> But from time to time it seems to me that speed isn't the solution.
>>>> Cheers,
>>>> Christian
>>> Dear Christian,
>>> yes, there is so much to do.
>>> 
>>> Thanks for the hint on TkTable. We may ask Jeffrey Hobbs about it, who is still around ;-).
>>> 
>>> I added this point as it is often a challenge to differenciate sarcasm and critism in the intercultural context.
>>> The best way is to speak.
>>> 
>>> My challenge is to link the Wizard level (Christian, Sergery, ...) with a common consensus, basically to get great results from whichever source.
>>> 
>>> Thank you all, you guys rock !
>>> Harald
> <OpenPGP_signature.asc>

Re: [TCLCORE] (No subject)

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

Brian,
would it be ok for you to put tktable to the orphaned package repository?
It would be great to have one repository for it, so we join forces.
The Astrology guys are also interested and have a copy (if it is not you).

THanks for a,,
Harald

Am 09.08.2025 um 18:58 schrieb Brian O’Hagan:
> I’ll fix it in my fork of TkTable.
> 
>> On Aug 9, 2025, at 9:36 AM, Harald Oehlmann <har...@el...> wrote:
>>
>> Am 08.08.2025 um 18:56 schrieb Christian Werner:
>>>> On 08/08/2025 05:42 PM, Harald Oehlmann wrote:
>>>> ...
>>>> - Sarcastic E-Mail by Christian Werner on the release
>>> Well, for me it seems acceleration is in high demand. Here's another
>>> little annoyance (not in Tcl not in Tk but in tkTable) but 20 years old
>>> at least it is. A grown up bug so to speak:
>>>    https://androwish.org/home/fdiff?v1=578db587e6eb6019&v2=dcfe9657bea31256
>>> And I'm still unsure about my workaroundery being correct.
>>> Lemme point out: I am not against progress, future, and the rest.
>>> But from time to time it seems to me that speed isn't the solution.
>>> Cheers,
>>> Christian
>> Dear Christian,
>> yes, there is so much to do.
>>
>> Thanks for the hint on TkTable. We may ask Jeffrey Hobbs about it, who is still around ;-).
>>
>> I added this point as it is often a challenge to differenciate sarcasm and critism in the intercultural context.
>> The best way is to speak.
>>
>> My challenge is to link the Wizard level (Christian, Sergery, ...) with a common consensus, basically to get great results from whichever source.
>>
>> Thank you all, you guys rock !
>> Harald

Re: [TCLCORE] (No subject)

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

On 08/09/2025 06:58 PM, Brian O’Hagan via Tcl-Core wrote:

Brian,

> I’ll fix it in my fork of TkTable.

Great. If you are at it, maybe my observations help for further review.
The problem became slowly apparent using tksqlite on some complex query,
which gives one result column and possible zero rows. It took me quite
a time to come to the conclusion, that the visual representation in this
case was misleading. The first culprit was tksqlite, but the real problem
turned out to be tktable in this case. Now the bad point is, that the
many combinations of number of header rows and/or columns plus the number
of modes on how to deal with the selection might yield, that my naive
patch isn't even a tenth of the real solution. It only fixed my issue
in the aforementioned tksqlite case.

Hope that helps for improving tktable,
Christian

Re: [TCLCORE] (No subject)

[Brian O’H. <bri...@co...>]

I’ll fix it in my fork of TkTable.

> On Aug 9, 2025, at 9:36 AM, Harald Oehlmann <har...@el...> wrote:
> 
> Am 08.08.2025 um 18:56 schrieb Christian Werner:
>>> On 08/08/2025 05:42 PM, Harald Oehlmann wrote:
>>> ...
>>> - Sarcastic E-Mail by Christian Werner on the release
>> Well, for me it seems acceleration is in high demand. Here's another
>> little annoyance (not in Tcl not in Tk but in tkTable) but 20 years old
>> at least it is. A grown up bug so to speak:
>>   https://androwish.org/home/fdiff?v1=578db587e6eb6019&v2=dcfe9657bea31256
>> And I'm still unsure about my workaroundery being correct.
>> Lemme point out: I am not against progress, future, and the rest.
>> But from time to time it seems to me that speed isn't the solution.
>> Cheers,
>> Christian
> Dear Christian,
> yes, there is so much to do.
> 
> Thanks for the hint on TkTable. We may ask Jeffrey Hobbs about it, who is still around ;-).
> 
> I added this point as it is often a challenge to differenciate sarcasm and critism in the intercultural context.
> The best way is to speak.
> 
> My challenge is to link the Wizard level (Christian, Sergery, ...) with a common consensus, basically to get great results from whichever source.
> 
> Thank you all, you guys rock !
> Harald
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> <OpenPGP_signature.asc>

Re: [TCLCORE] Biweekly telco on 11th of August at 12:00 UTC

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

Am 08.08.2025 um 18:56 schrieb Christian Werner:
> On 08/08/2025 05:42 PM, Harald Oehlmann wrote:
> 
>> ...
>> - Sarcastic E-Mail by Christian Werner on the release
> 
> Well, for me it seems acceleration is in high demand. Here's another
> little annoyance (not in Tcl not in Tk but in tkTable) but 20 years old
> at least it is. A grown up bug so to speak:
> 
>    https://androwish.org/home/fdiff?v1=578db587e6eb6019&v2=dcfe9657bea31256
> 
> And I'm still unsure about my workaroundery being correct.
> 
> Lemme point out: I am not against progress, future, and the rest.
> But from time to time it seems to me that speed isn't the solution.
> 
> Cheers,
> Christian
Dear Christian,
yes, there is so much to do.

Thanks for the hint on TkTable. We may ask Jeffrey Hobbs about it, who 
is still around ;-).

I added this point as it is often a challenge to differenciate sarcasm 
and critism in the intercultural context.
The best way is to speak.

My challenge is to link the Wizard level (Christian, Sergery, ...) with 
a common consensus, basically to get great results from whichever source.

Thank you all, you guys rock !
Harald

Re: [TCLCORE] Biweekly telco on 11th of August at 12:00 UTC

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

On 08/08/2025 05:42 PM, Harald Oehlmann wrote:

> ...
> - Sarcastic E-Mail by Christian Werner on the release

Well, for me it seems acceleration is in high demand. Here's another
little annoyance (not in Tcl not in Tk but in tkTable) but 20 years old
at least it is. A grown up bug so to speak:

   https://androwish.org/home/fdiff?v1=578db587e6eb6019&v2=dcfe9657bea31256

And I'm still unsure about my workaroundery being correct.

Lemme point out: I am not against progress, future, and the rest.
But from time to time it seems to me that speed isn't the solution.

Cheers,
Christian

[TCLCORE] Biweekly telco on 11th of August at 12:00 UTC

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

Dear Tcl/Tk team,

please feel invited to the next Tcl/Tk beweekly telco:
11th of August at 12:00 UTC
At: https://meet.jit.si/TclMonthlyMeetup

Agenda proposal:

Top 1) Celebrate Tcl/Tk 9.1a0 release
What is next?
- TIP 713 revision of the next steps proposed
Jul 25    9.1a0
Nov 25    9.1a1
Feb 26    9.1a2
May 26    9.1b0
Jul 26    9.1b1
Aug 26    9.1b2
Sep 26    9.1.0
- Question by Kevin Waltzer on Tk accessibility support TIP
- Sarcastic E-Mail by Christian Werner on the release

Top 2) Tcl 8.6.16

Top 3) TIP 726: Commands for Unicode normalization

Top 4) TIP 722: Return loaded packages by "package present"

Top 5) TIP 689: Namespace unknown resolves in caller or target?

Top 6) TCLCompile for 9.0/9.1
Miguel Bañón is active
To orphaned packages?

Top 7) Tk dialogs on small screens:
https://core.tcl-lang.org/tk/info/e19f1d8914442195
https://core.tcl-lang.org/tk/info/7c28f8351e3cebeb

---

Next meeting:
12th of August 18:00 UTC: TCL Meetup (I am not available)
25th of August 12:00: Bi-weekly Telco (I am available)

Note: in September and October, I will not be able to attend the meetings.

Thank you for all,
Harald

Re: [TCLCORE] Adding a "zipfs" tag to the build-info command

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

Will do. Both no-zipfs and TIP 726 await your return and review!

 

From: Jan Nijtmans <jan...@gm...> 
Sent: Friday, August 8, 2025 1:53 AM
To: Ashok Nadkarni <apn...@ya...>; Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] Adding a "zipfs" tag to the build-info command

 

Hi all,

 

I don't have principal objection to this idea, just a -rather important - practical one. After I'm back from my vacation, I will show you what's wrong with the "apn-build-info-nozipfs" branch.

 

Op do 7 aug 2025, 07:58 schreef apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> >:

Thanks Harald. Also, I see other tags are present that are not mentioned in any TIP so presumably no TIP required for this.

As an aside, zipfs is actually a misnomer as zipfs support and command is *always* present. The --disable-zipfs does not remove the functionality, it only disables the embedding of the zip file. I'll also use no-zipfs to be consistent with that.

/Ashok

-----Original Message-----
From: Harald Oehlmann <har...@el... <mailto:har...@el...> > 
Sent: Thursday, August 7, 2025 12:43 AM
To: apn...@ya... <mailto:apn...@ya...> ; apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> >
Subject: Re: [TCLCORE] Adding a "zipfs" tag to the build-info command

As Jan explained to me, the tags are extensable by nature.
But I don't see this in TIP599, as it says "may be extended in future".

As the "normal" value is no tag, you may add the tag "no-zfs", as "no-threads".

Take care,
Harald

> apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > hat am 06.08.2025 19:35 CEST geschrieben:
> 
> 
> I would like to add a “zipfs” tag to the {tcl,tk}::build-info command (TIP 599) that would indicate if the {tcl,tk}_library was embedded as a zip file into the binary. Does this require a TIP? I would hope not given that the TIP suggests third-parties could add their own tags.
> 
> The primary use is in the test suite. Based on my manual testing, it is my belief that the Tk test suite actually never tests the embedded zip at all as it sets the TK_LIBRARY environment variable. Further, on macOS I *think* based on github CI logs, even tclsh zipfs builds fail to find the embedded ZIP and instead land up using the init.tcl found by searching up the directory hierarchy.
> 
> The tag would help detect such cases, for example, by checking the value of $tcl_library corresponds to the expected result if the zipfs tag was present.
> 
> (all this is based on my not being aware of any way to check at runtime if the build was configured with –enable-zipfs or –disable-zipfs. If someone can identify a method for this, the tag may not be needed)
> 
> /Ashok
> _______________________________________________ Tcl-Core mailing list Tcl...@li... <mailto:Tcl...@li...>  https://lists.sourceforge.net/lists/listinfo/tcl-core



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

Re: [TCLCORE] Adding a "zipfs" tag to the build-info command

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

Hi all,

I don't have principal objection to this idea, just a -rather important -
practical one. After I'm back from my vacation, I will show you what's
wrong with the "apn-build-info-nozipfs" branch.

Op do 7 aug 2025, 07:58 schreef apnmbx-public--- via Tcl-Core <
tcl...@li...>:

> Thanks Harald. Also, I see other tags are present that are not mentioned
> in any TIP so presumably no TIP required for this.
>
> As an aside, zipfs is actually a misnomer as zipfs support and command is
> *always* present. The --disable-zipfs does not remove the functionality, it
> only disables the embedding of the zip file. I'll also use no-zipfs to be
> consistent with that.
>
> /Ashok
>
> -----Original Message-----
> From: Harald Oehlmann <har...@el...>
> Sent: Thursday, August 7, 2025 12:43 AM
> To: apn...@ya...; apnmbx-public--- via Tcl-Core <
> tcl...@li...>
> Subject: Re: [TCLCORE] Adding a "zipfs" tag to the build-info command
>
> As Jan explained to me, the tags are extensable by nature.
> But I don't see this in TIP599, as it says "may be extended in future".
>
> As the "normal" value is no tag, you may add the tag "no-zfs", as
> "no-threads".
>
> Take care,
> Harald
>
> > apnmbx-public--- via Tcl-Core <tcl...@li...> hat am
> 06.08.2025 19:35 CEST geschrieben:
> >
> >
> > I would like to add a “zipfs” tag to the {tcl,tk}::build-info command
> (TIP 599) that would indicate if the {tcl,tk}_library was embedded as a zip
> file into the binary. Does this require a TIP? I would hope not given that
> the TIP suggests third-parties could add their own tags.
> >
> > The primary use is in the test suite. Based on my manual testing, it is
> my belief that the Tk test suite actually never tests the embedded zip at
> all as it sets the TK_LIBRARY environment variable. Further, on macOS I
> *think* based on github CI logs, even tclsh zipfs builds fail to find the
> embedded ZIP and instead land up using the init.tcl found by searching up
> the directory hierarchy.
> >
> > The tag would help detect such cases, for example, by checking the value
> of $tcl_library corresponds to the expected result if the zipfs tag was
> present.
> >
> > (all this is based on my not being aware of any way to check at runtime
> if the build was configured with –enable-zipfs or –disable-zipfs. If
> someone can identify a method for this, the tag may not be needed)
> >
> > /Ashok
> > _______________________________________________ Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Adding a "zipfs" tag to the build-info command

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

Marc, it worth more than just mentioning 😊

 

This issue is exactly why I went down this path of testing if zipfs builds really are zipfs builds. Trying to track down why another fix was working on Linux and Windows  but not macOS, it turned out it had nothing to do with the fix. It was because the zipfs was not being found at all and it was falling back to the Tcl source library via TCL_LIBRARY in the test suite (which is yet another bug to be fixed – zipfs CI builds should be testing zipfs contained libraries not loading from the source directory). Not pleasant to debug on github CI.

 

Not knowing macos builds, it would be nice if someone who does know the platform disables zipfs for those scenarios. Hint, hint… It would have saved me literally a week’s worth of evenings.

 

/Ashok

 

From: Marc Culler <cul...@gm...> 
Sent: Thursday, August 7, 2025 7:32 PM
To: apn...@ya...
Cc: Harald Oehlmann <har...@el...>; apnmbx-public--- via Tcl-Core <tcl...@li...>
Subject: Re: [TCLCORE] Adding a "zipfs" tag to the build-info command

 

It may be worth mentioning that embedding the zip file does not work on macOS ARM systems.  Adding data at the end of a mach binary corrupts the binary, making it not loadable.  The is a hack which works on Intel systems by placing the zip file inside of an arch block  in a fat binary.  However,  on ARM systems every arch in a fat binary must be signed (possibly with an ad-hoc signature) and the signature must go at the end of the block.  Adding data at the end of a zip fle corrupts it.

 

So I would recommend always disabling embedding the zip file on macOS.  It just causes breakage.  It is currently disabled for framework builds but is the default for prefix builds.

 

- Marc

 

On Thu, Aug 7, 2025 at 12:58 AM apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > wrote:

Thanks Harald. Also, I see other tags are present that are not mentioned in any TIP so presumably no TIP required for this.

As an aside, zipfs is actually a misnomer as zipfs support and command is *always* present. The --disable-zipfs does not remove the functionality, it only disables the embedding of the zip file. I'll also use no-zipfs to be consistent with that.

/Ashok

-----Original Message-----
From: Harald Oehlmann <har...@el... <mailto:har...@el...> > 
Sent: Thursday, August 7, 2025 12:43 AM
To: apn...@ya... <mailto:apn...@ya...> ; apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> >
Subject: Re: [TCLCORE] Adding a "zipfs" tag to the build-info command

As Jan explained to me, the tags are extensable by nature.
But I don't see this in TIP599, as it says "may be extended in future".

As the "normal" value is no tag, you may add the tag "no-zfs", as "no-threads".

Take care,
Harald

> apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > hat am 06.08.2025 19:35 CEST geschrieben:
> 
> 
> I would like to add a “zipfs” tag to the {tcl,tk}::build-info command (TIP 599) that would indicate if the {tcl,tk}_library was embedded as a zip file into the binary. Does this require a TIP? I would hope not given that the TIP suggests third-parties could add their own tags.
> 
> The primary use is in the test suite. Based on my manual testing, it is my belief that the Tk test suite actually never tests the embedded zip at all as it sets the TK_LIBRARY environment variable. Further, on macOS I *think* based on github CI logs, even tclsh zipfs builds fail to find the embedded ZIP and instead land up using the init.tcl found by searching up the directory hierarchy.
> 
> The tag would help detect such cases, for example, by checking the value of $tcl_library corresponds to the expected result if the zipfs tag was present.
> 
> (all this is based on my not being aware of any way to check at runtime if the build was configured with –enable-zipfs or –disable-zipfs. If someone can identify a method for this, the tag may not be needed)
> 
> /Ashok
> _______________________________________________ Tcl-Core mailing list Tcl...@li... <mailto:Tcl...@li...>  https://lists.sourceforge.net/lists/listinfo/tcl-core



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

Re: [TCLCORE] Adding a "zipfs" tag to the build-info command

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

It may be worth mentioning that embedding the zip file does not work on
macOS ARM systems.  Adding data at the end of a mach binary corrupts the
binary, making it not loadable.  The is a hack which works on Intel systems
by placing the zip file inside of an arch block  in a fat binary.
However,  on ARM systems every arch in a fat binary must be signed
(possibly with an ad-hoc signature) and the signature must go at the end of
the block.  Adding data at the end of a zip fle corrupts it.

So I would recommend always disabling embedding the zip file on macOS.  It
just causes breakage.  It is currently disabled for framework builds but is
the default for prefix builds.

- Marc

On Thu, Aug 7, 2025 at 12:58 AM apnmbx-public--- via Tcl-Core <
tcl...@li...> wrote:

> Thanks Harald. Also, I see other tags are present that are not mentioned
> in any TIP so presumably no TIP required for this.
>
> As an aside, zipfs is actually a misnomer as zipfs support and command is
> *always* present. The --disable-zipfs does not remove the functionality, it
> only disables the embedding of the zip file. I'll also use no-zipfs to be
> consistent with that.
>
> /Ashok
>
> -----Original Message-----
> From: Harald Oehlmann <har...@el...>
> Sent: Thursday, August 7, 2025 12:43 AM
> To: apn...@ya...; apnmbx-public--- via Tcl-Core <
> tcl...@li...>
> Subject: Re: [TCLCORE] Adding a "zipfs" tag to the build-info command
>
> As Jan explained to me, the tags are extensable by nature.
> But I don't see this in TIP599, as it says "may be extended in future".
>
> As the "normal" value is no tag, you may add the tag "no-zfs", as
> "no-threads".
>
> Take care,
> Harald
>
> > apnmbx-public--- via Tcl-Core <tcl...@li...> hat am
> 06.08.2025 19:35 CEST geschrieben:
> >
> >
> > I would like to add a “zipfs” tag to the {tcl,tk}::build-info command
> (TIP 599) that would indicate if the {tcl,tk}_library was embedded as a zip
> file into the binary. Does this require a TIP? I would hope not given that
> the TIP suggests third-parties could add their own tags.
> >
> > The primary use is in the test suite. Based on my manual testing, it is
> my belief that the Tk test suite actually never tests the embedded zip at
> all as it sets the TK_LIBRARY environment variable. Further, on macOS I
> *think* based on github CI logs, even tclsh zipfs builds fail to find the
> embedded ZIP and instead land up using the init.tcl found by searching up
> the directory hierarchy.
> >
> > The tag would help detect such cases, for example, by checking the value
> of $tcl_library corresponds to the expected result if the zipfs tag was
> present.
> >
> > (all this is based on my not being aware of any way to check at runtime
> if the build was configured with –enable-zipfs or –disable-zipfs. If
> someone can identify a method for this, the tag may not be needed)
> >
> > /Ashok
> > _______________________________________________ Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Adding a "zipfs" tag to the build-info command

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

Thanks Harald. Also, I see other tags are present that are not mentioned in any TIP so presumably no TIP required for this.

As an aside, zipfs is actually a misnomer as zipfs support and command is *always* present. The --disable-zipfs does not remove the functionality, it only disables the embedding of the zip file. I'll also use no-zipfs to be consistent with that.

/Ashok

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Thursday, August 7, 2025 12:43 AM
To: apn...@ya...; apnmbx-public--- via Tcl-Core <tcl...@li...>
Subject: Re: [TCLCORE] Adding a "zipfs" tag to the build-info command

As Jan explained to me, the tags are extensable by nature.
But I don't see this in TIP599, as it says "may be extended in future".

As the "normal" value is no tag, you may add the tag "no-zfs", as "no-threads".

Take care,
Harald

> apnmbx-public--- via Tcl-Core <tcl...@li...> hat am 06.08.2025 19:35 CEST geschrieben:
> 
> 
> I would like to add a “zipfs” tag to the {tcl,tk}::build-info command (TIP 599) that would indicate if the {tcl,tk}_library was embedded as a zip file into the binary. Does this require a TIP? I would hope not given that the TIP suggests third-parties could add their own tags.
> 
> The primary use is in the test suite. Based on my manual testing, it is my belief that the Tk test suite actually never tests the embedded zip at all as it sets the TK_LIBRARY environment variable. Further, on macOS I *think* based on github CI logs, even tclsh zipfs builds fail to find the embedded ZIP and instead land up using the init.tcl found by searching up the directory hierarchy.
> 
> The tag would help detect such cases, for example, by checking the value of $tcl_library corresponds to the expected result if the zipfs tag was present.
> 
> (all this is based on my not being aware of any way to check at runtime if the build was configured with –enable-zipfs or –disable-zipfs. If someone can identify a method for this, the tag may not be needed)
> 
> /Ashok
> _______________________________________________ Tcl-Core mailing list Tcl...@li... https://lists.sourceforge.net/lists/listinfo/tcl-core