tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Confusion around TCL_WIDE_INT_IS_LONG in Tcl 8 vs Tcl 9

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

Hi Ashok,
that looks interesting. What I read from the TIP, the correct the check 
would be:

#if defined(TCL_WIDE_INT_IS_LONG) && TCL_WIDE_INT_IS_LONG = 1

It would be great to mention this in the migration notes.
In Tcl 9:
-> Tcl_WideInt is now always "long long".
define "TCL_WIDE_INT_IS_LONG" is always 0.

Thanks,
Harald

Am 28.11.2024 um 11:27 schrieb apnmbx-public--- via Tcl-Core:
> Thanks for the link, Jan. I haven’t used TCL_WIDE_INT_IS_LONG before but 
> was intending to use it as follows so the appropriate built-in is called 
> in both 8.6 and 9.0 for all platforms.
> 
> Tcl_WideInt a, b, result;
> 
> int status;
> 
> #ifdef TCL_WIDE_INT_IS_LONG
> 
>      status = __builtin_saddl_overflow(a, b, &result);
> 
> #else
> 
>      status = __builtin_saddll_overflow(a, b, &result);
> 
> #endif
> 
> I’ve modified it now to be
> 
> #if TCL_MAJOR_VERSION < 9 && defined(TCL_WIDE_INT_IS_LONG)
> 
> Not ideal, suggestions for better approaches appreciated.
> 
> /Ashok
> 
> *From:*Jan Nijtmans <jan...@gm...>
> *Sent:* Thursday, November 28, 2024 2:11 PM
> *To:* apn...@ya...
> *Cc:* tcl...@li...
> *Subject:* Re: [TCLCORE] Confusion around TCL_WIDE_INT_IS_LONG in Tcl 8 
> vs Tcl 9
> 
>     Could someone clarify - Is this difference between Tcl 8 and 9
>     intentional? What is the purpose of the TCL_WIDE_INT_IS_LONG 
>     #define if not to indicate which Tcl_WideInt typedef was in effect?
>     How else can I detect whether to call the “long” version or “long
>     long” of a runtime function for Tcl_WideInt values?
> 
> Tcl Improvement Proposals: TIP 476: Scan/Printf format consistency 
> <https://core.tcl-lang.org/tips/doc/trunk/tip/476.md>
> 
> Lessons:
> 
>     - don't use 'long', everything you do with it needs to be tested on 
> both 32 and 64-bit platforms
> 
>     - In Tcl 9 - eventually - all uses of Tcl_WideInt can simply be 
> replaced with 'long long'
> 
> TCL_WIDE_INT_IS_LONG should be interpreted as
> 
>       TCL_WIDE_INT_HAS_SAME_SIZE_AS_LONG
> 
> But better, don't use it any more
> 
> Hope this helps,
> 
>             Jan 

Re: [TCLCORE] Confusion around TCL_WIDE_INT_IS_LONG in Tcl 8 vs Tcl 9

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

Thanks for the link, Jan. I haven’t used TCL_WIDE_INT_IS_LONG before but was intending to use it as follows so the appropriate built-in is called in both 8.6 and 9.0 for all platforms.

 

Tcl_WideInt a, b, result;

int status;

#ifdef TCL_WIDE_INT_IS_LONG

    status = __builtin_saddl_overflow(a, b, &result);

#else

    status = __builtin_saddll_overflow(a, b, &result);

#endif

 

I’ve modified it now to be

 

#if TCL_MAJOR_VERSION < 9 && defined(TCL_WIDE_INT_IS_LONG)

 

Not ideal, suggestions for better approaches appreciated.

 

/Ashok

 

 

From: Jan Nijtmans <jan...@gm...> 
Sent: Thursday, November 28, 2024 2:11 PM
To: apn...@ya...
Cc: tcl...@li...
Subject: Re: [TCLCORE] Confusion around TCL_WIDE_INT_IS_LONG in Tcl 8 vs Tcl 9

 

Could someone clarify - Is this difference between Tcl 8 and 9 intentional? What is the purpose of the TCL_WIDE_INT_IS_LONG  #define if not to indicate which Tcl_WideInt typedef was in effect? How else can I detect whether to call the “long” version or “long long” of a runtime function for Tcl_WideInt values?

 

Tcl Improvement Proposals: TIP 476: Scan/Printf format consistency <https://core.tcl-lang.org/tips/doc/trunk/tip/476.md> 

 

Lessons:

   - don't use 'long', everything you do with it needs to be tested on both 32 and 64-bit platforms

   - In Tcl 9 - eventually - all uses of Tcl_WideInt can simply be replaced with 'long long'

 

TCL_WIDE_INT_IS_LONG should be interpreted as

     TCL_WIDE_INT_HAS_SAME_SIZE_AS_LONG

 

But better, don't use it any more

 

Hope this helps,

           Jan Nijtmans

 

Re: [TCLCORE] Confusion around TCL_WIDE_INT_IS_LONG in Tcl 8 vs Tcl 9

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

>
> Could someone clarify - Is this difference between Tcl 8 and 9
> intentional? What is the purpose of the TCL_WIDE_INT_IS_LONG  #define if
> not to indicate which Tcl_WideInt typedef was in effect? How else can I
> detect whether to call the “long” version or “long long” of a runtime
> function for Tcl_WideInt values?
>

Tcl Improvement Proposals: TIP 476: Scan/Printf format consistency
<https://core.tcl-lang.org/tips/doc/trunk/tip/476.md>

Lessons:
   - don't use 'long', everything you do with it needs to be tested on both
32 and 64-bit platforms
   - In Tcl 9 - eventually - all uses of Tcl_WideInt can simply be replaced
with 'long long'

TCL_WIDE_INT_IS_LONG should be interpreted as
     TCL_WIDE_INT_HAS_SAME_SIZE_AS_LONG

But better, don't use it any more

Hope this helps,
           Jan Nijtmans

Re: [TCLCORE] Proposal for my contribution to Tk, request for comments

[Erik L. <el...@xs...>]

OK. Thanks.

Erik.
--

On 11/28/24 07:52 , Francois Vogel wrote:
> Le 27/11/2024 à 23:44, Erik Leunissen a écrit :
>> Would you like me to report back here when that moment arrives (in 
>> order to create an
>>     appropriate branch in the Fossil Tk repository) ?
>
> That's up to you, you could get feedback.
>
> Right now I gave you developer (write) access to the Tk repository. If 
> you need help with fossil just ask.
>
> Regards,
>
> Francois
>
>

Re: [TCLCORE] TIP 705 - Affirm Tcl License

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

