tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TCL/Tk biweekly telco on 24th of Mars, 2025 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

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

Harald,

I'd like to add the following topics -

TIP 715 - platform support definitions. 

TIP 710 - development workflow and TIP process which seems to have stalled.

/Ashok 

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Friday, March 21, 2025 2:56 PM
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] TCL/Tk biweekly telco on 24th of Mars, 2025 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

Dear Tcl/Tk team,
please allow me to invite anybody to the telco:
Where: https://meet.jit.si/TclMonthlyMeetup
When: 2025-03-24 12:00 UTC

Possible discussion points:

1) Possible Incompatible changes for 9.1 in Tk
- "tk grid" https://core.tcl-lang.org/tk/info/7c51624a96ab2092
- "tk_getOpenFile -xpstyle 1" 
https://core.tcl-lang.org/tk/tktview/441c526c0d

2) Stop Tcl/Tk 8.7 ?

3) coroutine traces symetry (Sergey calls for comments): 
https://core.tcl-lang.org/tcl/info/5bd41844e62aceb2

4) bytecode compiler optimization by Donal Fellows

5) TIP 700: Documentation

6) Next meeting time: Europe will move to daytime saving time -> keep 
12:00 UTC ? Date will be 7th of April 2025

7) Conference news

8) Any other business

Thank you all,
Harald

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

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

Jan,

 

Sorry, I understood neither of the points you made.

 

> Since ALL of the commands are modified to use Tcl_Size objc, all current
testcases test the new behavior.

 

This means nothing. The new behavior defined by the TIP requires commands to
accept > 2**31 arguments. Nothing in the test suite verifies this. I'll
point out again that the same exact logic could be applied to the 32-bit ->
64bit transition for 9.0. "All structures now use Tcl_Size so all current
testcases test..". And this thinking was probably why tests were not added
there either. And yet in reality most commands did not work with lengths >
2**31 even in beta 1 until the implementation was specifically tested in
bigdata.test.

 

If you were in fact right about the current test suite being adequate, why
would the simple test I did fail?

 

> You already wrote a testcase for that, see:.

 

The test you mention verifies that 9.0 raises an error instead of crashing
when argument lengths are exceeded. It does not verify correct operation of
commands. I am not sure I see the relevance to the "no such variable"
failure example I gave.

 

 

 

-----Original Message-----
From: Jan Nijtmans <jan...@gm...> 
Sent: Monday, March 24, 2025 12:24 AM
To: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31
elements

 

Op zo 23 mrt 2025 om 18:28 schreef < <mailto:apn...@ya...>
apn...@ya...>:

> Jan,

> Having had only a cursory look so far, I only have a few preliminary
comments and questions.

> 

> The implementation touches a lot of files and although most are nominal
size changes, it will take some time to review. Please wait at least a
couple of weeks, if not more, before calling for a vote.

 

That's OK. You will see the pattern soon.

 

> I did not see any test cases.

 

Since ALL of the commands are modified to use Tcl_Size objc, all

current testcases

test the new behavior. All current extensions (like thread or Itcl)

still use the "int objc"

functions, that's how you can verify that the original functions still

work OK too.

 

> Does the TIP only address the generic framework for passing arguments or
are all core commands expected to also work? I ask because just my second
attempt to exercise the functionality failed (I am not sure how to
practically generate a large number of arguments other than use of {*}):

> 

> % set s [string cat {*}[lrepeat 0x100000000 x]]; string length $s

> 

> can't read "s": no such variable

 

You already wrote a testcase for that, see:

     < <https://core.tcl-lang.org/tcl/info/eb734aab392c0b31>
https://core.tcl-lang.org/tcl/info/eb734aab392c0b31>

This testcase should be modified now to no longer give an error.

 

All core commands and extensions are expected to work as they do now.

The only exception I am aware of is "nsf", since it pokes into the

internal structures.

 

Hope this helps,

    Jan Nijtmans

 

 

_______________________________________________

Tcl-Core mailing list

 <mailto:Tcl...@li...> Tcl...@li...

 <https://lists.sourceforge.net/lists/listinfo/tcl-core>
https://lists.sourceforge.net/lists/listinfo/tcl-core

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

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

Op zo 23 mrt 2025 om 18:28 schreef <apn...@ya...>:
> Jan,
> Having had only a cursory look so far, I only have a few preliminary comments and questions.
>
> The implementation touches a lot of files and although most are nominal size changes, it will take some time to review. Please wait at least a couple of weeks, if not more, before calling for a vote.

That's OK. You will see the pattern soon.

> I did not see any test cases.

Since ALL of the commands are modified to use Tcl_Size objc, all
current testcases
test the new behavior. All current extensions (like thread or Itcl)
still use the "int objc"
functions, that's how you can verify that the original functions still
work OK too.

> Does the TIP only address the generic framework for passing arguments or are all core commands expected to also work? I ask because just my second attempt to exercise the functionality failed (I am not sure how to practically generate a large number of arguments other than use of {*}):
>
> % set s [string cat {*}[lrepeat 0x100000000 x]]; string length $s
>
> can't read "s": no such variable

You already wrote a testcase for that, see:
     <https://core.tcl-lang.org/tcl/info/eb734aab392c0b31>
This testcase should be modified now to no longer give an error.

All core commands and extensions are expected to work as they do now.
The only exception I am aware of is "nsf", since it pokes into the
internal structures.

Hope this helps,
    Jan Nijtmans

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

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

Jan,

 

Having had only a cursory look so far, I only have a few preliminary
comments and questions.

 

The implementation touches a lot of files and although most are nominal size
changes, it will take some time to review. Please wait at least a couple of
weeks, if not more, before calling for a vote.

 

I have the same reservations as Sergey and Eric but I also see the symmetry
with list lengths that Christian W. cited so I am ambivalent at the moment.

 

I did not see any test cases. I am of the opinion that for any TIP, not just
626, a reasonable test suite should be in place before a CFV. This is
particularly important when so many files and API's are touched by the TIP.
The existing test suite does not suffice because it does not cover the
enhancement the TIP proposes. Early 9.0 betas shipped without any tests for
64-bit support and as might be expected, practically no string commands
worked for large data. That is not acceptable imo. Accordingly, for 626,
tests should be added as well, probably in bigdata.test, testing both
byte-compiled and uncompiled forms as they exercise different code paths.

 

Does the TIP only address the generic framework for passing arguments or are
all core commands expected to also work? I ask because just my second
attempt to exercise the functionality failed (I am not sure how to
practically generate a large number of arguments other than use of {*}):

 

% set s [string cat {*}[lrepeat 0x100000000 x]]; string length $s

can't read "s": no such variable

 

A strange error. May be just an isolated bug but regardless, test cases that
exercise at least basic commands are needed to ensure there is not a more
general fundamental issue.

 

This is on Stefan's monster 128GB machine so I don't think memory is an
issue. 

 

/Ashok

 

-----Original Message-----
From: Jan Nijtmans <jan...@gm...> 
Sent: Thursday, March 20, 2025 9:21 PM
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

 

This is a CFV warning for TIP #626. for Tcl 9.1+:

    Command arguments > 2^31 elements

    < <https://core.tcl-lang.org/tips/doc/trunk/tip/626.md>
https://core.tcl-lang.org/tips/doc/trunk/tip/626.md>

 

If you think this is a bad idea, speak up now. If not,

I'll start the vote in a few days.

 

Regards,

         Jan Nijtmans

 

 

_______________________________________________

Tcl-Core mailing list

 <mailto:Tcl...@li...> Tcl...@li...

 <https://lists.sourceforge.net/lists/listinfo/tcl-core>
https://lists.sourceforge.net/lists/listinfo/tcl-core

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

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

Pathetic opinion of someone who's not in charge:

