tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] GPL Licence in TCLLib added

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

On 2024-11-05 16:39, Jan Nijtmans wrote:
> Op di 5 nov 2024 om 15:23 schreef Poor Yorick:
> 
>> modules/math/filtergen.tcl is GPL.
>> 
> 
> Well, I'm happy to report that filtergen.tcl is
> not GPL. It was derived from javascript code,
> which is GPL. The License for tcllib
> can be found in ./license.terms or in
> devdoc/tcllib_license.man
> 
> Hope this helps,
>            Jan Nijtmans

Uh... that makes filtergen.tcl GPL.

-- 
yorick

Re: [TCLCORE] GPL Licence in TCLLib added

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

Op di 5 nov 2024 om 15:23 schreef Poor Yorick:

> modules/math/filtergen.tcl is GPL.
>

Well, I'm happy to report that filtergen.tcl is
not GPL. It was derived from javascript code,
which is GPL. The License for tcllib
can be found in ./license.terms or in
devdoc/tcllib_license.man

Hope this helps,
           Jan Nijtmans

Re: [TCLCORE] GPL Licence in TCLLib added

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

On 2024-11-05 16:03, Jan Nijtmans wrote:
> Op di 5 nov 2024 om 14:40 schreef Poor Yorick:
> 
>> There is already GPL-licensed code in trunk (not by me), so this isn't
>> necessarily true.
>> 
> 
> The only GPL-licensed stuff I know of is in compat/zlib/contrib.
> It isn't used by Tcl at all. minizip is not GPL,
> 
> The output of the Bison parser is not protected by GPL
> either, but you will find the GPL license in tclDate.c
> Just read the "a special exception" in there.
> 
modules/math/filtergen.tcl is GPL.

-- 
Yorick

Re: [TCLCORE] GPL Licence in TCLLib added

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

Op di 5 nov 2024 om 14:40 schreef Poor Yorick:

> There is already GPL-licensed code in trunk (not by me), so this isn't
> necessarily true.
>

The only GPL-licensed stuff I know of is in compat/zlib/contrib.
It isn't used by Tcl at all. minizip is not GPL,

The output of the Bison parser is not protected by GPL
either, but you will find the GPL license in tclDate.c
Just read the "a special exception" in there.

What's not allowed is re-licensing, like in this commit:
    <Tcl Source Code: Check-in [d8a3450f12]
<https://core.tcl-lang.org/tcl/info/d8a3450f12e5bfaf>>
You can ask your lawyer if things are unclear.

Regards,
      Jan Nijtmans

Re: [TCLCORE] GPL Licence in TCLLib added

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

On 2024-11-01 13:28, Jan Nijtmans wrote:
> Op vr 1 nov 2024 om 12:19 schreef Jan Nijtmans 
> <jan...@gm...>:
> 
>> Conclusion: No problem at all, just a waste of time.
>> 
> 
> Note that the "module-aes" branch cannot be merged to "trunk" as well.
> Same reason, same person.
> 

There is already GPL-licensed code in trunk (not by me), so this isn't 
necessarily true.

-- 
Yorick

Re: [TCLCORE] GPL Licence in TCLLib added

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

On 2024-11-04 12:33, Dipl. Ing. Sergey G. Brester via Tcl-Core wrote:
> I guess, because fossil isn't really distributed SCM - I don't know any
> way to have 2 or more
> remotes (like git does), so his changes could not be pushed to 
> different
> repo (by retaining pull from core).
>  This is one the largest advantages of git, imho.
> And private branches in fossil are really private - they would not be
> synchronized at all
> and remain completely local.
> 
> I don't know why Nathan cannot switch to git (using fossil mirror for
> pull and then push his branches
> to some git-remote, like I do), but probably some historical thing.
> 
> As for the behaviour that shouldn't be allowed...
> Hmm... I can only criticize the strange method, he uses to hold the
> branches synchronized with tcl-core -
> for some reason instead of simple periodic merge, every commit will be
> repeated (cherry-picked).
> The bottom line this causes a lot of data in the repository and
> duplicates the number of commits.
> 

It's not a lot more data.  A single commit of a regenerated file like
"configure" adds more data than lots and lots of "normal" commits.  I 
was
considering switching to git but didn't, mostly due to inertia.

-- 
Yorick

