Re: [sage-combinat-devel] cristallographic takes two l
Yes indeed, and that is what I have done in the patch. Sorry for the mistake here. Le vendredi 31 mai 2013 22:44:37 UTC+2, Anne Schilling a écrit : Hi Frederic, If you want the English spelling, I think it is crystallographic. Best, Anne On 5/31/13 12:41 PM, Fr�d�ric Chapoton wrote: And it is spelled in sage/combinat with just one ! I have made a (little bomb) patch at http://trac.sagemath.org/sage_trac/ticket/14673 turning everything to cristallographic I think this is necessary, but I am afraid it may cause a lot of trouble in the combinat queue Opinions ? Frederic -- You received this message because you are subscribed to the Google Groups sage-combinat-devel group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: recompilation with sage -clone
John H Palmieri wrote: On Thursday, May 30, 2013 9:57:07 PM UTC-7, leif wrote: leif wrote: Looks like reinstalling the Sage library spkg would meanwhile also trigger the rebuild of *all* extension modules; not sure since when though... (seen with Sage 5.10.beta5 at least) Yep. This is because #14570, merged into Sage 5.10.beta4, completely breaks sage-sync-build, which is also used in the Sage library's spkg-install. (sage -sync-build now removes all Cython-generated files, hence *all* have to get rebuilt afterwards.) IMHO both issues (complete rebuild upon cloning and after sage-sync-build) should be resolved before the final 5.10 gets out. The rebuild is dealt with at #13245 (needs partial review). I'll revisit #13245 now that you've changed the ticket's title... ;-) [Avoiding also the rebuild of the fast_callable interpreters should be feasable by just copying a few more files in sage-clone (I /think/ I already did that), but I agree that's a minor issue, at least compared to rebuilding the whole Sage library.] Is there a ticket for the sage-sync-build problem? Not yet. There are a couple of ways to (quickly or temporarily) fix this: 1) Unmerge #14570, which doesn't fix a bug, but only introduces a new (btw. non-configurable) feature. [A bit odd, especially since #14570 also patches the Cython spkg.] 2) Revert just #14570's change to setup.py, a one-liner (removing the build_dir parameter to cythonize()). [Better than 1), although effectively the same -- feature vanishes until we reenable it on some follow-up ticket.] 3) Make the behaviour configurable (defaulting to the previous; little change to setup.py). No breakage to ordinary users; people using the new feature are expected to know what they're doing, i.e., at least sage-sync-build [still] won't work for them. [IMHO preferable for a temporary / quick fix; easy and safe.] 4) Minimally adapt sage-sync-build.py to reflect the (hard-coded) change by #14570. [May be easy as well, but potentially unsafe.] I'd personally prefer 2) or 3) for now, postponing a proper solution to a follow-up ticket which presumably won't make it into 5.10 (but hopefully 5.11.*), as sage-sync-build needs some rework* anyway, the Cython build directory (kind of VPATH) should IMHO be configurable, and #14570 might cause further issues we haven't noticed yet. -leif __ * the usual can of worms -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- 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 email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: recompilation with sage -clone
leif wrote:
John H Palmieri wrote:
Is there a ticket for the sage-sync-build problem?
Not yet. There are a couple of ways to (quickly or temporarily) fix
this:
1) Unmerge #14570, which doesn't fix a bug, but only introduces a new
(btw. non-configurable) feature. [A bit odd, especially since #14570
also patches the Cython spkg.]
2) Revert just #14570's change to setup.py, a one-liner (removing the
build_dir parameter to cythonize()). [Better than 1), although
effectively the same -- feature vanishes until we reenable it on some
follow-up ticket.]
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -532,7 +532,7 @@
ext_modules = cythonize(
ext_modules,
nthreads = int(os.environ.get('SAGE_NUM_THREADS', 0)),
-build_dir = 'build/cythonized',
+# build_dir = 'build/cythonized',
force=force)
open(version_file, 'w').write(Cython.__version__)
works for me (with Sage 5.10.rc0).
3) Make the behaviour configurable (defaulting to the previous; little
change to setup.py). No breakage to ordinary users; people using the
new feature are expected to know what they're doing, i.e., at least
sage-sync-build [still] won't work for them. [IMHO preferable for a
temporary / quick fix; easy and safe.]
Similar to the above change, but with (say)
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -532,7 +532,7 @@
ext_modules = cythonize(
ext_modules,
nthreads = int(os.environ.get('SAGE_NUM_THREADS', 0)),
-build_dir = 'build/cythonized',
+build_dir = 'build/cythonized' if
os.environ.get(BREAK_SAGE_SYNC_BUILD, no)==yes else None,
force=force)
open(version_file, 'w').write(Cython.__version__)
which *optionally* enables building extension modules out of tree
(they're in fact in the same tree, but one level deeper, still
hard-coded location) at the expense of breaking (at least)
sage-sync-build. (Works for me, too.)
-leif
4) Minimally adapt sage-sync-build.py to reflect the (hard-coded) change
by #14570. [May be easy as well, but potentially unsafe.]
I'd personally prefer 2) or 3) for now, postponing a proper solution
to a follow-up ticket which presumably won't make it into 5.10 (but
hopefully 5.11.*), as sage-sync-build needs some rework* anyway, the
Cython build directory (kind of VPATH) should IMHO be configurable, and
#14570 might cause further issues we haven't noticed yet.
-leif
__
* the usual can of worms
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
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 email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: 3 GSoC projects for Sage
I know that this is not exactly about the windows port situation, but still, it is closely related to the sage-on-windows issue: On the project ideas suggestions that were proposed by sage, there was one dedicated to writing a GUI to handle the sage installation in windows. No student decided to propose such a project. On the other hand, there are people working on a cygwin port. I haven't tested it, but they claim to have obtained something usable. So it is not true at all that the windows port has been abandoned. What it is true, on the other hand, is that the prefered way to run sage on windows is through the virtualbox appliance. This is maybe a suboptimal solution, but it's a solution that works. So the statement that we are ignoring the windows is far from being true. -- 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 email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: 3 GSoC projects for Sage
On Friday, May 31, 2013 3:21:06 AM UTC-7, Volker Braun wrote: On Friday, May 31, 2013 7:39:02 AM UTC+1, rjf wrote: Interesting perspective. Where did you get the $10k/year difference? http://www.indeed.com/salary?q1=Unix+System+Administratorq2=windows+System+Administrator This is an interesting resource. Here's some more data from the same source. Unix Systems Administrator$88,000. Windows Systems Administrator $77,000. Lisp Programmer $95,000. Python Programmer $89,000 -- 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 email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: 3 GSoC projects for Sage
On Friday, May 31, 2013 5:25:39 AM UTC-7, kcrisman wrote: I think the mentor thing is a red herring, though; the number of projects proposed on Windows probably would roughly match the number of mentors (at least by proportion), because you wouldn't likely get interested in Sage development in the first place unless you were on Linux or Mac. My assumption was that the number of mentors willing and capable of supervising a Windows port was, most likely, zero. It's the kind of expertise that is probably not so common among mathematicians. So I agree that the number might match, proportionally. My point was that Google goals were consistent with a possible (student-proposed) project of porting Sage to native Windows framework. -- 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 email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: 3 GSoC projects for Sage
On Saturday, June 1, 2013 6:16:59 AM UTC-7, mmarco wrote: On the other hand, there are people working on a cygwin port. I haven't tested it, ... Why is it suboptimal? (one guess: you can't have a one-click windows installer?) I thought this had been done some time ago -- a cygwn solution. It also seemed to me that there was an undercurrent of activity to get a native windows version. I'm not sure why this was viewed as valuable -- certainly there are some neat things on Windows that are not on Linux, but just as certainly Sage can't depend on them... people would be upset if Sage on windows had better features and could not be back-ported to Linux. Anyway, maybe we will all meet in the cloud. -- 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 email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: 3 GSoC projects for Sage
rjf wrote: On Friday, May 31, 2013 3:21:06 AM UTC-7, Volker Braun wrote: On Friday, May 31, 2013 7:39:02 AM UTC+1, rjf wrote: Interesting perspective. Where did you get the $10k/year difference? http://www.indeed.com/salary?q1=Unix+System+Administratorq2=windows+System+Administrator http://www.indeed.com/salary?q1=Unix+System+Administratorq2=windows+System+Administrator This is an interesting resource. Here's some more data from the same source. Unix Systems Administrator$88,000. Windows Systems Administrator $77,000. Lisp Programmer $95,000. Python Programmer $89,000 Demanding William's Lisp port of Sage even more. (Although I have to admit I haven't checked whether there are figures for Cython programmers as well.) -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- 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 email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: 3 GSoC projects for Sage
On Saturday, June 1, 2013 4:51:39 PM UTC+2, rjf wrote: Lisp Programmer $95,000. I raise you the VAX Mainframe: $100,000 http://www.indeed.com/salary?q1=vax+mainframe Welcome to the cloud! Could we stop this pointless discussion please? -- 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 email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] LELA for matrices?
I would like to have some discussion about the roadmap for matrices in Sage. It seems that linbox has essentially been forked by LELA (http://www.singular.uni-kl.de/lela). Since it optionally contains M4RI, one would think that it is a good fit for Sage, too. Has anybody given any thoughts to switching Sage from linbox to LELA? In particular, Burcin and Martin should have an opinion and it would be nice to hear from them ;-) On a related note, sparse matrices in Sage suck (dictionary of keys). Sparse matrices in LELA only suck slightly less (list of lists). For fast computation one should implement compressed sparse row/column, I think. -- 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 email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: 3 GSoC projects for Sage
rjf wrote: On Friday, May 31, 2013 5:25:39 AM UTC-7, kcrisman wrote: I think the mentor thing is a red herring, though; the number of projects proposed on Windows probably would roughly match the number of mentors (at least by proportion), because you wouldn't likely get interested in Sage development in the first place unless you were on Linux or Mac. My assumption was that the number of mentors willing and capable of supervising a Windows port was, most likely, zero. It's the kind of expertise that is probably not so common among mathematicians. So I agree that the number might match, proportionally. My point was that Google goals were consistent with a possible (student-proposed) project of porting Sage to native Windows framework. Modulo the time frame. -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- 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 email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] LELA for matrices?
Hi, as far as I know LELA does not support the same operations as LinBox, it's not a straight-forward fork but a re-implementation of a subset (that's my understanding, anyway). it has some advantages, i.e., that some bits nicely generic, i.e., it should be fairly easy to add new matrix types by adding stuff like matrix-matrix multiplication and e.g. PLE decomposition is handled generically. Also, the main developer of LELA Bradford has left academia. He usually responds fairly quickly to e-mail and is up for helping out, but as far as I know nobody is actively developing LELA at the moment (I might be terribly wrong here!) On Saturday 01 Jun 2013, Volker Braun wrote: I would like to have some discussion about the roadmap for matrices in Sage. It seems that linbox has essentially been forked by LELA (http://www.singular.uni-kl.de/lela). Since it optionally contains M4RI, one would think that it is a good fit for Sage, too. Has anybody given any thoughts to switching Sage from linbox to LELA? In particular, Burcin and Martin should have an opinion and it would be nice to hear from them ;-) On a related note, sparse matrices in Sage suck (dictionary of keys). Sparse matrices in LELA only suck slightly less (list of lists). For fast computation one should implement compressed sparse row/column, I think. Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6532AFB4 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://martinralbrecht.wordpress.com/ _jab: martinralbre...@jabber.ccc.de signature.asc Description: This is a digitally signed message part.
Re: [sage-devel] LELA for matrices?
My understanding is that only a very small subset of linbox is wired into Sage. In particular, all the iterative methods for the [rank/minpoly/charpoly/det] of sparse matrices are not accessible yet, but they are Linbox's strong point. Currently, sparse matrices are converted to dense ones, and very generic cython code is then used. Recent versions of linbox have some support for (read-only) compressed row matrices. --- Charles Bouillaguet http://www.lifl.fr/~bouillaguet/ On Jun 1, 2013, at 6:48 PM, Martin Albrecht wrote: Hi, as far as I know LELA does not support the same operations as LinBox, it's not a straight-forward fork but a re-implementation of a subset (that's my understanding, anyway). it has some advantages, i.e., that some bits nicely generic, i.e., it should be fairly easy to add new matrix types by adding stuff like matrix-matrix multiplication and e.g. PLE decomposition is handled generically. Also, the main developer of LELA Bradford has left academia. He usually responds fairly quickly to e-mail and is up for helping out, but as far as I know nobody is actively developing LELA at the moment (I might be terribly wrong here!) On Saturday 01 Jun 2013, Volker Braun wrote: I would like to have some discussion about the roadmap for matrices in Sage. It seems that linbox has essentially been forked by LELA (http://www.singular.uni-kl.de/lela). Since it optionally contains M4RI, one would think that it is a good fit for Sage, too. Has anybody given any thoughts to switching Sage from linbox to LELA? In particular, Burcin and Martin should have an opinion and it would be nice to hear from them ;-) On a related note, sparse matrices in Sage suck (dictionary of keys). Sparse matrices in LELA only suck slightly less (list of lists). For fast computation one should implement compressed sparse row/column, I think. Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6532AFB4 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://martinralbrecht.wordpress.com/ _jab: martinralbre...@jabber.ccc.de -- 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 email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: recompilation with sage -clone and after sage -sync-build
leif wrote:
leif wrote:
John H Palmieri wrote:
Is there a ticket for the sage-sync-build problem?
Not yet. There are a couple of ways to (quickly or temporarily) fix
this:
1) Unmerge #14570, which doesn't fix a bug, but only introduces a new
(btw. non-configurable) feature. [A bit odd, especially since #14570
also patches the Cython spkg.]
2) Revert just #14570's change to setup.py, a one-liner (removing the
build_dir parameter to cythonize()). [Better than 1), although
effectively the same -- feature vanishes until we reenable it on some
follow-up ticket.]
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -532,7 +532,7 @@
ext_modules = cythonize(
ext_modules,
nthreads = int(os.environ.get('SAGE_NUM_THREADS', 0)),
-build_dir = 'build/cythonized',
+# build_dir = 'build/cythonized',
force=force)
open(version_file, 'w').write(Cython.__version__)
works for me (with Sage 5.10.rc0).
3) Make the behaviour configurable (defaulting to the previous; little
change to setup.py). No breakage to ordinary users; people using the
new feature are expected to know what they're doing, i.e., at least
sage-sync-build [still] won't work for them. [IMHO preferable for a
temporary / quick fix; easy and safe.]
Similar to the above change, but with (say)
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -532,7 +532,7 @@
ext_modules = cythonize(
ext_modules,
nthreads = int(os.environ.get('SAGE_NUM_THREADS', 0)),
-build_dir = 'build/cythonized',
+build_dir = 'build/cythonized' if
os.environ.get(BREAK_SAGE_SYNC_BUILD, no)==yes else None,
force=force)
open(version_file, 'w').write(Cython.__version__)
which *optionally* enables building extension modules out of tree
(they're in fact in the same tree, but one level deeper, still
hard-coded location) at the expense of breaking (at least)
sage-sync-build. (Works for me, too.)
-leif
4) Minimally adapt sage-sync-build.py to reflect the (hard-coded) change
by #14570. [May be easy as well, but potentially unsafe.]
Even that turns out to be non-trivial, AFAICS, i.e., the whole strategy
would have to get changed, as opposed to just some file / directory
names in a few places.
-leif
I'd personally prefer 2) or 3) for now, postponing a proper solution
to a follow-up ticket which presumably won't make it into 5.10 (but
hopefully 5.11.*), as sage-sync-build needs some rework* anyway, the
Cython build directory (kind of VPATH) should IMHO be configurable, and
#14570 might cause further issues we haven't noticed yet.
-leif
__
* the usual can of worms
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
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 email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: GSoC New decoding error-correcting codes algorithm for Sage
Welcome on board, Veronica. Please keep us up to date to your progress. I am your mentor, but i am sure the rest of the sage community would like to have you involved. Just a little clarification: Veronica has been selected under the umbrella of lmonade, even thoigh her work will be focused on sage. -- 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 email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[sage-devel] Re: 3 GSoC projects for Sage
I haven't tested it, ... Why is it suboptimal? I used the word suboptimal to reffer to the virtualbox based solution, not to the cygwin one. If by native you mean without cygwin... i am afraid that that we would be very far away from that. Not only from the sage side (at the end of the day, most of the code writen by sage devs is portable python/cython), but from the thirthd party pieces: Singular is not natively ported to windows (runs under cygwin), GAP for windows uses cygwin too, Pari/gp also runs under cygwin (and has limitations compared to the linux version)... So the native windows port of sage is really unlikely to happen in the mid term. Considering that, Sage releases official versions that work under windows (via virtualbox), and also a cygwin port is being worked on (although it is true that, with the virtual machine available, this has become a secondary effort). And since you mention the one-click installer... that was pretty much what the GUI project that we suggested was about. As i said, no student showed interest in working on that. As i said, the statement that the sage project is turning its back on windows system is far from being true. -- 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 email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: 3 GSoC projects for Sage
On Thursday, 30 May 2013 12:21:25 UTC-7, rjf wrote: I repeat. Generating random arguments is not sensible. (Incidentally, you will still need to be able to generate the correct answers for these functions. This seems to have been overlooked. What do you do if your benchmark test shows slightly different answers from the systems?) My point is that this is poorly formulated as a question, and the proposed answer is also poorly thought out. Hello, Do you have any suggestions on how to benchmark the different backends other than pick random arguments from specified domains? I'm open to any suggestions. In any case, the benchmark framework is going to be a relatively minor part of the project. Eviatar -- 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 email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [sage-devel] Re: 3 GSoC projects for Sage
On Sat, Jun 1, 2013 at 3:47 PM, mmarco mma...@unizar.es wrote: I haven't tested it, ... Why is it suboptimal? I used the word suboptimal to reffer to the virtualbox based solution, not to the cygwin one. If by native you mean without cygwin... i am afraid that that we would be very far away from that. Not only from the sage side (at the end of the day, most of the code writen by sage devs is portable python/cython), but from the thirthd party pieces: Singular is not natively ported to windows (runs under cygwin), GAP for windows uses cygwin too, Pari/gp also runs under cygwin (and has limitations compared to the linux version)... So the native windows port of sage is really unlikely to happen in the mid term. Considering that, Sage releases official versions that work under windows (via virtualbox), and also a cygwin port is being worked on (although it is true that, with the virtual machine available, this has become a secondary effort). And since you mention the one-click installer... that was pretty much what the GUI project that we suggested was about. As i said, no student showed interest in working on that. As i said, the statement that the sage project is turning its back on windows system is far from being true. One tidbit to add to this discussion (which has gone on way too long), is that in my experience often compute intensive functions in Sage are faster on Windows when run on a VM than when run under Cygwin or natively. There are many reasons for this, including LInux's excellent memory management, special optimizations people writing code make for the Linux version of some code, but don't make anywhere else, etc. -- William -- 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 email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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 email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