In  a Bird's-eye view (or U-boat perspective) the number
of parameters to a procedure ideally should be equal to
the number of elements a list can contain. Pure symmetry.
Aesthetics. And it may be infinite at least in theory of
course, disregarding any contemporary machinery and
algorithms. I.e. "argc" or "objc" shall be a bignum
(I'm kidding).

Just another two hundredths of your favorite currency unit,
Christian

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

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

Op vr 21 mrt 2025 om 20:05 schreef Dipl. Ing. Sergey G. Brester via
Tcl-Core <tcl...@li...>:
> green - 9.1 without TIPs 627/626 & no 64-bit counters in Command- and other structs (Tcl_Size <-> int),
> red - 9.1 with TIPs 627/626 & 64-bit counters

My conclusion (but you have the right to differ in your opinion). Since TIP #626
doesn't change any struct members, any change in timing you see here is can
be attributed to your additional Tcl_Size <-> int changes, not to the TIP #626
implementation. What will increase is the stack usage, because any function
having a Tcl_Size objc argument will use 4 bytes more on the stack than
int objc arguments. That will only be noticed in deep recursive function
calls, that's not what you are doing in this example. Neither does
Tcl do that in the new NR implementation.

Thanks!
     Jan Nijtmans

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

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

 

Well, as already said it is anyway very questionable approach, and even
a generation of lists with 2**31 elements in tcl is very doubtful (even
repeating the same element 2**31 times expects alone by creation 16GB
memory, by duplication for eval of proc further 16GB, so 32GB after end,
without to do something with the list). Not to mention the memory
consume, evaluation times and co in the real case (not in "obscure" case
like bottom example with lrepeat). Again, a pure tcl-list with 2**31
real elements (even numbers, let alone the strings and co) would need
too many memory, so it makes the usage of them senseless. No matter
direct or expanded to command args, let alone the implicit duplication
(CoW, CoE, etc) if the object is shared.

And all this to avoid something like that? 

% llength [set l [lrepeat [expr {2**31}] _]]
2147483648
% proc test args {llength $args}; test {*}$l
Number of words (2147483649) in command exceeds limit 2147483647. 

The impact on memory usage (by replacing int32 with int64) is not
interesting per se (as I said the memory is cheap), but must be
considered in conjunction with CPU cache/granularity/coherence, rather
as possible cause for performance deterioration. 

The issue with the performance is obvious without to measure something: 

 	* the usage of extra layer (cmdWrapperProc) would make it already
slower directly. How can it be otherwise if still one function gets
involved per invocation of any command (invokeStk instructions and co)?

	* the few extra bytes in tcls internal structures wouldn't show it
direct with simple measurements, but would surely play a role, because
CPU cache is not endless and every single byte (ADDED EN MASSE), can
cause more washouts, cache invalidations, etc.
And if in case of L3 it is not so grave, in case of L1 or L2 we'd speak
about factor 100x (0.33ns L1- vs. 33.33ns MEM-access) 	* the measurement
would be complex, but as already mentioned - totally unneeded, because
it's basically obvious.

However if you really want - here is even though artificial construct,
but it can illustrate the regression: 

timerate -calibrate {};
proc test k {
 upvar cmd cmd body body
 if {![info exists cmd($k)]} {
 # just a lot of procs with dummy bodies (if called with 0):
 set pbody [string repeat "if {$a} {" 100][string repeat "}" 100]
 set i 0; while {$i<=$k} {
 proc [set cmd($i) test$i] {a args} $pbody
 incr i
 }
 # reorder it additionally to array hash buckets arbitrary but
deterministic,
 # (so they are "random" in the same way - able to use it in different
shells):
 set i 0; set s $k; set seed 16807; while {$i<=$k/2} {
 set seed [expr {($i + $seed / (1 + $s<<3) + 2**($i % 64) * 3**($seed %
39) % 0x17A311E02F4623 + 1) % $k}]
 set s [expr {$seed % $k}]
 set p [lindex $cmd($i)]; set cmd($i) $cmd($s); set cmd($s) $p; incr i
 }
 }
 # body calling all the procs at once (in specific "random" order,
targeting different mem-blocks):
 if {![info exists body($k)]} {
 set body(k) {}
 set i 0; while {$i<=$k} { append body(k) "$cmd($i) 0 0 0 0 0; "; incr i
}
 timerate $body(k) 100; # warm-up this body
 }
 timerate $body(k) 5000; # measure 5 seconds
}

GREEN - 9.1 without TIPs 627/626 & no 64-bit counters in Command- and
other structs (Tcl_Size <-> int),
RED - 9.1 with TIPs 627/626 & 64-bit counters 

 % TEST 10000
+ 7488.61 ΜS/# 667 # 133.54 #/SEC 4994.904 NET-MS
- 9769.15 ΜS/# 511 # 102.36 #/SEC 4992.038 NET-MS 

 % TEST 1000
+ 362.284 ΜS/# 13800 # 2760.3 #/SEC 4999.517 NET-MS
- 415.089 ΜS/# 12044 # 2409.1 #/SEC 4999.330 NET-MS 

 % TEST 100
+ 29.7158 ΜS/# 168078 # 33652.2 #/SEC 4994.565 NET-MS
- 31.1066 ΜS/# 160574 # 32147.6 #/SEC 4994.904 NET-MS 

Although the last one (yes, it would already begin by 100 procs) is not
so conspicuous anymore, because it seems to match the CPU cache size and
therefore simply has fewer cache-washouts, I think it'd more or less
illustrate only the extra cost of new interim layer (cmdWrapperProc and
co), but may be just some fluctuations or measurement uncertainty
(however looks stable).
Whereas the jump between 1000 and 10000 is obviously non-linear (not
10x), so the CPU cache washouts wreaking havoc here definitely, but MORE
AGGRESSIVE FOR THE RED PLAYER. 

All this is single-threaded, so you would notice much more regression
multi-threaded or under parasitic load, because L3 (and on some
platforms also L2) will be shared between multiple cores and therefore
can cause more cache invalidations.
However the result may surely depend on CPU cache size, etc.

One would probably see almost the same picture comparing it with 8.7
(where Tcl_Size is int), but it is not quite correct test, since 9.x is
slightly different (got a bit more features etc) and for instance its
invocation and TEBC behaviour may differ. But the tendency is
noticeable. 

Sure, every change, even if causes a performance regression, may be
justified, but I don't understand how it could be applied here - even by
big-data researches or data-science work, I'd never ever try to use such
large things as plain tcl-objects in memory, let alone do their
processing there (without indices, DB, special objects or handling).
And my objections are about the whole complex of such 64-bit
"enhancements" and not about particular case of TIP #626, what imho
targets just the consequences of TIP #627 and other similar changes. 

Anyway, the application is and remains 64-bit-capable without the need
to address more than 2 billions elements inside every single internal of
it. Sure it must be able to handle more than 2GB/4GB of memory as whole
process, but not for single list, command or string. It is as already
said very doubtful requirement and neither would affect the usage of
64-bit architecture in some regard, nor can justify the effort to
change, the deprecation of int-usage everywhere or loss of backward
compatibility of the code (pieces of code). 

Hope this helps,
Serg. 

21.03.2025 13:23, Harald Oehlmann wrote: 

> Dear Sergey,
> thank you for the comment.
> I appreciate your valuable opinion and try to get this in.
> 
> We mostly have the issue, that many people on voting time don't know about the consequences.
> 
> You are *the* expert on timing and memory usage.
> Maybe, we may get the discussion to a level of real numbers:
> 
> * what is the impact in time and memory usage?
> 
> I don't think, Jan will react on this post without concrete numbers...
> 
> It is often hard to get Wizard-level opinions from you, Christians, Marc etc. and this is so valuable.
> 
> Thanks for all,
> Harald
 

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

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

Op vr 21 mrt 2025 om 14:16 schreef Jan Nijtmans:
> In the TIP#626 implementation,
> this error-handling is all gone.

Thanks for reminding me:
    <https://core.tcl-lang.org/tcl/info/124360b3fda00f0f>
since TclCommandWordLimitError() isn't used
anywhere any more it is now removed completely.

Then about the cost: Only when extensions create their
own command (which they usually do when they are
initialized), it takes an additional allocation. And when
the function is called, there's a small wrapper-function
involved (which just passes the parameters through).
In my judgement, that's a much smaller cost
than the maintenance cost of using TclCommandWordLimitError()
everywhere a list element count becomes a command
arg count. I'm sure there are cases in Tcl 9.0 where
such a check would be needed, but where it's missing now.

Hope this helps,
      Jan Nijtmans

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

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

Op vr 21 mrt 2025 om 13:24 schreef Harald Oehlmann:
> You are *the* expert on timing and memory usage.
> Maybe, we may get the discussion to a level of real numbers:
>
>     *   what is the impact in time and memory usage?

