tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] CFV warning: TIP #698: Handle negative screen distances

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

Op wo 30 apr 2025, 19:51 schreef Francois Vogel <fvo...@fr...>:

> Hi Jan,
>
> My concern, as often, is regarding the revised text widget. When this
> will get merged into trunk, will you also make the necessary changes in
> branch revised_text?
>

For the revised_text widget, only the -offset tag is affected (see TIP). I
will make the necessary change for this single option. All other options
dont need modification.

Hope this helps
        Jan Nijtmans

>

Re: [TCLCORE] CFV warning: TIP #698: Handle negative screen distances

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

Hi Jan,

My concern, as often, is regarding the revised text widget. When this 
will get merged into trunk, will you also make the necessary changes in 
branch revised_text?

Regards,

Francois

Le 30/04/2025 à 14:14, Jan Nijtmans a écrit :
> This is a CFV warning for TIP #698. for Tk 9.1+:
>      Handle negative screen distances
>      <https://core.tcl-lang.org/tips/doc/trunk/tip/698.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

[TCLCORE] CFV warning: TIP #698: Handle negative screen distances

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

This is a CFV warning for TIP #698. for Tk 9.1+:
    Handle negative screen distances
    <https://core.tcl-lang.org/tips/doc/trunk/tip/698.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] TIP 716 ready for comments

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

Op wo 30 apr 2025 om 09:43 schreef Jan Nijtmans:
> > The following idiom I presume you are referring to,
> >
> > Tcl_UtfToExternalDString(NULL,...,&ds);
> > CreateFileA(Tcl_Value(&ds)...);

For completeness, another idiom I'm referring to:
   const char *str = Tcl_GetStringFromObj(....)
   CreateFileA(str, ...)

Surprisingly many extensions use that. In 8.x it works fine, as
long as the filename is restricted to ASCII. In 9.0.0/9.0.1 it
works fine as long as the filename is restricted to UTF-8 ;-).
With TIP #716 it works fine as long as the filename is
restricted to ASCII (which is the same brokenness as 8.x ...)

It's up to you how to incorporate this information in the TIP
text, or - if you want - leave it out.

Some examples:
    https://sqlite.org/src/file?name=src/tclsqlite.c&ci=ba7d5bad32ad6aac&ln=2604
    https://github.com/auriocus/VecTcl/blame/master/WavReader/generic/wavreader.c
(line 88)

Regards,
       Jan Nijtmans

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

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

Further to what Pietro has said,  I cannot see why a *nix variant (or even a Linux distro) should require two maintainers when that is the same number are required for Windows and macOS,  both of which are quite different from a *nix/X11 platform.

Surely it is enough for the test suite for a release to pass for a platform to be considered tested, irrespective of the number of developers?

