tcl-core — Tcl Core Team discussions about Tcl development

[TCLCORE] Speed/memory tradeoffs on list operations

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

All,

 

While Tcl 9 supports strings, lists etc. greater than 2**32, even some

basic operations on data of much smaller lengths has practical

difficulties around execution time and memory space. I am experimenting

with approaches to improve efficiency and looking for opinions and some

guidance on time and memory tradeoffs, starting with list operations

(both existing ones like lreverse as well as new ones like merge, zip).

 

The most obvious way to improve performance is of course to implement

more commands in C. Consider the operation of "zipping" lists written

in script as "lmap x $l1 y $l2 {list $x $y}". Measuring speed (timerate)

and memory (/proc/self/statm) when zipping lists of size 100000 shows:

 

Memory pre: 3070 1752 1083 1 0 752 0

lmap $a $b: 46985.7 µs/# 22 # 21.283 #/sec 1033.686 net-ms

Memory post lmap: 7701 6293 1083 1 0 5383 0

 

The same operation implemented as a "lzip" command in C, is obviously

faster.

 

Memory pre: 3314 2066 1102 1 0 992 0

lzip $a $b: 13895.7 µs/# 72 # 71.965 #/sec 1000.491 net-ms

Memory post lzip: 7747 6417 1102 1 0 5425 0

 

Note however the memory requirements are (naturally) the same.

 

Going further, implementing lzip as a TIP 636 abstract list with an

obvious implementation,

 

Memory pre: 3314 2076 1112 1 0 992 0

lzip $a $b: 0.270993 µs/# 3298677 # 3690129 #/sec 893.919 net-ms

Memory post lzip: 3314 2076 1112 1 0 992 0

 

Notice (a) orders of magnitude faster (in fact constant time

irrespective of list length), and (b) *zero* memory cost as the list

arguments' storage is simply referenced.

 

Alas, there is no free lunch.

 

The cost of indexing and iterating over the list as "foreach x $l {}" is

significantly higher with abstract lists.

 

traditional list:

iterate: 18256.1 µs/# 55 # 54.776 #/sec 1004.083 net-ms

index: 0.056268 µs/# 10757211 # 17772142 #/sec 605.285 net-ms

Memory post pure iterate: 7747 6483 1102 1 0 5425 0

 

abstract list:

iterate: 29596.3 µs/# 34 # 33.788 #/sec 1006.274 net-ms

index: 0.169833 µs/# 4926811 # 5888123 #/sec 836.737 net-ms

Memory post pure iterate: 3314 2076 1112 1 0 992 0

 

Thus cost of construction+iteration is roughly a wash with the abstract

list implementation coming out slightly ahead. However, if iterating

multiple times, the traditional lists will be much more performant.

 

The difference (which shows up even for lseq) arises because the

non-abstract implementation is basically a direct access into the C

array holding the elements whereas abstract lists have to construct

elements on request.

 

Note however, the memory disparity remains.

 

[The above measured using extension. There might be some improvement in

the core with some byte code support but I do not think it would be

substantial].

 

Given the lack of application benchmarks, it's difficult to make a call

one way or another as to real-life impact. May be the much lower memory

requirements means better cache properties? Conversely, if application

retains constructed elements retrieved during iteration, perhaps the

memory savings are illusory?

 

Of course, it is possible to choose at runtime between the two internal

representations (abstract/non-abstract) based on the length of the lists

so only "large" lists longer than some threshold would be abstracted.

 

I am looking for opinions as to all this would be worth

doing ("this" being abstract lists implementing zip, lreverse, concat,

merge, range, and other list operations). There are really two

questions:

 

1. Is it worth moving above operations into C?

 

2. If so, are abstract lists worth the construction+memory vs iteration

speed tradeoff?

 

I'm inclined to say yes to both, particularly as abstract lists will

allow operations on lists too large for the other methods (what was the

point of increasing size limits otherwise?).

 

Alternatively, we could do just 1. benefiting speed but not memory.

 

Or neither, which would save me a bunch of work and avoid code bloat in

the core.

 

Thoughts anyone?

 

/Ashok

Re: [TCLCORE] Tcl_WideInt and long long

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

Thanks for bringing this up. It has always been a source of confusion for me so I'm all for eliminating it. See my question and Jan's response at https://sourceforge.net/p/tcl/mailman/tcl-core/thread/00c701db4146%24f0ec3650%24d2c4a2f0%24%40yahoo.com/#msg58846548

