Opened 8 years ago
Closed 6 years ago
#14894 closed defect (fixed)
Fix PARI error handling
Reported by:  vbraun  Owned by:  jdemeyer 

Priority:  major  Milestone:  sage6.5 
Component:  packages: standard  Keywords:  pari error signal 
Cc:  jdemeyer  Merged in:  
Authors:  Jeroen Demeyer  Reviewers:  Peter Bruin 
Report Upstream:  N/A  Work issues:  
Branch:  2d532fc (Commits, GitHub, GitLab)  Commit:  2d532fcb86ba0d993bc946adb3088c18bb20526d 
Dependencies:  #12142, #14873  Stopgaps: 
Description (last modified by )
Instead of catching whatever PARI writes to pariErr
, we should use a callback function cb_pari_err_handle
. That way, we don't need special tricks for warnings anymore.
Moreover, we also get access to the "error data" (a t_ERROR
object) which we store in the exception.
Attachments (7)
Change History (68)
comment:1 Changed 8 years ago by
 Cc pbruin added; pbrun removed
comment:2 followup: ↓ 3 Changed 8 years ago by
comment:3 in reply to: ↑ 2 Changed 8 years ago by
Replying to vbraun:
Ah sorry, its dutch, not french. Too many variations of my own surname ;)
Kein Problem! 8)
comment:4 Changed 8 years ago by
 Cc pbruin removed
 Dependencies set to #12142, #14873
 Description modified (diff)
 Keywords pari error signal added
 Summary changed from Update to Pari 2.6.0 (when its out) and fix error handling to Fix PARI error handling (needed for future upgrade to PARI 2.6)
comment:5 Changed 8 years ago by
 Description modified (diff)
 Status changed from new to needs_review
comment:6 Changed 8 years ago by
 Description modified (diff)
comment:7 followup: ↓ 8 Changed 8 years ago by
 Cc jdemeyer added
Looks fine to me. We lose some syntactic sugar but get closer to the upstream coding convention, so it should make our live easier in the long run. Maybe Jeroen has an opinion?
I would have preferred some shorter names especially since they'll be used very frequently in the Pari library interface. The file is part of the Sage library, so why prefix with sage_
?. Maybe just catch_begin
/ catch_end
/ catch_reset
since its usage should be pretty much only in sage/libs/pari
.
comment:8 in reply to: ↑ 7 Changed 8 years ago by
Replying to vbraun:
Looks fine to me. We lose some syntactic sugar but get closer to the upstream coding convention, so it should make our live easier in the long run.
The new macros do require more keystrokes  or things like replaceregexp
in Emacs, which I ought to list as a coauthor of these patches. 8) On the other hand, they make the code easier to understand in the sense that one doesn't have to remember or guess where the error catching block ends.
I would have preferred some shorter names especially since they'll be used very frequently in the Pari library interface. The file is part of the Sage library, so why prefix with
sage_
?. Maybe justcatch_begin
/catch_end
/catch_reset
since its usage should be pretty much only insage/libs/pari
.
In fact, I spent quite a bit of thought on the names, and altogether, I think that there are good reasons for the sage_pari_
prefix:
My first idea was pari_catch
/ pari_endcatch
/ pari_catch_reset
. Then I decided that this set of names looks better with catch_end
than with endcatch
.
The variable sage_pari_catcherr
in your patch for #14873 then gave me the idea of prefixing the names with sage_
. It is true that this makes them a bit long (which is why I did not change sage_pari_catch
to sage_pari_catch_begin
). But it is also true that they are nontrivial wrappers around the corresponding PARI macros that involve signal trapping, conversion of PARI errors to Python exceptions, and potentially retrying the same code several times until the stack is large enough. I thought this justified the prefix sage_
to make it clear that they are not the vanilla PARI macros but somewhat elaborate customised versions.
About keeping the pari
part of the name: I think it is important because these macros are used outside sage/libs/pari
, so the name should indicate that they have a more specialised purpose than the generic sig_on()
/ sig_off()
. Currently they are used in a few places for integers, real and complex numbers, and integer and rational matrices. The FiniteField_pari_ffelt
class of #12142 heavily depends on them, and there are many other data types of which fast PARI implementations could be made (e.g. polynomials, power series rings and elliptic curves over finite fields), which would undoubtedly also use these macros.
comment:9 Changed 8 years ago by
 Description modified (diff)
