tcl-core

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

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

All,

 

Even after the discussions in the last meet-up, I'm struggling to progress
on TIP 715 due to a lack of clarity in my own mind with regards to platform
support definitions, requirements and the rest.

 

If someone wants to take it over and drive it, please let me know (Harald, I
noticed you had made some updates that seem reasonable).

 

Otherwise, I plan to withdraw the TIP.

 

/Ashok

 

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Thursday, March 13, 2025 5:23 PM
To: tcl...@li...
Subject: [TCLCORE] TIP 715 - Supported platforms and build environments for
Tcl/Tk 9.1

 

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.

 

Please review and fill in the ???  for the platforms you are familiar with.
Or (less preferable) comment here in the mailing list.

 

Note as per the discussion, the TIP also proposes C11 as a requirement for
9.1. I am neutral / ambivalent on that and also not sure if it should be
included in this particular TIP.

 

/Ashok

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

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

Op problem, I will take over.

Thanks for all the work,
Harald

Am 29.03.2025 um 07:34 schrieb apnmbx-public--- via Tcl-Core:
> All,
> 
> Even after the discussions in the last meet-up, I’m struggling to 
> progress on TIP 715 due to a lack of clarity in my own mind with regards 
> to platform support definitions, requirements and the rest.
> 
> If someone wants to take it over and drive it, please let me know 
> (Harald, I noticed you had made some updates that seem reasonable).
> 
> Otherwise, I plan to withdraw the TIP.
> 
> /Ashok
> 
> *From:*apnmbx-public--- via Tcl-Core <tcl...@li...>
> *Sent:* Thursday, March 13, 2025 5:23 PM
> *To:* tcl...@li...
> *Subject:* [TCLCORE] TIP 715 - Supported platforms and build 
> environments for Tcl/Tk 9.1
> 
> 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 <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.
> 
> Please review and fill in the ???  for the platforms you are familiar 
> with. Or (less preferable) comment here in the mailing list.
> 
> Note as per the discussion, the TIP also proposes C11 as a requirement 
> for 9.1. I am neutral / ambivalent on that and also not sure if it 
> should be included in this particular TIP.
> 
> /Ashok
> 
> 
> 
> _______________________________________________
> 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 715 - Supported platforms and build environments for Tcl/Tk 9.1

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

Thanks much, Harald.

/Ashok

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Saturday, March 29, 2025 4:59 PM
To: tcl...@li...
Subject: Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

Op problem, I will take over.

Thanks for all the work,
Harald

Am 29.03.2025 um 07:34 schrieb apnmbx-public--- via Tcl-Core:
> All,
> 
> Even after the discussions in the last meet-up, I’m struggling to 
> progress on TIP 715 due to a lack of clarity in my own mind with regards 
> to platform support definitions, requirements and the rest.
> 
> If someone wants to take it over and drive it, please let me know 
> (Harald, I noticed you had made some updates that seem reasonable).
> 
> Otherwise, I plan to withdraw the TIP.
> 
> /Ashok
> 
> *From:*apnmbx-public--- via Tcl-Core <tcl...@li...>
> *Sent:* Thursday, March 13, 2025 5:23 PM
> *To:* tcl...@li...
> *Subject:* [TCLCORE] TIP 715 - Supported platforms and build 
> environments for Tcl/Tk 9.1
> 
> 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 <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.
> 
> Please review and fill in the ???  for the platforms you are familiar 
> with. Or (less preferable) comment here in the mailing list.
> 
> Note as per the discussion, the TIP also proposes C11 as a requirement 
> for 9.1. I am neutral / ambivalent on that and also not sure if it 
> should be included in this particular TIP.
> 
> /Ashok
> 
> 
> 
> _______________________________________________
> 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 715 - Supported platforms and build environments for Tcl/Tk 9.1

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

Folks,
TIP 715 was updated by the given information.

Thanks for any comment !

Harald

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

[TCLCORE] The -blockcursor option of text widgets

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

Dear fellow readers of the core mailing list,

after some playing with the text widget's -blockcursor option my conclusion
is unfortunately, that it is almost unusable when turned on, at least when
the default options of the text widget are in place, which is a very common
use case.

