> I'll email him, as I speak to him quasi-regularly by email. And I know > for a fact he has been working on other things. I personally worked on > them with him, and he discussed other projects he's done too. I don't > think I speculated in any of the three sentences here. But I will > explicitly ask him about the status of sympow.
Thank you. > >> >> > But, we should be more selective when including packages. >> >> No new packages ever again :-) > > Is that the official policy or were you joking. The smiley face was supposed to indicate that I was joking. > I actually don't know > what the current policy is, though I think I saw a not too old version > of it some time not too long ago, which significantly toughened the > restrictions for new packages. We've had a documented policy for a few years now about how to get new packages into Sage. I think it hasn't changed since we made it. It's basically: (1) vote -- with many criterion for what should be taken into account when voting, (2) package has to be optional for a while no matter what (3) maintainer for at least a while Python itself also has a policy for getting new packages into Python, which is much more stringent. >> >> > I'm also really wondering why cephes is in Sage. Unless there are two >> > packages with the same name, it was last updated circa 1994 and uses >> > non-portable long doubles. We've booted packages from Sage for much >> > less felonious offences. >> >> Cephes is in Sage because it's absolutely critical for the Windows port. > > You mean you used it in the Cygwin port? Yes. > Doesn't the inclusion of an old package like this with no maintainer > potentially cause more maintenance problems for people down the line. > Isn't this the lesson we are learning from sympow? Or am I missing > that it now has a more recent version maintained by someone and it no > longer uses long doubles. I would rather have a windows port than not having a Windows port. Problems may be created as a result. But since Cephes is only used on Windows, the problems will be less than the current problem which is that Sage doesn't work at all on Windows. > >> >> > Is there a modularity problem here? I always thought that given Sage >> > sees itself as more of a distribution (like linux) than a single >> > project, >> >> Sage is not more of a distribution than a single project. Sage is: >> >> > then all but a very small number of core libs should be able >> > to be added/removed from Sage at the flick of a switch. >> >> This is not even true of Linux distributions. Even the most minimal >> ubuntu install still has tons of packages... or at least a lot more >> then "a very small number". > > But I think packages in a linux distribution have prerequisites, and > if you install one, the prereqs get installed too (e.g. using apt- > get). I'm not seeing that happening with the sage spkgs. And I don't > know if that is possible or technically feasible. But I am asking the > question. There is a dependency system in place now for standard packages. It is defined by spkg/standard/deps > >> >> > It sure would've made a Windows port easier! >> >> Programs that aren't Sage are easier to port to Windows :-). >> You might try porting SPD to Windows instead, which would >> be easier.http://github.com/certik/spd > > The primary difficulty in porting Sage is in porting the C libraries > Sage relies on. Probably. Eliminating all the use of pexpect from Sage will also be a massive undertaking, which will likely be even more difficult than porting the C libraries Sage depends upon. It's probably at least possible though. > SPD probably just doesn't include them. You're right, SPD doesn't. >> > packages which are optional spkgs are considered truly.... optional. >> >> Correct. > > I take it this refers to the last sentence, meaning that a minimal > Sage will always be all of Sage standard. IMHO this makes it harder > for Sage to grow in certain ways.... That's correct. However, there could be a "Sage lite", which would be a lot smaller. There has been very little interest by people in the Sage community in actually working on this though. 99% of people who work on Sage, work on Sage because they actually want Sage to do something useful for their research or teaching. Working on a Sage lite does not contribute at all to this motivation. Outside the Sage community there is interest, and of course the result is SPD (and the like), which has little to do with Sage. >> > If so, I think the core is potentially unwieldy and >> >> It's not unwieldy, but it is difficult to wield. >> >> > may be >> > contributing to some of the maintenance issues..... >> >> Sage is definitely contributing to the maintenance issues of Sage. >> > > I mean the lack of modularity is contributing. But I've made this > point before and it all just got sent to sage-flame. So I won't > continue making it here. Back to what I was doing.... Sage is a lot more modular than Magma. William -- 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
