tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP 716 ready for comments

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

Harald,

 

Could you try the tip-716 branch to see if fixes your print dll umlaut issue?

 

Also, the encoding user command is documented. “Correspondingly, a new command encoding user will be added on all platforms and will return the result of Tcl_GetEncodingNameForUser.” I suppose I should add the syntax synopsis for both the C API and the command.

 

I am not particularly tied to use of environment variables but note Tcl does use several, even on Windows.

 

/Ashok

 

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Monday, April 14, 2025 5:23 PM
To: tcl...@li...
Subject: Re: [TCLCORE] TIP 716 ready for comments

 

Ashok,

thanks for the great initiative.

You are always our saver of preliminary decisions, like Size_t and 

ptrDiff_t.

 

I am personally trapped in two senses:

- my own printing dll's use 8 bit API and don't print German Umlauts 

(äöüÄÖÜ) any more.

- there is no way on Tcl 9 on the script level to find the system 

encoding of Tcl 8.6. So, sourcing files using "source -encoding native" 

is not possible, because "native" is not known on the script level. You 

mention a new command "[encoding user]" in an example. I suppose, this 

will solve this issue and "encoding user" will return what "encoding 

system" returns in 8.6.

 

About the TIP:

- GREAT !!!!

- describe "encoding user"

- On Windows, environment variables are less comment. As a consequence, 

using an environment variable for the default set of "exec -encoding" 

is, at least, strange on Windows. This is a minor point. IMHO it is aso 

a security risk, that an application does not work as expected due to 

external influence.

 

Thanks for ALL !

Harald

 

Am 14.04.2025 um 06:51 schrieb apnmbx-public--- via Tcl-Core:

> TIP 716: New command "encoding user", remove UTF-8 manifest setting on 

> Windows < <https://core.tcl-lang.org/tips/doc/trunk/tip/716.md> https://core.tcl-lang.org/tips/doc/trunk/tip/716.md> is ready 

> for comments. It proposes reversion of a change made in 9.0 to tclsh and 

> wish Windows manifests while keeping compatibility with 9.0.{0,1}.

> 

> Apologies for my usual verbosity, but when I brought this up in the 

> mailing list prior to the previous release, the comments wandered into 

> why UTF-8 should be the default. I've tried to better explain that is 

> not the issue.

> 

> I will point out that the original change to the manifest, which made 

> UTF-8 the default on Win 10 1903+ and Win 11, should have been TIP'ed as 

> it overrides user settings and is a change in behavior of a public API 

> and command. It's water under the bridge now that 9.0 has shipped so the 

> TIP maintains status quo and only changes the implementation. It also 

> adds a new /encoding user/ command and an /-encoding/ option to /exec / 

> as a workaround for compatibility issues introduced by forcing a UTF-8 

> default.

> 

> Note the implementation in the tip-716 branch is mostly complete but not 

> ready for review. I am only looking for comments on the proposal before 

> proceeding further with tests and docs.

> 

> /Ashok

> 

Re: [TCLCORE] TIP 716 ready for comments

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

Ashok,
thanks for the great initiative.
You are always our saver of preliminary decisions, like Size_t and 
ptrDiff_t.

I am personally trapped in two senses:
- my own printing dll's use 8 bit API and don't print German Umlauts 
(äöüÄÖÜ) any more.
- there is no way on Tcl 9 on the script level to find the system 
encoding of Tcl 8.6. So, sourcing files using "source -encoding native" 
is not possible, because "native" is not known on the script level. You 
mention a new command "[encoding user]" in an example. I suppose, this 
will solve this issue and "encoding user" will return what "encoding 
system" returns in 8.6.

About the TIP:
- GREAT !!!!
- describe "encoding user"
- On Windows, environment variables are less comment. As a consequence, 
using an environment variable for the default set of "exec -encoding" 
is, at least, strange on Windows. This is a minor point. IMHO it is aso 
a security risk, that an application does not work as expected due to 
external influence.

Thanks for ALL !
Harald

Am 14.04.2025 um 06:51 schrieb apnmbx-public--- via Tcl-Core:
> TIP 716: New command "encoding user", remove UTF-8 manifest setting on 
> Windows <https://core.tcl-lang.org/tips/doc/trunk/tip/716.md> is ready 
> for comments. It proposes reversion of a change made in 9.0 to tclsh and 
> wish Windows manifests while keeping compatibility with 9.0.{0,1}.
> 
> Apologies for my usual verbosity, but when I brought this up in the 
> mailing list prior to the previous release, the comments wandered into 
> why UTF-8 should be the default. I've tried to better explain that is 
> not the issue.
> 
> I will point out that the original change to the manifest, which made 
> UTF-8 the default on Win 10 1903+ and Win 11, should have been TIP'ed as 
> it overrides user settings and is a change in behavior of a public API 
> and command. It's water under the bridge now that 9.0 has shipped so the 
> TIP maintains status quo and only changes the implementation. It also 
> adds a new /encoding user/ command and an /-encoding/ option to /exec / 
> as a workaround for compatibility issues introduced by forcing a UTF-8 
> default.
> 
> Note the implementation in the tip-716 branch is mostly complete but not 
> ready for review. I am only looking for comments on the proposal before 
> proceeding further with tests and docs.
> 
> /Ashok
> 

Re: [TCLCORE] TIP 714: image driver photo formats

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

Dear group,

sorry, I was wrong in one point of my message:

