tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] The revised text version as a TEA package

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

I recall being told there were issues back then, but hopefully they have been resolved.  Tablelist over the revised text widget would be a major step forward.

Thanks

-- Steve
On 13 Nov 2024 at 3:11 PM +0800, Francois Vogel <fvo...@fr...>, wrote:
> Le 13/11/2024 à 08:01, Steve Landers a écrit :
> > Excellent progress.
> >
> > Any idea if Csaba’s tablelist works with it?
>
> I didn't try. The state should be the same as with the revised_text
> branch of Tk. Csaba tried the latter a long time ago but I don't
> remember the results (which might be different today anyway).
>
> Francois
>
>
>

Re: [TCLCORE] The revised text version as a TEA package

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

Le 13/11/2024 à 08:01, Steve Landers a écrit :
> Excellent progress.
>
> Any idea if Csaba’s tablelist works with it?

I didn't try. The state should be the same as with the revised_text 
branch of Tk. Csaba tried the latter a long time ago but I don't 
remember the results (which might be different today anyway).

Francois

Re: [TCLCORE] The revised text version as a TEA package

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

Excellent progress.

Any idea if Csaba’s tablelist works with it?

-- Steve
On 13 Nov 2024 at 2:57 PM +0800, Francois Vogel <fvo...@fr...>, wrote:
> Le 10/11/2024 à 22:49, Francois Vogel a écrit :
> > I have created a repository called 'rtext' which is a first embryonic
> > attempt at providing the revised text widget as a TEA package. See:
> >
> > https://chiselapp.com/user/fvogel/repository/rtext
> >
> > Current state is that it builds for Windows, but there is nothing more
> > at all. It does not build on Linux or mac. On any platform, the tests
> > do not run, the man page does not get built, and so on.
> >
> Update: it now builds on both Windows and Linux, and the tests run 100%
> OK on both platforms.
>
> Regards,
>
> Francois
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] The revised text version as a TEA package

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

Le 10/11/2024 à 22:49, Francois Vogel a écrit :
> I have created a repository called 'rtext' which is a first embryonic 
> attempt at providing the revised text widget as a TEA package. See:
>
> https://chiselapp.com/user/fvogel/repository/rtext
>
> Current state is that it builds for Windows, but there is nothing more 
> at all. It does not build on Linux or mac. On any platform, the tests 
> do not run, the man page does not get built, and so on.
>
Update: it now builds on both Windows and Linux, and the tests run 100% 
OK on both platforms.

Regards,

Francois

[TCLCORE] Proposed Tk telco on 26th of November 18:00 UTC

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

Dear Tk team,
Kevin, Marc: thank you for your answers about Tk.
I think, it would be great to make a special Tk telco to support Don 
Porter on some points.
As Kevin, Marc and Don are to my knowledge in the US.
What about a US friendly meeting on
26th of November at 18:00 UTC on Jitzi for one hour?

The points are:
- Release schedule of Tk
- New text widget now loadable module
- AOB

Any other active Tk developer is also invited: Jan, Csaba, Brian, 
Francois, Schelte, Peter, ...

You may also send me a private E-Mail in case of availability or request 
to other time slots.
My own time schedule is restraint on evenings and Steve is hopefully 
sleeping at the proposed time.

Thank you all,
Harald

Re: [TCLCORE] Report of TCL Biweekly Monday meeting

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

On 12 Nov 2024 at 10:29 AM +0800, Kevin Walzer <kw...@co...>, wrote:
> I agree with Marc that a regular cadence of releases for Tcl and Tk is preferred. Let’s say that 9.1 ships in September 2025, 9.2 ships in September 2026, and so on. Whatever features aren’t ready just roll inside the next.
This I agree with.
> To me that makes more sense than an aggressive schedule for Tk and no defined schedule for Tcl.
No one is suggesting an aggressive schedule for Tk and no defined schedule for Tcl.  What is being suggested is a defined schedule for both, but Tk is free to evolve more quickly should that be necessary or desirable. The specific situations I envisage might be to support a new version of an operating system or windowing system, new themes becoming available, a new widget or important bug fixes. Why should Tk be constrained by Tcl’s release schedule?

