tcl-core

[TCLCORE] Report of Tcl/Tk biweekly telco

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

Dear Tcl/Tk team,
here is a report of the meeting of today.

1) Orphaned extensions
Orphaned extensions may be put into a github repository.
This may not be personal but under the hood of an organisation for legal 
reasons.
Steve will contact Cliff Redler from the Tcl association, if this is 
possible under this hat.

2) TCT fossil forum
a TCT forum was proposed for inner TCT communication. Benefit compared 
to E-Mail list is:
- control when and how one gets notified
- organisation of threads
- archive

3) TCL infrastructure
Recent fall-outs lead to the opinion that less infra structure is better.
Another opinion is that infra structure is great if you control it.

The E-Mail notification feature still does not work for the core. A 
participant reported, that it now works on Chiseal (which is perhaps the 
same machine) and he may try to fix it.

4) Tests
Many new features came only with basic tests.
An example is the zip file system, which only has basic tests.
It was proposed to require a higher test coverage before a merge to the 
productive branches.
On the other hand, Wizards just do and don't need tests at all.
And we are happy to get their great code.
Testing will happen in productive environments, (but there are anyway 
never issues).
And the group of non-believers is charged to write tests.
The discussion lead in case of the memory load module to the result:
- the code is correct, no doubt
- there will ne more test cases for those non believers

To say it positive: we respect each others opinion and work on it - great !

5) Next meeting:
2025-01-27 12:00 UTC Bi-weekly Tcl/Tk
2025-02-04 18:00 UTC Tk meeting, afterwards "Stammtisch", Harald will 
demonstrate Barcode scanning using tclwmf and zxing-cpp packages
2025-02-10 12:00 UTC Bi-weekly Tcl/Tk (Harald will not be available)

Thank you all,
Harald

Re: [TCLCORE] Report of Tcl/Tk biweekly telco

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

Harald, thanks for the summary but I do want to make clarifications with respect to what I took away from the meeting.

 

With respect to the memory module, the result was not "code is correct, no doubt". Jan held that the code was correct in his view and he was only working on tests. I contended that the code as it currently stands fails even the simple test cases I provided in my apn-tip-709 branch and he has not yet indicated why the tests were invalid. If I understood Jan correctly, he also said the tests do not show corrupt data (perhaps I misunderstood what he was saying)  and my response was that one DLL writing to the private TLS data of another DLL instead of its own *in the same thread* was indeed data corruption by any definition of the term. But the matter is still in progress as Jan works on his own tests. As of now, there is no doubt in my mind the code is broken.

 

My comments with respect to test cases were that the TCT should hold a stronger position with respect to even passed TIP's being merged to trunk without a reasonable test suite.

 

That led to what I think both Jan and I agreed (Jan, correct me if I misunderstood) that we have different views of how software development on the trunk should proceed. Jan's view was that if something was deemed to be a good idea based on a TIP's passage, it should be merged to trunk for more people to beat on it, test and provide patches. My view was that it is the author's responsibility that should not be punted to everybody else, the most important reasons being (a) this crowd-sourced testing and patching just does not happen leaving the code fragile or completely broken and I can give several cases in the Tcl 9 development cycle of the latter, and (b) it is unfair to the rest of the contributors to be saddled with the tedium of debugging, writing tests and patches. (I'll just stress this is not a comment on Jan himself!)

 

Jan, please add your view of the meeting as necessary. It's important for everyone to get on the same page as to what we should expect of commits to the trunk.

 

It was a productive meeting indeed in thrashing out the different views. Thanks

 

/Ashok

 

 

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Monday, January 20, 2025 8:38 PM
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] Report of Tcl/Tk biweekly telco

 

Dear Tcl/Tk team,

here is a report of the meeting of today.

 

1) Orphaned extensions

Orphaned extensions may be put into a github repository.

This may not be personal but under the hood of an organisation for legal 

reasons.

Steve will contact Cliff Redler from the Tcl association, if this is 

possible under this hat.

 

2) TCT fossil forum

a TCT forum was proposed for inner TCT communication. Benefit compared 

to E-Mail list is:

- control when and how one gets notified

- organisation of threads

- archive

 

3) TCL infrastructure

Recent fall-outs lead to the opinion that less infra structure is better.

Another opinion is that infra structure is great if you control it.

 

The E-Mail notification feature still does not work for the core. A 

participant reported, that it now works on Chiseal (which is perhaps the 

same machine) and he may try to fix it.

 

4) Tests

Many new features came only with basic tests.

An example is the zip file system, which only has basic tests.

It was proposed to require a higher test coverage before a merge to the 

productive branches.

On the other hand, Wizards just do and don't need tests at all.

And we are happy to get their great code.

