Email list hosting service & mailing list manager

SRFI-metadata-syncing SRFI? noosphere@xxxxxx (08 Nov 2020 21:50 UTC)
Re: SRFI-metadata-syncing SRFI? Vladimir Nikishkin (09 Nov 2020 01:00 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 09:41 UTC)
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 16:15 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 16:36 UTC)
Re: SRFI-metadata-syncing SRFI? Lulu (09 Nov 2020 19:42 UTC)
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 20:35 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 20:57 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 21:05 UTC)
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 23:41 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (10 Nov 2020 07:53 UTC)
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 23:45 UTC)
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 20:49 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 21:11 UTC)
The funnel pattern Lassi Kortela (09 Nov 2020 21:30 UTC)

Re: SRFI-metadata-syncing SRFI? Lulu 09 Nov 2020 19:42 UTC

I'm all in favour of a standardised, minimal way of expressing SRFI
support, or maybe even general features (eg 'this implementation has
native threads') for each implementation. It's worth noting that this
won't be possible for unmaintained implementations, but fortunately their
respective feature sets aren't likely to change any time soon. :-)

> > There's also unnecessary bandwidth being wasted repeatedly downloading
> > tar files, and time spent uncompressing and searching through them for
> > what amounts to a relatively tiny bit of data.
>
> These are non-issues. GitHub and GitLab have tons of bandwidth. Gambit
> is one of the biggest Schemes and running listings/gambit-head.sh takes
> only 4 seconds, including the time GitHub takes to generate us a
> tailor-made tar archive of Gambit's git master.
>

FWIW I'm experimenting with scripts that directly query the GitHub API.
See `external.rkt' in the repo. It might or might not be a cleaner
solution. We'll see!

--
~erkin