Hi,
Le 26/09/2014 10:32, Jeroen Demeyer a écrit :
Hello sage-devel,
The upstream situation with PARI has always been somewhat difficult. The
don't easily accept patches written by people which are not in their
inner circle. That, plus the importance of PARI inside Sage, is probably
also one of the reasons that PARI in Sage has so many patches.
I don't think it's good to patch upstream and ship it as if it were
upstream.
I have been working on the upgrade to the PARI git master (#16997),
which is in theory ready for review. The main new feature is an
implementation of Kedlaya for (hyper)elliptic curve point counting.
In that ticket, I would like to add two patches to PARI adding new
functionality, which unfortunately upstream refuses. Personally, I think
we should add these two patches to PARI-in-Sage anyway, regardless of
what upstream thinks. This will create a small "fork" between upstream
PARI and PARI-in-Sage. Hopefully, over time upstream will change their
mind and accept those patches after all.
If somebody has advice about how to deal with this situation or has
reasons why adding functionality to the PARI-in-Sage is absolutely not
acceptable, I would love to hear.
It would be better to add functionality to sage-over-pari instead of
PARI-in-sage... same point as above : don't lie on what you ship!
Details about the 2 patches:
* infinity.patch: PARI has a new infinity type but in upstream's
version, this type is almost useless. My patch allows basic arithmetic
(like 2*oo gives oo), which is needed to not break Denis Simon's scripts.
Rejected by upstream because "Purposefully, we restricted the semantic
attached to oo. Most of the time such operations are the symptom of a bug."
Is the problem really on PARI's side or on the scripts' side?
* ispseudoprimepower.patch: add a new function ispseudoprimepower()
which is like isprimepower() but without a primality proof. This could
be used in Sage for GF(p^n, proof=False).
Upstream's reaction: "Well, but who would use it ?"
Well... the question is good, isn't it?
In #16997, I am also adding other patches:
* qfparam_primpart.patch: fixes PARI bug #1611, upstream has not yet
commented on this.
...
* public_memory_functions.patch: make some private functions public. I
consider this a transitional patch to keep using Sage's memory handling
code for PARI. Upstream has changed a lot the way they deal with the
PARI stack. For the moment, we don't use these functions, but in some
future ticket we can have a look at it. Because of the transitional
nature, not submitted to upstream.
Beware of transitional things which end up staying...
There are basically two points I want to make:
- if sage ships "PARI 3.14159", then anything which uses sage's PARI
should also work with the upstream version ;
- if sage ships a forked PARI for some time and has code which depends
more and more on the different features, then it will make upgrading to
a newer upstream more painful.
Both points to: don't patch needlessly, and if you think you need it,
think better -- can't it go in sagelib instead?
Snark on #sagemath
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