If a benchmark would help to convince people, please
share benchmark results here. I didn't do that, because
TIP #626 only reduces lines of code. For example,
have a look at those lines in the TclEvalEx() function
(which is a heavily-used function!), and similar lines
in TclNRExecuteByteCode():

    <https://core.tcl-lang.org/tcl/artifact/4e2f21469d278886?ln=5408-5414>
    <https://core.tcl-lang.org/tcl/artifact/250a9712ef70bfb3?ln=2827-2832>

Because everywhere when we put a list ad command, we have
to check for the maximum command-size and produce an
error if the command-size is to large. In the TIP#626 implementation,
this error-handling is all gone.

Hope this helps,
        Jan Nijtmans

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

[Eric B. <eri...@gm...>]

Hi,

My voice doesn't count, but I totally agree with Sergey.

What's the point of creating such a command?
Also just try this, which is less than 2**31:

# Prepare list of parameters
set L {}
for {set i 0} {$i < 2**31-1} {incr i} {
    lappend L a$i
}

I don't write the code next, I had to close the application before it
terminates...
But imagine bytecoding the proc placing parameters in LVT...

Eric

Le ven. 21 mars 2025 à 13:24, Harald Oehlmann <har...@el...>
a écrit :

> Dear Sergey,
> thank you for the comment.
> I appreciate your valuable opinion and try to get this in.
>
> We mostly have the issue, that many people on voting time don't know
> about the consequences.
>
> You are *the* expert on timing and memory usage.
> Maybe, we may get the discussion to a level of real numbers:
>
>     *   what is the impact in time and memory usage?
>
> I don't think, Jan will react on this post without concrete numbers...
>
> It is often hard to get Wizard-level opinions from you, Christians, Marc
> etc. and this is so valuable.
>
> Thanks for all,
> Harald
>
> Am 21.03.2025 um 12:00 schrieb Dipl. Ing. Sergey G. Brester:
> > Unfortunately exactly this is not old stuff. It looks rather like
> > elimination of self-induced issue (introduced by TIP 627).
> > I never understand the necessity to use 64-bit types wherever possible.
> > And when in case of string/list length it may be indeed justified
> > (however one could also provide them with new types like bigstring or
> > biglist), by commands it is not only questionable (who really needs 2
> > billions arguments by the command?), it additionally bothers with extra
> > memory consume (per command), with new layer to hold it backward
> > compatible (and performance cost involved), etc.
> >
> > In my opinion TIP 627 was a mistake (together with TIP 626 and co)...
> > let alone another stuff like, Command::refCount or Command::cmdEpoch...
> > But however I'd not expect the exceeding of 2 billions references, it is
> > indeed imaginable (as for refCount), cmdEpoch may overflow without any
> > issue, but it is also 64-bit now.
> >
> > There is only one case where a command/proc really could get 2 billions
> > arguments - it is an expansion of really large list, but... In such case
> > it'd rather not named arguments but have something like `args`
> > parameter, what is also a list object, so why not just consider it as
> > special case and make some "transparent" expansion possible instead?
> > It'd be much nicer enhancement without to lost backwards compatibility
> > (generation of crutches for extra layer to support both 32-bits and 64-
> > bits arguments), enlarge memory usage etc.
> >
> > The issue with extra memory consumption (by usage of larger types en
> > masse) is also important, because despite the memory is cheap nowadays,
> > but not the CPU cache (and that extra memory definitely causes more
> > cache-washouts, invalidations, etc). The issue is - such en masse types
> > replacement would bother for all the regular cases too, not only there
> > where it is may be needed (I guess not even in 1%, probably we speaking
> > about fractions).
> >
> > If one would think twice, one could consider that all that is not just
> > something like "640K ought to be enough for anybody", but reasonable and
> > legitimate arguments against 64-bit types everywhere at all costs.
> > Pity nobody seems to care about and even votes of 3 people are enough
> > for such grave mods.
> >
> > Regards,
> > Serg.
> >
> > 21.03.2025 10:16, Harald Oehlmann wrote:
> >
> >> Jan,
> >> I think, this is a ggod idea.
> >> For me, cutting old stuff is always good.
> >> It hurts once, but does not bite 10 times later.
> >>
> >> I also see the decision to not release TCL/Tk 8.7 was a good decision.
> >> Now, we really migrate to 9.0 and have a better and cleaner environment.
> >> Sorry for anybody struggelling, but 9.0 is really better, specially for
> Tk.
> >>
> >> Take care,
> >> Harald
> >>
> >>
> >> Am 20.03.2025 um 16:50 schrieb Jan Nijtmans:
> >>> This is a CFV warning for TIP #626. for Tcl 9.1+: Command arguments >
> >>> 2^31 elements <https://core.tcl-lang.org/tips/doc/trunk/tip/626.md
> >>> <https://core.tcl-lang.org/tips/doc/trunk/tip/626.md>> If you think
> >>> this is a bad idea, speak up now. If not, I'll start the vote in a
> >>> few days. Regards, Jan Nijtmans
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

Dear Sergey,
thank you for the comment.
I appreciate your valuable opinion and try to get this in.

We mostly have the issue, that many people on voting time don't know 
about the consequences.

You are *the* expert on timing and memory usage.
Maybe, we may get the discussion to a level of real numbers:

    *   what is the impact in time and memory usage?

I don't think, Jan will react on this post without concrete numbers...

It is often hard to get Wizard-level opinions from you, Christians, Marc 
etc. and this is so valuable.

Thanks for all,
Harald

Am 21.03.2025 um 12:00 schrieb Dipl. Ing. Sergey G. Brester:
> Unfortunately exactly this is not old stuff. It looks rather like 
> elimination of self-induced issue (introduced by TIP 627).
> I never understand the necessity to use 64-bit types wherever possible. 
> And when in case of string/list length it may be indeed justified 
> (however one could also provide them with new types like bigstring or 
> biglist), by commands it is not only questionable (who really needs 2 
> billions arguments by the command?), it additionally bothers with extra 
> memory consume (per command), with new layer to hold it backward 
> compatible (and performance cost involved), etc.
> 
> In my opinion TIP 627 was a mistake (together with TIP 626 and co)... 
> let alone another stuff like, Command::refCount or Command::cmdEpoch... 
> But however I'd not expect the exceeding of 2 billions references, it is 
> indeed imaginable (as for refCount), cmdEpoch may overflow without any 
> issue, but it is also 64-bit now.
> 
> There is only one case where a command/proc really could get 2 billions 
> arguments - it is an expansion of really large list, but... In such case 
> it'd rather not named arguments but have something like `args` 
> parameter, what is also a list object, so why not just consider it as 
> special case and make some "transparent" expansion possible instead? 
> It'd be much nicer enhancement without to lost backwards compatibility 
> (generation of crutches for extra layer to support both 32-bits and 64- 
> bits arguments), enlarge memory usage etc.
> 
> The issue with extra memory consumption (by usage of larger types en 
> masse) is also important, because despite the memory is cheap nowadays, 
> but not the CPU cache (and that extra memory definitely causes more 
> cache-washouts, invalidations, etc). The issue is - such en masse types 
> replacement would bother for all the regular cases too, not only there 
> where it is may be needed (I guess not even in 1%, probably we speaking 
> about fractions).
> 
> If one would think twice, one could consider that all that is not just 
> something like "640K ought to be enough for anybody", but reasonable and 
> legitimate arguments against 64-bit types everywhere at all costs. 
> Pity nobody seems to care about and even votes of 3 people are enough 
> for such grave mods.
> 
> Regards,
> Serg.
> 
> 21.03.2025 10:16, Harald Oehlmann wrote:
> 
>> Jan,
>> I think, this is a ggod idea.
>> For me, cutting old stuff is always good.
>> It hurts once, but does not bite 10 times later.
>>
>> I also see the decision to not release TCL/Tk 8.7 was a good decision.
>> Now, we really migrate to 9.0 and have a better and cleaner environment.
>> Sorry for anybody struggelling, but 9.0 is really better, specially for Tk.
>>
>> Take care,
>> Harald
>>
>>
>> Am 20.03.2025 um 16:50 schrieb Jan Nijtmans:
>>> This is a CFV warning for TIP #626. for Tcl 9.1+: Command arguments > 
>>> 2^31 elements <https://core.tcl-lang.org/tips/doc/trunk/tip/626.md 
>>> <https://core.tcl-lang.org/tips/doc/trunk/tip/626.md>> If you think 
>>> this is a bad idea, speak up now. If not, I'll start the vote in a 
>>> few days. Regards, Jan Nijtmans

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

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

 

