Re: [sage-devel] Re: Windows port status

[William Stein]

On Tue, Apr 19, 2011 at 1:36 PM, Georg S. Weber
<georg...@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-...@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

[William Stein]

[Please respond on sage-windows...]

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

[Bill Hart]

On 20 April 2011 17:43, William Stein <wst...@gmail.com> wrote:
> [Please respond on sage-windows...]
>
> 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. 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 Redmond.
>
> These are some of the many reasons I stopped working on a native Win32 port.

Whilst I don't disagree with the comments at all, it is rather the
other way around:

the reason Windows has essentially no share in high performance
computing is..... because Sage is not ported to native Windows (and
for similar reasons, e.g. insert {your favourite high performance
computing software} for {Sage}).

Well, if I am brutally honest, Microsoft have shot themselves in the
foot in this regard. In case someone from Redmond reads this list, let
me enumerate some of the things that I personally see as reasons for
this (I might be wrong on some of this stuff -- but perception is
everything):

1) The very long delay before 64 bit Windows operating systems became
standard, as opposed to the *nix (including MAC OSX) platforms, which
made them available/standard very fast. In this I would include the
ability to easily upgrade from a 32 bit to 64 bit Windows.

2) The lack of decent command line scripting and build tools which are
easy to target when you have a build that works for nearly every other
*nix. Yes, MS, we love the GUI, but it just doesn't cut it when trying
to make large volumes of existing high performance computing code work
on Windows.

3) No support for inline assembly on x86_64 in MSVC. Well, there is
support in the guise of the Intel compiler, but it costs another
$1000, or something like that.

4) Lack of a *performant* posix layer (maybe this exists, but it's
either no longer supported, or not available for enough Windows, or
whatever). Hence Cygwin.

5) Completely different ABI to just about every other x86_64 ABI out
there. Why does MS have to change everything and make it unique to
Windows? What's wrong with embracing standards? The whole sizeof
long/int/ptr business and the callee saved register business makes
high performance computing code very difficult to develop for Windows,
unless you are targeting just Windows.

6) Microsoft has been pushing C# and C++ not C. The former is managed
and slow, thus not terribly suitable for high performance computing.
The C# community seems uninterested in reinventing the wheel in C#.
The latter is more acceptable these days, but see 5 and also note that
unless you support the more recent C standard (C99), many things
become unavailable.

Every obstacle, no matter how minor it may seem, becomes the source of
another percentage of users choosing something else. You have to
remove *all* the obvious obstacles before you can expect to become
dominant or even a major player in a given market. You can't just
decide to leave large sectors of the community out in the cold and
expect it will be overlooked.

Maybe in some future OS from MS, they could give some of the above a
greater priority. Of course, if they don't intend to be the OS of
choice for high performance computing, ever, then it's perfectly fine
to keep doing what they're doing.

Even though I'd love to run Sage on Windows, all my high performance
computing is done on a linux box.

Bill.

[Sazzad]

@Alexandre:

Hello!

Thank you very much for bringing up this topic. I've always been looking for a free/open source alternative to Mathematica. Hence, I would love to have Sage ported natively on windows. Despite my interest, several things was holding me back (mainly slow internet speed and electricity disruption). I've downloaded whole cygwin packages and it took last February and half of March. :P

Now, I've got a better WiMAX internet (30 KB/sec, up to 3GB per month), the only problem is electricity (I have been interrupted thrice while composing this email!).

I've been looking for ways about how to make an open-source/free alternative to Mathematica. Mathematica is really awesome. Last year, Bill Hart posted long threads about Sagemath windows porting issues. Every time I read it, I get baffled. He was so true about some of the issues that there is no way escaping. He even offered to use Scala for a completely new write of Sagemath (But now I think this may not be a good option).

I discovered Making Mathematica with Haskell while researching. 

What I've understood so far is, porting is still an area out of our reach. Not because, some technical difficulties lie. But because, most often standards are not followed by the industry (or, they aren't pragmatic enough to be followed?). Like Theory Of Everything, we're looking for a solution so that everything works on everything. This reveals some of the complexities of porting at hardware level.