Rationale: the block cursor in its active state (INSERT_ON) draws a rectangle
in the text widget's foreground color. Following that drawing the text is drawn
in the text widget's foreground color resulting in a rectangle in the text
widget's foreground color, i.e.  without any information which was in place
when the widget/cursor was in inactive (INSERT_OFF) state. This makes the
block cursor indefinitely hiding the character under the cursor when the
-insertofftime option is set to zero. Bluntly, the "-blockcursor 1" option
is not usable at all since it's invention, BTW this was in 2003.

Here is a POC how it can be remedied:

---8><---
--- old/tkTextDisp.c
+++ new/tkTextDisp.c
@@ -15,6 +15,7 @@
  
  #include "tkInt.h"
  #include "tkText.h"
+#include "tk3d.h"
  
  #if defined(_WIN32) && !defined(PLATFORM_SDL)
  #include "tkWinInt.h"
@@ -2444,10 +2445,13 @@
  				 * must make sure it's large enough to hold
  				 * line. */
  {
-    TkTextDispChunk *chunkPtr;
+    TkTextDispChunk *chunkPtr, tmpChunk, *otherChunkPtr = NULL;;
      TextDInfo *dInfoPtr = textPtr->dInfoPtr;
      Display *display;
      int height, y_off;
+    struct TextStyle tmpStyle;
+    TkBorder *borderPtr;
+    CharInfo ci;
  #ifndef TK_NO_DOUBLE_BUFFERING
      const int y = 0;
  #else
@@ -2539,6 +2543,38 @@
  	     * here.
  	     */
  
+	    if (textPtr->insertCursorType &&
+		    ((textPtr->flags & (GOT_FOCUS | INSERT_ON)) ==
+			(GOT_FOCUS | INSERT_ON)) &&
+		    (chunkPtr->nextPtr != NULL) &&
+		    (chunkPtr->nextPtr->displayProc == CharDisplayProc) &&
+		    (chunkPtr->nextPtr->numBytes > 0)) {
+		/*
+		 * Make a temporary chunk for displaying the text
+		 * within the block cursor later on.
+		 */
+
+		otherChunkPtr = &tmpChunk;
+		*otherChunkPtr = *(chunkPtr->nextPtr);
+		otherChunkPtr->undisplayProc = NULL;
+		otherChunkPtr->numBytes = 1;
+		tmpStyle = *otherChunkPtr->stylePtr;
+		otherChunkPtr->stylePtr = &tmpStyle;
+		tmpStyle.bgGC = None;
+		borderPtr = (TkBorder *) textPtr->border;
+		tmpStyle.fgGC = borderPtr->bgGC;
+		ci = *((CharInfo *) (otherChunkPtr->clientData));
+		otherChunkPtr->clientData = (ClientData) &ci;
+		ci.numBytes = 1;
+		if ((ci.chars[0] == '\n') ||
+			(ci.chars[0] == ' ') || (ci.chars[0] == '\t')) {
+		    /*
+		     * Ignore newline and other whitespace.
+		     */
+
+		    otherChunkPtr = NULL;
+		}
+	    }
  	    continue;
  	}
  
@@ -2569,6 +2605,28 @@
  		    display, pixmap, dlPtr->y + dlPtr->spaceAbove);
  	}
  
