tcllib-devel — Discussion of development for tcllib

Re: [Tcllib-devel] Tcllib 1.21 Release To Come, And Further

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

> On Tue, Apr 26, 2022 at 5:39 PM Andreas Kupries <and...@gm...>
> wrote:
> 
> > I actually still test Tcllib release RCs against 8.5.
> > 8.4 even.
> >
> > Specifically
> >         8.4.20
> >         8.5.19
> >         8.6.10
> >         8.7.a4 (*)
> >
> >
> > (*) Just to look ahead for possible issues.
> >     Failures there are not blockers and not acted on.

> OK, good to know!  In any case, the fact remains that code (such as
> struct::disjointsets) that loaded in Tcl 8.5 on earlier Tcllib
> releases now may have declared Tcl 8.6 dependencies. That's sort of
> a silent regression, since I'm sure your test process simply ignores
> packages with a declared dependency on a newer release.

.. Checking ... Ok, disjointset declares a 8.6 dependency in the code
(package require), the tests (testsNeedTcl), and the package index (if
vsatisfies guard). The latter means that it cannot be loaded into 8.5
anymore because it would not be registered at all.

However, having thought about it, having a package X declare an 8.6
dependency in the tests while still having an 8.5 dependency
declaration in code and package index, yes, that kind of mismatch and
regression I would indeed miss.

Even the `./sak.tcl validate versions` only compares package and index
version information, and ignores version information in the tests.

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

Re: [Tcllib-devel] Tcllib 1.21 Release To Come, And Further

[Kevin K. <kev...@gm...>]

On Tue, Apr 26, 2022 at 5:39 PM Andreas Kupries <and...@gm...>
wrote:

> I actually still test Tcllib release RCs against 8.5.
> 8.4 even.
>
> Specifically
>         8.4.20
>         8.5.19
>         8.6.10
>         8.7.a4 (*)
>
>
> (*) Just to look ahead for possible issues.
>     Failures there are not blockers and not acted on.
>
>
OK, good to know!  In any case, the fact remains that code (such as
struct::disjointsets) that loaded in Tcl 8.5 on earlier Tcllib releases now
may have declared Tcl 8.6 dependencies. That's sort of a silent regression,
since I'm sure your test process simply ignores packages with a declared
dependency on a newer release.


-- 
73 de ke9tv/2, Kevin

Re: [Tcllib-devel] Tcllib 1.21 Release To Come, And Further

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

> On Tue, Apr 26, 2022 at 9:27 AM Evan Rempel <er...@uv...> wrote:
> 
> > If there isn't a technical reason to increase the minimum tcl
> > requirement can I request that a minimum of 8.5 be used until 2026?

> I'd contend that the last few Tcllib releases would be pretty dodgy against
> 8.5, and package authors are likely to have overlooked updating the Tcl
> version dependency. I surely don't think you can expect many packages
> actually to have been tested against such an old release. Andreas could
> probably recover information about when Tcllib's release process stopped
> testing on 8.5.

I actually still test Tcllib release RCs against 8.5.
8.4 even.

Specifically
	8.4.20
	8.5.19
	8.6.10
	8.7.a4 (*)


(*) Just to look ahead for possible issues.
    Failures there are not blockers and not acted on.

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

Re: [Tcllib-devel] Tcllib 1.21 Release To Come, And Further

[Kevin K. <kev...@gm...>]

On Tue, Apr 26, 2022 at 9:27 AM Evan Rempel <er...@uv...> wrote:

> If there isn't a technical reason to increase the minimum tcl
> requirement can I request that a minimum of 8.5 be used until 2026?
>

2026 is fourteen years after Tcl 8.6 became the current release, and ten
years after 8.5's end of life. It always struck me as peculiar that RHEL 7
shipped with a two-years-out-of-date Tcl from the start.

It doesn't seem unreasonable to me to require that if you're going to use
an obsolete Tcl, you have to use an obsolete Tcllib.

If I'm editing a Tcllib package, I generally have it assert a dependency
against the earliest point release that I've tested against - and I don't
routinely test against end-of-life releases. 8.5 has been at end-of-life
for long enough that I'm not always aware of whether I'm using
8.6-dependent functionality, and I certainly don't avoid introducing
8.6-dependent features for the sake of downstream extended-support
releases, so updating the dependency is a routine action.

For instance, in 2018 I introduced an 8.6 dependency into
struct::disjointset - because the existing implementation didn't actually
provide a disjoint-sets data structure. Apparently, the GSoC student who
introduced it was none to clear on what a disjoint-sets data structure
actually was. With 8.5 already at end of life, I had no qualms whatever
about using TclOO features in the implementation and asserting an 8.6
dependency.  This would, however, definitely be a regression if someone
were to install a current Tcllib on top of Tcl 8.5, since the previous
version, ineffective though it was, was satisfied by 8.5 (or even, if
memory serves, 8.4).

If someone wants to take a branch off an earlier Tcllib release and
maintain it with bug fixes, they're welcome to do so. There are even Tcllib
maintainers who would consider providing paid support. (I'm not one; I'm
semi-retired and working part-time for a single employer, not looking for
new business.)

I'd contend that the last few Tcllib releases would be pretty dodgy against
8.5, and package authors are likely to have overlooked updating the Tcl
version dependency. I surely don't think you can expect many packages
actually to have been tested against such an old release. Andreas could
probably recover information about when Tcllib's release process stopped
testing on 8.5.

