On Friday, 9 October 2015 00:38:37 UTC+2, William wrote: > > >>> On cygwin32 the result was decent. > >> > >> > >> > >> How many people *use* it? > > > > Not even me! > > I guess it misses advertising, proper packaging, proper testing, proper > > continuous integration, ... > > The last few times I spent months on Windows porting, the net result > of using Cygwin was -- in practice -- so much worse than just using a > Linux VM, that nobody would actually use it. I don't want to > minimize the great value of the work you've done, but I was never > convinced that Cygwin sage was actually viable at all. >
What were the main issues? Were they mainly in the build process or in actually using Sage? Some ways to possibly improve it might be: * Have a script that downloads binaries for all the dependencies of Sage (still keep the source code intact of course) so that these don't need to be built to use it. * Peg to a commit that is known to work (and for which binaries are available), but naturally allow the user to advance to later commits and rebuild anything that needs to be rebuilt. * Ensure that rebuilding Sage only rebuilds those binary dependencies that have actually been changed when doing a git pull. * Advertise it. * Give some idea to users how long it is expected to take on a modern Windows laptop to get up and running from scratch, including an estimate for download of source and binaries on a certain speed internet connection. People want to know if they can fit it in between lectures or if it will tie up their machine for the next week and a half. * Link to the BLODA. * MSYS2 might be nicer in the long run. It has a command line package manager, so you don't need to tell users to get this and that dependency even before starting. Admittedly not all the dependencies you ask for are there yet. MSYS2 is also itself quicker and nicer to install in my experience. * Provide a binary only version for people who want to try it out first, or who really don't want to do any development. * I still think some more modularisation of Sage would help. Anything that isn't needed to do computations in Sage could be separate. Some particularly expensive parts of sage bloat-wise could also have hooks that just tell you that such and such is missing, and telling you precisely what you have to type to get it, like what happens in the shell in Ubuntu. People will use it if it is practical to do so, especially if others are using it and word gets about. If it's clear that it won't ever be practical, then maybe another strategy is needed. I was curious about the comment on the Cygwin64 port page where Pari declared 131 composite. Knowing just how little is involved in that computation, it's hard to understand how that happened on Cygwin 64. Was this Cygwin related? Bill. -- 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. For more options, visit https://groups.google.com/d/optout.