Testing will happen in productive environments, (but there are anyway 

never issues).

And the group of non-believers is charged to write tests.

The discussion lead in case of the memory load module to the result:

- the code is correct, no doubt

- there will ne more test cases for those non believers

 

To say it positive: we respect each others opinion and work on it - great !

 

5) Next meeting:

2025-01-27 12:00 UTC Bi-weekly Tcl/Tk

2025-02-04 18:00 UTC Tk meeting, afterwards "Stammtisch", Harald will 

demonstrate Barcode scanning using tclwmf and zxing-cpp packages

2025-02-10 12:00 UTC Bi-weekly Tcl/Tk (Harald will not be available)

 

Thank you all,

Harald

Re: [TCLCORE] Report of Tcl/Tk biweekly telco

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

Thank you, Ashok, for providing some details on this issue.

-Marc

On Mon, Jan 20, 2025 at 9:42 AM apnmbx-public--- via Tcl-Core <
tcl...@li...> wrote:

> Harald, thanks for the summary but I do want to make clarifications with
> respect to what I took away from the meeting.
>
>
>
> With respect to the memory module, the result was not "code is correct, no
> doubt". Jan held that the code was correct in his view and he was only
> working on tests. I contended that the code as it currently stands fails
> even the simple test cases I provided in my apn-tip-709 branch and he has
> not yet indicated why the tests were invalid. If I understood Jan
> correctly, he also said the tests do not show corrupt data (perhaps I
> misunderstood what he was saying)  and my response was that one DLL writing
> to the private TLS data of another DLL instead of its own *in the same
> thread* was indeed data corruption by any definition of the term. But the
> matter is still in progress as Jan works on his own tests. As of now, there
> is no doubt in my mind the code is broken.
>
>
>
> My comments with respect to test cases were that the TCT should hold a
> stronger position with respect to even passed TIP's being merged to trunk
> without a reasonable test suite.
>
>
>
> That led to what I think both Jan and I agreed (Jan, correct me if I
> misunderstood) that we have different views of how software development on
> the trunk should proceed. Jan's view was that if something was deemed to be
> a good idea based on a TIP's passage, it should be merged to trunk for more
> people to beat on it, test and provide patches. My view was that it is the
> author's responsibility that should not be punted to everybody else, the
> most important reasons being (a) this crowd-sourced testing and patching
> just does not happen leaving the code fragile or completely broken and I
> can give several cases in the Tcl 9 development cycle of the latter, and
> (b) it is unfair to the rest of the contributors to be saddled with the
> tedium of debugging, writing tests and patches. (*I'll just stress this
> is not a comment on Jan himself!)*
>
>
>
> Jan, please add your view of the meeting as necessary. It's important for
> everyone to get on the same page as to what we should expect of commits to
> the trunk.
>
>
>
> It was a productive meeting indeed in thrashing out the different views.
> Thanks
>
>
>
> /Ashok
>
>
>
>
>
> -----Original Message-----
> From: Harald Oehlmann <har...@el...>
> Sent: Monday, January 20, 2025 8:38 PM
> To: Tcl Core List <tcl...@li...>
> Subject: [TCLCORE] Report of Tcl/Tk biweekly telco
>
>
>
> Dear Tcl/Tk team,
>
> here is a report of the meeting of today.
>
>
>
> 1) Orphaned extensions
>
> Orphaned extensions may be put into a github repository.
>
> This may not be personal but under the hood of an organisation for legal
>
> reasons.
>
> Steve will contact Cliff Redler from the Tcl association, if this is
>
> possible under this hat.
>
>
>
> 2) TCT fossil forum
>
> a TCT forum was proposed for inner TCT communication. Benefit compared
>
> to E-Mail list is:
>
> - control when and how one gets notified
>
> - organisation of threads
>
> - archive
>
>
>
> 3) TCL infrastructure
>
> Recent fall-outs lead to the opinion that less infra structure is better.
>
> Another opinion is that infra structure is great if you control it.
>
>
>
> The E-Mail notification feature still does not work for the core. A
>
> participant reported, that it now works on Chiseal (which is perhaps the
>
> same machine) and he may try to fix it.
>
>
>
> 4) Tests
>
> Many new features came only with basic tests.
>
> An example is the zip file system, which only has basic tests.
>
> It was proposed to require a higher test coverage before a merge to the
>
> productive branches.
>
> On the other hand, Wizards just do and don't need tests at all.
>
> And we are happy to get their great code.
>
> Testing will happen in productive environments, (but there are anyway
>
> never issues).
>
> And the group of non-believers is charged to write tests.
>
> The discussion lead in case of the memory load module to the result:
>
> - the code is correct, no doubt
>
> - there will ne more test cases for those non believers
>
>
>
> To say it positive: we respect each others opinion and work on it - great !
>
>
>
> 5) Next meeting:
>
> 2025-01-27 12:00 UTC Bi-weekly Tcl/Tk
>
> 2025-02-04 18:00 UTC Tk meeting, afterwards "Stammtisch", Harald will
>
> demonstrate Barcode scanning using tclwmf and zxing-cpp packages
>
> 2025-02-10 12:00 UTC Bi-weekly Tcl/Tk (Harald will not be available)
>
>
>
> Thank you all,
>
> Harald
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Report of Tcl/Tk biweekly telco

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

