El Tramo | Programming

XMPP Scripting with Sluift

2011-03-05T00:00:00+01:00

Did you ever want to find out what XMPP clients people in your contact list are using? Do you want to migrate your contact list from one server to another, but don’t want to provide your password to some on-line service to do that? Do you have some XMPP-related task you quickly want to write a script for, but don’t want to deal with complex asynchronous APIs? Well, Sluift may be just the thing you are looking for! Sluift is a Lua-based script layer on top of the Swiften XMPP library. It provides a simple API to do common XMPP tasks, either interactively (through an XMPP console), or by running a script in batch mode. In this post, we’ll go through some examples of what you can already do with Sluift today. Let’s start with a very simple task: logging into a server, and sending a message to one of our contacts. We fire up Sluift, and start by typing the commands to log in:

== Sluift XMPP Console (20110304) == 
Press Ctrl-D to exit  
> c = sluift.new_client("alice@wonderland.lit", "MySecret")
> c:connect()
>

Now that we're connected to the server, let's send out presence (so people can see we’re online), and send the message to one of our contacts:

> c:send_presence("I'm here")
> c:send_message("sister@realworld.lit", "Hi there!")

Now, let's wait 3 seconds for her reply, by printing out all the incoming events, and finish off by disconnecting:

> c:for_event(function(e) tprint(e) end, 3000)
([type] => presence, [from] => sister@realworld.lit/Home, 
 [status] => At home)
([type] => presence, [from] => rabbit@wonderland.lit/Party, 
 [status] => Tea party!)
([type] => message, [from] => sister@realworld.lit/Home, 
 [body] => Hi Alice!)
> c:disconnect()
>

Now for a slightly more complex example. Suppose that you want to switch XMPP servers, but you want to take all your contacts with you to your new account. To do this, you start by logging into your current account, and fetch your contact list:

> c = sluift.new_client("alice@wonderland.lit", "MySecret")
> c:connect()
> contacts = c:get_contacts()
> tprint(contacts)
[sister@wonderland.lit] => table
    ( [jid] => sister@wonderland.lit
      [subscription] => both
      [groups] => table ( [1] => Family )
      [name] => Sister )
...

Now that we have our contact list, let’s disconnect, log into our second account, and add all the contacts from the list to the second account:

> c:disconnect()
> c = sluift.new_client("alice@teaparty.lit", "MyOtherSecret")
> c:connect()
> for _, contact in pairs(contacts) do c:add_contact(contact) end

That’s it, all your contacts have now been migrated! So far, we have used Sluift as an interactive XMPP console. However, Sluift’s synchronous/blocking nature (it only executes the next command when you have the results of the previous) also makes it very suitable for writing small batch scripts. For example, you can write a short script to collect statistics about which sever software is popular amongst your contacts:

c = sluift.new_client("alice@wonderland.lit", "MySecret")
c:connect()
versions = {}
for jid, _ in pairs(c:get_contacts()) do
  v = c:get_version(sluift.jid_domain(jid))
  if v then versions[v["name"]] = (versions[v["name"]] or 0) + 1 end
end
for name, cnt in pairs(versions) do print(name .. ": " .. cnt) end
c:disconnect()

Executing the script gives us the following result:

$ ./sluift CollectVersions.lua
jabberd2: 1
Prosody: 25
Isode M-Link: 31
yabberd: 1
SoapBox Server 2007: 1
jabberd: 5
Tigase: 2
ejabberd: 19
Openfire: 4

And finally, we can’t show script examples without including our beloved EchoBot from XMPP: The Definitive Guide:

c = sluift.new_client("echobot@wonderland.lit", "mypass")
c:connect():send_presence("Send me a message")
c:for_event(function(e)
    if e["type"] == "message" then 
      c:send_message(e["from"], e["body"])
    end
  end)

