On Sun, Mar 3, 2019 at 11:52 AM Jeroen Demeyer wrote:
>
> On 2019-03-03 11:48, Vincent Delecroix wrote:
> > Is this supposed to crash Sage?
>
> OK, I missed that part. The fact that you run out of file descriptors is
> not a bug, but the fact that it crashes Sage is a bug.
I'm not sure I'd even c
On Sunday, March 3, 2019 at 1:09:45 PM UTC+1, Jeroen Demeyer wrote:
> What is it that you're *actually* trying to do?
>
Use the gp code by Denis Simon in
/src/ext/pari/simon
didnt know how to feed that to pari, so I used gp. And that is what I saw in
schemes/elliptic_curves/gp_simon.py:
On Sunday, March 3, 2019 at 12:50:42 PM UTC+1, Jeroen Demeyer wrote:
> But maybe it's not closed *immediately*. It would be interesting to do
> the same experiment with a time.sleep(0.1) or a gc.collect() in the loop.
>
I tried that
sage: for k in range(1):
: gp = Gp()
: g
On 2019-03-03 12:46, Simon Brandhorst wrote:
Shouldn't the gp session be closed afterwards? After all it is not
used/referenced anymore?
So that the file descriptor gets freed again?
If not what is the recommended way to start computations in gp
The recommended way is not to use the GP pexpect
On 2019-03-03 12:46, Simon Brandhorst wrote:
Shouldn't the gp session be closed afterwards? After all it is not
used/referenced anymore?
But maybe it's not closed *immediately*. It would be interesting to do
the same experiment with a time.sleep(0.1) or a gc.collect() in the loop.
--
You rec
Shouldn't the gp session be closed afterwards? After all it is not
used/referenced anymore?
So that the file descriptor gets freed again?
If not what is the recommended way to start computations in gp (or
gap/magma )?
Say in some method in some class? give it some global gp instance as a
pa
On 2019-03-03 11:48, Vincent Delecroix wrote:
Is this supposed to crash Sage?
OK, I missed that part. The fact that you run out of file descriptors is
not a bug, but the fact that it crashes Sage is a bug.
--
You received this message because you are subscribed to the Google Groups
"sage-de
Le 03/03/2019 à 11:46, Jeroen Demeyer a écrit :
On 2019-03-03 11:43, Vincent Delecroix wrote:
Could you open a trac ticket? This is definitely a bug
(most probably in `interfaces/expect.py`).
I wouldn't call it a bug. You're opening 1 independent GP sessions,
which each need a few file de
On 2019-03-03 11:43, Vincent Delecroix wrote:
Could you open a trac ticket? This is definitely a bug
(most probably in `interfaces/expect.py`).
I wouldn't call it a bug. You're opening 1 independent GP sessions,
which each need a few file descriptors. It's normal that you run out of
file
Could you open a trac ticket? This is definitely a bug
(most probably in `interfaces/expect.py`).
Le 03/03/2019 à 11:41, Simon Brandhorst a écrit :
Trying to provoke more errors:
sage: from sage.env import SAGE_EXTCODE
sage: for k in range(1):
: gp = Gp()
: gp.read(SAGE_EXTC
Trying to provoke more errors:
sage: from sage.env import SAGE_EXTCODE
sage: for k in range(1):
: gp = Gp()
: gp.read(SAGE_EXTCODE + "/pari/simon/qfsolve.gp")
: k
breaks at k = 1922 with
-
OSError
Could it be a failed attempt to recover from a PARI/GP stackoverflow?
Just guessing.
On Sun, Mar 3, 2019 at 9:21 AM Simon Brandhorst wrote:
>
> I am trying a medium scale computation. Unfortunately it breaks every time
> with error messages I do not know how to interpret.
> They may or may not b
I am trying a medium scale computation. Unfortunately it breaks every time
with error messages I do not know how to interpret.
They may or may not be bugs in sage. Here is a traceback
--
ValueError
13 matches
Mail list logo