But, for now I plan to work steadily on cygwin (daily 2-3 hours, since this is the time I've left free). If I personally wanted to make a native port I would try a MinGW port. Not, MSVC. If I personally, were to rewrite sage from scratch, I would go for Haskell probably. Chiefly because, they have a religious attitude towards Haskell. Its good for any open source project to be successful.

I disagree about the qualification required for Sagemath port. Any kind of porting largely depends on the knowledge of that particular language(where does C89 differs from C99) and environment and debugging skills (gdb/pdb). Now I don't think even the Red level coders at TopCoder is used to a debugger (or Makefiles/Autoconf). And at schools programming is some sorts of algorithmic problem solving not industry oriented. So I request explicitly tell these requirements anybody interested in porting, so that they can get prepared.

While solving a problem at SPOJ I just discovered few weeks back, you can't declare an integer array of length 1000000 in C. :)

By the way, I've a question. I've downloaded Sage source code. By the list of tickets do you mean, they arise when one tries to compile this source under cygwin?

Sincerely,

Sazzad Bin Kamal

[Bill Hart]

Regarding Haskell, I agree it's pretty good for mathematics. It's far
too hard for most mathematicians to understand though.

In recent weeks I have truly come to appreciate it though. But I've
still not written any sizeable programs in it. I think it would get
very frustrating very quick.

I'm working on a language that is much easier than Haskell, but steals
some of its good ideas. I'll let you know in ten years if I was
successful.

Bill.

> --
> You received this message because you are subscribed to the Google Groups
> "sage-windows" group.
> To post to this group, send email to sage-w...@googlegroups.com.
> To unsubscribe from this group, send email to
> sage-windows...@googlegroups.com.

> For more options, visit this group at

> http://groups.google.com/group/sage-windows?hl=en.
>

[Sazzad]

@Bill: I'll be waiting .... :)

Sincerely,

Sazzad Bin Kamal

[Dr. David Kirkby]

On 04/20/11 05:43 PM, William Stein wrote:
> [Please respond on sage-windows...]

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

I don't actually believe it would be hard to maintain. In fact implementing it
could make for a small student project. I don't see why it should be necessary
to update Cygwin much (if at all).

Sage builds fine on the first release of Solaris 10 (2005), which is around 6
years old. There's no need to keep updating Solaris to keep Sage working. So
once the binaries are in place on sage.math, it should not take much effort to
keep it working. The whole point is the operating system is not changing, so
there should be no need to keep updating the Cygwin components.

One of the strong points of Sage is that since it has everything with it,
there's little reliance on what the system has installed. You are basically
saying that's not possible under Cygwin. That means it goes against the
philosophy of Sage. But there's no need to do that - it can be overcome.

Dave

[Dr. David Kirkby]

On 04/21/11 07:47 PM, Bill Hart wrote:
> Regarding Haskell, I agree it's pretty good for mathematics. It's far
> too hard for most mathematicians to understand though.
>
> In recent weeks I have truly come to appreciate it though. But I've
> still not written any sizeable programs in it. I think it would get
> very frustrating very quick.
>
> I'm working on a language that is much easier than Haskell, but steals
> some of its good ideas. I'll let you know in ten years if I was
> successful.
>
> Bill.

Well, according to Jon Harrop

http://www.haskell.org/pipermail/haskell-cafe/2007-May/026221.html

writing a Mathematica implementation is an excellent idea and would be a great
project for a Haskell newbie.

So there's something for you to ponder Bill!!!

Dave (writing this rather tong-in-cheek)

[Bill Hart]

This was, I think, largely a case of misunderstanding. What was
proposed there is quite doable in Haskell.

I was going to make an estimate of how many lines of code I think it
would take in theory to implement the documented mathematical
functionality of Sage in Haskell (sans doctests and extended comments
of course).... {steps back to reality}

The thing is though, only a genius could really elegantly implement
Sage in Haskell. For example, you can't just stick a print "hello"
wherever you want (well you can, but you have to bathe and undergo
seven days of ritual cleansing if you do).

To entertain yourself, here are two blogs of interest:

1) http://symbo1ics.com/blog/?p=788

[Ignore the big long winge at the beginning of that. The code starts a
pageful or two down. The big long winge turns out to be the guy not
understanding why 1 has type (Num t) => t (actually that's a typeclass
and type, technically), rather than what you might expect it to. Or
something like that.]

2) http://haskellformaths.blogspot.com/

These are both exceedingly elegant and I think they should be required
reading for everyone at age 9.

I think my point is, yes, you can do immensely powerful things in
Haskell. But I only know 3 people in the entire world who have shown
even a remote interest in the language. Even the Haskell people admit
there are only 38 in total:

http://steve-yegge.blogspot.com/2010/12/haskell-researchers-announce-discovery.html

There are reasons for this.

Bill.

[Bill Hart]

P.S: if you want some serious (non mathematical) entertainment, see:

Part I: http://blip.tv/file/324976
Part II: http://blip.tv/file/324976
Slides: http://conferences.oreillynet.com/presentations/os2007/os_peytonjones.pdf

It's long, but he basically implements an abstraction of the workings
of a Window manager in Haskell. This is not something you couldn't do
elegantly in other languages, but it's still a classic talk which
shows Haskell in the hands of a genius.

Bill.

[Dr. David Kirkby]

On 04/22/11 02:03 AM, Bill Hart wrote:

> I think my point is, yes, you can do immensely powerful things in
> Haskell. But I only know 3 people in the entire world who have shown
> even a remote interest in the language. Even the Haskell people admit
> there are only 38 in total:

The second part of that statement is total rubbish. Here alone is one company
looking for people with Haskell experience.

http://www.tsurucapital.com/en/jobs.html#programmer

do a search on a job site, type hask, and you will find the rest if filled in. I
very much doubt that if there was only 38 people in the entire world having the
remotest interst in the language.

In fact, doing a search on monstir.com I can find more jobs mentioning Haskell
than Mathematica.

Anyway, this is all very off-topic.

Dave

[Sazzad]

On Wed, Apr 20, 2011 at 11:37 PM, Bill Hart <goodwi...@googlemail.com> wrote:

 

The lack of decent command line scripting and build tools which are

easy to target when you have a build that works for nearly every other
*nix. Yes, MS, we love the GUI, but it just doesn't cut it when trying
to make large volumes of existing high performance computing code work
on Windows.

Just for the record:

1. There is now a bash alternative in windows, PowerShell. Its been said that PowerShell has been greatly influenced by Bash.
2. Windows alternative to Make/AutoConf : MSBuild

--
Sincerely,
Sazzad Bin Kamal

[Bill Hart]

Did you even read the link I provided? If you had done so, you would
not have bothered to type all that.

[Dr. David Kirkby]

On 04/22/11 03:07 PM, Bill Hart wrote:
> Did you even read the link I provided? If you had done so, you would
> not have bothered to type all that.

Well it was a very long web page, so no, I did not really all of it.

dave

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

[Bill Hart]

As far as I know, the Haskell developers actually claim that in the
past few years Haskell usage has gone from a few hundred people to a
few tens of thousands.

Tiobe claims about a 0.3% usage of Haskell. So the Haskell devs may be
slightly underestimating. But they are probably not far off.

Bill.

[Dr. David Kirkby]

On 04/21/11 04:42 PM, Sazzad wrote:

> I've been looking for ways about how to make an open-source/free alternative
> to Mathematica.

Me too. I've reached the conclusion it is practically impossible - see below for
some of my reasons.

> Mathematica is really awesome.

I too are very impressed with it. I quite like MATLAB too, but always have the
feeling MATLAB is a collection of bits bolted together and not necessarily
designed to work with MATLAB from the start. That is the case with the symbolic
toolbox for example. First MATLAB used to use a cut-down version of Maple. Then
Mathworks acquired a company that had a symbolic maths product. But they don't
fit as well together as Mathematica does.

