I just pushed out these four commits. Basically they let a libgit user use the functionality which was hardwired to git-merge-tree till now. The idea is from Dscho, so I hope the patches will be welcomed. ;-)

(I did not sent out any patches for now, since my ls-files parseopt patch isn't in yet, either.)

Ah and we talked about (in case I'll be home during the summer) if I should re-apply for git in GSoC. Basically I don't want to do it, but I'm very happy that my ex-mentor even recommends me not doing so. Here are his lines:

> About reapplying for Git... I would _love_ to have you again, since I know > you will get stuff done, and in a very nice way. > > There is always a but. > > But. Realistically, I think that you learnt so many things in the GSoC > project last year, that you do not really have all that much left which > you could learn in the Git community. You really just would be a work > horse. > > There are other projects out there who do fantastic and exciting things, > and have completely different personal (and political!) environments. > > So while the Git community member says "keep him!", the mentor in me says > "let him go!" albeit with half a sad eye. > > Therefore I am strong and point you to http://code.google.com/soc/2008; I > even met some of the guys at the mentor summit, and they are all pretty > cool.

These lines made me happy, really. :-)

So lilypond is a really geek-friendly project to produce music notation from text-based files. It has its own cryptic language. I spent a half day playing with it, so I'm not an expert at all, but I achieved something. ;-)

The example song I wanted to describe is the cantina band from starwars.

To make the long story short, here is the asciidoc source, the Makefile, and the result.

It's out, the only recent change is that I added a new setting to be able to see what is the raw stream BitlBee received. The other interesting part is that after the release I finally decided to split up that huge read callback and now each part is handled by a separate function, and I have a nice array of function pointers. BTW, this also made checkpatch happy about skype.c without doing hacks like:

printf("%s %s",
        foo,
        bar);

Which would really just make the code ugly.

Yay! :)

People say that using bitfields in structs is slow. Of course it reduces memory usage, but the aritmetic is slower than just using pointers.

But my real problem is that if a struct uses bitfields, I can't just pass foo->bar as a pointer. And I hate that. When migrating ls-files to parseopt, I needed to write 3 extra callback functions just because of this.

Grr.

Still preparing for my 'Computer Networks' exam, so I did not do much coding.

LGee just uploaded a few new pictures about his servers, and there are two interesting ones. ;-)

First is this one. And then yes, I must agree that some mainboards are really can't be used a server.

This other one is just interesting - first we though that's a bug in the Frugalware ppc installer, then later it turned out to be a generic Linux-ppc issue.

OK, this was silly.

Yesterday I wanted to reply to a post on the swig mailing list. I found the post on nabble.com, which is way worse than gmane.org, but - I guess - due to SEO black magic Google prefers the previous. So I searched for the mail on gmane.org, appended the usual /raw to the mail, but I still did not get a mbox, to feed it to mutt. Given that I had no idea what do to, I just simply wrote an mbox header, then mutt was able to open it.

And finally it turns out that gmane has a nice export feature. Duh! ;-)

BMH still feeds me with info, he just found a -Qt bug - fortunately the fix was rather trivial.

The nontrivial stuff is that he wants callbacks in the Python bindings and it seems that won't be easy. The reason is that - it seems, I don't have a working implementation yet - we'll need the traditional 'void *data' extra parameters in each callback to support that, since we need to store the Python context pointer somewhere.

Of course first I want to have the whole thing working, before breaking the API with no good reason.

The whole idea is based on this post. The provided examples work fine, at least.

Snip. Dscho mailed me today with a project list about what could I do in Git - the two items are a major merge-recursive rework, the other is about packv4. I could learn a lot with both, my interest is in this order. But that's not yet in coding status, we're just discussing the details ATM.

This came up on the mailing list, and finally resulted in a commit in pacman-g2.git.

The idea is to speed up the pacman -Sy operation just like rsync speeds up not re-transferring already sent data.

Also BMH started to poke me about the bindings privately, so I pushed a few fixes and probably I will continue doing so.

At least if you track git.git's "next" branch. Happy new year! :)

(patch, merge)

I did it in 2oo7 and 2oo6, so I did it this year as well.

Writing such a list takes a lot of time, but I think it worth the effort.