How practical/useful would a native windows subset be?

[Dr. David Kirkby (Kirkby Microwave Ltd)]

It seems Sage really could do with a native windows port. I am wondering
how practical it would be to make a version which is a subset of Sage, with
something like Qt which runs on Windows, Linux, OSX and Solaris and has
the look and feel of those platforms.

It could make a Google Summer of Code project.

If a small subset could be implemented, the chances are reasonable that
others might port more bits. If it could do more than a scientific
calculator, that would probably be enough to get people using it. Call it
"Mini Sage" or something similar to indicate it is not the full version.

I believe that there are some are some bits of Sage that uses fork and has
have no Windows equivalent, so those bits could be left out. Perhaps at a
later date a complete rewrite of such bits could form other GSOC projects.

The download size of such a subset would be smaller than the full version
and MUCH smaller that a virtual machine image, as one doesn't need to
include a complete operating system too.

Wolfram Research did at one point offer a subset of Mathematica, which i
think was called Calc Centre, but I think it was a bit of a flop, so I
don't think that they sell it any more. That might be an argument for not
doing a partial native port.

If a partial port was done, avoiding the need for a browser, one could use
its own parser and provide a more confident interface. Although many are
critical of Mathematica's interface, it is more consistent than that of
Sage.

Dave

[maldun]

Hi!

