ps: it’s just marketing, I know. But I really liked the  message…

But this method is inconvenient sometimes: when you want to comment on a patch posted on the list, portions of that patch (which may include long lines that shouldn’t wrap) will show up in the message body and you can have trouble. This is a problem especially when the poster also sent their patch as attachment, because you will most likely need to copy & paste the patch into your reply window and things will get mangled right there.

Turns out that there is a way to include a patch in the message body in Evolution’s compose window and it will get through unmaimed: select the Preformat option in the paragraph style dropdown, and then paste in your patch or use the Insert -> Text File… option.

Caveat: Older versions of Evolution converted tabs to spaces when pasting text, so you had to insert it from a text file to preserve whitespace. I just tested with version 2.12.3 from Debian (package version 2.12.3-1), and pasting a patch containing tabs worked fine so the bug has been fixed.

Thanks Klaus Kiwi for the tip!

This is the tale of my patch-producing efforts. I’m sorry, it is most likely boring for everyone but me. Still, I wanted to write it down so you are free to stop reading the post here.

Anyway, back to where I was: I (foolishly, perhaps?) volunteered to create the patches. One reason for me to do that is that I actually enjoy working with and learning about source code management and related issues, and this was a good opportunity for me to improve my git-fu (since I thought git could help me do the job in a sane way, which fortunately proved to be the case).

I say foolishly because I thought it wouldn’t take too much time to cut out the patches, since I knew what I would have to do… The task of course took longer than I expected, in part because of unforeseen autotools woes, but of course also because I underestimated the effort (I am an optimist).

Here is the method I used:

First of all, I wanted to update the code to the latest CVS version of GDB, because the work in the git repo was done based on a CVS version from February… Nothing to see here, actually. I just created a new branch with the latest CVS update, and rebased the commits on top of that. In hindsight, I should have merged the new CVS update into the python branch, which would have made me deal with less conflicts. I used rebase because I thought I would cherry pick the commits later, so I wanted each of them refreshed.

Then the real fun began. I started using interactive mode of git rebase to squash related commits together (to form the patches), and reorder them. I quickly realised that with this approach I would have a bit of difficulty with commits which touched different areas of the code and crossed the borders I had in my mind for the patches I wanted to generate. I would have to first split those into smaller, more behaving commits and only then squash them with other similar changes. That seemed to be more work than really necessary.

Also, the older commits did things in ways and places which were later changed, and it looked like I would have some trouble reconciling older and newer code to fit in one patch (maybe not though, maybe that would be taken care of more or less naturally). Also, I would need to take some time to familiarise myself with the commits in the branch, because I only authored some of them. The “shuffle commits around” approach wasn’t looking very promising.

I then turned to a different strategy: I generated a big patch containing all of the code in the branch, and applied it (using the plain old patch command) on top of a clean branch which contained only the CVS HEAD version I was using as a base. All I needed to do now was to selectively add to the index the changes that I wanted to include in a patch and then commit those changes together. And repeat the process for the next patch and so on.

It proved to be a good approach, especially because of the interactive mode of git-add. This mode asks you about each change inside a modified file, letting you add that change to the index or skip it, leaving it in the working directory for a future commit. git add -i streamlined the “change picking” process quite a lot, and made the patch-cutting almost mechanical. (By the way, this feature is also available in Mercurial, with the Record extension. I even believe (not sure though) that the Mercurial extension predates git add -i) (I don’t know if Bazaar has it, would be nice to know).

In this phase of the process, git rebase -i was useful. Sometimes I came accross a change in the working directory which would fit better in a patch which I had already committed. It was simply a matter of committing that change and then shuflling it back and squashing with the proper patch.

At each commit I pushed the changes to a pristine repo which I used to build GDB and guarantee that each patch included all the changes it needed.

Voilà, at the end of the process I had a git branch where each commit corresponded to one patch which I wanted to send to the mailing list.

Well, of course this is a dumb approach to the problem, and today I just found out (almost by accident) the smarter way to do it: run the config.status script in the build directory. It will regenerate the Makefile and you can just type make from there, compiling or recompiling just what’s needed.

In addition, you need pay attention to the import wizard’s window to see if all images were downloaded correctly. If an error occurs, the only indication is a small red cross on the image itself. There’s no warning dialog or status message telling you that something went wrong. You have to check each image. I opened a bug report about this too.

This is actually the first problem I had with digikam, and have always had a great experience with it. I really recommend the application to organize your photos (well, just avoid version 0.9.3 ). Along with amarok, I think it’s one of KDE’s killer apps.

Anyway, I started this post to suggest a game which I recently started playing and found very interesting and fun. I know, after  mentioning that two of my favorite games were NetHack and Koules I don’t deserve much credit, but still…

’tis called Neverball,  and is one of those simple, but yet effective games. There’s a ball and you have to make it through the game level while collecting the coins. The thing is, you don’t control the ball. What you actually control is the level floor beneath it. So what you do is tilt the floor to make the ball roll in the direction you want, at the speed you want (well, if you are a good player!).