I am a little hesitant about defining Tcl_WideInt as int64_t (if I understood Donal correctly) rather than long long, in case some platform typedefs int64_t as long. Even though that is more elegant and cleaner in some respect, I suspect it would cause gcc warnings in extensions that are passing Tcl_WideInt to (external functions) that expect long long * (see above thread) or use it with %lld.

/Ashok

-----Original Message-----
From: Donald G Porter via Tcl-Core <tcl...@li...> 
Sent: Thursday, April 17, 2025 12:55 AM
To: Tcl List Core <tcl...@li...>
Subject: [TCLCORE] Tcl_WideInt and long long


This question may be fully addressed and answered in some TIP, and if
so it's a sufficient answer to point me to it.

In Tcl 9, is it true that C type Tcl_WideInt is always the same as
C type (long long int) ?  Likewise Tcl_WideUInt is always same as
(unsigned long long int) ?

If it is not true, what are the exceptions and why is it important to
continue supporting them?

If it is true, what do people think about work for Tcl 9.1 to tear
down constructions that suggest otherwise, like conditional compilation
on the value TCL_WIDE_INT_TYPE, etc. ?  What do people think about
including that simplification work also in Tcl 9.0 patch releases?

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|



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

Re: [TCLCORE] Tcl_WideInt and long long

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

I'd be very happy if we ended up using int64_t and uint64_t from <stdint.h>, which I think should be there in all but the most recalcitrant C implementation now. Everything to do with "wide ints" was a bodge to work around that not being a common header file 20 years ago.

Donal.

-------- Original message --------
From: Jan Nijtmans <jan...@gm...>
Date: 16/04/2025 21:15 (GMT+00:00)
To: Donald G Porter <don...@ni...>
Cc: Tcl List Core <tcl...@li...>
Subject: Re: [TCLCORE] Tcl_WideInt and long long

I would be OK with throwing away TCL_WIDE_INT_TYPE.
Changing it would be a binary incompatible changes, and too
many internal constructs would break if
sizeof(Tcl_WideInt) > sizeof(long long)

Re: [TCLCORE] Summary of my favorite tickets of this week

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

On 04/16/2025 06:16 PM, Harald Oehlmann wrote
Harald,

> …
> For me, this is critical and probably only solvable by using the much better Undroidwish... The code for 302 is impossible to even put in a branch and adopt to current main. THere is no hope. And there is no Mac-OS implementation.

the once proposed TIP#302 implementation was suitable for both Win32 and POSIX(ish enough, i.e. MacOS) platforms.
Things may have diverged due to the various kqueue/epoll inventions, so adopting the patch might be substantial
work. But the general idea still holds. IMO there is not even a minuscule obstacle to check it out. Well, except
for the virtual time, which was never TIP#ed and documented.
  
All the best,
Christian

Re: [TCLCORE] Tcl_WideInt and long long

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

Op wo 16 apr 2025 om 21:59 schreef Donald G Porter via Tcl-Core:
>
>
> This question may be fully addressed and answered in some TIP, and if
> so it's a sufficient answer to point me to it.

> In Tcl 9, is it true that C type Tcl_WideInt is always the same as
> C type (long long int) ?  Likewise Tcl_WideUInt is always same as
> (unsigned long long int) ?

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

    "Whenever possible, typedef Tcl_WideInt to be equal to long long,
    even on platforms where long has the same size as long long."

I would be OK with throwing away TCL_WIDE_INT_TYPE.
Changing it would be a binary incompatible changes, and too
many internal constructs would break if
sizeof(Tcl_WideInt) > sizeof(long long)

Hope this helps,
      Jan Nijtmans

[TCLCORE] Tcl_WideInt and long long

[Donald G P. <don...@ni...>]

This question may be fully addressed and answered in some TIP, and if
so it's a sufficient answer to point me to it.

In Tcl 9, is it true that C type Tcl_WideInt is always the same as
C type (long long int) ?  Likewise Tcl_WideUInt is always same as
(unsigned long long int) ?

If it is not true, what are the exceptions and why is it important to
continue supporting them?

If it is true, what do people think about work for Tcl 9.1 to tear
down constructions that suggest otherwise, like conditional compilation
on the value TCL_WIDE_INT_TYPE, etc. ?  What do people think about
including that simplification work also in Tcl 9.0 patch releases?

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] TIP 716 ready for comments

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

Harald wrote:
> I wonder, that the manifest aparently has no influence on TextOutA.

That's right. TextOut is part of Windows GDI which Microsoft explicitly documents as not supporting UTF-8 *even if the code page is set to UTF-8 via the manifest*. There is a "beta" (Microsoft's word, not mine) mode you can set in the registry to enable this but it has been beta mode since *2019* fwiw! And of course it will affect all applications and users on the system.

