tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Suggestion: change tab size from 8 to 4 to so 1 tab = 1 indent.

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

Hi All,

I would be happy if all tabs were replaced with spaces.

The next best choice for leading whitespace would be pure tabs with nominal
spacing 4.

The 8+4 convention might have made sense when it was introduced; is there a
good reason to continue using it today?

Best wishes,

Keith.

------ Original Message ------
Received: Sat, 21 Jun 2025 11:12:24 PM BST
From: EricT <tw...@gm...>
To: Tcl...@li...
Subject: [TCLCORE] Suggestion: change tab size from 8 to 4 to so 1 tab = 1
indent.

> If I might make a suggestion (from someone who only downloads tcl
> source code) I find that the combination of indent 4 and tab size 8 to
> be problematic. Unless I adjust all my text tools, the code is not
> indented properly when viewed. Perhaps this is what leads some to use
> all spaces while others use tabs.
> 
> This asymmetry causes odd combinations to result: 1 tab = 2 indents, 2
> tabs + 4 spaces = 5 indents, instead of a more natural 1 tab / 1
> indent.
> 
> Many text editors will automatically change a typed tab to spaces if
> that's what you desire, but only when indent is the same as tab size.
> Mine can also block indent using the tab on a selection. Shift-tab
> un-indents 1 level as well. It's all much simpler if tabsize = indent
> size.
> 
> When I download the tcl source, I run it all through a pass to expand
> using tab size 8, then I re-tab with size 4.  I don't really NEED
> tabs, but in one text editor, it facilitates adding visual indentation
> lines.
> 
> I think maybe it's worth considering this change to the coding style
> guide. It might even solve the tab/space controversy.
> 
> -Eric
> 
> 
> (forgive me if this was double posted)
> 

> 

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

Re: [TCLCORE] TIP 649

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

Sorry, below should read manpages and test suite are *now* complete.

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 



 

Manpages and test suites are not complete.

 

 

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...
<mailto:tcl...@li...> > 
Sent: Tuesday, June 17, 2025 11:50 AM
To: tcl...@li... <mailto:tcl...@li...> 
Subject: Re: [TCLCORE] TIP 649

 

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

 

/Ashok

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

/Ashok

Re: [TCLCORE] TIP 649

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

TIP 649 has been slightly modified. Tcl_ListObjRepeat signature has changed
to take an objc/objv pair in lieu of a listPtr holding values to be
repeated. Fits better with call pattern.

 

Manpages and test suites are not complete.

 

Will hold off on a vote for a couple of days in case anybody has comments on
the changes.

 

 

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Tuesday, June 17, 2025 11:50 AM
To: tcl...@li...
Subject: Re: [TCLCORE] TIP 649

 

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

 

/Ashok

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

/Ashok

[TCLCORE] Suggestion: change tab size from 8 to 4 to so 1 tab = 1 indent.

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

If I might make a suggestion (from someone who only downloads tcl
source code) I find that the combination of indent 4 and tab size 8 to
be problematic. Unless I adjust all my text tools, the code is not
indented properly when viewed. Perhaps this is what leads some to use
all spaces while others use tabs.

This asymmetry causes odd combinations to result: 1 tab = 2 indents, 2
tabs + 4 spaces = 5 indents, instead of a more natural 1 tab / 1
indent.

Many text editors will automatically change a typed tab to spaces if
that's what you desire, but only when indent is the same as tab size.
Mine can also block indent using the tab on a selection. Shift-tab
un-indents 1 level as well. It's all much simpler if tabsize = indent
size.

When I download the tcl source, I run it all through a pass to expand
using tab size 8, then I re-tab with size 4.  I don't really NEED
tabs, but in one text editor, it facilitates adding visual indentation
lines.

I think maybe it's worth considering this change to the coding style
guide. It might even solve the tab/space controversy.

-Eric


(forgive me if this was double posted)

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

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

Thanks Paul. That bit of history helps a lot. I will merge accordingly if no one else picks up tkpath.

 

/Ashok

 

From: Paul Obermeier <pa...@po...> 
Sent: Thursday, June 19, 2025 12:55 AM
To: apn...@ya...; tcl...@li...
Subject: Re: [TCLCORE] tclx, tktreectrl and tkpath repositories and a request

 