-- Steve
> 8.6.0 was released in 2012. 8.6.15 was released in 2024. Surely we can do better than that with 9.x.
>
> > On Nov 11, 2024, at 8:40 PM, Marc Culler <cul...@gm...> wrote:
> >
> > On Mon, Nov 11, 2024 at 7:59 AM Harald Oehlmann <har...@el...> wrote:
> > > Other points were postponed due to time lack and missing people:
> > > - Tcl/Tk separation
> >
> > I have a comment about this issue, which I think means that Tcl releases and Tk releases would be allowed to happen on different schedules.
> > While I don't object to this, I also don't understand what problem it aims to solve.  On the other hand there is something related to Tcl and Tk releases which I think would solve a real problem, especially for projects which package Tcl and Tk.  That is for Tcl and Tk to have an announced release schedule.  If it were announced that a new release of Tcl and Tk would be targeted to happen at regular intervals, say once a year in June for example, I think it would simplify the work of projects which have regular release schedules of their own and whose releases depend upon Tcl and Tk.  I am thinking specifically of Python, but I imagine that this also applies to Ruby and Perl, at least.
> >
> > - Marc
> >
> >
> > _______________________________________________
> > 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

Re: [TCLCORE] Report of TCL Biweekly Monday meeting

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

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><img width="1" height="1" src='https://fedbdhd.r.af.d.sendibt2.com/tr/op/Ur9uXYhd9DmsbcwB3lXApLXtfNrE1U89Zalyv8u94xSKA_nQaJPlsvswBM8hB4JI8dxZs81ZSPQoAH6GWqofZAOtQMM1zCc0QfkY09Xr5KIFEBCqCmhUVu5ChgTOYAxr4ffOtVcRD12_kDy6C1hvro8hmh1v9X5RJujN257BUd8bWpyfB-Vr-hN0WPgAHBUZSPIDoCDsETGB0xoOhIRlNe2UgH9uc-Kj' /><div dir="ltr"></div><div dir="ltr">I agree with Marc that a regular cadence of releases for Tcl and Tk is preferred. Let’s say that 9.1 ships in September 2025, 9.2 ships in September 2026, and so on. Whatever features aren’t ready just roll inside the next. To me that makes more sense than an aggressive schedule for Tk and no defined schedule for Tcl.&nbsp;</div><div dir="ltr"><br></div><div dir="ltr">8.6.0 was released in 2012. 8.6.15 was released in 2024. Surely we can do better than that with 9.x.&nbsp;</div><div dir="ltr"><br><blockquote type="cite">On Nov 11, 2024, at 8:40 PM, Marc Culler &lt;cul...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Nov 11, 2024 at 7:59 AM Harald Oehlmann &lt;<a href="mailto:har...@el...">har...@el...</a>&gt; wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Other points were postponed due to time lack and missing people:<br>
- Tcl/Tk separation<br></blockquote><div><br></div><div>I have a comment about this issue, which I think means that Tcl releases and Tk releases would be allowed to happen on different schedules.&nbsp;&nbsp;</div><div>While I don't object to this, I also don't understand what problem it aims to solve.&nbsp; On the other hand there is something related to Tcl and Tk releases which I think would solve a real problem, especially for projects which package Tcl and Tk.&nbsp; That is for Tcl and Tk to have an announced release schedule.&nbsp; If it were announced that a new release of Tcl and Tk would be targeted to happen at regular intervals, say once a year in June for example, I think it would simplify the work of projects which have regular release schedules of their own and whose releases depend upon Tcl and Tk.&nbsp; I am thinking specifically of Python, but I imagine that this also applies to Ruby and Perl, at least.</div><div><br></div><div>- Marc <br></div><div>&nbsp;</div><div><br>
</div></div></div>
<span>_______________________________________________</span><br><span>Tcl-Core mailing list</span><br><span>Tcl...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/tcl-core</span><br></div></blockquote></body></html>

Re: [TCLCORE] Report of TCL Biweekly Monday meeting

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

Decoupling (or loosely coupling) Tcl and Tk allows Tk to evolve more quickly than Tcl. By loosely coupling I mean there would always be a Tk release concurrent with Tcl (with the same version numbering) but the may be more frequent Tk releases with version numbers based off that.  For example, we might choose to release a new Tk version when new themes become available.  Or for fixes to a widget.  There’s no reason why those should wait to Tcl, especially a Tk is now a loadable package like any other.

I would be happy to see a fixed (perhaps yearly) schedule for Tcl+Tk as well. That will at least give us a target to aim for.

