# Evolution kicks the libgdata-google habit

So, after a year of blood, sweat and tears repeatedly appearing at exactly the wrong time to get my patches in, I've finally managed to commit my patches to Evolution and evolution-data-server to port it to use libgdata rather than its home-grown libgdata-google library. Since Evolution has switched to using CalDAV for its Google Calendar backend, libgdata is just used for the Google Contacts backend. This is the first outing into the big scary world of popular usage for libgdata's Google Contacts support, so any and all testing of the changes would be appreciated.

In the meantime, I'll get back to looking at adding support for any additional features/contact fields I can to the Google Contacts backend.

# Non-recursive automake

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 91

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 92

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 91

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 92

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 91

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 92

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 91

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 92

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 91

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 92

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 91

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 92

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 91

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 92

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 91

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 92

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 91

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 92

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 91

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 92

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 91

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 92

A while back, I was toying with the idea of adding gcov support to libgdata, to give metrics on the code coverage of the test suite. I played around with adding it, but my attempts were thwarted by the fact that I couldn't easily get a list of all C files which were to be compiled, in all source directories, to use in the top-level Makefile.

I recently found a little time to work on this some more and, as usually happens, it ballooned into something bigger, and I ended up redoing the entire build system for libgdata. It now uses non-recursive automake, which makes things a lot simpler in many respects. The diffstat was favourable ("21 files changed, 641 insertions(+), 833 deletions(-)"), and it has made the autogen/clean/build cycle about 20 seconds faster (on average, from some very rough tests). Accomplishing this was largely possible due to the (fairly) recent literature on the subject from Murray Cumming and Daniel Elstner, which proved rather useful; so many thanks to them.

As a result of all this, I now know that only just over 50% of libgdata's code was actually being exercised before by the test suite. I've now pushed this up to 60%, and uncovered a few buglets in the process. I dread to think what other problems lie in the remaining 40%; there's certainly lots of work left to be done.

