tcl-core — Tcl Core Team discussions about Tcl development

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

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

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

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

Great!

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

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

1. Write a plist serializer for Tcl.  (Big project, prone to errors, not
very useful in general.)
2. Write C code to directly convert an Objective C dictionary to a Tcl
dict.  (Big project, prone to errors, not very useful in general.)
3. Use existing Apple code to serialize an Objective C dict as JSON and use
existing, tested, easily available and lightweight Tcl code to decode a
json-encoded dict.  (Easy, low impact, fast, uses tested code in a
straightforward way, so very likely to be correct.)

I chose 3.

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

Indeed, that was my rationale.


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

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

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

You are very welcome.

- Marc

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

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

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

> hi,
>
> sorry for the long delay.
> real life got in the way.
>
> On 6/4/25 20:47, Marc Culler wrote:
> > *IOhannes m zmoelnig*: I hope you will build that branch and let me know
> if
> > it does what you were asking for.
>
> i finally got around to build and test your branch, and so far it does
> indeed everything I've asked for.
>
> i've yet to conduct some speed tests with our real application, to see
> whether all my problems (on this front) are indeed solved ;-)
>
>
> just a tiny nitpick: i find it a bit weird that i have to resort to an
> external library ("tcllib") in order to do something meaningful with the
> data returned by a core function ("::tk::mac::getInfoAsJSON").
>
> of course tcllib is pure Tcl, and if i only include the "json" package,
> the (size) overhead is marginal.
> and i totally see the beauty of the simplicity of the current
> implementation.
> but it feels a bit weird nevertheless.
>
> but then, i'm not a deep diver in the Tcl seas, and the community as
> such might find this a totally normal approach, in which case please
> ignore my feeling.
>
>
> anyhow: thanks a lot for the very quick response/implementation/help.
> (and special thanks for giving me instructions off-list on how to build
> from fossil)
>
> \o/
>
> gfamsdr
> IOhannes
>
>
> PS: please CC me in any replies, as i'm not subscribed to this mailinglist.
>
>

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

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

hi,

sorry for the long delay.
real life got in the way.

On 6/4/25 20:47, Marc Culler wrote:
> *IOhannes m zmoelnig*: I hope you will build that branch and let me know if
> it does what you were asking for.

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

i've yet to conduct some speed tests with our real application, to see 
whether all my problems (on this front) are indeed solved ;-)


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

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

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


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

\o/

gfamsdr
IOhannes


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

Re: [TCLCORE] Question on C casts

[Dipl. I. S. G. B. <se...@us...>]

 

Nope. 
It was not about addition but about multiplication, so "aDouble *
aDouble" (explicit) vs "aDouble * anInteger" (without cast).
Sure, as already written, the result of this is always double, but the
accuracy may depend on compiler, platform/cpu, level of optimization
etc.
And your assumption it shall always be the same is quite incorrect -
IIRC, there are several tickets already,
for instance - in [d2a3c5f80b] [2] it behaves different for ARM. 

Regards,
Serg. 

11.06.2025 07:29, apn...@ya... wrote: 

> Sergey, 
> 
> You example is not illustrative of the question I was asking. It compared a value uncast to a double with a value cast to a double. Obviously that will make a difference if the integer value crosses 53 (or whatever) bits available in a double. 
> 
> Rather, the question I was asking was whether there would be a difference in behavior between the *EXPLICIT* casts and implicit conversions. Perusing the C standard (Section 6.3.1.8), I am convinced any compiler, with optimization enabled or not, must handle "aDouble + anInteger" exactly as "aDouble + (double) anInteger". 
> 
> In any case, my purpose for asking was really whether I needed to revisit my code for such cases where I do not use a cast and add one. I have concluded it is not necessary. If someone wants to add (double) casts in such cases because it adds clarity for them, fine. 
> 
> /Ashok 
> 
> FROM: Dipl. Ing. Sergey G. Brester <se...@us...> 
> SENT: Tuesday, June 10, 2025 9:54 PM
> TO: apn...@ya...
> CC: tcl...@li...
> SUBJECT: Re: [TCLCORE] Question on C casts 
> 
> Although there is indeed implicit conversion (of result) to double, besides the clarifying purposes, 
> the explicit cast may be considered as certain stability "fix", because may avoid some compiler "optimizations" 
> and/or version dependencies...
> For instance if in certain cases two compilers may prefer multiplication double with integer in a different way
> (in one case with an integer, in another case with implicitly converted double), the behaviour and result may deviate.
> And then even some tests may fail, just because the accuracy of double is not the same than of a (wide)integer.
> 
> Here is an example of the "accuracy" issue as an illustration: 
> 
> % expr wide(0x200000000000001)
> 144115188075855873
> % expr wide(double(0x200000000000001))
> 144115188075855872 
> 
> So purely hypothetically I can imagine that an explicit pre-cast to double can behave more stable across compilers/optimizations/etc. 
> 
> Regards,
> Serg. 
> 
> 10.06.2025 17:23, apnmbx-public--- via Tcl-Core wrote: 
> 
>> In a recent commit to tclArithSeries.c on the core-9-0-branch, casts have been added in several places. For example, 
>> 
>> dend = dstart + (dstep * (len-1)); 
>> 
>> has become 
>> 
>> dend = dstart + (dstep * (double)(len-1)); 
>> 
>> Given dstep is a double, is that cast to double really necessary? I thought double ranked highest and all integer operands would be promoted to double automatically when the other operand was a double. Am I wrong that these casts are superfluous and unnecessary clutter? 
>> 
>> /Ashok 
>> 
>> _______________________________________________
>> 
>> Tcl-Core mailing list
>> 
>> Tcl...@li...
>> 
>> https://lists.sourceforge.net/lists/listinfo/tcl-core [1]
 

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/tcl-core
[2] https://core.tcl-lang.org/tcl/tktview/d2a3c5f80b