-- Steve
On 30 Apr 2025 at 4:21 PM +0800, Pietro Cerutti via Tcl-Core <tcl...@li...>, wrote:
> On Mar 13 2025, 11:53 +0000, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote:
> [-- Type: text/plain; charset=US-ASCII, Encoding: 7bit, Size: 0.7K --]
> > All,
> >
> > In Tuesday's online meet, the need for formally defining supported
> > platforms
> > was raised (triggered by Francois' post regarding macOS/XQuartz). As
> > suggested by Harald, I've committed TIP 715
> > (https://core.tcl-lang.org/tips/doc/trunk/tip/715.md) as a starting point
> > for discussion. I have no idea what to include for platforms other than
> > Windows.
>
> I regularly test Tcl/Tk, and several other extensions on FreeBSD. I am
> the one behind tc...@Fr..., and I maintain a lot of Tcl/Tk-related
> ports on FreeBSD.
>
> I don't qualify as "At least two developers committing to development
> and testing for that item", but I think as long as I'm around, we can
> consider FreeBSD as "tested".
>
> As for CI, there's https://cirrus-ci.com/ which offers FreeBSD platforms
> and can be integrated in GitHub, or we could use
> https://github.com/vmactions/freebsd-vm/. Happy to help out setting that
> up.
>
> --
> Pietro Cerutti
> I have pledged to give 10% of income to effective charities
> and invite you to join me - https://givingwhatwecan.org
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

[Pietro C. <ga...@ga...>]

On Mar 13 2025, 11:53 +0000, apnmbx-public--- via Tcl-Core <tcl...@li...> wrote:
[-- Type: text/plain; charset=US-ASCII, Encoding: 7bit, Size: 0.7K --]
>All,
>
>In Tuesday's online meet, the need for formally defining supported 
>platforms
>was raised (triggered by Francois' post regarding macOS/XQuartz). As
>suggested by Harald, I've committed TIP 715
>(https://core.tcl-lang.org/tips/doc/trunk/tip/715.md) as a starting point
>for discussion. I have no idea what to include for platforms other than
>Windows.

I regularly test Tcl/Tk, and several other extensions on FreeBSD. I am 
the one behind tc...@Fr..., and I maintain a lot of Tcl/Tk-related 
ports on FreeBSD.

I don't qualify as "At least two developers committing to development 
and testing for that item", but I think as long as I'm around, we can 
consider FreeBSD as "tested".

As for CI, there's https://cirrus-ci.com/ which offers FreeBSD platforms 
and can be integrated in GitHub, or we could use 
https://github.com/vmactions/freebsd-vm/. Happy to help out setting that 
up.

-- 
Pietro Cerutti
I have pledged to give 10% of income to effective charities
and invite you to join me - https://givingwhatwecan.org

Re: [TCLCORE] TIP 716 ready for comments

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

Op wo 30 apr 2025 om 07:26 schreef Ashok Nadkarni:
> The following idiom I presume you are referring to,
>
> Tcl_UtfToExternalDString(NULL,...,&ds);
> CreateFileA(Tcl_Value(&ds)...);
>
> can produce garbage file names as far back as 8.0. I don't know if it makes sense to add a compatibility note that says in effect "Use of ANSI API's continues to be broken in 9.0.2 ...".

Yes, this is what Iḿ referring to. In 8.x it works fine, as long as
the filename is restricted to CP1252. In 9.0.0/9.0.1 it works fine
as long as the filename is restricted to UTF-8 ;-). With TIP #716
it works fine as long as the filename is restricted to ASCII (which
is even more broken than 8.x ...)

> CFV will be after all the above is done and we discuss the whole topic in the next online meet.

Still, because of the DB2 failure (and maybe more dll's, the TIP says
"many" but I am not aware
of any other) we have to do something about it, so the best approach
is to accept TIP #716 and
handle the damage later.

Hope this helps,
      Jan Nijtmans

Re: [TCLCORE] TIP 716 ready for comments

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

I have no objection to a Compatibility section as such but note the brokenness of ANSI API's is not new to 9.0.2. The following idiom I presume you are referring to,

Tcl_UtfToExternalDString(NULL,...,&ds);
CreateFileA(Tcl_Value(&ds)...);

can produce garbage file names as far back as 8.0. I don't know if it makes sense to add a compatibility note that says in effect "Use of ANSI API's continues to be broken in 9.0.2 ...".

As far as release notes, of course, an item will be added as it is user visible change. Manpages also need to be updated. There is nothing useful in the manpages currently about [encoding system] or the differences between platforms, or even between Windows versions, so that is something I intend to add irrespective of whether 716 passes or not.

CFV will be after all the above is done and we discuss the whole topic in the next online meet.

Thanks

/Ashok




________________________________
From: Jan Nijtmans
Sent: Monday, April 28, 2025 6:38 PM
To: Ashok Nadkarni
Cc: Tcl Core List
Subject: Re: [TCLCORE] TIP 716 ready for comments

Op ma 28 apr 2025 om 14:34 schreef Ashok Nadkarni:
> TL;DR use wide character API's to avoid these exact issues.

So, why isn't there a "Compatibility" section in the TIP describing
that starting with Tcl 9.0.2 the Windows ANSI API cannot be
used any more in the same way as in Tcl 8.6/9.0.0/9.0.1?

This should also be put in the Tcl 9.0.2 release notes, if
this TIP is accepted. If the majority is OK with this
breakage, I won't stand in the way.

              Jan Nijtmans


      Jan Nijtmans

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

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

I have some comments on TIP 715

OpenBSD is listed as untested - I suspect Stu might disagree with this :) And I test on a Debian derived distro (Armbian or Plebian) on aarch64.  There may well be others who test on FreeBSD, NetBSD and other systems. How can we formalise moving a platform out of the Untested to the Tested Platform list?

Also under Tested for Linux it states “Tested distributions are latest two versions of Ubuntu and Debian on x86_64.”  IMO that is not precise enough.  Does it meanthe  last two major versions, last two minor versions or last two LTS (long term support) versions or something else?   This page shows the Ubuntu lifecycle and release cadence https://ubuntu.com/about/release-cycle.  You’ll see there are LTS version every two years and those versions are supported in some form for 12 years each.    I don’t know the answer but I think we should discuss the topic.

-- Steve

Re: [TCLCORE] Tclvfs

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

+1 for 1.5.0
________________________________
From: Brian Griffin <bri...@ea...>
Sent: Tuesday, April 29, 2025 5:56 AM
To: Tcl List <tcl...@li...>
Subject: [TCLCORE] Tclvfs

There hasn’t been a release of tclvfs in a long time, unless I missed it.
Between Jan and myself, changes have been made that support the mixed Tcl9/Tcl8.6 environment. I’m thinking of doing a beta release. The question I have is should the version bump up from 1.4.2 to 1.4.3, or 1.5.0? (functionally there’s no change, afaict.)

-Brian
(from mobile device)
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

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

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

Hi All,

Requirements for Tcl/Tk 9.1: the 2038 problem.

The TIP proposes:

{
Where applicable, Tcl 9.1 requires
...
* C runtime / syscall with a 64 bit time_t structure to avoid the year
2038 Problem.
...
}

and also:

{
Obsolete platforms

The following platforms are explicitly marked as obsolete.
...
* Linux: 32-bit kernel versions prior to 5.6, released March 29, 2020.
...
}


The 2038 problem is painful, because despite plenty of warning, the
available fixes for 32-bit systems are embarrassingly recent.

The TIP proposes to obsolete 32-bit Linux kernel versions prior to 5.6
(released March 2020).  The reason is not given, but I guess it is
because these kernels lack system calls for 64-bit time.  I am not sure
that such obsolescence is necessary: if a host cannot handle the 2038
problem, there is no reason why a user should expect Tcl to have this
capability when running on that host.  Perhaps a warning could be
logged and also written to stderr whenever Tcl starts on a host that
has no system calls for 64-bit time, and also if commands such as
[clock], [file mtime] are used with inappropriate arguments or results.

The TIP also proposes a requirement for glibc >= 2.34, which is the
earliest version **ON 32-BIT SYSTEMS** that provides 64-bit time_t.
There is no problem with glibc on 64-bit systems, which has used 64-bit 
time as far back as glibc 2.0. On 32-bit systems running glibc 2.34,
compilation of glibc with 64-bit time_t is available but is **DISABLED
BY DEFAULT** for compatibility reasons - so a requirement for glibc
2.34 does not necessarily solve the problem: it will still be necessary
to test for the length of time_t.  Again, warnings could be emitted
rather than preventing the use of Tcl completely.

I suggest removing the mandatory requirement for 64-bit time_t,
replacing it with a recommendation, and if 64-bit time_t is not
available doing the best we can to either implement a workaround or
issue warnings.

Best wishes,

Keith.


On Tue, 2025-04-01 at 21:53 +0200, Harald Oehlmann wrote:
> Folks,
> TIP 715 was updated by the given information.
> 
> Thanks for any comment !
> 
> Harald
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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

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

Hi All,

I am a bit concerned about requiring a recent version of glibc (2.34,
released on 2021-08-02) for two reasons.  First, if 2.34-specific
features were actually used, Tcl/Tk 9.1 would become unusable on
systems with older glibc.  Second, many systems use gcc but not glibc,
and there is the risk of making Tcl/Tk 9.1 unusable on these systems
too.

>From the TIP:

{Where applicable, Tcl 9.1 requires

* C compiler supporting the mandatory features of the C11 standard,
* C runtime / syscall with a 64 bit time_t structure to avoid the
  year 2038 Problem.
* glibc >= 2.34 if using gcc
* POSIX.1-2008 API on non-Windows platforms (is this correct?)
* SDK 10.0.20348.0 (version 2104) or later on Windows (needed for
  updated C11 support in UCRT). MSVCRT is not supported due to C11
  requirements.
* X11 >= R6 in X Windows environments (Tk only**
* autoconf >= 2.72 when using autoconf based builds
}

It took some digging to try to understand the motivation for the glibc
proposal (I think it's 2038).  Would it be possible for the TIP to
explain the reasons for each non-obvious proposal?

I suggest removing the line that refers to glibc, and replacing it with
a statement of the features that the libc must support. These might be,
for example:

* C library that implements:
** POSIX.1-2008 API (Issue 7, 2008 version)
** the mandatory features of the C11 standard for libc
** a 64 bit time_t structure to avoid the year 2038 problem

I suggest replacing the time_t requirement with a recommendation, and
implementing a workaround if 64-bit time_t is not available: the reason
is that even with the current glibc, 64-bit time_t may or may not not
be present on 32-bit Linux systems.

The 2038 problem is painful, and I will attempt to discuss it in a
separate message.  

Apart from 64-bit time_t on 32-bit systems, the features listed above
are implemented by glibc 2.16 (released in June 2012).

My AI friend Grok 3 provides the following information (modulo
hallucinations):

Support for the mandatory parts of the C11 standard library was added
to the following platforms as follows:
* OpenBSD 5.3 (May 2012)
* glibc 2.16 (June 2012)
* FreeBSD 10.0 (January 2014)
* NetBSD 8.0 (July 2018)
* Solaris 11.4 (August 2018)

I am a bit surprised by the lateness of adoption by Solaris.  If the
information is correct, it is a reminder that even system software with
paying customers can be slow in adopting new standards.

Best wishes,

Keith.


On Tue, 2025-04-01 at 21:53 +0200, Harald Oehlmann wrote:
> Folks,
> TIP 715 was updated by the given information.
> 
> Thanks for any comment !
> 
> Harald
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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

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

Keith,
thanks. Proposal commited to TIP 715, including some clean-up.

Thanks,
Harald

Am 29.04.2025 um 01:18 schrieb Keith Nash:
> Hi All,
> 
> Suggestions for "untested" platforms:
> 
> - FreeBSD, NetBSD, OpenBSD on x86_64
> - Debian or its "Raspberry Pi OS" derivative on armv7l, aarch64
>    (ARM 32-bit, 64-bit)
> - Solaris on x86_64, sparc64
> - Any non-vintage Linux, BSD, or UNIX distribution on any
>    non-vintage hardware
> 
> The idea of the last one is not to raise false expectations, but to
> suggest that there is a good chance that Tcl/Tk will build and run on
> these platforms with no issues, and we would at least try to help
> anybody who reported any problems.
> 
> A few of these might qualify as "tested" platforms - e.g. if there is
> an established relationship with those who build the
> ports/pkgsrc/packages for the BSD distributions.
> 
> Best wishes,
> 
> Keith.
> 
> On Tue, 2025-04-01 at 21:53 +0200, Harald Oehlmann wrote:
>> Folks,
>> TIP 715 was updated by the given information.
>>
>> Thanks for any comment !
>>
>> Harald
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core


-- 
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] Tclvfs

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

> On 29 Apr 2025 at 11:01 AM +0800, Brian Griffin wrote:
>
> There hasn’t been a release of tclvfs in a long time, unless I missed it.
> Between Jan and myself, changes have been made that support the mixed Tcl9/Tcl8.6 environment. I’m thinking of doing a beta release. The question I have is should the version bump up from 1.4.2 to 1.4.3, or 1.5.0? (functionally there’s no change, afaict.)
>
> -Brian

I agree with Steve, I would go for 1.5.0 too. Even if there is no functional
change, the "working with 9.0" state is enough reason.

Thanks!
        Jan Nijtmans

Re: [TCLCORE] Tclvfs

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

I’d vote for 1.5.0 and leave the minor point releases for bug fixes only.

Just my 2c

-- Steve
On 29 Apr 2025 at 11:01 AM +0800, Brian Griffin <bri...@ea...>, wrote:
> There hasn’t been a release of tclvfs in a long time, unless I missed it.
> Between Jan and myself, changes have been made that support the mixed Tcl9/Tcl8.6 environment. I’m thinking of doing a beta release. The question I have is should the version bump up from 1.4.2 to 1.4.3, or 1.5.0? (functionally there’s no change, afaict.)
>
> -Brian
> (from mobile device)
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] Tclvfs

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

There hasn’t been a release of tclvfs in a long time, unless I missed it.  
Between Jan and myself, changes have been made that support the mixed Tcl9/Tcl8.6 environment. I’m thinking of doing a beta release. The question I have is should the version bump up from 1.4.2 to 1.4.3, or 1.5.0? (functionally there’s no change, afaict.)

-Brian
(from mobile device)

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

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

Hi All,

Suggestions for "untested" platforms:

- FreeBSD, NetBSD, OpenBSD on x86_64
- Debian or its "Raspberry Pi OS" derivative on armv7l, aarch64
  (ARM 32-bit, 64-bit)
- Solaris on x86_64, sparc64
- Any non-vintage Linux, BSD, or UNIX distribution on any
  non-vintage hardware

The idea of the last one is not to raise false expectations, but to
suggest that there is a good chance that Tcl/Tk will build and run on
these platforms with no issues, and we would at least try to help
anybody who reported any problems.

A few of these might qualify as "tested" platforms - e.g. if there is
an established relationship with those who build the
ports/pkgsrc/packages for the BSD distributions.

Best wishes,

Keith.

On Tue, 2025-04-01 at 21:53 +0200, Harald Oehlmann wrote:
> Folks,
> TIP 715 was updated by the given information.
> 
> Thanks for any comment !
> 
> Harald
> 
> _______________________________________________
> 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 ma 28 apr 2025 om 14:34 schreef Ashok Nadkarni:
> TL;DR use wide character API's to avoid these exact issues.

So, why isn't there a "Compatibility" section in the TIP describing
that starting with Tcl 9.0.2 the Windows ANSI API cannot be
used any more in the same way as in Tcl 8.6/9.0.0/9.0.1?

This should also be put in the Tcl 9.0.2 release notes, if
this TIP is accepted. If the majority is OK with this
breakage, I won't stand in the way.

              Jan Nijtmans


      Jan Nijtmans

Re: [TCLCORE] TIP 716 ready for comments

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

Jan,

You always have our attention but I am not sure about the converse!

I already commented on your test cases in Re: [TCLCORE] TIP 716 ready for comments | Tcl<https://sourceforge.net/p/tcl/mailman/message/59173666/> and how they needed to be written. Your response was that you were still experimenting. In any case, I have fixed your failing chmod tests. TL;DR use wide character API's to avoid these exact issues.

In particular, from the TIP (emphasized in the TIP itself):  For compatibility reasons, the Tcl_GetEncodingNameForUser function will not be public via stubs in 9.0.2 but will be public in 9.1.

Further attempts to clarify my preference for 716, as much as I have to hold my nose when proposing it ...

There are four transfer points at which encodings matter. Tcl core <-> Tcl extensions <->third party DLL's<->external applications.

In Tcl 8.6, all was hunky dory because all above components agreed on the encodings

[encoding system] == Tcl.GetACP() == OtherProcess.GetACP() (i.e. User's encoding in registry).

Both Tcl 9 and TIP 716 break this in slightly different ways.

In Tcl 9,

[encoding system] == Tcl.GetACP() == utf-8 (within the Tcl process only!) but Tcl.GetACP() != OtherProcess.GetACP().

This causes two forms of breakage. First, because Tcl.GetAcp() != OtherProcess.GetACP(), transfers to other applications breaks (e.g. Piping to Windows command line programs, database servers etc.). Second, because Tcl.GetACP() == utf8 applies to shared libraries, this breaks shared libraries that cannot handle UTF-8, e.g. GDI etc. (By shared libraries, I don't mean Tcl extensions but DLL's linked to Tcl or extensions that know nothing about Tcl.)

TIP 716 chooses a different mode of breakage!

[encoding system] == utf-8 (bad idea imo but required for Tcl 9 compatibility w.r.t. default channel encodings), BUT
[encoding system] != Tcl.GetACP() and instead Tcl.GetACP() == OtherProcess.GetACP().

Neither Tcl 9.0 nor 716 are optimal, unlike 8.6.

Why then do I prefer 716? Because with 716 the breaking points can be fixed within Tcl and Tcl extension code by switching to wide character API's or using Tcl encoding API's. It's all code within the control of the extension writer. My changes to your test cases above fall into this category. On the other hand, Tcl 9.0 behavior has the potential for issues like DB2 where the extension writer has *no recourse* other than his own tclsh build with the manifest removed. That in turn immediately makes the "modified" tclsh incompatible with "stock" tclsh (files written on the same system by one will be unreadable by the other) which is not a desirable thing. I would seriously consider withdrawing 716 if you can figure out how to fix the DB 2 kind of issue.

/Ashok




________________________________
From: Jan Nijtmans
Sent: Monday, April 28, 2025 12:45 PM
To: Harald Oehlmann
Cc: tcl...@li...
Subject: Re: [TCLCORE] TIP 716 ready for comments

Op vr 25 apr 2025 om 19:37 schreef Harald Oehlmann:
> P.S. I have retried my test with the updated branch. This does not make
> any difference (and should IMHO not). The result is ok and now, we have
> migration text ;-).

1) So, did you see the following test failures?
2) Does TIP #716 tell anything about this?

