the corner office : tech blog

• Stackoverflow: Flat object file directory structure output with GNU Make
• Stackoverflow: gcc/g++ option to place all object files into separate directory
• Tutorial for using a single Makefile for an entire project
• Implementing non-recursive make
• Recursive make considered harmful

Guess what I'm playing around with.

Eve Online are phasing out support for my old laptop's graphics card, so my half-hearted trading has now become 'no trading.' And since there is no Eve Online, I'm booting back into Ubuntu for the first time in ages. I've upgraded from one of the 09 versions to 10.10, and naturally have all sorts of things to fix.

Sun Java

Sun Java isn't the default. To install: (thanks to here and here).

sudo add-apt-repository "deb http://archive.canonical.com/ maverick partner"
sudo apt-get install sun-java6-jdk

You could just update defaults, using:

sudo update-alternatives --config java

I didn't want openjdk, so removed everything (in which case no update-alternatives is needed:

sudo apt-get remove openjdk-6-jdk openjdk-6-jre openjdk-6-jre-headless openjdk-6-jre-lib

Firefox fonts

Firefox fonts were fuzzy, so back to this old trick:

sudo rm /etc/fonts/conf.d/10*
sudo dpkg-reconfigure fontconfig

Volume Control

The sound volume control button disappeared. To get it back, you can do one of two things:

1. add "Indicator applet" to your panel. That comes with a mail indicator and others. To get rid of those, run:

   sudo apt-get remove indicator-messages indicator-me
   

2. add gnome-volume-control-applet as a startup application.

I presume the Ubuntu bigwigs have decided that the indicator applet is the way of the future. Another suggestion on this page (which I didn't try) was to install sudo apt-get install gnome-volume*. No idea what that does.

• Dispensing with final voodoo. For semantics, never for performance.

  • Renaud Valdera: The final work on the final keyword
  • Developerworks - Brian Goetz: Java theory and practice: Is that your final answer?
  • Wikipedia: final in Java

• Google tech talk: Cliff Click: A JVM does that?

I've always left the mvn release:blah tomfoolery to colleagues. I've been fiddling with some projects at home and even though it's not strictly necessary for pet projects, I've been trying to release fixed versions of some of them.

If I have dependencies on other libraries from the project, I usually show the version tag as ${parent.version}. The maven-release plugin didn't like that, dying with an error:

The version could not be updated: ${parent.version}

The solution (found somewhere online) is to use ${pom.version} instead of ${parent.version}. Maybe it's even more correct to handle libraries via the parent pom's dependencyManagement element, but ${pom.version} works for me.

Stack overflow: Notification when a file changes in .Net. FileSystemWatcher. Simples (not really, eg and eg).

This is a helluva lot easier than the C++-and-Windows-API equivalent which I've used for a while (and which often breaks), that's for sure. Java 7 will have this with JSR 203, but pfffff.

• Stack Overflow: Set up git to pull and push all branches

Ouch.

Java Hangs When Converting 2.2250738585072012e-308. I haven't read it fully yet, but I think it boils down to 'it's suddenly become easy to blow up a JVM,' which has fun implications for a large part of the Interwebs.

I see an old colleague in the thick of things there as well :-)

I've been using git for a few months, but I don't yet know how some parts of it work. One thing I haven't understood entirely is the index - mainly because it's (mostly) possible to chug along using git as it if were CVS or Subversion - do some work, git status to see what's changed, git diff to see changes, git add to add new files, git commit to get it committed.

I say mostly, because there is this shifting-sandish ground where things go wrong or where git diff and git status don't tell me what I expect. I've always known this is due to the 'index', but not really understood how it works.

I have a better idea now, but it's not entirely clear yet. The main thing I read is that it allows one to tailor commits, and to differentiate between known-good commits and stuff for review (which is what git diff shows). I'm not sure whether the intention is broadly different to (or, at this stage, better than) Perforce's changelists, which allowed you to group up changes. I hated Perforce with a passion when I used it, but changelists where the one thing I really liked.

This Stackoverflow discussion seems to be saying, roughly, that git branches are the equivalent to changelists, but that's not entirely true, since branches aren't concurrent. You could argue that it's safer not to have different changelists on the same code base (and it's a common issue in Perforce world where a particular changelist has an overlooked dependency on a change in another changelist and breaks a build), but on balance, when you're comfortable that changes are mutually exclusive, multiple change lists are a useful feature to have.

• Libpuzzle: a library to find similar pictures

• Git FAQ: How do I make an existing non-bare repository bare?

• StackOverflow: Git: Convert normal to bare repository

• Behind the magic curtain (via)