Recently in Computer Category

August 21, 2013

openSUSE 12.3

Here is a random recommendation for openSUSE 12.3.  It seems that, while we were all busy moaning about GNOME's recent-ish design decisions, KDE has gradually been becoming absolutely awesome.  Loads of features, fast, stable and looks beautiful.  Switching to openSUSE with KDE after using Fedora with LXDE (up to version 17) is like waking up from a horrible dream.  There were only a tiny number of things that I needed to tweak or fight against after installation.

To whichever programmer did the extra fiddling to make things such that the assignments of the other mouse buttons, no matter how weird, are preserved when you switch between right or left-handed mode: I noticed it and appreciate your work - thank you.

Fun with linking data files

Here's a neat trick that I recently discovered, from here.  Say you have a data file which is needed by your program, and you don't want to bother with installing it in /usr/share/somewhere and having to "make install" every time you want to test a tiny change.  You would also prefer to edit it as a separate file, not weave it into your other source code somehow.  You can achieve this by creating an object out of the file itself and linking it into your binary.  The procedure is quite simple:

$ ld -r -b binary -o myfile.o myfile.txt
$ gcc myprogram.o myfile.o -o myprogram

Then, in C:

extern void *_binary_myfile_txt_start;
extern void *_binary_myfile_txt_size;

void get_data()
size_t len;
char *v;

len = (size_t)&_binary_myfile_txt_size;
v = malloc(len+1);
memcpy(v, &_binary_myfile_txt_start, len);
v[len] = '\0';
printf("myfile.txt contains '%s'\n", v);

