Add pari_PRIMES declaration

[antonio-rojas]

Needed to port sagemath to work with pari 2.17

[antonio-rojas]

Note that cypari doesn't build against 2.17.0 due to an upstream bug:
https://pari.math.u-bordeaux.fr/cgi-bin/bugreport.cgi?bug=2575

[dimpase]

This is an innocent change in header files only

[tornaria]

It seems the "right" (portable / upstream supported) way of iterating over primes involves functions forprime_init() and forprime_next().

In sagemath, something like:

--- a/src/sage/libs/pari/convert_sage.pyx
+++ b/src/sage/libs/pari/convert_sage.pyx
@@ -574,16 +574,14 @@ cpdef list pari_prime_range(long c_start, long c_stop, bint py_ints=False):
         [2, 3, 5, 7, 11, 13, 17]
     """
     cdef long p = 0
-    cdef byteptr pari_prime_ptr = diffptr
+    cdef forprime_t T
     res = []
-    while p < c_start:
-        NEXT_PRIME_VIADIFF(p, pari_prime_ptr)
-    while p < c_stop:
+    u_forprime_init(&T, max(c_start, 0), max(c_stop-1,0))
+    while p := u_forprime_next(&T):
         if py_ints:
             res.append(p)
         else:
             z = <Integer>PY_NEW(Integer)
             mpz_set_ui(z.value, p)
             res.append(z)
-        NEXT_PRIME_VIADIFF(p, pari_prime_ptr)
     return res

However, this fails to build because struct forprime_t is not correctly defined in cypari2. Something like:

--- a/cypari2/types.pxd
+++ b/cypari2/types.pxd
@@ -119,7 +119,7 @@ cdef extern from "pari/pari.h":
     struct nfmaxord_t
     struct forcomposite_t
     struct forpart_t
-    struct forprime_t
+    ctypedef struct forprime_t: pass
     struct forvec_t
     struct gp_context
     struct nfbasic_t

seems to be needed.

[dimpase]

+    ctypedef struct forprime_t: pass

I don't grok this ctypedef. I thought it's only ctypedef Foo Bar, to use Bar instead of Foo?

[culler]

You are confusing the C typedef statement with the Cython ctypedef statement.

The C statement "typedef foo bar" allows bar to be used as an alias for the type foo.

The purpose of the Cython ctypedef statement is to inform the Cython compiler about typedefs that appear in C header files included by the C code generated by the Cython compiler. The idea is to tell the Cython compiler all it needs to know about a C type and nothing more. If the C code generated by the Cython compiler will only refer to a forprime_t as a struct, meaning that it will never access any fields of that struct, then the minimal ctypedef command which you do not grok is sufficient. It informs Cython that a C struct named forprime_t exists. That is all it needs to know. It does not need to know the names of any fields in that struct.

[dimpase]

In my defence I can say that I can't find ctypedef in Cython docs proper - only in examples, without any : foobar part.

[culler]

The Cython documentation is not very helpful. Its intended audience consists of people who don't read documentation.

The colon is required for structs, but not for simple types like unsigned int.

There is no need to defend yourself; you are welcome.

[tornaria]

See:
http://docs.cython.org/en/latest/src/userguide/external_C_code.html#styles-of-struct-union-and-enum-declaration

It seems that just cdef struct Foo declares a struct that cannot be used except by pointer (however, this prevents creating an actualy object to take the address of).

An empty struct declaration is ok if we add : pass (these are really opaque structs, we don't need to know what's inside).

In summary, the whole block of struct foo declarations are not very useful. It seems there are two possible styles depending on how the type is defined in pari headers, e.g.:

    struct bb_group: pass
    [...]
    ctypedef struct forprime_t: pass
    [...]

In the first statement, I think the cdef is implicit, but I think it also won't work without the : pass. OTOH, I'm not sure bb_group will be useful at all without declaration of members, maybe we should take it easy and only do now the ones that are clear (and for which we can write simple self-contained tests that work).

I couldn't find a way to override this declaration in sagemath without changing cypari2, which would make handling the dependency easier. If anyone sees a way, it might be nice to get this into sagemath 10.5. If it needs an update to cypari2, then it's probably better to wait until 10.6 (but we should do a cypari2 release soon, is someone in charge?).

[dimpase]

we should do a cypari2 release soon, is someone in charge?

@videlec ?

[roed314]

Vincent is no longer acting as maintainer for cypari2 (see this thread on sage-devel). I appreciate the time he's taken recently to help figure out what steps might help with #107.

I'd be motivated to help resolve #107, but in practice I'm unlikely to have much time to devote to it in the next several months.

[dimpase]

I can help maintain pplpy and cypari2. Feel free to make me a maintainer/admin on these. And on cysignals.
(OK, this is done)

[dimpase]

@tornaria - I can now deal with merging PRs and make releases, please go ahead with your proposed changes.