Re: [TCLCORE] GPL Licence in TCLLib added

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

 

I guess, because fossil isn't really distributed SCM - I don't know any
way to have 2 or more 
remotes (like git does), so his changes could not be pushed to different
repo (by retaining pull from core).
 This is one the largest advantages of git, imho.
And private branches in fossil are really private - they would not be
synchronized at all 
and remain completely local. 

I don't know why Nathan cannot switch to git (using fossil mirror for
pull and then push his branches 
to some git-remote, like I do), but probably some historical thing. 

As for the behaviour that shouldn't be allowed... 
Hmm... I can only criticize the strange method, he uses to hold the
branches synchronized with tcl-core - 
for some reason instead of simple periodic merge, every commit will be
repeated (cherry-picked). 
The bottom line this causes a lot of data in the repository and
duplicates the number of commits. 

Regards,
Serg. 

02.11.2024 02:49, Emiliano wrote: 

> The real question is: why is someone (ab)using the limited resources of the
> Tcl community at large to pursuit its own personal agenda?
> 
> Why isn't he pulling Tcl changes on his own personal fork (something it's
> perfectly allowed in the Tcl license) instead of commiting to Tcl repos?.
> 
> IMO these kind of behaviour shouldn't be allowed at all in all tcl related
> repos (Tcl/Tk core, tcllib, tklib, etc) since we have limited man power and
> bandwidth.
> 
> Nobody is saying anything about the derived work; it's just that the Tcl
> community should not be engaged in such forks due to its own limited
> contribution man power.
 

Re: [TCLCORE] GPL Licence in TCLLib added

[Emiliano <emi...@gm...>]

On Fri, 1 Nov 2024 12:19:47 +0100
Jan Nijtmans <jan...@gm...> wrote:

> Op vr 1 nov 2024 om 12:01 schreef Harald Oehlmann <
> har...@el...>:
> 
> > Dear TCLLib group,
> >
> > within commit:
> > https://core.tcl-lang.org/tcllib/info/f5d6a5e51b7d8607
> > a GPL Licence was added in TCLLib.
> >
> > I see this highly critical.
> > To my understanding of the licence, the branch is not mergable any more
> > to any distribution branch, sorry.
> >
> 
> My guess is that the "mime" branch is a personal branch created
> by Nathan Coulter. I don't know why he didn't make this branch
> "private", it appears that no-one else than Nathan ever did
> any commit here. My suggestion would be, please @nathan, make
> this branch "hidden". Then all confusion is gone.
> 
>d The same holds for the "unchained" branch in Tcl (and Thread).
> It can never be merged to trunk for the same reason. This
> branch is already "hidden"
> 
> Conclusion: No problem at all, just a waste of time.

The real question is: why is someone (ab)using the limited resources of the
Tcl community at large to pursuit its own personal agenda?

Why isn't he pulling Tcl changes on his own personal fork (something it's
perfectly allowed in the Tcl license) instead of commiting to Tcl repos?.

IMO these kind of behaviour shouldn't be allowed at all in all tcl related
repos (Tcl/Tk core, tcllib, tklib, etc) since we have limited man power and
bandwidth.

Nobody is saying anything about the derived work; it's just that the Tcl
community should not be engaged in such forks due to its own limited
contribution man power.

-- 
Emiliano <emi...@gm...>

Re: [TCLCORE] TCL/Tk planning meeting on Monday 28th at 12:00 UTC

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

Le 29/10/2024 à 15:22, apnmbx-public--- via Tcl-Core a écrit :
>
> I would definitely prefer prioritizing fixes for 9.0 first. Moreover, 
> at some point in the future backporting should not be mandated for 
> bugs that have a low severity level (leaving aside the question of who 
> determines the severity of a bug!)
>
Given our limited resources I would happily go one step further, and fix 
bugs in 9.0 *only* (at least in Tk). That is: backporting would no 
longer be expected from the bug fixer. Whoever wants to backport a fix 
is free to do so.

Regards,

Francois

[TCLCORE] sqlite3 3.47.0 released

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

The upstream SQLite project released 3.47.0 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.0.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

Re: [TCLCORE] GPL Licence in TCLLib added

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

Op vr 1 nov 2024 om 12:19 schreef Jan Nijtmans <jan...@gm...>:

> Conclusion: No problem at all, just a waste of time.
>