9.0 and TIP 716 behave the same way because the latter preserves 9.0's [encoding system] to be always utf-8 (modulo platform).

It is unfortunate that extensions have to be modified, needless pain imo, but at least you can fix it since you have the source. The real hard nut is when you do not own the source and have no means to modify it as happened in the DB2 TPC case.

/Ashok

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Wednesday, April 16, 2025 2:51 PM
To: tcl...@li...
Subject: Re: [TCLCORE] TIP 716 ready for comments

Ashok,
you were totally correct.

Here is the relevant code snippet:

pStr = Tcl_GetStringFromObj(objv[PositionSPar],&lStr);
Tcl_UtfToExternalDString( NULL, pStr, lStr, &sPar1);
TextOut(pdlg.hDC, X0, Y0, Tcl_DStringValue( &sPar1 ), Tcl_DStringLength( 
&sPar1 ))

So, TextOutA gets utf-8 in TCL9 and tip-715 and cp12xx on TCL 8.6.

I wonder, that the manifest aparently has no influence on TextOutA.
Normally, it should work with 9.0, as data and interpretation is utf-8.

I don't want to dig too deep here.
TIP 715 is great and already the "encoding user" is very important.

Thanks for all,
Harald



Am 16.04.2025 um 04:17 schrieb apnmbx-public--- via Tcl-Core:
> Harald,
> 
> It **appears** from the output you are passing UTF-8 data to the DLL 
> which is expecting cp1252 or similar.
> 
> For example,
> 
> % set x 1AÄÖÜäöü
> 
> 1AÄÖÜäöü
> 
> % set utf [encoding convertto utf-8 $x]
> 
> 1AÃÃÃäöü
> 
> % encoding convertfrom cp1252 $utf
> 
> 1AÄÖÜäöü
> 
> Which is the output you are seeing. My **guess** (because it works on 
> Tcl8) is you are using one of the Tcl encoding routines which default to 
> [encoding system] (utf-8) and passing that string to the DLL. Note this 
> has not changed in TIP 716 to maintain 9.0 compatibility.
> 
> Can you elaborate on how you are passing data? I would like to resolve 
> as many of these encoding issues on Windows as we can, whether they 
> relate to the manifest/716 or not, before the next patchlevel.
> 
> /Ashok
> 
> -----Original Message-----
> From: Harald Oehlmann <har...@el...>
> Sent: Wednesday, April 16, 2025 1:16 AM
> To: apn...@ya...; tcl...@li...
> Subject: Re: [TCLCORE] TIP 716 ready for comments
> 
> Am 14.04.2025 um 16:54 schrieb apn...@ya... <mailto:apnmbx- 
> pu...@ya...>:
> 
>  > Harald,
> 
>  >
> 
>  > Could you try the tip-716 branch to see if fixes your print dll umlaut
> 
>  > issue?
> 
> Unfortunately, my dll with A-suffix API prints:
> 
> 1AÄÖÜäöü
> 
> for 8.6 and
> 
> 1AÄÖÃoeäöü
> 
> for 9.0 and TIP715 branch
> 
> 8.6 was build with MS.VC 6 32 bit
> 
> 9.0 was build with VS 2022 32 bit
> 
> Sorry,
> 
> Harald
> 
> 
> 
> _______________________________________________
> 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] Summary of my favorite tickets of this week

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

Dear Christian,
thanks for the post!
As you can see in most of the tickets: I am totally desperate that we 
can ever cope with this wizard stuff. You need much better nerds on this 
side, sorry. I have no hope...

For me, specially TIP 302 is very annoying, as a running TCL/Tk program 
can be put to malfunction by just changing the clock.

On the Windows side, I have critical programs, which rely on after. But 
you can:
- remove after events
- delay them by hours or days
by changing the clock.

For me, this is critical and probably only solvable by using the much 
better Undroidwish... The code for 302 is impossible to even put in a 
branch and adopt to current main. THere is no hope. And there is no 
Mac-OS implementation.

On the block cursor I have tried. I was positively surprised by the 
current Windows performance. There are no other platforms who wanted to 
test or look into this. The real nerd level (color font, combining 
recent unicode) or to stop split-brain is IMHO impossible for the 
current nerd level for Windows. Firefox has it.

Thanks for all your great work,
Harald

