On 3 Nov, 14:46, William Stein <wst...@gmail.com> wrote: > 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,
Wait, what!??? ...why on earth would anyone think that!!? Have I ever held some kind of executive capacity in the project? No!! Anything I suggest is nothing more than that, a suggestion, and an opinion. > I am absolutely against ever removing PARI from Sage. I hope no one was confused about this. I wrote: "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? " I don't think there is any suggestion there that we should remove Pari from Sage. That would be impractical. I've added emphasis to the important points I was making. > (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, I think I said the main Sage release should pass doctests on widely used platforms. I'm talking about having separate groups manage separate Sage releases on other less widely used platforms. If we add Windows to the list of supported platforms eventually, will that get added to the list of platforms that will need to be tested on and fixed every other week when there is a new Sage release? Did anyone do this with the Cygwin port to check for regressions/new doctest failures before 4.6 came out? At what point will the list of supported platforms just become too large to be managing simultaneous releases on all platforms simultaneously every other week? I'm trying to think through some of the standard ways that large projects manage the complexity of software releases to see if there is a way to streamline things. By that I mean non-blocking threads. Another oft suggested strategy is to have a sage-stable and sage- devel. In some ways, purple-sage looks like it might become some people's sage-devel, I don't know. > 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. For a vast number of projects, ports to platforms that are not in the general category of "widely used linux distros" are managed separately. It's not a GCC thing, but certainly a prevalent thing. > > * 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. The biggest problem I see here is each doctest only seems to do a single iteration of the function in question. I am sure there are exceptions to this. But I don't see how you hope to catch corner cases by testing fewer times than I have fingers and toes. Still, one line in four, if accurate, doesn't sound like a bad ratio. Writing test code in Python is easier than in some other languages, so I don't know what is a good ratio for python code. > > * Bill remarks that "modularity" is helpful, and we should use a > language that supports it (we do!), Quite obviously it does. So my point was obviously not about the language! > 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. I agree with this. I think the purplesage concept actually addresses some of the major issues. > 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. There is almost infinitely more work in a native Windows port than a Solaris port. Solaris is similar enough to other unixes to make a port doable by one person. I think it is completely unfair to say Blair failed because David was more persistent. Blair failed because it is a much, much harder job, and he got tired. One person will never finish the job on Windows. It needs a team of skilled individuals. But a smaller bite-sized useful chunk of Sage at a time is far more likely to be ported than the whole thing at once. > > * 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). I don't recall suggesting the "core of Sage" should be broken into 20 pieces. That would be totally pointless. Or are you suggesting that everything that is currently in that 300mb tarball should be considered "core Sage". I think that is a completely and utterly unsustainable model. The core should be *much* smaller. Then communities should be building on top of that smaller core with packages relevant to their area. That's what I mean by modularisation. I cannot think of a single other project out there that has a single monolithic 300mb source tarball released every other week. Anyhow, I don't think we disagree on the general principle that modularity is a good thing. Bill. -- 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