> Last year, Bill Hart posted
> long threads about Sagemath windows porting issues. Every time I read it, I
> get baffled. He was so true about some of the issues that there is no way
> escaping. He even offered to use Scala for a completely new write of
> Sagemath (But now I think this may not be a good option).
>
> I discovered Making Mathematica with
> Haskell

> http://www.haskell.org/pipermail/haskell-cafe/2007-May/026264.html
> while researching.

That post refers to something Jon Harrop posted. If you Google Jon's name you
will probably conclude as I have done. He talks a lot of ****. His comment
at

http://www.haskell.org/pipermail/haskell-cafe/2007-May/026221.html

=== Written by Jon Harrop ===
I noticed a recent thread about writing a Mathematica implementation in
Haskell. I think this is an excellent idea and would be a great project for a
Haskell newbie."
======== </quote> ===========

is but one of the stupid things he has written. I tend to copy any of his posts
to /dev/null. Who in their right mind thinks a Mathematica implementation is an
ideal task for a Haskell newbie? Jon does though!

I would tend to take what he says with a BIG pinch of salt. I guess the author
of the post you linked to has trouble believing some of Jon's claims, as he
concludes with "I'm in a state of disbelief here."

So I would not take too much notice of the post you quote.

> What I've understood so far is, *porting* is still an area out of our reach.

> Not because, some technical difficulties lie. But because, most often

> *standards
> *are not followed by the industry (or, they aren't pragmatic enough to be

> followed?). Like Theory Of Everything, we're looking for a solution so that
> everything works on everything.

> This<http://www.dina.kvl.dk/~abraham/Linus_vs_Tanenbaum.html> reveals
> some of the complexities of porting at *hardware *level.

A lot of code is Sage is written by mathematicians who quite honestly don't care
and/or don't have a clue about standards of coding. At the end of the day,
writing code conforming to professional standards does not result in
publications and in this day and age it is basically a case of "publish or
perish". So there's little incentive to make code any better than needed to
solve your own particular problem on your own particular computer.

I cringe when I see some of the code in Sage, like a shell script that starts

#!/bin/sh

then looks for various programs (grep, sed, and also "sh") and will report if sh
does not exist !!! That's one of many jems I have seen.

That is part of the problem which makes porting Sage hard.

AIX 5.3 is a certified POSIX UNIX operating system. I think about 20% of the
Sage packages will build on AIX. Given the difficultly in porting to another
UNIX platform, I think its fair to say a Windows platform would be a lot harder.
(To be fair, a lot of the failures on AIX are due to their prerequisites failing
to build, but there are others which have other problems).

> But, for now I plan to work steadily on cygwin (daily 2-3 hours, since this

> is the time I've left free). If I personally wanted to make a *native* port

> I would try a MinGW port. Not, MSVC. If I personally, were to rewrite sage
> from scratch, I would go for Haskell probably. Chiefly because, they have a

> *religious* attitude towards Haskell. Its good for any open source project
> to be successful.

Pure is another language worth looking at.

If I ever decided to make an MMA clone (and I've given it some consideration),
basing it on C++, Lisp, Pure or Haskell are all worth serious consideration.

But the basic problem is that the task is too hard without a serious amount of
resources. I doubt one could find the computer science expertese to start the
project and unless solid foundations are in place, one would not attract
mathematicians to become developers. Until the foundations are solid, there's
not a lot of need for mathematicians.

If written in Lisp, Pure of Haskell I think it would be hard to get the
mathematicians interested. Some write in C++, but there's some awful C++ in Sage.

I think getting code to do something useful in Python is a lot easier than
Haskell, Lisp or Pure, yet all of those languages are probably technically
superior for an MMA clone.

> I disagree about the qualification required for Sagemath port. Any kind of
> porting largely depends on the knowledge of that particular language(where
> does C89 differs from C99) and environment and debugging skills (gdb/pdb).
> Now I don't think even the Red level coders at TopCoder is used to a
> debugger (or Makefiles/Autoconf). And at schools programming is some sorts
> of algorithmic problem solving not industry oriented. So I request
> explicitly tell these requirements anybody interested in porting, so that
> they can get prepared.

I'm not quite sure what you are getting at here. I'm still of the opinion that a
native port would be very hard indeed.

> While solving a problem at SPOJ I just discovered few weeks back, you can't
> declare an integer array of length 1000000 in C. :)

drkirkby@hawk:~$ cat test.c
#include <stdio.h>
int main(){
int a[1000000];
}

drkirkby@hawk:~$ gcc test.c
drkirkby@hawk:~$ ./a.out

> By the way, I've a question. I've downloaded Sage source code. By the list
> of tickets do you mean, they arise when one tries to compile this source
> under cygwin?

You would need to try to compile the source and solve any problems. Then run the
tests and solve them. Expect to come across some doggy code along the way.

> Sincerely,
> Sazzad Bin Kamal
>

I seriously believe if one wanted a heavy maths program as a native Windows
application, it would be best to start from scratch and not from the Sage source
code. You would cherry-pick some of the libraries which are well written and
portable, and reject code that is inherently unportable.

But it would be a huge undertaking, and I personally don't see how it could be
done without an interested academic with serious funding for such a project.

I think you would be best to have

* Separate front end to kernel, perhaps communicating via OpenMPI to allow
multiple-kernels to be used for parallel processing.
* Use libraries like mpfr, mpc, mpir but forget any code that does not have a
well defined library interface. Also forget things like ATLAS which would be
difficult to port.
* GLR parser to understand Mathematica. Perhaps flex & bison could provide the
parser.
* A LOT of things I've not even thought about. Basically this would be a huge
undertaking, and I doubt it's practical.

Dave

[Sazzad]

First of all thank you very much for your exhaustive reply. I've learned a lot.

On Sun, Apr 24, 2011 at 4:05 PM, Dr. David Kirkby <david....@onetel.net> wrote:

I would tend to take what he says with a BIG pinch of salt. I guess the author of the post you linked to has trouble believing some of Jon's claims, as he concludes with "I'm in a state of disbelief here."

So I would not take too much notice of the post you quote.

Me too. But, this explanation illuminated me the history of Mathematica.

 

A lot of code is Sage is written by mathematicians who quite honestly don't care and/or don't have a clue about standards of coding. At the end of the day, writing code conforming to professional standards does not result in publications and in this day and age it is basically a case of "publish or perish". So there's little incentive to make code any better than needed to solve your own particular problem on your own particular computer.

This motto is enough to resist my temptation for higher studies. I'm a big fan of Daniel Lemire's blog. As an influence, I may go for an MSc at most. Probably in Mathematics/TCS, I'm not sure. But, since I'm not planning for higher studies, I've got some time of my own. And, I'm planning to spend it on Sage. :)

 

