On May 16, 1:50 am, "William Stein" <[EMAIL PROTECTED]> wrote: > Hi Michael (cc: sage-devel and bcc: some sponsors),
Feel free to forward since there is no BCC in Google groups ;) > What's the quick status on: > > * OS X 64-bit porting Cleaning up patches. One crash issue related to libSingular's memory management code. Singular itself works in 64 bit mode on OSX 10.5, i.e. I computed some GBases with it without problems. There are 30 new tickets in trac and I am cleaning up patches [bsd: ~/OSX64] and will put up spkgs to be merged into 3.0.2.alpha1 shortly. > * Cygwin porting No work done, but I have a list of issues. > * MSVC porting No work done - I am waiting on licenses to setup up my build box. > * Solaris porting Progress on pure [i.e. no /opt/sfw] build. Starting to work on the Sun Forte build, but one libSingular issues [very likely coercion related] remains. Plan to investigate post 3.1. Sage 3.0.2 should build on neron with the right setup except small issues with rpy, cvxopt. and obviously clisp. I send you CCs on all the email I send to David and other people, so you can read all the gory details :) > * Itanium porting RHEL 5 with system compiler is 100% working. One doctest failure with gcc 4.3 due to compiler bug. Can probably be fixed by compiling extensions with "-O2". SLES10: clisp shits all over itself. Using clisp 2.44.2 with "-O0" fixes the issue. > I want to jump into something (and maybe get others to), but I don't know > which to do. > > Frankly, I think that now that Sage-3.0 is out and we basically (very roughly) > have the full range of features we want (modulo polish and little > things), porting > is by far what should be our current number one priority. If we don't > do it *NOW*, > then it could potentially be vastly harder later. If you had not been release > manager for the last 7 months, it *would* be vastly harder now. And > fortunately, > we now have over 50% doctest coverage, which will help a lot. > > Now is the time to port Sage. And it's going to take more than just you > working on it. I think your number one priority should be to get Sage > to build automatically as much as possible. But beyond that you should > let the rest of us do a lot of work making things actually work correctly. > > Here is *my* personal impression of the porting situation. > > I think the above five platforms should be our target for > the next year. Anything beyond that is to worry about later (e.g., iphone). That will be fun to do during a long weekend :) > Based on who is paying us the order of priority should be: > > 1. Itanium > 2. Cygwin > 3. Solaris > 4. MSVC > 5. OS X 64-bit OSX 64 bit is 99.5% done and also resulted in massive cleanups of spkg-installs for example, so it wasn't wasted time. > Based on difficulty and developer resources, I think the > order from easiest to hardest is: > > 1. Itanium > 2. OS X 64-bit > 3. Cygwin > 4. Solaris > 5. MSVC > > These match up except OS X 64-bit. Pretty much. > For each, here's my rough understanding of the status: > > 1. Itanium Linux: we need to incorporate Steve Linton's patches to Gap. > There is an issue with Singular, but maybe that is fixed. There are > issues making the build 100% automatic on SLES, and some possible > ATLAS build issues. GAP works as is with "-O0" and the current workaround. We could merge upstream patches for GAP, but I don't see it as a high priority. I got a fix for the ATLAS robustness issue, but 3.8.1 has better timers on Itanium and so the issue is harder to hit [I hit it once out of 10+ builds]. SLES itself suffers from some clisp build issues, but we have a workaround and I am hoping we will be able to dump it soon. ecls works fine on RHEL and SLES Itanium. > 2. OS X 64-bit. There are a huge slew of little issues. There are > several people who could and would love to work on this, but you're > currently heroically doing all the work. It will be a lot easier to get > help when Sage builds but goes boom on startup. This is hard > because OS X is a bi-arch build environment like Solaris. Assuming you set SAGE64=yes now things nearly build automatically. There are some small issues with gmp [we need 4.2.2 since that one only has 64 bit OSX support - switch to MPIR will help there] and need to update and spkg or two. Other than that all build issues are solved and I just need some cleanup and merge the build fixes back into the release. > 3. Cygwin: There are tons of liittle fixes and changes you > have posted to the wiki. When all these are applied, Sage mostly > builds. (?) There are some serious unresolved problems > involving libsingular. Otherwise this should be relatively > smooth sailing. (Three years ago when I ported Sage from > Linux to OS X and Cygwin, it was *much* easier to port > to Cygwin than OS X... but then Cygwin itself was fundamentally > broken by one very annoying Cygwin developer, etc., which made > for a very painful 6 months.) There are more issues, but none of the build issues are hard. libSingular will be a pain to get done, but since I have malb's stand alone test code I should be able to fix this. I also rediscovered some scripts by Gary Z. that remap DLLs which was also a problem I had prior to the 2.5.x release. Some long standing issues in the Cygwin port, i.e. the mysterious mwrank crashes have turned out to be real bugs in the eclib codebase and been fixed for months now. Since the Cygwin port is used as a stepping stone for MSVC this certainly has high priority. The reason no more detailed work has happened on Cygwin is that I have been waiting on licenses to set up my new test box and I plan to do the Cygwin build on there, too. If those licenses do not show up soon I will probably switch to an VMWare image just for the Cygwin build for now, but I would really like to avoid reinstalling all the build env again. > 4. Solaris: It's almost done, but a lot of things don't work. > Solaris support for Sage has been "nearly there" for 4 years; I know > since I have spent a lot of time on it. Lisp/Maxima sucks big time, but > at least Maxima's not a binary link to Sage, so we can worry about > that separately. I can build Sage on Solaris with little effort. David Kirkby has been testing the fixes I have proposed and he got to numpy when he tried with 3.0.2.alpha1, so build support is in pretty good shape. The numpy failure is realated to ATLAS being stupid with gld on Solaris, but I will spare you the details here since you got CCed on all that fun stuff last week. Once we get that pesky libSingular issue fixed [I suspect coercion] we are very close to a workable 32 bit gcc based build. Taking it to 64 bit and Sun Forte will take some heavy lifting, but is easy compared to the MSVC port. > 5. MSVC: Massive numbers of issues all over the place. > Well worth the effort. Your cup of tea (not mine). > Lack of pexpect for windows is a major problem. > > Anyway, in summary, we need to make Itanium Linux Sage absolutely 100% > solid ASAP, and make Sage work on Cygwin as well very soon. > OS X 64-bit will hopefully soon be more of a community effort. > Solaris is really a "the devil is in the details" thing, and we just need > to make it happen. > > Until Sage is ported to the above architectures (at least everything but MSVC), > we should be very very very reluctant to add any additional external standard > spkg's to Sage. That's my opinion at least. Yes. The bar is much higher and I do not see the need for anything else in the core that isn't trivially ported. I would discourage adding code to Sage which requires heavy lifting on my end at all costs ;). > Now's the time in the Sage life > cycle that we need to make damn sure Sage works on a really wide > range of machines. Otherwise we will start loosing potential users > left and right. I bet we've easily lost around 100 potential users > in the last > couple of days because of lack of sufficient sage ports. I seriously doubt that number, but not having a native Windows port is certainly a problem that needs and will be solved. > ""I'll give Sage another try when I get a new computer (which > hopefully isn't too far off), or when there is a native Sage for > windows. Thank you for your time. For now, I will stick to > straight Python." -- From sage-support yesterday. Oh well, life is too short to worry about that IMHO now. You win some, you lose some. And while Sage tries to be the best tool out there it isn't the best tool for every mathematical job. I don't really care if people do not use Sage now on Windows because it isn't native since we have a lot of room to grow in the non-Windows world. The MSVC port is on the way and I plan to be done with it by the end of the year. I suspect most of the hard code people who are likely to become power users and then developers are not on Windows, so except from raw user number there is little to gain on that front. But I agree 100% with you that we need to go that route since you cannot compete with three of the 4Ms if you aren't native *and* 64bit on Windows because if you ignore 95% of the desktop market [the native bit, not the 64 bit :)] you will forever stay in your ghetto and I think that many people who make deployment decisions will take a look at Sage and once they see that there is no "real" Windows version will discard Sage as a option and most likely turn to the commercial products. Because the vast majority of code hasn't been ported we need to do the heavy lifting for a whole generation of OS math people. Cygwin can be done before Dev1, so I think that will be a nice stepping stone on the way to "World Domination" :) > Anyway, I think you'll probably strongly agree with some of this email, > since I think porting is the part of Sage you care about the most. If nothing > else, I think I'm very much on the same page as you regarding this. Yep, pretty much. > -- William Cheers, Michael > -- > William Stein > Associate Professor of Mathematics > University of Washingtonhttp://wstein.org --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
