Sage 4.1.alpha0
Robert Miller
and co-chair the release with Tom. The source tarball and sage.math
binary are available:
http://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0.tar
http://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0-sage.math-only-x86_64-Linux.tar.gz
This is the first development release in which the new merge tools
were used by people other than the authors. Several doctests fail on
sage.math:
sage -t devel/sage-main/sage/graphs/graph.py # 25 doctests
failed
sage -t devel/sage-main/sage/databases/database.py # 20
doctests failed
sage -t devel/sage-main/sage/geometry/polyhedra.py # 1
doctests failed
These are all due to the removal of graph_isom.pyx, and I will be
posting a patch to fix this shortly, at #6394. I think that there was
no way to avoid these failures, since the only way to expose them was
to remove the code, rebuild entirely from scratch, and then run the
tests.
This release does not include any tickets involving spkg's. I will
make this the main focus of alpha1, which should drop before Friday.
Each of the following tickets were rejected by the merge scripts, but
unfortunately the failures are not available at this time (this is due
to human error on my part). If you are involved with one of them, you
are encouraged to try applying the patches to 4.1.alpha0 and see why/
if they failed. Tom and I will eventually do this, but it would be
helpful for people involved in the ticket to get things started:
6196
5481
6276
4712
5517
5991
6164
6200
5902
6269
Other easy ways to save release managers time, resulting in more
frequent releases and shorter wait times to get your code merged:
* Please include the trac number in each commit message if possible.
* Please make sure Author and Reviewer fields are set, when changing
the ticket status to "positive review." Since these are used in
generating release notes, please use full names.
* Please adhere to the "trac_####-description.patch" filename format
when creating patch files.
Cheers,
Robert Miller (and Tom Boothby)
John Cremona
>
6196 mpmath support
5481 devel/doc/output/* should be filtered from the list of files to doctest
6276 atlas-3.8.3.p2 dumps core on Solaris 10 with gcc 4.4.0
4712 Make the doctest timeouts in Sage easily adjustable
5517 cvxopt-0.9.p7: build failure due to missing perl modules
5991 Add a standard constructor for dynamic classes
6164 Phan's Mini-AES for educational purposes
6200 Use mpmath to compute constants
5902 Try SAGE_ROOT as base of argument to "sage -t"
6269 Coloring odds and ends
William Stein
Thanks. I've started builds going on the build farm and two OS X boxes...
William
kcrisman
> binary are available:
>
If you are involved with one of them, you
> are encouraged to try applying the patches to 4.1.alpha0 and see why/
> if they failed. Tom and I will eventually do this, but it would be
> helpful for people involved in the ticket to get things started:
Thanks,
- kcrisman
Jason Grout
>
> Other easy ways to save release managers time, resulting in more
> frequent releases and shorter wait times to get your code merged:
>
> * Please include the trac number in each commit message if possible.
Surely this could be scripted? Just prepend a "Trac #xxxx: " to the
commit message when the patch is merged? You could even do "Trac #xxxx,
patch x: "
William Stein
I still think it is a very good idea to include the trac number in
each commit message.
It makes it vastly easier on people when reading through the hg history later.
I personally *always* include the trac ticket in my commit messages.
Often I do "hg ci", then realize I haven't made a ticket for what I'm
doing, so I make one, get the number, then finish the commit. It's a
good idea to help make the development of Sage more collaborative (by
letting others know what you're really working on), and also make it
easier for people to trace through what happened.
-- William
Tom Boothby
> unfortunately the failures are not available at this time (this is due
> to human error on my part). If you are involved with one of them, you
> are encouraged to try applying the patches to 4.1.alpha0 and see why/
> if they failed. Tom and I will eventually do this, but it would be
> helpful for people involved in the ticket to get things started:
>
> 6196
> 5481
> 6276
> 4712
> 5517
> 5991
> 6164
> 6200
> 5902
> 6269
Don't look at these too carefully -- I know for a fact that at least a
couple of these failing is my fault. I'm going to re-test and post
detailed info to each ticket, starting in about an hour.
Thanks for all your help, Robert!
--tom
John Cremona
> This is the first release of the new cycle, and I've agreed to step in
> and co-chair the release with Tom. The source tarball and sage.math
> binary are available:
>
> http://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0.tar
> http://sage.math.washington.edu/home/rlmill/release/sage-4.1.alpha0-sage.math-only-x86_64-Linux.tar.gz
>
> This is the first development release in which the new merge tools
> were used by people other than the authors. Several doctests fail on
> sage.math:
>
> sage -t devel/sage-main/sage/graphs/graph.py # 25 doctests
> failed
> sage -t devel/sage-main/sage/databases/database.py # 20
> doctests failed
> sage -t devel/sage-main/sage/geometry/polyhedra.py # 1
> doctests failed
John
Tom Boothby
Robert's list of failures was too long -- I didn't actually apply most
of that list. The following actually failed:
6196
5991
6164
6200
6269
I'm generating reports on these right now and posting them to tickets
as they come.
Tom Boothby
> 6196
> 5991
> 6164
> 6200
> 6269
>
> I'm generating reports on these right now and posting them to tickets
> as they come.
>
Ah -- and 6269 almost certainly failed because I applied both patches
on the ticket, not because the second patch was actually bad.
Rob Beezer
> sage -t devel/sage-main/sage/graphs/graph.py # 25 doctests
> failed
> sage -t devel/sage-main/sage/databases/database.py # 20
> doctests failed
> sage -t devel/sage-main/sage/geometry/polyhedra.py # 1
> doctests failed
the three expected failing modules as in the announcement.
I also continue to consistently get the cryptic
sage -t devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py
# 0 doctests failed
The test passes just fine when run by itself. Is this just noise, and
is it just me? ;-)
Rob
Minh Nguyen
On Wed, Jun 24, 2009 at 10:04 PM, Robert Miller<rlmil...@gmail.com> wrote:
>
> This is the first release of the new cycle, and I've agreed to step in
> and co-chair the release with Tom. The source tarball and sage.math
> binary are available:
<SNIP>
Here are the tickets merged in Sage 4.1.alpha0:
#1871: Robert Miller: wiki -- pressing control-c just starts another
copy running [Reviewed by David Joyner]
#3084: Rob Beezer, Tom Boothby: Solve Sudoku faster! [Reviewed by Nick
Alexander]
#4196: John Palmieri: write a new coercion section for the
developer's/programmer's guide [Reviewed by Minh Van Nguyen]
#4290: Lloyd Kilford, John Cremona: function to construct an Elliptic
Curve from a plane curve of genus one (using Magma) [Reviewed by Nick
Alexander]
#4313: John Cremona: Add some functionality to matrices in eclib
[Reviewed by William Stein]
#4761: Martin Albrecht: global cputime (inclusive some subprocesses
like Singular) [Reviewed by Simon King, Nick Alexander]
#5080: David Loeffler: Bug in decomposing modular symbol subspace
[Reviewed by Craig Citro, Michael Abshoff]
#5280: Franco Saliola: problem with a subposet coming from an
order_filter [Reviewed by Mike Hansen, Robert Miller]
#5307: John Cremona: Bug in conductor() over number fields [Reviewed
by Nick Alexander]
#5594: John Palmieri: better error message for list_plot [Reviewed by
Nick Alexander]
#5637: John Palmieri: allow \[ and \] to delimit math in %html blocks
[Reviewed by Nick Alexander]
#5711: Golam Mortuza Hossain: Enhanced Typesetting of Symbolic
Functions [Reviewed by Burcin Erocal]
#5806: Dan Drake: Sage 3.4.1.rc3: failing test
"devel/sage/sage/misc/sagedoc.py" [Reviewed by John Palmieri]
#5850: Marc Mezzarobba, Dan Drake: add Creative Commons license to
French tutorial [Reviewed by Nicolas Borie]
#5878: Franco Saliola: Add support for constructing irreducible matrix
representations of the symmetric group [Reviewed by Mike Hansen]
#6027: Ryan Dingman: get_memory_usage() sucks performance wise on OSX
[Reviewed by Nick Alexander]
#6073: John Palmieri: Developer guide somewhat wrong about cython
extensions [Reviewed by David Joyner]
#6112: Dan Drake: Remove stale file sage/graphs/graph_isom.pyx
[Reviewed by Robert Miller]
#6215: Nicolas Thiery: Followup ot #6126: Symmetric group algebra
jucys_murphy elements incorrect [Reviewed by Robert Miller]
#6239: Minh Van Nguyen: fix ReST formatting for pydesign module
ext_rep [Reviewed by Carlo Hamalainen]
#6261: Yann Laigle-Chapuy: Add multiplicative order for matrices over
finite fields [Reviewed by John Cremona]
#6273: John Cremona: Improve random_element for number field orders
and ideals [Reviewed by Nick Alexander]
#6274: Minh Van Nguyen: fix formatting of files under sage/plot
[Reviewed by John Palmieri]
#6289: John Palmieri: minor ref manual issue with calculus stuff
[Reviewed by Minh Van Nguyen]
#6290: Golam Mortuza Hossain: Allow keywords such as latex_name=LaTeX
while defining symbolic function [Reviewed by Nick Alexander]
#6314: David Joyner: optional doctest failure -- many failures in
linear_codes related to wtdist [Reviewed by Robert Miller]
#6330: John Palmieri: optional doctest failure -- constructions number
fields doctest failures [Reviewed by David Joyner]
#6336: John Palmieri: optional doctest failure -- constructions
calculus tests hang forever [Reviewed by David Joyner]
#6349: Robert Miller: graphs -- bug in DiGraph constructor [Reviewed
by William Stein]
#6351: Robert Miller: typo in Graph.plot docstring [Reviewed by John Palmieri]
#6354: Nicolas Thiery: Advertise and improve sage -fixdoctest
[Reviewed by Mike Hansen]
#6361: Minh Van Nguyen: elliptic curves -- easy to fix mistake in docs
[Reviewed by Mike Hansen]
#6363: Mitesh Patel: Display Sage version on notebook login page
[Reviewed by John Cremona]
--
Regards
Minh Van Nguyen
Dr. David Kirkby
I'd like to know why 6276 failed. It seemed pretty simple, and should
have only had an effect on Solaris.
import shutil
if os.uname()[0] == 'SunOS':
shutil.copy2('patches/mmsearch-with-temp-Solaris-fix.c','src/tune/blas/gemm/mmsearch.c')
6380 has positive review too, but that does not appear to have been
listed as either failing, nor included.
Dave
Jason Grout
> On Wed, Jun 24, 2009 at 5:13 PM, Jason Grout<jason...@creativetrax.com> wrote:
>> Robert Miller wrote:
>>> Other easy ways to save release managers time, resulting in more
>>> frequent releases and shorter wait times to get your code merged:
>>>
>>> * Please include the trac number in each commit message if possible.
>> Surely this could be scripted? Just prepend a "Trac #xxxx: " to the
>> commit message when the patch is merged? You could even do "Trac #xxxx,
>> patch x: "
>>
>
> I still think it is a very good idea to include the trac number in
> each commit message.
> It makes it vastly easier on people when reading through the hg history later.
>
I totally agree. Is it possible to modify the commit message of a patch
when applying the patch to the Sage tree? That was my suggestion, so
that I don't have to worry so much about including the trac ticket
number. I'm constantly finding myself in your situation, where I've
created a patch, but then have to re-edit the message just to add the
ticket number.
Jason
Robert Bradshaw
> William Stein wrote:
If you're using queues, just use qrefresh -e. Personally, whenever I
realize I don't have a ticket number, I realize that's a hint I need
to go and create a ticket :).
- Robert
Tom Boothby
Robert was in error when he reported that those tickets failed. I
didn't apply anything to the scripts repo, or anything with a spkg.
Also, a number of tickets appeared in report 11 during the time
between me pulling down the patches and getting them applied / tested.
#6380 will go in for alpha2, which will be rc1 if Robert manages to
get Mike Hansen's Python 2.6 spkg in.
Jason Grout
I think I'm not communicating my point very clearly. I'm suggesting
that the release manager have in his patch application script an
automated "prepend 'Trac #xxxx: ' to the commit message" step. This
ensures that the ticket number mentioned in the commit message is the
right one, makes the logs very consistent and readable, and takes away
human error (and inconvenience).
Jason
Nick Alexander
> that the release manager have in his patch application script an
> automated "prepend 'Trac #xxxx: ' to the commit message" step.
I thought of implementing this but couldn't think of a way to discover
if there was a ticket number already there! (If you can do that, you
can just use it :) How do you prevent Trac #6346: fix trac #6346?
Nick
Jason Grout
I think it's fine to have two mentions of the ticket number. The first
is understood to be automated and corresponds to the actual ticket
number the patch was pulled from (so is guaranteed to be correct). In
fact, your example shows how commit messages might change: if you know
the trac number will go on automatically, then you might give a more
descriptive commit message :).
Jason
David Joyner
Should I post the full log somewhere? Here is the tail:
/Users/davidjoyner/sagefiles/sage-4.1.alpha0/local/include/python2.5 -c sage/misc/darwin_memory_usage.c -o build/temp.macosx-10.3-i386-2.5/sage/misc/darwin_memory_usage.o -w
sage/misc/darwin_memory_usage.c:7:32: error: mach/shared_region.h: No such file or directory
sage/misc/darwin_memory_usage.c: In function ‘shared_region_size’:
sage/misc/darwin_memory_usage.c:34: error: ‘SHARED_REGION_SIZE_PPC’ undeclared (first use in this function)
sage/misc/darwin_memory_usage.c:34: error: (Each undeclared identifier is reported only once
sage/misc/darwin_memory_usage.c:34: error: for each function it appears in.)
sage/misc/darwin_memory_usage.c:36: error: ‘SHARED_REGION_SIZE_PPC64’ undeclared (first use in this function)
sage/misc/darwin_memory_usage.c:38: error: ‘SHARED_REGION_SIZE_I386’ undeclared (first use in this function)
sage/misc/darwin_memory_usage.c:40: error: ‘SHARED_REGION_SIZE_X86_64’ undeclared (first use in this function)
sage/misc/darwin_memory_usage.c: In function ‘in_shared_region’:
sage/misc/darwin_memory_usage.c:48: error: ‘SHARED_REGION_BASE_PPC’ undeclared (first use in this function)
sage/misc/darwin_memory_usage.c:49: error: ‘SHARED_REGION_SIZE_PPC’ undeclared (first use in this function)
sage/misc/darwin_memory_usage.c:54: error: ‘SHARED_REGION_BASE_PPC64’ undeclared (first use in this function)
sage/misc/darwin_memory_usage.c:55: error: ‘SHARED_REGION_SIZE_PPC64’ undeclared (first use in this function)
sage/misc/darwin_memory_usage.c:60: error: ‘SHARED_REGION_BASE_I386’ undeclared (first use in this function)
sage/misc/darwin_memory_usage.c:61: error: ‘SHARED_REGION_SIZE_I386’ undeclared (first use in this function)
sage/misc/darwin_memory_usage.c:66: error: ‘SHARED_REGION_BASE_X86_64’ undeclared (first use in this function)
sage/misc/darwin_memory_usage.c:67: error: ‘SHARED_REGION_SIZE_X86_64’ undeclared (first use in this function)
error: command 'gcc' failed with exit status 1
sage: There was an error installing modified sage library code.
kcrisman
>
> Is there an -upgrade location to go to?
understandable. Just asking!
- kcrisman
Nick Alexander
On 25-Jun-09, at 5:10 AM, David Joyner wrote:
> Build failed for intel macbook 10.4.11
>
> Should I post the full log somewhere? Here is the tail:
>
>
> /Users/davidjoyner/sagefiles/sage-4.1.alpha0/local/include/python2.5
> -c sage/misc/darwin_memory_usage.c -o build/temp.macosx-10.3-
> i386-2.5/sage/misc/darwin_memory_usage.o -w
> sage/misc/darwin_memory_usage.c:7:32: error: mach/shared_region.h:
> No such file or directory
I merged this patch and forgot how volatile Mach headers and the like
are. Could you use locate or spotlight to find shared_region.h on
your machine and tell me where it is? Also, can you give info about
your development chain, such as the version of XCode, gcc, etc.
Nick
gsw
It's clearly is the reason for this brokenness, and wasn't tested on
Mac OS X 10.4 at all. As it is stated in its comments.
Cheers,
gsw
Robert Miller
shortly.
Robert Miller
>
> It's clearly is the reason for this brokenness, and wasn't tested on
> Mac OS X 10.4 at all. As it is stated in its comments.
momentarily.
rlm
David Joyner
> your development chain, such as the version of XCode, gcc, etc.
Looks like I have XDarwin 1.4a1. Does that help?
>
> Nick
>
> >
>
Ryan Dingman
would have ported this code to those versions when I originally wrote
the code for this patch. If anyone has a machine available with OSX
10.4 or 10.3 I'd be happy to port this code to it.
William Stein
I posted a patch that changes the code so that it isn't used on OS X
<= 10.4. That's in sage-4.1.alpha1.tar already...
William
gsw
> I posted a patch that changes the code so that it isn't used on OS X
> <= 10.4. That's in sage-4.1.alpha1.tar already...
>
> William
Ryan,
I've got both a MacPPC and a MacIntel running with OS X 10.4.11, so I
think together we could make this work on OS X 10.4, too (OS X 10.3 is
not supported at all by Sage AFAIK). I'm using Xcode 2.5, the output
of gcc --version is:
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
5370)
...
resp.
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.
build 5370)
...
I'm currently downloading Sage-4.1.alpha1.tar.
Cheers,
gsw