tcllib-devel — Discussion of development for tcllib

[Tcllib-devel] Links to package revisions with Tcl 9.0b1 support

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

Hi.

enclosed a link to a technote in the tcllib timeline which in turn links to 
the revisions of Tcllib, Critcl, and Kettle supporting Tcl 9.0b1.

Note that these are not official releases of the packages in question.
Just revisions having the desired support.

https://core.tcl-lang.org/tcllib/technote/ecc5be7f13dd1ab4fbe5f4cc6ecd07e42a7d2
69e

-- 
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] [TCLCORE] FW: [Tcllib] (oehhar) tkt (Closed): math::geometry::direction and octant counts clockwise instead of counterclockwise

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

Hi Steve,
thanks for the action, great !
I did the same, and reverted the pages on the wiki.

On one moderate, I pressed unfortunately the accept button in this 
ticket comment:
https://core.tcl-lang.org/tcl/info/267b7e2334ee2e9d
But you removed the comment, great!

And the changes are gone from the wiki and even the changes page does 
not show them.

Great work, thank you !
Harald


Am 03.12.2023 um 11:52 schrieb Steve Landers:
> I can’t agree that the repository has been compromised, it is simply 
> that someone has created tickets containing spam and they were 
> automatically held for moderation.  Anyone with admin authority can shun 
> the tickets, which I’ve done.
> 
> -- Steve
> On 3 Dec 2023 at 6:23 PM +0800, Arjen Markus <Arj...@de...>, 
> wrote:
>> Hi everyone,
>>
>> As Harald has also noticed, the Tcllib repository has been 
>> compromised. I have no idea how to remove a comment, so I am reaching 
>> out to the wider community for this.
>>
>> Regards,
>>
>> Arjen
>>
>> -----Original Message-----
>> From: no...@tc... <no...@tc...>
>> Sent: Saturday, December 2, 2023 8:24 PM
>> To: Arjen Markus <Arj...@de...>
>> Subject: [Tcllib] (oehhar) tkt (Closed): math::geometry::direction and 
>> octant counts clockwise instead of counterclockwise
>>
>> 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..." as an attachment.
>>
>>
>> Automated mail by fx, on behalf of no...@tc...
>>
>> Ticket Change 
>> [4f1eb40a7c05930755ebe3aa52e7c2ab214113c9d6dbd6300b9639b7cafbaab9]
>> [math::geometry::direction and octant counts clockwise instead of 
>> counterclockwise]
>> By oehhar
>> For Tcllib
>> On 2023-12-02T19:23:42.251
>> Details 
>> https://core.tcl-lang.org/tcllib/tinfo?name=4f1eb40a7c05930755ebe3aa52e7c2ab214113c9d6dbd6300b9639b7cafbaab9
>> Ticket 
>> https://core.tcl-lang.org/tcllib/tktview/fb4812f82b4894d5b80c0594944cffec516cd3d6
>>
>> Changed Fields
>> icomment: Could someone remove the last comment? It is an online Casino.
>>
>> Take care, Harald
>> login: oehhar
>> username: oehhar
>>
>> ------------------------------------------------------------
>> See Tcl/Tk development @ http://core.tcl-lang.org/
>> ------------------------------------------------------------
>> 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: [Tcllib-devel] [TCLCORE] FW: [Tcllib] (oehhar) tkt (Closed): math::geometry::direction and octant counts clockwise instead of counterclockwise

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

> I can’t agree that the repository has been compromised, it is simply that someone has created tickets containing spam and they were automatically held for moderation.  Anyone with admin authority can shun the tickets, which I’ve done.
> 

Thank you. Was about to look into this after lunch. In tcllib I have now 
removed all permissions from the self-registered user `osmancan`, and 
randomized the password.

Further `fossil rebuild` the repo so that the shunned pieces are fully gone.

