Would it be possible to generate all of the plots in the reference manual
in parallel? For example, the plots in
local/share/doc/sage/inventory/en/reference/plotting/sage/graphs seem to be
generated serially, and this is a bottleneck in building the reference
manual. Maybe instead of generating
Ok. Well it is finding openblas
customize UnixCCompiler
FOUND:
libraries = ['openblas', 'blas']
library_dirs = ['/usr/local/src/Misc/sage-8.6/local/lib', '/usr/lib64']
language = c
define_macros = [('HAVE_CBLAS', None)]
include_dirs = ['/usr/local/include', '/usr/include',
'
Numpy log and sagelib log were attached to original note.
On Sun, Mar 3, 2019 at 15:32 François Bissey wrote:
> I need more info for a diagnostic. Logs and more logs.
>
> > On 4/03/2019, at 10:09, Ike Stoddard wrote:
> >
> > Relevantly, numpy build process does not find my ATLAS. It seems to
>
I need more info for a diagnostic. Logs and more logs.
> On 4/03/2019, at 10:09, Ike Stoddard wrote:
>
> Relevantly, numpy build process does not find my ATLAS. It seems to check
> ATLAS instead of SAGE_ATLAS_LIB.
> Shell coding error? Or is ATLAS supposed to be set to SAGE_ATLAS_LIB at some
Relevantly, numpy build process does not find my ATLAS. It seems to check
ATLAS instead of SAGE_ATLAS_LIB.
Shell coding error? Or is ATLAS supposed to be set to SAGE_ATLAS_LIB at
some point?
On Sunday, March 3, 2019 at 2:17:24 AM UTC-6, François Bissey wrote:
>
> You suffer from a classic case
On Sun, 3 Mar 2019, Frédéric Chapoton wrote:
> In sage 8.7.b6 built with python3, there are now 464 failing doctests, in a
> total of 137 files.
You forgot to say that this is great progress -- and we should thank you
for a big part of this!
It also seems that in py3 the testing framework does
Hello everybody.
In sage 8.7.b6 built with python3, there are now 464 failing doctests, in a
total of 137 files. Among these files, 55 have just one failing doctest.
The worst file is now 'src/sage/matroids/matroid.pyx' with 22 doctests
failed.
To make further progress, one thing that we must
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
Ah I see and to answer my own question using grep:
from sage.interfaces.gp import gp
is probably what I should do.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
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
Can you try *directly* at k=1842 (no loop). As Jeroen pointed
out, each gp session opens a file descriptor.
Le 03/03/2019 à 11:45, Simon Brandhorst a écrit :
I can consistently reproduce that error. Tried again and crashed at k = 1888
and
k = 1871
and
k = 1842
maybe I am hitting some preset lim
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
I can consistently reproduce that error. Tried again and crashed at k = 1888
and
k = 1871
and
k = 1842
maybe I am hitting some preset limit?
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving email
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
Hi,
Is there anybody working on ticket #23091?
https://trac.sagemath.org/ticket/23091
There seem similar tickets #7207, #23091.
Of course, there is a way to bypass this (don't import anything from
__future__), or I use Python3 port of Sagemath :)
--
---
Iwao KIMURA
Dept. Mathematics, U. of Toyam
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 get it. Thank you. It is the old tool-upgrade-breaks-lots-of-things
scenario.
Using the upstream numpy instead of my locally built, later version, means
that it found and is trying to link to something old. I need to read out
the -L arguments and see where it went askew.
In the meantime, before y
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
You suffer from a classic case of gcc/gfortran upgrade. I have been fielding
bugs
for the same kind of errors in Gentoo for a number of months now.
up to gcc-6, gfortran provided its runtime with libgfortran.so.3.
But gcc-7 broke the compatibility and provided libgfortran.so.4.
And gcc-8 broke the
25 matches
Mail list logo