Python XY ( https://code.google.com/p/pythonxy/ )and WinPython
(http://winpython.sourceforge.net/) do this for years now and are working
properly. Maybe one can use this as a start since many of the needed
prequisites are there.

but why not concentrate on a working cygwin port, and bundle everything to
a working standalone executable? This would avoiding rewriting and
spliiting the code in several parts which would also need to be maintained
seperately.

On Monday, August 25, 2014 10:15:41 AM UTC+2, Dr. David Kirkby (Kirkby

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
It seems Sage really could do with a native windows port. I am wondering
how practical it would be to make a version which is a subset of Sage, with
something like Qt which runs on Windows, Linux, OSX and Solaris and has
the look and feel of those platforms.
It could make a Google Summer of Code project.
If a small subset could be implemented, the chances are reasonable that
others might port more bits. If it could do more than a scientific
calculator, that would probably be enough to get people using it. Call it
"Mini Sage" or something similar to indicate it is not the full version.
I believe that there are some are some bits of Sage that uses fork and has
have no Windows equivalent, so those bits could be left out. Perhaps at a
later date a complete rewrite of such bits could form other GSOC projects.
The download size of such a subset would be smaller than the full version
and MUCH smaller that a virtual machine image, as one doesn't need to
include a complete operating system too.
Wolfram Research did at one point offer a subset of Mathematica, which i
think was called Calc Centre, but I think it was a bit of a flop, so I
don't think that they sell it any more. That might be an argument for not
doing a partial native port.
If a partial port was done, avoiding the need for a browser, one could use
its own parser and provide a more confident interface. Although many are
critical of Mathematica's interface, it is more consistent than that of
Sage.
Dave

[Dr. David Kirkby (Kirkby Microwave Ltd)]

Hi!
Python XY ( https://code.google.com/p/pythonxy/ )and WinPython (

http://winpython.sourceforge.net/) do this for years now and are working
properly. Maybe one can use this as a start since many of the needed
prequisites are there.

Yes, maybe.

but why not concentrate on a working cygwin port,

I think people been working on it for years and despite a lot of time and
effort spent on it, it has never been completed. I think there are a number
of reasons it has not been completed, but lack of effort is not one of
them.

Dave

[Jeroen Demeyer]

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
I think people been working on it for years and despite a lot of time
and effort spent on it, it has never been completed. I think there are a
number of reasons it has not been completed, but lack of effort is not
one of them.

I think Sage-on-Cygwin is fay more realistic than a pure native (even
stripped down) version of Sage. I you care about Windows, concentrate
your efforts on the Cygwin port.

[William A Stein]

Post by Jeroen Demeyer

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
I think people been working on it for years and despite a lot of time
and effort spent on it, it has never been completed. I think there are a
number of reasons it has not been completed, but lack of effort is not
one of them.

I think Sage-on-Cygwin is fay more realistic than a pure native (even
stripped down) version of Sage. I you care about Windows, concentrate your
efforts on the Cygwin port.

+1

And we actually did spend *months* of very hard work on such a "mini
sage" fully native approach to sage on windows, a few years ago (when
it was easier). It was a complete and total waste of time. Once
you understand the architecture of Sage, you see that even the most
basics parts of Sage are so intertwined that the amount of
dependencies (e.g., PARI, etc.,) that you need, make this approach
incredibly difficult. Really IPython + Sympy (say) *is* this "mini
sage", but to get from that to full native windows Sage is at least a
million dollar project....

Post by Jeroen Demeyer

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
The download size of such a subset would be smaller than the full version and MUCH smaller that a virtual machine image, as one doesn't need to include a complete operating system too.

That's not true. E.g., Puppy Linux is around 50MB, and is a complete
useful operating system. In fact, I used to build the Sage VM
(targeted at windows) using Puppy Linux years ago.

-- William

Post by Jeroen Demeyer
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
***@uw.edu

[Dr. David Kirkby (Kirkby Microwave Ltd)]

Post by William A Stein

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
The download size of such a subset would be smaller than the full version and MUCH smaller that a virtual machine image, as one doesn't need to include a complete operating system too.

That's not true. E.g., Puppy Linux is around 50MB, and is a complete
useful operating system. In fact, I used to build the Sage VM
(targeted at windows) using Puppy Linux years ago.
-- William

OK, but it still doesn't get around the problem one needs to install
VirtualBox, and the whole process of installing virtual machines is
really alien to a lot of Windows users.

Personally I find installing virtual machines quite easy and useful,
but it seems to be a barrier for some at least.

Dave

[William A Stein]

On Wednesday, August 27, 2014, Dr. David Kirkby (Kirkby Microwave Ltd) <

Post by Dr. David Kirkby (Kirkby Microwave Ltd)

Post by William A Stein

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
The download size of such a subset would be smaller than the full

version and MUCH smaller that a virtual machine image, as one doesn't need
to include a complete operating system too.

Post by William A Stein
That's not true. E.g., Puppy Linux is around 50MB, and is a complete
useful operating system. In fact, I used to build the Sage VM
(targeted at windows) using Puppy Linux years ago.
-- William

OK, but it still doesn't get around the problem one needs to install
VirtualBox, and the whole process of installing virtual machines is
really alien to a lot of Windows users.
Personally I find installing virtual machines quite easy and useful,
but it seems to be a barrier for some at least.
Dave

You are absolutely right about that! I'm.not arguing for VM's here - just
pointing out that disk space isn't a priori significantly worse because of
that approach.

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
<javascript:;>.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
***@uw.edu

[Dr. David Kirkby (Kirkby Microwave Ltd)]

Post by Jeroen Demeyer
I think Sage-on-Cygwin is fay more realistic than a pure native (even

stripped down) version of Sage. I you care about Windows, concentrate your
efforts on the Cygwin port.

Why has so much time been spent on it, without success?

William wrote in 2007 Sage would probably never be built on Cygwin

http://markmail.org/message/fapx25o3kqipdeg2

Then in 2010 described how he got it to build

https://groups.google.com/forum/m/#!topic/sage-windows/ygK1kJm9p9w

and while I can't find the post, I think William later expressed some
doubt whether it would ever work properly.

I am on my mobile phone now, so not too easy to browse the web, but I
pretty sure that the Cygwin port was due to be finished before the Solaris
port.

Maybe there's a case for a fresh start with more modest aims and a cleaner
interface.

Dave

[maldun]

There a reports on Trac that sage 5.9 worked fine on windows 7 64-Bit.
http://trac.sagemath.org/wiki/CygwinPort
So it is no science-fiction to say that sage on Cygwin is possible.
Indeed it will not come without some trouble and hard work.

On Monday, August 25, 2014 1:48:41 PM UTC+2, Dr. David Kirkby (Kirkby

Post by Jeroen Demeyer

Post by Jeroen Demeyer
I think Sage-on-Cygwin is fay more realistic than a pure native (even

stripped down) version of Sage. I you care about Windows, concentrate your
efforts on the Cygwin port.
Why has so much time been spent on it, without success?
William wrote in 2007 Sage would probably never be built on Cygwin
http://markmail.org/message/fapx25o3kqipdeg2
Then in 2010 described how he got it to build
https://groups.google.com/forum/m/#!topic/sage-windows/ygK1kJm9p9w
and while I can't find the post, I think William later expressed some
doubt whether it would ever work properly.
I am on my mobile phone now, so not too easy to browse the web, but I
pretty sure that the Cygwin port was due to be finished before the Solaris
port.
Maybe there's a case for a fresh start with more modest aims and a cleaner
interface.
Dave

[Dima Pasechnik]

--bcaec51b1b9968213b050172c4f7
Content-Type: text/plain; charset=UTF-8

Post by Jeroen Demeyer
I think Sage-on-Cygwin is fay more realistic than a pure native (even

stripped down) version of Sage. I you care about Windows, concentrate your
efforts on the Cygwin port.
Why has so much time been spent on it, without success?

cause M$ is unwilling to release specifications of kernel
calls needed to make a good modern implementation of fork().

It is a constant fight against a fundamentally shaky fork()
as implemented in Cygwin :-(

William wrote in 2007 Sage would probably never be built on Cygwin
http://markmail.org/message/fapx25o3kqipdeg2
Then in 2010 described how he got it to build
https://groups.google.com/forum/m/#!topic/sage-windows/ygK1kJm9p9w
and while I can't find the post, I think William later expressed some
doubt whether it would ever work properly.
I am on my mobile phone now, so not too easy to browse the web, but I
pretty sure that the Cygwin port was due to be finished before the Solaris
port.
Maybe there's a case for a fresh start with more modest aims and a cleaner
interface.

fresh or not, but Win64-only should probably be more doable.
And it would satisfy most of the current demand, IMHO.

Dave

[Francesco Biscani]

Post by Dima Pasechnik
cause M$ is unwilling to release specifications of kernel
calls needed to make a good modern implementation of fork().
It is a constant fight against a fundamentally shaky fork()
as implemented in Cygwin :-(

Is the fork() implementation in SUA shaky as well?

http://stackoverflow.com/questions/4243880/substitute-for-forking-in-windows
http://www.microsoft.com/en-us/download/details.aspx?id=2391

[Dima Pasechnik]

--089e0115ece08dd452050174a8ff
Content-Type: text/plain; charset=UTF-8

Post by Dima Pasechnik
cause M$ is unwilling to release specifications of kernel
calls needed to make a good modern implementation of fork().
It is a constant fight against a fundamentally shaky fork()
as implemented in Cygwin :-(

Is the fork() implementation in SUA shaky as well?
http://stackoverflow.com/questions/4243880/substitute-for-forking-in-windows
http://www.microsoft.com/en-us/download/details.aspx?id=2391

apparently it's better, but it's only supported on certain more
expensive versions of Windows 7 and Windows Server 2008.

to quote:

Supported Operating Systems: Windows Server 2008 R2; Windows 7 Enterprise;
Windows 7 Enterprise 64-bit edition; Windows 7 Ultimate; Windows 7 Ultimate
64-bit edition;

[kcrisman]

My understanding was that Cygwin 32 had been "solved", largely due to work
by JP, though perhaps feature creep and upgrades have changed that, and the
current status of Cygwin 64 is at http://trac.sagemath.org/wiki/Cygwin64Port

Among other tickets needing review for this:
MPIR upgrade - http://trac.sagemath.org/ticket/15015
IML tiny fix - http://trac.sagemath.org/ticket/14648
Something PPL related - http://trac.sagemath.org/ticket/16152
gf2x fixes - http://trac.sagemath.org/ticket/16152

JP's been doing an awesome job keeping things up-to-date as he can. If we
had a buildbot for Cygwin that would make things a lot easier of course.

[Jean-Pierre Flori]

My souvenir here is that Sage almost builds out of the box on Cygwin64
modulo some patches i posted in different tickets.
It is not really funcitonnal though, last time I tried it seemed to me that
Python itself was horribly broken.

Post by kcrisman
My understanding was that Cygwin 32 had been "solved", largely due to work
by JP, though perhaps feature creep and upgrades have changed that, and the
current status of Cygwin 64 is at
http://trac.sagemath.org/wiki/Cygwin64Port
MPIR upgrade - http://trac.sagemath.org/ticket/15015
IML tiny fix - http://trac.sagemath.org/ticket/14648
Something PPL related - http://trac.sagemath.org/ticket/16152
gf2x fixes - http://trac.sagemath.org/ticket/16152
JP's been doing an awesome job keeping things up-to-date as he can. If we
had a buildbot for Cygwin that would make things a lot easier of course.

[Francesco Biscani]

Post by Dima Pasechnik
apparently it's better, but it's only supported on certain more
expensive versions of Windows 7 and Windows Server 2008.
Supported Operating Systems: Windows Server 2008 R2; Windows 7 Enterprise;
Windows 7 Enterprise 64-bit edition; Windows 7 Ultimate; Windows 7 Ultimate
64-bit edition;

Ah bummer... I wonder if the version check is strict or if it can be worked
around somehow. Seems like at some point Debian had an Interix port:

http://www.debian-interix.net/

(As a side question, what versions of Windows are commonly found on
desktops/laptops these days? Are people switching over to Windows 8?)

There's quite a bit of material on how to write a replacement of fork()
using the Windows API. See, e.g.,

http://stackoverflow.com/questions/985281/what-is-the-closest-thing-windows-has-to-fork/985525#985525
http://doxygen.scilab.org/5.3/d0/d8f/forkWindows_8c_source.html#l00216

And it seems MinGW has the prototype for fork(), although not the
implementation:

http://stackoverflow.com/questions/9612315/why-does-my-compiler-not-accept-fork-despite-my-inclusion-of-unistd-h

Even if the implementation is not 100% conforming, it would probably be
adequate for some purposes. Is the lack of fork() the biggest showstopper
or just one of many roadblocks? I would imagine a lot of external
components included in sage are not written with platform independence in
mind (but IMO this would rather be an argument to work with upstream to
rectify the issue instead of working around it).

[Dima Pasechnik]

--089e013c6576f2ddd4050175975f
Content-Type: text/plain; charset=UTF-8

Post by Dima Pasechnik
apparently it's better, but it's only supported on certain more
expensive versions of Windows 7 and Windows Server 2008.
Supported Operating Systems: Windows Server 2008 R2; Windows 7 Enterprise;
Windows 7 Enterprise 64-bit edition; Windows 7 Ultimate; Windows 7 Ultimate
64-bit edition;

Ah bummer... I wonder if the version check is strict or if it can be worked
around somehow.

good luck doing this - you will need to provide a hack that does this
to be distributed with Sage :)

As well, SUA is deprecated in Windows 8, and won't be
supported beyond Windows 8.

http://www.debian-interix.net/
(As a side question, what versions of Windows are commonly found on
desktops/laptops these days? Are people switching over to Windows 8?)

some time ago retailers offered a choice of Windows 7 or 8, but I
guess this will stop sooner of later.
Anyhow, I've never seen a retailer offering a windows edition
other than Home or Pro.

There's quite a bit of material on how to write a replacement of fork()
using the Windows API. See, e.g.,
http://stackoverflow.com/questions/985281/what-is-the-closest-thing-windows-has-to-fork/985525#985525
http://doxygen.scilab.org/5.3/d0/d8f/forkWindows_8c_source.html#l00216
And it seems MinGW has the prototype for fork(), although not the
http://stackoverflow.com/questions/9612315/why-does-my-compiler-not-accept-fork-despite-my-inclusion-of-unistd-h
Even if the implementation is not 100% conforming, it would probably be
adequate for some purposes. Is the lack of fork() the biggest showstopper
or just one of many roadblocks? I would imagine a lot of external
components included in sage are not written with platform independence in
mind (but IMO this would rather be an argument to work with upstream to
rectify the issue instead of working around it).

GAP uses fork, mmap, and ioctl - none of which are supported by MinGW/MSYS.
Dunno about PARI and Singular.'

[Dima Pasechnik]

--089e01537eba8a9d2805016fca81
Content-Type: text/plain; charset=UTF-8
It seems Sage really could do with a native windows port. I am wondering
how practical it would be to make a version which is a subset of Sage, with
something like Qt which runs on Windows, Linux, OSX and Solaris and has
the look and feel of those platforms.

Sage components such as GAP, Singular, PARI/GP do not have native Windows ports.
Without them you'd better run IPython directly, it will provide you better
experience and roughly the same functionality.

[mmarco]

IIRC, GAP and Pari/GP do have a native windows version. Singular has a
cygwin version.

On 2014-08-25, Dr. David Kirkby (Kirkby Microwave Ltd) <

--089e01537eba8a9d2805016fca81
Content-Type: text/plain; charset=UTF-8
It seems Sage really could do with a native windows port. I am wondering
how practical it would be to make a version which is a subset of Sage,

with

something like Qt which runs on Windows, Linux, OSX and Solaris and

has

the look and feel of those platforms.

Sage components such as GAP, Singular, PARI/GP do not have native Windows ports.
Without them you'd better run IPython directly, it will provide you better
experience and roughly the same functionality.

[Jean-Pierre Flori]

Post by mmarco
IIRC, GAP and Pari/GP do have a native windows version. Singular has a
cygwin version.

On 2014-08-25, Dr. David Kirkby (Kirkby Microwave Ltd) <

--089e01537eba8a9d2805016fca81
Content-Type: text/plain; charset=UTF-8
It seems Sage really could do with a native windows port. I am

wondering

how practical it would be to make a version which is a subset of Sage,

with

something like Qt which runs on Windows, Linux, OSX and Solaris and

has

the look and feel of those platforms.

Sage components such as GAP, Singular, PARI/GP do not have native Windows ports.
Without them you'd better run IPython directly, it will provide you better

PARI/GP is definitely not native.

It is Cygwin or MinGW.
And PARI/GP was one of the big issues when Tim Abbott (? or someone else, I
don't really recall the discussions here) was aatempting to build Sage on
Windows.
Indeed they have some sizeof(long) = sizeof(void*) constraint which is more
than painful for a Windows port.

If you dig through the archive here, you may find that post and also get an
idea of what the other big obstacles were.

[Francesco Biscani]

Post by mmarco
PARI/GP is definitely not native.
It is Cygwin or MinGW.

MinGW and Cygwin are two completely different things. I don't know what you
mean with "native", but MinGW is as native on Windows as, e.g., the Intel
compiler is.

[Dima Pasechnik]

------=_Part_2559_2117096191.1408960189386
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
IIRC, GAP and Pari/GP do have a native windows version. Singular has a=20
cygwin version.

no, GAP does not have a native Windows version.
It has a prebuilt distribution for Windows with cygwin DLL bundled in.

I think native GAP port to Windows should be doable, but it still needs to be
done. It's not completely trivial.

El lunes, 25 de agosto de 2014 11:05:08 UTC+2, Dima Pasechnik escribi=C3=B3=

On 2014-08-25, Dr. David Kirkby (Kirkby Microwave Ltd) <

--089e01537eba8a9d2805016fca81=20
Content-Type: text/plain; charset=3DUTF-8=20
=20
It seems Sage really could do with a native windows port. I am wonderin=

g=20

how practical it would be to make a version which is a subset of Sage,=

=20

with=20

something like Qt which runs on Windows, Linux, OSX and Solaris and=

=20

has=20

the look and feel of those platforms.=20

Sage components such as GAP, Singular, PARI/GP do not have native Windows=

=20

ports.=20
Without them you'd better run IPython directly, it will provide you bette=

r=20

experience and roughly the same functionality.=20

--=20
You received this message because you are subscribed to the Google Groups "=
sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
------=_Part_2559_2117096191.1408960189386
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
IIRC, GAP and Pari/GP do have a native windows version. Singular has a cygw=
in version.<br><br>El lunes, 25 de agosto de 2014 11:05:08 UTC+2, Dima Pase=
chnik escribi=C3=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-0=
8-25, Dr. David Kirkby (Kirkby Microwave Ltd) &lt;<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"15NGl7oNS-cJ" onmousedown=3D"this=
.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';re=
<br>
<br>Sage components such as GAP, Singular, PARI/GP do not have native Windo=
ws ports.
<br>Without them you'd better run IPython directly, it will provide you bet=
ter
<br>experience and roughly the same functionality.
<br>
<br>
<br></blockquote>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;sage-devel&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
Visit this group at <a href=3D"http://groups.google.com/group/sage-devel">h=
ttp://groups.google.com/group/sage-devel</a>.<br />
For more options, visit <a href=3D"https://groups.google.com/d/optout">http=
s://groups.google.com/d/optout</a>.<br />
------=_Part_2559_2117096191.1408960189386--

[Julien Puydt]

Hi,

Post by Dima Pasechnik

--089e01537eba8a9d2805016fca81
Content-Type: text/plain; charset=UTF-8
It seems Sage really could do with a native windows port. I am wondering
how practical it would be to make a version which is a subset of Sage, with
something like Qt which runs on Windows, Linux, OSX and Solaris and has
the look and feel of those platforms.

Sage components such as GAP, Singular, PARI/GP do not have native Windows ports.
Without them you'd better run IPython directly, it will provide you better
experience and roughly the same functionality.

I don't understand why people insist on trying to build the windows port
on windows with cygwin ; it's also possible to cross-build windows ports :
http://wiki.ekiga.org/index.php/Building_Ekiga_for_Windows

Of course, that requires some sanitization of build systems, clean
sources, etc...

Snark on #sagemath

[Dr. David Kirkby (Kirkby Microwave Ltd)]

Post by Julien Puydt
I don't understand why people insist on trying to build the windows port

on windows with cygwin ; it's also possible to cross-build windows ports
I was mainly thinking of a C++ version with its own parser. If that used Qt
or wxWidgits it would be multi platform. It does need to use Python at all
initially - if ever.

I guess there is more than one way to approach it, but if one set out with
the aim of nothing much more than a decent scientific calculator, one
would not need to worry about porting things that are hard.

I would not think it too hard to generate a parser which is linked to the

* GMP
* MPFR
* GNU scientific library

which I would expect would compile with Qt or WxWidgets without too many
changes. If it used Qt, the code could be developed on virtually any
platform. Producing executables for many mobile phones, including Android
and Apple iPhone and iPad, Linux etc.

By only linking to code and not calling external command-line tools, it
should be possible to create a uniform interface, which is one of the
criticisms of Sage.

Dave

[William A Stein]

On Mon, Aug 25, 2014 at 1:27 PM, Dr. David Kirkby (Kirkby Microwave

Post by Dr. David Kirkby (Kirkby Microwave Ltd)

Post by Julien Puydt
I don't understand why people insist on trying to build the windows port
on windows with cygwin ; it's also possible to cross-build windows ports

I was mainly thinking of a C++ version with its own parser. If that used Qt
or wxWidgits it would be multi platform. It does need to use Python at all
initially - if ever.
I guess there is more than one way to approach it, but if one set out with
the aim of nothing much more than a decent scientific calculator, one would
not need to worry about porting things that are hard.
I would not think it too hard to generate a parser which is linked to the
* GMP
* MPFR
* GNU scientific library
which I would expect would compile with Qt or WxWidgets without too many
changes. If it used Qt, the code could be developed on virtually any
platform. Producing executables for many mobile phones, including Android
and Apple iPhone and iPad, Linux etc.
By only linking to code and not calling external command-line tools, it
should be possible to create a uniform interface, which is one of the
criticisms of Sage.

This reminds me of Michael Abshoff. He was supposed to port Sage to
Windows, and was also complaining about how horrible every component
of Sage was, and wanting to remove them. At one point, I wondered if
his eventual port would be something like:

int main(void) {
printf("sage: ");
/* etc., -- a simple REPL that does nothing */
}

More seriously, what you're describing definitely isn't Sage at all...

-- William
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
***@uw.edu

[Jean-Pierre Flori]

Post by William A Stein
This reminds me of Michael Abshoff. He was supposed to port Sage to
That was the name I was looking for I guess.

And one of the posts I was thinking of:
https://groups.google.com/d/msg/sage-devel/QXy_2KMbP1k/Z3cfpCieYzgJ

[Jeroen Demeyer]

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
I would not think it too hard to generate a parser which is linked to the
* GMP
* MPFR
* GNU scientific library
which I would expect would compile with Qt or WxWidgets without too many
changes. If it used Qt, the code could be developed on virtually any
platform.

And the result would be something like this:
Loading Image...

[Dr. David Kirkby (Kirkby Microwave Ltd)]

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
I would not think it too hard to generate a parser which is linked to the
* GMP
* MPFR
* GNU scientific library
which I would expect would compile with Qt or WxWidgets without too many
changes. If it used Qt, the code could be developed on virtually any
platform.

http://www.online-tech-tips.com/wp-content/uploads/2010/08/Windows7ScientificCalculatorMode_thumb.png

No it would be s lot better than the Windows scientific calculator you
refere to.

* It would have arbitrary precision in both FP and integer.
* All the functionality of the GSL - Bessel functions for example.
* Highly portable.

Dave.

[Dima Pasechnik]

Post by Julien Puydt
Hi,

Post by Dima Pasechnik

--089e01537eba8a9d2805016fca81
Content-Type: text/plain; charset=UTF-8
It seems Sage really could do with a native windows port. I am wondering
how practical it would be to make a version which is a subset of Sage, with
something like Qt which runs on Windows, Linux, OSX and Solaris and has
the look and feel of those platforms.

Sage components such as GAP, Singular, PARI/GP do not have native Windows ports.
Without them you'd better run IPython directly, it will provide you better
experience and roughly the same functionality.

I don't understand why people insist on trying to build the windows port
http://wiki.ekiga.org/index.php/Building_Ekiga_for_Windows
Of course, that requires some sanitization of build systems, clean
sources, etc...

Ekiga only does mingw(64/32) builds, but mingw does not provide enough
POSIX (no fork(), etc).
So the sources need to be worked on quite a bit...
(and native mingw builds aren't so problematic, in fact)

[Bill Hart]

I am again very interested in having Windows 64 ports of various packages.

At the top of my list are:

* GAP
* Singular
* Pari/GP

Note that MinGW2 is a much better way to do this than has previously been
available. It builds packages in a tiny fraction of the time it takes to
build with MinGW. It also fixes the broken parallel make that was in MinGW.
It has a nice package manager. The compiler seems stable. It 1000% better
in every way. In my opinion, a more or less native port of various packages
to MinGW2 is quite feasible.

Note that the flint library generated only two warnings with MSVC after we
got it building with MinGW2.

The biggest problem by far is the upstream projects who do not accept
patches into their repositories to support Windows, and aren't willing to
make the changes to their codebase to support Windows 64. Nor do they
continue to maintain the ports once it is done.

This attitude in the Open Source community to Windows 64 really bugs me.
It's a decade old technology, and not going anywhere.

A port of Sage to Windows 64 is probably not a viable project. It would
take years of effort by numerous individuals to accomplish. And it would
bitrot before it was even completed. But the fact that it isn't viable
right now doesn't mean that upstream projects shouldn't support Windows 64
so that if Sage ever wants to do such a port, it would be possible.

Five projects Sage doesn't have to worry about are:

* flint
* gmp/mpir
* mpfr
* gmp-ecm
* GNU Scientific library

They support Windows fully. In fact, these projects even build on MSVC
thanks to years of effort by Brian Gladman.

For those unfamiliar with what a port to native Windows means, here is a
description of the steps involved for an ANSI C project (it's slightly
easier to port C99 projects to MinGW2 than ANSI C, but the MSVC compiler
does not have full C99 support):

* Replace all occurrences of long and unsigned long with alternative types
(e.g. slong, ulong in flint or mp_limb_signed_t, mp_limb_t in GMP) since a
long is only 32 bits on 64 bit Windows

* Ensure memory allocations do not mix allocating pointers and words/limbs,
e.g. long * a =malloc(32*sizeof(long)); void ** b = (void **) a + 16;

* Replace all format specifiers for printf, scanf, fscanf, sscanf. This
usually implies creating a project_printf function, for example, which
accepts all the usual format specifiers, but provides new ones (e.g. %wd,
%wu) for printing e.g. slong and ulong on Windows. Then use the new
project_flintf/scanf, etc ubiquitously.

* Replace all integer constant literals, e.g. 123L with a macro, e.g.
WORD(123) which expands to 123L or 123LL depending on the platform. Similar
macro UWORD(123) for 123UL. Use ubiquitously.

* Place all code that requires posix functionality (pipes, etc) inside
guards so it is not built on Windows. If the functionality is important to
retain as part of the core functionality, Windows equivalents need to be
implemented. For mathematical software written in C, this is usually not
common. For other kinds of software, this can be a massive task.

* If you wish to support MSVC, some code may need to be ported from C99
back to ANSI C style. This is not as difficult nowadays as it used to be.
MSVC is about 90% of the way there now. They for example support mixing
declarations with other code, they have numerous C99 headers available and
so on.

* Replace intrinsics with Windows equivalents. Most of them exist on
Windows too, just with different names.

* Rewrite code which uses GNU C extensions. (This is not usually a big
project.)

Porting an assembly language project is quite a lot of work.

* There is no inline assembler in MSVC on 64 bit Windows. So there has to
be fallback C for this platform.

* Windows uses a different ABI for assembly functions than Linux, say. One
way around this is to write macros (such as the ones in GMP) which change
the order of registers on the way into and out of an assembly function
(only the ones actually used in the function). This is usually acceptable
because it doesn't affect any loops, except for perhaps moving them to
different alignments in memory. You can expect about a 5-10% slowdown with
this method. Given the scale of effort that would be required to rewrite
all the x86_64 assembly code in a project specially for Windows, this is an
acceptable compromise. (We use a different solution in MPIR. We have a lot
of our assembly code written in Yasm, which works on Linux and Windows. We
have separate assembly versions for many functions.)

* If you are porting to MSVC, you might like to support stack unwinding.
This is quite a bit of work, but Brian Gladman does it for example for
MPIR. It is my understanding that GMP doesn't do this, however I have not
checked recently to see if this is still the case.

Of course quite a lot of build system work may be necessary, even if using
Autotools, for either C or assembly projects. Some versions of Autotools
break the build on Windows, so you have to find a version which works on
that platform.

It's definitely much easier to port a project to Windows in four steps.
Linux -> Cygwin -> Cygwin 64 -> MinGW64 -> MSVC. The biggest step is from
Cygwin64 -> MinGW64. The last step is very easy nowadays. It can be done
for a medium sized project (150,000 lines of C code) in a couple of man
weeks, most of which is just fixing bugs that didn't show up on Linux/GCC.

I understand that Sage uses things like Lisp, Java, Python, Cython, etc. So
the above doesn't help much with Sage overall. But perhaps it will help
raise awareness for projects that are using C and assembly only.

Bill.

On Monday, 25 August 2014 10:15:41 UTC+2, Dr. David Kirkby (Kirkby

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
It seems Sage really could do with a native windows port. I am wondering
how practical it would be to make a version which is a subset of Sage, with
something like Qt which runs on Windows, Linux, OSX and Solaris and has
the look and feel of those platforms.
It could make a Google Summer of Code project.
If a small subset could be implemented, the chances are reasonable that
others might port more bits. If it could do more than a scientific
calculator, that would probably be enough to get people using it. Call it
"Mini Sage" or something similar to indicate it is not the full version.
I believe that there are some are some bits of Sage that uses fork and has
have no Windows equivalent, so those bits could be left out. Perhaps at a
later date a complete rewrite of such bits could form other GSOC projects.
The download size of such a subset would be smaller than the full version
and MUCH smaller that a virtual machine image, as one doesn't need to
include a complete operating system too.
Wolfram Research did at one point offer a subset of Mathematica, which i
think was called Calc Centre, but I think it was a bit of a flop, so I
don't think that they sell it any more. That might be an argument for not
doing a partial native port.
If a partial port was done, avoiding the need for a browser, one could use
its own parser and provide a more confident interface. Although many are
critical of Mathematica's interface, it is more consistent than that of
Sage.
Dave

[Bill Hart]

I forgot some for porting C:

* MSVC is a C++ compiler, so malloc must always be cast, e.g. ulong * a =
(ulong *) malloc(32*sizeof(ulong)); instead of ulong * a =
malloc(32*sizeof(ulong));

* Addition of C++ guards around headers

* Adding declspec(__dllexport__) in front of all prototypes in .h files

* Various additional linker options are needed to build a dll correctly on
Windows

* If the project will be linked from other projects, especially if you
intend to distribute binaries, you have to move libgcc_s and libpthread
inside the library, rather than allow it to use the system libraries for
this. Similar things often apply to GMP/MPIR as MinGW especially
distributes its own versions of these, which may not be compatible with
your project

* Windows is a case insensitive file system. This means that filenames must
be distinguishable under the constraints this implies. This can be
especially problematic during builds.

* MinGW doesn't seem to work well with paths containing spaces.

* Various header files are named differently on Windows.

Bill.

Post by Bill Hart
I am again very interested in having Windows 64 ports of various packages.
* GAP
* Singular
* Pari/GP
Note that MinGW2 is a much better way to do this than has previously been
available. It builds packages in a tiny fraction of the time it takes to
build with MinGW. It also fixes the broken parallel make that was in MinGW.
It has a nice package manager. The compiler seems stable. It 1000% better
in every way. In my opinion, a more or less native port of various packages
to MinGW2 is quite feasible.
Note that the flint library generated only two warnings with MSVC after we
got it building with MinGW2.
The biggest problem by far is the upstream projects who do not accept
patches into their repositories to support Windows, and aren't willing to
make the changes to their codebase to support Windows 64. Nor do they
continue to maintain the ports once it is done.
This attitude in the Open Source community to Windows 64 really bugs me.
It's a decade old technology, and not going anywhere.
A port of Sage to Windows 64 is probably not a viable project. It would
take years of effort by numerous individuals to accomplish. And it would
bitrot before it was even completed. But the fact that it isn't viable
right now doesn't mean that upstream projects shouldn't support Windows 64
so that if Sage ever wants to do such a port, it would be possible.
* flint
* gmp/mpir
* mpfr
* gmp-ecm
* GNU Scientific library
They support Windows fully. In fact, these projects even build on MSVC
thanks to years of effort by Brian Gladman.
For those unfamiliar with what a port to native Windows means, here is a
description of the steps involved for an ANSI C project (it's slightly
easier to port C99 projects to MinGW2 than ANSI C, but the MSVC compiler
* Replace all occurrences of long and unsigned long with alternative types
(e.g. slong, ulong in flint or mp_limb_signed_t, mp_limb_t in GMP) since a
long is only 32 bits on 64 bit Windows
* Ensure memory allocations do not mix allocating pointers and
words/limbs, e.g. long * a =malloc(32*sizeof(long)); void ** b = (void **)
a + 16;
* Replace all format specifiers for printf, scanf, fscanf, sscanf. This
usually implies creating a project_printf function, for example, which
accepts all the usual format specifiers, but provides new ones (e.g. %wd,
%wu) for printing e.g. slong and ulong on Windows. Then use the new
project_flintf/scanf, etc ubiquitously.
* Replace all integer constant literals, e.g. 123L with a macro, e.g.
WORD(123) which expands to 123L or 123LL depending on the platform. Similar
macro UWORD(123) for 123UL. Use ubiquitously.
* Place all code that requires posix functionality (pipes, etc) inside
guards so it is not built on Windows. If the functionality is important to
retain as part of the core functionality, Windows equivalents need to be
implemented. For mathematical software written in C, this is usually not
common. For other kinds of software, this can be a massive task.
* If you wish to support MSVC, some code may need to be ported from C99
back to ANSI C style. This is not as difficult nowadays as it used to be.
MSVC is about 90% of the way there now. They for example support mixing
declarations with other code, they have numerous C99 headers available and
so on.
* Replace intrinsics with Windows equivalents. Most of them exist on
Windows too, just with different names.
* Rewrite code which uses GNU C extensions. (This is not usually a big
project.)
Porting an assembly language project is quite a lot of work.
* There is no inline assembler in MSVC on 64 bit Windows. So there has to
be fallback C for this platform.
* Windows uses a different ABI for assembly functions than Linux, say. One
way around this is to write macros (such as the ones in GMP) which change
the order of registers on the way into and out of an assembly function
(only the ones actually used in the function). This is usually acceptable
because it doesn't affect any loops, except for perhaps moving them to
different alignments in memory. You can expect about a 5-10% slowdown with
this method. Given the scale of effort that would be required to rewrite
all the x86_64 assembly code in a project specially for Windows, this is an
acceptable compromise. (We use a different solution in MPIR. We have a lot
of our assembly code written in Yasm, which works on Linux and Windows. We
have separate assembly versions for many functions.)
* If you are porting to MSVC, you might like to support stack unwinding.
This is quite a bit of work, but Brian Gladman does it for example for
MPIR. It is my understanding that GMP doesn't do this, however I have not
checked recently to see if this is still the case.
Of course quite a lot of build system work may be necessary, even if using
Autotools, for either C or assembly projects. Some versions of Autotools
break the build on Windows, so you have to find a version which works on
that platform.
It's definitely much easier to port a project to Windows in four steps.
Linux -> Cygwin -> Cygwin 64 -> MinGW64 -> MSVC. The biggest step is from
Cygwin64 -> MinGW64. The last step is very easy nowadays. It can be done
for a medium sized project (150,000 lines of C code) in a couple of man
weeks, most of which is just fixing bugs that didn't show up on Linux/GCC.
I understand that Sage uses things like Lisp, Java, Python, Cython, etc.
So the above doesn't help much with Sage overall. But perhaps it will help
raise awareness for projects that are using C and assembly only.
Bill.
On Monday, 25 August 2014 10:15:41 UTC+2, Dr. David Kirkby (Kirkby

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
It seems Sage really could do with a native windows port. I am wondering
how practical it would be to make a version which is a subset of Sage, with
something like Qt which runs on Windows, Linux, OSX and Solaris and has
the look and feel of those platforms.
It could make a Google Summer of Code project.
If a small subset could be implemented, the chances are reasonable that
others might port more bits. If it could do more than a scientific
calculator, that would probably be enough to get people using it. Call it
"Mini Sage" or something similar to indicate it is not the full version.
I believe that there are some are some bits of Sage that uses fork and
has have no Windows equivalent, so those bits could be left out. Perhaps at
a later date a complete rewrite of such bits could form other GSOC
projects.
The download size of such a subset would be smaller than the full version
and MUCH smaller that a virtual machine image, as one doesn't need to
include a complete operating system too.
Wolfram Research did at one point offer a subset of Mathematica, which i
think was called Calc Centre, but I think it was a bit of a flop, so I
don't think that they sell it any more. That might be an argument for not
doing a partial native port.
If a partial port was done, avoiding the need for a browser, one could
use its own parser and provide a more confident interface. Although many
are critical of Mathematica's interface, it is more consistent than that
of Sage.
Dave

[Dr. David Kirkby (Kirkby Microwave Ltd)]

Post by Bill Hart
The biggest problem by far is the upstream projects who do not accept

patches into their repositories to support Windows, and aren't willing to
make the changes to their codebase to support Windows 64. Nor do they
continue to maintain the ports once it is done.

I can't say I have ever looked at it, but if true it is an odd attitude. I
found *generally* that upstream projects were happy to take Solaris
patches. A patch I made for GSL to run on AIX was accepted upstream.

I an no fan of Windows, but with so many programs only working on Windows,
or tested more on Windows, I see it as a necessary evil.

Post by Bill Hart
This attitude in the Open Source community to Windows 64 really bugs me.

It's a decade old technology, and not going anywhere.

Lots of open source programs run on Windows, and with Windows being more
and more 64 bit, they will either have to adapt or

Post by Bill Hart
A port of Sage to Windows 64 is probably not a viable project. It would

take years of effort by numerous individuals to accomplish. And it would
bitrot before it was even completed. But the fact that it isn't viable
right now doesn't mean that upstream projects shouldn't support Windows 64
so that if Sage ever wants to do such a port, it would be possible.

Post by Bill Hart
* flint
* gmp/mpir
* mpfr
* gmp-ecm
* GNU Scientific library

Maxima has a native Windows application, so that would work too. Maxims
uses ECL which is very portable.

Unfortunately, I don't think Maxima has a library interface, do once that
is added, any attempt to make a more consistent user interface would be
hampered.

Post by Bill Hart
I understand that Sage uses things like Lisp, Java, Python, Cython, etc.

So the above doesn't help much with Sage overall. But perhaps it will help
raise awareness for projects that are using C and assembly only.

Post by Bill Hart
Bill.

Call it "Mini Sage", foobar or something else, it appears to me a
significant subset of Sage could be built into a native application.

If Qt was used to build it, the application would run on an iPhone too.

Anyway, it was just an idea I had.

Dave.

[William A Stein]

On Wed, Aug 27, 2014 at 8:25 AM, Dr. David Kirkby (Kirkby Microwave

Post by Dr. David Kirkby (Kirkby Microwave Ltd)

Post by Bill Hart
The biggest problem by far is the upstream projects who do not accept
patches into their repositories to support Windows, and aren't willing to
make the changes to their codebase to support Windows 64. Nor do they
continue to maintain the ports once it is done.

I can't say I have ever looked at it, but if true it is an odd attitude. I
found *generally* that upstream projects were happy to take Solaris patches.
A patch I made for GSL to run on AIX was accepted upstream.

I dug up a relevant thread. [1] Here's a real example thread
involving a major patch to get pari to build on Windows. You can see
the response by the core PARI developers, the issues with build
support, etc.

[1] http://pari.math.u-bordeaux.fr/archives/pari-dev-0912/threads.html#00011

Near the end B. Allombert says: "Hello Vasili,
I have applied a variant of you patch:
On mingw you can now Configure PARI with
./Configure --datadir=@
and datadir will be set to win32_GPDATADIR() at run-time. This option
is used when compiling the daily GP windows binaries starting at svn
12711."

In short, it fully supports your argument that at least one upstream
project (PARI) is willing to take upstream patches to support
windows.... but you can also read in the thread about the
difficulties. It starts with remarks about the pari devs not having
windows access.

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
I an no fan of Windows, but with so many programs only working on Windows,
or tested more on Windows, I see it as a necessary evil.

Post by Bill Hart
This attitude in the Open Source community to Windows 64 really bugs me.
It's a decade old technology, and not going anywhere.

Lots of open source programs run on Windows, and with Windows being more and
more 64 bit, they will either have to adapt or

Post by Bill Hart
A port of Sage to Windows 64 is probably not a viable project. It would
take years of effort by numerous individuals to accomplish. And it would
bitrot before it was even completed. But the fact that it isn't viable right
now doesn't mean that upstream projects shouldn't support Windows 64 so that
if Sage ever wants to do such a port, it would be possible.
* flint
* gmp/mpir
* mpfr
* gmp-ecm
* GNU Scientific library

Maxima has a native Windows application, so that would work too. Maxims
uses ECL which is very portable.
Unfortunately, I don't think Maxima has a library interface, do once that is
added, any attempt to make a more consistent user interface would be
hampered.

We Sage developers (mainly Nils Bruin) wrote a C-library level
interface to Maxima, for use by Sage. I don't know if it would be
difficult to port that to Windows. It uses ECL = embedded common lisp
(where the whole point of *embedded* is that it is easy to embed in
other C programs).

Post by Dr. David Kirkby (Kirkby Microwave Ltd)

Post by Bill Hart
I understand that Sage uses things like Lisp, Java, Python, Cython, etc.
So the above doesn't help much with Sage overall. But perhaps it will help
raise awareness for projects that are using C and assembly only.
Bill.

Call it "Mini Sage", foobar or something else, it appears to me a
significant subset of Sage could be built into a native application.

All of Sage could be built... with *sufficient* work. Everything
could be ported and maintained... with sufficient work. But
sufficient is really dauntingly huge. Bill only scratched the surface
by listing technical problems at the C/C++ level - there's also tons
of build system issues as well, longterm maintenance, etc. It's all
totally do-able, but very expensive.

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
Anyway, it was just an idea I had.

It's a good idea. I had the same one years ago... and that's when
Sage started. A problem is that it's too hard today to do something
really useful without significant funding (since it's all ugly dirty
work, and definitely not research math).

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
Dave.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
***@uw.edu

[Jean-Pierre Flori]

Post by Bill Hart
I am again very interested in having Windows 64 ports of various packages.
* GAP
* Singular
* Pari/GP
Note that MinGW2 is a much better way to do this than has previously been
available. It builds packages in a tiny fraction of the time it takes to
build with MinGW. It also fixes the broken parallel make that was in MinGW.
It has a nice package manager. The compiler seems stable. It 1000% better
in every way. In my opinion, a more or less native port of various packages
to MinGW2 is quite feasible.
Note that cross-compiler running on linux and targetting mingw(64) have

been available since mingw(64) is.
You even get Debian packages for them.
And they are fast.

[Jeroen Demeyer]

Post by Bill Hart
Note that cross-compiler running on linux and targetting mingw(64) have
been available since mingw(64) is.

Many packages in Sage do not support cross-compiling. For example, the
Python build toolchain does not really support cross-compiling.

[Jean-Pierre Flori]

Post by Jeroen Demeyer

Post by Bill Hart
Note that cross-compiler running on linux and targetting mingw(64) have
been available since mingw(64) is.

Many packages in Sage do not support cross-compiling. For example, the
Python build toolchain does not really support cross-compiling.

Sure, but GMP/MPIR/MPFR/FLINT do.
You can even run testsuites using Wine64 :)

[William A Stein]

I tried to port Sage to mingw once, back when it was easier (2006),
and failed already at building Python.
There was a huge page with hacks to maybe do it back then, but they
weren't working.
There's a stackoverflow question now about this problem:

http://stackoverflow.com/questions/15365249/build-python-with-mingw-and-gcc

" Python does not build out of the box with MinGW, let alone for Win64."

and another suggests this fork of Python 3.4 that's meant to build on
mingw: https://bitbucket.org/puqing/python-mingw

but there are issues entitled "Build fails on mingw (msys)" down the
right side of the screen...

Post by Jean-Pierre Flori

Post by Jeroen Demeyer

Post by Bill Hart
Note that cross-compiler running on linux and targetting mingw(64) have
been available since mingw(64) is.

Many packages in Sage do not support cross-compiling. For example, the
Python build toolchain does not really support cross-compiling.

Sure, but GMP/MPIR/MPFR/FLINT do.
You can even run testsuites using Wine64 :)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
***@uw.edu

[Emil Widmann]

Post by William A Stein
I tried to port Sage to mingw once, back when it was easier (2006),
and failed already at building Python.
There was a huge page with hacks to maybe do it back then, but they
weren't working.
http://stackoverflow.com/questions/15365249/build-python-with-mingw-and-gcc
" Python does not build out of the box with MinGW, let alone for Win64."
and another suggests this fork of Python 3.4 that's meant to build on
mingw: https://bitbucket.org/puqing/python-mingw
but there are issues entitled "Build fails on mingw (msys)" down the
right side of the screen...

Post by Jean-Pierre Flori

Post by Jeroen Demeyer

Post by Bill Hart
Note that cross-compiler running on linux and targetting mingw(64)

have

Post by Jean-Pierre Flori

Post by Jeroen Demeyer

Post by Bill Hart
been available since mingw(64) is.

Many packages in Sage do not support cross-compiling. For example, the
Python build toolchain does not really support cross-compiling.

Sure, but GMP/MPIR/MPFR/FLINT do.
You can even run testsuites using Wine64 :)
--
You received this message because you are subscribed to the Google

Groups

Post by Jean-Pierre Flori
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send

an
<javascript:>.

Post by Jean-Pierre Flori
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

It seems this discussion about sage on windows surfaces periodically.
The virtual image is the most practical solution at the moment.

My arguments:
a) a native windows port is not realistic.
b) cygwin needs constant care and code maintainance, New versions of sage
may or may not build. It has a speed penalty.
c) I built an andlinux version 3 years ago. This was not too hard and has a
good integration with the windows desktop on the surface. Under the hood
there are, like william stein mentioned, possible crashes, a speed penalty
(similar cygwin) and rough edges. The project is no longer maintained and
it is 32 bit only.
d) the speed penalty will also hit other colinux based versions, I guess it
is also only 32 bit.

Arguments for the virtual image:
The virtual image has almost no speed penalty. It can always build on a
proven stable linux OS, so there is no extra cost for development. The size
should bot be a problem. Although a complete OS will not ship (not even
Puppy as mentioned) with 50 MB, it is possible to build a stable base OS
without desktop (no X) at around 50 - 70 MB - this size values refere to a
compressed image. This has not to be "Puppy" but can be e.g. Debian, or
probably Fedora. A few years ago I build Sage virtual machines around 400
MB (compressed image), I estimate that today this could be around 700 - 800
MB. A few years ago there was also "make stripped" build option which
should build a smaller, but full functional sage image, I don't know the
present stage of this developement.

The easiest approach to improve the user experience would be to write a
windows GUI to communicate with the VM over its commandline parameters. So
you can handle operation mode (headless mode, notebook), data transfer and
lots of other things. This could take care of most user inconveniences.

For the installation process I once wrote a windows installer which
installed Virtualbox (if no Virtualbox or an older version was detected)
together with the the Sage VM, I think it even had some menu entries to
start the notebook etc. This should still work, although it is not tested
on windows 8.

This is the link to the sage-windows thread about this combined installer:
https://groups.google.com/forum/#!topic/sage-windows/yoAcv8W5Fw0

unfortunately the download links over there don't work any more...

To sum up, enduser experience of the VM approach could be improved quite
easily.
But whatever, everybody who is online can use the SageCloud. This should
take care for most users independent of OS.

Cheers
emil

[Travis Scrimshaw]

Post by Emil Widmann
It seems this discussion about sage on windows surfaces periodically.
The virtual image is the most practical solution at the moment.
a) a native windows port is not realistic.
b) cygwin needs constant care and code maintainance, New versions of sage
may or may not build. It has a speed penalty.
c) I built an andlinux version 3 years ago. This was not too hard and has
a good integration with the windows desktop on the surface. Under the hood
there are, like william stein mentioned, possible crashes, a speed penalty
(similar cygwin) and rough edges. The project is no longer maintained and
it is 32 bit only.
d) the speed penalty will also hit other colinux based versions, I guess
it is also only 32 bit.
The virtual image has almost no speed penalty. It can always build on a
proven stable linux OS, so there is no extra cost for development. The size
should bot be a problem. Although a complete OS will not ship (not even
Puppy as mentioned) with 50 MB, it is possible to build a stable base OS
without desktop (no X) at around 50 - 70 MB - this size values refere to a
compressed image. This has not to be "Puppy" but can be e.g. Debian, or
probably Fedora. A few years ago I build Sage virtual machines around 400
MB (compressed image), I estimate that today this could be around 700 - 800
MB. A few years ago there was also "make stripped" build option which
should build a smaller, but full functional sage image, I don't know the
present stage of this developement.

But running the VM surely has a speed penalty because it has to go through
that big fat layer of the VM? Unless we can make an extremely lightweight
VM that primarily acts as a bridge between Sage and Windows (via the
notebook or command-line). Couldn't we just take a Free-BSD or other
feather-weight OS, make the appropriate changes to the kernel or installed
packages, and ship that out?

Post by Emil Widmann
The easiest approach to improve the user experience would be to write a
windows GUI to communicate with the VM over its commandline parameters. So
you can handle operation mode (headless mode, notebook), data transfer and
lots of other things. This could take care of most user inconveniences.
For the installation process I once wrote a windows installer which
installed Virtualbox (if no Virtualbox or an older version was detected)
together with the the Sage VM, I think it even had some menu entries to
start the notebook etc. This should still work, although it is not tested
on windows 8.
https://groups.google.com/forum/#!topic/sage-windows/yoAcv8W5Fw0
unfortunately the download links over there don't work any more...
To sum up, enduser experience of the VM approach could be improved quite
easily.
But whatever, everybody who is online can use the SageCloud. This should
take care for most users independent of OS.

IMO there are three big issues with the current Sage Windows VM:

1 - It's slow because it runs within the VM (which also causes some
usability issues with multiple webpages by the OS setup); this also has
high memory usage.
2 - It's too big (I think it's something like 3+ GB)
3 - You can't upgrade Sage or really work with different branches as far as
I remember.

