How easy it is to make people believe a lie, and how hard it is to undo that work again

I made a little bit of documentation on reference counting. It’s not yet really finished, but I’ve let two other developers review it now. I guess that means it’s somewhat ready.

The reason I made it was because as I browsed and contributed to GNOME’s code, I noticed that a lot of developers seem to either ignore reference counting or they use it incorrectly all over their code.

I even saw people removing their valid reference usage because they had a memory leak they wanted to solve. As if introducing a race condition is the right fix for a memory leak! Some people have rather strange ways of fixing bugs.

What people who don’t want to care about it should do, and I agree with them, is to use Vala instead.(Or D, or Python, or C#, or Java, before I get hordes of language fans in my comments again. Oh! Or C++ with smartpointers too! – oeps, I almost forgot about the poor céé plus plus guys -)

Anyway, I’m sure my guidelines are not correct according to some people, as there are probably a lot of opinions on reference counting. In general I do think that whenever you pass an instance to another context (another thread or a callback) that you simply must add a reference. If you do this consistently you’ll have far less problems with one context finalizing while another context is still using it.

It’s a wiki page, I’m subscribed. You can just change the content if you disagree. Being subscribed I’ll notice your changes and I’ll review them that way.

http://live.gnome.org/ReferenceCounting

It’s not the first such item that I wrote down. Here are a few others:

• How to use gdk in threads and timeouts
• How to implement Vala interfaces in C
• Switching to multiple threads, with a non-thread-safe resource
• How to use DBus’s binding tool with GLib
• Iterators in GLib, a proposal

After reviewing this document José Dapena promised me he’s going to make a page about reference count debugging in gdb, like adding watches on the ref_count field of instances. To make sure he keeps to his promise I decided to put a note about that here. <g>

Quim Gil announces why.

It’s a little bit frightening … I guess quite a lot of people will now start using our code.

I’m also proud of having been involved with such a great team of software developers working on Modest and Tinymail.

I think I succeeded at creating a healthy free software project suitable for both commercial and purely free software appliances. People are contributing for and from different angles. Different companies are involved. I am trying to blend the contributions a bit more in order to get more “passion contributions” rather than “just the minimum must work, here’s a quick-fix”-patches. It’s improving, though.

Nokia (however) gave me ‘the’ opportunity to create Tinymail. They allowed me to work on it full time for more than a year. Everything was always immediately free software, and happened completely in the open too. Go check if you don’t believe that.

You can accuse Nokia of a lot of things, but they did great at fostering several free software projects. They made mistakes, of course. In my opinion, the handling of this project was done in a very healthy way: very open minded and very much the way free software can be commercially successful. I hope they learned free software won’t do wonders but that it can help you finding experts in specific fields, working together on the bigger picture: the actual consumer device. Working together with free software inspires a certain kind of passion among engineers. Capitalizing on that is fine, as long as you have respect for the passion. Just like the engineers have respect for the passion of solving the problem of producing and bringing millions of devices to the customers in time. Both enemy and friend know no company can do this better than Nokia.

I don’t think there’s anything controversial in respecting the hardware dudes’s jobs. In the end we humans are all about our passions.

I didn’t succeed at making a release before Modest was thrown to the Maemo users. That should happen very soon now, though. I’m very much in agreement with that “release often, release fast” – meme. But I also only want to call something a one-point-zero if it’s really stuff that works, behaves as expected and has all API that people’s E-mail clients require. The problem is that as an engineer I’ll never think that any of my software is finished. Everything can be better. Living near Eindhoven I grew up with the slogan “Let’s make things better“. I agree with the meme in that slogan.

Neither did I reach a bunch of technical goals. I have so many things in mind that would make Tinymail based E-mail clients by far the best kind of mobile E-mail clients ever created. Although Polymer, damn you Dave Cridland! :-), makes it hard to really be the best. Subjects ranging from pipelining to supporting CONVERT, forward without download, streaming media as attachments, and many more. IMAP has a few interesting limitations that I would like to address too, like Lemonade does. And then you have the IMAP servers … grmbl.