Hope I have your attention now ;-)
            Jan NIjtmans

P.S.: Github ACTIONS shows the same failure:
         <https://github.com/tcltk/tcl/actions/runs/14635843756/job/41066664724>

109==== cmdAH-16.2 Tcl_FileObjCmd: readable FAILED
110==== Contents of test case:
111file readable $gorpfile
112---- Test setup failed:
113D:\a\tcl\tcl\win\górp.file: no such file or directory
114---- errorInfo(setup): D:\a\tcl\tcl\win\górp.file: no such file or directory
115 while executing
116"testchmod 0o444 $gorpfile"
117 ("uplevel" body line 1)
118 invoked from within
119"uplevel 1 $setup"
120---- errorCode(setup): POSIX ENOENT {no such file or directory}
121==== cmdAH-16.2 FAILED
122
123
124
125==== cmdAH-17.2 Tcl_FileObjCmd: writable FAILED
126==== Contents of test case:
127file writable $gorpfile
128---- Test setup failed:
129D:\a\tcl\tcl\win\górp.file: no such file or directory
130---- errorInfo(setup): D:\a\tcl\tcl\win\górp.file: no such file or directory
131 while executing
132"testchmod 0o555 $gorpfile"
133 ("uplevel" body line 1)
134 invoked from within
135"uplevel 1 $setup"
136---- errorCode(setup): POSIX ENOENT {no such file or directory}
137==== cmdAH-17.2 FAILED
138
139
140
141==== cmdAH-17.3 Tcl_FileObjCmd: writable FAILED
142==== Contents of test case:
143file writable $gorpfile
144---- Test setup failed:
145D:\a\tcl\tcl\win\górp.file: no such file or directory
146---- errorInfo(setup): D:\a\tcl\tcl\win\górp.file: no such file or directory
147 while executing
148"testchmod 0o222 $gorpfile"
149 ("uplevel" body line 1)
150 invoked from within
151"uplevel 1 $setup"
152---- errorCode(setup): POSIX ENOENT {no such file or directory}
153==== cmdAH-17.3 FAILED
154
155cmdIL.test


