[sage-devel] Re: Changes to supported platforms
2012-05-02 21:44, Jeroen Demeyer skrev:
On 2012-05-02 21:40, Johan Grönqvist wrote:
2012-05-02 10:44, Jeroen Demeyer skrev:
I made some changes to http://wiki.sagemath.org/SupportedPlatforms
The only debian version mentioned for sage-5.0 is "Debian 5.0 on x86
(Both 32-bit and 64-bit)" which is unsupported since February.
Debian 6.0, the only released and supported version at this time, is not
mentioned.
Can you confirm that sage-5.0.rc0 builds and passes all tests on Debian
6.0? If so, you can change the page to include Debian 6.0.
The mercurial test (cmdline.py) fails in my default locale, because the
term "Distributed" is translated to the Swedish ("Distribuerad").
Perhaps the test should always run in locale "C"?
Debian 7 (amd64) (not yet released, but widely used) passes all tests.
Debian 6 (amd64) passes all tests, as Dima reported.
Debian 6 (i386) passes all tests.
Regards
Johan
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] Re: Can we develop a plan to get 100% doctest coverage?
On Thu, May 3, 2012 at 8:50 AM, rjf wrote: > > > It seems to me that "doctests" are supposed to serve two purposes. > Since I have not looked at them (well, maybe one or two over the years?), > my comments may be naive or irrelevant, but here goes. > > documentation has to be written by the programmer who writes the code, > preferably before the code is written, but certainly before the code is > inserted into a system. It should include examples of how the code is > thought to be useful, written as complete examples if possible. It should > include, in a separate section, the "edge" cases that are either the most > extreme but "still working" examples, and maybe the just one-more than > that which fail to work, but which an unwary user might think might work. Yes, exactly. > then there are the tests which are almost inevitably inadequate. Many > programs (certainly most in Maxima) do not exhaustively test their inputs > for nonsense (e.g. non-terminating computations, ill-specified tasks) > because these conditions cannot be detected 100%, and sometimes it > is better to just let stuff go through and hope that some program further > down > the line can make sense of it. For example, one could check for strict > adherence to expectations, like "argument must be a polynomial in x" but > would you notice that acos(n*cos(x)) is a polynomial? > > But some checking is probably worthwhile, like checking for the expected > number of arguments. Though even there, someone might have ANOTHER > function in mind... > > Anyway, a list of things that the programmer has thought of that will not > work and might be useful for someone to fix up later could be helpful. > > A list of things that you might think the program will do but it won't > (features?) e.g. "This program does not work for complex numbers". > > Of course in some cases writing the framework to do checking of all kinds of > buggy input > can be daunting, and may even be expensive at runtime. > > In the case of Sage, where important functionality is simply imported from > external packages after the fact, and the programmer may be long gone, > your options are limited. > > Having a naive person come by after the fact and write tests can even be > counterproductive --- if it gives you a false sense of confidence that > something works when the tests are quite meaningless. I would hope at least one of the test writer and test reviewer will not be completely naive, at least often enough that this is not a big issue. Author-written tests are valuable (and have been a requirement for most of Sage's history) but tests written by a non-author are quite valuable as well (verifying that the function conforms to its specifications as provided by its definition/documentation, and hitting corner cases the original author may not have thought of.) > As an example, > I recall someone testing/comparing Macsyma's polynomial factoring program > against some other program, and drawing conclusions about the speed of > the Berlekamp algorithm. > > In fact most of the tests were composed of "well-known" factoring special > cases, > most of which were specifically tested for in Macsyma, and for which the > algorithm was never invoked. > > Also, if you insist on writing doctests for maxima functionality accessed > through > Sage, you should probably document what maxima does. Then you can > separately document what Sage does to prepare input and process output > from maxima. Ideally, maxima will have it's own, complete testing suite and we can "just trust" it. Our tests will then be that we are using maxima correctly, and that it and our interface to it, behave as expected. Of course due to limited resources we are in a less than ideal case on both sides of the fence (and some packages have little to no tests, in which case Sage's tests themselves have proved a valuable regression suite). I do feel though at this point simply writing more doctests has less value than investigating other forms of coverage and testing, but it's still a worthwhile task (as is adding better/more doctests to those functions that already have time). - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Help with detecting "glibc detected"
Hi Volker, On 4 Mai, 18:37, Volker Braun wrote: > Simon, for debugging and correctness check purposes it would be great to > have a hook to run an optional garbage collection (or anything else) before > each access to a weak dictionary cache in Sage. Did you ever think about > something like that? I made the python debugger hook print information on each call. However, as I mentioned earlier, this didn't help, because it made the problem vanish. Of course, modifying the weak dictionaries such that either garbage collection occurs or some information on the objects that are accessed in the weak dictionaries are printed to some file, would be the next logical step. > Right now one can abuse the python debugger hook to > continuously collect garbage but that slows Sage down to a crawl. I wouldn't care about slowing down sage for debugging, and actually I hope that that would trigger the error. What I tried was to use the Python hook to print the types of all collectable objects to a file. That exceeded my disc quota... Best regards, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] sage-5.0.rc0 released
On Friday, May 4, 2012 12:27:33 PM UTC-7, Henry de Valence wrote: > > On Wed, May 2, 2012 at 3:02 AM, Jeroen Demeyer wrote: > > Please build, test, and report! We'd love to hear about your > > experiences with this release. > > Running ./sage -testall -long, I get: > What sort of machine, OS, etc.? > > -- > The following tests failed: > > > sage -t -long -force_lib > "devel/sage/doc/en/installation/source.rst" # Time out > sage -t -long -force_lib "devel/sage/sage/misc/sagedoc.py" > sage -t -long -force_lib > "devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py" # Time > out > Total time for all tests: 68027.9 seconds > Please see /home/hdevalence/.sage//tmp/test.log for the complete log > from this test. > > The test that didn't time out but just failed has the following > description in > the log file: > The ensuing error messages make it look like the documentation didn't build. Is that true? -- John -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] sage-5.0.rc0 released
On Wed, May 2, 2012 at 3:02 AM, Jeroen Demeyer wrote:
> Please build, test, and report! We'd love to hear about your
> experiences with this release.
Running ./sage -testall -long, I get:
--
The following tests failed:
sage -t -long -force_lib
"devel/sage/doc/en/installation/source.rst" # Time out
sage -t -long -force_lib "devel/sage/sage/misc/sagedoc.py"
sage -t -long -force_lib
"devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py" # Time
out
Total time for all tests: 68027.9 seconds
Please see /home/hdevalence/.sage//tmp/test.log for the complete log
from this test.
The test that didn't time out but just failed has the following description in
the log file:
sage -t -long -force_lib "devel/sage/sage/misc/sagedoc.py"·
**
File "/home/hdevalence/code/sage-5.0.rc0/devel/sage/sage/misc/sagedoc.py",
line 22:
sage: for line in open(docfilename):
if "#sage.symbolic.expression.Expression.N" in line:
print line
Exception raised:
Traceback (most recent call last):
File "/home/hdevalence/code/sage-5.0.rc0/local/bin/ncadoctest.py",
line 1231, in run_one_test
self.run_one_example(test, example, filename, compileflags)
File "/home/hdevalence/code/sage-5.0.rc0/local/bin/sagedoctest.py",
line 38, in run_one_example
OrigDocTestRunner.run_one_example(self, test, example,
filename, compileflags)
File "/home/hdevalence/code/sage-5.0.rc0/local/bin/ncadoctest.py",
line 1172, in run_one_example
compileflags, 1) in test.globs
File "", line 1, in
for line in open(docfilename):###line 22:
sage: for line in open(docfilename):
IOError: [Errno 2] No such file or directory:
'/home/hdevalence/code/sage-5.0.rc0/devel/sage/doc/output/html/en/reference/sage/symbolic/expression.html'
**
File "/home/hdevalence/code/sage-5.0.rc0/devel/sage/sage/misc/sagedoc.py",
line 576:
sage: 'abvar/homology' in _search_src_or_doc('doc', 'homology',
'variety', interact=False) # long time (4s on sage.math, 2012)
Expected:
True
Got:
False
**
2 items had failures:
1 of 5 in __main__.example_0
1 of 8 in __main__.example_8
***Test Failed*** 2 failures.
For whitespace errors, see the file /home/hdevalence/.sage//tmp/sagedoc_25648.py
[518.5 s]
Cheers,
Henry de Valence.
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
Re: [sage-devel] sage-5.0.rc0 released
On Wed, May 2, 2012 at 5:02 PM, Jeroen Demeyer wrote: > Dear Sage lovers, > > We're releasing Sage 5.0.rc0. > > Source archive: > > http://boxen.math.washington.edu/home/release/sage-5.0.rc0/sage-5.0.rc0.tar > > Upgrade path: > > http://boxen.math.washington.edu/home/release/sage-5.0.rc0/sage-5.0.rc0/ > > The source and upgrade path can also be found on the mirror network > (you might need to wait a while before the mirrors are synchronized): > > http://www.sagemath.org/download-latest.html > > > Please build, test, and report! We'd love to hear about your > experiences with this release. > > Built successfully on i386/i686 LSB Version: core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch Distributor ID: Ubuntu Description:Ubuntu 11.10 Release:11.10 Codename: oneiric Only env variables set: MAKE=make -j2 SAGE_PARALLEL_SPKG_BUILD=yes All ./sage -testall -long passed except: sage -t -long -force_lib "devel/sage/sage/misc/randstate.pyx" # Time out sage -t -long -force_lib "devel/sage/sage/interacts/debugger.py" # Time out sage -t -long -force_lib "devel/sage/sage/interfaces/expect.py" # Time out sage -t -long -force_lib "devel/sage/sage/interfaces/sage0.py" # Time out sage -t -long -force_lib "devel/sage/sage/interfaces/psage.py" # Time out sage -t -long -force_lib "devel/sage/sage/tests/startup.py" # Time out -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] eigenvalues for symmetric matrices
I am making an appeal to have the patch http://trac.sagemath.org/sage_trac/ticket/11608 reviewed. For background, I'll be giving some lectures on algebraic graph theory at Simon Fraser University in July (see http://www.sfu.ca/~mdevos/summerschool2012/CourseDetails.html) and I want the students working with spectral decompositions in sage. This patch would make all our lives easier. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Help with detecting "glibc detected"
Simon, for debugging and correctness check purposes it would be great to have a hook to run an optional garbage collection (or anything else) before each access to a weak dictionary cache in Sage. Did you ever think about something like that? Right now one can abuse the python debugger hook to continuously collect garbage but that slows Sage down to a crawl. On Friday, May 4, 2012 12:13:27 PM UTC-4, Simon King wrote: > > Hi Willem Jan, > > On 4 Mai, 17:37, Willem Jan Palenstijn wrote: > > > Anyway, I still wonder: Can't one use valgrind to detect those things? > > > > > I tried > > > valgrind --log-file=... ./sage -t > devel/sage/sage/crypto/mq/mpolynomialsystem.py > > > and then "glibc detected" did show up on screen. But after > interrupting > > > with Ctrl-c, the log file wasn't exactly helpful (just a handful of > > > lines). > > > > Did you try ./sage -t -valgrind devel/sage/sage/ ? > > No, since I don't have the optional valgrind spkg installed - yet... > > > You probably need either the valgrind optional spkg or just the > sage.supp from > > it in local/lib/valgrind/sage.supp. > > > > Running "valgrind ./sage -t " will just debug the shell executing > the sage > > script, not sage itself. (--trace-children=yes should get around that, > by the > > way, but ./sage -t -valgrind would be preferable if that works.) > > I'll certainly try! > > BTW, I made some progress, in the sense that changing a weak > dictionary into a strong dictionary fixed that test - however, not all > is good: Another test fails with exactly the same message, and passes > if the strong dictionary is reverted into a weak dictionary! > > Anyway, it seems to confirm that the problem comes from garbage > collection. > > Best regards, > Simon > -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] SAT and MAXSAT in Sage
The author of akmaxsat is a good friend of mine. He was excited to hear that an interface to his solver might be added to Sage. So if you need any additional interface in akmaxsat, he should be able to do something about it. If you start writing a wrapper, please CC me (saraedum) on the ticket — I'd like to help to such efforts. julian * Dima Pasechnik [2012-05-01 09:07:51 +]: > Has there been any discussion and/or consensus on how to encode boolean > formulae in Sage? > > I, incidentally, need to solve some MAXSAT problems from Sage-generated > data, and am musing about writing a proper interface to akmaxsat, see > http://www.uni-ulm.de/fileadmin/website_uni_ulm/iui.inst.190/Mitarbeiter/kuegel/akmaxsat_1.1.tgz > which has a Sage-compatible licence, by the way... > > Dima > > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Help with detecting "glibc detected"
Hi Willem Jan, On 4 Mai, 17:37, Willem Jan Palenstijn wrote: > > Anyway, I still wonder: Can't one use valgrind to detect those things? > > > I tried > > valgrind --log-file=... ./sage -t > > devel/sage/sage/crypto/mq/mpolynomialsystem.py > > and then "glibc detected" did show up on screen. But after interrupting > > with Ctrl-c, the log file wasn't exactly helpful (just a handful of > > lines). > > Did you try ./sage -t -valgrind devel/sage/sage/ ? No, since I don't have the optional valgrind spkg installed - yet... > You probably need either the valgrind optional spkg or just the sage.supp from > it in local/lib/valgrind/sage.supp. > > Running "valgrind ./sage -t " will just debug the shell executing the sage > script, not sage itself. (--trace-children=yes should get around that, by the > way, but ./sage -t -valgrind would be preferable if that works.) I'll certainly try! BTW, I made some progress, in the sense that changing a weak dictionary into a strong dictionary fixed that test - however, not all is good: Another test fails with exactly the same message, and passes if the strong dictionary is reverted into a weak dictionary! Anyway, it seems to confirm that the problem comes from garbage collection. Best regards, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Help with detecting "glibc detected"
On Fri, May 04, 2012 at 07:31:46AM +, Simon King wrote: > On 2012-05-04, Simon King wrote: > >> I guess I better try whether garbage collection is related. Or create a > >> hook, such that all occuring calls to Python functions or methods are > >> listed. > > Aha! When disabling garbage collection before the failing test and > enabling it afterwards, then the tests pass as well! > > I'll see whether I can make gc document what objects it collects. That > will hopefully tell me what object is causing the double free when being > deallocated. > > Anyway, I still wonder: Can't one use valgrind to detect those things? > > I tried > valgrind --log-file=... ./sage -t > devel/sage/sage/crypto/mq/mpolynomialsystem.py > and then "glibc detected" did show up on screen. But after interrupting > with Ctrl-c, the log file wasn't exactly helpful (just a handful of > lines). Did you try ./sage -t -valgrind devel/sage/sage/ ? You probably need either the valgrind optional spkg or just the sage.supp from it in local/lib/valgrind/sage.supp. Running "valgrind ./sage -t " will just debug the shell executing the sage script, not sage itself. (--trace-children=yes should get around that, by the way, but ./sage -t -valgrind would be preferable if that works.) -Willem Jan -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] eclib on googlecode
I answered this partly in your off-list message to me. I can divide the binaries into 3 classes (but the boundaries are not so clear): (1) mwrank (needed to be installed for Sage; none of the others are) (2) programs which *I* need to be installed when I do "make install" on my machine (3) everything else, let's call them "tests" which are used as tests but not for real work. For simplicity I merged (2) and (3), and made "make install" install (1)+(2)+(3) by default, with a non-default option causing only (1) to be installed, as in the Sage install. On 4 May 2012 09:34, Julien Puydt wrote: > Le mercredi 23 février, John Cremona a écrit: >> The source for eclib is now at eclib.googlecode.com. > > The tests seem to be considered as normal programs -- hence installed > when typing "make install". > > If that's not the intent, you should use "noinst_PROGRAMS" instead of > "bin_PROGRAMS" in tests/Makefile.am. > > If that is the intent, then it is annoying, since for example "tred" > is also the name of a graphviz program. :-/ > If thta's the only problem I could rename it -- its name means "test-reduce" and acts both as a test program and also as a useful one (if you like to reduce integral binary quartics, at least). john > Snark on #sagemath > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] eclib on googlecode
Le mercredi 23 février, John Cremona a écrit: > The source for eclib is now at eclib.googlecode.com. The tests seem to be considered as normal programs -- hence installed when typing "make install". If that's not the intent, you should use "noinst_PROGRAMS" instead of "bin_PROGRAMS" in tests/Makefile.am. If that is the intent, then it is annoying, since for example "tred" is also the name of a graphviz program. :-/ Snark on #sagemath -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] eclib on googlecode
Le vendredi 04 mai, Julien Puydt a écrit: > I know I can use autogen.sh to get what I need That script should run libtoolize, after aclocal and before automake. Snark on #sagemath -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] eclib on googlecode
Le vendredi 04 mai, Julien Puydt a écrit: > Le mercredi 23 février, John Cremona a écrit: > > The source for eclib is now at eclib.googlecode.com. > > I tried to compile it, but soon hit a wall: > > jpuydt@newton:/tmp/eclib$ ./configure > configure: error: cannot find install-sh, install.sh, or shtool in "." > "./.." "./../.." Just to be clear : I know I can use autogen.sh to get what I need, but I find strange that configure is there, and the needed files to run it aren't : I would expect either zero generated files or all of them. Snark on #sagemath -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] eclib on googlecode
Le mercredi 23 février, John Cremona a écrit: > The source for eclib is now at eclib.googlecode.com. I tried to compile it, but soon hit a wall: jpuydt@newton:/tmp/eclib$ ./configure configure: error: cannot find install-sh, install.sh, or shtool in "." "./.." "./../.." Hope that helps, Snark on #sagemath -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Help with detecting "glibc detected"
On 2012-05-04, Simon King wrote: >> I guess I better try whether garbage collection is related. Or create a >> hook, such that all occuring calls to Python functions or methods are listed. Aha! When disabling garbage collection before the failing test and enabling it afterwards, then the tests pass as well! I'll see whether I can make gc document what objects it collects. That will hopefully tell me what object is causing the double free when being deallocated. Anyway, I still wonder: Can't one use valgrind to detect those things? I tried valgrind --log-file=... ./sage -t devel/sage/sage/crypto/mq/mpolynomialsystem.py and then "glibc detected" did show up on screen. But after interrupting with Ctrl-c, the log file wasn't exactly helpful (just a handful of lines). Best regards, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Help with detecting "glibc detected"
PPS: On 2012-05-04, Simon King wrote: > PS: > > I guess I better try whether garbage collection is related. Or create a > hook, such that all occuring calls to Python functions or methods are listed. I tried the latter. But helas, all tests pass when tracing the python calls. Big bug fun here... Cheers, Simon -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Help with detecting "glibc detected"
Le vendredi 04 mai, Simon King a écrit: > Hi Julien > > On 2012-05-03, Julien Puydt wrote: > >> However, when I give the same commands in an interactive session > >> (without change_warning_output(sys.stdout), since I don't know > >> where to import that from), there is no crash. That's not good for > >> debugging. I could try to control garbage collection, though. > >> Perhaps that's triggering the crash. > > > > I suggest to modify the .py by commenting out that line, then run > > the non-interactive test -- to see if it's indeed the culprit. > > change_warning_output(sys.stdout) is not part of the doc test, but it > is added by the doctest framework. Hence, I can't comment it out. > > In order to test whether it is really the culprit, I'd rather like to > know where I can that command import from, so that I can add when > executing the test on the command line. I suggest you look for change_warning_output in local/bin/sage-doctest :-) Snark on #sagemath -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