Pure is another language worth looking at.

Thank you very much for mentioning. I didn't know its name. :P

The documentation says, its not appropriate from Big projects but its worth learning.

 

If I ever decided to make an MMA clone (and I've given it some consideration), basing it on C++, Lisp, Pure or Haskell are all worth serious consideration.

But the basic problem is that the task is too hard without a serious amount of resources. I doubt one could find the computer science expertese to start the project and unless solid foundations are in place, one would not attract mathematicians to become developers. Until the foundations are solid, there's not a lot of need for mathematicians.

If written in Lisp, Pure of Haskell I think it would be hard to get the mathematicians interested. Some write in C++, but there's some awful C++ in Sage.

I think getting code to do something useful in Python is a lot easier than Haskell, Lisp or Pure, yet all of those languages are probably technically superior for an MMA clone.

I understand your concern. See? I started to work out a problem on Graph Theory. This is the primary sin that brought me so far. I was completely stupid back then and knew nothing about Graph Drawing vs Graph/Network Processing. Combinatorica was and is a very good package for both Graph Drawing and Processing. But, I couldn't find the book I wanted to learn Combinatorica. I tried JGraphT, LEDA, QuickGraph, Graphviz and then NetworkX. NetworkX rescued me. I did all my work based on it and matplotlib (for drawing. Well for presentation I used TikZ). I wanted to use Sagemath, since its graph theory package is the most versatile. But, vmware image version of Sage took a lot of ram. I thought, if I have to take care of so much technical details how come I can concentrate on the theoretical part? Where is the time to study and ponder all those theories? 

 

I disagree about the qualification required for Sagemath port. Any kind of
porting largely depends on the knowledge of that particular language(where
does C89 differs from C99) and environment and debugging skills (gdb/pdb).
Now I don't think even the Red level coders at TopCoder is used to a
debugger (or Makefiles/Autoconf). And at schools programming is some sorts
of algorithmic problem solving not industry oriented. So I request
explicitly tell these requirements anybody interested in porting, so that
they can get prepared.

I'm not quite sure what you are getting at here. I'm still of the opinion that a native port would be very hard indeed.

Yes, it would. But, when it comes to porting even a bright cs undergrad needs preparation. That is what I was talking about.

 

While solving a problem at SPOJ I just discovered few weeks back, you can't
declare an integer array of length 1000000 in C. :)

drkirkby@hawk:~$ cat test.c
#include <stdio.h>
int main(){
 int a[1000000];
}

drkirkby@hawk:~$ gcc test.c
drkirkby@hawk:~$ ./a.out

It still crashes on my XP at home and Fedora 14 at office.

 

By the way, I've a question. I've downloaded Sage source code. By the list
of tickets do you mean, they arise when one tries to compile this source
under cygwin?

You would need to try to compile the source and solve any problems. Then run the tests and solve them. Expect to come across some doggy code along the way.

Okay, thanks for your direction.

 

I seriously believe if one wanted a heavy maths program as a native Windows application, it would be best to start from scratch and not from the Sage source code. You would cherry-pick some of the libraries which are well written and portable, and reject code that is inherently unportable.

But it would be a huge undertaking, and I personally don't see how it could be done without an interested academic with serious funding for such a project.

I think you would be best to have

 * Separate front end to kernel, perhaps communicating via OpenMPI to allow multiple-kernels to be used for parallel processing.
 * Use libraries like mpfr, mpc, mpir but forget any code that does not have a well defined library interface. Also forget things like ATLAS which would be difficult to port.
 * GLR parser to understand Mathematica. Perhaps flex & bison could provide the parser.
 * A LOT of things I've not even thought about. Basically this would be a huge undertaking, and I doubt it's practical.

Dave 

You concerns are very pragmatic. But, let's where does it end. Sagemath's goal is very pragmatic too. Only if we got a native installer for it.

By the way, I'm reading Sagemath's documentation for developers. Probably, I'll maintain a blog [for fine tuned description of my works] and post here any of the hackish output by cygwin [if it's allowed].

Thank you very much again.

[Bill Hart]

OK, a very long post, so let's deal with the most important issue raised:

On 26 April 2011 15:03, Sazzad <sazzadb...@gmail.com> wrote:
>>>
>>> While solving a problem at SPOJ I just discovered few weeks back, you
>>> can't
>>> declare an integer array of length 1000000 in C. :)
>>
>> drkirkby@hawk:~$ cat test.c
>> #include <stdio.h>
>> int main(){
>>  int a[1000000];
>> }
>>
>> drkirkby@hawk:~$ gcc test.c
>> drkirkby@hawk:~$ ./a.out
>
> It still crashes on my XP at home and Fedora 14 at office.

Technically you are both correct, but it's all far more subtle than this.

The declaration int a[1000000]; means to set up an array of ints on
the stack. There is another way to declare arrays in C, which sets
them up on the heap:

int * a = malloc(1000000000*sizeof(int));

This works fine on my machine, as it has enough GB of ram. Indeed the
amount of free memory is basically your only restriction when using
the heap.

However, the stack space is limited.

Now the following works fine on my machine:

#include <stdio.h>

int main(void)
{
long a[2000000];

return 0;
}

But the reason for this is straightforward. You aren't putting
anything into that array. All that happens (if the compiler doesn't
optimise it away entirely) is that it moves the stack pointer
temporarily.

main:
subq $15999888, %rsp <- allocate about 2000000*8 bytes on
the stack by moving the stack pointer
movl $0, %eax <- set return value of function main
addq $15999888, %rsp <- put stack pointer back where it was
ret <- return from main