-- 
73 de ke9tv/2, Kevin

Re: [Tcllib-devel] Tcllib 1.21 Release To Come, And Further

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

Am 26.04.2022 um 19:29 schrieb Evan Rempel:
> On 4/26/22 09:42, Pietro Cerutti via Tcllib-devel wrote:
>>> On 26 Apr 2022, at 17:21, Andreas Kupries <and...@gm...> 
>>> wrote:
>>>>> On 2022-04-26 03:53, Andreas Kupries wrote:
>>>>> And looking beyond 1.21 my plan is to have a larger cleanup, as in:
>>>>>   1. Even Tcl 8.5 is end of life for oever 6 years now (8.5.19 was 
>>>>> 2016-02-12).
>>>>>      Let alone 8.4 and older.
>>>>>      Some of the packages in Tcllib still declare 8.2 as min 
>>>>> requirement/
>>>>>      I want to declare everything before 8.6 as unsupported now.
>>>>>      There was enough time to switch.
>>>>>      That will make development much easier as there is no need to
>>>>>      think about if a command, function, syntax is supported by the
>>>>>      declared min-version of the package, or not. Recently seen with a
>>>>>      patch using the `max` function. Does not exist in 8.4.
>>>> Redhat Enterprise Linux 7 uses tcl 8.5
>>>> Redhat Enterprise Linux 7 is a supported product through 2024, and with
>>>> extended support until 2026.
>>>> https://access.redhat.com/support/policy/updates/errata
>>>> If there isn't a technical reason to increase the minimum tcl
>>>> requirement can I request that a minimum of 8.5 be used until 2026?
>>> Fair argument.
>>>
>>> Are there __strong objections__ (i.e. with good arguments) against 
>>> keeping to
>>> 8.5 as the minimum over 8.6 ?
>>>
>>> If not I would change the plans for after 1.21 to go with 8.5.
>> Not very strong, but it feels weird to me that long-term distros would 
>> push the maintenance burden upstreams.
>>
>> I contribute(d) very little to tcl/tcllib, but having to be 
>> retro-compatible with 8.5 has already meant you Andrea had to modify a 
>> patch of mine.
>>
>> Is the message really going to be that 8.5 is unmaintained but tcllib 
>> still needs to run on it?
>>
>> If users of RHEL can install a newer tcllib, I guess they can surely 
>> install a newer Tcl?
>>
>> -- 
>> Pietro Cerutti
> 
> tcl is provided by Redhat and they generally have a policy that they 
> don't change the versions of things within the life of the major Redhat 
> OS version. They are getting better ar being able to introduce different 
> versions, but that is a different story.
> 
> tcllib is NOT provided by Redhat. Anyone trying to install tcllib onto 
> RHEL7 would either have to install an old version of tcllib (supported 
> by tcllib maintainers?) or have the latest tcllib release accept the 
> minimum tcl version of 8.5
> 
> It is a lot more difficult to replace a Redhat package than it is to 
> provide one along side the Redhat package set.
> 
> Just for discussion, Redhat 8 includes 8.6 and the normal life cycle for 
> that is to 2029

Thank you, Evan, for your contribution.

As the TCLLIB installer is run by the TCL on the system, maybe the 
installer may check, if TCL8.6 is available.
If it is 8.5, the installer may point to an older TCLLIB version.

If there is TCL8.5 on the system, the system lacks anyway many features.
So, an older TCLLIB release would be perfectly suitable for this system.

Thank you,
Harald

Re: [Tcllib-devel] Tcllib 1.21 Release To Come, And Further

[Evan R. <er...@uv...>]

On 4/26/22 09:42, Pietro Cerutti via Tcllib-devel wrote:
>> On 26 Apr 2022, at 17:21, Andreas Kupries <and...@gm...> wrote:
>>>> On 2022-04-26 03:53, Andreas Kupries wrote:
>>>> And looking beyond 1.21 my plan is to have a larger cleanup, as in:
>>>>   1. Even Tcl 8.5 is end of life for oever 6 years now (8.5.19 was 2016-02-12).
>>>>      Let alone 8.4 and older.
>>>>      Some of the packages in Tcllib still declare 8.2 as min requirement/
>>>>      I want to declare everything before 8.6 as unsupported now.
>>>>      There was enough time to switch.
>>>>      That will make development much easier as there is no need to
>>>>      think about if a command, function, syntax is supported by the
>>>>      declared min-version of the package, or not. Recently seen with a
>>>>      patch using the `max` function. Does not exist in 8.4.
>>> Redhat Enterprise Linux 7 uses tcl 8.5
>>> Redhat Enterprise Linux 7 is a supported product through 2024, and with
>>> extended support until 2026.
>>> https://access.redhat.com/support/policy/updates/errata
>>> If there isn't a technical reason to increase the minimum tcl
>>> requirement can I request that a minimum of 8.5 be used until 2026?
>> Fair argument.
>>
>> Are there __strong objections__ (i.e. with good arguments) against keeping to
>> 8.5 as the minimum over 8.6 ?
>>
>> If not I would change the plans for after 1.21 to go with 8.5.
> Not very strong, but it feels weird to me that long-term distros would push the maintenance burden upstreams.
>
> I contribute(d) very little to tcl/tcllib, but having to be retro-compatible with 8.5 has already meant you Andrea had to modify a patch of mine.
>
> Is the message really going to be that 8.5 is unmaintained but tcllib still needs to run on it?
>
> If users of RHEL can install a newer tcllib, I guess they can surely install a newer Tcl?
>
> --
> Pietro Cerutti