Regretfully a lot of people think of E-mail as a simple subject. They should figure out then why so many teams have tried to write good E-mail clients, yet relatively few succeeded. I’ll spare you the details and I’ll just point out that a lot of ’stuff’ is involved that you won’t expect. But really, if it wasn’t a challenge, I wouldn’t have been interested anyway. I’m not complaining, I enjoyed and I am enjoying a hard task ahead of me.

Meanwhile, I enjoy working on Tracker for Nokia. It was time for something different. Incubation time for Tinymail, perhaps? I’m working a lot with SQLite, who knows what will come out of that symbiosis? Perhaps I learn that it’s not suitable? Perhaps it is? I haven’t had the chance to explore cursors in SQLite. That’s what I’d be interested in most for things like Tinymail.

I should stop thinking about it too much, before I end up hacking until eight in the morning again.

I have been whining about features that I want in Vala to Jürg. To make up for all the time he lost listening to me I decided to fix two Vala bugs.

The first bug I fixed was using a recursive mutex for lock statements. Code like this will work as expected now:

public class LockMe : GLib.Object { }
public class Executer : GLib.Object {
	LockMe o { get; set; }
	construct { o = new LockMe (); }
	void Internal () {
		lock (o) { }
	}
	public void Method () {
		lock (o) { Internal (); }
	}
}
public class App : GLib.Object {
	static void main (string[] args) {
		Executer e = new Executer ();
		e.Method ();
	}
}

Here’s a gdb session that most GLib programmers will recognize:

Breakpoint 1, 0x08048a87 in executer_Method ()
(gdb) break g_static_rec_mutex_lock
Breakpoint 2 at 0xb7e4d0e6
(gdb) cont
Continuing.
Breakpoint 2, 0xb7e4d0e6 in g_static_rec_mutex_lock ()
   from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0  0xb7e4d0e6 in g_static_rec_mutex_lock () from /usr/lib/libglib-2.0.so.0
#1  0x08048b04 in executer_Method ()
#2  0x08049046 in app_main ()
#3  0x0804908a in main ()
(gdb) cont
Continuing.
Breakpoint 2, 0xb7e4d0e6 in g_static_rec_mutex_lock ()
   from /usr/lib/libglib-2.0.so.0
(gdb) bt
#0  0xb7e4d0e6 in g_static_rec_mutex_lock () from /usr/lib/libglib-2.0.so.0
#1  0x08048a6e in executer_Internal ()
#2  0x08048b0f in executer_Method ()
#3  0x08049046 in app_main ()
#4  0x0804908a in main ()
(gdb) cont
Continuing.
Program exited normally.
(gdb)

The second bug is supporting interfaces for D-Bus services in Vala. It goes like this:

using GLib;
[DBus (name = "org.gnome.TestServer")]
public interface TestServerAPI {
	public abstract int64 ping (string msg);
}
public class TestServer : Object, TestServerAPI {
	int64 counter;
	public int64 ping (string msg) {
		message (msg);
		return counter++;
	}
}
void main () {
	MainLoop loop = new MainLoop (null, false);
	try {
		var conn = DBus.Bus.get (DBus.BusType.SESSION);
		dynamic DBus.Object bus = conn.get_object (
			"org.freedesktop.DBus", "/org/freedesktop/DBus",
			"org.freedesktop.DBus");
		uint request_name_result = bus.RequestName ("org.gnome.TestService", 0);
		if (request_name_result == DBus.RequestNameReply.PRIMARY_OWNER) {
			// start server
			var server = new TestServer ();
			conn.register_object ("/org/gnome/test", server);
			loop.run ();
		} else {  // client
			dynamic DBus.Object test_server_object =
				conn.get_object ("org.gnome.TestService",
					"/org/gnome/test", "org.gnome.TestServer");
			int64 pong = test_server_object.ping ("Hello from Vala");
			message (pong.to_string ());
		}
        } catch (Error foo) { }
}