I'm attaching one more patch, which I hope will be the last one for this ticket. It makes the C macros as simple as possible and moves the handling of pari_errno
to a single Cython function pari_handle_error
.
comment:10 followup: ↓ 12 Changed 8 years ago by
One other thing I experimented with is a decorator @pari_catch_function
, which wraps the function in sage_pari_catch()...sage_pari_catch_end()
. It works nicely, but I'm not sure that it is useful for gen.pyx
, since it will probably slow things down. On the other hand, it might be useful later for new code that is less speedcritical. I am thinking of creating a patch implementing this (in a new ticket) sometime in the future.
comment:11 followup: ↓ 14 Changed 8 years ago by
One recomendation: could you use other names than sage_pari_catch
, something which clearly refers to sig_on()
, since sage_pari_catch()
really is an extension of sig_on()
.
What about pari_sig_on()
and pari_sig_off()
which would mirror ecl_sig_on()
and ecl_sig_off()
which we already have?
comment:12 in reply to: ↑ 10 ; followup: ↓ 15 Changed 8 years ago by
Replying to pbruin:
One other thing I experimented with is a decorator
@pari_catch_function
, which wraps the function insage_pari_catch()...sage_pari_catch_end()
.
Since this is lowlevel C code, I cannot believe a decorator (which is on the level of Python) would work.
comment:13 followup: ↓ 16 Changed 8 years ago by
Also, I really don't like that sage_pari_catch()
and sage_pari_catch_end()
contain complementaty braces. I would strongly recommend to try to keep the following working as before:
sage_pari_catch() return new_gen(something returning GEN)
comment:14 in reply to: ↑ 11 Changed 8 years ago by
Replying to jdemeyer:
One recomendation: could you use other names than
sage_pari_catch
, something which clearly refers tosig_on()
, sincesage_pari_catch()
really is an extension ofsig_on()
.
As I understand it, the two purposes of sage_pari_catch()
are equally important, namely
 catching signals
 catching PARI errors.
It would be nice to have a name that mirror this. Maybe the prefix sage_
is somewhat redundant, as Volker Braun suggested, and we could call them pari_catch_on()
and pari_catch_off()
?
What about
pari_sig_on()
andpari_sig_off()
which would mirrorecl_sig_on()
andecl_sig_off()
which we already have?
Do these have the same two purposes as above? In that case, I would find the names pari_sig_on()
and pari_sig_off()
acceptable for the sake of consistency, but in principle I dislike the fact that they don't hint at the fact that these macros catch PARI errors and not just signals.
comment:15 in reply to: ↑ 12 ; followup: ↓ 20 Changed 8 years ago by
Replying to jdemeyer:
Since this is lowlevel C code, I cannot believe a decorator (which is on the level of Python) would work.
Maybe I can convince you by giving the definition of the decorator:
def pari_catch_function(f): """ Decorator to wrap a function in sage_pari_catch() ... sage_pari_catch_end(). """ def g(*args): cdef object _x sage_pari_catch() _x = f(*args) sage_pari_catch_end() return _x return g
I put this in a Cython file and tested it. It works, but probably it is not very good for efficiency.
Something that I do not see how to do easily, on the other hand, is a context guard (context manager) for use with the with
statement, i.e.
with pari_catch: ...code...
giving you catching of PARI errors and signals within the block.
comment:16 in reply to: ↑ 13 ; followup: ↓ 19 Changed 8 years ago by
Replying to jdemeyer:
Also, I really don't like that
sage_pari_catch()
andsage_pari_catch_end()
contain complementaty braces. I would strongly recommend to try to keep the following working as before:sage_pari_catch() return new_gen(something returning GEN)
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. The fact that the macros contain complementary braces makes them less flexible, but make it clearer where the errorcatching block ends.
Actually, as far as I'm concerned it would be even nicer if we could have the with
syntax as in my previous comment. This would force us at the same time to avoid complementary braces, which can be a good thing or not (we seem to disagree on this). However, there are two real disadvantages to this approach:
 it won't translate into simple C code and will certainly be slower;
 we cannot use the macros that PARI provides, and instead hack something ourselves that uses