Re: [TCLCORE] Question on C casts

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

Sergey,

 

You example is not illustrative of the question I was asking. It compared a value uncast to a double with a value cast to a double. Obviously that will make a difference if the integer value crosses 53 (or whatever) bits available in a double.

 

Rather, the question I was asking was whether there would be a difference in behavior between the *explicit* casts and implicit conversions. Perusing the C standard (Section 6.3.1.8), I am convinced any compiler, with optimization enabled or not, must handle “aDouble + anInteger” exactly as “aDouble + (double) anInteger”.

 

In any case, my purpose for asking was really whether I needed to revisit my code for such cases where I do not use a cast and add one. I have concluded it is not necessary. If someone wants to add (double) casts in such cases because it adds clarity for them, fine.

 

/Ashok

 

From: Dipl. Ing. Sergey G. Brester <se...@us...> 
Sent: Tuesday, June 10, 2025 9:54 PM
To: apn...@ya...
Cc: tcl...@li...
Subject: Re: [TCLCORE] Question on C casts

 

Although there is indeed implicit conversion (of result) to double, besides the clarifying purposes, 
the explicit cast may be considered as certain stability "fix", because may avoid some compiler "optimizations" 
and/or version dependencies...
For instance if in certain cases two compilers may prefer multiplication double with integer in a different way
(in one case with an integer, in another case with implicitly converted double), the behaviour and result may deviate.
And then even some tests may fail, just because the accuracy of double is not the same than of a (wide)integer.

Here is an example of the "accuracy" issue as an illustration:

% expr wide(0x200000000000001)
144115188075855873
% expr wide(double(0x200000000000001))
144115188075855872

So purely hypothetically I can imagine that an explicit pre-cast to double can behave more stable across compilers/optimizations/etc.

Regards,
Serg.

10.06.2025 17:23, apnmbx-public--- via Tcl-Core wrote:

In a recent commit to tclArithSeries.c on the core-9-0-branch, casts have been added in several places. For example,

dend = dstart + (dstep * (len-1));

has become

dend = dstart + (dstep * (double)(len-1));

Given dstep is a double, is that cast to double really necessary? I thought double ranked highest and all integer operands would be promoted to double automatically when the other operand was a double. Am I wrong that these casts are superfluous and unnecessary clutter? 

 

/Ashok

 

 

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

Re: [TCLCORE] Question on C casts

[Dipl. I. S. G. B. <se...@us...>]

 

Although there is indeed implicit conversion (of result) to double,
besides the clarifying purposes, 
the explicit cast may be considered as certain stability "fix", because
may avoid some compiler "optimizations" 
and/or version dependencies...
For instance if in certain cases two compilers may prefer multiplication
double with integer in a different way
(in one case with an integer, in another case with implicitly converted
double), the behaviour and result may deviate.
And then even some tests may fail, just because the accuracy of double
is not the same than of a (wide)integer.

Here is an example of the "accuracy" issue as an illustration: 

% expr wide(0x200000000000001)
144115188075855873
% expr wide(double(0x200000000000001))
144115188075855872 

So purely hypothetically I can imagine that an explicit pre-cast to
double can behave more stable across compilers/optimizations/etc. 

Regards,
Serg. 