-- Steve
On 12 Nov 2024 at 9:40 AM +0800, Marc Culler <cul...@gm...>, wrote:
> On Mon, Nov 11, 2024 at 7:59 AM Harald Oehlmann <har...@el...> wrote:
> > > Other points were postponed due to time lack and missing people:
> > > - Tcl/Tk separation
> >
> > I have a comment about this issue, which I think means that Tcl releases and Tk releases would be allowed to happen on different schedules.
> > While I don't object to this, I also don't understand what problem it aims to solve.  On the other hand there is something related to Tcl and Tk releases which I think would solve a real problem, especially for projects which package Tcl and Tk.  That is for Tcl and Tk to have an announced release schedule.  If it were announced that a new release of Tcl and Tk would be targeted to happen at regular intervals, say once a year in June for example, I think it would simplify the work of projects which have regular release schedules of their own and whose releases depend upon Tcl and Tk.  I am thinking specifically of Python, but I imagine that this also applies to Ruby and Perl, at least.
> >
> > - Marc
> >
> >
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Report of TCL Biweekly Monday meeting

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

On Mon, Nov 11, 2024 at 7:59 AM Harald Oehlmann <har...@el...>
wrote:

> Other points were postponed due to time lack and missing people:
> - Tcl/Tk separation
>

I have a comment about this issue, which I think means that Tcl releases
and Tk releases would be allowed to happen on different schedules.
While I don't object to this, I also don't understand what problem it aims
to solve.  On the other hand there is something related to Tcl and Tk
releases which I think would solve a real problem, especially for projects
which package Tcl and Tk.  That is for Tcl and Tk to have an announced
release schedule.  If it were announced that a new release of Tcl and Tk
would be targeted to happen at regular intervals, say once a year in June
for example, I think it would simplify the work of projects which have
regular release schedules of their own and whose releases depend upon Tcl
and Tk.  I am thinking specifically of Python, but I imagine that this also
applies to Ruby and Perl, at least.

- Marc

Re: [TCLCORE] Report of TCL Biweekly Monday meeting

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

 
Sorry, I am on the road and could not make the call.
I have no problems with withdrawing TIP 702 and shipping reg and dde as separate dll's.
/Ashok
    On Monday, November 11, 2024 at 07:30:00 PM GMT+5:30, Harald Oehlmann <har...@el...> wrote:  
 
 Dear Tcl/Tk group,

thanks for your participation and support.

The points were:

- Licence issues
It was made clear by founding members of TCL that the BSD Licence was 
always the only accepted licence for TCL and all core parts including 
TCLLib.
This will be made more clear and any non-acceptance of this rule should 
be solved.
- Copyright statement
Copyright statements should be replaced by credit statements. Only the 
addition of the TCL association as copyright holder is allowed within 
TCL and friends. As current copyrights may not be removed without the 
authors permission, new copyright statements should not happen.
- Merge Order
It was focused that bug fixing should be focused on TCL 9 and only parts 
should be backported to TCL 8.6. The amendmend of TIP 386 is not seen as 
possibility. A new TIP should be authored. This may also specify what is 
back-ported and how.
- TIP 702/703, Windows Registry/DDE packages in zip or static
Ashok was not on the call, so only partial discussion.
Jan and Harald seeing it critical to make registry/dde package static.
The dll issue and temporary folders should be solved in general.
Getting them out of the zip is a temporary solution, as there are also 
other dll's out there (zip.dll, libtommath.dll).
The dll in zip issue should be solved in general.
TIP 703: Making time zone and locale detection a core command (instead 
of a registry lookup) is seen as an advantages, as APIs may be used 
instead of registry lookup, which is more future proof and reliable. Jan 
wants to wait for 9.1 with this change.
- Parallel installation of TCL/Tk8.6 and 9.0
Reinhard Max mentioned, that the "with-tcl8" mechanism crashes with a 
stubs null pointer, if an extension uses tcl and tk. The example was the 
Tix extension. Jan answered, that this might be the case and asked 
Reinhard to file a ticket in tk.
- Tcl 9.0.1 preparation
It was underlined, that most people are still in bug-fixing mode and 
don't look for new features.
- Time zone text issue
Sergey underlined this ticket via E-Mail:
https://core.tcl-lang.org/tcl/info/2c237beffbace823
The group sees this as critical and as a reason to do a 8.6 release soon 
(December).

Other points were postponed due to time lack and missing people:
- Tcl/Tk separation
- documentation reform
- critical packages to port to 9

Next meeting will be 25th of November 12:00 UTC on Jitzi.

Thank you for all,
Harald

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

Re: [TCLCORE] TIP 702 CFV Warning

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

