On Tue, Feb 1, 2011 at 6:21 AM, Dr. David Kirkby <david.kir...@onetel.net> wrote: > On 02/ 1/11 08:50 AM, David Roe wrote: > >> I think most people agree that a Windows port is important. > > But there's no plan for Sage, which sets out priorities and reasonable > estimates of time. > >> But it still >> hasn't happened. My impression is that the reasons for that are primarily >> that it's >> 1) hard, >> 2) not interesting to most Sage developers. >> >> There's not much that we can do about the difficulty; if we want it to >> happen we need to address the second point. Sage isn't a project where we >> can really tell people that they have to work on something. Personally, >> I'm completely uninterested in working on a Windows port. > > I don't know how hard it is, but I got the impression from William only a > few months back that it did not need a lot of work. But I've come very > suspicious about time estimates from many Sage developers. > > One ticket I was aware was outstanding was that SYMPOW was not working. That > got fixed when I realised it was an issue on Solaris, so I sorted it out. > >> We've tried hiring someone to work on porting Sage to Windows, and it >> wasn't >> that successful. > > My understanding was that Microsoft sponsored a student for a short period > of time (2-3 months). It was blatantly obvious to me that it would have not > been done in that time scale. I think that was supposed to be a native port > too - not Cygwin. A native port is a *much* harder problem. > > To my knowledge, there was nobody else paid to work on a Windows port, but I > may be wrong. > > I know Micheal was paid to work on the *Solaris* port, but went off on a > tangent and did his own thing. To my knowledge, Micheal was the only full > time person paid to work on Sage. > > But if there was a plan for Sage, like there is for other projects, with > estimated dates for specific targets, and those kept slipping, then we would > be aware there's a problem. > > Regularly slipping time scales should then be fed back to the people making > the estimates. They would hopefully realise they were unrealistic in their > expectations. > > Once that is realised, more realistic time scales would be set for future > Sage goals. Then priorities could be set, based on knowledge of what are > realistic time scales. > > All this is pretty much standard software engineering principles. > >> Just waiting until people decide to work on it isn't >> achieving anything. One way we've traditionally had success in gathering >> momentum for a project is hosting a Sage Days workshop. One focused on >> Windows development might achieve something, if we can find the funding >> for >> it. > > Some of the problems seem to be firmly in the hands of people who have > written code in the Sage library, which simply does not work properly on > Cygwin. They should be able to sort that out. > > Some of the portability issues are not trivial IMHO, but just need hard > work. I agree it's not the most interesting thing. I also think the time > estimates I've seen are totally unrealistic. > > What is obvious to me is how close the correlation is between Cygwin issues > and code I'd previously identified as being very badly written. > > I can't help feeling William was unwise to start Psage before the Cygwin > port of Sage was complete. > >> The only other thing I can think of would be to hire someone, IF we can >> find >> someone with the necessary qualifications and determination. I don't know >> how feasible that is, or whether funding for that project would be >> available. I have to think that the people who might have funded it may >> be >> discouraged by previous failures. > > I personally would not let previous failures put me off. Micheal spent a > couple of years working on a Solaris port, but his failure did not put me > off. I knew it could be done. > >> Even though I don't want to work on it, I'll be a cheerleader for those of >> you who do. :-) >> David > > Sage is something people work on in their spare time, so you can't dictate > to people what they do. But if there was a plan, people could be encouraged > to work on what is considered important. Student projects could be based > around specific goals. > > We should also have status reports. See for example some of the archived > FreeBSD status reports. > > http://www.freebsd.org/news/status/report-2009-04-2009-09.html > http://www.freebsd.org/news/status/report-2008-10-2008-12.html > http://www.freebsd.org/news/status/report-2008-07-2008-09.html > > To me at least, it seems the vast majority of people ware working on what > interests them,
Yes, exactly, though I would like to point out that while few things are of interest to the entire Sage community, most code that goes in is of interest to large groups of people. > and those changes get put into Sage, without any discussion > of what's actually needed in Sage, and what should be written as an external > program. I think part of this is due to the historical context in which Sage arose. Pre-Sage, the open source mathematical landscape consisted of a few large pieces (e.g. Pari, Gap, Maxima) and dozens of specialized libraries (gfan, ntl, ...) most of which were hard to build, needed manually managed dependencies, and didn't interoperate with each other. The Sage community is often accused of being full of more mathematicians than programmers, and though to some people manually configuring, compiling, and installing various interdependent libraries is all in a days work this is not what mathematicians enjoy spending their time doing (if they even have the background at all). Along comes Sage with it's kitchen sink strategy (and a huge amount of hard work to get all these systems to build out of the box) and it's hailed as "the easiest way to get X" for many X which were before only available separately. Since then it's grown as we now have many of these these programs working together, hundreds of thousands of lines of new code, and a (subjectively) nice Python and notebook interface. PSage is an interesting move. It's swinging the pendulum the other way a bit, but it's not just a technical issue, but the recognition that there's value in both a core stable base and shared fast-moving research code. > * No documented plan > * No real documented estimates of time scales > * No status reports for the project as a whole. Anyone could come up with a plan, but who would enforce it? Who would allocate the resources to make it happen? Most large OSS projects have full-time staff as well as many non-paid contributors--we don't. While it's good to have common goals (and these sometimes get decided, e.g., at Sage days) the best we can really do is have everyone document (to the best of their ability) their own plan and estimated time scales, often in collaboration with others. Also, while something like porting would be a Sage-wide plan, the majority of the work, and hence plan, would simply be a breakdown into the subfields and sub-subfields, each with their own goals and timelines, rather than be a cohesive whole. That being said, I would love a plan/status report that's a higher level than trac. An aggregated blog? A wiki? A quarterly newsletter (which would motivate people to write up anything of note they did/were aware of)? For a while we had Sage release tours, which were really cool, though even something higher-level than that would be great. In terms of the statement "a viable free open source alternative to M*," I interpret it as applying individually--for your research, teaching, enjoyment what is Sage missing? Each will have their own answer. One thing that's missing is that just equalling the M* is not enough, often at the cutting edge there is *no* code to do what you want, in which case someone needs to write it (and push Sage to be a viable platform on which to do so). - Robert -- 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