In Vala you can define interfaces just like in C# and Java. Interfaces imply that you can have class types that implement one or more such interfaces. Vala does not force you to implement its interfaces in Vala. You can also implement them in good-old GObject C.

Here’s a detailed example how you implement a type that implements two Vala interfaces in GObject/C:

Your application used to be single threaded and is consuming a resource that is not thread-safe. You’re splitting your application up into two or more threads. Both threads want to consume the non-thread-safe resource.

In this GNOME-Live item I explain how to use GThreadPool for this.

It’s a wiki so if you find any discrepancies in the sample and or text, just correct them. I’m subscribed so I’ll review it that way.

The GNOME-Live item is done in a similar way to the item about using asynchronous DBus bindings and the AsyncWorker item.

Summer of code 2008

I’m going to mentor three Summer of Code applications.

• E-mail activity for OLPC by Shikhar Bhushan
• Seahorse integration in Evolution by Zhang Shunchang
• SuperRandom, a predictive listening plugin for Rhythmbox by Charlotte Curtis

One of the Igalians who developed Modest and among many of his Tinymail contributions implemented the libcst implementation for handling certificates in Tinymail, José Dapena Paz, is going to mentor Zhang Shunchang’s application together with me.

Picking up what I left in 2005

I also just picked up AsyncWorker. I made it a little page and with the help of Tinne I improved its API documentation. Perhaps I will do a release someday (I never did, actually). Thing is that I hate the work involved with releasing. Especially since most of our development tools stink.

Note that my super fantastic lovely girlfriend, Tinne, has her own blog now. It contains a bunch of photos of our stay in Durham UK. In a few minutes, she just told me, she will put online a funny photo of me holding a fish bowl filled with cocktail.

While I was gathering some info about a DBus related task that I’m doing at this moment, I wrote down whatever I found about DBus’s glib bindings in tutorial format.

A few other people have done similar things in their blogs. This one explains how to use org.freedesktop.DBus.GLib.Async a little bit too.

If you find any mistakes in the document, it’s a wiki page so please just correct them.

I just released Tinymail’s pre 0.0.9, enjoy!

I noticed that more and more people from several specific cities are visiting Tinymail pages, and I know at least a few companies and organisations who are using Tinymail right now.

My personal opinion on development frameworks is that if they come without documentation, they are worth as much as vaporware.That’s why I started first, at an early stage, with writing the API documentation of Tinymail and then Tinymail’s trac, which holds a collection of examples and on top of the API documentation also explains most of its types and how to use them.

This was not sufficient. I wanted to write a test E-mail client to find the source of bugs in Modest. While I was doing that I decided that this test E-mail client was going to be documentation too. Documentation in the form of source code that itself required documentation.

I started TMut’s trac to deposit that documentation. Yesterday I mentioned that I implemented simple account management in TMut, today this is ~ finished. Here is the documentation about that source code.

New items:

• TMut’s account store
• Account manager
• Account editing

Former items:

• Creating messages
• Select a folder window
• TMut’s menu, its first screen
• Showing the summary of a folder
• The message view component

You guys remember TMut? It’s an E-mail client for small screens that uses Tinymail. It serves as an actual E-mail client, as some code that you can use to peek at while developing your E-mail client and as a piece of code where you can derive your stuff from (although TMut’s current build is not set up to build TMut’s classes into a library, you could easily do this and then subclass TMut’s high level components).

What makes TMut unusable for non-software developers is that it has no account management. You need to do that in for example GConf (depending on what implementation of TnyAccountStore your TMut uses).

At Modest we need to test Tinymail’s account management capabilities without executing all of the extra code involved in what Modest does whenever you manage its accounts. Therefore I started putting in place some code to have basic account management in TMut.

It’s, as usual with the things that I blog about, unfinished.