Determining the correct, most up-to-date source/document for scraping CHICKEN SRFI metadata from

[noosphere]

Summary:

The "SRFI Table" project, which scrapes information about Chicken SRFI
support, needs to find an authoritative and up-to-date source of this
information.

Background:

Many of you will be familiar with the "SRFI Table" web page[1], which
shows which SRFIs are supported by which Scheme implementations.

A few days ago I found out that the Chicken SRFI support listed on that
document was being scraped from a Chicken wiki page[2] that hadn't been
updated since 2019.

I found this out right after I'd created my new Chicken SRFI Support
table wiki page,[3] which I had generated from an org-mode document in
which I'd compiled from various sources on the Chicken wiki.

I mentioned this to erkin (who authored the SRFI Table) on #scheme, who
decided to scrape the org-mode document, since at the time it was the
source of truth for the Chicken SRFI Support table wiki page, which at
least as of a few days ago was the most up-to-date source of this
information.

But this org-mode document is neither a reliable nor authoritative
source for this information, and it can and has gotten out of sync with
what SRFIs chicken actually supports.

The "Supported Standards" page[4], which is another source of Chicken
SRFI support information is not complete either.

There seems to be no one wiki page which is guaranteed to
be either authoritative or complete which could be used by the SRFI
Table project to find out which SRFIs Chicken supports.

Issue:

At erikn's request I've documented the issue with more detail on the
project's repo:

  https://github.com/schemedoc/srfi-metadata/issues/13

Anyone interested in making sure the SRFI Table stays up-to-date with
the SRFIs that Chicken supports is encouraged to read that issue and
make suggestions.

  --Sergey

[1] - https://htmlpreview.github.io/?https://github.com/schemedoc/srfi-metadata/blob/master/table.html

[2] - https://wiki.call-cc.org/SRFI-conformance

[3] - https://wiki.call-cc.org/srfi-support

[4] - https://wiki.call-cc.org/supported-standards

[Mario Domenech Goulart-4]

Hi,

On Wed, 11 Nov 2020 05:07:58 -0800 [hidden email] wrote:

> Summary:
>
> The "SRFI Table" project, which scrapes information about Chicken SRFI
> support, needs to find an authoritative and up-to-date source of this
> information.
>
> Background:
>
> Many of you will be familiar with the "SRFI Table" web page[1], which
> shows which SRFIs are supported by which Scheme implementations.
>
> A few days ago I found out that the Chicken SRFI support listed on that
> document was being scraped from a Chicken wiki page[2] that hadn't been
> updated since 2019.
>
> I found this out right after I'd created my new Chicken SRFI Support
> table wiki page,[3] which I had generated from an org-mode document in
> which I'd compiled from various sources on the Chicken wiki.
>
> I mentioned this to erkin (who authored the SRFI Table) on #scheme, who
> decided to scrape the org-mode document, since at the time it was the
> source of truth for the Chicken SRFI Support table wiki page, which at
> least as of a few days ago was the most up-to-date source of this
> information.
>
> But this org-mode document is neither a reliable nor authoritative
> source for this information, and it can and has gotten out of sync with
> what SRFIs chicken actually supports.
>
> The "Supported Standards" page[4], which is another source of Chicken
> SRFI support information is not complete either.
>
> There seems to be no one wiki page which is guaranteed to
> be either authoritative or complete which could be used by the SRFI
> Table project to find out which SRFIs Chicken supports.
>
> Issue:
>
> At erikn's request I've documented the issue with more detail on the
> project's repo:
>
>   https://github.com/schemedoc/srfi-metadata/issues/13
>
> Anyone interested in making sure the SRFI Table stays up-to-date with
> the SRFIs that Chicken supports is encouraged to read that issue and
> make suggestions.
>
>   --Sergey
>
> [1] - https://htmlpreview.github.io/?https://github.com/schemedoc/srfi-metadata/blob/master/table.html
>
> [2] - https://wiki.call-cc.org/SRFI-conformance
>
> [3] - https://wiki.call-cc.org/srfi-support
>
> [4] - https://wiki.call-cc.org/supported-standards

If you assume that the SRFIs supported by the CHICKEN core are static
and the only variable source of supported SRFIs is eggs, you can get a
list of the current SRFI eggs with something like

wget --user=anonymous \
     --password="" \
     -qO - \
     http://code.call-cc.org/svn/chicken-eggs/release/5/egg-locations |\
     awk '/^\(srfi-/ {print substr($1, 2)}'

This assumes that SRFI eggs are named according to the `srfi-' pattern,
which might not be always true, though (e.g., vector-lib).

All the best.
Mario
--
http://parenteses.org/mario

[noosphere]

On Wed 11 Nov 2020 05:29:22 PM +01, Mario Domenech Goulart wrote:

>
> If you assume that the SRFIs supported by the CHICKEN core are static
> and the only variable source of supported SRFIs is eggs, you can get a
> list of the current SRFI eggs with something like
>
> wget --user=anonymous \
>      --password="" \
>      -qO - \
>      http://code.call-cc.org/svn/chicken-eggs/release/5/egg-locations |\
>      awk '/^\(srfi-/ {print substr($1, 2)}'
>
> This assumes that SRFI eggs are named according to the `srfi-' pattern,
> which might not be always true, though (e.g., vector-lib).

Right.  vector-lib was one example of an egg that provided SRFI support
but was did not start with "srfi-".  The "box" egg was another.
So this method is not completely reliable, and while we've been good in
recent days about starting names of SRFI-supporting eggs with "srfi-"
can we maybe make it a policy?

That way the above code should be sufficient and reliable, at least for
SRFI support that's provided via eggs.

  --Sergey

[Lassi Kortela]

Another option is to add an S-expression like (provides-srfi 1 2 3) into
the .egg file of each egg that implements one or more SRFIs. This would
make the information independent of the package name, and the
`eggs-5-latest` Git repo already aggregates all eggs, so an indexer
could clone that repo and read all the egg files to arrive at the full
list of SRFIs. Can the existing tools handle a new form in those files?

This has the downside that all egg authors need to be contacted. Having
a policy of `srfi-NNN` package names sounds reasonable as well.

[Mario Domenech Goulart-4]

On Wed, 11 Nov 2020 10:38:39 -0800 <[hidden email]> wrote:

> On Wed 11 Nov 2020 05:29:22 PM +01, Mario Domenech Goulart wrote:
>>
>> If you assume that the SRFIs supported by the CHICKEN core are static
>> and the only variable source of supported SRFIs is eggs, you can get a
>> list of the current SRFI eggs with something like
>>
>> wget --user=anonymous \
>>      --password="" \
>>      -qO - \
>>      http://code.call-cc.org/svn/chicken-eggs/release/5/egg-locations |\
>>      awk '/^\(srfi-/ {print substr($1, 2)}'
>>
>> This assumes that SRFI eggs are named according to the `srfi-' pattern,
>> which might not be always true, though (e.g., vector-lib).
>
> Right.  vector-lib was one example of an egg that provided SRFI support
> but was did not start with "srfi-".  The "box" egg was another.
> So this method is not completely reliable, and while we've been good in
> recent days about starting names of SRFI-supporting eggs with "srfi-"
> can we maybe make it a policy?

As far as I remember, those are the only two exceptions in CHICKEN 5,
and they date back from the CHICKEN 2 days (vector-lib was available for
CHICKEN 1, even).  Do we actually have more exceptions in CHICKEN 5?

I think currently people tend to naturally name SRFI eggs after their
corresponding number.

> That way the above code should be sufficient and reliable, at least for
> SRFI support that's provided via eggs.

All the best.
Mario
--
http://parenteses.org/mario