TODOs before next release

[triska]

In the hope to encourage interest and contributions towards the next release of Scryer Prolog, I collect here issues that were either mentioned in discussions as prerequisites for merging rebis-dev, or should be addressed due to their seriousness or in order to make more extensive testing possible before the next release:

• failing tests with rebis-dev, already significantly improved thanks to @bakaq via https://github.com/mthom/scryer-prolog/pull/2945, and even further improved thanks to @Skgland in #2946.
• avoid performance overhead when only one thread is active: https://github.com/mthom/scryer-prolog/issues/2908#issuecomment-2826555227 for which a PR is pending review: https://github.com/mthom/scryer-prolog/pull/2967
• number_chars/2 regression in rebis-dev: https://github.com/mthom/scryer-prolog/issues/2986
• pio difference in rebis-dev: https://github.com/mthom/scryer-prolog/issues/2988
• assertz/1 does not work correctly (master and rebis-dev): https://github.com/mthom/scryer-prolog/issues/2668#issuecomment-2843664353
• unexpectedly increased memory consumption with tabling: #2947 (will be resolved when GC is implemented)
• there is another problem with tabling (master and rebis-dev). Due to a much simpler recent test case thanks to @haijinSk, solving it may now be in reach: https://github.com/mthom/scryer-prolog/issues/1526#issuecomment-2849397285
• I will batch-process meta_predicate/1 declarations in source files and remove the operator definition (#2822)

Does anyone have any other issues that should definitely be addressed before the next release? If so, please mention them here.

The good news is that overall, rebis-dev seems already now far superior to master. For instance, it handles \0\ bytes in strings correctly, it handles 1-char predicate names correctly, it processes files with DCGs much faster, and all that in addition to the highly desirable O(1) string reclamation on backtracking, and even inlined short atoms on the heap.

[bakaq]

Does anyone have any other issues that should definitely be addressed before the next release? If so, please mention them here.

I stress again that, as-is, next release (of the library) MUST be 0.10 and not 0.9.5 because the library crate had extensive major breaking changes (a lot of this for example) since 0.9.4 and Rust/Cargo uses a variation of semver pretty strictly in it's ecosystem to benefit from proper dependency resolution. If we do want to release the binary as 0.9.5 for some reason, then a hard requirement before release is separating the binary into a different package than the library so that they can be versioned independently.

[triska]

Why "MUST" it be 0.10? Can it be for example 0.95 ?

[bakaq]

It must be at least 0.10.0 because of semver. We could go to 0.10.4, 0.95.0, 1.0.0 or even 9001.0.0 directly and it would be fine version-wise, 0.10.0 is just the smallest version that would be allowed by semver and also the one that makes the most sense.

[UWN]

It must be at least 0.10.0 because of semver. We could go to 0.10.4, 0.95.0, 1.0.0 or even 9001.0.0 directly and it would be fine version-wise, 0.10.0 is just the smallest version that would be allowed by semver and also the one that makes the most sense.

The next version should be something with a lot of zeroes in it. Rebis-dev got completely off rail, ignoring all problems. It will take some time in main to get it back on track. [[outdated]]

[triska]

One additional point I will do after rebis-dev is merged: Provide the predicates from library(error) without Context argument, to encourage the use of newly available call_with_error_context/2 which can be used instead and is already very successfully applied as part of  #3009. DONE!

[triska]

Scryer is now in better shape than ever, with many previously long-standing issues resolved.

Is there anything else that is within reach for the next release and should be added? For instance, what about the ffi++ branch by you @Skgland so that we can run plwm with Scryer, do you think this is ready very soon, or is this something that is better handled after the release?

[Skgland]

Scryer is now in better shape than ever, with many previously long-standing issues resolved.

Is there anything else that is within reach for the next release and should be added? For instance, what about the ffi++ branch by you @Skgland so that we can run plwm with Scryer, do you think this is ready very soon, or is this something that is better handled after the release?

I think ffi++ is doable before the next release, I opened a draft PR #3063 to track things I still consider TODO

[triska]

It's tagged! Yippie, and thank you a lot!