Some history.
I originally had Rene's tkpath version in BAWT (last update was in 2018),
which does not compile on Mac.
Manfred Rosenberger (author of tkpath based RattleCAD) asked me to add 
Christian Werner's version of tkpath, because his version runs on Mac and
has several other fixes.
After Tcl9 release Steve Shaw sent me a Tcl9 ready version of tkpath.
Unfortunately this version was based on Rene's version (no Mac) and did only
work with Tcl9, but not Tcl8.
I then merged the Tcl9 changes into Christian's version, which is the version 0.4.0
available with BAWT.

So in my point of view, the BAWT version is the most advanced one.
It runs the test suite without errors on Windows and Linux using Tcl/Tk 8.6.16 and Tcl/Tk 9.0.1
The test suite runs on Mac with 1 error both using Tcl/Tk 8.6.16 and 9.0.1, see below.

Paul

==== canvText-1.12 configuration options: bad value for -stipple FAILED
==== Contents of test case:

    .c create text 20 20 -tag test
    .c itemconfigure test $name $badValue

---- Test completed normally; Return code was: 0
---- Return code should have been one of: 1
==== canvText-1.12 FAILED



Am 18.06.2025 um 05:26 schrieb apnmbx-public--- via Tcl-Core:

Thanks Paul. Do you know if your version of tkpath also incorporates Rene’s changes from chiselapp?

 

I hope someone picks up tkpath, else I will make an attempt at a merge at some point. For the macOS issues, I’m afraid I have no way of testing GUI’s. At least for console only, Github actions can be used (painfully).

 

/Ashok

 

From: Paul Obermeier  <mailto:pa...@po...> <pa...@po...> 

I do have a version of tkpath, which is a merge of Christian's and Steve's work and compiles  
using Tcl 8.6 and 9.0 on Windows, Linux and Mac.
See https://www.bawt.tcl3d.org/download/InputLibs/tkpath-0.4.0.7z

It works on Windows and Linux using Tcl 8.6 and 9.0.
It works on Mac using 8.6, but does not work with Tcl 9.0.





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

Repository version of tktreectrl works on Windows, Linux, Mac using Tcl 8.6 and 9.0.

Note, that I tested the packages only by using the simple scripts contained in the BAWT framework.






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

 

Re: [TCLCORE] On editing whitespace

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

It is pretty disturbing to see a commit containing nothing but changes to
whitespace after this discussion.

- Marc

On Wed, Jun 18, 2025, 2:48 PM Francois Vogel <fvo...@fr...> wrote:

> It's comforting to observe that people's common views are being listened
> to.
>
>
> https://core.tcl-lang.org/tcl/info/40d70239582496f7b96a6024fa78bca461f5e3b94611d117414377d6f6f53c9b
>
> Listen, this project will go on without me. I take a break (at least).
>
> Francois
> Le 04/06/2025 à 21:55, Francois Vogel a écrit :
>
> Let me just state that I strongly second this exact request I have made a
> few times before (at no avail).
>
> Oh, and yes I know there is a switch in fossil allowing to ignore
> whitespaces in diffs. No, that does not make a true difference on the
> subject.
>
> Again: this is not about choosing between spaces and tabs. The Tcl
> engineering manual is clear about this (set TIP #247). It is about not
> changing what is already there, be it spaces or tabs. And this is true too
> for whitespace at end of lines.
>
> Regards,
>
> Francois
> Le 04/06/2025 à 18:24, apnmbx-public--- via Tcl-Core a écrit :
>
> On more than one occasion in the past couple of months, commits have been
> made that include copious changes of spaces to tabs. TIP 247, which
> presumably is the coding standard Tcl core follows, does not have any
> mandate to use tabs afaict. If that is the case, can we please desist from
> such changes? Without getting into a tabs vs spaces war (personally, I
> prefer spaces) can we just respect whatever exists as long as it meets the
> standard (indent of 4 etc.) It has practical implications in that, when
> reviewing diffs or merging, one has to go unnecessarily go through each
> diff to see what changed.
>
>
>
> /Ashok
>
>
> _______________________________________________
> Tcl-Core mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
>
> _______________________________________________
> Tcl-Core mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tcl-core
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] On editing whitespace

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

It's comforting to observe that people's common views are being listened to.

https://core.tcl-lang.org/tcl/info/40d70239582496f7b96a6024fa78bca461f5e3b94611d117414377d6f6f53c9b

Listen, this project will go on without me. I take a break (at least).

Francois

