Support flint 3.1 in sagelib

[antonio-rojas]

Drop uses of deprecated API

• fmpq_get_mpz_frac/fmpq_init_set_mpz_frac_readonly, replace by verbatim code from the removed functions
• arb_version was only used by the obsolete arb216 and arb218 doctest tags, remove it

[antonio-rojas]

I have a feeling this auto-generated bindings of the entire flint API are going to cause packagers many headaches

[kiwifb]

I am not in a great position to test this right now. But it does feel like your changes are backward compatible with flint 3.0 if you only remove deprecated stuff. Correct? Binding autogeneration is what cypari2 does. Maybe there should be a cyflint?

[antonio-rojas]

I am not in a great position to test this right now. But it does feel like your changes are backward compatible with flint 3.0 if you only remove deprecated stuff. Correct? Binding autogeneration is what cypari2 does. Maybe there should be a cyflint?

cypari generates bindings at build time from the installed version of pari. This, OTOH, is a static copy which is manually generated (IIUC) https://github.com/sagemath/sage/blob/develop/src/sage_setup/autogen/flint/README.md. Quite a different story.

Yes, this should be backwards compatible with flint 3.0. I haven't tested, but CI will tell.

[kiwifb]

Oh, I get it. It is really bothersome.

[grhkm21]

Yes that's correct. My PR #37458 improves the README slightly, but the bindings for FLINT are indeed generated manually.

[mkoeppe]

@antonio-rojas I'd suggest to clarify the scope of the PR (only sagelib) in the title of the PR; this can help avoid bizarre and intense complaints by other developers later.

[github-actions]

Documentation preview for this PR (built with commit 6e904cf; changes) is ready! 🎉

[mezzarobba]

cypari generates bindings at build time from the installed version of pari. This, OTOH, is a static copy which is manually generated (IIUC) https://github.com/sagemath/sage/blob/develop/src/sage_setup/autogen/flint/README.md. Quite a different story.

Can you explain what is bothering you? I view these scripts simply as tools to help Sage developers maintain the pxd files containing declarations of flint functions; there is no requirement that the pxd we ship be complete or correspond to any particular flint release or anything like that; and the output of the scripts is pretty similar to the bindings we used to maintain manually, only more consistent. So I don't really see what difference it makes if the bindings are (partially) auto-generated.

[mezzarobba]

lgtm!

[mezzarobba]

@vbraun This PR is not technically a blocker, but I think it would be nice if it could be part of sage-10.3.

[mkoeppe]

I think it would be nice if it could be part of sage-10.3.

@mezzarobba This would only help if we can sort out the trouble with Singular - see #37203

[antonio-rojas]

I think it would be nice if it could be part of sage-10.3.

@mezzarobba This would only help if we can sort out the trouble with Singular - see #37203

It would still be beneficial for distros

[antonio-rojas]

cypari generates bindings at build time from the installed version of pari. This, OTOH, is a static copy which is manually generated (IIUC) https://github.com/sagemath/sage/blob/develop/src/sage_setup/autogen/flint/README.md. Quite a different story.

Can you explain what is bothering you? I view these scripts simply as tools to help Sage developers maintain the pxd files containing declarations of flint functions; there is no requirement that the pxd we ship be complete or correspond to any particular flint release or anything like that; and the output of the scripts is pretty similar to the bindings we used to maintain manually, only more consistent. So I don't really see what difference it makes if the bindings are (partially) auto-generated.

OK, I was under the (wrong) impression that things would break if the pxd contains bindings for API that no longer exists, which would force distro patching for every API change in flint even if it wasn't directly used in sage. Still, header removals (such as mpf_mat.h and mpf_vec.h in 3.1) will require patching, even if nothing from those headers is used in sage. But I expect these to be less frequent than general API changes.

[mezzarobba]

OK, I was under the (wrong) impression that things would break if the pxd contains bindings for API that no longer exists, which would force distro patching for every API change in flint even if it wasn't directly used in sage. Still, header removals (such as mpf_mat.h and mpf_vec.h in 3.1) will require patching, even if nothing from those headers is used in sage. But I expect these to be less frequent than general API changes.

Yes, there's a tradeoff here: we are shipping bindings for things that are not used, but it is convenient to have them already available when you are writing new code using flint, be it in sagelib (and I hope sagelib will make use of more of flint in the future!) or in sage packages... That being said, I hoped that the flint developers had removed everything they wanted to remove with the 3.0 release, and that does not seem to be the case. We'll see how things develop with the next few releases!

[videlec]

A .pxd by itself is mostly harmless : these are just informations for the cython compiler. As long as you do not compile a cythonized file, API mismatches would remain unnoticed.

[tornaria]

Works for me.

Singular 4.3.2p10 works fine.

To build singular 4.3.2p10 with flint 3.1, I use Singular/Singular@b5605a7 + https://gitlab.archlinux.org/archlinux/packaging/packages/singular/-/blob/main/flint-3.1.patch

[tornaria]

@vbraun This PR is not technically a blocker, but I think it would be nice if it could be part of sage-10.3.

It's a blocker for sagelib.

[antonio-rojas]

To build singular 4.3.2p10 with flint 3.1, I use Singular/Singular@b5605a7 + https://gitlab.archlinux.org/archlinux/packaging/packages/singular/-/blob/main/flint-3.1.patch

This is upstreamed now Singular/Singular@772cf3b

[tornaria]

To build singular 4.3.2p10 with flint 3.1, I use Singular/Singular@b5605a7 + https://gitlab.archlinux.org/archlinux/packaging/packages/singular/-/blob/main/flint-3.1.patch

This is upstreamed now Singular/Singular@772cf3b

Thanks for the pointer. OTOH, singular 4.3.2p15 is not released in the same way as p10, and it breaks sagelib in other ways (I know you have a patch but that one is less clear to me so I'll stick to p10).

[mkoeppe]

I've also been tracking Singular spielwiese, and there's still a bunch of build problems - see Singular/Singular#1205

[dimpase]

all good with Flint 3.0.1 from the system