Note that the "module-aes" branch cannot be merged to "trunk" as well.
Same reason, same person.

Regards,
       Jan Nijtmans

Re: [TCLCORE] GPL Licence in TCLLib added

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

Op vr 1 nov 2024 om 12:01 schreef Harald Oehlmann <
har...@el...>:

> Dear TCLLib group,
>
> within commit:
> https://core.tcl-lang.org/tcllib/info/f5d6a5e51b7d8607
> a GPL Licence was added in TCLLib.
>
> I see this highly critical.
> To my understanding of the licence, the branch is not mergable any more
> to any distribution branch, sorry.
>

My guess is that the "mime" branch is a personal branch created
by Nathan Coulter. I don't know why he didn't make this branch
"private", it appears that no-one else than Nathan ever did
any commit here. My suggestion would be, please @nathan, make
this branch "hidden". Then all confusion is gone.

The same holds for the "unchained" branch in Tcl (and Thread).
It can never be merged to trunk for the same reason. This
branch is already "hidden"

Conclusion: No problem at all, just a waste of time.

Hope this helps,
         Jan Nijtmans

[TCLCORE] GPL Licence in TCLLib added

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

Dear TCLLib group,

within commit:
https://core.tcl-lang.org/tcllib/info/f5d6a5e51b7d8607
a GPL Licence was added in TCLLib.

I see this highly critical.
To my understanding of the licence, the branch is not mergable any more 
to any distribution branch, sorry.

I would also love to have a general decision on copyright statements:

The software is copyrighted by the TCL association und the TCL licence. 
Any addition of other copyright statements is not permitted.

Thank you all,
Harald

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

Re: [TCLCORE] "In the core"

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

Am 31.10.2024 um 02:47 schrieb Steve Landers:
> Folks,
> 
> Over the years we often hear people ask for something to be “in the 
> core” and it’s happening again recently as we start thinking about what 
> comes after Tcl 9.0.   But what does “in the core” mean?  I’m interested 
> in hearing people’s opinions.
> 
> Does it mean “I want this package to be tightly controlled via TIPs” 
> like Tcl itself?
> 
> Does it mean “I want this package to always be available when Tcl is 
> installed?"
> 
> Does it mean “I want have confidence that this package can be built and 
> installed in a particular Tcl version?"
> 
> Does it mean all of the above or something else?
> 
> Here’s my take ...
> 
> Some packages are foundational and need to be carefully managed and 
> always available with a Tcl release: e.g. http (perhaps), tls, thread, 
> perhaps others. Does that mean they need to be under TIP 
> control?  Probably not albeit we should try not to break the 
> compatibility of packages like http and tls.  But what I would greatly 
> appreciate is having a set of packages that I could rely upon being 
> present in any Tcl install (unless explicitly omitted - such as on 
> memory constrained devices).
> 
> We already have a mechanism for this in the tcl/pkgs directory. I would 
> be satisfied to see more packages being included in that and perhaps a 
> “batteries included” distribution added to the Tcl distribution 
> files.  And since we are in parallel talking about decoupling Tk from 
> Tcl we could add Tk to tcl/pkgs too.  I realise this might cause 
> heartburn for distro maintainers so their input will be vital. And how 
> would we differentiate Tcl pkgs from Tk pkgs if Tk itself was a pkg 
> (maybe we don’t need to).  But directionally I am comfortable with the 
> notion that “in the core” means “in tcl/pkgs” except for features that 
> can’t be distributed as a package.
> 
> So what are your thoughts?
> 
> -- Steve
Dear Steve,
I have no opinion on how to distribute Tk. For me, this is a side issue.

On other bundled packages, I would appreciate, if we have active 
maintainers for the packages.

The big advantage of the bundled packages is, that they are tested and 
released together with the core. This is the advantage, as compatibility 
and minimum maintenance is there.

But bundled packages give extra burden to the release process. 
Basically, if a bundled package is not ready, a release is not possible.

About the bundled packages:
- itcl 4: for me, this may be removed. Causes most problems, as it 
depends on many internals of TCL. The creator Arnulf Wiedemann is gone.
It was often told, that ActiveState has many support contracts for itcl.
- tdbc* & sqlite: it is handy, that those are there. But to not bundle 
them would be ok for me. Great Massimo Manghi has expressed to be ready 
as maintainer. That would be great !
- thread: Don once said, that basic parts should go directly to the core 
and some parts stay external. I see no reason, why this should be an 
external package at all. The functionality is central for anybody. Once, 
there existed alternate packages, but this is long time ago.

