The good thing about this fix for the tinymail Python bindings, is that I did it in a generic way this time. I created a filter.py script which you can pass a –topsrcdir=$(top_srcdir) option on its commandline. It will walk all folders searching for .h files that have GTypeInterfaces. The h2def.py of pygtk should also do this, but seems to fail on detecting whether or not it’s a GTypeInterface. I made the regex in filter.py a little bit less strict and piped the output of h2def through filter.py. The filter.py script also makes it possible to append extra defines to the resulting .defs file. That’s why you are seeing .defs.extra files in the directory with the Python binding of tinymail. The idea is that I wanted everything to be generated. No way I’m going to store .defs files in my repository and maintain that junk.
The API docs also had a little problem that my tny-shared.h file with its ugly forward typedefs obfuscated the real location of the type struct to the parser of gtk-doc. This has also been fixed by doing some #ifdef #endif tricks in the .h files of the types.
I also have this new idea for the mmap patch for Camel. Check the idea out if memory consumption interests you. Note that the defines for calculating the offsets are still wrong (even in the 3th attempt, I forgot the ‘* x’ after the last sizeof). Nevertheless should the idea itself be clear, no? If you wonder why this patch isn’t yet in upstream Camel and Evolution: ask the evolution team, not me. The patch is default in camel-lite-builder and will be used by tinymail releases.
At work, I know I don’t often talk about work and should do that more often in stead of only whining about tinymail, I started doing some kernel development. I’m implementing a reassembly algorithm for IP fragmented in ATM cells accompanied by a timestamp using sliding window. Funky stuff.