[sage-devel] Re: cannot build 2.8.4 on sage.math
Well, good news. I can tell you exactly what is causing the problem, and there are two easy ways to fix it. Here's what's going on: c_lib/ ntl_wrap.os is getting shipped with sage-2.8.4.tar, and that file was compiled with a compiler that includes the gnu stack-checking stuff (what they were talking about in the google article you found). Since that file exists, scons doesn't rebuild it when we do scons install, so it gets linked against into libcsage.so, which then gets put into $SAGE_ROOT/local/lib, and causes all your headache. You can even see this: do nm ntl_wrap.os | grep stack and you'll see the symbol there. So, your fix is easy: cd c_lib ; rm -f ntl_wrap.os ; scons install ... that will fix you up. There are two steps we're going to take to fix this. First, we'll make sure to remove the .os files in the sage-*.tar we distribute from now on, which will stop this from happening. Also, as a second check, I'm going to make sure that the sage install does something to remove those files on install, since there's no reason not to (if nothing else, simply to avoid annoying things like this). There's even a trac ticket, #626. I'm going to fix up the sage install process right now, and post a patch. I want to point out that this is probably the third or fourth weird build problem we've had with switching to scons, and even given all that, I still strongly support using scons, because I think it's worth it in the long run. I haven't used it too much (just for this, actually), but I've been very happy with it, and I think it's better for us than make. There are just some growing pains to be dealt with. ;) -cc On Sep 8, 2007, at 10:05 AM, David Harvey wrote: > > > On Sep 8, 2007, at 1:03 PM, mabshoff wrote: > >> Ok, I get loads of test failures on sage.math complaining about >> "__stack_chk_fail". That is gmp related. I am looking trying to use >> the old p9 gmp package and see what will happen then. > > Great, so it's not just me then. I was really starting to go nuts. > > david > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Sage 2.8.4 port to PPC Linux 32 bit 99.9% done
Hello, 2.8.4 + the integer doc + 1 line fix to pari's build system leads to: [EMAIL PROTECTED] sage-2.8.4]$ uname -a Linux localhost.localdomain 2.6.21-1.3194.fc7 #1 Wed May 23 22:12:25 EDT 2007 ppc ppc ppc GNU/Linux [EMAIL PROTECTED] sage-2.8.4]$ ./sage -- | SAGE Version 2.8.4, Release Date: 2007-09-07 | | Type notebook() for the GUI, and license() for information.| -- sage: Exiting SAGE (CPU time 0m0.01s, Wall time 0m3.58s). I will post the patch for pari tomorrow. All the doctests pass, expect some trivial DSage issues: sage.dsage.twisted.tests.test_remote ClientRemoteCallsTest testremoteSubmitBadJob ... [OK] testremoteSubmitJob ... [OK] MonitorRemoteCallsTest testget_killed_jobs_list ... [ERROR] [ERROR] testremote_get_job ... [ERROR] [ERROR] testremote_job_done ... [ERROR] [ERROR] testremote_job_failed ... [ERROR] [ERROR] === [ERROR]: sage.dsage.twisted.tests.test_remote.MonitorRemoteCallsTest.testget_killed_jobs_list Traceback from remote host -- Traceback unavailable === [ERROR]: sage.dsage.twisted.tests.test_remote.MonitorRemoteCallsTest.testget_killed_jobs_list Traceback (most recent call last): File "/tmp/Work/sage-2.8.4/local/lib/python2.5/site-packages/sage/ dsage/twisted/pb.py", line 412, in requestAvatar avatar.attached(avatar, mind) File "/tmp/Work/sage-2.8.4/local/lib/python2.5/site-packages/sage/ dsage/twisted/pb.py", line 258, in attached self.DSageServer.monitordb.add_monitor(self.host_info) File "/tmp/Work/sage-2.8.4/local/lib/python2.5/site-packages/sage/ dsage/database/monitordb.py", line 120, in add_monitor cpu_speed = host_info['cpu_speed'] exceptions.KeyError: 'cpu_speed' === [ERROR]: sage.dsage.twisted.tests.test_remote.MonitorRemoteCallsTest.testremote_get_job Traceback from remote host -- Traceback unavailable === [ERROR]: sage.dsage.twisted.tests.test_remote.MonitorRemoteCallsTest.testremote_get_job Traceback (most recent call last): File "/tmp/Work/sage-2.8.4/local/lib/python2.5/site-packages/sage/ dsage/twisted/pb.py", line 412, in requestAvatar avatar.attached(avatar, mind) File "/tmp/Work/sage-2.8.4/local/lib/python2.5/site-packages/sage/ dsage/twisted/pb.py", line 258, in attached self.DSageServer.monitordb.add_monitor(self.host_info) File "/tmp/Work/sage-2.8.4/local/lib/python2.5/site-packages/sage/ dsage/database/monitordb.py", line 120, in add_monitor cpu_speed = host_info['cpu_speed'] exceptions.KeyError: 'cpu_speed' === [ERROR]: sage.dsage.twisted.tests.test_remote.MonitorRemoteCallsTest.testremote_job_done Traceback from remote host -- Traceback unavailable === [ERROR]: sage.dsage.twisted.tests.test_remote.MonitorRemoteCallsTest.testremote_job_done Traceback (most recent call last): File "/tmp/Work/sage-2.8.4/local/lib/python2.5/site-packages/sage/ dsage/twisted/pb.py", line 412, in requestAvatar avatar.attached(avatar, mind) File "/tmp/Work/sage-2.8.4/local/lib/python2.5/site-packages/sage/ dsage/twisted/pb.py", line 258, in attached self.DSageServer.monitordb.add_monitor(self.host_info) File "/tmp/Work/sage-2.8.4/local/lib/python2.5/site-packages/sage/ dsage/database/monitordb.py", line 120, in add_monitor cpu_speed = host_info['cpu_speed'] exceptions.KeyError: 'cpu_speed' === [ERROR]: sage.dsage.twisted.tests.test_remote.MonitorRemoteCallsTest.testremote_job_failed Traceback from remote host -- Traceback unavailable === [ERROR]: sage.dsage.twisted.tests.test_remote.MonitorRemoteCallsTest.testremote_job_failed Traceback (most recent call last): File "/tmp/Work/sage-2.8.4/local/lib/python2.5/site-packages/sage/ dsage/twisted/pb.py", line 412, in requestAvatar avatar.attached(avatar, mind) File "/tmp/Work/sage-2.8.4/local/lib/python2.5/site-packages/sage/ dsage/twisted/pb.py", line 258, in attached self.DSageServer.monitordb.add_monitor(self.host_info) File "/tmp/Work/sage-2.8.4/local/lib/python2.5/site-packages/sage/ dsage/database/monitordb.py", line 120, in add_monitor cpu_speed = host_info['cpu_speed'] exceptions.KeyError: 'cpu_speed' --
[sage-devel] Re: cannot build 2.8.4 on sage.math
On Sep 9, 3:10 am, mabshoff <[EMAIL PROTECTED] dortmund.de> wrote: > On Sep 9, 2:40 am, "Joel B. Mohler" <[EMAIL PROTECTED]> wrote: > > > On Saturday 08 September 2007 17:49, mabshoff wrote: > > > > Executive Summary: SCons somehow gets its LD_LIBRARY_PATH or env in > > > general wrong and ends up linking against the gmp 4.2.1 provided by > > > Debian. Somehow the compiler gets it all wrong and *boom* > > > > How to fix: Fix SCons *ducks* - a short term solution seems to be to > > > source local/sage/env before building sage-2.8.4.spkg. > > Hello Joel, > > > This confuses me. > > Oh, me too. > > > How is source'ing local/sage/env any different from what > > normally happens? > > Are you saying that in a "source blah" vs "./blah" way or more meta/ > abstract? > > > Isn't that always source'd once you get into the internals > > of sage batch files? > > I don't know. > > > So, I thought I could answer that question myself: In local/bin/sage-build > > we > > call local/bin/sage-env with-out source, but inside of local/bin/sage-env, > > we > > say you must: """ > > # You must source this; see below! > > """ > > Thus, I'm thinking that line 45 of sage-build needs 'source ' at the front, > > but I'm too close to my bed-time to actually go test that myself. > > I did that, started a build and will see in the morning - or in about > 90 minutes depending if I stay motivated that long and will let you > know. > Sorry, but that didn't work. I am out of ideas for the night. Let's hope somebody else can pick it up from here. Cheers, Michael > > I believe that autoconf might have not cared so much about things like this > > because the --prefix option got set which essentially rewrote the > > environment > > on it's own. > > Well, SCons is without a doubt better than autohell, we just have to > get through the teething phase until we are good to go. > > > -- > > Joel > > Cheers, > > Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: cannot build 2.8.4 on sage.math
On Sep 9, 2:40 am, "Joel B. Mohler" <[EMAIL PROTECTED]> wrote: > On Saturday 08 September 2007 17:49, mabshoff wrote: > > > Executive Summary: SCons somehow gets its LD_LIBRARY_PATH or env in > > general wrong and ends up linking against the gmp 4.2.1 provided by > > Debian. Somehow the compiler gets it all wrong and *boom* > > > How to fix: Fix SCons *ducks* - a short term solution seems to be to > > source local/sage/env before building sage-2.8.4.spkg. > Hello Joel, > This confuses me. Oh, me too. > How is source'ing local/sage/env any different from what > normally happens? Are you saying that in a "source blah" vs "./blah" way or more meta/ abstract? > Isn't that always source'd once you get into the internals > of sage batch files? > I don't know. > So, I thought I could answer that question myself: In local/bin/sage-build we > call local/bin/sage-env with-out source, but inside of local/bin/sage-env, we > say you must: """ > # You must source this; see below! > """ > Thus, I'm thinking that line 45 of sage-build needs 'source ' at the front, > but I'm too close to my bed-time to actually go test that myself. > I did that, started a build and will see in the morning - or in about 90 minutes depending if I stay motivated that long and will let you know. > I believe that autoconf might have not cared so much about things like this > because the --prefix option got set which essentially rewrote the environment > on it's own. > Well, SCons is without a doubt better than autohell, we just have to get through the teething phase until we are good to go. > -- > Joel Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: cannot build 2.8.4 on sage.math
On Saturday 08 September 2007 17:49, mabshoff wrote: > Executive Summary: SCons somehow gets its LD_LIBRARY_PATH or env in > general wrong and ends up linking against the gmp 4.2.1 provided by > Debian. Somehow the compiler gets it all wrong and *boom* > > How to fix: Fix SCons *ducks* - a short term solution seems to be to > source local/sage/env before building sage-2.8.4.spkg. This confuses me. How is source'ing local/sage/env any different from what normally happens? Isn't that always source'd once you get into the internals of sage batch files? So, I thought I could answer that question myself: In local/bin/sage-build we call local/bin/sage-env with-out source, but inside of local/bin/sage-env, we say you must: """ # You must source this; see below! """ Thus, I'm thinking that line 45 of sage-build needs 'source ' at the front, but I'm too close to my bed-time to actually go test that myself. I believe that autoconf might have not cared so much about things like this because the --prefix option got set which essentially rewrote the environment on it's own. -- Joel --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Python bindings for Ginac
One more comment: I see that this project is not actively maintained, in fact in its e-mail list the last e-mail is from 2005... On 9/8/07, Pablo De Napoli <[EMAIL PROTECTED]> wrote: > The idea of incorporating Ginac into Sage was discussed some time ago > in this list. > Now I see that in its page there is a link to some python bindings for Ginac > > http://pyginac.sourceforge.net/ > > This could be useful for us, however they use boost rather than cython/pyrex > > Pablo > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Python bindings for Ginac
> The idea of incorporating Ginac into Sage was discussed some time ago > in this list. > Now I see that in its page there is a link to some python bindings for Ginac > > http://pyginac.sourceforge.net/ > > This could be useful for us, however they use boost rather than cython/pyrex You can also use swiginac, that I wrote together with Ola Skavhaug: http://swiginac.berlios.de/ It's using SWIG, instead of boost-python, that I find very cumbersome to use. But I am not working on it anymore, since it's difficult to extend ginac with new features and I started SymPy instead. But I think Ola is still using it. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Python bindings for Ginac
The idea of incorporating Ginac into Sage was discussed some time ago in this list. Now I see that in its page there is a link to some python bindings for Ginac http://pyginac.sourceforge.net/ This could be useful for us, however they use boost rather than cython/pyrex Pablo --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: cannot build 2.8.4 on sage.math
Why does Sage 2.8.4 crash on sage.math? Executive Summary: SCons somehow gets its LD_LIBRARY_PATH or env in general wrong and ends up linking against the gmp 4.2.1 provided by Debian. Somehow the compiler gets it all wrong and *boom* How to fix: Fix SCons *ducks* - a short term solution seems to be to source local/sage/env before building sage-2.8.4.spkg. The detailed story: untar sage 2.8.4, make, wait a while. Then: [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.4-2$ ldd local/lib/ libcsage.so libntl.so => not found libgmp.so.3 => /usr/lib/libgmp.so.3 (0x2abf99d8d000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2abf99ecb000) libm.so.6 => /lib/libm.so.6 (0x2abf9a0c9000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2abf9a24c000) libc.so.6 => /lib/libc.so.6 (0x2abf9a359000) /lib64/ld-linux-x86-64.so.2 (0x4000) That doesn't look good. start Sage: *boom* [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.4-2$ ./sage -- | SAGE Version 2.8.4, Release Date: 2007-09-07 | | Type notebook() for the GUI, and license() for information.| -- --- Traceback (most recent call last) /tmp/Work-mabshoff/sage-2.8.4-2/local/bin/ in () /tmp/Work-mabshoff/sage-2.8.4-2/local/lib/python2.5/site-packages/sage/ misc/preparser_ipython.py in () 6 ### 7 > 8 import sage.misc.interpreter 9 10 import preparser /tmp/Work-mabshoff/sage-2.8.4-2/local/lib/python2.5/site-packages/sage/ plot/all.py in () 2 text, circle, disk, hue, graphics_array, 3 list_plot, networkx_plot, parametric_plot, 4 polar_plot, contour_plot, arrow, 5 plot_vector_field, matrix_plot, bar_chart, 6 is_Graphics, /tmp/Work-mabshoff/sage-2.8.4-2/local/lib/python2.5/site-packages/sage/ plot/plot.py in () 126 127 --> 128 from sage.structure.sage_object import SageObject 129 130 ## IMPORTANT: Do *not* import matplotlib at module scope. It takes a : /tmp/Work-mabshoff/sage-2.8.4-2/local/ lib/libcsage.so: undefined symbol: __stack_chk_fail source local/bin/sage-env - Now it looks a little better: [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.4-2$ source local/bin/sage- env [EMAIL PROTECTED]:/tmp/Work-mabshoff/sage-2.8.4-2$ ldd local/lib/ libcsage.so libntl.so => /tmp/Work-mabshoff/sage-2.8.4-2/local/lib/ libntl.so (0x2b67db845000) libgmp.so.3 => /tmp/Work-mabshoff/sage-2.8.4-2/local/lib/ libgmp.so.3 (0x2b67dbb0c000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2b67dbc5f000) libm.so.6 => /lib/libm.so.6 (0x2b67dbe5d000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2b67dbfe) libc.so.6 => /lib/libc.so.6 (0x2b67dc0ed000) /lib64/ld-linux-x86-64.so.2 (0x4000) But still: : /tmp/Work-mabshoff/sage-2.8.4-2/local/ lib/libcsage.so: undefined symbol: __stack_chk_fail Now [having sourced local/bin/sage-env]: ./sage -ba [drink a couple of gin tonics/cups of coffee/tea ... whatever] running install_scripts changing mode of /tmp/Work-mabshoff/sage-2.8.4-2/local/bin/ dsage_server.py to 755 changing mode of /tmp/Work-mabshoff/sage-2.8.4-2/local/bin/ dsage_worker.py to 755 changing mode of /tmp/Work-mabshoff/sage-2.8.4-2/local/bin/ dsage_setup.py to 755 running install_egg_info Removing /tmp/Work-mabshoff/sage-2.8.4-2/local/lib/python2.5/site- packages/sage-0.0.0-py2.5.egg-info Writing /tmp/Work-mabshoff/sage-2.8.4-2/local/lib/python2.5/site- packages/sage-0.0.0-py2.5.egg-info -- | SAGE Version 2.8.4, Release Date: 2007-09-07 | | Type notebook() for the GUI, and license() for information.| -- sage: Exiting SAGE (CPU time 0m0.00s, Wall time 0m4.86s). If anybody wants to make a proper patch, open a ticket and send a patch to William please do so. I gotta get back to fixing "Conditional jump or move depends on uninitialised value(s)" in LinBox :) Thank you, come again. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: cannot build 2.8.4 on sage.math
On Sep 8, 7:05 pm, David Harvey <[EMAIL PROTECTED]> wrote: > On Sep 8, 2007, at 1:03 PM, mabshoff wrote: > Hey David, > > Ok, I get loads of test failures on sage.math complaining about > > "__stack_chk_fail". That is gmp related. I am looking trying to use > > the old p9 gmp package and see what will happen then. > > Great, so it's not just me then. I was really starting to go nuts. > :) - I did install gmp-4.2.1p9, did a "sage -ba" a now I no longer see the problem about "__stack_chk_fail". Some doctest fail, but that is to be expected because the we get different but correct output for various gmp related functions like crt. Now the interesting question: Why does the new spkg fail on sage.math? We did test it on many, many systems. Oh well. I will run "make check" on both spkgs and see if anything pops up. > david Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: cannot build 2.8.4 on sage.math
On Sep 8, 2007, at 1:03 PM, mabshoff wrote: > Ok, I get loads of test failures on sage.math complaining about > "__stack_chk_fail". That is gmp related. I am looking trying to use > the old p9 gmp package and see what will happen then. Great, so it's not just me then. I was really starting to go nuts. david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: cannot build 2.8.4 on sage.math
On Sep 8, 6:38 pm, Craig Citro <[EMAIL PROTECTED]> wrote: > Yeah, that doesn't sound like fun. Try the following from your sage- > main directory: cd c_lib ; rm -f libcsage.* ; scons install. You > should see scons rebuild the libcsage.so and then copy it to your > $SAGE_ROOT/local/lib ... let me know if that works. > > If it does, we might just need to be more adamant about how the c_lib > build happens on install, because it sounds like your c_lib isn't > getting rebuilt (i.e. your $SAGE_ROOT/local/lib/libcsage.so is bunk). > In fact, I can see this being pretty likely -- it could be the same > problem I was having when I switched branches, and I just need to > make sure the same thing is happening when you do an install. This > shouldn't be too bad, and it'll save you from having to pull out any > more hair. ;) > > If *not*, it means there's actually a problem with the libcsage.so > that's getting built, which is bad. This will require more thought. > > I'll be gone most of the day, but I'll read your reply when I get > back and make a fix if it's the first one. > > -cc > > On Sep 8, 2007, at 7:44 AM, David Harvey wrote: > > > Ok, I get loads of test failures on sage.math complaining about "__stack_chk_fail". That is gmp related. I am looking trying to use the old p9 gmp package and see what will happen then. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Some observations on #619
Executive summary for ticket #619: Matrix_integer_dense__zero_out_matrix does not leak. But there must be operations on dense matricies that do not properly deallocate elements that were allocated in Matrix_integer_dense__zero_out_matrix, so vagrind claims rightfully that those entries are leaked. Another interesting tidbit: A=matrix(ZZ,1000,1000,0) B=A.copy() leads to: ==31604== 8,000,000 bytes in 1,000,000 blocks are still reachable in loss record 1,975 of 1,979 ==31604==at 0x4A05A66: malloc (vg_replace_malloc.c:207) ==31604==by 0x95A4C17: __gmpz_init (in /tmp/Work2/sage-2.8.3.6- clean/local/lib/libgmp.so.3.4.1) ==31604==by 0x205E840F: __pyx_f_20matrix_integer_dense_20Matrix_integer_dense__zero_out_matrix (matrix_integer_dense.c:4 649) ==31604==by 0x206161E4: __pyx_f_20matrix_integer_dense_20Matrix_integer_dense___init__ (matrix_integer_dense.c:3769) ==31604==by 0x45A321: type_call (typeobject.c:436) ==31604==by 0x4156A2: PyObject_Call (abstract.c:1860) ==31604==by 0x480783: PyEval_EvalFrameEx (ceval.c:3775) ==31604==by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604==by 0x4845B3: PyEval_EvalFrameEx (ceval.c:3660) ==31604==by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604==by 0x4CFF37: function_call (funcobject.c:517) ==31604==by 0x4156A2: PyObject_Call (abstract.c:1860) ==31604== ==31604== ==31604== 8,000,000 bytes in 1,000,000 blocks are still reachable in loss record 1,976 of 1,979 ==31604==at 0x4A05A66: malloc (vg_replace_malloc.c:207) ==31604==by 0x95A5BE0: __gmpz_init_set (in /tmp/Work2/sage-2.8.3.6- clean/local/lib/libgmp.so.3.4.1) ==31604==by 0x20605951: __pyx_f_20matrix_integer_dense_20Matrix_integer_dense___copy__ (matrix_integer_dense.c:3223) ==31604==by 0x4156A2: PyObject_Call (abstract.c:1860) ==31604==by 0x47DB71: PyEval_CallObjectWithKeywords (ceval.c:3433) ==31604==by 0x1E12C45C: __pyx_f_7matrix0_6Matrix_copy (matrix0.c: 845) ==31604==by 0x485B9B: PyEval_EvalFrameEx (ceval.c:3548) ==31604==by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604==by 0x485BDF: PyEval_EvalFrameEx (ceval.c:494) ==31604==by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604==by 0x4845B3: PyEval_EvalFrameEx (ceval.c:3660) ==31604==by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604== ==31604== 16,000,000 bytes in 1 blocks are still reachable in loss record 1,977 of 1,979 ==31604==at 0x4A05A66: malloc (vg_replace_malloc.c:207) ==31604==by 0x205E9766: __pyx_f_20matrix_integer_dense_20Matrix_integer_dense___new__ (matrix_integer_dense.c:2966) ==31604==by 0x205E9BE0: __pyx_tp_new_20matrix_integer_dense_Matrix_integer_dense (matrix_integer_dense.c:17692) ==31604==by 0x45A90A: tp_new_wrapper (typeobject.c:4022) ==31604==by 0x4156A2: PyObject_Call (abstract.c:1860) ==31604==by 0x47DB71: PyEval_CallObjectWithKeywords (ceval.c:3433) ==31604==by 0x20605868: __pyx_f_20matrix_integer_dense_20Matrix_integer_dense___copy__ (matrix_integer_dense.c:3189) ==31604==by 0x4156A2: PyObject_Call (abstract.c:1860) ==31604==by 0x47DB71: PyEval_CallObjectWithKeywords (ceval.c:3433) ==31604==by 0x1E12C45C: __pyx_f_7matrix0_6Matrix_copy (matrix0.c: 845) ==31604==by 0x485B9B: PyEval_EvalFrameEx (ceval.c:3548) ==31604==by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604== ==31604== ==31604== 16,000,000 bytes in 1 blocks are still reachable in loss record 1,978 of 1,979 ==31604==at 0x4A05A66: malloc (vg_replace_malloc.c:207) ==31604==by 0x205E9766: __pyx_f_20matrix_integer_dense_20Matrix_integer_dense___new__ (matrix_integer_dense.c:2966) ==31604==by 0x205E9BE0: __pyx_tp_new_20matrix_integer_dense_Matrix_integer_dense (matrix_integer_dense.c:17692) ==31604==by 0x45A272: type_call (typeobject.c:422) ==31604==by 0x4156A2: PyObject_Call (abstract.c:1860) ==31604==by 0x480783: PyEval_EvalFrameEx (ceval.c:3775) ==31604==by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604==by 0x4845B3: PyEval_EvalFrameEx (ceval.c:3660) ==31604==by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604==by 0x4CFF37: function_call (funcobject.c:517) ==31604==by 0x4156A2: PyObject_Call (abstract.c:1860) ==31604==by 0x41BE0C: instancemethod_call (classobject.c:2497) But with A=matrix(ZZ,1000,1000,0) B=A.copy() del A del B the above problem is gone, no more "still reachable" that are caused to A or B. A.echelonize() doesn't leak for that A over ZZ either. burcin found out that "A = random_matrix(ZZ, 100, 120);" leaks, as does "A._pari_()" I am currently looking into getting useful information out of the Python garbage collector. So stay tuned. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and ht
[sage-devel] Re: cannot build 2.8.4 on sage.math
Yeah, that doesn't sound like fun. Try the following from your sage- main directory: cd c_lib ; rm -f libcsage.* ; scons install. You should see scons rebuild the libcsage.so and then copy it to your $SAGE_ROOT/local/lib ... let me know if that works. If it does, we might just need to be more adamant about how the c_lib build happens on install, because it sounds like your c_lib isn't getting rebuilt (i.e. your $SAGE_ROOT/local/lib/libcsage.so is bunk). In fact, I can see this being pretty likely -- it could be the same problem I was having when I switched branches, and I just need to make sure the same thing is happening when you do an install. This shouldn't be too bad, and it'll save you from having to pull out any more hair. ;) If *not*, it means there's actually a problem with the libcsage.so that's getting built, which is bad. This will require more thought. I'll be gone most of the day, but I'll read your reply when I get back and make a fix if it's the first one. -cc On Sep 8, 2007, at 7:44 AM, David Harvey wrote: > > I am tearing my hair out. > > I do a clean build of sage 2.8.4 on sage.math, and when I run it I > get this: > > == > > > -- > | SAGE Version 2.8.4, Release Date: 2007-09-07 | > | Type notebook() for the GUI, and license() for information.| > -- > -- > -- > --- >Traceback (most recent call > last) > > /home/dmharvey/sage-2.8.4/local/bin/ in () > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ > preparser_ipython.py in () >6 > ## > ## > ### >7 > > 8 import sage.misc.interpreter >9 > 10 import preparser > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ > interpreter.py in () > 102 > 103 import os > --> 104 import log > 105 > 106 import remote_file > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ > log.py in () > 51 > 52 import interpreter > ---> 53 import latex > 54 import misc > 55 > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ > latex.py in () > 41 import random > 42 > ---> 43 import sage.plot.all > 44 > 45 from misc import tmp_dir > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/plot/ > all.py in () >2 text, circle, disk, hue, graphics_array, >3 list_plot, networkx_plot, parametric_plot, >4 polar_plot, contour_plot, arrow, >5 plot_vector_field, matrix_plot, bar_chart, >6 is_Graphics, > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/plot/ > plot.py in () > 126 > ## > ## > > 127 > --> 128 from sage.structure.sage_object import SageObject > 129 > 130 ## IMPORTANT: Do *not* import matplotlib at module scope. > It takes a > > : /home/dmharvey/sage-2.8.4/local/lib/ > libcsage.so: undefined symbol: __stack_chk_fail > WARNING: Failure executing code: 'import > sage.misc.preparser_ipython; > sage.misc.preparser_ipython.magma_colon_equals=True' > > -- > -- > --- >Traceback (most recent call > last) > > /home/dmharvey/sage-2.8.4/local/bin/ in () > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ > interpreter.py in () > 102 > 103 import os > --> 104 import log > 105 > 106 import remote_file > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ > log.py in () > 51 > 52 import interpreter > ---> 53 import latex > 54 import misc > 55 > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ > latex.py in () > 41 import random > 42 > ---> 43 import sage.plot.all > 44 > 45 from misc import tmp_dir > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/plot/ > all.py in () >2 text, circle, disk, hue, graphics_array, >3 list_plot, networkx_plot, parametric_plot, >4 polar_plot, contour_plot, arrow, >5 plot_vector_field, matrix_plot, bar_chart, >6 is_Graphics, > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/plot/ > plot.py in () > 126 > ## > ## > > 127 > --> 128 from sage.structure.sage_ob
[sage-devel] Re: sage-2.8.4
mabshoff wrote: > > > the changeset at http://www.sagemath.org/hg/sage-main/rev/f12659f0ebd0 > should fix that problem. It happens only on 32 bit systems. William > respun the tarballs after he announced 2.8.4 (which did not contain > the changeset), but I don't believe he mirrored them out. Please let > us know if that fixes your issue. > sage -t devel/sage-main/sage/rings/tests.py [1.3 s] -- All tests passed! Total time for all tests: 1.3 seconds Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.4
On Sep 8, 6:15 pm, Jaap Spies <[EMAIL PROTECTED]> wrote: > William Stein wrote: > > Hi, > > > SAGE-2.8.4 -- a "mega bugfix release" (70 tickets closed since 2.8.3.6) > > has been released: > >http://sagemath.org > > or > >sage -upgrade > > Only this test failed on fedora 7: > Linux paix 2.6.22.4-65.fc7 #1 SMP Tue Aug 21 22:36:56 EDT 2007 i686 i686 i386 > GNU/Linux > > sage -t devel/sage-main/sage/rings/tests.py > ** > File "tests.py", line 8: > sage: (1/2)^(2^100) > Expected: > Traceback (most recent call last): > ... > RuntimeError: exponent must be at most 4294967294 > Got: > Traceback (most recent call last): >File "/home/jaap/downloads/sage-2.8.4/local/lib/python2.5/doctest.py", > line 1212, in __run > compileflags, 1) in test.globs >File "", line 1, in > (Integer(1)/Integer(2))**(Integer(2)**Integer(100))###line 8: > sage: (1/2)^(2^100) >File "rational.pyx", line 1008, in rational.Rational.__pow__ > raise RuntimeError, "exponent must be at most %s" % sys.maxint > RuntimeError: exponent must be at most 2147483647 > ** > 1 items had failures: > 1 of 4 in __main__.example_0 > ***Test Failed*** 1 failures. > For whitespace errors, see the file .doctest_tests.py > [5.9 s] > exit code: 256 > > Jaap Hello Jaap, the changeset at http://www.sagemath.org/hg/sage-main/rev/f12659f0ebd0 should fix that problem. It happens only on 32 bit systems. William respun the tarballs after he announced 2.8.4 (which did not contain the changeset), but I don't believe he mirrored them out. Please let us know if that fixes your issue. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage-2.8.4
William Stein wrote: > Hi, > > SAGE-2.8.4 -- a "mega bugfix release" (70 tickets closed since 2.8.3.6) > has been released: >http://sagemath.org > or >sage -upgrade > Only this test failed on fedora 7: Linux paix 2.6.22.4-65.fc7 #1 SMP Tue Aug 21 22:36:56 EDT 2007 i686 i686 i386 GNU/Linux sage -t devel/sage-main/sage/rings/tests.py ** File "tests.py", line 8: sage: (1/2)^(2^100) Expected: Traceback (most recent call last): ... RuntimeError: exponent must be at most 4294967294 Got: Traceback (most recent call last): File "/home/jaap/downloads/sage-2.8.4/local/lib/python2.5/doctest.py", line 1212, in __run compileflags, 1) in test.globs File "", line 1, in (Integer(1)/Integer(2))**(Integer(2)**Integer(100))###line 8: sage: (1/2)^(2^100) File "rational.pyx", line 1008, in rational.Rational.__pow__ raise RuntimeError, "exponent must be at most %s" % sys.maxint RuntimeError: exponent must be at most 2147483647 ** 1 items had failures: 1 of 4 in __main__.example_0 ***Test Failed*** 1 failures. For whitespace errors, see the file .doctest_tests.py [5.9 s] exit code: 256 Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: cannot build 2.8.4 on sage.math
On Saturday 08 September 2007 11:09, David Harvey wrote: > > I think this may be something in your ambient environment which > > scons handles > > differently than autoconf and friends. > > Is "ambient environment" a technical unix term? Is that the same as > my environment? No, sorry. I was intending it as a bit more generic than the technical term environment. The bit that I understood on the similar IRC conversation seemed like you were linking to a gmp outside your sage tree. Now, how that would have occurred is probably a matter of the technical-term environment. -- Joel --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: cannot build 2.8.4 on sage.math
On Sep 8, 5:23 pm, David Harvey <[EMAIL PROTECTED]> wrote: > On Sep 8, 2007, at 11:21 AM, mabshoff wrote: > > >> It's already got that line in 2.8.4. > > > I would suggest commenting it out then. It was merged because of a > > build problem on RHEL 5. > > Okay, I'll try again with that line restored to how it was before. > > > > >> Has anyone else actually built sage-2.8.4 from scratch on sage.math? > > > I believe William did do, I didn't try in person. > > Sorry I should rephrase that question: has anyone else actually built > 2.8.4 and succesfully *run* it on sage.math? (The build itself > appears to go smoothly.) > I am sure William ran testall, but I just started a build to see if I can replicate your problem. I shall report back in about 2 hours (unless something big is running on sage.math). > david Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: compiling on AIX/PowerPPC
On Sep 8, 4:33 pm, Hamptonio <[EMAIL PROTECTED]> wrote: > It turns out that I also have access to a linux-based supercomputer, > (an IBM BladeCenter with about 300 quad-processor nodes), which should > be faster than the Power4 system anyway. So I will give up, for the > moment, trying to install sage on AIX. Ok, how far did you get? > I have installed sage-2.8.3.6 > on the BladeCenter successfully, with the following "make test" > failures: > > sage -t devel/sage-main/sage/modular/modform/ambient_g1.py > sage -t devel/sage-main/sage/modular/modform/ > eisenstein_submodule.py > sage -t devel/sage-main/sage/modular/modform/submodule.py > sage -t devel/sage-main/sage/rings/real_rqdf.pyx > Total time for all tests: 2137.4 seconds > > Probably some of those have been fixed in 2.8.4. > Please do an "./sage -upgrade" and then rerun the testsuite. If any of those persist we should fix them. There was a last minute 32 bit only regression at the very end of 2.8.4. It was so late that William respun the tarball ;) > Now I'll have to learn more about DSage; I am not sure how to exploit > all those processors the way I usually code. > > Cheers, > Marshall > Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: cannot build 2.8.4 on sage.math
On Sep 8, 2007, at 11:21 AM, mabshoff wrote: >> It's already got that line in 2.8.4. >> > > I would suggest commenting it out then. It was merged because of a > build problem on RHEL 5. Okay, I'll try again with that line restored to how it was before. > >> Has anyone else actually built sage-2.8.4 from scratch on sage.math? >> > > I believe William did do, I didn't try in person. Sorry I should rephrase that question: has anyone else actually built 2.8.4 and succesfully *run* it on sage.math? (The build itself appears to go smoothly.) david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: cannot build 2.8.4 on sage.math
On Sep 8, 5:09 pm, David Harvey <[EMAIL PROTECTED]> wrote: > On Sep 8, 2007, at 11:00 AM, Joel B. Mohler wrote: > > Hello, > > > Hi David, > > > I think this may be something in your ambient environment which > > scons handles > > differently than autoconf and friends. > > Is "ambient environment" a technical unix term? Is that the same as > my environment? ;), but I don't see anything suspicious. > > > > > You could try replacing > > *** > > env = Environment() > > *** with > > env = Environment(ENV = os.environ) > > *** > > near the top of the c_lib/SConstruct file. SCons does not copy > > environment > > variables into it's environment. I think it is a strange design, > > but the > > SCons developers are quite dogmatic about it. > > > This fixed a build problem for Kiran with thread title "2.8.3.x build > > problem". I'm not sure what that SConstruct looks like in 2.8.4, > > but I > > don't think this change made it in. I wasn't quite certain that I > > recommended the change, but if it fixes your problem as well, I'd > > say we > > should put it in. > > It's already got that line in 2.8.4. > I would suggest commenting it out then. It was merged because of a build problem on RHEL 5. > Has anyone else actually built sage-2.8.4 from scratch on sage.math? > I believe William did do, I didn't try in person. > david Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: cannot build 2.8.4 on sage.math
On Sep 8, 2007, at 11:00 AM, Joel B. Mohler wrote: > > Hi David, > > I think this may be something in your ambient environment which > scons handles > differently than autoconf and friends. Is "ambient environment" a technical unix term? Is that the same as my environment? > You could try replacing > *** > env = Environment() > *** with > env = Environment(ENV = os.environ) > *** > near the top of the c_lib/SConstruct file. SCons does not copy > environment > variables into it's environment. I think it is a strange design, > but the > SCons developers are quite dogmatic about it. > > This fixed a build problem for Kiran with thread title "2.8.3.x build > problem". I'm not sure what that SConstruct looks like in 2.8.4, > but I > don't think this change made it in. I wasn't quite certain that I > recommended the change, but if it fixes your problem as well, I'd > say we > should put it in. It's already got that line in 2.8.4. Has anyone else actually built sage-2.8.4 from scratch on sage.math? david --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: cannot build 2.8.4 on sage.math
Hi David, I think this may be something in your ambient environment which scons handles differently than autoconf and friends. You could try replacing *** env = Environment() *** with env = Environment(ENV = os.environ) *** near the top of the c_lib/SConstruct file. SCons does not copy environment variables into it's environment. I think it is a strange design, but the SCons developers are quite dogmatic about it. This fixed a build problem for Kiran with thread title "2.8.3.x build problem". I'm not sure what that SConstruct looks like in 2.8.4, but I don't think this change made it in. I wasn't quite certain that I recommended the change, but if it fixes your problem as well, I'd say we should put it in. -- Joel On Saturday 08 September 2007 10:44, David Harvey wrote: > I am tearing my hair out. > > I do a clean build of sage 2.8.4 on sage.math, and when I run it I > get this: > > == > > > -- > > | SAGE Version 2.8.4, Release Date: 2007-09-07 | > | Type notebook() for the GUI, and license() for information.| > > -- > > --- >Traceback (most recent call > last) > > /home/dmharvey/sage-2.8.4/local/bin/ in () > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ > preparser_ipython.py in () >6 > > ### >7 > > 8 import sage.misc.interpreter >9 > 10 import preparser > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ > interpreter.py in () > 102 > 103 import os > --> 104 import log > 105 > 106 import remote_file > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ > log.py in () > 51 > 52 import interpreter > ---> 53 import latex > 54 import misc > 55 > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ > latex.py in () > 41 import random > 42 > ---> 43 import sage.plot.all > 44 > 45 from misc import tmp_dir > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/plot/ > all.py in () >2 text, circle, disk, hue, graphics_array, >3 list_plot, networkx_plot, parametric_plot, >4 polar_plot, contour_plot, arrow, >5 plot_vector_field, matrix_plot, bar_chart, >6 is_Graphics, > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/plot/ > plot.py in () > 126 > > > 127 > --> 128 from sage.structure.sage_object import SageObject > 129 > 130 ## IMPORTANT: Do *not* import matplotlib at module scope. > It takes a > > : /home/dmharvey/sage-2.8.4/local/lib/ > libcsage.so: undefined symbol: __stack_chk_fail > WARNING: Failure executing code: 'import > sage.misc.preparser_ipython; > sage.misc.preparser_ipython.magma_colon_equals=True' > > > --- >Traceback (most recent call > last) > > /home/dmharvey/sage-2.8.4/local/bin/ in () > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ > interpreter.py in () > 102 > 103 import os > --> 104 import log > 105 > 106 import remote_file > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ > log.py in () > 51 > 52 import interpreter > ---> 53 import latex > 54 import misc > 55 > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ > latex.py in () > 41 import random > 42 > ---> 43 import sage.plot.all > 44 > 45 from misc import tmp_dir > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/plot/ > all.py in () >2 text, circle, disk, hue, graphics_array, >3 list_plot, networkx_plot, parametric_plot, >4 polar_plot, contour_plot, arrow, >5 plot_vector_field, matrix_plot, bar_chart, >6 is_Graphics, > > /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/plot/ > plot.py in () > 126 > > > 127 > --> 128 from sage.structure.sage_object import SageObject > 129 > 130 ## IMPORTANT: Do *not* import matplotlib at module scope. > It takes a > > : /home/dmharvey/sage-2.8.4/local/lib/ > libcsage.so: undefined symbol: __stack_chk_fail > > > == >
[sage-devel] cannot build 2.8.4 on sage.math
I am tearing my hair out. I do a clean build of sage 2.8.4 on sage.math, and when I run it I get this: == -- | SAGE Version 2.8.4, Release Date: 2007-09-07 | | Type notebook() for the GUI, and license() for information.| -- --- Traceback (most recent call last) /home/dmharvey/sage-2.8.4/local/bin/ in () /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ preparser_ipython.py in () 6 ### 7 > 8 import sage.misc.interpreter 9 10 import preparser /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ interpreter.py in () 102 103 import os --> 104 import log 105 106 import remote_file /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ log.py in () 51 52 import interpreter ---> 53 import latex 54 import misc 55 /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ latex.py in () 41 import random 42 ---> 43 import sage.plot.all 44 45 from misc import tmp_dir /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/plot/ all.py in () 2 text, circle, disk, hue, graphics_array, 3 list_plot, networkx_plot, parametric_plot, 4 polar_plot, contour_plot, arrow, 5 plot_vector_field, matrix_plot, bar_chart, 6 is_Graphics, /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/plot/ plot.py in () 126 127 --> 128 from sage.structure.sage_object import SageObject 129 130 ## IMPORTANT: Do *not* import matplotlib at module scope. It takes a : /home/dmharvey/sage-2.8.4/local/lib/ libcsage.so: undefined symbol: __stack_chk_fail WARNING: Failure executing code: 'import sage.misc.preparser_ipython; sage.misc.preparser_ipython.magma_colon_equals=True' --- Traceback (most recent call last) /home/dmharvey/sage-2.8.4/local/bin/ in () /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ interpreter.py in () 102 103 import os --> 104 import log 105 106 import remote_file /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ log.py in () 51 52 import interpreter ---> 53 import latex 54 import misc 55 /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/misc/ latex.py in () 41 import random 42 ---> 43 import sage.plot.all 44 45 from misc import tmp_dir /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/plot/ all.py in () 2 text, circle, disk, hue, graphics_array, 3 list_plot, networkx_plot, parametric_plot, 4 polar_plot, contour_plot, arrow, 5 plot_vector_field, matrix_plot, bar_chart, 6 is_Graphics, /home/dmharvey/sage-2.8.4/local/lib/python2.5/site-packages/sage/plot/ plot.py in () 126 127 --> 128 from sage.structure.sage_object import SageObject 129 130 ## IMPORTANT: Do *not* import matplotlib at module scope. It takes a : /home/dmharvey/sage-2.8.4/local/lib/ libcsage.so: undefined symbol: __stack_chk_fail == This was happening to me towards the second half of the bug squash too. I took special precautions before building this time. I removed everything in my home directory (packed away everything into tarballs), except for the following files: .bash_profile .bashrc el .emacs .emacs.d flint-home flint_trac .gnupg .hgrc .ssh .svn .viminfo and a few text files and pdf files. My environment is the following: TERM=xterm-color SHELL=/bin/bash SSH_CLIENT=140.247.248.30 52541 22 SSH_TTY=/dev/pts/4 SVN_EDITOR=emacs USER=dmharvey LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40 ; 33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37; 44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31: *.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.deb=01;31:*.rpm =01;31:*.jar=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pb m=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.ti f=01;35:*.tiff=01;35:*.png=01;3
[sage-devel] Re: compiling on AIX/PowerPPC
It turns out that I also have access to a linux-based supercomputer, (an IBM BladeCenter with about 300 quad-processor nodes), which should be faster than the Power4 system anyway. So I will give up, for the moment, trying to install sage on AIX. I have installed sage-2.8.3.6 on the BladeCenter successfully, with the following "make test" failures: sage -t devel/sage-main/sage/modular/modform/ambient_g1.py sage -t devel/sage-main/sage/modular/modform/ eisenstein_submodule.py sage -t devel/sage-main/sage/modular/modform/submodule.py sage -t devel/sage-main/sage/rings/real_rqdf.pyx Total time for all tests: 2137.4 seconds Probably some of those have been fixed in 2.8.4. Now I'll have to learn more about DSage; I am not sure how to exploit all those processors the way I usually code. Cheers, Marshall On Sep 7, 1:50 pm, "William Stein" <[EMAIL PROTECTED]> wrote: > On 9/7/07, Hamptonio <[EMAIL PROTECTED]> wrote: > > > > > Thanks guys. I can't use the notebook anyway from that machine, I > > would be running pre-written scripts to do heavy calculations. It got > > far enough that I am hopeful I can get it to where it does what I > > need. > > Please post anything you figure out. We would be very happy > to have AIX officially supported one day!! > > William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: bug in isprime()
Thanks for the extra explanations, Bill. I wrote an extra item in pari's online FAQ, and an additional note in the manual, while Karim has put into the pari cvs already. But (at least as far as mwrank is concerned) we still need a "proof=true" version of factorint(). John On 9/8/07, Bill Hart <[EMAIL PROTECTED]> wrote: > > factor is a general factoring function for integers, polynomials and > various other types. It also takes an optional parameter to tell it > how many primes to use in the factorisation. So for example if you > want to know all prime factors of an integer up to 1000 you'd use > factor(n, 1000). > > factorint only factors integers and takes an optional parameter to > tell it which factorisation algorithms to use. For example you may > know that your integer is an RSA modulus and only divisible by two > large primes. As such running a trial factoring routine, an elliptic > curve factorisation or a SQUFOF test is not going to find a factor. > Similarly you may have a very large integer which has no hope of being > factored by the quadratic sieve and your only hope of finding a factor > is if it is relatively small, in which case you'd want to use the > elliptic curve method without giving up. factorint allows you to do > that. > > Bill. > > > > > -- John Cremona --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
