On Sep 6, 1:48 pm, Simon King wrote:
> > We've seen before that invalidated expect interfaces can interact
> > unexpectedly with weakreffed stuff in entirely unrelated places.
>
> Is it known how the interaction occurs? Is there a ticket or an example
> explaining the relation?
The issue we ran
On Sep 6, 2:40 pm, Simon King wrote:
> def _eval_line(self,...):
> if self.locked:
> raise RuntimeError, "%s is locked - preventing a nested call"%self
> self.locked=True
You'd need an atomic semaphore for that. And in fact, in the presence
of a fork, a semaphore that woul
On Sep 6, 9:00 am, Simon King wrote:
> [Errno 4] Interrupted system call
OK, here's at least a snippet that produces the relevant error
message:
sage: import signal
sage: import sys
sage: def handler(a,b):
: print "signal handled"
:
sage: signal.signal(signal.SIGALRM,handler)
0
s
First attempt at scheduling alarms a little cleaner:
http://trac.sagemath.org/sage_trac/ticket/13437
In hindsight, I don't think this ever comes into play for the doctest
you're looking at. There, timeout==0, so p_iter_fork never schedules
SIGALRMs. The signal that is interfering must be coming f
There seems to be a big push to use caching in a lot of places in
sage. There, a problem arises from the fact that sage's conventions
for equality tests are rather liberal.
Obviously, one should only cache functions that solely depend on the
equality class of their argument. That's probably less o
On Sep 13, 9:51 am, Volker Braun wrote:
> On Thursday, September 13, 2012 5:19:57 PM UTC+1, Nils Bruin wrote:
> > sage: A==B
> > True
> > sage: hash(A)
> > 0
> > sage: hash(B)
> > 44546084519852655
>
> Really, the issue is that the objects violate the
On Sep 13, 4:48 pm, Volker Braun wrote:
> The UniqueRepresentation issue is slightly more tricky. If you follow the
> "no __hash__" route then you can't use them as arguments to objects with
> unique representation. We either demand that == always means identical
> (often not convenient at the com
On Sep 14, 3:02 pm, Andrey Novoseltsev wrote:
> sage: list(m)
> [(0, 0), (0, 0)]
This is just a consequence of iter(m) yielding an iterator over the
rows of m. Changing that would break code.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To p
[Disclaimer: "comparison" here only means testing for equality here,
not
"comparison" in the sense of testing for a (partial) ordering.]
On Sep 15, 5:13 am, Simon King wrote:
> Hi!
>
> I think we are talking about two different topics here, that should be
> kept separate.
>
> 1) The hash must obe
On Sep 15, 9:51 am, Simon King wrote:
> You think so? If I was aware that something is cached, then I would be
> surprised if things were *not* stuffed into a dict behind the scenes.
The key is in the "If". People can easily use functions without
knowing whether or not they are cached. Caching i
On Sep 17, 4:45 am, Mizuchi wrote:
> Sometimes we only care about the cauchy principal value. How to get it from
> sage?
You could just use the definition:
sage: var('x,e')
(x, e)
sage: assume(e>0,e<1); integrate(1/x^3,x,-1,-e)+integrate(1/x^3,x,e,3)
4/9
In maxima_lib this line:
ecl_eval('(de
On Sep 19, 9:58 pm, Mizuchi wrote:
> I think it could be better if either (1) sage provide a
> parameter for integrate that whether accept the principal value, (2) or at
> least print a warning instead throw an exception.
Well here's a way that voids your warranty (which you didn't have
anyway):
On Oct 8, 9:30 am, Dox wrote:
> Sorry It's not getting updated.
Is it still not updated if you explicitly request a reload in your
browser? As far as I can see, reevaluating a cell does cause
full_output.txt to be rewritten with new content. It could be just
your browser being reluctant to ch
On Oct 11, 12:27 am, Jeroen Demeyer wrote:
> I think "relative" imports means something different here. It means
> relative in the logical module hierarchy, unrelated to the on-disk
> structure.
A bit of googling to provide context:
Python bug http://bugs.python.org/issue946373 closed as "won't
On Oct 16, 7:29 pm, Andrew Mathas wrote:
> register_unpickle_override('sage.combinat.tableau', 'Tableau_class',
> Tableau)
>
> but this does not work. My guess is that it is not possible to unpickle the
> deprecated *Tableau_class* objects using the new *Tableau* class objects
> because the under
OK, sorry. The hook is elsewhere:
You should provide a __setstate__ method on Tableau (or if you don't
like that, a proxy class that you provide with
register_unpickle_override). Now you have to write __setstate__ in
such a way that it can distinguish between input data for either
Tableau_class or
print an
B(10) instance
sage: bn = loads(dumps(b))
B(20) instance
sage: print bn
Someone should feel free to work this into appropriate doc. I thought
this was pretty discoverable already :-).
By the way, Andrew, 4 hours for learning how python's pickle protocol
works isn't so bad :-).
On Oct 19, 4:45 am, mmarco wrote:
> Do you think it would be worth implementing all these features
> ourselves? Is there some movement in the Singular community to
> implement these rings?
My first reaction is "no". For any non-trivial linear algebra or
polynomial computations, you'll be testing
Does this solve your problem? (found by googling "bits/predef")
http://askubuntu.com/questions/82510/gcc-no-longer-works-after-upgrade
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to sage-devel@googlegroups.co
On Oct 21, 4:03 am, mmarco wrote:
> That was my first idea when i encountered these problems. But then,
> things like primary decomposition rely on factorization of
> polynomials... which will differ a lot from QQbar to an algebraic
> extension of Q.
Indeed. Data point: Magma does allow QQbar as
On Oct 22, 8:06 am, William Stein wrote:
> Is there a research paper explaining the finite field approach to
> QQbar? It would be good to mention it here, since implementing
> similar functionality Sage for computing with QQbar would be a good
> project for somebody.
MR2578343 (2011d:13043) Ste
On Oct 24, 8:58 am, mmarco wrote:
> How fast is Magma for this?
Pretty snappy on small examples. Of course it'll get slow on bigger
ones. You can try yourself using their online version (at least as
long as you try examples that take less than 2 seconds total).
Example script:
Qbar:=AlgebraicClo
On Oct 30, 2:58 pm, David Roe wrote:
> I think this is a bug: the type of the result should be consistent.
> David
Consistent doesn't mean constant. Functions like "sin" are generic
functions that dispatch on input type:
sin(1.2) should return a float, not a symbolic expression (that would
be un
On Oct 31, 8:47 am, mmarco wrote:
> for i in range(10):
> print cos(i).n()
...
> Besides, 0 should be converted to Integer(0) by the
> preparser, right? so the criterion of keeping the input type also
> points to the same direction.
*keeping* input types would still let your example fail, sin
platform and I
suspect I am not the only one for which it is.
Cheers,
Nils
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this group, send emai
On Nov 8, 1:17 pm, Simon King wrote:
> Hi Volker,
>
> On 2012-11-08, Volker Braun wrote:
>
> > But then you'd always have to write a lot of
> > boilerplate to return an iterator. Its much easier to use yield, but then
> > you can't return any additional information about finiteness.
>
> No? What'
On Nov 8, 9:20 pm, Robert Bradshaw
wrote:
> However, I agree with the sentiment that V.sum(W) grossly violates the
> principle of least surprise as well as being of dubious merit over the
> builtin sum(...).
And note that python's builtin sum is in sage shadowed by
sum=sage.misc.functional.symb
On Nov 9, 2:11 am, "Nicolas M. Thiery"
wrote:
> The main point is that writing V.sum(args) gives more information to
> the system than sum(args, self.zero()): this is making a promise that
> all elements in args are elements of V.
In python's call dispatch system, it does not. It says something a
On Nov 10, 1:35 pm, John H Palmieri wrote:
> By the way, to clarify: this will only affect the 'server' directory. which
> consists of unused code (old notebook code, superseded by sagenb), since
> that's the only place there are files called 'nodoctest.py'.
Do we have a good reason to carry aro
On Nov 12, 7:21 am, Andrea Lazzarotto
wrote:
> > is there any method which gives me an Ascii output for a
> > mathematical-express like sqrt(x)?
You can use some of maxima's capabilities for that:
sage: maxima(x^(1/x)).display2d()
1/x
On Nov 12, 9:46 am, Dima Pasechnik wrote:
> please have a look (and perhaps reply - I am not an expert on this
> stuff):
It has to check that a certain analytic function vanishes to 8th order
at a particular point. That involves proving that all its derivatives
up to 7th order vanish at the point
On Nov 12, 12:08 pm, Jason Grout wrote:
> I think you can also use gdb; it seems I've done it once before, at least.
I have used gdb for stack examination after a segfault. For "C-like"
pieces of Cython it works quite well. For "Python-like" pieces it's
horrible, because python objects are virtua
On Nov 12, 12:33 pm, Nils Bruin wrote:
> Does this need a "cydb" wrapper around gdb or does gdb have its
> own customization options that allow something along these lines?
I should have googled before I replied:
http://docs.cython.org/src/userguide/debugging.html
It would be
On Nov 12, 10:07 am, P Purkayastha wrote:
> + inv = self.base_ring()(1)/self.base_ring()(right)
It's probably more efficient to do:
inv = self.base_ring().one()/self.base_ring()(right)
since it completely avoids the coercion framework for constructing 1.
--
You received this messa
On Nov 12, 6:06 pm, Dima Pasechnik wrote:
> sage: e.cremona_label()
> '457532830151317a1'
> sage: e.analytic_rank(leading_coefficient=True)
> (4, -2.50337480324368498e-9)
>
> here is what I got after some hours of running.
> e-9 does not look as suspiciosuly small to me...
That depends on what th
On Nov 12, 1:47 pm, Jeroen Demeyer wrote:
> And for added fun: this time the error isn't always reproducible.
That's excellent news! Just keep trying until it's not reproducible
anymore. Then we're fine!
Seriously though, given that the bug pops up in the same file as
before indicates that proba
On Nov 14, 8:29 am, Jeroen Demeyer wrote:
> It happens also on other systems, including 64-bit. It's easy to
> reproduce on the Skynet machine "sextus" (Linux x86_64) where it happens
> about 71% of the time.
That might be workable. What exact version/patches to reproduce the
problem? (I don't t
On Nov 14, 11:28 am, Jeroen Demeyer wrote:
> FYI: it's a Fedora 16 system with an Intel(R) Pentium(R) 4 CPU 3.60GHz
> processor running Linux 3.3.7-1.fc16.x86_64.
That sounded convenient because my desktop is similar:
Fedora 16 running 3.6.5-2.fc16.x86_64 #1 SMP on Intel(R) Core(TM)
i7-2600 CPU
However, in an effort to make memory errors during testing a little
more reproducible I made this little edit to local/bin/sagedoctest.py
to ensure the garbage collector is run before every doctested line:
diff --git a/sagedoctes
:
This is actually reproducible in plain 5.0. This is now
http://trac.sagemath.org/sage_trac/ticket/13710
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email to sage-devel@googlegroups.com.
To unsubscribe from this g
Other consequences from gc.collect() insertions:
sage -t -force_lib devel/sage/sage/crypto/mq/mpolynomialsystem.py #
Killed/crashed
sage -t -force_lib devel/sage/sage/rings/polynomial/
multi_polynomial_sequence.py # Killed/crashed
(same problem; reported as above)
On Nov 13, 1:26 am, John Cremona wrote:
> No, you do not miss anything. As someone has already reminded us (and
> I say clearly in the talk for which those are the slides), there is no
> known way of proving that the 3rd (or higher) derivative of an
> elliptic curve L-function is 0. Any computat
On Nov 15, 11:59 pm, Jeroen Demeyer wrote:
> Could you try again with sage-5.5.beta1?
Same behaviour. Was there a reason to expect differently?
I guess something is different on sextus. Bad memory/other hardware
problems?
I was surprised by how little issues arose from inserting garbage
collecti
This is probably a good one for Simon King to look into:
sage-5.5beta1, with gc.collect() inserted in local/bin/
sagedoctest.py:run_one_example
Furthermore, modified singular to use system malloc:
http://sage.math.washington.edu/home/nbruin/singular-3-1-5.malloc-linux.spkg
[Note: this is a very
It's worth running the sage testsuite on linux with "export
MALLOC_CHECK_=3" (on OSX, look up gmalloc for similar testing). It
makes malloc a little less tolerant of misuse. It found a problem in
graph_generators.py. See
http://trac.sagemath.org/sage_trac/ticket/13719
--
You received this messag
On Nov 16, 10:57 pm, Simon King wrote:
> I think it should be on a Sage trac ticket even if it should be the case
> that ultimately it is an upstream bug.
I don't think it's upstream. I think it's a bad interaction between
how we (fail to) properly refcount singular objects and how it is
expected
On Nov 17, 1:01 am, Jeroen Demeyer wrote:
> On 2012-11-16 19:35, Nils Bruin wrote:> On Nov 15, 11:59 pm, Jeroen Demeyer
> wrote:
> After adding every single ticket, there is reason to expect differently.
> This stuff is *so sensitive* to changes, even changes which look
> co
On Nov 17, 12:20 pm, Ivan Andrus wrote:
> At one point I had the goal of creating a suppressions file so that the
> doctests passed "cleanly". I'm sure some of the suppressions were actual
> problems, but it would at least allow you to find new problems. I still have
> the scripts that I use
On Nov 17, 9:28 pm, Robert Bradshaw
wrote:
> How about doing
>
> sage: f = legendre_P(3, GF(11)['x'].gen()); f
> 8*x^3 + 4*x
> sage: parent(f)
> Univariate Polynomial Ring in x over Finite Field of size 11
> sage: f(5)
> 8
>
> However, the implementation (manipulating strings) is pretty horrid.
On Nov 16, 7:05 pm, Nils Bruin wrote:
> ./sage -t --gdb devel/sage/sage/libs/singular/function.pyx
Interestingly, when running this with ElectricFence using
$ export LD_PRELOAD=libefence.so
$ export EF_ALLOW_MALLOC_0=1 #apparently sage/python does a
malloc(0) somewhere
$ echo 512000 | s
On Nov 18, 9:22 am, Dima Pasechnik wrote:
> How different is "rational number"*"finite field element"
> from division, which is also a partial operation?
> (Well, I admit I don't know Sage's coersion model at all...)
Robert is probably more qualified to explain, but I'll try for now.
Both
*
an
On Nov 18, 6:28 pm, Dima Pasechnik wrote:
> if I understand it right, if we define the minimal parent of
> elements of GF(p^k) and QQ to be GF(p^k), then we get all this for free.
Yes, but the problem is that there is NOT a natural morphism QQ ->
GF(p^k); only a partial map. I don't know how muc
On Nov 19, 6:22 am, Dima Pasechnik wrote:
> Perhaps the coersion system itself might be a bit confused, but
> it looks like here we talk rigour for the sake of rigour, without
> any benefits.
One benefit is error detection and picking proper normalizations. For
instance, if you create a "reducti
For debugging, the behaviour already occurs with:
sage: A. = FreeAlgebra(QQ, 2)
sage: P. = A.g_algebra({y*x:-x*y})
sage: x*y
if you set `MALLOC_CHECK_ 3` and use singular-malloc. So I'd be
surprised if python's gc comes into play here. I think it might be a
pure mismatch in refcount i
These issues are now trac-ed at
http://trac.sagemath.org/sage_trac/ticket/13731
Feel free to reformat/redistribute that data.
It would be very welcome if someone would clean up the libsingular-
malloc package so that it can be used more cleanly. I don't have the
packaging skill to do that, but I d
On Nov 21, 5:15 am, Dima Pasechnik wrote:
> hmm, I don't think this example will fly. If you happen to have a
> divisior of p in the denominator then you get a point with every
> nonzero coordinate divisible by p. So the reduction of it is
> (0:0..:0) -- oeps --- a runtime error sowieso...
Not qu
On Nov 25, 10:49 am, Christian Stump
wrote:
> Hi --
>
> we are almost ready getting the universal cyclotomic field, UCF (which
> is the smallest subfield of the complex numbers containing all roots
> of unity) into sage, seehttp://trac.sagemath.org/sage_trac/ticket/8327.
>
> In GAP, the point of e
On Nov 25, 12:12 pm, Nils Bruin wrote:
> However, I would be opposed to have E injected in the global namespace
> for this purpose.
Sorry, I wasn't clear there. I mean I'm opposed to have E injected *by
default*. Of course, once someone defines an instance of this field
then
On Nov 25, 9:55 pm, Dima Pasechnik wrote:
> wouldn't EE be a more consistent choice, in line with QQ, ZZ, etc?
That looks like an emulation of \mathbb{E}, which I have quite
frequently seen used for expectation of a random variable and for
nothing else.
If we put UCF in the global namespace, wo
On Nov 26, 8:18 am, Christian Stump wrote:
> I agree that I could add this, though the term "gen" or "gens" is a little
> stretched in this context.
That will REALLY help discoverability, since that's what anyone with a
little sage experience expects to work.
> In which sense do exp( 2 pi i / n
On Nov 26, 10:01 am, Christian Stump
wrote:
> 2. accessing the UCF as myUCF = UniversalCyclotomicField(
> genname="E"). Do people prefer name or names (as in CyclotomicField)
> over genname ? This would also mean that there is nothing to
> initialize at startup, and thus no startup time difference
On Nov 26, 1:03 pm, Christian Stump wrote:
> Can you be a little more specific here? How would you want the
> embedding being defined using an extra argument?
Perhaps (embedding = emb)
where emb is an indexable object such that emb[i] yields the image of
zeta[i] ?
Of course, it is possible t
On Nov 27, 6:12 am, Christian Stump wrote:
> sage: UCF. = UniversalCyclotomicField(); UCF
> Universal Cyclotomic Field endowed with the Zumbroich basis
> sage: E(5)
> E(5)
> sage: UCF. = UniversalCyclotomicField()
> sage: zeta(5)
> zeta5
OK, now we're firmly arriving in bikeshedding territory:
I
On Nov 27, 9:34 am, Nils Bruin wrote:
> As you see, Ka and Kb apparently have an arbitrary isomorphism between
> them that is preferred, but of course we can't expect that to be
> compatible with chosen embeddings.
This has actually more dangerous consequences than the example
On Nov 28, 12:46 am, Christian Stump
wrote:
> - I now define the embedding as follows: the optional argument
> embedding can be given a function n -> k where 0 \leq k < n, which I
> then use to embed the UCF into QQbar. The advantage of this approach
> is that I can also access this function in th
On Nov 28, 2:27 am, Christian Stump wrote:
> I do agree but the majority was for not having the function "E" in the
> global namespace, so I removed it. On the other hand, we now have
> UniversalCyclotomicField in there, so people can still find it by tab
> completion and read the manual.
If you
On Nov 28, 8:22 am, Christian Stump wrote:
> I see that for number field, the embedding is defined using
> number_field_morphisms.create_embedding_from_approx
Ah, that explains the odd behaviour for
CyclotomicField(...,embedding=CC(17)) we saw before. I guess it's
documented that it should just t
On Nov 28, 9:03 am, Christian Stump wrote:
> What about making the mapping n -> 0 \leq
> emb(n) < n one possibility to define the embedding into QQbar the way
> it is currently done, and as well giving the possibility to embed it
> similarly to the current embedding of NumberField ?
That's cute,
On Dec 1, 12:08 pm, John Cremona wrote:
> This makes it hard to see why projective coordinates are normalised
> sage: ProjectiveSpace(QQ,2)(list(v))
> (2/5 : 3/5 : 1)
I think this has its roots in mathematical tradition. Taking
coordinates (x,y) on affine space and homogenizing via (x,y)=(X/Z,Y/Z
On Dec 11, 1:54 pm, Jason Grout wrote:
> I think the OP's point was that it should complain about the types, not
> that we should make tuples act like vectors.
This strikes me as related to the decision on returning "False" for
equality between
incomparable objects versus raising an error:
sage:
There's a patchbot problem on #8327 that needs more eyeballs (or at
least Robert's eyeballs):
The patchbot there sporadically fails on various tests with errors of
the type
Traceback (most recent call last):
File "/mnt/storage2TB/patchbot/.sage/tmp/
volker_desktop.stp.dias.ie-14095/multireplace
On http://trac.sagemath.org/13826 there is now a workaround. However,
there is currently a problem with where the cache file lives: in
`.sage`. The problem is that running `sage -b` can invalidate the
cache. Indeed `sage -b` removes the cache file from the .sage of the
UID who runs `sage -b`. Other
On Dec 15, 5:05 am, Volker Braun wrote:
> This isn't the only place where something has to be run once after
> something in the filesystem changed, for example the GAP workspace and
> running sage-location both have the same underlying problem
Perhaps the lowest cost change is to go with a reliab
On Dec 19, 12:16 am, Jeroen Demeyer wrote:
> Just when I thought the #715 + #11521 issues were fixed in sage-5.5.rc1...
>
> Apparently, sage-5.6.beta0 has uncovered a new problem: with the current
> sage-5.6.beta0, I get the following reproducible segfault on hawk
> (OpenSolaris i386):
>
> > sag
On Dec 26, 10:04 am, Volker Braun wrote:
> I propose
> that we use SAGE_DEBUG in three different ways:
[...]
+1. Obvious and easy to use.
Very minor mod: Also provide an assignable value for SAGE_DEBUG for
the default behaviour, rather than relying on SAGE_DEBUG being unset.
Probably SAGE_DEBUG=
On Dec 26, 10:18 am, Nils Bruin wrote:
> Very minor mod: Also provide an assignable value for SAGE_DEBUG for
> the default behaviour, rather than relying on SAGE_DEBUG being unset.
> Probably SAGE_DEBUG='', unset SAGE_DEBUG and perhaps also
> SAGE_DEBUG='default&#
On Dec 27, 3:13 pm, Jeroen Demeyer wrote:
> Another issue came up: ticket #13566 also causes a segmentation fault
> which goes away when #715 + #11521 are undone.
[...]
> My feeling is increasing that Sage isn't ready yet for #715.
I feel compelled to repeat here that sage is not useful for my
re
Thank you, Volker and JP, for excellent instructions on #13864
Unfortunately(?) module.py now completes successfully for me. I
haven't been able to nudge it into giving the "import segfault" we
were seeing before. No surprise if pydebug changes the memory layout
of objects. That issue is obviously
On Dec 28, 2:17 pm, Simon King wrote:
> Could that be ZODB related?
My guess is that ZODB data structures are lying around with fields
that Python 2.7 recognizes as pointers, but which haven't increased
the refcount. Thus, if GC examines them it may find more pointers than
explained by the refcou
On Dec 28, 2:37 pm, Simon King wrote:
> How can I upgrade it? Is there a trac ticket?
see
http://trac.sagemath.org/sage_trac/ticket/13864#comment:79
I haven't made a ticket yet because I didn't know if it was a real
problem or just a silly artifact. Making a new spkg should be easy:
just drop in
Good progress thanks to #13864 . After solving the ZODB issue I'm now
running into the following (this is just one example, the same issue
arises in many cases):
sage: sage.homology.chain_complex.HomologyGroup(100)
ERROR (at getWritePointer in /usr/local/sage/5.6b1/local/include/
linbox/matrix/pe
On Dec 29, 6:01 am, Simon King wrote:
> * In sage/misc/memory_info.py, MemoryInfo().available_swap() returns
> zero, but it is expected to return a positive number. No idea where
> that comes from.
For me that test works properly. However, I'd say it's perfectly
legitimate to configure a syste
On Dec 29, 11:13 am, Volker Braun wrote:
> We set up GAP to reserve a lot of swap on systems with a lot of free swap.
> 640kb is not enough for everybody.
Agreed. It sucks that GAP needs an upper limit at startup, but we
won't be changing that.
I retract my complaint about sage not starting up:
> > Maybe the problem is with endomorphism rings, because we have the domain
> > and codomain pointing to the same parent, that's a nice culprit for a
> > superfluous decref.
I spent some quality time with gdb and this failing doctest. The good
news: memory layout is deterministic, so you can just
On Dec 30, 8:03 am, Volker Braun wrote:
> No, if you mmap() with MAP_NORESERVE then it always succeeds (if the
> processor can address it, 16TB on x86_64). Reads always succeed. But
> whenever you write to the memory map, you can get a SIGSEGV.
In the face of Linux's overcommit strategy and its O
OK, caught redhanded. Indeed, the freelist of this pool ends up being
circular, due to a double free happening. The first free is
indeed coming from a TripleDictEraser callback. The second one doesn't
seem to be. Indeed, the second one doesn't seem to be
triggered by a GC, but simply by a refcount
By the way, the object that is allocated in the block that eventually
gets freed twice is:
Set of Morphisms from to in Category of modules over Integer Ring
Note that the first dealloc above is part of a TripleDictEraser call,
that gets triggered by a PyObject_ClearWeakRefs as part of the deall
On Dec 24, 4:44 pm, Jean-Pierre Flori wrote:
> Any reason for calling directly _refcache.__delitem__ rather than del
> _refcache ?
> Changing this solves the problem, but surely only by hiding the bug...
I'm not so sure this only hides it. If my analysis is correct then
this line is virtually th
On Dec 31, 12:58 am, Jean-Pierre Flori wrote:
> But then I had a look at the C code Cython generated and thought it was
> the same...
> So we should look back at the C code, or ask a Python/Cython guru.
The __delitem__ compiles as an ordinary method lookup and call,
whereas the "del A[..]" compi
On Dec 31, 7:32 am, Simon King wrote:
> But I completely forgot: What exactly is the failing test, and what
> patches need to be applied to make it fail?
It's sage -t devel/sage/sage/modules/module.pyx on 5.6b0. However:
- I sometimes need to run it *twice* (I guess because some *.pyc
files must
On Dec 31, 7:29 am, Nils Bruin wrote:
> I am not sure that this is exactly the issue we're running into, but
> it seems plausible (it certainly needs a very brittle confluence of
> circumstances to become apparent). Furthermore, I think it is a
> scenario that does need ad
On Dec 31, 8:46 am, Jean-Pierre Flori wrote:
> Of course, if Nils is right, it might not be up to us to solve such
> problems, but rather Python itself...
It might by cython, not python:
A little grepping in the Python source shows that the first thing
dealloc methods do i
On Dec 31, 9:45 am, Simon King wrote:
> > The difference between the "del A[1]" and "A.__delitem__(1)" might only be
> > the fact that in the latter case (where more fucntions calls are performed)
> > a gc is triggered whereas its not in the first case, that's just a wild
> > guess though.
>
> Tha
On Dec 31, 10:38 am, Robert Bradshaw
wrote:
> Is there a build somewhere on sage.math that I could copy and reproduce
> this with?
There is now:
sage.math.washington.edu:/scratch/nbruin/5.6b2
I've inserted a gc.collect() into TripleDictEraser.__call__ to
reliably produce a crash with
./sage -t
On Dec 31, 3:23 pm, Robert Bradshaw
wrote:
> Curiously, we don't mark our objects as tracked or untracked in the
> constructor or destructor respectively in Cython at all. Hmm...
But the cinit and dealloc of object probably do support GC tracking,
so I suppose they get tracked and untracked from
On Dec 31, 3:48 pm, Nils Bruin wrote:
> I bet there must be examples of this in the python library
> that show how to cooperate with superclasses that already want to
> control tracking/untracking.
It looks like the discussion in Objects/typeobject.c, line 1024
onwards might be of
On Dec 31, 5:15 pm, Robert Bradshaw wrote:
> Looking at this more, this seems fine, as the un-initialized members are
> NULL before cinit completes, and set to null as dealloc progresses
> using Py_CLEAR. The traversal and clear functions ignore NULL members.
Except that the Py_CLEAR executions c
On Dec 31, 5:35 pm, Robert Bradshaw
wrote:
> Yeah, sticking an untrack there certainly seems safe. It looks
> like PyObject_GC_UnTrack is idempotent, so we don't have to track it before
> going up the dealloc stack. If this fixes it, I sense another Cython
> release around the corner...
Not quite
On Dec 31 2012, 9:36 am, Nils Bruin wrote:
> It might by cython, not python:
This is now
http://trac.sagemath.org/sage_trac/ticket/13896
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To post to this group, send email
On Jan 2, 5:29 am, Thierry Dumont wrote:
> The problem is that Python dictionaries are *very* slow. Do you know how
> they are implemented?
That's an interesting observation. I think python developers have put
a lot of time into optimizing their dict structures, because they are
used *everywhere*
401 - 500 of 1748 matches
Mail list logo