10.06.2025 17:23, apnmbx-public--- via Tcl-Core wrote: 

> In a recent commit to tclArithSeries.c on the core-9-0-branch, casts have been added in several places. For example, 
> 
> dend = dstart + (dstep * (len-1)); 
> 
> has become 
> 
> dend = dstart + (dstep * (double)(len-1)); 
> 
> Given dstep is a double, is that cast to double really necessary? I thought double ranked highest and all integer operands would be promoted to double automatically when the other operand was a double. Am I wrong that these casts are superfluous and unnecessary clutter? 
> 
> /Ashok 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [1]
 

Links:
------
[1] https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] New TIP #724

[Colin M. <col...@ya...>]

On 10/06/2025 16:42, Marc Culler wrote:
> Colin, you neglected to mention that the author of the TWAPI extension 
> is Ashok P. Nadkarni!

Well I assumed that everyone here knew that!

Colin.

Re: [TCLCORE] New TIP #724

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

Colin, you neglected to mention that the author of the TWAPI extension
is Ashok P. Nadkarni!

In any case, thanks to everyone's comments and the model provided by TWAPI,
I think I see what is the correct path forward.

* I will withdraw this TIP
* I will remove the `clipboard transient` command from the
clipboard_transient branch, leaving the fix for ticket [e94c8bc845] in
place.  I can then merge that as a simple bugfix.
* I will reuse the code that I remove to write a mac-specific extension
which implements the same behavior but in its own private command.
* I will hope that someone figures out why the clipboard clear command does
not work when the xclipboard app is running in the background.

- Marc







> Colin.
>

Re: [TCLCORE] New TIP #724

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

Afaik, you can disable all cloud clipboard uploads via a registry setting but not on a per-clipboard copy basis.

 

From: Marc Culler <cul...@gm...> 

 

Do any of the resident Windows experts have any idea of how this works, or how one might go about adding something to the Windows clipboard without having it end up in the Microsoft cloud?

 

- Marc

 

PS For linux it would at least be possible to study the source code of xclipboard (only 750 lines of code) to try to find out how it detects that the clipboard has changed.  How to get notified when the clipboard contents is pasted is another story.

Re: [TCLCORE] New TIP #724

[Colin M. <col...@ya...>]

On 10/06/2025 16:08, Marc Culler wrote:
>
> Do any of the resident Windows experts have any idea of how this 
> works, or how one might go about adding something to the Windows 
> clipboard without having it end up in the Microsoft cloud?
>
> - Marc
>
> PS For linux it would at least be possible to study the source code of 
> xclipboard (only 750 lines of code) to try to find out how it detects 
> that the clipboard has changed.  How to get notified when the 
> clipboard contents is pasted is another story.

For Windows, TWAPI has functions to manipulate the clipboard, including 
detecting when another application has changed it - see 
https://twapi.magicsplat.com/v5.0/clipboard.html#start_clipboard_monitor

Colin.

Re: [TCLCORE] New TIP #724

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

On Tue, Jun 10, 2025 at 1:01 AM Francois Vogel <fvo...@fr...> wrote:

> - Moreover, if 1. is a bugfix, why does it need to be TIPped? In other
> word, why isn't the TIP only propose 2. ? Is it because 2. is in fact the
> fix for 1. ?
>

 Essentially, yes.  But not exactly.

The major part of the behavior "added" by 2 was the broken behavior
reported in the ticket.  The additional part of 2 is that the clipboard is
cleared after the transient data is pasted.  Since I had already been
thinking about how one could write a password manager in Tk which would
allow pasting a password without storing it in the archives of one's
favorite clipboard manager, I noticed that the broken behavior was actually
useful, but in a different context.

- Marc

[TCLCORE] Question on C casts

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

In a recent commit to tclArithSeries.c on the core-9-0-branch, casts have
been added in several places. For example,

 

dend = dstart + (dstep * (len-1));

 

has become

 

dend = dstart + (dstep * (double)(len-1));

 

Given dstep is a double, is that cast to double really necessary? I thought
double ranked highest and all integer operands would be promoted to double
automatically when the other operand was a double. Am I wrong that these
casts are superfluous and unnecessary clutter? 

 

/Ashok

 

Re: [TCLCORE] New TIP #724

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

Am 10.06.2025 um 17:08 schrieb Marc Culler:
> Do any of the resident Windows experts have any idea of how this works, 
> or how one might go about adding something to the Windows clipboard 
> without having it end up in the Microsoft cloud?

We use KeePassXC on Windows.

The only security feature there regarding the clipboard is, that you can 
clear the clipboard after a timeout.

