HTTP proxy and apt

This might be well-known, but I though I'd mention it anyway, as it seems a bit mysterious at first sight.
If you live behind a HTTP proxy you probably are used to the two ways of making your system use the proxy: by http_proxy and no_proxy environment variables and by the GNOME Network Proxy Preferences (gnome-network-properties). But either way it can happen that simple sudo aptitude or sudo apt-get install foo fail because it tries to access the internet directly, ignoring the proxy setting. So, why is that?

Eclipse CDT: removing non-existent include paths

It seems that Eclipse CDT doesn't like it when you have a non-existent path in the list of project include paths. Fair enough. You can selectively remove the non-existent paths from your project via some mouse-clicking.

But if you are generating your Eclipse project via, say, CMake and you're unfortunate enough that you can't reasonably change the CMake project files (think of evil upstream and you not wanting to patch their overly complex build system changing with every release), what do you do? After a bunch of project regenerations removing of the include paths by hand becomes annoying.

As I was experiencing this issue, I decided to hack together an Eclipse plugin to resolve this for me. And here is the result: fixincludes Eclipse CDT plugin.

Linux 3.0 on ALIX 2d3

Update: Due to the way the current ALIX LEDs driver is implemented it cannot be used at the same time the generic GPIO driver is loaded. :-/ Luckily there's some work going on to resolve the issue - see this commit in linux-next.

Just an update: Here's a linux 3.0-rc4 config file for ALIX 2, more specifically for the ALIX 2d3.
This should have all the basic things on the board running, including Ethernet, USB, LEDs, GPIO (not tested), watchdog.
You most certainly want to hand-tune it for your particular setup. No WiFi driver is enabled in the referenced config -- if you have one (or two :-)) wireless NICs in your ALIX, you certainly want to add that to your configuration.

Creating animated SVG plots with GNU Octave and gnuplot

It's relatively easy to create an animated plot as either a video (AVI, MPEG, ...) file or an animated GIF file via GNU Octave or gnuplot -- one needs only to create a sequence of images and then use a tool like mencoder or ffmpeg to combine these into a single video file.

But how about an animated SVG file? As plots are vector by nature, an animated vector file sounds cool. Gnuplot is capable of producing output graphs in SVG format, but I was not successful in finding a way of converting these into a single animated SVG.

So I hacked together something for the task. If you have a recent-enough browser (tested in Firefox 4.0.1 and Chromium 11.0.696.65) you can have a look at a trivial example.
If you're interested, grab the scripts here: ani-plot

Windows XP both native and in VirtualBox

There are several good tutorials about similar topics, namely:

1. How to migrate existing Windows installations to VirtualBox
2. HOWTO: Windows XP in both VM and native

but I couldn't find any that would describe what I was trying to achieve.

What I had: Windows XP installed on a physical partition. What I wanted: Being able to run the installation both inside VirtualBox and also natively. I did not want to reinstall the WinXP installation nor did I want to have to fiddle with any Windows Genuine Disadvantage stuff. And I didn't want to break the native boot in the process. Also, as this was some über-corporate install I didn't want to have to ever use the WinXP install CD + its rescue console.

Using Glib::RefPtr with STL sorted containers

It turns there's a bug in glibmm that prevents one from using Glib::RefPtr<T> with any of the STL sorted containers, e.g. std::map or std::set.

The issue is a side effect of Glib::RefPtr<T>:

• declaring operators == and !=
• declaring operator bool()
• not declaring operators <, <=, >, >=

The operators == and != compare pointers for equality and work as expected. The operator bool() is defined to allow the following usage of a RefPtr:

if (ref_ptr)
    puts("is non-null");
else
    puts("is null");

STL sorted containers need operator< on the type they contain. Assuming p1 and p2 are of type Glib::RefPtr<T>, the following compiles just fine:

p1 < p2

This in turn means that e.g. std::set<Glib::RefPtr<T> > my_map; compiles. Unfortunately, with current version of glibmm, this breaks badly at runtime.

Why? As there's no custom operator<, the compiler interprets p1 < p2 like this:

(bool)p1 < (bool)p2

This is true iff p1 is NULL and p2 is non-NULL. The operators <=, >, >= also work on the results of operator bool(). So, depending on the pointers wrapped in p1 and p2, it's possible that the following would be true:

p1 != p2 && !(p1 < p2) && !(p1 > p2)

(this is true iff p1 and p2 wrap two different non-NULL pointers)

There's a bug report for the issue.

A workaround for the time being is to use a custom comparator like this:

template<typename T>
class RefPtrLess
{
public:
    bool operator() (const Glib::RefPtr<T> &a,
        const Glib::RefPtr<T> &b)
    {
        const T* const a_ptr = a.operator->();
        const T* const b_ptr = b.operator->();

        return a_ptr < b_ptr;
    }
};

typedef std::set<Glib::RefPtr<MyType>, RefPtrLess<MyType> > TMyTypeSet;

Sending git patches from a different box

Here's a solution to a problem that's been bothering me for a while: I wanted to create git patches from a box where there is no real MTA and so git send-email can't be used.

One option is setting up real mail MTA or something simpler like msmtp or nullmailer. While this is the preferable, "true unix" way, I think plenty of ordinary linux users don't have this either.

If, for whatever reason, this is not an option, but you have access to another box, where a MTA is set up correctly, you can do this:

1. commit the change(s) into the git tree
2. create the patch emails with: git format-patch --to to@addr ...
3. transfer the produced patch email files to the box where you can send mails from
4. send the email(s) with: /usr/sbin/sendmail -oi -t < mail-formatted.patch

The first time I suggest you send the patch to yourself to verify it's all working as expected.

This approach has a downside: You don't see the mails you sent in your MUA sent mail folder. Depending on your MUA, there are other ways of sending the mail. If you're using mutt, you might be in luck. But in general MUAs tend to mangle the patches. :-(