Besides interactive and scripted tasks, another great use for Sluift is for XMPP testing (which is the reason we started Sluift in the first place). However, we will go into details about this use case in a later blog post. For now, if you want to play around with Sluift yourself, you can build a development version from the Swift Git repository (together with some examples), or you can get a snapshot for Windows or Mac OS X here (currently only works on very specific setups). Finally, note that, although you can already do quite some tasks with Sluift today, the API is still quite limited (and undocumented). We are adding new functionality to Sluift as we need it or as people ask for it, so if you’re interested in Sluift, speak up! Stay tuned for more on the topic of XMPP scripting!

Swiften on Lambdas

2011-02-04T00:00:00+01:00

One of the cool new features of the upcoming C++ (0x) standard is support for lambda expressions, providing functional-style inline function declarations. After seeing Herb Sutter’s PDC 2010 webcast on lambdas, I wanted to try this out on Swiften, the XMPP library behind Swift. I adapted the introductory EchoBot example from XMPP: The Definitive Guide, and ported it from Python to a C++ application using Swiften. The result is surprisingly clean. The purpose of EchoBot is simple: connect to an XMPP server, log in, send out a status message to announce you're available, and then wait and respond to all incoming messages with the exact same message. Translating this into C++ code, with lambdas, gives us the following:

#include <Swiften/Swiften.h>

using namespace Swift;

int main(int, char**) {
	// Set up the event loop and network classes
	SimpleEventLoop eventLoop;
	BoostNetworkFactories networkFactories(&amp;eventLoop);

	// Initialize the client with the JID and password
	Client client(
		&quot;echobot@wonderland.lit&quot;, &quot;mypass&quot;, &amp;networkFactories);

	// When the client is connected, send out initial presence
	client.onConnected.connect([&amp;] {
		client.sendPresence(Presence::create(&quot;Send me a message&quot;));
	});

	// When the client receives an incoming message, echo it back
	client.onMessageReceived.connect([&amp;] (Message::ref message) {
		message-&gt;setTo(message-&gt;getFrom());
		message-&gt;setFrom(JID());
		client.sendMessage(message);
	});

	// Start the client
	client.connect();

	// Run the event loop to start processing incoming network events
	eventLoop.run();
	return 0;
}

The flow of the code follows the description of the bot quite closely. Before connecting the client to the network, we declare the actions to be taken on different events: when connected, send out presence, and when a message was received, send it back. Swiften uses signals to notify events, and instead of having to declare slot methods and using boost::bind to connect signals to slots, we can now use lambdas to directly specify what should happen. (for the curious: [&] means that all variables outside of the lambda, i.e. client, are passed by reference) The great thing about this is that this works out of the box with recent compilers: I tried this code with Microsoft Visual Studio 2010 and GCC 4.5.0. (unfortunately, CLang doesn’t support this feature yet) If you want to try building your own XMPP applications using Swiften (with or without C++0x), grab a development version from the Git repository, and consult the Swiften Developers Guide and Swiften API documentation to get started.

Eclipse CPPUnit Error Parser

2010-08-24T00:00:00+02:00

I've recently been experimenting with using Eclipse CDT as IDE for Swift development. One of the handy things is that Eclipse CDT has support for parsing compiler error messages, allowing you to quickly navigate to the failing source code line by simply clicking on the error message. Although Eclipse CDT supports all the compilers we use for Swift out of the box, I was still missing the easy navigation for fixing failing CPPUnit tests. Since the error parser (just like almost everything else from Eclipse) is extensible, I wrote a small plugin for parsing CPPUnit error messages. You can get the plugin by opening Eclipse's Install new software menu, adding http://el-tramo.be/eclipse as a plugin repository, and selecting the ECPPUnit plugin from the list of available software.

“XMPP: The Definitive Guide” Code Examples

2009-07-13T00:00:00+02:00

