[Ooops, I didn't realize that this was CCed to sage-devel, so here is my reply, slightly edited for public consumption]
William Stein wrote: > Michael, William > > I want to somehow start a very tentative *actual* step toward doing a > native windows port. I installed > Windows into vmware on my laptop yesterday. I think the first thing > we need to do is decide whether > we're going to: > (1) build our own Python using mingw, > or (2) use the standard Visual C++ built Python that is distributed at > python.org. > I still think I can ressurect option (3) Cygwin temporarily and get it working with libSingular. I found a rebase script by Gary Zablackis, so I think I can get the other issue I had under control - I gave up on those after libSingular. > The advantage to (1) is .... I can't think of any, except maybe "control" > but my impression when we last talked was > that you thought (1) was the way to go. > > The advantage to (2) is that whatever we do it will play very nicely with > all existing Python libraries that get distributed for windows. In > particular, > graphics libraries, Enthought's Scipy for windows, etc., will all just work. > If we go the (2) route, we can just immediately check scipy/numpy off > the list, and any other python library that has been ported to native windows > already. > > If we do (2), step 1 will be to figure out the modern way to build > Python extensions > against that standard Visual C++ built Python, either using mingw or Visual > C++. > I did this 3 years ago using mingw, and it was possible but painful. Things > may have changed. > I started looking into that and provided we have the libstc++ runtime for MinGW it could work. I am still skeptical, but I am willing to be proven wrong. > Once we decide on (1) versus (2), the next step is to somehow get > pexpect or some > pexpect replacement (with equivalent functionality) to work in the > context of Windows. I was thinking of hacking pexpect to use CreateProcess() and some other Windows APIs - the qprocess implementation in Qt does the same thing and could be used as guidance. We only have to get enough of pexpect working to make Sage run :) > Once that is done, we can port the Sage notebook and all interfaces to > Windows -- they're > pure python and depend only on Twisted, so this shouldn't be > impossible. We should > also port the pure python matplotlib-based plotting code, which should be > easy. Agreed. > Next we port the calculus Python functionality, which is again pure python. > Given a maxima binary, we'll then have Sage's calculus functionality > and plotting > fully ported. This will on its own be a very useful program for a lot > of people. Agreed. > > After that we can start thinking about the much harder parts of the > SAge library that > involve Cython, external C/C++ libraries, [lib]Singular, etc., etc. Salami tactic, combined with Cygwin should let us do that. > By far the main difficult and thing that scares me above is pexpect. > Even in Cygwin, > pexpect sucked... > Agreed. Do you got the statistics script for downloads of Sage? I checked my Sage mirror logs and it looks like I had about 100 binary downloads from 11/01-11/26 this month from sage.apcocoa.org alone. Cheers, Michael --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
