Fri, 25 Jun 2010
Last week Red Hat put on a Professors' Open Source Summer Experience (POSSE) at RIT. Being an alumni, I was excited by the opportunity to be able to go back up to The ROC and teach some of the people that taught me. Going into it, I really had no idea what to expect. All I knew is that I was going to help lead the 'deep dive' section of the course, where I would teach professors how to dive in head first and get productively lost in a strange codebase. This is not something that can be accomplished with a set of powerpoint slides. Teaching how to hack on open source requires that you emerse yourself into a codebase, and bring your students with you.
Measure is an activity that turns the computer into an oscilloscope. Signals from the microphone (and sensors) can be plotted in time and frequency domains.
I had never used this activity, let alone hacked on it before. I've also never
done any sugar activity development, aside from some tweaking of the OpenVideoChat, so I really
had no idea what I was getting myself into. The obvious first step was to
get it running. All of us were able to start the activity in virtual machines
or emulators, except for one install which hit some odd errors upon startup.
We were able to quickly track the bug down to a stray
__init__ before some critical initialization code.
Right after we fixed the problem we noticed that Walter Bender had already
fixed this issue a few hours earlier. After a
git pull, we were
up and running.
Once we all got the activity running, we took a look at the bug list to see if there was any low-hanging fruit for us to tackle. Since the previous POSSE had already done some work on this activity the week before, there were not any trivial tickets left in the queue. So, in that case, we dove head first into the hardest one, "Measure activity gets stuck after recording". This ticket had very little information, and no log output, so we were on our own to try and track it down. We were able to reliably reproduce the issue on the XO-1.5, but not on the 1.0. In our virtual machines we hit it sporadically. We all agreed that it felt like a race-condition, most likely due to threading. So we started instrumenting the code and adding some debugging statements to try and figure out which line of code was the culprit.
In our efforts to scatter
raise Exception("WTF?!"). We finally realized that since the activity would freeze, it was never able to flush stderr/stdout to the log. A quick find/replace regex later, and we were using the proper
logging module and seeing our debugging output hit the logs.
We were then able to track the bug down to a line of code that uses GTK to try and get
the coordinates of the parent window. At this point, since none of us were GTK
experts, we had to go upstream. So, I dropped into #fedora-devel and asked.
Within 10 minutes I had responses from 3 different GTK hackers. One was a
typical RTFM response, which humored the professors (who are very used to
hearing/saying this), but the others pointed us in the right direction. One
mentioned that gtk.gdk calls probably should not be done in a seperate thread.
So, a suggested workaround was to add
calls before running any gtk.gdk code in the thread. A 2-line
patch later, and we had squashed the bug.
We eventually bumped into the inevitable typo in some comments. So, we made the fix locally, and committed it to our git repo. A few minutes later and we found another one. I saw this as a great opportunity to show off some of my git-fu. Instead of sending two "Fix typo" patches upstream, I showed the professors how to use git interactive rebasing to squash multiple commits into a single one. They all followed along closely, and the workflow made sense to them.
While we were looking through the ticket queue, we saw an issue where Measure
would apparently leak memory and crash when running it for a long period of
time. While keeping this in mind, we kept our eyes peeled while wandering
around the codebase to see if we could track the issue down. When looking at
the code that takes screenshots of the waveform, I noticed that it created a
temporary file with
tempfile.mkstemp, saved the pixmap to it,
injected it into the Journal, and then deleted the directory. This looked fine
at a first glance, until I realized that it never closed the temporary file descriptor.
Another 2-line patch later, and this issue was solved.
The next day both of the patches that we sent upstream were applied by Walter Bender.
Overall, POSSE definitely exceeded my expectations, and I'm extremely satisfied with how the 'deep dive' section went. I went into it feeling completely unprepared to teach, but by trusting my "hacker intuition", I feel that it turned out to be a fantastic learning experience for all of us.
Mon, 15 Dec 2008
Fri, 10 Aug 2007
With my college career at RIT coming to an end, I had to say goodbye to Rochester NY last week. My last day in Rochester consisted of open face for lunch, and a tasty Mark's Sloppy Plate for dinner -- with an abundance of ruckus in between.
So last week I moved into a sweet apartment in Watertown, MA. The place is right on Arlington street, and is in a pretty amazing neighborhood. I'm 1 block from a basketball court, 2 blocks from a 24/7 711 (my girlfriend and I have already made multiple 4am slurpee & nacho runs), and a 10 minute bus ride to harvard square.
One of my favorite parts about Watertown is that it is really not chainy at all. Every corner has a ton of mom&pop shops, and I haven't seen a single McDonalds yet. But by far the best part about living here -- RUSSOS!!1.
One of the kids who lived in my last apartment left me with a pretty badass server rack, which I gladly accepted. I still need to order some more shelving and such, but it's great to finally have a central place for all of my puters.
Wed, 06 Jun 2007
So, long story short, last week I:
- "Graduated" from RIT with a BS in Computer Science and a minor in Philosophy
- Moved into a house in downtown ROC
- Deployed bodhi, the new Fedora Update System that is used to push out updates for Fedora 7. More details on that when I come up for air.
- Start summer classes.. my last quarter @ RIT. Taking AI and ancient philosophy, along with a couple of online classes.
- Slay bitches with Python.
- Rock the fuck out.
Thu, 15 Feb 2007
So my Thanksgiving break was far from a break. I spent a couple of days last week at Red Hat's westford office before heading back up to RIT to start a new quarter. In my two days in the office I was able to touch base with a bunch of people, and get a bunch of stuff done as well. I had a long discussion with dmalcom about integrating the Fedora Updates System with Beaker/TableCloth. He also gave me a quick rundown on a bunch of the Red Hat QA infrastructure that is currently being used. Ideally we'd like to be able to crunch all package updates through an automated test system before pushing them out to the world. Involvement needed: FedoraTesting.
Later that day I met with jrb and jkeating about getting a package updating system in place for a new Red Hat product that is going out the door very soon. This means that much work will be going into the new UpdatesSystem in the near future, which means I get to dig deeper into the world of TurboGears :)
On thursday I cranked a bunch of code out, but was fairly distracted most of the time by the OLPC laptops that were lying around the office. I must say, it is an absolutely incredible machine. The screen is gorgeous, and it's camera is very impressive. I hung around later at the office for an OLPC hackfest that was going down.
I was busy working on the updates system most of the time, but then later on I started looking into some Python start-up issues, which can be seen by doing:
You'll notice a ton of syscalls like the following, which try to open/stat modules in locations that do not exist:
strace python 2>&1 | grep ENOENT
stat64("/usr/lib/python24.zip/posixpath", 0xbfdb5094) = -1 ENOENT (No such file or directory)
PrivoxyWindowOpen("/usr/lib/python24.zip/posixpath.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
PrivoxyWindowOpen("/usr/lib/python24.zip/posixpathmodule.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
PrivoxyWindowOpen("/usr/lib/python24.zip/posixpath.py", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
PrivoxyWindowOpen("/usr/lib/python24.zip/posixpath.pyc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (N o such file or directory)
stat64("/usr/lib/python2.4/posixpath", 0xbfdb5094) = -1 ENOENT (No such file or directory)
PrivoxyWindowOpen("/usr/lib/python2.4/posixpath.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No su ch file or directory)
PrivoxyWindowOpen("/usr/lib/python2.4/posixpathmodule.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
PrivoxyWindowOpen("/usr/lib/python2.4/posixpath.py", O_RDONLY|O_LARGEFILE) = 5
So it's obvious that modules could exist in multiple locations, but if you are repeatedly going to check a series of directories, such as
/usr/lib/python24.zip, wouldn't it be a *bit* smarter to check if they exists first, and then avoid checking there in the future? Doing so would help cut down from the 233+ syscalls python makes while starting up looking for modules. I really don't have any free cycles to try and add some sense into Python, so I really hope someone can beat me to a patch.
I came back home to find the new TurboGears book in my mailbox, which has been extremely informative, aside from the fact that the project has awesome online docs as well. I pushed out the latest TurboGears release, 1.0b2, for FC6 and rawhide yesterday as well.
Mon, 14 Aug 2006
So last week, on my way to grab a sandwich before class, I ended up shaking hands with our former president, Bill Clinton. Turns out he was invited by Tom Golisano to check out our new GCCIS building, and to give an invite-only presentation (which I was not fortunate enough to attend).