ANSI Common Lisp, by Paul Graham


ANSI Common Lisp (Prentice Hall Series in Artificial Intelligence) by Paul Graham (ISBN-10: 9780133708752; ISBN-13: 978-0133708752)

Source: ANSI Common Lisp (Prentice Hall Series in Artificial Intelligence): Amazon.co.uk: Paul Graham: 9780133708752: Books


Book Cover of The UNIX Programming Environment


The Unix Programming Environment (Prentice-Hall Software Series) by Brian W. Kernighan, Rob Pike (ISBN: 9780139376818)

Source: The Unix Programming Environment (Prentice-Hall Software Series): Amazon.co.uk: Brian W. Kernighan, Rob Pike: 9780139376818: Books

Using Debian Wheezy, I found that trying to use Evolution as my task source for hamster-applet was not working.

I enabled Evolution as my source for tasks in Hamster. When executing hamster-time-tracker from the CLI, an error would appear in my terminal:

** (Time Tracker:14088): WARNING **: Failed to open calendar (type 1): Authentication required

I first thought that the problem was with hamster, that it was an outdated version. So I downloaded the source from github, re-built it and installed it on my system (after removing the old hamster). This didn’t help. But, as I had the source handy, I thought I’d take a look.

In the hamster-master/src/hamster directory is a file called external.py and, in that, this:

import evolution
from evolution import ecal
evolution = None

So, I know I have found the right area to start investigating this issue further.