Le 04/06/2025 à 21:55, Francois Vogel a écrit :
>
> Let me just state that I strongly second this exact request I have 
> made a few times before (at no avail).
>
> Oh, and yes I know there is a switch in fossil allowing to ignore 
> whitespaces in diffs. No, that does not make a true difference on the 
> subject.
>
> Again: this is not about choosing between spaces and tabs. The Tcl 
> engineering manual is clear about this (set TIP #247). It is about not 
> changing what is already there, be it spaces or tabs. And this is true 
> too for whitespace at end of lines.
>
> Regards,
>
> Francois
>
> Le 04/06/2025 à 18:24, apnmbx-public--- via Tcl-Core a écrit :
>>
>> On more than one occasion in the past couple of months, commits have 
>> been made that include copious changes of spaces to tabs. TIP 247, 
>> which presumably is the coding standard Tcl core follows, does not 
>> have any mandate to use tabs afaict. If that is the case, can we 
>> please desist from such changes? Without getting into a tabs vs 
>> spaces war (personally, I prefer spaces) can we just respect whatever 
>> exists as long as it meets the standard (indent of 4 etc.) It has 
>> practical implications in that, when reviewing diffs or merging, one 
>> has to go unnecessarily go through each diff to see what changed.
>>
>> /Ashok
>>
>>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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

[Paul O. <pa...@po...>]

Some history.
I originally had Rene's tkpath version in BAWT (last update was in 2018),
which does not compile on Mac.
Manfred Rosenberger (author of tkpath based RattleCAD) asked me to add
Christian Werner's version of tkpath, because his version runs on Mac and
has several other fixes.
After Tcl9 release Steve Shaw sent me a Tcl9 ready version of tkpath.
Unfortunately this version was based on Rene's version (no Mac) and did only
work with Tcl9, but not Tcl8.
I then merged the Tcl9 changes into Christian's version, which is the version 0.4.0
available with BAWT.

So in my point of view, the BAWT version is the most advanced one.
It runs the test suite without errors on Windows and Linux using Tcl/Tk 8.6.16 and Tcl/Tk 9.0.1
The test suite runs on Mac with 1 error both using Tcl/Tk 8.6.16 and 9.0.1, see below.

Paul

==== canvText-1.12 configuration options: bad value for -stipple FAILED
==== Contents of test case:

     .c create text 20 20 -tag test
     .c itemconfigure test $name $badValue

---- Test completed normally; Return code was: 0
---- Return code should have been one of: 1
==== canvText-1.12 FAILED


Am 18.06.2025 um 05:26 schrieb apnmbx-public--- via Tcl-Core:
>
> Thanks Paul. Do you know if your version of tkpath also incorporates Rene’s changes from chiselapp?
>
> I hope someone picks up tkpath, else I will make an attempt at a merge at some point. For the macOS issues, I’m afraid I have no way of testing GUI’s. At least for console only, Github actions can be used (painfully).
>
> /Ashok
>
> *From:*Paul Obermeier <pa...@po...>
>
> I do have a version of tkpath, which is a merge of Christian's and Steve's work and compiles
> using Tcl 8.6 and 9.0 on Windows, Linux and Mac.
> See https://www.bawt.tcl3d.org/download/InputLibs/tkpath-0.4.0.7z
>
> It works on Windows and Linux using Tcl 8.6 and 9.0.
> It works on Mac using 8.6, but does not work with Tcl 9.0.
>
>
>     tktreectrl and tkpath have been tested on Windows and Linux. Someone testing on macOS would be helpful.
>
> Repository version of tktreectrl works on Windows, Linux, Mac using Tcl 8.6 and 9.0.
>
> Note, that I tested the packages only by using the simple scripts contained in the BAWT framework.
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] [Ext] Re: tclx, tktreectrl and tkpath repositories and a request

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

René,
thanks for your proposal.

To my knowledge, your version is quite modified and has the 
"compatibility layer" to the canvas removed.
You reported in the conference, that there are two coordinate systems: 
one working with tensors and one with coordinates (canvas).

I think, we are first seeking to bugfixes and tk 9 patches of the 
current "legacy" implementation.

It would be great, if both versions may live together or would be 
compatible.

The great tko layer is also a candidate for the tk core...

Thanks for all,
Harald

