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