Am 06.11.2024 um 12:58 schrieb apnmbx-public--- via Tcl-Core:
> The current mechanism (in the default build config with embedded zip) of 
> writing a DLL out to disk and loading it has issues on Windows as 
> described in the TIP. Static linking is proposed as a solution. If this 
> is not acceptable for whatever reason, at the very least, Jan’s proposal 
> of not including the DLL’s in the ZIP but instead shipping them 
> separately is an alternative that should be considered as the current 
> situation is the least desirable of the three options.
> 
> Personally, I prefer a single binary with all core functionality as that 
> was the whole purpose behind embedded ZIP’s but I could live with Jan’s 
> suggestion as well.
> 
> /Ashok
Ashok,
I am seeing the TIP as critical.

I see TIP 703 to solve the time zone/locale request by commands/API as 
better. The registry package is then only required by 3rd party action. 
The dde package is anyway a bit outside.

If put as fix parts into the core, I would totally vanish the DLL and 
the requirement of "package require". That would be ok, but for 9.1.

The vulnerability by virus checkers to take those dlls as hostile was 
also my concern. But in the last time, I don't see that any more by any 
virus checker.
I often supposed, that this was an issue with zip-kits, but it never 
was. The reason often was the direct download of the exe, which then was 
marked as hostile. An installation routine solved this.

I would also love to solve the dll reuse issue in general with the 
zipkits. Then, the registry/dde does not make any issue any more.

Currently, we have 2 external dll's in the standard distribution: 
libtommath and zip.
Adding two additional external dll's in the standard distribution would 
not make a big difference.

Sorry.
Thank you for all,
Harald

[TCLCORE] Report of TCL Biweekly Monday meeting

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

Dear Tcl/Tk group,

thanks for your participation and support.

The points were:

- Licence issues
It was made clear by founding members of TCL that the BSD Licence was 
always the only accepted licence for TCL and all core parts including 
TCLLib.
This will be made more clear and any non-acceptance of this rule should 
be solved.
- Copyright statement
Copyright statements should be replaced by credit statements. Only the 
addition of the TCL association as copyright holder is allowed within 
TCL and friends. As current copyrights may not be removed without the 
authors permission, new copyright statements should not happen.
- Merge Order
It was focused that bug fixing should be focused on TCL 9 and only parts 
should be backported to TCL 8.6. The amendmend of TIP 386 is not seen as 
possibility. A new TIP should be authored. This may also specify what is 
back-ported and how.
- TIP 702/703, Windows Registry/DDE packages in zip or static
Ashok was not on the call, so only partial discussion.
Jan and Harald seeing it critical to make registry/dde package static.
The dll issue and temporary folders should be solved in general.
Getting them out of the zip is a temporary solution, as there are also 
other dll's out there (zip.dll, libtommath.dll).
The dll in zip issue should be solved in general.
TIP 703: Making time zone and locale detection a core command (instead 
of a registry lookup) is seen as an advantages, as APIs may be used 
instead of registry lookup, which is more future proof and reliable. Jan 
wants to wait for 9.1 with this change.
- Parallel installation of TCL/Tk8.6 and 9.0
Reinhard Max mentioned, that the "with-tcl8" mechanism crashes with a 
stubs null pointer, if an extension uses tcl and tk. The example was the 
Tix extension. Jan answered, that this might be the case and asked 
Reinhard to file a ticket in tk.
- Tcl 9.0.1 preparation
It was underlined, that most people are still in bug-fixing mode and 
don't look for new features.
- Time zone text issue
Sergey underlined this ticket via E-Mail:
https://core.tcl-lang.org/tcl/info/2c237beffbace823
The group sees this as critical and as a reason to do a 8.6 release soon 
(December).

Other points were postponed due to time lack and missing people:
- Tcl/Tk separation
- documentation reform
- critical packages to port to 9

Next meeting will be 25th of November 12:00 UTC on Jitzi.

Thank you for all,
Harald

Re: [TCLCORE] GPL Licence in TCLLib added

[Arjen M. <Arj...@de...>]

Hi everyone,

I found an alternative implementation. While I have not studied it in any detail yet, it offers a variety of filters (low, high, band, …). So, it is richer in that respect than the one I had before 😊.

Regards,

Arjen

From: Arjen Markus via Tcl-Core <tcl...@li...>
Sent: woensdag 6 november 2024 14:41
To: Kevin Walzer <kw...@co...>; tcl...@li...
Subject: Re: [TCLCORE] GPL Licence in TCLLib added

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de...<mailto:Ser...@de...>" as an attachment.

Hi everyone,

I indeed intend to revise the code, so that no GPL dependency is left. The algorithms are simple enough to rewrite them from scratch.

(The idea of a separate library that contains contributions with a different and incompatible license might be worth elaborating, but that is a very different matter and should be discussed in some detail.)

Regards,

Arjen