alloca()
,malloc()
or a global variable to allocate thejmp_buf
(stack environment for use withsigjmp()
); otherwise it will disappear from the scope. This is exactly the problem that this ticket tries to solve.
comment:17 Changed 8 years ago by
One last comment for now: when I was working on this ticket I realised that a language feature that would give a good solution for this problem would be Lispstyle macros (so one could pass a "quoted" piece of code to a macro that does catch_on()
, evaluates the code, and does catch_off()
). Unfortunately this is something that Python doesn't have; the closest thing is the decorator described above, but it only works for entire functions.
comment:18 Changed 8 years ago by
I also don't like the unbalancedbrackethack. But, since Pari sets up its error catching framework that way, we should go with it, ugly or not.
Then I agree with Peter that the name should be different form sig_on
/off
precisely because it has different semantics.
I don't really see the need for getting too fancy with context managers or decorators, the pari error try/catch should essentially only be used in sage.libs.pari
and nowhere else in the Sage tree. And that is precisely where you wouldn't want to take any performance hit for one of the more fancy solutions.
comment:19 in reply to: ↑ 16 Changed 8 years ago by
Replying to pbruin:
Actually, as far as I'm concerned it would be even nicer if we could have the
with
syntax as in my previous comment.
Sure, but that needs some Cython patches, so it's not possible now.
comment:20 in reply to: ↑ 15 Changed 8 years ago by
Replying to pbruin:
I put this in a Cython file and tested it. It works, but probably it is not very good for efficiency.
Since _x = f(*args)
is evaluated through Python (not C), it will badly break the Python interpreter if interrupted at the wrong time.
comment:21 Changed 8 years ago by
In the previous version of trac_14894pari_catch_simplify.patch I tried to move the except *
from sage_pari_catch()
to sage_pari_catch_end()
. This was fine for catching PARI errors, but turned out to break interrupt handling, so I reverted this change.
comment:22 followup: ↓ 23 Changed 8 years ago by
About the names for the macros: how about pari_catch_on()
and pari_catch_off()
?
Advantages:
 not too long
 reminiscent of
sig_on()
andsig_off()
 do not suggest that the sole purpose is handling signals (as opposed to PARI errors)
comment:23 in reply to: ↑ 22 Changed 8 years ago by
Replying to pbruin:
 reminiscent of
sig_on()
andsig_off()
In my opinion, not sufficiently reminiscent..., I still prefer 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 twoliners like
sig_on() return P.new_gen(gcos(x.g, pbw(precision)))
to the fiveliner
cdef gen result_gen sage_pari_catch() result_gen = P.new_gen(gcos(x.g, pbw(precision))) sage_pari_catch_end() return result_gen
comment:24 Changed 8 years ago by
For reviewing purposes, could you please fold all patches into one? Because some later patches rewrite stuff from older patches.
comment:25 followup: ↓ 27 Changed 8 years ago by
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 redoing 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).
comment:26 Changed 8 years ago by
 Reviewers set to Jeroen Demeyer
 Status changed from needs_review to needs_work
comment:27 in reply to: ↑ 25 ; followup: ↓ 28 Changed 8 years ago by
Replying to jdemeyer:
Replying to pbruin:
 reminiscent of
