On Wednesday, October 7, 2015 at 8:08:30 PM UTC+2, Bill Hart wrote: > > > > On Wednesday, 7 October 2015 19:54:30 UTC+2, Dima Pasechnik wrote: >> >> >> >> On Wednesday, 7 October 2015 07:35:22 UTC-7, Bill Hart wrote: >>> >>> HI all, >>> >>> William Stein recently bemoaned the fact that SageMath currently only >>> runs natively on some brands of Linux, and not natively on the latest >>> Windows or OSX (that is to say nothing of BSD). [1] >>> >>> Until recently, a port of SageMath to Windows has seemed like a pipe >>> dream. However, things have changed a lot, and I think it would now be >>> possible to achieve this (for some definition of the word "native"). >>> >>> I've tried VM's before and it has always ended in disaster. They either >>> screw up my networking, they have performance issues, or don't support my >>> mouse properly, or change my keyboard layout, or it's impossible to get >>> files from my hard drive into the system easily, or they take up too much >>> disk space or need to be constantly downloaded to update them, or some >>> features don't work, or people stop supporting them, etc. The disadvantages >>> of VMs are so numerous I hardly need to enumerate them. And even if it is a >>> solution for users, it's hardly a solution for serious Windows developers. >>> >>> As some people know, I've been recently working on a Julia based >>> "computer algebra system" for a much more limited subset of "computer >>> algebra" than Sage targets. What people may not know is that that entire >>> technology stack works natively on Windows. >>> >>> I can't express how fantastic it was to be sitting on a train recently, >>> with no web access whatsoever and to be able to do work on my Windows 10 >>> (64 bit) laptop on the train. And everything ran as fast, or in some cases >>> faster, than my Linux server. That's the first time that has happened since >>> I started doing computational stuff about 10 years ago! >>> >>> MSYS2 as a solution >>> ================ >>> >>> The new technology that makes all this work is MSYS2. Here are some of >>> its features: >>> >>> * Installing MSYS2 on Windows couldn't be easier. [2] >>> * It supports proper Windows exception handling protocols. >>> * It has an amazing command line package manager called Pacman, which >>> Just Works TM. >>> * Unlike Cygwin, it's very minimal, and takes little time to install. >>> * It's fast. Very fast. >>> * Parallel make works. >>> * The resulting binaries are fast, sometimes faster on my laptop than on >>> the Linux server I usually use for development. >>> * MSYS2 provides a posix layer! (Applications can be distributed with an >>> MSYS2 dll for this.) >>> * Multithreading using pthreads Just Works TM (Applications can be >>> distributed with a winthreads dll for this. I've actually used this, no >>> patching required, so I am not speaking theoretically here.) >>> * Like native Windows, sizeof(long) = 4 and sizeof(long long) = 8 on >>> MSYS2. This means interop with native Windows applications or assembly >>> objects is a cynch. >>> * The resulting applications can be run on Windows as essentially native >>> applications. They don't have to be run from within the MSYS2 shell. They >>> can also be distributed as binary packages for those that don't care about >>> the source code. But here's the thing: it's not *necessary* to distribute >>> them as binary packages. It's now quite feasible for developers to actually >>> *build* packages on Windows. And let's face it, this is the type of >>> developer we actually want on the Windows platform. Simply supporting users >>> and not developers is just going to increase the maintenance burden for >>> people who work on other platforms. We want actual Windows developers, not >>> just users! >>> >>> The only bad thing about MSYS2 is that autotools is still incredibly >>> slow (Flint roll-your-own configure takes 5s at most on Windows, whereas >>> autotools can take some minutes to configure a package). Note: make is not >>> slow (at least not on Windows 64 -- it's not as fast on 32 bit Windows, but >>> fortunately almost no one is using Windows 32 any more anyway). >>> >> >> If MSYS2 has (Cygwin's?) fork(), it should not differ much from Cygwin, >> in the sense of porting of Sage. >> fork() was the major pain on Win32, as building Python extensions results >> in huge number of dlls that have hard time >> fitting into the (32bit) address space, so (semi)automatic running of >> rebase during the build was necessary... >> > > I am really, really uninterested in Windows 32, as are, I imagine, most > Windows developers these days. Given that Sage is so very far behind the > ball game on Windows, I would skip it entirely. You will likely have to > visit a museum to get a working Win32 box by the time the port is complete. > (This was already the case back when Sage started its Cygwin port). > Same issue for Windows64, that's basically the way DLLs work which makes fork unimplementable in a not-broken way on Windows. And yes, I'm quite sure MSYS2 has the same issue as Cygwin as MSYS2 is a frequently resynced fork of Cygwin.
-- 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.