From: Kevin Walzer <kw...@co...<mailto:kw...@co...>>
Sent: woensdag 6 november 2024 13:01
To: tcl...@li...<mailto:tcl...@li...>
Subject: Re: [TCLCORE] GPL Licence in TCLLib added

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de...<mailto:Ser...@de...>" as an attachment.


On 11/6/24 6:08 AM, Poor Yorick wrote:

> "Contagious" is a mischaracterization.  A project chooses derive its
> work from
> a GPL-licensed work or not.  It doesn't involuntarily "get infected".
> filtergen.tcl is licensed under the GPL, and if it disappears from
> Tcllib,
> where will it be placed?  Some other GPL analogue of Tcllib?  The
> point of
> Tcllib is to make it easier for projects to get their hands on
> software they
> want to use.  Why not then just have branch in Tcllib for such
> things?  Or even
> better just make the license clear and let projects choose for
> themselves what
> works from Tcllib they will use?

The obvious answer to this question is that filtergen.tcl will be
updated with a clean implementation not derived from GPL code, or it
will be removed altogether. That's exactly the choice that the GPL
requires.

The point of tcllib is indeed "to make it easier to projects to get
their hands on projects they want to use." But tcllib has already has a
license, the BSD-style Tcl licnese, and the GPL is not compatible with
this license from the standpoint of developer freedom. That is, if a
developer wants to make code proprietary/closed-source, then any
copyleft-licensed code must be avoided.

--Kevin
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

Re: [TCLCORE] The revised text version as a TEA package

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

Le 11/11/2024 à 06:41, Christian Gollwitzer via Tcl-Core a écrit :
> Am 10.11.24 um 22:49 schrieb Francois Vogel:
>> The next thing to solve is that it crashes during revised text widget
>> instantiation because tkStubsPtr is NULL. I know nothing about stubs so
>> far, and would be happy to get some help here. Thanks.
>
> This is rather trivial. Stubs must be initialised in the Init function.

Oh, yes, thanks! Sounds so trivial when stated. Thanks a lot!

> Note, that you requested version 9.0 for Tcl, so the package will not
> load in 8.6 (is this intended?) Similarly, you must state the minimum Tk
> version in the init function.

Yes, this is intended, at least at this very early stage. The revised 
text version is tested against Tk trunk for a long time, not with 8.6.

Thanks again for your help.

Regards,

Francois

Re: [TCLCORE] The revised text version as a TEA package

[Christian G. <aur...@gm...>]

Am 10.11.24 um 22:49 schrieb Francois Vogel:
>
> Le 08/11/2024 à 18:09, Donald Porter via Tcl-Core a écrit :
>>> On Nov 8, 2024, at 12:00 PM, Harald Oehlmann<har...@el...> wrote:
>>>
>>> Don is asking to raise the question of decoupeling Tcl and Tk - we will do. As this was already adressed last time with the result: yes, Tk minor releases without Tcl possible - what is your additional question?
>> At the previous meeting, we were all nodding in agreement about what we thought was a good idea without the actual major players in Tk development present to offer their perspective.  Looking for confirmation and formation of whatever needs forming to carry out the plans.
>
> Hi all,
>
> I won't attend the call, sorry.
>
> That said let me take this opportunity to inform everybody I have
> created a repository called 'rtext' which is a first embryonic attempt
> at providing the revised text widget as a TEA package. See:
>
> https://chiselapp.com/user/fvogel/repository/rtext
>
> Current state is that it builds for Windows, but there is nothing more
> at all. It does not build on Linux or mac. On any platform, the tests do
> not run, the man page does not get built, and so on.
>
> The next thing to solve is that it crashes during revised text widget
> instantiation because tkStubsPtr is NULL. I know nothing about stubs so
> far, and would be happy to get some help here. Thanks.
>

This is rather trivial. Stubs must be initialised in the Init function.
YOu do this for Tcl stubs:

  if (Tcl_InitStubs(interp, "9.0", 0) == NULL) {
	return TCL_ERROR;
     }


Now you just need the same for TkStubs:

  if (Tk_InitStubs(interp, "9.0", 0) == NULL) {
	return TCL_ERROR;
     }



Note, that you requested version 9.0 for Tcl, so the package will not
load in 8.6 (is this intended?) Similarly, you must state the minimum Tk
version in the init function.

          Christian

Re: [TCLCORE] Reminder on TCL call next Monday 11th of November 2024 at 12:00 UTC

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

