Scryer-prolog: Question about rug/num

[notoria]

Scryer-Prolog switched to rug in f3441503 and the parser too but the log doesn't say/explain why.

Why did Scryer-Prolog switch to rug? What were the issues with num?

[mthom]

rug uses the GMP library, which is very well regarded for the speed of its bignum arithmetic.

[notoria]

Yes, it is fast but it supports less platform, it isn't possible to compile easily to an Android (like cargo build --target=armv7-linux-androideabi) or to WASM/WASI like here.

After the change how fast did Scryer-Prolog get?

[mthom]

I'd be interested to see a benchmark. I doubt the performance differences between it and num will be noticeable unless the integers involved are very big indeed.

[dcnorris]

Apropos of @notoria's comment, I have just now failed to build on MacOS Catalina 10.15.7 due to crate 'gmp-mpfr-sys' failing its build with segfaulting tests.

If I cd into gmp-src/ and do {./configure; make; make check} per the INSTALL, I find tests "t-toom53" and "t-fib2m" both fail with segfaults.

I'm new to Rust (never heard of it before today) but am glad to follow up, share build output, etc. I assume this is an issue that must be resolved for this crate. However, is there any way to drop this dependency, and build a (mostly) functioning Scryer Prolog without GMP?

[notoria]

A way to build scryer-prolog without GMP is:

$ cargo build --no-default-features --features num

But it will fail.
For now it is required to have a working GMP to have scryer-prolog.

Another way around the issue could be to use the docker solution:

# docker run -it mjt128/scryer-prolog

[malbarbo]

I updated num-rug-dapter to fix the missing functions and created a PR to update scryewr-prolog: https://github.com/mthom/scryer-prolog/pull/706