sig_on()
andsig_off()
In my opinion, not sufficiently reminiscent..., I still prefer
pari_sig_on()
andpari_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 twoliners like [...] to the fiveliner [...]
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 saywith 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, saypari_catch_wrap()
, should callpari_catch_on()
, executecode
(and remember its return value), callpari_catch_off()
and return the return value ofcode
, 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 thepari_CATCH
stuff is redoing asetjmp()
call which Sage'ssig_on()
already does. This is bad, for example for performance reasons (I made a lot of effort in makingsig_on()
fast).
There is a tradeoff 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 errorhandling 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.
comment:28 in reply to: ↑ 27 ; followup: ↓ 29 Changed 8 years ago by
Replying to pbruin:
 either find out how (in)efficient context managers (the
with
statement) are in Cython; I still think being able to saywith pari_catch: code
would be ideal
Of course this would be ideal. But as I said, this needs Cython patches. I recently looked into this for implementing sig_on()
and it currently cannot be done in Cython.
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 errorhandling code whether a signal or a PARI error occurred.
Exactly. I know it's far from trivial, otherwise I would have done it already in the past. But I can say that I thought a lot about signal/error handling.
I would hope that setjmp() is very fast on most systems
It's not. I remember it being particularly slow on BSD (and therefore OS X) systems.
comment:29 in reply to: ↑ 28 ; followup: ↓ 30 Changed 8 years ago by
Replying to jdemeyer:
Replying to pbruin:
I would hope that setjmp() is very fast on most systems
It's not. I remember it being particularly slow on BSD (and therefore OS X) systems.
I just found a discussion about this on the paridev mailing list: http://pari.math.ubordeaux.fr/archives/paridev0909/msg00007.html.
The reason is that in BSD, setjmp()
saves the signal mask (which apparently is very expensive), while in System Vlike systems it does not. BSD does have _setjmp()
and sigsetjmp(, 0)
, which are comparable to setjmp()
on other systems. According to the link above, the setjmp()
variant that does not touch the signal mask is 2.5 to 12 times as fast as the one that does.
Of course, for signal handling you are stuck with the slow version, but for other purposes one could use the fast version. In our situation the question is whether we do one slow system call, or the slow one for signal handling plus the fast one for handling PARI errors.
Finally, the discussion cited above mentions the idea of letting the user of the PARI library specify a function to call when an error occurs instead of the setjmp()/longjmp()
construction. This doesn't currently seem to be implemented, though.
comment:30 in reply to: ↑ 29 ; followup: ↓ 32 Changed 8 years ago by
Replying to pbruin:
Of course, for signal handling you are stuck with the slow version
False :) Sage's sig_on()
uses sigsetjmp(env,0)
. It manually resets the signal mask when actually handling an error.
Finally, the discussion cited above mentions the idea of letting the user of the PARI library specify a function to call when an error occurs instead of the
setjmp()/longjmp()
construction.
I think this would be very good for Sage. I personally wouldn't mind patching that in ourselves in the Sage version of PARI.
comment:31 Changed 8 years ago by
 Description modified (diff)