Am 18.06.2025 um 09:31 schrieb Zaumseil René via Tcl-Core:
> Hello
> 
> My version of tkpath is now contained in tko https://chiselapp.com/user/ 
> rene/repository/tko <https://chiselapp.com/user/rene/repository/tko>
> 
> Together with rbc::graph.
> 
> I have switched to an oo widget style.
> 
> Should I create a ticket to include it in thehttps://github.com/tcltk- 
> depot <https://github.com/tcltk-depot>
> 
> I'm maintaining this version. It is used in our simulator.
> 
> Regards
> 
> René
> 
> *Von:*apnmbx-public--- via Tcl-Core <tcl...@li...>
> *Gesendet:* Mittwoch, 18. Juni 2025 05:27
> *An:* 'Paul Obermeier' <pa...@po...>; tcl...@li...
> *Betreff:* [Ext] Re: [TCLCORE] tclx, tktreectrl and tkpath repositories 
> and a request
> 
> Thanks Paul. Do you know if your version of tkpath also incorporates 
> Rene’s changes from chiselapp?
> 
> I hope someone picks up tkpath, else I will make an attempt at a merge 
> at some point. For the macOS issues, I’m afraid I have no way of testing 
> GUI’s. At least for console only, Github actions can be used (painfully).
> 
> /Ashok
> 
> *From:*Paul Obermeier <pa...@po... <mailto:pa...@po...>>
> 
> I do have a version of tkpath, which is a merge of Christian's and 
> Steve's work and compiles
> using Tcl 8.6 and 9.0 on Windows, Linux and Mac.
> See https://www.bawt.tcl3d.org/download/InputLibs/tkpath-0.4.0.7z 
> <https://www.bawt.tcl3d.org/download/InputLibs/tkpath-0.4.0.7z>
> 
> It works on Windows and Linux using Tcl 8.6 and 9.0.
> It works on Mac using 8.6, but does not work with Tcl 9.0.
> 
>     tktreectrl and tkpath have been tested on Windows and Linux. Someone
>     testing on macOS would be helpful.
> 
> Repository version of tktreectrl works on Windows, Linux, Mac using Tcl 
> 8.6 and 9.0.
> 
> Note, that I tested the packages only by using the simple scripts 
> contained in the BAWT framework.
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core


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

Re: [TCLCORE] [Ext] Re: tclx, tktreectrl and tkpath repositories and a request

[Zaumseil R. <RZa...@kk...>]

Hello

My version of tkpath is now contained in tko https://chiselapp.com/user/rene/repository/tko
Together with rbc::graph.
I have switched to an oo widget style.

Should I create a ticket to include it in the https://github.com/tcltk-depot

I'm maintaining this version. It is used in our simulator.


Regards
René

Von: apnmbx-public--- via Tcl-Core <tcl...@li...>
Gesendet: Mittwoch, 18. Juni 2025 05:27
An: 'Paul Obermeier' <pa...@po...>; tcl...@li...
Betreff: [Ext] Re: [TCLCORE] tclx, tktreectrl and tkpath repositories and a request

Thanks Paul. Do you know if your version of tkpath also incorporates Rene's changes from chiselapp?

I hope someone picks up tkpath, else I will make an attempt at a merge at some point. For the macOS issues, I'm afraid I have no way of testing GUI's. At least for console only, Github actions can be used (painfully).

/Ashok

From: Paul Obermeier <pa...@po...<mailto:pa...@po...>>
I do have a version of tkpath, which is a merge of Christian's and Steve's work and compiles
using Tcl 8.6 and 9.0 on Windows, Linux and Mac.
See https://www.bawt.tcl3d.org/download/InputLibs/tkpath-0.4.0.7z

It works on Windows and Linux using Tcl 8.6 and 9.0.
It works on Mac using 8.6, but does not work with Tcl 9.0.

tktreectrl and tkpath have been tested on Windows and Linux. Someone testing on macOS would be helpful.
Repository version of tktreectrl works on Windows, Linux, Mac using Tcl 8.6 and 9.0.

Note, that I tested the packages only by using the simple scripts contained in the BAWT framework.

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

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

Thanks Paul. Do you know if your version of tkpath also incorporates Rene’s changes from chiselapp?

 

I hope someone picks up tkpath, else I will make an attempt at a merge at some point. For the macOS issues, I’m afraid I have no way of testing GUI’s. At least for console only, Github actions can be used (painfully).

 

/Ashok

 

From: Paul Obermeier <pa...@po...> 

I do have a version of tkpath, which is a merge of Christian's and Steve's work and compiles  
using Tcl 8.6 and 9.0 on Windows, Linux and Mac.
See https://www.bawt.tcl3d.org/download/InputLibs/tkpath-0.4.0.7z

It works on Windows and Linux using Tcl 8.6 and 9.0.
It works on Mac using 8.6, but does not work with Tcl 9.0.




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

Repository version of tktreectrl works on Windows, Linux, Mac using Tcl 8.6 and 9.0.

Note, that I tested the packages only by using the simple scripts contained in the BAWT framework.

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

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

