[sage-devel] Rules for closing tickets in trac
Hello, since this has come up repeatedly I would like to clarify: Do not close any tickets in trac unless you have been explicitly told to do so by either malb, was, cwitty or mabshoff. This is to avoid having issues slip through the cracks. Once a ticket is closed and off the top of the time line chances are nobody will ever look at it again unless you stumble across it by accident. Just like the [with patch] byline we should come up with something to indicate that a ticket should be looked at like [should be closed], [is invalid] or [is won'tfix]. In addition you should give a reason why you think the action you requested should be taken (the more precise the better) and retag the ticket against the current target, i.e. 2.8.9 at the moment. If you leave it in 2.9 for now it is unlikely to be found and looked at because there are another 140 tickets open against that one. William can configure trac so that closing tickets is limited to a few, but so far he has not done so. But as we have to deal with an ever increasing number of tickets we need to follow the process in order to avoid losing issues and also keep the confusion and the work to deal with tickets to a minimum. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Rules for closing tickets in trac
On Monday 22 October 2007, mabshoff wrote: Hello, since this has come up repeatedly I would like to clarify: Do not close any tickets in trac unless you have been explicitly told to do so by either malb, was, cwitty or mabshoff. This is to avoid having issues slip through the cracks. Once a ticket is closed and off the top of the time line chances are nobody will ever look at it again unless you stumble across it by accident. Just like the [with patch] byline we should come up with something to indicate that a ticket should be looked at like [should be closed], [is invalid] or [is won'tfix]. In addition you should give a reason why you think the action you requested should be taken (the more precise the better) and retag the ticket against the current target, i.e. 2.8.9 at the moment. If you leave it in 2.9 for now it is unlikely to be found and looked at because there are another 140 tickets open against that one. William can configure trac so that closing tickets is limited to a few, but so far he has not done so. But as we have to deal with an ever increasing number of tickets we need to follow the process in order to avoid losing issues and also keep the confusion and the work to deal with tickets to a minimum. I got a clarification for the clarification: Michael mentioned me (malb) and Carl (cwitty) because William (was) asked us to prepare the next release. So for 2.8.9 the three of us are the release managers and consequently we are supposed to close tickets. and a question: Take ticket 729 as an example ( http://trac.sagemath.org/sage_trac/ticket/729 ): It was closed by Robert (rml) because the bugfix/feature request was invalid. Michael (mabshoff) reopened it due to the rule state above. But there is nothing for the release manager to do and I feel perfectly comfortable with rml closing invalid tickets for the Graph subsystem. So I think in those cases it makes perfectly sense to just close tickets. IMHO this rule could be relaxed if we had the e-mail subsystem working (I know it is being worked on). Because in that case, the submitter and the owner of a ticket get an e-mail and can complain if it isn't actually fixed. 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Rules for closing tickets in trac
On Oct 22, 10:40 am, Martin Albrecht [EMAIL PROTECTED] wrote: On Monday 22 October 2007, mabshoff wrote: Hello, Hello, since this has come up repeatedly I would like to clarify: Do not close any tickets in trac unless you have been explicitly told to do so by either malb, was, cwitty or mabshoff. This is to avoid having issues slip through the cracks. Once a ticket is closed and off the top of the time line chances are nobody will ever look at it again unless you stumble across it by accident. Just like the [with patch] byline we should come up with something to indicate that a ticket should be looked at like [should be closed], [is invalid] or [is won'tfix]. In addition you should give a reason why you think the action you requested should be taken (the more precise the better) and retag the ticket against the current target, i.e. 2.8.9 at the moment. If you leave it in 2.9 for now it is unlikely to be found and looked at because there are another 140 tickets open against that one. William can configure trac so that closing tickets is limited to a few, but so far he has not done so. But as we have to deal with an ever increasing number of tickets we need to follow the process in order to avoid losing issues and also keep the confusion and the work to deal with tickets to a minimum. I got a clarification for the clarification: Michael mentioned me (malb) and Carl (cwitty) because William (was) asked us to prepare the next release. So for 2.8.9 the three of us are the release managers and consequently we are supposed to close tickets. and a question: Take ticket 729 as an example (http://trac.sagemath.org/sage_trac/ticket/729): It was closed by Robert (rml) because the bugfix/feature request was invalid. Michael (mabshoff) reopened it due to the rule state above. But there is nothing for the release manager to do and I feel perfectly comfortable with rml closing invalid tickets for the Graph subsystem. So I think in those cases it makes perfectly sense to just close tickets. Well, I see it the same way: rml is responsible for the graph subsystem, so he is the person with the expertise to determine that the ticket is invalid. But he closed that ticket against 2.9, while it is customary to close invalid tickets against the sage-duplicate/ invalid milestone. The same applies for #731. It is not so much the marking the ticket invalid, it just ended up against the wrong milestone. What caused me to actually raise the issue is #656: That one is clearly not a duplicate. #968 is an enhancement relative to #656. During Bug Day 4 William also told rlm not to close tickets until the issue had been officially resolved. IMHO this rule could be relaxed if we had the e-mail subsystem working (I know it is being worked on). Because in that case, the submitter and the owner of a ticket get an e-mail and can complain if it isn't actually fixed. Yep, that has been requested for quite some time. William has enabled smtp support for trac IIRC, but it doesn't work (yet). Martin Cheers, Michael -- 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Rules for closing tickets in trac
Take ticket 729 as an example (http://trac.sagemath.org/sage_trac/ticket/729): It was closed by Robert (rml) because the bugfix/feature request was invalid. Michael (mabshoff) reopened it due to the rule state above. But there is nothing for the release manager to do and I feel perfectly comfortable with rml closing invalid tickets for the Graph subsystem. So I think in those cases it makes perfectly sense to just close tickets. Well, I see it the same way: rml is responsible for the graph subsystem, so he is the person with the expertise to determine that the ticket is invalid. But he closed that ticket against 2.9, while it is customary to close invalid tickets against the sage-duplicate/ invalid milestone. The same applies for #731. It is not so much the marking the ticket invalid, it just ended up against the wrong milestone. Why do we need to change the milestone for invalid tickets? 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Rules for closing tickets in trac
On Oct 22, 11:13 am, Martin Albrecht [EMAIL PROTECTED] wrote: Take ticket 729 as an example (http://trac.sagemath.org/sage_trac/ticket/729):It was closed by Robert (rml) because the bugfix/feature request was invalid. Michael (mabshoff) reopened it due to the rule state above. But there is nothing for the release manager to do and I feel perfectly comfortable with rml closing invalid tickets for the Graph subsystem. So I think in those cases it makes perfectly sense to just close tickets. Well, I see it the same way: rml is responsible for the graph subsystem, so he is the person with the expertise to determine that the ticket is invalid. But he closed that ticket against 2.9, while it is customary to close invalid tickets against the sage-duplicate/ invalid milestone. The same applies for #731. It is not so much the marking the ticket invalid, it just ended up against the wrong milestone. Why do we need to change the milestone for invalid tickets? The idea is to collect all invalid tickets in one milestone so that they can be found by accessing one milestone. You can pull all of them via custom query, but that is not as transparent. I only recently started doing that, so there are invalid tickets attached to older milestones, but I had a discussion with William about that in IRC before creating that special milestone. The discussion happened about 3 weeks ago. Martin Cheers, Michael -- 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [sage-forum] sage-2.8.8
I had the following failure from make test, from devel/sage-main/ sage/numerical/test.py. I'm guessing its from the convoluted history of my fortran installs on that machine (a powerpc apple powerbook): sage -t devel/sage-main/sage/numerical/test.py ** File test.py, line 4: : from cvxopt.base import * Exception raised: Traceback (most recent call last): File /Users/mh/sage-2.8.4.1/local/lib/python2.5/doctest.py, line 1212, in __run compileflags, 1) in test.globs File doctest __main__.example_0[0], line 1, in module from cvxopt.base import *###line 4: : from cvxopt.base import * ImportError: dlopen(/Users/mh/sage-2.8.4.1/local/lib/python/site- packages/cvxopt/base.so, 2): Symbol not found: __g95_ioparm Referenced from: /Users/mh/sage-2.8.4.1/local/lib/python/site- packages/cvxopt/base.so Expected in: dynamic lookup ** File test.py, line 5: : from cvxopt import umfpack Exception raised: Traceback (most recent call last): File /Users/mh/sage-2.8.4.1/local/lib/python2.5/doctest.py, line 1212, in __run compileflags, 1) in test.globs File doctest __main__.example_0[1], line 1, in module from cvxopt import umfpack###line 5: : from cvxopt import umfpack ImportError: dlopen(/Users/mh/sage-2.8.4.1/local/lib/python/site- packages/cvxopt/umfpack.so, 2): Symbol not found: __g95_st_write_done Referenced from: /Users/mh/sage-2.8.4.1/local/lib/python/site- packages/cvxopt/umfpack.so Expected in: dynamic lookup ** 1 items had failures: 2 of 8 in __main__.example_0 ***Test Failed*** 2 failures. On Oct 21, 3:03 pm, John Cremona [EMAIL PROTECTED] wrote: Successfully upgraded to 2.8.8.1 on linux (Kubuntu 7.04): sage --testall (...) All tests passed! Total time for all tests: 1978.6 seconds John Cremona --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [sage-forum] sage-2.8.8
On 10/22/07, Hamptonio [EMAIL PROTECTED] wrote: I had the following failure from make test, from devel/sage-main/ sage/numerical/test.py. I'm guessing its from the convoluted history of my fortran installs on that machine (a powerpc apple powerbook): You're right. We added some doctests in test.py to specifically test that all the convex optimization code really got built. Evidently it didn't for you. If you aren't doing convex optimization (via cvxopt) this won't affect you. By the way, I am able to replicate exactly this problem on my powerpc mac test machine. I've opened http://trac.sagemath.org/sage_trac/ticket/969 about this. sage -t devel/sage-main/sage/numerical/test.py ** File test.py, line 4: : from cvxopt.base import * Exception raised: Traceback (most recent call last): File /Users/mh/sage-2.8.4.1/local/lib/python2.5/doctest.py, line 1212, in __run compileflags, 1) in test.globs File doctest __main__.example_0[0], line 1, in module from cvxopt.base import *###line 4: : from cvxopt.base import * ImportError: dlopen(/Users/mh/sage-2.8.4.1/local/lib/python/site- packages/cvxopt/base.so, 2): Symbol not found: __g95_ioparm Referenced from: /Users/mh/sage-2.8.4.1/local/lib/python/site- packages/cvxopt/base.so Expected in: dynamic lookup ** File test.py, line 5: : from cvxopt import umfpack Exception raised: Traceback (most recent call last): File /Users/mh/sage-2.8.4.1/local/lib/python2.5/doctest.py, line 1212, in __run compileflags, 1) in test.globs File doctest __main__.example_0[1], line 1, in module from cvxopt import umfpack###line 5: : from cvxopt import umfpack ImportError: dlopen(/Users/mh/sage-2.8.4.1/local/lib/python/site- packages/cvxopt/umfpack.so, 2): Symbol not found: __g95_st_write_done Referenced from: /Users/mh/sage-2.8.4.1/local/lib/python/site- packages/cvxopt/umfpack.so Expected in: dynamic lookup ** 1 items had failures: 2 of 8 in __main__.example_0 ***Test Failed*** 2 failures. On Oct 21, 3:03 pm, John Cremona [EMAIL PROTECTED] wrote: Successfully upgraded to 2.8.8.1 on linux (Kubuntu 7.04): sage --testall (...) All tests passed! Total time for all tests: 1978.6 seconds John Cremona -- 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Rules for closing tickets in trac
What caused me to actually raise the issue is #656: That one is clearly not a duplicate. #968 is an enhancement relative to #656. During Bug Day 4 William also told rlm not to close tickets until the issue had been officially resolved. I'm assuming you're talking about 956. The reason I closed 956 and deferred to 968 was because the patches are both to the same area of code, and if you apply the patch in #956, then the ones in 968, funny stuff might happen. The recommended patches in #968 will cover both, so... --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] 2.8.8.1 on Ubuntu
Hi all, I did a fresh install of Ubuntu, downloaded 2.8.7, then did a sage - upgrade, and got the following error: [EMAIL PROTECTED]:/home/kostadm/sage# ./sage -upgrade [...] GCC Version gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c+ +,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with- system-zlib --libexecdir=/usr/lib --without-included-gettext --enable- threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/ 4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486- linux-gnu Thread model: posix gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) make[1]: Entering directory `/home/kostadm/sage/spkg/build/ singular-3-0-3-2-20071020/src' make[1]: *** No rule to make target `distclean'. Stop. make[1]: Leaving directory `/home/kostadm/sage/spkg/build/ singular-3-0-3-2-20071020/src' rm: cannot remove `/home/kostadm/sage/local/bin/Singular*': No such file or directory creating cache ./config.cache checking uname for singular... ix86-Linux checking for gcc... gcc checking whether the C compiler (gcc -fPIC -O3 ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. Unable to configure Singular. Command exited with non-zero status 1 0.41user 0.31system 0:01.31elapsed 55%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+40811minor)pagefaults 0swaps sage: An error occurred while installing singular-3-0-3-2-20071020 Please email sage-devel http://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/kostadm/sage/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/kostadm/sage/spkg/build/singular-3-0-3-2-20071020 and type 'make'. Instead (using bash) type source local/bin/sage-env from the directory /home/kostadm/sage in order to set all environment variables correctly, then cd to /home/kostadm/sage/spkg/build/singular-3-0-3-2-20071020 make: *** [installed/singular-3-0-3-2-20071020] Error 1 Command exited with non-zero status 2 11.77user 1.40system 0:30.39elapsed 43%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+47241minor)pagefaults 0swaps I'm sure I must need to do something trivial, but what is that trivial thing? Thanks, JV --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: [sage-forum] sage-2.8.8
On 10/21/07, William Stein [EMAIL PROTECTED] wrote:
I think I know what's going on.
If you install the Gap optional packages, then reset the
workspace you get the behavior I see. If you don't install
the optional packages you don't. Thus one of the packages
changes the print behavior of Gap.
Indeed, here it is:
gap LoadPackage(hap);
Loading HAP 1.7.5gamma ...
true
gap PolynomialRing(Rationals,2);
PolynomialRing(..., [ x, x_2 ])
My solution will be to slightly change gap.py, so it does *not*
autoload hap into the workspace, then change the doctests
back.Note: In the old gap.py, hap wasn't loaded into the
workspace automatically -- I thought this was a mistake, but
evidently the reason is because hap slightly modifies
how certain things work with gap polynomial rings. Annoying.
I believe this is *illegal* (ie, does not conform to GAP package requirements)
and have reported it. I'll let you know when I hear more. If needed, I'll create
a new gap_packages*.spkg.
Sorry about the hassle.
OK, I've pushed this out, so hg_sage.pull() will get you the
fixed version of gap.py.
William
On 10/21/07, Jaap Spies [EMAIL PROTECTED] wrote:
William Stein wrote:
On 10/21/07, Jaap Spies [EMAIL PROTECTED] wrote:
There seems to be some typos in the test of gap.py
These are not typos. The behavior of gap-4.4.10 changed from that
of gap-4.4.9, and the doctests reflect that change. Evidently for
some reason your gap didn't get upgraded. Try
sage: !gap
This is on a fresh install (but dito with the upgrade):
GAP4, Version: 4.4.10 of 02-Oct-2007, i686-pc-linux-gnu-gcc
gap
to see what version of gap you now have.
Also, you may need to do
sage: gap_reset_workspace()
That does not help. Same test failures.
Jaap
[EMAIL PROTECTED] sage-2.8.8]$ ./sage -t
devel/sage-main/sage/interfaces/gap.py
sage -t devel/sage-main/sage/interfaces/gap.py
**
File gap.py, line 69:
sage: R = gap.PolynomialRing('Rationals', 2); R
Expected:
PolynomialRing(..., [ x, x_2 ])
Got:
PolynomialRing(..., [ x_1, x_2 ])
**
File gap.py, line 71:
sage: I = R.IndeterminatesOfPolynomialRing(); I
Expected:
[ x, x_2 ]
Got:
[ x_1, x_2 ]
**
File gap.py, line 86:
sage: f = gap(str(g)); f
Expected:
-x^5+x_2^2
Got:
-x_1^5+x_2^2
**
1 items had failures:
3 of 22 in __main__.example_0
***Test Failed*** 3 failures.
For whitespace errors, see the file .doctest_gap.py
[2.4 s]
exit code: 256
--
The following tests failed:
sage -t devel/sage-main/sage/interfaces/gap.py
Total time for all tests: 2.4 seconds
[EMAIL PROTECTED] sage-2.8.8]$
--
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~--~~~~--~~--~--~---
[sage-devel] Re: sage -upgrade and file corruption
md5 sums (or sha1 for extra security) could be useful if there's ever any interest in signing spkgs in the future (official or 3rd party ones). - Robert On Oct 21, 2007, at 3:28 PM, Pablo De Napoli wrote: My idea was actually the second one, so nothing has to be changed in current sage packages.I don't see this as so painfull (as the Debian is currently doing something similar for debian packages (actually for each Debian package there are 3 sources files: a .dsc file, with description and checksum, .diff.gz (the differencies as a patch to pristine sources) and .orig.tar.gz (the pristine sources) I think that this good be a good model to follow. But yes, perhaps is just having tar to report if the opeation of unpacking was sucessfull or not. Pablo On 10/21/07, William Stein [EMAIL PROTECTED] wrote: On 10/21/07, Pablo De Napoli [EMAIL PROTECTED] wrote: I'm currently working on ticket #329 My idea is adding to each .spkg file a .spkg.md5 file with the md5checksum This should prevent file corruption. Are you literally adding to each .spkg file. If so, make sure this is completely automatic. I.e., whenever anybody does sage -pkg directory-version the md5 file is created inside the resulting spkg. What are you going to create the md5 hash of, by the way, given that the spkg doesn't exist when you create the md5 hash to add to the spkg? The alternative is that we have to have separate files directory-version.spkg and directory-version.spkg.md5 and then whenever anybody ever wants to trade spkgs, they have to copy around, get, etc. 2 separate files. That would be painful in practice. Just out of curiosity, shouldn't tar report if the file it is unpacking is somehow corrupt? Why do we need md5 hashes at all if the whole point is to determine whether or not a download of a .tar.bz2 file (an spkg) was corrupted or not? Should we be able to get that information from tar during the extract process, or at least change how we make the tarball so that information is available. I really don't want to have to keep track of twice as many files if it isn't absolutely necessary. I've already reimplemented the md5sum standard utility (from the coreutils package) in python (using the md5 module), so that we don't need to add an extra dependency to sage. I still have to modify the logic of the scripts (sage-download- package, etc.) so that they do the right thing. Pablo On 10/20/07, Timothy Clemans [EMAIL PROTECTED] wrote: Hi, I think I have done sage -upgrade a few times when William was in the process of uploading a new release. I think it would be helpful if Sage would check a file on sagemath that gave the latest release that had been completed uploaded. Another possibility might be that William would upload the files to directories that Sage doesn't look in and then move them over to the release directories after they have been completely uploaded. Timothy -- 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Rules for closing tickets in trac
On Oct 22, 5:17 pm, Robert Miller [EMAIL PROTECTED] wrote: What caused me to actually raise the issue is #656: That one is clearly not a duplicate. #968 is an enhancement relative to #656. During Bug Day 4 William also told rlm not to close tickets until the issue had been officially resolved. Hello Robert, I'm assuming you're talking about 956. You are right, sorry for the type. The reason I closed 956 and deferred to 968 was because the patches are both to the same area of code, and if you apply the patch in #956, then the ones in 968, funny stuff might happen. The recommended patches in #968 will cover both, so... Well, #968 has two patches, one of which is idential to the one attached to #656 except that it is rebased against the tree after your fixes went in. I would have suggested to attach the updated version for #656 to that ticket and add a comment not to apply the first, but the second version due to the rewrite attached to #968. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 2.8.8.1 on Ubuntu
On Oct 22, 6:52 pm, John Voight [EMAIL PROTECTED] wrote: Hi all, I did a fresh install of Ubuntu, downloaded 2.8.7, then did a sage - upgrade, and got the following error: [EMAIL PROTECTED]:/home/kostadm/sage# ./sage -upgrade [...] GCC Version gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c+ +,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with- system-zlib --libexecdir=/usr/lib --without-included-gettext --enable- threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/ 4.1.3 --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486- linux-gnu Thread model: posix gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2) make[1]: Entering directory `/home/kostadm/sage/spkg/build/ singular-3-0-3-2-20071020/src' make[1]: *** No rule to make target `distclean'. Stop. make[1]: Leaving directory `/home/kostadm/sage/spkg/build/ singular-3-0-3-2-20071020/src' rm: cannot remove `/home/kostadm/sage/local/bin/Singular*': No such file or directory creating cache ./config.cache checking uname for singular... ix86-Linux checking for gcc... gcc checking whether the C compiler (gcc -fPIC -O3 ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. Unable to configure Singular. Command exited with non-zero status 1 0.41user 0.31system 0:01.31elapsed 55%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+40811minor)pagefaults 0swaps sage: An error occurred while installing singular-3-0-3-2-20071020 Please email sage-develhttp://groups.google.com/group/sage-devel explaining the problem and send the relevant part of of /home/kostadm/sage/install.log. Describe your computer, operating system, etc. If you want to try to fix the problem, yourself *don't* just cd to /home/kostadm/sage/spkg/build/singular-3-0-3-2-20071020 and type 'make'. Instead (using bash) type source local/bin/sage-env from the directory /home/kostadm/sage in order to set all environment variables correctly, then cd to /home/kostadm/sage/spkg/build/singular-3-0-3-2-20071020 make: *** [installed/singular-3-0-3-2-20071020] Error 1 Command exited with non-zero status 2 11.77user 1.40system 0:30.39elapsed 43%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+47241minor)pagefaults 0swaps Hello John, I'm sure I must need to do something trivial, but what is that trivial thing? according to the configure script you have a gcc, but it fails to compile with -fPIC -O3 checking for gcc... gcc checking whether the C compiler (gcc -fPIC -O3 ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. Unable to configure Singular. Command exited with non-zero status 1 Could you try compiling hello world or some or simple C program with the same options and see if anything pops up? The autoconf run of Singular also leaves a log around. There you should find the exact failure why that config test failed. Thanks, JV Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: 2.8.8.1 on Ubuntu
Boo. Only part of gcc gets installed by Ubuntu. I had to sudo apt-get install build-essential. Now we're good. JV --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage -upgrade and file corruption
I think you can easily make tar-archives that contain a checksum, if you agree on some extremely mild file naming convention for such a checksum (i.e., the archive is not allowed to contain a filename that clashes with the file that stores the checksum). Of course, the key is that when you add something to the archive, the file changes, so the plain md5sum of the total archive changes. You have to md5sum something that is easily extracted and independent of the later added md5sum. The options -O (dump to stdout), -r (append file) and -- exclude provide the necessary features for tar. Procedure for storing a checksum in a tar archive: -- (tar xf file.tar --exclude md5sum.check -O; \ tar tvf file.tar --exclude md5sum.check ) | md5sum md5sum.check tar -rf file.tar md5sum.check -- Procedure for checking that the stored sum agrees with the computed one: -- tar xf file.tar md5sum.check -O storedcheck (tar xf file.tar --exclude md5sum.check -O; \ tar tvf file.tar --exclude md5sum.check ) | md5sum computedcheck cmp storedcheck computedcheck -- Note that we need to include the directory listing information as well, because the output of -O does not include file names (i.e., one could move files around and still have the same checksum) If it is ever decided that .spkgs should be signed, then you could include a .gpg-file via the same procedure. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: sage -upgrade and file corruption
On 10/22/07, Nils Bruin [EMAIL PROTECTED] wrote: I think you can easily make tar-archives that contain a checksum, if you agree on some extremely mild file naming convention for such a checksum (i.e., the archive is not allowed to contain a filename that clashes with the file that stores the checksum). Of course, the key is that when you add something to the archive, the file changes, so the plain md5sum of the total archive changes. You have to md5sum something that is easily extracted and independent of the later added md5sum. The options -O (dump to stdout), -r (append file) and -- exclude provide the necessary features for tar. Procedure for storing a checksum in a tar archive: -- (tar xf file.tar --exclude md5sum.check -O; \ tar tvf file.tar --exclude md5sum.check ) | md5sum md5sum.check tar -rf file.tar md5sum.check -- Procedure for checking that the stored sum agrees with the computed one: -- tar xf file.tar md5sum.check -O storedcheck (tar xf file.tar --exclude md5sum.check -O; \ tar tvf file.tar --exclude md5sum.check ) | md5sum computedcheck cmp storedcheck computedcheck -- Note that we need to include the directory listing information as well, because the output of -O does not include file names (i.e., one could move files around and still have the same checksum) If it is ever decided that .spkgs should be signed, then you could include a .gpg-file via the same procedure. I really like this idea a lot! It's vastly better -- I think -- from a usability point of view than having to constantly pass around .spkg's and .md5 files together. It will just work 100% automatically and transparently to users, once we modify some scripts in local/bin/sage-*. While we're at it, we should make the following work: 1) sage -unpkg packagename-version.spkg which just does tar jxvf and does the above consistency checks. I suggest sage -unpkg, since making a package is sage -pkg. Another option would be sage -extract blah.spkg, or even sage -x blah.spkg.Please note, sage spkg's can be either bzip2'd or not, so that has to be taken account of. 2) sage -i packagename-version where packagename-version is the name of a *directory*, does sage -pkg on the directory, then installs 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Integrating SymPy with SAGE
Hi, I finally found time to write those _sage_ methods in SymPy we discussed earlier. The code is here: http://dakol.hopto.org/sympy-sage/ (we are in the state of moving from Subversion to Mercurial in SymPy). I created a new sympy spkg, by updating it's hg repository: http://dakol.hopto.org/sympy-spkg/ (the change is trivial, because the src is not included). The spkg can be downloaded from: http://dakol.fsik.cvut.cz/~ondra/sympy-0.5.5.spkg Install with: ./sage -i sympy-0.5.5.spkg Now test it. Run this in sage: - #!/usr/bin/env sage #import sys #sys.path.insert(0,/home/ondra/ext/sympy-sage/) from sympy import __version__ print __version__ print SAGE: e = 1/cos(x)**3 print e f = e.taylor(x, 0, 8) print f print SymPy: from sympy import Symbol, cos, sympify, pprint from sympy.abc import x e = sympify(1)/cos(x)**3 print e f = e.series(x, 10) print f print \nSymPy pretty printer: pprint(e) pprint(f) print \nSymPy - SAGE: print e._sage_() print f._sage_() --- it will produce the following output (I put the code above into example.sage): [EMAIL PROTECTED]:~/ext/sage-2.8.7-debian32-i686-Linux$ ./sage example.sage 0.5.5-svn SAGE: 1 --- 3 cos (x) 86 4 2 8651 x241 x11 x3 x --- + -- + - + + 1 13440 240 8 2 SymPy: cos(x)**(-3) 1 + (3/2)*x**2 + (11/8)*x**4 + (241/240)*x**6 + (8651/13440)*x**8 + O(x**10) SymPy pretty printer: -3 cos (x) 2 46 8 3*x11*x241*x8651*x 1 + + - + -- + --- + O(x**10) 2 8 240 13440 SymPy - SAGE: 1 --- 3 cos (x) 86 4 2 8651 x241 x11 x3 x --- + -- + - + + 1 13440 240 8 2 Currently only the Add, Mul, Pow, Rational, Integer, sin, cos classes have the _sage_ method, but that is enough for some basic playing. Let's now implement the corresponding _sympy_ method in SAGE and maybe a few more iterations to see if we like it. And if so, I'll implement the _sage_() for more SymPy classes. I'd like to achieve a state, where the same code in SAGE could be run on both backends (Maxima and SymPy). That way we could easily see where Maxima is better than SymPy and vice versa. Could you William please create a trac login for me? I'd like to open and discuss a new ticket for it. Also so that I can attach any bundles in there. Are you planning to make another SAGE release before SD 6? If so, it would be good if we could make it before it, then we'll release SymPy, create spkg, you'll release SAGE, include the spkg, so that it's working out of the box for everyone at SD6 and we can discuss some new more exciting things to do in Bristol. I am sorry it has taken me so long, I was really busy. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Integrating SymPy with SAGE
On 10/22/07, Ondrej Certik [EMAIL PROTECTED] wrote: Are you planning to make another SAGE release before SD 6? If so, it We plan to make several releases :-). I've made updating sympy a trac ticket tagged for soon: http://trac.sagemath.org/sage_trac/ticket/971 would be good if we could make it before it, then we'll release SymPy, create spkg, you'll release SAGE, include the spkg, so that it's working out of the box for everyone at SD6 and we can discuss some new more exciting things to do in Bristol. I am sorry it has taken me so long, I was really busy. Ondrej -- 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Integrating SymPy with SAGE
I've made updating sympy a trac ticket tagged for soon: http://trac.sagemath.org/sage_trac/ticket/971 Just a note that the spkg above is just a preliminary unreleased version and contains some other minor bugs. But I want to settle on some interface to SAGE now. And then we'll fix the bugs and make a release and then you can include it in SAGE officially. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] edit_module patch updated
See: http://sagetrac.org/sage_trac/ticket/768 I have updated the attached patch to be clean against 2.8.8.1. When I checked the edit() command in sage 2.8.8.1, I realized it was really broken -- It doesn't work if EDITOR is unset in the environment. The patch attached to the trac ticket is supposed to fix that. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