> -- Steve
> On 3 Dec 2023 at 6:23 PM +0800, Arjen Markus <Arj...@de...>, wrote:
> > Hi everyone,
> >
> > As Harald has also noticed, the Tcllib repository has been compromised. I have no idea how to remove a comment, so I am reaching out to the wider community for this.
> >
> > Regards,
> >
> > Arjen
> >
> > -----Original Message-----
> > From: no...@tc... <no...@tc...>
> > Sent: Saturday, December 2, 2023 8:24 PM
> > To: Arjen Markus <Arj...@de...>
> > Subject: [Tcllib] (oehhar) tkt (Closed): math::geometry::direction and octant counts clockwise instead of counterclockwise
> >
> > 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..." as an attachment.
> >
> >
> > Automated mail by fx, on behalf of no...@tc...
> >
> > Ticket Change [4f1eb40a7c05930755ebe3aa52e7c2ab214113c9d6dbd6300b9639b7cafbaab9]
> > [math::geometry::direction and octant counts clockwise instead of counterclockwise]
> > By oehhar
> > For Tcllib
> > On 2023-12-02T19:23:42.251
> > Details https://core.tcl-lang.org/tcllib/tinfo?name=4f1eb40a7c05930755ebe3aa52e7c2ab214113c9d6dbd6300b9639b7cafbaab9
> > Ticket https://core.tcl-lang.org/tcllib/tktview/fb4812f82b4894d5b80c0594944cffec516cd3d6
> >
> > Changed Fields
> > icomment: Could someone remove the last comment? It is an online Casino.
> >
> > Take care, Harald
> > login: oehhar
> > username: oehhar
> >
> > ------------------------------------------------------------
> > See Tcl/Tk development @ http://core.tcl-lang.org/
> > ------------------------------------------------------------
> > 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.
> >
> >
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
> >
> 
> 

-- 
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] [TCLCORE] FW: [Tcllib] (oehhar) tkt (Closed): math::geometry::direction and octant counts clockwise instead of counterclockwise

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

I can’t agree that the repository has been compromised, it is simply that someone has created tickets containing spam and they were automatically held for moderation.  Anyone with admin authority can shun the tickets, which I’ve done.

-- Steve
On 3 Dec 2023 at 6:23 PM +0800, Arjen Markus <Arj...@de...>, wrote:
> Hi everyone,
>
> As Harald has also noticed, the Tcllib repository has been compromised. I have no idea how to remove a comment, so I am reaching out to the wider community for this.
>
> Regards,
>
> Arjen
>
> -----Original Message-----
> From: no...@tc... <no...@tc...>
> Sent: Saturday, December 2, 2023 8:24 PM
> To: Arjen Markus <Arj...@de...>
> Subject: [Tcllib] (oehhar) tkt (Closed): math::geometry::direction and octant counts clockwise instead of counterclockwise
>
> 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..." as an attachment.
>
>
> Automated mail by fx, on behalf of no...@tc...
>
> Ticket Change [4f1eb40a7c05930755ebe3aa52e7c2ab214113c9d6dbd6300b9639b7cafbaab9]
> [math::geometry::direction and octant counts clockwise instead of counterclockwise]
> By oehhar
> For Tcllib
> On 2023-12-02T19:23:42.251
> Details https://core.tcl-lang.org/tcllib/tinfo?name=4f1eb40a7c05930755ebe3aa52e7c2ab214113c9d6dbd6300b9639b7cafbaab9
> Ticket https://core.tcl-lang.org/tcllib/tktview/fb4812f82b4894d5b80c0594944cffec516cd3d6
>
> Changed Fields
> icomment: Could someone remove the last comment? It is an online Casino.
>
> Take care, Harald
> login: oehhar
> username: oehhar
>
> ------------------------------------------------------------
> See Tcl/Tk development @ http://core.tcl-lang.org/
> ------------------------------------------------------------
> 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.
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

[Tcllib-devel] FW: [Tcllib] (oehhar) tkt (Closed): math::geometry::direction and octant counts clockwise instead of counterclockwise

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

Hi everyone,

As Harald has also noticed, the Tcllib repository has been compromised. I have no idea how to remove a comment, so I am reaching out to the wider community for this.