Op vr 8 nov 2024 om 11:33 schreef Harald Oehlmann:
> Possible points are:
> - Tcl/Tk 9.0.1 release preparation
> - TIP 702/703 strategy MS-Windows registry/dde packages - I hope Ashok
> and Jan will be present
> - Parallel distribution of Tcl/Tk 8.6 and Tcl/Tk 9 on Linux
> - TIP 700: documentation and presentation project
> - Make critical packages TCL/Tk 9 ready
> - TCL/Tk 8.7 release or not
> - Doing Tk 9 releases without TCL 9 releases

Two more possible points:
- Currently, all CI builds on macOS (--enable-symbols=all) are
  broken, due to this commit:
    <https://core.tcl-lang.org/tcl/info/b56973969223f1e2>
  This commit was done to core-8-6-branch, but immediately
  forwarded to core-8-branch and trunk. Result: 3 broken
  branches. How do we deal with this? I think it's a blokker
  for 9.0.1 and/or 8.6.16.
- How do we deal with branches (in Tcl and tcllib) with a
  different licence? Do we allow it? If not, how do we
  prevent this from happening/undo the damage?

See you tomorrow (hopefully)
     Jan Nijtmans

[TCLCORE] The revised text version as a TEA package

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

Le 08/11/2024 à 18:09, Donald Porter via Tcl-Core a écrit :
>> On Nov 8, 2024, at 12:00 PM, Harald Oehlmann<har...@el...> wrote:
>>
>> Don is asking to raise the question of decoupeling Tcl and Tk - we will do. As this was already adressed last time with the result: yes, Tk minor releases without Tcl possible - what is your additional question?
> At the previous meeting, we were all nodding in agreement about what we thought was a good idea without the actual major players in Tk development present to offer their perspective.  Looking for confirmation and formation of whatever needs forming to carry out the plans.

Hi all,

I won't attend the call, sorry.

That said let me take this opportunity to inform everybody I have 
created a repository called 'rtext' which is a first embryonic attempt 
at providing the revised text widget as a TEA package. See:

https://chiselapp.com/user/fvogel/repository/rtext

Current state is that it builds for Windows, but there is nothing more 
at all. It does not build on Linux or mac. On any platform, the tests do 
not run, the man page does not get built, and so on.

The next thing to solve is that it crashes during revised text widget 
instantiation because tkStubsPtr is NULL. I know nothing about stubs so 
far, and would be happy to get some help here. Thanks.

If you want to check this out on Windows, please see recipe pasted below.

The big advantage of this TEA approach is that one should be able to 
have both the legacy and the revised versions of the text widget at the 
same time. And it saves us from making the terrible decision to replace 
the legacy widget by the revised version in the distributed Tk.

As I said, this is *very* embryonic --> Don't expect anything at this 
stage. Help to push this forward is very welcome.

Regards,

Francois

---------------------

My build recipe for Windows with Visual Studio (please adapt as needed):

REM Tcl /Tk 9 must have been built and installed first. REM Tcl 9 and Tk 
9 source code directories set 
MYTCL="C:\Users\francois\Documents\Development\tcltk-fossil\tcl" set 
MYTK="C:\Users\francois\Documents\Development\tcltk-fossil\tk" REM 
Tcl/Tk 9 installation directory set 
MYTCLTK="C:\Users\francois\Documents\Development\tcltk-fossil\tcltk" set 
DEBUGRELEASE="symbols" CALL "C:\Program Files\Microsoft Visual 
Studio\2022\Community\VC\Auxiliary\Build\vcvarsall.bat" x86_amd64 cd 
C:\Users\francois\Documents\Development\tcltk-fossil\rtext\win nmake -f 
makefile.vc TCLDIR=%MYTCL% TKDIR=%MYTK% INSTALLDIR=%MYTCLTK% 
OPTS=%DEBUGRELEASE% clean nmake -f makefile.vc TCLDIR=%MYTCL% 
TKDIR=%MYTK% INSTALLDIR=%MYTCLTK% OPTS=%DEBUGRELEASE% nmake -f 
makefile.vc TCLDIR=%MYTCL% TKDIR=%MYTK% INSTALLDIR=%MYTCLTK% 
OPTS=%DEBUGRELEASE% install

Then fire tclsh90.exe and run:

     package require Tk
     package require rtext
     rtext::build-info
     ::tk::text .lt    ; # legacy
     text .rt          ; # revised (crashes at this stage)

Re: [TCLCORE] Reminder on TCL call next Monday 11th of November 2024 at 12:00 UTC

[Dipl. I. S. G. B. <se...@us...>]

 

