how to obtain s7.c?

[umlaeute]

this is merely a question (with my Debian maintainer's hat on; i'd like to get s4pd into Debian)
the s7 implementation consists of about 100000 LOC, crammed into two source files.
afaict, the files found here are a copy of another s7 implementation (probably from snd).

the questions are all related and in now particular order:

• are there s4pd-specific modifications to s7?
• how could I (as opposed to you) update to the latest and greatest upstream s7-implementation (assuming that it is ABI-compatible)
• is the interpreter code hand-written or generated? (y'know: 100000 LOC in a single file look a bit...suspicious)
  • if the latter, how? (would it make more sense to include the original sources in the repository and generate the C-code on-the-fly (possibly only on-demand?)

[lassik]

@umlaeute There is now https://salsa.debian.org/scheme-team. Would you be willing to package s7 and s4pd under this team?

The s7 upstream repo is here: https://cm-gitlab.stanford.edu/bil/s7

Iain knows better about the rest.

[umlaeute]

@lassik i typically use the multimedia-team to package Pd stuff. snd is also packaged there - so s4pd would find a quite natural home there.

i'm not really a bearded schemer (well, i'm bearded, but not lisping) so i don't know how well i would fit into the scheme-team 😋 - apart from that i'm of course happy to join whatever team (and it might be nice to have a single s7 package that other packages could use; i don't know how feasible this actually is)

[lassik]

If you want to package s4pd in multimedia-team, sounds like it makes a lot of sense.

I've been meaning to package s7 in scheme-team. I can do it sooner if you need the s7 package.

s4pd would be an excellent test case that it's working properly. Assuming s4pd can use the upstream version of s7 as-is. s7's author is very active, and quite amenable to making useful changes, so ideally we could upstream any new features that s4pd needs, but Iain is of course the ultimate judge on that.

[umlaeute]

I've been meaning to package s7 in scheme-team. I can do it sooner if you need the s7 package.

that sounds like a good plan.

i'm currently in no hurry about the packaging timeline.

[lassik]

Great. Feel free to email me (and/or the scheme-team mailing list) at any time if something relevant comes up.

The snd package currently contains an embedded copy of s7.c. As far as I know, the upstream version really is edited as one big .c file, and the file is not an amalgamation like sqlite3.c.

[iainctduncan]

My intention is to make sure I can always run Bill's latest s7, but in this rough first cut, I'm not doing so. I think I should probably plan on updating s7 with every actual release until I have a regression suite that I can run on all platforms easily. Does that sound reasonable? I'll make a ticket to myself to update to latest s7 prior to make a real 0.1 release of this.

There are no modifications to s7 and I'm hoping to keep it that way. So far I've been able to just add to it on a scheme level (which is what the s74.scm file is)

Putting in a new s7 should be as simple as replacing s7.c and s7.h, and rebuilding. Bill maintains it as those two files and typically puts out new versions with his updates of snd.

I agree with packaging with whatever Pd does, so multi-media makes sense to me.

thanks fellows!

[lassik]

Yes, sounds reasonable!

s74 is a nice pun :)

[lassik]

Has s7 settled on a version numbering scheme yet? Something like YYYYMM or YYYYMMDD date, or the standard major.minor.patch version number? Bill's been using things like DD-Mon-YY in the past which don't sort easily.

[schottstaedt]

I tried the all-numbers dates, but kept inadvertently switching between month-day and day-month. The s7 version number changes when there's some API change, or some non-backwards-compatible scheme-level change (which almost never happens). I stopped making the monthly s7 tarball because it was an administrative burden and as far as I could see no-one was using it. I would just use whatever the current cm-gitlab version is, or the ccrma-ftp tarball. (Right at the moment, due to ccrma's upgrade to fedora 34, I can't update the gitlab s7 code).

[iainctduncan]

Thanks Bill, I think I'll just resync on every real release then and/or significant change to s7. Once I've figured out Pd packaging I'll do a proper (non-rc) release and update to latest s7.