Contrary to what's implied by the original article, I don't think you can assume that the data is zero-terminated (why would it add a terminator?  It's binary data as far as the linker is concerned, not text).  This example code includes some extra faffing around to add the terminator.

This technique works quite nicely with automake as well.  In, I put something like this:

src/myfile.o: src/myfile.txt
ld -r -b binary -o src/myfile.o src/myfile.txt
LDADD += src/myfile.o

I use a single at the top level of my project, avoiding "recursive make" where possible, so everything is prefixed with "src/".  The symbols used to find the data in the program therefore look more like this:

extern void *_binary_src_myfile_txt_start;
extern void *_binary_src_myfile_txt_end;

Disadvantages of this technique?  "ld" is not the linker on all platforms supported by autotools, e.g. Mac OS X, so it's not very portable.

July 28, 2013

GPG public key

Encrypted email is welcome to any of my addresses.
Key fingerprint = 4E1F C14D 0E0A A014 FE5D 3FC6 C628 75D1 D4CA 4C30

$ gpg --keyserver --recv-keys D4CA4C30

Version: GnuPG v2.0.19 (GNU/Linux)


August 9, 2012

Reproducible random ordering from "sort -R"

Random discovery for the day (actually yesterday, but never mind): "sort -R", which randomises the order of lines in its input, uses a crytographic random number generator seeded using numbers which include its PID and the time.  It's the same random number generator as used by "shred": ISAAC.

So, if you need to get the same random order of lines each time, as I did for a test script, you need to provide your own source of "random" numbers.  Any old binary file will do, for example:

$ sort -R --random-source=/bin/ls

October 4, 2011

Project X

I'm still here, and programming.  Work has been taking up most of my "programming brain" recently, but the results will hopefully be released as free and open source software very soon.

For the last few months I've been working on a new non-work project as well, which I'm not going to say too much about just yet - let's call it Project X for now.  It's a piece of major "itch scratching" for me, but I have a feeling that many other scientists who use Linux will love it.  Perhaps many other people besides.  Watch this space...

July 6, 2011

Command line weight loss

$ sudo setweight --bmi=21

It'd be nice if it were that simple.  But it almost is!

Scales of Truth
is a command line implementation of The Hacker's Diet.  The basic principle is to lose (or gain, I guess, theoretically at least) weight by taking an engineering approach to your body's energy requirements. There are quite a few implementations of this or similar things (e.g. The Hacker's Diet Online and Physics Diet), and an important feature is that the required day-to-day administration, i.e. typing in your weight, is not very time-consuming.  Less than five minutes a day?  Well opening a website, logging in, typing a value in and so on seems like a lot of work to me.  With Scales of Truth, you simply click over to one of the many terminals you no doubt have open, and type:

$ sot XXX

Where "XXX" is your current scale reading (in your choice of unit).  Scales of Truth does all the necessary calculations, backs up your readings using Git (because losing months of figures would really suck), and displays some interesting statistics:

Current mass estimate: XXX kg (instantaneous BMI XX.X kg/m^2)
7-day change: -.42 kg (-1757.2 kJ or -419.9 kcal per day)
30-day change: -2.77 kg (-2704.2 kJ or -646.3 kcal per day)

If you happen to miss a few readings, it interpolates the missing values automatically so your running average stays up to date.  For the average reader of this site, the whole procedure probably takes slightly less than two seconds.  That is, assuming you can resist taking a look at your progress using "sot --graph":

sot.pngThat's my own graph for the last few months, so I've taken the liberty of removing the actual numbers.  Suffice to say that each tick on the mass axis corresponds to two kilograms, and I'm rather pleased with progress so far...

You can download Scales of Truth right here.  Simply download the file, open it in a text editor, satisfy yourself that it's not going to do anything evil to your computer, then follow the instructions.

September 13, 2010

Trackball Configuration

I have a slightly strange configuration for my trackball.  I have it set up left-handed, so the main button on the right is "left click", and vice-versa.  There are two smaller buttons, one on each side, and I have the left-hand one as "middle click" and the right-hand one turning the ball into a "scroll wheel" when it's held ("wheel emulation" in X speak).  To complicate matters, I have the trackpad on my laptop right-handed.  In previous times, I'd configure this with some lines like these in the relevant section of xorg.conf to set up the buttons properly just for the trackball:

Option "Buttons" "9"
Option "EmulateWheel" "on"
Option "EmulateWheelButton" "9"
Option "ButtonMapping" "3 8 1 4 5 6 7 2 9"

That worked until the business of HAL for X input configuration came along.  Then I put something like this in /etc/hal/fdi/policy/trackball.fdi:

<deviceinfo version="0.2">
  <match key="info.product" string="Logitech USB Trackball">
   <merge key="input.x11_driver" type="string">mouse</merge>
   <merge key="input.x11_options.Buttons" type="string">5</merge>
   <merge key="input.x11_options.EmulateWheel" type="string">true</merge>
   <merge key="input.x11_options.EmulateWheelButton" type="string">9</merge>
   <merge key="input.x11_options.ZaxisMapping" type="string">4 5</merge>
   <merge key="input.x11_options.ButtonMapping" type="string">3 2 1 4 5 6 7 8 9</merge>
   <merge key="input.x11_options.MinSpeed" type="string">0.40</merge>
   <merge key="input.x11_options.MaxSpeed" type="string">0.60</merge>
   <merge key="input.x11_options.AccelFactor" type="string">0.010</merge>

That worked, but never quite satisfactorily.  In some versions, the trackball would only work properly if plugged in after I'd booted up and logged in.  In later versions (notably Fedora 12 and 13) it would never work correctly at all.  In Fedora 13, the HAL method was deprecated and replaced with a method via files under /etc/X11/xorg.conf.d/.  I added a file called "01-trackball.conf" containing:

Section "InputClass"
  Identifier     "trackball"
  MatchProduct   "Logitech USB Trackball"
  Option         "Buttons" "9"
  Option         "EmulateWheel" "on"
  Option         "EmulateWheelButton" "9"
  Option         "ButtonMapping" "3 8 1 4 5 6 7 2 9"

Section "InputClass"
  Identifier     "trackpad"
  MatchProduct   "SynPS/2 Synaptics TouchPad"
  Option         "ButtonMapping" "1 2 3"

These lines define the exact button configuration for both the trackball and the trackpad, and the combination of InputClass and MatchProduct means that the rule works even if the trackball isn't present when X starts.

But it still didn't quite work.  It seemed that the settings always got overridden by Gnome's central mouse options, left or right handed but not my strange mixture.  The main buttons (left and right click) on the trackball had to be the same as the trackpad because Gnome couldn't understand the idea of having the two configured differently.

With a little clear thought, it's probably already obvious what was going wrong, though it was infuriating for a long time.  Gnome (specifically gnome-settings-daemon) does indeed override your nicely thought out X config.  Fortunately, besides "left handed" and "right handed" modes, it also has an extra mode called "don't screw with my damn setup you piece of ****".  It just takes a little more surgery to enable:

$ gconftool-2 -s /apps/gnome_settings_daemon/plugins/mouse/active --type bool false

With Gnome's mouse config stuff safely (and permanently) anaesthetised, you're clear to configure things your way again.

August 22, 2010

Thinkpad DVD Noise

My handy household hint for the weekend:

One problem I've been experiencing with my new(ish) Thinkpad T500 is the large amount of noise made by the DVD drive.  It's loud enough to be distracting when watching a film - not quite enough to drown it out, but enough to be clearly heard over even the louder parts until your mind starts filtering it out.  The tray rattles against the casing, which makes it much worse.  I found the noise could be reduced significantly by squashing one or two bits of folded tissue between then tray and the casing above, but that's a nasty solution.

Of course, there's a proper fix for this.  Just go into the BIOS config (press the blue ThinkVantage button when the BIOS boot screen shows up, hold it down until the message goes away, then follow the instructions), and find the options for the CD drive, and set it to "Silent".  Problem solved - the drive becomes almost inaudible, and it doesn't seem to have any adverse effect on the playback of DVDs.

June 30, 2010

iAudio X5 Tagging

The Cowon iAudio X5 is, in many ways, the ideal music player for the discerning geek.  It's Linux friendly, behaving as a normal USB mass storage device requiring no special software nor drivers; it plays Ogg/Vorbis and FLAC files; it has a line in connector; it has fantastic sound quality; it organises your files by folder, so you can have your files organised how you really want them.  It also has a battery which lasts ages, particularly the X5L version.  When my X5L was younger, a full charge would last for about two weeks of fairly constant use at work.  Now it's several years old - I've actually forgotten how old exactly - and it still lasts for many days.

It does, however, have a particular weirdness when handling Ogg/Vorbis files.  Its tag parser is extremely basic, and apparently just skips one character (the equals sign) after finding the letters "ARTIST" in the tags.  But most recent ripping software adds an extra field, called ARTISTSORT.  The X5 often finds that instead of ARTIST, and thinks the name of the artist is something like "ORT=Haza, Ofra" instead of "Ofra Haza".

So, I wrote a little script to remove the ARTISTSORT tags altogether.  It's a cheap solution - it'd probably be better just to move that tag to the end (possibly the start, I didn't really test) of the tags field, but this field isn't used for sorting on the X5 anyway.

Here's the script ("ogg-retag").  It's really simple:


if [ -e ogg.tags ]; then
        echo "ogg.tags file exists.  Please remove it first."
        exit 1

for FILENAME in "$@"; do

        echo "Processing "$FILENAME

        # Dump tags to file, removing ARTISTSORT tag
        vorbiscomment -l "$FILENAME" | grep -v "ARTISTSORT=" \
                > ogg.tags

        # Write tags back
        vorbiscomment -w -c ogg.tags "$FILENAME"


rm -f ogg.tags

To run, simply "cd" into the folder containing the problematic Ogg/Vorbis files, then run "ogg-retag *.ogg" or similar.

May 24, 2010

Easier Partial "DCommitting"

I've been making extensive use of Git-SVN recently, because I vastly prefer the user interface of Git to that of SVN, yet am collaborating on a project which uses SVN.  My workflow consists of keeping a set of commits on top of the commits from SVN, which do things like add .gitignore files (hint: use git svn create-ignore to make these automatically), or contain code that I'm not ready to show other people just yet, or don't ever want to release.

This isn't the most advanced use of git-svn possible, but it's quite neat, simple and difficult to make mistakes with.  When I described the method on IRC to someone who was asking about exactly this situation, it sounded like my method was of interest.  I promised to do a short write-up, and here it is.

My workflow consists of three simple(ish) aliases.  The first one is the simplest, for updating to the latest SVN trunk:

git stash && git svn rebase && git stash pop

This just stashes any local changes to the working tree, then rebases the unpublished, "floating" commits on top of the latest commits from SVN.

The second is used when I have one or more commits to add to the SVN repository. Having previously created a branch "for-commit" (it doesn't matter where it's based initially), I open "gitk" and make sure it's up to date.  It probably looks something like this:

Then I invoke the second alias, which is:

git stash && git checkout for-commit && git reset --hard remotes/git-svn

This stashes local changes, checks out the "for-commit" branch and resets it to the most recent known head of the Subversion trunk.  Then I refresh my gitk window, which then looks like this:

during-1.pngNothing too exciting has happened, but we're now on the "for-commit" branch which points in a sensible place.  I right-click* each commit that's to be committed to Subversion, and cherry-pick them onto the "for-commit" branch:

So, now the "for-commit" branch has diverged from "master" because the commits have been re-written by the cherry-pick operation.  Now comes the clever(ish) part, which is the third alias:

git svn dcommit && git checkout master && git svn rebase && git stash pop

This commits the contents of the for-commit branch to SVN, then switches back to master and rebases it on top of the latest SVN branch, which now includes the commits just added.  Git-SVN is clever enough to realise that some of the commits, but not all, are now in SVN.  Gitk looks like this after a final update:

There are a couple of "sidings" in the history.  The lower of the two is the old location of the "floating" commits on master.  The upper one is the previous location of the for-commit branch.  You could tidy them up by restarting gitk, but I find they're useful for keeping track of what I did.  If you look closely, you'll notice that someone else added a commit to the Subversion branch between the last time I updated and the final commit, and git-svn dealt with that too.

So there you go.  Maybe that's useful to someone.

* I don't actually "right-click", since I'm left-handed.  I also use a trackball instead of a mouse.  You should get one - they're awesome.