(I've compiled this with -fomit-frame-pointer to simplify it a bit,
and removed some canonical frame address guff, which I don't want to
explain.)

Note it doesn't quite allocate as much memory as you might imagine.
It's 112 bytes short. This is likely because above the stack is a
region which can be used in certain circumstances. For example,
somewhere above the stack is supposed to be a copy of the environment
and any command line arguments and the number of them. These days
there's a lot of security features in linux though, so your guess is
as good as mine.

Anyhow, now contrast this with the following program:

#include <stdio.h>

int main(void)
{
long a[2000000] = {0};

return 0;
}

The assembly is as follows:

main:
subq $16000008, %rsp <- allocate 2000000*8 bytes + extra 8 bytes
movq %rsp, %rax <- put address of this new buffer into rax
movl $16000000, %edx <- put size of buffer into edx as an
argument for memset
movl $0, %esi <- put 0 (value to write) into
esi as an argument for memset
movq %rax, %rdi <- move that rax value into rdi as
an argument for memset
call memset <- call memset (ptr to buffer,
0, 16000000)
movl $0, %eax <- return value 0 for main
addq $16000008, %rsp <- put stack pointer back
ret <- return from main

I don't know what the extra 8 bytes is for.

As you can see, this program actually writes data into the stack.

When this code is run on my machine, it segfaults. The stack
overflows. In fact, even with 1200000 as the size of the array it
still segfaults.

Here's another way to overflow the stack:

#include <stdio.h>

long fac(long n)
{
if (n == 1)
return 1;
return n * fac(n-1);
}

int main(void)
{
printf("%ld\n", fac(300000));
return 0;
}

Each time fac calls itself, 24 bytes gets allocated on the stack for
the value of n. This has to be saved somewhere during the recursive
call to fac so that when it returns it can be multiplied by fac(n-1).
I don't know why 24 bytes are reserved rather than 8. I think this is
because the stack has to remain aligned somehow.

Anyhow, when the recursive call is made to fac, the return address has
to be saved on the stack so that the function will come back from the
call. That's another 8 bytes.

So 32 bytes get used in total for every call to fac. Now, as there
will be 300000 recursive calls to fac, a total of 300000*32 = 9600000
bytes of stack space are used.

Of course the precise amount of stack space available to a process is
platform dependent. So in general allocating large amounts of space on
the stack is unwise. One should always use the heap for big
allocations.

Bill.

[Sazzad]

@Bill : Superb! I didn't know that. :P

[Sazzad]

By the way, Simon is an extraordinary speaker! Thanks for those links too.

[RegB]

Having waded through this thread yet again I am left with a distinct
impression that;
a) Cygwin is too much of a moving target to catch up with.
b) Cygwin, if ever "caught up with" would continue to move in ways
that couldn't be sync'd to.
c) Freezing releases of Cygwin and packaging Sage them with them as
"known quantities" is impractical.
d) MS Windows has SO MANY other problems as a development platform
ANYWAY that a native port is impractical.
These lead me to believe that Sage on Windows (other than in virtual
machines running Linux) will never be.
{Never say "never"; lets say "is incredibly unlikely to ever be" ?}

I have a minor problem understanding how the Cygwin moving target is
SO DIFFERENT from the
many Linux distribution moving targets.
A lot of those are also available as very small bases that pull down
the "latest and greatest" versions
of what they build for installs - same/similar in principle.

In lay terms.... do those just have a more consistent and predictable
"interface" ?
Again, in naive terms; Isn't Cygwin supposedly an X-Windows interface
to MS Windows ?
Kinda/Sorta (-:

On May 3, 4:51 am, Sazzad <sazzadbinka...@gmail.com> wrote:
> By the way, Simon is an extraordinary speaker! Thanks for those links too.
>

[Bill Hart]

I don't personally think there are huge issues "catching up" with
Cygwin. Sage almost did that and I believe people have had Sage
working on Cygwin. In fact, I suspect Sage moves more than Cygwin
does.

The issue is surely more one of manpower. One needs a community of
volunteers to maintain Cygwin support in Sage, as with any other OS.
The big issue here is most software developers using Windows don't
seem to be developing software with Cygwin (if they develop software
for Windows at all). So you can't expect a community of Windows
developers to commit their time to this. But nor do you expect a
community of Linux developers to commit their time either, as there is
little in it for them, as they use Linux and don't need a Windows port
to get their daily job done.

One problem with Cygwin is that it takes so long to build Sage. That's
not a problem for users if they download binaries. But it does make
maintaining Cygwin support a little painful. Cygwin is also 32 bits
only and there are occasionally other performance issues. These issues
put at least some people off working on a Cygwin Sage, even if they
aren't important issues for most users.

There's also the fact that the other ways of running Sage on Windows
boxes have been more successful.

My own perspective on the Windows port issue has changed with time. At
one point I felt that nothing but a native port of Sage to Windows
using MSVC would do. My reasoning for this is due to the fact that
there is a community of Windows developers who use MSVC.

But since that time I've come to think of this a different way. The
main reason MSVC developers would want to have a native port of Sage
is so that the libraries that are built can be linked to from MSVC. In
other words, it is Sage as a distribution of Open Source software that
is important from this perspective, not Sage as a "CAS".

But the former can be achieved by porting C/C++ libraries to build
with MinGW then distributing Windows library binaries, which is the
Windows way of doing things anyway. Of course with the current
manpower levels, getting a full port of the whole of Sage to MinGW is
out of reach. Sage itself would have to change too much and it would
probably be too much effort to ask Sage developers to support MinGW at
every step. It would slow the whole of Sage development down.

Anyhow, that is just my personal perspective, highly coloured by the
fact that I do not use the Python front end of Sage very often. But I
do link to the C/C++ libraries built as part of Sage quite often. My
use case is obviously a minority use case. When most people think of
Sage, they think of the Python library. So please do take what I say
with a grain of salt, and understand it comes from a completely
different perspective.

Bill.

[kcrisman]

On Jun 17, 11:53 am, Bill Hart <goodwillh...@googlemail.com> wrote:
> I don't personally think there are huge issues "catching up" with
> Cygwin. Sage almost did that and I believe people have had Sage
> working on Cygwin. In fact, I suspect Sage moves more than Cygwin
> does.
>

In general this is the problem. However, right now Maxima won't build
for anyone (not just Sage) with ECL on Cygwin. Just FYI.

[Dr. David Kirkby]

On 06/17/11 03:45 PM, RegB wrote:
> Having waded through this thread yet again I am left with a distinct
> impression that;
> a) Cygwin is too much of a moving target to catch up with.