To have such an easy way to get local versions of Sage running on Windows
would be a major help for India, Japan, and South Korea -- when I was there
last year giving some Sage demos, nearly everyone had a Windows laptop.
(Although now I'd just refer them to SMC, but solid internet connections in
India can be hit or miss.)

Best,
Travis

[Julien Puydt]

Hi,

Post by Travis Scrimshaw
2 - It's too big (I think it's something like 3+ GB)

On my little ARM box where I have 16G for both chromeos and ubuntu, du
-hc on the sage-6.3 directory says 3.9G. And on my amd64 box, the same
command says 4.6G. I have no clue about the 700M difference.

No VM in sight. No optional package.

Snark on #sagemath

[Volker Braun]

Post by Travis Scrimshaw
But running the VM surely has a speed penalty because it has to go through

Post by Travis Scrimshaw
that big fat layer of the VM?

Virtual machines are extremely fast on somewhat-recent hardware due to
hardware support. Using the gui inside the VM is somewhat slow since it has
to go through the graphics emulation, but if you connect with the OS
browser its probably difficult to notice any speed difference.

Of course the VM can't be much smaller than this if you want to be able to
develop inside it:

$ du -sh Sage/
5.2G Sage/

[William A Stein]

Post by Volker Braun

Post by Travis Scrimshaw
But running the VM surely has a speed penalty because it has to go

