* Time for a new release? 3.1.2? @ 2022-09-28 17:53 Duncan Mak 2022-09-29 4:38 ` Per Bothner 0 siblings, 1 reply; 14+ messages in thread From: Duncan Mak @ 2022-09-28 17:53 UTC (permalink / raw) To: kawa mailing list [-- Attachment #1: Type: text/plain, Size: 216 bytes --] Hello Per, It's been over two years since the last release (3.1.1, 2020-01-16), I count 72 commits made to the master branch since then. Would it be a good time to make a 3.1.2 release soon? Thanks! -- Duncan. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Time for a new release? 3.1.2? 2022-09-28 17:53 Time for a new release? 3.1.2? Duncan Mak @ 2022-09-29 4:38 ` Per Bothner 2022-09-29 15:18 ` Arvydas Silanskas 0 siblings, 1 reply; 14+ messages in thread From: Per Bothner @ 2022-09-29 4:38 UTC (permalink / raw) To: Duncan Mak, kawa mailing list On 9/28/22 10:53, Duncan Mak via Kawa wrote: > Hello Per, > > It's been over two years since the last release (3.1.1, 2020-01-16), I > count 72 commits made to the master branch since then. > > Would it be a good time to make a 3.1.2 release soon? Might as well call it 3.2. It would be helpful if someone went through the changes (using 'git log' and **/ChangeLog) to summarize what has change in a format suitable for doc/news.texi. Also make a note of where the manual needs to be updated. Minor tweaks and bug fixes don't need to be mentioned. -- --Per Bothner per@bothner.com http://per.bothner.com/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Time for a new release? 3.1.2? 2022-09-29 4:38 ` Per Bothner @ 2022-09-29 15:18 ` Arvydas Silanskas 2022-10-03 11:36 ` Arvydas Silanskas 0 siblings, 1 reply; 14+ messages in thread From: Arvydas Silanskas @ 2022-09-29 15:18 UTC (permalink / raw) To: Per Bothner; +Cc: Duncan Mak, kawa mailing list [-- Attachment #1: Type: text/plain, Size: 824 bytes --] I can go over it on Sunday, if no one else does it by then. Arvydas 2022-09-29, kt, 07:38 Per Bothner <per@bothner.com> rašė: > > > On 9/28/22 10:53, Duncan Mak via Kawa wrote: > > Hello Per, > > > > It's been over two years since the last release (3.1.1, 2020-01-16), I > > count 72 commits made to the master branch since then. > > > > Would it be a good time to make a 3.1.2 release soon? > > Might as well call it 3.2. > > It would be helpful if someone went through the changes > (using 'git log' and **/ChangeLog) to summarize what has > change in a format suitable for doc/news.texi. > > Also make a note of where the manual needs to be updated. > > Minor tweaks and bug fixes don't need to be mentioned. > > -- > --Per Bothner > per@bothner.com http://per.bothner.com/ > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Time for a new release? 3.1.2? 2022-09-29 15:18 ` Arvydas Silanskas @ 2022-10-03 11:36 ` Arvydas Silanskas 2022-10-21 9:01 ` Arvydas Silanskas 0 siblings, 1 reply; 14+ messages in thread From: Arvydas Silanskas @ 2022-10-03 11:36 UTC (permalink / raw) To: Per Bothner; +Cc: Duncan Mak, kawa mailing list [-- Attachment #1: Type: text/plain, Size: 1257 bytes --] I propose to pause a bit; I remembered one thing that irked me quite a bit, and that is the failing test suite. I think it would be prudent to fix it first before the release. As part of the hacktober festive theme, I'll try to sit down and find time to make a pull request on the matter soon. Arvydas 2022-09-29, kt, 18:18 Arvydas Silanskas <nma.arvydas.silanskas@gmail.com> rašė: > I can go over it on Sunday, if no one else does it by then. > > Arvydas > > 2022-09-29, kt, 07:38 Per Bothner <per@bothner.com> rašė: > >> >> >> On 9/28/22 10:53, Duncan Mak via Kawa wrote: >> > Hello Per, >> > >> > It's been over two years since the last release (3.1.1, 2020-01-16), I >> > count 72 commits made to the master branch since then. >> > >> > Would it be a good time to make a 3.1.2 release soon? >> >> Might as well call it 3.2. >> >> It would be helpful if someone went through the changes >> (using 'git log' and **/ChangeLog) to summarize what has >> change in a format suitable for doc/news.texi. >> >> Also make a note of where the manual needs to be updated. >> >> Minor tweaks and bug fixes don't need to be mentioned. >> >> -- >> --Per Bothner >> per@bothner.com http://per.bothner.com/ >> > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Time for a new release? 3.1.2? 2022-10-03 11:36 ` Arvydas Silanskas @ 2022-10-21 9:01 ` Arvydas Silanskas 2022-10-27 4:50 ` Shawn Wagner 0 siblings, 1 reply; 14+ messages in thread From: Arvydas Silanskas @ 2022-10-21 9:01 UTC (permalink / raw) To: Per Bothner; +Cc: Duncan Mak, kawa mailing list [-- Attachment #1: Type: text/plain, Size: 1847 bytes --] The test suite had been fixed. But then one other thing popped into my mind -- how about the R7RS large red and tangerine support? The SRFIs required seem to be very straightforward, not requiring any pervasive compiler hacking but simply defining some simple libraries. I know R7RS large colors down the road will start including various non-portable / more invasive requirements, but we can decide if we want to support those when we get there. 2022-10-03, pr, 14:36 Arvydas Silanskas <nma.arvydas.silanskas@gmail.com> rašė: > I propose to pause a bit; I remembered one thing that irked me quite a > bit, and that is the failing test suite. I think it would be prudent to fix > it first before the release. As part of the hacktober festive theme, I'll > try to sit down and find time to make a pull request on the matter soon. > > Arvydas > > 2022-09-29, kt, 18:18 Arvydas Silanskas <nma.arvydas.silanskas@gmail.com> > rašė: > >> I can go over it on Sunday, if no one else does it by then. >> >> Arvydas >> >> 2022-09-29, kt, 07:38 Per Bothner <per@bothner.com> rašė: >> >>> >>> >>> On 9/28/22 10:53, Duncan Mak via Kawa wrote: >>> > Hello Per, >>> > >>> > It's been over two years since the last release (3.1.1, 2020-01-16), I >>> > count 72 commits made to the master branch since then. >>> > >>> > Would it be a good time to make a 3.1.2 release soon? >>> >>> Might as well call it 3.2. >>> >>> It would be helpful if someone went through the changes >>> (using 'git log' and **/ChangeLog) to summarize what has >>> change in a format suitable for doc/news.texi. >>> >>> Also make a note of where the manual needs to be updated. >>> >>> Minor tweaks and bug fixes don't need to be mentioned. >>> >>> -- >>> --Per Bothner >>> per@bothner.com http://per.bothner.com/ >>> >> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Time for a new release? 3.1.2? 2022-10-21 9:01 ` Arvydas Silanskas @ 2022-10-27 4:50 ` Shawn Wagner 2022-12-06 9:07 ` Arvydas Silanskas 0 siblings, 1 reply; 14+ messages in thread From: Shawn Wagner @ 2022-10-27 4:50 UTC (permalink / raw) To: Arvydas Silanskas; +Cc: Per Bothner, kawa mailing list [-- Attachment #1: Type: text/plain, Size: 2216 bytes --] I've ported a lot of SRFIs to Kawa at https://gitlab.com/shawn_w/kawalib/-/tree/master though I'm not sure if any of them are included in Red or Tangerine. On Fri, Oct 21, 2022 at 2:02 AM Arvydas Silanskas via Kawa < kawa@sourceware.org> wrote: > The test suite had been fixed. But then one other thing popped into my mind > -- how about the R7RS large red and tangerine support? The SRFIs required > seem to be very straightforward, not requiring any pervasive compiler > hacking but simply defining some simple libraries. I know R7RS large colors > down the road will start including various non-portable / more invasive > requirements, but we can decide if we want to support those when we get > there. > > 2022-10-03, pr, 14:36 Arvydas Silanskas <nma.arvydas.silanskas@gmail.com> > rašė: > > > I propose to pause a bit; I remembered one thing that irked me quite a > > bit, and that is the failing test suite. I think it would be prudent to > fix > > it first before the release. As part of the hacktober festive theme, I'll > > try to sit down and find time to make a pull request on the matter soon. > > > > Arvydas > > > > 2022-09-29, kt, 18:18 Arvydas Silanskas <nma.arvydas.silanskas@gmail.com > > > > rašė: > > > >> I can go over it on Sunday, if no one else does it by then. > >> > >> Arvydas > >> > >> 2022-09-29, kt, 07:38 Per Bothner <per@bothner.com> rašė: > >> > >>> > >>> > >>> On 9/28/22 10:53, Duncan Mak via Kawa wrote: > >>> > Hello Per, > >>> > > >>> > It's been over two years since the last release (3.1.1, 2020-01-16), > I > >>> > count 72 commits made to the master branch since then. > >>> > > >>> > Would it be a good time to make a 3.1.2 release soon? > >>> > >>> Might as well call it 3.2. > >>> > >>> It would be helpful if someone went through the changes > >>> (using 'git log' and **/ChangeLog) to summarize what has > >>> change in a format suitable for doc/news.texi. > >>> > >>> Also make a note of where the manual needs to be updated. > >>> > >>> Minor tweaks and bug fixes don't need to be mentioned. > >>> > >>> -- > >>> --Per Bothner > >>> per@bothner.com http://per.bothner.com/ > >>> > >> > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Time for a new release? 3.1.2? 2022-10-27 4:50 ` Shawn Wagner @ 2022-12-06 9:07 ` Arvydas Silanskas 2023-01-05 21:34 ` Per Bothner 0 siblings, 1 reply; 14+ messages in thread From: Arvydas Silanskas @ 2022-12-06 9:07 UTC (permalink / raw) To: Shawn Wagner; +Cc: Per Bothner, kawa mailing list [-- Attachment #1: Type: text/plain, Size: 2772 bytes --] I'd like to bump a question, would we want to add (for the time being considering only red and tangerine) R7RS-large support? I'm fine with doing necessary work as far as human resources go, but I want to know that this is a direction that people agree with. Shawn, thank you for sharing. Even if it doesn't make it to kawa core, these libraries will be useful to have in personal projects. 2022-10-27, kt, 07:51 Shawn Wagner <shawnw.mobile@gmail.com> rašė: > I've ported a lot of SRFIs to Kawa at > https://gitlab.com/shawn_w/kawalib/-/tree/master though I'm not sure if > any of them are included in Red or Tangerine. > > On Fri, Oct 21, 2022 at 2:02 AM Arvydas Silanskas via Kawa < > kawa@sourceware.org> wrote: > >> The test suite had been fixed. But then one other thing popped into my >> mind >> -- how about the R7RS large red and tangerine support? The SRFIs required >> seem to be very straightforward, not requiring any pervasive compiler >> hacking but simply defining some simple libraries. I know R7RS large >> colors >> down the road will start including various non-portable / more invasive >> requirements, but we can decide if we want to support those when we get >> there. >> >> 2022-10-03, pr, 14:36 Arvydas Silanskas <nma.arvydas.silanskas@gmail.com> >> rašė: >> >> > I propose to pause a bit; I remembered one thing that irked me quite a >> > bit, and that is the failing test suite. I think it would be prudent to >> fix >> > it first before the release. As part of the hacktober festive theme, >> I'll >> > try to sit down and find time to make a pull request on the matter soon. >> > >> > Arvydas >> > >> > 2022-09-29, kt, 18:18 Arvydas Silanskas < >> nma.arvydas.silanskas@gmail.com> >> > rašė: >> > >> >> I can go over it on Sunday, if no one else does it by then. >> >> >> >> Arvydas >> >> >> >> 2022-09-29, kt, 07:38 Per Bothner <per@bothner.com> rašė: >> >> >> >>> >> >>> >> >>> On 9/28/22 10:53, Duncan Mak via Kawa wrote: >> >>> > Hello Per, >> >>> > >> >>> > It's been over two years since the last release (3.1.1, >> 2020-01-16), I >> >>> > count 72 commits made to the master branch since then. >> >>> > >> >>> > Would it be a good time to make a 3.1.2 release soon? >> >>> >> >>> Might as well call it 3.2. >> >>> >> >>> It would be helpful if someone went through the changes >> >>> (using 'git log' and **/ChangeLog) to summarize what has >> >>> change in a format suitable for doc/news.texi. >> >>> >> >>> Also make a note of where the manual needs to be updated. >> >>> >> >>> Minor tweaks and bug fixes don't need to be mentioned. >> >>> >> >>> -- >> >>> --Per Bothner >> >>> per@bothner.com http://per.bothner.com/ >> >>> >> >> >> > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Time for a new release? 3.1.2? 2022-12-06 9:07 ` Arvydas Silanskas @ 2023-01-05 21:34 ` Per Bothner 2023-01-05 22:02 ` Damien Mattei ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Per Bothner @ 2023-01-05 21:34 UTC (permalink / raw) To: Arvydas Silanskas; +Cc: kawa mailing list On 12/6/22 01:07, Arvydas Silanskas wrote: > I'd like to bump a question, would we want to add (for the time being considering only red and tangerine) R7RS-large support? I'm fine with doing necessary work as far as human resources go, but I want to know that this is a direction that people agree with. I think the R7RS-large process is off-track, and is unlikely to reach any useful destination without a fundamental course-correction. Piling on more and more different-but-similar libraries is not the way to do a programming language in the 21st century. Even Common Lisp realized that different differently-named functions for every useful data-type is not good language design. Scheme needs some way to define "interfaces"/"traits" that multiple data-types can implement. Many Scheme implementations (including Kawa) have that, but a general portable solution is highly desired. Without that, there is no point in piling on more and more libraries for more and more data types. I am not the only one who feels this way, as you can see from the SRFI/R7RS mailing lists. -- --Per Bothner per@bothner.com http://per.bothner.com/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Time for a new release? 3.1.2? 2023-01-05 21:34 ` Per Bothner @ 2023-01-05 22:02 ` Damien Mattei 2023-01-06 12:16 ` Lassi Kortela 2023-01-08 18:11 ` Sascha Ziemann 2 siblings, 0 replies; 14+ messages in thread From: Damien Mattei @ 2023-01-05 22:02 UTC (permalink / raw) To: kawa mailing list; +Cc: Arvydas Silanskas, shawnw.mobile [-- Attachment #1: Type: text/plain, Size: 1789 bytes --] Hello, if the SRFI 105 (curly infix) is ported to Kawa i could easily release a Scheme+ version for Kawa as i already did it for Guile and Racket: https://github.com/damien-mattei/Scheme-PLUS-for-Guile i have little understanding of the implementation of SRFI 105 but i succeed in implementing it for Racket indeed: https://github.com/damien-mattei/Scheme-PLUS-for-Racket https://pkgd.racket-lang.org/pkgn/package/Scheme-PLUS-for-Racket SRFI 105 and scheme+ could be interesting as language for Kawa Damien On Thu, Jan 5, 2023 at 10:34 PM Per Bothner <per@bothner.com> wrote: > > > On 12/6/22 01:07, Arvydas Silanskas wrote: > > I'd like to bump a question, would we want to add (for the time being > considering only red and tangerine) R7RS-large support? I'm fine with doing > necessary work as far as human resources go, but I want to know that this > is a direction that people agree with. > > I think the R7RS-large process is off-track, and is unlikely to reach any > useful destination > without a fundamental course-correction. Piling on more and more > different-but-similar > libraries is not the way to do a programming language in the 21st > century. Even Common Lisp > realized that different differently-named functions for every useful > data-type is not > good language design. > > Scheme needs some way to define "interfaces"/"traits" that multiple > data-types > can implement. Many Scheme implementations (including Kawa) have that, but > a > general portable solution is highly desired. Without that, there is no > point > in piling on more and more libraries for more and more data types. > > I am not the only one who feels this way, as you can see from the > SRFI/R7RS mailing lists. > -- > --Per Bothner > per@bothner.com http://per.bothner.com/ > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Time for a new release? 3.1.2? 2023-01-05 21:34 ` Per Bothner 2023-01-05 22:02 ` Damien Mattei @ 2023-01-06 12:16 ` Lassi Kortela 2023-01-08 18:11 ` Sascha Ziemann 2 siblings, 0 replies; 14+ messages in thread From: Lassi Kortela @ 2023-01-06 12:16 UTC (permalink / raw) To: Per Bothner, Arvydas Silanskas; +Cc: kawa mailing list > I think the R7RS-large process is off-track, and is unlikely to reach > any useful destination > without a fundamental course-correction. Piling on more and more > different-but-similar > libraries is not the way to do a programming language in the 21st > century. Even Common Lisp > realized that different differently-named functions for every useful > data-type is not > good language design. > > Scheme needs some way to define "interfaces"/"traits" that multiple > data-types > can implement. Many Scheme implementations (including Kawa) have that, > but a > general portable solution is highly desired. Without that, there is no > point > in piling on more and more libraries for more and more data types. > > I am not the only one who feels this way, as you can see from the > SRFI/R7RS mailing lists. Thank you for saying this, Per. Agreed on all counts. We just had another round of discussions on the SRFI lists. Like the earlier ones, it went nowhere. The core group cannot examine its own flaws. I'm leaving and starting alternatives. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Time for a new release? 3.1.2? 2023-01-05 21:34 ` Per Bothner 2023-01-05 22:02 ` Damien Mattei 2023-01-06 12:16 ` Lassi Kortela @ 2023-01-08 18:11 ` Sascha Ziemann 2023-01-09 9:03 ` Lassi Kortela 2 siblings, 1 reply; 14+ messages in thread From: Sascha Ziemann @ 2023-01-08 18:11 UTC (permalink / raw) To: kawa mailing list > Scheme needs some way to define "interfaces"/"traits" that multiple data-types > can implement. Many Scheme implementations (including Kawa) have that, but a > general portable solution is highly desired. Without that, there is no point > in piling on more and more libraries for more and more data types. This requires generics and this requires method dispatching. Many Schemers like to pay the price for dynamic types, but are scared by the price for dynamic dispatching. I am still astonished why this is the case. Any ideas? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Time for a new release? 3.1.2? 2023-01-08 18:11 ` Sascha Ziemann @ 2023-01-09 9:03 ` Lassi Kortela 2023-01-09 9:42 ` Arvydas Silanskas 0 siblings, 1 reply; 14+ messages in thread From: Lassi Kortela @ 2023-01-09 9:03 UTC (permalink / raw) To: Sascha Ziemann, kawa mailing list >> Scheme needs some way to define "interfaces"/"traits" that multiple data-types >> can implement. Many Scheme implementations (including Kawa) have that, but a >> general portable solution is highly desired. Without that, there is no point >> in piling on more and more libraries for more and more data types. > This requires generics and this requires method dispatching. > > Many Schemers like to pay the price for dynamic types, but are scared by the > price for dynamic dispatching. I am still astonished why this is the case. The efficiency debate can only be settled by profiling and benchmarking. > Any ideas? IMHO the right solution is: - Specify generic collection procedures in RnRS. - Those procedures MUST handle all the collection types in RnRS. - The procedures SHOULD also handle extra collection types provided by the Scheme implementation (from SRFIs, etc.) - The implementation MAY support user-defined generic procedures. When it does, the standard collection procedures SHOULD be defined using this framework so that users can extend them. The RnRS number procedures are already generic, and work according to these principles (e.g. Kawa extends them to support quaternions). This approach is simple, flexible, and has stood the test of time. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Time for a new release? 3.1.2? 2023-01-09 9:03 ` Lassi Kortela @ 2023-01-09 9:42 ` Arvydas Silanskas 2023-01-09 10:51 ` Lassi Kortela 0 siblings, 1 reply; 14+ messages in thread From: Arvydas Silanskas @ 2023-01-09 9:42 UTC (permalink / raw) To: Lassi Kortela; +Cc: Sascha Ziemann, kawa mailing list [-- Attachment #1: Type: text/plain, Size: 2311 bytes --] The way I understand the r7rs-large process, is that it tries to split out low floor difficulty / portable concerns (eg., streams) from high floor difficulty / not-portable concerns (syntax-case, etc), so that implementations could choose to implement some but not all of it, to extent that is feasible (I wasn't there when it happened, but my understanding of r6rs controversies was mostly to do with implementers getting handed uncompromising burden of implementation requirements). In that view, it seems sensible to me to have both specific procedures now and plausibly generic procedures later. Also, specific procedures enable more deterministic optimization opportunities. Number system is generic in the standard, but we also have eg. srfi 143 providing non-generic procedures with "allow more efficient implementations" stated as the core reasoning. 2023-01-09, pr, 11:03 Lassi Kortela <lassi@lassi.io> rašė: > >> Scheme needs some way to define "interfaces"/"traits" that multiple > data-types > >> can implement. Many Scheme implementations (including Kawa) have that, > but a > >> general portable solution is highly desired. Without that, there is no > point > >> in piling on more and more libraries for more and more data types. > > > This requires generics and this requires method dispatching. > > > > Many Schemers like to pay the price for dynamic types, but are scared by > the > > price for dynamic dispatching. I am still astonished why this is the > case. > > The efficiency debate can only be settled by profiling and benchmarking. > > > Any ideas? > > IMHO the right solution is: > > - Specify generic collection procedures in RnRS. > > - Those procedures MUST handle all the collection types in RnRS. > > - The procedures SHOULD also handle extra collection types provided by > the Scheme implementation (from SRFIs, etc.) > > - The implementation MAY support user-defined generic procedures. When > it does, the standard collection procedures SHOULD be defined using this > framework so that users can extend them. > > The RnRS number procedures are already generic, and work according to > these principles (e.g. Kawa extends them to support quaternions). This > approach is simple, flexible, and has stood the test of time. > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Time for a new release? 3.1.2? 2023-01-09 9:42 ` Arvydas Silanskas @ 2023-01-09 10:51 ` Lassi Kortela 0 siblings, 0 replies; 14+ messages in thread From: Lassi Kortela @ 2023-01-09 10:51 UTC (permalink / raw) To: Arvydas Silanskas; +Cc: Sascha Ziemann, kawa mailing list > The way I understand the r7rs-large process, is that it tries to split > out low floor difficulty / portable concerns (eg., streams) from high > floor difficulty / not-portable concerns (syntax-case, etc), so that > implementations could choose to implement some but not all of it, to > extent that is feasible Modularity is the only way forward for RnRS. > (I wasn't there when it happened, but my > understanding of r6rs controversies was mostly to do with implementers > getting handed uncompromising burden of implementation requirements). The disagreements are about style as well as complexity. > In that view, it seems sensible to me to have both specific procedures now > and plausibly generic procedures later. Also, specific procedures enable > more deterministic optimization opportunities. Number system is generic > in the standard, but we also have eg. srfi 143 providing non-generic > procedures with "allow more efficient implementations" stated as the > core reasoning. Yes. R6RS also added fixnum procedures. The existing specific procedures have to be kept for backward compatibility. Whether new ones should be added is another matter. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2023-01-09 10:51 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-09-28 17:53 Time for a new release? 3.1.2? Duncan Mak 2022-09-29 4:38 ` Per Bothner 2022-09-29 15:18 ` Arvydas Silanskas 2022-10-03 11:36 ` Arvydas Silanskas 2022-10-21 9:01 ` Arvydas Silanskas 2022-10-27 4:50 ` Shawn Wagner 2022-12-06 9:07 ` Arvydas Silanskas 2023-01-05 21:34 ` Per Bothner 2023-01-05 22:02 ` Damien Mattei 2023-01-06 12:16 ` Lassi Kortela 2023-01-08 18:11 ` Sascha Ziemann 2023-01-09 9:03 ` Lassi Kortela 2023-01-09 9:42 ` Arvydas Silanskas 2023-01-09 10:51 ` Lassi Kortela
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).