On Jun 17, 2025, at 16:28, Donald Porter via Tcl-Core <tcl...@li...> wrote:



On Jun 17, 2025, at 4:12 PM, Paul Obermeier <pa...@po...> wrote:
Tested Brian's branch, found an error, but did not find a button for submitting an issue in the tclx repository.
Compiling with Tcl9 does not work, because TCL_RESULT_SIZE does not exist anymore.
Adding
#ifndef TCL_RESULT_SIZE
#define TCL_RESULT_SIZE 200
#endif
makes it compile and work both with Tcl 8.6 and 9.0 (Windows, Linux, Mac).

At the risk of saying something that is already blinking obvious to everybody…

If there is code that wants to make use of TCL_RESULT_SIZE, it is very likely also seeking to interact with the interp->result field or with Tcl_FreeResult(), which are both gone gone gone in Tcl 9.  Resupplying the missing #define isn’t going to address the issue.

Or, possibly the code was using TCL_RESULT_SIZE, but was always using it wrong, in some manner disconnected from its intended purpose.

Best aim to track down the issue and squash it.

Thanks for the warning. In this case, it's just temp space needed before calling an appropriate Append operation.
I will clean up the code, as it is a bit old, but not broken.

-Brian


DGP

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

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

[Donald P. <d.g...@co...>]

> On Jun 17, 2025, at 4:12 PM, Paul Obermeier <pa...@po...> wrote:
> Tested Brian's branch, found an error, but did not find a button for submitting an issue in the tclx repository.
> Compiling with Tcl9 does not work, because TCL_RESULT_SIZE does not exist anymore.
> Adding
> #ifndef TCL_RESULT_SIZE
> #define TCL_RESULT_SIZE 200
> #endif
> makes it compile and work both with Tcl 8.6 and 9.0 (Windows, Linux, Mac).

At the risk of saying something that is already blinking obvious to everybody…

If there is code that wants to make use of TCL_RESULT_SIZE, it is very likely also seeking to interact with the interp->result field or with Tcl_FreeResult(), which are both gone gone gone in Tcl 9.  Resupplying the missing #define isn’t going to address the issue.

Or, possibly the code was using TCL_RESULT_SIZE, but was always using it wrong, in some manner disconnected from its intended purpose.

Best aim to track down the issue and squash it.

DGP

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

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

Thanks Paul, I’ll take a look, and see about tickets as well.

Not all of Tclx is functional. Some parts should be dropped. Some parts have been dropped.
The profiler needs a deep dive, which I haven’t had the time to do yet.

-Brian
(from mobile device)

On Jun 17, 2025, at 13:29, Paul Obermeier <pa...@po...> wrote:

 Thanks Ashok for your effort.

I have a few questions and remarks, see below.

Paul

Am 17.06.2025 um 08:40 schrieb apnmbx-public--- via Tcl-Core:
tclx, tktreectrl and tkpath have been added to the Tcl/Tk “orphaned extensions” repository at https://github.com/tcltk-depot.

Thanks to Brian Griffin for tclx.
Tested Brian's branch, found an error, but did not find a button for submitting an issue in the tclx repository.
Compiling with Tcl9 does not work, because TCL_RESULT_SIZE does not exist anymore.
Adding
#ifndef TCL_RESULT_SIZE
#define TCL_RESULT_SIZE 200
#endif
makes it compile and work both with Tcl 8.6 and 9.0 (Windows, Linux, Mac).


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

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

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

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

I do have a version of tkpath, which is a merge of Christian's and Steve's work and compiles
using Tcl 8.6 and 9.0 on Windows, Linux and Mac.
See https://www.bawt.tcl3d.org/download/InputLibs/tkpath-0.4.0.7z

It works on Windows and Linux using Tcl 8.6 and 9.0.
It works on Mac using 8.6, but does not work with Tcl 9.0.

tktreectrl and tkpath have been tested on Windows and Linux. Someone testing on macOS would be helpful.
Repository version of tktreectrl works on Windows, Linux, Mac using Tcl 8.6 and 9.0.

Note, that I tested the packages only by using the simple scripts contained in the BAWT framework.

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

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

[Paul O. <pa...@po...>]

Thanks Ashok for your effort.

I have a few questions and remarks, see below.

Paul