_______________________________________________
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 ma 28 apr 2025 om 11:43 schreef Harald Oehlmann:
> That is great.
> If we need it, we need it.

Well, I would like the DB2 problem to be fixed too. TIP #716
describes a new function Tcl_GetEncodingNameForUser()
which could be of help fixing the testcases. So, I tried it:
       <https://core.tcl-lang.org/tcl/info/8a040c000aa41a0e>
It's on the TIP of the "tip-716" now. This demonstrates that
whatever function we use in testcases, the function needs
to be exported through the stub table.

Thinking further, a function returning the encoding _ name_
in itself is not so useful. It would be more useful to have
a function returning the Tcl_Encoding itself. If we want
the name only, we can always use Tcl_GetEncodingName().
That's my inspiration for TIP #718. ;-)  I think
"encoding name" in itself is useful.

Hope this helps,
       Jan Nijtmans

Re: [TCLCORE] TIP 716 ready for comments

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

Jan,
thank you for the information.
That is great.
If we need it, we need it.
Thanks,
Harald

Am 28.04.2025 um 09:15 schrieb Jan Nijtmans:
> Op vr 25 apr 2025 om 19:37 schreef Harald Oehlmann:
>> P.S. I have retried my test with the updated branch. This does not make
>> any difference (and should IMHO not). The result is ok and now, we have
>> migration text ;-).
> 
> 1) So, did you see the following test failures?
> 2) Does TIP #716 tell anything about this?
> 
> Hope I have your attention now ;-)
>              Jan NIjtmans
> 
> P.S.: Github ACTIONS shows the same failure:
>           <https://github.com/tcltk/tcl/actions/runs/14635843756/job/41066664724>
> 
> 109==== cmdAH-16.2 Tcl_FileObjCmd: readable FAILED
> 110==== Contents of test case:
> 111file readable $gorpfile
> 112---- Test setup failed:
> 113D:\a\tcl\tcl\win\górp.file: no such file or directory
> 114---- errorInfo(setup): D:\a\tcl\tcl\win\górp.file: no such file or directory
> 115 while executing
> 116"testchmod 0o444 $gorpfile"
> 117 ("uplevel" body line 1)
> 118 invoked from within
> 119"uplevel 1 $setup"
> 120---- errorCode(setup): POSIX ENOENT {no such file or directory}
> 121==== cmdAH-16.2 FAILED
> 122
> 123
> 124
> 125==== cmdAH-17.2 Tcl_FileObjCmd: writable FAILED
> 126==== Contents of test case:
> 127file writable $gorpfile
> 128---- Test setup failed:
> 129D:\a\tcl\tcl\win\górp.file: no such file or directory
> 130---- errorInfo(setup): D:\a\tcl\tcl\win\górp.file: no such file or directory
> 131 while executing
> 132"testchmod 0o555 $gorpfile"
> 133 ("uplevel" body line 1)
> 134 invoked from within
> 135"uplevel 1 $setup"
> 136---- errorCode(setup): POSIX ENOENT {no such file or directory}
> 137==== cmdAH-17.2 FAILED
> 138
> 139
> 140
> 141==== cmdAH-17.3 Tcl_FileObjCmd: writable FAILED
> 142==== Contents of test case:
> 143file writable $gorpfile
> 144---- Test setup failed:
> 145D:\a\tcl\tcl\win\górp.file: no such file or directory
> 146---- errorInfo(setup): D:\a\tcl\tcl\win\górp.file: no such file or directory
> 147 while executing
> 148"testchmod 0o222 $gorpfile"
> 149 ("uplevel" body line 1)
> 150 invoked from within
> 151"uplevel 1 $setup"
> 152---- errorCode(setup): POSIX ENOENT {no such file or directory}
> 153==== cmdAH-17.3 FAILED
> 154
> 155cmdIL.test