I don't believe that.

> b) Cygwin, if ever "caught up with" would continue to move in ways
> that couldn't be sync'd to.

I'm not convinced that is true either.

> c) Freezing releases of Cygwin and packaging Sage them with them as
> "known quantities" is impractical.

I was the one that proposed (c), if (a) or (b) were considered problems. I
really don't see why (c) should be so difficult, but I don't believe (a) or (b)
are significant barriers to a port of Sage to Cygwin.

We could easily get a version of Cygwin which downloads from a mirror at
sagemath, so the versions of the packages are fixed.

> d) MS Windows has SO MANY other problems as a development platform
> ANYWAY that a native port is impractical.

I doubt there is anything in Sage that was initially designed to work in
Windows. Although Python was aimed to be portable from the start, the first
released never worked on Windows.

Maxima and R both existed long before Windows, but there are good Windows ports
of those programs.

But much of the rest of Sage was never written for Windows, and would be hard to
port natively. I suspect about 100 man years myself.

Some of the code in Sage is very flaky which does not help.

> These lead me to believe that Sage on Windows (other than in virtual
> machines running Linux) will never be.
> {Never say "never"; lets say "is incredibly unlikely to ever be" ?}

I think its quite doable. I suspect I could do it myself IF I put my mind to it.
I've written portable software, and arguably done more than anyone else in
getting Sage running on Solaris.

But I have the problem Bill alludes too - lack of motivation. My motivation to
complete ports of Sage to AIX or HP-UX is low, but for Cygwin it is even lower.

> I have a minor problem understanding how the Cygwin moving target is
> SO DIFFERENT from the
> many Linux distribution moving targets.

I think the reason you have a problem understanding how the Cygwin moving target
is different from the Linux moving target is that there really is NO SIGNIFICANT
DIFFERENCE.

In fact, whilst Ubuntu might put out a new release every 6 months or so, if you
update the system regularly you probably get more changes than you would with
Cygwin over the same period.

> A lot of those are also available as very small bases that pull down
> the "latest and greatest" versions
> of what they build for installs - same/similar in principle.

I'm not following you there.

> In lay terms.... do those just have a more consistent and predictable
> "interface" ?

I'm not following you there either

> Again, in naive terms; Isn't Cygwin supposedly an X-Windows interface
> to MS Windows ?

No.

