Hi,
Le 04/03/2015 19:54, Bill Allombert a écrit :
On Wed, Mar 04, 2015 at 10:47:15AM +0100, Julien Puydt wrote:
Hi,
Le 04/03/2015 00:53, Bill Allombert a écrit :
I expect they should do something like
if (setjmp(&iferr_env))
{
GEN E = pari_err_last();
char *s = GSTR(GENtoGENstr(E));
fprintf(stderr,s);
...
}
before the point they are recovering using cb_pari_err_recover() at this time.
I had a look at their code, and in fact, what they do is:
- detect there has been an error (cb_pari_err_handle is used here) ;
- if it's a normal error, raise a python exception ;
- if it's a stack overflow, double the stack ;
- in case of any error, apparently pari always tries to recover
Not recovering in PARI term means terminating the program.
(cb_pari_err_recover is used here) : if there is a python exception,
they decide it's a real error and don't recover -- if there isn't
(doubling the stack succeeded), they restart the computation.
I see there is also a cb_pari_err_pre_recover... could it be used
instead of cb_pari_err_handle, given their use-case?
No it will not work.
What they should do is to move their recover code inside some
if (setjmp(&iferr_env))
{
}
block that is put somewhere appropriate.
*They* won't do anything, but *I* am trying to wrap my head between what
they already have, and what they should have -- I must admit I'm quite
unfamiliar with setjmp/longjmp.
Let's see if I'm starting to get it ; in their code to setup error
handling, they should :
(1) have something like:
if (setjmp(&iferr_env)) {
GEN E = pari_err_last ();
/* the code of their cb_pari_err_handle implementation,
* whose argument is precisely a GEN, and E[1] has the error
* number, so it's possible to decide to raise a python exception
* or resize the stack */
pari_err(0, err); /* <- no infinite loop? */
}
(2) still set cb_pari_err_recover to the very same function.
My goal is to try to make a patch -- if sage devs accept it, they'll
stop forking pari. If they don't, we'll use it to package sagemath in
debian until you have released a pari package which makes it obsolete.
Snark on #debian-science
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