through that big fat layer of the VM?

Virtual machines are extremely fast on somewhat-recent hardware due to
hardware support. Using the gui inside the VM is somewhat slow since it has
to go through the graphics emulation, but if you connect with the OS
browser its probably difficult to notice any speed difference.
Of course the VM can't be much smaller than this if you want to be able to
$ du -sh Sage/
5.2G Sage/

One remark: that gets knocked almost in half if you use a compressed
filesystem (btrfs or ZFS) like I do with SageMathCloud...

Post by Volker Braun
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
***@uw.edu

[Travis Scrimshaw]

Here's some idea about how to setup that connection (FTR I haven't tried
them):

- https://coderwall.com/p/yx23qw
- http://askubuntu.com/questions/52147/how-can-i-access-apache-on-virtualbox-guest-from-host

So the VM would just have a simple command-line style interface which tells
the user what to do (and to exit out of Sage in order to use git and
recompile it's Sage for more dev minded people).

Best,
Travis

Post by Volker Braun

Post by Travis Scrimshaw
But running the VM surely has a speed penalty because it has to go

through that big fat layer of the VM?

Virtual machines are extremely fast on somewhat-recent hardware due to
hardware support. Using the gui inside the VM is somewhat slow since it has
to go through the graphics emulation, but if you connect with the OS
browser its probably difficult to notice any speed difference.
Of course the VM can't be much smaller than this if you want to be able to
$ du -sh Sage/
5.2G Sage/

[Volker Braun]

These links suggest "bridged" networking, with you should NOT do unless you
are aware of the security implications. The VM uses "NAT" networking which
makes it only accessible from the computer running the VM.

For development you can just ssh into the VM (again, only from the host
running the VM by default)

Post by Travis Scrimshaw
Here's some idea about how to setup that connection (FTR I haven't tried
- https://coderwall.com/p/yx23qw
-
http://askubuntu.com/questions/52147/how-can-i-access-apache-on-virtualbox-guest-from-host
So the VM would just have a simple command-line style interface which
tells the user what to do (and to exit out of Sage in order to use git and
recompile it's Sage for more dev minded people).
Best,
Travis

Post by Volker Braun

Post by Travis Scrimshaw
But running the VM surely has a speed penalty because it has to go

through that big fat layer of the VM?

Virtual machines are extremely fast on somewhat-recent hardware due to
hardware support. Using the gui inside the VM is somewhat slow since it has
to go through the graphics emulation, but if you connect with the OS
browser its probably difficult to notice any speed difference.
Of course the VM can't be much smaller than this if you want to be able
$ du -sh Sage/
5.2G Sage/

[mmarco]

Iirc, it would be accessible from any machine that can access the host. It just should point to the forwarded ports

[mmarco]

Iirc, it would be accessible from any machine that can access the host. It just should point to the forwarded ports

[Emil Widmann]

Post by Travis Scrimshaw
1 - It's slow because it runs within the VM (which also causes some
usability issues with multiple webpages by the OS setup); this also has
high memory usage.
2 - It's too big (I think it's something like 3+ GB)
3 - You can't upgrade Sage or really work with different branches as far
as I remember.
To have such an easy way to get local versions of Sage running on Windows
would be a major help for India, Japan, and South Korea -- when I was there
last year giving some Sage demos, nearly everyone had a Windows laptop.
(Although now I'd just refer them to SMC, but solid internet connections in
India can be hit or miss.)
Best,
Travis

