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
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
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
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
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
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
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
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:
> 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
Thanks! 11468 fixed the leak. While I was at it I gave 11495 a positive
review also.
On Mon, Jul 25, 2011 at 1:19 AM, Jean-Pierre Flori wrote:
> I tested your function on my Sage 4.7.alpha? install with 11468 (not
> 14468...) and 11495 and I do not seem tp get the leak:
> sage: leak()
> 0.46875
>
On 09/19/2010 08:45 PM, dmharvey wrote:
> On Sep 19, 9:28 pm, dmharvey wrote:
>> Curiouser and curiouser it has nothing to do with matrices. Even
>> doing this causes the problem:
>>
>> K = Integers(13^10)
>> M = [[K.random_element() for j in range(200)] for k in range(200)]
>> save(M, "thing.
Gonzalo,
On Mon, Mar 15, 2010 at 1:17 PM, Gonzalo Tornaria
wrote:
> On Mon, Mar 15, 2010 at 3:57 PM, Brian Granger
> wrote:
> > Thanks for describing this better, it helps me to understand what the
> > current _sig_on/_sig_off does. Because of the licensing issues, I am
> > not looking at the c
William,
Fantasic, thanks for trying this!
Cheers,
Brian
On Mon, Mar 15, 2010 at 2:02 PM, William Stein wrote:
> On Mon, Mar 15, 2010 at 12:57 PM, Brian Granger
> wrote:
> > Gonzalo,
> > On Sun, Mar 14, 2010 at 9:21 PM, Brian Granger
> > wrote:
> >>
> >> > Gonzalo,
> >> > Thanks for startin
On Mon, Mar 15, 2010 at 12:57 PM, Brian Granger wrote:
> Gonzalo,
> On Sun, Mar 14, 2010 at 9:21 PM, Brian Granger
> wrote:
>>
>> > Gonzalo,
>> > Thanks for starting this discussion. I am willing to help with this
>> > effort
>> > as I definitely need this capability. Part of the challenge will
On Mon, Mar 15, 2010 at 3:57 PM, Brian Granger wrote:
> Thanks for describing this better, it helps me to understand what the
> current _sig_on/_sig_off does. Because of the licensing issues, I am
> not looking at the code in Sage until it has been officially re-licensed.
> Once that has been do
Gonzalo,
On Sun, Mar 14, 2010 at 9:21 PM, Brian Granger
wrote:
> > Gonzalo,
> > Thanks for starting this discussion. I am willing to help with this
> effort
> > as I definitely need this capability. Part of the challenge will be
> > figuring out how to do this on Windows.
>
> Not necessarily.
On Mar 14, 2010, at 8:18 PM, Gonzalo Tornaria wrote:
On Sat, Mar 13, 2010 at 7:22 PM, Robert Bradshaw
wrote:
On Mar 13, 2010, at 4:04 PM, Gonzalo Tornaria wrote:
What are the options for supporting this (either the
decorator/function attribute or the with-clause)?
We can support both. We co
On Sun, Mar 14, 2010 at 9:21 PM, Brian Granger wrote:
> Gonzalo,
> Thanks for starting this discussion. I am willing to help with this effort
> as I definitely need this capability. Part of the challenge will be
> figuring out how to do this on Windows.
Not necessarily. I think signals(2) is pa
On Sat, Mar 13, 2010 at 7:22 PM, Robert Bradshaw
wrote:
> On Mar 13, 2010, at 4:04 PM, Gonzalo Tornaria wrote:
>> What are the options for supporting this (either the
>> decorator/function attribute or the with-clause)?
>
> We can support both. We could support custom signal handlers via something
> no_signals? signals_disabled? This would give something like:
>
>with no_signals:
>...
>
>with signals_disabled:
>...
>
>
The current names in Sage of _sig_on/_sig_off are a bit confusing and the
names no_signals or signals_disabled carry forward that confu
Gonzalo,
Thanks for starting this discussion. I am willing to help with this effort
as I definitely need this capability. Part of the challenge will be
figuring out how to do this on Windows.
Eventually, I think we do want to capability to be built into Cython. But,
while we experiment with di
On Sat, Mar 13, 2010 at 04:22:09PM -0800, Robert Bradshaw wrote:
> There's also the question of naming--sig_on probably isn't the
> clearest name.
no_signals? signals_disabled? This would give something like:
with no_signals:
...
with signals_disabled:
...
On Mar 13, 2010, at 4:04 PM, Gonzalo Tornaria wrote:
On Sat, Mar 13, 2010 at 2:30 PM, Robert Bradshaw
wrote:
On Mar 13, 2010, at 5:29 AM, Nicolas M. Thiery wrote:
def bla(...):
with sig_on:
if ...
raise ...
elif ...
return
...
This is exactly
On Sat, Mar 13, 2010 at 2:30 PM, Robert Bradshaw
wrote:
> On Mar 13, 2010, at 5:29 AM, Nicolas M. Thiery wrote:
>>
>> def bla(...):
>> with sig_on:
>> if ...
>> raise ...
>> elif ...
>> return
>> ...
This is exactly the required semantics. I didn't k
On Mar 13, 2010, at 5:29 AM, Nicolas M. Thiery wrote:
On Thu, Mar 11, 2010 at 12:07:16AM -0500, Gonzalo Tornaria wrote:
What may actually be nice is to have some kind of support in cython
to
declare we want signals enabled for a whole function (something
like a
decorator or attribute). Cyth
On Thu, Mar 11, 2010 at 12:07:16AM -0500, Gonzalo Tornaria wrote:
> What may actually be nice is to have some kind of support in cython to
> declare we want signals enabled for a whole function (something like a
> decorator or attribute). Cython would then add the calls to every
> entry and exit po
On Fri, Mar 5, 2010 at 7:47 AM, Simon King wrote:
> I created a ticket at
> http://trac.sagemath.org/sage_trac/ticket/8444
Thanks Simon. I posted a patch with an explanation into that ticket,
which is now awaiting review (it's one line patch).
I was looking around gen.pyx, and there seems to be
Em 6 de março de 2010 13:29, Paulo César Pereira de Andrade
escreveu:
> 2010/3/6 Robert Bradshaw :
>> On Mar 5, 2010, at 6:33 PM, Minh Nguyen wrote:
>>
>>> Hi Dima,
>>>
>>> On Sat, Mar 6, 2010 at 1:27 PM, Dima Pasechnik wrote:
if it's PARI-dependent, it makes sense to upgrade PARI to th
2010/3/6 Robert Bradshaw :
> On Mar 5, 2010, at 6:33 PM, Minh Nguyen wrote:
>
>> Hi Dima,
>>
>> On Sat, Mar 6, 2010 at 1:27 PM, Dima Pasechnik wrote:
>>>
>>> if it's PARI-dependent, it makes sense to upgrade PARI to the latest
>>> version.
>>
>> Perhaps upgrading Pari could be a goal for Sage 5.0?
On Mar 5, 2010, at 6:33 PM, Minh Nguyen wrote:
Hi Dima,
On Sat, Mar 6, 2010 at 1:27 PM, Dima Pasechnik
wrote:
if it's PARI-dependent, it makes sense to upgrade PARI to the latest
version.
Perhaps upgrading Pari could be a goal for Sage 5.0?
It is: http://trac.sagemath.org/sage_trac/wiki
On Fri, Mar 5, 2010 at 10:28 PM, Mike Hansen wrote:
> On Fri, Mar 5, 2010 at 6:33 PM, Minh Nguyen wrote:
>> Hi Dima,
>>
>> On Sat, Mar 6, 2010 at 1:27 PM, Dima Pasechnik wrote:
>>> if it's PARI-dependent, it makes sense to upgrade PARI to the latest
>>> version.
>>
>> Perhaps upgrading Pari coul
On Fri, Mar 5, 2010 at 6:33 PM, Minh Nguyen wrote:
> Hi Dima,
>
> On Sat, Mar 6, 2010 at 1:27 PM, Dima Pasechnik wrote:
>> if it's PARI-dependent, it makes sense to upgrade PARI to the latest
>> version.
>
> Perhaps upgrading Pari could be a goal for Sage 5.0?
I think upgrading to the latest sta
Hi Dima,
On Sat, Mar 6, 2010 at 1:27 PM, Dima Pasechnik wrote:
> if it's PARI-dependent, it makes sense to upgrade PARI to the latest
> version.
Perhaps upgrading Pari could be a goal for Sage 5.0?
--
Regards
Minh Van Nguyen
--
To post to this group, send an email to sage-devel@googlegroups.
On 5-Mar-10, at 6:27 PM, Dima Pasechnik wrote:
if it's PARI-dependent, it makes sense to upgrade PARI to the latest
version.
PARI used by Sage is almost 2-year old.
They rolled out two upgrades in the meantime.
Unfortunately, updating PARI in sage is phenomenally difficult. I
tried more th
On Fri, Mar 5, 2010 at 10:47 AM, Simon King wrote
> Hi!
>
> I created a ticket at
> http://trac.sagemath.org/sage_trac/ticket/8444
I think this is caused by a duplicate _sig_on in the bottom part of
pari.__call__.
I'll post details and (possible) solution later (feel free to ping me
in a few da
94 matches
Mail list logo