Re: [TCLCORE] TIP 716 ready for comments

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

Op vr 25 apr 2025 om 19:37 schreef Harald Oehlmann:
> P.S. I have retried my test with the updated branch. This does not make
> any difference (and should IMHO not). The result is ok and now, we have
> migration text ;-).

1) So, did you see the following test failures?
2) Does TIP #716 tell anything about this?

Hope I have your attention now ;-)
            Jan NIjtmans

P.S.: Github ACTIONS shows the same failure:
         <https://github.com/tcltk/tcl/actions/runs/14635843756/job/41066664724>

109==== cmdAH-16.2 Tcl_FileObjCmd: readable FAILED
110==== Contents of test case:
111file readable $gorpfile
112---- Test setup failed:
113D:\a\tcl\tcl\win\górp.file: no such file or directory
114---- errorInfo(setup): D:\a\tcl\tcl\win\górp.file: no such file or directory
115 while executing
116"testchmod 0o444 $gorpfile"
117 ("uplevel" body line 1)
118 invoked from within
119"uplevel 1 $setup"
120---- errorCode(setup): POSIX ENOENT {no such file or directory}
121==== cmdAH-16.2 FAILED
122
123
124
125==== cmdAH-17.2 Tcl_FileObjCmd: writable FAILED
126==== Contents of test case:
127file writable $gorpfile
128---- Test setup failed:
129D:\a\tcl\tcl\win\górp.file: no such file or directory
130---- errorInfo(setup): D:\a\tcl\tcl\win\górp.file: no such file or directory
131 while executing
132"testchmod 0o555 $gorpfile"
133 ("uplevel" body line 1)
134 invoked from within
135"uplevel 1 $setup"
136---- errorCode(setup): POSIX ENOENT {no such file or directory}
137==== cmdAH-17.2 FAILED
138
139
140
141==== cmdAH-17.3 Tcl_FileObjCmd: writable FAILED
142==== Contents of test case:
143file writable $gorpfile
144---- Test setup failed:
145D:\a\tcl\tcl\win\górp.file: no such file or directory
146---- errorInfo(setup): D:\a\tcl\tcl\win\górp.file: no such file or directory
147 while executing
148"testchmod 0o222 $gorpfile"
149 ("uplevel" body line 1)
150 invoked from within
151"uplevel 1 $setup"
152---- errorCode(setup): POSIX ENOENT {no such file or directory}
153==== cmdAH-17.3 FAILED
154
155cmdIL.test