Slowness may come due to high memory consumtion on restricted hardware. If
you have enough memory to run the virtual machine and bridge the output of
the sage VM to the host browser you have almost no speed penalty.

Of course in a real world use case with 3-10 year old computers and limited
bandwith/memory/diskspace big VM's can become problematic.

If you want to develop in sage then maybe the best way to go is a big
image. In other cases of just using sage, maybe it is better to use
compressed images.

@volker braun
$ du -sh Sage/
5.2G Sage/

When I spoke of 700 MB virtual machine I meant the data in a compressed
filesystem (e.g. Squashfilesystem with estimated compression rate of 3.5)
like most live distributions use. I also removed some files (e.g. docs)
from the full sage distribution to make it smaller. Docs can be stored
directly in the windows filesystem.

This would also mean that such a small version is not perfectly suited for
developement (although it can be done), but well suited for just "use" like
teaching.

I developed and tested on restricted hardware (e.g. old desktop with 1 GB
memory, 2,2 Ghz dual core Processor).

I know this topic has been discussed before and it was decided to ship the
full blown version as the the official sage VM. Still it is my opinion that
a small image with an optimized userinterface would be the best use of
developer hours and skill to improve the "sage on windows experience" for
new users and students. With the exception of using the Cloud, of course.

Cheers
emil

[William A Stein]

Post by Emil Widmann

Post by Travis Scrimshaw
1 - It's slow because it runs within the VM (which also causes some
usability issues with multiple webpages by the OS setup); this also has high
memory usage.
2 - It's too big (I think it's something like 3+ GB)
3 - You can't upgrade Sage or really work with different branches as far
as I remember.
To have such an easy way to get local versions of Sage running on Windows
would be a major help for India, Japan, and South Korea -- when I was there
last year giving some Sage demos, nearly everyone had a Windows laptop.
(Although now I'd just refer them to SMC, but solid internet connections in
India can be hit or miss.)
Best,
Travis

Slowness may come due to high memory consumtion on restricted hardware. If
you have enough memory to run the virtual machine and bridge the output of
the sage VM to the host browser you have almost no speed penalty.
Of course in a real world use case with 3-10 year old computers and limited
bandwith/memory/diskspace big VM's can become problematic.
If you want to develop in sage then maybe the best way to go is a big image.
In other cases of just using sage, maybe it is better to use compressed
images.
@volker braun
$ du -sh Sage/
5.2G Sage/
When I spoke of 700 MB virtual machine I meant the data in a compressed
filesystem (e.g. Squashfilesystem with estimated compression rate of 3.5)
like most live distributions use. I also removed some files (e.g. docs) from
the full sage distribution to make it smaller. Docs can be stored directly
in the windows filesystem.
This would also mean that such a small version is not perfectly suited for
developement (although it can be done), but well suited for just "use" like
teaching.
I developed and tested on restricted hardware (e.g. old desktop with 1 GB
memory, 2,2 Ghz dual core Processor).
I know this topic has been discussed before and it was decided to ship the
full blown version as the the official sage VM. Still it is my opinion that

I think it might be more accurate to say that Volker, who creates the
VM, decided that he only has time to ship a full blown official Sage
VM. If somebody, anybody, wants to provide (and regularly update) an
additional VM like you describe, I don't see why we wouldn't ship it.

William

Post by Emil Widmann
a small image with an optimized userinterface would be the best use of
developer hours and skill to improve the "sage on windows experience" for
new users and students. With the exception of using the Cloud, of course.
Cheers
emil
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
***@uw.edu

[Emil Widmann]

Post by Dr. David Kirkby (Kirkby Microwave Ltd)

Post by Emil Widmann

Post by Travis Scrimshaw
1 - It's slow because it runs within the VM (which also causes some
usability issues with multiple webpages by the OS setup); this also has

high

Post by Emil Widmann

Post by Travis Scrimshaw
memory usage.
2 - It's too big (I think it's something like 3+ GB)
3 - You can't upgrade Sage or really work with different branches as

far

Post by Emil Widmann

Post by Travis Scrimshaw
as I remember.
To have such an easy way to get local versions of Sage running on

Windows

Post by Emil Widmann

Post by Travis Scrimshaw
would be a major help for India, Japan, and South Korea -- when I was

there

Post by Emil Widmann

Post by Travis Scrimshaw
last year giving some Sage demos, nearly everyone had a Windows laptop.
(Although now I'd just refer them to SMC, but solid internet

connections in

Post by Emil Widmann

Post by Travis Scrimshaw
India can be hit or miss.)
Best,
Travis

Slowness may come due to high memory consumtion on restricted hardware.

If

Post by Emil Widmann
you have enough memory to run the virtual machine and bridge the output

of

Post by Emil Widmann
the sage VM to the host browser you have almost no speed penalty.
Of course in a real world use case with 3-10 year old computers and

limited

Post by Emil Widmann
bandwith/memory/diskspace big VM's can become problematic.
If you want to develop in sage then maybe the best way to go is a big

image.

Post by Emil Widmann
In other cases of just using sage, maybe it is better to use compressed
images.
@volker braun
$ du -sh Sage/
5.2G Sage/
When I spoke of 700 MB virtual machine I meant the data in a compressed
filesystem (e.g. Squashfilesystem with estimated compression rate of

3.5)

Post by Emil Widmann
like most live distributions use. I also removed some files (e.g. docs)

from

Post by Emil Widmann
the full sage distribution to make it smaller. Docs can be stored

directly

Post by Emil Widmann
in the windows filesystem.
This would also mean that such a small version is not perfectly suited

for

Post by Emil Widmann
developement (although it can be done), but well suited for just "use"

like

Post by Emil Widmann
teaching.
I developed and tested on restricted hardware (e.g. old desktop with 1

GB

Post by Emil Widmann
memory, 2,2 Ghz dual core Processor).
I know this topic has been discussed before and it was decided to ship

the

Post by Emil Widmann
full blown version as the the official sage VM. Still it is my opinion

that
I think it might be more accurate to say that Volker, who creates the
VM, decided that he only has time to ship a full blown official Sage
VM. If somebody, anybody, wants to provide (and regularly update) an
additional VM like you describe, I don't see why we wouldn't ship it.
William

Post by Emil Widmann
a small image with an optimized userinterface would be the best use of
developer hours and skill to improve the "sage on windows experience"

for

Post by Emil Widmann
new users and students. With the exception of using the Cloud, of

course.

Post by Emil Widmann
Cheers
emil
--
You received this message because you are subscribed to the Google

Groups

Post by Emil Widmann
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send

an
<javascript:>.

Post by Emil Widmann
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

Sounds good.
One argument was to have a scripted approach to auto build the VM. What is
the current state of the "make stripped" or "build micro release" option?

[Volker Braun]

The script to build the VM is here:

https://bitbucket.org/vbraun/sage-virtual-appliance-buildscript

If anybody wants to adapt it to build a minimal VM in addition to a full
(ready-for-development) one then I'd be happy to run it twice.

Post by Emil Widmann

Post by Travis Scrimshaw
1 - It's slow because it runs within the VM (which also causes some
usability issues with multiple webpages by the OS setup); this also has
high memory usage.
2 - It's too big (I think it's something like 3+ GB)
3 - You can't upgrade Sage or really work with different branches as far
as I remember.
To have such an easy way to get local versions of Sage running on Windows
would be a major help for India, Japan, and South Korea -- when I was there
last year giving some Sage demos, nearly everyone had a Windows laptop.
(Although now I'd just refer them to SMC, but solid internet connections in
India can be hit or miss.)
Best,
Travis

Slowness may come due to high memory consumtion on restricted hardware. If
you have enough memory to run the virtual machine and bridge the output of
the sage VM to the host browser you have almost no speed penalty.
Of course in a real world use case with 3-10 year old computers and
limited bandwith/memory/diskspace big VM's can become problematic.
If you want to develop in sage then maybe the best way to go is a big
image. In other cases of just using sage, maybe it is better to use
compressed images.
@volker braun
$ du -sh Sage/
5.2G Sage/
When I spoke of 700 MB virtual machine I meant the data in a compressed
filesystem (e.g. Squashfilesystem with estimated compression rate of 3.5)
like most live distributions use. I also removed some files (e.g. docs)
from the full sage distribution to make it smaller. Docs can be stored
directly in the windows filesystem.
This would also mean that such a small version is not perfectly suited for
developement (although it can be done), but well suited for just "use" like
teaching.
I developed and tested on restricted hardware (e.g. old desktop with 1 GB
memory, 2,2 Ghz dual core Processor).
I know this topic has been discussed before and it was decided to ship the
full blown version as the the official sage VM. Still it is my opinion that
a small image with an optimized userinterface would be the best use of
developer hours and skill to improve the "sage on windows experience" for
new users and students. With the exception of using the Cloud, of course.
Cheers
emil

[kcrisman]

Post by Volker Braun
https://bitbucket.org/vbraun/sage-virtual-appliance-buildscript
If anybody wants to adapt it to build a minimal VM in addition to a full
(ready-for-development) one then I'd be happy to run it twice.

And Emil has a lot of tested practice in delivering the Live version, so
hopefully between the two of you a good solution could be found there.
Nice!

[Jori Mantysalo]

1 - It's slow  because it runs within the VM (which also causes some
usability issues with multiple webpages by the OS setup); this also
has high memory usage.
2 - It's too big (I think it's something like 3+ GB)
3 - You can't upgrade Sage or really work with different branches as
far as I remember.

For casual sage *user*, not *developer*, those are not necessarily
problems. They might be, but one can have fast computer, enought bandwith
for downloading etc.

However, can we put VirtualBox and Sage to one .exe? What is really needed
is to convert http://wiki.sagemath.org/SageAppliance to be just "1)
Download this .exe, 2) Doubleclick it, 3) Ready".

I am now thinking for example university class using Sage as a part of
some course. Teachers don't want to use time for being it-support;
students do not try installing Sage, if it SEEMS to be complicated.

[Volker Braun]

To install the hypervisor (if you don't have a virtualization environment
already) definitely requires administrative permissions.

Post by Jori Mantysalo

Post by Travis Scrimshaw
1 - It's slow because it runs within the VM (which also causes some
usability issues with multiple webpages by the OS setup); this also
has high memory usage.
2 - It's too big (I think it's something like 3+ GB)
3 - You can't upgrade Sage or really work with different branches as
far as I remember.

For casual sage *user*, not *developer*, those are not necessarily
problems. They might be, but one can have fast computer, enought bandwith
for downloading etc.
However, can we put VirtualBox and Sage to one .exe? What is really needed
is to convert http://wiki.sagemath.org/SageAppliance to be just "1)
Download this .exe, 2) Doubleclick it, 3) Ready".
I am now thinking for example university class using Sage as a part of
some course. Teachers don't want to use time for being it-support;
students do not try installing Sage, if it SEEMS to be complicated.
--
Jori MÀntysalo

[Vincent Delecroix]

Post by Jori Mantysalo

Post by Travis Scrimshaw
1 - It's slow because it runs within the VM (which also causes some
usability issues with multiple webpages by the OS setup); this also
has high memory usage.
2 - It's too big (I think it's something like 3+ GB)
3 - You can't upgrade Sage or really work with different branches as
far as I remember.

