On Wed, Nov 3, 2010 at 5:30 AM, Bill Hart <goodwillh...@googlemail.com> wrote:
> Finally, testing each individual spkg (against its dependencies) on
> all supported platforms *before* having to download and build the
> whole of the latest Sage seems to me to be a logical first step. I'm
> not seeing even that happen at the moment. This again is a kind of
> modularity. If the new Pari doesn't even build on the Solaris, what is
> the point of spending a whole day building and testing the whole of
> Sage on Solaris? And if Pari doesn't even have a comprehensive test
> suite and a new stable release I'm not getting why we are even using
> it the way we are. We surely need to be much more sceptical about it
> and test the hell out of it before trying to put it into Sage. OK it's
> in now, but is it really worth doing it that way again in the future?
Just for the record, for people reading this who might think Bill
speaks for the whole project,
I am absolutely against ever removing PARI from Sage. (This is an
important distinction
to make, since I *do* often get offlist questions from people whenever
some random person posts
opinions like the above on Sage devel.)
I guess my summary of the above other suggestions by Bill are:
* Bill says we should go ahead and release Sage anyways even if we
know it is "broken" on some widely used platforms, where broken means
"some doctests fail", and people using those platforms can use an
older or different version of Sage. He says this is fine to do,
since that's what everybody else does. I disagree with this, and
think GCC is not everybody.
* Bill remarks his test suite for some project has about one line
devoted to testing for every line of actual code, and Sage should too.
I looked, and Sage probably has about 3 lines of code for every line
of testing, since there are 134,329 lines of input doctests, and
probably around 300,000-400,000 lines of actual code in the sage
library.
* Bill remarks that "modularity" is helpful, and we should use a
language that supports it (we do!), and that it would make a windows
port much easier. I think that as a community we should also support
modularity -- I'm working on making that even easier for developers --
http://code.google.com/p/purplesage/ is a prototype, and I'll be
writing more about how other groups can do something similar. I think
a smallish library version of Sage would in fact be easier to port ot
Windows. That said, the biggest obstruction to Sage on Windows has
always been lack of focused work on the port by people who knew what
they're doing. Sage only got ported to Solaris because David Kirkby
put in an _enormous_ amount of effort making that happen. Something
similar is needed for windows. Blair Sutton started in that
direction, but ran out of steam after about 4 months; David Kirkby was
much, much more longterm persistent.
* Bill suggests that the development of the core of Sage should be
broken up into 20 or so special groups, etc. I disagree with this;
personally I think specialized groups in different research areas
should instead develop packages *on top* of Sage, while *everybody*
contributes to making the core of Sage much more bugfree and stable
than it already is. But this shouldn't happen until we iron out the
bugs about how to best develop packages on top of Sage see remarks
above).
-- William
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
--
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