Unfortunately exactly this is not old stuff. It looks rather like
elimination of self-induced issue (introduced by TIP 627).
I never understand the necessity to use 64-bit types wherever possible.
And when in case of string/list length it may be indeed justified
(however one could also provide them with new types like bigstring or
biglist), by commands it is not only questionable (who really needs 2
billions arguments by the command?), it additionally bothers with extra
memory consume (per command), with new layer to hold it backward
compatible (and performance cost involved), etc.

In my opinion TIP 627 was a mistake (together with TIP 626 and co)...
let alone another stuff like, Command::refCount or Command::cmdEpoch...
But however I'd not expect the exceeding of 2 billions references, it is
indeed imaginable (as for refCount), cmdEpoch may overflow without any
issue, but it is also 64-bit now.

There is only one case where a command/proc really could get 2 billions
arguments - it is an expansion of really large list, but... In such case
it'd rather not named arguments but have something like `args`
parameter, what is also a list object, so why not just consider it as
special case and make some "transparent" expansion possible instead?
It'd be much nicer enhancement without to lost backwards compatibility
(generation of crutches for extra layer to support both 32-bits and
64-bits arguments), enlarge memory usage etc.

The issue with extra memory consumption (by usage of larger types en
masse) is also important, because despite the memory is cheap nowadays,
but not the CPU cache (and that extra memory definitely causes more
cache-washouts, invalidations, etc). The issue is - such en masse types
replacement would bother for all the regular cases too, not only there
where it is may be needed (I guess not even in 1%, probably we speaking
about fractions). 

If one would think twice, one could consider that all that is not just
something like "640K ought to be enough for anybody", but reasonable and
legitimate arguments against 64-bit types everywhere at all costs. Pity
nobody seems to care about and even votes of 3 people are enough for
such grave mods. 

Regards,
Serg.

21.03.2025 10:16, Harald Oehlmann wrote: 

> Jan,
> I think, this is a ggod idea.
> For me, cutting old stuff is always good.
> It hurts once, but does not bite 10 times later.
> 
> I also see the decision to not release TCL/Tk 8.7 was a good decision.
> Now, we really migrate to 9.0 and have a better and cleaner environment.
> Sorry for anybody struggelling, but 9.0 is really better, specially for Tk.
> 
> Take care,
> Harald
> 
> Am 20.03.2025 um 16:50 schrieb Jan Nijtmans:
> 
>> This is a CFV warning for TIP #626. for Tcl 9.1+: Command arguments > 2^31 elements <https://core.tcl-lang.org/tips/doc/trunk/tip/626.md [1]> If you think this is a bad idea, speak up now. If not, I'll start the vote in a few days. Regards, Jan Nijtmans
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core [2]
 

Links:
------
[1] https://core.tcl-lang.org/tips/doc/trunk/tip/626.md
[2] https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] TCL/Tk biweekly telco on 24th of Mars, 2025 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

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

Dear Tcl/Tk team,
please allow me to invite anybody to the telco:
Where: https://meet.jit.si/TclMonthlyMeetup
When: 2025-03-24 12:00 UTC

Possible discussion points:

1) Possible Incompatible changes for 9.1 in Tk
- "tk grid" https://core.tcl-lang.org/tk/info/7c51624a96ab2092
- "tk_getOpenFile -xpstyle 1" 
https://core.tcl-lang.org/tk/tktview/441c526c0d

2) Stop Tcl/Tk 8.7 ?

3) coroutine traces symetry (Sergey calls for comments): 
https://core.tcl-lang.org/tcl/info/5bd41844e62aceb2

4) bytecode compiler optimization by Donal Fellows

5) TIP 700: Documentation

6) Next meeting time: Europe will move to daytime saving time -> keep 
12:00 UTC ? Date will be 7th of April 2025

7) Conference news

8) Any other business

Thank you all,
Harald

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

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

Jan,
I think, this is a ggod idea.
For me, cutting old stuff is always good.
It hurts once, but does not bite 10 times later.

I also see the decision to not release TCL/Tk 8.7 was a good decision.
Now, we really migrate to 9.0 and have a better and cleaner environment.
Sorry for anybody struggelling, but 9.0 is really better, specially for Tk.

Take care,
Harald


Am 20.03.2025 um 16:50 schrieb Jan Nijtmans:
> This is a CFV warning for TIP #626. for Tcl 9.1+:
>      Command arguments > 2^31 elements
>      <https://core.tcl-lang.org/tips/doc/trunk/tip/626.md>
> 
> If you think this is a bad idea, speak up now. If not,
> I'll start the vote in a few days.
> 
> Regards,
>           Jan Nijtmans

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

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

This is a CFV warning for TIP #626. for Tcl 9.1+:
    Command arguments > 2^31 elements
    <https://core.tcl-lang.org/tips/doc/trunk/tip/626.md>

If you think this is a bad idea, speak up now. If not,
I'll start the vote in a few days.

Regards,
         Jan Nijtmans

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

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

I did look at PEP 11 before writing the TIP, the hope being one could just do a s/Python/Tcl/g and be done with it 😊

 

However, I did not think it suitable given the differences between the size of the Python community versus Tcl’s. While the PEP defines three tiers of support, I’m afraid there are one or two orders of magnitude fewer core contributors to Tcl compared to Python. And nowhere near as active. There is no point in defining three Tiers when we do not even have the manpower and build infrastructure to support their Tier 1 definition.

 

A lesser point limited to Windows, I felt their tying of Py support to Microsoft EOL and specific Visual Studio versions for each release was complicated and unnecessary.

 

/Ashok

 

 

 

From: Francois Vogel <fvo...@fr...> 
Sent: Saturday, March 15, 2025 8:30 PM
To: apn...@ya...; tcl...@li...
Subject: Re: [TCLCORE] [External] Re: TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

 

Le 15/03/2025 à 05:20, apnmbx-public--- via Tcl-Core a écrit :

1.      In hindsight, my use of the terms Supported, Obsolete and Unsupported may be misleading, particularly the last. It does not mean Tcl will not build or that we will ignore bug reports for unsupported platforms. Suggestions for better names and definitions most welcome.

Some food for thought could be what Python defines:

https://peps.python.org/pep-0011/

In particular, instead of having supported/unsupported/obsolete platforms, Python defines support tiers.

Regards,

Francois

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

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

That’s excellent news Marc.