By the way, since I’m talking about games: there’s one other I find very good. Since I won’t write a full post about it, I might as well mention it here: it’s Pingus, a free Lemmings clone. It’s very well done with good graphics and sound.

I was gladly surprised when I was in FNAC one day and found a player which clearly stated in the box that it was able to play .ogg files (okay, ogg vorbis for the purists out there. but I’ll say .ogg from now on.) and better yet, even not counting this feature, it was actually the player with the best cost/benefit ratio on that store. It’s the Samsung U3.

I’ve been using it for about two months now, and I am enjoying it. You should take this with a grain of salt, since I didn’t have many requirements from a digital player except that it could play .ogg files, and I’m not an expert or music lover. I’m just an occasional listener. The reviews I have read about it tend to be good though, even regarding the sound quality.

One nice thing is it’s form factor. The player is very small, thin and light. I also like it’s very bright OLED screen, and the fact that it’s very simple to use in Linux. It just presents itself as a regular pen drive. It sports 2 GB of capacity, FM radio, sound recording, progressive “fast forward”…

The main drawback is it’s very sensitive touch buttons. They’re cool, but not very practical. You need to look at the device to see where to touch (but eventually you develop your muscle memory and just know where buttons are). You also need to use the player’s hold key a lot, otherwise buttons will activate all the time while the player is in your pocket.

Now, why this need of playing .ogg files? I have all my CDs encoded in ogg vorbis format, and didn’t want to reencode it all. I think ogg vorbis is a better format than mp3 since it’s newer (mp3 is already more than 10 years old. some advances in lossy audio compression must have been made since then!) and patent-unencumbered. Before you ask: no, I can’t hear the difference in quality between .ogg and .mp3… It’s more the decision of an engineer who preferred to go with the newer, shinier system.

First of all, I’m not trying to do rigorous analysis here but just do some estimates to make a decision for personal use. Still, if you find something in my method which invalidates the results I obtained, I’d be glad to know about it.

To know the memory consumption of each desktop system, I simply started a fresh session in that desktop, opened a terminal and obtained a process listing with ps -e. No other program was opened at the time. Because I did this using a new user account, the test was made with the default configuration and default loaded programs of each desktop system.

Since the important figure in the ps output is the RSS (resident set size) column, I also turned off the swap partition in my computer. The ps manpage says that the RSS field doesn’t count swapped memory from the process. Good thing I noticed this before it was too late!

Here is the result for KDE:

And here is the result for XFCE:

So, XFCE uses 152MB of RAM, versus the 191MB KDE uses. Not bad, almost 40MB (20%) less!

That’s not the whole story, though. I also wrote down the output of the free command as a sanity check.

Using KDE:

Using XFCE:

Look at the “used” column, in the “-/+ buffers/cache” line. That is the actual memory amount being used by the running programs in the computer.

This is a very interesting and surprising result: at the end of the day, XFCE actually uses more memory than KDE! Why, if adding up the resident sizes of the processes from each desktop system you get a different conclusion?

One explanation would be that KDE actually shares more memory between processes than XFCE. Its programs most probably have a greater number of shared libraries in common, which enables the kernel to use the same memory pages for the text section of those libraries accross process images. Unfortunately I didn’t collect data to test that possibility, and it’s late at night now. But it makes sense.

The bottom line, surprisingly enough, is that you should stick with KDE to preserve memory. Or switch to a bare-bones window manager instead of a complete desktop system, like IceWM, Window Maker, Blackbox or something else. But I’m too spoiled by the amenities of a good desktop to do that.

By the way, the tests were made with KDE 3.5.8 and XFCE 4.4.2 under Debian GNU/Linux unstable (updated on 2008/01/06) on a 32-bit x86 machine.

http://sourceware.org/ml/frysk/2008-q1/msg00004.html

You have to do a commit just with the rename operation (identical file contents), and then modify it. Sheesh, good to know about that!

I recall I had a similar problem with Subversion once… I think it was refusing my commit or something. I had to go back and do just the rename, commit and then modify the file.

The other hint is about reverting your tree back to how it was at some point in the past, play with it and then come back to present:

1. Write down somewhere the commit ID for the current HEAD.
2. $ git reset --hard <commit id you want to go to>
3. Do something useful with your tree from the past.
4. $ git reset --hard <commit id you wrote down in #1>

Very nice.

… that “after reading in all makefiles, make will consider each as a goal target and attempt to update it. If a makefile has a rule which says how to update it (found either in that very makefile or in another one) or if an implicit rule applies to it (see Using Implicit Rules), it will be updated if necessary. After all makefiles have been checked, if any have actually been changed, make starts with a clean slate and reads all the makefiles over again.“

(From the GNU make Manual)

Self-updating Makefiles! Imagine the possibilities.

I just found out about this feature in KDE which I suspect will become very handy for me from now on: have the taskbar’s clock show the time in different timezones:

To enable it, just right-click on the clock, select “Configure Clock…” and then the “Timezones” tab.

GNOME, of course, has the same feature. That’s how I had the idea to search for this in the first place…