sage-5.0
William Stein
I'm setting the Sage-5.0 target date for August 31, 2010 (see
http://trac.sagemath.org/sage_trac/milestone/sage-5.0). The goals
are:
1. Windows port via Cygwin: http://trac.sagemath.org/sage_trac/wiki/CygwinPort
2. Upgrade PARI to svn: #9343
3. Upgrade MPIR to version 2.x: #8664
4. Raise the coverage score to 90%
5. (Done) Sparc Solaris 10
What follows is a brief discussion of the status of each of these.
1. Windows port via Cygwin: http://trac.sagemath.org/sage_trac/wiki/CygwinPort
There is still some work to do on this. See the 13 tickets I opened at
http://trac.sagemath.org/sage_trac/wiki/CygwinPort
So far, Mike Hansen has done an amazing job on this (I've helped some
too). We could really, really use help here, especially because
this work can go on independently of other things. This document
explains a lot about cygwin: http://cygwin.com/cygwin-ug-net/
2. Upgrade PARI to svn: #9343
Robert Bradshaw, John Cremona and I did a huge chunk of this two weeks
ago, and John also did a bunch more yesterday. What remains is just
resolving a few doctest failures, some of which might be subtle.
3. Upgrade MPIR to version 2.x: #8664
Nobody has done anything on this for two months. Anybody could work
on this. It's very easy -- just make an spkg, then test the sage
build and report issues. Pretty straightforward for almost anybody to
do.
4. Raise the coverage score to 90%
If you delete the devel/sage/sage/server directory, then Sage-4.5.rc0
has this coverage score:
Overall weighted coverage score: 84.6%
So we have barely even budged in a while. That said, I suspect there
are a lot of doctest patches that just need review or have positive
reviewed, but need to get merged into sage-4.5.rc0.
5. (Done) Sparc Solaris 10
This is done.
----
(Note: the above are the Sage-5.0 goals. This is not negotiable. If
you disagree with them, send email to sage-flame, not this list.)
-- William
David Kirkby
> Hi Sage Developers,
>
> I'm setting the Sage-5.0 target date for August 31, 2010 (see
> http://trac.sagemath.org/sage_trac/milestone/sage-5.0). The goals
> are:
>
> 1. Windows port via Cygwin: http://trac.sagemath.org/sage_trac/wiki/CygwinPort
> 2. Upgrade PARI to svn: #9343
> 3. Upgrade MPIR to version 2.x: #8664
> 4. Raise the coverage score to 90%
> 5. (Done) Sparc Solaris 10
Currently the SPARC is only 32-bit. If you are lucky, you might get
64-bit SPARC and/or OpenSolaris x64 by then. I rekon there is an 80%
chance of one or the other by then. Just as I write, I'm trying a
64-bit build on 't2' in
/rootpool2/local/kirkby/64/sage-4.5.rc0
73 packages have all built as 64-bit binaries and the build is still
going. I think the build will fail (singular, pynac, libfpll are
likely problems), but I suspect by the end of August a 64-bit build is
possible. I've solved all those on x64, though some of the solutions
are rather hackish.
With the exception of R and Maxima, Sage actually builds on
OpenSolaris x64, but it crashes at startup and I don't have much idea
how to debug that. (I created you an account on my quad core 3.33 GHz
Xeon if you want to try debugging it).
disk.math needs quite a bit of setting up, as too many tools are too
old, or configured in a way that wont work. It would take the best
part of a day to sort out disk.math for building Sage.
There's a good chance Maxima and R might build on 64-bit SPARC, and
the patches to pynac, singular and libfplll that work on OpenSolaris
x64, should work on 64-bit SPARC.
So you can probably be a bit more optimistic on the Solaris front, and
not just consider it done.
Dave
William Stein
> On 14 July 2010 00:49, William Stein <wst...@gmail.com> wrote:
>> Hi Sage Developers,
>>
>> I'm setting the Sage-5.0 target date for August 31, 2010 (see
>> http://trac.sagemath.org/sage_trac/milestone/sage-5.0). The goals
>> are:
>>
>> 1. Windows port via Cygwin: http://trac.sagemath.org/sage_trac/wiki/CygwinPort
>> 2. Upgrade PARI to svn: #9343
>> 3. Upgrade MPIR to version 2.x: #8664
>> 4. Raise the coverage score to 90%
>> 5. (Done) Sparc Solaris 10
>
> Currently the SPARC is only 32-bit. If you are lucky, you might get
> 64-bit SPARC and/or OpenSolaris x64 by then.
That would be amazing.
> I rekon there is an 80%
> chance of one or the other by then. Just as I write, I'm trying a
> 64-bit build on 't2' in
>
> /rootpool2/local/kirkby/64/sage-4.5.rc0
>
> 73 packages have all built as 64-bit binaries and the build is still
> going. I think the build will fail (singular, pynac, libfpll are
> likely problems), but I suspect by the end of August a 64-bit build is
> possible. I've solved all those on x64, though some of the solutions
> are rather hackish.
>
> With the exception of R and Maxima, Sage actually builds on
> OpenSolaris x64, but it crashes at startup
That's incredible.
> and I don't have much idea
> how to debug that. (I created you an account on my quad core 3.33 GHz
> Xeon if you want to try debugging it).
I do. Thanks for the reminder.
> disk.math needs quite a bit of setting up, as too many tools are too
> old, or configured in a way that wont work. It would take the best
> part of a day to sort out disk.math for building Sage.
I agree.
>
> There's a good chance Maxima and R might build on 64-bit SPARC, and
> the patches to pynac, singular and libfplll that work on OpenSolaris
> x64, should work on 64-bit SPARC.
>
> So you can probably be a bit more optimistic on the Solaris front, and
> not just consider it done.
Sweet.
>
> Dave
>
> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
Jonathan
sure it is not perfect, but I'm getting no feedback with it as an
optional .spkg. I'm pretty sure it works as well as what is in Sage
now, so although it needs input and work, I would like to argue for
including it, so that we can start getting feedback.
Jonathan
> I'm setting the Sage-5.0 target date for August 31, 2010 (seehttp://trac.sagemath.org/sage_trac/milestone/sage-5.0). The goals
William Stein
> I'd like to get wider distribution of the new interface for Jmol. I'm
> sure it is not perfect, but I'm getting no feedback with it as an
> optional .spkg. I'm pretty sure it works as well as what is in Sage
> now, so although it needs input and work,
What work does it need?
Jonathan
people other than myself, I'm sure it still needs work. I'm sure it
could be prettier. The issue is that I can't think of a way to test
it other than have people try it.
The only problem I am aware of is the issue I reported with Jmol not
working in FF on Macs when the worksheet is not published. That
appeared to be a notebook problem with keeping track of logins (I
assume cookies). I have no idea if that problem has been solved.
Jonathan
Volker Braun
(Fedora 13 x86_64):
http://trac.sagemath.org/sage_trac/ticket/9232
Volker
Jonathan
(http://trac.sagemath.org/sage_trac/ticket/9238). I think this broke
when the notebook was put inside an egg. I took that into account
with the new version of Jmol
Robert Bradshaw
> I'd like to get wider distribution of the new interface for Jmol. I'm
> sure it is not perfect, but I'm getting no feedback with it as an
> optional .spkg. I'm pretty sure it works as well as what is in Sage
> now, so although it needs input and work, I would like to argue for
> including it, so that we can start getting feedback.
If there aren't any regressions, I'd say lets try to get it in sooner
rather than later even if it's not totally polished yet. On that note,
do you have any good ideas on how we could test this (other than
manually?)
- Robert
Jonathan
mostly needs interactive testing. I also think that the major issues
are design, not whether it does what was intended (I fear my
intentions may be misinterpretations of what people wanted).
I'm not sure what you mean by regressions? This package updates to
the latest stable Jmol release and effects only two other files:
jmol_lib.js (completely rewritten) and notebook_lib.js (a couple of
additional calls to jmol_lib.js added to the version distributed with
SAGE 4.4.3). So I think everything is "latest and greatest".
I also know that this fixes Jmol from the command line, which has
stopped working since the notebook was moved inside of an .egg.
Jonathan
Try it at: http://www.uwosh.edu/faculty_staff/gutow/Jmol_for_SageNoteBook-1.1.spkg
On Jul 14, 9:22 pm, Robert Bradshaw <rober...@math.washington.edu>
wrote:
Robert Bradshaw
> Since all the changes are basically user interface changes, I think it
> mostly needs interactive testing. I also think that the major issues
> are design, not whether it does what was intended (I fear my
> intentions may be misinterpretations of what people wanted).
Ah, OK.
> I'm not sure what you mean by regressions?
Meaning everything that used to work still does. (And it sounds like
this is the case.)
> This package updates to
> the latest stable Jmol release and effects only two other files:
> jmol_lib.js (completely rewritten) and notebook_lib.js (a couple of
> additional calls to jmol_lib.js added to the version distributed with
> SAGE 4.4.3). So I think everything is "latest and greatest".
>
> I also know that this fixes Jmol from the command line, which has
> stopped working since the notebook was moved inside of an .egg.
>
> Jonathan
>
> Try it at: http://www.uwosh.edu/faculty_staff/gutow/Jmol_for_SageNoteBook-1.1.spkg
I'll give that a whirl.
- Robert