Am 11.04.2025 um 21:59 schrieb Christian Werner:
> Hello friends of critical thinking,
> 
> here we go, the top 3 are:
> 
> 1. Floating point numbers
> 
> Ticket
> https://core.tcl-lang.org/tcl/info/42d14c495a096159
> got at least a branch of its own now. IMO it deserves
> much attention since its non-solution keeps the doors
> wide open for penetrators presenting loooooooooooong
> floating point strings to your innocent maiden Tcl
> script.
> 
> 2. TIP#302
> 
> This discussion is universal and got revival in a new
> ticket this time in the Tk repo:
> https://core.tcl-lang.org/tk/info/2f1086ac088c3593
> Now even the Python users of Tkinter (with Tcl under
> the hood) get aware of this long standing problem.
> Time is heavy sometimes…
> 
> 3. The text widget's -blockcursor option
> 
> The heat is on, see ticket
> https://core.tcl-lang.org/tk/info/5d0bc3cfec7c1adb
> and we've got still no clue what should be done.
> Put ICU on hold on not MacOS platforms or live with
> differences between ICU and platform dependent font
> rendering.
> 
> I hope these points will be addressed in the not so
> distant future.
> 
> Wish you all a nice weekend,
> Christian
> 

Re: [TCLCORE] TIP 716 ready for comments

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

Am 16.04.2025 um 14:03 schrieb Jan Nijtmans:
> Op wo 16 apr 2025 om 13:35 schreef Harald Oehlmann:
>> thanks for the hint. I have now replaced it with the idom introduced in
>> Tcl 8.0 (at least Tcl 8.4):
>>
>> Tcl_WinUtfToTChar( pStr, lStr, &sPar1);
> 
> That's fine too. Tcl_WinUtfToTChar is platform-dependant
> (Windows-only), and  works fine.

But it is deprecated.
The great advantage of Tcl_UtfToWCharDString is, that it appends to the 
DString, and does not replace it.

> The function Tcl_WinTCharToUtf() (the other way round)
> has the strange property that the "length" parameter
> must be specified in "bytes", not in WCHAR's. That's
> one source of confusion. Another one is that
> Tcl_WinUtfToTChar and Tcl_WinTCharToUtf don't
> accept -1 as length parameter, which should mean
> "until the terminating NULL". Tcl_UtfToWCharDString()
> is much more useful than Tcl_WinTCharToUtf().
> 
>> The migration:
>> https://core.tcl-lang.org/tcl/wiki?name=Migrating+C+extensions+to+Tcl+9&p
>> does not tell anything on this...
> 
> So, that should be extended. All is described here:
>       <https://core.tcl-lang.org/tips/doc/trunk/tip/548.md>

The man-page is here:

https://www.tcl-lang.org/man/tcl9.0/TclLib/Utf.html

I think, there should be examples here and use-cases.
This page does not mention "Tcl_WinUtfToTChar".

This command is documented on the encoding.3 man page in 8.6.
In Tcl 9.0, it is not documented at all.

That is probably ok to not mention deprecated functions.

I may fix all this one day.
In documentation, I am not so bad as in coding...

Thanks for all,
Harald

Re: [TCLCORE] TIP 716 ready for comments

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

Op wo 16 apr 2025 om 13:35 schreef Harald Oehlmann:
> thanks for the hint. I have now replaced it with the idom introduced in
> Tcl 8.0 (at least Tcl 8.4):
>
> Tcl_WinUtfToTChar( pStr, lStr, &sPar1);

That's fine too. Tcl_WinUtfToTChar is platform-dependant
(Windows-only), and  works fine.

The function Tcl_WinTCharToUtf() (the other way round)
has the strange property that the "length" parameter
must be specified in "bytes", not in WCHAR's. That's
one source of confusion. Another one is that
Tcl_WinUtfToTChar and Tcl_WinTCharToUtf don't
accept -1 as length parameter, which should mean
"until the terminating NULL". Tcl_UtfToWCharDString()
is much more useful than Tcl_WinTCharToUtf().

> The migration:
> https://core.tcl-lang.org/tcl/wiki?name=Migrating+C+extensions+to+Tcl+9&p
> does not tell anything on this...

So, that should be extended. All is described here:
     <https://core.tcl-lang.org/tips/doc/trunk/tip/548.md>

Hope this helps,
       Jan Nijtmans

Re: [TCLCORE] TIP 716 ready for comments

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

Jan,
thanks for the hint. I have now replaced it with the idom introduced in 
Tcl 8.0 (at least Tcl 8.4):

Tcl_WinUtfToTChar( pStr, lStr, &sPar1);

IMHO this looks nicer, as no #if is required. I suppose, there is an #if 
under the hood, but it is not visible to me.

But I feel, I get again something completly wrong. That is all 
soooooooooooooo complicated...
Why now two commands, where there was one before and a requirement for 
an #if, where there was none before.
The migration:
https://core.tcl-lang.org/tcl/wiki?name=Migrating+C+extensions+to+Tcl+9&p
does not tell anything on this...

