Differences between revisions 16 and 17
⇤ ← Revision 16 as of 2010-08-12 23:44:08 →
Size: 14965
Editor: BillHart
Comment:
← Revision 17 as of 2010-08-12 23:58:27 → ⇥
Size: 15231
Editor: BillHart
Comment:
Deletions are marked like this. Additions are marked like this.
Line 57: Line 57:
 || ntl || 5.4.1.p11 || works fine with MSVC. Some functions like the time functions use old and crappy Win95+ interfaces. That can be easily fixed. It is very difficult to get fixes merged upstream, but the potential diff is rather small. The build requires Perl for a tuned build [[upstream merging probably isn't as hard as you think. The NTL author is a number theorist that many of "us", e.g,. John Cremona, know well.]] ||
 || opencdk || 0.6.6 || ||
 || palp || 1.1.p1 || unclear how hard the port will be, but shouldn't be too hard. ||
 || pari || 2.3.3 || Some build support exists in tree, but it is currently broken. Support from the maintainers exists and they are willing to integrate fixes upstream. The main issue is to get the build system play nice for MinGW+MSVC. ||
 || pexpect || 2.0.p1 || This is the big, difficult one. pexpect uses pseudo ttys and a whole bunch of POSIX infrastructure. It is essential and central to Sage and no one has ported pexpect to Windows. While the API is very different it is still possible to map all functionality to native Windows API calls. But it will probably take a lot of energy to get it stable and clean. The ultimate goal would be to get this merged upstream since it would be quite a lot of work to go at this alone [[yes, this is the biggie. note that pexpect does sort of work under cygwin, which might be relevant. Also, instead of porting pexpect, it might be possible to simply do something completely different than accomplishes much the same thing. pexpect was the way to go with Python and Unix -- in windows perhaps there is a totally different approach to interprocess communication that would work better? It's possibly OK if this means rewriting SAGE_ROOT/devel/sage/sage/interfaces/ for this new approach.   This definitely needs to be investigated. Some of the programs Sage interfaces with have native "client server" archicture, and that could perhaps be used instead. E.g., Maple and Mathematica do. Maxima almost certainly doesn't...]] ||
 || polybori || 0.1-r7 || no Windows port, could be tricky, but upstream is willing to cooperate. [[worry??]] ||		  || [[http://www.warwick.ac.uk/staff/J.E.Cremona/mwrank/index.html | mwrank]] || XXXX || ||
 || [[http://www.shoup.net/ntl/ | ntl]] || 5.4.1.p11 || works fine with MSVC. Some functions like the time functions use old and crappy Win95+ interfaces. That can be easily fixed. It is very difficult to get fixes merged upstream, but the potential diff is rather small. The build requires Perl for a tuned build [[upstream merging probably isn't as hard as you think. The NTL author is a number theorist that many of "us", e.g,. John Cremona, know well.]] ||
 || [[http://www.gnu.org/software/gnutls/ | opencdk]] || 0.6.6 || ||
 || [[http://www.openopt.org/Welcome | openopt]] || XXXX || ||
 || [[http://www.math.ucf.edu/~reid/Rubik/optimal_solver.html | optimalrubik]] || XXXX || ||
 || [[http://hep.itp.tuwien.ac.at/~kreuzer/CY/CYpalp.html | palp]] || 1.1.p1 || unclear how hard the port will be, but shouldn't be too hard. ||
 || [[http://pari.math.u-bordeaux.fr/ | pari]] || 2.3.3 || Some build support exists in tree, but it is currently broken. Support from the maintainers exists and they are willing to integrate fixes upstream. The main issue is to get the build system play nice for MinGW+MSVC. ||
 || [[http://www.noah.org/wiki/Pexpect | pexpect]] || 2.0.p1 || Difficult. pexpect uses pseudo ttys and a whole bunch of POSIX infrastructure. It is essential and central to Sage and no one has ported pexpect to Windows. While the API is very different it is still possible to map all functionality to native Windows API calls. Instead of porting pexpect, it might be possible to do something different that accomplishes the same thing. pexpect was the way to go with Python and Unix. It's possibly OK if this means rewriting SAGE_ROOT/devel/sage/sage/interfaces/ for this new approach. Some of the programs Sage interfaces with have native "client server" archicture, and that could perhaps be used instead. E.g., Maple and Mathematica do. Maxima almost certainly doesn't... ||
 || [[http://www.pythonware.com/library/index.htm | pil]] || XXXX || ||
 || [[http://polybori.sourceforge.net/ | polybori]] || 0.1-r7 || no Windows port, could be tricky, but upstream is willing to cooperate. [[worry??]] ||
Line 64: Line 68:
 || pycrypto || 2.0.1.p1 || unclear how hard the port will be, but shouldn't be too hard. [[maybe trivial??]] ||
 || python || 2.5.1.p13 || excellent support for MSVC, 32 & 64 bit mode. [[yep, very very good support on windows]] ||		  || [[http://www.amk.ca/python/code/crypto | pycrypto]] || 2.0.1.p1 || unclear how hard the port will be, but shouldn't be too hard. [[maybe trivial??]] ||
 || [[http://www.python.org/ | python]] || 2.5.1.p13 || excellent support for MSVC, 32 & 64 bit mode. [[yep, very very good support on windows]] ||
Line 67: Line 71:
 || [[http://pynac.sagemath.org/ | pynac]] || XXXX || ||
Line 90: Line 95:
 || numpy || 20080104-1.0.4.p2 || support by enthought, builds out of the box with MSVC + ATLAS ||  || [[http://numpy.scipy.org/ | numpy]] || 20080104-1.0.4.p2 || support by enthought, builds out of the box with MSVC + ATLAS ||
Line 98: Line 103:
 || networkx || 0.36.p1 || pure python, no portability issues ||  || [[http://networkx.lanl.gov/ | networkx]] || 0.36.p1 || pure python, no portability issues ||

This page is part of the Sage on Windows port.

Package Analysis

Below you will find a list of packages in Sage as well as remarks on issues that will potentially come up during the Windows port. As we progress we will add detailed problem reports and how we resolved those issues at individual pages.

Packages with upstream MSVC support

  • atlas

    3.8.p11

    Works find fine, Intel C for better performance preferred

    ecm

    6.1.3

    no Windows port, but C, potentially issues with threading. Upstream ecm-6.2 has MSVC project by Brian Gladman - upgrading evm to the 6.2 release is #3237

    gsl

    1.10.p0

    port exists: http://gnuwin32.sourceforge.net/packages/gsl.htm. Brian Gladman also maintains a native MSVC port, 32 & 64 bit.

    m4ri

    20071224.p1

    MSVC and SunForte port done by Martin Albrecht and in upstream. Upgrade ticket is #3204

    mpfr

    2.3.1

    pure C, Windows make file support welcome upstream, depends on gmp. MSVC project by Brian Gladman exists and is recommended by upstream

    numpy

    20080104-1.0.4.p2

    support by enthought, builds out of the box with MSVC + ATLAS

    scipy

    20071020-0.6.p3

    support by enthought, builds out of the box with MSVC + ATLAS

    scipy_sandbox

    20071020.p2

    support by enthought, builds out of the box with MSVC + ATLAS

    scons

    0.97

    works fine on Windows, python based.

    tachyon

    0.98beta.p4

    Windows port exists, unsure about MSVC + threading.

    weave

    0.4.9

    now part of scikits, works fine with MSVC

Pure Python Packages

  • networkx

    0.36.p1

    pure python, no portability issues

    sympy

    0.5.7

    pure python, no portability issues.

Packages without code

  • doc

    2.10.2.alpha0

    no compiled code, so no portability issues.