All Blogs

So you want to play around with Gaim 2.0beta1 or CVS, you definately want the Bonjour/RendezVous protocol plugin to be able to IM with your buddies on your local LAN, but you haven't got Howl on your system as you believe Avahi is the way to go (good boy :-))?

Just apply this little patch. It's against current anoncvs from sf.net. You need to build avahi with avahi-compat-howl support.

I've been playing with creating GTK+ widgets using Cairo lately. As I had to write some text for some bloody Word-task (university stuff) I started writing a widget for an "OXO" game, and make a little tutorial on how to make something alike. The task is done (I even had to remove some parts of the text :(), the tutorial isn't finished yet as there are some issues left with the widget.

Anyway, writing 2D drawing code using Cairo is really fun. Sometimes you need some maths to get some tasks done, but it's fun to experiment and the possibilities are almost endless.

Here's a little sample of what I got now, click on the image for a full-scale screenshot:

Some parts of the "logics" inside the widget are still buggy (-> the code to check whether a move is a winning one or not).

I start to get rid of the spammers on my blog. There's still some comment- and trackback-spam, but at least most spambots can't leech several gigabytes of my bandwith anymore. There are still requests done, but they get a 300byte answer, or even less.
One issue left: if I get 2 identical requests (same HTTP_REQUEST, HTTP_REFERER etc), one using HTTP/1.0 and one using HTTP/1.1, my mod_rewrite rules generate another response: 403 (5 bytes) when using HTTP/1.0, 301 (352 bytes) when using HTTP/1.1:

216.195.35.XX - - [16/Dec/2005:14:24:58 +0100] "GET /index.php/all?skin=stockholm HTTP/1.1" 403 5 "http://spamhost/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)"
216.195.35.XX - - [16/Dec/2005:14:25:05 +0100] "GET /index.php/all?skin=stockholm HTTP/1.1" 301 352 "http://spamhost/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)"

Can anyone explain me what causes this?

Thanks to RubenV who helped me out when creating the mod_rewrite rules :)

Sigh. Luckily we got Nat ;-)
I still got my lockups on high IO load, or my mouse starting to go all over the screen and generating random clicks while doing so on high load, after which I get warnings in dmesg the psmouse driver lost ticks. Guess what part of my machine's stack causes that B-)

Although I'm not a big Ubuntu lover, this is most certainly a good thing.
Who doesn't know the "Metro"? :-)

[edit] Looks like Peter saw it too ;-)

After my previous article on Valgrind I started using it more and more, and discovered another nice feature of it. Just check this sample:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <assert.h>

#define MESSAGE "test"

int main(int argc, char *argv[]) {
        char *t = NULL;

        /* Hey, everyone makes mistakes */
        t = (char *)malloc(strlen("" MESSAGE) * sizeof(char));
        assert(t != NULL);
        strcpy(t, "" MESSAGE);

        printf("%s\n", t);

        free(t);

        return 0;
}

Compiling and running looks ok:

$ gcc -g -Wall -Werror -o test2 test2.c
$ ./test2
test

But luckily there's Valgrind to tell us the code is horribly wrong:

$ valgrind --tool=memcheck ./test2
==13483== Memcheck, a memory error detector for x86-linux.
==13483== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==13483== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==13483== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==13483== For more details, rerun with: -v
==13483==
==13483== Invalid write of size 1
==13483==    at 0x1B906485: strcpy (mac_replace_strmem.c:199)
==13483==    by 0x80484B2: main (test2.c:14)
==13483==  Address 0x1BA5C02C is 0 bytes after a block of size 4 alloc'd
==13483==    at 0x1B906B82: malloc (vg_replace_malloc.c:131)
==13483==    by 0x8048472: main (test2.c:12)
==13483==
==13483== Invalid read of size 1
==13483==    at 0x1B968B6B: _IO_vfprintf (in /lib/tls/libc-2.3.5.so)
==13483==    by 0x1B96DF36: _IO_printf (in /lib/tls/libc-2.3.5.so)
==13483==    by 0x1B93DF36: __libc_start_main (in /lib/tls/libc-2.3.5.so)
==13483==  Address 0x1BA5C02C is 0 bytes after a block of size 4 alloc'd
==13483==    at 0x1B906B82: malloc (vg_replace_malloc.c:131)
==13483==    by 0x8048472: main (test2.c:12)
test
==13483==
==13483== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 13 from 1)
==13483== malloc/free: in use at exit: 0 bytes in 0 blocks.
==13483== malloc/free: 1 allocs, 1 frees, 4 bytes allocated.
==13483== For a detailed leak analysis,  rerun with: --leak-check=yes
==13483== For counts of detected errors, rerun with: -v

This should be fairly self-explaining... I guess most C programmers forgot to allocate strlen(msg)+1 (the end '\0') at least once in their life...

By the way: hello Planet Grep :-)