> Kinda/Sorta (-:

Well, I would not even say Kinda/Sorta

Dave

[William Stein]

Yep. And historical this kind of _crap_ has been a problem with
Cygwin repeatedly. Back in 2005/2006 I had major trouble with
supporting (a much smaller) version of Sage on Cygwin because they
totally broke building extensions for Python on Cygwin. This was
horrible, and it took at least 8 months of pestering before the Cygwin
devs would acknowledge their bug and fix it.

Cygwin is a frustrating moving target. Only people who haven't tried
to keep complicated software working on Cygwin over a period of time
would disagree.

-- William

>
> --
> You received this message because you are subscribed to the Google Groups "sage-windows" group.
> To post to this group, send email to sage-w...@googlegroups.com.
> To unsubscribe from this group, send email to sage-windows...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sage-windows?hl=en.
>
>

--

[William Stein]

On Fri, Jun 17, 2011 at 11:39 AM, William Stein <wst...@gmail.com> wrote:
> On Fri, Jun 17, 2011 at 9:15 AM, kcrisman <kcri...@gmail.com> wrote:
>>
>>
>> On Jun 17, 11:53 am, Bill Hart <goodwillh...@googlemail.com> wrote:
>>> I don't personally think there are huge issues "catching up" with
>>> Cygwin. Sage almost did that and I believe people have had Sage
>>> working on Cygwin. In fact, I suspect Sage moves more than Cygwin
>>> does.
>>>
>>
>> In general this is the problem.  However, right now Maxima won't build
>> for anyone (not just Sage) with ECL on Cygwin.  Just FYI.
>
> Yep.  And historical this kind of _crap_ has been a problem with
> Cygwin repeatedly.  Back in 2005/2006 I had major trouble with
> supporting (a much smaller) version of Sage on Cygwin because they
> totally broke building extensions for Python on Cygwin.  This was
> horrible, and it took at least 8 months of pestering before the Cygwin
> devs would acknowledge their bug and fix it.
>
> Cygwin is a frustrating moving target.  Only people who haven't tried
> to keep complicated software working on Cygwin over a period of time
> would disagree.

That sounded overly negative. Despite all that, I'm certain we could
have a version of Sage for Cygwin that stays maintained, if enough
people would actually put in the effort...

-- William

[kcrisman]

On Jun 17, 3:02 pm, William Stein <wst...@gmail.com> wrote:
> On Fri, Jun 17, 2011 at 11:39 AM, William Stein <wst...@gmail.com> wrote:

> > On Fri, Jun 17, 2011 at 9:15 AM, kcrisman <kcris...@gmail.com> wrote:
>
> >> On Jun 17, 11:53 am, Bill Hart <goodwillh...@googlemail.com> wrote:
> >>> I don't personally think there are huge issues "catching up" with
> >>> Cygwin. Sage almost did that and I believe people have had Sage
> >>> working on Cygwin. In fact, I suspect Sage moves more than Cygwin
> >>> does.
>
> >> In general this is the problem.  However, right now Maxima won't build
> >> for anyone (not just Sage) with ECL on Cygwin.  Just FYI.
>
> > Yep.  And historical this kind of _crap_ has been a problem with
> > Cygwin repeatedly.  Back in 2005/2006 I had major trouble with
> > supporting (a much smaller) version of Sage on Cygwin because they
> > totally broke building extensions for Python on Cygwin.  This was
> > horrible, and it took at least 8 months of pestering before the Cygwin
> > devs would acknowledge their bug and fix it.
>
> > Cygwin is a frustrating moving target.  Only people who haven't tried
> > to keep complicated software working on Cygwin over a period of time
> > would disagree.
>
> That sounded overly negative.  Despite all that, I'm certain we could
> have a version of Sage for Cygwin that stays maintained, if enough
> people would actually put in the effort...
>

See my recent email. Juanjo suggests using the mingw Maxima in Cygwin
as a 'drop-in' replacement. If it works on a technical basis, then
the other things are surmountable. Now that Mike showed me how to do
it, I'm going to try to help with this, on XP at least.

- kcrisman

[Bill Hart]

On 17 June 2011 20:02, William Stein <wst...@gmail.com> wrote:
> On Fri, Jun 17, 2011 at 11:39 AM, William Stein <wst...@gmail.com> wrote:
>> On Fri, Jun 17, 2011 at 9:15 AM, kcrisman <kcri...@gmail.com> wrote:
>>>
>>>
>>> On Jun 17, 11:53 am, Bill Hart <goodwillh...@googlemail.com> wrote:
>>>> I don't personally think there are huge issues "catching up" with
>>>> Cygwin. Sage almost did that and I believe people have had Sage
>>>> working on Cygwin. In fact, I suspect Sage moves more than Cygwin
>>>> does.
>>>>
>>>
>>> In general this is the problem.  However, right now Maxima won't build
>>> for anyone (not just Sage) with ECL on Cygwin.  Just FYI.
>>
>> Yep.  And historical this kind of _crap_ has been a problem with
>> Cygwin repeatedly.  Back in 2005/2006 I had major trouble with
>> supporting (a much smaller) version of Sage on Cygwin because they
>> totally broke building extensions for Python on Cygwin.  This was
>> horrible, and it took at least 8 months of pestering before the Cygwin
>> devs would acknowledge their bug and fix it.
>>
>> Cygwin is a frustrating moving target.  Only people who haven't tried
>> to keep complicated software working on Cygwin over a period of time
>> would disagree.
>
> That sounded overly negative.  Despite all that, I'm certain we could
> have a version of Sage for Cygwin that stays maintained, if enough
> people would actually put in the effort...
>

Well, at least flint2 should work with Cygwin (I have built it on
Cygwin), and MPIR certainly does (thanks to Jason Moxham). So that's
about 1% of Sage ready for the future. (Well, no doubt Windows 8 will
break everything for everyone....) The latest SBCL is nearly working
on Windows 32 by the way. No Windows 64 in sight. Also still sans
documentation on how to embed it.

Bill.

[Bill Hart]

You aren't going to make MinGW another dependency to build Sage on
Cygwin are you? It's worrying that Juanjo considers this bug in Cygwin
to be so severe it can't be worked around!

Bill.

[kcrisman]

> >> That sounded overly negative.  Despite all that, I'm certain we could
> >> have a version of Sage for Cygwin that stays maintained, if enough
> >> people would actually put in the effort...
>
> > See my recent email.  Juanjo suggests using the mingw Maxima in Cygwin
> > as a 'drop-in' replacement.  If it works on a technical basis, then
> > the other things are surmountable.  Now that Mike showed me how to do
> > it, I'm going to try to help with this, on XP at least.
>
> You aren't going to make MinGW another dependency to build Sage on
> Cygwin are you? It's worrying that Juanjo considers this bug in Cygwin
> to be so severe it can't be worked around!

No, I think that what would happen is that we would have to use a
prebuilt one or something. I'm not sure - Juanjo is working on some
details for a different possible fix, but one that may or may not
actually be possible. We'll see.

[Bill Hart]

Ok cool. He's the expert and the right guy for the job.

Bill.

[Dr. David Kirkby]

I don't see a problem in making MinGW a dependency to build on Cygwin, in much
the same as gcc is required on Solaris, OS X and Linux.

It would be crazy to include it as part of the Sage tarball though.

[Bill Hart]

On 17 June 2011 23:52, Dr. David Kirkby <david....@onetel.net> wrote:
> On 06/17/11 11:06 PM, Bill Hart wrote:
>>
>> On 17 June 2011 20:05, kcrisman<kcri...@gmail.com>  wrote:
>
>> You aren't going to make MinGW another dependency to build Sage on
>> Cygwin are you? It's worrying that Juanjo considers this bug in Cygwin
>> to be so severe it can't be worked around!
>>
>> Bill.
>
> I don't see a problem in making MinGW a dependency to build on Cygwin, in
> much the same as gcc is required on Solaris, OS X and Linux.
>
> It would be crazy to include it as part of the Sage tarball though.
>

The problem I have is it is a massive kludge that should only be a
last resort when every other option has been exhausted. Adding
complexity to software makes it less and less maintainable.

Removing the dependecncy on Maxima altogether seems better to my way
of thinking. But I certainly don't have the skills to do that. I
assume the Risch integration algorithm is used? It has a nice 100+
page summary somewhere.

Bill.

[Dima Pasechnik]

On Jun 17, 7:39 pm, William Stein <wst...@gmail.com> wrote:

> On Fri, Jun 17, 2011 at 9:15 AM, kcrisman <kcris...@gmail.com> wrote:
>
> > On Jun 17, 11:53 am, Bill Hart <goodwillh...@googlemail.com> wrote:
> >> I don't personally think there are huge issues "catching up" with
> >> Cygwin. Sage almost did that and I believe people have had Sage
> >> working on Cygwin. In fact, I suspect Sage moves more than Cygwin
> >> does.
>
> > In general this is the problem.  However, right now Maxima won't build
> > for anyone (not just Sage) with ECL on Cygwin.  Just FYI.

well, ECL itself does not build on Cygwin on Windows 7...

>
> Yep.  And historical this kind of _crap_ has been a problem with
> Cygwin repeatedly.  Back in 2005/2006 I had major trouble with
> supporting (a much smaller) version of Sage on Cygwin because they
> totally broke building extensions for Python on Cygwin.  This was
> horrible, and it took at least 8 months of pestering before the Cygwin
> devs would acknowledge their bug and fix it.
>
> Cygwin is a frustrating moving target.  Only people who haven't tried
> to keep complicated software working on Cygwin over a period of time
> would disagree.

Having spent some time on Sage Cygwin port and on Cygwin mainling list
recently,
I have a feeling that Cygwin project is not coping well with the
recent Windows versions.
The latter have the ASLR in place, which makes the life of Cygwin's
fork implementation
very hard.

People write to the Cygwin list complaining about fork-related issues,
and do not get real fixes,
only some ad hoc advice.
Presently, Cygwin's fork is not guaranteed to succeed, and there is no
reliable way around it.
(see e.g. http://cygwin.com/ml/cygwin/2011-03/msg00187.html)

Thus I am no convinced that Sage Cygwin port will be reliable enough,
at least not for the precent Cygwin.

Dima

>
>  -- William
>
>
>
> > --
> > You received this message because you are subscribed to the Google Groups "sage-windows" group.
> > To post to this group, send email to sage-w...@googlegroups.com.
> > To unsubscribe from this group, send email to sage-windows...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/sage-windows?hl=en.

[Bill Hart]

That's a very interesting insight. Do you know if MinGW is
qualitatively different with regard to fork behaviour?

I still think a port of Sage to MinGW would be too much work. But I'm
interested to know if similar problems might be inevitable if using
GCC.

Bill.

[kcrisman]

> > > In general this is the problem.  However, right now Maxima won't build
> > > for anyone (not just Sage) with ECL on Cygwin.  Just FYI.
>
> well, ECL itself does not build on Cygwin on Windows 7...

But see
http://sourceforge.net/mailarchive/forum.php?thread_name=BANLkTi%3D-aq8MA8XjZz_LuL-rso4-OkBEBg%40mail.gmail.com&forum_name=ecls-list

where Juanjo has decided to do something different on Cygwin to avoid
fork. I do not understand enough of the technicalities to say for
sure if this is a solution, but it sounds like good news.

>
> Having spent some time on Sage Cygwin port and on Cygwin mainling list
> recently,
> I have a feeling that Cygwin project is not coping well with the
> recent Windows versions.
> The latter have the ASLR in place, which makes the life of Cygwin's
> fork implementation
> very hard.
>
> People write to the Cygwin list complaining about fork-related issues,
> and do not get real fixes,
> only some ad hoc advice.
> Presently, Cygwin's fork is not guaranteed to succeed, and there is no
> reliable way around it.
> (see e.g.http://cygwin.com/ml/cygwin/2011-03/msg00187.html)
>

Let's hope that this is a good enough workaround for Sage, at least.

[Bill Hart]

On Wednesday, 22 June 2011, Dima Pasechnik <dim...@gmail.com> wrote:
>
>

That's a very interesting insight. Do you know if MinGW is

qualitatively different with regard to fork behaviour?

I still think a port of Sage to MinGW would be too much work. But I'm
interested to know if similar problems might be inevitable if using
GCC.

Bill.

>

[Dima Pasechnik]

On Jun 22, 3:39 pm, Bill Hart <goodwillh...@googlemail.com> wrote:

> > (see e.g.http://cygwin.com/ml/cygwin/2011-03/msg00187.html)

>
> > Thus I am no convinced that Sage Cygwin port will be reliable enough,
> > at least not for the precent Cygwin.
>
> That's a very interesting insight. Do you know if MinGW is
> qualitatively different with regard to fork behaviour?

MinGW simply does not provide fork(), full stop.
One has to work around this limitation.

>
> I still think a port of Sage to MinGW would be too much work. But I'm
> interested to know if similar problems might be inevitable if using
> GCC.

Nothing bad with GCC per se. It's just a particular POSIX function,
fork(), is hard
to implement right on Windows Vista, Windows 7 and its contemporaries,
and Cygwin
is not doing it quite right at the moment.
I know that Python people have ways around it, using subprocesses
(cf. e.g. http://stackoverflow.com/questions/765129/hows-python-multiprocessing-implemented-on-windows)

>
> Bill.
>
>
> > Dima
>
> >>  -- William
>
Dima

[Dima Pasechnik]

On Jun 22, 3:39 pm, kcrisman <kcris...@gmail.com> wrote:
> > > > In general this is the problem.  However, right now Maxima won't build
> > > > for anyone (not just Sage) with ECL on Cygwin.  Just FYI.
>
> > well, ECL itself does not build on Cygwin on Windows 7...
>

> But see http://sourceforge.net/mailarchive/forum.php?thread_name=BANLkTi%3D-a...

>
> where Juanjo has decided to do something different on Cygwin to avoid
> fork.  I do not understand enough of the technicalities to say for
> sure if this is a solution, but it sounds like good news.

It does sound like bad news, on a larger scheme of things.
It sounds as if all the occurrences of fork in Sage have to be
worked around!

[Bill Hart]

Ah, very interesting. I had assumed they'd have to have something to
allow the GNU toolchain to do builds, which for some reason I thought
made extensive use of fork. But posix is simply something I know
nothing about. Thanks for the info.

> One has to work around this limitation.
>
>>
>> I still think a port of Sage to MinGW would be too much work. But I'm
>> interested to know if similar problems might be inevitable if using
>> GCC.
>
> Nothing bad with GCC per se. It's just a particular POSIX function,
> fork(), is hard
> to implement right on Windows Vista, Windows 7 and its contemporaries,
> and Cygwin
> is not doing it quite right at the moment.
> I know that Python people have ways around it, using subprocesses
> (cf. e.g. http://stackoverflow.com/questions/765129/hows-python-multiprocessing-implemented-on-windows)
>
>>
>> Bill.
>>
>>
>> > Dima
>>
>> >>  -- William
>>
> Dima
>