On Fri, Jan 1, 2010 at 2:46 PM, Dr. David Kirkby
<david.kir...@onetel.net> wrote:
> William Stein wrote:
>> On Fri, Jan 1, 2010 at 9:04 AM, Dr. David Kirkby
>> <david.kir...@onetel.net> wrote:
>>> William Stein wrote:
>>>
>>>> Unfortunately, there is no native port of Sage to Microsoft Windows (I
>>>> wish there were).  So you can't use it from .NET.
>>>>
>>>>  -- William
>>> Is that situation changing?
>>
>> Not lately.
>
> Shame. As much as I do not like to admit it, a Windows version would
> dramatically increase the user base.
>
> That said, tech savvy people who are thinking of running Sage are more likely 
> to
> use OS X, Linux, Solaris than the average PC user.
>
> But still, a large number of tech savvy people only use Windows.
>
>>> I was under the impression Microsoft were sponsoring
>>> a port, but I've not heard much about it.
>>
>> 2 years ago Microsoft sponsored part-time work on a port for a year.
>
> There was never a hope in hells chance with that.
>
> To get ALL of the functionality of Sage, the time is going to be several man
> years - probably 10 to 30 of them. A more limited subset of functionality 
> would
> take less time of course.
>
> If people can run some parts of Sage, but it pops up with the occasional:
>
> "Sorry, that functionality is not available in the native Windows version of
> Sage. Please use Linux, Solaris or Install VirtulBox on your PC and download 
> an
> image from ..."
>
> A limited sub set of the full functionality:
>
> 1) May be sufficient for many users.
>
> 2) Might get them wanting more, and so upgrade.
>
> Shareware software was often like that. You get some functionality free, but 
> you
> paid for the rest. Well in this case, they don't pay money, but they have to 
> pay
> with a bit of effort to install Linux, Solaris or VirtualBox, plus learn to 
> use
> Linux/Unix.
>
>
>
>>> Knowing the hurdles to overcome in porting Sage to Solaris, I would imagine
>>> those hurdles are much larger to port to Windows. However, with a larger 
>>> user
>>> base, perhaps you can attract more developers, so a port is easier.
>>
>> That appears to not be the case.   After 3-4 years of
>> waiting/trying/encouraging, I'm pretty sure the only way Sage will
>> ever get ported to Windows is if me and Mike Hansen just do it
>> ourselves.
>
> I'd go for the limited subset approach.

The Cygwin-based port will provide all functionality, not a limited
subset.  As an estimate of difficulty: I'm confident Mike Hansen and I
working fulltime for one month could complete it.  It would have been
finished already if good people were working on it.   Just to back up
that claim, consider:

  (1)  For most of 2005 and 2006,  Gary Zablackis distributed a
Cygwin-based version of Sage, complete with a nice automated 1-click
.msi installer.   Unfortunately, Gary stopped working on this in
mid-2006 so it languished.  Gary was exceptionally capable, in that he
actually understood the internals of Cygwin1.dll, and wasn't afraid to
dive in, hack stuff in there, report bugs to the Cygwin dev's. etc.
Once a new version of Cygwin1.dll completeley broke robustly building
Python C extensions, and Gary had a huge argument with the Cygwin devs
about this (he was right about the technical issues).

  (2) In Jan 2007, I spent one solid week and redid a port of Sage to
Cygwin, which people used for a while around then.   I was motivated
by an upcoming visit to Microsoft to give a talk.

  (3) The Cygwin port was killed around March 2007 mainly because of
libSingular.  More precisely I'll take responsibility -- I made a bad
choice to let libSingular into Sage without the portability issues
that it caused on Cygwin being resolved.

  (4) The Cygwin port has stayed dead for almost two years, from March
2007 until now, while much new functionality has been added to Sage,
thus making the port even harder.  (It's possible this was because a
certain Sage developer staked out doing a Windows port as "his
terrain".)    On the other hand, the build system and code in Sage has
been made more portable and is better understood, due to porting to OS
X 64-bit, Solaris, etc., so maybe the port is easier now.

  (5) In the meantime, Cygwin itself has certainly got much better.
For example, they just did a new release that evidently greatly
improves their fork system call, which is highly relevant for Sage.

---------

For a full native MSVC-based port, a limited subset of functionality
is perhaps more realistic, and might be the approach we're already
following.   However, note that creating a version of Sage with
"limited functionality" is actually very, very difficult, and requires
exceptional knowledge of Sage, Python/Cython programming, and a wide
range of areas of advanced mathematics.  The different parts of
mathematics are actually highly interrelated.

 -- William

-- 
To post to this group, send email to sage-support@googlegroups.com
To unsubscribe from this group, send email to 
sage-support+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org

Reply via email to