Regards,

Arjen

-----Original Message-----
From: no...@tc... <no...@tc...>
Sent: Saturday, December 2, 2023 8:24 PM
To: Arjen Markus <Arj...@de...>
Subject: [Tcllib] (oehhar) tkt (Closed): math::geometry::direction and octant counts clockwise instead of counterclockwise

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..." as an attachment.


Automated mail by fx, on behalf of no...@tc...

Ticket Change [4f1eb40a7c05930755ebe3aa52e7c2ab214113c9d6dbd6300b9639b7cafbaab9]
  [math::geometry::direction and octant counts clockwise instead of counterclockwise]
  By      oehhar
  For     Tcllib
  On      2023-12-02T19:23:42.251
  Details https://core.tcl-lang.org/tcllib/tinfo?name=4f1eb40a7c05930755ebe3aa52e7c2ab214113c9d6dbd6300b9639b7cafbaab9
  Ticket  https://core.tcl-lang.org/tcllib/tktview/fb4812f82b4894d5b80c0594944cffec516cd3d6

Changed Fields
  icomment: Could someone remove the last comment?  It is an online Casino.

            Take care,  Harald
  login:    oehhar
  username: oehhar

------------------------------------------------------------
See Tcl/Tk development @ http://core.tcl-lang.org/
------------------------------------------------------------
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: [Tcllib-devel] would it be possible to extend crc16 in tcllib

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

HI Andreas, Markus,

Great, that has already been taken care of then 😊.

Regards,

Arjen

-----Original Message-----
From: Andreas Kupries <and...@gm...>
Sent: Wednesday, November 8, 2023 9:42 PM
To: Arjen Markus <Arj...@de...>; mar...@we...; tcl...@li...
Subject: Re: [Tcllib-devel] would it be possible to extend crc16 in tcllib

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..." as an attachment.


Hi all.

> Hello Markus,

> We can certainly add this to the Tcl library, but what is lacking is a
> description and test cases. Could you supply these too? (I am not an
> expert on these CRC methods, so I am utterly unable to judge the code or to help out with the specific test cases ????).

I took a look and tests and docs were relatively easy and trivial to add.
I have now done so, and committed the result (pushed also).
The new code is has version 1.1.5.
See:

        https://core.tcl-lang.org/tcllib/info/a061c12325631216

Tempted to make a 1.2 which requires Tcl 8.6 and then looks for possible code simplifications.

Beyond that, definitely agreed with Arjen that patches should come with tests and docs.

> Hi,
> i use a rs485 converter to read serial data from a solar inverters and a electricity meter. crc16 is used to check the transmission.
> these methods are currently available in tcllib:

> however, other crc codes are used. would it be possible to extend crc16 with these codes in tcllib 1.21 and above?
> #   KERMIT:    0x2189
> #   MODBUS:    0x4B37
> #   MCRF4XX:   0x6F91
> #   GENIBUS:   0xD64E
> #   X.25:      0x906E
> #   SDLC:      0x906E
> #   USB:       0xB4C8
> #   BUYPASS:   0xFEE8
> #   UMTS:      0xFEE8
> #   GSM:       0xCE3C
> #   MAXIM:     0x44C2
> #   CMS:       0xAEE7

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




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: [Tcllib-devel] would it be possible to extend crc16 in tcllib

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

Hi all.

> Hello Markus,

> We can certainly add this to the Tcl library, but what is lacking is a description and test
> cases. Could you supply these too? (I am not an expert on these CRC methods, so I am utterly
> unable to judge the code or to help out with the specific test cases 😊).

I took a look and tests and docs were relatively easy and trivial to add.
I have now done so, and committed the result (pushed also).
The new code is has version 1.1.5.
See:

	https://core.tcl-lang.org/tcllib/info/a061c12325631216

Tempted to make a 1.2 which requires Tcl 8.6 and then looks for possible code 
simplifications.

Beyond that, definitely agreed with Arjen that patches should come with tests 
and docs.
 
