Category Archives: Planets

I spent last weekend in Beijing attending GNOME Asia 2014; yeah, long trip from Europe just for 3 days, but it was totally worth it. The worst part of it was of course fighting jet lag when I arrived, and fighting it again 3 days later when I came back to Spain :) The conference was really well organized [1], so kudos to all the local team!

After a quick sleep on Friday morning, I attended the development and documentation training sessions that Kat, André and Dave gave. They were quite interesting, especially since I’m not involved in the real user documentation that GNOME provides. I have to say that these guys do an amazing job, not only teaching during conferences, but also through the whole year.

There are, from my point of view, two main ways of learning new things:

The ‘engineer’ way: Learning things as you need them, what you would do when you start writing an application and looking for examples of how to do what you want to do (autotools, anyone?). It is a very ‘engineer’ way, as you pick black boxes that you’ll use to build something bigger, while not fully understanding what the black box does inside.

The ‘scientific’ way: When you learn something in order to fully understand it and be able to teach others. This approach takes a lot longer, as you need to make sure that everything you learn is accurate and you end up questioning the things that are not clear enough. Learning stuff to teach others is actually what you do in University; you’re learning things that will afterwards need to be explained in an exam to someone who knows more about the subject than you do.

Sure, both ways have their ups and downs, but if you want to write software you need to be able to switch between those two mindsets constantly. You’ll use the engineer way when reading API docs, looking for the bits and pieces that you need to build your stuff. You’ll use the ‘scientific’ way when you need to start learning a new technology, or when you need more detail on how to do things. While the API docs are taken care of by the library developers, it is the documentation team the one making sure that user guides, tutorials, and other developer resources are kept up to date, which are definitely some of the toughest and most important tasks done to help newcomers and other developers. So go on, go learn GNOME technologies and teach others, join the documentation team! ;)

GNOME Asia is not a usual conference. If you have attended a Desktop Summit, GUADEC or FOSDEM before, all those conferences are built by developers and for developers. The focus of those conferences is usually not (explicitly) to attract newcomers, but instead to be a show of the latest and shiniest things happening in the projects. Of course we also had part of that in Beijing, say Lennart’s talk about the status of systemd or Allan’s talk about application bundles. Those both were very good talks, but likely too specific for most of the audience. Instead, I chose to talk about something more basic, focused on attracting newcomers wanting to write applications, and so I gave an Introduction to D-Bus talk, including some examples. It is the same talk I gave last year in GUADEC-ES, but in English this time (my Mandarin is not good enough).

I’m at the GNOME Development Experience Hackfest in Berlin, and one of the things that I wanted to target during these days was to keep on looking at how we can enable different profiles in Devhelp.

As you probably know, Devhelp will show you the documentation of libraries installed in your system (usually only if you have the -devel or -docs package of the library installed). While this is already enough for most users, there is also the case where a developer wants to target a different version (older or newer) of the library than the one installed in the system.

A typical case for this is developing applications using GNOME’s jhbuild infrastructure, targeted either to a given GNOME release or to git master of the involved modules. In this case, if you want to use new methods of let’s say GTK+, you usually end up needing to fire up a web browser and looking for the latest GTK+ documentation either in developer.gnome.org or in your jhbuild’s ${prefix}/share/gtk-doc/html directory.

In order to avoid this, I’m prototyping some ideas to let the users switch between different profiles, e.g.:

The ‘local’ profile, which is equivalent to what Devhelp currently shows.

A user-defined ‘jhbuild’ profile, which could point to the install prefix of the jhbuild setup.

Other user-defined profiles, which could point to other prefixes where the user has installed the newer (or older) libraries and their documentation.

Profiles for each new GNOME release, e.g. 3.12, which could get downloaded from developer.gnome.org as a tarball containing all documentation for a given release.

The most challenging case is probably the last one, given that it would require some extra work in the website in order to make sure the documentation tarball is generated and published in every new release, plus of course client-side management of these downloaded profiles in Devhelp.

For now this is just a basic set of ideas, the final result may or may not be similar; we’re of course open to suggestions!

Unit testing is a very powerful approach to quickly find issues that may have been introduced in your software. I have always been very interested in unit testing, even more since my first professional job at Panda Security was implementing a whole new unit testing system for a desktop antivirus.

In ModemManager we had some unit testing support, but it was really only focused on making sure that our AT response parsers worked correctly. These tests are of course very important, not saying they aren’t, but they only cover a very small subset of the implementation.

Supporting completely different devices from multiple vendors with completely different behaviors, while still providing a unified interface for all of them is a very challenging task. In particular, making changes to fix the behavior of one device may lead to broken behavior with others, and the AT response parser unit tests really are not up to the task of finding those issues. So, in order to improve that, we have now included a nice black box system testing environment along with the common unit tests, which can not only simulate AT-based modems, but also let us play with the ModemManager DBus interface directly. And all this by just running make check!

Keep on reading if you want to know how all this was setup :)

Every test using the new black box system testing will run a common test setup method before the actual test (and a common teardown method after having run it). This setup method will take care of launching a private DBus session using the excellent GTestDBus implementation in GLib/GIO. Once the new bus is ready to use, the test setup will also request a Ping() to the standard org.freedesktop.DBus.Peer interface in ModemManager, which in turn will make the daemon get started by DBus. Once the test fixture is setup, the test itself will be able to make use of the ModemManager process running in the private session, without any interference with the ModemManager that may already be running in the standard system-level bus.

Each test will then setup the simulation of the modem, by launching a separate thread running a Unix-domain socket service. This socket will have an abstract address, and will allow other processes to get connected to send/receive data. In addition to the socket service, the simulator will also read a dictionary of AT requests and responses from a text file included in the test context. This pair of socket and AT chat build together the simulation of an AT port of a modem: AT requests will arrive through the socket, and the simulator will reply the corresponding AT response gathered from the AT chat dictionary. If the dictionary doesn’t have the response expected for a given request, it will just reply “ERROR”.

But the private ModemManager instance doesn’t know anything about the new modem simulator being available, as there is no real physical port being created that ModemManager could get notified about via udev. So, once the simulator is in place, the test will report the abstract address of the socket via the SetProfile() method in the new org.freedesktop.ModemManager.Test interface. This method will just tell ModemManager that a given new virtual AT port is available in a given abstract socket address, and ModemManager will go on creating a new AT virtual port object internally and treat it as if it were a new TTY reported by udev.

As soon as ModemManager knows about the new virtual AT port, it will start probing it and creating a whole Modem object internally. Of course, for this to work well, the simulated modem needs to be able to reply correctly to most AT requests sent by ModemManager. The current implementation provides a generic AT chat dictionary for 3GPP (GSM, UMTS, HSPA, LTE…) devices, and the overall idea is that tests can load first the generic one to get a basic subset of responses, and then load a vendor-specific one with vendor-specific responses (overriding the generic ones if needed).

And of course, the last step is the test itself. Once every previous step has been successfully executed, the tester can now play with the standard ModemManager interfaces in DBus, querying for modems, requesting PIN unlock, enabling or disabling the device, and so on.

The currently available setup is not fully featured yet, it just provides some basic building blocks to be able to extend the black box system tests further more. The real work comes now, adding new behavior tests and writing new AT chat dictionaries to simulate different devices. If you want to play yourself with this setup, get the latest code from git master!