tcl is provided by Redhat and they generally have a policy that they 
don't change the versions of things within the life of the major Redhat 
OS version. They are getting better ar being able to introduce different 
versions, but that is a different story.

tcllib is NOT provided by Redhat. Anyone trying to install tcllib onto 
RHEL7 would either have to install an old version of tcllib (supported 
by tcllib maintainers?) or have the latest tcllib release accept the 
minimum tcl version of 8.5

It is a lot more difficult to replace a Redhat package than it is to 
provide one along side the Redhat package set.

Just for discussion, Redhat 8 includes 8.6 and the normal life cycle for 
that is to 2029

Re: [Tcllib-devel] Tcllib 1.21 Release To Come, And Further

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

Am 26.04.2022 um 18:42 schrieb Pietro Cerutti via Tcllib-devel:> If 
users of RHEL can install a newer tcllib, I guess they can surely 
install a newer Tcl?
+1

Harald

Re: [Tcllib-devel] Tcllib 1.21 Release To Come, And Further

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


> On 26 Apr 2022, at 17:21, Andreas Kupries <and...@gm...> wrote:
> 
> 
>>> On 2022-04-26 03:53, Andreas Kupries wrote:
>>> And looking beyond 1.21 my plan is to have a larger cleanup, as in:
>>>  1. Even Tcl 8.5 is end of life for oever 6 years now (8.5.19 was 2016-02-12).
>>>     Let alone 8.4 and older.
>>>     Some of the packages in Tcllib still declare 8.2 as min requirement/
>>>     I want to declare everything before 8.6 as unsupported now.
>>>     There was enough time to switch.
>>>     That will make development much easier as there is no need to
>>>     think about if a command, function, syntax is supported by the
>>>     declared min-version of the package, or not. Recently seen with a
>>>     patch using the `max` function. Does not exist in 8.4.
>> Redhat Enterprise Linux 7 uses tcl 8.5
>> Redhat Enterprise Linux 7 is a supported product through 2024, and with
>> extended support until 2026.
>> https://access.redhat.com/support/policy/updates/errata
>> If there isn't a technical reason to increase the minimum tcl
>> requirement can I request that a minimum of 8.5 be used until 2026?
> 
> Fair argument.
> 
> Are there __strong objections__ (i.e. with good arguments) against keeping to 
> 8.5 as the minimum over 8.6 ?
> 
> If not I would change the plans for after 1.21 to go with 8.5.

Not very strong, but it feels weird to me that long-term distros would push the maintenance burden upstreams.

I contribute(d) very little to tcl/tcllib, but having to be retro-compatible with 8.5 has already meant you Andrea had to modify a patch of mine.

Is the message really going to be that 8.5 is unmaintained but tcllib still needs to run on it?

If users of RHEL can install a newer tcllib, I guess they can surely install a newer Tcl?

-- 
Pietro Cerutti

Re: [Tcllib-devel] Tcllib 1.21 Release To Come, And Further

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

> On 2022-04-26 03:53, Andreas Kupries wrote:
> > And looking beyond 1.21 my plan is to have a larger cleanup, as in:
> >
> >    1. Even Tcl 8.5 is end of life for oever 6 years now (8.5.19 was 2016-02-12).
> >       Let alone 8.4 and older.
> >       Some of the packages in Tcllib still declare 8.2 as min requirement/
> >
> >       I want to declare everything before 8.6 as unsupported now.
> >       There was enough time to switch.
> >
> >       That will make development much easier as there is no need to
> >       think about if a command, function, syntax is supported by the
> >       declared min-version of the package, or not. Recently seen with a
> >       patch using the `max` function. Does not exist in 8.4.
> 
> Redhat Enterprise Linux 7 uses tcl 8.5
> 
> Redhat Enterprise Linux 7 is a supported product through 2024, and with 
> extended support until 2026.
> https://access.redhat.com/support/policy/updates/errata
> 
> If there isn't a technical reason to increase the minimum tcl 
> requirement can I request that a minimum of 8.5 be used until 2026?

Fair argument.

Are there __strong objections__ (i.e. with good arguments) against keeping to 
8.5 as the minimum over 8.6 ?

If not I would change the plans for after 1.21 to go with 8.5.

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

Re: [Tcllib-devel] Tcllib 1.21 Release To Come, And Further

[Evan R. <er...@uv...>]

On 2022-04-26 03:53, Andreas Kupries wrote:
> And looking beyond 1.21 my plan is to have a larger cleanup, as in:
>
>    1. Even Tcl 8.5 is end of life for oever 6 years now (8.5.19 was 2016-02-12).
>       Let alone 8.4 and older.
>       Some of the packages in Tcllib still declare 8.2 as min requirement/
>
>       I want to declare everything before 8.6 as unsupported now.
>       There was enough time to switch.
>
>       That will make development much easier as there is no need to
>       think about if a command, function, syntax is supported by the
>       declared min-version of the package, or not. Recently seen with a
>       patch using the `max` function. Does not exist in 8.4.

