On Nov 28, 4:46 pm, "William Stein" <[EMAIL PROTECTED]> wrote:
> > > 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.
>
> Why are you skeptical? Even I was able to do this before in 2005,
> and I don't know anything about Windows.
My experience with even mixing C code and DDLs compiled with MSVC and
MinGW respectively has been less than stellar and I can point to
plenty of of odd crashes, inifinte loops at DLL import and so on.
Mixing that with C++ runtime code and potentially exceptions doesn't
exactly fill me with confidence. It might work some of the time, but
getting from it seems to work in this particular case to it works is a
very far way.
And one more remark: History has taught me that porting jobs,
especially the "easy" ones, always seem to end in death march like
situations. I have been down that road plenty of time, and I am not
afraid to go down that road again :) And getting there once is not the
problem, maintaining the port is just as much work, i.e. the Solaris
situation.
> Granted, it was pretty
> painful. But the bonus of integrating nicely with all existing Python
> libraries for Windows is nontrivial (just like it would be for Debian
> in the long run).
Sure, but MinGW is only a band-aid to get there. In the end it ought
to be MSVC, also for the 64 bit support. That is why I like the Cygwin
option with Salami tactic, we know it sucks, but at least we are much
closer to a more or less working version than MinGW and/or MSVC. The
good thing about MinGW is that we only have to deal with POSIX and
less so with build system and compiler issues at one time. Once we got
many issues sorted out with MinGW we still have to deal with build
system and Compiler issues. That is why I always guesstimated that it
would take at least one year of my time doing nothing else to get
there. Hopefully rpw or somebody else will get us some talented people
to help out.
I am thinking more and more that Sage on Windows will be mostly a
binary version where few people have the skill set to build and debug
and the vast majority will just install binaries. But taking into
account what most Windows people want that might be a decent fit.
> > > 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 :)
>
> Cool!
Well, that is certainly at least a couple weeks of work, but at some
point we have to bite the bullet.
Cheers,
Michael
>
>
>
> > > 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.
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
