PyExt2lib

I pushed a new project to Github about a week ago: PyExt2lib, Python bindings around the ext2fslib that comes with e2fsprogs.

The motivation for this project and the story behind it are quite interesting, so I though I would share them.

It all started with an Operating Systems class assignment in which the students (divided into pairs) were supposed to develop a tool to extract some information from filesystems, such as sizes of segments of contiguous free blocks and sizes of blocks allocated per inode, and display some of that information as histograms.

No one in the class had ever come close to doing anything related, so we all started looking into how to implement that. Some attempted to use the Virtual File System layer in the kernel to no avail, while others looked up how other tools, such as dumpe2fs, did it, and came up with the idea of using ext2lib.

We thus faced the challenge of learning the poorly documented API of a complex library we didn’t even know existed before, as a prerequisite to actually starting the assignment.

PyExt2lib, albeit not crucial to overcoming this problem (which required countless hours reading the e2fsprogs source code), provided a nice abstraction over the underlying library once we got the hang of it. That is, my partner and I could rapidly encapsulate chains of undocumented ext2lib API calls into Python code implementing the functionalities we actually needed, such as iterating over all free blocks.

Using Python also helped us with post-processing the information, a task that was made quite simple using the built-in types as data structures and matplotlib for the histograms.

I had already used Cython before in a patch for XMMS2, liked it and wanted to learn more about it. That and the fact that GSoC may require me to use it again made it the tool of choice to develop PyExt2lib.

Even though PyExt2lib is incomplete and might never get finished, and contains some plain ugly hacks, I like to think it served its purpose and taught a few things in the process.

We did, after all, deliver the assignment in time, and aside from the bindings themselves, it boiled down to about 400 lines of Python that came together in a few days.

It’s ALIVE!

It’s been two weeks since I began coding for GSoC, and it’s time to share some of the progress we’ve made.
For the anxious: the courier object, as described in the last post, is already crawling on its own. I have implemented and briefly tested both methods described in the wiki, as well as a few other features to ipc.c and GenIPC.

My first attempt at implementing the courier object was to expose some data structures from ipc.c to courier.c and let the latter manipulate them at will.
After discussing this design with the community, we settled for hiding these data structures and only exposing through new functions the bare minimum necessary for the courier to operate.
That is how this commit came to be. Since some of the new functions are mere copies of code that already existed elsewhere in the same file, they could be used instead of that code. I should add “cleaning up ipc.c” to my TODO list.

At that point I was planning on not making the courier a xmms_object_t, and have it special-cased for commands and replies in ipc.c (just like the SIGNAL object). This works for the two methods described in the wiki, but would complicate things for the other methods we have in mind. So after discussing the issue with nesciens, we decided to adapt GenIPC to our needs.
This means making it possible to specify that the server should not automatically send replies to clients that call a server object’s method, and that it instead should leave that responsibility to the method itself.
This set of changes was made in a separate branch of my repository, which has now been merged into master. This is the most relevant commit, describing the changes. The other commits are fixes and cleanups both to new and old code.

With that issue out of the way, I integrated the courier object to GenIPC with these two commits. It should now be fairly easy to implement the remaining methods we have in mind. So far, we are planning on implementing a method that returns a list of ids of connected clients, and a method for clients to consult their own id.

Today I made a small breakthrough by writing a very silly but functional service client. In order to do that, I had to hack support for the courier object in libxmmsclient and main.c. I didn’t commit such ugly code, but it helped me test what I already had and, after a few hours of debugging, I had sumservice, the client that accepts messages containing a list of two integers from other clients, sums them and returns the result, and sumclient, the client that takes two integers from the command line and sends them for summation :)

Next steps: Aside from the remaining methods for the courier, I’m still unsure how to integrate this new object in main.c (i.e., its initialization and destruction). Also, the code written so far still needs revision and testing, as I may (as in, probably) have screwed up refcounting and other tricky parts.

See you soon!

The coding begins!

Yesterday was the official start of the GSoC program!