Apparently, there is no way to secure the clipboard and to use it with 
any application.
The clipboard is often used for keybord-based attacks...

Mac is the most advanced platform in regard of security. I am always 
amazed how far those folks think...

Sorry,
Harald

Re: [TCLCORE] New TIP #724

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

On Tue, Jun 10, 2025 at 1:01 AM Francois Vogel <fvo...@fr...> wrote:

> A few thoughts indeed:
>

Thank you, François! Let me respond to your comments one at a time.

> - The TIP does 1. fix ticket [e94c8bc845], and 2. add [clipboard
> transient]. Regarding 1. did someone check that this issue, which was
> reported for macOS, does not also affect the other two platforms and should
> be fixed for them as well?
>
Well, now you are opening a can of worms.  After you asked, I did some
checking and can give a partial answer, regarding linux.  The short answer
is: No [e94c8bc845] does not (exactly) happen with linux, but other worse
things happen.  The simplest way to view the issue on macOS was with the
Pasteboard Viewer app.  That app monitors the clipboard and prints out
whatever is currently in the clipboard.  On X11 there is a very similar
program which is part of the standard X distribution called xclipboard.
Based on your comment I decided to try checking the basic clipboard
operations on X11.  It shows that the append operations work fine on linux
- the macOS behavior does not occur with append.

That said, there is a completely different but equally bad bug in linux (I
am using Ubuntu 24.04 with X11 simulation via wayland).  It seems that the
clipboard clear command does not work at all on (this) linux.  Here is a
sample wish session showing the X11 clipboard working as expected:

% clipboard clear
% clipboard get
CLIPBOARD selection doesn't exist or form "STRING" not defined
% clipboard append aa
% clipboard get
aa
% clipboard append bb
% clipboard get
aabb
% clipboard clear
% clipboard get
CLIPBOARD selection doesn't exist or form "STRING" not defined

Now I do exactly the same thing, but with xclipboard running in the
background (displaying the clipboard contents in a small window):

% clipboard clear
% clipboard get
 some clip
% clipboard append aa
% clipboard get
aa
% clipboard append bb
% clipboard get
aabb
% clipboard clear
% clipboard get
aabb

Conclusion: On X11, when xclipboard is running the Tk clipboard clear
command does not clear the clipboard.  (The text "some clip" was  something
which I had put into the clipboard before starting wish.)

So I don't really know the full range of linux clipboard managers and how
they work, but xclipboard is a very basic version of a clipboard manager
(probably the starting point for many of the fancier ones) and its
interaction with Tk is also broken, but not in the same way as for macOS.

Is there a simple free clipboard manager for Windows along the lines of
xclipboard?

- Marc

Re: [TCLCORE] New TIP #724

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

On Tue, Jun 10, 2025 at 1:01 AM Francois Vogel <fvo...@fr...> wrote:

> - API: Any rationale about choosing [clipboard transient] instead of
> something else, e.g. adding a switch to [clipboard append] i.e. [clipboard
> append -transient]? What about -format and -type in the new command? Given
> the purpose of the TIP, I would have expected a new switch, not a new
> subcommand.
>
I would be OK with a switch, I guess.  But on which command?  The transient
behavior is partly an extension of clipboard append and partly an extension
of clipboard clear.  That is, it first does a clear, then does an append
(both without waking up the clipboard manager) then, within a callback
function used by the paste operation, it launches an after task which
clears the clipboard after the paste.

I think this is more of a new behavior than it is a modification of one of
the old behaviors.

- Marc

Re: [TCLCORE] New TIP #724

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

On Tue, Jun 10, 2025 at 1:01 AM Francois Vogel <fvo...@fr...> wrote:

> - Documentation changes are missing from the implementation branch.

Agreed

> - Test cases are also missing. I have adapted test clipboard-7.16 but this
> is not enough since it does not test the new feature nor the bugfix.
>
Thanks!  and agreed.

I planned to address these  issues if it looked like this TIP was going to
be able to get off the ground.

- Marc

Re: [TCLCORE] New TIP #724

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

On Tue, Jun 10, 2025 at 9:19 AM Marc Culler <cul...@gm...> wrote:

> Is there a simple free clipboard manager for Windows along the lines of
> xclipboard?
>

I guess the answer to this question is that Windows includes a built-in
clipboard manager which can be accessed by typing Windows-V.  And
apparently it ships the clips off into the Microsoft cloud.

Do any of the resident Windows experts have any idea of how this works, or
how one might go about adding something to the Windows clipboard without
having it end up in the Microsoft cloud?