Op ma 20 jan 2025 om 16:42 schreef Ashok:
> That led to what I think both Jan and I agreed (Jan, correct me if I misunderstood) that we have different views of how software development on the trunk should proceed. Jan's view was that if something was deemed to be a good idea based on a TIP's passage, it should be merged to trunk for more people to beat on it, test and provide patches.

What I said was that for TIP #430, that's what happened. And
it was OK, because:
 1) Trunk was meant for 8.7/9.0, which was still far away.
      That gives enough time for testing
 2) We felt that zipfs support would be the main
     must-have feature for 8.7/9.0. Having it on
     trunk means that more people would beat on it.
Now the situation changed: anything merged to trunk will
be in tcl 9.0.2, so we need to be more careful. As soon as
trunk is split off for 9.1 development, we can be less
careful on features merged to it. If we want a feature
for 9.1 (expressed by YES votes on a TIP) then it's
important to have it on trunk as soon as it is sufficiently
stable. We need to define what is "sufficiently stable",
but IMHO the most important thing is "no regression".

That's why memorymodule needs to be an opt-in
feature for 8.6 and 9.0. It's the only way to assure
there are no regressions.

Enough so far. I'll come back on it.

Thanks!
        Jan Nijtmans

Re: [TCLCORE] Report of Tcl/Tk biweekly telco

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

Ashok,

Thanks for explaining all this. Let me state I share your view about how 
development should be done in trunk.

Regards,

Francois

Le 20/01/2025 à 16:42, apnmbx-public--- via Tcl-Core a écrit :
>
> Harald, thanks for the summary but I do want to make clarifications 
> with respect to what I took away from the meeting.
>
> With respect to the memory module, the result was not "code is 
> correct, no doubt". Jan held that the code was correct in his view and 
> he was only working on tests. I contended that the code as it 
> currently stands fails even the simple test cases I provided in my 
> apn-tip-709 branch and he has not yet indicated why the tests were 
> invalid. If I understood Jan correctly, he also said the tests do not 
> show corrupt data (perhaps I misunderstood what he was saying)  and my 
> response was that one DLL writing to the private TLS data of another 
> DLL instead of its own *in the same thread* was indeed data corruption 
> by any definition of the term. But the matter is still in progress as 
> Jan works on his own tests. As of now, there is no doubt in my mind 
> the code is broken.
>
> My comments with respect to test cases were that the TCT should hold a 
> stronger position with respect to even passed TIP's being merged to 
> trunk without a reasonable test suite.
>
> That led to what I think both Jan and I agreed (Jan, correct me if I 
> misunderstood) that we have different views of how software 
> development on the trunk should proceed. Jan's view was that if 
> something was deemed to be a good idea based on a TIP's passage, it 
> should be merged to trunk for more people to beat on it, test and 
> provide patches. My view was that it is the author's responsibility 
> that should not be punted to everybody else, the most important 
> reasons being (a) this crowd-sourced testing and patching just does 
> not happen leaving the code fragile or completely broken and I can 
> give several cases in the Tcl 9 development cycle of the latter, and 
> (b) it is unfair to the rest of the contributors to be saddled with 
> the tedium of debugging, writing tests and patches. (*I'll just stress 
> this is not a comment on Jan himself!)*
>
> Jan, please add your view of the meeting as necessary. It's important 
> for everyone to get on the same page as to what we should expect of 
> commits to the trunk.
>
> It was a productive meeting indeed in thrashing out the different 
> views. Thanks
>
> /Ashok
>
> -----Original Message-----
> From: Harald Oehlmann <har...@el...>
> Sent: Monday, January 20, 2025 8:38 PM
> To: Tcl Core List <tcl...@li...>
> Subject: [TCLCORE] Report of Tcl/Tk biweekly telco
>
> Dear Tcl/Tk team,
>
> here is a report of the meeting of today.
>
> 1) Orphaned extensions
>
> Orphaned extensions may be put into a github repository.
>
> This may not be personal but under the hood of an organisation for legal
>
> reasons.
>
> Steve will contact Cliff Redler from the Tcl association, if this is
>
> possible under this hat.
>
> 2) TCT fossil forum
>
> a TCT forum was proposed for inner TCT communication. Benefit compared
>
> to E-Mail list is:
>
> - control when and how one gets notified
>
> - organisation of threads
>
> - archive
>
> 3) TCL infrastructure
>
> Recent fall-outs lead to the opinion that less infra structure is better.
>
> Another opinion is that infra structure is great if you control it.
>
> The E-Mail notification feature still does not work for the core. A
>
> participant reported, that it now works on Chiseal (which is perhaps the
>
> same machine) and he may try to fix it.
>
> 4) Tests
>
> Many new features came only with basic tests.
>
> An example is the zip file system, which only has basic tests.
>
> It was proposed to require a higher test coverage before a merge to the
>
> productive branches.
>
> On the other hand, Wizards just do and don't need tests at all.
>
> And we are happy to get their great code.
>
> Testing will happen in productive environments, (but there are anyway
>
> never issues).
>
> And the group of non-believers is charged to write tests.
>
> The discussion lead in case of the memory load module to the result:
>
> - the code is correct, no doubt
>
> - there will ne more test cases for those non believers
>
> To say it positive: we respect each others opinion and work on it - 
> great !
>
> 5) Next meeting:
>
> 2025-01-27 12:00 UTC Bi-weekly Tcl/Tk
>
> 2025-02-04 18:00 UTC Tk meeting, afterwards "Stammtisch", Harald will
>
> demonstrate Barcode scanning using tclwmf and zxing-cpp packages
>
> 2025-02-10 12:00 UTC Bi-weekly Tcl/Tk (Harald will not be available)
>
> Thank you all,
>
> Harald
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Report of Tcl/Tk biweekly telco

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