For casual sage *user*, not *developer*, those are not necessarily
problems. They might be, but one can have fast computer, enought bandwith
for downloading etc.
However, can we put VirtualBox and Sage to one .exe? What is really needed
is to convert http://wiki.sagemath.org/SageAppliance to be just "1)
Download this .exe, 2) Doubleclick it, 3) Ready".
I am now thinking for example university class using Sage as a part of
some course. Teachers don't want to use time for being it-support;
students do not try installing Sage, if it SEEMS to be complicated.

Note that for teaching/installation there is an alternative: tell the
students to come with a USB stick and just clone the sage-debian live
(http://sagedebianlive.metelu.net/). It is very easy to use and all
students will have exactly the same system. The procedure to duplicate
the key is integrated inside the key, so the time to set up 200 keys
is in theory just log(200)/log(2) * (time of one install), ignoring
the fact that you could clone several keys at once.

The key is definitely not set up for development. But it's still
doable using a local drive (intensive access to the filesystem on a
USB stick will just burn it quickly).

It is completely self contained with no it-support needed (except that
you need computers that are able to boot on USB).

Vincent

[Jori Mantysalo]

Post by Vincent Delecroix
Note that for teaching/installation there is an alternative: tell the
students to come with a USB stick and just clone the sage-debian live
(http://sagedebianlive.metelu.net/). It is very easy to use and all
students will have exactly the same system.

Interesting! This could also be easy enought. However, students should be
told how to boot from usb stick. But on the other way, there is almost
nothing that can got broken with this system.

[Thierry]

Hi,

Post by Jori Mantysalo

Post by Vincent Delecroix
Note that for teaching/installation there is an alternative: tell the
students to come with a USB stick and just clone the sage-debian live
(http://sagedebianlive.metelu.net/). It is very easy to use and all
students will have exactly the same system.

Interesting! This could also be easy enought. However, students
should be told how to boot from usb stick. But on the other way,
there is almost nothing that can got broken with this system.

The fun thing is that, while the one-click clone/upgrade feature was
primarily intented for easy deployment of Sage without internet
connection, i was surprised to get most feedback from "well-connectedd"
teachers using it in order to have a uniform configuration for windows
students.

An even more interesting use-case is about a teacher who maintain his
own custom live USB to include additional software related for his
lecture's needs (numerical analysis tools and specific development
environment).

Actually, i got some positive feedback from Burkina Faso, France, Italy,
Mexico, Spain, USA and China (though those two seem for individual use,
not classroom).

Ciao,
Thierry

[Dr. David Kirkby (Kirkby Microwave Ltd)]

Post by Vincent Delecroix

Post by Jori Mantysalo
I am now thinking for example university class using Sage as a part of
some course. Teachers don't want to use time for being it-support;
students do not try installing Sage, if it SEEMS to be complicated.

Note that for teaching/installation there is an alternative: tell the
students to come with a USB stick and just clone the sage-debian live
(http://sagedebianlive.metelu.net/). It is very easy to use and all
students will have exactly the same system. The procedure to duplicate
the key is integrated inside the key, so the time to set up 200 keys
is in theory just log(200)/log(2) * (time of one install), ignoring
the fact that you could clone several keys at once.
The key is definitely not set up for development. But it's still
doable using a local drive (intensive access to the filesystem on a
USB stick will just burn it quickly).
It is completely self contained with no it-support needed (except that
you need computers that are able to boot on USB).
Vincent

I can't imagine a single *professional* system admin in a university
would want students booting computers from USB sticks. I'm not saying
some random lecturer who takes on a system admin role would mind, but
from a security point of view, having PCs booting from a USB stick is
risky. Malicious software could do any sort of nasty. I've reset
passwords on Windows machines doing that - boot Linux, mount the NTFS
file system, edit the files.

If students have their own laptops, then it is less of a risk, but I
would imagine the lecturer would spend all his/her time trying to help
a student get his/her laptop to boot from a USB stick. You would need
to get into the BIOS for that, and many computers are different about
how that works.

Of course, the same argument can be made about booting from any form
of ISO image, such as a DVD.

Maybe use of Sage should at some point be preeded by some lectures on
the use of Linux. I was reading in the UK today that *programming* is
to be made part of the compulsory school curriculum in England. I'm
not sure by what age, but given people can leave school at 16 here, it
will be before 16. Given mathmaticians are going to be using
Mathematical software, teaching them enough of the OS on which that
software runs is probably not a bad idea. I believe it happens in
Germany for example.



Dave

[William A Stein]

On Mon, Sep 1, 2014 at 3:42 AM, Dr. David Kirkby (Kirkby Microwave

Post by Dr. David Kirkby (Kirkby Microwave Ltd)

Post by Vincent Delecroix

Post by Jori Mantysalo
I am now thinking for example university class using Sage as a part of
some course. Teachers don't want to use time for being it-support;
students do not try installing Sage, if it SEEMS to be complicated.

Note that for teaching/installation there is an alternative: tell the
students to come with a USB stick and just clone the sage-debian live
(http://sagedebianlive.metelu.net/). It is very easy to use and all
students will have exactly the same system. The procedure to duplicate
the key is integrated inside the key, so the time to set up 200 keys
is in theory just log(200)/log(2) * (time of one install), ignoring
the fact that you could clone several keys at once.
The key is definitely not set up for development. But it's still
doable using a local drive (intensive access to the filesystem on a
USB stick will just burn it quickly).
It is completely self contained with no it-support needed (except that
you need computers that are able to boot on USB).
Vincent

I can't imagine a single *professional* system admin in a university
would want students booting computers from USB sticks. I'm not saying
some random lecturer who takes on a system admin role would mind, but
from a security point of view, having PCs booting from a USB stick is
risky. Malicious software could do any sort of nasty. I've reset
passwords on Windows machines doing that - boot Linux, mount the NTFS
file system, edit the files.
If students have their own laptops, then it is less of a risk, but I
would imagine the lecturer would spend all his/her time trying to help
a student get his/her laptop to boot from a USB stick. You would need
to get into the BIOS for that, and many computers are different about
how that works.
Of course, the same argument can be made about booting from any form
of ISO image, such as a DVD.

I'm also personally uncomfortable with the whole USB stick/DVD boot
proposal for making Sage easier to use
for similar reasons. However, it's important to distinguish between a
modern professionally run computer lab (with full disk encryption,
BIOS passwords, fast network), etc., and a second-hand lab of older
computers in a developing country with crappy or non-existent network,
say. There's huge value in the USB/ISO Live linux approach to
running Sage in *that* context.

Thierry, I'm definitely +1 your efforts, even though I'm not
personally likely to use them. If we should feature something more
prominently somewhere on the sage website, let me know.
--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
***@uw.edu

[Thierry]

Post by Dr. David Kirkby (Kirkby Microwave Ltd)

Post by Vincent Delecroix

Post by Jori Mantysalo
I am now thinking for example university class using Sage as a part of
some course. Teachers don't want to use time for being it-support;
students do not try installing Sage, if it SEEMS to be complicated.

Note that for teaching/installation there is an alternative: tell the
students to come with a USB stick and just clone the sage-debian live
(http://sagedebianlive.metelu.net/). It is very easy to use and all
students will have exactly the same system. The procedure to duplicate
the key is integrated inside the key, so the time to set up 200 keys
is in theory just log(200)/log(2) * (time of one install), ignoring
the fact that you could clone several keys at once.
The key is definitely not set up for development. But it's still
doable using a local drive (intensive access to the filesystem on a
USB stick will just burn it quickly).
It is completely self contained with no it-support needed (except that
you need computers that are able to boot on USB).
Vincent

I can't imagine a single *professional* system admin in a university
would want students booting computers from USB sticks. I'm not saying
some random lecturer who takes on a system admin role would mind, but
from a security point of view, having PCs booting from a USB stick is
risky. Malicious software could do any sort of nasty. I've reset
passwords on Windows machines doing that - boot Linux, mount the NTFS
file system, edit the files.

To give an explicit example, one comment from a teacher in Madrid says:
"I use the USB for my students, which often are scared to install linux
but have to use Sage.", so it is for student laptops.

Of course, if a professional sysadmin maintains the university's
computers, she can install Sage on the computers or serve it from a
dedicated server as they do for example in Lyon with sage notebook
(which is why i advocate having a multi-user version of Sage to actually
work, the current situation is pretty hazardous: ipython notebook is
single user (and the planned multi-user will only work with trusted
users), the multi-user part of sagemathcloud is not open-sourced, Sage
notebook might become unmaintained or lagging behind ipython notebook).

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
If students have their own laptops, then it is less of a risk, but I
would imagine the lecturer would spend all his/her time trying to help
a student get his/her laptop to boot from a USB stick. You would need
to get into the BIOS for that, and many computers are different about
how that works.

My experience is that it is indeed much easier to explain how to boot
from a USB drive ("press F2/F12/Delete/whatever at boot time, search for
'boot sequence', try to put the USB drive on top (F5/F6, +/-,
PageUp/PageDown) and search for 'save and exit', not a big deal) than
explaining how to install a GNU/Linux distro (which contains the
previous step, but also making backups, reduce existing partitions,...).
Moreover, once the bootstrap is done on a few laptops, the diffusion is
pretty fast (each student with a working live system becomes a seeder).

Moreover this exercise has to be done only once, and there is no more
work to do afterwards, e.g. when upgrading. My personal strategy is to
use the live USB when i have to deal with a lot of people, and to
propose to help installing a GNU/Linux distro when i am with a single
motivated person since it takes much more time to install and explain
basics (e.g. using the package manager instead of downloading a binary
on the web). Also the live USB can be a step in the discovery of a full
featured GNU/Linux before actually willing to install it on the hard
disk.

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
Of course, the same argument can be made about booting from any form
of ISO image, such as a DVD.
Maybe use of Sage should at some point be preeded by some lectures on
the use of Linux.

+1

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
I was reading in the UK today that *programming* is
to be made part of the compulsory school curriculum in England. I'm
not sure by what age, but given people can leave school at 16 here, it
will be before 16. Given mathmaticians are going to be using
Mathematical software, teaching them enough of the OS on which that
software runs is probably not a bad idea. I believe it happens in
Germany for example.
Dave

Ciao,
Thierry

[Emil Widmann]

However, can we put VirtualBox and Sage to one .exe? What is really needed
is to convert http://wiki.sagemath.org/SageAppliance to be just "1)
Download this .exe, 2) Doubleclick it, 3) Ready".

Yes, I wrote an installer which included the VirtualBox installer and the
Sage Appliance inside one exe.
Technically it is no problem, I don't know about legal implications.

[kcrisman]

Post by Jori Mantysalo
However, can we put VirtualBox and Sage to one .exe? What is really needed
is to convert http://wiki.sagemath.org/SageAppliance to be just "1)
Download this .exe, 2) Doubleclick it, 3) Ready".
Yes, I wrote an installer which included the VirtualBox installer and the
Sage Appliance inside one exe.
Technically it is no problem,

The Holy Grail... one click to install Sage on Windows!

Post by Jori Mantysalo
I don't know about legal implications.

Yeah, I think that is the problem :(

[Dr. David Kirkby (Kirkby Microwave Ltd)]

Post by kcrisman

Post by Jori Mantysalo
However, can we put VirtualBox and Sage to one .exe? What is really needed
is to convert http://wiki.sagemath.org/SageAppliance to be just "1)
Download this .exe, 2) Doubleclick it, 3) Ready".
Yes, I wrote an installer which included the VirtualBox installer and

the Sage Appliance inside one exe.

Post by kcrisman

Post by Jori Mantysalo
Technically it is no problem,

The Holy Grail... one click to install Sage on Windows!

Post by Jori Mantysalo
I don't know about legal implications.

Yeah, I think that is the problem :(

There's no harm in asking Oracle, who I assume own VirtualBox, for
permission to do something outside the license conditions.

Some years ago there was a discussion about using Wolfrom|Alpha in a way
that some believed was outside the terms of use of the site. I sought
permission to do it, and Wolfram Research said that they would permit us
to do it. The sad thing is I don't think we ever used it, but that's
another issue.

Dave

[Volker Braun]

VirtualBox (OSE edition) is GPLv2 so we are free to modify and distribute
it. We don't link against it so there is no issue with GPL versions... Any
installer / Sage frontend would have to be GPLv2 compatible.

Post by Jori Mantysalo
However, can we put VirtualBox and Sage to one .exe? What is really needed
is to convert http://wiki.sagemath.org/SageAppliance to be just "1)
Download this .exe, 2) Doubleclick it, 3) Ready".
Yes, I wrote an installer which included the VirtualBox installer and the
Sage Appliance inside one exe.
Technically it is no problem, I don't know about legal implications.

[Jori Mantysalo]

Post by Emil Widmann

Post by Jori Mantysalo
However, can we put VirtualBox and Sage to one .exe? What is really needed
is to convert http://wiki.sagemath.org/SageAppliance to be just "1)
Download this .exe, 2) Doubleclick it, 3) Ready".

Yes, I wrote an installer which included the VirtualBox installer and the
Sage Appliance inside one exe.

Then THIS is what we need!

And of course underlying sage system should start automatically, in
headless mode etc, if by all means possible. And open browser, so icon on
user's desktop would be shortcut to .bat that "just works". And to think
little more, maybe have sage binaries installed to virtual drive marked as
immutable image or (virtual) disk partition mounted as read-only.

Post by Emil Widmann
To install the hypervisor (if you don't have a virtualization
environment already) definitely requires administrative permissions.

Yep, that's not usually a problem.

[Emil Widmann]

Post by Jori Mantysalo

Post by Emil Widmann