Thanks for all,
Harald

Am 16.04.2025 um 13:05 schrieb Jan Nijtmans:
> Op wo 16 apr 2025 om 11:21 schreef Harald Oehlmann:
>> Here is the relevant code snippet:
>>
>> pStr = Tcl_GetStringFromObj(objv[PositionSPar],&lStr);
>> Tcl_UtfToExternalDString( NULL, pStr, lStr, &sPar1);
>> TextOut(pdlg.hDC, X0, Y0, Tcl_DStringValue( &sPar1 ), Tcl_DStringLength(
>> &sPar1 ))
> 
> My recommendation would be to do this:
> 
> #if (TCL_MAJOR_VERSION < 9) /* In case of Tcl 8.6 */
> # define Tcl_UtfToWCharDString Tcl_UtfToUniCharDString
> # endif
> 
> pStr = Tcl_GetStringFromObj(objv[PositionSPar],&lStr);
> Tcl_DStringInit( &sPar1 );
> Tcl_UtfToWCharDString( pStr, lStr, &sPar1);
> TextOutW(pdlg.hDC, X0, Y0, Tcl_DStringValue( &sPar1 ), Tcl_DStringLength(
> &sPar1 )/sizeof(WCHAR));
> 
> That's what Tcl_UtfToWCharDString was meant for, and it
> works with any encoding, with or without TIP #716.
> 
> Hope this helps,
>           Jan Nijtmans

Re: [TCLCORE] TIP 716 ready for comments

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

Op wo 16 apr 2025 om 11:21 schreef Harald Oehlmann:
> Here is the relevant code snippet:
>
> pStr = Tcl_GetStringFromObj(objv[PositionSPar],&lStr);
> Tcl_UtfToExternalDString( NULL, pStr, lStr, &sPar1);
> TextOut(pdlg.hDC, X0, Y0, Tcl_DStringValue( &sPar1 ), Tcl_DStringLength(
> &sPar1 ))

My recommendation would be to do this:

#if (TCL_MAJOR_VERSION < 9) /* In case of Tcl 8.6 */
# define Tcl_UtfToWCharDString Tcl_UtfToUniCharDString
# endif

pStr = Tcl_GetStringFromObj(objv[PositionSPar],&lStr);
Tcl_DStringInit( &sPar1 );
Tcl_UtfToWCharDString( pStr, lStr, &sPar1);
TextOutW(pdlg.hDC, X0, Y0, Tcl_DStringValue( &sPar1 ), Tcl_DStringLength(
&sPar1 )/sizeof(WCHAR));

That's what Tcl_UtfToWCharDString was meant for, and it
works with any encoding, with or without TIP #716.

Hope this helps,
         Jan Nijtmans

Re: [TCLCORE] TIP 716 ready for comments

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

Ashok,
you were totally correct.

Here is the relevant code snippet:

pStr = Tcl_GetStringFromObj(objv[PositionSPar],&lStr);
Tcl_UtfToExternalDString( NULL, pStr, lStr, &sPar1);
TextOut(pdlg.hDC, X0, Y0, Tcl_DStringValue( &sPar1 ), Tcl_DStringLength( 
&sPar1 ))

So, TextOutA gets utf-8 in TCL9 and tip-715 and cp12xx on TCL 8.6.

I wonder, that the manifest aparently has no influence on TextOutA.
Normally, it should work with 9.0, as data and interpretation is utf-8.

I don't want to dig too deep here.
TIP 715 is great and already the "encoding user" is very important.

Thanks for all,
Harald