> Hi, 
> i use a rs485 converter to read serial data from a solar inverters and a electricity meter. crc16 is used to check the transmission.
> these methods are currently available in tcllib:

> however, other crc codes are used. would it be possible to extend crc16 with these codes in tcllib 1.21 and above?
> #   KERMIT:    0x2189
> #   MODBUS:    0x4B37
> #   MCRF4XX:   0x6F91
> #   GENIBUS:   0xD64E
> #   X.25:      0x906E
> #   SDLC:      0x906E
> #   USB:       0xB4C8
> #   BUYPASS:   0xFEE8
> #   UMTS:      0xFEE8
> #   GSM:       0xCE3C
> #   MAXIM:     0x44C2
> #   CMS:       0xAEE7

-- 
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] would it be possible to extend crc16 in tcllib

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

Hello Markus,

We can certainly add this to the Tcl library, but what is lacking is a description and test cases. Could you supply these too? (I am not an expert on these CRC methods, so I am utterly unable to judge the code or to help out with the specific test cases 😊).

Regards,

Arjen

From: mar...@we... <mar...@we...>
Sent: Wednesday, November 8, 2023 12:05 PM
To: tcl...@li...
Subject: [Tcllib-devel] would it be possible to extend crc16 in tcllib

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,

i use a rs485 converter to read serial data from a solar inverters and a electricity meter. crc16 is used to check the transmission.
these methods are currently available in tcllib:
# CRC16: 0xBB3D
# CRC-CCITT: 0x29B1
# XMODEM: 0x31C3
# CRC-32: 0xCBF43926

however, other crc codes are used. would it be possible to extend crc16 with these codes in tcllib 1.21 and above?
#   KERMIT:    0x2189
#   MODBUS:    0x4B37
#   MCRF4XX:   0x6F91
#   GENIBUS:   0xD64E
#   X.25:      0x906E
#   SDLC:      0x906E
#   USB:       0xB4C8
#   BUYPASS:   0xFEE8
#   UMTS:      0xFEE8
#   GSM:       0xCE3C
#   MAXIM:     0x44C2
#   CMS:       0xAEE7

See table Appendix A in http://reveng.sourceforge.net/crc-catalogue/all.htm

i have integrated these changes into the tcllib1.21/crc/crc16.tcl file, but they are overwritten with every new update.
For example, i have attached the extended file. all places where a change was made were marked with MMMMMM

best regards
markus ort

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.

[Tcllib-devel] would it be possible to extend crc16 in tcllib

[<mar...@we...>]

Hi,



i use a rs485 converter to read serial data from a solar inverters and a
electricity meter. crc16 is used to check the transmission.

these methods are currently available in tcllib:

# CRC16: 0xBB3D

# CRC-CCITT: 0x29B1

# XMODEM: 0x31C3

# CRC-32: 0xCBF43926



however, other crc codes are used. would it be possible to extend crc16 with
these codes in tcllib 1.21 and above?

#   KERMIT:    0x2189

#   MODBUS:    0x4B37

#   MCRF4XX:   0x6F91

#   GENIBUS:   0xD64E

#   X.25:      0x906E

#   SDLC:      0x906E

#   USB:       0xB4C8

#   BUYPASS:   0xFEE8

#   UMTS:      0xFEE8

#   GSM:       0xCE3C

#   MAXIM:     0x44C2

#   CMS:       0xAEE7



See table Appendix A in http://reveng.sourceforge.net/crc-catalogue/all.htm



i have integrated these changes into the tcllib1.21/crc/crc16.tcl file, but
they are overwritten with every new update.

For example, i have attached the extended file. all places where a change
was made were marked with MMMMMM



best regards

markus ort

Re: [Tcllib-devel] Tklib Map work

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