Post by Jori Mantysalo
However, can we put VirtualBox and Sage to one .exe? What is really needed
is to convert http://wiki.sagemath.org/SageAppliance to be just "1)
Download this .exe, 2) Doubleclick it, 3) Ready".

Yes, I wrote an installer which included the VirtualBox installer and

the

Post by Emil Widmann
Sage Appliance inside one exe.

Then THIS is what we need!
And of course underlying sage system should start automatically, in
headless mode etc, if by all means possible. And open browser, so icon on
user's desktop would be shortcut to .bat that "just works". And to think
little more, maybe have sage binaries installed to virtual drive marked as
immutable image or (virtual) disk partition mounted as read-only.

here is the link to the Sage Win installer
https://www.dropbox.com/s/uq9p60hkttr3ail/Sage-Win-Installer.exe?dl=0

It will install Virtualbox and Sage.ova with one exe installer. it is ca
490 MB size.

sage version is outdated and it still contains a full VM with X and
desktop, but you can start notebook and then use the windows browser.
Enough to test as a protoype.

best regards
emil

[Volker Braun]

How do I build it from a script on Linux?

Post by Emil Widmann

Post by Jori Mantysalo

Post by Emil Widmann

Post by Jori Mantysalo
However, can we put VirtualBox and Sage to one .exe? What is really needed
is to convert http://wiki.sagemath.org/SageAppliance to be just "1)
Download this .exe, 2) Doubleclick it, 3) Ready".

Yes, I wrote an installer which included the VirtualBox installer and

the

Post by Emil Widmann
Sage Appliance inside one exe.

Then THIS is what we need!
And of course underlying sage system should start automatically, in
headless mode etc, if by all means possible. And open browser, so icon on
user's desktop would be shortcut to .bat that "just works". And to think
little more, maybe have sage binaries installed to virtual drive marked as
immutable image or (virtual) disk partition mounted as read-only.

here is the link to the Sage Win installer
https://www.dropbox.com/s/uq9p60hkttr3ail/Sage-Win-Installer.exe?dl=0
It will install Virtualbox and Sage.ova with one exe installer. it is ca
490 MB size.
sage version is outdated and it still contains a full VM with X and
desktop, but you can start notebook and then use the windows browser.
Enough to test as a protoype.
best regards
emil

[Emil Widmann]

wine should work

Post by Volker Braun
How do I build it from a script on Linux?

Post by Emil Widmann

Post by Jori Mantysalo

Post by Emil Widmann

Post by Jori Mantysalo
However, can we put VirtualBox and Sage to one .exe? What is really needed
is to convert http://wiki.sagemath.org/SageAppliance to be just "1)
Download this .exe, 2) Doubleclick it, 3) Ready".

Yes, I wrote an installer which included the VirtualBox installer and

the

Post by Emil Widmann
Sage Appliance inside one exe.

Then THIS is what we need!
And of course underlying sage system should start automatically, in
headless mode etc, if by all means possible. And open browser, so icon on
user's desktop would be shortcut to .bat that "just works". And to think
little more, maybe have sage binaries installed to virtual drive marked as
immutable image or (virtual) disk partition mounted as read-only.

here is the link to the Sage Win installer
https://www.dropbox.com/s/uq9p60hkttr3ail/Sage-Win-Installer.exe?dl=0
It will install Virtualbox and Sage.ova with one exe installer. it is ca
490 MB size.
sage version is outdated and it still contains a full VM with X and
desktop, but you can start notebook and then use the windows browser.
Enough to test as a protoype.
best regards
emil

[Volker Braun]

Maybe yes, maybe no. Which steps did you do to get the output?

Post by Emil Widmann
wine should work

Post by Volker Braun
How do I build it from a script on Linux?

Post by Emil Widmann

Post by Jori Mantysalo

Post by Emil Widmann

Post by Jori Mantysalo
However, can we put VirtualBox and Sage to one .exe? What is really needed
is to convert http://wiki.sagemath.org/SageAppliance to be just "1)
Download this .exe, 2) Doubleclick it, 3) Ready".

Yes, I wrote an installer which included the VirtualBox installer and

the

Post by Emil Widmann
Sage Appliance inside one exe.

Then THIS is what we need!
And of course underlying sage system should start automatically, in
headless mode etc, if by all means possible. And open browser, so icon on
user's desktop would be shortcut to .bat that "just works". And to think
little more, maybe have sage binaries installed to virtual drive marked as
immutable image or (virtual) disk partition mounted as read-only.

here is the link to the Sage Win installer
https://www.dropbox.com/s/uq9p60hkttr3ail/Sage-Win-Installer.exe?dl=0
It will install Virtualbox and Sage.ova with one exe installer. it is ca
490 MB size.
sage version is outdated and it still contains a full VM with X and
desktop, but you can start notebook and then use the windows browser.
Enough to test as a protoype.
best regards
emil

[Emil Widmann]

It is all old stuff. Links to sources etc are here:
https://groups.google.com/forum/#!topic/sage-windows/yoAcv8W5Fw0

Post by Volker Braun
Maybe yes, maybe no. Which steps did you do to get the output?

Post by Emil Widmann
wine should work

Post by Volker Braun
How do I build it from a script on Linux?

Post by Emil Widmann

Post by William A Stein

Post by Emil Widmann

Post by Jori Mantysalo
However, can we put VirtualBox and Sage to one .exe? What is really needed
is to convert http://wiki.sagemath.org/SageAppliance to be just

"1)

Post by Emil Widmann

Post by Jori Mantysalo
Download this .exe, 2) Doubleclick it, 3) Ready".

Yes, I wrote an installer which included the VirtualBox installer

and the

Post by Emil Widmann
Sage Appliance inside one exe.

Then THIS is what we need!
And of course underlying sage system should start automatically, in
headless mode etc, if by all means possible. And open browser, so icon on
user's desktop would be shortcut to .bat that "just works". And to think
little more, maybe have sage binaries installed to virtual drive marked as
immutable image or (virtual) disk partition mounted as read-only.

here is the link to the Sage Win installer
https://www.dropbox.com/s/uq9p60hkttr3ail/Sage-Win-Installer.exe?dl=0
It will install Virtualbox and Sage.ova with one exe installer. it is
ca 490 MB size.
sage version is outdated and it still contains a full VM with X and
desktop, but you can start notebook and then use the windows browser.
Enough to test as a protoype.
best regards
emil

[Volker Braun]

Links don't work (home directories on boxen are private now)

Post by Emil Widmann
https://groups.google.com/forum/#!topic/sage-windows/yoAcv8W5Fw0

Post by Volker Braun
Maybe yes, maybe no. Which steps did you do to get the output?

Post by Emil Widmann
wine should work

Post by Volker Braun
How do I build it from a script on Linux?

Post by Emil Widmann

Post by Dr. David Kirkby (Kirkby Microwave Ltd)

Post by Emil Widmann

Post by Jori Mantysalo
However, can we put VirtualBox and Sage to one .exe? What is

really

Post by Emil Widmann

Post by Jori Mantysalo
needed
is to convert http://wiki.sagemath.org/SageAppliance to be just

"1)

Post by Emil Widmann

Post by Jori Mantysalo
Download this .exe, 2) Doubleclick it, 3) Ready".

Yes, I wrote an installer which included the VirtualBox installer

and the

Post by Emil Widmann
Sage Appliance inside one exe.

Then THIS is what we need!
And of course underlying sage system should start automatically, in
headless mode etc, if by all means possible. And open browser, so icon on
user's desktop would be shortcut to .bat that "just works". And to think
little more, maybe have sage binaries installed to virtual drive marked as
immutable image or (virtual) disk partition mounted as read-only.

here is the link to the Sage Win installer
https://www.dropbox.com/s/uq9p60hkttr3ail/Sage-Win-Installer.exe?dl=0
It will install Virtualbox and Sage.ova with one exe installer. it is
ca 490 MB size.
sage version is outdated and it still contains a full VM with X and
desktop, but you can start notebook and then use the windows browser.
Enough to test as a protoype.
best regards
emil

[Emil Widmann]

Oh, I see. I got reports from people who couldn't donwload my stuff. I was
not much interested over the last 2-3 years and from what I can see
paradigmas have changed. From postings I read Prof. Stein thinks that
commercialising via the SageCloud is the way to go to. So I have to rethink
my part and maybe/maybe not setup a different download location.

kind regards
emil

Post by Volker Braun
Links don't work (home directories on boxen are private now)

Post by Emil Widmann
https://groups.google.com/forum/#!topic/sage-windows/yoAcv8W5Fw0

Post by Volker Braun
Maybe yes, maybe no. Which steps did you do to get the output?

Post by Emil Widmann
wine should work

Post by Volker Braun
How do I build it from a script on Linux?

Post by Emil Widmann

Post by Dr. David Kirkby (Kirkby Microwave Ltd)

Post by Emil Widmann

Post by Jori Mantysalo
However, can we put VirtualBox and Sage to one .exe? What is

really

Post by Emil Widmann

Post by Jori Mantysalo
needed
is to convert http://wiki.sagemath.org/SageAppliance to be just

"1)

Post by Emil Widmann

Post by Jori Mantysalo
Download this .exe, 2) Doubleclick it, 3) Ready".

Yes, I wrote an installer which included the VirtualBox installer

and the

Post by Emil Widmann
Sage Appliance inside one exe.

Then THIS is what we need!
And of course underlying sage system should start automatically, in
headless mode etc, if by all means possible. And open browser, so icon on
user's desktop would be shortcut to .bat that "just works". And to think
little more, maybe have sage binaries installed to virtual drive marked as
immutable image or (virtual) disk partition mounted as read-only.

here is the link to the Sage Win installer
https://www.dropbox.com/s/uq9p60hkttr3ail/Sage-Win-Installer.exe?dl=0
It will install Virtualbox and Sage.ova with one exe installer. it is
ca 490 MB size.
sage version is outdated and it still contains a full VM with X and
desktop, but you can start notebook and then use the windows browser.
Enough to test as a protoype.
best regards
emil

[William A Stein]

Post by Emil Widmann

Post by Volker Braun
Links don't work (home directories on boxen are private now)

I'm happy to change any to be public, on a case-by-case basis. I was
just having too much trouble with people posting illegal books
publicly, then I get contacted by angry publishers and authors.

Post by Emil Widmann
Oh, I see. I got reports from people who couldn't donwload my stuff. I was
not much interested over the last 2-3 years and from what I can see
paradigmas have changed. From postings I read Prof. Stein thinks that
commercialising via the SageCloud is the way to go to.

That's the way *I'm* going to increase easy availability of Sage. I
really hope other people
like you will continue to work on and support all ways of gaining
access to Sage.

William

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann
https://groups.google.com/forum/#!topic/sage-windows/yoAcv8W5Fw0

Post by Volker Braun
Maybe yes, maybe no. Which steps did you do to get the output?

Post by Emil Widmann
wine should work

Post by Volker Braun
How do I build it from a script on Linux?

Post by Emil Widmann

Post by Jori Mantysalo

Post by Emil Widmann

Post by Jori Mantysalo
However, can we put VirtualBox and Sage to one .exe? What is
really
needed
is to convert http://wiki.sagemath.org/SageAppliance to be just "1)
Download this .exe, 2) Doubleclick it, 3) Ready".

Yes, I wrote an installer which included the VirtualBox installer and the
Sage Appliance inside one exe.

Then THIS is what we need!
And of course underlying sage system should start automatically, in
headless mode etc, if by all means possible. And open browser, so icon on
user's desktop would be shortcut to .bat that "just works". And to think
little more, maybe have sage binaries installed to virtual drive marked as
immutable image or (virtual) disk partition mounted as read-only.

here is the link to the Sage Win installer
https://www.dropbox.com/s/uq9p60hkttr3ail/Sage-Win-Installer.exe?dl=0
It will install Virtualbox and Sage.ova with one exe installer. it is
ca 490 MB size.
sage version is outdated and it still contains a full VM with X and
desktop, but you can start notebook and then use the windows browser. Enough
to test as a protoype.
best regards
emil

--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
***@uw.edu

[William A Stein]

Post by William A Stein

Post by Emil Widmann

Post by Volker Braun
Links don't work (home directories on boxen are private now)

I'm happy to change any to be public, on a case-by-case basis. I was
just having too much trouble with people posting illegal books
publicly, then I get contacted by angry publishers and authors.

This should now work:

http://sage.math.washington.edu/home/emil/

Post by William A Stein

Post by Emil Widmann
Oh, I see. I got reports from people who couldn't donwload my stuff. I was
not much interested over the last 2-3 years and from what I can see
paradigmas have changed. From postings I read Prof. Stein thinks that
commercialising via the SageCloud is the way to go to.

That's the way *I'm* going to increase easy availability of Sage. I
really hope other people
like you will continue to work on and support all ways of gaining
access to Sage.
William

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann
https://groups.google.com/forum/#!topic/sage-windows/yoAcv8W5Fw0

Post by Volker Braun
Maybe yes, maybe no. Which steps did you do to get the output?

Post by Emil Widmann
wine should work

Post by Volker Braun
How do I build it from a script on Linux?

Post by Emil Widmann

Post by Jori Mantysalo

Post by Emil Widmann

Post by Jori Mantysalo
However, can we put VirtualBox and Sage to one .exe? What is
really
needed
is to convert http://wiki.sagemath.org/SageAppliance to be just "1)
Download this .exe, 2) Doubleclick it, 3) Ready".

Yes, I wrote an installer which included the VirtualBox installer
and the
Sage Appliance inside one exe.

Then THIS is what we need!
And of course underlying sage system should start automatically, in
headless mode etc, if by all means possible. And open browser, so icon on
user's desktop would be shortcut to .bat that "just works". And to think
little more, maybe have sage binaries installed to virtual drive marked as
immutable image or (virtual) disk partition mounted as read-only.