+	if ((otherChunkPtr != NULL) && (textPtr->tkwin != NULL) &&
+		!(textPtr->flags & DESTROYED)) {
+	    /*
+	     * Draw text within the block cursor.
+	     */
+
+	    int x = otherChunkPtr->x + dInfoPtr->x - dInfoPtr->curXPixelOffset;
+
+	    if ((x + otherChunkPtr->width <= 0) || (x >= dInfoPtr->maxX)) {
+		/*
+		 * See note above.
+		 */
+
+		x = -otherChunkPtr->width;
+	    }
+	    otherChunkPtr->displayProc(textPtr, otherChunkPtr, x,
+		    y + dlPtr->spaceAbove, dlPtr->height - dlPtr->spaceAbove -
+		    dlPtr->spaceBelow, dlPtr->baseline - dlPtr->spaceAbove,
+		    display, pixmap, dlPtr->y + dlPtr->spaceAbove);
+	    otherChunkPtr = NULL;
+	}
+
  	if ((textPtr->tkwin == NULL) || (textPtr->flags & DESTROYED)) {
  	    /*
  	     * A displayProc called in the loop above invoked a binding
---8><---

I've tested it in an X11 environment. No idea if this works in Win32 or MacOS.

Cheers,
Christian

Re: [TCLCORE] The -blockcursor option of text widgets

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

On 04/01/2025 10:25 PM, Christian Werner wrote:

> after some playing with the text widget's -blockcursor option my conclusion…

I should have admitted, that the POC patch is not ideal, since it leaves
artefacts of the double drawing of the character under the cursor due to
antialiasing, when the xft font rendering is in effect.

Nevertheless, it gives a more natural feedback resembling a good old vi
in a good old terminal. And wasn't that the original intention and means
of existence of the block cursor option?

BR,
Christian

Re: [TCLCORE] The -blockcursor option of text widgets

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

On 04/01/2025 10:57 PM, Christian Werner wrote:

> …
> Nevertheless, it gives a more natural feedback resembling a good old vi
> in a good old terminal. And wasn't that the original intention and means
> of existence of the block cursor option?

Meanwhile the patch evolved to work on Windows and MacOS, too, see

   https://www.androwish.org/home/info/b8894bb57964415f

Cheers,
Christian

Re: [TCLCORE] The -blockcursor option of text widgets

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

On 04/02/2025 08:56 PM, Christian Werner wrote:

> …
> Meanwhile the patch evolved to work on Windows and MacOS, too, see
>
>   https://www.androwish.org/home/info/b8894bb57964415f

Some more iterations later the patch is now in a branch in the
Tk repo thanks to Harald, who followed it closely and tested
especially on Win32.

 From my point of view, the block cursor now is working, although
the code of the patch is still debatable and possibly could be
improved and/or simplified.

However, some concerns regarding Tk came up, which can be read in
the comments to ticket https://core.tcl-lang.org/tk/info/5d0bc3cf

My conclusions so far:

* Most likely, the block cursor is fine on MacOS, so please test.

   No actions needed on this platform, hopefully.

* On X11 and Win32 TIP#621 is in the way: it implements run-time
   linking of ICU for determining bounds of glyph clusters among
   other features. And Tk 9.x uses these functions for navigating
   e.g. by cursor keys through the chars in a text widget. However,
   since both, X11 and Win32 font rendering isn't glyph cluster
   aware at all, this leads to rather ugly behavior which Harald
   documented in the ticket.

   Action required: it must be decided, if tk::startOfCluster and
   tk::endOfCluster with ICU backing is to be used in Tk's text
   widget or not. If not, the block cursor will be fine. If it
   shall be used, the whole complexity of char measurement in the
   guts of Tk must be improved to take glyph clustering into
   account when measuring the pixel widths of char sequences.

Cheers,
Christian

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

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

Harald,

Thanks again for taking up 715.

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

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

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

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

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

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


/Ashok

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

Folks,
TIP 715 was updated by the given information.

Thanks for any comment !

Harald

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

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

Thanks Ashok, great.

We may discuss this in the telco of today.

Take care,
Harald

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


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

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

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

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

Hi all,

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

See you
        Jan Nijtmans

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

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

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

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

I had originally suggested the two developer requirement. My thought at the time was that any future enhancement on the platform, such as TIP 458 on *ix or some future support of IOCP on Windows, would have at least one reviewer with competency on that platform, as well as someone who could fix related bugs in case of unavailability of the original implementor for whatever reason.

The TIP is now focused on what is tested for a release rather than future development. In that case, the developer requirement could be dropped completely. As long as someone signs up to test a platform before release, that should suffice as a tested platform for that release.

/Ashok
________________________________
From: Steve Landers <st...@di...>
Sent: Wednesday, April 30, 2025 2:43 PM
To: apn...@ya... <apn...@ya...>; tcl...@li... <tcl...@li...>
Cc: Pietro Cerutti <ga...@ga...>
Subject: Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

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

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

I think, the main point is a maintainer, which commits to test releases 
and to check failure tickets.

I have changed the TIP in this way and propose a wiki page with maintainers.

Is this a good idea?

About the time_t 64 bit, I did not do any modifications. For me, the 
post had to many "may" like "a warning may be issued". Is this warning 
implemented? Or shall a warning be required?
I have no opinion on Linux and understand that it is a very moving 
target. It may disqualify small platforms like controllers which 
eventually do not have a RTC at all and the time is irrelevant.

Thanks for all,
Harald

Am 01.05.2025 um 04:41 schrieb Ashok Nadkarni via Tcl-Core:
> I had originally suggested the two developer requirement. My thought at 
> the time was that any future enhancement on the platform, such as TIP 
> 458 on *ix or some future support of IOCP on Windows, would have at 
> least one reviewer with competency on that platform, as well as someone 
> who could fix related bugs in case of unavailability of the original 
> implementor for whatever reason.
> 
> The TIP is now focused on what is tested for a release rather than 
> future development. In that case, the developer requirement could be 
> dropped completely. As long as someone signs up to test a platform 
> before release, that should suffice as a tested platform for that release.
> 
> /Ashok
> ------------------------------------------------------------------------
> *From:* Steve Landers <st...@di...>
> *Sent:* Wednesday, April 30, 2025 2:43 PM
> *To:* apn...@ya... <apn...@ya...>; tcl- 
> co...@li... <tcl...@li...>
> *Cc:* Pietro Cerutti <ga...@ga...>
> *Subject:* Re: [TCLCORE] TIP 715 - Supported platforms and build 
> environments for Tcl/Tk 9.1
> 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- 
> co...@li...>, wrote:
>> On Mar 13 2025, 11:53 +0000, apnmbx-public--- via Tcl-Core <tcl- 
>> co...@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 

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

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

On 2 May 2025 at 2:17 PM +0800, Harald Oehlmann <har...@el...>, wrote:

> I think, the main point is a maintainer, which commits to test releases
> and to check failure tickets.
>
> I have changed the TIP in this way and propose a wiki page with maintainers.
>
> Is this a good idea?
Yes, but let’s do it now instead of waiting for 9.1

-- Steve

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

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

Am 02.05.2025 um 11:53 schrieb Steve Landers:
> On 2 May 2025 at 2:17 PM +0800, Harald Oehlmann 
> <har...@el... <mailto:har...@el...>>, wrote:
> 
>     I think, the main point is a maintainer, which commits to test releases
>     and to check failure tickets.
> 
>     I have changed the TIP in this way and propose a wiki page with
>     maintainers.
> 
>     Is this a good idea?
> 
> Yes, but let’s do it now instead of waiting for 9.1
> 
> -- Steve

As the TIP defines primary the supported platforms and build systems for 
9.1, I would leave this for 9.1.

I would say, that the listed maintainers are not limited to 9.1, but for 
all supported versions.
Is this ok?

Thanks,
Harald

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

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

I think the wiki page adds value. Let’s see what others think.

-- Steve
On 2 May 2025 at 6:02 PM +0800, Harald Oehlmann <har...@el...>, wrote:
> Am 02.05.2025 um 11:53 schrieb Steve Landers:
> > On 2 May 2025 at 2:17 PM +0800, Harald Oehlmann
> > <har...@el... <mailto:har...@el...>>, wrote:
> >
> > I think, the main point is a maintainer, which commits to test releases
> > and to check failure tickets.
> >
> > I have changed the TIP in this way and propose a wiki page with
> > maintainers.
> >
> > Is this a good idea?
> >
> > Yes, but let’s do it now instead of waiting for 9.1
> >
> > -- Steve
>
> As the TIP defines primary the supported platforms and build systems for
> 9.1, I would leave this for 9.1.
>
> I would say, that the listed maintainers are not limited to 9.1, but for
> all supported versions.
> Is this ok?
>
> Thanks,
> 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,

1. MAINTAINERS

On a different aspect of maintenance: the default assignees for Tcl
tickets could be updated.  The aim is that when a ticket is created, an
email is sent to an appropriate person.

I volunteer to be the default assignee for these Tcl categories:

[29] http Package
[33] Safe Base

If the ticket is more appropriate for somebody else (e.g. DKF for
cookies in [29], namespace ensembles in [33]) I will redirect the
ticket to them.

2. 2038 and 64-bit time_t

My main concern is to not make non-compliant systems unusable (yet). 
We have 13 years until the 2038 rollover, and for comparison we did not
decide to eliminate all Y2K-non-compliant systems as early as 1987.

I do not mind if the language is changed to avoid "may".

I suggest the following for Tcl/Tk on Linux/UNIX/BSD systems:

{
After 2033-01-01, Tcl 9.1 must write a warning to the system log and to
stderr whenever Tcl starts, and also if commands such as [clock], [file
mtime] are called with arguments corresponding to negative time_t or
return a result with this property, in the following circumstances:

* On a host that has no system calls for 64-bit time (e.g. 32-bit Linux
kernels earlier than 5.6)

* On a system on which the length of time_t has been tested and found
to be 32-bit (N.B. even a libc that is nominally compliant may have
been built with a compatibility option to use 32-bit time_t).

* On a system on which a 64-bit time operation has been tested at
startup and has failed (e.g. creating a file and changing its mtime to
a date in 2040).

We shall review this policy in 2032.
}

It is clearly a good thing to start thinking early about 2038, but I
hope that we do not yet need to exclude systems that use glibc older
than 2.34, or a 32-bit Linux kernel older than 5.6: the age of suchsystems can be less than four years or five years respectively.

Best wishes,

Keith.


On Fri, 2025-05-02 at 08:15 +0200, Harald Oehlmann wrote:
> I think, the main point is a maintainer, which commits to test
> releases 
> and to check failure tickets.
> 
> I have changed the TIP in this way and propose a wiki page with
> maintainers.
> 
> Is this a good idea?
> 
> About the time_t 64 bit, I did not do any modifications. For me, the 
> post had to many "may" like "a warning may be issued". Is this
> warning 
> implemented? Or shall a warning be required?
> I have no opinion on Linux and understand that it is a very moving 
> target. It may disqualify small platforms like controllers which 
> eventually do not have a RTC at all and the time is irrelevant.
> 
> Thanks for all,
> 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...>]

Am 03.05.2025 um 01:53 schrieb Keith Nash:
> After 2033-01-01, Tcl 9.1 must write a warning to the system log and to
> stderr whenever Tcl starts, and also if commands such as [clock], [file
> mtime] are called with arguments corresponding to negative time_t or
> return a result with this property, in the following circumstances:
> 
> * On a host that has no system calls for 64-bit time (e.g. 32-bit Linux
> kernels earlier than 5.6)
> 
> * On a system on which the length of time_t has been tested and found
> to be 32-bit (N.B. even a libc that is nominally compliant may have
> been built with a compatibility option to use 32-bit time_t).
> 
> * On a system on which a 64-bit time operation has been tested at
> startup and has failed (e.g. creating a file and changing its mtime to
> a date in 2040).

Dear Keith,
thanks for volontaring to maintain, that is highly appreciated.
I have removed the 32 bit time_t requirement to 9.1.
I see also those points to make the code easier and to remove code for 
32 bit and 64 bit. If it is not the moment, that is ok.
I have put your text for a future version of TCL, as 9.1 will probably 
out of maintenance in 2033.

Dear Steve,
thanks for your contribution about tested Linux systems.
Could you correct the list?

Dear Pietro,
can you give me some wordings to describe the "FreeBSD" ? I have never 
heard this system, sorry. Is this the same as "BSD" ? Well, stupid 
questions, sorry. Or "Debian" ? My Proxmox server is running "Debian", 
another mystic Linux variant...
Do I need a version/platform with "FreeBSD", like Arm64 or 12.0 ?
Or can you directly correct the TIP?

Thanks for all,
Harald