Embedded Scryer Prolog Update and Tolton Talk follow up

[jjtolton]

Hello everyone!

1. Sorry for delay on getting the talk notes out for the talk on Embedded Scryer Prolog Powering Video Game AI, they are nearly finished.
2. 8b307a1c515b9f3489e9a581aff8fb77e8f63e76 is currently usable if you want to test embedded functionality from a shared library in a host language.
3. @bakaq , @Skgland and I need to get on a call figure out what needs to be done to finish up ISSUE-2464: exposing scryer prolog functionality in libscryer_prolog.so for client library consumption #2465 so that it can be merged into main.
4. I will be writing a full guide on using 8b307a1c515b9f3489e9a581aff8fb77e8f63e76 for embedding Scryer Prolog into host languages soon.

[Skgland]

Regarding 3. I was under the assumption that everyone was waiting on the looming
Rebis-dev/Rebis-next merge to not cause further divergence/conflict with master.

[Skgland]

Maybe @mthom or @triska have an updated on that?

[jjtolton]

Great question. My understanding is that work on that probably won't resume until February/March next year, so it probably depends on how much effort it would be for us to finish what we have first. I think @mthom and @triska are expecting us to advise them on the direction of the embedded pathway.

Aside from rebis, I know @bakaq has some solid points about semver and packaging of the rust library portion of the PR. We also had some outstanding questions regarding datatypes, etc. We don't necessarily need to wait on rebis to finish up that portion of the discussion.

Although mostly at this point it's been so long I can't actually remember what the state of everything is :)

[bakaq]

I think the embedding effort is almost completely orthogonal to the improvements in rebis-dev (or even #2424), so I'm not very concerned about conflicts. I am, however, very concerned about semver, but maybe I'm exaggerating a bit. The binary not following semver is completely fine, but the library is very problematic because the entire Rust ecosystem expects it¹. Since #2475 was merged and it's clearly a breaking change, the next library version should clearly be at least 0.10.0². It has been a long time since 0.9.4, but I believe we should use this opportunity to make more breaking changes (like #2523 and #2582).

I think the work on the embedding API is currently stagnated on #2582³. Nobody commented on it, so I assume the interface is going in the right direction. I'll return to work on it soon.

Footnotes

1. Also, relevant blogpost. ↩

2. For example, if we released current master as 0.9.5, a simple cargo update could break the entire build for the guys at @coasys. ↩

3. It's not exactly a requirement for ISSUE-2464: Make scryer prolog usable as a shared library for other programs #2464 and related, but it would make work on the Rust API (Tracking issue: Rust library interface overhaul #2490) be independent of the work on the C API because it would eliminate constant conflicts in trying to improve both at the same time. ↩

[jjtolton]

I think the work on the embedding API is currently stagnated on #25823. Nobody commented on it, so I assume the interface is going in the right direction. I'll return to work on it soon.

Based on my conversations at the meetup, the three of us are really "leading the charge" 🏇 🏇 🏇 on this, so there's no one to wait for except for us.

My understanding of the order of operations:

1. We need to satisfy @bakaq 's excellent observations for semver, the interface, and the datatypes
2. We need to satisfy @Skgland 's tactical and quality observations and additional observations about the datatypes and interface
3. I need to update the examples and the API to support points 1 and 2

As an additional point, jjtolton@8b307a1 is "good enough" for the WASM API.

It would be great to start building out in that direction, I'm just worried about the amount of rework that would have to be done in response to changes for 1/2.