Am 17.06.2025 um 08:40 schrieb apnmbx-public--- via Tcl-Core:
>
> tclx, tktreectrl and tkpath have been added to the Tcl/Tk “orphaned extensions” repository at https://github.com/tcltk-depot.
>
> Thanks to Brian Griffin for tclx.
>
Tested Brian's branch, found an error, but did not find a button for submitting an issue in the tclx repository.
Compiling with Tcl9 does not work, because TCL_RESULT_SIZE does not exist anymore.
Adding
#ifndef TCL_RESULT_SIZE
#define TCL_RESULT_SIZE 200
#endif
makes it compile and work both with Tcl 8.6 and 9.0 (Windows, Linux, Mac).

> Thanks to @egavilan (Emiliano) for the porting tktreectrl to Tcl/Tk 9 and @bandito for updating the build system to the latest tclconfig.
>
> tkpath comes from the fork used in HammerDB and updates from Steve Shaw (@sm-shaw) for tkpath. It has been updated for Tcl/Tk 9 but may need work to build for Tcl 8.6.
>
> Looking for volunteers to take ownership of the above (merge other forks as necessary, review pull requests and bug reports etc.) If you can help, let Harald, Emiliano or me know and we can add you as a member.
>
> For tkpath in particular, there are at least a couple of forks – Rene’s on chiselapp and Christian’s Androwish. I could not tell the temporal relation with the above tkpath so it would help if Rene, Christian or someone familiar could see what, if anything, might need to be merged.
>
I do have a version of tkpath, which is a merge of Christian's and Steve's work and compiles
using Tcl 8.6 and 9.0 on Windows, Linux and Mac.
See https://www.bawt.tcl3d.org/download/InputLibs/tkpath-0.4.0.7z

It works on Windows and Linux using Tcl 8.6 and 9.0.
It works on Mac using 8.6, but does not work with Tcl 9.0.

> tktreectrl and tkpath have been tested on Windows and Linux. Someone testing on macOS would be helpful.
>
Repository version of tktreectrl works on Windows, Linux, Mac using Tcl 8.6 and 9.0.

Note, that I tested the packages only by using the simple scripts contained in the BAWT framework.

Re: [TCLCORE] Update of macosx/Readme

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

Thanks!

The x86 was a typo.  The arm64 is correct. I changed "x86" to "x86_64" and
removed the reference to Apple Silicon.

- Marc

On Tue, Jun 17, 2025 at 11:04 AM Alexander Schöpe <a.s...@gm...> wrote:

> Hi Marc,
>
> my point is that in one place it says x86 but it should be x86_64, and in
> another place it says arm64 and elsewhere Apple Silicon.
> Maybe it would be better to consistently use only the architecture names,
> and write them correctly everywhere.
>
> Best
> Alex
>
> > Am 17.06.2025 um 17:04 schrieb Marc Culler <cul...@gm...>:
> >
> > According to the internet, the production of "Apple Silicon" is
> outsourced to Samsung and Taiwan Semiconductor Manufacturing Company but
> Apple owns the trademark and provides the design (via ARM).
> >
> > Perhaps it would be formally better to call it "Apple Silicon™" if we
> want to be pedantic.
> >
> > - Marc
> >
> >
> > On Tue, Jun 17, 2025 at 9:56 AM Marc Culler <cul...@gm...> wrote:
> > I don't know of  any formal requirement that would be satisfied by
> mentioning "Apple Silicon".  As far as I know "Apple Silicon" is not an
> architecture; it is a trade mark that indicates who the chip manufacturer
> is.  So I would actually consider it formally incorrect to refer to it as
> an architecture.  But if you think it clarifies something then I have no
> objection to mentioning it.
> >
> > - Marc
> >
> > On Tue, Jun 17, 2025 at 9:45 AM Alexander Schöpe via Tcl-Core <
> tcl...@li...> wrote:
> > Maybe a bit pedantic, but formally better:
> >
> > The minimum macOS versions supported by Tcl differ for the x86_64 and
> arm64 architectures because macOS 11 was the first OS version that
> supported arm64 (Apple Silicon).
> >
> >
> > > Am 17.06.2025 um 16:20 schrieb Harald Oehlmann <
> har...@el...>:
> > >
> > > Marc,
> > > thanks for updating the macos readme on the main branch:
> > >
> > > When looking to:
> > > https://core.tcl-lang.org/tips/doc/trunk/tip/715.md
> > >
> > > there is the requirement of Mac-OS 11 for arm64 silicon.
> > > May this information be added?
> > >
> > > As 9.0.2 is knocking on the door: are there any correction for this
> branch?
> > >
> > > Thanks for all,
> > > Harald
> > > _______________________________________________
> > > Tcl-Core mailing list
> > > Tcl...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tcl-core
> >
> >
> >
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>