It is not THE CLOCK PATTERN "%Z", but the TZ-NAME in many
timezone-definitions in library/tzdata got "%z" in 8.6.15, 
instead of for instance "±0100"...
As mentioned in the ticket, the regression was [9275edd424971958] [2]
and how one can see, that affects many tzdata files.
To be more clear, all scan- and format-attempts could be affected, where
current TZ (and the timestamp) would 
match or result to such zone blocks, for instance: 

% clock format [clock seconds] -timezone :Pacific/Norfolk;
Sat Nov 09 06:17:17 %Z 2024
% clock format [clock seconds] -timezone :Etc/GMT-1;
Fri Nov 08 20:17:18 %Z 2024

Regards,
Serg. 

08.11.2024 18:00, Harald Oehlmann wrote: 

> Sergey has reported the following issue: 
> 
> https://core.tcl-lang.org/tcl/info/2c237beffbace823 [1]
> Sergey sees this as very critical and as a reason to quickly re-release 8.6.16.
> The clock pattern "%z" is giving wrong answers which is felt as critical.
 

Links:
------
[1] https://core.tcl-lang.org/tcl/info/2c237beffbace823
[2] https://core.tcl-lang.org/tcl/info/9275edd424971958

Re: [TCLCORE] Reminder on TCL call next Monday 11th of November 2024 at 12:00 UTC

[Donald P. <d.g...@co...>]

> On Nov 8, 2024, at 12:00 PM, Harald Oehlmann <har...@el...> wrote:
> 
> Am 08.11.2024 um 11:33 schrieb Harald Oehlmann:
>> Dear TCL/Tk team,
>> the next TCL/Tk call will take place on jitzi:
>> Monday 11th of November 2024 at 12:00 UTC
>> Possible points are:
>> - Tcl/Tk 9.0.1 release preparation
>> - TIP 702/703 strategy MS-Windows registry/dde packages - I hope Ashok and Jan will be present
>> - Parallel distribution of Tcl/Tk 8.6 and Tcl/Tk 9 on Linux
>> - TIP 700: documentation and presentation project
>> - Make critical packages TCL/Tk 9 ready
>> - TCL/Tk 8.7 release or not
>> - Doing Tk 9 releases without TCL 9 releases
>> https://meet.jit.si/TclMonthlyMeetup
>> Thank you and take care,
>> Harald
> Amendmend to the invitation:
> 
> Sorry to place the meeting on Thanksgiving - one of the highest days in the US. Please allow the rest to meet. Next meeting will be 25th of November 2024.

November 11 is Veterans Day / Armistice Day.

For future planning, USA Thanksgiving Day is Thursday, November 28.

> Don is asking to raise the question of decoupeling Tcl and Tk - we will do. As this was already adressed last time with the result: yes, Tk minor releases without Tcl possible - what is your additional question?

At the previous meeting, we were all nodding in agreement about what we thought was a good idea without the actual major players in Tk development present to offer their perspective.  Looking for confirmation and formation of whatever needs forming to carry out the plans.

> Sergey has reported the following issue:
> https://core.tcl-lang.org/tcl/info/2c237beffbace823
> Sergey sees this as very critical and as a reason to quickly re-release 8.6.16.
> The clock pattern "%z" is giving wrong answers which is felt as critical.

Good to know about.  Will take a look.

DGP

Re: [TCLCORE] Reminder on TCL call next Monday 11th of November 2024 at 12:00 UTC

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

Am 08.11.2024 um 11:33 schrieb Harald Oehlmann:
> Dear TCL/Tk team,
> 
> the next TCL/Tk call will take place on jitzi:
> Monday 11th of November 2024 at 12:00 UTC
> 
> Possible points are:
> - Tcl/Tk 9.0.1 release preparation
> - TIP 702/703 strategy MS-Windows registry/dde packages - I hope Ashok 
> and Jan will be present
> - Parallel distribution of Tcl/Tk 8.6 and Tcl/Tk 9 on Linux
> - TIP 700: documentation and presentation project
> - Make critical packages TCL/Tk 9 ready
> - TCL/Tk 8.7 release or not
> - Doing Tk 9 releases without TCL 9 releases
> 
> https://meet.jit.si/TclMonthlyMeetup
> 
> Thank you and take care,
> Harald
Amendmend to the invitation:

Sorry to place the meeting on Thanksgiving - one of the highest days in 
the US. Please allow the rest to meet. Next meeting will be 25th of 
November 2024.

Don is asking to raise the question of decoupeling Tcl and Tk - we will 
do. As this was already adressed last time with the result: yes, Tk 
minor releases without Tcl possible - what is your additional question?

