Windows port status

51 views
Skip to first unread message

Alexandre Blondin Massé

unread,
Apr 14, 2011, 12:29:56 PM4/14/11
to sage-devel
Hi, all!

I know this is a recurrent subject, but I was wondering what was the
status about the Windows port. As many other users/developers of Sage,
I promote it the most I can but one obstacle that keeps showing up is
that it does not work natively on Windows. I know that there is the
VMWare solution, the Notebook server and all, but for some people, it
is unfortunately not good enough.

1. What remains to be done?
2. Who is working actively/partially actively on the project?
3. What human ressource is needed? What profile should people working
on it have?
4. Assuming that the appropriate people work on the project, is there
a timeline of what could be expected and when?

(I'm sure I forget important questions, so anyone feel free to add
one!)

Sorry for bugging you all with that again and thank you in advance for
the answers.

Alexandre

P.S. One reason I ask is that after discussing with Franco Saliola and
Sébastien Labbé, we thought it could be a good idea to hire someone
this summer at UQAM to work on the project, but maybe it is not
realistic. For instance, would it be doable for an undergraduate
student in computer science?

Kelvin Li

unread,
Apr 14, 2011, 2:34:47 PM4/14/11
to sage-devel
Currently, windows porting efforts are focusing on porting to Cygwin.
One of the targets for the Sage-5.0 release is a successful port to
Cygwin. Here is a page with some good info:

http://trac.sagemath.org/sage_trac/wiki/CygwinPort

I am not involved in the project myself. Someone else with more
knowledge should fill in.

-- Kelvin

On Apr 14, 12:29 pm, Alexandre Blondin Massé

Dr. David Kirkby

unread,
Apr 15, 2011, 3:30:08 AM4/15/11
to sage-...@googlegroups.com
On 04/14/11 05:29 PM, Alexandre Blondin Mass� wrote:
> Hi, all!
>
> I know this is a recurrent subject, but I was wondering what was the
> status about the Windows port. As many other users/developers of Sage,
> I promote it the most I can but one obstacle that keeps showing up is
> that it does not work natively on Windows. I know that there is the
> VMWare solution, the Notebook server and all, but for some people, it
> is unfortunately not good enough.
>
> 1. What remains to be done?

At least a partial list is at

http://trac.sagemath.org/sage_trac/wiki/CygwinPort

> 2. Who is working actively/partially actively on the project?

Mike Hansen has done more than most. I think it's fair to say not a lot has
happened over the last 6 months or so, but there does appear to be a recent (< 1
month) updates to several of the tickets, and a few new ones created. So perhaps
things are picking up.

> 3. What human ressource is needed? What profile should people working
> on it have?

A decent knowledge of Linux or UNIX would be ideal. A computer science student,
which you mention later. would be an ideal person.

> 4. Assuming that the appropriate people work on the project, is there
> a timeline of what could be expected and when?

Personally I can see that there are several issues which are absolutely trivial
to resolve.

Other bugs, like that due to lcalc

http://trac.sagemath.org/sage_trac/ticket/9165

are probably more difficult to resolve.

> (I'm sure I forget important questions, so anyone feel free to add
> one!)

I don't see anything important you have forgot.

> Sorry for bugging you all with that again and thank you in advance for
> the answers.

No problem.

> Alexandre
>
> P.S. One reason I ask is that after discussing with Franco Saliola and

> S�bastien Labb�, we thought it could be a good idea to hire someone


> this summer at UQAM to work on the project, but maybe it is not
> realistic. For instance, would it be doable for an undergraduate
> student in computer science?

Completing the port may be possible for an undergrad. It it fairly likely that
if someone put quite a bit of effort in, it would encourage others.

But even if they did not complete the port, they would be able to make
substantial headway.


--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Dave

Alexandre Blondin Massé

unread,
Apr 15, 2011, 11:59:01 PM4/15/11
to sage-devel
Hi !

Thank you for the detailed answer. It will help to find someone who
could work on the Windows port and I'm glad it seems reasonable to ask
a good undergraduated student in computer science to do the job, at
least partially.

Alexandre

Mike Hansen

