On Jan 21, 2010, at 8:37 AM, Dr. David Kirkby wrote:
It looks like the exact same version of FLINT, which did work in Sage
4.3, no longer works in 4.3.1. I can't imagine what the problem is.
(Guess: too much fiddling with the Sage build system.)
There's also no patch to fix the issue attached to the trac ticket.
If you mean the ticket I created, then I have no patch.
I wouldn't expect Sage to not release because of some problem with an
upstream package on an architecture that relatively few developers
actually use - especially as the next version of Sage is already
being
worked on and will come to the rescue any day.
Well Sun have supplied free SPARC hardware, and only a week or two
were asking about when they could point people at it. So there does
seem to be a good argument for not breaking the Solaris SPARC build.
Having worked quite hard on the SPARC build, I was less than keen to
see it broken.
Yes, that is disappointing. I spent a fair amount of time trying to
resolve the first Solaris stopper that came up, but who knows how long
until the above issue is resolved, and given that there's so much
stuff that'll be a huge step forward for nearly all users in this
latest release, I don't think it made sense to wait on this. The huge,
long release cycles tend to be the worst culprits for breaking things.
I have thought for some time that the frequency of public releases
is too fast
to allow proper testing. (By public, I mean x.y.z releases, not
alpha or release
candidate releases).
That is clearly true. But it doesn't necessarily imply Sage should
release less frequently. Look at the current MPIR release. It's six
months overdue just because we did not release regularly and caused
all sorts of problems for ourselves with a massive release. It'll
probably still have bugs when we do release. All software has bugs,
except tex, which once had a bug, but it got fixed.
Most big software builds have at least two branches, where something
pretty stable is always available, and developers use more cutting
edge stuff. If you look at gcc for example, the latest release is
4.4.2, but there is also a 4.4.2 branch, were some fixes are
applied, and I expect they will appear in 4.4.3 when fully tested.
Then there is also a gcc 4.5 branch.
This has been discussed before. I don't think we're "big" enough to
support two branches--it's hard enough for people to find the time to
manage one set of releases.
William has said of the 4.3.1 release "There were billions of
tickets closed and
bugs fixed"
http://groups.google.com/group/sage-devel/browse_thread/thread/d0468f
...
Within less than 5 hours of 4.3.1 being released, there are people
saying it
does not build on Ubuntu,
I found only one person (on sage-support) who reported an issue on
Ubuntu. But he seems to say that Sage did build successfully (he did
run into problems on startup though) and this seems to be with 4.3.
There's a couple of people on sage-devel having this problem.
People who built without the now prerequisite Fortran compiler
experienced issues. This looks like a simple apt-get install in
ubuntu
(sudu apt-get install gfortran), though one needs admin rights on the
system to install this, no?
I'm not a user of Ubunta, but you are probably right users needing
root access.
I assume someone could download the gcc sources, and build Fortran
themselves.
Anyhow, with the prereq installed, sage builds.
which is an officially supported platform, on which
Sage has for a long time built ok. I'd raised the issue that the
earlier release
candidate did not build on SPARC, despite older versions building.
Would it not be more sensible to test that a release actually
builds properly on
supported platforms before making it public? In other words,
introduce a much
longer delay between the expected final release, and that
something actually
being released. Its obviously an impossible task for the release
managers to do
this themselves, but other developers can test versions if they
are given time.
There were some issues this time around due to build farms being
down.
Fair enough. But unless tested, would it not be more sensible to
wait until it is tested a bit more?
Perhaps we should have waited a bit longer, but as for the above
example, it would not have made a difference, as the solution was "you
need to install fortran" rather than changing Sage.
I do agree with the general sentiment--the time between release
candidate and final release is often too quick for someone not
constantly online to download and test it. No reason we can't start
the next release cycle while an rc is sitting for a day or two.
To me it is a miracle that so many millions of lines of code builds
on
any system at all. I find it extremely hard to just get MPIR to build
on all the supported platforms, and people keep throwing new ones at
me. Many of these I have no access to, e.g. AIX, HP-UX, hppa,
alpha, ....
+1 It's a Herculean effort.
Perhaps I am unique, but I tend to lose confidence in code where it
either
* has lots of warnings
* It's clear the developers try to hide warning messages, rather
than fix the underlying problem.
This is probably because of the level that you look at code. Unlike
most people whose goal is to use Sage, your goal is to build it. Most
people never even look at the build logs unless it fails to build, and
even then just to post it to the list.
I loose confidence in code that (among other things) lacks
documentation and uses lots of magic constants--something a compiler
would never pick up.
Also, as Dag Sverre mentioned, most of the warnings in the Sage
library themselves are due to Cython (there is very little hand-coded
C). It is certainly our goal to produce warning-free code [1], but
none of the warnings that I'm aware of are indictions of actual
erroneous code (mostly its unused variables that aren't suppressed),
and so they're lower priority than other bugs/missing features.
- Robert
[1] http://trac.cython.org/cython_trac/search?q=warnings
--
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