Re: [TCLCORE] TIP 716 ready for comments

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

Am 26.04.2025 um 00:12 schrieb Jan Nijtmans:
> Op vr 25 apr 2025 om 16:06 schreef Ashok Nadkarni <apn...@ya...>:
>>
>> And other posts on the same (DB2 drivers not supporting UTF-8) - SQLAllocHandle of the driver on SQL_HANDLE_ENV failed when connecting to IBM-DB2 database - MATLAB Answers - MATLAB Central and windows - DB2 service does not start - Stack Overflow
> 
> Those posts tell me something. First, compare the story with this Tcl ticket:
>      <https://core.tcl-lang.org/tcl/info/0b9332722a>
> Tcl had the same problem 5 years ago. It got the ACP value, prepended it
> with "cp" and then used it as an encoding name. There is no "cp65001"
> encoding, it should be handled as "utf-8".
> 
> My guess is that the IBM dll does the same thing. No surprise
> the initialisation fails. They really should fix this bug, it shouldn't
> be difficult. Is it already reported to them? The DB2 dll
> simply doesn't work in any utf-8 environment.
> 
> Does that make sense?
> 
>          Jan Nijtmans
> 
Dear Jan,
indeed, it might be the same issue related to the ticket, who knows.
The magic manifest key is a partial work-around for programs using the 8 
bit Windows API. It was introduced in Windows 10.
It only affects the ANSI/char/MCBS Windows API which is superseeded 
since 1993 by the wide Windows API.