Am 15.12.2022 um 20:49 schrieb Andreas Kupries:
> 
> Related to Critcl 3.2 and Tcllib's `map::slippy` updates, Tklib has gained a
> new set of `map::*`
> packages to show maps and associated data (areas, tracks (paths), boxes,
> points).
> 
> Based mainly on the new `map::slippy`, `canvas::sqmap`, the `canvas::edit::*`
> packages, and a few
> other `canvas::*` packages.
> 
> Demo applications show basic maps, maps with additional features, and maps
> with data entry features
> (boxes, areas, tracks).
> 
> See commit [76668aeace]
> 
> The work on this comes out of a private project and was put into Tklib as the
> functionality was
> pretty much independent of that project. Only the connection to the database
> of geo features is
> dependent on that. IOW custom store implementations are needed for it.
> 
> Happy Xmas and a good new year.
> 

Yes, impressive work! It was great to watch your demonstration at the 
ETCL call last week.

Happy Xmas and a good new year.
Harald

[Tcllib-devel] Tklib Map work

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

Related to Critcl 3.2 and Tcllib's `map::slippy` updates, Tklib has gained a 
new set of `map::*`
packages to show maps and associated data (areas, tracks (paths), boxes, 
points).

Based mainly on the new `map::slippy`, `canvas::sqmap`, the `canvas::edit::*` 
packages, and a few
other `canvas::*` packages.

Demo applications show basic maps, maps with additional features, and maps 
with data entry features
(boxes, areas, tracks).

See commit [76668aeace]

The work on this comes out of a private project and was put into Tklib as the 
functionality was
pretty much independent of that project. Only the connection to the database 
of geo features is
dependent on that. IOW custom store implementations are needed for it.

Happy Xmas and a good new year.

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

[Tcllib-devel] Tcllib Map Work

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

Related to Critcl 3.2, the C accelerator for Tcllib's `map::slippy` package 
makes use of new 3.2
features. Specifically of the `[]type` syntax for list types.

See commit [2e83f22d34].

Happy Xmas and a good new year.

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

[Tcllib-devel] Critcl 3.2 is available

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

For the detailed changes see

https://andreas-kupries.github.io/critcl/doc/files/critcl_changes.html#section2

====

Two BREAKING changes since 3.1.18.1

  1. Tcl Core Version

       - 3.2 needs Tcl 8.6 to run
       - 3.2 generates Tcl 8.6 extensions by default
       - 3.2 is __still able__ to generate 8.4/8.5 extensions
       	 (See `critcl::tcl` command)

  2. The syntax of `build.tcl install` was wholly rewritten.
     Scripts using it have to be adapted.

FEATURES

  1. `cproc` allows near-C argument syntax.

     IOW `cproc foo {double alpha, int max} ...` is now ok.
     As are `cproc foo {double alpha ,int max} ...`
     and `cproc foo {double alpha , int max} ...`
     Note the comma in its various locations.

  1. `cproc` allows range-limited scalar types. I.e. `int > 3 < 10`
     is now a type limited to integer values in the range `4..9`.
     Can use all of `>`, `>=`, `<`, `<=`, in combinations.

  1. `cproc` now allows length-limited lists, type-restricted lists, and in
     combination.

     For example, `[4]` is a generic list limited to exactly 4 elements.

     Wheras `[]int` (and `int[]`) are lists whose elements have to be integers.

     And `[4]int` combines the length limit and type restrictions.

     The types `[]` (and `[*]`) are aliases of the existing basic `list` type.

     For syntax nearer to C the form `type foo[]` etc, for an argument `foo` is
     recognized too.

     Limitation: It is not possible to nest lists, nor can they be combined 
with
     range-limited scalars. I.e. types like `[][][]foo` are not possible, nor
     `[]int > 0`, or similar.

     This is used by Tcllib's updated `map::slippy` C accelerator to handle
     lists of geographic locations, boxes, points, ... See commit [2e83f22d34]

Happy Xmas and good new year.

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

[Tcllib-devel] Tcllib 1.21 Released

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

For the details please see

https://core.tcl-lang.org/tcllib/technote/7a047636411e9c9d8e1410ddee0fb02d1458a
7c0

-- 
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

[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
-------------------------------------------------------------------------------