Although the primary focus of XMPP: The Definitive Guide is explaning the XMPP protocol and all its extensions through text and illustrations, we also included a few Python code examples to help people get started with implementing their own ideas. In fact, we devoted a whole chapter to building an XMPP application, starting out with a simple bot implementation, but gradually extending the application into a full server component. For people who want to try this out for themselves, we’re releasing the source code of all code examples, including a simple echo bot, and different variants of the CheshiR microblogging platform XMPP interface. All examples are built using the lightweight SleekXMPP Python XMPP library. In fact, SleekXMPP is so lightweight that we included a version in the source bundle, making it even easier to get started implementing your own bots and components. Do bear in mind that these examples only serve illustrative purposes for the book, so don’t expect very robust code. Although making this code fail-safe is not really our primary goal (since that would involve a lot of code that would only distract the reader), we do welcome bug reports or fixes. The code examples are available as a source package, or directly from the Git repository (mirrored on GitHub). We will soon put a link to the package on the book’s webpage.

Mixing Cocoa and Qt

2008-08-16T00:00:00+02:00

Qt does a great job at abstracting out platform-specific features into platform-independent C++ APIs. However, sometimes you still need to write platform-specific code for features that are not in Qt (e.g. to access the platform's address book), or to access platform-specific applications (e.g. iTunes) or libraries (e.g. Sparkle). On Mac OS X, almost all interfaces are offered through the Cocoa Objective-C interface, and the interfaces that are written in C++ have been deprecated and will disappear soon in favor of Cocoa. Although the language of Cocoa is different from Qt's, Qt and GCC make it very easy to call these interfaces from within your application. In this post, I will show how this can be done by making an auto-updating application using Sparkle. To create our auto-updating application, we first lay down the auto-updater interface in a (pure) virtual class:

class AutoUpdater {
  public:
    virtual void checkForUpdates() = 0;
};

The Sparkle implementation of this interface has the following C++ header:

class SparkleAutoUpdater : public AutoUpdater {
  public:
    SparkleAutoUpdater(const QString& url);
    ~SparkleAutoUpdater();
    virtual void checkForUpdates();
  private:
    class Private;
    Private* d;
};

Note that I am using the Pimpl idiom to hide Cocoa-specific internals from the API into a private internal class. The actual impementation of the SparkleUpdater needs to call Sparkle's Objective-C API. However, we cannot write the implementation in Objective-C, since the header for our updater (which will be included from within our application) is written in C++. Luckily, GCC's Objective-C++ extension allows you to mix Objective-C with C++ without any problem. So, we create an Objective-C++ implementation of our updater, and put it in a .mm file:

class SparkleAutoUpdater::Private {
  public:
    SUUpdater* updater;
};

SparkleAutoUpdater::SparkleAutoUpdater(const QString& aUrl) {
  d = new Private;
  d->updater = [[SUUpdater sharedUpdater] retain];
  NSURL* url = [NSURL URLWithString:
      [NSString stringWithUTF8String: aUrl.toUtf8().data()]];
  [d->updater setFeedURL: url];
}

SparkleAutoUpdater::~SparkleAutoUpdater() {
  [d->updater release];
  delete d;
}

void SparkleAutoUpdater::checkForUpdates() {
  [d->updater checkForUpdatesInBackground];
}

All we do here is create an SUUpdater (Sparkle's updater class), set it up, and activate it in our checkForUpdates() method. To integrate Objective-C++ classes into a Qt project, qmake provides the OBJECTIVE_SOURCES variable. Knowing this, we add our new classes to our qmake project file:

HEADERS += AutoUpdater.h
SOURCES += AutoUpdater.cpp
mac {
  HEADERS += SparkleAutoUpdater.h
  OBJECTIVE_SOURCES += SparkleAutoUpdater.mm
  LIBS += -framework Sparkle
}

Before we integrate the updater into our application, there is still one detail we have to take care of: if you write Objective-C code that creates objects, you need to instantiate an NSAutoReleasePool to enable Cocoa's memory management. Although we could do this in SparkleAutoUpdater, we're going to put this in a separate initializer class, so we can share this with other Objective-C++ implementations in our application. The body of this class looks as follows:

class CocoaInitializer::Private {
  public:
    NSAutoreleasePool* autoReleasePool;
};

CocoaInitializer::CocoaInitializer() {
  d = new CocoaInitializer::Private();
  NSApplicationLoad();
  d->autoReleasePool = [[NSAutoreleasePool alloc] init];
}

CocoaInitializer::~CocoaInitializer() {
  [d->autoReleasePool release];
  delete d;
}

Now all that's left to do is integrate all this into our application:

int main(int argc, char* argv[]) {
  ...
  AutoUpdater* updater = 0;
#ifdef Q_WS_MAC
  CocoaInitializer cocoaInitiarizer;
  updater = new SparkleUpdater("http://el-tramo.be/myapp/appcast.xml");
#endif
  ...
  if (updater) {
    updater->checkForUpdates();
  }
  ...
}

That's it! If you want to try this out yourself, just download the sources of this mini-project, build them, and off you go. Don't forget to remove ~/Library/Preferences/be.el-tramo.mixing-cocoa-and-qt.plist to clear Sparkle's state cache.

Basic Music Theory in Haskell

2008-06-19T00:00:00+02:00

While doing some spring cleaning around my hard disk, I found a little Haskell program I wrote several years ago in an attempt to learn the basics of music theory. Now, I'm not a pro at writing Haskell, and I know even less about music theory, but I'm hoping that what I wrote down back then is a bit accurate. The program seems to summarize the basics quite consisely: by just having a glance at the program, I'm rediscovering some things I totally forgot about scales and chords. For example, this is what it says about the sus4 chord:

chordNotes Five = [(ScaleNote Major 1), (ScaleNote Major 5)] chordNotes Sus4 = (chordNotes Five) ++ [(ScaleNote Major 4)]

So, sus4 is a power (5) chord (consisting of the first and the fifth of the major scale), added with the 4th note of the major scale. So, for Esus4, the program tells me:

Main> scale2notes $ Scale (read "E") Major [E,F#,G#,A,B,C#,D#]
Main> chord2notes $ Chord (read "E") Sus4

[E,A,B]

Something else I forgot is:

intervals Ionian = [2,2,1,2,2,2,1] intervals Major = Ionian intervals scale = shift (intervals Ionian) (rank scale) where rank ...

So, every scale is really a shift of the major (well, any) scale, which is actually called the Ionian scale. This program might come in handy as a summary of music theory in case I forget these things again :)

:set noexpandtab

2008-06-18T00:00:00+02:00

Google recently published a C++ style guide, containing all the rules that Google code adheres to. Many of the style tips are quite sensible, and well accepted by many developers out there. However, I was surprised to find the following rule:

Spaces vs. Tabs: Use only spaces, and indent 2 spaces at a time. We use spaces for indentation. Do not use tabs in your code. You should set your editor to emit spaces when you hit the tab key.

I never really understood why so many people have such a hatred towards tabs. Is it just because they have seen code where some editor has mixed tabs with spaces (which of course results in a horrible mess)? Or do they have valid counter-arguments, even when tabs are used consistently? Why would you force presentation of your code upon someone if you don't need to? If you use tabs, you don't need rules like ‘indent 2 spaces at a time’: I can choose whether I want 2 spaces, 4, or whatever indentation I feel most comfortable with when reading code. After some discussion, the pro-space people typically come up with the following piece of code, where they have their parameter names aligned:

void SomeClass::someMethodName(int parameterA,
                               unsigned int parameterB,
                               std::string parameterC)
{
    ...
}

No, you can't do that with tabs, that's true. But why would you do that in the first place (unless you're using an editor which does such annoying auto-formating automatically)? When your method name gets too long, it won't fit on your screen anyway. Why don't you indent 2 tabs for your parameter names instead:

void SomeClassWithALongName::someMethodName(
        unsigned int parameterA,
        int parameterB,
        std::string parameterC)
{
    ...
}

Another popular argument is aligning member declarations:


FooClass foo_;
Bar      bar_;

Same remark: why would you do this? Does it really make your code more readable? Besides, it doesn't scale: whenever someone comes along and has to add a VeryLongClassName member, your alignment will be messed up, and you will have to change every member again. My opinion: let the person who reads your code decide how he/she wants to see it, and lay out your code in a way it is flexible to be seen with different view settings. This avoids lengthy discussions about whether tabs should be 2, 3, 4, or 13 spaces wide. Besides, people have been preaching the separation of presentation and content for ages for HTML and CSS, why would this be any different for code?

Unit testing method overrides

2008-03-07T00:00:00+01:00

It probably happened to most of us developers before: while refactoring, you change the name of a virtual method, but forget to change the name of the overriding method in one of your derived classes. Compilation works fine, all unit tests pass, but your program doesn't work: the overriding method is never called. Java (and C#) programmers can avoid this problem by putting @Override (and override) in front of their methods, which causes the compiler to print out an error message if the method is not overriding anything. However, most other languages leave you hanging with this problem. Luckily, with statically typed languages like C++, you can avoid these bugs by slightly adapting your unit tests. Suppose you have a base class Oracle, and a derived class GeekyOracle, defined as follows:


  class Oracle {
    virtual int getLckyNmbr() {
      return 13;
    }
  };

  class GeekyOracle : public Oracle {
    virtual int getLckyNmbr() {
      return 42;
    }
  };

Being a good developer, you unit test GeekyOracle's getLckyNmbr():


  void GeekyOracleTest::testGetLckyNmbr() {
    GeekyOracle* oracle = createGeekyOracle();
    assertEquals(42, oracle->getLckyNmbr());
  }

After a while, you realize that using abbreviations in method names is actually not very good practice, so you change your method name to something more readable:


  class Oracle {
    virtual int getLuckyNumber() {
      return 13;
    }
  };

However, when you compile your program now, it is behaving completely different than before, although all unit tests passed. It requires manual debugging to find out that you forgot to rename GeekyOracle's method as well, causing Oracle's getLuckyNumber() to be executed, no matter what oracle you instantiate. Your unit tests didn't catch this, because they test every method of a class separately, but don't test the class being used in your application. A way to check for this in your unit tests is to make sure that, when testing a virtual method, you always call it on an object that is statically typed with its base class. In our example, our unit test would call getLckyNmbr() on an Oracle instead of on a GeekyOracle:


  void GeekyOracleTest::testGetLckyNmbr() {
    Oracle* oracle = createGeekyOracle();
    assertEquals(42, oracle->getLckyNmbr());
  }

This unit test will fail to compile when you change the method name of the base class, which avoids you end up with the silly bug in your program. If your test allocates your object under test on the stack (e.g. for simplicity), you could use the following alternative:


  void GeekyOracleTest::testGetLckyNmbr() {
    GeekyOracle oracle;
    assertEquals(42, ((Oracle*) &oracle)->getLckyNmbr());
  }

However, since this degrades the readability of the test, I prefer to add a static helper method to my unit test, and write the test as follows:


  static inline Oracle* p(Oracle& foo) {
    return &foo;
  }

  void GeekyOracleTest::testGetLckyNmbr() {
    GeekyOracle oracle;
    assertEquals(42, p(oracle)->getLckyNmbr());
  }

Although I used C++ in my example, this technique should work for all statically typed languages. Advocates of dynamically typed languages claim they can compensate the lack of types by unit testing their classes properly; I wonder how they avoid this kind of problems, though.

Qtopia Greenphone Grant

2007-08-15T00:00:00+02:00

A month or 2 ago, I applied for the Qtopia Greenphone Innovation Grant Program, an initiative from TrollTech to promote the development of applications for their Linux-based Qtopia Greenphone. I probably won't surprise anyone by saying that I sent in a proposal about writing a good, cross-platform, mobile Jabber/XMPP client. Anyway, I was very excited to receive a mail from TrollTech yesterday, stating that my proposal was accepted by their review panel! As an applicant, I will be receiving a shiny new Greenphone, together with a Qtopia SDK to develop against. Deadline for submitting my application: October 31st. Let the coding begin.

'The First 10 Prolog Programming Contests' available for downloading

2006-07-01T00:00:00+02:00

Exactly one year after we finished it, our book `The First 10 Prolog Programming Contests' is now freely downloadable. On the home page of the book, you will also find the source code of all solutions presented in the book. Below are some pictures of the 'deluxe' edition of the book, hand-made by my mom.