Anyway, since all the snippets of automake magic I could find were subtly incompatible with non-recursive automake, I ended up with a slightly different one (based on gobject-introspection's gcov support). Hopefully it's useful to someone, though it could probably do with some tidying up:

if GCOV_ENABLED
gcov-report.txt: gcov-clean all check
$(AM_V_GEN)(rm -f$@; \
echo -e "Test coverage for libgdata:\n" >> $@; \ total_covered=0; total_actual=0; \ for file in$(filter %.c,$(gdata_libgdata_la_SOURCES)); do \ file2={file%/*}; \ gcov -o find -newer {file2/.c/.gcda}" -print0 | sed -e 's/\.gcda/\.o/' file2.gcov; then \ actual=grep -v ' -:' file2.gcov | wc -l; \ covered=((total_covered + covered)); \ total_actual=file:\tactual\t(covered * 100) / total_actual\nCovered statements: (((total_actual))%" >>$@)

gcov: gcov-report.txt
@cat gcov-report.txt

clean: gcov-clean
gcov-clean:
@find . -name "*.gcda" -o -name "*.gcov" -delete

MAINTAINERCLEANFILES += gcov-report.txt

.PHONY: gcov gcov-clean gcov-report.txt
else
gcov:
@echo "Need to reconfigure with --enable-gcov"
endif

It will output a code coverage report of the test suite (make check) when make gcov is called, and will also save it as "gcov-report.txt" in the root source directory.

# Introspectable libgdata

Now that full term at university has finished, I have a little free time (inbetween sleeping, doing all the holiday work, and that celebration thing that people seem to do) to spend on projects. Today, I got round to adding GObject introspection support to libgdata. I think some of the Makefile changes I made were a little hacky, but they seem to work. If anyone wants to use libgdata from an interpreted language which has GIR support, it should now be possible.

In university news, things have gone well this term, and I managed to (precariously) stay on top of the rolling mountain of work. I've now got two weeks' stay in Cambridge to help shepherd interviewees around for their application interviews before I go home and do Christmassy things.

It took me until about half way through the term to notice that I was actually walking past Collabora's UK office every morning (opposite King's College). It was quite a shock when I noticed. It was also a shock to see they weren't at the computer lab's recent careers fair. Perhaps missing a trick there?

# Reviewing and applying a patch

I've been fortunate enough to have been reviewing a lot of patches recently. Fortunate, because it means other people are contributing to my library. However, few of these contributions are without their problems; as with all contributions, each patch generally goes through two or three iterations before I think it's near enough to being ready that it's easier for me to apply the patch than it is to comment on it and request an updated version.

Generally, when patches get to this stage, it's just the really small, nitpicky things which are still wrong. Rogue whitespace, quirky indentation, typos in documentation…these are all really minor things, but they take time to check through and correct. One of the latest libgdata patches was, I think, a bit of a rushed job; and so there were more of these niggly problems than usual. Instead of going through and fixing all the problems and never giving detailed feedback about them to the patch contributor – as is usually the way, since the changes are so trivial, albeit cumulatively not inconsiderate – I decided to make a screencast of the process I go through when reviewing a patch.

Reviewing and applying a patch

It's about half an hour long, unscripted and unedited, so there are a couple of mistakes and omissions in there (for example, I later noticed I'd forgotten to mention the lack of input validation on the new function). However, I think it's quite comprehensive. It's aimed at those who are getting used to the open-source patch submission and development process, though those more talented than me welcome to watch it and lambast me for not using Emacs. Hopefully it's useful to someone, anyway. It's licenced under cc-by-sa 2.0.

# libgdata 0.4.0 released

This blog seems to be an endless stream of release announcements, which is unfortunate. Here's another one!

libgdata 0.4.0 has just been released. This release brings support for PicasaWeb and Google Documents, courtesy of Richard Schwarting and Thibault Saunier, respectively. The core API is slowing tending towards becoming stable, and the changes to the core API in this release should (hopefully) be the last really disruptive ones.

In a desparate attempt to make this post more than just a release announcement, here's a little update on my work experience with Red Hat. Things are going well; I've spent a while doing hardware testing, and I'm now doing some code review in anticipation of being given something else interesting to do tomorrow.

# Rogues' gallery

So far in my travels, I have met, for the first time, many gnomeshackers. One of the people I met was Tim-Philipp Müller and… Two of the people I've met were Tim-Philipp Müller, Matthew Garrett and Lennart Poettering… Amongst the many people I've met are such (in)famous hackers as: Vincent Untz, Alexander Larsson, Germán Póo Caamaño, Tim-Philipp Müller, Lennart Poettering, Matthew Garrett…

The truth is, there are too many people to name (and listing more would just destroy the joke). The conference is going great, apart from a minor incident with some snails, and I've enjoyed the talks I've been to so far.

Somehow, miraculously, my lightning talk on libgdata (slides) went OK (as far as I was concerned), and it even resulted in someone coming and talking to me about libgdata. How brilliant is that?

Still, my littlebig library pales in comparison to some of the interesting things which are being shown off at GCDS. Here's to GNOME 3.0!

# GCDS 2009

With my exams now finished (all 19 hours of them), it's time to look forward to GCDS 2009. In a fit of madness, I signed up to do a lightning talk on "libgdata and web integration", which will take place in the Synphonic Hall sometime between 15:30 and 16:30 on Saturday. If anyone wants a laugh at my expense, please turn up.

I was wondering if anyone attending GCDS was planning on going hiking in the mountains of Gran Canaria. To me, that would be more appealing than the arranged tourist outing, and some company would be welcome. I was thinking the Thursday would be most suitable, but I don't have any plans at this stage.

# End of the beginning

It's been a week now since I had my last ever lessons and left school for good. I've been at that school for seven years now, and it's a little weird knowing I'm never again going to have to go back there (apart from exams). I'm now on exam leave, leading up to A-level exams throughout June. After that, I'm free!

The last seven years have been fairly good, on the whole. I made some good friends, learnt a fair bit, and amassed a collection of award ties which is almost into double figures. The school does seem to have a fetish for giving out ties.

What's next? A summer of partyingwork, leading up to university next year, assuming I get the grades in the coming exams. For that reason I might be out of contact quite a bit for the next month, partyingstudying.

In other news, I released libgdata 0.3.0 a few days ago, which features a lot of cleanup work, plus an access control list framework contributed by Thibault Saunier as part of his GSoC work on Nautilus.

# Unused results

Work on libgdata is progressing nicely, and I've started on porting evolution-data-server to the shiny new calendar and contacts services provided by libgdata. One idea I recently had was to use the G_GNUC_WARN_UNUSED_RESULT macro (gcc's warn_unused_result attribute) on functions which return allocated data, to warn users of the library if they're not using the data, and thus leaking memory.

After a little research, I've found no real uses of that gcc attribute in this manner, which is rather surprising. Perhaps people think the effort of adding the attribute to all applicable functions is not worth it, given that 90% of the time, users of their libraries will correctly use the result of functions (if not free them)?

Anybody got any insights into the matter? I'll probably go ahead and add the attributes anyway, since there are definitely a few functions in libgdata which return allocated data when the user probably isn't expecting it.

# libgdata

It's about time to announce something I've been working on for about three months now: libgdata. It's a GLib-, libsoup- and libxml2-based library for accessing GData APIs, as used by most Google services. There already exist several such libraries in a variety of languages, but as far as I'm aware this is the first one written in C — and thus the first which is widely accessible to the GNOME stack. So far it has decent support for YouTube video queries, and the beginnings of Google Calendar support.

Having ported the Totem YouTube plugin to use libgdata, my next plan is to port the evolution-data-server Google Calendar backend as well. With that done, libgdata will hopefully be stable and fully-featured enough for people to get to work on starting to fulfil Rob Bradford's dream of tighter desktop integration with web services.