SRFI support matrix is now auto-generated
Lassi Kortela
(03 May 2020 10:09 UTC)
|
Re: SRFI support matrix is now auto-generated
Erkin Batu Altunbas
(03 May 2020 11:42 UTC)
|
Re: SRFI support matrix is now auto-generated
Lassi Kortela
(03 May 2020 11:47 UTC)
|
Re: SRFI support matrix is now auto-generated
Erkin Batu Altunbas
(04 May 2020 16:26 UTC)
|
Re: SRFI support matrix is now auto-generated
Arthur A. Gleckler
(04 May 2020 17:19 UTC)
|
Re: SRFI support matrix is now auto-generated
Erkin Batu Altunbas
(04 May 2020 17:27 UTC)
|
Re: SRFI support matrix is now auto-generated
Erkin Batu Altunbas
(04 May 2020 17:37 UTC)
|
Re: SRFI support matrix is now auto-generated
Arthur A. Gleckler
(03 May 2020 16:25 UTC)
|
Re: SRFI support matrix is now auto-generated
Erkin Batu Altunbas
(03 May 2020 16:46 UTC)
|
Re: SRFI support matrix is now auto-generated
Lassi Kortela
(03 May 2020 17:00 UTC)
|
Re: SRFI support matrix is now auto-generated
Duy Nguyen
(03 May 2020 16:47 UTC)
|
Re: SRFI support matrix is now auto-generated
Lassi Kortela
(03 May 2020 17:26 UTC)
|
Re: SRFI support matrix is now auto-generated
Duy Nguyen
(04 May 2020 08:59 UTC)
|
Re: SRFI support matrix is now auto-generated Lassi Kortela (04 May 2020 13:06 UTC)
|
Re: SRFI support matrix is now auto-generated
Erkin Batu Altunbas
(03 May 2020 17:00 UTC)
|
Re: SRFI support matrix is now auto-generated
Arthur A. Gleckler
(03 May 2020 17:02 UTC)
|
Re: SRFI support matrix is now auto-generated
Lassi Kortela
(03 May 2020 17:05 UTC)
|
Re: SRFI support matrix is now auto-generated
Erkin Batu Altunbas
(03 May 2020 17:09 UTC)
|
Re: SRFI support matrix is now auto-generated
Lassi Kortela
(03 May 2020 17:16 UTC)
|
>> Snow packages should all have an email address somewhere in the package >> metadata (if you download the tar file from snow-fort.org and grep for >> '@' you'll probably be able to find it). Reaching all the different >> authors could take quite a bit of time and work. > > This is why I want some kind of "group author" to have upload access > to snow-fort.org instead of one person. The easiest way to accomplish that would be a shared r7rs-srfi GitHub repo where you can give access to a group of people. The whole repo could then be uploaded to snow-fort as one package. That's how chez-srfi is done in Akku: <https://akkuscm.org/packages/chez-srfi/>. > Though now that I think more > about it, this probably should not be srfi editors (which are about > the documents, not about wasting time on maintaining srfi > implementations for all schemes). In fact, anyone who is willing to contribute fixes to a particular SRFI's sample implementation, or to add an entirely new sample implementation, is allowed to do so. At least that has been my impression of recent activities. Just ask on a SRFI's mailing list and/or send pull requests to the SRFI's GitHub repo :) >> A unified "r7rs-srfi" collection could also make sense. The chez-srfi >> package (from Akku) despite its name is effectively "r6rs-srfi" now. It >> explicitly supports several different R6RS implementations. The same >> could be done for R7RS. > > I'll look more into it. Thanks! Last I checked, @arcfide who curates chez-srfi was quite responsive and helpful so if you have any questions about a similar r7rs project he might be able to help. Göran Weinholt (who I think is subscribed to this list) wrote Akku and also has a lot of experience with r6rs<->r7rs portability. This guy @okuoku as well: <https://github.com/okuoku/yuni>. This is a good idea and it would be great to get a group of people together to do it.