I would love, if critical packages like itcl & thread are constantly 
tested with tcl, so we are early alerted if there are issues. Would it 
possible to integrate them in continuous testing on github?

As a criteria of new bundled packages, I would say:
- common interest on one platform
- well maintained
- testable (with Tcl/Tk continuous integration)
- tcl 9 ready ;-).
- TCL compatible Licence

If a package is bundled, we also have a common responsibility. I would 
be in favour to extend the TIP process to bundled packages.

Thank you for all,
Harald

Re: [TCLCORE] "In the core"

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

On 11/01/2024 06:45 AM, st...@di... wrote:

> ...
> My interest is having a console available on all platforms. I use rlwrap to give me command line editing on *nix but when I deploy via CloudTk it is nice to have a console available during testing and debugging.   Mostly I use the one from https://wiki.tcl-lang.org/page/console+for+Unix.

Which directly brings up the question why not to include the Tk console module into POSIX builds, too?

In my vanillawish builds this is done and can be enabled per environment variable TK_CONSOLE=1
which gives the same console experience as on Win32. In undroidwish builds it is required due
to the architecture (single framebuffer, non existent std(in|out|err) channels, possibly).

BR,
Christian

Re: [TCLCORE] "In the core"

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

It's a separate issue to the topic, but I used linenoise as an example given that SQLite are including it as an optional build.  

My interest is having a console available on all platforms. I use rlwrap to give me command line editing on *nix but when I deploy via CloudTk it is nice to have a console available during testing and debugging.   Mostly I use the one from https://wiki.tcl-lang.org/page/console+for+Unix.

-- Steve

> On 1 Nov 2024, at 11:57 am, Julian Noble via Tcl-Core <tcl...@li...> wrote:
> 
> Aside from tls, Thread - which I would like to see available by default and I expect are relatively uncontroversial - I'm wary of things like linenoise.
> 
> The console space is a big curly one - currently undergoing lots of innovation across platforms and languages - but notoriously difficult to get working across platforms - especially windows.
> The https://github.com/msteveb/linenoise repository still uses windows API calls that are not 'virtual terminal' suitable - and are somewhat deprecated in that context.
> I haven't tried recently - but had difficulty attempting to build/use it on windows in the past - and judging by these calls, I don't think it's anywhere near a good solution on windows yet.
> 
> Aside from signal handling oddities - it's entirely possible to make cross-platform line editing and other advanced console features work in pure Tcl - it's just difficult.
> (e.g I have a proof of concept that works on FreeBSD,linux,windows - but nothing releaseworthy)
> 
> I understand a cross platform console is a greatly desirable feature - and I guess if it's entirely an optional package it won't get in the way of other solutions - but I do also worry about buildability if too many things are considered 'core' in some sense.
> 
> It's hard enough to build for multiple platforms as it is, without extra things being required to be buildable to be considered a relatively 'complete' Tcl release.
> I am for example having initial success building using a zig build process - which entirely replaces the existing build/make process - and while in initial stages and not necessarily of wider interest yet, is promising for me anyway.
> More items considered 'core' is more work in that regard.
> 
> For me, 'core' packages should generally be smaller units of basic cross platform functionality, and some platform specific things (like registry, maybe dbus?) 
> 
> I find Twapi indispensable on windows - but it's large and I wouldn't consider it suitable as core due to size and build trickiness.
> Just one of its useful features is signal handling - which I would like to see in 'core' one day.
> 
> JMN
> 
> 
> On 2024-10-31 1:52 pm, Steve Landers wrote:
>> So would adding dbus to tcl/pkgs achieve you goals?  
>> 
>> I can think of others - e.g. Steve Bennet�"s linenoise fork to provide a console on all platforms (much like the SQLite project has recently done.   
>> 
>> -- Steve
>> On 31 Oct 2024 at 10:48⬯AM +0800, Kevin Walzer <kw...@co...> <mailto:kw...@co...>, wrote:
>>> 
>>> On 10/30/24 9:47 PM, Steve Landers wrote:
>>> > Does it mean all of the above or something else?
>>> 
>>> 
>>> Depends on the package. A loosely-coupled "nice to have" package like
>>> todbc is not really in the core. A key platform package like registry IS
>>> in the core for all intents and purposes. It is distributed and built
>>> with the core Tcl code. I have floated the idea of adding dbus to the
>>> core in the latter form.
>>> 
>>> --Kevin
>>> 
>>> _______________________________________________
>>> Tcl-Core mailing list
>>> Tcl...@li... <mailto:Tcl...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>> 
>> 
>> 
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li... <mailto: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] "In the core"

