I can't reproduce the pari message on 10.4, but your code leaks memory.
This might be the opposite of memory leak: use after free.
Use after free in general is considered security vulnerability.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To u
I don't have anything helpful to add but here is something I just ran into
(with version 10.2). Here, E = EllipticCurve('162a1') -- but rerunning in
a fresh Sage did not trigger the error. The number of bytes in the second
line is rather more than my laptop has, I think (and pari.stacksize()
On Tuesday 17 September 2024 at 07:04:18 UTC-7 dim...@gmail.com wrote:
that's the legacy of developing software in a platform-independent
machine assembly language
known as C or C++, or Fortran :-)
Then, as we know, Greenspun's tenth rule states that:
Any sufficiently complicated C or Fortra
On Tue, Sep 17, 2024 at 9:48 AM Georgi Guninski wrote:
>
> > It's very common for computer algebra packages to have memory leaks
>
> At least you are honest about the generalization for the whole
> software development theater.
that's the legacy of developing software in a platform-independent
ma
> It's very common for computer algebra packages to have memory leaks
At least you are honest about the generalization for the whole
software development theater.
Bill Gates said: "If I had a cent every time Windows crashes,
I would have been billionaire. Oh, wait..."
--
You received this messa
On Monday 16 September 2024 at 06:20:37 UTC-7 Georgi Guninski wrote:
Maybe fighting leaks should start at developer level, then QA.
Waiting to see gigabytes missing in a minute is a very crude way
to recognize leak.
It's very common for computer algebra packages to have memory leaks,
particu
> from there, https://pypi.org/project/objgraph/ . The author has linked some
> blogposts to illustrate how to use these tools to find memory links
Maybe fighting leaks should start at developer level, then QA.
Waiting to see gigabytes missing in a minute is a very crude way
to recognize leak.
-
On Sunday 15 September 2024 at 10:46:06 UTC-7 marc@gmail.com wrote:
> You can grab one of those objects on the heap and look at its
backreference graph
How does one do that?
You can grab one of the objects:
next(a for a in gc.get_objects() if id(a) not in pre and str(type(a)) ==
"")
(
> You can grab one of those objects on the heap and look at its backreference
> graph
How does one do that?
- Marc
On Sun, Sep 15, 2024 at 11:17 AM Nils Bruin wrote:
>
> On Sunday 15 September 2024 at 10:08:18 UTC-7 dim...@gmail.com wrote:
>
> For me this code is rather unpredictable, as ipyth
On Sunday 15 September 2024 at 10:08:18 UTC-7 dim...@gmail.com wrote:
For me this code is rather unpredictable, as ipython and prompt_toolkit
kick in
and produce extra objects.
For consistency (at least them the output values are reproducible)
it looks better to experiment with Sage's python
For me this code is rather unpredictable, as ipython and prompt_toolkit kick in
and produce extra objects.
For consistency (at least them the output values are reproducible)
it looks better to experiment with Sage's python (./sage --python)
for which the code needs to be adjusted, with "^" replace
On Sun, Sep 8, 2024 at 6:12 PM Marc Culler wrote:
>
> I think something else is causing Sage NumberField objects to leak memory
> (i.e. to not be deallocated) in your example. The fact that both issues
> involve growth of the PARI heap does not mean that both issues have the same
> cause. The
On Sunday 8 September 2024 at 13:18:40 UTC-7 marc@gmail.com wrote:
As I said above this does not happen with either cypari or cypari2 when
using getno.
This is not a cypari issue. The issue is that Sage creates a "unique"
object for each new number field, where new means that the input par
I'd say that, normally speaking, a cache is something of limited size,
and managed - once it is full, the least used objects are removed to
make room for new objects. I don't know if there are CASs which use
such a design.
An unlimited size cache is easier and more efficient - as long as you have
As I said above this does not happen with either cypari or cypari2 when
using getno.
This is not a cypari issue. The issue is that Sage creates a "unique"
object for each new number field, where new means that the input parameters
for the NumberField function have not been used before. The number
Can this be reproduced in plain Python with cypari2 installed?
One would need to replace the call to NumberField with the corresponding
cypari2 equivalent.
This would at least tell whether it's a leak in cypari2, or not.
Dima
On 8 September 2024 17:03:54 BST, Nils Bruin wrote:
>This examp
This example is definitely leaving loads of stuff on the python heap, so if
there is a leak onto the cython heap then it is not the only one. My guess
would be an interaction with the coercion system or UniqueRepresentation,
which both keeps global weak references to objects. If the key informat
Below is evidence (again) that the "leak" you are reporting is actually
caused by caching NumberField objects or related data. You can see that
when a calculation using a certain NumberField is repeated it does not
increase the size of the PARI heap, although the first time that the
calculati
I agree that this is a bug. I do not think it is the same issue as the
leak you reported involving elliptic curves. The reason I don't think so
is that it is possible to compute class numbers with no memory leak using
the PARI getno function in either cypari or cypari 2. There are many
thing
This is not complaint, it is an observation about bug of type memory leak.
To leak about one GB, run the testcase `leaknf5` from the top of the
thread with argument N=3*10^4:
#3*10^4 leaks: 1084.55 MB in 1m35.208s
--
You received this message because you are subscribed to the Google Groups
"s
Caching uses memory intentionally, for the purpose of speeding up
computations.
Leaks use memory unintentionally, for no purpose.
I don't know where the caching happens. I only deduce that it exists
because, when running the same computation twice, the second time is faster.
However, the cachi
On Wed, Sep 4, 2024 at 11:13 PM Marc Culler wrote:
>
> I think that here you are seeing caching taking place, rather than a memory
> leak. This is what I tried:
>
>
You call this caching, I call it leak, it can be both ways.
It is natural to compute the class numbers of QQ[sqrt(-n)] and
it shoul
On Monday, September 2, 2024 at 11:13:43 AM UTC-6 dima wrote:
It appears that all these gunclone_deep() etc aren't documented in any
proper way (and this is a root cause of this; same applies to memleaks we
have in libsingular interface). Can you post a link to docs you are reading?
I can only f
I think that here you are seeing caching taking place, rather than a memory
leak. This is what I tried:
sage: import cypari2
sage: pari = cypari2.Pari()
sage: def test(N):
: for a in range(1, N):
: K = NumberField(x^2+a, 'w')
: m = K.class_group().order
:
Georgi, sorry for misspelling your name.
- Marc
On Tuesday, September 3, 2024 at 12:56:49 PM UTC-5 Marc Culler wrote:
> That is a pretty interesting exchange, it indicates that this memory leak
> has been known to exist for 6 years, and the remedy is also discussed
> there. Details and answer
That is a pretty interesting exchange, it indicates that this memory leak
has been known to exist for 6 years, and the remedy is also discussed
there. Details and answers to questions asked in this thread follow.
To answer Dima's question first, the Pari documentation that I am referring
to is
It appears that all these gunclone_deep() etc aren't documented in any proper
way (and this is a root cause of this; same applies to memleaks we have in
libsingular interface). Can you post a link to docs you are reading?
I can only find an email exchange from 2018 where
similar issues are disc
sage: def test3(N,A=2**70):
: for a in range(1,N):
: e=EllipticCurve([A,0])
: m=e.root_number()
:
sage: test3(10^4)
sage: pari.getheap()
[7, 289]
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe fr
Is it known why the following doesn't leak?
sage: def test3(N,A=2**70):
: e=EllipticCurve([A,0])
: m=e.root_number()
:
sage: test3(10^4)
sage: pari.getheap()
[4, 149]
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscr
Unsurprisingly, changing gunclone to gunclone_deep in Gen.__dealloc__ is
not a full fix. It stops this leak but it also causes a crash when running
the doctests. On macOS the crash error is "freeing a pointer which was not
allocated". On linux the error is "corrupted size vs. prev_size in
fastbi
This is now fixed in cypari. The fix consisted of replacing gunclone by
gunclone_deep in the Gen.__dealloc__ method. The same change would
probably help in cypari2, although I would not expect it to fix the other
memory leaks reported in issue #112.
Here is the explanation. The Pari GEN retu
My experiments with cypari so far indicate the opposite of what I
expected. (This is with one small but significant bug fix that I found
along the way.) The main observations are:
(1) Without the call to pari.ellrootno there is no memory leak. The
call to pari.getheap returns the same value
I would say that the getheap behavior is a symptom of the same memory
management bug(s). Also, it is not as simple as you suggest. It is not
always true that every call to getheap leaves something on the heap:
>>> from cypari import pari
>>> pari.getheap()
[4, 41]
>>> pari.getheap()
[5, 58]
>>
On Sun, Sep 1, 2024 at 7:38 AM Georgi Guninski wrote:
>
> >As well, with cypari, a call to pari.getheap() adds 1 object there, a
> bug, I guess.
> >(this does not happen with cypari2)
> >In [14]: pari.getheap()
> >Out[14]: [334, 163655741]
> >In [15]: pari.getheap()
> >Out[15]: [335, 16365
>As well, with cypari, a call to pari.getheap() adds 1 object there, a
bug, I guess.
>(this does not happen with cypari2)
>In [14]: pari.getheap()
>Out[14]: [334, 163655741]
>In [15]: pari.getheap()
>Out[15]: [335, 163655758]
I can't reproduce this on 10.4:
sage: s=pari.getheap()
sage: fo
On Sat, Aug 31, 2024 at 4:35 AM Marc Culler wrote:
>
> As Dima says, and as the issue he mentions supports, the current cypari2 code
> which attempts to keep Pari Gens on the Pari stack as much as possible is
> badly broken. There are many situations where Python Gen objects cannot be
> garbag
As Dima says, and as the issue he mentions supports, the current cypari2
code which attempts to keep Pari Gens on the Pari stack as much as possible
is badly broken. There are many situations where Python Gen objects cannot
be garbage-collected after being destroyed. I am sure that is a big pa
On Fri, Aug 30, 2024 at 6:47 AM Georgi Guninski wrote:
>
> > How do you know that doesn't leak? Do you mean that repeated execution of
> > those commands in the same session does not swell memory use?
>
> I am computing the root number in a loop, collect garbage and measure
> the used memory usin
On Fri, Aug 30, 2024 at 8:02 AM Georgi Guninski wrote:
> For a start, I have been killing sage bugs since 2012 [1]:
> and have debugged some of them.
> I think I deserve to be listed as sage contributor for wasting my time
> and electricity.
>
We are always happy to acknowledge contributions.
On Fri, Aug 30, 2024 at 11:43 AM Dima Pasechnik wrote:
>
> If the loop over elliptic curves is shorter (or longer), do you still
> have the same leak size?
>
For a start, I have been killing sage bugs since 2012 [1]:
and have debugged some of them.
I think I deserve to be listed as sage contribut
> How do you know that doesn't leak? Do you mean that repeated execution of
> those commands in the same session does not swell memory use?
I am computing the root number in a loop, collect garbage and measure
the used memory using `Process.memory_info().rss`
> It may even be the case that 128
It would be good to reproduce this with cypari2 alone.
cypari2 is known to have similar kind (?) of problems:
https://github.com/sagemath/cypari2/issues/112
On Thu, Aug 29, 2024 at 6:47 PM Nils Bruin wrote:
>
> On Thursday 29 August 2024 at 09:51:04 UTC-7 Georgi Guninski wrote:
>
> I observe tha
On Thursday 29 August 2024 at 09:51:04 UTC-7 Georgi Guninski wrote:
I observe that the following does not leak:
E=EllipticCurve([5*13,0]) #no leak
rn=E.root_number()
How do you know that doesn't leak? Do you mean that repeated execution of
those commands in the same session does not swell m
I observe that the following does not leak:
E=EllipticCurve([5*13,0]) #no leak
rn=E.root_number()
The size of the leak is suspiciously close to a power of two.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and st
The leakage does not seem to be happening on the python heap. A next step
could be to see if cypari's stack is swelling.
On Thursday 29 August 2024 at 02:34:06 UTC-7 Georgi Guninski wrote:
> In short:
> ```
> for A2 in range(1, 10**5):
> E=EllipticCurve([A2,0])
> rn=E.root_number()
> ```
> leaks
I've created a PR with the missing mpz_clear and a unit test strategy for
memory leaks at https://github.com/sagemath/sage/pull/36046
On Friday, August 4, 2023 at 1:46:15 AM UTC+2 Dima Pasechnik wrote:
> is it related to https://github.com/sagemath/sage/issues/27185 ?
> and/or
> https://github
is it related to https://github.com/sagemath/sage/issues/27185 ?
and/or
https://github.com/sagemath/sage/issues/19363
pynac is a worry.
On Thu, 3 Aug 2023, 23:59 Volker Braun, wrote:
> A quick valgrind run for
>
> from sage.all import sqrt
> T2 = sqrt(2)
> for b in range(num := 100
A quick valgrind run for
from sage.all import sqrt
T2 = sqrt(2)
for b in range(num := 100_000):
C = sqrt(T2)
confirms that it is in pynac:
==3947957== 799,912 bytes in 99,989 blocks are definitely lost in loss
record 1,299 of 1,300
==3947957==at 0x484182F: malloc (vg_re
The leak does not seem to be on the python heap, so Pynac is the next
likely candidate (I don't think this code should be hitting maxima_lib)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails
El lunes, 16 de mayo de 2022 a las 17:34:14 UTC+2, Ricardo Buring escribió:
> Specifically bliss::AbstractGraph::canonical_form calls
> bliss::AbstractGraph::search, which sometimes calls
> bliss::Partition::cr_init without calling bliss::Partition::cr_free, due
> to a (conditional) early retur
Hi Thomas,
Sorry for taking so long to respond as I was away from my computer last
week to test.
Yes, I seem to be seeing it as well. However, if it is within bliss, then
it needs to be solved upstream (and/or with a patch here).
Best,
Travis
On Tuesday, April 26, 2022 at 5:47:07 AM UTC+9
Hi Travis,
I do not know whether the leak is caused within bliss or by sage's wrapper
unfortunately.
But can you reproduce the problem?
Best,
Thomas
On Monday, April 25, 2022 at 2:49:07 AM UTC+2 Travis Scrimshaw wrote:
> Hi Thomas,
>Could the memleak be coming from within bliss?
>
> Best,
Hi Thomas,
Could the memleak be coming from within bliss?
Best,
Travis
On Sunday, April 24, 2022 at 1:50:26 AM UTC+9 t.will...@gmail.com wrote:
> Dear all,
>
> there seems to be a memory leak in canonical_label(...), using bliss.
> Here is a test script to demonstrate the problem:
>
> --
Its the same code in the Main line. Sorry for the confusion.
I googled it and that is how I found the exact place where this is defined.
What I linked is how it looks now accounting for changes in gmp 6.2. Flint
2.6.3 has it but not 2.5.2.On May 14, 2021 10:31 PM, Dima Pasechnik
wrote:
>
> On
On Fri, May 14, 2021 at 4:03 PM 'jonatha...@googlemail.com' via
sage-devel wrote:
>
> I think I tracked it down.
>
> https://github.com/BrianGladman/flint/blob/trunk/gmpcompat.h
this is a fork, dealing with Windows support of Flint.
We should be working with
https://github.com/wbhart/flint2
whic
Thanks Freddie for reporting this.
I'm glad it resolves so easily. Yes, that is a mistake in our 9.2
configure. One can fix this by passing `--with-system-gmp=no` to
configure, but it should have rejected gmp 6.2 as long as flint 2.5.2 is
the install candidate.
So you can update sage or rebu
Awesome, many thanks for running this down.
`sage --standard | grep gmp`
>> gmp.6.1.2 (not_installed)
`equery --quiet list gmp`
>> dev-libs/gmp-6.2.1-r1
`sage --standard | grep flint`
>> flint...2.5.2.p5 (2.5.2.p5)
So yes, that
I think I tracked it down.
https://github.com/BrianGladman/flint/blob/trunk/gmpcompat.h
In there you see that `flint_mpz_set_si` is modified to work with GMP 6.2
I'm assuming this one is picked up from your system?
`sage --standard | grep gmp`
This code is not present yet in flint 2.5.2, which
Dear all,
Sorry for the delay getting back to you -- this was waiting in the
moderation queue for a bit (me being new) and then I dropped the ball.
> run the underlying functions
>
> M = identity_matrix(n)
> L = M.list()
> MS = sage.matrix.matrix_space.MatrixSpace(GF(101), 1000, 1000,
sparse=F
we've fixed a memory leak in matrices recently (this fix will be in
9.3), not sure if this is related
https://trac.sagemath.org/ticket/31340
On Wed, May 5, 2021 at 8:45 AM 'jonatha...@googlemail.com' via
sage-devel wrote:
>
> Dear Freddie,
>
> thank you for the report.
>
> Fortunatly or unfortuna
Dear Freddie,
thank you for the report.
Fortunatly or unfortunately, I can't reproduce this on sage 9.2 or on the
develop branch (on ubuntu focal with libflint-2.5.2 and debian buster with
sage's flint 2.6.3).
This might be a bug with flint. What flint are you using?
You can go into detail, t
With 9.3.beta8 on arch I get:
588
0
memory usage 10k: 10.1875
0
memory usage 20k: 21.26953125
Le 18/03/2021 à 12:06, Antonio Rojas a écrit :
> On Arch, using system libraries:
>
> 0
> 0
> memory usage 10k: 10.69921875
> 0
> memory usage 20k: 21.40234375
>
> El jueves, 18 de marzo de 2021 a las
On Arch, using system libraries:
0
0
memory usage 10k: 10.69921875
0
memory usage 20k: 21.40234375
El jueves, 18 de marzo de 2021 a las 11:56:33 UTC+1, m.derick...@gmail.com
escribió:
>
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsu
let's move this to #26795:
see https://trac.sagemath.org/ticket/26795#comment:19
On Mon, Dec 3, 2018 at 9:34 AM Jori Mäntysalo wrote:
>
> On Mon, 3 Dec 2018, Dima Pasechnik wrote:
>
> > please post the test you use.
>
> import gc
>
> i = 0
> for P in Posets(8):
> if i % 1000 == 0:
>
On Mon, 3 Dec 2018, Dima Pasechnik wrote:
please post the test you use.
import gc
i = 0
for P in Posets(8):
if i % 1000 == 0:
gc.collect()
print get_memory_usage()
i += 1
_ = P.dimension()
--
Jori Mäntysalo
please post the test you use.
I don't see anything interesting there...
On Mon, Dec 3, 2018 at 7:39 AM Jori Mäntysalo wrote:
>
> On Sun, 2 Dec 2018, Dima Pasechnik wrote:
>
> > do you still see it with https://trac.sagemath.org/ticket/26795 ?
>
> Yes, it is still there.
>
> --
> Jori Mäntysalo
-
On Sun, 2 Dec 2018, Dima Pasechnik wrote:
do you still see it with https://trac.sagemath.org/ticket/26795 ?
Yes, it is still there.
--
Jori Mäntysalo
do you still see it with https://trac.sagemath.org/ticket/26795 ?
On Saturday, December 1, 2018 at 7:11:00 PM UTC, Jori Mäntysalo wrote:
>
> This shows a leak:
>
> i = 0
> for P in Posets(8):
> if i % 1000 == 0:
> gc.collect()
> print get_memory_usage()
> i += 1
On Friday, November 4, 2016 at 7:11:27 PM UTC, Sébastien Labbé wrote:
>
> I created https://trac.sagemath.org/ticket/21826
>
OK, I've reviewed it already :-)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and st
Oups! closing #21826 as duplicate!
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to
I created https://trac.sagemath.org/ticket/21826
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, se
I have created https://trac.sagemath.org/ticket/21825 to track this.
On Friday, November 4, 2016 at 1:18:34 AM UTC, Saul Schleimer wrote:
>
>
> This also appears to leak memory:
>
> def get_polytope():
> q = MixedIntegerLinearProgram( maximization = False, solver = 'Coin' )
> w = q.new_
This also appears to leak memory:
def get_polytope():
q = MixedIntegerLinearProgram( maximization = False, solver = 'Coin' )
w = q.new_variable(real = True, nonnegative = True)
q.add_constraint( w[0] == 0 )
def fill_memory(n):
for i in xrange(n):
P = get_polytope(
Therefore, this should also leak:
def get_polytope():
q = MixedIntegerLinearProgram( maximization = False, solver = 'Coin' )
w = q.new_variable(real = True, nonnegative = True)
q.add_constraint( w[0] == 0 )
q.add_constraint( w[1] == 0 )
def fill_memory(n):
for i in xrange(n):
Dear Sébastien -
>
> def get_polytope(M):
> q = MixedIntegerLinearProgram( maximization = False, solver = 'Coin' )
> w = q.new_variable(real = True, nonnegative = True)
> for v in M.rows():
> q.add_constraint( dot_prod(v, w) == 0 )
> return None
>
This also leaks.
> de
Can you check if the following also leaks?
def get_polytope(M):
q = MixedIntegerLinearProgram( maximization = False, solver = 'Coin' )
w = q.new_variable(real = True, nonnegative = True)
for v in M.rows():
q.add_constraint( dot_prod(v, w) == 0 )
return None
def get_polytop
It seems that:
'CVXOPT', 'PPL', 'GLPK' don't leak
'COIN' does
'CPLEX', 'Gurobi' are not yet installed on my machine
best,
saul
On Wednesday, November 2, 2016 at 5:23:27 AM UTC-7, Dima Pasechnik wrote:
>
>
>
> On Wednesday, November 2, 2016 at 11:22:43 AM UTC, Sébastien Labbé wrote:
>>
>> I get
On Wednesday, November 2, 2016 at 11:22:43 AM UTC, Sébastien Labbé wrote:
>
> I get: "ImportError: No module named coin_backend".
>
> Without solver='Coin', I get:
>
> sage: get_memory_usage()
> 316.6015625
> sage: fill_memory(2000)
> sage: get_memory_usage()
> 341.578125
> sage: fill_memory(2000
I get: "ImportError: No module named coin_backend".
Without solver='Coin', I get:
sage: get_memory_usage()
316.6015625
sage: fill_memory(2000)
sage: get_memory_usage()
341.578125
sage: fill_memory(2000)
sage: get_memory_usage()
341.578125
sage: fill_memory(2000)
sage: get_memory_usage()
341.57812
Fixed in Cython. I provided a backport of the patch in Sage at #20268
(needs review).
Volker: Once it is reviewed, could we have a new stable Sage release
with the fix?
Vincent
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe fr
For the python-level leak, I think it's down to this:
x = polygen(ZZ)
v = x # or 1/3 or RR(3) but not, say 3
pre={id(c) for c in gc.get_objects()}
for _ in range(2): test =
sage.rings.polynomial.polynomial_element.Polynomial.__call__(x,v)
It ends up letting a lot of 1-element tuples of the
Strangely enough, it does not seem to be NTL related... I was able to
reproduce a somehow minimal Cython example without any use of Sage.
. See the report on Cython mailing list
https://groups.google.com/forum/#!topic/cython-users/g10b0911qq0
The reason why everything is fine with FLINT vers
On Wednesday, March 23, 2016 at 12:08:29 PM UTC-7, vdelecroix wrote:
>
>
> I am not sure about the Python analysis (though it might be some other
> problem).
>
> I observed the same thing. It looks like we're looking at two different
memory leaks in the same example:
1) A plain old malloc-type
On 23/03/16 15:39, Nils Bruin wrote:
On Wednesday, March 23, 2016 at 9:17:58 AM UTC-7, vdelecroix wrote:
Hello,
Some friend just sent an e-mail to me mentioning a memory leak. Here is
a minimal example
sage: x = polygen(ZZ)
sage: K = NumberField(x**3 - 2, 'cbrt2', embedding=RR(1.2599))
sage:
On Wednesday, March 23, 2016 at 9:17:58 AM UTC-7, vdelecroix wrote:
>
> Hello,
>
> Some friend just sent an e-mail to me mentioning a memory leak. Here is
> a minimal example
>
> sage: x = polygen(ZZ)
> sage: K = NumberField(x**3 - 2, 'cbrt2', embedding=RR(1.2599))
> sage: w = K.gen()
> sage:
> Why it doesn't just check if dot2tex has been installed as an optional
> package?
>
Because one also needs an installation of graphviz as well (which is an
experimental package, but a system-wide installation is what is recommended
and typically used).
>
> Or should Sage be able to use sy
> Why it doesn't just check if dot2tex has been installed as an optional
> package?
>
> Or should Sage be able to use system-wide dot2tex also?
>
> In any case, something should be done. Who will make a ticket?
You can. Ticket 18124 was created recently, but it is not immediately
related (it may c
On Sat, 30 May 2015, Travis Scrimshaw wrote:
So it seems to come from the have_dot2tex() function, in that it tests the
installation of dot2tex by executing a dot2tex command. I think the easiest
and best solution would be to make have_dot2tex() into a @cached_function.
Why it doesn't just che
So it seems to come from the have_dot2tex() function, in that it tests the
installation of dot2tex by executing a dot2tex command. I think the easiest
and best solution would be to make have_dot2tex() into a @cached_function.
Best,
Travis
On Saturday, May 30, 2015 at 8:23:57 AM UTC-7, Jori Män
On Sat, 30 May 2015, Nathann Cohen wrote:
OK, so it's dot2tex (I guess). Somebody wants to test with it installed?
Having doc2tex turns a 100ms function into a 30s functions ? O_o
I tested this on 6.8beta1 on quite old and slow computer with 32-bit
kernel. In this machine the result after
> OK, so it's dot2tex (I guess). Somebody wants to test with it installed?
Having doc2tex turns a 100ms function into a 30s functions ? O_o
Nathann
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving
On Fri, 29 May 2015, Nathann Cohen wrote:
I did P6=Posets(6).list() and then for 4 time
I ran the code you give, and instead of 33s I get 94ms :-P
sage: P6=Posets(6).list()
sage: %timeit for P in P6:g=P.hasse_diagram()
10 loops, best of 3: 94.2 ms per loop
OK, so it's dot2tex (I guess
>
> I did P6=Posets(6).list() and then for 4 time
>
I ran the code you give, and instead of 33s I get 94ms :-P
sage: P6=Posets(6).list()
sage: %timeit for P in P6:g=P.hasse_diagram()
10 loops, best of 3: 94.2 ms per loop
sage: %timeit for P in P6:g=P.hasse_diagram()
10 loops, best of 3: 97.2 ms
Upon closer inspection, the leak always happens when libsingular evaluates
a polynomial to a constant. Its just more noticeable in GF(11^2) because we
leak more memory per iteration.
Fix is at http://trac.sagemath.org/ticket/16958
--
You received this message because you are subscribed to the
Does leak with 6.0, I don't have an older version around to test.
On Wednesday, September 10, 2014 9:31:51 AM UTC+1, Jean-Pierre Flori wrote:
>
> Does it also leak with older version of Sage?
>
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To u
Does it also leak with older version of Sage?
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send
this does not remind me of anything except
http://trac.sagemath.org/ticket/3603 which is surely unrelated (different
backend) and http://trac.sagemath.org/ticket/13447 but not so related
either.
On Wednesday, September 10, 2014 1:03:15 AM UTC+2, Volker Braun wrote:
>
> I was dabbling in arithme
Le lundi 16 juin 2014 16:53:45 UTC+2, Volker Braun a écrit :
>
> The problem is in posets, so you get it in all methods that construct the
> face lattice:
>
> http://trac.sagemath.org/ticket/14356
>
>
Ok! Good to know! Thanks for the quick reply!
--
You received this message because you are s
The problem is in posets, so you get it in all methods that construct the
face lattice:
http://trac.sagemath.org/ticket/14356
On Monday, June 16, 2014 3:47:18 PM UTC+1, jplab wrote:
>
> Hey Sage-devel!
>
> I've been experiencing memory issues dealing with Polyhedron objects for a
> while now
On Aug 15, 5:48 am, Simon King wrote:
> Anyway, I'd be glad if someone could review #715, #11521, #12313 and
> #13370...
I'm trying! In the process, I think I might have found a useful
debugtool. In sage.structure.coerce_dict, I have added:
cpdef refcache():
"""
for debug reasons only! A
1 - 100 of 161 matches
Mail list logo