-- Steve
On 17 Mar 2025 at 11:56 PM +0800, Marc Culler <cul...@gm...>, wrote:
> Over the weekend I built Tk 9.1 on macOS 10.13, 10.14, 10.15, 11, 12, 13, 14 and 15 (where all but the last were VMs) and ran the test suite on all of those systems.  The builds were clean and all tests passed on all of those systems.  So I am pretty comfortable with the claim that Tk 9.1 supports macOS 10.13 and newer.  (Also, closing the "About Tcl & Tk" window in Wish now returns focus to a Tk window on all of those systems!)
>
> If you haven't experienced this sort of thing it may not seem amazing that all tests pass on that many Apple systems.  But it is amazing.  That *never* happened with any release of Tk 8.  Every new macOS release required an effort to get the tests to pass, and when that was done some (often many) tests would fail on older systems.  I think this is a testament to both the extended effort by François and others to clean up the test suite and to Christopher Chavez's suggestion for how to redesign the macOS port of Tk to enable Tk to draw into the backing CALayer of a TKContentView at any time.  That made the macOS port work more like the other platforms, thereby making it more robust.
>
> - Marc
>
> PS There are still a few tests which fail sporadically, especially on the one and only system which we truly support - the one which no human will ever use - namely the github CI runner.
>
> On Mon, Mar 17, 2025 at 7:44 AM da Silva, Peter J <pet...@fl...> wrote:
> > That sounds fantastic, I have a Mac Pro still running High Sierra to support older software.
> >
> > From: Steve Landers <st...@di...>
> > Date: Friday, March 14, 2025 at 19:40
> > To: Tcl Core List <tcl...@li...>, nicolas bats <sl1...@gm...>, da Silva, Peter J (USA) <pet...@fl...>, Dipl. Ing. Sergey G. Brester <se...@us...>, Marc Culler <cul...@gm...>
> > Subject: Re: [TCLCORE] [External] Re: TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1
> > FWIW I agree with Marc.
> >
> > Mac hardware lasts a long time in my experience and I have old equipment dedicated to specific tasks that is still running happily (not internet facing so I’m not concerned about the security).  Being able to run Tcl 9 its a bonus if it doesn’t cost us anything.
> >
> > -- Steve
> > On 15 Mar 2025 at 5:50 AM +0800, Marc Culler <cul...@gm...>, wrote:
> >
> > > I would advocate supporting macOS 10.13 and newer.  The reason is that there is no issue right now with building or running Tk9 on
> > > macOS 10.13 and newer.  It takes no extra work for us to support those versions.  The current tiip of main even passes all tests on 10.13.  And we have recently had several very useful tickets opened by Eric Brunel based on testing on 10.13 but applicable generally.
> > >
> > > I think that as long as it costs us nothing and provides even a tiny marginal benefit, then we should do it.
> > >
> > > - Marc
> > >
> > > On Thu, Mar 13, 2025 at 9:00 AM nicolas bats <sl1...@gm...> wrote:
> > > > Hi,
> > > > I saw a lot of Intel64 that cannot go after macOS 10.15.7 (without OpenCore)
> > > >
> > > > ++
> > > >
> > > > Le jeu. 13 mars 2025 à 14:53, da Silva, Peter J <pet...@fl...> a écrit :
> > > > > With or without OpenCore? If you’re talking about 32-bit machines, I suspect excluding them was intended:
> > > > >
> > > > > > “It makes sense to drop support for all macOS versions before 2020. This would limit support to Intel-64 and ARM64”
> > > > >
> > > > > From: nicolas bats <sl1...@gm...>
> > > > > Date: Thursday, March 13, 2025 at 08:44
> > > > > To: Alexander Schöpe <a.s...@gm...>
> > > > > Cc: Dipl. Ing. Sergey G. Brester via Tcl-Core <tcl...@li...>
> > > > > Subject: [External] Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1
> > > > > Hi,
> > > > > regrading macOS I would strongly be in favor to support from
> > > > > macOS 10.15     Catalina        Intel 64                October 7, 2019
> > > > >
> > > > > As several old machines cannot go to Big Sur
> > > > _______________________________________________
> > > > 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
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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

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

Over the weekend I built Tk 9.1 on macOS 10.13, 10.14, 10.15, 11, 12, 13,
14 and 15 (where all but the last were VMs) and ran the test suite on all
of those systems.  The builds were clean and all tests passed on all of
those systems.  So I am pretty comfortable with the claim that Tk 9.1
supports macOS 10.13 and newer.  (Also, closing the "About Tcl & Tk" window
in Wish now returns focus to a Tk window on all of those systems!)

If you haven't experienced this sort of thing it may not seem amazing that
all tests pass on that many Apple systems.  But it is amazing.  That
*never* happened with any release of Tk 8.  Every new macOS release
required an effort to get the tests to pass, and when that was done some
(often many) tests would fail on older systems.  I think this is a
testament to both the extended effort by François and others to clean up
the test suite and to Christopher Chavez's suggestion for how to redesign
the macOS port of Tk to enable Tk to draw into the backing CALayer of a
TKContentView at any time.  That made the macOS port work more like the
other platforms, thereby making it more robust.

- Marc

PS There are still a few tests which fail sporadically, especially on the
one and only system which we truly support - the one which no human will
ever use - namely the github CI runner.

On Mon, Mar 17, 2025 at 7:44 AM da Silva, Peter J <
pet...@fl...> wrote:

> That sounds fantastic, I have a Mac Pro still running High Sierra to
> support older software.
>
>
>
> *From: *Steve Landers <st...@di...>
> *Date: *Friday, March 14, 2025 at 19:40
> *To: *Tcl Core List <tcl...@li...>, nicolas bats <
> sl1...@gm...>, da Silva, Peter J (USA) <
> pet...@fl...>, Dipl. Ing. Sergey G. Brester <
> se...@us...>, Marc Culler <cul...@gm...>
> *Subject: *Re: [TCLCORE] [External] Re: TIP 715 - Supported platforms and
> build environments for Tcl/Tk 9.1
>
> FWIW I agree with Marc.
>
> Mac hardware lasts a long time in my experience and I have old equipment
> dedicated to specific tasks that is still running happily (not internet
> facing so I’m not concerned about the security).  Being able to run Tcl 9
> its a bonus if it doesn’t cost us anything.
>
>
>
> -- Steve
>
> On 15 Mar 2025 at 5:50 AM +0800, Marc Culler <cul...@gm...>, wrote:
>
> I would advocate supporting macOS 10.13 and newer.  The reason is that
> there is no issue right now with building or running Tk9 on
>
> macOS 10.13 and newer.  It takes no extra work for us to support those
> versions.  The current tiip of main even passes all tests on 10.13.  And we
> have recently had several very useful tickets opened by Eric Brunel based
> on testing on 10.13 but applicable generally.
>
>
>
> I think that as long as it costs us nothing and provides even a tiny
> marginal benefit, then we should do it.
>
>
>
> - Marc
>
>
>
> On Thu, Mar 13, 2025 at 9:00 AM nicolas bats <sl1...@gm...> wrote:
>
> Hi,
>
> I saw a lot of Intel64 that cannot go after macOS 10.15.7 (without
> OpenCore)
>
>
>
> ++
>
>
>
> Le jeu. 13 mars 2025 à 14:53, da Silva, Peter J <
> pet...@fl...> a écrit :
>
> With or without OpenCore? If you’re talking about 32-bit machines, I
> suspect excluding them was intended:
>
> > “It makes sense to drop support for all macOS versions before 2020. This
> would limit support to Intel-64 and ARM64”
>
>
>
> *From:* nicolas bats <sl1...@gm...>
> *Date:* Thursday, March 13, 2025 at 08:44
> *To:* Alexander Schöpe <a.s...@gm...>
> *Cc:* Dipl. Ing. Sergey G. Brester via Tcl-Core <
> tcl...@li...>
> *Subject:* [External] Re: [TCLCORE] TIP 715 - Supported platforms and
> build environments for Tcl/Tk 9.1
>
> Hi,
>
> regrading macOS I would strongly be in favor to support from
>
> macOS 10.15     Catalina        Intel 64                October 7, 2019
>
>
>
> As several old machines cannot go to Big Sur
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> <https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/tcl-core__;!!MvWE!BrnSRwJF2xBjZsXtHw77LXOvK8C0_w6U4WA8PveSdDWjO7DxEX1VZ5AW-6OZvEZe1HZio1RRp8Gc-fPhcIdx4Wlc3UQ$>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> <https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/tcl-core__;!!MvWE!BrnSRwJF2xBjZsXtHw77LXOvK8C0_w6U4WA8PveSdDWjO7DxEX1VZ5AW-6OZvEZe1HZio1RRp8Gc-fPhcIdx4Wlc3UQ$>
>
>

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

[da S. P. J <pet...@fl...>]

That sounds fantastic, I have a Mac Pro still running High Sierra to support older software.

From: Steve Landers <st...@di...>
Date: Friday, March 14, 2025 at 19:40
To: Tcl Core List <tcl...@li...>, nicolas bats <sl1...@gm...>, da Silva, Peter J (USA) <pet...@fl...>, Dipl. Ing. Sergey G. Brester <se...@us...>, Marc Culler <cul...@gm...>
Subject: Re: [TCLCORE] [External] Re: TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1
FWIW I agree with Marc.

Mac hardware lasts a long time in my experience and I have old equipment dedicated to specific tasks that is still running happily (not internet facing so I’m not concerned about the security).  Being able to run Tcl 9 its a bonus if it doesn’t cost us anything.

-- Steve
On 15 Mar 2025 at 5:50 AM +0800, Marc Culler <cul...@gm...>, wrote:

I would advocate supporting macOS 10.13 and newer.  The reason is that there is no issue right now with building or running Tk9 on
macOS 10.13 and newer.  It takes no extra work for us to support those versions.  The current tiip of main even passes all tests on 10.13.  And we have recently had several very useful tickets opened by Eric Brunel based on testing on 10.13 but applicable generally.