Am 16.04.2025 um 04:17 schrieb apnmbx-public--- via Tcl-Core:
> Harald,
> 
> It **appears** from the output you are passing UTF-8 data to the DLL 
> which is expecting cp1252 or similar.
> 
> For example,
> 
> % set x 1AÄÖÜäöü
> 
> 1AÄÖÜäöü
> 
> % set utf [encoding convertto utf-8 $x]
> 
> 1AÃÃÃäöü
> 
> % encoding convertfrom cp1252 $utf
> 
> 1AÄÖÜäöü
> 
> Which is the output you are seeing. My **guess** (because it works on 
> Tcl8) is you are using one of the Tcl encoding routines which default to 
> [encoding system] (utf-8) and passing that string to the DLL. Note this 
> has not changed in TIP 716 to maintain 9.0 compatibility.
> 
> Can you elaborate on how you are passing data? I would like to resolve 
> as many of these encoding issues on Windows as we can, whether they 
> relate to the manifest/716 or not, before the next patchlevel.
> 
> /Ashok
> 
> -----Original Message-----
> From: Harald Oehlmann <har...@el...>
> Sent: Wednesday, April 16, 2025 1:16 AM
> To: apn...@ya...; tcl...@li...
> Subject: Re: [TCLCORE] TIP 716 ready for comments
> 
> Am 14.04.2025 um 16:54 schrieb apn...@ya... <mailto:apnmbx- 
> pu...@ya...>:
> 
>  > Harald,
> 
>  >
> 
>  > Could you try the tip-716 branch to see if fixes your print dll umlaut
> 
>  > issue?
> 
> Unfortunately, my dll with A-suffix API prints:
> 
> 1AÄÖÜäöü
> 
> for 8.6 and
> 
> 1AÄÖÃoeäöü
> 
> for 9.0 and TIP715 branch
> 
> 8.6 was build with MS.VC 6 32 bit
> 
> 9.0 was build with VS 2022 32 bit
> 
> Sorry,
> 
> Harald
> 
> 
> 
> _______________________________________________
> 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] TIP 716 ready for comments

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

Harald,

 

It *appears* from the output you are passing UTF-8 data to the DLL which is expecting cp1252 or similar. 

 

For example,

 

% set x 1AÄÖÜäöü

1AÄÖÜäöü

% set utf [encoding convertto utf-8 $x]

1AÃÃÃäöü

% encoding convertfrom cp1252 $utf

1AÄÖÜäöü

 

Which is the output you are seeing. My *guess* (because it works on Tcl8) is you are using one of the Tcl encoding routines which default to [encoding system] (utf-8) and passing that string to the DLL. Note this has not changed in TIP 716 to maintain 9.0 compatibility.

 

Can you elaborate on how you are passing data? I would like to resolve as many of these encoding issues on Windows as we can, whether they relate to the manifest/716 or not, before the next patchlevel.

 

/Ashok

 

 

 

 

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Wednesday, April 16, 2025 1:16 AM
To: apn...@ya...; tcl...@li...
Subject: Re: [TCLCORE] TIP 716 ready for comments

 

Am 14.04.2025 um 16:54 schrieb  <mailto:apn...@ya...> apn...@ya...:

> Harald,

> 

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

> issue?

Unfortunately, my dll with A-suffix API prints:

 

1AÄÖÜäöü

 

for 8.6 and

 

1AÄÖÃoeäöü

 

for 9.0 and TIP715 branch

 

8.6 was build with MS.VC 6 32 bit

9.0 was build with VS 2022 32 bit

 

Sorry,

Harald

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

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

Here is a new Wiki page that summarises the choices for a scrollable frame,
and also acts as a Category page for the many other pages on the subject. 
Please edit as usual.

https://wiki.tcl-lang.org/page/Category+Scrollable+Widget

Keith.


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

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

> 

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

Re: [TCLCORE] TIP 716 ready for comments

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

Op di 15 apr 2025 om 21:02 schreef apnmbx-public--- via Tcl-Core
<tcl...@li...>:
> I noticed the commit you made in tclWinTest.c for testing TIP 716. Thanks for the test but the test construction is broken with respect to the intent of TIP 716.

I'm still in "experimenting" state ....     Feel free to use the
outcome of those experiments to
clarify the TIP #716 text and/or modify the tcl9.0/doc documentation.

Hope this helps,
     Jan Nijtmans

Re: [TCLCORE] TIP 716 ready for comments

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

Am 14.04.2025 um 16:54 schrieb apn...@ya...:
> Harald,
> 
> Could you try the tip-716 branch to see if fixes your print dll umlaut 
> issue?
Unfortunately, my dll with A-suffix API prints:

1AÄÖÜäöü

for 8.6 and

1AÄÖÃoeäöü

for 9.0 and TIP715 branch

8.6 was build with MS.VC 6 32 bit
9.0 was build with VS 2022 32 bit

Sorry,
Harald

Re: [TCLCORE] TIP 716 ready for comments

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

Jan,

 

I noticed the commit you made in tclWinTest.c for testing TIP 716. Thanks
for the test but the test construction is broken with respect to the intent
of TIP 716.

 

The fundamental purpose of TIP 716 is to ensure that DLL's (that may know
nothing about Tcl) that use ANSI API's continue to work as before. The use
of ANSI API's involves calling the Win32 WideCharToMultiByte function first
to encode as per the user's code page, obtained through GetACP. The encoded
string is then passed to the ANSI API. The important point I've tried to
emphasize in the TIP is that if you force GetACP to return utf-8, (a) the
DLL may not be coded to handle variable length encoding of 4 bytes (a lot of
legacy ANSI based code assumes DBCS or MBCS with max length 2), and (b) the
application at the other end of the data transfer (like the database server
in the DB2 case) expects the real user's code page setting and fails when it
sees utf-8 instead.

 

