Opened 8 years ago

Closed 7 years ago

#14894 closed defect (fixed)

Fix PARI error handling

Reported by: vbraun Owned by: jdemeyer
Priority: major Milestone: sage-6.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:

Status badges

Description (last modified by jdemeyer)

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)

trac_14894-pari_catch.patch (6.2 KB) - added by pbruin 8 years ago.
new Cython macros for PARI error handling
trac_14894-pari_catch_gen.patch (153.1 KB) - added by pbruin 8 years ago.
make gen.pyx use new PARI error handling macros
trac_14894-pari_catch_FiniteFieldElement_pari_ffelt.patch (14.2 KB) - added by pbruin 8 years ago.
make PARI finite field elements use new error handling macros
trac_14894-pari_catch_misc.patch (8.4 KB) - added by pbruin 8 years ago.
new PARI error handling for miscellaneous Cython code
trac_14894-pari_catch_delete_old.patch (5.5 KB) - added by pbruin 8 years ago.
delete old Cython macros for PARI error handling
trac_14894-pari_catch_simplify.patch (5.7 KB) - added by pbruin 8 years ago.
simplify macros, do pari_errno handling in gen.pyx:pari_handle_error
trac_14894-pari_catch-folded.patch (182.9 KB) - added by pbruin 8 years ago.
unified patch combining all the above patches

Download all attachments as: .zip

Change History (68)

comment:1 Changed 8 years ago by pbruin

  • Cc pbruin added; pbrun removed

comment:2 follow-up: Changed 8 years ago by vbraun

Ah sorry, its dutch, not french. Too many variations of my own surname ;-)

comment:3 in reply to: ↑ 2 Changed 8 years ago by pbruin

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 pbruin

  • Authors set to Peter Bruin
  • 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)

Changed 8 years ago by pbruin

new Cython macros for PARI error handling

Changed 8 years ago by pbruin

make gen.pyx use new PARI error handling macros

Changed 8 years ago by pbruin

make PARI finite field elements use new error handling macros

Changed 8 years ago by pbruin

new PARI error handling for miscellaneous Cython code

Changed 8 years ago by pbruin

delete old Cython macros for PARI error handling

comment:5 Changed 8 years ago by pbruin

  • Description modified (diff)
  • Status changed from new to needs_review

comment:6 Changed 8 years ago by pbruin

  • Description modified (diff)

comment:7 follow-up: Changed 8 years ago by vbraun

  • 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 pbruin

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 replace-regexp in Emacs, which I ought to list as a co-author 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 just catch_begin / catch_end / catch_reset since its usage should be pretty much only in sage/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 non-trivial 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 pbruin

  • 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 follow-up: Changed 8 years ago by pbruin

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 speed-critical. I am thinking of creating a patch implementing this (in a new ticket) sometime in the future.

comment:11 follow-up: Changed 8 years ago by jdemeyer

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 ; follow-up: Changed 8 years ago by jdemeyer

Replying to pbruin:

One other thing I experimented with is a decorator @pari_catch_function, which wraps the function in sage_pari_catch()...sage_pari_catch_end().

Since this is low-level C code, I cannot believe a decorator (which is on the level of Python) would work.

comment:13 follow-up: Changed 8 years ago by jdemeyer

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 pbruin

Replying to jdemeyer:

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().

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() and pari_sig_off() which would mirror ecl_sig_on() and ecl_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 ; follow-up: Changed 8 years ago by pbruin

Replying to jdemeyer:

Since this is low-level 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.

Last edited 8 years ago by pbruin (previous) (diff)

comment:16 in reply to: ↑ 13 ; follow-up: Changed 8 years ago by pbruin

Replying to jdemeyer:

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)

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 error-catching 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 the jmp_buf (stack environment for use with sigjmp()); 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 pbruin

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 Lisp-style 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 vbraun

I also don't like the unbalanced-bracket-hack. 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 jdemeyer

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 jdemeyer

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.

Changed 8 years ago by pbruin

simplify macros, do pari_errno handling in gen.pyx:pari_handle_error

comment:21 Changed 8 years ago by pbruin

In the previous version of trac_14894-pari_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 follow-up: Changed 8 years ago by pbruin

About the names for the macros: how about pari_catch_on() and pari_catch_off()?

Advantages:

  • not too long
  • reminiscent of sig_on() and sig_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 jdemeyer

Replying to pbruin:

  • reminiscent of sig_on() and sig_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 two-liners like

sig_on() 
return P.new_gen(gcos(x.g, pbw(precision))) 

to the five-liner

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 jdemeyer

For reviewing purposes, could you please fold all patches into one? Because some later patches rewrite stuff from older patches.

comment:25 follow-up: Changed 8 years ago by jdemeyer

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).

comment:26 Changed 8 years ago by jdemeyer

  • Reviewers set to Jeroen Demeyer
  • Status changed from needs_review to needs_work

comment:27 in reply to: ↑ 25 ; follow-up: Changed 8 years ago by pbruin

Replying to jdemeyer:

Replying to 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.

comment:28 in reply to: ↑ 27 ; follow-up: Changed 8 years ago by jdemeyer