[Julian N. <ju...@pr...>]

Aside from tls, Thread - which I would like to see available by default 
and I expect are relatively uncontroversial - I'm wary of things like 
linenoise.

The console space is a big curly one - currently undergoing lots of 
innovation across platforms and languages - but notoriously difficult to 
get working across platforms - especially windows.
The https://github.com/msteveb/linenoise repository still uses windows 
API calls that are not 'virtual terminal' suitable - and are somewhat 
deprecated in that context.
I haven't tried recently - but had difficulty attempting to build/use it 
on windows in the past - and judging by these calls, I don't think it's 
anywhere near a good solution on windows yet.

Aside from signal handling oddities - it's entirely possible to make 
cross-platform line editing and other advanced console features work in 
pure Tcl - it's just difficult.
(e.g I have a proof of concept that works on FreeBSD,linux,windows - but 
nothing releaseworthy)

I understand a cross platform console is a greatly desirable feature - 
and I guess if it's entirely an optional package it won't get in the way 
of other solutions - but I do also worry about buildability if too many 
things are considered 'core' in some sense.

It's hard enough to build for multiple platforms as it is, without extra 
things being required to be buildable to be considered a relatively 
'complete' Tcl release.
I am for example having initial success building using a zig build 
process - which entirely replaces the existing build/make process - and 
while in initial stages and not necessarily of wider interest yet, is 
promising for me anyway.
More items considered 'core' is more work in that regard.

For me, 'core' packages should generally be smaller units of basic cross 
platform functionality, and some platform specific things (like 
registry, maybe dbus?)

I find Twapi indispensable on windows - but it's large and I wouldn't 
consider it suitable as core due to size and build trickiness.
Just one of its useful features is signal handling - which I would like 
to see in 'core' one day.

JMN


On 2024-10-31 1:52 pm, Steve Landers wrote:
> So would adding dbus to tcl/pkgs achieve you goals?
>
> I can think of others - e.g. Steve Bennet"s linenoise fork to provide 
> a console on all platforms (much like the SQLite project has recently 
> done.
>
> -- Steve
> On 31 Oct 2024 at 10:48⬯AM +0800, Kevin Walzer <kw...@co...>, 
> wrote:
>>
>> On 10/30/24 9:47 PM, Steve Landers wrote:
>> > Does it mean all of the above or something else?
>>
>>
>> Depends on the package. A loosely-coupled "nice to have" package like
>> todbc is not really in the core. A key platform package like registry IS
>> in the core for all intents and purposes. It is distributed and built
>> with the core Tcl code. I have floated the idea of adding dbus to the
>> core in the latter form.
>>
>> --Kevin
>>
>> _______________________________________________
>> 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] "In the core"

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

Thanks Marc, appreciated.

Building on  your idea about a TIP for inclusion in the standard library (which I support) perhaps also for incompatible changes or for inclusion of updated versions. That way a package maintainer is free to innovate but if there is breakage the TCT needs to decide whether and when to accept the breaking version, or (worst case) whether to back out gratuitous breakage and maintain a fork.