- Marc

PS For linux it would at least be possible to study the source code of
xclipboard (only 750 lines of code) to try to find out how it detects that
the clipboard has changed.  How to get notified when the clipboard contents
is pasted is another story.

Re: [TCLCORE] New TIP #724

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

Hi Marc,

A few thoughts indeed:

- The TIP does 1. fix ticket [e94c8bc845], and 2. add [clipboard 
transient]. Regarding 1. did someone check that this issue, which was 
reported for macOS, does not also affect the other two platforms and 
should be fixed for them as well?

- Moreover, if 1. is a bugfix, why does it need to be TIPped? In other 
word, why isn't the TIP only propose 2. ? Is it because 2. is in fact 
the fix for 1. ?

- Regarding 2. [clipboard transient] I'm always reluctant to add 
functionality that in its essence is cross-platform (the need is the 
same on all platforms), but have an implementation for one platform 
only. I had to state this , despite I didn't research if and how this 
could be implemented for Linux and Windows, because I'm not comfortable 
with providing features that work on one platform only (unless this 
feature is a completely platform-specific thing, which I believe is not 
the case here).

- API: Any rationale about choosing [clipboard transient] instead of 
something else, e.g. adding a switch to [clipboard append] i.e. 
[clipboard append -transient]? What about -format and -type in the new 
command? Given the purpose of the TIP, I would have expected a new 
switch, not a new subcommand.

- Documentation changes are missing from the implementation branch.

- Test cases are also missing. I have adapted test clipboard-7.16 but 
this is not enough since it does not test the new feature nor the bugfix.

- I had a warning at build time (unused variable 'options'), which I 
have fixed. The branch now builds on Windows.

I didn't much look at the implementation.

Regards,

Francois

Le 07/06/2025 à 23:03, Marc Culler a écrit :
> I have just added TIP #724:Add subcommand "transient" to the Tk 
> clipboard command <https://core.tcl-lang.org/tips/doc/trunk/tip/724.md>;
> This is a call for discussion of the TIP.
>
> As is explained in detail in the TIP it does two things: it fixes 
> [e94c8bc845] <https://core.tcl-lang.org/tk/tktview/e94c8bc845>: "macOS 
> clipboard managers do not notice clipboard changes done by Tk" and it 
> adds a new "transient" subcommand to the clipboard command.  The new 
> command is intended to make copying a password from Tk and pasting it 
> into a web browser somewhat safer.  Unfortunately I have no idea how 
> to implement the new subcommand on linux or Windows.  Also the bug is 
> specific to Aqua.  So this TIP only affects Åqua. The TIP targets 9.1.
>
> Any thoughts?
>
> - Marc
>
>
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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

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

TIP #712: YES

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

[TCLCORE] June 10 2025 Tcl monthly virtual meetup notice

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

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

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

-- Steve

Re: [TCLCORE] Tcllib2.0 installer is broken on macOS

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

It turns out that this issue with default paths for the tcllib2.0 installer
was reported (by Ashok) on the tcllib fossil repository as ticket
[e5f3dfc055] <https://core.tcl-lang.org/tcllib/tktview/e5f3dfc055>.  The
ticket is over a year old now and is not assigned to anyone.

I suggest that we continue this conversation in that ticket.

- Marc

On Sun, Jun 8, 2025 at 5:45 PM Phillip Brooks <phi...@um...> wrote:

