Make this thing actually useful

[cspiegel]

Gargoyle includes a bunch of Glk-enabled interpreters which were extracted to make this repository. It's meant so that other Glk implementations can have a group of interpreters like Gargoyle. However, this has basically stagnated for several years. If it is in fact useful, it should have some sort of coherence and goal instead of being, generally, an old clone of part of Gargoyle's repository.

I'm prompted by the following: https://intfiction.org/t/lectrote-1-3-8/47931/15. The TADS interpreter uses a Gargoyle-specific call, meaning it won't be useful on any other Glk implementations. Since this came from Gargoyle, it "knows" that function call exists, but it's hidden away with #ifdef meaning there will be silent failure on other Glk platforms. There are probably other similar issues in it and other interpreters.

Something that makes this difficult is the source of the interpreters. They come from various places and in various states of maintenance/Glk-ness:

1. Unmaintained with no official Glk support (e.g. advsys)
2. Unmaintained but with Glk support (e.g. jacl)
3. Maintained but no Glk (e.g. TADS3)
4. Maintained with Glk but no Gargoyle (e.g. Glulxe)
5. Maintained with Glk and Gargoyle (e.g. Bocfel)

There's also the wrinkle that Gargoyle has some bug fixes added to some of the unmaintained interpreters.

I think in all cases regardless of state of maintenance, there needs to be a Git setup where there's an upstream branch and a “port” branch, so it's trivial to track the changes that have been made for Glk support. Any new releases go into upstream and are merged into the port branch. That'd entail separate repositories for each interpreter however, and I don't know if going with submodules would be an ideal approach. In fact I don't really have a preference on how this is accomplished, but after dealing with upgrades in Gargoyle, I can attest that it's a pain to keep track of all changes without actual history documenting those changes. If anybody happens to have extensive experience with this sort of Git management, by all means, please chime in.

The itemized list above also has to be taken into account. For 1, maintenance kind of has to be taken over by this project. If this is the central location for Glk-enabled ports, then it's necessary to provide complete interpreters with known bugs fixed. That shouldn't be a huge deal.

For 2, adding Gargoyle support in the port branch is necessary, as would be bug fixes that won't be coming from upstream.

For 3, both Glk and Gargoyle support need to be added in the port branch.

For 4, Gargoyle support needs to be added in the port branch.

For 5, ideally nothing needs to happen in the port branch.

Gargoyle support is crucial because I'd really like to be able to move interpreter maintenance from Gargoyle to here; but at the same time it's important to completely support non-Gargoyle Glk implementations. A starting point for managing this is https://curiousdannii.github.io/if/gargoyle.html, which documents Gargoyle extensions and helps to standardize them, such that individual Gargoyle extensions can be added by other Glk implementations and tested for.

[cibersheep]

This repo has been essential for Gelek Vanilla so I thank you all your work.

We could add to the list:

• Maintained but no Glk: Adrift 5

I didn't know about the TADS bug. Thanks for the headsup

[curiousdannii]

From my perspective, I intend to switch to using the garglk repository. The only big advantage this repo gives is the CMake files, which I'm not using. If you ever finished switching garglk over to using CMake there'd be little reason for this repo to exist.

The other alternative I think could work would be to remove all the terps from garglk, and include this repo as a submodule there. It would be more work, and I'm not sure if it would really offer that much advantage.

For the terps which already have upstream git repositories, switching them to using submodules would probably be a good idea. That's at least Glulxe, Git, Hugo, and Alan 3. Frotz has a Git repo but the Glk port isn't part of it. And I think TADS is basically unmaintained now, I don't think there's been an update since 2016.

@cibersheep Turns out you did know about the TADS bug, you reported it as #4!

[cibersheep]

Following up the conversation in #6 @cspiegel I have added the magnetic terp from upstream to the upstream branch: https://github.com/cspiegel/interpreters/pull/2 Now, should I add the copy in this repo to interpreters/main? And push fro upstream to main to see than changes?

Or have you thought another way? I'm not so sure if I'm in the right path, that's why I'm asking

[cspiegel]

@cibersheep To be in line with what I've been doing, we'll get your changes into my upstream branch. Then you can merge (non fast-forward) upstream into your local master, add any patches (for Gargoyle and/or build fixes) in a new commit on top of that, commit, then create a pull request from your master to mine.

Boiled down, the steps you'd do in your own repository would go something like this:

git checkout upstream
git add new_interpreter
git commit
git checkout master
git merge upstream --no-ff
[apply any patches]
git add [changed files]
git commit

So you have the record of the upstream additions in upstream, the record of the merge of upstream (I think having --no-ff is useful so the history of these merges is clear), and then the record of which patches were needed on top of the upstream branch.

[cibersheep]

Ok, first attempt pushed.