[sage-devel] Re: Sage 3.2.3.final released
2009/1/3 John Cremona : > Built fine and all tests pass on my 32-bit ubuntu laptop. In And also on a 64-bit Suse Linux version 2.6.18.8-0.3-default (ge...@buildhost) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #1 SMP Tue Apr 17 08:42:35 UTC 2007 John > particular, Atlas built fine and quickly for the first time ever on > this machine (at least, once I realized that setting SAGE_ATLAS_LIB to > the empty string was not the same as unsetting it). > > John > > 2009/1/3 mabshoff : >> >> >> >> On Jan 3, 6:14 am, Jaap Spies wrote: >> >> >> >> >>> On Fedora 9, 32 bits: >>> -- >>> All tests passed! >>> >>> Jaap >> >> Thanks Jaap, this is pretty much what was expected. >> >> Cheers, >> >> Michael >> >> >> > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Maxima, ECL, asksign; was: Re: reduce
mabshoff wrote: > On Jan 3, 11:27�am, Robert Dodier wrote: > > Hmm, what is "this possibility" ? I don't understand. > I meant embedding Maxima into a library extensions via ecl. You stated > to the best of my recollection that this would be troublesome due to > asksign since there would be the need on occasion by the user to > interact with the integration/limit calculation - unless I > misunderstood you :) OK, I don't remember what I might have said, probably not too important. Instead let me spell out my current thoughts about the situation. Maxima + ECL seems to work OK at this point so I guess you could indeed link in Maxima via CFFI or some other C interface. (Although there are two layers of glue here, right? Lisp -> C and C -> Python; seems like it could be messy.) asksign would presumably still interfere, but it wouldn't be any more of problem than it is now. About disabling asksign, I made an attempt to do that in a non- intrusive way, by having asksign throw an exception back to a high-level handler which could construct a conditional expression. (The code is in share/contrib/noninteractive/.) That sort of works, except that it clogs up the assume system (which eventually stops working). Also, the scheme inherits assume's weakness. So at this point I think it would be necessary to revise every call to asksign to construct a conditional expression when asksign is disabled. That would be tedious --- there are something like 100 calls to asksign or similar functions throughout the core code --- but it seems straightforward. I might try to work on that in 2009. FWIW Robert Dodier --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.3.final released
All tests passed on my 10.4 ppc (g4) mac laptop, except for calculus.py timing out as usual. -M. Hampton On Jan 3, 1:32 am, mabshoff wrote: > Hello folks, > > Sage 3.2.3.final is out, 3.2.3.rc0 was never announced on the list. > Well, technically the following happened: the first final had some > issues, so it was renamed rc0 and a new final was spun with a number > of fixes. > > Most of the fixes are stabilization and bug fixes only in nature, so > this release should be rather solid. It seems that things were rather > quiet over the last couple days, but I guess that also has its good > sides :) This release should be next to identical to 3.2.3 unless > something major pops up. The main feature in rc0/final is an upgraded > ATLAS 3.8.2 with much better Core2 support and also finally support > for Pentium E, AMD K10s as well as Intel Dunningtons. I.e. building > ATLAS on sage.math now takes 11 minutes instead of three hours. > > You can download the sources from > > http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.3/ > > or upgrade to this release via > > ./sage > -upgradehttp://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.3/sa... > > There is also a 3.2.3.rc0 sage.math only binary, so if you want a > 3.2.3.final for sage.math you should be easily able to upgrade from > that. > > Cheers, > > Michael > > Merged in Sage 3.2.3.final: > > #4870: Michael Abshoff: Sage 3.2.3: turn off FLINT test suite in the > final build [Reviewed by William Stein] > #4894: William Stein: save_session -- bug when saving %cython > functions, etc. [Reviewed by William Stein] > #4899: John Cremona: bug in sqrt(1) over GF(2^e) for e>15 [Reviewed by > William Stein] > #4929: Michael Abshoff: 3.2.3.rc0: remove sage/functions/elementary.py > from files to build in the documentation [Reviewed by Kiran Kedlaya] > #4930: Michael Abshoff: 3.2.3.rc0: Fix bug in ATLAS' spkg-install that > breaks the install target for dynamic libs [Reviewed by William Stein] > #4931: Michael Abshoff: Sage 3.2.3.final: Fix various Solaris 10 build > issues in the Sage library [Reviewed by William Stein] > > Merged in Sage 3.2.3.rc0: > > #3640: Michael Abshoff: optional spkg polymake is broken with Sage > 3.0.3/3.0.4 [Reviewed by Marshall Hampton] > #3785: Michael Abshoff: upgrade atlas in sage to version 3.8.2 > [Reviewed by William Stein] > #3787: Michael Abshoff: make ATLAS use extended cpuid [Reviewed by > William Stein] > #4862: Michael Abshoff: macaulay2 optional spkg is broken with > parallel make [Reviewed by William Stein] > #4872: William Stein: use sage_native_execute for dvipng, clean up > file handling [Reviewed by Arnaud Bergeron] > #4879: Michael Abshoff: Update FLINT to 1.0.21 (latest 1.0.x upstream) > [Reviewed by Jaap Spies] > #4882: Michael Abshoff: macaulay2 related doctest failure in sage/ > rings/polynomial/multi_polynomial_ideal.py [Reviewed by Jaap Spies] > #4885: William Stein, Mike Hansen: fix fallout from sloppy review of > #4535 [Reviewed by Mike Hansen, William Stein] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.3.final released
On Jan 2, 2009, at 23:32 , mabshoff wrote: > > Hello folks, > > Sage 3.2.3.final is out, 3.2.3.rc0 was never announced on the list. > Well, technically the following happened: the first final had some > issues, so it was renamed rc0 and a new final was spun with a number > of fixes. > > Most of the fixes are stabilization and bug fixes only in nature, so > this release should be rather solid. It seems that things were rather > quiet over the last couple days, but I guess that also has its good > sides :) This release should be next to identical to 3.2.3 unless > something major pops up. The main feature in rc0/final is an upgraded > ATLAS 3.8.2 with much better Core2 support and also finally support > for Pentium E, AMD K10s as well as Intel Dunningtons. I.e. building > ATLAS on sage.math now takes 11 minutes instead of three hours. > > You can download the sources from > > http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.3/ > > or upgrade to this release via > > ./sage -upgrade > http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.3/sage-3.2.3.final/ Built on Mac OS X, 10.5.6 (Dual Quad Xeon) and 10.4.11 (Core 2 Duo) without problems. All tests passed on both systems. Justin -- Justin C. Walker, Curmudgeon-At-Large, Director Institute for the Enhancement of the Director's Income The path of least resistance: it's not just for electricity any more. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.3.final released
On Sun, Jan 4, 2009 at 5:38 PM, Justin C. Walker wrote: > > > On Jan 2, 2009, at 23:32 , mabshoff wrote: > >> >> Hello folks, >> >> Sage 3.2.3.final is out, 3.2.3.rc0 was never announced on the list. >> Well, technically the following happened: the first final had some >> issues, so it was renamed rc0 and a new final was spun with a number >> of fixes. >> >> Most of the fixes are stabilization and bug fixes only in nature, so >> this release should be rather solid. It seems that things were rather >> quiet over the last couple days, but I guess that also has its good >> sides :) This release should be next to identical to 3.2.3 unless >> something major pops up. The main feature in rc0/final is an upgraded >> ATLAS 3.8.2 with much better Core2 support and also finally support >> for Pentium E, AMD K10s as well as Intel Dunningtons. I.e. building >> ATLAS on sage.math now takes 11 minutes instead of three hours. >> >> You can download the sources from >> >> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.3/ >> >> or upgrade to this release via >> >> ./sage -upgrade >> http://sage.math.washington.edu/home/mabshoff/release-cycles-3.2.3/sage-3.2.3.final/ > > Built on Mac OS X, 10.5.6 (Dual Quad Xeon) and 10.4.11 (Core 2 Duo) > without problems. All tests passed on both systems. I built on a CentOS 64-bit system with 1GB RAM, and a test in arith.py fails due to swapping leading to a timeout. The test in question is a *massive* performance regression, I think caused by a patch of Craig Citro. I've created a blocker ticket for this here: http://trac.sagemath.org/sage_trac/ticket/4939 I've posted a patch there, and hope somebody will review it (hint, hint: Craig.) I think this should be a blocker since it prevents doctests pass on what I view as a supported platform (namely 64-bit machines with <= 1GB RAM). William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.3.final released
On Jan 4, 6:21 pm, "William Stein" wrote: > On Sun, Jan 4, 2009 at 5:38 PM, Justin C. Walker wrote: Hi, > I built on a CentOS 64-bit system with 1GB RAM, and a test in arith.py > fails due to swapping leading to a timeout. The test in question is a > *massive* performance regression, I think caused by a patch of Craig > Citro. I've created a blocker ticket for this here: Hmm, do you mean changeset: 10906:5af5af172db9 user:Craig Citro date:Wed Nov 05 02:04:21 2008 -0800 summary: Speed up prime_range, massive arith cleanup. See trac #4443. I am under the impression that Craig added a bunch of doctests including this one, but I could be wrong. > http://trac.sagemath.org/sage_trac/ticket/4939 > > I've posted a patch there, and hope somebody will review it (hint, > hint: Craig.) :) > I think this should be a blocker since it prevents doctests pass on > what I view as a supported platform (namely 64-bit machines with <= > 1GB RAM). Yep, and I agree that we should not be using pari for this. I cannot believe that this doesn't expose a bug in pari, so if someone has 2.3.4svn or 2.4.3svn handy please check out if this is still a problem and report it upsream if that is the case. > William Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.3.final released
On Sun, Jan 4, 2009 at 6:35 PM, mabshoff wrote: > > > > On Jan 4, 6:21 pm, "William Stein" wrote: >> On Sun, Jan 4, 2009 at 5:38 PM, Justin C. Walker wrote: > > Hi, > > > >> I built on a CentOS 64-bit system with 1GB RAM, and a test in arith.py >> fails due to swapping leading to a timeout. The test in question is a >> *massive* performance regression, I think caused by a patch of Craig >> Citro. I've created a blocker ticket for this here: > > Hmm, do you mean > > changeset: 10906:5af5af172db9 > user:Craig Citro > date:Wed Nov 05 02:04:21 2008 -0800 > summary: Speed up prime_range, massive arith cleanup. See trac > #4443. > > I am under the impression that Craig added a bunch of doctests > including this one, but I could be wrong. > >> http://trac.sagemath.org/sage_trac/ticket/4939 >> >> I've posted a patch there, and hope somebody will review it (hint, >> hint: Craig.) > > :) > >> I think this should be a blocker since it prevents doctests pass on >> what I view as a supported platform (namely 64-bit machines with <= >> 1GB RAM). > > Yep, and I agree that we should not be using pari for this. I cannot > believe that this doesn't expose a bug in pari, so if someone has > 2.3.4svn or 2.4.3svn handy please check out if this is still a problem > and report it upsream if that is the case. Actually in all cases we use pari for this -- it's just that for some reason when we *don't* convert from pari back to sage, there is a massive slowdown. Yes, you read that right. It's very counterintuitive! There is more to #4939 that should be investigated. I've had some undergrad student(s) do projects on implementing a faster prime_range command not using pari, but they've never succeeded. I wish somebody would do this right at some point, e.g., using something like the Sieve of Atkin. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.3.final released
On Fri, Jan 2, 2009 at 11:32 PM, mabshoff wrote:
>
> Hello folks,
>
> Sage 3.2.3.final is out, 3.2.3.rc0 was never announced on the list.
> Well, technically the following happened: the first final had some
> issues, so it was renamed rc0 and a new final was spun with a number
> of fixes.
>
> Most of the fixes are stabilization and bug fixes only in nature, so
> this release should be rather solid. It seems that things were rather
> quiet over the last couple days, but I guess that also has its good
> sides :) This release should be next to identical to 3.2.3 unless
> something major pops up.
Your ticket #4934 segfault:
http://trac.sagemath.org/sage_trac/ticket/4934
which you were just seeing on cicero is popping up for me on several test
os's on several compilers.
I'm getting exactly this test failure in "make check" on debian 32 and
64-bit vanilla (with gcc-4.1.2) under vmware with 1GB RAM and also the
same failure on 32-bit Ubuntu 1GB RAM (with gcc-4.3.2):
sage -t "devel/sage/sage/matrix/matrix1.pyx"
A mysterious error (perphaps a memory error?) occurred, which may have
crashed doctest.
[4.3 s]
If I do --verbose I get:
Trying:
a._mathematica_init_()###line 171:_sage_>>> a._mathematica_init_()
Expecting:
'{{Pi, Sin[x]}, {Cos[x], (E) ^ (-1)}}'
ok
Unhandled SIGSEGV: A segmentation fault occured in SAGE.
This probably occured because a *compiled* component
of SAGE has a bug in it (typically accessing invalid memory)
or is not properly wrapped with _sig_on, _sig_off.
You might want to run SAGE under gdb with 'sage -gdb' to debug this.
SAGE will now terminate (sorry).
[4.9 s]
exit code: 1024
Under gdb, I get:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7d5c8c0 (LWP 19059)]
0xb2d53673 in
__pyx_tp_dealloc_4sage_6matrix_21matrix_symbolic_dense_Matrix_symbolic_dense
(o=0xb57a65c) at sage/matrix/matrix_symbolic_dense.c:6535
6535 Py_XDECREF(p->__variables);
(gdb) bt
#0 0xb2d53673 in
__pyx_tp_dealloc_4sage_6matrix_21matrix_symbolic_dense_Matrix_symbolic_dense
(o=0xb57a65c) at sage/matrix/matrix_symbolic_dense.c:6535
#1 0x0808a1fc in PyDict_Clear (op=0xb3e713c) at Objects/dictobject.c:757
...
I'm going to look into this for a few minutes...
William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.3.final released
On Sun, Jan 4, 2009 at 9:01 PM, William Stein wrote:
> On Fri, Jan 2, 2009 at 11:32 PM, mabshoff wrote:
>>
>> Hello folks,
>>
>> Sage 3.2.3.final is out, 3.2.3.rc0 was never announced on the list.
>> Well, technically the following happened: the first final had some
>> issues, so it was renamed rc0 and a new final was spun with a number
>> of fixes.
>>
>> Most of the fixes are stabilization and bug fixes only in nature, so
>> this release should be rather solid. It seems that things were rather
>> quiet over the last couple days, but I guess that also has its good
>> sides :) This release should be next to identical to 3.2.3 unless
>> something major pops up.
>
> Your ticket #4934 segfault:
>
> http://trac.sagemath.org/sage_trac/ticket/4934
>
> which you were just seeing on cicero is popping up for me on several test
> os's on several compilers.
>
> I'm getting exactly this test failure in "make check" on debian 32 and
> 64-bit vanilla (with gcc-4.1.2) under vmware with 1GB RAM and also the
> same failure on 32-bit Ubuntu 1GB RAM (with gcc-4.3.2):
>
> sage -t "devel/sage/sage/matrix/matrix1.pyx"
> A mysterious error (perphaps a memory error?) occurred, which may have
> crashed doctest.
> [4.3 s]
>
> If I do --verbose I get:
>
> Trying:
>a._mathematica_init_()###line 171:_sage_>>> a._mathematica_init_()
> Expecting:
>'{{Pi, Sin[x]}, {Cos[x], (E) ^ (-1)}}'
> ok
>
> Unhandled SIGSEGV: A segmentation fault occured in SAGE.
> This probably occured because a *compiled* component
> of SAGE has a bug in it (typically accessing invalid memory)
> or is not properly wrapped with _sig_on, _sig_off.
> You might want to run SAGE under gdb with 'sage -gdb' to debug this.
> SAGE will now terminate (sorry).
>
> [4.9 s]
> exit code: 1024
>
>
>
> Under gdb, I get:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb7d5c8c0 (LWP 19059)]
> 0xb2d53673 in
> __pyx_tp_dealloc_4sage_6matrix_21matrix_symbolic_dense_Matrix_symbolic_dense
> (o=0xb57a65c) at sage/matrix/matrix_symbolic_dense.c:6535
> 6535 Py_XDECREF(p->__variables);
> (gdb) bt
> #0 0xb2d53673 in
> __pyx_tp_dealloc_4sage_6matrix_21matrix_symbolic_dense_Matrix_symbolic_dense
> (o=0xb57a65c) at sage/matrix/matrix_symbolic_dense.c:6535
> #1 0x0808a1fc in PyDict_Clear (op=0xb3e713c) at Objects/dictobject.c:757
> ...
>
>
>
>
> I'm going to look into this for a few minutes...
OK, I found a temporary workaround. See the patch at #4934.
It would also be very nice if we could also fix the openSUSE build
bug, since I think you said you know how (Michael Abshoff). I noticed
that on both my 32 and 64-bit opensuse build machines,
/bin/sh: symbol lookup error:
/home/wstein/build/opensuse64/build/sage-3.2.3.final/local/lib/libreadline.so.5:
undefined symbol: PC
real0m0.004s
user0m0.000s
sys 0m0.004s
sage: An error occurred while installing pari-2.3.3.p0
...
sh: symbol lookup error:
/home/wstein/build/opensuse64/build/sage-3.2.3.final/local/lib/libreadline.so.5:
undefined symbol: PC
make: *** [check] Error 127
wst...@opensuse64:~/build/opensuse64/build/sage-3.2.3.final$
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.3.final released
On Jan 4, 9:01 pm, "William Stein" wrote:
> On Fri, Jan 2, 2009 at 11:32 PM, mabshoff wrote:
> Your ticket #4934 segfault:
>
> http://trac.sagemath.org/sage_trac/ticket/4934
>
> which you were just seeing on cicero is popping up for me on several test
> os's on several compilers.
Ok.
> I'm getting exactly this test failure in "make check" on debian 32 and
> 64-bit vanilla (with gcc-4.1.2) under vmware with 1GB RAM and also the
> same failure on 32-bit Ubuntu 1GB RAM (with gcc-4.3.2):
>
> sage -t "devel/sage/sage/matrix/matrix1.pyx"
> A mysterious error (perphaps a memory error?) occurred, which may have
> crashed doctest.
> [4.3 s]
>
> If I do --verbose I get:
>
> Trying:
> a._mathematica_init_()###line 171:_sage_ >>> a._mathematica_init_()
> Expecting:
> '{{Pi, Sin[x]}, {Cos[x], (E) ^ (-1)}}'
> ok
>
> Unhandled SIGSEGV: A segmentation fault occured in SAGE.
> This probably occured because a *compiled* component
> of SAGE has a bug in it (typically accessing invalid memory)
> or is not properly wrapped with _sig_on, _sig_off.
> You might want to run SAGE under gdb with 'sage -gdb' to debug this.
> SAGE will now terminate (sorry).
>
> [4.9 s]
> exit code: 1024
>
>
>
> Under gdb, I get:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb7d5c8c0 (LWP 19059)]
> 0xb2d53673 in
> __pyx_tp_dealloc_4sage_6matrix_21matrix_symbolic_dense_Matrix_symbolic_dens e
> (o=0xb57a65c) at sage/matrix/matrix_symbolic_dense.c:6535
> 6535 Py_XDECREF(p->__variables);
> (gdb) bt
> #0 0xb2d53673 in
> __pyx_tp_dealloc_4sage_6matrix_21matrix_symbolic_dense_Matrix_symbolic_dens e
> (o=0xb57a65c) at sage/matrix/matrix_symbolic_dense.c:6535
> #1 0x0808a1fc in PyDict_Clear (op=0xb3e713c) at Objects/dictobject.c:757
> ...
That is identical to what I get. If you follow the path you will
likely come to the same conclusion I did, i.e. somehow the Maxima
instance is getting decrefed.
>
>
> I'm going to look into this for a few minutes...
Cool. The dirty fix is to disable that doctest for now. If I ran the
last doctest by itself it passed, running the whole doctest crashed
valgrind 3.3.1. There is brand spanking new 3.4 release I have been
playing with for most of the day, but I haven't tried it. IIRC the
doctest valgrinds clean on sage.math.
>From http://www.python.org/download/releases/2.5.3/NEWS.txt
- Issue #3100: Corrected a crash on deallocation of a subclassed
weakref which
holds the last (strong) reference to its referent.
The above issue could be partially responsible for what we are seeing,
but given the number of times making something no longer weekly
referenced fixing mysterious errors I could see this being involved in
some cases.
> William
Cheers,
Michael
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.3.final released
On Sun, Jan 4, 2009 at 9:17 PM, mabshoff wrote: > Cool. The dirty fix is to disable that doctest for now. If I ran the That is very dirty indeed. I think I prefer at least the hack I've posted to the ticket, which is to make the variable public. > last doctest by itself it passed, running the whole doctest crashed > valgrind 3.3.1. There is brand spanking new 3.4 release I have been > playing with for most of the day, but I haven't tried it. IIRC the > doctest valgrinds clean on sage.math. > > From http://www.python.org/download/releases/2.5.3/NEWS.txt > > - Issue #3100: Corrected a crash on deallocation of a subclassed > weakref which > holds the last (strong) reference to its referent. > > The above issue could be partially responsible for what we are seeing, > but given the number of times making something no longer weekly > referenced fixing mysterious errors I could see this being involved in > some cases. Yes, I claimed a possible bug in Cython a few times on the ticket, but you're right, this could be an issue with Python. In any case, that changing the variable to be public makes the problem go away must be a hint. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.3.final released
On Jan 4, 9:15 pm, "William Stein" wrote: > On Sun, Jan 4, 2009 at 9:01 PM, William Stein wrote: > OK, I found a temporary workaround. See the patch at #4934. Ok, I will take a look. > It would also be very nice if we could also fix the openSUSE build > bug, since I think you said you know how (Michael Abshoff). I noticed > that on both my 32 and 64-bit opensuse build machines, Yes, I am not 100% happy with the workaround. There are three scenarios: (a) bash is linked statically against libreadline - we are in the clear, no trouble (b) bash is dynamically linked against some oddly patched readline and dev packages, i.e. headlers are installed - copy over headers and lib and be done (c) bash is dynamically linked against some oddly patched readline and no dev packages are installed - build readline, overwrite libreadline.so with the system one (c) is dirty and can cause trouble down the road, i.e. mysterious segfaults. And this is also the default setup for OpenSUSE 11.1. I have an spkg that does (a) and (c), but not (b) yet, so if at all possible I would want to wait for 3.3 to sort this out. One alternative fix would be to build bash from sources and link it statically all the way, but that has its own set of shortcomings. On the other hand it would spare us the often system bash, so I can see the good here, but this is longer term. Another alternative would be to build termcap or curses before readline, but I am not 100% sure how the bash.rpm on OpenSUSE is build to nail the problem down. Thoughts? Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.3.final released
On Sun, Jan 4, 2009 at 9:24 PM, mabshoff wrote: > > > > On Jan 4, 9:15 pm, "William Stein" wrote: >> On Sun, Jan 4, 2009 at 9:01 PM, William Stein wrote: > > > >> OK, I found a temporary workaround. See the patch at #4934. > > Ok, I will take a look. > >> It would also be very nice if we could also fix the openSUSE build >> bug, since I think you said you know how (Michael Abshoff). I noticed >> that on both my 32 and 64-bit opensuse build machines, > > Yes, I am not 100% happy with the workaround. There are three > scenarios: > > (a) bash is linked statically against libreadline - we are in the > clear, no trouble > (b) bash is dynamically linked against some oddly patched readline > and dev packages, i.e. headlers are installed - copy over headers and > lib and be done > (c) bash is dynamically linked against some oddly patched readline > and no dev packages are installed - build readline, overwrite > libreadline.so with the system one > > (c) is dirty and can cause trouble down the road, i.e. mysterious > segfaults. And this is also the default setup for OpenSUSE 11.1. I > have an spkg that does (a) and (c), but not (b) yet, so if at all > possible I would want to wait for 3.3 to sort this out. > > One alternative fix would be to build bash from sources and link it > statically all the way, but that has its own set of shortcomings. On > the other hand it would spare us the often system bash, so I can see > the good here, but this is longer term. > > Another alternative would be to build termcap or curses before > readline, but I am not 100% sure how the bash.rpm on OpenSUSE is build > to nail the problem down. > > Thoughts? What about if we just don't install a shared readline at all? That seems way safer to me than overwriting it with the system readline. In the spkg-install for readline, if the OS is OpenSuse, we just do $RM -f $SAGE_LOCAL/lib/libreadline.so* I.e., for Sage we build only the static readline. Can't Python, Gap, PARI, etc. just link in a static readline? I'm testing this right now, and PARI appears to statically link in $SAGE_ROOT/local/lib/libreadline.a just fine. So please think cynically of what could possibly go wrong with my suggestion, which is similar to yours, but maybe (?) cleaner. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.3.final released
On Jan 4, 10:39 pm, "William Stein" wrote: > On Sun, Jan 4, 2009 at 9:24 PM, mabshoff wrote: > What about if we just don't install a shared readline at all? That > seems way safer to me than overwriting it with the system readline. > In the spkg-install for readline, if the OS is OpenSuse, we just do > $RM -f $SAGE_LOCAL/lib/libreadline.so* > > I.e., for Sage we build only the static readline. Can't Python, Gap, > PARI, etc. just link in a static readline? Well, I tried that and I ended up with a Python without readline support and Singular failed to build at all without it. These were strange failures to say the least. clisp also has trouble IIRC. > I'm testing this right > now, and PARI appears to statically link in > > $SAGE_ROOT/local/lib/libreadline.a > > just fine. > > So please think cynically of what could possibly go wrong with my > suggestion, which is similar to yours, but maybe (?) cleaner. I don' think it will work - it didn't on my OpenSUSE 11.1 install :). Other than that if we get it to work I would be fine with that solution since we so rarely update readline that it won't matter if we link static or dynamic libs in this case. > -- William Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.2.3.final released
On Sun, Jan 4, 2009 at 10:52 PM, mabshoff wrote: > > > > On Jan 4, 10:39 pm, "William Stein" wrote: >> On Sun, Jan 4, 2009 at 9:24 PM, mabshoff wrote: > > > >> What about if we just don't install a shared readline at all? That >> seems way safer to me than overwriting it with the system readline. >> In the spkg-install for readline, if the OS is OpenSuse, we just do >> $RM -f $SAGE_LOCAL/lib/libreadline.so* >> >> I.e., for Sage we build only the static readline. Can't Python, Gap, >> PARI, etc. just link in a static readline? > > Well, I tried that and I ended up with a Python without readline > support and Singular failed to build at all without it. These were That makes sense. OK, so that won't work. > Other than that if we get it to work I would be fine with that > solution since we so rarely update readline that it won't matter if we > link static or dynamic libs in this case. Here's another suggestion. Did you try this? Just use the system-wide readline with the system-wide devel library, and we don't build ours at all in the case of opensuse. We could make the build terminate at the start if readline isn't available on opensuse, and document this requirement in the README as well. Well, my question is first: does this work? -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