here is the link to the Sage Win installer
https://www.dropbox.com/s/uq9p60hkttr3ail/Sage-Win-Installer.exe?dl=0
It will install Virtualbox and Sage.ova with one exe installer. it is
ca 490 MB size.
sage version is outdated and it still contains a full VM with X and
desktop, but you can start notebook and then use the windows browser. Enough
to test as a protoype.
best regards
emil

--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
***@uw.edu

[Emil Widmann]

Thank you. I am still reading posts here and blog posts. Do you think a
sleak windows version would interfere with you plans of SCM and the goal to
raise funding for further developement?

Post by William A Stein

Post by William A Stein

Post by Emil Widmann

Post by Volker Braun
Links don't work (home directories on boxen are private now)

I'm happy to change any to be public, on a case-by-case basis. I was
just having too much trouble with people posting illegal books
publicly, then I get contacted by angry publishers and authors.

http://sage.math.washington.edu/home/emil/

Post by William A Stein

Post by Emil Widmann
Oh, I see. I got reports from people who couldn't donwload my stuff. I

was

Post by William A Stein

Post by Emil Widmann
not much interested over the last 2-3 years and from what I can see
paradigmas have changed. From postings I read Prof. Stein thinks that
commercialising via the SageCloud is the way to go to.

That's the way *I'm* going to increase easy availability of Sage. I
really hope other people
like you will continue to work on and support all ways of gaining
access to Sage.
William

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann
https://groups.google.com/forum/#!topic/sage-windows/yoAcv8W5Fw0

Post by Volker Braun
Maybe yes, maybe no. Which steps did you do to get the output?

Post by Emil Widmann
wine should work

Post by Volker Braun
How do I build it from a script on Linux?

Am Freitag, 29. August 2014 07:36:05 UTC+2 schrieb Jori

Post by Jori Mantysalo

Post by Emil Widmann

Post by Jori Mantysalo
However, can we put VirtualBox and Sage to one .exe? What is
really
needed
is to convert http://wiki.sagemath.org/SageAppliance to be

just

Post by William A Stein

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

Post by Jori Mantysalo

Post by Emil Widmann

Post by Jori Mantysalo
"1)
Download this .exe, 2) Doubleclick it, 3) Ready".

Yes, I wrote an installer which included the VirtualBox

installer

Post by William A Stein

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

Post by Jori Mantysalo

Post by Emil Widmann
and the
Sage Appliance inside one exe.

Then THIS is what we need!
And of course underlying sage system should start automatically,

in

Post by William A Stein

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

Post by Jori Mantysalo
headless mode etc, if by all means possible. And open browser,

so

Post by William A Stein

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

Post by Jori Mantysalo
icon on
user's desktop would be shortcut to .bat that "just works". And

to

Post by William A Stein

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

Post by Jori Mantysalo
think
little more, maybe have sage binaries installed to virtual drive
marked as
immutable image or (virtual) disk partition mounted as

read-only.

Post by William A Stein

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

here is the link to the Sage Win installer

https://www.dropbox.com/s/uq9p60hkttr3ail/Sage-Win-Installer.exe?dl=0

Post by William A Stein

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

It will install Virtualbox and Sage.ova with one exe installer.

it is

Post by William A Stein

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

ca 490 MB size.
sage version is outdated and it still contains a full VM with X

and

Post by William A Stein

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

desktop, but you can start notebook and then use the windows

browser. Enough

Post by William A Stein

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

Post by Emil Widmann

Post by Volker Braun

to test as a protoype.
best regards
emil

--
You received this message because you are subscribed to the Google

Groups

Post by William A Stein

Post by Emil Widmann
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send

an
<javascript:>.

Post by William A Stein

Post by Emil Widmann
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[kcrisman]

Post by Emil Widmann
Thank you. I am still reading posts here and blog posts. Do you think a
sleak windows version would interfere with you plans of SCM and the goal to
raise funding for further developement?

Post by William A Stein
That's the way *I'm* going to increase easy availability of Sage. I

Post by William A Stein
really hope other people
like you will continue to work on and support all ways of gaining
access to Sage.

I think this answers your question as "go for it and make a sleek Windows
version"!

[Jori Mantysalo]

Post by Emil Widmann
here is the link to the Sage Win installer
https://www.dropbox.com/s/uq9p60hkttr3ail/Sage-Win-Installer.exe?dl=0

Slow link. Here's faster: http://www.sis.uta.fi/~jm58660/sage-win.exe

As for testing, I am awaiting report from my wife.

[Dima Pasechnik]

Post by Bill Hart
I am again very interested in having Windows 64 ports of various packages.
* GAP
* Singular
* Pari/GP

by the way, GAP once used to support OS 9, the old Apple's OS, natively.
(not sure at what point this was removed)

Surely, if one persists, it can be ported to MinGW-64, too. There is
relatively
little code to change, most nontrivial would be GAP's garbage collector.

Trouble is, GAP builds runs reasonably well under Cygwin, so there is not
much momentum
towards such a port.
Although patches for such a port would be welcome, I suppose.

Post by Bill Hart
Note that MinGW2 is a much better way to do this than has previously been
available. It builds packages in a tiny fraction of the time it takes to
build with MinGW. It also fixes the broken parallel make that was in MinGW.
It has a nice package manager. The compiler seems stable. It 1000% better
in every way. In my opinion, a more or less native port of various packages
to MinGW2 is quite feasible.
Note that the flint library generated only two warnings with MSVC after we
got it building with MinGW2.
The biggest problem by far is the upstream projects who do not accept
patches into their repositories to support Windows, and aren't willing to
make the changes to their codebase to support Windows 64. Nor do they
continue to maintain the ports once it is done.
This attitude in the Open Source community to Windows 64 really bugs me.
It's a decade old technology, and not going anywhere.
A port of Sage to Windows 64 is probably not a viable project. It would
take years of effort by numerous individuals to accomplish. And it would
bitrot before it was even completed. But the fact that it isn't viable
right now doesn't mean that upstream projects shouldn't support Windows 64
so that if Sage ever wants to do such a port, it would be possible.
* flint
* gmp/mpir
* mpfr
* gmp-ecm
* GNU Scientific library
They support Windows fully. In fact, these projects even build on MSVC
thanks to years of effort by Brian Gladman.
For those unfamiliar with what a port to native Windows means, here is a
description of the steps involved for an ANSI C project (it's slightly
easier to port C99 projects to MinGW2 than ANSI C, but the MSVC compiler
* Replace all occurrences of long and unsigned long with alternative types
(e.g. slong, ulong in flint or mp_limb_signed_t, mp_limb_t in GMP) since a
long is only 32 bits on 64 bit Windows
* Ensure memory allocations do not mix allocating pointers and
words/limbs, e.g. long * a =malloc(32*sizeof(long)); void ** b = (void **)
a + 16;
* Replace all format specifiers for printf, scanf, fscanf, sscanf. This
usually implies creating a project_printf function, for example, which
accepts all the usual format specifiers, but provides new ones (e.g. %wd,
%wu) for printing e.g. slong and ulong on Windows. Then use the new
project_flintf/scanf, etc ubiquitously.
* Replace all integer constant literals, e.g. 123L with a macro, e.g.
WORD(123) which expands to 123L or 123LL depending on the platform. Similar
macro UWORD(123) for 123UL. Use ubiquitously.
* Place all code that requires posix functionality (pipes, etc) inside
guards so it is not built on Windows. If the functionality is important to
retain as part of the core functionality, Windows equivalents need to be
implemented. For mathematical software written in C, this is usually not
common. For other kinds of software, this can be a massive task.
* If you wish to support MSVC, some code may need to be ported from C99
back to ANSI C style. This is not as difficult nowadays as it used to be.
MSVC is about 90% of the way there now. They for example support mixing
declarations with other code, they have numerous C99 headers available and
so on.
* Replace intrinsics with Windows equivalents. Most of them exist on
Windows too, just with different names.
* Rewrite code which uses GNU C extensions. (This is not usually a big
project.)
Porting an assembly language project is quite a lot of work.
* There is no inline assembler in MSVC on 64 bit Windows. So there has to
be fallback C for this platform.
* Windows uses a different ABI for assembly functions than Linux, say. One
way around this is to write macros (such as the ones in GMP) which change
the order of registers on the way into and out of an assembly function
(only the ones actually used in the function). This is usually acceptable
because it doesn't affect any loops, except for perhaps moving them to
different alignments in memory. You can expect about a 5-10% slowdown with
this method. Given the scale of effort that would be required to rewrite
all the x86_64 assembly code in a project specially for Windows, this is an
acceptable compromise. (We use a different solution in MPIR. We have a lot
of our assembly code written in Yasm, which works on Linux and Windows. We
have separate assembly versions for many functions.)
* If you are porting to MSVC, you might like to support stack unwinding.
This is quite a bit of work, but Brian Gladman does it for example for
MPIR. It is my understanding that GMP doesn't do this, however I have not
checked recently to see if this is still the case.
Of course quite a lot of build system work may be necessary, even if using
Autotools, for either C or assembly projects. Some versions of Autotools
break the build on Windows, so you have to find a version which works on
that platform.
It's definitely much easier to port a project to Windows in four steps.
Linux -> Cygwin -> Cygwin 64 -> MinGW64 -> MSVC. The biggest step is from
Cygwin64 -> MinGW64. The last step is very easy nowadays. It can be done
for a medium sized project (150,000 lines of C code) in a couple of man
weeks, most of which is just fixing bugs that didn't show up on Linux/GCC.
I understand that Sage uses things like Lisp, Java, Python, Cython, etc.
So the above doesn't help much with Sage overall. But perhaps it will help
raise awareness for projects that are using C and assembly only.
Bill.
On Monday, 25 August 2014 10:15:41 UTC+2, Dr. David Kirkby (Kirkby

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
It seems Sage really could do with a native windows port. I am wondering
how practical it would be to make a version which is a subset of Sage, with
something like Qt which runs on Windows, Linux, OSX and Solaris and has
the look and feel of those platforms.
It could make a Google Summer of Code project.
If a small subset could be implemented, the chances are reasonable that
others might port more bits. If it could do more than a scientific
calculator, that would probably be enough to get people using it. Call it
"Mini Sage" or something similar to indicate it is not the full version.
I believe that there are some are some bits of Sage that uses fork and
has have no Windows equivalent, so those bits could be left out. Perhaps at
a later date a complete rewrite of such bits could form other GSOC
projects.
The download size of such a subset would be smaller than the full version
and MUCH smaller that a virtual machine image, as one doesn't need to
include a complete operating system too.
Wolfram Research did at one point offer a subset of Mathematica, which i
think was called Calc Centre, but I think it was a bit of a flop, so I
don't think that they sell it any more. That might be an argument for not
doing a partial native port.
If a partial port was done, avoiding the need for a browser, one could
use its own parser and provide a more confident interface. Although many
are critical of Mathematica's interface, it is more consistent than that
of Sage.
Dave

[Harald Schilly]

On Monday, August 25, 2014 10:15:41 AM UTC+2, Dr. David Kirkby (Kirkby

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
It seems Sage really could do with a native windows port.

Just my 2 cents (after not really reading the whole thread)
What about andLinux, which also has an X server included?
http://www.andlinux.org/

... and since that website looks kind of dead, underneath is coLinux which
is still active
http://www.colinux.org/

-- H

[William A Stein]

On Wed, Aug 27, 2014 at 8:41 AM, Harald Schilly

Post by maldun
On Monday, August 25, 2014 10:15:41 AM UTC+2, Dr. David Kirkby (Kirkby

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
It seems Sage really could do with a native windows port.

Just my 2 cents (after not really reading the whole thread)
What about andLinux, which also has an X server included?
http://www.andlinux.org/
... and since that website looks kind of dead, underneath is coLinux which
is still active
http://www.colinux.org/

For a while the sage-for-windows distribution I produced was based on
colinux/andlinux. The main reason I discontinued support was that
every time I watched people install Sage-for-windows via co-linux, I
then saw (or heard reports) of it completely crashing MS Windows...
repeatedly. Also, getting networking to work properly is a pain...
support is much worse than with VirtualBox or VMware.

William

Post by maldun
-- H
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org
***@uw.edu

[Dr. David Kirkby (Kirkby Microwave Ltd)]

Post by maldun
On Monday, August 25, 2014 10:15:41 AM UTC+2, Dr. David Kirkby (Kirkby

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
It seems Sage really could do with a native windows port.

Just my 2 cents (after not really reading the whole thread)
What about andLinux, which also has an X server included?
http://www.andlinux.org/

Looks interesting. Not a native port as I origially suggested, but
possibly a better way than a virtual machine.

Post by maldun
... and since that website looks kind of dead, underneath is coLinux which
is still active
http://www.colinux.org/

Maybe I missed it, but it did not look to me as if there was any code
published in a few years, but the website seems to have been updated.



Dr. David Kirkby Ph.D CEng MIET
Kirkby Microwave Ltd
Registered office: Stokes Hall Lodge, Burnham Rd, Althorne, Essex, CM3 6DT, UK.
Registered in England and Wales, company number 08914892.
http://www.kirkbymicrowave.co.uk/
Tel: [phone] (0900 to 2100 GMT only please)

[Harald Schilly]

On Wed, Aug 27, 2014 at 8:54 AM, Dr. David Kirkby (Kirkby Microwave

Post by Dr. David Kirkby (Kirkby Microwave Ltd)
Maybe I missed it, but it did not look to me as if there was any code
published in a few years, but the website seems to have been updated.

yes, you are right, i only saw "2014" on the front page, not much else.
maybe it's due to what william said.

is there any other "compatibility layer" with linux in windows?

The "SUA" unix extension for windows servers is also deprecated.
Microsoft itself points instead to either Hyper-V-it or cygwin, mingw
or mingw-64bit

-- h