Python ORMs

There is really no point to this post except to remind me of all the Python ORMs I promised myself I'd look at over the summer. I want to convert my web application from raw SQL(ite) to some ORM, but there are way too many of them. I could roll dice, but that doesn't seem appropriate somehow... :-D

Autumn
Axiom
DejaVu
Elixir
Membrane
Storm
SQLAlchemy
SQLObject
XRecord

And then there are these Gadfly and buzhug and SnakeSQL things, not ORMs of course, but interesting anyway...

Update 2010/06/24: Alright, I've looked at a few of these in more detail now. Seems that Autumn has not been updated in a while, so it's off the list. Also Elixir being a declarative layer over SQLAlchemy seems a little strange now that SQLAlchemy got it's own declarative layer, so it's off the list.

I implemented a basic model layer for my web application using both SQLObject and Storm, so those two I actually sort of grok now. The first major difference is that Storm requires writing some raw SQL to create tables and related schema stuff, whereas SQLObject tries to hide SQL even for those tasks. The second major difference is that Storm separates object creation from persistence whereas SQLObject combines the two to some extent; this can be good or bad depending on what your application needs to do. Also, coming from a "raw SQL" background, both Storm and SQLObject have some "issues" when it comes to formulating complex queries. Nothing much to be done about that I guess, but I still don't like it all that much.

If I had to pick an ORM right now, I'd probably pick SQLObject. But I have a few more to evaluate so stay tuned. :-D

QEMU: The Machine Park Replacement?

Alright, so teaching 600.318/418: Operating Systems last semester forced me to finally take a serious look at QEMU. And guess what? I liked it! :-D (Special thanks to Venkatesh Srinivas for helping me getting used to QEMU!)

Since QEMU supports some "exotic" platforms like PowerPC and SPARC, platforms I love to use for 600.328/428: Compilers and Interpreters, I started a little project to see if I could replace my aging "machine park" with QEMU instances.

The bad news is that installing a standard Linux distro for anything but x86 is somewhat complicated on QEMU, at least I had a very hard time with it. The good news is that I found some very nice Debian images tailored specifically for QEMU. And most of those even work! :-D

A few minutes ago I was finally able to SSH into my first MIPS QEMU instance! Now I'll work on finishing the same setup for ARM and PowerPC. So far it looks like I can replace at least my Cobalt Qube (MIPS) and my iMac (PowerPC) with QEMU instances. SPARC is a bit of a problem child right now, so I'll keep working on my Ultra 60 (I made some good progress there BTW, a later post will have the details).

But why replace my "machine park" in the first place? Granted, it's great fun to keep those old machines running and to hack compiler backends on them. However, it's also a big drain on my time. And what's worse, it's obvious that eventually each of these machines is going to fail beyond repair. In addition it's going to be easier to backup QEMU images every now and then, and having them all hosted on the gaming lab server with its nice RAID-6 makes things a tad more reliable and predictable as well. So while I am not planning on actually getting rid of my old machines just yet, overall QEMU seems to be a much better tradeoff for instructional purposes.

Getting Debian ARM to work with screen: I like to run my QEMU instances in screen, so I want the console output to go to, well, the console. Here is how:

qemu-system-arm -M versatilepb -m 256 -kernel vmlinuz-2.6.26-2-versatile -initrd initrd.img-2.6.26-2-versatile -hda arm.img -append "root=/dev/sda1 console=ttyAMA0" -nographic

The important part is the ttyAMA0 thing, that convinces the Debian ARM kernel to use stdin/stdout for everything. So now I am happy with my virtual ARM box. :-D

Getting Debian PowerPC to work with screen: At first I couldn't get the PowerPC QEMU instance to work with screen at all, so I had to "fake" a display as follows:

qemu-system-ppc -m 256 -hda powerpc.img -no-reboot -vnc :0

This worked fine, but it just wasn't very satisfying. So I poked around a bit more and found a getty process listening on ttyPZ0. Given my experience with the other QEMU instances, I figured this must be where the serial console is. However, since I didn't provide a kernel to QEMU directly, I couldn't append anything to the kernel command line either. So I copied the kernel from the PowerPC Debian image out and tried booting that way, but it wouldn't mount the root partition. So I copied the Debian initrd image out as well, and voila:

qemu-system-ppc -m 256 -hda powerpc.img -no-reboot -nographic -initrd initrd.img-2.6.26-1-powerpc -kernel vmlinux-2.6.26-1-powerpc -append "root=/dev/hda3 console=ttyPZ0"

Now I have a PowerPC QEMU instance that works with screen. Not much more I can ask for at this point, I now have three platforms for the next compilers course and that means my students will finally have to write native ELF backends next time around. Yay! :-D