[sage-devel] Re: Sage 3.0.alpha3 released
I built alpha3 ok but had two bad fails with --testall: The following tests failed: sage -t devel/sage/sage/plot/plot.py # Segfault sage -t devel/sage/sage/interfaces/psage.py # Segfault -- BUT when I re-ran these two manually they were fine. The original --testall took place in the background (in an unattended screen session) if that is relevant. Linux host-57-71 2.6.18.8-0.3-default #1 SMP Tue Apr 17 08:42:35 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux gcc version 4.1.2 20061115 (prerelease) (SUSE Linux) John On 10/04/2008, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Try alpha3, and ignore my last email. William and I have been re-working js.py quite a bit. As of alpha2, I think you needed to use ctrl-backspace to delete a cell. That didn't last long, and backspace is back in alpha3. Please tell me if you find otherwise. On Wed, 9 Apr 2008, Robert Miller wrote: On OSX 10.5/Firefox 2, I cannot delete cells in a notebook worksheet as of sage-3.0.alpha2. On Apr 9, 9:48 pm, Justin C. Walker [EMAIL PROTECTED] wrote: On Apr 9, 2008, at 12:56 , mabshoff wrote: On Apr 9, 8:40 pm, mabshoff [EMAIL PROTECTED] dortmund.de wrote: Can somebody on OSX 10.4 try the spkg at http://sage.math.washington.edu/home/mabshoff/SPKG/polybori-0.3.1.p0 You need to first install the updated linbox.spkg at http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0/alph... to get past the LinBox build problem. Josh Kantor will check if it builds in a couple hours, but I wouldn't be hurt about some feedback sooner. Mac OS X, 10.4.11 (Core 2 Duo, -j2): real 123m10.195s user 88m28.361s sys26m32.847s ... SAGE build/upgrade complete! All tests passed! Total time for all tests: 4608.7 seconds Cheers, 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: should bool(x 0) be False or an exception?
On Apr 10, 4:18 am, Carl Witty [EMAIL PROTECTED] wrote: I like the raise an exception behavior, because it would eliminate questions asking why form1 and form2 below are different (from this sage-support threadhttp://groups.google.com/group/sage-support/browse_thread/thread/79d0...). (I have seen this exact problem at least twice on sage-support.) What do you think? I guess what i suggest wouldn't solve the plot-issue. However, i think if one doesn't know whether an inequality holds, or if the inequality simply makes no sense (such as in the case of an unordered field) then bool() should neither raise an exception nor return False but return None. I think it is much simpler to have if bool(x0) == True: bla1 elif bool(x0)==None: bla2 else: bla3 than catching exceptions. Perhaps it would even make sense to have a new type UnknownBool. This could be returned if the inequality may be true, whereas None could be returned if the inequality simply makes no sense. I don't like at all what happens for complex numbers or finite fields! Here are some examples. sage: bool(x0) False # i think it should be None, or better UnknownBool or so sage: assume(x0) sage: bool(x-1) True # fine sage: bool(xComplexNumber(0,0)) True # ??? The complex field is not ordered. So, the answer True doesn't make sense! sage: bool(xGF(2)(0)) False # Again, does not apply. So, to get False or True isn't quite correct. sage: bool(xComplexNumber(-1,0)) True # sage: bool(xComplexNumber(-1,1)) False # Yours Simon --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: use zip instead of 7zip for distributing the sage binary
On Apr 10, 4:29 am, mabshoff [EMAIL PROTECTED] dortmund.de wrote: It is *341* MB vs. *601* MB, that's really huge. Well, I prefer not to use self extracting executables either,... Well, I don't see a problem in using a self extracting 7z archive. A note on the download site with short instructions and a link to 7zip.org should help everybody. It's really bad to have users unable to handle compressed archives, because they will have problems with the vmware system, too. Therefore we need to include good instructions on the website. (I'll try to cover these issues in my current design for the next website) h --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: tick marks
On Wednesday 09 April 2008 07:37:56 pm gerhard wrote: * The actual bounds used for the axes can yield very surprising results. Should the range bounds be honored if the user sets them explicitely? Since we had a thread about this a bit ago and I was allegedly going to write a patch, I'll share my results of the patch. I had a patch which (in the case I was interested in) eliminated 3 places which nudge the margins about for aesthetic reasons. I thought it might be a manageable job to turn that into a more generic patch which honors margins. However, I was thoroughly scared off when I saw what would need to be done to honor the bounds setting for all cases (frame/no frame, etc). There is a lot of magic constants in the code (0.1, 0.015, 0.002, etc) which evidently were labored over for days. This is a very worthwhile task, but it sure looks like it needs a more massive overhaul than I wanted to engage in. In general, I think the right algorithm is something like this: 1) Honor the bounds settings 2) Check if there are tick marks, axis labels, tick labels outside the viewable area 3) Enlarge the viewable area using font metrics to include these labels. I know nothing about matplotlib so parts 23 are not possible for me in any amount of time I wanted to commit to this. However, parts 23 are necessary for the frames=True option. I don't know if it is actually difficult or not. I totally reject the aesthetic padding idea though so it really is (IMO) just a matter of finding font metrics from whatever code is making text. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: use zip instead of 7zip for distributing the sage binary
An anecdote: I have been unable to get 95% of my students to install sage on their own machines; in at least two cases they got hung up on 7zip and came to me for help. Probably several more got stuck and didn't come for help. (To be fair: I haven't tried that hard to push personal installs, since I supply three powerful servers for a class of 12 people, and its easier to collaborate on the servers.) A link to 7zip.org right by the archive or in the install instructions would help. Its funny, I often listen to faculty who are not great with computers marvel at the skills of the net generation (or whatever buzzword generation), but I'm not convinced that computer literacy of any depth as increased at all since my generation (I'm in my mid-thirties) and if anything I think it might have gone down as people get more and more removed from the underpinnings. -M. Hampton On Apr 10, 5:24 am, Harald Schilly [EMAIL PROTECTED] wrote: On Apr 10, 4:29 am, mabshoff [EMAIL PROTECTED] dortmund.de wrote: It is *341* MB vs. *601* MB, that's really huge. Well, I prefer not to use self extracting executables either,... Well, I don't see a problem in using a self extracting 7z archive. A note on the download site with short instructions and a link to 7zip.org should help everybody. It's really bad to have users unable to handle compressed archives, because they will have problems with the vmware system, too. Therefore we need to include good instructions on the website. (I'll try to cover these issues in my current design for the next website) h --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.0.alpha3 released
Installs fine (ubuntu 7.10 amd64) but has anyone seen something like this: snip sage -t devel/sage/sage/gsl/gsl_random.pxi [2.3 s] sage -t devel/sage/sage/lfunctions/lcalc.py Aborted (core dumped) A mysterious error (perphaps a memory error?) occurred, which may have crashed doctest. [6.0 s] sage -t devel/sage/sage/lfunctions/dokchitser.py [11.7 s] sage -t devel/sage/sage/lfunctions/sympow.py [12.9 s] sage -t devel/sage/sage/plot/plot3d/index_face_set.pyx [2.7 s] sage -t devel/sage/sage/plot/plot3d/parametric_surface.pyx [4.4 s] sage -t devel/sage/sage/plot/plot3d/help.pyx [3.8 s] sage -t devel/sage/sage/plot/plot3d/texture.py [2.5 s] sage -t devel/sage/sage/plot/plot3d/list_plot3d.py [6.5 s] sage -t devel/sage/sage/plot/plot3d/transform.pyx [6.7 s] sage -t devel/sage/sage/plot/plot3d/platonic.py [6.4 s] sage -t devel/sage/sage/plot/plot3d/point_c.pxi [2.3 s] sage -t devel/sage/sage/plot/plot3d/shapes.pyx [12.0 s] sage -t devel/sage/sage/plot/plot3d/parametric_plot3d.py [13.4 s] sage -t devel/sage/sage/plot/plot3d/base.pyx [3.8 s] sage -t devel/sage/sage/plot/plot3d/shapes2.py [4.4 s] sage -t devel/sage/sage/plot/plot3d/plot3d.py [8.3 s] sage -t devel/sa at which point, it is frozen? On Wed, Apr 9, 2008 at 7:18 AM, mabshoff [EMAIL PROTECTED] wrote: Hello folks, here is alpha3. Loads of small fixes, a total of 141 tickets have been closed for the 3.0 milestone so far. First the good news: The Fortran doctest issue has been fixed by Josh Kantor. Now the not so good news: Issue: Invalid read in libgroebner.so (#2822): No solution yet, various leads. Issue: Linbox build failure on OSX 10.4 intel (#2833): Clement Pernet is on it and will likely just rip out the commentator code since we don't use it anyway. Issue: sage-3.0-alpha1 on ppc -- new randstate code doesn't work right at all (#2814): Carl Witty is back and has some patches in preparation. We will probably need some testing of those patches. Sources, binaries and documentation [due to special request]: http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0/sage-3.0.alpha3.tar http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0/sage-3.0.alpha3-sage.math-only-x86_64-Linux.tar.gz http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0/doc-3.0.alpha3.spkg Cheers, Michael Merged in alpha3: #1761: Tom Boothby, Nick Alexander: Graphviz output for graphs #2242: Jason Grout: optional nauty package #2379: Gary Furnish, Michael Abshoff: Merge sage-ptest into sage-test #2748: Dan Drake: Permutation constructor does not accept lists of tuples #2802: Josh Kantor: Sage 3.0.alpha1: sage/misc/inline_fortran.py doctest failure #2820: William Stein: notebook -- turn off the jsmath warning; fix other misc polish issues and bugs resulting from #2840 #2826: William Stein: notebook -- in safari, pressing enter after showing the list of completions doesn't work. You have to click #2834: Martin Albrecht: PyLint import cleanup for sage.rings.polynomial #2835: Nick Alexander: primes_of_degree_one iterator for NumberField_generic #2839: Mike Hansen: bug in conversion from symmetrica's longint #2840: William Stein: notebook -- remove ALL unused javascript from js.py and DOCUMENT every single function #2842: Martin Albrecht: PyLint - unused variable cleanup for sage.rings.polynomial #2844: Marshall Hampton: Polyhedral improvements, round 2 #2845: Martin Albrecht: fix PolyBoRi assertion errror #2846: Robert Bradshaw: no need for bitset.h with new Cython #2847: Robert Bradshaw: more speedups to cyclotomic polynomials #2848: Michael Abshoff: numerical noise in sage/misc/prandom.py on MacIntel OSX 10.5 #2849: John Cremona, Alex Ghitza: Bug in elliptic curve cardinality for j=0 in char. 3 #2852: Tom Boothby: ctrl-enter broken in firefox/linux #2853: Dan Bump: A correction to the weight of crystal elements for type A and a speedup for all types #2856: Martin Albrecht: PyLint unused variable cleanup for sage.rings.polynomial - Part 2 #2859: Jason Grout: arrow3d((0,0,0), (0,0,-1)) plots an *upward* pointing arrow #2862: Michael Abshoff: Sage 3.0.alpha2: fix tex problems #2863: Dan Drake: Integer() does not specify that numbers beginning with 0 and 0x are treated specially Merged in alpha2: #358: John Cremona: padic_height_pairing_matrix computes too many heights #530: Martin Albrecht: leak in Matrix_integer_dense__solve_iml exposed by matrix/strassen.pyx #2316: Yi Qiang: dsage.start_all() can leave zombie workers around #2346: Robert Bradshaw: Sage needs a simple api for interaction with other
[sage-devel] Re: tick marks
I would just like to give a +1 on the importance of fixing this. I am often irritated by my explicit bounds being expanded in hard to predict ways. I am somewhat confused by the way the 2D graphics use and alter matplotlib, so I didn't fix it myself either, but I could at least review a patch. The first thing a lot of people want to do with something like Sage is plot something, and if it doesn't look good they might not try it again. I have literally seen that happen. The 3D graphics have been a huge boost but 2D is what people try first. -M. Hampton On Apr 10, 6:15 am, Joel B. Mohler [EMAIL PROTECTED] wrote: On Wednesday 09 April 2008 07:37:56 pm gerhard wrote: * The actual bounds used for the axes can yield very surprising results. Should the range bounds be honored if the user sets them explicitely? Since we had a thread about this a bit ago and I was allegedly going to write a patch, I'll share my results of the patch. I had a patch which (in the case I was interested in) eliminated 3 places which nudge the margins about for aesthetic reasons. I thought it might be a manageable job to turn that into a more generic patch which honors margins. However, I was thoroughly scared off when I saw what would need to be done to honor the bounds setting for all cases (frame/no frame, etc). There is a lot of magic constants in the code (0.1, 0.015, 0.002, etc) which evidently were labored over for days. This is a very worthwhile task, but it sure looks like it needs a more massive overhaul than I wanted to engage in. In general, I think the right algorithm is something like this: 1) Honor the bounds settings 2) Check if there are tick marks, axis labels, tick labels outside the viewable area 3) Enlarge the viewable area using font metrics to include these labels. I know nothing about matplotlib so parts 23 are not possible for me in any amount of time I wanted to commit to this. However, parts 23 are necessary for the frames=True option. I don't know if it is actually difficult or not. I totally reject the aesthetic padding idea though so it really is (IMO) just a matter of finding font metrics from whatever code is making text. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: use zip instead of 7zip for distributing the sage binary
On Apr 10, 2:14 pm, mhampton [EMAIL PROTECTED] wrote: A link to 7zip.org right by the archive or in the install instructions would help. will be there ... but I'm not convinced that computer literacy of any depth as increased ... Yes, especially because I think that's far more general. That computer literacy only increases, if there is some interest/force/reward to master the problems [e.g. nobody knows more about graphic cards + drivers than active gamers!], but this applies to all areas in life. Humans constantly optimize themselves and new things with a barrier are avoided, if there are other shorter path to accomplish the task. Even if in a long term period the initial higher investment would have the greater return of investment. So, emphasis should be in explaining why an open system with involvement of everybody is better than a closed up encapsulated for-profit one. Then the motivation is higher to master install instructions. But, disclaimer, that's just my private theory concerning the dumb colorful point and click vs. complex and fast functionality war ;) h --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: use zip instead of 7zip for distributing the sage binary
On Thu, Apr 10, 2008 at 6:22 AM, Harald Schilly [EMAIL PROTECTED] wrote: On Apr 10, 2:14 pm, mhampton [EMAIL PROTECTED] wrote: A link to 7zip.org right by the archive or in the install instructions would help. will be there ... but I'm not convinced that computer literacy of any depth as increased ... Yes, especially because I think that's far more general. That computer literacy only increases, if there is some interest/force/reward to master the problems [e.g. nobody knows more about graphic cards + drivers than active gamers!], but this applies to all areas in life. Humans constantly optimize themselves and new things with a barrier are avoided, if there are other shorter path to accomplish the task. Even if in a long term period the initial higher investment would have the greater return of investment. So, emphasis should be in explaining why an open system with involvement of everybody is better than a closed up encapsulated for-profit one. Then the motivation is higher to master install instructions. But, disclaimer, that's just my private theory concerning the dumb colorful point and click vs. complex and fast functionality war ;) We should make Sage as easy or easier to install than any of Mathematica, Maple, Matlab, or Magma. I see no reason to compromise on this at all, since the goal is to provide a viable alternative to Mathematica, Maple, Matlab, and Magma. Part of this is that Sage must be as easy to install as those programs. I don't think we should try to convince people to install a difficult-to-install version of Sage because it will be better for them in the long run. The right thing to do is to make Sage easier to install.That's been my philosophy since I started Sage, and is why Sage comes as a complete install, instead of something incomplete with a huge number of dependencies. Until now the main goal has been growing the developer community, so a lot of effort has gone into making Sage easy to install *for developers*. I think Sage is in fact easier to install for developers (i.e., to get a full developer environment setup) than most math software projects. By this I mean that if one were to become a Magma developer the barrier to getting everything setup on your system to do development would I think be higher than for Sage. Incidentally, here are last weeks download numbers on sagemath.org and sage.math.washington.edu (2 of the download sites): Linux Binary: 81 OS X Binary: 42 Source: 76 VMware: 95 TOTAL: 294 -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: use zip instead of 7zip for distributing the sage binary
On Thu, Apr 10, 2008 at 10:40 AM, William Stein [EMAIL PROTECTED] wrote: On Thu, Apr 10, 2008 at 6:22 AM, Harald Schilly [EMAIL PROTECTED] wrote: On Apr 10, 2:14 pm, mhampton [EMAIL PROTECTED] wrote: A link to 7zip.org right by the archive or in the install instructions would help. will be there ... but I'm not convinced that computer literacy of any depth as increased ... Yes, especially because I think that's far more general. That computer literacy only increases, if there is some interest/force/reward to master the problems [e.g. nobody knows more about graphic cards + drivers than active gamers!], but this applies to all areas in life. Humans constantly optimize themselves and new things with a barrier are avoided, if there are other shorter path to accomplish the task. Even if in a long term period the initial higher investment would have the greater return of investment. So, emphasis should be in explaining why an open system with involvement of everybody is better than a closed up encapsulated for-profit one. Then the motivation is higher to master install instructions. But, disclaimer, that's just my private theory concerning the dumb colorful point and click vs. complex and fast functionality war ;) We should make Sage as easy or easier to install than any of Mathematica, Maple, Matlab, or Magma. I see no reason to compromise on this at all, since the goal is to provide a viable alternative to Mathematica, Maple, Matlab, and Magma. Part of this is that Sage must be as easy to install as those programs. I don't think we should try to convince people to install a difficult-to-install version of Sage because it will be better for them in the long run. The right thing to do is to make Sage easier to install.That's been my philosophy since I started Sage, and is why Sage comes as a complete install, instead of something incomplete with a huge number of dependencies. Until now the main goal has been growing the developer community, so a lot of effort has gone into making Sage easy to install *for developers*. I think Sage is in fact easier to install for developers (i.e., to get a full developer environment setup) than most math software projects. By this I mean that if one were to become a Magma developer the barrier to getting everything setup on your system to do development would I think be higher than for Sage. Incidentally, here are last weeks download numbers on sagemath.org and sage.math.washington.edu (2 of the download sites): Linux Binary: 81 OS X Binary: 42 Source: 76 VMware: 95 TOTAL: 294 I agree with all this but really just want to pipe in one comment since by coincidence I looked at the download stats for sage.scipy. What was (to me) unusualy was the *huge* spike in downloads over the winder break last December). (Nearly a 10-fold increase.) I would be very interested in knowing if this 294 number increases around the end of next month, when the summer break starts for a lot of colleges. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.0.alpha3 released
Alpha 3 issues: On sage.math: The following tests failed: sage -t devel/sage/sage/matrix/matrix_generic_dense.pyx # Segfault sage -t devel/sage/sage/matrix/matrix_mod2_dense.pyx # Segfault sage -t devel/sage/sage/libs/ntl/ntl_GF2.pyx # Segfault sage -t devel/sage/sage/modular/modform/cuspidal_submodule.py # Segfault sage -t devel/sage/sage/functions/orthogonal_polys.py # Segfault On sagemath.org: The following tests failed: sage -t devel/sage/sage/server/simple/twist.py # 10 doctests failed sage -t devel/sage/sage/matrix/strassen.pyx # Segfault sage -t devel/sage/sage/matrix/matrix_integer_dense_saturation.py # Segfault sage -t devel/sage/sage/groups/matrix_gps/matrix_group_element.py # Segfault sage -t devel/sage/sage/groups/group.pyx # Segfault sage -t devel/sage/sage/dsage/tests/testdoc.py # 2 doctests failed -- Total time for all tests: 3468.0 seconds On Powerpc osx/Debian 32 I can't even do make check since it keeps asking me or credentials I don't know. SAGE_TEST_TEX=1 . local/bin/sage-env ./sage -t devel/sage/sage/ 21 | tee -a test.log Enter passphrase (empty for no passphrase): Enter same passphrase again: Enter passphrase (empty for no passphrase): Enter same passphrase again: I get this on Ubuntu 32-bit: sage -t devel/sage/sage/server/notebook/compress/JavaScriptCompressor.py (skipping) -- nodoctest.py Enter passphrase (empty for no passphrase): ... then I'm stuffed. On debian 64 the whole doctesting freezes midstream: sage -t devel/sage/sage/crypto/classical.py [2.4 s] sage -t devel/sage/sage/crypto/stream_cipher.py [1.7 s] sage -t deve [wait 20 hours] [1]+ Stopped ./bb [EMAIL PROTECTED]:~$ I suspect sage -tp. On bsd (os x intel), All tests passed! -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 3.0.alpha3 released
Tom, Confirmed working in 3.0.alpha3. On Apr 9, 10:39 pm, [EMAIL PROTECTED] wrote: Try alpha3, and ignore my last email. William and I have been re-working js.py quite a bit. As of alpha2, I think you needed to use ctrl-backspace to delete a cell. That didn't last long, and backspace is back in alpha3. Please tell me if you find otherwise. On Wed, 9 Apr 2008, Robert Miller wrote: On OSX 10.5/Firefox 2, I cannot delete cells in a notebook worksheet as of sage-3.0.alpha2. On Apr 9, 9:48 pm, Justin C. Walker [EMAIL PROTECTED] wrote: On Apr 9, 2008, at 12:56 , mabshoff wrote: On Apr 9, 8:40 pm, mabshoff [EMAIL PROTECTED] dortmund.de wrote: Can somebody on OSX 10.4 try the spkg at http://sage.math.washington.edu/home/mabshoff/SPKG/polybori-0.3.1.p0 You need to first install the updated linbox.spkg at http://sage.math.washington.edu/home/mabshoff/release-cycles-3.0/alph... to get past the LinBox build problem. Josh Kantor will check if it builds in a couple hours, but I wouldn't be hurt about some feedback sooner. Mac OS X, 10.4.11 (Core 2 Duo, -j2): real 123m10.195s user 88m28.361s sys26m32.847s ... SAGE build/upgrade complete! All tests passed! Total time for all tests: 4608.7 seconds Cheers, 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: use zip instead of 7zip for distributing the sage binary
Incidentally, here are last weeks download numbers on sagemath.org and sage.math.washington.edu (2 of the download sites): Linux Binary: 81 OS X Binary: 42 Source: 76 VMware: 95 TOTAL: 294 I agree with all this but really just want to pipe in one comment since by coincidence I looked at the download stats for sage.scipy. What was (to me) unusualy was the *huge* spike in downloads over the winder break last December). (Nearly a 10-fold increase.) That was when Sage got on the cover of slashdot, and there were articles in tons of papers about Sage winning Trophees du Libre. I would be very interested in knowing if this 294 number increases around the end of next month, when the summer break starts for a lot of colleges. 294 in one week is unusually high. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: use zip instead of 7zip for distributing the sage binary
Dear William, On Apr 10, 4:40 pm, William Stein [EMAIL PROTECTED] wrote: We should make Sage as easy or easier to install than any of Mathematica, Maple, Matlab, or Magma. This is very reasonable IMO. Would it be feasible and reasonable to provide several ways of installations, with brief comments which one should be chosen? Such as a self-extracting thing with the comment This is the easiest way to download Sage (you are just two clicks away), and another one This option is preferred if your internet connection has restricted bandwidth? In that way, one would fit the requirements of various types of users. Cheers Simon --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: use zip instead of 7zip for distributing the sage binary
On Apr 10, 4:40 pm, William Stein [EMAIL PROTECTED] wrote: SNIP We should make Sage as easy or easier to install than any of Mathematica, Maple, Matlab, or Magma. I see no reason to compromise on this at all, since the goal is to provide a viable alternative to Mathematica, Maple, Matlab, and Magma. Part of this is that Sage must be as easy to install as those programs. Sage *is* easy to install provided one is capable of reading and following README.txt. All the points about computer literacy aside [insert when I was young I had to walk both ways to school uphill rant] I believe that this is a sad, sad world when somebody who is attempting to get a college education is incapable of following a simple README.txt. And I am not asking people to do anything hard here, i.e. Robert's argument that people should learn mathematics instead of CS skills does not reflect reality, but to follow an url, download a 1MB binary and install it. Other people in IRC have pointed out that my expectations of the average college student seem rather high and not grounded in reality, so I have no intention of opposing the switch to zip files for the vmware image. But it is my understanding the people at a University are supposed to acquire the skills to solve problems, i.e. become capable to approach a problem they have never solved and solve it by thinking about it. I don't want to sound like an elitist jerk [too late I guess], but if you are foiled by a 7zip archive maybe we have a case of PEBKAC :) [look it up if you don't know what that is ;)] SNIP -- William 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: use zip instead of 7zip for distributing the sage binary
On Thu, Apr 10, 2008 at 8:35 AM, mabshoff [EMAIL PROTECTED] wrote: On Apr 10, 4:40 pm, William Stein [EMAIL PROTECTED] wrote: SNIP We should make Sage as easy or easier to install than any of Mathematica, Maple, Matlab, or Magma. I see no reason to compromise on this at all, since the goal is to provide a viable alternative to Mathematica, Maple, Matlab, and Magma. Part of this is that Sage must be as easy to install as those programs. Sage *is* easy to install provided one is capable of reading and following README.txt. I think the most productive definition of easy to to have potential Sage users -- ranging from students to college professors to professionals -- test out the process and report their experiences. If they say it is easy, then it is easy. If they say it isn't, then it isn't. Simple as that. We've done that a lot recently at UW, and the conclusion is that we have room to improve. Regarding: We should make Sage as easy or easier to install than any of Mathematica, Maple, Matlab, or Magma. This is very reasonable IMO. Would it be feasible and reasonable to provide several ways of installations, with brief comments which one should be chosen? That is feasible. Unfortunately having several ways of installation can be the opposite of easy... so let's be careful. -- William All the points about computer literacy aside [insert when I was young I had to walk both ways to school uphill rant] I believe that this is a sad, sad world when somebody who is attempting to get a college education is incapable of following a simple README.txt. And I am not asking people to do anything hard here, i.e. Robert's argument that people should learn mathematics instead of CS skills does not reflect reality, but to follow an url, download a 1MB binary and install it. Other people in IRC have pointed out that my expectations of the average college student seem rather high and not grounded in reality, so I have no intention of opposing the switch to zip files for the vmware image. But it is my understanding the people at a University are supposed to acquire the skills to solve problems, i.e. become capable to approach a problem they have never solved and solve it by thinking about it. I don't want to sound like an elitist jerk [too late I guess], but if you are foiled by a 7zip archive maybe we have a case of PEBKAC :) [look it up if you don't know what that is ;)] SNIP -- William Cheers, Michael -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: use zip instead of 7zip for distributing the sage binary
On Apr 10, 2008, at 11:35 AM, mabshoff wrote: On Apr 10, 4:40 pm, William Stein [EMAIL PROTECTED] wrote: SNIP We should make Sage as easy or easier to install than any of Mathematica, Maple, Matlab, or Magma. I see no reason to compromise on this at all, since the goal is to provide a viable alternative to Mathematica, Maple, Matlab, and Magma. Part of this is that Sage must be as easy to install as those programs. Sage *is* easy to install provided one is capable of reading and following README.txt. All the points about computer literacy aside [insert when I was young I had to walk both ways to school uphill rant] I believe that this is a sad, sad world when somebody who is attempting to get a college education is incapable of following a simple README.txt. And I am not asking people to do anything hard here, i.e. Robert's argument that people should learn mathematics instead of CS skills does not reflect reality, but to follow an url, download a 1MB binary and install it. Other people in IRC have pointed out that my expectations of the average college student seem rather high and not grounded in reality, so I have no intention of opposing the switch to zip files for the vmware image. But it is my understanding the people at a University are supposed to acquire the skills to solve problems, i.e. become capable to approach a problem they have never solved and solve it by thinking about it. I don't want to sound like an elitist jerk [too late I guess], but if you are foiled by a 7zip archive maybe we have a case of PEBKAC :) [look it up if you don't know what that is ;)] I don't think the issue is whether or not the prospective user is capable of following instructions. The real issue is the cost-benefit analysis for the prospective user. I think there are a lot of potential users who might have vaguely heard about Sage from a colleague/teacher/whoever, and get to sagemath.org, and have to figure out what to do next. For many of these people, we now have their eyeballs for about 15 seconds. If they can't figure out how to download and start using Sage with less neurons than it takes to get distracted by the newspaper or their cup of coffee or whatever, then we lose them. The thing is, they *don't care about Sage yet*, and if the coffee smells better, they'll go for the coffee. So for this reason I advocate we push this even further. We should try to absolutely minimise the number of clicks needed to get them running Sage on their own machine. Currently on sagemath.org, they have to do the following: (1) click on download, (2) click on Microsoft Windows Binary (note that many users may not even know what binary means), (3) figure out that they need to download the zip file, i.e. click on it (note that many users at this stage might never have seen an apache-served directory listing) I reckon it needs to be WAY simpler than this. It needs to be a single click from the main page, labelled Download Sage for Microsoft Windows, which goes straight to a self-extracting installer. The contents of README.txt need to be put on the screen without even needing to click on README.txt. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: use zip instead of 7zip for distributing the sage binary
I reckon it needs to be WAY simpler than this. It needs to be a single click from the main page, labelled Download Sage for Microsoft Windows, which goes straight to a self-extracting installer. The contents of README.txt need to be put on the screen without even needing to click on README.txt. I guess something like the firefox website would be feasible http://www.mozilla.com/en-US/firefox/ (I mean the green button-like thing) Btw. I think Harald is working on redesigning the website anyway. Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: use zip instead of 7zip for distributing the sage binary
On Thu, Apr 10, 2008 at 9:04 AM, Martin Albrecht [EMAIL PROTECTED] wrote: I reckon it needs to be WAY simpler than this. It needs to be a single click from the main page, labelled Download Sage for Microsoft Windows, which goes straight to a self-extracting installer. The contents of README.txt need to be put on the screen without even needing to click on README.txt. I guess something like the firefox website would be feasible http://www.mozilla.com/en-US/firefox/ (I mean the green button-like thing) Btw. I think Harald is working on redesigning the website anyway. Yes, let's make it official. Harald Schilly is now the new official sagemath.org webmaster! And he's working on doing all kinds of cool stuff... And yes, browser detection, etc., for downloading Sage binaries is a great idea. Fortunately, there are many good examples out there to look at? Do you have a favorite site regarding the download process for their software? If so, speak up. Personally I agree with Martin that Firefox is quite good. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Locally scoped dynamic memory (in SAGE and elsewhere)
Hi, (dual posted to sage and cython) A few of us (ipython and mpi4py devs) are wondering what the best/safest way of allocating dynamic memory in a local scope (method/function) is when using cython. An example would be if you need an array of c ints that is locally scoped. The big question is how to make sure that the memory gets freed - even if something goes wrong in the function/method. That is, you want to prevent memory leaks. It looks like in sage, the sage_malloc/sage_free functions are used for this purpose: from sage/graphs/graph_isom.pyx: 176def incorporate_permutation(self, gamma): 202cdef int *_gamma = int * sage_malloc( n * sizeof(int) ) 203if not _gamma: 204raise MemoryError(Error allocating memory.) 205for k from 0 = k n: 206_gamma[k] = gamma[k] 207self._incorporate_permutation(_gamma, n) 208sage_free(_gamma) Because sage_malloc is #defined to malloc in stdsage.h, I think there is a significant potential for memory leaks in code like this. Are we thinking correctly on this issue? Isn't this a huge problem? Lisandro Dalcin (author of mpi4py) came up with the following trick that, while more complicated, prevents memory leaks: cdef extern from Python.h: object PyString_FromStringAndSize(char*,Py_ssize_t) char* PyString_AS_STRING(object) cdef inline object pyalloc_i(int size, int **i): if size 0: size = 0 cdef Py_ssize_t n = size * sizeof(int) cdef object ob = PyString_FromStringAndSize(NULL, n) i[0] = int* PyString_AS_STRING(ob) return ob and now def foo(sequence): cdef int size = len(sequence), cdef int *buf = NULL cdef object tmp = pyalloc_i(size, buf) This could probably be adapted into a malloc-like function. What do people think? Thanks, Brian --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Locally scoped dynamic memory (in SAGE and elsewhere)
On Thu, Apr 10, 2008 at 9:51 AM, Brian Granger [EMAIL PROTECTED] wrote: Hi, (dual posted to sage and cython) A few of us (ipython and mpi4py devs) are wondering what the best/safest way of allocating dynamic memory in a local scope (method/function) is when using cython. An example would be if you need an array of c ints that is locally scoped. The big question is how to make sure that the memory gets freed - even if something goes wrong in the function/method. That is, you want to prevent memory leaks. It looks like in sage, the sage_malloc/sage_free functions are used for this purpose: from sage/graphs/graph_isom.pyx: 176def incorporate_permutation(self, gamma): 202cdef int *_gamma = int * sage_malloc( n * sizeof(int) ) 203if not _gamma: 204raise MemoryError(Error allocating memory.) 205for k from 0 = k n: 206_gamma[k] = gamma[k] 207self._incorporate_permutation(_gamma, n) 208sage_free(_gamma) Because sage_malloc is #defined to malloc in stdsage.h, I think there is a significant potential for memory leaks in code like this. Are we thinking correctly on this issue? Yes. In the above code one could easily cause a serious memory leak by input a gamma so that gamma[k], for some k with 0 = k n, results in an exception. Isn't this a huge problem? Yes it's a problem. Lisandro Dalcin (author of mpi4py) came up with the following trick that, while more complicated, prevents memory leaks: cdef extern from Python.h: object PyString_FromStringAndSize(char*,Py_ssize_t) char* PyString_AS_STRING(object) cdef inline object pyalloc_i(int size, int **i): if size 0: size = 0 cdef Py_ssize_t n = size * sizeof(int) cdef object ob = PyString_FromStringAndSize(NULL, n) i[0] = int* PyString_AS_STRING(ob) return ob and now def foo(sequence): cdef int size = len(sequence), cdef int *buf = NULL cdef object tmp = pyalloc_i(size, buf) This could probably be adapted into a malloc-like function. What do people think? Could you explain what the point is? Is it that this is a trick so that Cython will correctly garbage collect the allocated memory, even if an exception occurs? -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Cython] Locally scoped dynamic memory (in SAGE and elsewhere)
Brian Granger wrote: Hi, Hi Brian, (dual posted to sage and cython) A few of us (ipython and mpi4py devs) are wondering what the best/safest way of allocating dynamic memory in a local scope (method/function) is when using cython. An example would be if you need an array of c ints that is locally scoped. The big question is how to make sure that the memory gets freed - even if something goes wrong in the function/method. That is, you want to prevent memory leaks. It looks like in sage, the sage_malloc/sage_free functions are used for this purpose: They generally aren't used in most of the code. The idea for those functions is that in the future we can wrap other allocators like slab allocators. from sage/graphs/graph_isom.pyx: 176def incorporate_permutation(self, gamma): 202cdef int *_gamma = int * sage_malloc( n * sizeof(int) ) 203if not _gamma: 204raise MemoryError(Error allocating memory.) 205for k from 0 = k n: 206_gamma[k] = gamma[k] 207self._incorporate_permutation(_gamma, n) 208sage_free(_gamma) Because sage_malloc is #defined to malloc in stdsage.h, I think there is a significant potential for memory leaks in code like this. Are we thinking correctly on this issue? Isn't this a huge problem? Well, I don't see an advantage in using Python's allocator there. It is likely slower for large allocations and make debugging memory issues much more complicated since issues like pointer corruption is significantly harder to debug. Lisandro Dalcin (author of mpi4py) came up with the following trick that, while more complicated, prevents memory leaks: cdef extern from Python.h: object PyString_FromStringAndSize(char*,Py_ssize_t) char* PyString_AS_STRING(object) cdef inline object pyalloc_i(int size, int **i): if size 0: size = 0 cdef Py_ssize_t n = size * sizeof(int) cdef object ob = PyString_FromStringAndSize(NULL, n) i[0] = int* PyString_AS_STRING(ob) return ob and now def foo(sequence): cdef int size = len(sequence), cdef int *buf = NULL cdef object tmp = pyalloc_i(size, buf) This could probably be adapted into a malloc-like function. What do people think? We valgrind the complete test suite at least weekly and with ever increasing doctest coverage I don't see that we have a problem. Python's memory management has also some serious issues and I doubt it will offer any advantage for anything but loads of small allocs. And by switching to a slab allocator on our end will fix that problem. Thanks, Brian Cheers, Michael ___ Cython-dev mailing list [EMAIL PROTECTED] http://codespeak.net/mailman/listinfo/cython-dev --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Cython] Locally scoped dynamic memory (in SAGE and elsewhere)
On Thu, Apr 10, 2008 at 9:27 AM, Michael.Abshoff [EMAIL PROTECTED] wrote: Brian Granger wrote: Hi, Hi Brian, (dual posted to sage and cython) A few of us (ipython and mpi4py devs) are wondering what the best/safest way of allocating dynamic memory in a local scope (method/function) is when using cython. An example would be if you need an array of c ints that is locally scoped. The big question is how to make sure that the memory gets freed - even if something goes wrong in the function/method. That is, you want to prevent memory leaks. It looks like in sage, the sage_malloc/sage_free functions are used for this purpose: They generally aren't used in most of the code. They should be. The idea for those functions is that in the future we can wrap other allocators like slab allocators. from sage/graphs/graph_isom.pyx: 176def incorporate_permutation(self, gamma): 202cdef int *_gamma = int * sage_malloc( n * sizeof(int) ) 203if not _gamma: 204raise MemoryError(Error allocating memory.) 205for k from 0 = k n: 206_gamma[k] = gamma[k] 207self._incorporate_permutation(_gamma, n) 208sage_free(_gamma) Because sage_malloc is #defined to malloc in stdsage.h, I think there is a significant potential for memory leaks in code like this. Are we thinking correctly on this issue? Isn't this a huge problem? Well, I don't see an advantage in using Python's allocator there. It is likely slower for large allocations and make debugging memory issues much more complicated since issues like pointer corruption is significantly harder to debug. Since our answers differ, I should clarify. The point is that by giving bad input a user could cause a memory leak. It's something our doctests probably wouldn't notice. Lisandro Dalcin (author of mpi4py) came up with the following trick that, while more complicated, prevents memory leaks: cdef extern from Python.h: object PyString_FromStringAndSize(char*,Py_ssize_t) char* PyString_AS_STRING(object) cdef inline object pyalloc_i(int size, int **i): if size 0: size = 0 cdef Py_ssize_t n = size * sizeof(int) cdef object ob = PyString_FromStringAndSize(NULL, n) i[0] = int* PyString_AS_STRING(ob) return ob and now def foo(sequence): cdef int size = len(sequence), cdef int *buf = NULL cdef object tmp = pyalloc_i(size, buf) This could probably be adapted into a malloc-like function. What do people think? We valgrind the complete test suite at least weekly and with ever increasing doctest coverage I don't see that we have a problem. Python's memory management has also some serious issues and I doubt it will offer any advantage for anything but loads of small allocs. And by switching to a slab allocator on our end will fix that problem. I think the point Brian is making is that if you think about a certain class of code that is common in Sage/Numpy/Scipy, you can construct situations where exceptions are raised and code isn't freed. We're almost surely not actually testing these situations since they are exceptional. But they do exist, and we've been planning to address them some day. -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Locally scoped dynamic memory (in SAGE and elsewhere)
On Thu, Apr 10, 2008 at 10:04 AM, Brian Granger [EMAIL PROTECTED] wrote: Lisandro Dalcin (author of mpi4py) came up with the following trick that, while more complicated, prevents memory leaks: cdef extern from Python.h: object PyString_FromStringAndSize(char*,Py_ssize_t) char* PyString_AS_STRING(object) cdef inline object pyalloc_i(int size, int **i): if size 0: size = 0 cdef Py_ssize_t n = size * sizeof(int) cdef object ob = PyString_FromStringAndSize(NULL, n) i[0] = int* PyString_AS_STRING(ob) return ob and now def foo(sequence): cdef int size = len(sequence), cdef int *buf = NULL cdef object tmp = pyalloc_i(size, buf) This could probably be adapted into a malloc-like function. What do people think? Could you explain what the point is? Is it that this is a trick so that Cython will correctly garbage collect the allocated memory, even if an exception occurs? Yes, that is the idea. By having a python object that knows about the memory, the garbage collection should prevent memory leaks if an exception occurs. I am not sure if Lisandro has proved that this is the case - he is just wondering how people typically handle this case. Seems like we are not alone in thinking this is a problem though. It's I think a general problem not only in Python but in programming in general. The authors of http://www.flintlib.org/ -- a pure C library -- spent a lot of time worrying about this, just to I think decide that it's a really hard problem. That said, there is definitely a significant class of problems in the context of Cython that could be fixed if Lisandro's suggestion works. Thanks for posting it! 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: use zip instead of 7zip for distributing the sage binary
On Apr 10, 4:40 pm, William Stein [EMAIL PROTECTED] wrote: The right thing to do is to make Sage easier to install. Yes, of course, I wanted to point out where the problem is and how it could be handled, the current issue with the Windows install, in my opinion, is the lack of a native port. And then MSI!! MSI is necessary, because system administrators for networks of computers use them like linux packages to push-install them on all machines .. that's impossible for .exe setups !. so, i think, that's the best solution, but i know this is not done until tomorrow... (and there are admins who _only_ take msi packages and forget about the rest ... too much work) @webpage: On Apr 10, 6:04 pm, Martin Albrecht [EMAIL PROTECTED] wrote: Btw. I think Harald is working on redesigning the website anyway. Yes, I'll try to make it easier ... less text, less clicks, gives a higher information density. But it's also not done until tomorrow. Personally, I don't like the firefox install site, but i'll collect all ideas and mix something up. Harald --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Cython] Locally scoped dynamic memory (in SAGE and elsewhere)
On Thu, Apr 10, 2008 at 10:27 AM, Michael.Abshoff [EMAIL PROTECTED] wrote: Brian Granger wrote: Hi, Hi Brian, (dual posted to sage and cython) A few of us (ipython and mpi4py devs) are wondering what the best/safest way of allocating dynamic memory in a local scope (method/function) is when using cython. An example would be if you need an array of c ints that is locally scoped. The big question is how to make sure that the memory gets freed - even if something goes wrong in the function/method. That is, you want to prevent memory leaks. It looks like in sage, the sage_malloc/sage_free functions are used for this purpose: They generally aren't used in most of the code. The idea for those functions is that in the future we can wrap other allocators like slab allocators. Maybe so, but I am am not very familiar with the sage codebase and I quickly found numerous examples of sage_malloc :) Also, from Williams reponse it sounds like the idea is that sage code _would_ use these functions. Also, how else would you allocate dynamic memory? from sage/graphs/graph_isom.pyx: 176def incorporate_permutation(self, gamma): 202cdef int *_gamma = int * sage_malloc( n * sizeof(int) ) 203if not _gamma: 204raise MemoryError(Error allocating memory.) 205for k from 0 = k n: 206_gamma[k] = gamma[k] 207self._incorporate_permutation(_gamma, n) 208sage_free(_gamma) Because sage_malloc is #defined to malloc in stdsage.h, I think there is a significant potential for memory leaks in code like this. Are we thinking correctly on this issue? Isn't this a huge problem? Well, I don't see an advantage in using Python's allocator there. It is likely slower for large allocations and make debugging memory issues much more complicated since issues like pointer corruption is significantly harder to debug. I am not concerned about performance here, but rather memory leaks. I don't think it is a good idea to trade memory leaks for performance. Lisandro Dalcin (author of mpi4py) came up with the following trick that, while more complicated, prevents memory leaks: cdef extern from Python.h: object PyString_FromStringAndSize(char*,Py_ssize_t) char* PyString_AS_STRING(object) cdef inline object pyalloc_i(int size, int **i): if size 0: size = 0 cdef Py_ssize_t n = size * sizeof(int) cdef object ob = PyString_FromStringAndSize(NULL, n) i[0] = int* PyString_AS_STRING(ob) return ob and now def foo(sequence): cdef int size = len(sequence), cdef int *buf = NULL cdef object tmp = pyalloc_i(size, buf) This could probably be adapted into a malloc-like function. What do people think? We valgrind the complete test suite at least weekly and with ever increasing doctest coverage I don't see that we have a problem. Python's memory management has also some serious issues and I doubt it will offer any advantage for anything but loads of small allocs. And by switching to a slab allocator on our end will fix that problem. But, test test suite doesn't test for all of the odd input that users will feed to sage. These are the cases that will leak memory and there is not possible way to test for all of them. Also debugging memory leaks is super nasty. Compared to that pain, having a slightly slower memory allocator is not a big deal. Brian Thanks, Brian Cheers, Michael ___ Cython-dev mailing list [EMAIL PROTECTED] http://codespeak.net/mailman/listinfo/cython-dev --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Locally scoped dynamic memory (in SAGE and elsewhere)
It's I think a general problem not only in Python but in programming in general. The authors of http://www.flintlib.org/ -- a pure C library -- spent a lot of time worrying about this, just to I think decide that it's a really hard problem. Very true. That said, there is definitely a significant class of problems in the context of Cython that could be fixed if Lisandro's suggestion works. Thanks for posting it! I will talk with Lisandro more about this and see if we can explore his trick further. Brian 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Cython] Locally scoped dynamic memory (in SAGE and elsewhere)
Brian Granger wrote: On Thu, Apr 10, 2008 at 10:27 AM, Michael.Abshoff [EMAIL PROTECTED] wrote: Brian Granger wrote: Hi, Hi Brian, Hi Brian, (dual posted to sage and cython) A few of us (ipython and mpi4py devs) are wondering what the best/safest way of allocating dynamic memory in a local scope (method/function) is when using cython. An example would be if you need an array of c ints that is locally scoped. The big question is how to make sure that the memory gets freed - even if something goes wrong in the function/method. That is, you want to prevent memory leaks. It looks like in sage, the sage_malloc/sage_free functions are used for this purpose: They generally aren't used in most of the code. The idea for those functions is that in the future we can wrap other allocators like slab allocators. Maybe so, but I am am not very familiar with the sage codebase and I quickly found numerous examples of sage_malloc :) Also, from Williams reponse it sounds like the idea is that sage code _would_ use these functions. Also, how else would you allocate dynamic memory? Well, in the end you end up using sbrk() anyway, but I don't see what is wrong with malloc itself? sage_malloc was introduced a while back to make it possible to switch to a slab allocator like omalloc potentially to see if there is any benefit from it. from sage/graphs/graph_isom.pyx: 176def incorporate_permutation(self, gamma): 202cdef int *_gamma = int * sage_malloc( n * sizeof(int) ) 203if not _gamma: 204raise MemoryError(Error allocating memory.) 205for k from 0 = k n: 206_gamma[k] = gamma[k] 207self._incorporate_permutation(_gamma, n) 208sage_free(_gamma) Because sage_malloc is #defined to malloc in stdsage.h, I think there is a significant potential for memory leaks in code like this. Are we thinking correctly on this issue? Isn't this a huge problem? Well, I don't see an advantage in using Python's allocator there. It is likely slower for large allocations and make debugging memory issues much more complicated since issues like pointer corruption is significantly harder to debug. I am not concerned about performance here, but rather memory leaks. I don't think it is a good idea to trade memory leaks for performance. Absolutely not, but if you want to write exception safe extensions just write them in exception safe C++ using autoptr friends. While you might not be too concerned about performance here the issue is still debuggability. If you ran standard Python under valgrind (after disabling pymalloc) you will get [EMAIL PROTECTED]:/scratch/mabshoff/release-cycle/sage-3.0.alpha2/local/bin$ valgrind --tool=memcheck --leak-resolution=high ./python ==12347== Memcheck, a memory error detector. ==12347== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==12347== Using LibVEX rev 1812, a library for dynamic binary translation. ==12347== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==12347== Using valgrind-3.4.0.SVN, a dynamic binary instrumentation framework. ==12347== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==12347== For more details, rerun with: -v ==12347== Python 2.5.1 (r251:54863, Apr 6 2008, 21:59:15) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2 Type help, copyright, credits or license for more information. ==12347== ==12347== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 9 from 2) ==12347== malloc/free: in use at exit: 599,274 bytes in 2,441 blocks. ==12347== malloc/free: 12,890 allocs, 10,449 frees, 2,420,712 bytes allocated. ==12347== For counts of detected errors, rerun with: -v ==12347== searching for pointers to 2,441 not-freed blocks. ==12347== checked 998,864 bytes. ==12347== ==12347== LEAK SUMMARY: ==12347==definitely lost: 0 bytes in 0 blocks. ==12347== possibly lost: 15,736 bytes in 54 blocks. ==12347==still reachable: 583,538 bytes in 2,387 blocks. ==12347== suppressed: 0 bytes in 0 blocks. So we have roughly 2,400 blocks of memory that Python itself cannot properly deallocate due to problems with their own garbage collection. I will spare you the numbers for Sage (they are much worst due to still to be solved problems with Cython and extensions in general) and starting to poke for leaks in that pile of crap is not something I find appealing. Sure, once all mallocs in Sage are converted to sage_malloc one could switch and see what happens, but I can guarantee you that debugging some problem stemming from us doing something stupid with malloc compared to tracking it down inside Python is not a contest. Check out #1337 in our track to see such a case. And by the way: The python interpreter itself does leak some small bits of memory while running. So the above while it looks like a really good idea is far from a fool proof solution. Lisandro Dalcin
[sage-devel] Re: [Cython] Locally scoped dynamic memory (in SAGE and elsewhere)
On Thu, Apr 10, 2008 at 10:12 AM, Brian Granger [EMAIL PROTECTED] wrote: (I'm not on the SAGE list so not dual-posting) A few of us (ipython and mpi4py devs) are wondering what the best/safest way of allocating dynamic memory in a local scope (method/function) is when using cython. An example would be if you need an array of c ints that is locally scoped. Won't try-finally work here? I don't see why it wouldn't. But, typical usages of sage_malloc are not protected in that way. Maybe they should be. Note by the way though that it's a bit tricky since in the finally block you have to know whether things when wrong and memory has to be freed or not. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Cython] Locally scoped dynamic memory (in SAGE and elsewhere)
On Thu, Apr 10, 2008 at 10:02 AM, Michael.Abshoff [EMAIL PROTECTED] wrote: But, test test suite doesn't test for all of the odd input that users will feed to sage. These are the cases that will leak memory and there is not possible way to test for all of them. Also debugging memory leaks is super nasty. Compared to that pain, having a slightly slower memory allocator is not a big deal. Well, as long as you write code in C memory leaks when something goes wrong is something you have to live with. And python is far from perfect regarding memory management too IMHO as I point out above. Another issue is that once we have extensions that do work with threads we no longer can use Python's allocation since it isn't thread safe. Adding some more checks to the Sage codebase around allocations is something that ought to be done, but on the list of things to fix potential memory leaks from garbage input is low on the list of my personal priority as long as we have real leaks to deal with. Feel free to try out the above and report back if it fixes issues and how much of an impact on performance it has. Just for the record, I think Brian isn't suggesting we do anything differently with Sage. He's writing lots of _new_ code using Cython for his distributed matrix arrays project, and ran into this problem, and thought -- surely the Sage folks have solved this. Then he looked at our code for the solution and noticed that we haven't. That said, this is definitely not the most important thing for *us* to worry about at this point.We have many more important problems to solve first. But I'm really glad Brian is raising this issue, etc. -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Cython] Locally scoped dynamic memory (in SAGE and elsewhere)
Well, in the end you end up using sbrk() anyway, but I don't see what is wrong with malloc itself? sage_malloc was introduced a while back to make it possible to switch to a slab allocator like omalloc potentially to see if there is any benefit from it. And that makes sense. Absolutely not, but if you want to write exception safe extensions just write them in exception safe C++ using autoptr friends. While you might not be too concerned about performance here the issue is still debuggability. If you ran standard Python under valgrind (after disabling pymalloc) you will get I do think performance is important, but not at the expense of potential memory leaks. I don't have experience running valgrind with python, but from what I have gleaned from others, you need to run valgrind with valgrind-python.supp that is in the Misc directory of the Python source tree. Details are here: http://svn.python.org/projects/python/trunk/Misc/README.valgrind My impression from others is that the memory problems you are seeing here will go away if you use this .supp file. Not sure though. I do know that the python-devs use valgrind to detect real memory leaks and there is _no_ way that they actually have thousands of them. [EMAIL PROTECTED]:/scratch/mabshoff/release-cycle/sage-3.0.alpha2/local/bin$ valgrind --tool=memcheck --leak-resolution=high ./python ==12347== Memcheck, a memory error detector. ==12347== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==12347== Using LibVEX rev 1812, a library for dynamic binary translation. ==12347== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==12347== Using valgrind-3.4.0.SVN, a dynamic binary instrumentation framework. ==12347== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==12347== For more details, rerun with: -v ==12347== Python 2.5.1 (r251:54863, Apr 6 2008, 21:59:15) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2 Type help, copyright, credits or license for more information. ==12347== ==12347== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 9 from 2) ==12347== malloc/free: in use at exit: 599,274 bytes in 2,441 blocks. ==12347== malloc/free: 12,890 allocs, 10,449 frees, 2,420,712 bytes allocated. ==12347== For counts of detected errors, rerun with: -v ==12347== searching for pointers to 2,441 not-freed blocks. ==12347== checked 998,864 bytes. ==12347== ==12347== LEAK SUMMARY: ==12347==definitely lost: 0 bytes in 0 blocks. ==12347== possibly lost: 15,736 bytes in 54 blocks. ==12347==still reachable: 583,538 bytes in 2,387 blocks. ==12347== suppressed: 0 bytes in 0 blocks. So we have roughly 2,400 blocks of memory that Python itself cannot properly deallocate due to problems with their own garbage collection. See above. I will spare you the numbers for Sage (they are much worst due to still to be solved problems with Cython and extensions in general) and starting to poke for leaks in that pile of crap is not something I find appealing. Sure, once all mallocs in Sage are converted to sage_malloc one could switch and see what happens, but I can guarantee you that debugging some problem stemming from us doing something stupid with malloc compared to tracking it down inside Python is not a contest. Check out #1337 in our track to see such a case. True, malloc is more straightforward in that sense. And by the way: The python interpreter itself does leak some small bits of memory while running. So the above while it looks like a really good idea is far from a fool proof solution. Is your argument: there are already lots of memory leaks in python and sage so a few more is not a big deal? Brian Lisandro Dalcin (author of mpi4py) came up with the following trick that, while more complicated, prevents memory leaks: cdef extern from Python.h: object PyString_FromStringAndSize(char*,Py_ssize_t) char* PyString_AS_STRING(object) cdef inline object pyalloc_i(int size, int **i): if size 0: size = 0 cdef Py_ssize_t n = size * sizeof(int) cdef object ob = PyString_FromStringAndSize(NULL, n) i[0] = int* PyString_AS_STRING(ob) return ob and now def foo(sequence): cdef int size = len(sequence), cdef int *buf = NULL cdef object tmp = pyalloc_i(size, buf) This could probably be adapted into a malloc-like function. What do people think? We valgrind the complete test suite at least weekly and with ever increasing doctest coverage I don't see that we have a problem. Python's memory management has also some serious issues and I doubt it will offer any advantage for anything but loads of small allocs. And by switching to a slab allocator on our end will fix that problem. But, test test suite doesn't test for all of the odd input that users will feed to
[sage-devel] Re: [Cython] [sage-devel] Re: Locally scoped dynamic memory (in SAGE and elsewhere)
Just for the record, I think Brian isn't suggesting we do anything differently with Sage. He's writing lots of _new_ code using Cython for his distributed matrix arrays project, and ran into this problem, and thought -- surely the Sage folks have solved this. Then he looked at our code for the solution and noticed that we haven't. Very true. It is somewhat comforting to know that we are not crazy in wondering what the best solution to the problem is. We very well may punt and use malloc :) That said, this is definitely not the most important thing for *us* to worry about at this point.We have many more important problems to solve first. Understandable. Us too. But I'm really glad Brian is raising this issue, etc. -- William ___ Cython-dev mailing list [EMAIL PROTECTED] http://codespeak.net/mailman/listinfo/cython-dev --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Locally scoped dynamic memory (in SAGE and elsewhere)
Lisandro Dalcin (author of mpi4py) came up with the following trick that, while more complicated, prevents memory leaks: cdef extern from Python.h: object PyString_FromStringAndSize(char*,Py_ssize_t) char* PyString_AS_STRING(object) cdef inline object pyalloc_i(int size, int **i): if size 0: size = 0 cdef Py_ssize_t n = size * sizeof(int) cdef object ob = PyString_FromStringAndSize(NULL, n) i[0] = int* PyString_AS_STRING(ob) return ob and now def foo(sequence): cdef int size = len(sequence), cdef int *buf = NULL cdef object tmp = pyalloc_i(size, buf) This could probably be adapted into a malloc-like function. What do people think? Could you explain what the point is? Is it that this is a trick so that Cython will correctly garbage collect the allocated memory, even if an exception occurs? Yes, that is the idea. By having a python object that knows about the memory, the garbage collection should prevent memory leaks if an exception occurs. I am not sure if Lisandro has proved that this is the case - he is just wondering how people typically handle this case. Seems like we are not alone in thinking this is a problem though. Brian -- 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Cython] [sage-devel] Re: Locally scope d dynamic memory (in SAGE and elsewhere)
William Stein wrote: On Thu, Apr 10, 2008 at 10:02 AM, Michael.Abshoff [EMAIL PROTECTED] wrote: But, test test suite doesn't test for all of the odd input that users will feed to sage. These are the cases that will leak memory and there is not possible way to test for all of them. Also debugging memory leaks is super nasty. Compared to that pain, having a slightly slower memory allocator is not a big deal. Well, as long as you write code in C memory leaks when something goes wrong is something you have to live with. And python is far from perfect regarding memory management too IMHO as I point out above. Another issue is that once we have extensions that do work with threads we no longer can use Python's allocation since it isn't thread safe. Adding some more checks to the Sage codebase around allocations is something that ought to be done, but on the list of things to fix potential memory leaks from garbage input is low on the list of my personal priority as long as we have real leaks to deal with. Feel free to try out the above and report back if it fixes issues and how much of an impact on performance it has. Just for the record, I think Brian isn't suggesting we do anything differently with Sage. He's writing lots of _new_ code using Cython for his distributed matrix arrays project, and ran into this problem, and thought -- surely the Sage folks have solved this. Then he looked at our code for the solution and noticed that we haven't. Yes, without a doubt, but I am skeptical that that solution would work [Brian never claimed it did and actually raised that concern]. That said, this is definitely not the most important thing for *us* to worry about at this point.We have many more important problems to solve first. But I'm really glad Brian is raising this issue, etc. Sure and it is certainly good to be discussed. I didn't want to be dismissive about the idea, it is just that I have been in the debugging memory leaks in Cython extension trenches for the last eight months and hence I do not trust python or its memory management at all any more. And having been burned over and over again has left me the way I am ;) -- William Cheers, Michael ___ Cython-dev mailing list [EMAIL PROTECTED] http://codespeak.net/mailman/listinfo/cython-dev --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Cython] [sage-devel] Re: Locally scoped dynamic memory (in SAGE and elsewhere)
Sure and it is certainly good to be discussed. I didn't want to be dismissive about the idea, it is just that I have been in the debugging memory leaks in Cython extension trenches for the last eight months and hence I do not trust python or its memory management at all any more. And having been burned over and over again has left me the way I am ;) Your comments make more sense in this light. Sounds painful :) Just our of curiosity - are the problem with cython itself or how people are using/misusing it? Brian -- William Cheers, Michael ___ Cython-dev mailing list [EMAIL PROTECTED] http://codespeak.net/mailman/listinfo/cython-dev ___ Cython-dev mailing list [EMAIL PROTECTED] http://codespeak.net/mailman/listinfo/cython-dev --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Cython] Locally scoped dynamic memory (in SAGE and elsewhere)
Brian Granger wrote: Hi Brian, Well, in the end you end up using sbrk() anyway, but I don't see what is wrong with malloc itself? sage_malloc was introduced a while back to make it possible to switch to a slab allocator like omalloc potentially to see if there is any benefit from it. And that makes sense. Absolutely not, but if you want to write exception safe extensions just write them in exception safe C++ using autoptr friends. While you might not be too concerned about performance here the issue is still debuggability. If you ran standard Python under valgrind (after disabling pymalloc) you will get I do think performance is important, but not at the expense of potential memory leaks. Sure, we want both. I don't have experience running valgrind with python, but from what I have gleaned from others, you need to run valgrind with valgrind-python.supp that is in the Misc directory of the Python source tree. Details are here: http://svn.python.org/projects/python/trunk/Misc/README.valgrind My impression from others is that the memory problems you are seeing here will go away if you use this .supp file. Not sure though. No, they are not. Suppressing still reachable memory doesn't make the problem go away. It is just a cosmetic solution and hides real bugs. I do know that the python-devs use valgrind to detect real memory leaks and there is _no_ way that they actually have thousands of them. Well, those aren't technically leaks, but memory that is not properly deallocated at exit. The amount is more or less constant independent on how long you run a python session. The amount usually grows once you import more modules and it is a bug in my book if you do not properly dealloc all memory and let the heap tear down at the program exit take care of it. What happens is that if you do not free a reference for some piece of memory and you do that repeatedly in your code you end up with a lot of stale memory chunks that all get reaped at exit as still reachable. And that is a very real problem if you chose to ignore those chunks since the system frees them at python's exit anyway. I have found a bug like that for example in Singular where the slab allocator did hide the problem, so this is a real issue. [EMAIL PROTECTED]:/scratch/mabshoff/release-cycle/sage-3.0.alpha2/local/bin$ valgrind --tool=memcheck --leak-resolution=high ./python ==12347== Memcheck, a memory error detector. ==12347== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. ==12347== Using LibVEX rev 1812, a library for dynamic binary translation. ==12347== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==12347== Using valgrind-3.4.0.SVN, a dynamic binary instrumentation framework. ==12347== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==12347== For more details, rerun with: -v ==12347== Python 2.5.1 (r251:54863, Apr 6 2008, 21:59:15) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2 Type help, copyright, credits or license for more information. ==12347== ==12347== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 9 from 2) ==12347== malloc/free: in use at exit: 599,274 bytes in 2,441 blocks. ==12347== malloc/free: 12,890 allocs, 10,449 frees, 2,420,712 bytes allocated. ==12347== For counts of detected errors, rerun with: -v ==12347== searching for pointers to 2,441 not-freed blocks. ==12347== checked 998,864 bytes. ==12347== ==12347== LEAK SUMMARY: ==12347==definitely lost: 0 bytes in 0 blocks. ==12347== possibly lost: 15,736 bytes in 54 blocks. ==12347==still reachable: 583,538 bytes in 2,387 blocks. ==12347== suppressed: 0 bytes in 0 blocks. So we have roughly 2,400 blocks of memory that Python itself cannot properly deallocate due to problems with their own garbage collection. See above. I will spare you the numbers for Sage (they are much worst due to still to be solved problems with Cython and extensions in general) and starting to poke for leaks in that pile of crap is not something I find appealing. Sure, once all mallocs in Sage are converted to sage_malloc one could switch and see what happens, but I can guarantee you that debugging some problem stemming from us doing something stupid with malloc compared to tracking it down inside Python is not a contest. Check out #1337 in our track to see such a case. True, malloc is more straightforward in that sense. And by the way: The python interpreter itself does leak some small bits of memory while running. So the above while it looks like a really good idea is far from a fool proof solution. Is your argument: there are already lots of memory leaks in python and sage so a few more is not a big deal? No: My argument is that the solution you suggested is not something that will work in the general case, but obfuscate real problems at the expense of
[sage-devel] Re: Locally scoped dynamic memory (in SAGE and elsewhere)
On Apr 10, 2008, at 9:51 AM, Brian Granger wrote: Hi, (dual posted to sage and cython) A few of us (ipython and mpi4py devs) are wondering what the best/safest way of allocating dynamic memory in a local scope (method/function) is when using cython. An example would be if you need an array of c ints that is locally scoped. The big question is how to make sure that the memory gets freed - even if something goes wrong in the function/method. That is, you want to prevent memory leaks. It looks like in sage, the sage_malloc/sage_free functions are used for this purpose: from sage/graphs/graph_isom.pyx: 176def incorporate_permutation(self, gamma): 202cdef int *_gamma = int * sage_malloc( n * sizeof (int) ) 203if not _gamma: 204raise MemoryError(Error allocating memory.) 205for k from 0 = k n: 206_gamma[k] = gamma[k] 207self._incorporate_permutation(_gamma, n) 208sage_free(_gamma) Because sage_malloc is #defined to malloc in stdsage.h, I think there is a significant potential for memory leaks in code like this. Are we thinking correctly on this issue? Isn't this a huge problem? Lisandro Dalcin (author of mpi4py) came up with the following trick that, while more complicated, prevents memory leaks: cdef extern from Python.h: object PyString_FromStringAndSize(char*,Py_ssize_t) char* PyString_AS_STRING(object) cdef inline object pyalloc_i(int size, int **i): if size 0: size = 0 cdef Py_ssize_t n = size * sizeof(int) cdef object ob = PyString_FromStringAndSize(NULL, n) i[0] = int* PyString_AS_STRING(ob) return ob and now def foo(sequence): cdef int size = len(sequence), cdef int *buf = NULL cdef object tmp = pyalloc_i(size, buf) This could probably be adapted into a malloc-like function. What do people think? This is actually the same solution that popped into my mind when I first read your question, and I think it is a very good one. Using string objects is particularly interesting because the they are highly optimized (for example, the buffer allocation is done as part of the object allocation). I would probably have it take a void** rather than make an allocator specific to ints. If people like this idea, I could add such a function to Sage. Maybe it would even be worthwhile adding it to Cython (in one of the included header files). Alternatively, using a try-finally will work. If the buffers all are set to start as NULL then one just frees the non-NULL buffers at the end (so one doesn't have to keep track of where in the procedure things went wrong). - Robert --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Cython] [sage-devel] Re: Locally scoped dynamic memory (in SAGE and elsewhere)
Brian Granger wrote: Hi Brian, Sure and it is certainly good to be discussed. I didn't want to be dismissive about the idea, it is just that I have been in the debugging memory leaks in Cython extension trenches for the last eight months and hence I do not trust python or its memory management at all any more. And having been burned over and over again has left me the way I am ;) Your comments make more sense in this light. Sounds painful :) Just our of curiosity - are the problem with cython itself or how people are using/misusing it? It is a general problem when writing extensions and Cython [via code written by Robert Bradshaw] has started to add code to deal with the situation. But the deallocation code can cause trouble when extensions are carefully written (i.e. interdependencies) and I hope that during Dev1 I will have time to delve into this. If I had time I would lock myself in a room with the Python code for two weeks and try to figure this out. So far that hasn't happened yet du to lack of time. Maybe I need to go on vacation for two weeks where due to unforeseen circumstances I cannot be reached ;) Brian 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Cython] [sage-devel] Re: Locally scoped dynamic memory (in SAGE and elsewhere)
On Apr 10, 2008, at 11:10 AM, Michael.Abshoff wrote: Brian Granger wrote: Hi Brian, Sure and it is certainly good to be discussed. I didn't want to be dismissive about the idea, it is just that I have been in the debugging memory leaks in Cython extension trenches for the last eight months and hence I do not trust python or its memory management at all any more. And having been burned over and over again has left me the way I am ;) Your comments make more sense in this light. Sounds painful :) Just our of curiosity - are the problem with cython itself or how people are using/misusing it? It is a general problem when writing extensions and Cython [via code written by Robert Bradshaw] has started to add code to deal with the situation. But the deallocation code can cause trouble when extensions are carefully written (i.e. interdependencies) and I hope that during Dev1 I will have time to delve into this. To rephrase the problem, as the Python interpreter and environment get torn down, it becomes less and less safe to run the code invoked by deallocating objects. Most people don't worry about this because the whole process is about to be terminated, releasing all requested memory, but it does produce noise if one is trying to do memory profiling (e.g. with valgrind). - Robert --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Fwd: [soc2008-mentors] SymPy apps -- looking for comments and mentors
This may be of interest to Sage. Begin forwarded message: From: Ondrej Certik [EMAIL PROTECTED] Date: April 10, 2008 12:36:47 PM PDT To: [EMAIL PROTECTED] Subject: [soc2008-mentors] SymPy apps -- looking for comments and mentors Hi, there are 10 applications for SymPy at PSF, some of them are very good, so it's difficult to sort them (especially pick up the best one). We would be very interested, if you could comment on them and give us more feedback -- is it useful for the Python community? Is it useful to you? To the scientific community (SciPy, Sage, ...), etc? Of course we know the applicants more than you probably do, but if google is going to give only 22 slots to PSF and if sympy apps fits into those 22 slots, we'd have to pick the best app, so it'd be very useful for us to have more feedback on them. For example we'd appreciate more input on [5] (especially from the Sage people), how much useful you think it is. Here they are sorted roughly from the best one to the worst: [1] SymPy: Improving the Plotting Module and a Pure Python TeX Engine http://code.google.com/soc/2008/psf/app.html? csaid=ORcMXRhQQS4PGBQJEgJdHSIKNUkCQw5VCiNXOklWElJXAXRXbA%3D%3D%0A [2] SymPy: robust high-precision numerical evaluation http://code.google.com/soc/2008/psf/app.html? csaid=PgEBFxlYWG8PNxsFHRhCXC8lPx4FGgcfUC4IYkNVRg9UAXcEYkBcSlpQBnFR%0A [3] Creating a GTK based GUI for Sympy http://code.google.com/soc/2008/psf/app.html? csaid=KBsNHwJBQ28WLAEFEABxVCwEMR9KEARcCSdQbksBEV9XCXMGaBVSRwpU%0A [4] Sympy: Definite Integration via Integration in the Complex Plane http://code.google.com/soc/2008/psf/app.html? csaid=KhoeFApDHSwANB8FMwxcUigJdhALHlFXUCNSPkJVQVEDVyNTPEUGRg%3D%3D%0A [5] Improving number theory and graph theory modules in sympy http://code.google.com/soc/2008/psf/app.html? csaid=PB9KFARERykENTMDHgpYX28GNx5eFV5XV3RcYUpeRFkJAHcBPks%3D%0A [6] SymPy:A Logic Algebra Module for SymPy http://code.google.com/soc/2008/psf/app.html? csaid=KBYKFBtQXTIRPQEkFAZQWi1LOxwJSQ4IAHlVbktTSUYFB3QEahJdRQ%3D%3D%0A [7] SymPy: Improvement for Ordinary Differential Equations Solver http://code.google.com/soc/2008/psf/app.html? csaid=KBYKFBtQXTIRPQEkFAZQWi1LOxwJSVsEACQDaxFTSUYDVXEHORVdEA%3D%3D%0A [8] SymPy : Implementing the recursive Risch integration algorithm http://code.google.com/soc/2008/psf/app.html? csaid=OV0PGh9eRi8MGBQJEgJdHSIKNUkCRg1QViBda0lJRA1TUidRaUI%3D%0A [9] 2-Fold improvement to SymPy - Generalized Functions Diffy Qs http://code.google.com/soc/2008/psf/app.html? csaid=KxYWEhtZHTkOPQokFAZQWi1LOxwJSVlTBXkAOkcFSVlVAHYDPENT%0A [10] Generalized Functions for SymPy http://code.google.com/soc/2008/psf/app.html? csaid=ORgFBwpDWjgEaTMDHgpYX28GNx5eQQkFAXlXbEFeXlkJUXdSPEIB%0A And we have these potential mentors: 1) Ondrej Certik 2) Kirill Smelkov 3) Mateusz Paprocki 4) Michael Droettboom If there is anyone else who would be available for mentoring, or act as a backup mentor, please let us know. If google only gives 22 slots to PSF, I think we can easily cover all possible sympy projects with our current mentors, but just in case. Currently we have the first four applications that have 4 points. There is also a slight chance, that one SymPy project will get accepted at the Portland State University. You can see the last year SymPy's involvement in GSoC here: http://code.google.com/p/sympy/wiki/GSoC2007 We had 3 students at PSF and 2 elsewhere. Thanks, Ondrej ___ soc2008-mentors mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/soc2008-mentors --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: p-adic crash error
I think Willem fixed this bug. I've made the same change a few other
places and added a doctest.
David
On Mon, Apr 7, 2008 at 11:16 AM, Kiran Kedlaya [EMAIL PROTECTED] wrote:
Jen Balakrishnan spent time with some of the usual suspects during the
Arizona Winter School tracking down bugs in the p-adics, but more
remain. We've isolated a code snippet that makes sage 2.11 go boom on
multiple platforms:
{{{
sage: R.x = QQ[]
sage: K = Qp(11,10)
sage: J.a = K.extension(x^30-11)
sage: M.t = PowerSeriesRing(J)
sage: S.x,y = QQ[]
sage: xr = O(a^152)*t + (8*a^2 + 10*a^32 + 7*a^62 + 10*a^92 + 7*a^122
+ O(a^152))*t^2 + O(a^154)*t^3 + (2*a^4 + 10*a^64 + 2*a^124 +
O(a^154))*t^4 + O(a^156)*t^5 + (5*a^6 + 2*a^96 + a^126 + O(a^156))*t^6
+ O(a^158)*t^7 + (7*a^8 + 6*a^38 + 8*a^68 + 2*a^98 + 5*a^128 +
O(a^158))*t^8 + O(a^160)*t^9 + (8*a^10 + 10*a^40 + a^70 + 5*a^130 +
O(a^160))*t^10 + O(a^162)*t^11 + (9*a^12 + 7*a^42 + 8*a^72 + 6*a^102 +
9*a^132 + O(a^162))*t^12 + O(a^164)*t^13 + (2*a^14 + 5*a^44 + 3*a^74 +
a^104 + 4*a^134 + O(a^164))*t^14 + O(a^166)*t^15 + (2*a^16 + 5*a^46 +
8*a^76 + 5*a^106 + 7*a^136 + O(a^166))*t^16 + O(a^168)*t^17 + (7*a^18
+ 3*a^48 + 6*a^78 + 9*a^138 + O(a^168))*t^18 + O(a^172)*t^19 + (7*a^50
+ 3*a^80 + 5*a^110 + 5*a^140 + 7*a^170 + O(a^172))*t^20 +
O(a^172)*t^21 + (a^22 + a^52 + 3*a^82 + 3*a^112 + 2*a^142 +
O(a^172))*t^22 + O(a^174)*t^23 + (4*a^24 + 7*a^54 + 9*a^84 + 4*a^114 +
7*a^144 + O(a^174))*t^24 + O(a^176)*t^25 + (3*a^26 + 8*a^56 + 8*a^116
+ 5*a^146 + O(a^176))*t^26 + O(a^178)*t^27 + (2*a^28 + 2*a^58 + 6*a^88
+ a^118 + 10*a^148 + O(a^178))*t^28 + O(a^180)*t^29 + (8*a^30 + 5*a^60
+ 8*a^90 + 5*a^120 + 6*a^150 + O(a^180))*t^30 + O(a^184)*t^31 +
(7*a^62 + 9*a^92 + 2*a^182 + O(a^184))*t^32
sage: yr = xr^2
sage: dtr = xr.derivative()
sage: f_dtr = yr*dtr # boom
FFTRep: inconsistent use
(and then sage exits uncleanly)
}}}
I wasn't able to find a shorter value of xr that reproduces this
(removing the t^32 term alleviates the error).
We've opened ticket #2843 for this.
Kiran
--~--~-~--~~~---~--~~
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://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: tick marks
Just to illustrate, the results of something like plot(sin(40*x),(1.96,2.04)) are intriguing -gerhard --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Final Push for 3.0 this weekend
Also, I'd like to request that people test the notebook in their favorite browser. William and I have made some pretty substantial changes; while I think we've caught most of the major bugs, we definately haven't caught them all. Get alpha4, or apply #2869 to alpha3. http://trac.sagemath.org/sage_trac/ticket/2869 Thanks! On Thu, 10 Apr 2008, mabshoff wrote: Hello folks, it has been eleven days since the last stable Sage release and I can imagine that William is getting jittery for another release. So I would suggest that interested parties meet in IRC Saturday and/or Sunday for some final push to get 3.0 ready for release. What needs to be done? * General ticket review * #2344: [with spkg, needs review, additional work] python -- upgrade to version 2.5.2 * #2822: PolyBoRi segfault at exit issue * #2851: clean binary install of sage followed by sage -br is broken * gcc 4.3 [mabshoff] * MacIntel 64 bit [mabshoff] The usual other things can also help out, i.e. writing doctests and fixing other bugs. For tickets with patches that might need review/some additional work see http://trac.sagemath.org/sage_trac/report/13 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Introductory Cython talk
Hi, Robert Bradshaw gave a very introductory talk about Cython yesterday to my undergraduate class, which I video'd and uploaded to google video here: http://wiki.wstein.org/2008/480a/schedule/2008-04-09 (The aspect ratio is wrong... sigh, but otherwise the video works fine.) -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: tick marks
On Thu, Apr 10, 2008 at 4:01 PM, gerhard [EMAIL PROTECTED] wrote: Just to illustrate, the results of something like plot(sin(40*x),(1.96,2.04)) are intriguing The output in Sage now is just plain crap and totally wrong. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Fwd: tick mark bundle
-- Forwarded message -- From: Gerhard Ertaler [EMAIL PROTECTED] Date: Wed, Apr 9, 2008 at 4:56 PM Subject: tick mark bundle To: [EMAIL PROTECTED] The code replaces the _tastefulticks routine in axes.py without altering the API. It would be trivial to allow the user to specify the number of ticks required (currently hardcoded), and to extract a common power of 10 to declutter the printed labels. -gerhard Gesendet von Yahoo! Mail. Der Lieblings-Mailbox der Welt. -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~--- mybundle.hg Description: Binary data
[sage-devel] Fwd: tick mark bundle
I should say, I'm forwarding this code to sage-devel in the hopes that somebody can do something to it, since I'm too busy right now. -- Forwarded message -- From: William Stein [EMAIL PROTECTED] Date: Thu, Apr 10, 2008 at 5:36 PM Subject: Fwd: tick mark bundle To: sage-devel@googlegroups.com sage-devel@googlegroups.com -- Forwarded message -- From: Gerhard Ertaler [EMAIL PROTECTED] Date: Wed, Apr 9, 2008 at 4:56 PM Subject: tick mark bundle To: [EMAIL PROTECTED] The code replaces the _tastefulticks routine in axes.py without altering the API. It would be trivial to allow the user to specify the number of ticks required (currently hardcoded), and to extract a common power of 10 to declutter the printed labels. -gerhard Gesendet von Yahoo! Mail. Der Lieblings-Mailbox der Welt. -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~--- mybundle.hg Description: Binary data
[sage-devel] Re: p-adic crash error
On Apr 11, 12:35 am, David Roe [EMAIL PROTECTED] wrote: I think Willem fixed this bug. I've made the same change a few other places and added a doctest. David Hi David, I posted a one line patch to make you patch compile. It is attached to #2843. Can you have a look? craigcitro just said in IRC that you intend to remove the extra _a 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Introductory Cython talk
Ahhh, this helps a lot. I have been needing more cython help, and I think this will get me about 90% there. -M. Hampton On Apr 10, 6:31 pm, William Stein [EMAIL PROTECTED] wrote: Hi, Robert Bradshaw gave a very introductory talk about Cython yesterday to my undergraduate class, which I video'd and uploaded to google video here: http://wiki.wstein.org/2008/480a/schedule/2008-04-09 (The aspect ratio is wrong... sigh, but otherwise the video works fine.) -- William Stein Associate Professor of Mathematics University of Washingtonhttp://wstein.org --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Build Error
Just got this build error that told me to post it here: mpn_extras.o:mpn_extras.c:(.text+0x2630): first defined here collect2: ld returned 1 exit status make[2]: *** [libflint.so] Error 1 make[2]: Leaving directory `/home/zarathustra/Download/sage-3.0.alpha3/ spkg/build/flint-1.06.p2/src' Error building flint shared library. real0m23.087s user0m22.184s sys 0m0.559s sage: An error occurred while installing flint-1.06.p2 Please email sage-devel http://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/zarathustra/Download/sage-3.0.alpha3/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/zarathustra/Download/sage-3.0.alpha3/spkg/build/flint-1.06.p2 and type 'make'. Instead type /home/zarathustra/Download/sage-3.0.alpha3/sage -sh in order to set all environment variables correctly, then cd to /home/zarathustra/Download/sage-3.0.alpha3/spkg/build/flint-1.06.p2 (When you are done debugging, you can type exit to leave the subshell.) make[1]: *** [installed/flint-1.06.p2] Error 1 make[1]: Leaving directory `/home/zarathustra/Download/sage-3.0.alpha3/ spkg' real19m40.074s user17m33.744s sys 1m27.617s Any advice? --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Build Error
On Apr 11, 5:02 am, Walt [EMAIL PROTECTED] wrote: Just got this build error that told me to post it here: mpn_extras.o:mpn_extras.c:(.text+0x2630): first defined here collect2: ld returned 1 exit status make[2]: *** [libflint.so] Error 1 make[2]: Leaving directory `/home/zarathustra/Download/sage-3.0.alpha3/ spkg/build/flint-1.06.p2/src' Error building flint shared library. real 0m23.087s user 0m22.184s sys 0m0.559s sage: An error occurred while installing flint-1.06.p2 Please email sage-develhttp://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/zarathustra/Download/sage-3.0.alpha3/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/zarathustra/Download/sage-3.0.alpha3/spkg/build/flint-1.06.p2 and type 'make'. Instead type /home/zarathustra/Download/sage-3.0.alpha3/sage -sh in order to set all environment variables correctly, then cd to /home/zarathustra/Download/sage-3.0.alpha3/spkg/build/flint-1.06.p2 (When you are done debugging, you can type exit to leave the subshell.) make[1]: *** [installed/flint-1.06.p2] Error 1 make[1]: Leaving directory `/home/zarathustra/Download/sage-3.0.alpha3/ spkg' real 19m40.074s user 17m33.744s sys 1m27.617s Any advice? Hi, this is way to little to do any kind of debugging. Are you using gcc 4.3 by any chance? If so you are out of luck until 3.0 (out early next week) which will support gcc 4.3. Id you are not using gcc 4.3 please gzip up install.log, upload it to the net somewhere and post a link here. Do not attach the log to an email. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Build Error
Yep, I'm using gcc 4.3.0. On Apr 10, 11:07 pm, mabshoff [EMAIL PROTECTED] dortmund.de wrote: On Apr 11, 5:02 am, Walt [EMAIL PROTECTED] wrote: Just got this build error that told me to post it here: mpn_extras.o:mpn_extras.c:(.text+0x2630): first defined here collect2: ld returned 1 exit status make[2]: *** [libflint.so] Error 1 make[2]: Leaving directory `/home/zarathustra/Download/sage-3.0.alpha3/ spkg/build/flint-1.06.p2/src' Error building flint shared library. real 0m23.087s user 0m22.184s sys 0m0.559s sage: An error occurred while installing flint-1.06.p2 Please email sage-develhttp://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/zarathustra/Download/sage-3.0.alpha3/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/zarathustra/Download/sage-3.0.alpha3/spkg/build/flint-1.06.p2 and type 'make'. Instead type /home/zarathustra/Download/sage-3.0.alpha3/sage -sh in order to set all environment variables correctly, then cd to /home/zarathustra/Download/sage-3.0.alpha3/spkg/build/flint-1.06.p2 (When you are done debugging, you can type exit to leave the subshell.) make[1]: *** [installed/flint-1.06.p2] Error 1 make[1]: Leaving directory `/home/zarathustra/Download/sage-3.0.alpha3/ spkg' real 19m40.074s user 17m33.744s sys 1m27.617s Any advice? Hi, this is way to little to do any kind of debugging. Are you using gcc 4.3 by any chance? If so you are out of luck until 3.0 (out early next week) which will support gcc 4.3. Id you are not using gcc 4.3 please gzip up install.log, upload it to the net somewhere and post a link here. Do not attach the log to an email. 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Fwd: use zip instead of 7zip for distributing the sage binary
+1 for firefox website architecture style On Apr 10, 12:08 pm, Harald Schilly [EMAIL PROTECTED] wrote: On Apr 10, 4:40 pm, William Stein [EMAIL PROTECTED] wrote: The right thing to do is to make Sage easier to install. Yes, of course, I wanted to point out where the problem is and how it could be handled, the current issue with the Windows install, in my opinion, is the lack of a native port. And then MSI!! MSI is necessary, because system administrators for networks of computers use them like linux packages to push-install them on all machines .. that's impossible for .exe setups !. so, i think, that's the best solution, but i know this is not done until tomorrow... (and there are admins who _only_ take msi packages and forget about the rest ... too much work) @webpage: On Apr 10, 6:04 pm, Martin Albrecht [EMAIL PROTECTED] wrote: Btw. I think Harald is working on redesigning the website anyway. Yes, I'll try to make it easier ... less text, less clicks, gives a higher information density. But it's also not done until tomorrow. Personally, I don't like the firefox install site, but i'll collect all ideas and mix something up. Harald --~--~-~--~~~---~--~~ 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: p-adic crash error
No, I forgot to change it back. Use the patch I posted instead, which changes all the eis_shift_a's back to eis_shift. The p-adics folder passes sage -t now. David On Thu, Apr 10, 2008 at 8:53 PM, mabshoff [EMAIL PROTECTED] wrote: On Apr 11, 12:35 am, David Roe [EMAIL PROTECTED] wrote: I think Willem fixed this bug. I've made the same change a few other places and added a doctest. David Hi David, I posted a one line patch to make you patch compile. It is attached to #2843. Can you have a look? craigcitro just said in IRC that you intend to remove the extra _a 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://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Final Push for 3.0 this weekend
On Apr 11, 1:01 am, [EMAIL PROTECTED] wrote: Also, I'd like to request that people test the notebook in their favorite browser. William and I have made some pretty substantial changes; while I think we've caught most of the major bugs, we definately haven't caught them all. Get alpha4, or apply #2869 to alpha3. http://trac.sagemath.org/sage_trac/ticket/2869 Thanks! Yep, people should really do that. The current Notebook code in alpha3 should support Safari 3.1. For all those people with gcc 4.3 out there: [EMAIL PROTECTED] sage-3.0.alpha3]$ gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable- languages=c,c++,fortran,objc,obj-c++,treelang --enable-threads=posix -- mandir=/usr/share/man --enable-__cxa_atexit --disable-multilib -- libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable- libstdcxx-pch --with-tune=generic Thread model: posix gcc version 4.3.0 (GCC) [EMAIL PROTECTED] sage-3.0.alpha3]$ ./sage -- | SAGE Version 3.0.alpha3, Release Date: 2008-04-09 | | Type notebook() for the GUI, and license() for information.| -- sage: 1+1 2 sage: Exiting SAGE (CPU time 0m0.01s, Wall time 0m2.67s). That build is actually on an arch linux x86-64 image, so we will have binaries for that platform from 3.0 forward. I will merge all the build fixes into alpha4 and release that in the next 16 hours. 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://www.sagemath.org -~--~~~~--~~--~--~---