For python applications to interface to Evolution, which is written in C, some interfacing software is required. This is installed generally in the form of the package “python-evolution” (http://packages.debian.org/wheezy/python-evolution). As shown at the top of that page, the source for this binary package is gnome-python-desktop (http://packages.debian.org/source/wheezy/gnome-python-desktop).

The next step was to search for the source package responsible for interfacing to Evolution’s calendar. I soon found this. From the Packages Debian page (packages.debian.org) you would click the Developer Information (PTS) link (http://packages.qa.debian.org/gnome-python-desktop). Once there, on the right hand side, click browse source code (http://sources.debian.net/src/gnome-python-desktop/2.32.0%2Bdfsg-3). You end up at a page listing folders containing source files. Simply click into evolution and then click on evo-calendar.c (http://sources.debian.net/src/gnome-python-desktop/2.32.0%2Bdfsg-3/evolution/evo-calendar.c).

I don’t profess to know programming in C, or even how to read much of it really, but you learn by doing – so let’s give it a go. Around lines 24-34, we see the declaration of what I believe is a structure:

#include “evo-calendar.h”

ECal *
evo_cal_source_open_source(const char *uri, ECalSourceType type)
ESourceList *sources = NULL;
ESource *source = NULL;
ECal *cal = NULL;
GError *gerror = NULL;

g_debug(“Opening calendar source uri: %s\n”, uri);

This looks like what we need – some code that is trying to open the calendar. It’s also including the header file, evo-calendar.h, which we may need to look at in a sec. So, the main purpose of this code is to open a calendar:

if (strcmp(uri, “default”)) {
if (!e_cal_get_sources(&sources, type, &gerror)) {
g_warning(“Unable to get sources for calendar (type %u): %s”,
type, gerror && gerror->message ? gerror->message : “None”);
return NULL;

source = evo_environment_find_source(sources, uri);
if (!source) {
g_warning(“Unable to find source for calendar (type %u)”, type);
return NULL;

cal = e_cal_new(source, type);
if(!cal) {
g_warning(“Failed to create new calendar (type %u)”, type);
return NULL;

if(!e_cal_open(cal, FALSE, &gerror)) {
g_warning(“Failed to open calendar (type %u): %s”,
type, gerror && gerror->message? gerror->message : “None”);
return NULL;
} else {
if (!e_cal_open_default (&cal, type, NULL, NULL, &gerror)) {
g_warning(“Failed to open default calendar: %s”,
gerror && gerror->message ? gerror->message : “None”);
return NULL;

return cal;

If you read closely, you’ll see that we have an IF statement, followed immediately by another IF statement:

if (strcmp(uri, “default”)) {
if (!e_cal_get_sources(&sources, type, &gerror)) {
g_warning(“Unable to get sources for calendar (type %u): %s”,

strcmp may be a string-compare function. Regardless, because of our error message in the terminal, cited previously, it’s fair to say that this strcmp is returning a TRUE. In other words, a basic test is conducted based on the URI that is being passed in to this function, and an error is being returned.

The error returned, “Failed to open calendar”, is a string within the C source code in this same file, at around line 57:

if(!e_cal_open(cal, FALSE, &gerror)) {
g_warning(“Failed to open calendar (type %u): %s”,
type, gerror && gerror->message? gerror->message : “None”);
return NULL;

This is the error message we are seeing! The (type %u) bit after the message is probably the return code (a general rule is that if the return code is 0, everything is ok, and any valyue other than 0 means there’s a problem)  and the  : %s bit is the string returned from the function trying to open the calendar, giving a reason why.

So, to reiterate our error message:

** (Time Tracker:14088): WARNING **: Failed to open calendar (type 1): Authentication required

The function e_cal_open() is returning this error code.  To understand this function more, and what’s happening in this code, we need to look at the source for this function and also understand what data we’re passing to it.

Firstly, our call to the function is this:

e_cal_open(cal, FALSE, &gerror)

We can come back to what we’re passing to this function in a moment.  Firstly, though, where is the e_cal_open function?  We need to find out how it works!

Remember earlier that our file evo-calendar.c has an “include” pointing to the file evo-calendar.h?  Well, that means “grab the file evo-calendar.h and make its resources available to me”.  Within evo-calendar.h, there is no e_cal_open() function, but there are other includes, including one pointing to libecal/e-cal.h.

On debian, lib-ecal is another package installed along with Evolution.  So, finding the file e-cal.h is as simple as using find or locate.  On my system, the complete path to the file is /usr/include/evolution-data-server-3.4/libecal/e-cal.h. Hurrah – let’s go searching that C for e_cal_open:

$ grep -i e_cal_open /usr/include/evolution-data-server-3.4/libecal/e-cal.h

gboolean e_cal_open (ECal *ecal, gboolean only_if_exists, GError **error);
void e_cal_open_async (ECal *ecal, gboolean only_if_exists);
gboolean    e_cal_open_default (ECal **ecal, ECalSourceType type, ECalAuthFunc func, gpointer data, GError **error);

The first one is the one we’re interested in at present: e_cal_open.

[ Sorry.  This is an incomplete post, published for completeness instead of binned.]

You probably got here because you Googled.  I did 😉

As an eclipse user, occasionally you get greeted with error messages which are tricky to resolve.  The error, “Resource ‘X’ is out of sync with file system” made me scratch my head for a little while – as far as I could tell, it wasn’t!

Screenshot of error dialog
As an eclipse user, sooner or later you’ll see this.

There can be a few causes of this:

  • If you edit any workspace file from outside of eclipse, which is part of your project, this can throw the error.
  • The same is true of directories – have you renamed/moved/deleted anything?
  • The cause which threw my error was symbolic links.  Because I had changed the name of a target directory, this was enough to trigger this error dialog, even though the file name of the symlink itself was unchanged!

To prevent this dialog appearing, as far as possible, visit Window > Preferences > General > Workspace and select:

  • Refresh using native hooks or polling
  • Refresh on access
Image of eclipse preferences window
Selecting appropriate preferences can keep your workspace up to date and reduce the chance of errors appearing.

The combination of ensuring tight controls on renaming files and directories, together with automating detection of this as much as possible, will lead to a smoother experience with this great integrated development environment.

*Getting into Getting Things GNOME!*

(Edit: this is an old draft, now published for testing purposes)

This is the beginning of what I hope will become a multi-part journal of my adventure into contributing free software.  I thought I’d share my education, FWIW! 🙂

Part 1: Read The Flipping Manual(s)!

As a user of a great amount of free software, I often wondered what was involved in producing it.  I was aware of the basic process – or at least I thought, but not really much of the details.

Here’s how I kinda reckoned the basic process works:

My take on the basic process of Free/Open Source software projects

  1. Some people (usually one person) would start a project off, following their interest in some way.
  2. He/She would set up somewhere for software code to live (a repository) which would be available to anyone to download.  This, the source of the project’s code, would be what’s often referred to as “upstream”.  It’s where the goodness flows from.
  3. Other people interested in this software could also join up and contribute changes to the code.
  4. At some point, someone involved with a distributor/vendor like Red Hat or Debian would “notice” the project and be interested in packaging up the software.
  5. The upstream software would get duly packaged up and released into the distributor’s/vendor’s “downstream” repository.  Users could then install and use it at-will.

This only really covers the basic of software creation though.  What about bugs?  Even the best software has the odd bug or two.  What happens then?

There are two main places for bugs to be recorded:

  1. On a downstream bug reporting/management system.
  2. On an upstream bug reporting/management system.

Typically, users of the distributor’s packaged version of the software will report bugs with it on the distributor’s (downstream) system.  Why not on the upstream one?  Mainly because a distro (distribution) will contain an older version of the software that may, upstream, now be fixed of that bug.

When a distro user reports a bug, he/she is reporting against the distribution’s version of that software, not against that software in general.

Doesn’t this create a duplication of bug reports?

In a nutshell, yes.  But it’s better that the same bug is reported twice, than not at all.  Quite often duplicates relating to the same issue are recorded, even on the same system.  They are simply marked as such, with one bug record being the “master”, to which the others are link for reference.

Getting involved upstream

The project I chose to get involved with is Getting Things Gnome! – a Getting Things Done-inspired task manager application for the GNOME desktop.

My motivations to get involved were:

  • I like the GTD methodology – it helps bring focus and organisation to my working day;
  • I want to learn how to program in Python – a well respected and widely utilised programming language;
  • I want to see the gtg tool develop so I can use it more effectively; and
  • I want to contribute something back to the free/open source software community.


Expressing (and progressing) an interest

The first thing to do was to express my interest with a project leader.  From doing this, I received very supportive and constructive emails relating to ways in which I could contribute which suited both the project and me.  (a hat-tip to Izidor Matušov for enormous support and coaching in the early days).

Secondly, after receiving such great support, the thing I soon realised is that the responsibility to check things out really rests with me.  I want to be involved, so I should be the person reading the mailing list posts, reading related blog posts, reading the web site, reading the manual for hackers… You get the idea.  If you’re considering joining a software project, you need to read a lot to learn what it’s all about!

Finally, be prepared.  Prepare your computer to work in the best way possible.  Prepare your mind to be opened up to learning new programming techniques.  And prepare your attitude – you will be rewarded and pleasantly surprised by the capability and maturity of others who are already contributing to the project.

Getting involved in free/open source software is educating, inspiring, liberating and, most importantly … (I hope he doesn’t mind me stealing this line from his first email), “Don’t forget, hacking opensource should be about having fun!”

And it is.

This problem has been reported for other systems – Jayway covers 64-bit Ubuntu, which is where I derived most of the info I needed (thanks guys!).

If you are developing Android apps using Eclipse, especially on 64-bit Fedora 16, then you too may have come across the error message:

Failed to get the adb version: Cannot run program "/home/[user]/[path]/android/[sdk]/tools/adb": java.io.IOException: error=2, No such file or directory

I did.

To fix it, you need to install 32-bit compatibility libraries.  On Ubuntu (and probably Debian) you can use the getlibs tools.  For Fedora users, it requires installing a few bits and pieces.  Easily accomplished with this:

su -
yum install libstdc++.i686 ncurses-libs.i686

Yum will pull in the necessary dependencies.

Restart Eclipse and the error should disappear.

Well Apple-lovers, you sure do choose interesting products. Like the iPod; a “revolutionary” portable audio player, being probably the first to have a non-replaceable battery. I might be wrong, having done no research on the subject, but this was enough to turn me off. Let alone the insistence of using iTunes.

Or the iPad; the computer-but-not-a-computer consumer device that let’s you do anything you want with your media.  So long as it is on Apple’s terms.  I don’t get why someone as apparently intellectual as Stephen Fry gets so excited about it. Yes, it’s so exciting, in fact, that I’d go immediately to iPad.com and check it out!

The iPad. I mean, for goodness sake, it’s a laptop without a keyboard, but with potentially harmful restrictions, a proprietary operating system and about as much appeal as a colonoscopy. According to Fry, it also has no “multitasking, still no Adobe Flash. No camera, no GPS”. But it does have a touch-screen and 3D desktop effects… Perhaps that’s why the Free Software Foundation dropped “Freedom” Fry’s video from their homepage: who’d want to appear as hypocritical as that?

And then there’s the iPhone. This is the biggy. Apple are using typical Microsoft-like tactics here.  Make an “irresistable” upgrade, probably for free or very cheap, and subtly attach some conditions to it. This time, as exposed in Giorgio Sironi’s blog post, The Apple of Sin, the condition is that you must only develop iPhone applications in languages prescribed to you by Apple.

The reasons, given by Giorgio, are pretty clear: Apple want to kill any chance of Flash appearing on the iPhone, else it might be inconsistent with the new iPad policy.

So, Mac users, be aware that your choice of platform may well come to haunt you in a year or two, when Apple extends this anti-Flash policy to OS X.  There is one nice aspect of this, though: Apple might just force Adobe to open-source Flash.  Then will follow a review-and-embrace process, where Flash gains recognition as an open standard.

Then we’ll see if Apple is embracing open standards as it “seems” to be with its current policies.  If not, then you’ll get more choice of hardware and software if you choose Windows. And even more if you opt for Linux and, not only would that be cheaper, you would also retain your right to choose what you do with it.

Sorry about that. 😉

In every day life, I come across a number of things that I find extremely useful.  Instead of clogging up my browser’s bookmarks, I’ll list there here for my reference.

I hope they might be of use to you too!


  • PHP
  • Flex