Le 20/01/2025 à 16:08, Harald Oehlmann a écrit :
> 3) TCL infrastructure
> Recent fall-outs lead to the opinion that less infra structure is better.
> Another opinion is that infra structure is great if you control it.

Scratching my head on this statement, I have to admit I have no idea 
what is meant here by "infrastructure" - it's probably not a building. 
Could you please explain?

> The E-Mail notification feature still does not work for the core. A 
> participant reported, that it now works on Chiseal (which is perhaps 
> the same machine) and he may try to fix it.

With the help of Roy Keene (many thanks again!), I got email alerts 
working for my rtext repository at Chiselapp. Now that I know how to do 
it I can easily propagate my fresh knowledge. The key that I didn't 
figure out by myself is the last two lines:

For repositories hosted at Chiselapp, go to (you need repo admin rights):
https://chiselapp.com/user/<username>/repository/<repo_name>/setup_notification

Canonical Server URL           : 
https://chiselapp.com/user/<username>/repository/<repo_name>
Administrator email address    : whatever
"Return-Path" email address    : whatever
Repository Nickname            : [repo_name]
Email Send Method              : Store in a database
Store Emails In This Database  : /data/mail.sql

For Tcl, the address is (you need repo admin rights to access it):

https://core.tcl-lang.org/tcl/setup_notification

Fossil documentation about this is here (including how to test the setup):

https://fossil-scm.org/home/doc/trunk/www/alerts.md

Regards,

Francois

Re: [TCLCORE] Report of Tcl/Tk biweekly telco

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

The “infrastructure” discussion pertained to the resources – repository hosts, wiki, web site, CI, chat  etc. – used by the community, the effort required to maintain these, single points of failure and attendant risk of unavailability (including human 😊)

 

From: Francois Vogel <fvo...@fr...> 
Scratching my head on this statement, I have to admit I have no idea what is meant here by "infrastructure" - it's probably not a building. Could you please explain?

Re: [TCLCORE] Report of Tcl/Tk biweekly telco

[Schelte B. <tc...@tc...>]

On 20/01/2025 22:20, Francois Vogel wrote:
> With the help of Roy Keene (many thanks again!), I got email alerts 
> working for my rtext repository at Chiselapp. Now that I know how to do 
> it I can easily propagate my fresh knowledge.

I knew this is how to do it on chiselapp. Unfortunately the same method 
doesn't work on core. The error indicates that the /data/mail.sql 
database does not exist. I sent a mail to Roy to ask for assistance,

Before I knew about the database, I used the SMTP relay method. I set up 
postfix on an obscure port on my server at home and punched a hole in 
the firewall to allow access from the chiselapp IP address only. That 
worked for me, but I don't think it's a feasible solution for the core 
repositories. I cannot guarantee reliability and considering that there 
are already thousands of messages queued up for the Tcl repository 
alone, I expect my ISP will block me for sending spam when those are all 
released at once through my server.

If there is some other place where we could set up a mail relay server, 
that could be an alternative.


Schelte.