Oh well, Ondrej Certik offered a debugging challenge for a problem in Sage he discovered. The problem was that he hit a timeout when starting up a binary copy of Sage on his shiny, new and fast Intel Quad Code box. After some debugging he discovered that Debian's XFS default mount options cause the slowdown, all the details can be found in this blog entry from Ondej's blog. You should go over to his blog and check out the quite interesting details since he took the time to track the issue down.
The challenge boiled down to the whether the timeout bug was in Sage or XFS. The loser would have to publicly claim that he is lame. Since the challenge was issued and resolved while I was asleep I did contribute little to the end result and let's just say that I am not lame. By the process of elimination you can guess the outcame. But I have been wrong about bugs in Sage and elsewhere in computing in general many times before and while I teased Ondrej a little bit about it in IRC it was all good fun. It just shows that Sage is much, much more than a pure technical project and has a social and community side, too.
Cheers,
Michael
Tuesday, February 26, 2008
Saturday, February 23, 2008
Sage 2.10.2 has been released
Sage 2.10.2 has been release roughly three weeks after 2.10.1. The delay is mostly due to Sage Days 7, which took the attention away from most developers and also caused a number of people to come down with nasty colds (me included). Highlights from the release (shamelessly stolen from the announcement):
Sage 2.10.3 is coming up and we might do a real quick bug fix only release since Sage Day 8 at Enthought is coming up.
Cheers,
Michael
- John Voight's fast new code for enumeration of totally real fields is now included.
- David Roe's code for unramified and Eisenstein extensions of Qp and Zp is now included.
- Clement Pernet, Burcin Erocal and William Stein have implemented an optimized p-adic/modular algorithm for computing Hermite normal forms of matrices over the integers. For random square nonsingular matrices with small entries it is similar to Magma in speed, and vastly faster than the implementations in Gap, NTL, and PARI. For matrices with large entries (e.g., 16 bits or more), it is faster than anything else in the world. For nonsquare matrices it is also reasonably good, though more optimization is needed since Magma is much better in some cases. We also implemented related code for computing determinants over QQ and ZZ, which is again the fastest in the world especially when the matrix entries are large. The main reasons for the speed of our implementation are (1) IML is fast, and (2) we found some tricks that are not in the literature.
- Tim Abbott and Michael Abshoff worked on the Debianization of the build process. Due to a lot of work done by Project Athena at MIT Tim Abbott contributed many build scripts for chroot environments. He also contributed build scripts for nearly all of the SPKGs not yet in Debian. Michael Abshoff did set up a test build server and while it has been shut down for now the Sage project will set up another 64 bit build server in the near future top provide Debian packages for a wide variety of Debian based distributions.
Sage 2.10.3 is coming up and we might do a real quick bug fix only release since Sage Day 8 at Enthought is coming up.
Cheers,
Michael
Tuesday, February 19, 2008
A Late Sage Days 7 report
Oh well, Sage Days 7 has been over for quite a while and I did procrastinate on this blog post for way too long.
The event was hosted at IPAM at UCLA and it was a lot of fun meeting a whole new set of faces only known from IRC and email in person and also meeting a large set of people I met at previous Sage Days again. I was one of the few Europeans there (and probably the only one who came directly from Europe) and the flights sucked. For some reason I was routed via Las Vegas and the airline managed to lose my luggage on the last leg of my flight itinerary, a 40 minute flight from Las Vegas to LAX. The travel from LAX to Westwood was very pleasant, but finding the UCLA guest house took some more time than I had thought. In the end I finally caught some sleep and due to my charger and backup laptop resting safely in my luggage I didn't respond to email too much for the first 48 hours.
After my luggage showed finally up roughly two days later things got better, but I never caught up with my email until I made it home. I mostly worked on the Debianization of Sage with Tim Abbott, merged a bunch of tickets and spend a lot of time on discussions and bug fixing. Overall it was a very productive Sage Days for me.
I ended up winning the "Guess that spkg" and "Guess that ticket" competitions and I guess everybody did expect me to win since it would have been a major upset if somebody else beat me there. Let's see if we are having another contest at Sage Days 8 in Austin at the end of the month.
Flying back to Europe was alright, even though I didn't sleep the night before and dozed on the plane for a couple of hours. On the way back I visited rpw in Darmstadt, but at that point I was pretty useless from lack of sleep. I also ended up with a rather severe cold which also attacked other participants of SD7, so that I spend the two days after I got home mostly sleeping and away from the computer.
Cheers,
Michael
The event was hosted at IPAM at UCLA and it was a lot of fun meeting a whole new set of faces only known from IRC and email in person and also meeting a large set of people I met at previous Sage Days again. I was one of the few Europeans there (and probably the only one who came directly from Europe) and the flights sucked. For some reason I was routed via Las Vegas and the airline managed to lose my luggage on the last leg of my flight itinerary, a 40 minute flight from Las Vegas to LAX. The travel from LAX to Westwood was very pleasant, but finding the UCLA guest house took some more time than I had thought. In the end I finally caught some sleep and due to my charger and backup laptop resting safely in my luggage I didn't respond to email too much for the first 48 hours.
After my luggage showed finally up roughly two days later things got better, but I never caught up with my email until I made it home. I mostly worked on the Debianization of Sage with Tim Abbott, merged a bunch of tickets and spend a lot of time on discussions and bug fixing. Overall it was a very productive Sage Days for me.
I ended up winning the "Guess that spkg" and "Guess that ticket" competitions and I guess everybody did expect me to win since it would have been a major upset if somebody else beat me there. Let's see if we are having another contest at Sage Days 8 in Austin at the end of the month.
Flying back to Europe was alright, even though I didn't sleep the night before and dozed on the plane for a couple of hours. On the way back I visited rpw in Darmstadt, but at that point I was pretty useless from lack of sleep. I also ended up with a rather severe cold which also attacked other participants of SD7, so that I spend the two days after I got home mostly sleeping and away from the computer.
Cheers,
Michael
Saturday, February 16, 2008
Bug Day 10
For those who hadn't heard the news: Bug Day 10 will start in a couple hours. Basis will the Sage 2.10.2.alpha0, so if you want to participate you should try to compile it until then.
It has been a while since I blogged, mostly due to Sage Days 7 and a cold that followed, but more about that later. I plan to blog about various Sage related issues in the near future, so things should be more lively again.
Cheers,
Michael
It has been a while since I blogged, mostly due to Sage Days 7 and a cold that followed, but more about that later. I plan to blog about various Sage related issues in the near future, so things should be more lively again.
Cheers,
Michael
Tuesday, January 29, 2008
Sage 2.10.1 release plan and an Outlook for 2.10.2
After various release candidates, i.e. Sage 2.10.1.rc0-rc2 we are getting finally close to the final release. The release cycle has been longer than usual since we still have a number of blockers to resolve, i.e. the ATLAS tuning issue as well as fallout from the GNUTLS update which causes segfaults when starting the notebook. It will be the release for Sage Days 7, but we might still push another bug fix only release if it turns out that we have some glaring, must fix bugs in Sage 2.10.1. Sage 2.10.2 (or .3) will probably merged David Roe's unramified and eisenstein extensions of Qp and Zp as well as John Voight's code for enumerating totally real fields with improvements by Craig Citro. We also expect more fixes for the 64 bit OSX port as well as for the Solaris port, but it is uncertain if either one of them will become officially stable in that release.
Cheers,
Michael
Cheers,
Michael
Friday, January 25, 2008
Worst SPKG ever!
Well, in case you don't get the Simpsons reference about Comic Book Guy's catch phrase you might want to read those two links. But to get back to the point of this post: I spend about 6 hours or so on ticket #1852. It looked very harmless, i.e. just enable ATLAS during the configure phase and fix some other odd issues, but it turned out to be the worst spkg I ever had to fix. No need to name names here since the subject of this post is mostly tongue in cheek by now. While I did work on the spkg I did feel differently, but those things had a tendency to fade into the background once I have moved on to other things.
Do I blame the person who initially did create the spkg in question? Not really, since we are all busy people and I also had to read the R build manual to fix some of the issues I saw. It was just surprising that this particular spkg was quite bad compared to all the other ones, i.e. we installed about 60 mb unneeded object files somewhere in SAGE_LOCAL and those do add up for the final download size. I am just glad it is done and now I could start bitching about gsl 1.10, see #1623. Since that one is done, too, now it is on to #1631 and then who knows what. So, sooner or later there will be another "Worst SPKG ever!" and this one will be a distant memory ;)
Cheers,
Michael
Do I blame the person who initially did create the spkg in question? Not really, since we are all busy people and I also had to read the R build manual to fix some of the issues I saw. It was just surprising that this particular spkg was quite bad compared to all the other ones, i.e. we installed about 60 mb unneeded object files somewhere in SAGE_LOCAL and those do add up for the final download size. I am just glad it is done and now I could start bitching about gsl 1.10, see #1623. Since that one is done, too, now it is on to #1631 and then who knows what. So, sooner or later there will be another "Worst SPKG ever!" and this one will be a distant memory ;)
Cheers,
Michael
Tuesday, January 22, 2008
Sage 2.10.1 Progress
Progress on Sage 2.10.1 has been good so far. We closed 71 tickets as off alpha2 and have about another 30 patches or so under review. The initial load of patches were merged during Bug Day 9, which turned out to be an excellent debug session. The wiki page is somewhat misleading since the IRC log isn't up yet and many people who participated did not add themselves to the wiki page.
But there is some trouble in paradise since the upgrade of GNUTLS and its related components broke the notebook in secure mode. This lead to a revisit in #sage-devel about whether linking a GPLed program like Sage against OpenSSL is legal or not. While opinion diverged in this it remains a fact that we should fix the GNUTLS issue (or is it in Twisted? I am not sure yet) since we can't ship OpenSSL libraries with the binary and the reliance on a properly working system OpenSLL in the past had lead to plenty of trouble in the past.
Besides the above issue what else can we expect of 2.10.1? Better ATLAS build times on Pentium Ms and 32 bit Athlons (not merged yet as of alpha1). a lot of work toward building a 64 bit OSX version of Sage and maybe even a universal binary for OSX (32 bit ppc and x86), so stay tuned.
Cheers,
Michael
But there is some trouble in paradise since the upgrade of GNUTLS and its related components broke the notebook in secure mode. This lead to a revisit in #sage-devel about whether linking a GPLed program like Sage against OpenSSL is legal or not. While opinion diverged in this it remains a fact that we should fix the GNUTLS issue (or is it in Twisted? I am not sure yet) since we can't ship OpenSSL libraries with the binary and the reliance on a properly working system OpenSLL in the past had lead to plenty of trouble in the past.
Besides the above issue what else can we expect of 2.10.1? Better ATLAS build times on Pentium Ms and 32 bit Athlons (not merged yet as of alpha1). a lot of work toward building a 64 bit OSX version of Sage and maybe even a universal binary for OSX (32 bit ppc and x86), so stay tuned.
Cheers,
Michael
Subscribe to:
Posts (Atom)