Dear Sage-Combinat Developers!
It's the time of the year where we need to report to our funding
agencies. The NSF asked us to send some highlights about the
Sage-Combinat project. To help with this, could all of you please
mail the details of any publications that used and/or cite Sage
to Minh
Dear Colleagues,
I just want to point out that at least one of the results of the
Tour-Benchmark should be modified/updated: the
Matrix Multiplication in Sage vs. MATLAB and Mathematica.
On my personal, quite old, with a Celeron 3Ghz, 2 core machine, 64 bits,
I get:
752 ms
which is very
On Sunday, December 30, 2012 3:05:52 AM UTC, Dima Pasechnik wrote:
GAP uses mmap to get/extend memory.
On Linux, mmap has a MAP_NORESERVE parameter which tells the kernel
whether or not to reserve the swap.
Granted, if MAP_NORESERVE is set then one can get
a segfault - but segfaults can
On 2012-12-30, Volker Braun vbraun.n...@gmail.com wrote:
--=_Part_615_22553311.1356862244107
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, December 30, 2012 3:05:52 AM UTC, Dima Pasechnik wrote:
GAP uses mmap to get/extend memory.
On Linux, mmap has a MAP_NORESERVE parameter
On Sunday, December 30, 2012 1:20:24 PM UTC, Dima Pasechnik wrote:
I think it's just the matter of setting up a fresh signal handler before
calling mmap(), and reinstating the old one after this is done.
No, if you mmap() with MAP_NORESERVE then it always succeeds (if the
processor can
On Sunday, December 30, 2012 2:13:23 AM UTC+1, Nils Bruin wrote:
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
On Dec 30, 8:03 am, Volker Braun vbraun.n...@gmail.com 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
I think it would be very useful to get more information out of a segfault
while Sage is running. To this end I've extended the crash handler
(Unhandled SIGSEGV: A segmentation fault occurred in Sage...) to attach
gdb and extract more information. With these changes you'd get Python or
Cython
On 31/12/12 10:27, Volker Braun wrote:
I think it would be very useful to get more information out of a
segfault while Sage is running. To this end I've extended the crash
handler (Unhandled SIGSEGV: A segmentation fault occurred in Sage...)
to attach gdb and extract more information. With
It starts with a bt full but then uses gdb / Python / Cython integration
to resolve the stack frames into source code. Try reading it from the
bottom up, the way you'll see it on screen after a crash.
On Sunday, December 30, 2012 9:35:40 PM UTC, François wrote:
On 31/12/12 10:27, Volker
I am trying to build sage 5.6.beta1 from source,
but mercurial does not build. (The same problem
also applies to sage 5.5) Xcode 4.5.2 is installed.
I change the PATH variable due to macports.
The following build options are used:
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin
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
Hi,
Before 5.4, tmp_filename() would return incremental file names:
sage: tmp_filename()
'/home/jaje/.sage//temp/ukko/26221//tmp_0'
sage: tmp_filename()
'/home/jaje/.sage//temp/ukko/26221//tmp_1'
sage: tmp_filename()
'/home/jaje/.sage//temp/ukko/26221//tmp_2'
But now it returns random names:
On 2012-12-30, Volker Braun vbraun.n...@gmail.com wrote:
--=_Part_795_4463763.1356883427560
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, December 30, 2012 1:20:24 PM UTC, Dima Pasechnik wrote:
I think it's just the matter of setting up a fresh signal handler before
calling
By the way, the object that is allocated in the block that eventually
gets freed twice is:
Set of Morphisms from type 'sage.modules.module.Module' to type
'sage.modules.module.Module' in Category of modules over Integer Ring
Note that the first dealloc above is part of a TripleDictEraser call,
On Dec 24, 4:44 pm, Jean-Pierre Flori jpfl...@gmail.com 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
16 matches
Mail list logo