What does this workaround do:
- switch some (not all) ANSI API functions from the local encoding 
(cp1252 in Western Europe) to use UTF-8 as char encoding
- switch the reporting of the native codepage
- as the manifest is in the exe, it applies to all loaded DLLs

Unfortunately, this breaks a lot of legacy DLLs. They are not fixed as 
the source code or maintainer is not available.
In addition, there is no reason to fix. The DLLs work.

The upper workaround is only useful (if for any case), if a small 
application with only WinAPI dependencies should be easily ported.

It is not useful for TCL as it breaks legacy DLLs.
There is no useful application, as TCL uses the wide Windows API.

Ashok gets a bit nerved, as this was changed without a TIP.
Here, I am not his opinion. The intention was clear and when reading 
from it, I was initialy also in favor: Unicode? Yes, we want it.
Now, we are wiser and we should revert this change.
Ashok goes the formal way by a TIP, what is noble.
IMHO, it could just be reverted as a not valid bugfix.

I really appreciate all your work.
But putting energy in here is IMHO lost and may better be investigated 
in the great three tickets by Christian ;-).

Thanks for all and take care,
Harald

Re: [TCLCORE] TIP 716 ready for comments

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

Op vr 25 apr 2025 om 16:06 schreef Ashok Nadkarni <apn...@ya...>:
>
> And other posts on the same (DB2 drivers not supporting UTF-8) - SQLAllocHandle of the driver on SQL_HANDLE_ENV failed when connecting to IBM-DB2 database - MATLAB Answers - MATLAB Central and windows - DB2 service does not start - Stack Overflow

