On Tue, Apr 19, 2011 at 1:36 PM, Georg S. Weber
<georgswe...@googlemail.com> wrote:
>
>
> 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)Gary Zablackis. (Who is now deceased.) > 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. Python was annoyingly seriously broke on Cygwin for about 8 months. Gary understood exactly what the problem was, but the Cygwin dev's didn't seem to agree... at least not until several months. At the time (5 years ago), at least, it was very difficult to install Cygwin-from-one-year-ago (say), which made this issue a serious problem for Sage for a while. Cygwin is not like Linux distros -- instead of a single CD with a complete install on it, one installs a tiny installer, and that downloads Cygwin packages from a central repository. This makes Cygwin a constantly changing moving target. That said, Cygwin was and still is by far the easiest way to get Sage running on Microsoft Windows without using Linux somehow (a virtual machine or co-Linux). > 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). Yes, it's worse, much worse. > 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. It would be insanely hard to do in the first place, and really hard to maintain in the longrun. But it's doable if some people would just start doing it, and would be optimal in the longrun. As has been mentioned elsewhere, pexpect is basically a non-option for Windows in the longrun, so everything in Sage that uses pexpect would have to be rewritten to not use pexpect (or simply not be available under Windows). Minimizing use of pexpect is a good idea anyways; the recent work on libGAP, libECL, etc., all helps tremendously with making this possible. This project (a native port of Sage to Windows) is doable but would really take a *lot* of time, and it is definitely *NOT* something that a random computer science undergrad could do. In fact, it's unlikely any one person could do it. E.g., many people tried to finish my libGAP work (including me), and person after person failed miserably until Volker Braun came along and just powered through it at a recent Sage Days. There are many similar problems with native Sage on Windows, and they would all have to be solved. Some of us spent a few months on this project already, including writing a 100% Python-based build system. You can see and even try the results here: http://windows.sagemath.org/download.html > 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, I've done that before. :-) I didn't use pexpect though -- the evaluation was in the same process as Sage, just using the eval function. > 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 > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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