We had some nice ideas about my proposal during the Community Bonding Period and documented them in a dedicated wiki page. And now it’s time to put them to practice.

I started coding the server object described in the last section of the wiki page yesterday, and also made some progress today. I’ll have some code to show in the next few days.
And before I forget: last week I copied over the official XMMS2 development repository to a repository of my own in Github, which is where my changes will end up when they are a little more mature.

I’ll also update the wiki page with the issues I encounter and necessary clarifications as I go.

XChat notifications on GNOME 3

Hey there, thanks for reaching my old blog! I’ll probably stop posting here, so it would be awesome if you could visit the new version. Here, I’ll even give you the link to this post in the new location: XChat notifications on GNOME 3.

Yesterday I decided to upgrade my Gentoo system to GNOME 3.
It was not a painless process, although I must admit I expected worse.

One of the small annoyances that issued from the migration was that I could no longer rely on a blinking XChat tray icon to warn me of new IRC messages since, well, there’s no immediately visible tray.
Messing with the alarm settings in XChat, I came across an option to display Notification Baloons with libnotify. Thinking it might be nice to have an occasional balloon popping up with the new message text, I enabled it.

It did work, but:

So many messages!

For every message sent, not only a balloon would pop up and vanish after a few seconds, but also an icon would persist in the notification panel. The notification panel would shortly be cluttered by lots of useless icons.
(Ok, so this screenshot is actually me reproducing the problem manually, and not XChat causing it, but you get the idea).

Looking up the problem a bit, I found out that it had happened before, and could be solved by simply spawning the notification balloon with the appropriate parameters (namely, with a new transient hint set).

So, by grepping the XChat 2.8.8 source code for notify-send, I eventually reached the file where the magic happens, which looked somewhat like this.

After tinkering a bit, I found out that XChat 2.8.8 first attempts to load libnotify dynamically in order to use notification balloons, and if that fails, it falls back to calling the notify-send utility. So adding the transient hint would require changes in two sections of the code.

And here’s the diff of my modifications. Basically I used notify_notification_set_hint in the code section that attempts to use libnotify and added the command line parameter described in the bug above to notify-send.

After applying this and compiling, notifications no longer leave icons in the panel, which is exactly what I wanted.

I eventually found out that due to some bugs present in my version of XChat, the libnotify code (but not the notify-send code) always fails even before my changes have a chance to run. Well, at least I didn’t break it any further :-).

Come to think of it, I should probably have tried the latest SVN version first, since it fixes several issues with that specific file. But I had my fun anyway, and will gladly upgrade when the next XChat version comes out.

5-minute battery monitor

I was left with no AC adapter for my notebook for a few hours on Tuesday.
Also, no internet access for the same period.
Also, I was in class.
Oh, the horror.

Having no battery monitor installed and being unable to install one, I was clueless about how much battery life I still had.
So I did the best I could at the time: shut down the notebook hacked together a very simple battery monitor by parsing the contents of /proc/acpi/battery/BAT0/state and /proc/acpi/battery/BAT0/info.

So here it is, too pointless for Github, and too useful for oblivion:

#!/bin/bash

while :; do
    now=$(awk '(NR == 5) {print $3}' /proc/acpi/battery/BAT0/state)
    total=$(awk '(NR == 3) {print $4}' /proc/acpi/battery/BAT0/info)

    echo $now $total | \ 
        awk '{ printf("\r%d/%d mWh (%.1f%%)", $1, $2, 100*$1/$2) }'

    sleep 2
done

A fun time-waster would be to try to convert it into a pure awk script, but that’s going to have to wait.

So it begins…

I have been accepted by XMMS2 as a student for GSoC this year!
My proposal is to implement Service Clients: basically, clients that can offer functionalities to other clients by exposing methods for remote calls.
This is actually a long-standing idea, and there’s even an incomplete implementation already.
It will be very interesting to see all sorts of crazy services popping up after I’m done with my project…

Stay tuned!