Those posts tell me something. First, compare the story with this Tcl ticket:
    <https://core.tcl-lang.org/tcl/info/0b9332722a>
Tcl had the same problem 5 years ago. It got the ACP value, prepended it
with "cp" and then used it as an encoding name. There is no "cp65001"
encoding, it should be handled as "utf-8".

My guess is that the IBM dll does the same thing. No surprise
the initialisation fails. They really should fix this bug, it shouldn't
be difficult. Is it already reported to them? The DB2 dll
simply doesn't work in any utf-8 environment.

Does that make sense?

        Jan Nijtmans

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:
>> 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 migration page is now extended by the change of the MS-Windows 
system encoding:

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

and the deprecated Tcl_Winxxx functions:

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

I try to use full examples. The Tcl_Winxxx functions were never fully 
documented. I hope, this works.

About TIP 548:
https://core.tcl-lang.org/tips/doc/trunk/tip/548.md

I am hesitant to document more. Basically, I don't understand the text.
Or it is incomplete. The type "wchar_t" is 16 bit on Windows, but may be 
another size on other platforms. But this is a platform issue, not a TCL 
issue.
I am also not happy by the word "utf-8". Here, not the utf-8 encoding is 
ment, but the TCL variant replacing the 0 Codepoint. Or is this not the 
case, e.g. the functions may not handle 0 bytes.
Also, there is nothing written about eventual surrogates for the 16 bit 
functions.

More questions than answers as usual....

Thanks for all,
Harald

P.S. I have retried my test with the updated branch. This does not make 
any difference (and should IMHO not). The result is ok and now, we have 
migration text ;-).