unread,
Apr 16, 2011, 12:20:16 AM4/16/11
to sage-...@googlegroups.com
Hello,

Sorry about the delay in response.

On Thu, Apr 14, 2011 at 11:29 AM, Alexandre Blondin Massé
<alexandre.b...@gmail.com> wrote:
> 1. What remains to be done?

All of the current known build issues are listed at
http://trac.sagemath.org/sage_trac/wiki/CygwinPort under the "Build
Tickets" section. They all currently have fixes, but some work needs
to be done in updating spkgs for some of them. With those fixes, I
got all the spkgs in Sage 4.7.alpha3 to build on Cygwin.

Currently Sage 4.7.alpha3 does not start up due to a segfault caused
by either the new PARI added in 4.6 or the new interrupt handling
code. I have a clean backtrace for this, but I haven't delved into it
yet.

There are some tickets on there for doctest failures that need to be
looked into, but a number of them are trivial.

> 2. Who is working actively/partially actively on the project?

I think I am the only one who is spending some time on it every now and then.

> 3. What human ressource is needed? What profile should people working
> on it have?

It seems like most the issues left are with C code so someone who is
very familiar building Unix C code would be best.

--Mike

Dima Pasechnik

unread,
Apr 16, 2011, 12:43:10 AM4/16/11
to sage-devel
Mike,