-- Steve
On 31 Oct 2024 at 9:49 PM +0800, Marc Culler <cul...@gm...>, wrote:
> Here is a suggestion.  Maybe we should stop using the phrase "in the core", which we clearly do not know the meaning of, and replace it by two phrases: "in the Tcl language core" and "in the Tcl standard library", where the standard library includes Tk and various other extension packages which are always provided in any standard distribution of Tcl (but could be removed, e.g. when embedding Tcl).  Of course the Tcl language is designed to be extendable.  The core of the language is the part that is *always* included.
>
> The contents of the standard library should be able to change and there should be a process for deciding which extension packages go into the library.  Adding or removing packages from the standard library could be something which is controlled by TIPs.  I am not sure whether adding features to a package in the standard library should be controlled by TIPs. But that seems like something that could be discussed on its own.
>
> I think something like dbus should be in the standard library.  I do not think it should be in the Tcl language core.  I think that the same is true for Tk, but Tk should not be removable from the standard library and it should continue to be controlled by TIPs.  I don't think that "being in the standard library" is equivalent to "being in tcl/pkgs".  The latter is an implementation detail and could have exceptions, Tk being one.
>
> - Marc
>
> > On Thu, Oct 31, 2024 at 3:53 AM Colin Macleod via Tcl-Core <tcl...@li...> wrote:
> > > On 31 Oct 2024 at 2:14 PM +0800, Brian Griffin <bri...@ea...>, wrote:
> > > > > As a (former) consumer of Tcl, delivering a commercial product, my take on "in the core" means a single download and single build step.
> > > > > And, to address corporate due diligence, the download is subject to copyright vetting and security analysis.
> > > > >
> > > > > The number of open-source downloads that have to go through these steps can be overwhelming, hence the desire to bundle stuff together whenever possible.
> > > > >
> > > > > -Brian
> > > Been there, done that :-)  At Bloomberg I fudged this by putting the whole kbskit through the approval process as a single entity, which was perhaps slightly dodgy.
> > > Colin.
> > > _______________________________________________
> > > 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] "In the core"

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

Here is a suggestion.  Maybe we should stop using the phrase "in the core",
which we clearly do not know the meaning of, and replace it by two phrases:
"in the Tcl language core" and "in the Tcl standard library", where the
standard library includes Tk and various other extension packages which are
always provided in any standard distribution of Tcl (but could be removed,
e.g. when embedding Tcl).  Of course the Tcl language is designed to be
extendable.  The core of the language is the part that is *always* included.

The contents of the standard library should be able to change and there
should be a process for deciding which extension packages go into the
library.  Adding or removing packages from the standard library could be
something which is controlled by TIPs.  I am not sure whether adding
features to a package in the standard library should be controlled by TIPs.
But that seems like something that could be discussed on its own.

I think something like dbus should be in the standard library.  I do not
think it should be in the Tcl language core.  I think that the same is true
for Tk, but Tk should not be removable from the standard library and it
should continue to be controlled by TIPs.  I don't think that "being in the
standard library" is equivalent to "being in tcl/pkgs".  The latter is an
implementation detail and could have exceptions, Tk being one.

- Marc

On Thu, Oct 31, 2024 at 3:53 AM Colin Macleod via Tcl-Core <
tcl...@li...> wrote:

> On 31 Oct 2024 at 2:14 PM +0800, Brian Griffin <bri...@ea...>
> <bri...@ea...>, wrote:
>
> As a (former) consumer of Tcl, delivering a commercial product, my take on
> "in the core" means a single download and single build step.
> And, to address corporate due diligence, the download is subject to
> copyright vetting and security analysis.
>
> The number of open-source downloads that have to go through these steps
> can be overwhelming, hence the desire to bundle stuff together whenever
> possible.
>
> -Brian
>
> Been there, done that :-)  At Bloomberg I fudged this by putting the whole
> kbskit through the approval process as a single entity, which was perhaps
> slightly dodgy.
>
> Colin.
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] "In the core"

[Colin M. <col...@ya...>]

On 31 Oct 2024 at 2:14 PM +0800, Brian Griffin 
<bri...@ea...>, wrote:
>
>     As a (former) consumer of Tcl, delivering a commercial product, my
>     take on "in the core" means a single download and single build step.
>     And, to address corporate due diligence, the download is subject
>     to copyright vetting and security analysis.
>
>     The number of open-source downloads that have to go through these
>     steps can be overwhelming, hence the desire to bundle stuff
>     together whenever possible.
>
>     -Brian
>
Been there, done that :-)  At Bloomberg I fudged this by putting the 
whole kbskit through the approval process as a single entity, which was 
perhaps slightly dodgy.

Colin.

Re: [TCLCORE] "In the core"

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