comment:32 in reply to: ↑ 30 ; followup: ↓ 33 Changed 8 years ago by
Replying to jdemeyer:
Replying to pbruin:
Of course, for signal handling you are stuck with the slow version
False :) Sage's
sig_on()
usessigsetjmp(env,0)
. It manually resets the signal mask when actually handling an error.
OK, I read the code too carelessly. But if you can simply use sigsetjmp(env, 0)
for signal handling, then surely you can use it for handling PARI errors as well, so the slowness of setjmp()
on BSD should be irrelevant. The try/catch macros provided by PARI do use a plain setjmp()
, but that should be easy to change.
Anyway, if a nonsetjmp()
based approach is feasible, that would be great. It would probably still be quite nontrivial, though.
comment:33 in reply to: ↑ 32 Changed 8 years ago by
Replying to pbruin:
But if you can simply use
sigsetjmp(env, 0)
for signal handling, then surely you can use it for handling PARI errors as well
Anyway, if a non
setjmp()
based approach is feasible, that would be great.
Both of these require patching the PARI sources, and then I prefer the second approach for simplicity.
comment:34 Changed 8 years ago by
Actually, in [PARI source]/language/init.c
(and in the header file paricom.h
) there is a declaration
int (*cb_pari_handle_exception)(long);
if this is nonzero, pari_err()
calls it (with an error code as argument) when no saved environment is present to do a longjmp()
to. I could imagine setting this to a Cython function that converts a PARI error into an appropriate Python exception, and raising that exception.
It appears that the function to which cb_pari_handle_exception
points should return nonzero if and only if the error was handled succesfully; if it was, pari_err()
simply returns. However, functions calling pari_err()
normally expect that function not to return, so as things stand now, a suitable setjmp()/longjmp()
would still seem to be necessary.
comment:35 Changed 8 years ago by
And just now I discovered that as long ago as #9640, you (Jeroen) were already saying that we should use cb_pari_handle_exception
to catch PARI errors...
comment:36 followup: ↓ 37 Changed 8 years ago by
In any case, is this urgent at all? I think it makes more sense to do this as part of the upgrade to PARI2.6, because PARI2.6 does change the error handling mechanism quite a bit.
comment:37 in reply to: ↑ 36 Changed 8 years ago by
Replying to jdemeyer:
In any case, is this urgent at all? I think it makes more sense to do this as part of the upgrade to PARI2.6, because PARI2.6 does change the error handling mechanism quite a bit.
The current implementation has its problems (see the ticket description), but I know of nothing that is broken in practice. Whether to do it now or during the upgrade depends on which solution is chosen.
 Option 1: use the try/catch macros provided by PARI. This we can do now, and it will make the upgrade easier, since similar macros are provided in 2.6 (albeit with slightly different names and a different implementation).
 Option 2: keep using undocumented PARI functions/variables. This can only be done at the same time as the upgrade, since the internals have changed a lot in 2.6.
Option 1 is what the current patch does, and I still prefer this option.
comment:38 Changed 8 years ago by
Or option 3: patch PARI to hack the error handling functions.
comment:39 Changed 8 years ago by
comment:40 followup: ↓ 41 Changed 8 years ago by
I asked paridev
about a callback function instead of longjmp()
for PARI error handling (i.e. option 3 above).
comment:41 in reply to: ↑ 40 ; followup: ↓ 42 Changed 8 years ago by
Replying to jdemeyer:
I asked
paridev
about a callback function instead oflongjmp()
for PARI error handling (i.e. option 3 above).
There is the callback function cb_pari_handle_exception
, but I don't quite see how to use this without any longjmp()
; see comment:34. Hence two questions:
 Would a new callback function really be needed (e.g. because it has to be called at a different moment than
cb_pari_handle_exception
)?  Does the option 3 that you have in mind somehow avoid
longjmp()
, or do you propose to do thelongjmp()
inside a common errorhandling function for signals and PARI errors?
comment:42 in reply to: ↑ 41 ; followup: ↓ 43 Changed 8 years ago by
Replying to pbruin:
There is the callback function
cb_pari_handle_exception
The problem with that callback is that it is called after printing the error message. For Sage, we don't want the error to be printed.
My approach would still use a longjmp()
to jump to the setjmp()
inside sig_on()
. It would avoid an additional setjmp()
call for PARI.
comment:43 in reply to: ↑ 42 ; followup: ↓ 44 Changed 8 years ago by
Replying to jdemeyer:
Replying to pbruin:
There is the callback function
cb_pari_handle_exception
The problem with that callback is that it is called after printing the error message. For Sage, we don't want the error to be printed.
Couldn't we prevent printing the error message by using a custom pariErr
like we already do for pariOut
? Besides not having to patch PARI to add another callback, this has the additional advantage that the error text can be stored for possible inspection.
My approach would still use a
longjmp()
to jump to thesetjmp()
insidesig_on()
. It would avoid an additionalsetjmp()
call for PARI.
Good, that is what I suspected.
comment:44 in reply to: ↑ 43 ; followup: ↓ 45 Changed 8 years ago by
Replying to pbruin:
Couldn't we prevent printing the error message by using a custom
pariErr
like we already do forpariOut
? Besides not having to patch PARI to add another callback, this has the additional advantage that the error text can be stored for possible inspection.
That was my original idea but there are some complications, for example the printing of an extra newline in err_init()
and the use of ANSI escape sequences for colours.
comment:45 in reply to: ↑ 44 Changed 8 years ago by
Replying to jdemeyer:
Replying to pbruin:
Couldn't we prevent printing the error message by using a custom
pariErr
like we already do forpariOut
? Besides not having to patch PARI to add another callback, this has the additional advantage that the error text can be stored for possible inspection.That was my original idea but there are some complications, for example the printing of an extra newline in
err_init()
and the use of ANSI escape sequences for colours.
I see. But wouldn't it be a more satisfactory solution to have PARI do those things only if the output is connected to a terminal (using isatty
)? This would still require a patch, of course.
comment:46 Changed 8 years ago by
 Milestone changed from sage5.13 to sagepending
 Summary changed from Fix PARI error handling (needed for future upgrade to PARI 2.6) to Fix PARI error handling for PARI 2.6
