On 19 Apr., 13:27, Keshav Kini <keshav.k...@gmail.com> wrote:
> Perhaps a bit off topic, but is there any possibility of Sage ever being
> ported to Windows natively, i.e. without cygwin dependencies? We have a
> couple thousand lines worth of shell scripts currently underpinning Sage,
> and we'd probably have to convert those to Python or something to make them
> portable to Windows, right? Does anyone know what benefits we would gain
> from not using cygwin?
>
> -Keshav
>
> ----
> Join us in #sagemath on irc.freenode.net !
Hi Keshav,
the Sage ("core") library is written in Python and Cython. So Sage as
a "whole" runs not better than Python/Cython are supported, on a
specific system. Of course Python comes with Cygwin, but I guess on
Windows, only a (very!) small minority of Python users will actually
use Cygwin's Python, since there is a well supported Windows "native"
Python available.
This simply means that Python (let alone Cython) is not very well
tested under Cygwin, and this does mean trouble ahead.
It was before my time in the Sage project, but I think I read some old
posts from the times of Sage v1.x/v2.x which was regularly released
also under Cygwin, that the "Sage Cygwin port maintainer" at that time
(I would have to look up his name) had quite some troubles solving
with Cygwin-specific Python problems (mind you well, not special Sage
problems, but general Python problems!), and had at least one heated
discussion with Cygwin upstream IIRC. The situation for Python under
MinGW is even worse. Despite several attempts in the past, there does
not seem to be an actively maintained Python port at the moment for
MinGW (or MinGW-w64, for what it's worth). I don't know whether Python
has been tested under UWIN/AST (who has ever used this apart from its
creators at AT&T, even now it is open source?). And SUA/Interix is not
a real option for Sage, as that comes only with "Ultimate" and
"Enterprise" Windows editions, as Volker alread pointed out.
Now what about using the "native" Windows Python, built with a
compiler from Microsoft?
The Sage library "itself" would be fine, alas, it is not only written
in Python and parts in Cython, but Cython is also used as a "gluing
layer" to many plain C and C++ libraries (about two dozen of which are
really "vital", see PSAGE by William). And using a "native" Python,
built with a compiler from Microsoft, means it is linked against the
"msvcrt*.dll" C library/runtime (not like under Cygwin, which has its
"cygwin1.dll" for that, and as a Posix layer). This means that each
and every of these external C (and C++) libraries "vital" to Sage
would have also to be built against this very same "msvc*.dll", for
Sage to have any chance of working (if not, "double free's" would be
your least problems). And here comes the problem, since Microsoft
Visual C(++) seems still to be more preferable than GCC for doing so.
But most of the two dozen "vital" C/C++ libraries come from the "*nix
land", so would require quite some porting effort(s). This is what
David meant, and e.g. GMP/MPIR is not an example that this would be
easy/fast/painless by any means.
That being said, my personal dream is that sometime in the near future
we will have as an intermediate step the Sage Notebook running under
"native" Python on Windows, some "Sage" console also (and maybe even
some eye/user candy like the Mac OS X "Sage App"), and you have all
your files (even those of Sage, especially the Sage library itself)
hosted under the "native" Windows filesystem. But the bulk of the
"backend" of Sage, esp. the Sage "core" library, its needed "vital"
libraries, GAP and so on, all this runs "under the hood" in a (say
Linux) virtual machine!
I think this is doable today (e.g. VirtualBox 4 finally seems to have
working "shared folder" support, i.e. where symlinks are not broken
anymore, and networking in and out of a virtual machine is standard),
and would IMHO require not more skill than an undergraduate in
computer science does have (the biggest problem being rather how to
package things up, than getting them running).
Alternatively, one could replace the "virtual machine" in the above
proposal by "Cygwin", and thanks to the many and recent efforts of
Mike (see his post), this is even much closer to reality.
Cheers,
Georg
--
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