> On Oct 30, 2024, at 18:47, Steve Landers <st...@di...> wrote:
> 
> Folks,
> 
> Over the years we often hear people ask for something to be “in the core” and it’s happening again recently as we start thinking about what comes after Tcl 9.0.   But what does “in the core” mean?  I’m interested in hearing people’s opinions.
> 
> Does it mean “I want this package to be tightly controlled via TIPs” like Tcl itself?
> 
> Does it mean “I want this package to always be available when Tcl is installed?"
> 
> Does it mean “I want have confidence that this package can be built and installed in a particular Tcl version?"
> 
> Does it mean all of the above or something else?
> 
> Here’s my take ...
> 
> Some packages are foundational and need to be carefully managed and always available with a Tcl release: e.g. http (perhaps), tls, thread, perhaps others. Does that mean they need to be under TIP control?  Probably not albeit we should try not to break the compatibility of packages like http and tls.  But what I would greatly appreciate is having a set of packages that I could rely upon being present in any Tcl install (unless explicitly omitted - such as on memory constrained devices).
> 
> We already have a mechanism for this in the tcl/pkgs directory. I would be satisfied to see more packages being included in that and perhaps a “batteries included” distribution added to the Tcl distribution files.  And since we are in parallel talking about decoupling Tk from Tcl we could add Tk to tcl/pkgs too.  I realise this might cause heartburn for distro maintainers so their input will be vital. And how would we differentiate Tcl pkgs from Tk pkgs if Tk itself was a pkg (maybe we don’t need to).  But directionally I am comfortable with the notion that “in the core” means “in tcl/pkgs” except for features that can’t be distributed as a package.
> 
> So what are your thoughts?   

As a (former) consumer of Tcl, delivering a commercial product, my take on "in the core" means a single download and single build step.
And, to address corporate due diligence, the download is subject to copyright vetting and security analysis.

The number of open-source downloads that have to go through these steps can be overwhelming, hence the desire to bundle stuff together whenever possible.

-Brian

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

Re: [TCLCORE] "In the core"

[Torsten B. <be...@ty...>]

Hi,

I think the definition depends on the people requesting some functionality or package to be in the core.

If it is a *single command*, then the definition is clear. They want to have the command in the Tcl source tree #(.../generic, .../unix, .../win, .../macosx). This will result in TIP control and the command to be available as every other Tcl command.

Users who want *a package* "in the core" will likely just want to have it distributed and available with every Tcl release, just as the packages in tcl/pkgs ("I want this package to always be available when Tcl is installed"). They don't care if it is under TIP control as long as it works. In my view this is the case for all packages under tcl/pkgs. For example, sqlite is inside tcl/pkgs and this one is definitely not under TIP control, right? Consequently, this should apply to all packages in tcl/pkgs as we have no rule distinguishing between "controlled packages" and "uncontrolled packages".

This has consequences for the developers maintaining a package. They need to make sure the package works with every new release of Tcl. This should be the rule for all packages in tcl/pkgs: they must have a maintainer who commits to keep it running with every Tcl release. It does not mean the package is under TIP control. It does also not mean that the package needs to be developed inside the Tcl repo (but it could). It can be copied into the Tcl source code distribution when the release is prepared. This is the situation now. Reading the README in tcl/pkgs, there is no requirement there that the package must run with every Tcl release. I feel, "in the core" implies just this and it should be stated in the README. So, every package listed in tcl/pkgs/package.list.txt automatically puts itself under this additional requirement (without putting the package under TIP control). This also means the package must run under unix/win/macos and cannot be restricted to one platform (unless it is specifically designed for an individual platofrm such as dde).

If some package developer/maintainer does not want this additional constraint, the package can not be defined as being "in the core" and thus needs to go somewhere else, e.g. into tcllib or tklib. These two I would expect to be in a Batteries Included distribution. There, a user has no guarantee the package will run with every new Tcl or Tk release. It is totally up to the maintainers what they are doing.

I totally agree that putting a package under TIP control may easily lead to a maintainer abandoning the package. This is also a reason not to require TIP control for  a package in tcl/pkgs.

Bottom line:

- “I want this package to be tightly controlled via TIPs” means we have the source code in .../generic, .../unix, .../win, .../macosx and the TCT controls it using TIPS. This is "in the core".

- “I want this package to always be available when Tcl is installed?" means the package is in tcl/pkgs. This is also "in the core" but not under TIP control and not under TCT control. However, the maintainer commits to some specific rules.

- “I want have confidence that this package can be built and installed in a particular Tcl version?" is NOT "in the core"

Regards, Torsten