I recall reporting some weirdness on Windows 7, originating from the
randomized addressing issue.
(that's what rebase and rebaseall Cygwin utilities are/were fighting).
At that time Cygwin still had Python 2.5.

Is it correct that since then it has fixed itself, as Cygwin folks
found a way to fix these problems?

Dima


On Apr 16, 12:20 pm, Mike Hansen <mhan...@gmail.com> wrote:
> Hello,
>
> Sorry about the delay in response.
>
> On Thu, Apr 14, 2011 at 11:29 AM, Alexandre Blondin Massé
>
> <alexandre.blondin.ma...@gmail.com> wrote:
> > 1. What remains to be done?
>
> All of the current known build issues are listed athttp://trac.sagemath.org/sage_trac/wiki/CygwinPortunder the "Build

Mike Hansen

unread,
Apr 16, 2011, 2:36:24 AM4/16/11
to sage-...@googlegroups.com, Dima Pasechnik
On Fri, Apr 15, 2011 at 11:43 PM, Dima Pasechnik <dim...@gmail.com> wrote:
> I recall reporting some weirdness on Windows 7, originating from the
> randomized addressing issue.
> (that's what rebase and rebaseall Cygwin utilities are/were fighting).
> At that time Cygwin still had Python 2.5.
>
> Is it correct that since then it has fixed itself, as Cygwin folks
> found a way to fix these problems?

Everything I've done has been on WindowsXP since that's the only
Windows box I currently have access to.

--Mike

Dima Pasechnik

unread,
Apr 16, 2011, 3:04:07 AM4/16/11
to Mike Hansen, sage-...@googlegroups.com
Mike,

As XP is becoming obsolete (it does not seem to be possible to easily buy it, or
a new computer with it preinstalled), it seems to be urgent to start testing on
Windows 7, too.
When I tried it, it really behaved badly (I don't have such a system
available right now,
but I asked our IT to provide me with one).


Best,
Dima

Jason Grout

unread,
Apr 16, 2011, 9:16:36 AM4/16/11
to sage-...@googlegroups.com
On 4/16/11 2:04 AM, Dima Pasechnik wrote:
> As XP is becoming obsolete (it does not seem to be possible to easily buy it, or
> a new computer with it preinstalled)

In fact, it's been end-of-lifed:

http://windows.microsoft.com/en-US/windows/help/end-support

Jason


Jason Grout

unread,
Apr 16, 2011, 9:19:59 AM4/16/11
to sage-...@googlegroups.com


Oops, I didn't realize that SP3 was out. It looks like support goes
through April 2014:

http://windows.microsoft.com/en-US/windows/products/lifecycle?T1=winxp

Jason


Keshav Kini

unread,
Apr 19, 2011, 7:27:26 AM4/19/11
to sage-...@googlegroups.com
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 !

David Kirkby

unread,
Apr 19, 2011, 8:57:27 AM4/19/11
to sage-...@googlegroups.com
On 19 April 2011 12:27, Keshav Kini <kesha...@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

A native port to Windows would need a lot more than converting the
scripts to Python. Much of the code in Sage was written on UNIX/Linux
systems and would not easily port to Windows. Even porting to a proper
UNIX system is hard (the Solaris port was a LOT of work) and attempts
to build on AIX or HP-UX have found numerous issues. I think for
Windows, you would really struggle to get a native port.

Much of the code in Sage is written in a GNU variant of C and C++, so
I doubt it would compile with a Microsoft compiler. (Much of it will
not build with the Sun compiler on Solaris). Most of the Makefiles
have GCC-specific flags, so one would probably be better to try to use
gcc on Windows rather than use Microsoft's compiler.

As someone who spent 100's if not 1000's of hours on the Solaris port,
I personally think a complete native port to Windows would take 10-100
man years. Others have disagreed with that guesstimate, and think it
would take less time.

Getting a sub-set of Sage working natively on Windows might well be
doable. Some parts of Sage (Maxima, R etc) already have Windows
interfaces.

Dave

Volker Braun

unread,
Apr 19, 2011, 8:59:24 AM4/19/11
to sage-...@googlegroups.com
A lot of the C code is Sage relies on posix, in particular fork() is not provided by the Win32 API. So a plain Win32-version of Sage would be a very invasive rewrite of a lot of stuff.

Even Microsoft noticed that you need to support posix for real work, so they have SFU (Windows Services for UNIX) which is a posix compatibility layer on top of the Windows kernel. But in their zeal for upselling they don't include it with every one of the dozen Windows 7 editions. So we can't really rely on that.

In summary, I think cygwin (or one of the other 3rd party posix layers) is the only real option.


Dima Pasechnik

unread,
Apr 19, 2011, 10:32:04 AM4/19/11
to sage-devel


On Apr 19, 7:27 pm, 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?

Shell scripts aren't a problem, as there is a native port of bash to
Win32...

even porting GAP alone to native Windows has not been done...
(it's doable, but very unpleasant)
Similar tasks for Singular, Maxima, etc etc...

Jason Grout

unread,
Apr 19, 2011, 12:40:53 PM4/19/11
to sage-...@googlegroups.com
On 4/19/11 9:32 AM, Dima Pasechnik wrote:
> Similar tasks for Singular, Maxima, etc etc...

Maxima appears to already support Windows, at least in some shape or form:

http://maxima.sourceforge.net/download.html

Jason


Georg S. Weber

unread,
Apr 19, 2011, 4:36:24 PM4/19/11
to sage-devel
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

William Stein

unread,
Apr 19, 2011, 11:21:52 PM4/19/11
to sage-...@googlegroups.com, sage-windows

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-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@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

Volker Braun

unread,
Apr 20, 2011, 12:50:20 AM4/20/11
to sage-...@googlegroups.com
If you are fine with using a virtual machine then just punch the notebook port through. The only thing running native would be the browser rendering the worksheet. Of course you need admin rights to install a virtual machine, and there can be only one hypervisor on the system. So you'll never have a one-click app.

With Cygwin, a one-click Sage installer could just drop a sufficient minimal install and then add Sage on top. The official python docs specifically mention cygwin so it can't be that hard to build nowadays.

I don't see the point of going beyond this stage. Yes, with huge effort one could port everything to Win32 instead of posix. For what, to run 10% faster on somebody's gaming system? While running slower everywhere else because we have to remove fork()? Windows has essentially no market share in high performance computing. Or, for that matter, anywhere outside of the desktop. Having students work on a Win32 port is not in the interest of their education unless they have their mind already set on a job in Redmont.

Dr. David Kirkby

unread,
Apr 20, 2011, 3:59:26 AM4/20/11
to sage-...@googlegroups.com
On 04/20/11 04:21 AM, William Stein wrote:

> 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.

If the "moving target" became a problem, we could always create a Cygwin
installer which went to sage.math to download the files. I'm sure it can't be
hard to add another mirror and remove the other mirrors.

Dave

RegB

unread,
Apr 20, 2011, 10:20:35 AM4/20/11
to sage-devel
Perhaps even farther off topic;
I doubt that Cygwin (Cygwin/X) is in any case a good path for many/
most MS_Windows
folk - from THEIR point of view.
The path to getting Cygwin/X up and running "usefully" on a MS_Windows
platform
is long and arduous for the naive user, e.g. it was so for me.

Oracle (Sun) VM_VirtualBox installs as a MS_Windows program.
It is "culturally compatible" with everything the user is used to.
The learning curve to then install a standard Linux distro, e.g.
Ubuntu or Debian, then Sage within that is quite trivial.
VMware is another possibility, although I think that isn't "free".

For Sage to be adopted WIDELY by windows users the path
to getting it up and running needs to be simple and reasonably quick.
Cygwin /X does not (yet) offer that.

For my very simple needs/wants there has not been a performance
issue with Vista->VirtualBox->Debian->Sage, although it would seem
that Vista->Cygwin/X->Sage may perform better simply by having
one fewer layers - Yes/No ?

kcrisman

unread,
Apr 20, 2011, 10:29:46 AM4/20/11
to sage-devel


On Apr 20, 10:20 am, RegB <2regburg...@earthlink.net> wrote:
> Perhaps even farther off topic;
> I doubt that Cygwin (Cygwin/X) is in any case a good path for many/
> most MS_Windows
> folk - from THEIR point of view.
> The path to getting Cygwin/X up and running "usefully" on a MS_Windows
> platform
> is long and arduous for the naive user, e.g. it was so for me.
>
> Oracle (Sun) VM_VirtualBox  installs as a MS_Windows program.
> It is "culturally compatible" with everything the user is used to.
> The learning curve to then install a standard Linux distro, e.g.
> Ubuntu or Debian, then Sage within that is quite trivial.
> VMware is another possibility, although I think that isn't "free".
>
> For Sage to be adopted WIDELY by windows users the path
> to getting it up and running needs to be simple and reasonably quick.
> Cygwin /X does not (yet) offer that.

My understanding is that the previous Cygwin-cum-Sage behavior was
that you downloaded one installer, and that this then would
essentially be a double-click to the Sage command line. At any rate,
it is intended to be packaged as one file to download, which is then
opened - not a multi-step process, which is just how one needs to do
it now because it doesn't work fully yet without some massaging which
is in various tickets.

- kcrisman

Dima Pasechnik

unread,
Apr 20, 2011, 11:38:18 AM4/20/11
to sage-devel


On Apr 20, 10:20 pm, RegB <2regburg...@earthlink.net> wrote:
> Perhaps even farther off topic;
> I doubt that Cygwin (Cygwin/X) is in any case a good path for many/
> most MS_Windows
> folk - from THEIR point of view.
> The path to getting Cygwin/X up and running "usefully" on a MS_Windows
> platform
> is long and arduous for the naive user, e.g. it was so for me.

one probably won't need X11 part, if the graphics is handled via the
notebook/browser.
The only things needed from the user would be to start Sage "server"
application, which
can be just one click, and then open the browser to connect to it.

In fact, deploying an application that uses cygwin.dll is trivial ---
Sage is of course
much more, as it needs a subset of the development environment to take
advantage of Cygwin etc.

>
> Oracle (Sun) VM_VirtualBox  installs as a MS_Windows program.
> It is "culturally compatible" with everything the user is used to.
> The learning curve to then install a standard Linux distro, e.g.
> Ubuntu or Debian, then Sage within that is quite trivial.
> VMware is another possibility, although I think that isn't "free".
>
> For Sage to be adopted WIDELY by windows users the path
> to getting it up and running needs to be simple and reasonably quick.
> Cygwin /X does not (yet) offer that.
>
> For my very simple needs/wants there has not been a performance
> issue with Vista->VirtualBox->Debian->Sage, although it would seem
> that Vista->Cygwin/X->Sage may perform better simply by having
> one fewer layers  - Yes/No ?

the VM performance hit might be relatively minor, but the amount of
resources a VM
takes is quite big, compared to Cygwin.

John Cremona

unread,
Apr 20, 2011, 12:07:21 PM4/20/11
to sage-...@googlegroups.com
Why not move this thread to the sage-windows group?

John

Robert Bradshaw

unread,
Apr 20, 2011, 11:37:16 AM4/20/11
to sage-...@googlegroups.com
On Tue, Apr 19, 2011 at 9:50 PM, Volker Braun <vbrau...@gmail.com> wrote:
> If you are fine with using a virtual machine then just punch the notebook
> port through. The only thing running native would be the browser rendering
> the worksheet.

I think that this is the whole point no matter what approach we take;
the user shouldn't have to interact with the Sage's container
environment at all--whether that be Cygwin or a virtual machine or a
co-linux like solution or whatever. The question then becomes what of
these platforms is it easiest to distribute Sage in (install, startup,
and get Sage working at all).

> Of course you need admin rights to install a virtual machine,
> and there can be only one hypervisor on the system. So you'll never have a
> one-click app.
> With Cygwin, a one-click Sage installer could just drop a sufficient minimal
> install and then add Sage on top. The official python docs specifically
> mention cygwin so it can't be that hard to build nowadays.
> I don't see the point of going beyond this stage. Yes, with huge effort one
> could port everything to Win32 instead of posix. For what, to run 10% faster
> on somebody's gaming system?

Interestingly, some libraries and computations actually run faster in
a virtualized linux environment than natively on Windows.

> While running slower everywhere else because we
> have to remove fork()? Windows has essentially no market share in high
> performance computing. Or, for that matter, anywhere outside of the desktop.
> Having students work on a Win32 port is not in the interest of their
> education unless they have their mind already set on a job in Redmont.
>

William Stein

unread,
Apr 20, 2011, 12:34:48 PM4/20/11
to sage-...@googlegroups.com
On Wed, Apr 20, 2011 at 9:07 AM, John Cremona <john.c...@gmail.com> wrote:
> Why not move this thread to the sage-windows group?

+1 -- I cross-posted my response there.

--

William Stein

unread,
Apr 20, 2011, 12:43:05 PM4/20/11
to sage-...@googlegroups.com, sage-windows
[Please respond on sage-windows...]

On Tue, Apr 19, 2011 at 9:50 PM, Volker Braun <vbrau...@gmail.com> wrote:

> education unless they have their mind already set on a job in Redmond.

These are some of the many reasons I stopped working on a native Win32 port.

> If the "moving target" became a problem, we could always create a Cygwin
> installer which went to sage.math to download the files. I'm sure it can't
> be hard to add another mirror and remove the other mirrors.

This could be a lot of work to maintain, but it is an interesting
idea, and I'm surprised we didn't consider doing it before. Thanks
for suggesting it.

RegB:


> The path to getting Cygwin/X up and running "usefully" on
> a MS_Windows platform
> is long and arduous for the naive user, e.g. it was so for me.

Just to confirm what kcrisman said, from 2005-2007 when we distributed
a Cygwin version of Sage this wasn't the case. It really was a
1-click install. We used a standard .msi installer and just
distributed the libraries (etc.) in Cygwin that were needed, and it
worked.

Bradshaw:


> Interestingly, some libraries and computations actually run faster in
> a virtualized linux environment than natively on Windows.

For example, the assembly language optimizations in GMP and/or MPIR
are different for MSVC + Windows than for GCC + Linux, even on the
same hardware. This can have a significant impact on performance,
since the virtual machine will be building MPIR for GCC + Linux on
that hardware.

Dima:


> the VM performance hit might be relatively minor, but the amount of
> resources a VM
> takes is quite big, compared to Cygwin.

There are a lot of performance related issues people haven't mentioned
yet, as far as I can tell:

* fork on cygwin works, but it is still dog slow -- vastly slower
than on Linux + VM

* VM's generally suck at shared file support "just working",
whereas in Cygwin it always just works

* VM's sometimes/often have issues with networking, whereas in
Cygwin it just works or isn't necessary

* Cygwin is 32-bit only. It is easy to make a 64-VM running Linux
(maybe even if Windows is a 32-bit install), as long as the hardware
is 64-bit.

William

Reply all
Reply to author
Forward
0 new messages