Re: [sage-devel] Diverging PARI from upstream (#16997)
I waited a little bit before saying my bit. You are making my work as a person packaging sage for a distro difficult. Heck it was difficult when you started shipping pari 2.4 snapshots while you were release manager. The only thing that keeps me from quitting is pure dumb stubbornness. As for my opinion on the two patches that would cause divergence: * On infinities upstream has a point and it may be best left alone. * On the extra function, I am on your side. If you have a set of functions, you try to make it complete. Sooner or later someone will want the ones that are missing in your set however dumb, trivial or useless you think they are. I am sure a number of people could come with examples, I certainly have one. François On 27/09/2014, at 19:23, Jeroen Demeyer wrote: > On 2014-09-26 10:32, Jeroen Demeyer wrote: >> * qfparam_primpart.patch: fixes PARI bug #1611, upstream has not yet >> commented on this. > This has now been accepted upstream, so there is 1 less patch to worry about. > > -- > 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. This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. -- 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.
Re: [sage-devel] Diverging PARI from upstream (#16997)
On 2014-09-26 10:32, Jeroen Demeyer wrote: * qfparam_primpart.patch: fixes PARI bug #1611, upstream has not yet commented on this. This has now been accepted upstream, so there is 1 less patch to worry about. -- 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.
Re: [sage-devel] Diverging PARI from upstream (#16997)
Hi, Le 26/09/2014 17:04, Jeroen Demeyer a écrit : On 2014-09-26 16:42, Julien Puydt wrote: I don't think it's good to patch upstream and ship it as if it were upstream. What do you mean with "ship it as if it were upstream"? It's not like we hide the fact that PARI is patched. A good distribution doesn't patch further than what is needed to package. It would be better to add functionality to sage-over-pari instead of PARI-in-sage... Even better would be to have PARI upstream accept these patches, but we have no control over that. Upstream doesn't find the idea interesting, here on the ml people don't find the idea interesting... perhaps it's just not worth it? * 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? Depends on which side you're on... I would say PARI caused the problem since they have changed the documented behaviour of a function. Upstream's reaction: "Well, but who would use it ?" Well... the question is good, isn't it? Sage would certainly use it, but apparently that's not good enough. Who would use that seriously in sage? From what you have explained, I gather that you prefer forking a well-maintained upstream rather than modify a bunch of unmaintained scripts... don't patch needlessly, and if you think you need it, think better -- can't it go in sagelib instead? I disagree with this. I think we should put code in the most logical place where it belongs. Given that PARI already has an implementation for isprimepower(), it is easier and more natural to implement ispseudoprimepower() in PARI than in Sage. It doesn't seem that natural, and forking isn't easy... for two lines in sagelib! 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.
Re: [sage-devel] Diverging PARI from upstream (#16997)
On 2014-09-26 16:42, Julien Puydt wrote: I don't think it's good to patch upstream and ship it as if it were upstream. What do you mean with "ship it as if it were upstream"? It's not like we hide the fact that PARI is patched. It would be better to add functionality to sage-over-pari instead of PARI-in-sage... Even better would be to have PARI upstream accept these patches, but we have no control over that. * 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? Depends on which side you're on... I would say PARI caused the problem since they have changed the documented behaviour of a function. Upstream's reaction: "Well, but who would use it ?" Well... the question is good, isn't it? Sage would certainly use it, but apparently that's not good enough. don't patch needlessly, and if you think you need it, think better -- can't it go in sagelib instead? I disagree with this. I think we should put code in the most logical place where it belongs. Given that PARI already has an implementation for isprimepower(), it is easier and more natural to implement ispseudoprimepower() in PARI than in Sage. -- 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.
Re: [sage-devel] Diverging PARI from upstream (#16997)
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.
Re: [sage-devel] Diverging PARI from upstream (#16997)
On 2014-09-26 10:52, John Cremona wrote: I'm sure many Sage users do not know how much Pari is used for come very important functionality, such as most number field stuff. ...and a lot of elliptic curves stuff, elementary number theory of integers, some linear algebra, arbitrary-precision numerical evaluation of special functions, large finite fields... I would be very worried by an explicit fork. Of course, that is certainly not my intention. Maintaining a true PARI fork is not feasible. I also don't consider this an explicit fork, just a few patches on top of upstream. -- 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.
Re: [sage-devel] Diverging PARI from upstream (#16997)
Sage is very lucky indeed that Pari exists and is as good as it is for many things. Sage is also very lucky that you (Jeroen) exist since you have been very useful to *both* projects, working hard to improve both, and on particular reporting -- and fixing -- a lot of "upstream" bugs, i.e. bugs in Pari.The set of Pari developers is so small (essentially 2) that personalities matter. I know both Karim and Bill well, but just last week was so annoyed with Bill's reaction on pari-dev tha I did actually unsubscribe from that list. You have given us more examples if this stubborn-ness. Perhaps we need more Sage people active on pari-dev (I could re-join!) to up-vote such changes. I think Karim is much more aware of the value of Pari to the wider community than Bill, especially if due credit is given to Pari where it is used within Sage. (I'm sure many Sage users do not know how much Pari is used for come very important functionality, such as most number field stuff.) I would be very worried by an explicit fork. What about maintainability? John On 26 September 2014 09:32, Jeroen Demeyer wrote: > 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 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. > > Regards, > Jeroen. > > > 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." > > * 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 ?" > > 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. > > -- > 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. -- 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.
[sage-devel] Diverging PARI from upstream (#16997)
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 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. Regards, Jeroen. 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." * 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 ?" 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. -- 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.