I think that as long as it costs us nothing and provides even a tiny marginal benefit, then we should do it.

- Marc

On Thu, Mar 13, 2025 at 9:00 AM nicolas bats <sl1...@gm...<mailto:sl1...@gm...>> wrote:
Hi,
I saw a lot of Intel64 that cannot go after macOS 10.15.7 (without OpenCore)

++

Le jeu. 13 mars 2025 à 14:53, da Silva, Peter J <pet...@fl...<mailto:pet...@fl...>> a écrit :
With or without OpenCore? If you’re talking about 32-bit machines, I suspect excluding them was intended:

> “It makes sense to drop support for all macOS versions before 2020. This would limit support to Intel-64 and ARM64”

From: nicolas bats <sl1...@gm...<mailto:sl1...@gm...>>
Date: Thursday, March 13, 2025 at 08:44
To: Alexander Schöpe <a.s...@gm...<mailto:a.s...@gm...>>
Cc: Dipl. Ing. Sergey G. Brester via Tcl-Core <tcl...@li...<mailto:tcl...@li...>>
Subject: [External] Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1
Hi,
regrading macOS I would strongly be in favor to support from
macOS 10.15     Catalina        Intel 64                October 7, 2019

As several old machines cannot go to Big Sur
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/tcl-core__;!!MvWE!BrnSRwJF2xBjZsXtHw77LXOvK8C0_w6U4WA8PveSdDWjO7DxEX1VZ5AW-6OZvEZe1HZio1RRp8Gc-fPhcIdx4Wlc3UQ$>
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/tcl-core__;!!MvWE!BrnSRwJF2xBjZsXtHw77LXOvK8C0_w6U4WA8PveSdDWjO7DxEX1VZ5AW-6OZvEZe1HZio1RRp8Gc-fPhcIdx4Wlc3UQ$>

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

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

Le 15/03/2025 à 05:20, apnmbx-public--- via Tcl-Core a écrit :
>
>   * In hindsight, my use of the terms Supported, Obsolete and
>     Unsupported may be misleading, particularly the last. It does not
>     mean Tcl will not build or that we will ignore bug reports for
>     unsupported platforms. Suggestions for better names and
>     definitions most welcome.
>
Some food for thought could be what Python defines:

https://peps.python.org/pep-0011/

In particular, instead of having supported/unsupported/obsolete 
platforms, Python defines support tiers.

Regards,

Francois

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

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

Here is another data point regarding macOS.  Many if not most users of Tk
use it via the Python tkinter module.  And the python.org distribution for
macOS included an embedded copy of the Tcl and Tk libraries. The oldest
version of Python which is not at end-of-life is 3.9.  That version of
Python is advertised as supporting 10.9 and newer.  (I think that means, at
minimum, that it is compiled with the flag -mmacosx-version-min=10.9.)  The
Tcl and Tk versions are 8.6.x, where I am not sure of the value of x but I
would guess 12.

- Marc

On Sat, Mar 15, 2025 at 9:05 AM Marc Culler <cul...@gm...> wrote:

> First, some concrete data about what I do.  I have the free version of
> VMWare running on an intel mac mini.  I have images for macsOS 10.12 and
> later.  However, I cannot get the 10.12 version to boot.   So I could only
> test on 10.13 and newer.  And I did run the tests for 9.1 on the macOS
> 10.13 VM recently.  I have not run the tests on 10.14 and up recently,
> however.  I usually try to do that when there is a release.  (This is yet
> another reason for not having releases too often.)
>
> Note that my process depends on having an Intel mac available.  Apple is
> not producing Intel machines anymore.  So my ability to test on those
> versions of macOS which were not released for Arm will probably end when my
> Intel mac mini dies.
>
> Second, there are many lined of code in the macosx directory which test
> for versions of the OS.  I think that Ashok is saying that those can and
> should be left in place even after support is dropped for the versions.
>
> - Marc
>
>
>
> On Sat, Mar 15, 2025 at 3:37 AM Alexander Schöpe via Tcl-Core <
> tcl...@li...> wrote:
>
>> I will put my conclusion first, following the TL;DR approach.
>>
>> I believe that the definitions Ashok described may need to be clarified
>> to make it clear that something may still run on outdated systems but is no
>> longer actively supported.
>>
>> I still have to support several old industrial systems where
>> manufacturers no longer provide updates, and where no new C compilers are
>> available. These systems still run on Tcl/Tk 8.6 and will remain on this
>> version. The effort required to port even 8.6.x to these old systems is
>> extremely high. However, anyone is free to attempt it.
>>
>> On the other hand, Tcl/Tk 9.x is code-breaking anyway, and sometimes you
>> have to let go of outdated things to create something new. Then you can
>> say, “Yes, macOS High Sierra works and requires no additional effort.” This
>> would mean “runs” but “is no longer maintained.”
>>
>> The discussion highlights that the current terms “Supported,” “Obsolete,”
>> and “Unsupported” are not clearly defined and can lead to misunderstandings.
>> It is particularly important to clarify that software or platforms may
>> still be operational even if they are no longer actively supported or
>> tested.
>>
>> The data on macOS versions and SSL/TLS standards illustrate that outdated
>> systems may still exist but, without active maintenance, will become
>> increasingly irrelevant over time.
>> Therefore, it makes sense to focus Tcl/Tk 9.x support on platforms that
>> have vendor maintenance and a relevant market share.
>>
>> A more precise definition of these terms would help manage future support
>> more effectively and avoid confusion.
>>
>> > Am 15.03.2025 um 05:20 schrieb apnmbx-public--- via Tcl-Core <
>> tcl...@li...>:
>> >
>> > Thanks for the comments so far. I am awaiting for further feedback
>> before updating the TIP. In the meanwhile, some thoughts on the responses
>> received so far.
>> >
>> >     • There have been some comments about autoconf etc. not being
>> runtime requirements. Note that the TIP intends to address *both* runtime
>> and build requirements, including compilers (C11 support), tools (min
>> autoconf version, gnu make dependencies etc.) etc. If anyone thinks the
>> build environment should be moved to a separate TIP, please do so, no
>> objection from me.
>> >
>> >     • With regards to Marc and Steve’s comments about platforms
>> (paraphrasing) “not needing extra work”. As the definition currently stands
>> Supported means it has to be specifically tested on that platform for every
>> release. So at a minimum there is at least that effort required. In
>> addition, when new features are added, they must be implemented for that
>> platform as well. That is the reason Windows 7 is explicitly marked as
>> Obsolete though no additional work is required as of today. It is not
>> tested, and if new features, say pty console support, are added,
>> feasibility on Windows 7 will not be taken into consideration.
>>
>> Let's take a closer look at the manufacturer's status:
>>
>> macOS High Sierra 10.13.6, released September 25, 2017, last update July
>> 09, 2018, Intel 64, not maintained
>> macOS Mojave 10.14.6, released September 24, 2018, last update September
>> 26, 2019, Intel 64, not maintained
>> macOS Catalina 10.15.7, released October 7, 2019, last update September
>> 23, 2020, Intel 64, not maintained
>> macOS Big Sur 11.7.10, released November 12, 2020, last update September
>> 11, 2023, Intel and ARM 64, not maintained
>> macOS Monterey 12.7.6, released October 25, 2021, last update July 29,
>> 2024, Intel and ARM 64, not maintained
>> macOS Ventura 13.7.4, released October 24, 2022, last update February 10,
>> 2025, Intel and ARM 64, still maintained
>> macOS Sonoma 14.7.4, released September 26, 2023, last update February
>> 10, 2025, Intel and ARM 64, still maintained
>> macOS Sequoia 15.3.2, released September 16, 2024, last update March 11,
>> 2025, Intel and ARM 64, maintained
>>
>> Apart from that, hardware from 2008 onwards can be provided with macOS
>> from macOS Monterey 12+ to macOS Sequoia using the OpenCorePatcher. The
>> OpenCorePatcher no longer supports macOS prior to macOS Monterey 12.
>>
>> So everyone can get a picture of it.
>>
>> >     • In hindsight, my use of the terms Supported, Obsolete and
>> Unsupported may be misleading, particularly the last. It does not mean Tcl
>> will not build or that we will ignore bug reports for unsupported
>> platforms. Suggestions for better names and definitions most welcome.
>>
>> What does this look like with SSL/TLS
>>
>> SSL 2.0, released 1995, deprecated in 2011, not maintained
>> SSL 3.0, released 1996, deprecated in 2015, not maintained
>> TLS 1.0, released 1999, deprecated in 2021, not maintained
>> TLS 1.1, released 2006, deprecated in 2021, not maintained
>> TLS 1.2, released 2008, in use since 2008, still maintained
>> TLS 1.3, released 2018, in use since 2018, maintained
>>
>> >     • Someone needs to take the lead on macOS and Linux/Unix. But as a
>> general comment, I do not think we should be concerned about supporting 9.1
>> on platforms that are old *and* have less than 5% market share (my criteria
>> for Windows). So for example, for macOS
>> https://telemetrydeck.com/survey/apple/macOS/versions/
>> >  /Ashok
>>
>> macOS, Linux/Unix must be considered separately. Although there is the
>> overlap that X11 R6 is also available on macOS, macOS has its own GUI.
>> So that means there is macOS on the one hand and Linux and Unix on the
>> other, which I think can be summarized.
>> I looked at the statistics, if you can trust them and compare them with
>> the supported versions mentioned above, the old stuff is hardly used
>> anymore.
>>
>>
>>
>>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>

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

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