> I am currently working on setting up a Tcllib 2.0 installation on Windows,
> and it similarly has a useless default path for installation.  If you run
> installer.tcl with no arguments, it will install to:
>
> .\installer.tcl -simulate -no-gui
> Installing Tcllib 2.0
>         Dry run, simulation, no actual activity.
>
> You have chosen the following configuration ...
>
> Packages:      //zipfs:/lib/tcl/tcllib2.0
> Applications:  //zipfs:/lib/bin
> Examples:      //zipfs:/lib/bin/tcllib_examples2.0
> Documentation:
>
>         NROFF:  Not installed.
>         HTML:   //zipfs:/lib/tcllib_doc
>
> //zipfs:/lib isn't very useful as a default.
>
> Also, it is very cumbersome to change the installation targets since each
> part of the install has a separate switch controlling the path.  It seems
> to me like they should have a common root controllable by the switch.  The
> default seems more like it should be something like $ProgramFiles/Tcl or
> the parent of the location of the bin/tclsh that is invoking the installer.
>
> Phil
>
>
> On Sun, Jun 8, 2025 at 10:59 AM Marc Culler <cul...@gm...> wrote:
>
>> It seems that ::tcl_pkgPath does not exist on Windows and contains only
>> one item (/usr/local/lib) on linux,
>> so the installer.tcl script would work in most contexts if it used the
>> first element of ::tcl_pkgPath instead of using the last one.
>>
>> - Marc
>>
>> On Sun, Jun 8, 2025 at 10:43 AM Marc Culler <cul...@gm...> wrote:
>>
>>> So, it turns out that the "ridiculous" path
>>> /Library/Frameworks/Tk.framework/Versions  was added to ::tclPkgPath
>>> by ME!
>>>
>>> Apparently I did that in order to allow Tcl to find Tk when there are
>>> multiple versions of Tcl installed [1562e10c58]
>>> <https://core.tcl-lang.org/tk/tktview/1562e10c58>.  That directory is
>>> perhaps not a ridiculous place to look for a package, if the package
>>> happens to be Tk.  (I am not certain why that should be the case, however.
>>> Would someone who understands the process by which Tcl finds Tk please tell
>>> me whether that even makes sense?)
>>>
>>> Nonetheless, that path is certainly is a ridiculous place to install
>>> Tcllib.
>>>
>>> I presumably put that path at the end of ::tclPkgPath because it was
>>> intended to be a last resort
>>>
>>> I did not suspect that the Tcllib installer would choose to use the last
>>> path on the list instead of the first.
>>>
>>> The other strange part of the path (~/Library/Tcl:/Library/Tcl:~/Library/Frameworks:/Library/Frameworks),
>>> which is strange because I know of no standard installation process which
>>> would create those directories, appears to be older, perhaps a vestige from
>>> a time when installing Tcl in ~/Library was common.
>>>
>>> So, once again, these two core principles of software development have
>>> been reaffirmed:
>>>
>>> * It is always something;
>>> * Nothing gets fixed without breaking something else.
>>>
>>> - Marc
>>>
>>> On Sun, Jun 8, 2025 at 9:16 AM Marc Culler <cul...@gm...> wrote:
>>>
>>>> I was surprised, when I tried to install Tcllib2.0,  to learn that it
>>>> had been released without anyone having tested it on macOS.  The script
>>>> installer.tcl wants to install the packages at the path:
>>>>     /Library/Frameworks/Tk.framework/Versions
>>>> which is completely ridiculous.
>>>>
>>>> The correct path (for Tcl 9.1) is:
>>>>    /Library/Frameworks/Tcl.framework/Versions/9.1/Resources/Scripts
>>>>
>>>> The error occurs on line 298 of installer.tcl where you find this code:
>>>>            if {[catch {set libdir [lindex $::tcl_pkgPath end]}]} {
>>>>                 set libdir [file dirname [info library]]
>>>>
>>>> For some bizarre reason it is choosing to use the last element of the
>>>> list ::tcl_pkgPath.
>>>>
>>>> When I inspect that list with tclsh9.1 I see:
>>>> % puts "$::tcl_pkgPath"
>>>> /Library/Frameworks/Tcl.framework/Versions/9.1/Resources/Scripts
>>>> /Users/culler/Library/Tcl /Library/Tcl /Users/culler/Library/Frameworks
>>>> /Library/Frameworks /Library/Frameworks/Tk.framework/Versions
>>>>
>>>> The last item, sure enough, is the same completely inappropriate
>>>> location for packages that is shown in the installer gui.
>>>>
>>>> The subdirectories of the Versions directory in a framework are
>>>> supposed to be the version numbers that are installed in the framework
>>>> (plus a symlink Current which points to the version currently in use).
>>>> Installing a package in there would completely break Apple's specification
>>>> for the structure of a framework bundle.
>>>>
>>>> The second and third items on the list are also ridiculous, since there
>>>> is no straightforward installation process which would even create those
>>>> paths.  They do not exist on my system.
>>>>
>>>> The correct path is the first item on the list.  The other three should
>>>> not be in ::tcl_pkgPath at all, in my opinion.
>>>>
>>>> What peculiar logic led to the idea that the last element of
>>>> ::tcl_pkgPath would be the correct choice?
>>>> And what design choice led to the other crazy paths being in the list
>>>> at all?
>>>>
>>>> - Marc
>>>>
>>>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>

Re: [TCLCORE] Tcllib2.0 installer is broken on macOS

[Phillip B. <phi...@um...>]

I am currently working on setting up a Tcllib 2.0 installation on Windows,
and it similarly has a useless default path for installation.  If you run
installer.tcl with no arguments, it will install to:

.\installer.tcl -simulate -no-gui
Installing Tcllib 2.0
        Dry run, simulation, no actual activity.

You have chosen the following configuration ...

Packages:      //zipfs:/lib/tcl/tcllib2.0
Applications:  //zipfs:/lib/bin
Examples:      //zipfs:/lib/bin/tcllib_examples2.0
Documentation:

        NROFF:  Not installed.
        HTML:   //zipfs:/lib/tcllib_doc

//zipfs:/lib isn't very useful as a default.

Also, it is very cumbersome to change the installation targets since each
part of the install has a separate switch controlling the path.  It seems
to me like they should have a common root controllable by the switch.  The
default seems more like it should be something like $ProgramFiles/Tcl or
the parent of the location of the bin/tclsh that is invoking the installer.

Phil


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

> It seems that ::tcl_pkgPath does not exist on Windows and contains only
> one item (/usr/local/lib) on linux,
> so the installer.tcl script would work in most contexts if it used the
> first element of ::tcl_pkgPath instead of using the last one.
>
> - Marc
>
> On Sun, Jun 8, 2025 at 10:43 AM Marc Culler <cul...@gm...> wrote:
>
>> So, it turns out that the "ridiculous" path
>> /Library/Frameworks/Tk.framework/Versions  was added to ::tclPkgPath
>> by ME!
>>
>> Apparently I did that in order to allow Tcl to find Tk when there are
>> multiple versions of Tcl installed [1562e10c58]
>> <https://core.tcl-lang.org/tk/tktview/1562e10c58>.  That directory is
>> perhaps not a ridiculous place to look for a package, if the package
>> happens to be Tk.  (I am not certain why that should be the case, however.
>> Would someone who understands the process by which Tcl finds Tk please tell
>> me whether that even makes sense?)
>>
>> Nonetheless, that path is certainly is a ridiculous place to install
>> Tcllib.
>>
>> I presumably put that path at the end of ::tclPkgPath because it was
>> intended to be a last resort
>>
>> I did not suspect that the Tcllib installer would choose to use the last
>> path on the list instead of the first.
>>
>> The other strange part of the path (~/Library/Tcl:/Library/Tcl:~/Library/Frameworks:/Library/Frameworks),
>> which is strange because I know of no standard installation process which
>> would create those directories, appears to be older, perhaps a vestige from
>> a time when installing Tcl in ~/Library was common.
>>
>> So, once again, these two core principles of software development have
>> been reaffirmed:
>>
>> * It is always something;
>> * Nothing gets fixed without breaking something else.
>>
>> - Marc
>>
>> On Sun, Jun 8, 2025 at 9:16 AM Marc Culler <cul...@gm...> wrote:
>>
>>> I was surprised, when I tried to install Tcllib2.0,  to learn that it
>>> had been released without anyone having tested it on macOS.  The script
>>> installer.tcl wants to install the packages at the path:
>>>     /Library/Frameworks/Tk.framework/Versions
>>> which is completely ridiculous.
>>>
>>> The correct path (for Tcl 9.1) is:
>>>    /Library/Frameworks/Tcl.framework/Versions/9.1/Resources/Scripts
>>>
>>> The error occurs on line 298 of installer.tcl where you find this code:
>>>            if {[catch {set libdir [lindex $::tcl_pkgPath end]}]} {
>>>                 set libdir [file dirname [info library]]
>>>
>>> For some bizarre reason it is choosing to use the last element of the
>>> list ::tcl_pkgPath.
>>>
>>> When I inspect that list with tclsh9.1 I see:
>>> % puts "$::tcl_pkgPath"
>>> /Library/Frameworks/Tcl.framework/Versions/9.1/Resources/Scripts
>>> /Users/culler/Library/Tcl /Library/Tcl /Users/culler/Library/Frameworks
>>> /Library/Frameworks /Library/Frameworks/Tk.framework/Versions
>>>
>>> The last item, sure enough, is the same completely inappropriate
>>> location for packages that is shown in the installer gui.
>>>
>>> The subdirectories of the Versions directory in a framework are supposed
>>> to be the version numbers that are installed in the framework (plus a
>>> symlink Current which points to the version currently in use).  Installing
>>> a package in there would completely break Apple's specification for the
>>> structure of a framework bundle.
>>>
>>> The second and third items on the list are also ridiculous, since there
>>> is no straightforward installation process which would even create those
>>> paths.  They do not exist on my system.
>>>
>>> The correct path is the first item on the list.  The other three should
>>> not be in ::tcl_pkgPath at all, in my opinion.
>>>
>>> What peculiar logic led to the idea that the last element of
>>> ::tcl_pkgPath would be the correct choice?
>>> And what design choice led to the other crazy paths being in the list at
>>> all?
>>>
>>> - Marc
>>>
>>> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Tcllib2.0 installer is broken on macOS

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

It seems that ::tcl_pkgPath does not exist on Windows and contains only one
item (/usr/local/lib) on linux,
so the installer.tcl script would work in most contexts if it used the
first element of ::tcl_pkgPath instead of using the last one.

- Marc

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

> So, it turns out that the "ridiculous" path
> /Library/Frameworks/Tk.framework/Versions  was added to ::tclPkgPath
> by ME!
>
> Apparently I did that in order to allow Tcl to find Tk when there are
> multiple versions of Tcl installed [1562e10c58]
> <https://core.tcl-lang.org/tk/tktview/1562e10c58>.  That directory is
> perhaps not a ridiculous place to look for a package, if the package
> happens to be Tk.  (I am not certain why that should be the case, however.
> Would someone who understands the process by which Tcl finds Tk please tell
> me whether that even makes sense?)
>
> Nonetheless, that path is certainly is a ridiculous place to install
> Tcllib.
>
> I presumably put that path at the end of ::tclPkgPath because it was
> intended to be a last resort
>
> I did not suspect that the Tcllib installer would choose to use the last
> path on the list instead of the first.
>
> The other strange part of the path (~/Library/Tcl:/Library/Tcl:~/Library/Frameworks:/Library/Frameworks),
> which is strange because I know of no standard installation process which
> would create those directories, appears to be older, perhaps a vestige from
> a time when installing Tcl in ~/Library was common.
>
> So, once again, these two core principles of software development have
> been reaffirmed:
>
> * It is always something;
> * Nothing gets fixed without breaking something else.
>
> - Marc
>
> On Sun, Jun 8, 2025 at 9:16 AM Marc Culler <cul...@gm...> wrote:
>
>> I was surprised, when I tried to install Tcllib2.0,  to learn that it had
>> been released without anyone having tested it on macOS.  The script
>> installer.tcl wants to install the packages at the path:
>>     /Library/Frameworks/Tk.framework/Versions
>> which is completely ridiculous.
>>
>> The correct path (for Tcl 9.1) is:
>>    /Library/Frameworks/Tcl.framework/Versions/9.1/Resources/Scripts
>>
>> The error occurs on line 298 of installer.tcl where you find this code:
>>            if {[catch {set libdir [lindex $::tcl_pkgPath end]}]} {
>>                 set libdir [file dirname [info library]]
>>
>> For some bizarre reason it is choosing to use the last element of the
>> list ::tcl_pkgPath.
>>
>> When I inspect that list with tclsh9.1 I see:
>> % puts "$::tcl_pkgPath"
>> /Library/Frameworks/Tcl.framework/Versions/9.1/Resources/Scripts
>> /Users/culler/Library/Tcl /Library/Tcl /Users/culler/Library/Frameworks
>> /Library/Frameworks /Library/Frameworks/Tk.framework/Versions
>>
>> The last item, sure enough, is the same completely inappropriate location
>> for packages that is shown in the installer gui.
>>
>> The subdirectories of the Versions directory in a framework are supposed
>> to be the version numbers that are installed in the framework (plus a
>> symlink Current which points to the version currently in use).  Installing
>> a package in there would completely break Apple's specification for the
>> structure of a framework bundle.
>>
>> The second and third items on the list are also ridiculous, since there
>> is no straightforward installation process which would even create those
>> paths.  They do not exist on my system.
>>
>> The correct path is the first item on the list.  The other three should
>> not be in ::tcl_pkgPath at all, in my opinion.
>>
>> What peculiar logic led to the idea that the last element of
>> ::tcl_pkgPath would be the correct choice?
>> And what design choice led to the other crazy paths being in the list at
>> all?
>>
>> - Marc
>>
>>

[TCLCORE] TIP 649

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

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] New TIP #724

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

The security model of X11 doesn't really allow for marking the contents of the clipboard as transient as such, though the clipboard owner may naturally refuse to transfer it more than once, and may vet the identity of the part to which the contents are transferred. I've never heard of anyone bothering to do that, but it is possible. (There's more of a security model in Wayland, but we don't support that, and the security model there is an awful mess.)

Don't know if there's anything like that in Windows.

Donal.

-------- Original message --------
From: Marc Culler <cul...@gm...>
Date: 07/06/2025 22:04 (GMT+00:00)
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] New TIP #724

Unfortunately I have no idea how to implement the new subcommand on linux or Windows.