Redhat Enterprise Linux 7 uses tcl 8.5

Redhat Enterprise Linux 7 is a supported product through 2024, and with 
extended support until 2026.
https://access.redhat.com/support/policy/updates/errata

If there isn't a technical reason to increase the minimum tcl 
requirement can I request that a minimum of 8.5 be used until 2026?


Thanks for the consideration.

Evan Rempel

[Tcllib-devel] Tcllib 1.21 Release To Come, And Further

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

Hi all.

[[
    This is an edited copy of something I posted on the Tcler's Chat
    today. IOW some of you may have seen this already.

    Mailing it around now for wider dispersal / attention.
]]

I have opened the `tcllib-1-21-rc` branch for work on the next Tcllib release, 
1.21.
(It is about 2.5 years since 1.20 was released).

See
	https://core.tcl-lang.org/tcllib/timeline?r=tcllib-1-21-rc

for the timeline.

I am setting a deadline of Fri May 6 for the release work (see below).
The weekend of May 7/8 is when I want to finalize and publish everything.

Currently done:

  - Fixed the `sak review` helper.

  - Fixed a number of packages which were changed, yet did not have
    their version bumped.

  - Bumped the Tcllib main version.
  
  - Generated the initial release README summarizing changes since 1.20.

    See
    https://core.tcl-lang.org/tcllib/file?name=support/releases/history/README-
1.21.txt

    This will be updated as work is done in the coming 1.5 weeks.

Things to still do:

  - Looking at more tickets easy to fix.

  - @arjen - Please keep me informed wrt your progress on the figurate fixes.

  - @pooryorick - Please keep me informed wrt your progress on the mime2 work.

  - @rkeene - Please look at open PKI tickets

  - @hypnotoad - Please look at tickets for your packages (httpd, processman, 
etc. pp.)

  - All/Generally: Please bring tickets felt to be important to my attention.

    Note however: Tickets without repro code and/or patch and/or tests
    are automatically low priority to me.

And looking beyond 1.21 my plan is to have a larger cleanup, as in:

  1. Even Tcl 8.5 is end of life for oever 6 years now (8.5.19 was 2016-02-12).
     Let alone 8.4 and older.
     Some of the packages in Tcllib still declare 8.2 as min requirement/

     I want to declare everything before 8.6 as unsupported now.
     There was enough time to switch.

     That will make development much easier as there is no need to
     think about if a command, function, syntax is supported by the
     declared min-version of the package, or not. Recently seen with a
     patch using the `max` function. Does not exist in 8.4.

  2. For all the packages which come in multiple major versions (md5
     IIRC, various struct/math packages, snit, ...) drop, as in,
     remove, anything but the last version. The mime package would be
     an exception to that given that its new major version (v2) would
     have appeared only with 1.21, without a decade or more for users
     to switch.

This release should then be Tcllib 2.0.

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

[Tcllib-devel] Announcement & Call for Speakers (The SQLite & Tcl Conf 2021)

[<con...@tc...>]

Hello tcllib-devel, fyi ...

# The SQLite & Tcl Conference

__Wednesday, November 17, 2021__

The 2nd annual SQLite & Tcl virtual conference will be held on Wednesday, November 17.
The virtual event will feature a combination of curated talks and work in progress talks (WIPs).

