sage-5.0
William Stein
What is the plan for releasing sage-5.0 right now? What's the
absolute bare minimum that could be done to do a release? We really,
really, really need to release sage-5.0...
-- William
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
leif
> What is the plan for releasing sage-5.0 right now? What's the
> absolute bare minimum that could be done to do a release? We really,
> really, really need to release sage-5.0...
http://trac.sagemath.org/sage_trac/ticket/12751#comment:13 ;-)
(#12751 is currently one of I think many blocker tickets, although I
wouldn't consider Sage 5.0 building with GCC 4.7.0 mandatory.)
I was actually thinking about (not me) releasing some 4.8.1 or 4.9,
until the "big one" is perfectly ready.
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
William Stein
> William Stein wrote:
>>
>> What is the plan for releasing sage-5.0 right now? What's the
>> absolute bare minimum that could be done to do a release? We really,
>> really, really need to release sage-5.0...
>
>
> http://trac.sagemath.org/sage_trac/ticket/12751#comment:13 ;-)
>
> (#12751 is currently one of I think many blocker tickets, although I
> wouldn't consider Sage 5.0 building with GCC 4.7.0 mandatory.)
Neither do I.
The blockers are:
- build on OS X 10.7 in some supported way.
- ???
William
>
> I was actually thinking about (not me) releasing some 4.8.1 or 4.9, until
> the "big one" is perfectly ready.
>
>
> -leif
>
> --
> () The ASCII Ribbon Campaign
> /\ Help Cure HTML E-Mail
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-release" group.
> To post to this group, send email to sage-r...@googlegroups.com.
> To unsubscribe from this group, send email to
> sage-release...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sage-release?hl=en.
leif
> On Wed, Apr 18, 2012 at 3:42 PM, leif<not.r...@online.de> wrote:
>> William Stein wrote:
>>>
>>> What is the plan for releasing sage-5.0 right now? What's the
>>> absolute bare minimum that could be done to do a release? We really,
>>> really, really need to release sage-5.0...
>>
>>
>> http://trac.sagemath.org/sage_trac/ticket/12751#comment:13 ;-)
>>
>> (#12751 is currently one of I think many blocker tickets, although I
>> wouldn't consider Sage 5.0 building with GCC 4.7.0 mandatory.)
>
> Neither do I.
>
> The blockers are:
> - build on OS X 10.7 in some supported way.
Maybe the GCC spkg included since beta13 solves that, although some
[Apple users, especially those *not* using Lion] might not be happy with
such a "solution".*
> - ???
Here are the current Sage 5.0 blocker and critical tickets grouped by
their state:
-leif
________________
* We could still offer the Fortran spkg with MacOS X binaries as an
optional package, i.e., as an alternative to building all of GCC on
older Apples.
William Stein
> William Stein wrote:
>>
>> On Wed, Apr 18, 2012 at 3:42 PM, leif<not.r...@online.de> wrote:
>>>
>>> William Stein wrote:
>>>>
>>>>
>>>> What is the plan for releasing sage-5.0 right now? What's the
>>>> absolute bare minimum that could be done to do a release? We really,
>>>> really, really need to release sage-5.0...
>>>
>>>
>>>
>>> http://trac.sagemath.org/sage_trac/ticket/12751#comment:13 ;-)
>>>
>>> (#12751 is currently one of I think many blocker tickets, although I
>>> wouldn't consider Sage 5.0 building with GCC 4.7.0 mandatory.)
>>
>>
>> Neither do I.
>>
>> The blockers are:
>> - build on OS X 10.7 in some supported way.
>
>
> Maybe the GCC spkg included since beta13 solves that, although some [Apple
> users, especially those *not* using Lion] might not be happy with such a
> "solution".*
The GCC spkg definitely is the solution.
I bought a new mac 2 days ago, installed the latest xcode, and beta13
does *not* build out of the box on it. First mpir fails. I fixed
that by swapping out the mpir from beta15 (?) -- whatever
mpir-2.4.0.p2.spkg is. Then ECM fails, and I fixed that by swapping
it for ecm-6.3.p6.spkg. The build then finishes and passes all tests.
>> - ???
>
>
> Here are the current Sage 5.0 blocker and critical tickets grouped by their
Forget about the critical ones. Here are the ones listed as blockers:
#11616 Upgrade MPIR -- just needs somebody to review it!
#12493 tol and optional in doctests don't play well together -- has
positive review
#12825 Fine-tune auto-detection of whether to install GCC -- has positive review
#11881 Metaticket: build Sage on OS X 10.7 Lion -- fixed if we
include new gmpecm
#12272 More # long time additions -- shouldn't be a blocker
#12751 Sage fails to build with GCC-4.7.0 -- shouldn't be a blocker
#12837 MPFR doesn't compile with GCC-4.7.0 on ia64 -- shouldn't be a blocker
#12849 The argspecs is broken in the Sphinx documentation -- fix in 5.1?
#12853 Severe slow-down in elliptic_curve integral_points() -- fix in 5.1?
#12854 Severe slow-down in plotting -- fix in 5.1?
If I were running the show, I would take pre13 + new mpir + new gmpecm
+ #12825 + #12493, make a release candidate, test it, and release.
Then make the GCC 4.7 stuff, etc. the top priorities for 5.1.
-- William
> state:
>
> http://trac.sagemath.org/sage_trac/query?priority=blocker&status=needs_info&status=needs_review&status=needs_work&status=new&status=positive_review&milestone=sage-5.0&or&status=needs_info&status=needs_review&status=needs_work&status=new&status=positive_review&priority=critical&milestone=sage-5.0&group=status&col=id&col=summary&col=priority&col=status&col=type&col=milestone&col=component&order=priority
>
>
> -leif
>
> ________________
> * We could still offer the Fortran spkg with MacOS X binaries as an optional
> package, i.e., as an alternative to building all of GCC on older Apples.
>
>
>>> I was actually thinking about (not me) releasing some 4.8.1 or 4.9, until
>>> the "big one" is perfectly ready.
>>>
>>>
>>> -leif
>
>
> --
> () The ASCII Ribbon Campaign
> /\ Help Cure HTML E-Mail
>
Volker Braun
Florent Hivert
> Forget about the critical ones. Here are the ones listed as blockers:
>
> [...]
I put it myself as a blocker, since it impairs a large part of Sage
HTML doc. I'm currently investigating on that on an might be able to
propose a solution very soon (maybe today or tomorrow), but with
Sphinx I never know.
Cheers,
Florent
Nicolas M. Thiery
> What is the plan for releasing sage-5.0 right now? What's the
> absolute bare minimum that could be done to do a release? We really,
> really, really need to release sage-5.0...
Yes, we would really appreciate if 5.0 was released before Sage Days
38 in Montreal (that is 2-3 days before May 7th). The code base is
getting so different that supporting the sage-combinat queue on both
4.8 and 5.0 is a pain, and I am uncomfortable telling every body at
the Sage Days to install a beta version.
Thanks in advance!
Cheers,
Nicolas
--
Nicolas M. Thi�ry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/
Jeroen Demeyer
> If it doesn't prevent build on a supported platform or yields
> the wrong result then it is not a blocker.
"blocker". For example, I think bugs *introduced* in a release are much
worse than *pre-existing* bugs.
Jeroen Demeyer
> If I were running the show, I would take pre13 + new mpir + new gmpecm
> + #12825 + #12493, make a release candidate, test it, and release.
John Cremona
I doubt that he is.
Can anyone give me a good reason why we should go to any trouble at
all helping people build Sage on a machine whose C compiler is "very
broken" (quoting from one patch at #12825)?
John
Jeroen Demeyer
> Can anyone give me a good reason why we should go to any trouble at
> all helping people build Sage on a machine whose C compiler is "very
> broken" (quoting from one patch at #12825)?
machines. For this, we need MPIR (#11616, needs_review) and MPFR (#12837).
Florent Hivert
> > Forget about the critical ones. Here are the ones listed as blockers:
> >
> > #12849 The argspecs is broken in the Sphinx documentation > > [...]
>
> I put it myself as a blocker, since it impairs a large part of Sage
> HTML doc. I'm currently investigating on that on an might be able to
> propose a solution very soon (maybe today or tomorrow), but with
> Sphinx I never know.
There is a 2 lines fix on trac which are needing review. I removed
accidently (at least I don't remember why) those two lines in #9128,
the patch just put them back. So if those two line are correct, I
think it would be very stupid not to have them into Sage 5.0.
Cheers,
Florent
Jeroen Demeyer
> blocker.
gsw
The blockers are:
- build on OS X 10.7 in some supported way.
- ???William
AFAIR, getting the doctest coverage up to 90% (or more) had been announced as mandatory for Sage 5.0.
I didn't look up any post(s) or ticket (I'm pretty sure there is one), so I don't know the current status, nor whether "90% doctest coverage" still should be considered a blocker for Sage 5.0.
Cheers,
Georg
Niles
On Thursday, April 19, 2012 8:23:13 AM UTC-4, gsw wrote:
I didn't look up any post(s) or ticket (I'm pretty sure there is one), so I don't know the current status, nor whether "90% doctest coverage" still should be considered a blocker for Sage 5.0.
Indeed, there is a "metaticket" at
http://trac.sagemath.org/sage_trac/ticket/12024
It is not marked as a blocker for 5.0.
leif
> On 2012-04-19 11:06, John Cremona wrote:
>> Can anyone give me a good reason why we should go to any trouble at
>> all helping people build Sage on a machine whose C compiler is "very
>> broken" (quoting from one patch at #12825)?
Well, not all users are able (or have the privileges) to install a
non-broken toolchain on the machines they [have to] use.
> At a minimum, we should ensure that Sage's GCC spkg builds on such
> machines. For this, we need MPIR (#11616, needs_review) and MPFR (#12837).
I have a fixed MPFR spkg (not just building on ia64) since a couple of
days; just haven't had the time yet to announce it on #12837 (and finish
the changelog IIRC), but meanwhile tested it on a couple of machines.
William Stein
> Jeroen Demeyer wrote:
>>
>> On 2012-04-19 11:06, John Cremona wrote:
>>>
>>> Can anyone give me a good reason why we should go to any trouble at
>>> all helping people build Sage on a machine whose C compiler is "very
>>> broken" (quoting from one patch at #12825)?
>
>
> Well, not all users are able (or have the privileges) to install a
> non-broken toolchain on the machines they [have to] use.
You could just as well wrote "not all users are able to install a
toolchain". We
have to draw the line somewhere.
>> At a minimum, we should ensure that Sage's GCC spkg builds on such
>> machines. For this, we need MPIR (#11616, needs_review) and MPFR
>> (#12837).
>
>
> I have a fixed MPFR spkg (not just building on ia64) since a couple of days;
> just haven't had the time yet to announce it on #12837 (and finish the
> changelog IIRC), but meanwhile tested it on a couple of machines.
>
>
>
> -leif
>
> --
> () The ASCII Ribbon Campaign
> /\ Help Cure HTML E-Mail
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-release" group.
> To post to this group, send email to sage-r...@googlegroups.com.
> To unsubscribe from this group, send email to
> sage-release...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/sage-release?hl=en.
>
--
leif
Now published; ready for review:
http://trac.sagemath.org/sage_trac/ticket/12837#comment:6
(It doesn't only work around building with GCC 4.7.x on ia64, but also
fixes a couple of other issues, and now applies all official upstream
patches.)
Note that a couple of other spkgs fixing GCC 4.7.0 and/or C++11 issues
(or CC / CFLAGS ignorance) also provide other fixes (or at least
clean-up), so at least some of them are IMHO worth being included into
Sage 5.0. A lot of them currently still need review; I'll probably post
a list here or to sage-devel later.
Further, we should IMHO try to include those spkgs fixing C++11 (GCC
4.7.0 / Clang) issues, which aren't related to GCC brokenness, but are
all listed on the meta-ticket #12751.
leif
> On Thu, Apr 19, 2012 at 6:12 AM, leif<not.r...@online.de> wrote:
>> Jeroen Demeyer wrote:
>>>
>>> On 2012-04-19 11:06, John Cremona wrote:
>>>>
>>>> Can anyone give me a good reason why we should go to any trouble at
>>>> all helping people build Sage on a machine whose C compiler is "very
>>>> broken" (quoting from one patch at #12825)?
>>
>>
>> Well, not all users are able (or have the privileges) to install a
>> non-broken toolchain on the machines they [have to] use.
>
> You could just as well wrote "not all users are able to install a
> toolchain". We
> have to draw the line somewhere.
I rather meant fixing broken packages by e.g. `sudo apt-get ...`.
(If some prerequisites like 'm4' are missing, we of course have similar
problems.)
(Users that /have/ the knowledge but lack system administrator
privileges could almost always install a toolchain into their home
directory, although that might be tedious, and probably takes up a lot
of disk space, i.e. might exceed their quota.)
[I'm not against shipping and building GCC etc. with Sage, but I think
there should also be a tarball without it; i.e., also the distribution
could be more modular, as opposed to offering only a single monolithic
thing that includes all that might probably be required on some systems.]
William Stein
> William Stein wrote:
>>
>> On Thu, Apr 19, 2012 at 6:12 AM, leif<not.r...@online.de> wrote:
>>>
>>> Jeroen Demeyer wrote:
>>>>
>>>>
>>>> On 2012-04-19 11:06, John Cremona wrote:
>>>>>
>>>>>
>>>>> Can anyone give me a good reason why we should go to any trouble at
>>>>> all helping people build Sage on a machine whose C compiler is "very
>>>>> broken" (quoting from one patch at #12825)?
>>>
>>>
>>>
>>> Well, not all users are able (or have the privileges) to install a
>>> non-broken toolchain on the machines they [have to] use.
>>
>>
>> You could just as well wrote "not all users are able to install a
>> toolchain". We
>> have to draw the line somewhere.
>
>
> I rather meant fixing broken packages by e.g. `sudo apt-get ...`.
>
> (If some prerequisites like 'm4' are missing, we of course have similar
> problems.)
>
> (Users that /have/ the knowledge but lack system administrator privileges
> could almost always install a toolchain into their home directory, although
> that might be tedious, and probably takes up a lot of disk space, i.e. might
> exceed their quota.)
>
>
> [I'm not against shipping and building GCC etc. with Sage, but I think there
> should also be a tarball without it; i.e., also the distribution could be
At present, I'm *not* for having two different sage-x.y.z.tar
tarballs. It greatly complicates things for the poor overworked
release manager, etc., while saving 4MB disk space (the difference
between the fortran spkg and the GCC spkg).
-- William
> more modular, as opposed to offering only a single monolithic thing that
> includes all that might probably be required on some systems.]
>
>
>
> -leif
>
> --
> () The ASCII Ribbon Campaign
> /\ Help Cure HTML E-Mail
>
Michael Orlitzky
>
> Here are the current Sage 5.0 blocker and critical tickets grouped by
> their state:
>
> http://trac.sagemath.org/sage_trac/query?priority=blocker&status=needs_info&status=needs_review&status=needs_work&status=new&status=positive_review&milestone=sage-5.0&or&status=needs_info&status=needs_review&status=needs_work&status=new&status=positive_review&priority=critical&milestone=sage-5.0&group=status&col=id&col=summary&col=priority&col=status&col=type&col=milestone&col=component&order=priority
>
I noticed this from a while ago,
http://trac.sagemath.org/sage_trac/ticket/5943
We can get two errors, either a PariError (if pari knows it can't
compute that many primes), or a MemoryError if it doesn't know but tries.
On x86, we simply can't ask for enough primes to cause the PariError.
With enough memory, it will actually compute sys.maxint primes, so we
can't count on a failure. However, if we ask it for 2^62 primes, we will
predictably fail on both x86 and x64, albeit in two different ways. This
is already doctested in,
http://trac.sagemath.org/sage_trac/ticket/11741
so if someone else agrees that the doctest in #11741 is sufficient, we
can close #5943. (I don't have access to my trac account right now, so
remove me as author, too, and add the author of #11741.)
leif
> On Thu, Apr 19, 2012 at 9:08 AM, leif<not.r...@online.de> wrote:
>> [I'm not against shipping and building GCC etc. with Sage, but I think there
>> should also be a tarball without it; i.e., also the distribution could be
>
> At present, I'm *not* for having two different sage-x.y.z.tar
> tarballs. It greatly complicates things for the poor overworked
> release manager, etc., while saving 4MB disk space (the difference
> between the fortran spkg and the GCC spkg).
Well, we have scripts automating such things, and most people won't need
the Fortran spkg (as well as others) either.
Not downloading the GCC (or Fortran) spkg currently alone saves 38441236
bytes (net); that's 12.5 percent (or, adding it means +14.3%).
-leif
>> more modular, as opposed to offering only a single monolithic thing that
>> includes all that might probably be required on some systems.]
--
David Kirkby
"The goal for Sage-5.0 is 90% coverage. And we should aim for 100% by
the end of the year. "
http://groups.google.com/group/sage-devel/msg/324e81239eedf293
Dave
William Stein
so, please take this to sage-flame.
It's far more important to make a release now and support users than
cut hairs over arbitrary goals.
I'm working on putting together binaries for a "beta" release right
now, because I'm sick and tired of people constantly asking me where
they can get a Sage that actually works on OS X 10.7, is even remotely
up to date, etc. I should be able post this release to the lists
with useful binaries for a few popular OS's and a tarball within 3
hours of now.
-- William
David Kirkby
> On Sat, Apr 28, 2012 at 8:00 PM, David Kirkby <david....@onetel.net> wrote:
>> On 19 April 2012 13:23, gsw <georg...@googlemail.com> wrote:
>>>
>>> AFAIR, getting the doctest coverage up to 90% (or more) had been announced
>>> as mandatory for Sage 5.0.
>>> I didn't look up any post(s) or ticket (I'm pretty sure there is one), so I
>>> don't know the current status, nor whether "90% doctest coverage" still
>>> should be considered a blocker for Sage 5.0.
>>>
>>>
>>> Cheers,
>>>
>>
>> This comment by William in June 2010 is interesting
>>
>> "The goal for Sage-5.0 is 90% coverage. And we should aim for 100% by
>> the end of the year. "
>>
>> http://groups.google.com/group/sage-devel/msg/324e81239eedf293
>>
>> Dave
>
> What's your point? Are you trying to flame me or start a fight? If
> so, please take this to sage-flame.
My point is that you don't ever seem to take a step back and look at
how things are progressing, and do something about them if they don't
progress. Sebastien Labbe has taken the trouble to actually plot a
graph of doctest coverage vs time
http://thales.math.uqam.ca/~labbes/blogue/2011/03/evolution-of-the-overall-doctest-coverage-of-sage/
His comment, on 6th March 2011 is:
==========
The coverage evolved quiet regularly during the last 20 releases (=20
months) with an average of a bit less than 5 percent a year. For
sage-4.6.2, it is actually 84.8%. If we keep this rhythm, we should
reach 90% coverage by March 2012 and 100% by April 2014.
==========
So if anything, progress in doctest coverage is slowing.
> It's far more important to make a release now and support users than
> cut hairs over arbitrary goals.
Sage is important (and I do), then a plan should be formulated to get
100% coverage. At the minute, it seems you have set arbitrary goals in
the past:
* 100% by the end of 2011
* 90% in Sage 5.0
but had no plan to achieve them. Not surprisingly, with no plan, the
first did not get achieved and the second looks unlikely to be
achieved.
The release date for the Solaris port was delayed many years longer
than you expected. The Cygwin port was delayed too, but has never been
reached. The time frame for those ports were admittidly more difficult
to get right. But formulating a plan to reach 100% doctest coverage,
and actually achieving that, should not be very difficult.
Dave