On Nov 27 2024, 20:52 +0000, Andreas Kupries <and...@gm...> wrote:
>
>> On 11/27/24 05:53, msc...@po... wrote:
>> > Hi,
>> >
>> > the Tcl/Tk license is also listed in the https://spdx.org/licenses/
>> > list at https://spdx.org/licenses/preview/TCL.html, which is commonly
>> > used for Software Bills of Materials to annotate code used and for
>> > license checking tooling.
>> >
>> > If we discuss alternative licenses to be allowed, i would highly
>> > recommend to use the SPDX identifiers to identify such licenses cleanly.
>>
>> I strong urge the acceptance of *TIP 705* */_AS IS_/* and not to start
>> down the slippery slope of allowing other licenses.
>
>Hello Gerald, glad to hear that you are still with us.
>
>I do not read Michael's mail as proposal to change the TIP.
>I believe that his sentence about alternative licenses refers to
>the second sentence of the rationale, i.e.:
>
>    > Should anyone seek to include code under a different license
>    > than the original Tcl license in a Tcl community repository,
>    > please submit that license as a separate TIP to be reviewed and
>    > voted on by the TCT.
>
>I would agree that using such official identifiers would be helpful.
>
>I further believe that it would be helpful to integrate the url
>
>	https://spdx.org/licenses/preview/TCL.html
>
>as a reference into the Abstract. Easier to follow than having to dig
>out the `license.terms` file. Actually, not a good argument, given
>that we would could use
>
>	https://core.tcl-lang.org/tcl/file?name=license.terms&ci=adbae584a7045f19
>
>However the SPDX link might be more useful/official to legal types.
>Third hand, maybe both links ?

I guess the canonical reference (also mentioned by SPDX) would be:
http://www.tcl.tk/software/tcltk/license.html

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

Re: [TCLCORE] Proposal for my contribution to Tk, request for comments

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

Le 27/11/2024 à 23:44, Erik Leunissen a écrit :
> Would you like me to report back here when that moment arrives (in 
> order to create an
>     appropriate branch in the Fossil Tk repository) ?

That's up to you, you could get feedback.

Right now I gave you developer (write) access to the Tk repository. If 
you need help with fossil just ask.

Regards,

Francois

[TCLCORE] Confusion around TCL_WIDE_INT_IS_LONG in Tcl 8 vs Tcl 9

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

In Tcl 8.6, if TCL_WIDE_INT_IS_LONG was defined, Tcl_WideInt was typdef'ed
as "long".

 

In Tcl 9.0, even if TCL_WIDE_INT_IS_LONG was defined, Tcl_WideInt is
typdef'ed as "long long" (see gcc warning below)

 

 

../../src/column.c:5682:61: warning: passing argument 3 of
'__builtin_saddl_overflow' from incompatible pointer type
[-Wincompatible-pointer-types]

5682 |                 if (addfn_(pbucket[bucket_index], pdata[i],
&pbucket[bucket_index]))            \

      |
^~~~~~~~~~~~~~~~~~~~~~

      |                                                             |

      |
Tcl_WideInt * {aka long long int *}

 

 

 

 

In my extension's use case, to detect Tcl_WideInt overflow on addition, I
was calling one of the gcc builtins '__builtin_saddl_overflow' (note single
l indicating long) or '__builtin_saddll_overflow'  (note ll indicating long
long) depending on whether TCL_WIDE_INT_IS_LONG is defined or not. This
generates the above warning because TWIIL is defined but Tcl_WideInt is
defined as "long long" and not "long".

 

Could someone clarify - Is this difference between Tcl 8 and 9 intentional?
What is the purpose of the TCL_WIDE_INT_IS_LONG  #define if not to indicate
which Tcl_WideInt typedef was in effect? How else can I detect whether to
call the "long" version or "long long" of a runtime function for Tcl_WideInt
values?

 

(Platform Ubuntu 20, gcc 9)

 

/Ashok

Re: [TCLCORE] Proposal for my contribution to Tk, request for comments

[Erik L. <el...@xs...>]

Thanks for the by and large positive reception of my proposal.

@Steve, regarding the encouragement to remain cross-platform
------------------------------------------------------------

     Sure, that's what I want too (why wouldn't I ?). Various of my 
previous contributions to bug
     tickets were reported/tested only on Linux and Windows, because I 
didn't have a macOS
     system available.

     Also, as far as compiled code is concerned, I don't master 
objective C. Therefore,
     this limits my possibilities for remaining entirely cross-platform.

     For the short term (subjects A. and B. of my proposal), this seems 
to be a moot point because
     these subjects are platform-indifferent, script-level tasks. 
However, for subjects C.
     and D. this will be something to be dealt with (occasionally).

     In anticipation of working more regularly on Tcl/Tk development, I 
got myself a macOS
     machine, so that I can at least run tests locally (against a 
pre-compiled Tcl/Tk) on
     that platform.


General procedure
-----------------

     I'm going to make a start with subject A.1 (see below for the 
entire subject A).

     My development efforts will happen intermittently at an order of 
magnitude of a week
     (currently two weeks on, one week off), because of my private 
situation.

     Therefore, it may take a few weeks before anything is ready for a 
first commit.

     Would you like me to report back here when that moment arrives (in 
order to create an
     appropriate branch in the Fossil Tk repository) ?


Best regards,
Erik Leunissen.
--


A. STRUCTURAl ASPECTS OF THE TK TEST SUITE
------------------------------------------
A.1 Collect utility procs

A.2 Collect (more) test constraint definitions in constraints.tcl

A.3 Make internal structure of test files uniform

A.4 Use common names for certain types of common utility procs

--

Re: [TCLCORE] TIP 705 - Affirm Tcl License

[Andreas K. <and...@gm...>]

> On 11/27/24 05:53, msc...@po... wrote:
> > Hi,
> >
> > the Tcl/Tk license is also listed in the https://spdx.org/licenses/ 
> > list at https://spdx.org/licenses/preview/TCL.html, which is commonly 
> > used for Software Bills of Materials to annotate code used and for 
> > license checking tooling.
> >
> > If we discuss alternative licenses to be allowed, i would highly 
> > recommend to use the SPDX identifiers to identify such licenses cleanly.
> 
> I strong urge the acceptance of *TIP 705* */_AS IS_/* and not to start 
> down the slippery slope of allowing other licenses.

Hello Gerald, glad to hear that you are still with us.

I do not read Michael's mail as proposal to change the TIP.
I believe that his sentence about alternative licenses refers to
the second sentence of the rationale, i.e.:

    > Should anyone seek to include code under a different license
    > than the original Tcl license in a Tcl community repository,
    > please submit that license as a separate TIP to be reviewed and
    > voted on by the TCT.

I would agree that using such official identifiers would be helpful.

I further believe that it would be helpful to integrate the url

	https://spdx.org/licenses/preview/TCL.html

as a reference into the Abstract. Easier to follow than having to dig
out the `license.terms` file. Actually, not a good argument, given
that we would could use

	https://core.tcl-lang.org/tcl/file?name=license.terms&ci=adbae584a7045f19

However the SPDX link might be more useful/official to legal types.
Third hand, maybe both links ?

-- 
Happy Tcling,
	Andreas Kupries <and...@gm...>
			<https://core.tcl-lang.org/akupries/>
			<https://akupries.tclers.tk/>
	Developer @	SUSE Software Solutions Germany GmbH
-------------------------------------------------------------------------------

Re: [TCLCORE] sqlite3 3.47.1 released

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

Op wo 27 nov 2024 om 17:53 schreef Donald G Porter via Tcl-Core:

>
> When I retrieve this release from sourceforge, and then unpack it,
> tar raises some complaints:
>
> $ gunzip -c sqlite3.47.1.tar.gz | tar xf -
> tar: Ignoring unknown extended header keyword
> 'LIBARCHIVE.xattr.com.apple.quarantine'
> tar: Ignoring unknown extended header keyword
> 'LIBARCHIVE.xattr.com.apple.quarantine'
> tar: Ignoring unknown extended header keyword
> 'LIBARCHIVE.xattr.com.apple.quarantine'
> tar: Ignoring unknown extended header keyword
> 'LIBARCHIVE.xattr.com.apple.quarantine'
>
>
See:
    <
https://stackoverflow.com/questions/51655657/tar-ignoring-unknown-extended-header-keyword-libarchive-xattr-security-selinux
>

Yes, this time I constructed it on a Mac, normally I do it on Windows.
Warnings are harmless

Hope this helps,
     Jan Nijtmans

Re: [TCLCORE] sqlite3 3.47.1 released

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

When I retrieve this release from sourceforge, and then unpack it,
tar raises some complaints:

$ gunzip -c sqlite3.47.1.tar.gz | tar xf -
tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.com.apple.quarantine'
tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.com.apple.quarantine'
tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.com.apple.quarantine'
tar: Ignoring unknown extended header keyword 'LIBARCHIVE.xattr.com.apple.quarantine'

What should I think about that?

On 11/25/24 16:45, Jan Nijtmans wrote:
> The upstream SQLite project released 3.47.1 of SQLite recently
>
> From that, I derived the TEA-based Tcl package we layer
> on top of it.
>
> http://cyqlite.sourceforge.net/cgi-bin/sqlite/timeline <http://cyqlite.sourceforge.net/cgi-bin/sqlite/timeline>
>
> That's now available as Tcl package sqlite3.47.1.tar.gz from
>
> https://sourceforge.net/projects/tcl/files/Tcl/8.6.15/ <https://sourceforge.net/projects/tcl/files/Tcl/8.6.15/>
> or
> https://sourceforge.net/projects/tcl/files/Tcl/9.0.0/ <https://sourceforge.net/projects/tcl/files/Tcl/9.0.0/>
>
> Unpack that source distribution in the "pkgs" subdir of your Tcl
> 8.6.15 or 9.0.0 source code distribution and run `make install`
> again for your platform.
> That will build and install the updated sqlite package.
>
> Unless another SQLite release happens first, this package will be
> bundled with Tcl 8.6.16 / Tcl 9.0.1
>
> Regards
>       Jan Nijtmans
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core


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

Re: [TCLCORE] TIP 705 - Affirm Tcl License

[Gerald L. <ger...@gm...>]

On 11/27/24 05:53, msc...@po... wrote:
> Hi,
>
> the Tcl/Tk license is also listed in the https://spdx.org/licenses/ 
> list at https://spdx.org/licenses/preview/TCL.html, which is commonly 
> used for Software Bills of Materials to annotate code used and for 
> license checking tooling.
>
> If we discuss alternative licenses to be allowed, i would highly 
> recommend to use the SPDX identifiers to identify such licenses cleanly.

I strong urge the acceptance of *TIP 705* */_AS IS_/* and not to start 
down the slippery slope of allowing other licenses.

To do such because they are "basically the same" opens to to much 
opinion on what "basically the same" means -- to some GPL and the Tcl 
License are "basically the same".


-- 
+------------------------------------------------------------------------+
| Gerald W. Lester                                                       |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+

Re: [TCLCORE] TIP 705 - Affirm Tcl License

[<msc...@po...>]

Hi,

the Tcl/Tk license is also listed in the https://spdx.org/licenses/ list 
at https://spdx.org/licenses/preview/TCL.html, which is commonly used 
for Software Bills of Materials to annotate code used and for license 
checking tooling.

If we discuss alternative licenses to be allowed, i would highly 
recommend to use the SPDX identifiers to identify such licenses cleanly.

Michael

Re: [TCLCORE] TIP 705 - Affirm Tcl License

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

On Nov 27 2024, 02:20 +0000, Kevin Walzer <kw...@co...> wrote:
>*
>Hello,
>
>The TCT invites review and discussion of TIP 705, Affirm Tcl License.
>See https://core.tcl-lang.org/tips/doc/trunk/tip/705.md for details.
>This is an informational TIP.

Would it be reasonable to accept - or even suggest - that new code be 
put under a more widespread and familiar license, of course with 
equivalent terms?

I find the current license problematic in any way:

1. The text starts with "This software is copyrighted by the Regents of 
the University of California, Sun Microsystems, Inc., Scriptics 
Corporation, ActiveState Corporation and other parties".  Because of the 
"and other parties" ending, this really doesn't give me any information.  
What's the use for this opening?

2. What follows is basically MIT / X11 / BSD2Clause. How about *using* 
any of those licenses? That'd allow people to understand at a glance 
what kind of licensing we're talking about.

3. As a non-US citizen, I'm having a real hard time understanding the 
"GOVERNMENT USE" clause. I probably understand that it doesn't apply to 
me, but if I am to license any of my code with a license that has such a 
clause, I guess I'm better off understanding what it's all about.
Is this still relevant / necessary / ever desired for new code?

As a final thought, I think this might be a good chance to restate and 
reaffirm the original *intent* perhaps by modernizing its form, rather 
than reinforce the original *form* itself.

Thanks,


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

[TCLCORE] TIP 705 - Affirm Tcl License

[Kevin W. <kw...@co...>]

<div><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/OQ7lWZyI03-88Ws2CGL3U04r5t91lfRxhpxhMJbiDyLaS_7F3oxDucsrley5MFnltmlm9XPlzSuaLq5fQ03hstGSv8kDky6xsU3M5scvpxI9sv4ubpO_W5PLn35idIdwurx4AvN3oaDaF8sZJ-fq2wIvmqk2nA6UTspin2m-gTUSM_QKnjtlT-zyOFCPDv-6y5B3EuoYo62Ir67FAIC6REMGF_0tZwyQ' /></div>Hello,<br/><br/>The TCT invites review and discussion of TIP 705, Affirm Tcl License. <br/>See https://core.tcl-lang.org/tips/doc/trunk/tip/705.md for details. <br/>This is an informational TIP.<br/><br/>We will put out a CFV early next week.<br/><br/>Thanks,<br/><br/>Kevin<br/><br/>

[TCLCORE] Tk meeting report on 2024-11-26

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

Dear Tk team,

the Tk team meeting took place today on Jitsi with 9 participants.

1) Tk release plan
Don asked the Tk team to give information about a possible decoupling of 
the Tk release plan from Tcl to allow more releases.

The result is as follows:
R1) Tcl and Tk should be generally released together.
- This allows to test only again one Tcl version and not more of them.
- Users are not confused by release plans
R2) There should be a predictable release plan
- one release per year for new features is seen as favourable. Other 
major projects like python release once per year.
- The release should be predictable, for example in October
- There is no need for more releases due to fancy new features
R3) Release quickly in case of major bugs
- In case of a critical bug, a quicker release may be done. This is 
currently done with 8.6.16
- (only) in this case, Tk may be released without Tcl. The version 
number should be in line with Tcl. An idea is to use a sub-version 
number like "8.6.16.1". This is possible but untested.

For some Tk developers, Tcl is seen as a "black box". Nevertheless, the 
interfaces and features are floating. For example, Unicode functionality 
like word boundaries etc may be better placed in Tcl, not Tk.

2) Celebrate tk 9.0 and tkinter 9.0
The radical changes in the Mac Port and the great tkinter release was 
highlighted in the meeting.

3) New text widget
There was an informal discussion on the new text widget.
Francois has put it as a loadable package on chipseal:
https://chiselapp.com/user/fvogel/repository/rtext
This allows to test it beside the current text widget.
Paul has included it in bawt as optional package.

The code is described as a masterpiece very hard to maintain. The 
creator is unfortunately gone.
The performance is described as a factor of 5 to 25 times faster, also 
with tablelist.

Currently, there is no Mac build. Francois is seeking for a build 
recipe/method for the Mac. It builds on Mac as part of Tk, but not as an 
extension.

4) Next meeting
The tk meeting was seen as a great opportunity to meet people.
A monthly schedule is seen as adequate at the same time (18:00 UTC).

In one month, there is Christmas.
We may do the meeting just before the German speaking very informal 
meeting each first Tuesday. This would allow people which are in both 
meetings (Paul, Csaba, myself) to block only one evening per month.

The next meeting is Thuesday, 7th of January 2025 at 18:00 UTC.

The German meeting may start at 19:00 UTC (20:00 Central European Time).

---

Thank you all ! You guys rock !
Take care,
Harald

[TCLCORE] sqlite3 3.47.1 released

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

The upstream SQLite project released 3.47.1 of SQLite recently

>From that, I derived the TEA-based Tcl package we layer
on top of it.

    http://cyqlite.sourceforge.net/cgi-bin/sqlite/timeline

That's now available as Tcl package sqlite3.47.1.tar.gz from

    https://sourceforge.net/projects/tcl/files/Tcl/8.6.15/
or
    https://sourceforge.net/projects/tcl/files/Tcl/9.0.0/

Unpack that source distribution in the "pkgs" subdir of your Tcl
8.6.15 or 9.0.0 source code distribution and run `make install`
again for your platform.
That will build and install the updated sqlite package.

Unless another SQLite release happens first, this package will be
bundled with Tcl 8.6.16 / Tcl 9.0.1

Regards
      Jan Nijtmans

[TCLCORE] tcl biweekly meeting report and announcement

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

Dear Tcl/Tk team,

the be-weekly Tcl/Tk meeting hour took place today.

The results are:
1) 8.6.16
release work will start soon. current core-8-6-branch is in good shape. 
Thanks to Jan for the changes file preparation:
https://core.tcl-lang.org/tcl/info/1fad737fe755bed0
https://core.tcl-lang.org/tk/info/f921d987c395c14f

2) 9.0.1
release will follow. The only open point is the Windows in-memory load 
of a DLL which will not be part of this release, as more discussion is 
required.

3) Packages and 9.0
Most critical packages are ported to 9.0. Thanks to all !
Within bundled packages:
- ITCL: is practically abandoned and may be unbundled in future
- Thread: may partly move into the core in future

4) Celebrate TkInter and PerlTk for Tk 9
We thank all people making this happen! YOu are awesome!

Vladim from PerlTk was in the call.
His report: There are two approaches for PerlTk:
- without TCL: no porting to 9 seen, is complicated
- with TCL as intermediate step: Vladim works on this has has some minor 
issues with TclObj's. Single values are working but lists don't.
He will come back with more detailed reports and questions.
Thanks for the work, we are here to assist !

5) Next meetings are:
Be-weekly TCL meetings:
2024-12-02 12:00 UTC (in one week)
2024-12-16 12:00 UTC (in three weeks)

6) Special Tk meeting
2024-11-26 18:00 UTC (US friendly time)
Don Porter, the release manager, plans to attend and has more questions 
on organizing the Tk release. I would appreciate, if some Tk wizards may 
attend.

All meetings are for everybody and not restricted to TCT members.
All meetings take one hour time.

Any comment welcome !

Take care,
Harald

Re: [TCLCORE] Proposal for my contribution to Tk, request for comments

[elns <el...@xs...>]

(Reply to forwarded comments by Francois)
--


Thanks for your comments Francois,

Please see below for my response to selected comments of yours.

Regards,
Erik
--


>  snip-snip ..

>  > A. STRUCTURAl ASPECTS OF THE TK TEST SUITE
>  > ==========================================
>  >
>  > A.1 Collect utility procs
>  > -------------------------
>  > Utility procs are helper procs used by tests. I'm distinguishing global
>  > utility procs from local utility procs. Global utility procs are expected to
>  > be used by multiple test files. Local utility procs are expected to be used
>  > only in the test file that holds the proc definition.
>  >
>  > A.1.1 Collect global utility procs
>  > Currently, global utility procs exist in various test files and in the file
>  > constraints.tcl. I propose to move global utility procs and collect them in
>  > a new, separate file "utils.tcl".
> 
> OK. Take care that this file be sourced when running the test suite for one or several files, not 
> just when the entire test suite is run.
> 

Sure, similar to the file constraints.tcl.

> snip-snip

>  >
>  > A.3.2 Prepend each individual test with a single blank line (two consecutive
>  >       newlines) in all test files. This makes it more easy for the human eye
>  >       to quickly see where a new test starts.
> 
> Hmmm. I have always fought against white blanks changes only.

But how about the goal: improving overview to the human eye ?


  At least please do it in a single
> commit (not one per file).
> 

No problem.

> snip-snip

>  >
>  >
>  > B. TEST HYGIENE
>  > ===============
>  >
>  > B.1 Tests leave no new objects behind
>  > -------------------------------------
>  >     Objects to check for:
>  >     - interps
>  >     - namespaces
>  >     - global variables
>  >     - procs
>  >     - windows
>  >     - queued events + idle tasks (this has priority in test files that
>  >       are dedicated to events)
> 
> I understand you'd use the -cleanup section of each test, right? See my comment below about your B.2.1.
> 

Indeed, I expect that anything that needs to be corrected, is done by adjusting the -cleanup section.


> 
>  >
>  > B.1.1 Provide a common utility proc "checkTestsClean" that performs these checks
>  >       while tests are executing. And possibly also provide a corresponding
>  >       test option -checkclean that triggers this facility.
> 
> A proc checkTestsClean could be added easily in the test suite.
> 
> A -checkclean option to tcltest is a different story, I think it requires a TIP (and should be done 
> in the Tcl repository.
> 

Or let the test files accept a command line argument -checkclean, which isn't propagated to tcltest.


> 
>  >
>  > B.1.2 Run these checks and list deficiences
>  >
>  > B.1.3 Fix deficiencies.
>  >
>  >
>  > B.2 Remove dependencies or interference between tests
>  > -----------------------------------------------------
>  > This subject may partially overlap with the previous subject B.1
>  >
>  > B.2.1 Provide a common utility command "runTestsSeparately" which runs each test
>  >       in a new interpreter (yes, very slow!).
> 
> Note that he current Tk test suite runs in -singleproc 1.
> 
> Further, many many tests rely on previous tests (this should be limited to tests in the same file). 
> This should be carefully thought before implementing I think. Decoupling tests is a good bottom line 
> idea, but doing so will add lots of setup and cleanup code in each test. Whether the balance is 
> positive or not may depend on who you ask.
> 

That's a bit of a surprise to me. I have always understood that inter-dependencies of individual 
test are a NO-NO, even if they only occur within a test file.


--

Re: [TCLCORE] Proposal for my contribution to Tk, request for comments

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

Many thanks Erik, your efforts will be greatly appreciated.

I would encourage you to work in a branch off the trunk/main (i.e. in Tk9) and take care to remain cross-platform. If need be your work can be back-ported later.  Other than that, I’ll defer to Francois on the details of the test suite changes themselves.

Again, many thanks.

-- Steve
On 25 Nov 2024 at 4:54 PM +0800, elns <el...@xs...>, wrote:
> Hi all,
>
> I'd like to work on improvements to Tk on a more regular basis than before.
>
> I'm most interested in work on improving overview and maintainability of the Tk test suite. I
> believe that life can be made more easy for Tk maintainers. I also believe
> that more streamlining would ease the making contributions from Tk users
> (speaking for myself at least).
>
> Appended to this message, you find a list of proposed subjects. I'd very much appreciate comments on
> that. Please note that this list is meant to convey ideas and purposes. It is not meant to be
> anywhere exact about the workflow. That's for later.
>
> Subjects A and B are aimed at maintainability/overview. Subjects C and D are
> targeted at other improvements. If welcomed, I'd like to start with A and then B.
>
> Before starting off with anything, I'd like know:
> - whether the proposed subjects are welcomed.
> - whether my proposal interferes with someone else's idea's or work in progress
>
> Please feel free to raise anything else you think of as important, but which I didn't mention.
>
> (I already sent my proposal to Francois. I'll forward his response as
> the very first response in this thread.)
>
> Thanks in advance,
> Erik Leunissen
> --
>
> -- Proposed subjects --
>
>
> A. STRUCTURAl ASPECTS OF THE TK TEST SUITE
> ==========================================
>
> A.1 Collect utility procs
> -------------------------
> Utility procs are helper procs used by tests. I'm distinguishing global
> utility procs from local utility procs. Global utility procs are expected to
> be used by multiple test files. Local utility procs are expected to be used
> only in the test file that holds the proc definition.
>
> A.1.1 Collect global utility procs
> Currently, global utility procs exist in various test files and in the file
> constraints.tcl. I propose to move global utility procs and collect them in
> a new, separate file "utils.tcl".
>
> A.1.2 Collect test-file-local utility procs
> Collect them in a dedicated section somewhere at the top of the test file.
>
>
> A.2 Collect (more) test constraint definitions in constraints.tcl
> -----------------------------------------------------------------
> For example: pressbutton, failsOnXQuarz, failsOnUbuntu (the latter two
> for the time that they continue to exist ...)
>
>
> A.3 Make internal structure of test files uniform
> -------------------------------------------------
>
> A.3.1 Divide test scripts in explicit sections, each marked with a uniform
> section comment like:
>
> #
> # LOCAL TEST CONSTRAINTS
> #
>
> DISCUSSION: This idea targets an ideal situation, but I'm unsure whether
> it is feasible to maintain once the sections have been created.
> I'm unsure whether the degree of discipline, that it requires from (all)
> Tk maintainers, to put things where they belong can be "enforced".
>
> Sections envisaged for now:
> - file header comment containing general description of functionality and
> copyright statements, like the current state.
> - loading and configuration of package tcltest
> - definition of local test constraints
> - definition of local utility procs (see also A.1.2)
> - tests, possibly interspersed with setup and cleanup code for groups
> of related tests such as in canvas.test
>
> A.3.2 Prepend each individual test with a single blank line (two consecutive
> newlines) in all test files. This makes it more easy for the human eye
> to quickly see where a new test starts.
>
>
> A.4 Use common names for certain types of common utility procs
> --------------------------------------------------------------
> For example: there are various procs that combine the waiting or halting for a
> (fixed) amount of time with invoking "update" or "update idletasks". I
> envisage to collect them and give them the same prefix or suffix in the proc's
> name.
>
>
> B. TEST HYGIENE
> ===============
>
> B.1 Tests leave no new objects behind
> -------------------------------------
> Objects to check for:
> - interps
> - namespaces
> - global variables
> - procs
> - windows
> - queued events + idle tasks (this has priority in test files that
> are dedicated to events)
>
> B.1.1 Provide a common utility proc "checkTestsClean" that performs these checks
> while tests are executing. And possibly also provide a corresponding
> test option -checkclean that triggers this facility.
>
> B.1.2 Run these checks and list deficiences
>
> B.1.3 Fix deficiencies.
>
>
> B.2 Remove dependencies or interference between tests
> -----------------------------------------------------
> This subject may partially overlap with the previous subject B.1
>
> B.2.1 Provide a common utility command "runTestsSeparately" which runs each test
> in a new interpreter (yes, very slow!).
>
> B.2.2 Run the tests and list extra test failures when run separately.
>
> B.2.3 Fix deficiencies.
>
>
> B.3 Standardization of recurring test objects
> ---------------------------------------------
> Like A.3.1, this idea targets an ideal situation, but I feel it may be overdone.
> No priority for me as I see it now.
>
> B.3.1 Window position, size and background color
>
> B.3.2 Standardize the name of result variable: "result"
>
>
> C. REPLACE FIXED TIME DELAY COMMANDS/PROCS WITH FLEXIBLE PROCS
> ==============================================================
> Scattered throughout the test suite there are commands that halt or wait for a
> fixed amount of time. The drawback of using such fixed waiting times is that
> they need to accommodate a variety of user-systems for which the required
> waiting time varies. Therefore, these waiting times are rather long in order to
> err on the safe side. This slows down test execution.
> A related issue is that current usage of "after ms" or "_pause" etc. in many
> tests is undocumented. This makes it hard to understand for other persons
> besides the test author (if he remembers well) exactly what it is that's being
> waited for. This is a maintainability issue. (Using procs with names like
> "raiseDelay" are already an improvement in this respect IMO.)
>
> I propose to use a different approach of waiting where possible throughout the
> test suite. The core of this approach is the waiting for the servicing of a
> specific window event. See for example the generic proc "waitForWindowEvent"
> introduced with the tests for ticket #22349fc78a .)
>
> When developing the test script for the package windetect, I've been using this
> flexible waiting mechanism to my satisfaction. Obvious advantages are:
> - no more worries about the exact amount of time needed
> - improved maintainability (by using better proc names and comments)
> - a big speed-up of test execution (relative to the amount of time that's being
> waited for)
>
> To be fair: it is a challenge is to make such flexible waiting procs robust, and
> maybe there are cases where it appears not to work. I like that challenge.
>
> I envisage a common name structure for such waiting procs, and collecting
> them all in one place.
>
>
> D. LESS TEST CONSTRAINTS
> ========================
> As Francois already explained in his post to the TCLCORE mailing list
> (Wed, 23 Oct 2024 22:49:43 +0200).
>
> -- End of proposed subbjects --
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Proposal for my contribution to Tk, request for comments

[elns <el...@xs...>]

This is the response by Francois (I hope that the quoting doesn't get mangled by the copy/paste action):
--


Hi Erik,

Thank you for your email.

Yes your proposal is very welcome to me! Let me comment in between your lines below.

Regards,

François

Le 23/11/2024 à 14:03, elns a écrit :
 > Before starting off with anything, I'd like know:
 > - whether the proposed subjects are welcomed. (And I believe that I know the
 >   answer to that question already for subject D.)
 > - whether my proposal interferes with someone else's idea's or work in progress

I believe your proposals make a lot of sense, yes.

Regarding interference, I"m not aware of any parallel effort. However, I would advise you to post 
your intentions on the tcl-core list. That way we could be sure of this, and we could also gather 
comments.


 >
 > A. STRUCTURAl ASPECTS OF THE TK TEST SUITE
 > ==========================================
 >
 > A.1 Collect utility procs
 > -------------------------
 > Utility procs are helper procs used by tests. I'm distinguishing global
 > utility procs from local utility procs. Global utility procs are expected to
 > be used by multiple test files. Local utility procs are expected to be used
 > only in the test file that holds the proc definition.
 >
 > A.1.1 Collect global utility procs
 > Currently, global utility procs exist in various test files and in the file
 > constraints.tcl. I propose to move global utility procs and collect them in
 > a new, separate file "utils.tcl".

OK. Take care that this file be sourced when running the test suite for one or several files, not 
just when the entire test suite is run.


 >
 > A.1.2 Collect test-file-local utility procs
 > Collect them in a dedicated section somewhere at the top of the test file.
 >
 >
 > A.2 Collect (more) test constraint definitions in constraints.tcl
 > -----------------------------------------------------------------
 > For example: pressbutton, failsOnXQuarz, failsOnUbuntu (the latter two
 > for the time that they continue to exist ...)
 >
 >
 > A.3 Make internal structure of test files uniform
 > -------------------------------------------------
 >
 > A.3.1 Divide test scripts in explicit sections, each marked with a uniform
 >       section comment like:
 >
 >       #
 >       # LOCAL TEST CONSTRAINTS
 >       #
 >
 >       DISCUSSION: This idea targets an ideal situation, but I'm unsure whether
 >       it is feasible to maintain once the sections have been created.
 >       I'm unsure whether the degree of discipline, that it requires from (all)
 >       Tk maintainers, to put things where they belong can be "enforced".
 >
 >       Sections envisaged for now:
 >       - file header comment containing general description of functionality and
 >         copyright statements, like the current state.
 >       - loading and configuration of package tcltest
 >       - definition of local test constraints
 >       - definition of local utility procs (see also A.1.2)
 >       - tests, possibly interspersed with setup and cleanup code for groups
 >         of related tests such as in canvas.test

OK, why not. Would be clearer than current state.


 >
 > A.3.2 Prepend each individual test with a single blank line (two consecutive
 >       newlines) in all test files. This makes it more easy for the human eye
 >       to quickly see where a new test starts.

Hmmm. I have always fought against white blanks changes only. At least please do it in a single 
commit (not one per file).


 >
 > A.4 Use common names for certain types of common utility procs
 > --------------------------------------------------------------
 > For example: there are various procs that combine the waiting or halting for a
 > (fixed) amount of time with invoking "update" or "update idletasks". I
 > envisage to collect them and give them the same prefix or suffix in the proc's
 > name.
 >
 >
 > B. TEST HYGIENE
 > ===============
 >
 > B.1 Tests leave no new objects behind
 > -------------------------------------
 >     Objects to check for:
 >     - interps
 >     - namespaces
 >     - global variables
 >     - procs
 >     - windows
 >     - queued events + idle tasks (this has priority in test files that
 >       are dedicated to events)

I understand you'd use the -cleanup section of each test, right? See my comment below about your B.2.1.


 >
 > B.1.1 Provide a common utility proc "checkTestsClean" that performs these checks
 >       while tests are executing. And possibly also provide a corresponding
 >       test option -checkclean that triggers this facility.

A proc checkTestsClean could be added easily in the test suite.

A -checkclean option to tcltest is a different story, I think it requires a TIP (and should be done 
in the Tcl repository.


 >
 > B.1.2 Run these checks and list deficiences
 >
 > B.1.3 Fix deficiencies.
 >
 >
 > B.2 Remove dependencies or interference between tests
 > -----------------------------------------------------
 > This subject may partially overlap with the previous subject B.1
 >
 > B.2.1 Provide a common utility command "runTestsSeparately" which runs each test
 >       in a new interpreter (yes, very slow!).

Note that he current Tk test suite runs in -singleproc 1.

Further, many many tests rely on previous tests (this should be limited to tests in the same file). 
This should be carefully thought before implementing I think. Decoupling tests is a good bottom line 
idea, but doing so will add lots of setup and cleanup code in each test. Whether the balance is 
positive or not may depend on who you ask.


 >
 > B.2.2 Run the tests and list extra test failures when run separately.
 >
 > B.2.3 Fix deficiencies.
 >
 >
 > B.3 Standardization of recurring test objects
 > ---------------------------------------------
 > Like A.3.1, this idea targets an ideal situation, but I feel it may be overdone.
 > No priority for me as I see it now.
 >
 > B.3.1 Window position, size and background color
 >
 > B.3.2 Standardize the name of result variable: "result"

Also probably a significant effort. We'd be convinced of the benefits first.


 > C. REPLACE FIXED TIME DELAY COMMANDS/PROCS WITH FLEXIBLE PROCS
 > ==============================================================
 > Scattered throughout the test suite there are commands that halt or wait for a
 > fixed amount of time. The drawback of using such fixed waiting times is that
 > they need to accommodate a variety of user-systems for which the required
 > waiting time varies. Therefore, these waiting times are rather long in order to
 > err on the safe side. This slows down test execution.
 > A related issue is that current usage of "after ms" or "_pause" etc. in many
 > tests is undocumented. This makes it hard to understand for other persons
 > besides the test author (if he remembers well) exactly what it is that's being
 > waited for. This is a maintainability issue. (Using procs with names like
 > "raiseDelay" are already an improvement in this respect IMO.)
 >
 > I propose to use a different approach of waiting where possible throughout the
 > test suite. The core of this approach is the waiting for the servicing of a
 > specific window event. See for example the generic proc "waitForWindowEvent"
 > introduced with the tests for ticket #22349fc78a .)

I would welcome this very much. Note however that it will probably be quite difficult to achieve for 
all platforms.

The CI at Github would certainly help here.

This makes me think of something else: one regularly have failures at CI (VMs) which we cannot 
reproduce on real computers for unclear reasons. Sometimes this is due to running tests in Xvfb, 
sometimes it's more puzzling. This is something we should have on our radar when dealing with the 
test suite.

And of course there are some tests which fail sporadically, on both GitHub and real computers. Run 
the test suite again and they don't fail. Issue here is robustness of these tests, but I can't tell 
robustness against what unfortunately. Dealing with your C. above should certainly help, let's see.


 > When developing the test script for the package windetect, I've been using this
 > flexible waiting mechanism to my satisfaction. Obvious advantages are:
 > - no more worries about the exact amount of time needed
 > - improved maintainability (by using better proc names and comments)
 > - a big speed-up of test execution (relative to the amount of time that's being
 >   waited for)
 >
 > To be fair: it is a challenge is to make such flexible waiting procs robust, and
 > maybe there are cases where it appears not to work. I like that challenge.

Exactly.


 > I envisage a common name structure for such waiting procs, and collecting
 > them all in one place.
 >
 >
 > D. LESS TEST CONSTRAINTS
 > ========================
 > As you already explained in your post to the TCLCORE mailing list
 > (Wed, 23 Oct 2024 22:49:43 +0200).
 >
 > -- End of proposed changes --

All in all, in a nutshell, in my opinion:

- Any effort that improves the test suite in any aspect such as readability, reliability, 
"cross-platformability", harmonization, robustness, maintainability and so on is very welcome to me.

- I would strongly suggest you announce your effort on Tcl-core, so that anyone is aware and can 
comment (I'm very fond of doing everything in public, generally speaking)

- You should work in a branch. Now, off which root should this branch be. I think it should be off 
the main branch (not core-8-6-branch), but this is one of the points that could/should be discussed 
on Tcl-core. Once the matter settled, I can give you write access to the Tk repository.

Many thanks for your proposal and the time you're willing to invest! This is much appreciated.

Regards,

Francois

[TCLCORE] Proposal for my contribution to Tk, request for comments

[elns <el...@xs...>]

Hi all,

I'd like to work on improvements to Tk on a more regular basis than before.

I'm most interested in work on improving overview and maintainability of the Tk test suite. I 
believe that life can be made more easy for Tk maintainers. I also believe
that more streamlining would ease the making contributions from Tk users
(speaking for myself at least).

Appended to this message, you find a list of proposed subjects. I'd very much appreciate comments on 
that. Please note that this list is meant to convey ideas and purposes. It is not meant to be 
anywhere exact about the workflow. That's for later.

Subjects A and B are aimed at maintainability/overview. Subjects C and D are
targeted at other improvements. If welcomed, I'd like to start with A and then B.

Before starting off with anything, I'd like know:
- whether the proposed subjects are welcomed.
- whether my proposal interferes with someone else's idea's or work in progress

Please feel free to raise anything else you think of as important, but which I didn't mention.

     (I already sent my proposal to Francois. I'll forward his response as
      the very first response in this thread.)

Thanks in advance,
Erik Leunissen
--

-- Proposed subjects --


A. STRUCTURAl ASPECTS OF THE TK TEST SUITE
==========================================

A.1 Collect utility procs
-------------------------
Utility procs are helper procs used by tests. I'm distinguishing global
utility procs from local utility procs. Global utility procs are expected to
be used by multiple test files. Local utility procs are expected to be used
only in the test file that holds the proc definition.

A.1.1 Collect global utility procs
Currently, global utility procs exist in various test files and in the file
constraints.tcl. I propose to move global utility procs and collect them in
a new, separate file "utils.tcl".

A.1.2 Collect test-file-local utility procs
Collect them in a dedicated section somewhere at the top of the test file.


A.2 Collect (more) test constraint definitions in constraints.tcl
-----------------------------------------------------------------
For example: pressbutton, failsOnXQuarz, failsOnUbuntu (the latter two
for the time that they continue to exist ...)


A.3 Make internal structure of test files uniform
-------------------------------------------------

A.3.1 Divide test scripts in explicit sections, each marked with a uniform
       section comment like:

       #
       # LOCAL TEST CONSTRAINTS
       #

       DISCUSSION: This idea targets an ideal situation, but I'm unsure whether
       it is feasible to maintain once the sections have been created.
       I'm unsure whether the degree of discipline, that it requires from (all)
       Tk maintainers, to put things where they belong can be "enforced".

       Sections envisaged for now:
       - file header comment containing general description of functionality and
         copyright statements, like the current state.
       - loading and configuration of package tcltest
       - definition of local test constraints
       - definition of local utility procs (see also A.1.2)
       - tests, possibly interspersed with setup and cleanup code for groups
         of related tests such as in canvas.test

A.3.2 Prepend each individual test with a single blank line (two consecutive
       newlines) in all test files. This makes it more easy for the human eye
       to quickly see where a new test starts.


A.4 Use common names for certain types of common utility procs
--------------------------------------------------------------
For example: there are various procs that combine the waiting or halting for a
(fixed) amount of time with invoking "update" or "update idletasks". I
envisage to collect them and give them the same prefix or suffix in the proc's
name.


B. TEST HYGIENE
===============

B.1 Tests leave no new objects behind
-------------------------------------
     Objects to check for:
     - interps
     - namespaces
     - global variables
     - procs
     - windows
     - queued events + idle tasks (this has priority in test files that
       are dedicated to events)

B.1.1 Provide a common utility proc "checkTestsClean" that performs these checks
       while tests are executing. And possibly also provide a corresponding
       test option -checkclean that triggers this facility.

B.1.2 Run these checks and list deficiences

B.1.3 Fix deficiencies.


B.2 Remove dependencies or interference between tests
-----------------------------------------------------
This subject may partially overlap with the previous subject B.1

B.2.1 Provide a common utility command "runTestsSeparately" which runs each test
       in a new interpreter (yes, very slow!).

B.2.2 Run the tests and list extra test failures when run separately.

B.2.3 Fix deficiencies.


B.3 Standardization of recurring test objects
---------------------------------------------
Like A.3.1, this idea targets an ideal situation, but I feel it may be overdone.
No priority for me as I see it now.

B.3.1 Window position, size and background color

B.3.2 Standardize the name of result variable: "result"


C. REPLACE FIXED TIME DELAY COMMANDS/PROCS WITH FLEXIBLE PROCS
==============================================================
Scattered throughout the test suite there are commands that halt or wait for a
fixed amount of time. The drawback of using such fixed waiting times is that
they need to accommodate a variety of user-systems for which the required
waiting time varies. Therefore, these waiting times are rather long in order to
err on the safe side. This slows down test execution.
A related issue is that current usage of "after ms" or "_pause" etc. in many
tests is undocumented. This makes it hard to understand for other persons
besides the test author (if he remembers well) exactly what it is that's being
waited for. This is a maintainability issue. (Using procs with names like
"raiseDelay" are already an improvement in this respect IMO.)

I propose to use a different approach of waiting where possible throughout the
test suite. The core of this approach is the waiting for the servicing of a
specific window event. See for example the generic proc "waitForWindowEvent"
introduced with the tests for ticket #22349fc78a .)

When developing the test script for the package windetect, I've been using this
flexible waiting mechanism to my satisfaction. Obvious advantages are:
- no more worries about the exact amount of time needed
- improved maintainability (by using better proc names and comments)
- a big speed-up of test execution (relative to the amount of time that's being
   waited for)

To be fair: it is a challenge is to make such flexible waiting procs robust, and
maybe there are cases where it appears not to work. I like that challenge.

I envisage a common name structure for such waiting procs, and collecting
them all in one place.


D. LESS TEST CONSTRAINTS
========================
As Francois already explained in his post to the TCLCORE mailing list
(Wed, 23 Oct 2024 22:49:43 +0200).

-- End of proposed subbjects --

Re: [TCLCORE] Tcl/Tk biwikly telco on 25th of November 12:00UTC, Tk telco on 26th of November 18:00 UTC

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

I have technical concerns (not license related) with the ticket linked by Jan below. See my comments in that link for details.

 

/Ashok

 

From: Jan Nijtmans <jan...@gm...> 

 

Regarding the 9.0.1 release, I would like this ticket being

discussed:

    <Tcl Source Code: View Ticket <https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4> >

The fix contains 2 (Windows-only) files which are under

the MPL (Mozilla Public License). The author is not active

any more, so we cannot ask to change the license. It is

compatible with the BSD license (there appears to be

agreement on that). So, how should we proceed?

 

Regards,

     Jan Nijtmans

 

[TCLCORE] TIP 702 withdrawn

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

For the reasons summarized in Harald's core mailing list post, TIP 702
stands withdrawn.

 

Thanks to all who provided input.

 

/Ashok

Re: [TCLCORE] Tcl/Tk biwikly telco on 25th of November 12:00UTC, Tk telco on 26th of November 18:00 UTC

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

Op do 21 nov 2024 om 14:27 schreef Harald Oehlmann:

> - TCL 9.0.1 release support
> - Eventual TCL 8.6.16 release (due to clock bugfix)
>

First, I won't be able to join the meeting, due to conflicting
obligations. A friday-meeting, occurring every 2 weeks, has
been moved to monday 13:00 every 2 weeks. So, next
week would be OK for me ;-)

Regarding the 9.0.1 release, I would like this ticket being
discussed:
    <Tcl Source Code: View Ticket
<https://core.tcl-lang.org/tcl/tktview/a8e4f76ce4>>
The fix contains 2 (Windows-only) files which are under
the MPL (Mozilla Public License). The author is not active
any more, so we cannot ask to change the license. It is
compatible with the BSD license (there appears to be
agreement on that). So, how should we proceed?

Regards,
     Jan Nijtmans