[Registration is open](https://www.eventbrite.com/e/the-sqlite-tcl-conference-st-2021-registration-168185004877)!

Please visit the [SQLite & TCL conference](https://conf.tcl-lang.org/) home page to stay informed.

# Call for Speakers

We've made it easier to contribute by asking for shorter, less formal
talks rather than requiring formal papers.

  - Have you done interesting work that you would like to share?

  - How about a cool idea that's not yet baked or just in the
    prototype stage but seems like something others would be
    interested in? We are particularly interested in new ideas, to
    hear about novel solutions to problems you've faced, or to see
    your work in progress.

## To submit your talk:

Please visit the [call for speakers page](https://conf.tcl-lang.org/callforspeakers/)
for instructions.

As a token of our appreciation, each speaker will be gifted with a
video conferencing light kit to use while presenting.

The call for speakers for S&T 2021 ends on __October 4, 2021 at 11:59 PM CT__.

__Important dates:__

  - October 4 - Call for speakers for S&T 2021 ends at 11:59 PM CT

  - October 8 - We will start notifying speakers with their status of
    their submission and scheduled talk.

  - October 18 - Agenda for S&T 2021 Announced

  - November 17 - S&T 2021 held digitally online  

Re: [Tcllib-devel] Configuration of fossil tickets in tcllib

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

(Richard, you can skip most here, until your name appears near the end)

> Hi,

Finally looking at this. Thu/Fri was a bit distracting. Not work
directly, just issues with one of the business app used by us, where
my data in some other app had a tiny issue, and it broke not the app I
was (trying to) use, but a system it then had to access. Luckily got
fixed within a day, still took enough time and put me off-kilter
enough that regular work was also affected. And I had no desire at the
end of these days to do anything but lounge around.

You may be aware already due to notification mail, both of your
markdown patches are now part of Tcllib. Thank you again for
submitting them.

Also fixed some other issues on trunk, some in the testsuite, exposed
now that I use a pretty minimal setup for the environment, and one
left over from a June commit.

> I noticed that it is not always easy to find the tickets for a logged-in user.
 
> While the ticket report "All Submitted By Me" does list the correct
> ones, the report "My tickets" doesn't. Instead, it lists all tickets
> submitted by 'gahr' only (maybe because this person is the owner of
> the ticket report).

Confirmed.

> I was assuming this report would list all tickets a user is
> associated with in terms of being a submitter, assignee or closer

>From the description I would have thought the same.

> (there's no ticket for that). I suggest to change the ticket name to
> something like "All tickets I am associated with" (or something else
> along these lines) and to change the SQL to this:

> [...]
 
> If that is too much (as some people may have closed or assigned a
> lot of tickets) I suggest to leave out the closers or restrict this
> to open tickets.

The report now is `All Open Or Pending Associated With Me`.
It is limited to open and pending tickets.


Hi Richard! Can you help us with the question below ?

> Also, when searching tickets using the search form that comes up
> when clicking on the "Tickets" menu, it is unclear what and where
> the search is done. I would have expected to get this ticket listed:
 
> https://core.tcl-lang.org/tcllib/tktview?name=7bca91a31c
 
> when searching for "markdown" as it has the string in the summary
> field, but it is not on the result list.

I do not know how this search is done either.

> These are probably all just minor things but thank's for considering
> anyway :-)

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

[Tcllib-devel] Configuration of fossil tickets in tcllib

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

Hi,

I noticed that it is not always easy to find the tickets for a logged-in user.

While the ticket report "All Submitted By Me" does list the correct ones, the report "My tickets" doesn't. Instead, it lists all tickets submitted by 'gahr' only (maybe because this person is the owner of the ticket report).

I was assuming this report would list all tickets a user is associated with in terms of being a submitter, assignee or closer (there's no ticket for that). I suggest to change the ticket name to something like "All tickets I am associated with" (or something else along these lines) and to change the SQL to this:


SELECT
CASE WHEN status='Open'    THEN '#f2dcdc'
     WHEN status='Deleted' THEN '#bde5d6'
     WHEN status='Pending' THEN '#cacae5'
     WHEN status='Closed'  THEN '#c8c8c8'
     ELSE                       '#ffffff'
END AS 'bgcolor',
substr(tkt_uuid,1,10) AS '#',
datetime(tkt_mtime)   AS 'Last Changed',
type                  AS 'Type',
status                AS 'Status',
subsystem             AS 'Subsystem',
title                 AS 'Summary'
FROM ticket
WHERE (submitter = $login OR assignee = $login OR closer = $login)
order by tkt_mtime DESC


If that is too much (as some people may have closed or assigned a lot of tickets) I suggest to leave out the closers or restrict this to open tickets.


Also, when searching tickets using the search form that comes up when clicking on the "Tickets" menu, it is unclear what and where the search is done. I would have expected to get this ticket listed:

https://core.tcl-lang.org/tcllib/tktview?name=7bca91a31c

when searching for "markdown" as it has the string in the summary field, but it is not on the result list.

These are probably all just minor things but thank's for considering anyway :-) 


Regards, Torsten

Re: [Tcllib-devel] Supplemented documentation for markdown package

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

Oops. Lost track of that yesterday (*).

> Der Andreas,
> 
> thanks for taking the time to answer.

> >> What is the recommended way of submitting such a change?
> > 
> >> Should I send it as a ticket on the fossil repository of tcllib?
> > 
> > Yes.

> OK, I'll do that.

Thanks.

> > 
> >> What are actually the requirements to become a contributor who is
> >> able to commit to the repository directly?
> > 
> > How much can you agree with
> > 
> >    https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tcllib/files/devdoc/
> > tcl_community_communication.md
> > 
> > ?

> I had read those documents unter https://core.tcl-lang.org/tcllib/dir?ci=tip&name=devdoc <https://core.tcl-lang.org/tcllib/dir?ci=tip&name=devdoc>

> already because I was looking for some guidance on how to
> contribute. This is totally fine with me and I appreciate you have
> spelled out clearly in the document how the Community is
> working. From your answer I see it works just the same as for the
> core. The more is contributed with good quality, the higher the
> chance will get to be trusted. Fine with me.

Yes, exactly
 
> > Do you plan to submit only documention changes ?
 
> No. I have also looked at the tickets which are open for the
> Markdown module and I think I have fixed this one:
 
> https://core.tcl-lang.org/tcllib/tktview/5b8e3a9e9bb8a12fe4d0 <https://core.tcl-lang.org/tcllib/tktview/5b8e3a9e9bb8a12fe4d0>

Nice. ... Although there is the feeling that the separating line is
needed ... I am wrong. Looking at
[Common Mark](https://spec.commonmark.org/0.30/#example-76),
it agrees with the report.

Note: It is actually example 77, but linking that directly keeps the
preceding explanatory text out of sight.

> I have added a few more test in markdown.test that expose the
> problem and can see that it works now in my version. But I want to
> add some more tests still to be sure I haven't broken something
> else.

Sure.

> I also want to look at the other open ticket on the Markdown module.

Go ahead and thank you ...

> After this, I would really like to add more of the extended markdown
> syntax to the module.

You are going definitely for maintainer here, I believe ;)
Good that you have read all the documents around that already.

> But, before I do this, I would like to have some feedback whether
> such additions are actually appreciated. I am not the original
> author of that package and can understand when the intention is to
> not go beyond the basic markdown implemented. I'll write my own
> version then. However, if this is welcome, I just do the work in
> tcllib and give it back to the Community.

Looping Sean in here. ... That said IIRC he is not the original author
either. I believe the original code was pulled and forked from the
... Caius Project (also MIT license) (Just looked at the code and found the 
ref)

We (Tcllib) have already changes in our code upstream has not
taken. Having more is fine with me. Especially if ours becomes more
capable in the bargain. I cannot speak to Sean's opinion (which is why
I looped him in)

> I also have some private packages here that I am using for years
> now, and at some point I think I am ready to make them
> public. Mostly, they are rather additions to tklib, however.

That sounds really good. Tklib has not had that much love over the
years than it should. It is mainly Csaba updating Tklib's opies of
some of his packages (tablelist, mentry)

(*) The distraction delaying this response was actually me using the
Tklib example `examples/canvas/osm.tcl` as foundation for a small map
widget and then an app enabling me to (relatively) quickly assign (**)
geo coordinates to the pictures I have taken over time. And then using
that to start through my collection, beginning in 2001.

Current image on the left, list in the middle, map display on the
right, various buttons and fields for coordinate display, naming
important coordinates for quick re-selection, etc.

(**) I should note that the assignments are __not__ stored in the
pictures themselves. I save them into a TSV file with the pictures
identified by hash. Plan is to feed that into a larger system for
document storage and indexing, where things can be tagged any which
way. For the longer term future, when I have enough geo tagged data I
will look into reverse geocoding as means of translating them into
addresses.

> > At the beginning I would prefer to get patches via tickets, with
> > possibility to upgrade to commit access after a while.
> 
> Sure, no problem! I am glad to help in whatever way yo find suitable!

Welcome to Tcllib.

> Regards, und beste Grüße aus dem Norden (Lübeck),
> Torsten

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

Re: [Tcllib-devel] Supplemented documentation for markdown package

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

Der Andreas,

thanks for taking the time to answer.

> 
>> What is the recommended way of submitting such a change?
> 
>> Should I send it as a ticket on the fossil repository of tcllib?
> 
> Yes.


OK, I'll do that.

> 
>> What are actually the requirements to become a contributor who is
>> able to commit to the repository directly?
> 
> How much can you agree with
> 
>    https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tcllib/files/devdoc/
> tcl_community_communication.md
> 
> ?


I had read those documents unter https://core.tcl-lang.org/tcllib/dir?ci=tip&name=devdoc <https://core.tcl-lang.org/tcllib/dir?ci=tip&name=devdoc>
already because I was looking for some guidance on how to contribute. This is totally fine with me and I appreciate you have spelled out clearly in the document how the Community is working. From your answer I see it works just the same as for the core. The more is contributed with good quality, the higher the chance will get to be trusted. Fine with me.

> 
> Do you plan to submit only documention changes ?

No. I have also looked at the tickets which are open for the Markdown module and I think I have fixed this one:

https://core.tcl-lang.org/tcllib/tktview/5b8e3a9e9bb8a12fe4d0 <https://core.tcl-lang.org/tcllib/tktview/5b8e3a9e9bb8a12fe4d0>

I have added a few more test in markdown.test that expose the problem and can see that it works now in my version. But I want to add some more tests still to be sure I haven't broken something else.

I also want to look at the other open ticket on the Markdown module.

After this, I would really like to add more of the extended markdown syntax to the module. But, before I do this, I would like to have some feedback whether such additions are actually appreciated. I am not the original author of that package and can understand when the intention is to not go beyond the basic markdown implemented. I'll write my own version then. However, if this is welcome, I just do the work in tcllib and give it back to the Community.

I also have some private packages here that I am using for years now, and at some point I think I am ready to make them public. Mostly, they are rather additions to tklib, however.

> 
> At the beginning I would prefer to get patches via tickets, with
> possibility to upgrade to commit access after a while.

Sure, no problem! I am glad to help in whatever way yo find suitable!


Regards, und beste Grüße aus dem Norden (Lübeck),
Torsten

Re: [Tcllib-devel] Supplemented documentation for markdown package

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

> Dear all,
 
> I found the markdown documentation page could need some more
> information on the actual set of markdown syntax which is supported
> by the package. I looked it up in the module code and added the
> information to the documentation page.
 
> What is the recommended way of submitting such a change?

> Should I send it as a ticket on the fossil repository of tcllib?

Yes.

> What are actually the requirements to become a contributor who is
> able to commit to the repository directly?

How much can you agree with

    https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tcllib/files/devdoc/
tcl_community_communication.md

?

Do you plan to submit only documention changes ?

At the beginning I would prefer to get patches via tickets, with
possibility to upgrade to commit access after a while.

> Regards, Torsten

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

Re: [Tcllib-devel] Supplemented documentation for markdown package

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

Am 13.09.2021 um 11:41 schrieb Torsten Berg:
> Dear all,
> 
> I found the markdown documentation page could need some more information on the actual set of markdown syntax which is supported by the package. I looked it up in the module code and added the information to the documentation page.
> 
> What is the recommended way of submitting such a change? Should I send it as a ticket on the fossil repository of tcllib?
> 
> What are actually the requirements to become a contributor who is able to commit to the repository directly?
> 
> Regards, Torsten


Directly committing is great !
Ask Andreas for commit rights.
I suppose, he will read that, otherwise private E-Mail.
I may help.

Best regards from Berlin to Potsdam,
Harald

[Tcllib-devel] Supplemented documentation for markdown package

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

Dear all,

I found the markdown documentation page could need some more information on the actual set of markdown syntax which is supported by the package. I looked it up in the module code and added the information to the documentation page.

What is the recommended way of submitting such a change? Should I send it as a ticket on the fossil repository of tcllib?

What are actually the requirements to become a contributor who is able to commit to the repository directly?

Regards, Torsten

Re: [Tcllib-devel] proposal: backwards-incompatible improvements to picoirc

[Leonid B. <cur...@di...>]

March 3, 2021 7:23 PM, "Andreas Kupries" <and...@gm...> wrote:

>> Sorry, I didn't check CC header in web client.
>> 
>> March 3, 2021 5:44 PM, "Gerald Lester" <ger...@gm...> wrote:
>> 
>> What needs to be done to make it "complete"?
>> 
>> Maybe do that and bump to 1.0???
>> 
>> Alright, it's good enough the way it is, I'll bump major version number after I'm done.
> 
> @gerald ... Current version is 0.5.2, so no need to increment major
> for big api changes.
> 
> (version < 1.0 ==> No official/proper release yet, API in flux).
> 
> @leonid That said, if you believe that your changes make the package
> good enough for a proper 1.0 release, go for that.
> 

Yes, I think after these changes all this API needs are internal tests and bugfixes.

Also I've noticed that picoirc internally hides ijchain and wubchain nicks (see line 172), I think this creates confusion because it's not clear who sent a message when nicks in IRC and external chat collide.

Are you ok with me removing that behavior?

>> I hope this won't create conflict with Andreas.
> 
> Nope.
> 
>> On 3/3/21 11:35 AM, Leonid Bobrov wrote:
>> 
>> March 3, 2021 5:20 PM, "Gerald Lester" <ger...@gm...> wrote:
>> 
>> On 3/3/21 7:33 AM, curiousbeaver--- via Tcllib-devel wrote:
>> 
>> Hi everyone!
>> 
>> I develop and use my own IRC client https://hub.darcs.net/gay/chatik and I contribute bugfixes to
>> picoirc and chatwidget, I've also improved picoirc by adding TLS support there.
>> 
>> Here's the list of what I'm planning to do:
>> * make picoirc handle MODE messages from server by sending them to callback as traffic mode, this
>> breaks compatibility because my IRC client expects them in callback as system;
>> * make picoirc handle NOTICE messages from server by sending them to callback as traffic notice,
>> this breaks compatibility because someone's IRC client might expect them in callback as system;
>> * make [spliturl] private because there is no reason to use it outside of picoirc;
>> * remove [send] and make [post] behave like [send] when channel is {}.
>> 
>> Let me know if you have any objections.
>> Sounds reasonable as long as you roll the major version number of the package.
>> 
>> Andreas Kupries thinks I should increase minor version number because this is v0 package (which
>> means incomplete?), so I'm not sure which one should be increased.
> 
> --
> Happy Tcling,
> Andreas Kupries <and...@gm...>
> <https://core.tcl-lang.org/akupries>
> <https://akupries.tclers.tk>
> Developer @ SUSE Software Solutions Germany GmbH
> -------------------------------------------------------------------------------

Re: [Tcllib-devel] proposal: backwards-incompatible improvements to picoirc

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

> Sorry, I didn't check CC header in web client.
> 
> March 3, 2021 5:44 PM, "Gerald Lester" <ger...@gm...> wrote:
> 
> > What needs to be done to make it "complete"?
> > 
> > Maybe do that and bump to 1.0???

> Alright, it's good enough the way it is, I'll bump major version number after I'm done.

@gerald ... Current version is 0.5.2, so no need to increment major
for big api changes.

(version < 1.0 ==> No official/proper release yet, API in flux).

@leonid That said, if you believe that your changes make the package
good enough for a proper 1.0 release, go for that.

> I hope this won't create conflict with Andreas.

Nope. 

> > On 3/3/21 11:35 AM, Leonid Bobrov wrote:
> > 
> >> March 3, 2021 5:20 PM, "Gerald Lester" <ger...@gm...> wrote:
> >> 
> >>> On 3/3/21 7:33 AM, curiousbeaver--- via Tcllib-devel wrote:
> >> 
> >> Hi everyone!
> >> 
> >> I develop and use my own IRC client https://hub.darcs.net/gay/chatik and I contribute bugfixes to
> >> picoirc and chatwidget, I've also improved picoirc by adding TLS support there.
> >> 
> >> Here's the list of what I'm planning to do:
> >> * make picoirc handle MODE messages from server by sending them to callback as traffic mode, this
> >> breaks compatibility because my IRC client expects them in callback as system;
> >> * make picoirc handle NOTICE messages from server by sending them to callback as traffic notice,
> >> this breaks compatibility because someone's IRC client might expect them in callback as system;
> >> * make [spliturl] private because there is no reason to use it outside of picoirc;
> >> * remove [send] and make [post] behave like [send] when channel is {}.
> >> 
> >> Let me know if you have any objections.
> >>> Sounds reasonable as long as you roll the major version number of the package.
> >> 
> >> Andreas Kupries thinks I should increase minor version number because this is v0 package (which
> >> means incomplete?), so I'm not sure which one should be increased.

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

Re: [Tcllib-devel] proposal: backwards-incompatible improvements to picoirc

[Leonid B. <cur...@di...>]

Sorry, I didn't check CC header in web client.

March 3, 2021 5:44 PM, "Gerald Lester" <ger...@gm...> wrote:

> What needs to be done to make it "complete"?
> 
> Maybe do that and bump to 1.0???
> 

Alright, it's good enough the way it is, I'll bump major version number after I'm done.

I hope this won't create conflict with Andreas.

> On 3/3/21 11:35 AM, Leonid Bobrov wrote:
> 
>> March 3, 2021 5:20 PM, "Gerald Lester" <ger...@gm...> wrote:
>> 
>>> On 3/3/21 7:33 AM, curiousbeaver--- via Tcllib-devel wrote:
>> 
>> Hi everyone!
>> 
>> I develop and use my own IRC client https://hub.darcs.net/gay/chatik and I contribute bugfixes to
>> picoirc and chatwidget, I've also improved picoirc by adding TLS support there.
>> 
>> Here's the list of what I'm planning to do:
>> * make picoirc handle MODE messages from server by sending them to callback as traffic mode, this
>> breaks compatibility because my IRC client expects them in callback as system;
>> * make picoirc handle NOTICE messages from server by sending them to callback as traffic notice,
>> this breaks compatibility because someone's IRC client might expect them in callback as system;
>> * make [spliturl] private because there is no reason to use it outside of picoirc;
>> * remove [send] and make [post] behave like [send] when channel is {}.
>> 
>> Let me know if you have any objections.
>>> Sounds reasonable as long as you roll the major version number of the package.
>> 
>> Andreas Kupries thinks I should increase minor version number because this is v0 package (which
>> means incomplete?), so I'm not sure which one should be increased.
>> 
>>> -- +------------------------------------------------------------------------+
>>> | Gerald W. Lester |
>>> |"The man who fights for his ideals is the man who is alive." - Cervantes|
>>> +------------------------------------------------------------------------+
> 
> -- +------------------------------------------------------------------------+
> | Gerald W. Lester |
> |"The man who fights for his ideals is the man who is alive." - Cervantes|
> +------------------------------------------------------------------------+

Re: [Tcllib-devel] proposal: backwards-incompatible improvements to picoirc

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

On 3/3/21 7:33 AM, curiousbeaver--- via Tcllib-devel wrote:
> Hi everyone!
>
> I develop and use my own IRC client https://hub.darcs.net/gay/chatik and I contribute bugfixes to picoirc and chatwidget, I've also improved picoirc by adding TLS support there.
>
> Here's the list of what I'm planning to do:
> * make picoirc handle MODE messages from server by sending them to callback as traffic mode, this breaks compatibility because my IRC client expects them in callback as system;
> * make picoirc handle NOTICE messages from server by sending them to callback as traffic notice, this breaks compatibility because someone's IRC client might expect them in callback as system;
> * make [spliturl] private because there is no reason to use it outside of picoirc;
> * remove [send] and make [post] behave like [send] when channel is {}.
>
> Let me know if you have any objections.


Sounds reasonable as long as you roll the major version number of the 
package.


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

[Tcllib-devel] proposal: backwards-incompatible improvements to picoirc

[<cur...@di...>]

Hi everyone!

I develop and use my own IRC client https://hub.darcs.net/gay/chatik and I contribute bugfixes to picoirc and chatwidget, I've also improved picoirc by adding TLS support there.

Here's the list of what I'm planning to do:
* make picoirc handle MODE messages from server by sending them to callback as traffic mode, this breaks compatibility because my IRC client expects them in callback as system;
* make picoirc handle NOTICE messages from server by sending them to callback as traffic notice, this breaks compatibility because someone's IRC client might expect them in callback as system;
* make [spliturl] private because there is no reason to use it outside of picoirc;
* remove [send] and make [post] behave like [send] when channel is {}.

Let me know if you have any objections.

[Tcllib-devel] Call For Presentations - SQLite & Tcl 2020 (Virtual Event)

[<con...@tc...>]

Hello tcllib-devel, fyi ...

SQLite & Tcl 2020 (Virtual Event)
https://www.tcl-lang.org/community/tcl2020/

This year the Tcl conference of past years has been re-imaged as a
virtual event titled __S&T 2020 (SQLite & TCL)__, to be held
__Tuesday, November 10 from 10am to 3pm CDT__. The exact timing is
subject to change depending on the amount of people who sign up to
present a WIP (work in progress) presentation.

The event will be hosted through Zoom.
To register please go to the
[event details on eventbrite](https://www.eventbrite.com/e/st-2020-tickets-122293825123).

Given the Covid-19 virus and all the disruption it's causing, we
thought rather than requiring people to put all the work and time into
creating a full-fledged academic paper, we'd instead make it easier on
contributors by asking for shorter, less formal talks.

Have you done interesting work that you would like to share?

How about a cool idea that's not yet baked or just in the prototype
stage but seems like something others would be interested in?

The SQLite & TCL audience would like to hear about it, and can provide
valuable discussion and feedback. We are particularly interested in
new ideas, to hear about novel solutions to problems you've faced, or
to see your work in progress.

To schedule your talk, please send email to
[vio...@fl...](mailto:vio...@fl...)

Sincerly.