Re: [TCLCORE] Update of macosx/Readme

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

Hi Marc,

my point is that in one place it says x86 but it should be x86_64, and in another place it says arm64 and elsewhere Apple Silicon.
Maybe it would be better to consistently use only the architecture names, and write them correctly everywhere.

Best
Alex

> Am 17.06.2025 um 17:04 schrieb Marc Culler <cul...@gm...>:
> 
> According to the internet, the production of "Apple Silicon" is outsourced to Samsung and Taiwan Semiconductor Manufacturing Company but Apple owns the trademark and provides the design (via ARM).
> 
> Perhaps it would be formally better to call it "Apple Silicon™" if we want to be pedantic.
> 
> - Marc
> 
> 
> On Tue, Jun 17, 2025 at 9:56 AM Marc Culler <cul...@gm...> wrote:
> I don't know of  any formal requirement that would be satisfied by mentioning "Apple Silicon".  As far as I know "Apple Silicon" is not an architecture; it is a trade mark that indicates who the chip manufacturer is.  So I would actually consider it formally incorrect to refer to it as an architecture.  But if you think it clarifies something then I have no objection to mentioning it.
> 
> - Marc 
> 
> On Tue, Jun 17, 2025 at 9:45 AM Alexander Schöpe via Tcl-Core <tcl...@li...> wrote:
> Maybe a bit pedantic, but formally better:
> 
> The minimum macOS versions supported by Tcl differ for the x86_64 and arm64 architectures because macOS 11 was the first OS version that supported arm64 (Apple Silicon).
> 
> 
> > Am 17.06.2025 um 16:20 schrieb Harald Oehlmann <har...@el...>:
> > 
> > Marc,
> > thanks for updating the macos readme on the main branch:
> > 
> > When looking to:
> > https://core.tcl-lang.org/tips/doc/trunk/tip/715.md
> > 
> > there is the requirement of Mac-OS 11 for arm64 silicon.
> > May this information be added?
> > 
> > As 9.0.2 is knocking on the door: are there any correction for this branch?
> > 
> > Thanks for all,
> > Harald
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Update of macosx/Readme

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

According to the internet, the production of "Apple Silicon" is outsourced
to Samsung and Taiwan Semiconductor Manufacturing Company but Apple owns
the trademark and provides the design (via ARM).

Perhaps it would be formally better to call it "Apple Silicon™" if we want
to be pedantic.

- Marc


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

> I don't know of  any formal requirement that would be satisfied by
> mentioning "Apple Silicon".  As far as I know "Apple Silicon" is not an
> architecture; it is a trade mark that indicates who the chip manufacturer
> is.  So I would actually consider it formally incorrect to refer to it as
> an architecture.  But if you think it clarifies something then I have no
> objection to mentioning it.
>
> - Marc
>
> On Tue, Jun 17, 2025 at 9:45 AM Alexander Schöpe via Tcl-Core <
> tcl...@li...> wrote:
>
>> Maybe a bit pedantic, but formally better:
>>
>> The minimum macOS versions supported by Tcl differ for the x86_64 and
>> arm64 architectures because macOS 11 was the first OS version that
>> supported arm64 (Apple Silicon).
>>
>>
>> > Am 17.06.2025 um 16:20 schrieb Harald Oehlmann <
>> har...@el...>:
>> >
>> > Marc,
>> > thanks for updating the macos readme on the main branch:
>> >
>> > When looking to:
>> > https://core.tcl-lang.org/tips/doc/trunk/tip/715.md
>> >
>> > there is the requirement of Mac-OS 11 for arm64 silicon.
>> > May this information be added?
>> >
>> > As 9.0.2 is knocking on the door: are there any correction for this
>> branch?
>> >
>> > Thanks for all,
>> > Harald
>> > _______________________________________________
>> > Tcl-Core mailing list
>> > Tcl...@li...
>> > https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>

Re: [TCLCORE] Update of macosx/Readme

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

I don't know of  any formal requirement that would be satisfied by
mentioning "Apple Silicon".  As far as I know "Apple Silicon" is not an
architecture; it is a trade mark that indicates who the chip manufacturer
is.  So I would actually consider it formally incorrect to refer to it as
an architecture.  But if you think it clarifies something then I have no
objection to mentioning it.

- Marc

On Tue, Jun 17, 2025 at 9:45 AM Alexander Schöpe via Tcl-Core <
tcl...@li...> wrote:

