#14894: Fix PARI error handling (needed for future upgrade to PARI 2.6)
--------------------------------------+------------------------------
Reporter: vbraun | Owner: jdemeyer
Type: defect | Status: needs_work
Priority: major | Milestone: sage-5.12
Component: packages: standard | Resolution:
Keywords: pari error signal | Merged in:
Authors: Peter Bruin | Reviewers: Jeroen Demeyer
Report Upstream: N/A | Work issues:
Branch: | Commit:
Dependencies: #12142, #14873 | Stopgaps:
--------------------------------------+------------------------------
Comment (by pbruin):
Replying to [comment:23 jdemeyer]:
> Replying to [comment:22 pbruin]:
> > - reminiscent of `sig_on()` and `sig_off()`
> In my opinion, not sufficiently reminiscent..., I still prefer
`pari_sig_on()` and `pari_sig_off()`.
But why? When I started looking at `gen.pyx`, the names `sig_on()` and
`sig_off()` really confused me, because they suggest that they are just
signal handling macros. It seems to me that in practice, PARI errors
(e.g. zero division) occur more often than signals, so the names should
not suggest otherwise. If you ask me, this problem is not fixed by
renaming them `pari_sig_on()` and `pari_sig_off()`.
> > I see that this would be desirable because it saves typing a few lines
each time. On the other hand, I think the above code is bad style because
it explicity begins a block, but implicity ends it.
> That might be true, but in this case I don't think it justifies the
overcomplication of two-liners like [...] to the five-liner [...]
I can't say I'm completely happy with the code increase, either, and by
now I'm really inclined to try one of two opposite strategies:
- either find out how (in)efficient context managers (the `with`
statement) are in Cython; I still think being able to say `with
pari_catch: code` (as in comment:15) would be ideal, and perhaps the
overhead is not so big compared to the overhead that we already have by
using Cython;
- or translate this part of `gen.pyx` from Cython to C, both for speed and
to be able to use a macro for signal and error handling. This macro, say
`pari_catch_wrap()`, should call `pari_catch_on()`, execute `code` (and
remember its return value), call `pari_catch_off()` and return the return
value of `code`, so one could type (in C)
{{{
return pari_catch_wrap(code);
}}}
> After looking at the PARI 2.6 sources, I think the best solution for
Sage would be to use the (admittedly undocumented) variable `iferr_env`
from PARI. Because the `pari_CATCH` stuff is re-doing a `setjmp()` call
which Sage's `sig_on()` already does. This is bad, for example for
performance reasons (I made a lot of effort in making `sig_on()` fast).
There is a trade-off between execution time and developer time here.
What you suggest seems to require a new set of macros, merging
`sig_on()/sig_off()` and PARI's error handling macros, that only do one
`sigsetjmp()` but then have to distinguish within the error-handling code
whether a signal or a PARI error occurred.
I would hope that `setjmp()` is very fast on most systems, so that it
doesn't really hurt to use it twice: once to set up signal handling and
once to set up PARI error handling. I would certainly be happy to pay
this price in order to cleanly separate between handling signals and
handling PARI errors.
--
Ticket URL: <http://trac.sagemath.org/ticket/14894#comment:27>
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.
For more options, visit https://groups.google.com/groups/opt_out.