First, some concrete data about what I do.  I have the free version of
VMWare running on an intel mac mini.  I have images for macsOS 10.12 and
later.  However, I cannot get the 10.12 version to boot.   So I could only
test on 10.13 and newer.  And I did run the tests for 9.1 on the macOS
10.13 VM recently.  I have not run the tests on 10.14 and up recently,
however.  I usually try to do that when there is a release.  (This is yet
another reason for not having releases too often.)

Note that my process depends on having an Intel mac available.  Apple is
not producing Intel machines anymore.  So my ability to test on those
versions of macOS which were not released for Arm will probably end when my
Intel mac mini dies.

Second, there are many lined of code in the macosx directory which test for
versions of the OS.  I think that Ashok is saying that those can and should
be left in place even after support is dropped for the versions.

- Marc



On Sat, Mar 15, 2025 at 3:37 AM Alexander Schöpe via Tcl-Core <
tcl...@li...> wrote:

> I will put my conclusion first, following the TL;DR approach.
>
> I believe that the definitions Ashok described may need to be clarified to
> make it clear that something may still run on outdated systems but is no
> longer actively supported.
>
> I still have to support several old industrial systems where manufacturers
> no longer provide updates, and where no new C compilers are available.
> These systems still run on Tcl/Tk 8.6 and will remain on this version. The
> effort required to port even 8.6.x to these old systems is extremely high.
> However, anyone is free to attempt it.
>
> On the other hand, Tcl/Tk 9.x is code-breaking anyway, and sometimes you
> have to let go of outdated things to create something new. Then you can
> say, “Yes, macOS High Sierra works and requires no additional effort.” This
> would mean “runs” but “is no longer maintained.”
>
> The discussion highlights that the current terms “Supported,” “Obsolete,”
> and “Unsupported” are not clearly defined and can lead to misunderstandings.
> It is particularly important to clarify that software or platforms may
> still be operational even if they are no longer actively supported or
> tested.
>
> The data on macOS versions and SSL/TLS standards illustrate that outdated
> systems may still exist but, without active maintenance, will become
> increasingly irrelevant over time.
> Therefore, it makes sense to focus Tcl/Tk 9.x support on platforms that
> have vendor maintenance and a relevant market share.
>
> A more precise definition of these terms would help manage future support
> more effectively and avoid confusion.
>
> > Am 15.03.2025 um 05:20 schrieb apnmbx-public--- via Tcl-Core <
> tcl...@li...>:
> >
> > Thanks for the comments so far. I am awaiting for further feedback
> before updating the TIP. In the meanwhile, some thoughts on the responses
> received so far.
> >
> >     • There have been some comments about autoconf etc. not being
> runtime requirements. Note that the TIP intends to address *both* runtime
> and build requirements, including compilers (C11 support), tools (min
> autoconf version, gnu make dependencies etc.) etc. If anyone thinks the
> build environment should be moved to a separate TIP, please do so, no
> objection from me.
> >
> >     • With regards to Marc and Steve’s comments about platforms
> (paraphrasing) “not needing extra work”. As the definition currently stands
> Supported means it has to be specifically tested on that platform for every
> release. So at a minimum there is at least that effort required. In
> addition, when new features are added, they must be implemented for that
> platform as well. That is the reason Windows 7 is explicitly marked as
> Obsolete though no additional work is required as of today. It is not
> tested, and if new features, say pty console support, are added,
> feasibility on Windows 7 will not be taken into consideration.
>
> Let's take a closer look at the manufacturer's status:
>
> macOS High Sierra 10.13.6, released September 25, 2017, last update July
> 09, 2018, Intel 64, not maintained
> macOS Mojave 10.14.6, released September 24, 2018, last update September
> 26, 2019, Intel 64, not maintained
> macOS Catalina 10.15.7, released October 7, 2019, last update September
> 23, 2020, Intel 64, not maintained
> macOS Big Sur 11.7.10, released November 12, 2020, last update September
> 11, 2023, Intel and ARM 64, not maintained
> macOS Monterey 12.7.6, released October 25, 2021, last update July 29,
> 2024, Intel and ARM 64, not maintained
> macOS Ventura 13.7.4, released October 24, 2022, last update February 10,
> 2025, Intel and ARM 64, still maintained
> macOS Sonoma 14.7.4, released September 26, 2023, last update February 10,
> 2025, Intel and ARM 64, still maintained
> macOS Sequoia 15.3.2, released September 16, 2024, last update March 11,
> 2025, Intel and ARM 64, maintained
>
> Apart from that, hardware from 2008 onwards can be provided with macOS
> from macOS Monterey 12+ to macOS Sequoia using the OpenCorePatcher. The
> OpenCorePatcher no longer supports macOS prior to macOS Monterey 12.
>
> So everyone can get a picture of it.
>
> >     • In hindsight, my use of the terms Supported, Obsolete and
> Unsupported may be misleading, particularly the last. It does not mean Tcl
> will not build or that we will ignore bug reports for unsupported
> platforms. Suggestions for better names and definitions most welcome.
>
> What does this look like with SSL/TLS
>
> SSL 2.0, released 1995, deprecated in 2011, not maintained
> SSL 3.0, released 1996, deprecated in 2015, not maintained
> TLS 1.0, released 1999, deprecated in 2021, not maintained
> TLS 1.1, released 2006, deprecated in 2021, not maintained
> TLS 1.2, released 2008, in use since 2008, still maintained
> TLS 1.3, released 2018, in use since 2018, maintained
>
> >     • Someone needs to take the lead on macOS and Linux/Unix. But as a
> general comment, I do not think we should be concerned about supporting 9.1
> on platforms that are old *and* have less than 5% market share (my criteria
> for Windows). So for example, for macOS
> https://telemetrydeck.com/survey/apple/macOS/versions/
> >  /Ashok
>
> macOS, Linux/Unix must be considered separately. Although there is the
> overlap that X11 R6 is also available on macOS, macOS has its own GUI.
> So that means there is macOS on the one hand and Linux and Unix on the
> other, which I think can be summarized.
> I looked at the statistics, if you can trust them and compare them with
> the supported versions mentioned above, the old stuff is hardly used
> anymore.
>
>
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

I will put my conclusion first, following the TL;DR approach.

I believe that the definitions Ashok described may need to be clarified to make it clear that something may still run on outdated systems but is no longer actively supported.

I still have to support several old industrial systems where manufacturers no longer provide updates, and where no new C compilers are available. These systems still run on Tcl/Tk 8.6 and will remain on this version. The effort required to port even 8.6.x to these old systems is extremely high. However, anyone is free to attempt it.

On the other hand, Tcl/Tk 9.x is code-breaking anyway, and sometimes you have to let go of outdated things to create something new. Then you can say, “Yes, macOS High Sierra works and requires no additional effort.” This would mean “runs” but “is no longer maintained.”

The discussion highlights that the current terms “Supported,” “Obsolete,” and “Unsupported” are not clearly defined and can lead to misunderstandings.
It is particularly important to clarify that software or platforms may still be operational even if they are no longer actively supported or tested.