> Maybe a bit pedantic, but formally better:
>
> The minimum macOS versions supported by Tcl differ for the x86_64 and
> arm64 architectures because macOS 11 was the first OS version that
> supported arm64 (Apple Silicon).
>
>
> > Am 17.06.2025 um 16:20 schrieb Harald Oehlmann <
> har...@el...>:
> >
> > Marc,
> > thanks for updating the macos readme on the main branch:
> >
> > When looking to:
> > https://core.tcl-lang.org/tips/doc/trunk/tip/715.md
> >
> > there is the requirement of Mac-OS 11 for arm64 silicon.
> > May this information be added?
> >
> > As 9.0.2 is knocking on the door: are there any correction for this
> branch?
> >
> > Thanks for all,
> > Harald
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Update of macosx/Readme

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

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

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

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

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

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

- Marc

Re: [TCLCORE] Update of macosx/Readme

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

Maybe a bit pedantic, but formally better:

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


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

[TCLCORE] Update of macosx/Readme

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

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

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

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

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

Thanks for all,
Harald

[TCLCORE] TIP #712 accepted and merged

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

Vote-Summary: Accepted 8/0/0

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

Votes-Against: none

Votes-Present: none

TIP #712 accepted.

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

Thanks,
Reinhard

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

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

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

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

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

Feel supported and appreciated,
Harald

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

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

Hi,

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

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

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

Cheers, Torsten


> Am 16.06.2025 um 14:55 schrieb Harald Oehlmann <Har...@El...>:
> 
> Signierter PGP-Teil
> Dear Tcl/Tk team,
> 
> thank you for your participation at the telco.
> 
> An old agenda was followed. Sorry.
> But it was a great meeting !
> 
> Here is my report:
> 1) Release items for TCL/Tk 9.0.2
> Branch will start today.
> Testing is clean.
> RC0 is ready soon.
> 
> Ashok has some bug-fixes, which may only go to 9.1.
> Only important on heavy load, use after free.
> Not for 9.0.2, as there are risks.
> 
> lseq corner cases will probably also not in 9.0.2, currently only in 9.1. Donal Fellows has taken over with new test cases.
> 
> 2) Release items for Tcl/Tk 9.1.0a0
> www.tcl-lang.org
> -> new page needed for 9.1 as this one:
> https://www.tcl-lang.org/software/tcltk/9.0.html
> -> Copy the .tml template file.
> -> include input from "changes.md".
> 
> 3) TIP 723: monotonic clock: is it a bug? Platform solutions
> New specification, no implementation jet, is for later.
> 
> 4) TIP 712: positive options to the subst command
> TIP merged, all ok.
> 
> 5) Reinhards new socket stuff
> May start as an extension and then go to the core.
> 
> QUICK WIP by Schelte.
> Link to new socket stuff is not clear.
> 
> 6) tk print enhancements
> Great part of 9.0.2 - thank you.
> Very careful work - test cases present, great work.
> 
> 7) TIP 725: JSON PLIST access
> Ok to have platform specific things as long as they are commonly useful.
> 
> It would be great if JSON data would be natively supported by 9.1.
> We need more people in the core to make dreams reality.
> 
> 8) TIP 720: TCL compiler reform
> Great work, try, lseq,...
> 
> We need duplicate the test cases for compiled, semi-compiled and not compiled for each newly compiled command: try, lseq, ...
> 
> 9) Documentation
> Great work, thanks Torsten!
> Back-porting of corrections would be great.
> 
> Troff-file corrections may be merged before md merge, but no hurry.
> 
> 10) Bundled packages
> 
> - SQLite: February Version will be distributed. Current update from SQLite is pending, but not in 9.0.2.
> - TDBC: there are changes, but no reason to hurry for 9.0.2.
> 
> Massimo, what about a release of TDBC?
> 
> 10) Orphan packages repository
> 
> tkpath added from Steve Shaw, which is the latested.
> Others are in Androwish and from René and BAWT.
> Contributions welcome !
> 
> 11) Conference status
> Deadline soon.
> 
> 12) Init functions.
> I have to add something to the Init on Windows.
> Which are the calls for Init?
> Tcl_FindExecutable(NULL)
> Once per process should be sufficient.
> Tcl_CreateInterp()
> 
> 13) tclconfig project
> The project has a couple of changes.
> This would change all bundled packages.
> 
> 14) TIP 649: List API TIP
> Vote warning soon.
> Nobody commented the question about reference count details.
> Input welcome!
> 
> Other meetings:
> 30th of June 12:00 UTC: UTC Monthly Virtual Meetup on same jitsi
> 
> Thank you all,
> Harald
> 
>