On Oct 4, 4:54 am, William Stein wst...@gmail.com wrote:
On Sat, Oct 3, 2009 at 8:07 PM, Rob Beezer goo...@beezer.cotse.net wrote:
On Oct 3, 6:05 pm, William Stein wst...@gmail.com wrote:
And this has already been almost completed by David Loeffler based
on work by me.
Sorry, I've just seen William's earlier post in this thread, and I see
that there was no need for my rather combative previous post -- I
apologise for any offence I may have caused.
David
On Oct 4, 2:05 am, William Stein wst...@gmail.com wrote:
On Sat, Oct 3, 2009 at 1:30 PM, David Joyner
Building on 64-bit SuSE with SAGE_CHECK=yes failed at libgcrypt,
with a bunch of errors in the gcrypt test script:
make[4]: Entering directory `/home/david/sage-4.1.2.rc0/spkg/build/
libgcrypt-1.4.3.p2/src/tests'
version:1.4.0:
I will give it a try once the current build has finished.
David
On Oct 1, 12:39 pm, Minh Nguyen nguyenmi...@gmail.com wrote:
Hi David,
On Thu, Oct 1, 2009 at 9:36 PM, davidloeffler dave.loeff...@gmail.com wrote:
Building on 64-bit SuSE with SAGE_CHECK=yes failed at libgcrypt
I've come up with another error. This is the first time I've built
with SAGE_CHECK set, so it's running all the test suites in all the
packages, and quaddouble fails:
Successfully installed quaddouble-2.2.p9
Running the test suite.
make[2]: Entering directory
On Oct 1, 4:15 pm, William Stein wst...@gmail.com wrote:
On Thu, Oct 1, 2009 at 6:47 AM, davidloeffler dave.loeff...@gmail.com wrote:
I've come up with another error. This is the first time I've built
with SAGE_CHECK set, so it's running all the test suites in all the
packages
On Oct 1, 12:39 pm, Minh Nguyen nguyenmi...@gmail.com wrote:
Hi David,
On Thu, Oct 1, 2009 at 9:36 PM, davidloeffler dave.loeff...@gmail.com wrote:
Building on 64-bit SuSE with SAGE_CHECK=yes failed at libgcrypt,
with a bunch of errors in the gcrypt test script:
Can you try using
On Oct 1, 4:28 pm, William Stein wst...@gmail.com wrote:
On Thu, Oct 1, 2009 at 8:23 AM, davidloeffler dave.loeff...@gmail.com wrote:
On Oct 1, 4:15 pm, William Stein wst...@gmail.com wrote:
On Thu, Oct 1, 2009 at 6:47 AM, davidloeffler dave.loeff...@gmail.com
wrote:
I've come up
I'm seeing some errors building the reference manual, from sage/
schemes/elliptic_curves/ell_rational_field.py and sage/databases/
jones.py. Presumably these are coming from the tickets
#6045: Robert Bradshaw: Computation of Heegner points [Reviewed by
John Cremona, Minh Van Nguyen]
#6332:
On Jul 21, 10:56 am, davidloeffler dave.loeff...@gmail.com wrote:
I'm seeing some errors building the reference manual, from sage/
schemes/elliptic_curves/ell_rational_field.py and sage/databases/
jones.py. Presumably these are coming from the tickets
#6045: Robert Bradshaw: Computation
Could someone point me to a reason why anything should be printed as
1.*var?
To remind you that the computation you're doing is only correct to 8
decimal places? If you want exact computations you shouldn't be using
the real field as base.
David
On Jul 13, 10:59 pm, Jaap Spies j.sp...@hccnet.nl wrote:
I think the documentation build system needs some polishing.
It's not really the fault of the documentation build system; it's the
upgrade and clone scripts that are at fault. In particular, the
decision to use hard links for the
On Jul 13, 8:24 am, Minh Nguyen nguyenmi...@gmail.com wrote:
As it now stands, the HTML version of the reference manual of Sage
4.1.1 is bit broken. You can build the HTML version. However, if the
docstring for a function or class uses the .. MATH:: tag, then it
won't render in the
On Jul 9, 9:02 am, Pat LeSmithe qed...@gmail.com wrote:
Minh Nguyen wrote:
Note that I have already deleted the experimental repository sage-exp,
but the documentation build script (I think) still links to or uses
that deleted repository. This might be due to ticket #5350
This is now #6462.
(I have played with it a bit myself, and I can get pickling and
unpickling to work, by defining a __reduce__ function for orders, and
adjusting the __reduce__ function for number field elements; but now
the standard x == loads(dumps(x)) test doesn't seem to work.)
David
On
It is indeed a bit strange that OrderElement derives from
FieldElement. But my diagnosis was different: Parent classes that have
attributes which are Elements cause problems for the default Python
unpickler.
For instance, if X is an AbsoluteOrder, then loads(dumps(X)) works and
equals X, *as
Patch is now up at: http://trac.sagemath.org/sage_trac/ticket/6462
David
On Jul 4, 2:14 pm, davidloeffler dave.loeff...@gmail.com wrote:
It is indeed a bit strange that OrderElement derives from
FieldElement. But my diagnosis was different: Parent classes that have
attributes which
I got the same thing; and when I added a single quote in the obvious
place, I got a new error:
Traceback (most recent call last):
File /home/david/sage-4.1/local/bin/sage-apply-ticket, line 20, in
module
import sage.misc.hg as hg
File
On Jun 27, 11:54 pm, davidloeffler dave.loeff...@gmail.com wrote:
On SuSE, 32-bit, sage -testall -long passes except for errors in the
same three files Jaap reported above (and a harmless timeout in
elliptic curves).
I spoke too soon. Something rather harmful has in fact happened: the
wrong
I've got a build running on my laptop at the moment, and I was
wondering: why does the install script not run the Flint test suite?
I'm puzzled by this since it did run Flint tests when I installed
4.0.2, which was actually the same Flint spkg version
(flint-1.3.0.p1.spkg)
David
On SuSE, 32-bit, sage -testall -long passes except for errors in the
same three files Jaap reported above (and a harmless timeout in
elliptic curves).
Craig: thanks for pointing out SAGE_CHECK. But it strikes me that
there is no way I can run those tests now, without recompiling the
On Jun 16, 2:15 am, Nick Alexander ncalexan...@gmail.com wrote:
On 15-Jun-09, at 4:22 PM, John H Palmieri wrote:
Someone didn't format their reST correctly, so building the reference
manual now produces warnings/errors.
Has the reference manual ever built correctly? (I always get tons
I notice that you still have libm4ri-20090512.spkg in this version,
rather than malb's updated libm4ri-20090615.spkg. Is this deliberate?
The former failed to build for lots of people (including me).
David
--~--~-~--~~~---~--~~
To post to this group, send email
Wow, that's a fast release cycle :-)
On Jun 16, 12:34 pm, William Stein wst...@gmail.com wrote:
On Tue, Jun 16, 2009 at 12:28 PM, davidloefflerdave.loeff...@gmail.com
wrote:
I notice that you still have libm4ri-20090512.spkg in this version,
rather than malb's updated
Is there a copy anywhere we can use with sage -upgrade?
David
On Jun 15, 9:13 am, Nick Alexander ncalexan...@gmail.com wrote:
Hi all,
Here's Sage 4.0.2.rc0. Come and get it while it's hot:
http://sage.math.washington.edu/home/ncalexan/releases
We merged all of the tickets with positive
Can I make a special request for this release? It would be really nice
if we could get rid of the insufferable WARNING: html_favicon is not
an .ico file on building the documentation. Inspection reveals that
the favicon is set to output/html/en/blah/_static/sageicon.png,
which is not an .ico file
On Jun 8, 1:05 pm, William Stein wst...@gmail.com wrote:
Just out of curiosity, if you do sage -upgrade again, does it build
the documentation yet again?
William
Yes, it does.
David
--~--~-~--~~~---~--~~
To post to this group, send email to
On Jun 6, 3:47 am, William Stein wst...@gmail.com 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
\begin{grumble}
For me, 4.0.1.alpha0 builds successfully on 32-bit Linux (upgrading
from 4.0). But there are a bunch of errors building the reference
manual, coming from sage.combinat.backtrack.SearchForest. This is
rather frustrating given the hours of work I put in to making sure the
4.0 docs
On Jun 2, 4:35 pm, kcrisman kcris...@gmail.com wrote:
Though I'll point out, for the sake of argument, that some of us have
such underpowered computers that even running full doctests is not
practical (i.e. everything times out), and given how long it takes to
build the documentation
At the end of the compilation, when it generates the reference manual,
I'm getting a huge bunch of warning messages from the Sphinx parser.
These are due to badly formatted ReST docstrings. I've opened a ticket
(#6149) and uploaded a patch -- any volunteers to review this? It
would look a bit
On May 28, 7:00 pm, John Cremona john.crem...@gmail.com wrote:
2009/5/28 Marshall Hampton hampto...@gmail.com:
I had the same two numerical noise type failures in matrix2.pyx and
expression.pyx, on an intel mac running 10.5. Those were the only
failures.
Same here on ubiuntu 32-bit.
Can I use this opportunity to request some reviews for modular forms
patches? I decided I'd spend a few afternoons squashing as many easy
modular forms buglets as I could, with the result that there is now a
bunch of tickets that are [with patch, needs review]. It would be
cool to get some of
On May 6, 7.10pm, William Stein wrote:
Crap. Thanks for spotting this. Fortunately this is used in only
one place in Sage; this one line in congroup_gamma0.py:
return [GammaH(N, H) for H in R.multiplicative_subgroups()]
Yes, that was how I noticed this -- my fix for 5250 caused
William Stein wst...@gmail.com:
On Wed, May 6, 2009 at 11:33 AM, davidloeffler dave.loeff...@gmail.com
wrote:
On May 6, 7.10pm, William Stein wrote:
Crap. Thanks for spotting this. Fortunately this is used in only
one place in Sage; this one line in congroup_gamma0.py:
return
On Apr 16, 9:02 pm, Jaap Spies j.sp...@hccnet.nl wrote:
On Fedora 9, 32 bit, after an upgrade:
The following tests failed:
sage -t devel/sage/sage/modular/dirichlet.py
sage -t devel/sage/sage/misc/sagedoc.py
On 32bit SuSE Linux, upgrading from 3.4.1.rc2, I also get the
Never mind -- I remembered the existence of sage -t -verbose and
found the problem. (It was because I had a comment in my file
containing an unmatched opening triple quote -- this somehow throws
out the doctest script's parser.)
David
On Apr 10, 12:03 pm, daveloeffler dave.loeff...@gmail.com
On Apr 9, 9:45 am, William Stein wst...@gmail.com wrote:
I hope those of you who feel qualified to write doctests, will help
out. It's nearly impossible for one person to do all 1900 of those
doctests in the next month. Writing doctests is not easy and it
absolutely requires experience
On Mar 31, 2:19 pm, John Cremona john.crem...@gmail.com wrote:
It works fine for me with an absolute path!
John
Me too. Thanks for the workaround, Georg!
David
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To
On Mar 30, 8:24 pm, Christophe Oosterlynck tif...@gmail.com wrote:
Hi,
Consider matrices containing univariate polynomials over GF(2): is it
normal that calculating the smith normal form for such a matrix is
extremely slow?
I wrote the smith_form code, and it's completely generic, applying
I think I'm being credited with more than my fair share of reviewing
here:
#2551: Francis Clarke: __getitem__ for relative number field elements
is ... surprising [Reviewed by John Cremona, David Loeffler]
#5214: Francis Clarke: coercion to orders in relative number fields is
not implemented
I also came across the problem with quaternion_order_ideal.py, but for
me it went away when I re-built from a clean tarball (rather than
upgrading from 3.4.rc0 as I had done before). But even the final 3.4
tarball generates some Sphinx error messages when you do a docbuild,
from some slightly
There seem to be *hundreds* of files missing from the new reference
manual. I did a grep:
da...@groke:~/sage-3.4.rc0/devel/sage-main/sage grep EXAMPL.*[^:]:$
-lr *
to pick up files that contained EXAMPLES: with a single colon rather
than a double one, and it turned up no fewer than 510 files!
43 matches
Mail list logo