Replying to pbruin:

  • 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 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 error-handling 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.

Changed 8 years ago by pbruin

unified patch combining all the above patches

comment:29 in reply to: ↑ 28 ; follow-up: Changed 8 years ago by pbruin

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 pari-dev mailing list: http://pari.math.u-bordeaux.fr/archives/pari-dev-0909/msg00007.html.

The reason is that in BSD, setjmp() saves the signal mask (which apparently is very expensive), while in System V-like 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 ; follow-up: Changed 8 years ago by jdemeyer

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 jdemeyer

  • Description modified (diff)

comment:32 in reply to: ↑ 30 ; follow-up: Changed 8 years ago by pbruin

Replying to jdemeyer:

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.

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 non-setjmp()-based approach is feasible, that would be great. It would probably still be quite non-trivial, though.

comment:33 in reply to: ↑ 32 Changed 8 years ago by jdemeyer

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 pbruin

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 non-zero, 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 non-zero 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 pbruin

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 follow-up: Changed 8 years ago by jdemeyer

In any case, is this urgent at all? I think it makes more sense to do this as part of the upgrade to PARI-2.6, because PARI-2.6 does change the error handling mechanism quite a bit.

comment:37 in reply to: ↑ 36 Changed 8 years ago by pbruin

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 PARI-2.6, because PARI-2.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 jdemeyer

Or option 3: patch PARI to hack the error handling functions.

comment:39 Changed 8 years ago by jdemeyer

Part of this should be done now for use in #14888: making the pari_sig_on() macros available, see #15124.

comment:40 follow-up: Changed 8 years ago by jdemeyer

I asked pari-dev about a callback function instead of longjmp() for PARI error handling (i.e. option 3 above).

comment:41 in reply to: ↑ 40 ; follow-up: Changed 8 years ago by pbruin

Replying to jdemeyer:

I asked pari-dev about a callback function instead of longjmp() 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 the longjmp() inside a common error-handling function for signals and PARI errors?

comment:42 in reply to: ↑ 41 ; follow-up: Changed 8 years ago by 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.

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 ; follow-up: Changed 8 years ago by pbruin

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 the setjmp() inside sig_on(). It would avoid an additional setjmp() call for PARI.

Good, that is what I suspected.

comment:44 in reply to: ↑ 43 ; follow-up: Changed 8 years ago by jdemeyer

Replying to pbruin:

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.

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 pbruin

Replying to jdemeyer:

Replying to pbruin:

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.

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 jdemeyer

  • Milestone changed from sage-5.13 to sage-pending
  • 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 pbruin

  • Status changed from needs_work to needs_info

Now that we have a better error-handling 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.u-bordeaux.fr/Events/PARI2014/), which suggests that a 2.7 release is in the pipeline.

comment:48 Changed 8 years ago by jdemeyer

I would say: let this ticket quietly sit here and let's look at it again when PARI-2.7 is released.

comment:49 Changed 7 years ago by pbruin

  • Authors Peter Bruin deleted
  • Milestone changed from sage-pending to sage-duplicate/invalid/wontfix
  • Status changed from needs_info to needs_review

In the light of #9640 and #15767, I think this ticket is no longer relevant and suggest to close it.

comment:50 Changed 7 years ago by jdemeyer

I think that this ticket is still relevant, since PARI-2.7.x has improved error handling mechanisms which we don't use.

comment:51 Changed 7 years ago by jdemeyer

I think we do need to reconsider the approach though. Personally I like to use Karim's proposal from http://pari.math.u-bordeaux.fr/archives/pari-dev-1309/msg00002.html, but that hasn't been implemented upstream yet.

comment:52 Changed 7 years ago by jdemeyer

  • Authors set to Peter Bruin
  • Milestone changed from sage-duplicate/invalid/wontfix to sage-6.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 jdemeyer

I'm willing to look into this ticket, but not right now.

comment:54 Changed 7 years ago by jdemeyer

  • Description modified (diff)
  • Milestone changed from sage-6.4 to sage-6.5

comment:55 Changed 7 years ago by jdemeyer

  • 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 7 years ago by git

  • Commit set to 0602271c328f6d0851af946671194786c8c78556

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

0602271Use cb_pari_err_handle() to handle PARI errors

comment:57 Changed 7 years ago by jdemeyer

  • Authors changed from Peter Bruin to Peter Bruin, Jeroen Demeyer
  • 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 7 years ago by pbruin

  • Authors changed from Peter Bruin, Jeroen Demeyer to Jeroen Demeyer
  • Reviewers set to Peter Bruin

comment:59 Changed 7 years ago by git

  • Commit changed from 0602271c328f6d0851af946671194786c8c78556 to 2d532fcb86ba0d993bc946adb3088c18bb20526d

Branch pushed to git repo; I updated commit sha1. New commits:

2d532fcMove PariError to handle_error.pyx; add sig_block() where needed

comment:60 Changed 7 years ago by pbruin

  • Status changed from needs_review to positive_review

comment:61 Changed 7 years ago by vbraun

  • Branch changed from u/jdemeyer/ticket/14894 to 2d532fcb86ba0d993bc946adb3088c18bb20526d
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.