Using gpsbabel and a USB to serial adapter on OS X to read out a Garmin GPS

For a couple of years I have been owning a Garmin eTrex GPS receiver. It’s a nice little tool, pretty ruggedized and reliable. I use it to track for example hiking tracks and also sometimes for Geocaching. It has a serial interface for downloading the data. However, my MacBook Pro does not have a serial port. So I bought one of the ubiquitous Digitus USB to Serial adapters. With this and gpsbabel (sudo port install gpsbabel, if you have MacPorts), it is really easy to download the track data for example to a KML file to be viewed in Google Earth:

gpsbabel -t -i garmin -f /dev/cu.usbserial-XXXXXX -o kml -F mytracks.kml

The XXXXXX in the device filename varies from device to device, you probably can also use /dev/cu.usbserial-* as the device filename, if you have only one of these things attached to your computer. It is important not to use the tty device file, since it seems not to work. I do not know yet what the exact difference is, but I will come back when I found out.

BibTeX bibliography title

The other day I was using the moderncv document class to create a CV. I also added my publications to the CV, which was supposed to be in German. BibTeX created a section “Literatur” for this. Obviously, I wanted the title of the bibliography to be “Publikationen” instead. When using the german package of babel, you can change the bibliography title like this in the LaTeX preamble:

addtocaptionsgerman{renewcommand{refname}{Publikationen}}

Clementine Player

A couple of years back, I was a big fan of Amarok, the music player. Then came along a rewrite and version 2.0, and I also switched to OS X. The version 2.0 was not very nice, stable or useful. The OS X version was very hard to install, due to the KDE dependencies. So I ditched Amarok. I replaced it with CogX for a while, and now I am using the horrid iTunes and the wonderful mpd (together with MPoD and Theremin). But today I read about the Clementine Player. It’s a cross platform Amarok 1.4 fork. And after 10 minutes of testing, I think it’s wonderful!

Where to put a label on a LaTeX figure

I just found out that LaTeX is sensitive as to where you put the label command in a figure environment. For example if you do something like this:

begin{figure}
centering
includegraphics[width=0.95columnwidth]{sompic}
label{fig:some-pic}
caption{Some caption.}
end{figure}

if you now do a ref{fig:some-pic}, the reference will point to the parent element of the figure environment. For me, I got a reference to the subsection enclosing the figure. This was very irritating, because the text then said “see Figure 3.4.2.4 for details.”
Instead you need to place the label in or after the caption command. For some reason the ref will then point to the figure:

begin{figure}
centering
includegraphics[width=0.95columnwidth]{sompic}
caption{Some caption.}
label{fig:some-pic}
end{figure}

Update: And here is also the answer to the question why it is necessary to do it this way.

Another OS X git UI: SourceTree

Besides gitx, I now was shown another git user interface for OS X. It is called SourceTree:

It is more mature and feature-rich, compared to gitx. But it is closed source. However, it is free (as in beer) for the time being in the App Store. So far, the program seems really nice. Let’s see how long I will continue using it, and if I’ll go back to gitx at some point.

XCode 4 is incredibly slow

XCode 4 has always been incredibly slow for me. The first release, 4.0, was especially bad. But that was just a .0 version. The next release 4.1 is much better, but it has also severe drawbacks, concerning performance. Everytime I start it, and not even do much with it, my system gets incredibly slow. That is on both a C2D 2.8 GHz MBP and also on a quad-core i7 MBP. Both machines come with 4 GB of RAM, and after firing XCode up and loading a large project, still at least 500 MB of it remains free. However, speed is abysmal. I just found the tool vmmap in OS X, and it gives me this output:

==== Summary for process 32136
ReadOnly portion of Libraries: Total=265.8M resident=114.4M(43%) swapped_out_or_unallocated=151.5M(57%)
Writable regions: Total=16.2G written=149.6M(1%) resident=360.9M(2%) swapped_out=6156K(0%) unallocated=15.9G(98%)
REGION TYPE                      VIRTUAL
===========                      =======
CG backing stores                  19.4M
CG image                            268K
CG raster data                     2840K
CG shared images                   3472K
CoreAnimation                       180K
CoreGraphics                         16K
CoreImage                           108K
CoreServices                       1704K
IOKit                              61.2M
MALLOC                            337.4M        see MALLOC ZONE table below
MALLOC (reserved)                  15.6G        reserved VM address space (unallocated)
MALLOC freed, no zone              30.5M
MALLOC guard page                    64K
MALLOC metadata                   128.8M
Memory tag=240                        4K
Memory tag=242                       12K
Memory tag=243                        4K
Memory tag=249                      156K
Memory tag=251                       64K
OpenCL                               60K
OpenGL GLSL                        1372K
OpenGL GLSL (reserved)              128K        reserved VM address space (unallocated)
SQLite page cache                  14.6M
STACK GUARD                        56.1M
Stack                              19.7M
VM_ALLOCATE                        16.1M
__CI_BITMAP                          80K
__DATA                             33.9M
__IMAGE                            1256K
__LINKEDIT                         59.5M
__TEXT                            206.4M
__UNICODE                           544K
mapped file                        72.9M
shared memory                      13.6M
===========                      =======
TOTAL                              16.7G
TOTAL, minus reserved VM space      1.1G

So the virtual memory space that XCode takes is more than 16 GB! The actual memory taken is “only” 1.1 GB, which is still huge, but my Emacs also takes 500 MB with tons of C++, Python and LaTeX buffers open.
The question is: can the unallocated, but reserved 16 GB address space degrade the performance? I have too little knowledge of the workings of virtual memory on Intel CPUs under OS X. But this value seems incredibly huge.

Update: I have asked a question on Stackoverflow, and have gotten some useful answers. What did help was removing my build/ folder from the git. Accidentally, a colleague checked in four files in the build/ folder. This made Xcode very slow, since it was checking the git status during compilation all the time. Still, Xcode 4 is much slower than Xcode 3 after this. So I also upgraded our machines to have at least 8 GB of RAM. This was definitely much of an improvement. It seems that development machines using Xcode 4 should have 8 GB RAM minimum. The more, the better…

LaTeX formulas in gnuplot

As a reminder to myself: On the TeX Stackexchange, there is a nice question and discussion by me and some helpful people on how to use LaTeX code in gnuplot / how to embed LaTeX equations in a plot. A copy of my revised answer:

First, we set up a gnuplot called test.plt:

plot [-5:5] [-1.5:1.5] sin(x+pi) title "$\sin(x+\pi)$"

Then we also set up a small Makefile:

.SUFFIXES: .plt .tex .pdf


%.tex: %.plt
gnuplot -e "
set format '$%g$' ;
set terminal epslatex standalone color ;
set output '$@'
" $<

%.pdf: %.tex
pdflatex $<

all: test.pdf

Running “make all” will produce this plot:

Emacs other-window backwards

I am currently writing a lot of text in Emacs, and I need to work on multiple files in parallel. So I use the split window functionality a lot. With C-x o you can switch to the next split window. However, it would be nice to go backward as well. The solution is simple, and is given on Stackoverflow and some other blogs:

(defun prev-window ()

(interactive)
(other-window -1))
(global-set-key (kbd "C-x p") 'prev-window)

Just put this in you init.el, and you can cycle backwards using C-x p.