The data on macOS versions and SSL/TLS standards illustrate that outdated systems may still exist but, without active maintenance, will become increasingly irrelevant over time.
Therefore, it makes sense to focus Tcl/Tk 9.x support on platforms that have vendor maintenance and a relevant market share.

A more precise definition of these terms would help manage future support more effectively and avoid confusion.

> Am 15.03.2025 um 05:20 schrieb apnmbx-public--- via Tcl-Core <tcl...@li...>:
> 
> Thanks for the comments so far. I am awaiting for further feedback before updating the TIP. In the meanwhile, some thoughts on the responses received so far.
>  
>     • There have been some comments about autoconf etc. not being runtime requirements. Note that the TIP intends to address *both* runtime and build requirements, including compilers (C11 support), tools (min autoconf version, gnu make dependencies etc.) etc. If anyone thinks the build environment should be moved to a separate TIP, please do so, no objection from me.
>  
>     • With regards to Marc and Steve’s comments about platforms (paraphrasing) “not needing extra work”. As the definition currently stands Supported means it has to be specifically tested on that platform for every release. So at a minimum there is at least that effort required. In addition, when new features are added, they must be implemented for that platform as well. That is the reason Windows 7 is explicitly marked as Obsolete though no additional work is required as of today. It is not tested, and if new features, say pty console support, are added, feasibility on Windows 7 will not be taken into consideration.

Let's take a closer look at the manufacturer's status:

macOS High Sierra 10.13.6, released September 25, 2017, last update July 09, 2018, Intel 64, not maintained
macOS Mojave 10.14.6, released September 24, 2018, last update September 26, 2019, Intel 64, not maintained
macOS Catalina 10.15.7, released October 7, 2019, last update September 23, 2020, Intel 64, not maintained
macOS Big Sur 11.7.10, released November 12, 2020, last update September 11, 2023, Intel and ARM 64, not maintained
macOS Monterey 12.7.6, released October 25, 2021, last update July 29, 2024, Intel and ARM 64, not maintained
macOS Ventura 13.7.4, released October 24, 2022, last update February 10, 2025, Intel and ARM 64, still maintained
macOS Sonoma 14.7.4, released September 26, 2023, last update February 10, 2025, Intel and ARM 64, still maintained
macOS Sequoia 15.3.2, released September 16, 2024, last update March 11, 2025, Intel and ARM 64, maintained

Apart from that, hardware from 2008 onwards can be provided with macOS from macOS Monterey 12+ to macOS Sequoia using the OpenCorePatcher. The OpenCorePatcher no longer supports macOS prior to macOS Monterey 12.

So everyone can get a picture of it.

>     • In hindsight, my use of the terms Supported, Obsolete and Unsupported may be misleading, particularly the last. It does not mean Tcl will not build or that we will ignore bug reports for unsupported platforms. Suggestions for better names and definitions most welcome. 

What does this look like with SSL/TLS

SSL 2.0, released 1995, deprecated in 2011, not maintained
SSL 3.0, released 1996, deprecated in 2015, not maintained
TLS 1.0, released 1999, deprecated in 2021, not maintained
TLS 1.1, released 2006, deprecated in 2021, not maintained
TLS 1.2, released 2008, in use since 2008, still maintained
TLS 1.3, released 2018, in use since 2018, maintained

>     • Someone needs to take the lead on macOS and Linux/Unix. But as a general comment, I do not think we should be concerned about supporting 9.1 on platforms that are old *and* have less than 5% market share (my criteria for Windows). So for example, for macOS https://telemetrydeck.com/survey/apple/macOS/versions/
>  /Ashok

macOS, Linux/Unix must be considered separately. Although there is the overlap that X11 R6 is also available on macOS, macOS has its own GUI.
So that means there is macOS on the one hand and Linux and Unix on the other, which I think can be summarized.
I looked at the statistics, if you can trust them and compare them with the supported versions mentioned above, the old stuff is hardly used anymore.

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

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

OK, that's a good statement, if that's the case I'm also of the opinion from 10.13.

> Am 14.03.2025 um 22:48 schrieb Marc Culler <cul...@gm...>:
> 
> I would advocate supporting macOS 10.13 and newer.  The reason is that there is no issue right now with building or running Tk9 on
> macOS 10.13 and newer.  It takes no extra work for us to support those versions.  The current tiip of main even passes all tests on 10.13.  And we have recently had several very useful tickets opened by Eric Brunel based on testing on 10.13 but applicable generally.
> 
> I think that as long as it costs us nothing and provides even a tiny marginal benefit, then we should do it.

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

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

Thanks for the comments so far. I am awaiting for further feedback before updating the TIP. In the meanwhile, some thoughts on the responses received so far.

 

*	There have been some comments about autoconf etc. not being runtime requirements. Note that the TIP intends to address *both* runtime and build requirements, including compilers (C11 support), tools (min autoconf version, gnu make dependencies etc.) etc. If anyone thinks the build environment should be moved to a separate TIP, please do so, no objection from me.

 

*	With regards to Marc and Steve’s comments about platforms (paraphrasing) “not needing extra work”. As the definition currently stands Supported means it has to be specifically tested on that platform for every release. So at a minimum there is at least that effort required. In addition, when new features are added, they must be implemented for that platform as well. That is the reason Windows 7 is explicitly marked as Obsolete though no additional work is required as of today. It is not tested, and if new features, say pty console support, are added, feasibility on Windows 7 will not be taken into consideration.

 

*	In hindsight, my use of the terms Supported, Obsolete and Unsupported may be misleading, particularly the last. It does not mean Tcl will not build or that we will ignore bug reports for unsupported platforms. Suggestions for better names and definitions most welcome.

 

*	Someone needs to take the lead on macOS and Linux/Unix. But as a general comment, I do not think we should be concerned about supporting 9.1 on platforms that are old *and* have less than 5% market share (my criteria for Windows). So for example, for macOS https://telemetrydeck.com/survey/apple/macOS/versions/ 

 

/Ashok

 

From: Steve Landers <st...@di...> 
Sent: Saturday, March 15, 2025 6:10 AM
To: Tcl Core List <tcl...@li...>; nicolas bats <sl1...@gm...>; da Silva, Peter J <pet...@fl...>; Dipl. Ing. Sergey G. Brester <se...@us...>; Marc Culler <cul...@gm...>
Subject: Re: [TCLCORE] [External] Re: TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

 

FWIW I agree with Marc.

Mac hardware lasts a long time in my experience and I have old equipment dedicated to specific tasks that is still running happily (not internet facing so I’m not concerned about the security).  Being able to run Tcl 9 its a bonus if it doesn’t cost us anything.

 

-- Steve

On 15 Mar 2025 at 5:50 AM +0800, Marc Culler <cul...@gm... <mailto:cul...@gm...> >, wrote:



I would advocate supporting macOS 10.13 and newer.  The reason is that there is no issue right now with building or running Tk9 on

macOS 10.13 and newer.  It takes no extra work for us to support those versions.  The current tiip of main even passes all tests on 10.13.  And we have recently had several very useful tickets opened by Eric Brunel based on testing on 10.13 but applicable generally.

 

I think that as long as it costs us nothing and provides even a tiny marginal benefit, then we should do it.

 

- Marc

 

On Thu, Mar 13, 2025 at 9:00 AM nicolas bats <sl1...@gm... <mailto:sl1...@gm...> > wrote:

Hi, 

I saw a lot of Intel64 that cannot go after macOS 10.15.7 (without OpenCore)

 

++

 

Le jeu. 13 mars 2025 à 14:53, da Silva, Peter J <pet...@fl... <mailto:pet...@fl...> > a écrit :

With or without OpenCore? If you’re talking about 32-bit machines, I suspect excluding them was intended:

> “It makes sense to drop support for all macOS versions before 2020. This would limit support to Intel-64 and ARM64”

 

From: nicolas bats <sl1...@gm... <mailto:sl1...@gm...> >
Date: Thursday, March 13, 2025 at 08:44
To: Alexander Schöpe <a.s...@gm...>
Cc: Dipl. Ing. Sergey G. Brester via Tcl-Core <tcl...@li... <mailto:tcl...@li...> >
Subject: [External] Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

Hi,

regrading macOS I would strongly be in favor to support from 

macOS 10.15     Catalina        Intel 64                October 7, 2019

 

As several old machines cannot go to Big Sur

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

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