comment:47 Changed 8 years ago by
 Status changed from needs_work to needs_info
Now that we have a better errorhandling mechanism (#9640), is there anything specific that needs to be done in this area when upgrading PARI? Should this rather become a general PARI upgrade ticket, or be closed as a duplicate of #9640?
Also, do we want to upgrade to PARI 2.6.x or wait for 2.7.x (even minor version = development, odd = stable)? In January there will be an "Atelier PARI/GP" where planning for PARI 2.9 is on the agenda (http://pari.math.ubordeaux.fr/Events/PARI2014/), which suggests that a 2.7 release is in the pipeline.
comment:48 Changed 8 years ago by
I would say: let this ticket quietly sit here and let's look at it again when PARI2.7 is released.
comment:49 Changed 7 years ago by
 Milestone changed from sagepending to sageduplicate/invalid/wontfix
 Status changed from needs_info to needs_review
comment:50 Changed 7 years ago by
I think that this ticket is still relevant, since PARI2.7.x has improved error handling mechanisms which we don't use.
comment:51 Changed 7 years ago by
I think we do need to reconsider the approach though. Personally I like to use Karim's proposal from http://pari.math.ubordeaux.fr/archives/paridev1309/msg00002.html, but that hasn't been implemented upstream yet.
comment:52 Changed 7 years ago by
 Milestone changed from sageduplicate/invalid/wontfix to sage6.4
 Status changed from needs_review to needs_info
 Summary changed from Fix PARI error handling for PARI 2.6 to Fix PARI error handling for PARI 2.7
comment:53 Changed 7 years ago by
I'm willing to look into this ticket, but not right now.
comment:54 Changed 6 years ago by
 Description modified (diff)
 Milestone changed from sage6.4 to sage6.5
comment:55 Changed 6 years ago by
 Branch set to u/jdemeyer/ticket/14894
 Created changed from 07/15/13 14:21:31 to 07/15/13 14:21:31
 Modified changed from 01/13/15 16:06:40 to 01/13/15 16:06:40
comment:56 Changed 6 years ago by
 Commit set to 0602271c328f6d0851af946671194786c8c78556
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
0602271  Use cb_pari_err_handle() to handle PARI errors

comment:57 Changed 6 years ago by
 Description modified (diff)
 Reviewers Jeroen Demeyer deleted
 Status changed from needs_info to needs_review
 Summary changed from Fix PARI error handling for PARI 2.7 to Fix PARI error handling
comment:58 Changed 6 years ago by
 Reviewers set to Peter Bruin
comment:59 Changed 6 years ago by
 Commit changed from 0602271c328f6d0851af946671194786c8c78556 to 2d532fcb86ba0d993bc946adb3088c18bb20526d
Branch pushed to git repo; I updated commit sha1. New commits:
2d532fc  Move PariError to handle_error.pyx; add sig_block() where needed

comment:60 Changed 6 years ago by
 Status changed from needs_review to positive_review
comment:61 Changed 6 years ago by
 Branch changed from u/jdemeyer/ticket/14894 to 2d532fcb86ba0d993bc946adb3088c18bb20526d
 Resolution set to fixed
 Status changed from positive_review to closed
Ah sorry, its dutch, not french. Too many variations of my own surname ;)