[sage-devel] Aren't the interfaces supposed to be unique parents??
Dear all, I thought that the interfaces to gap, singular, maxima etc. are considered to be unique parents. Apparently gap and singular are, but maxima is only half ways unique: -- | Sage Version 4.0, Release Date: 2009-05-29 | | Type notebook() for the GUI, and license() for information.| -- sage: 1._singular_().parent() is x._singular_().parent() True sage: 1._gap_().parent() is x._gap_().parent() True sage: 1._maxima_().parent() is 2._maxima_().parent() True sage: 1._maxima_().parent() is x._maxima_().parent() False sage: quit Exiting SAGE (CPU time 0m0.12s, Wall time 0m22.97s). Exiting spawned Singular process. Exiting spawned Gap process. Exiting spawned Maxima process. Exiting spawned Maxima process. Is this something to worry about? Cheers Simon --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Aren't the interfaces supposed to be unique parents??
Hello, On Sat, Jun 6, 2009 at 12:31 AM, Simon King wrote: > > Dear all, > > I thought that the interfaces to gap, singular, maxima etc. are > considered to be unique parents. Apparently gap and singular are, but > maxima is only half ways unique: Each expect interface parent corresponds to a session. So, if you want to make a new GAP session, you'd just do sage; g = Gap() For the interfaces to Maxima, the calculus code has its on session that it uses. It's parent is in sage.calculus.calculus.maxima rather than the default maxima object which corresponds to sage.interfaces.maxima.maxima --Mike --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0.1.rc0 (rc2)
On Fri, 5 Jun 2009 20:31:51 -0700 (PDT)
Marshall Hampton wrote:
>
> I had two failures on an intel mac running 10.4 (for rc2):
>
> sage -t "devel/sage/sage/numerical/optimize.py"
> sage -t "devel/sage/sage/symbolic/relation.py"
These are all caused by making the hashes of symbolic variables random
again to fix the segfault in #6163. It seems that Mike already fixed
them in #6230.
Cheers,
Burcin
> The relation.py failures:
>
> sage -t "devel/sage/sage/symbolic/relation.py"
> **
> File "/Volumes/D/wildsage2/devel/sage/sage/symbolic/relation.py", line
> 434:
> sage: solutions=solve([x^2+y^2 == 1, y^2 == x^3 + x + 1], x, y,
> solution_dict=True); solutions
> Expected:
> [{y: -1/2*sqrt(-I*sqrt(3) + 3)*sqrt(2), x: -1/2*I*sqrt(3) - 1/2},
> {y: 1/2*sqrt(-I*sqrt(3) + 3)*sqrt(2), x: -1/2*I*sqrt(3) - 1/2}, {y:
> -1/2*sqrt(I*sqrt(3) + 3)*sqrt(2), x: 1/2*I*sqrt(3) - 1/2}, {y:
> 1/2*sqrt (I*sqrt(3) + 3)*sqrt(2), x: 1/2*I*sqrt(3) - 1/2}, {y: -1, x:
> 0}, {y: 1, x: 0}]
> Got:
> [{x: -1/2*I*sqrt(3) - 1/2, y: -1/2*sqrt(-I*sqrt(3) + 3)*sqrt(2)},
> {x: -1/2*I*sqrt(3) - 1/2, y: 1/2*sqrt(-I*sqrt(3) + 3)*sqrt(2)}, {x:
> 1/2*I*sqrt(3) - 1/2, y: -1/2*sqrt(I*sqrt(3) + 3)*sqrt(2)}, {x:
> 1/2*I*sqrt(3) - 1/2, y: 1/2*sqrt(I*sqrt(3) + 3)*sqrt(2)}, {x: 0, y:
> -1}, {x: 0, y: 1}]
> **
> File "/Volumes/D/wildsage2/devel/sage/sage/symbolic/relation.py", line
> 553:
> sage: solve_mod([5*x + y == 3, 2*x - 3*y == 9], 3*5*7*11*19*23*29,
> solution_dict = True)
> Expected:
> [{y: 8610183, x: 12915279}]
> Got:
> [{x: 12915279, y: 8610183}]
>
>
> and the optimize.py failure:
>
> sage -t "devel/sage/sage/numerical/optimize.py"
> **
> File "/Volumes/D/wildsage2/devel/sage/sage/numerical/optimize.py",
> line 558:
> sage: find_fit(data, f, parameters = [a, b, c], variables = [x],
> solution_dict = True)
> Expected:
> {c: 0.19..., b: 0.49..., a: 1.21...}
> Got:
> {a: 1.2149883277029359, b: 0.49754483643114439, c:
> 0.19453491569812351}
>
>
> -M. Hampton
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: "What can Magma do that Sage can't do?"
On Jun 6, 3:47 am, William Stein wrote: > * Galois theory and ramification groups for p-adic extensions (needs > the previous features) I wrote a (very simplistic) implementation of Artin symbols and decomposition and ramification groups a few months back for extensions of *number fields*, so we have this via the canonical dumb algorithm: find an extension of number fields whose local extension at some prime is the p-adic extension you want. > VII. Modules > > * Sage has nothing for modules over Dedekind domains (except over > ZZ): this is an extremely important building block for certain > algorithms (e.g., arithmetic in quaternion algebras over number > fields), so needs to get implemented. I recently wrote code for > general modules over ZZ, but it isn't in Sage yet. > > PROJECT: Finish modules over ZZ, optimize > > PROJECT: Extend modules over ZZ to modules over a PID Last week I wrote some code for Hermite form, which is the key linear- algebra step for this; see trac #6178. So we have free modules over an arbitrary PID (me) and arbitrary fg modules over ZZ (you), and combining these probably won't be very hard. David --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Can gmp-4.2.3 & mpfr-2.3.2 be moved to the T2 to build gcc ??
On Sat, Jun 6, 2009 at 8:05 AM, Dr. David Kirkby wrote: > > I've downloaded gcc 4.4.0 with a view to building this to try to get rid > of the internal compiler bug on the T2. > As a general question to the list: I understand that sage is designed to be built by just typing make on any platform. Is there a general problem when people use compilers other than gcc and, it seems, a particular gcc version? The following have been my casual experience. Attempts to build sage 4.0 on ia64 SLES10SP1 failed using the intel compiler. Problems with gmp-mpir were overcome by unloading the Intel compiler module from my shell ( icc 9.1.051). gcc 4,1,2 was then used on all compiles and it then sailed on happily until polybori when that failed, [The ia64 issues have not been high on the list of priorities because I do not have a need for my model to run on that architecture. I had a test box I had reassembled and wanted to exercise it so a sage test build seemed like a good idea.] Anthony David > I looked at an install.log of one of my builds of Sage using the Solaris > binaries from Micheal and see the compiler was configured with: > > > GCC Version > gcc -v > Using built-in specs. > Target: sparc-sun-solaris2.10 > Configured with: ../gcc-4.3.2/configure > --prefix=/home/mabshoff/sparc-solaris-toolchain/ > --enable-languages=c,c++,fortran --with-gnu-ld > --with-ld=/home/mabshoff/sparc-solaris-toolchain/bin/ld --with-gnu-as > --with-as=/home/mabshoff/sparc-solaris-toolchain/bin/as > --with-gmp=/usr/local/gmp-4.2.3/sparc-SunOS-gcc-4.3.1-abi32/ > --with-mpfr=/usr/local/mpfr-2.3.2/sparc-SunOS-gmp-4.2.3-gcc-4.3.1-abi32/ > > > > > Is it possible to move those > > /usr/local/gmp-4.2.3/sparc-SunOS-gcc-4.3.1-abi32/ and > /usr/local/mpfr-2.3.2/sparc-SunOS-gmp-4.2.3-gcc-4.3.1-abi32/ > > to somewhere on the T2, so I can configure gcc to use them and build gcc > 4.4.0? > > > If those are known to work (on most machines anyway), I'd rather use > them than download the sources and compile gmp and mpfr. > > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: "What can Magma do that Sage can't do?"
Two or three things: 1. Rational conics. Magma first implemented my algorithms, which are in eclib but not wrapped, so we could do a lot quite easily there. But now Magma uses Denis Simon's algorithm which is better in certain cases, and he would certainly donate his code (in gp I think). 2. Elliptic curves over function fields: quite a bit of what Magma has came from my student David Roberts, whose thesis in 2007 was about this. I have his code. 3. 4-descent in Magma was developed first by my student Tom Womack, though later tidied up quite a lot in Sydney. I have all Tom's code. 4. Other descents on elliptic curves, and "genus one models": mostly written by Tom Fisher who has not (yet!) started to use Sage; but he is implementing algorithms developed jointly by himself, me Stoll, Simon and others, and may well be willing to donate his code to Sage. John 2009/6/6 davidloeffler : > > On Jun 6, 3:47 am, William Stein wrote: > >> * Galois theory and ramification groups for p-adic extensions (needs >> the previous features) > > I wrote a (very simplistic) implementation of Artin symbols and > decomposition and ramification groups a few months back for extensions > of *number fields*, so we have this via the canonical dumb algorithm: > find an extension of number fields whose local extension at some prime > is the p-adic extension you want. > >> VII. Modules >> >> * Sage has nothing for modules over Dedekind domains (except over >> ZZ): this is an extremely important building block for certain >> algorithms (e.g., arithmetic in quaternion algebras over number >> fields), so needs to get implemented. I recently wrote code for >> general modules over ZZ, but it isn't in Sage yet. >> >> PROJECT: Finish modules over ZZ, optimize >> >> PROJECT: Extend modules over ZZ to modules over a PID > > Last week I wrote some code for Hermite form, which is the key linear- > algebra step for this; see trac #6178. So we have free modules over an > arbitrary PID (me) and arbitrary fg modules over ZZ (you), and > combining these probably won't be very hard. > > David > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Can gmp-4.2.3 & mpfr-2.3.2 be moved to the T2 to build gcc ??
Anthony David wrote: > On Sat, Jun 6, 2009 at 8:05 AM, Dr. David Kirkby > wrote: >> I've downloaded gcc 4.4.0 with a view to building this to try to get rid >> of the internal compiler bug on the T2. >> > > As a general question to the list: > > I understand that sage is designed to be built by just typing make on > any platform. Is there a general problem when people use compilers > other than gcc and, it seems, a particular gcc version? The following > have been my casual experience. Solaris is not a supported platform yet for Sage. From what I gather, various bits of code making up Sage are very temperamental on Solaris, needing specific versions of the compiler. Not all tests pass either. I have however built Sage on my home machine, and while it fails some tests and the GUI does not work, the basic program appears to function properly. The fact is, Solaris is not as popular as linux on x86, so virtually any program is better tested on linux than Solaris. I think that is what causes the compatibility issues. I may have a clue to the issue on t2.math.washington.edu though. It is possible that the compiler binaries on that machine were built on a later version of Solaris than actually being used on the machine. That might cause problems. > Attempts to build sage 4.0 on ia64 SLES10SP1 failed using the intel > compiler. Problems with gmp-mpir were overcome by unloading the Intel > compiler module from my shell ( icc 9.1.051). gcc 4,1,2 was then used > on all compiles and it then sailed on happily until polybori when that > failed, > > [The ia64 issues have not been high on the list of priorities because > I do not have a need for my model to run on that architecture. I had a > test box I had reassembled and wanted to exercise it so a sage test > build seemed like a good idea.] > > Anthony David I think again you hit the same issue. Run a less common processor and you find most programs are less well tested. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Some progress on t2.math.washington.edu issues
I need to do some other things now, so will return to this later. But I believe I've found some of the reasons Sage is not building on t2.math.washington.edu whereas it does on my Blade 2000. 1) It is possible the gcc 4.3.1 binaries in /usr/local/sparc-solaris-toolchain were created in a newer version of Solaris than what is running on t2. According to some people on comp.unix.solaris, doing this could cause problems. without knowing exactly what Michael used I can't be sure. 2) I tried building the latest gmp (4.3.1) using the Solaris toolchain. It built ok and passed the tests. I installed that in /usr/local/gmp-4.3.1-Solaris-10-u4-ABI=32 3) I downloaded the latest mpfr-2.4.1, patched it to the latest patch level (5) and built that, again using the compiler in /usr/local/sparc-solaris-toolchain. Whilst mpfr compiled ok, it failed about 20 tests of the 148 tests. 4) Now, somewhat suspicious that the tool chain is working ok on t2, I decided to have another go building gmp and mpfr, but this time using the Sun-supplied gcc (3.4.3) in /usr/sfw/bin. This time the tests of both gmp and mpfr passed I've put two directories in /usr/local gmp-4.3.1-Solaris-10-u4-ABI=32-gcc-3.4.3 mpfr-2.4.1p5-Solaris-10-u4-gcc-3.4.3 which have the latest gmp and mpfr which pass tests. But as indicated on the directory names, these were built with gcc 3.4.3, not the Solaris toolchain, as that causes test failures in mpfr. I'm trying to build gcc-4.4.0 now. I'll leave running while I do something else. I know Micheal put a lot of work into getting the tool chain right, but i think it is failing on the t2, as I suspect he possibly built it on a machine with a newer version of Solaris. Dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Some progress on t2.math.washington.edu issues
On Sat, Jun 6, 2009 at 6:31 AM, Dr. David Kirkby wrote: > > I need to do some other things now, so will return to this later. But I > believe I've found some of the reasons Sage is not building on > t2.math.washington.edu whereas it does on my Blade 2000. > > 1) It is possible the gcc 4.3.1 binaries in > /usr/local/sparc-solaris-toolchain were created in a newer version of > Solaris than what is running on t2. According to some people on > comp.unix.solaris, doing this could cause problems. > > without knowing exactly what Michael used I can't be sure. It was built on either this machine: -bash-3.00$ uname -a SunOS mark 5.10 Generic_127111-01 sun4u sparc SUNW,Sun-Blade-2500 Solaris or this machine: -bash-3.00$ uname -a SunOS mark2 5.10 Generic_127111-01 sun4u sparc SUNW,Sun-Blade-2500 > > > 2) I tried building the latest gmp (4.3.1) using the Solaris toolchain. > It built ok and passed the tests. > > I installed that in > > /usr/local/gmp-4.3.1-Solaris-10-u4-ABI=32 > > 3) I downloaded the latest mpfr-2.4.1, patched it to the latest patch > level (5) and built that, again using the compiler in > /usr/local/sparc-solaris-toolchain. Whilst mpfr compiled ok, it failed > about 20 tests of the 148 tests. > > 4) Now, somewhat suspicious that the tool chain is working ok on t2, I > decided to have another go building gmp and mpfr, but this time using > the Sun-supplied gcc (3.4.3) in /usr/sfw/bin. > > This time the tests of both gmp and mpfr passed > > I've put two directories in /usr/local > > gmp-4.3.1-Solaris-10-u4-ABI=32-gcc-3.4.3 > mpfr-2.4.1p5-Solaris-10-u4-gcc-3.4.3 > > which have the latest gmp and mpfr which pass tests. But as indicated on > the directory names, these were built with gcc 3.4.3, not the Solaris > toolchain, as that causes test failures in mpfr. Thanks! > I'm trying to build gcc-4.4.0 now. I'll leave running while I do > something else. Thanks again! > > I know Micheal put a lot of work into getting the tool chain right, but > i think it is failing on the t2, as I suspect he possibly built it on a > machine with a newer version of Solaris. He built it on a Solaris 10 box (a 2500). So it seems to be the same version of Solaris, but of course different hardware. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Some progress on t2.math.washington.edu issues
William Stein wrote: > On Sat, Jun 6, 2009 at 6:31 AM, Dr. David Kirkby > wrote: >> I need to do some other things now, so will return to this later. But I >> believe I've found some of the reasons Sage is not building on >> t2.math.washington.edu whereas it does on my Blade 2000. >> >> 1) It is possible the gcc 4.3.1 binaries in >> /usr/local/sparc-solaris-toolchain were created in a newer version of >> Solaris than what is running on t2. According to some people on >> comp.unix.solaris, doing this could cause problems. >> >> without knowing exactly what Michael used I can't be sure. > > It was built on either this machine: > > -bash-3.00$ uname -a > SunOS mark 5.10 Generic_127111-01 sun4u sparc SUNW,Sun-Blade-2500 Solaris > > or this machine: > > -bash-3.00$ uname -a > SunOS mark2 5.10 Generic_127111-01 sun4u sparc SUNW,Sun-Blade-2500 Can you give me the output of $ cat /etc/release of both machines. It will be something like this: drkir...@kestrel:[~/sage/sage-4.0.1.alpha0] $ cat /etc/release Solaris 10 10/08 s10s_u6wos_07b SPARC Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 27 October 2008 The 'u6' in the first line says this is update 6 on my machine, whereas on the t2 kir...@t2:~$ cat /etc/release Solaris 10 8/07 s10s_u4wos_12b SPARC Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 16 August 2007 wheras the 'u4' there indicates it is Solaris 10 update 4. I'm in the process of building gcc-4.4.0. Initially the build of it failed, but I think I have found out how to get around that. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Can gmp-4.2.3 & mpfr-2.3.2 be moved to the T2 to build gcc ??
On Sat, Jun 6, 2009 at 2:25 AM, Anthony David wrote: > > On Sat, Jun 6, 2009 at 8:05 AM, Dr. David Kirkby > wrote: >> >> I've downloaded gcc 4.4.0 with a view to building this to try to get rid >> of the internal compiler bug on the T2. >> > > As a general question to the list: > > I understand that sage is designed to be built by just typing make on > any platform. That's not true. You should read README.txt in the root directory of the Sage tarball, which lists supported platforms. > Is there a general problem when people use compilers > other than gcc and, it seems, a particular gcc version? The following > have been my casual experience. Nobody has ever even once build Sage using any compiler except GCC. And even then, one must not use too buggy of a version of GCC. Sage contains much complicated highly optimized code, which exposes compiler bugs. That said, we definitely would welcome any help from anybody to make it possible to build Sage with other compilers. E.g., there is a project to build Sage using MSVC on Windows: http://windows.sagemath.org > > Attempts to build sage 4.0 on ia64 SLES10SP1 failed using the intel > compiler. Problems with gmp-mpir were overcome by unloading the Intel > compiler module from my shell ( icc 9.1.051). gcc 4,1,2 was then used > on all compiles and it then sailed on happily until polybori when that > failed, > > [The ia64 issues have not been high on the list of priorities because > I do not have a need for my model to run on that architecture. I had a > test box I had reassembled and wanted to exercise it so a sage test > build seemed like a good idea.] I regularly build Sage on itanium using GCC-4.3.x. It's a standard supported platform, and all tests pass. Sage built with GCC-4.4 doesn't 100% work in sage-4.0 or earlier, but works fine with sage-4.0.1.rc3 (soon to be released). > > Anthony David > > >> I looked at an install.log of one of my builds of Sage using the Solaris >> binaries from Micheal and see the compiler was configured with: >> >> >> GCC Version >> gcc -v >> Using built-in specs. >> Target: sparc-sun-solaris2.10 >> Configured with: ../gcc-4.3.2/configure >> --prefix=/home/mabshoff/sparc-solaris-toolchain/ >> --enable-languages=c,c++,fortran --with-gnu-ld >> --with-ld=/home/mabshoff/sparc-solaris-toolchain/bin/ld --with-gnu-as >> --with-as=/home/mabshoff/sparc-solaris-toolchain/bin/as >> --with-gmp=/usr/local/gmp-4.2.3/sparc-SunOS-gcc-4.3.1-abi32/ >> --with-mpfr=/usr/local/mpfr-2.3.2/sparc-SunOS-gmp-4.2.3-gcc-4.3.1-abi32/ >> >> >> >> >> Is it possible to move those >> >> /usr/local/gmp-4.2.3/sparc-SunOS-gcc-4.3.1-abi32/ and >> /usr/local/mpfr-2.3.2/sparc-SunOS-gmp-4.2.3-gcc-4.3.1-abi32/ >> >> to somewhere on the T2, so I can configure gcc to use them and build gcc >> 4.4.0? >> >> >> If those are known to work (on most machines anyway), I'd rather use >> them than download the sources and compile gmp and mpfr. >> >> >> >> > >> > > > > -- 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 sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: "What can Magma do that Sage can't do?"
On Sat, Jun 6, 2009 at 1:18 AM, davidloeffler wrote: > > On Jun 6, 3:47 am, William Stein wrote: > >> * Galois theory and ramification groups for p-adic extensions (needs >> the previous features) > > I wrote a (very simplistic) implementation of Artin symbols and > decomposition and ramification groups a few months back for extensions > of *number fields*, so we have this via the canonical dumb algorithm: > find an extension of number fields whose local extension at some prime > is the p-adic extension you want. Nice, thanks! > >> VII. Modules >> >> * Sage has nothing for modules over Dedekind domains (except over >> ZZ): this is an extremely important building block for certain >> algorithms (e.g., arithmetic in quaternion algebras over number >> fields), so needs to get implemented. I recently wrote code for >> general modules over ZZ, but it isn't in Sage yet. >> >> PROJECT: Finish modules over ZZ, optimize >> >> PROJECT: Extend modules over ZZ to modules over a PID > > Last week I wrote some code for Hermite form, which is the key linear- > algebra step for this; see trac #6178. So we have free modules over an > arbitrary PID (me) and arbitrary fg modules over ZZ (you), and > combining these probably won't be very hard. Actually, the code I wrote for "arbitrary fg modules over ZZ" should actually work for arbitrary fg modules over a PID. It was all written generically, assuming HNF and SNF algorithms. Of course, it's untested so I'm sure when we test it something will come up. William > > David > > > > > -- 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 sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] mathemagix
Hi, Has anybody here ever compiled or built a recent version of Mathemagix? http://www.mathemagix.org I'm planning to try to make an optional source spkg of it for Sage, if possible, but if anybody has already partly done so it would be helpful. My main motivation is that when I gave my Sage Plenary at MEGA in two weeks in Barcelona, there will be a Mathemagix talk shortly thereafter. -- William -- 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 sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: "What can Magma do that Sage can't do?"
> VIII. Finite Groups; Finitely-Presented Groups > > * I'm not enough of a group theorist to appreciate differences > between what Sage provides via GAP and Magma. They seem pretty > similar to me for group theory. Sage exposes much of GAP's > functionality for groups. William, I think you're right that the capabilities of GAP and Magma are very similar in the domain of group theory. However, there's at least one key thing that GAP has but Sage doesn't expose: finitely-presented groups. It's even in the title of this chapter of the Magma handbook, so we definitely need it ;-) So, PROJECT: Implement a finitely-presented group class in Sage. N.B. this has been briefly discussed on sage-devel before, and there are some ideas of where to start there. Best, Nathan --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: t2.math.washington.edu
On Sat, Jun 6, 2009 at 8:45 AM, Dr. David Kirkby wrote: > William Stein wrote: > >> >> -bash-3.00$ cat /etc/release >> Solaris 10 1/06 s10s_u1wos_19a SPARC >> Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. >> Use is subject to license terms. >> Assembled 07 December 2005 >> >> whereas on t2.math: >> >> wst...@t2:~$ cat /etc/release >> Solaris 10 8/07 s10s_u4wos_12b SPARC >> Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. >> Use is subject to license terms. >> Assembled 16 August 2007 > > Hi, > > the first of those machines is update 1, so quite old and should any binary > build on that, it should run on t2 too. > > But William said on sage-devel that the toolchain could have been built on > one of two machines (mark or mark2). Since they both have the same kernel > patch, I assume they are both Solaris 10 update 1 (07/2005). In that case, > it proves me wrong about the Solaris version being the problem. But perhaps > you can just confirm that. I have just confirmed that mark and mark2 have identical Solaris installs. So I guess that wasn't the problem. > > > Either way, that fortran compiler is definitely a problem on t2, as even a > simple example fortran program I downloaded from the web caused the internal > error, so it's not some exotic code in Sage that is exploiting an obscure > compiler bug. > > Anyway, the build of gcc-4.4.0 seems to be going ok (about an hour compiling > now!), so hopefully that will help matters. Yep, gcc takes a long time to build. There is also a GCC-4.2.1 Sage spkg that Michael made nearly two years ago. It's in the Sage experimental package repo. I'll try that on t2 and see what happens: wst...@t2:~/t2/sage-4.0$ ./sage -i gcc-4.2.1 (I doubt it will work, but we'll see...) David, if you are interested at all in making a new Sage GCC spkg (for gcc-4.4.0), which works on Solaris (in addition to other OS's), that would be a greatly appreciated contribution you could make to the Sage project. You can get the gcc-4.2.1 spkg here, if you want to see how it is constructed: http://sagemath.org/packages/experimental/ William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: t2.math.washington.edu
On Sat, Jun 6, 2009 at 9:09 AM, William Stein wrote: > On Sat, Jun 6, 2009 at 8:45 AM, Dr. David Kirkby > wrote: >> William Stein wrote: >> >>> >>> -bash-3.00$ cat /etc/release >>> Solaris 10 1/06 s10s_u1wos_19a SPARC >>> Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. >>> Use is subject to license terms. >>> Assembled 07 December 2005 >>> >>> whereas on t2.math: >>> >>> wst...@t2:~$ cat /etc/release >>> Solaris 10 8/07 s10s_u4wos_12b SPARC >>> Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. >>> Use is subject to license terms. >>> Assembled 16 August 2007 >> >> Hi, >> >> the first of those machines is update 1, so quite old and should any binary >> build on that, it should run on t2 too. >> >> But William said on sage-devel that the toolchain could have been built on >> one of two machines (mark or mark2). Since they both have the same kernel >> patch, I assume they are both Solaris 10 update 1 (07/2005). In that case, >> it proves me wrong about the Solaris version being the problem. But perhaps >> you can just confirm that. > > I have just confirmed that mark and mark2 have identical Solaris installs. > So I guess that wasn't the problem. > >> >> >> Either way, that fortran compiler is definitely a problem on t2, as even a >> simple example fortran program I downloaded from the web caused the internal >> error, so it's not some exotic code in Sage that is exploiting an obscure >> compiler bug. >> >> Anyway, the build of gcc-4.4.0 seems to be going ok (about an hour compiling >> now!), so hopefully that will help matters. > > Yep, gcc takes a long time to build. > > There is also a GCC-4.2.1 Sage spkg that Michael made nearly two years > ago. It's in the Sage experimental package repo. I'll try that on t2 > and see what happens: > > wst...@t2:~/t2/sage-4.0$ ./sage -i gcc-4.2.1 > > (I doubt it will work, but we'll see...) It fails with: checking whether compiler driver understands Ada... no checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16 checking for correct version of gmp.h... yes checking for correct version of mpfr.h... buggy version of MPFR detected checking for any version of mpfr.h... no configure: error: GMP 4.1 and MPFR 2.2.1 or newer versions required by fortran Error configuring gcc real0m15.238s user0m0.874s sys 0m1.589s sage: An error occurred while installing gcc-4.2.1 > > David, if you are interested at all in making a new Sage GCC spkg (for > gcc-4.4.0), which works on Solaris (in addition to other OS's), that > would be a greatly appreciated contribution you could make to the Sage > project. You can get the gcc-4.2.1 spkg here, if you want to see how > it is constructed: > > http://sagemath.org/packages/experimental/ > > William > -- 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 sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Sage Bug Report] Wrong matplotlibrc used if user has one in ~/.matplotlib
On Tue, May 19, 2009 at 12:18 PM, Brian Granger wrote: > >> I agree that there still is a problem. Before, I didn't think that >> Sage's matplotlib would need to have different options to even be able >> to function. > > The problem that I am running into is that my > ~./matplotlib/matplotlibrc sets a backend (macosx) that the Sage > matplotlib doesn't have. Thus, when Sage's matplotlib uses this > setting I see an ImportError. I want to reopen this thread. I have a build farm with many (nearly 20) different OS's that all build and test Sage in parallel. My home directory on each of those machines is NFS exported and shared. I sometimes have tests fail because all these different Sage's are trying to write to the same $HOME/.matplotlib directory (for temp files, configuration, etc.). For Sage itself, I set SAGE_HOME to a fast local scratch disk (on each machine), which completely solves any contention problems for *everything* related to Sage temp files, configuration, etc., with the notable exception of matplotlib. Thus I would also prefer it if Sage's matplotlib directory were under SAGE_HOME instead of it being the default $HOME/.matplotlib. Thoughts? William >> In the mailing list thread, the option was brought up to have the user >> put in a command in their init.sage file if they wanted a custom Sage >> initialization for matplotlib. Setting the MATPLOTLIBRC variable in the >> init.sage file should work, I think. > > Yes, but I don't see this file in my .sage directory. Where would it be? > >> In reality, (I think) the people this affects are the people that have >> already customized their system install of matplotlib. Those are the >> people that (I think) would be capable of writing another command in >> their init.sage or something to have Sage have a custom matplotlibrc file. > > Yes, for the most part I agree with this. But it is not quite that > simple. I still need/want to be able to configure matplotlib for Sage > and my own install separately. That means I have to copy my own > matplotlibrc file into .sage, make edits and set variables in > init.sage. > >> On the other hand, I can see the nice thing about Sage being totally >> self-contained and not pulling settings from a user's home directory for >> options. > > Yes, I think Sage should "Just Work", even for users that have > matplotlib installed previously. This is simple enough to fix, I > don't see why we wouldn't. The only thing is that the matplotlibrc > file needs to be updated anytime that matplotlib itself is updated. > > Cheers, > > Brian > > > > -- 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 sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0.1.rc0 (rc3)
William Stein wrote: > 2009/6/4 Mike Hansen : >> Hello, >> >> Now that sage.math is back up, I've cut rc0 and put it in >> /home/mhansen/sage-4.0.1.rc0.tar. All tests passed on sage.math. >> > sage-4.0.1.rc3 built fine and all tests passed on Fedora 9 and 10, 32 bit. Jaap --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0.1.rc0 (rc3)
On Sat, Jun 6, 2009 at 10:25 AM, Jaap Spies wrote: > > William Stein wrote: >> 2009/6/4 Mike Hansen : >>> Hello, >>> >>> Now that sage.math is back up, I've cut rc0 and put it in >>> /home/mhansen/sage-4.0.1.rc0.tar. All tests passed on sage.math. >>> >> > > sage-4.0.1.rc3 built fine and all tests passed on Fedora 9 and 10, 32 bit. > Cool. I just cut sage-4.0.1, which is here: http://sage.math.washington.edu/home/wstein/release/4.0.1/final/sage-4.0.1/ http://sage.math.washington.edu/home/wstein/release/4.0.1/final/sage-4.0.1/dist/sage-4.0.1.tar My plan now is to finish build testing it on sage.math, then build it on the build farm. Then officially release it. It's basically the same as rc3, except it fixes a small doctest issue with cwitty's amazing new "explain_pickle" module, and disables running "make check" by default for mpir and flint. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: t2.math.washington.edu
There's a fully built MPIR in my home directory. The include (gmp.h) is in /home/wbhart/mpir-trunk/ and the libraries (libgmp.*) are in / home/wbhart/mpir-trunk/.libs Bill. On 6 June, 17:13, William Stein wrote: > On Sat, Jun 6, 2009 at 9:09 AM, William Stein wrote: > > On Sat, Jun 6, 2009 at 8:45 AM, Dr. David Kirkby > > wrote: > >> William Stein wrote: > > >>> -bash-3.00$ cat /etc/release > >>> Solaris 10 1/06 s10s_u1wos_19a SPARC > >>> Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. > >>> Use is subject to license terms. > >>> Assembled 07 December 2005 > > >>> whereas on t2.math: > > >>> wst...@t2:~$ cat /etc/release > >>> Solaris 10 8/07 s10s_u4wos_12b SPARC > >>> Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. > >>> Use is subject to license terms. > >>> Assembled 16 August 2007 > > >> Hi, > > >> the first of those machines is update 1, so quite old and should any binary > >> build on that, it should run on t2 too. > > >> But William said on sage-devel that the toolchain could have been built on > >> one of two machines (mark or mark2). Since they both have the same kernel > >> patch, I assume they are both Solaris 10 update 1 (07/2005). In that case, > >> it proves me wrong about the Solaris version being the problem. But perhaps > >> you can just confirm that. > > > I have just confirmed that mark and mark2 have identical Solaris installs. > > So I guess that wasn't the problem. > > >> Either way, that fortran compiler is definitely a problem on t2, as even a > >> simple example fortran program I downloaded from the web caused the > >> internal > >> error, so it's not some exotic code in Sage that is exploiting an obscure > >> compiler bug. > > >> Anyway, the build of gcc-4.4.0 seems to be going ok (about an hour > >> compiling > >> now!), so hopefully that will help matters. > > > Yep, gcc takes a long time to build. > > > There is also a GCC-4.2.1 Sage spkg that Michael made nearly two years > > ago. It's in the Sage experimental package repo. I'll try that on t2 > > and see what happens: > > > wst...@t2:~/t2/sage-4.0$ ./sage -i gcc-4.2.1 > > > (I doubt it will work, but we'll see...) > > It fails with: > > checking whether compiler driver understands Ada... no > checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16 > checking for correct version of gmp.h... yes > checking for correct version of mpfr.h... buggy version of MPFR detected > checking for any version of mpfr.h... no > configure: error: GMP 4.1 and MPFR 2.2.1 or newer versions required by fortran > Error configuring gcc > > real 0m15.238s > user 0m0.874s > sys 0m1.589s > sage: An error occurred while installing gcc-4.2.1 > > > > > David, if you are interested at all in making a new Sage GCC spkg (for > > gcc-4.4.0), which works on Solaris (in addition to other OS's), that > > would be a greatly appreciated contribution you could make to the Sage > > project. You can get the gcc-4.2.1 spkg here, if you want to see how > > it is constructed: > > >http://sagemath.org/packages/experimental/ > > > William > > -- > 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 sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Aren't the interfaces supposed to be unique parents??
On Jun 6, 2009, at 1:06 AM, Mike Hansen wrote: > Hello, > > On Sat, Jun 6, 2009 at 12:31 AM, Simon King > wrote: >> >> Dear all, >> >> I thought that the interfaces to gap, singular, maxima etc. are >> considered to be unique parents. Apparently gap and singular are, but >> maxima is only half ways unique: > > Each expect interface parent corresponds to a session. So, if you > want to make a new GAP session, you'd just do > > sage; g = Gap() > > For the interfaces to Maxima, the calculus code has its on session > that it uses. It's parent is in sage.calculus.calculus.maxima rather > than the default maxima object which corresponds to > sage.interfaces.maxima.maxima The reason to do this is because maxima is not stateless, so it's nice not to worry about messing up your calculus when calling maxima, or vice-versa. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Some progress on t2.math.washington.edu issues
-bash-3.00$ cat /etc/release Solaris 10 1/06 s10s_u1wos_19a SPARC Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 07 December 2005 -bash-3.00$ cat /etc/release Solaris 10 1/06 s10s_u1wos_19a SPARC Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 07 December 2005 Bill. On 6 June, 16:22, "Dr. David Kirkby" wrote: > William Stein wrote: > > On Sat, Jun 6, 2009 at 6:31 AM, Dr. David Kirkby > > wrote: > >> I need to do some other things now, so will return to this later. But I > >> believe I've found some of the reasons Sage is not building on > >> t2.math.washington.edu whereas it does on my Blade 2000. > > >> 1) It is possible the gcc 4.3.1 binaries in > >> /usr/local/sparc-solaris-toolchain were created in a newer version of > >> Solaris than what is running on t2. According to some people on > >> comp.unix.solaris, doing this could cause problems. > > >> without knowing exactly what Michael used I can't be sure. > > > It was built on either this machine: > > > -bash-3.00$ uname -a > > SunOS mark 5.10 Generic_127111-01 sun4u sparc SUNW,Sun-Blade-2500 Solaris > > > or this machine: > > > -bash-3.00$ uname -a > > SunOS mark2 5.10 Generic_127111-01 sun4u sparc SUNW,Sun-Blade-2500 > > Can you give me the output of > > $ cat /etc/release > > of both machines. It will be something like this: > > drkir...@kestrel:[~/sage/sage-4.0.1.alpha0] $ cat /etc/release > Solaris 10 10/08 s10s_u6wos_07b SPARC > Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. > Assembled 27 October 2008 > > The 'u6' in the first line says this is update 6 on my machine, whereas > on the t2 > kir...@t2:~$ cat /etc/release > Solaris 10 8/07 s10s_u4wos_12b SPARC > Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. > Assembled 16 August 2007 > > wheras the 'u4' there indicates it is Solaris 10 update 4. > > I'm in the process of building gcc-4.4.0. Initially the build of it > failed, but I think I have found out how to get around that. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Sage Bug Report] Wrong matplotlibrc used if user has one in ~/.matplotlib
> I want to reopen this thread. Great! matplotlib under Sage is still broken for me because of this issue - I would love to see this resolved. > I have a build farm with many (nearly 20) different OS's that all build and > test > Sage in parallel. My home directory on each of those machines is NFS exported > and shared. I sometimes have tests fail because all these different > Sage's are trying to write to the same $HOME/.matplotlib directory > (for temp files, configuration, etc.). > For Sage itself, I set SAGE_HOME to a fast local scratch disk (on each > machine), which completely solves any contention problems for > *everything* related to Sage temp files, configuration, etc., with the > notable exception of matplotlib. I hadn't thought of this issue, but it is another good reason to not use $HOME/.matplotlib for the Sage matplotlib. > Thus I would also prefer it if > Sage's matplotlib directory were under SAGE_HOME instead of it being > the default $HOME/.matplotlib. > > Thoughts? I think the simplest solution is to have Sage set: export MPLCONFIGDIR=$SAGE_HOME/matplotlib But, wait, does SAGE_HOME point to $HOME/.sage by default? That is the right place for this, I just don't remember exactly where SAGE_HOME points. I don't even think we need to put a default matplotlibrc file there, so we don't have to worry about it becoming out of date. If people want to add their own matplotlibrc file to this directory they can, but the default will be that matplotlib works. Cheers, Brian > William > > >>> In the mailing list thread, the option was brought up to have the user >>> put in a command in their init.sage file if they wanted a custom Sage >>> initialization for matplotlib. Setting the MATPLOTLIBRC variable in the >>> init.sage file should work, I think. >> >> Yes, but I don't see this file in my .sage directory. Where would it be? >> >>> In reality, (I think) the people this affects are the people that have >>> already customized their system install of matplotlib. Those are the >>> people that (I think) would be capable of writing another command in >>> their init.sage or something to have Sage have a custom matplotlibrc file. >> >> Yes, for the most part I agree with this. But it is not quite that >> simple. I still need/want to be able to configure matplotlib for Sage >> and my own install separately. That means I have to copy my own >> matplotlibrc file into .sage, make edits and set variables in >> init.sage. >> >>> On the other hand, I can see the nice thing about Sage being totally >>> self-contained and not pulling settings from a user's home directory for >>> options. >> >> Yes, I think Sage should "Just Work", even for users that have >> matplotlib installed previously. This is simple enough to fix, I >> don't see why we wouldn't. The only thing is that the matplotlibrc >> file needs to be updated anytime that matplotlib itself is updated. >> >> Cheers, >> >> Brian >> >> > >> > > > > -- > 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 sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Some progress on t2.math.washington.edu issues
Bill Hart wrote: > -bash-3.00$ cat /etc/release >Solaris 10 1/06 s10s_u1wos_19a SPARC >Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. >Assembled 07 December 2005 > > -bash-3.00$ cat /etc/release >Solaris 10 1/06 s10s_u1wos_19a SPARC >Copyright 2005 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. >Assembled 07 December 2005 > > Bill. Thank you Bill. William had already sent me these, but it confirms that the binaries were created on an older release of Solaris to the t2, so that should not be a problem. I've build the very latest gmp and mpfr and are in the process of building the very latest gcc. That might solve the problem - there is no harm in trying anyway! dave --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] sage-4.0.1
Hi, Sage-4.0.1 has been released (by William Stein and Mike Hansen). You can download it from http://sagemath.org/src/ as usual. I'm building binaries right now too (which should work on a wider range of processors, by the way!). We closed 76 tickets in this release, as listed here: http://trac.sagemath.org/sage_trac/query?status=closed&group=resolution&milestone=sage-4.0.1 More detailed release notes will follow. -- William -- 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 sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Sage Bug Report] Wrong matplotlibrc used if user has one in ~/.matplotlib
2009/6/6 Brian Granger : > >> I want to reopen this thread. > > Great! matplotlib under Sage is still broken for me because of this > issue - I would love to see this resolved. > >> I have a build farm with many (nearly 20) different OS's that all build and >> test >> Sage in parallel. My home directory on each of those machines is NFS >> exported >> and shared. I sometimes have tests fail because all these different >> Sage's are trying to write to the same $HOME/.matplotlib directory >> (for temp files, configuration, etc.). >> For Sage itself, I set SAGE_HOME to a fast local scratch disk (on each >> machine), which completely solves any contention problems for >> *everything* related to Sage temp files, configuration, etc., with the >> notable exception of matplotlib. > > I hadn't thought of this issue, but it is another good reason to not > use $HOME/.matplotlib for the Sage matplotlib. > >> Thus I would also prefer it if >> Sage's matplotlib directory were under SAGE_HOME instead of it being >> the default $HOME/.matplotlib. >> >> Thoughts? > > I think the simplest solution is to have Sage set: > > export MPLCONFIGDIR=$SAGE_HOME/matplotlib > > But, wait, does SAGE_HOME point to $HOME/.sage by default? That is > the right place for this, I just don't remember exactly where > SAGE_HOME points. Yep, it does. We can make sure easily enough by running Sage and asking: sage: DOT_SAGE '/Users/wstein/.sage/' By the way, I just realized it is called "DOT_SAGE", not "SAGE_HOME". This is now: http://trac.sagemath.org/sage_trac/ticket/6235 -- William > > I don't even think we need to put a default matplotlibrc file there, > so we don't have to worry about it becoming out of date. If people > want to add their own matplotlibrc file to this directory they can, > but the default will be that matplotlib works. > > Cheers, > > Brian > >> William >> >> In the mailing list thread, the option was brought up to have the user put in a command in their init.sage file if they wanted a custom Sage initialization for matplotlib. Setting the MATPLOTLIBRC variable in the init.sage file should work, I think. >>> >>> Yes, but I don't see this file in my .sage directory. Where would it be? >>> In reality, (I think) the people this affects are the people that have already customized their system install of matplotlib. Those are the people that (I think) would be capable of writing another command in their init.sage or something to have Sage have a custom matplotlibrc file. >>> >>> Yes, for the most part I agree with this. But it is not quite that >>> simple. I still need/want to be able to configure matplotlib for Sage >>> and my own install separately. That means I have to copy my own >>> matplotlibrc file into .sage, make edits and set variables in >>> init.sage. >>> On the other hand, I can see the nice thing about Sage being totally self-contained and not pulling settings from a user's home directory for options. >>> >>> Yes, I think Sage should "Just Work", even for users that have >>> matplotlib installed previously. This is simple enough to fix, I >>> don't see why we wouldn't. The only thing is that the matplotlibrc >>> file needs to be updated anytime that matplotlib itself is updated. >>> >>> Cheers, >>> >>> Brian >>> >>> > >>> >> >> >> >> -- >> 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 sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Sage Bug Report] Wrong matplotlibrc used if user has one in ~/.matplotlib
>> But, wait, does SAGE_HOME point to $HOME/.sage by default? That is >> the right place for this, I just don't remember exactly where >> SAGE_HOME points. > > Yep, it does. We can make sure easily enough by running Sage and asking: > > sage: DOT_SAGE > '/Users/wstein/.sage/' > > By the way, I just realized it is called "DOT_SAGE", not "SAGE_HOME". Ahh, I that explains why I was confused. > This is now: > > http://trac.sagemath.org/sage_trac/ticket/6235 Great! Brian > -- William > > >> >> I don't even think we need to put a default matplotlibrc file there, >> so we don't have to worry about it becoming out of date. If people >> want to add their own matplotlibrc file to this directory they can, >> but the default will be that matplotlib works. >> >> Cheers, >> >> Brian >> >>> William >>> >>> > In the mailing list thread, the option was brought up to have the user > put in a command in their init.sage file if they wanted a custom Sage > initialization for matplotlib. Setting the MATPLOTLIBRC variable in the > init.sage file should work, I think. Yes, but I don't see this file in my .sage directory. Where would it be? > In reality, (I think) the people this affects are the people that have > already customized their system install of matplotlib. Those are the > people that (I think) would be capable of writing another command in > their init.sage or something to have Sage have a custom matplotlibrc file. Yes, for the most part I agree with this. But it is not quite that simple. I still need/want to be able to configure matplotlib for Sage and my own install separately. That means I have to copy my own matplotlibrc file into .sage, make edits and set variables in init.sage. > On the other hand, I can see the nice thing about Sage being totally > self-contained and not pulling settings from a user's home directory for > options. Yes, I think Sage should "Just Work", even for users that have matplotlib installed previously. This is simple enough to fix, I don't see why we wouldn't. The only thing is that the matplotlibrc file needs to be updated anytime that matplotlib itself is updated. Cheers, Brian > >>> >>> >>> >>> -- >>> 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 sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] sage release plan
Hi Sage Devel, Now that sage-4.0.1 has been released (13 hours ahead of schedule, and on budget!), it's time for the *community* to work on planning the next Sage release. To get things going, here are some questions. Should it be a quick 4.0.2 or a bigger 4.1? What should the planned release date be?What should we push to have go in? Personally, I think we've been in "very conservative" mode for a month now (with sage-4.0 and 4.0.1), so it is time to have a more ambitious feature-full release. This means 4.1. Good timing for the release would be right before Sage Days 16, i.e., June 21, 2009, which gives us a full 2 weeks. Some ideas for code to go in: * my code for finitely generated modules over a PID * the categories code from sage-combinat that Nic has worked so hard on * other code from sage-combinat * Python 2.6 * Scipy/Numpy upgrades to latest versions I think the above plus lots of other misc code would make a very nice 4.1. What are your ideas? There are 71 tickets right now that have patches ready to be reviewed. Doing them now would be perfect timing, giving that we're about to have a probably larger release, so Sage will be pretty stable for the next two weeks: http://trac.sagemath.org/sage_trac/report/14 Jason Grout -- or anybody -- if somebody can volunteer and go through and send out referee email requests, I think that would take a total of 2 hours and be *tremendously* beneficial to the whole project. -- William -- 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 sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage-4.0.1
Hi! On 6 Jun., 21:40, William Stein wrote: > We closed 76 tickets in this release, as listed here: > http://trac.sagemath.org/sage_trac/query?status=closed&group=resoluti... One question about trac. I had a ticket #6208. Originally I thought it'd be too late for sage-4.0.1, so, I started with the milestone sage-4.0.2. But review and merging was done sooner than I thought (4.0.1.rc1). In your query, that ticket doesn't appear, since you search for milestone 4.0.1. Is there an automated way to reset the milestone if the reviewing is quicker than expected? Cheers, Simon --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: t2.math.washington.edu
William Stein wrote: > I have just confirmed that mark and mark2 have identical Solaris installs. > So I guess that wasn't the problem. OK, that confirms my initial thought that the gfortran binary was too new is wrong. >> Either way, that fortran compiler is definitely a problem on t2, as even a >> simple example fortran program I downloaded from the web caused the internal >> error, so it's not some exotic code in Sage that is exploiting an obscure >> compiler bug. >> >> Anyway, the build of gcc-4.4.0 seems to be going ok (about an hour compiling >> now!), so hopefully that will help matters. > > Yep, gcc takes a long time to build. The gcc build is still going, though I did do 'make bootstrap' which means it gets built three times I think. It's been running over 6 hours now and still not finished! kir...@t2:~/build-gcc-4.4.0$ ls -l config.log -rw-r--r-- 1 kirkby 1093 28561 Jun 6 07:42 config.log kir...@t2:~/build-gcc-4.4.0$ date Sat Jun 6 14:02:36 PDT 2009 > David, if you are interested at all in making a new Sage GCC spkg (for > gcc-4.4.0), which works on Solaris (in addition to other OS's), that > would be a greatly appreciated contribution you could make to the Sage > project. You can get the gcc-4.2.1 spkg here, if you want to see how > it is constructed: > > http://sagemath.org/packages/experimental/ I'd certainly consider it. My maths is not very good, so I doubt there is much I could contribute in a mathematical sense to Sage. I'll certainly give the idea of creating a gcc package some consideration. > William > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: sage release plan
William Stein wrote: > Hi Sage Devel, > > Now that sage-4.0.1 has been released (13 hours ahead of schedule, and > on budget!), it's time for the *community* to work on planning the > next Sage release. > > To get things going, here are some questions. > > Should it be a quick 4.0.2 or a bigger 4.1? What should the planned > release date be?What should we push to have go in? > > Personally, I think we've been in "very conservative" mode for a month > now (with sage-4.0 and 4.0.1), so it is time to have a more ambitious > feature-full release. This means 4.1. Good timing for the release > would be right before Sage Days 16, i.e., June 21, 2009, which gives > us a full 2 weeks. Some ideas for code to go in: > > * my code for finitely generated modules over a PID > * the categories code from sage-combinat that Nic has worked so hard on > * other code from sage-combinat > * Python 2.6 > * Scipy/Numpy upgrades to latest versions If I get time: * TinyMCE fix!!! (I haven't started it yet, though. I think William's idea was probably the correct understanding of the problem.) * LU Decomposition and related changes to other algorithms (i.e., determinant, inverse, solve_right) > Jason Grout -- or anybody -- if somebody can volunteer and go through I can see what I can do, but I probably will not get to this before Monday. Is there a way to pull up a report of a ticket and everyone that participated in that ticket (i.e., posted a patch, made a comment, was CCd, etc.)? It seems we could make an automated system that would kick out an email to all people on a ticket with patch needing review if the ticket had no activity for several weeks. I think an automated email would be an effective way to make sure that patches did not sit in the "needs review" status for very long. At least I would be bothered enough (uh, I mean, appreciate the reminder enough) that I would either give some feedback or a positive review after a few weeks. Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Sage Bug Report] Wrong matplotlibrc used if user has one in ~/.matplotlib
Brian Granger wrote: >> I want to reopen this thread. > > Great! matplotlib under Sage is still broken for me because of this > issue - I would love to see this resolved. > >> I have a build farm with many (nearly 20) different OS's that all build and >> test >> Sage in parallel. My home directory on each of those machines is NFS >> exported >> and shared. I sometimes have tests fail because all these different >> Sage's are trying to write to the same $HOME/.matplotlib directory >> (for temp files, configuration, etc.). >> For Sage itself, I set SAGE_HOME to a fast local scratch disk (on each >> machine), which completely solves any contention problems for >> *everything* related to Sage temp files, configuration, etc., with the >> notable exception of matplotlib. > > I hadn't thought of this issue, but it is another good reason to not > use $HOME/.matplotlib for the Sage matplotlib. > >> Thus I would also prefer it if >> Sage's matplotlib directory were under SAGE_HOME instead of it being >> the default $HOME/.matplotlib. >> >> Thoughts? > > I think the simplest solution is to have Sage set: > > export MPLCONFIGDIR=$SAGE_HOME/matplotlib > > But, wait, does SAGE_HOME point to $HOME/.sage by default? That is > the right place for this, I just don't remember exactly where > SAGE_HOME points. > > I don't even think we need to put a default matplotlibrc file there, > so we don't have to worry about it becoming out of date. If people > want to add their own matplotlibrc file to this directory they can, > but the default will be that matplotlib works. This sounds great. However, what do we do about every sage install that exists out there right now? Every .sage directory already has a matplotlibrc file that throws warnings with the current matplotlibrc. Back when the decision was made, some ideas were kicked around: 1. Make a FAQ entry or documentation that upgrading to the next release requires a person to delete that file -- I think this is too hard to ask most people. 2. Every sage startup, check the DOT_SAGE directory to see if the matplotlibrc file there is identical to the file that we used to distribute and put in there. If it is, it is probably our original file, so just delete it. If it isn't, then someone modified it, so leave it. Put a FAQ entry in and something in the release notes to cover possible warnings experienced by people that modified their ./sage/matplotlibrc files. 3. Do option 2, but only do it for the next 6 months or something. After that, assume that everyone has cleaned up their .sage directory, so remove the check. What do people think? Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Sage Bug Report] Wrong matplotlibrc used if user has one in ~/.matplotlib
2009/6/6 Jason Grout : > > Brian Granger wrote: >>> I want to reopen this thread. >> >> Great! matplotlib under Sage is still broken for me because of this >> issue - I would love to see this resolved. >> >>> I have a build farm with many (nearly 20) different OS's that all build and >>> test >>> Sage in parallel. My home directory on each of those machines is NFS >>> exported >>> and shared. I sometimes have tests fail because all these different >>> Sage's are trying to write to the same $HOME/.matplotlib directory >>> (for temp files, configuration, etc.). >>> For Sage itself, I set SAGE_HOME to a fast local scratch disk (on each >>> machine), which completely solves any contention problems for >>> *everything* related to Sage temp files, configuration, etc., with the >>> notable exception of matplotlib. >> >> I hadn't thought of this issue, but it is another good reason to not >> use $HOME/.matplotlib for the Sage matplotlib. >> >>> Thus I would also prefer it if >>> Sage's matplotlib directory were under SAGE_HOME instead of it being >>> the default $HOME/.matplotlib. >>> >>> Thoughts? >> >> I think the simplest solution is to have Sage set: >> >> export MPLCONFIGDIR=$SAGE_HOME/matplotlib >> >> But, wait, does SAGE_HOME point to $HOME/.sage by default? That is >> the right place for this, I just don't remember exactly where >> SAGE_HOME points. >> >> I don't even think we need to put a default matplotlibrc file there, >> so we don't have to worry about it becoming out of date. If people >> want to add their own matplotlibrc file to this directory they can, >> but the default will be that matplotlib works. > > > This sounds great. However, what do we do about every sage install that > exists out there right now? Every .sage directory already has a > matplotlibrc file that throws warnings with the current matplotlibrc. > Back when the decision was made, some ideas were kicked around: > > 1. Make a FAQ entry or documentation that upgrading to the next release > requires a person to delete that file -- I think this is too hard to ask > most people. > > 2. Every sage startup, check the DOT_SAGE directory to see if the > matplotlibrc file there is identical to the file that we used to > distribute and put in there. If it is, it is probably our original > file, so just delete it. If it isn't, then someone modified it, so > leave it. Put a FAQ entry in and something in the release notes to > cover possible warnings experienced by people that modified their > ./sage/matplotlibrc files. > > 3. Do option 2, but only do it for the next 6 months or something. > After that, assume that everyone has cleaned up their .sage directory, > so remove the check. > > What do people think? 4. Do export MPLCONFIGDIR=$DOT_SAGE/matplotlibconfig That avoids every single problem above. :-) -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Sage Bug Report] Wrong matplotlibrc used if user has one in ~/.matplotlib
William Stein wrote: > > 4. Do export MPLCONFIGDIR=$DOT_SAGE/matplotlibconfig > > That avoids every single problem above. :-) Brilliant. It does leave an unused and possibly confusing matplotlibrc file in their .sage directory, but I suppose that's happening right now, so it's not any worse than now. What do you think? Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: Sage 4.0.1.rc0 (rc3)
Is there a fixed top-level home, independent of the current release manager, for announced development archives? William Stein wrote: > Cool. I just cut sage-4.0.1, which is here: > > http://sage.math.washington.edu/home/wstein/release/4.0.1/final/sage-4.0.1/ > http://sage.math.washington.edu/home/wstein/release/4.0.1/final/sage-4.0.1/dist/sage-4.0.1.tar > > My plan now is to finish build testing it on sage.math, then build it > on the build farm. Then officially release it. > > It's basically the same as rc3, except it fixes a small doctest issue > with cwitty's amazing new "explain_pickle" module, and disables > running "make check" by default for mpir and flint. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] TinyMCE issue
> >> due to a *major* bug in the tinyMCE integration, which anybody who has > >> seriously used the SAge notebook has run into. Nobody has come up > >> with a clean test case though. My worksheet is unfortunately > >> completely scrambled, and I'll have to spend an hour sorting it > >> through. Jason, since you wrote the tinymce integration into sage, > >> any idea why it would randomly scramble things? > > > Yes, and it's always just before class is about to start. It's SO > > annoying. > > Unfortunately, I just got done teaching my last class before the > summer break, so now it'll be even harder to debug this! > > > > >> If *anybody* has any idea how to systematically replicate this "random > >> scrambling" of worksheet contents, please post. > > > I can't quite do it, though I've tried many times. BUT I do know what > > it does, I think. I believe that somehow TinyMCE is recording the > > inputs and eventually gets too much input if you don't save the > > worksheet. Then (I'm pretty sure, again can't replicate) everything > > since your last save/the last time TinyMCE could handle it is appended > > in REVERSE order at the bottom of the worksheet - check it out! I > > hope this helps Jason or someone else replicate it. > > That makes some sense. Not having looked yet, I'm guessing that the > TinyMCE code in Sage doesn't properly verify that code was actually > inserted by the server into the server's copy of the worksheet. E.g., > when you insert a new cell in the notebook, you do *not* see that new > cell inserted until the message goes to the server "insert this cell", > then a message comes *back* saying "new cell inserted".Try the > following: > >(1) start the notebook server >(2) make a worksheet with some cells include some tinymce cells >(3) kill the notebook server. >(4) notice that you get a big error when you attempt to insert a cell >(5) try to edit a tinymce cell. Notice that everything appears to > work fine, but in fact it can't be since the server doesn't exist. > > The above "proves" that if the message "this text cell has changed" > from the web browser to the server somehow gets dropped, then one will > silently just have edits vanish. Maybe they get sent later, which is > why they appear elsewhere in the document. > > In any case, irregardless of it fixing the reording bug or not, the > tinymce integration code should be changed so that when you save your > changes to a cell, it does a roundtrip to the server to make damn sure > the changes really got sent. Here are some possibly related issues which have come up on this list and sage-support, which I record here for convenience. 1. Very often (but maddeningly not 100% reproducible, maybe 90% for me) the second-to-last place one can Shift-Click will not create a TinyMCE region, no matter how often one tries. 2. Open new worksheet, put text above and below the cell (don't bother to put anything in the Sage cell). Now save/quit, and reopen; you will have a new (2nd) Sage cell below your second text. This is reproducible, though I'm not sure it's a bug. 3. If you click on a text area too many times in a row before it saves (again, not consistently reproducible, but three often does it), perhaps before it sends to the server? then you will get a weird- looking text box which is NOT TinyMCE, but just a box with save and cancel buttons that do nothing; also, all text is now just plain text. At this point I usually have to just save the worksheet, reopen it, and hope for the best. - kcrisman --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] conjugate() in sage-4.0 is broken
Hi,
(1) pynac .conjugate() method returns wrong answer:
f(x) = function('f',x)
f(x).conjugate()
--
f(conjugate(x))
Above is certainly not true. For example: f(x) = I + x implies
f(x).conjugate() = -I + conjugate(x) which is not equal to
f(conjugate(x))
(2) view() causes SIGSEGV crash
---
f(x) = function('f',x)
g(x) = f(x).conjugate()
view( g(x) )
--
boom!!
-
Cheers,
Golam
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: [Sage Bug Report] Wrong matplotlibrc used if user has one in ~/.matplotlib
> This sounds great. However, what do we do about every sage install that > exists out there right now? Every .sage directory already has a > matplotlibrc file that throws warnings with the current matplotlibrc. > Back when the decision was made, some ideas were kicked around: > > 1. Make a FAQ entry or documentation that upgrading to the next release > requires a person to delete that file -- I think this is too hard to ask > most people. > > 2. Every sage startup, check the DOT_SAGE directory to see if the > matplotlibrc file there is identical to the file that we used to > distribute and put in there. If it is, it is probably our original > file, so just delete it. If it isn't, then someone modified it, so > leave it. Put a FAQ entry in and something in the release notes to > cover possible warnings experienced by people that modified their > ./sage/matplotlibrc files. > > 3. Do option 2, but only do it for the next 6 months or something. > After that, assume that everyone has cleaned up their .sage directory, > so remove the check. > > What do people think? The existence of a $DOT_SAGE/matplotlibrc file won't affect the above solution, export MPLCONFIGDIR=$DOT_SAGE/matplotlib in any way. By that, I mean that matplotlib will simply ignore the old file because it won't be in the appointed config dir. The reason for this is that previously, Sage didn't use MPLCONFIGDIR (which points to the entire config directory), but rather MATPLOTLIBRC, which just pointed to the rc file in the *top level* .sage directory. What would be a problem is if Sage previously had created a .sage/matplotlib/matplotlibrc file that no longer worked. But that isn't the case. But Williams proposed name for the config dir (matplotlibconfig) would also work fine. I would probably choose "matplotlib" because that is the standard name that mpl uses, but it doesn't really matter. Cheers, Brian > Jason > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Sage Bug Report] Wrong matplotlibrc used if user has one in ~/.matplotlib
Brian Granger wrote: >> This sounds great. However, what do we do about every sage install that >> exists out there right now? Every .sage directory already has a >> matplotlibrc file that throws warnings with the current matplotlibrc. >> Back when the decision was made, some ideas were kicked around: >> >> 1. Make a FAQ entry or documentation that upgrading to the next release >> requires a person to delete that file -- I think this is too hard to ask >> most people. >> >> 2. Every sage startup, check the DOT_SAGE directory to see if the >> matplotlibrc file there is identical to the file that we used to >> distribute and put in there. If it is, it is probably our original >> file, so just delete it. If it isn't, then someone modified it, so >> leave it. Put a FAQ entry in and something in the release notes to >> cover possible warnings experienced by people that modified their >> ./sage/matplotlibrc files. >> >> 3. Do option 2, but only do it for the next 6 months or something. >> After that, assume that everyone has cleaned up their .sage directory, >> so remove the check. >> >> What do people think? > > The existence of a $DOT_SAGE/matplotlibrc file won't affect the above > solution, > > export MPLCONFIGDIR=$DOT_SAGE/matplotlib > > in any way. By that, I mean that matplotlib will simply ignore the > old file because it won't be in the appointed config dir. The reason > for this is that previously, Sage didn't use MPLCONFIGDIR (which > points to the entire config directory), but rather MATPLOTLIBRC, which > just pointed to the rc file in the *top level* .sage directory. > ah, right, I wasn't understanding your solution (for some reason, I thought you were using what we used before, not a new variable pointing to a new directory). +1 to your solution (I'd rather use your more standard directory name over William's non-standard name). Jason > What would be a problem is if Sage previously had created a > .sage/matplotlib/matplotlibrc file that no longer worked. But that > isn't the case. But Williams proposed name for the config dir > (matplotlibconfig) would also work fine. I would probably choose > "matplotlib" because that is the standard name that mpl uses, but it > doesn't really matter. > > Cheers, > > Brian > > > >> Jason >> >> > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: [Sage Bug Report] Wrong matplotlibrc used if user has one in ~/.matplotlib
> ah, right, I wasn't understanding your solution (for some reason, I > thought you were using what we used before, not a new variable pointing > to a new directory). > > +1 to your solution (I'd rather use your more standard directory name > over William's non-standard name). It is important to set the directory, otherwise, it won't solve the problems that William is having with the other things in the directory. Cheers, Brian > Jason > > > > > >> What would be a problem is if Sage previously had created a >> .sage/matplotlib/matplotlibrc file that no longer worked. But that >> isn't the case. But Williams proposed name for the config dir >> (matplotlibconfig) would also work fine. I would probably choose >> "matplotlib" because that is the standard name that mpl uses, but it >> doesn't really matter. >> >> Cheers, >> >> Brian >> >> >> >>> Jason >>> >>> >> >> > >> > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
