Random stuff

Going to Brazil

On Sunday I will be going to be travelling to São Carlos, Brazil for two weeks of the Launchpad sprint. It will be my first time travelling to either Brazil or South America so should be fun. That leaves just North America as the only major continent I haven’t visited.

Bryan’s Bazaar Tutorial

Bryan: there are a number of steps you can skip in your little tutorial:

  1. You don’t need to set my-default-archive. If you often work with multiple archives, you can treat working copies for all archives pretty much the same. If you are currently inside a working copy, any branch names you use will be relative to your current one, so you can still use short branch names in almost all cases (this is similar to the reason I don’t set $CVSROOT when working with CVS).
  2. If you have a directory which contains only the files you want to import into your Bazaar archive, the following command will add them all, and convert the directory into a Bazaar working copy:
    cd background-channels
baz import -a bclark@redhat.com--gnomearchive/background-channels--dev--0.1

    No need for init-tree, add or commit.

  3. Running archive-mirror in your working copy will mirror that archive, so doesn’t need my-default-archive set.
  4. Other people probably don’t want to set your archive as their default. Also, they can ommit the register-archive call entirely:
    baz get http://gnome.org/~clarkbw/arch/background-channels--dev--0.1

    This checks out the branch, and registers the archive as a side effect.

  5. If you want to find out what is inside an archive, the following command is quite convenient:
    baz abrowse http://gnome.org/~clarkbw/arch

Some things you might want to do:

  1. If you have a PGP key, create a signed archive. This will cryptographically sign all revisions. When people checkout your branches, the signatures get checked automatically (this is useful if the server hosting your mirror gets broken into and you need to verify that nothing has been tampered with). If you have already created the archive, you can turn on signing with baz change-archive (remember to update the mirror archive too).
  2. If you turn on signing, consider using a PGP agent like gnome-gpg. You can configure it in ~/.arch-params/archives/defaults.
  3. It is customary to name the archive directory the same as the archive name. This has the benefit that the branch name matches the last portion of the URL.
  4. If you haven’t set up a revision library, you should do so:
    mkdir ~/.arch-revlib
baz my-revision-library ~/.arch-revlib
baz library-config --greedy --sparse ~/.arch-revlib

pkg-config vs. Cross Compile and Multi-arch

One of the areas where pkg-config can cause some problems is when trying to cross compile some code, or when working with multi-arch systems (such as bi-arch AMD64 Linux distros). While it is possible to use pkg-config in such systems by manipulating $PKG_CONFIG_PATH and/or $PKG_CONFIG_LIBDIR, users can’t just follow the instructions given for the single-arch case.

After some discussion with Wolfgang Wieser, we came up with a proposal for better supporting cross-compile and multi-arch uses. The main changes would be:

  • Add a new --host option pkg-config. This would allow pkg-config to use different default search paths based on the host type, and search for .pc files in host type specific subdirs on the search path.
  • If an unknown host type is given, then no default search path is disabled altogether.
  • The autoconf macro would pass this argument whenever it detected that pkg-config supported it.

For the common case, this should allow most packages to be built for the non default architecture on a bi-arch system, or cross compiled, by just passing --host=foo to configure and (you might still need to set $CC or $CFLAGS, depending on the compiler setup).

For packages that install .pc files, they should continue to work. However it will be worth updating them to install their .pc file into a host type specific sub directory (the autoconf macros will make this easy to do).

If this code is likely to affect you, send comments to the pkg-config mailing list (or leave comments here).

HTTP code in GWeather

  • Post author:
  • Post category:Uncategorized

One of the things that pisses me off about gweather is that it occasionally hangs and stops updating. It is a bit easier to tell when this has occurred these days, since it is quite obvious something’s wrong if gweather thinks it is night time when it clearly isn’t.

The current code uses gnome-vfs, which isn’t the best choice for this sort of thing. The code is the usual mess you get when turning an algoithm inside out to work through callbacks in C:

  1. One function opens the URL with gnome_vfs_async_open().
  2. The callback that gets triggered on completion of the open calls gnome_vfs_async_read().
  3. The callback that gets triggered on the end of the read checks the status. If it is at the end of the stream, then process the data and close the stream. Otherwise, perform another read (which will loop back to this step).

This logic is repeated 5 times for the different weather data sources. To clean this up, I started looking at libsoup which doesn’t try to be a full file system abstraction, but provides a better API for the kind of things gweather does.

I put together a simple HttpResource class that wraps the relevant parts of libsoup for apps like gweather. It can be used like so:

  1. Create an HttpResource instance for the given URI.
  2. Connect a handler to the resource’s updated signal.
  3. Call the _set_update_interval() method to say how often the resource should be checked.
  4. Call the _refresh() method to kick off periodic freshness checks.
  5. When new data arrives, the updated signal is emitted.

Since the code is designed for periodic updates, I added some simple caching behaviour. If the server reports that the resource hasn’t been modified, we don’t need to emit the updated signal.

There are a few things that still need doing:

  • Some code to keep a SoupSession instance up to date with the proxy configuration settings in GConf.
  • Correct handling of the Expires: response header. If we are checking for updates every 30 minutes, but the server says the current weather report is current for the next hour, then we shouldn’t check again til then.
  • Support gzip and/or deflate content transfer encoding to reduce bandwidth.

This code should be pretty trivial to integrate into gweather when it is done, and should simplify the logic. I guess it would be useful for other applets too, such as gtik. The current code is available in my Bazaar archive:

baz get http://www.gnome.org/~jamesh/arch/james@jamesh.id.au/http-resource--devel--0

Overriding Class Methods in Python

  • Post author:
  • Post category:Uncategorized

One of the features added back in Python 2.2 was class methods. These differ from traditional methods in the following ways:

  1. They can be called on both the class itself and instances of the class.
  2. Rather than binding to an instance, they bind to the class. This means that the first argument passed to the method is a class object rather than an instance.

For most intents and purposes, class methods are written the same way as normal instance methods. One place that things differ is overriding a class method in a subclass. The following simple example demonstrates the problem:

class SubClass(ParentClass):
    @classmethod
    def create(cls, arg):
        ret = ParentClass.create(cls, arg)
        ret.dosomethingelse()
        return ret

This code is broken because the ParentClass.create() call is calling the version of create() method in the context of ParentClass, rather than calling an unbound method like it would with a normal instance method. The most likely outcome will be a TypeError due to the method receiving too many arguments.

So how do you chain up to the parent class implementation? You use the super() object, which was also added in Python 2.2 as an alternative way to chain to the parent implementation of a method. The above code rewritten as follows:

class SubClass(ParentClass):
    @classmethod
    def create(cls, arg):
        ret = super(SubClass, cls).create(arg)
        ret.dosomethingelse()
        return ret

If you haven’t ever used the super() object, this is what it is doing in the above example:

  1. SubClass is looked up in the list cls.__mro__ (a linearised list of ancestor classes in the order used for method resolution).
  2. The class dict for each ancestor class coming after SubClass in cls.__mro__ is checked to see if it contains “create“.
  3. The super() object returns a version of “create” in the context of cls using the __get__(cls) “descriptor get” method.
  4. When this bound method gets called, cls will be passed in instead of the parent class.

Previously I’d ignored super() for the most part, since I could use the old chaining syntax. This shows a place where the old-style syntax can’t be applied.