In your modifications to tclWinTest.c, you are encoding the file name using
Tcl_UtfToExternalDString using Tcl's system encoding (utf-8) but passing it
to an ANSI API expecting the user's code page encoding. This will simply not
work. It should use Unicode API's, or encoding using
WideCharToMultiByte(GetACP().). The whole point of TIP 716 is that your
changes should fail as you should be encoding using the result of GetACP(),
not [encoding system]!

 

The rules are (as per TIP 716):

 

1.	Use the Unicode Windows API as Tcl/Tk already do. Then these issues
do not arise.
2.	If you have to use ANSI API's, use Windows encoding settings, not
Tcl encoding settings.

 

To summarize the whole situation again,

 

In Tcl 8.x AND 9.0 non-Windows platforms, [encoding system] is derived from
user settings (GetACP) making them consistent both with each other and with
other applications.

 

In 9.0 on new Windows platforms, in effect GetACP and [encoding system] are
both hardcoded to utf-8 because of the manifest. They are consistent with
each other but only within that process, not with other applications and not
compatible with some DLL's leading to the problems described in the TIP.
This consistency means that your changes to tclWinTest.c would be OK for 9.0
(but only because the file system API's, unlike GDI, supports UTF-8!).

 

In TIP 716, the explicit choice is made to (a) hardcode [encoding system] to
UTF-8 for compatibility with 9.0 but not hardcode GetACP , thereby making it
inconsistent with [encoding system]. This inconsistency is forced because
reverting to the 8.x / 9.0 non-Windows method would mean incompatibility
with 9.0 on Windows in terms of the default encoding for channels. This
inconsistency however eliminates some of the issues listed in 716 at the
cost of having to follow the rules mentioned above. Note Tcl/Tk already uses
Unicode Win32 API's.

 

This whole headache has arisen because of the implicit decision in Tcl 9 to
split Tcl's system encoding setting from Windows user's encoding setting but
it's too late to turn back the clock now. Either we stick with 9.0 and the
reported issues, or move with TIP 716 and stick to Unicode API's in Tcl
(which we already do anyways).

 

/Ashok

 

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Monday, April 14, 2025 10:22 AM
To: tcl...@li...
Subject: [TCLCORE] TIP 716 ready for comments

 

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

 

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

 

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

 

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

 

/Ashok

 

 

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

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

Dear Hararld, allow me to make a few remarks

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

I don't know the history of Tk before 8.4 days but, reading the code,
I had the impression that many data that was once global was moved to
a thread specific data, being static (or global) inside the current
thread. 

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

+1

> - only for current thread

This is the current behaviour. I would *really* prefer it to be interp
specific. More on this below.

> - may return an error (already registered)

Or not, but it should be user defined. A flag can be used to signal
"replace if already exists" or "error out if already exists".

In any case, I think the current behaviour should at least be documented.

> - maybe should make a copy of the passed data

This is the current behaviour; the Tk_ImageType structure saved in the
linked list of currently registered types is a copy of the passed in to
Tk_CreateImageType.

See https://core.tcl-lang.org/tk/file?ci=trunk&name=generic/tkImage.c&ln=158

> - should have a version in the passed data structure for later extension

+1

> - contains an unregister call (which may fail).

+1. This will make [unload] it at least possible.

I think an important point to decide is whether the type register should be
thread specific (as it is today) or interp specific. In the last case, the code
implementing it will mimic what any well behaved extension does.

> And the "low hanging fruit" "image photo formats" is evolving to a mega 
> project. As the final image goal is to load into tcl without tk, it 
> feels even more impossible to reach...

There is an extension mentioned in the wiki

https://wiki.tcl-lang.org/page/megaimage

for image manipulation in Tcl without Tk or external libraries, except
the ones required for external formats like jpg or png. While the source
vanished from the internet, I have a copy of it at home. Let me know if you
are interested and I'll gladly hand it out.

Regards.

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

Re: [TCLCORE] TIP 716 ready for comments

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

Ashok,

I can confirm that "encoding user" works as expected.
The print dll test will take some days.

Another term for non Windows users which may lead to confusion:
"Win32 API" is used for 32 (x86) and 64 bit (x64,ARM64) Windows

Thanks for all,
Harald

Am 14.04.2025 um 16:54 schrieb apn...@ya...:
> Harald,
> 
> Could you try the tip-716 branch to see if fixes your print dll umlaut 
> issue?
> 
> Also, the encoding user command is documented. “/Correspondingly, a new 
> command encoding user will be added on all platforms and will return the 
> result of Tcl_GetEncodingNameForUser.”/ I suppose I should add the 
> syntax synopsis for both the C API and the command.
> 
> I am not particularly tied to use of environment variables but note Tcl 
> does use several, even on Windows.
> 
> /Ashok
> 
> -----Original Message-----
> From: Harald Oehlmann <har...@el...>
> Sent: Monday, April 14, 2025 5:23 PM
> To: tcl...@li...
> Subject: Re: [TCLCORE] TIP 716 ready for comments
> 
> Ashok,
> 
> thanks for the great initiative.
> 
> You are always our saver of preliminary decisions, like Size_t and
> 
> ptrDiff_t.
> 
> I am personally trapped in two senses:
> 
> - my own printing dll's use 8 bit API and don't print German Umlauts
> 
> (äöüÄÖÜ) any more.
> 
> - there is no way on Tcl 9 on the script level to find the system
> 
> encoding of Tcl 8.6. So, sourcing files using "source -encoding native"
> 
> is not possible, because "native" is not known on the script level. You
> 
> mention a new command "[encoding user]" in an example. I suppose, this
> 
> will solve this issue and "encoding user" will return what "encoding
> 
> system" returns in 8.6.
> 
> About the TIP:
> 
> - GREAT !!!!
> 
> - describe "encoding user"
> 
> - On Windows, environment variables are less comment. As a consequence,
> 
> using an environment variable for the default set of "exec -encoding"
> 
> is, at least, strange on Windows. This is a minor point. IMHO it is aso
> 
> a security risk, that an application does not work as expected due to
> 
> external influence.
> 
> Thanks for ALL !
> 
> Harald
> 
> Am 14.04.2025 um 06:51 schrieb apnmbx-public--- via Tcl-Core:
> 
>  > TIP 716: New command "encoding user", remove UTF-8 manifest setting on
> 
>  > Windows <https://core.tcl-lang.org/tips/doc/trunk/tip/716.md 
> <https://core.tcl-lang.org/tips/doc/trunk/tip/716.md>> is ready
> 
>  > for comments. It proposes reversion of a change made in 9.0 to tclsh and
> 
>  > wish Windows manifests while keeping compatibility with 9.0.{0,1}.
> 
>  >
> 
>  > Apologies for my usual verbosity, but when I brought this up in the
> 
>  > mailing list prior to the previous release, the comments wandered into
> 
>  > why UTF-8 should be the default. I've tried to better explain that is
> 
>  > not the issue.
> 
>  >
> 
>  > I will point out that the original change to the manifest, which made
> 
>  > UTF-8 the default on Win 10 1903+ and Win 11, should have been TIP'ed as
> 
>  > it overrides user settings and is a change in behavior of a public API
> 
>  > and command. It's water under the bridge now that 9.0 has shipped so the
> 
>  > TIP maintains status quo and only changes the implementation. It also
> 
>  > adds a new /encoding user/ command and an /-encoding/ option to /exec /
> 
>  > as a workaround for compatibility issues introduced by forcing a UTF-8
> 
>  > default.
> 
>  >
> 
>  > Note the implementation in the tip-716 branch is mostly complete but not
> 
>  > ready for review. I am only looking for comments on the proposal before
> 
>  > proceeding further with tests and docs.
> 
>  >
> 
>  > /Ashok

Re: [TCLCORE] TIP 716 ready for comments

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

Harald,

 

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

 

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

 

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

 

/Ashok

 

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

 

Ashok,

thanks for the great initiative.

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

ptrDiff_t.

 

I am personally trapped in two senses:

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

(äöüÄÖÜ) any more.

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

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

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

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

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

system" returns in 8.6.

 

About the TIP:

- GREAT !!!!

- describe "encoding user"

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

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

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

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

external influence.

 

Thanks for ALL !

Harald

 

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

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

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

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

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

> 

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

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

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

> not the issue.

> 

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

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

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

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

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

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

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

> default.

> 

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

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

> proceeding further with tests and docs.

> 

> /Ashok

> 

Re: [TCLCORE] TIP 716 ready for comments

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

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

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

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

Thanks for ALL !
Harald

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

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

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

Dear group,

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

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

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

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

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

So many questions...

Thanks for all,
Harald

---

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

[TCLCORE] TIP 716 ready for comments

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

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

 

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

 

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

 

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

 

/Ashok

 

 

[TCLCORE] Wiki post on work areas and futures

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

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

 

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

 

/Ashok