#14346: The pari spkg is patching upstream too heavily
--------------------------------------+-------------------------------------
Reporter: Snark | Owner: tbd
Type: enhancement | Status: new
Priority: major | Milestone: sage-wishlist
Component: packages: standard | Resolution:
Keywords: | Work issues:
Report Upstream: N/A | Reviewers:
Authors: | Merged in:
Dependencies: | Stopgaps:
--------------------------------------+-------------------------------------
Comment (by jpflori):
Replying to [comment:17 fbissey]:
> So I did a bit more digging because it is a case of show me the code, I
will say that after looking at it carefully I have reached a pragmatic
view on this and I don't actually mind the change in question. If Julien
is worried about some other code he can put it on display. So in the
polred patch
> {{{
> diff -ruN src/src/headers/paridecl.h b/src/headers/paridecl.h
> --- src/src/headers/paridecl.h 2012-09-25 23:10:47.000000000
+0200
> +++ b/src/headers/paridecl.h 2013-01-31 14:49:05.557525771 +0100
> @@ -889,6 +889,7 @@
> GEN polredabs0(GEN x, long flag);
> GEN polredabs2(GEN x);
> GEN polredabsall(GEN x, long flun);
> +GEN polredbest(GEN x, long flag);
> GEN smallpolred(GEN x);
> GEN smallpolred2(GEN x);
> GEN tschirnhaus(GEN x);
> }}}
> That's technically a change in API you are exposing more functions than
in the original. That kind of change is unlikely to break anything. All
the rest of the code apart from the new function is private and shouldn't
be called directly, so _it_ doesn't matter.
> A more disturbing change would have been changing the way a public
function is called. If someone has been using a private function in their
code and it breaks, honestly they get what they deserve.
>
> I haven't looked upstream, Julien may be worried that this extra
function is not upstream or will be upstream under another name or call
structure.
I just checked and in PARI's git at least, it's just the same:
* http://pari.math.u-bordeaux.fr/cgi-
bin/gitweb.cgi?p=pari.git;a=blob;f=src/headers/paridecl.h;h=01e6378eac8e329e9da34ee414f2b2f19f1770f8;hb=HEAD#l1263
but I cannot tell you what will be in PARI 2.6.
>It is the only thing that I can think could be extracted and put
separately inside the sage library. And it technically could be done. BUT
I haven't digged the code deep to see if it was possible without calling
private functions from pari. I think I said something before about calling
private functions...
>
> There used to be some very invasive change in pari 2.3.xx where the sage
spkg added some error handling mechanism. I cannot see it anymore. In fact
looking at the patchset more closely than I did for some time, it is much
cleaner than it used to be.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14346#comment:29>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