Sergey has reported the following issue:
https://core.tcl-lang.org/tcl/info/2c237beffbace823
Sergey sees this as very critical and as a reason to quickly re-release 
8.6.16.
The clock pattern "%z" is giving wrong answers which is felt as critical.

Thank you, enjoy the week-end, enjoy thanksgiving and see you next 
Monday 12:00 UTC.

Harald

[TCLCORE] Reminder on TCL call next Monday 11th of November 2024 at 12:00 UTC

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

Dear TCL/Tk team,

the next TCL/Tk call will take place on jitzi:
Monday 11th of November 2024 at 12:00 UTC

Possible points are:
- Tcl/Tk 9.0.1 release preparation
- TIP 702/703 strategy MS-Windows registry/dde packages - I hope Ashok 
and Jan will be present
- Parallel distribution of Tcl/Tk 8.6 and Tcl/Tk 9 on Linux
- TIP 700: documentation and presentation project
- Make critical packages TCL/Tk 9 ready
- TCL/Tk 8.7 release or not
- Doing Tk 9 releases without TCL 9 releases

https://meet.jit.si/TclMonthlyMeetup

Thank you and take care,
Harald

Re: [TCLCORE] TIP 702 CFV Warning

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

Op wo 6 nov 2024 om 21:48 schreef Jan Nijtmans <jan...@gm...>:

> That's long enough for now.
>

    % package require dde 1.4
    version conflict for package "dde": have 9.0.1, need 1.4
    %

This is a potential incompatibility. Any legacy script using
dde/registry, checking for a specific version needs to
be updated.
    % package require dde 1.4-
    9.0.1
    %
This should be added to the migration documents, if
TIP #702 is accepted.

Regards,
      Jan Nijtmans

Re: [TCLCORE] GPL Licence in TCLLib added

[Poor Y. <org...@po...>]

On 2024-11-06 23:08, Kevin Walzer wrote:
> But what organization would take that risk?

There's no risk.  The GPL goes to some length to articulate that point.

-- 
Yorick

Re: [TCLCORE] GPL Licence in TCLLib added

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

<div><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/rdwe2XDx4Ud7y0e8TiwNWhjomL3yG8YDT8qsyqVIuFOxVKDZXM-7e_GlHZEK1Of5uOEewdeUhFVdlgvldAQ3QqLX7PAIrO74eD8L3JdItAVnW1aR6LoXgpZGAmMFrW38K1MOdvliVekMz4s4o_jLGVpOSLE7l8kCU3pbv4A03WnesZoho95jDdgN8K6neLCQaPqRB8_spzl2tvWojJotQtFyh3cqdqWG' /></div>But what organization would take that risk?<br/><br/>> On Nov 6, 2024, at 3:52 PM, Poor Yorick <org...@po...> wrote:<br/>> <br/>> A work that included Tcllib wholesale, but did not then itself use any GPL<br/>> licensed code from Tcllib, would not be de-facto in breach of the GPL.  The<br/>> only way the work would be considered derivative is if it depended functionally<br/>> on code licensed under the GPL<br/>

Re: [TCLCORE] GPL Licence in TCLLib added

[Poor Y. <org...@po...>]

On 2024-11-06 14:28, msc...@po... wrote:
> Am 06.11.2024 12:08 schrieb Poor Yorick:
>> 
>> "Contagious" is a mischaracterization.  A project chooses derive its 
>> work from
>> a GPL-licensed work or not.  It doesn't involuntarily "get infected".
>> filtergen.tcl is licensed under the GPL, and if it disappears from 
>> Tcllib,
>> where will it be placed?  Some other GPL analogue of Tcllib?  The 
>> point of
>> Tcllib is to make it easier for projects to get their hands on 
>> software they
>> want to use.  Why not then just have branch in Tcllib for such things? 
>>  Or even
>> better just make the license clear and let projects choose for 
>> themselves what
>> works from Tcllib they will use?
> 
> It is indeed contagious in a certain way.
> 
> Tcllib gets distributed by various groups. Linux distros, commercial 
> programs etc.
> By including a (A)GPL licensed module, you suddenly make distribution 
> of the whole
> tcllib much much harder (or impossible) for lots of organisations, even 
> for unused modules,
> as GPL talks about distribution mostly.
> Thats contagious.
> 

A work that included Tcllib wholesale, but did not then itself use any 
GPL
licensed code from Tcllib, would not be de-facto in breach of the GPL.  
The
only way the work would be considered derivative is if it depended 
functionally
on code licensed under the GPL.

-- 
Yorick