> Am 31.10.2024 um 02:47 schrieb Steve Landers <st...@di...>:
> 
> Folks,
> 
> Over the years we often hear people ask for something to be “in the core” and it’s happening again recently as we start thinking about what comes after Tcl 9.0.   But what does “in the core” mean?  I’m interested in hearing people’s opinions.
> 
> Does it mean “I want this package to be tightly controlled via TIPs” like Tcl itself?
> 
> Does it mean “I want this package to always be available when Tcl is installed?"
> 
> Does it mean “I want have confidence that this package can be built and installed in a particular Tcl version?"
> 
> Does it mean all of the above or something else?
> 
> Here’s my take ...
> 
> Some packages are foundational and need to be carefully managed and always available with a Tcl release: e.g. http (perhaps), tls, thread, perhaps others. Does that mean they need to be under TIP control?  Probably not albeit we should try not to break the compatibility of packages like http and tls.  But what I would greatly appreciate is having a set of packages that I could rely upon being present in any Tcl install (unless explicitly omitted - such as on memory constrained devices).
> 
> We already have a mechanism for this in the tcl/pkgs directory. I would be satisfied to see more packages being included in that and perhaps a “batteries included” distribution added to the Tcl distribution files.  And since we are in parallel talking about decoupling Tk from Tcl we could add Tk to tcl/pkgs too.  I realise this might cause heartburn for distro maintainers so their input will be vital. And how would we differentiate Tcl pkgs from Tk pkgs if Tk itself was a pkg (maybe we don’t need to).  But directionally I am comfortable with the notion that “in the core” means “in tcl/pkgs” except for features that can’t be distributed as a package.
> 
> So what are your thoughts?
> 
> -- Steve
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] "In the core"

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

Thanks Brian,

So if I hear you right, if the contents of tcl/pkgs are built with a Tcl build (which they are) and if they have the same (or compatible) license (which they do) then tcl/pkgs would meet your need without the need for those packages to be under TIP control.

-- Steve
On 31 Oct 2024 at 2:14 PM +0800, Brian Griffin <bri...@ea...>, wrote:
> As a (former) consumer of Tcl, delivering a commercial product, my take on "in the core" means a single download and single build step.
> And, to address corporate due diligence, the download is subject to copyright vetting and security analysis.
>
> The number of open-source downloads that have to go through these steps can be overwhelming, hence the desire to bundle stuff together whenever possible.
>
> -Brian
>

Re: [TCLCORE] "In the core"

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

That would certainly make the package less likely to change behaviour in a minor release, but it might also stop Schelte from evolving the package. And it also commits someone to maintain it ongoing even after the original author has lost interest.  I’m not saying TIP or pkgs is better or worse in this situation, just noting considerations.

Another alternative is for a package to go into tcl/pkgs until a maintainer loses interest and and/or there is broad agreement that a package should be in the core. Again, not pushing this for debug, just observing.

Thanks

-- Steve
On 31 Oct 2024 at 11:08 AM +0800, Kevin Walzer <kw...@co...>, wrote:
> That’s up to Schelte, but I would like it under TIP control.
>
> > On Oct 30, 2024, at 11:02 PM, Steve Landers wrote:
> >
> > Then you are asking for dbus to come under TIP control if it is part of the *nix source tree. Is that desirable or would it be better to stay maintained by Schelte as part of packages

Re: [TCLCORE] "In the core"

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

<div><img width="1" height="1" src='https://fedbdhd.r.af.d.sendibt2.com/tr/op/J3Y4YylxC_nyDXQdiFEPnYfJuShISSjuGvkqlyWWe9yxiu1ev0by-u_lwfwe_iRmyKR55-sZIePQDZfW95jeogXTjTodGYt5WeQL3VOu94wxVIU5JHmeImMUXIIwX-a5HGqpzOCt3ZPZCneRiVy4_Q_7JBABuxY388JKm-B9WHSGN6ioRM_xEVUKkq_C8f5XfjmgNJetVnPOMTwng6vw10rXXyRX0vMG' /></div>That’s up to Schelte, but I would like it under TIP control. <br/><br/>> On Oct 30, 2024, at 11:02 PM, Steve Landers <st...@di...> wrote:<br/>> <br/>> Then you are asking for dbus to come under TIP control if it is part of the *nix source tree.   Is that desirable or would it be better to stay maintained by Schelte as part of packages<br/>