Am 09.04.2025 um 14:41 schrieb Harald Oehlmann:
> Dear Emiliano,
> 
> thanks for the message. Please allow me to reply inline.
> 
> Am 09.04.2025 um 02:25 schrieb Emiliano:
>> On Thu, 3 Apr 2025 10:41:53 +0200
>> Harald Oehlmann <har...@el...> wrote:
>>
>> IMO this is the opportunity to fix some issues wrt the image type 
>> registration
>> and its implementation.
> 
> Yes, great !
> 
>> In this case, the list is walked from the start adding the .name 
>> member of
>> the Tk_ImageInfo structure until the .nextPtr member is null. Same with
>> [image create $type]: the list is walked until $type matches the .name
>> member. The result is
>>
>> * [image types] always grows, and can get duplicates.
>> * the first (last added) of the duplicated type names shadows the 
>> later ones.
>>
>> This last fact is easy to test
>>
>>    % image create bitmap
>>    Violación de segmento (`core' generado)
>>
>> I have a fix for the duplicated names issue. Since TIP#714 implements a
>> hash table to hold the registered Tk_ImageInfoProc, I've changed the
>> linked list for a(n internal) wrapper struct to hold both Tk_ImageType 
>> and
>> Tk_ImageInfoProc, and using the hash table to hold these wrappers.
>> If there are no questions, I'm going to commit it in a couple days in the
>> tip-714-alt branch, so it can be reviewed.
> 
> Thank you for working on this. IMHO, this is a bug of the current 
> implementation and is not TIP 714 related.
> Could you open a bug ticket and provide the fix there?
> I prefer to have the discussion archived somewhere and a ticket is a 
> great place.
> 
> I think, even with the current data structure, it would be possible to 
> avoid double registrations, but the list must be scanned for the name 
> entry. Currently, Tk_CreateImageType can not return an error on double 
> registration.
> 
>> Another issue identified has to do with the fact that image type managers
>> are implemented at thread level; newly registered image types are visible
>> in all interpreters in the same thread. Also, there's no provision to 
>> remove
>> an image type. These gotchas makes image type managers not well suited
>> to be implemented as extensions, since extensions are limited to
>> the interpreter which loads them (is this assumption true?). 
>> Interactively:
>>
>>    # loading in a child interp, visible from parent interp
>>    $ wish9.1
>>    % interp create i
>>    i
>>    % i eval {load ./libbadimage.so}
>>    % i eval {image types}
>>    bitmap photo bitmap
>>    % image types
>>    bitmap photo bitmap
>>
>> But this is subject for another TIP. Also, the photo image type format 
>> list
>> is also thread data; [package require ::img::jpeg] makes Tk photo image
>> supports jpeg in all the interpreters in the thread in which Tk is 
>> loaded.
> 
> I think, the thread issue is also a bug and may be handled in a ticket.
> Tk is slowly getting thread safe and this is another step in this 
> direction.

This is wrong. Making the Tk_CreateImageType only register for the 
current thread is a breaking change.
One may argue that there is nothing in the documentation about threads.
Yes, this was created in times where Tk was not jet thread aware.

Nevertheless, I get the impression that we need a successor for 
Tk_CreateImageType with the following features:

- only for current thread
- may return an error (already registered)
- maybe should make a copy of the passed data
- should have a version in the passed data structure for later extension
- may pass a thread local storage (don't know anything on this, but I 
see, that the image function may need this)
- contains an unregister call (which may fail).

So many questions...

Thanks for all,
Harald

---

I feel currently totally desesperate that we may handle the current 
issues. There are 5 Wizard points by Christian we should handle (3 in 
the recent mail + tksvg + tdbc::sqlite3).
And the "low hanging fruit" "image photo formats" is evolving to a mega 
project. As the final image goal is to load into tcl without tk, it 
feels even more impossible to reach...

[TCLCORE] TIP 716 ready for comments

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

 <https://core.tcl-lang.org/tips/doc/trunk/tip/716.md> TIP 716: New command
"encoding user", remove UTF-8 manifest setting on Windows is ready for
comments. It proposes reversion of a change made in 9.0 to tclsh and wish
Windows manifests while keeping compatibility with 9.0.{0,1}.

 

Apologies for my usual verbosity, but when I brought this up in the mailing
list prior to the previous release, the comments wandered into why UTF-8
should be the default. I've tried to better explain that is not the issue.

 

I will point out that the original change to the manifest, which made UTF-8
the default on Win 10 1903+ and Win 11, should have been TIP'ed as it
overrides user settings and is a change in behavior of a public API and
command. It's water under the bridge now that 9.0 has shipped so the TIP
maintains status quo and only changes the implementation. It also adds a new
encoding user command and an -encoding option to exec as a workaround for
compatibility issues introduced by forcing a UTF-8 default.

 

Note the implementation in the tip-716 branch is mostly complete but not
ready for review. I am only looking for comments on the proposal before
proceeding further with tests and docs.

 

/Ashok

 

 

[TCLCORE] Wiki post on work areas and futures

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

Earl Johnson's post
<https://wiki.tcl-lang.org/page/Where+Tcl+Needs+Work%2FWorkers>  on the wiki
asked about areas where folks could contribute to Tcl/Tk and its ecosystem.
I added my own thoughts there and hope others can do the same as well as
comment on what they feel should be the priorities.

 

It would help planning future development as well as coordinate package
contributors.

 

/Ashok

Re: [TCLCORE] Any plans on a tk scrollable frame and toplevel in the core?

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

On Fri, 11 Apr 2025 21:48:20 -0700
EricT <tw...@gm...> wrote:

> With 9.0 out the door, I was thinking that this might be a good time
> to consider some of the "missing" pieces in the tk and ttk widget set.
> 
> I think the most useful missing piece would be a built in scrollable
> frame and/or toplevel. If there's a TIP that has already requested
> this, then feel free to ignore this email. And if perchance, it's
> already there, then perhaps it just would need to be more prominent in
> the documentation. At least, I couldn't find one.

See Nemethi's excellent scrollutils package. In particular scrollutil::scrollarea and scrollutil::scollableframe

https://www.nemethi.de/scrollutil/index.html

You can download it and install from the above URL or as part of tklib

https://core.tcl-lang.org/tklib

Regards 
Emiliano

Re: [TCLCORE] Any plans on a tk scrollable frame and toplevel in the core?

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

<div><img width="1" height="1" src='https://fedbdhd.r.tsp1-brevo.net/tr/op/o--MPZd16aGgLJd_JmSpAGx-YVg_lqqsKSHxewge_RaO1rmr3s4F1KLxU_CaQD5oiT2RzS_guWcg7Q1-8PABA1T81S4o4hOfnmGiPuN2OziXDUY_xH8sUvwvAcUNEvEcDoXKzMAc2WCZZm0QXqAsF0GA98pK0UW1Zg5v-w2BOBWPH5RZRsZk5e4fmM_P5IyRkr91BvRKpf3W0KdmCsd04gnHEdAR' /></div>Eric,<br/><br/>Would you be willing to put together an implementation and TIP for a scrollable frame?<br/><br/>Thanks <br/>Kevin<br/><br/>> On Apr 12, 2025, at 7:56 AM, KEITH NASH <k.j...@us...> wrote:<br/>> <br/>> Hi Eric,<br/>> <br/>> If something like a scrollable frame is added to Tk, script form has the<br/>> advantage that if it is not exactly what the developer needs, any Tcl/Tk<br/>> developer can copy it and modify it for their purpose.<br/>> <br/>> Suggestions for possible alternatives to expanding the Tk core:<br/>> <br/>> 1. Improve the Wiki coverage of the subject, which is sometimes out of date<br/>> and confusing.  Whenever anybody figures something out, they could make sure<br/>> the knowledge is recorded on the Wiki.<br/>> <br/>> 2. Add an "Extensions" section to some Tcl/Tk man pages, describing the<br/>> relevant extensions that are available in Tcllib, Tklib and related packages<br/>> that are hosted on core.tcl-lang.org and have oversight by the Core Team.<br/>> <br/>> This is not intended to shoehorn the entire documentation for Tcllib, Tklib<br/>> into the docs for Tcl/Tk, but only a brief reference to a few packages that<br/>> are natural extensions of the Tcl/Tk facilities.  This suggestion might<br/>> require a TIP to expand the scope of the documentation.<br/>> <br/>> Keith.<br/>> <br/>> ------ Original Message ------<br/>> Received: Sat, 12 Apr 2025 05:50:10 AM BST<br/>> From: EricT <tw...@gm...><br/>> To: Tcl...@li...<br/>> Subject: [TCLCORE] Any plans on a tk scrollable frame and toplevel in the<br/>> core?<br/>> <br/>>> With 9.0 out the door, I was thinking that this might be a good time<br/>>> to consider some of the "missing" pieces in the tk and ttk widget set.<br/>>> <br/>>> I think the most useful missing piece would be a built in scrollable<br/>>> frame and/or toplevel. If there's a TIP that has already requested<br/>>> this, then feel free to ignore this email. And if perchance, it's<br/>>> already there, then perhaps it just would need to be more prominent in<br/>>> the documentation. At least, I couldn't find one.<br/>>> <br/>>> When I needed a scrollable frame, I found there are many versions on<br/>>> the wiki, but sometimes having too many choices makes the task harder.<br/>>> There once were also several notebook widgets, and the one I chose, in<br/>>> bwidgets, ended up not being the best choice. Had I known about<br/>>> ttk::notebook, I would certainly have looked at that first.<br/>>> <br/>>> Anyway, I think the one at<br/>>> https://wiki.tcl-lang.org/page/A+scrolled+frame by Paul Walton is a<br/>>> quite good one, although I didn't quite understand why I needed two<br/>>> frames in the example.<br/>>> <br/>>> There's also apparently a modified version just below it as well. And<br/>>> that's the one I tried because it also had 2 smallish examples.<br/>>> <br/>>> Paul's version is nice in that you can pack the scrollable frame, but<br/>>> the scrollable items can be packed, grid'd or placed. I suspect you<br/>>> could grid the frame as well, but I wanted to pack it.<br/>>> <br/>>> Bottom line, I believe having this widget in the Tk core would be<br/>>> quite useful, and it might even just be added there in script form.<br/>>> But having one supported version that was in the "manual" would be<br/>>> great and would also provide leverage for all the other languages that<br/>>> use the Tk toolkit.<br/>>> <br/>>> thanks<br/>>> <br/>>> Eric<br/>>> <br/>> <br/>>> <br/>> <br/>>> _______________________________________________<br/>>> Tcl-Core mailing list<br/>>> Tcl...@li...<br/>>> https://lists.sourceforge.net/lists/listinfo/tcl-core<br/>>> <br/>> <br/>> <br/>> <br/>> <br/>> _______________________________________________<br/>> Tcl-Core mailing list<br/>> Tcl...@li...<br/>> https://lists.sourceforge.net/lists/listinfo/tcl-core<br/>

Re: [TCLCORE] Any plans on a tk scrollable frame and toplevel in the core?

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

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/ReCj7X0JYPs1CXaHKJmSTNvaxHHnsYM-gBK2b_20Gr5LaWxCMlXgNRupM_3LArz-mceWhgm8s1StxKMatwXgjYTkFhJsBEEPbROLAmvYfehZzMRSDqht512Ed35ZTaUgpJdMgAi4fVZL3hGR6ui-y0750FQ89Tx7tLR_KfSHwaFPrQmOOAtDPqThg7_k6J_zv9HlXb3KYvbSQMKLM-NdgBsNLtn9vSni' /><div dir="ltr"></div><div dir="ltr">TkDND is a great extension for native drag and drop. The Windows code is written in C++ which would be hard to include in the core.&nbsp;</div><div dir="ltr"><br><blockquote type="cite">On Apr 12, 2025, at 7:08 AM, Patrick May &lt;dus...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="auto">Hello,&nbsp;<div dir="auto"><br><div dir="auto">I agree, and I'd like to take this opportunity to say, I think core Tk is missing some features that might be considered basic today, which other competing GUI toolkits probably have built in.</div><div dir="auto"><br></div><div dir="auto">I'd suggest that having these features in the core might be a good idea:</div><div dir="auto"><br></div><div dir="auto">- scrollable widget containers / scrollable frames</div><div dir="auto"><br></div><div dir="auto">- drag and drop</div><div dir="auto"><br></div><div dir="auto">I recently made a small utility that needed drag n drop. I had to load an extension for that, and it complicated getting it to work across platforms. I think I got it working on Linux and windows but not macOS.</div><div dir="auto"><br></div><div dir="auto">Regards, PM</div><div dir="auto"><br></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sat, 12 Apr 2025, 05:49 EricT, &lt;<a href="mailto:tw...@gm...">tw...@gm...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<pre style="color:rgb(0,0,0);background-color:rgb(255,255,255);font-family:&quot;Consolas&quot;;font-size:14pt;font-weight:normal;font-style:normal;text-decoration-line:none;white-space:pre-wrap">With 9.0 out the door, I was thinking that this might be a good time to consider some of the "missing" pieces in the <span style="text-decoration-line:underline;text-decoration-color:rgb(255,0,0);text-decoration-style:wavy">tk</span> and <span style="text-decoration-line:underline;text-decoration-color:rgb(255,0,0);text-decoration-style:wavy">ttk</span> widget set.

I think the most useful missing piece would be a built in scrollable frame and/or <span style="text-decoration-line:underline;text-decoration-color:rgb(255,0,0);text-decoration-style:wavy">toplevel</span>. If there's a TIP that has already requested this, then feel free to ignore this email. And if perchance, it's already there, then perhaps it just would need to be more prominent in the documentation. At least, I couldn't find one.

When I needed a scrollable frame, I found there are many versions on the <span style="text-decoration-line:underline;text-decoration-color:rgb(255,0,0);text-decoration-style:wavy">wiki</span>, but sometimes having too many choices makes the task harder. There once were also several notebook widgets, and the one I chose, in <span style="text-decoration-line:underline;text-decoration-color:rgb(255,0,0);text-decoration-style:wavy">bwidgets</span>, ended up not being the best choice. Had I known about <span style="text-decoration-line:underline;text-decoration-color:rgb(255,0,0);text-decoration-style:wavy">ttk</span>::notebook, I would certainly have looked at that first.

Anyway, I think the one at <span style="color:rgb(0,96,224);text-decoration-line:underline;text-decoration-style:solid"><a href="https://fedbdhd.r.bh.d.sendibt3.com/tr/cl/fiiJnUxvXfLT2CAdW-Fw-5scZTURdZpZ1NZ_pNIHd8l1V8cK7AoUI5YZdFrf_qEveNCLD51pDCbkjS76WYXbwpAFsbwBhnIZijzTsfeGouDZ9TdCE6XtOfFIyvxzHEofn30Xfgg3I7uiJSHeEKusACcQr1mjJpakX7nUOn8HglGBGp-_yx_atk3-4qt5-6WyOHF1WsVMfMWBWc1ER6ZgH-OP5gOJRsMeuo9FVHd_tmSOz0isRkKki2gUSHIT1EcNZQbEkrdVBXnMQMjRxqsDpw2AKlCIEjnhjjhtHwRAPlPZJ71hAjJu15wV6sUN" target="_blank" rel="noreferrer">https://wiki.tcl-lang.org/page/A+scrolled+frame</a></span> by Paul Walton is a quite good one, although I didn't quite understand why I needed two frames in the example.

There's also apparently a modified version just below it as well. And that's the one I tried because it also had 2 smallish examples.

Paul's version is nice in that you can pack the scrollable frame, but the scrollable items can be packed, <span style="text-decoration-line:underline;text-decoration-color:rgb(255,0,0);text-decoration-style:wavy">grid'd</span> or placed. I suspect you could grid the frame as well, but I wanted to pack it.

Bottom line, I believe having this widget in the Tk core would be quite useful, and it might even just be added there in script form. But having one supported version that was in the "manual" would be great and would also provide leverage for all the other languages that use the <span style="text-decoration-line:underline;text-decoration-color:rgb(255,0,0);text-decoration-style:wavy">Tk</span> toolkit.

thanks

Eric</pre>
</div>
_______________________________________________<br>
Tcl-Core mailing list<br>
<a href="mailto:Tcl...@li..." target="_blank" rel="noreferrer">Tcl...@li...</a><br>
<a href="https://fedbdhd.r.bh.d.sendibt3.com/tr/cl/zt2DZT5g4AUDjz8jpUEFvjKQam552LAoYJ7BFljaIdCgP5t0BUiin7cnpWutsOztiZiMjVQ7DX8VY50AyjErlhiZBnZiXHTlP0OVN5TWUAHgL2gGiDbda-xkulSYFWg3P_abMi4HFdHrWWuOvXIshUzU3e88yLorvqOrNJKhYANLs8E9VZQbQfOIMSshDznpplVWU1-YCMMpAgGWbWtkC2Qx1-EImQswMW2AQt7mFqRGXNSqro6j3A2Kc29ZcqXxG3cPks8JogT8gmBwaYYSysgmyDDCm3Hb3v51Kho1PM6L_fNg-48hGOSe1Km0FK5DAw" rel="noreferrer noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><br>
</blockquote></div>
<span>_______________________________________________</span><br><span>Tcl-Core mailing list</span><br><span>Tcl...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/tcl-core</span><br></div></blockquote></body></html>

Re: [TCLCORE] Any plans on a tk scrollable frame and toplevel in the core?

[KEITH N. <k.j...@us...>]

Hi Eric,

If something like a scrollable frame is added to Tk, script form has the
advantage that if it is not exactly what the developer needs, any Tcl/Tk
developer can copy it and modify it for their purpose.

Suggestions for possible alternatives to expanding the Tk core:

1. Improve the Wiki coverage of the subject, which is sometimes out of date
and confusing.  Whenever anybody figures something out, they could make sure
the knowledge is recorded on the Wiki.

2. Add an "Extensions" section to some Tcl/Tk man pages, describing the
relevant extensions that are available in Tcllib, Tklib and related packages
that are hosted on core.tcl-lang.org and have oversight by the Core Team.

This is not intended to shoehorn the entire documentation for Tcllib, Tklib
into the docs for Tcl/Tk, but only a brief reference to a few packages that
are natural extensions of the Tcl/Tk facilities.  This suggestion might
require a TIP to expand the scope of the documentation.

Keith.

------ Original Message ------
Received: Sat, 12 Apr 2025 05:50:10 AM BST
From: EricT <tw...@gm...>
To: Tcl...@li...
Subject: [TCLCORE] Any plans on a tk scrollable frame and toplevel in the
core?

> With 9.0 out the door, I was thinking that this might be a good time
> to consider some of the "missing" pieces in the tk and ttk widget set.
> 
> I think the most useful missing piece would be a built in scrollable
> frame and/or toplevel. If there's a TIP that has already requested
> this, then feel free to ignore this email. And if perchance, it's
> already there, then perhaps it just would need to be more prominent in
> the documentation. At least, I couldn't find one.
> 
> When I needed a scrollable frame, I found there are many versions on
> the wiki, but sometimes having too many choices makes the task harder.
> There once were also several notebook widgets, and the one I chose, in
> bwidgets, ended up not being the best choice. Had I known about
> ttk::notebook, I would certainly have looked at that first.
> 
> Anyway, I think the one at
> https://wiki.tcl-lang.org/page/A+scrolled+frame by Paul Walton is a
> quite good one, although I didn't quite understand why I needed two
> frames in the example.
> 
> There's also apparently a modified version just below it as well. And
> that's the one I tried because it also had 2 smallish examples.
> 
> Paul's version is nice in that you can pack the scrollable frame, but
> the scrollable items can be packed, grid'd or placed. I suspect you
> could grid the frame as well, but I wanted to pack it.
> 
> Bottom line, I believe having this widget in the Tk core would be
> quite useful, and it might even just be added there in script form.
> But having one supported version that was in the "manual" would be
> great and would also provide leverage for all the other languages that
> use the Tk toolkit.
> 
> thanks
> 
> Eric
> 

> 

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

Re: [TCLCORE] Any plans on a tk scrollable frame and toplevel in the core?

[Patrick M. <dus...@gm...>]

Hello,

I agree, and I'd like to take this opportunity to say, I think core Tk is
missing some features that might be considered basic today, which other
competing GUI toolkits probably have built in.

I'd suggest that having these features in the core might be a good idea:

- scrollable widget containers / scrollable frames

- drag and drop

I recently made a small utility that needed drag n drop. I had to load an
extension for that, and it complicated getting it to work across platforms.
I think I got it working on Linux and windows but not macOS.

Regards, PM


On Sat, 12 Apr 2025, 05:49 EricT, <tw...@gm...> wrote:

> With 9.0 out the door, I was thinking that this might be a good time to consider some of the "missing" pieces in the tk and ttk widget set.
>
> I think the most useful missing piece would be a built in scrollable frame and/or toplevel. If there's a TIP that has already requested this, then feel free to ignore this email. And if perchance, it's already there, then perhaps it just would need to be more prominent in the documentation. At least, I couldn't find one.
>
> When I needed a scrollable frame, I found there are many versions on the wiki, but sometimes having too many choices makes the task harder. There once were also several notebook widgets, and the one I chose, in bwidgets, ended up not being the best choice. Had I known about ttk::notebook, I would certainly have looked at that first.
>
> Anyway, I think the one at https://wiki.tcl-lang.org/page/A+scrolled+frame by Paul Walton is a quite good one, although I didn't quite understand why I needed two frames in the example.
>
> There's also apparently a modified version just below it as well. And that's the one I tried because it also had 2 smallish examples.
>
> Paul's version is nice in that you can pack the scrollable frame, but the scrollable items can be packed, grid'd or placed. I suspect you could grid the frame as well, but I wanted to pack it.
>
> Bottom line, I believe having this widget in the Tk core would be quite useful, and it might even just be added there in script form. But having one supported version that was in the "manual" would be great and would also provide leverage for all the other languages that use the Tk toolkit.
>
> thanks
>
> Eric
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

[TCLCORE] Any plans on a tk scrollable frame and toplevel in the core?

[EricT <tw...@gm...>]

With 9.0 out the door, I was thinking that this might be a good time
to consider some of the "missing" pieces in the tk and ttk widget set.

I think the most useful missing piece would be a built in scrollable
frame and/or toplevel. If there's a TIP that has already requested
this, then feel free to ignore this email. And if perchance, it's
already there, then perhaps it just would need to be more prominent in
the documentation. At least, I couldn't find one.

When I needed a scrollable frame, I found there are many versions on
the wiki, but sometimes having too many choices makes the task harder.
There once were also several notebook widgets, and the one I chose, in
bwidgets, ended up not being the best choice. Had I known about
ttk::notebook, I would certainly have looked at that first.

Anyway, I think the one at
https://wiki.tcl-lang.org/page/A+scrolled+frame by Paul Walton is a
quite good one, although I didn't quite understand why I needed two
frames in the example.

There's also apparently a modified version just below it as well. And
that's the one I tried because it also had 2 smallish examples.

Paul's version is nice in that you can pack the scrollable frame, but
the scrollable items can be packed, grid'd or placed. I suspect you
could grid the frame as well, but I wanted to pack it.

Bottom line, I believe having this widget in the Tk core would be
quite useful, and it might even just be added there in script form.
But having one supported version that was in the "manual" would be
great and would also provide leverage for all the other languages that
use the Tk toolkit.

thanks

Eric

[TCLCORE] Summary of my favorite tickets of this week

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

Hello friends of critical thinking,

here we go, the top 3 are:

1. Floating point numbers

Ticket
https://core.tcl-lang.org/tcl/info/42d14c495a096159
got at least a branch of its own now. IMO it deserves
much attention since its non-solution keeps the doors
wide open for penetrators presenting loooooooooooong
floating point strings to your innocent maiden Tcl
script.

2. TIP#302

This discussion is universal and got revival in a new
ticket this time in the Tk repo:
https://core.tcl-lang.org/tk/info/2f1086ac088c3593
Now even the Python users of Tkinter (with Tcl under
the hood) get aware of this long standing problem.
Time is heavy sometimes…

3. The text widget's -blockcursor option

The heat is on, see ticket
https://core.tcl-lang.org/tk/info/5d0bc3cfec7c1adb
and we've got still no clue what should be done.
Put ICU on hold on not MacOS platforms or live with
differences between ICU and platform dependent font
rendering.

I hope these points will be addressed in the not so
distant future.

Wish you all a nice weekend,
Christian

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

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

I think I have gotten about as far as I will with TIP 626 review. Some 100+ files are affected and I have been only been through a few but have enough concerns as to not proceed further until these are resolved.

Most important, is that as of now passing even the smallest 33-bit number of arguments is unusable in practice. Second, it is not clear to me based on a review of the source (keeping in mind my limited understanding of the byte code engine) that all necessary changes have been made.

With regards to the first, consider the following basic tests run on Stefan's 128GB Debian box (ulimit shows unlimited so I presume I can use as much memory as available).

% lassign [lseq 0x100000000] {*}[lseq 0x100000000]; set 1
killed

% lassign {} {*}[lseq 0x100000000]
killed

% dict set d {*}[lseq 0x100000000]; dict size $d
killed

% dict set d {*}[lrepeat 0x100000000 x]; dict size $d
killed

Or defining a proc that can take that many parameters. Note the proc is not even called.

% proc xx [lrepeat 0x100000000 x] {}
killed

Or explicitly defining the proc in script

% set l [lrepeat 0x100000000 x]; llength $l
4294967296
% writeFile manyargs.tcl [list proc xx $l {return $x}]
% exit
[apn@tcltk build]$ LD_LIBRARY_PATH=`pwd` ./tclsh manyargs.tcl  
killed

Or using args,

% proc xx args {}
% xx {*}[lseq 0x100000000]
killed

It is not clear to me if the above processes are killed because of memory exhaustion or *possible* implementation bugs (see below) that can be corrected. If the former, then I'm afraid one has to ask whether the extensive changes across more than a hundred files are warranted by a feature that will be very rarely used and is not usable even on a 128GB system.

My other concern is that the current implementation may be incomplete in at least some respects. This is purely based on a source review as confirmation through test cases is not possible because of the failures illustrated above. (Again, for CYA purposes, the byte code / compiler is a complicated beast so caveats about my reading of the code and understanding apply in all cases!)

Afaik, the byte code engine was incapable of handling 64-bit immediate values, jump offsets etc. in 9.0 and that has not changed with TIP 626. In 9.0, a global check ensured invocations with more than 2**31 (32?) arguments raised an error as it was explicitly not supported. TIP 626 removes this global check on argument count since that is its purpose. Instead, it adds a check to each compile command so that argument counts greater than INT_MAX are not byte compiled but take the slow path instead. It appears this check is missing at least in some cases, for example

TclCompileLindexCmd - the INST_LIST_INDEX_MULTI instruction emit

TclCompileListCmd - the build variable is an int but tracks number of arguments which is Tcl_Size and therefore can overflow. Changing it to Tcl_Size will not suffice either because it is then emitted via TclEmitInstInt4 which will truncate.

TclCompileReturnCmd - numOptionWords is typed Tcl_Size, derived from number of arguments but emitted via TclEmitInstInt4 with no check for overflow.

Those are the ones I found but I only went through a sampling of the compiled commands. 

Let me again stress the above are possibly correctable bugs but illustrate the need to have a test suite covering > 2**32 arguments for all commands that take a variable number of arguments.

The other category of potential errors is functions returning ints have changed to returning Tcl_Size. These include (at least)
 
TclCreateExceptRange
AnonymousLocal
LocalScalarFromToken
LocalScalar
ExceptionRangeStarts
TclCreateAuxData
IndexTailVarIfKnown
PushVarNameWord

These are used by multiple compilation functions. The potential problem here is the Tcl_Size value is then emitted by their callers with Emit14Inst / TclEmitInt4 etc. resulting in truncation. 

Similarly, jump offsets generated by if, switch, subst, exception range etc. compilers are now Tcl_Size but truncated to int (TclFixupForwardJumpToHere, OP4, IssueSwitchJumpTable). For example, TclFixupForwardJump and TclFinalizeLoopExceptionRange "break" targets issue INST_JUMP4 with 64-bit values.

Likewise, code offsets seem to be truncated before comparing in StartExpanding (afaik code offsets can be Tcl_Size with TIP 626 as per the type definitions)

In all these cases, I cannot see where the Tcl_Size values are restricted to INT_MAX making them eligible for emiting as 32 bit values. If in fact they are restricted, why were the functions changed to Tcl_Size in the first place? As an aside, the compiler does not generate truncation warnings because of casts.

That's all from me on TIP 626.

/Ashok



-----Original Message-----
From: Jan Nijtmans <jan...@gm...> 
Sent: Saturday, April 5, 2025 2:07 AM
To: apn...@ya...
Cc: tcl...@li...
Subject: Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

Op vr 4 apr 2025 om 12:21 schreef apnmbx-public:
> I haven't been reviewing it since you have been continuing with your
> commits. Since I can only afford the time for one full review, I wanted to
> wait till you are done. *If* you feel the implementation and test suite is
> more or less complete, I will review over the weekend. Let me know
> accordingly

Then, go ahead.

I'm sure some "bigdata" testcases need to be adapted: They
no longer give an error-message but will work as expected
now. I don't have a machine with enough memory to
do this. And those testcases cannot run in GITHUB
CI anyway.

       Jan Nijtmans

Re: [TCLCORE] TIP 714: image driver photo formats

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

Dear Emiliano,

thanks for the message. Please allow me to reply inline.

Am 09.04.2025 um 02:25 schrieb Emiliano:
> On Thu, 3 Apr 2025 10:41:53 +0200
> Harald Oehlmann <har...@el...> wrote:
> 
> IMO this is the opportunity to fix some issues wrt the image type registration
> and its implementation.

Yes, great !

> In this case, the list is walked from the start adding the .name member of
> the Tk_ImageInfo structure until the .nextPtr member is null. Same with
> [image create $type]: the list is walked until $type matches the .name
> member. The result is
> 
> * [image types] always grows, and can get duplicates.
> * the first (last added) of the duplicated type names shadows the later ones.
> 
> This last fact is easy to test
> 
>    % image create bitmap
>    Violación de segmento (`core' generado)
> 
> I have a fix for the duplicated names issue. Since TIP#714 implements a
> hash table to hold the registered Tk_ImageInfoProc, I've changed the
> linked list for a(n internal) wrapper struct to hold both Tk_ImageType and
> Tk_ImageInfoProc, and using the hash table to hold these wrappers.
> If there are no questions, I'm going to commit it in a couple days in the
> tip-714-alt branch, so it can be reviewed.

Thank you for working on this. IMHO, this is a bug of the current 
implementation and is not TIP 714 related.
Could you open a bug ticket and provide the fix there?
I prefer to have the discussion archived somewhere and a ticket is a 
great place.

I think, even with the current data structure, it would be possible to 
avoid double registrations, but the list must be scanned for the name 
entry. Currently, Tk_CreateImageType can not return an error on double 
registration.

> Another issue identified has to do with the fact that image type managers
> are implemented at thread level; newly registered image types are visible
> in all interpreters in the same thread. Also, there's no provision to remove
> an image type. These gotchas makes image type managers not well suited
> to be implemented as extensions, since extensions are limited to
> the interpreter which loads them (is this assumption true?). Interactively:
> 
>    # loading in a child interp, visible from parent interp
>    $ wish9.1
>    % interp create i
>    i
>    % i eval {load ./libbadimage.so}
>    % i eval {image types}
>    bitmap photo bitmap
>    % image types
>    bitmap photo bitmap
> 
> But this is subject for another TIP. Also, the photo image type format list
> is also thread data; [package require ::img::jpeg] makes Tk photo image
> supports jpeg in all the interpreters in the thread in which Tk is loaded.

I think, the thread issue is also a bug and may be handled in a ticket.
Tk is slowly getting thread safe and this is another step in this direction.

> 
>> It now features the great intuitive result:
>>
>> % image types photo
>> format {svg ppm png gif default} file {svg ppm png gif} write {ppm png gif}
> 
> I think it can be a bit more descriptive. What's the difference from file,
> format and write here? Also, I think should be documented too.

The current description is in TIP 714. Is this ok for you?

I like the "image types photo" command. It is intuitive.

I am not happy with the registration of an additional function pointer 
by "Tk_ImageInfoProc". IMHO, this has the same purpose as 
"Tk_CreateImageType", to pass a C function pointer for an image type 
handler. I would prefer to extend the passed data structure.

I am planning to copy the great "image type photo" code to the 
"tip-714-image-driver-info" branch. Is this a good idea?

There are other tasks in front of us:
A procedure to unregister an image type handler and cleaning up all its 
resources. One structural possibility would be to pass a pointer to a 
delete procedure with Tk_ImageInfoProc. Also, a TSD data pointer may be 
passed for its own thread memory.
The unregister functionality will require an unregister procedure for 
photo format handlers. So, this is a bigger bunch.

But all starts with the list of function pointers passed with 
"Tk_CreateImageType". Perhaps, a new "Tk_CreateImageType" may pass a 
memory with a version field, so, we may later extend it.

Any comment welcome!
Harald

Re: [TCLCORE] TIP 714: image driver photo formats

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

On Thu, 3 Apr 2025 10:41:53 +0200
Harald Oehlmann <har...@el...> wrote:

IMO this is the opportunity to fix some issues wrt the image type registration
and its implementation.

The low hanging fruit here is the current registration. It is implemented as
a single linked list, and the current implementation simply adds the newly
registered type at the front of the list unconditionally. What happens if you
add a new type with an already existing name? Let the code speak:

  $ cat badimage.c
  #include <tk.h>
  static const Tk_ImageType badType = {
      "bitmap", NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL
  };
  int Badimage_Init(Tcl_Interp *interp) {
      Tcl_InitStubs(interp, TCL_VERSION, 0);
      Tk_InitStubs(interp, TK_VERSION, 0);
      Tk_CreateImageType(&badType);
      return TCL_OK;
  }

  $ gcc -DUSE_TK_STUBS -DUSE_TCL_STUBS -shared -o libbadimage.so badimage.c -L/usr/local/lib -ltclstub -L/usr/local/lib -ltkstub

  $ wish9.1
  % image types
  photo bitmap 
  % load ./libbadimage.so
  % image types
  bitmap photo bitmap

In this case, the list is walked from the start adding the .name member of
the Tk_ImageInfo structure until the .nextPtr member is null. Same with
[image create $type]: the list is walked until $type matches the .name
member. The result is

* [image types] always grows, and can get duplicates.
* the first (last added) of the duplicated type names shadows the later ones.

This last fact is easy to test

  % image create bitmap
  Violación de segmento (`core' generado)

I have a fix for the duplicated names issue. Since TIP#714 implements a
hash table to hold the registered Tk_ImageInfoProc, I've changed the
linked list for a(n internal) wrapper struct to hold both Tk_ImageType and
Tk_ImageInfoProc, and using the hash table to hold these wrappers.
If there are no questions, I'm going to commit it in a couple days in the
tip-714-alt branch, so it can be reviewed.

Using a hash table preserve the behaviour that newly registered types with
an existing name overwrites the old one. Also, I think this should
be documented.

Another issue identified has to do with the fact that image type managers
are implemented at thread level; newly registered image types are visible
in all interpreters in the same thread. Also, there's no provision to remove
an image type. These gotchas makes image type managers not well suited
to be implemented as extensions, since extensions are limited to
the interpreter which loads them (is this assumption true?). Interactively:

  # loading in a child interp, visible from parent interp
  $ wish9.1
  % interp create i
  i
  % i eval {load ./libbadimage.so}
  % i eval {image types}
  bitmap photo bitmap
  % image types
  bitmap photo bitmap

But this is subject for another TIP. Also, the photo image type format list
is also thread data; [package require ::img::jpeg] makes Tk photo image
supports jpeg in all the interpreters in the thread in which Tk is loaded.

> It now features the great intuitive result:
> 
> % image types photo
> format {svg ppm png gif default} file {svg ppm png gif} write {ppm png gif}

I think it can be a bit more descriptive. What's the difference from file,
format and write here? Also, I think should be documented too.

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

Re: [TCLCORE] Project tk_collect_test_utils, report and invitation for final review

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

No, I can't. I'm sorry.

Erik.
--

On 4/7/25 10:13 , Harald Oehlmann wrote:
> Eric,
> I think, we may address this in the biweekly telco of today.
> Would it be possible for you to attend?
>
> Thanks and take care,
> Harald
>
> Am 06.04.2025 um 23:21 schrieb Erik Leunissen:
>> L.S.
>>
>> The project tk_collect_test_utils [1] has been underway for several 
>> months,
>> and has now reached a stage where it does what it's meant to do.
>> It is ready for a final review.
>>
>> This post invites comments from maintainers and other knowledgeable 
>> developers
>> frequenting this mailing list, especially those who are concerned 
>> with Tk.
>>
>> General information
>> -------------------
>> The project's ticket is at:
>>
>>          https://core.tcl-lang.org/tk/tktview/718cbc3016
>>
>>    The very first post in the ticket describes the project's purpose, 
>> and
>>    adjustments made along the way. The rest of the ticket serves as a 
>> course
>>    project log.
>>
>> The implementation is in the development branch at:
>>
>> https://core.tcl-lang.org/tk/timeline?r=tk_collect_test_utils
>>
>>    The current tip of the development branch is meant for inspection and
>>    possibly exercising. To indicate its correspondence to this post, 
>> that
>>    particular check-in has been tagged "FINAL_REVIEW".
>>
>> The development of this project took place in close consultation with
>> François Vogel [2].
>>
>> An overview of the project's results
>> ------------------------------------
>> * test constraints and utility procs that were used in multiple test 
>> files,
>>    have been relocated/collected; the utility procs in a new file
>>    "tests/testutils.tcl", the test constraints in the already 
>> existing file
>>    "constraints.tcl". What's left in test files are constraints and 
>> utility
>>    procs that are used only in a single test file.
>> * the loading of top-level scripts by the Tk test suite has been 
>> restructured.
>>    This was necessary to enable the loading of multiple scripts with 
>> entirely
>>    different functionality. The initial script loaded by test files 
>> in the Tk
>>    test suite is now "main.tcl", which in turn takes care of loading
>>    "testutils.tcl" and "constraints.tcl".
>> * test files that make use of collected utility procs have a command
>>    "testutils import xxx" inserted near the top of the file, and a 
>> corresponding
>>    "testutils forget xxx" at the end of the file. The "xxx" in these 
>> invocations
>>    stands for a certain functional area.
>> * the mechanism for importing/forgetting utility procs, including the 
>> proc
>>    "testutils", has been documented in the file "tests/testutils.GUIDE".
>> * the correct functioning of the proc "testutils" is tested in a 
>> separate test
>>    file "tests/testutils.test".
>> * the Tk test suite, as adjusted in this project, passes with CI runs 
>> at Github.
>>
>>
>> Procedure (in consultation with François)
>> -----------------------------------------
>> I'm asking that responses be directed to this mailing list within 
>> three weeks.
>> Please note that there is an intent to merge the development branch into
>> trunk. In the eventuality of no responses to this post, the merge 
>> will happen
>> after the period of three weeks.
>>
>> My advice to reviewers: read the initial post in the ticket and the 
>> documentation
>> in "tests/testutils.GUIDE" before anything else.
>>
>> Of course, I'm prepared to provide clarification if needed.
>>
>> Thanks in advance for your attention,
>> Erik Leunissen
>> -- 
>>
>> [1] On Tue, 17 Dec 2024 12:12, I announced the start of this effort/job
>>      in this mailing list (as part of a larger proposal that was 
>> mailed before
>>      that date). In the meantime, the project has been dubbed 
>> "tk_collect_test_utils".
>> [2] Besides providing excellent guidance for me, being new to fossil 
>> and the Tk
>>      repository, François' advice was especially valuable where 
>> development met with
>>      choices that were nontrivial, but where no policy preexisted to 
>> rely on.
>>
>>
>>
>> _______________________________________________
>> 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

[TCLCORE] Report if biweekly TCL/Tk telco on 2025-04-07

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

Dear TCL/Tk team,
here is the report of the telco of today.

It only consists personal opinions.

The moderator (Harald) was apparently a bit stressed. My apolgizes for 
this. Will do better next time.

0) Eventual surprise guest with special question
Stephan Beal

sqlite moved from autoconf to TCL autosetup
Proposal is to have a TEA using autosetup:
https://fossil.wanderinghorse.net/r/teaish

Lot of interest for unification
Autoconf has many exotic platforms supported, like Solaris, DEC,...
Much faster than other tools.
Uses tclConfig.sh
Advantage: not messing with auto tools.


1) TIP 715 - platform support definitions.
No hurry on this, we still have 1,5 years.
We never had it, we don't need it.
Tests for "tested" platforms should be sure.
Rename "supported" by "tested" is good.

"deprecated" means,:
- that it will go away in the next version
- that you will limit yourself

German telco result:
The word "deprecated" is seen as to strong and may harm business, as 
people may think,
this use-case does not work any more.
It is used for:
- platforms/use-cases
- features: like a command or C interface
May different wording be more appropriate?

2) TIP 710 - development workflow and TIP process

- 2nd eyeball of TCT before going to main branches
- before, we had maintainers for sub-systems, and they reviewed
- Two weeks reaction time?
Please comment !

3) TIP 700: Documentation

WIP
Do we need md and (generated) html/nrof in the repository?
This was discussed in the doc group, pandoc may be required.
Make clear, that there is only a single source!
Configure scripts may check for pandoc...

4) TIP 714 - "image types photo" - ready for vote?

I will have a look on it.

5) Github for orphaned extensions started

Orgainsation set-up.
This week, some maintainer may send packages

6) bytecode compiler optimization by Donal Fellows

Preliminary, may have advantages.

7) Conference news

10 people registered, 3 presentations.
Idea is a user meeting, we tell what we all do, no minimum "level" required.
Presentations welcome!

8) Next biweekly telco
in one month: 5th of May 2025 12:00UTC

Then, it is release preparation time for 9.0.2 and 9.1a0.
Make your contributions ready !

9) Any other business

Don_Refactor branch: status: great ideas but no release/merge planned

10) Eric: Tk test reform

Look into it over the week-end
I like it

---

Upcoming meetings:
- tomorrow, 8th of April 2025 1:00 UTC: TCL/Tk meetup at Jitsi
- in 4 weeks: 5th of May 2025 12:00 UTC: biweekly telco

Thank you all,
Harald

Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

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

Op ma 7 apr 2025 om 11:16 schreef Harald Oehlmann:
> We may discuss this in the telco of today.

Hi all,

I will join, but - most likely - about 20 minutes late.

See you
        Jan Nijtmans

Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

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

Thanks Ashok, great.

We may discuss this in the telco of today.

Take care,
Harald

Am 06.04.2025 um 12:18 schrieb apn...@ya...:
> Harald,
> 
> Thanks again for taking up 715.
> 
> I have some comments and suggestions having spent more time thinking about this. The TIP 715 in the tip-715-apn branch reflects the changes below. Needless to say, all are opinions and since you are now driving, feel free to reject any or all of the changes without prejudice 😊
> 
> - As someone stated in the online meet (sorry, I forget who, maybe it was you or Schelte) the terms supported and unsupported are ambiguous. I agree. In particular, "unsupported" can be very misleading. Instead, as was suggested there, the terms "tested" and "untested" more accurately reflect the intention.
> 
> - I don't feel the TIP should cover "features" as those are already covered by individual TIP's. A feature is by definition tested and supported so it seems superfluous for the TIP to address these. By the same token, "deprecated" is associated with features so I've removed that as well.
> 
> - I've refactored some common requirements into their own section. This is only a stylistic change. These requirements are then what the "untested" platforms are expected to meet.
> 
> - In the platform definition, have explicitly said the *latest* versions of (for example) Windows 10, 11 or Ubuntu etc. will be tested. In other words, this change stems from the focus being what is "supported" to what is actually tested.
> 
> -  And of course, I've added you as an author so you can share the brickbats!
> 
> 
> /Ashok
> 
> -----Original Message-----
> From: Harald Oehlmann <har...@el...>
> Sent: Wednesday, April 2, 2025 1:24 AM
> To: tcl...@li...
> Subject: Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1
> 
> Folks,
> TIP 715 was updated by the given information.
> 
> Thanks for any comment !
> 
> Harald
> 
> 


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

Re: [TCLCORE] Project tk_collect_test_utils, report and invitation for final review

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

Eric,
I think, we may address this in the biweekly telco of today.
Would it be possible for you to attend?

Thanks and take care,
Harald

Am 06.04.2025 um 23:21 schrieb Erik Leunissen:
> L.S.
> 
> The project tk_collect_test_utils [1] has been underway for several months,
> and has now reached a stage where it does what it's meant to do.
> It is ready for a final review.
> 
> This post invites comments from maintainers and other knowledgeable 
> developers
> frequenting this mailing list, especially those who are concerned with Tk.
> 
> General information
> -------------------
> The project's ticket is at:
> 
>          https://core.tcl-lang.org/tk/tktview/718cbc3016
> 
>    The very first post in the ticket describes the project's purpose, and
>    adjustments made along the way. The rest of the ticket serves as a 
> course
>    project log.
> 
> The implementation is in the development branch at:
> 
> https://core.tcl-lang.org/tk/timeline?r=tk_collect_test_utils
> 
>    The current tip of the development branch is meant for inspection and
>    possibly exercising. To indicate its correspondence to this post, that
>    particular check-in has been tagged "FINAL_REVIEW".
> 
> The development of this project took place in close consultation with
> François Vogel [2].
> 
> An overview of the project's results
> ------------------------------------
> * test constraints and utility procs that were used in multiple test files,
>    have been relocated/collected; the utility procs in a new file
>    "tests/testutils.tcl", the test constraints in the already existing file
>    "constraints.tcl". What's left in test files are constraints and utility
>    procs that are used only in a single test file.
> * the loading of top-level scripts by the Tk test suite has been 
> restructured.
>    This was necessary to enable the loading of multiple scripts with 
> entirely
>    different functionality. The initial script loaded by test files in 
> the Tk
>    test suite is now "main.tcl", which in turn takes care of loading
>    "testutils.tcl" and "constraints.tcl".
> * test files that make use of collected utility procs have a command
>    "testutils import xxx" inserted near the top of the file, and a 
> corresponding
>    "testutils forget xxx" at the end of the file. The "xxx" in these 
> invocations
>    stands for a certain functional area.
> * the mechanism for importing/forgetting utility procs, including the proc
>    "testutils", has been documented in the file "tests/testutils.GUIDE".
> * the correct functioning of the proc "testutils" is tested in a 
> separate test
>    file "tests/testutils.test".
> * the Tk test suite, as adjusted in this project, passes with CI runs at 
> Github.
> 
> 
> Procedure (in consultation with François)
> -----------------------------------------
> I'm asking that responses be directed to this mailing list within three 
> weeks.
> Please note that there is an intent to merge the development branch into
> trunk. In the eventuality of no responses to this post, the merge will 
> happen
> after the period of three weeks.
> 
> My advice to reviewers: read the initial post in the ticket and the 
> documentation
> in "tests/testutils.GUIDE" before anything else.
> 
> Of course, I'm prepared to provide clarification if needed.
> 
> Thanks in advance for your attention,
> Erik Leunissen
> -- 
> 
> [1] On Tue, 17 Dec 2024 12:12, I announced the start of this effort/job
>      in this mailing list (as part of a larger proposal that was mailed 
> before
>      that date). In the meantime, the project has been dubbed 
> "tk_collect_test_utils".
> [2] Besides providing excellent guidance for me, being new to fossil and 
> the Tk
>      repository, François' advice was especially valuable where 
> development met with
>      choices that were nontrivial, but where no policy preexisted to 
> rely on.
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core


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

[TCLCORE] April 8 2025 Tcl monthly meetup reminder

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

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

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

-- Steve

[TCLCORE] Project tk_collect_test_utils, report and invitation for final review

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

L.S.

The project tk_collect_test_utils [1] has been underway for several months,
and has now reached a stage where it does what it's meant to do.
It is ready for a final review.

This post invites comments from maintainers and other knowledgeable 
developers
frequenting this mailing list, especially those who are concerned with Tk.

General information
-------------------
The project's ticket is at:

         https://core.tcl-lang.org/tk/tktview/718cbc3016

   The very first post in the ticket describes the project's purpose, and
   adjustments made along the way. The rest of the ticket serves as a course
   project log.

The implementation is in the development branch at:

https://core.tcl-lang.org/tk/timeline?r=tk_collect_test_utils

   The current tip of the development branch is meant for inspection and
   possibly exercising. To indicate its correspondence to this post, that
   particular check-in has been tagged "FINAL_REVIEW".

The development of this project took place in close consultation with
François Vogel [2].

An overview of the project's results
------------------------------------
* test constraints and utility procs that were used in multiple test files,
   have been relocated/collected; the utility procs in a new file
   "tests/testutils.tcl", the test constraints in the already existing file
   "constraints.tcl". What's left in test files are constraints and utility
   procs that are used only in a single test file.
* the loading of top-level scripts by the Tk test suite has been 
restructured.
   This was necessary to enable the loading of multiple scripts with 
entirely
   different functionality. The initial script loaded by test files in 
the Tk
   test suite is now "main.tcl", which in turn takes care of loading
   "testutils.tcl" and "constraints.tcl".
* test files that make use of collected utility procs have a command
   "testutils import xxx" inserted near the top of the file, and a 
corresponding
   "testutils forget xxx" at the end of the file. The "xxx" in these 
invocations
   stands for a certain functional area.
* the mechanism for importing/forgetting utility procs, including the proc
   "testutils", has been documented in the file "tests/testutils.GUIDE".
* the correct functioning of the proc "testutils" is tested in a 
separate test
   file "tests/testutils.test".
* the Tk test suite, as adjusted in this project, passes with CI runs at 
Github.


Procedure (in consultation with François)
-----------------------------------------
I'm asking that responses be directed to this mailing list within three 
weeks.
Please note that there is an intent to merge the development branch into
trunk. In the eventuality of no responses to this post, the merge will 
happen
after the period of three weeks.

My advice to reviewers: read the initial post in the ticket and the 
documentation
in "tests/testutils.GUIDE" before anything else.

Of course, I'm prepared to provide clarification if needed.

Thanks in advance for your attention,
Erik Leunissen
--

[1] On Tue, 17 Dec 2024 12:12, I announced the start of this effort/job
     in this mailing list (as part of a larger proposal that was mailed 
before
     that date). In the meantime, the project has been dubbed 
"tk_collect_test_utils".
[2] Besides providing excellent guidance for me, being new to fossil and 
the Tk
     repository, François' advice was especially valuable where 
development met with
     choices that were nontrivial, but where no policy preexisted to 
rely on.

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

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

Op zo 6 apr 2025 om 14:48 schreef Gustaf Neumann (sslmail) <ne...@wu...>:
>
> Just for my understanding: the "string based" interface will not support 2^31+ arguments, and there will be no variant similar to the Tcl_Obj based counterparts.
> This makes the  "string based”  interface based on Tcl_CreateCommand a legacy interface. Right?

Right. For every such function call, a "const char *" array is
allocated, the string values
of all Tcl_Obj arguments are copied in there, and - when the call returns -
everything is cleaned up. This makes Tcl_CreateCommand functions less
efficient, they should be discouraged. However, I don't think we should
ever remove this interface: there are still too many extensions using it.

Deprecating an interface means that _some day_ the interface
might be removed. It is not a promise that it will be removed
in Tcl 10. That still can be decided then (which will need a TIP)

Hope this helps,
      Jan Nijtmans

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

[Gustaf N. (sslmail) <ne...@wu...>]

Just for my understanding: the "string based" interface will not support 2^31+ arguments, and there will be no variant similar to the Tcl_Obj based counterparts. 
This makes the  "string based”  interface based on Tcl_CreateCommand a legacy interface. Right?

-g

> On 04.04.2025, at 10:26, Jan Nijtmans <jan...@gm...> wrote:
> 
> Op wo 2 apr 2025 om 18:33 schreef Donald G Porter:
>> Looking at this again, I notice the call to deprecate Tcl_CreateCommand.
>> 
>> I think that's a bad idea. I think the ability to define string-based extension and application commands should live forever.
>> 
>> I like Tcl continuing to support extension via the simplest C language tools imaginable, writing what is very close to a main() routine.  The continuing interoperability with the oldest textbooks is also appealing to me.
> 
> Understood. I don't have much problems keeping that, it's just a tiny
> bit of wrapper functionality.The TIP and implementation is modified now.

Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

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

Harald,

Thanks again for taking up 715.

I have some comments and suggestions having spent more time thinking about this. The TIP 715 in the tip-715-apn branch reflects the changes below. Needless to say, all are opinions and since you are now driving, feel free to reject any or all of the changes without prejudice 😊

- As someone stated in the online meet (sorry, I forget who, maybe it was you or Schelte) the terms supported and unsupported are ambiguous. I agree. In particular, "unsupported" can be very misleading. Instead, as was suggested there, the terms "tested" and "untested" more accurately reflect the intention.

- I don't feel the TIP should cover "features" as those are already covered by individual TIP's. A feature is by definition tested and supported so it seems superfluous for the TIP to address these. By the same token, "deprecated" is associated with features so I've removed that as well.

- I've refactored some common requirements into their own section. This is only a stylistic change. These requirements are then what the "untested" platforms are expected to meet.

- In the platform definition, have explicitly said the *latest* versions of (for example) Windows 10, 11 or Ubuntu etc. will be tested. In other words, this change stems from the focus being what is "supported" to what is actually tested.

-  And of course, I've added you as an author so you can share the brickbats!


/Ashok

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Wednesday, April 2, 2025 1:24 AM
To: tcl...@li...
Subject: Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

Folks,
TIP 715 was updated by the given information.

Thanks for any comment !

Harald