The Fugue Counterpoint by Hans Fugal

6Dec/130

Reduce compilation time with template magic.

It is a common belief that templates must be implemented in header files, a lamentable situation that greatly increases build times because those full-blown headers must be compiled every time they are included. It also makes the headers less useful as brief documentation, which one of the things about headers that is actually good.

But that is not strictly true. You can separate template declarations and implementations. With a simple pattern and just a little thought, you can compile your template code once and link it just like you do regular objects or functions.

Let us begin with a function foo which just prints the T it was given to cout. Here is the header:

// foo.h
#pragma once

template <class T> void foo(T);

Now let's try to use it:

// a.cc
#include "foo.h"

int main(void) {
    foo(42);
    return 0;
}

And compile:

$ c++ -std=c++11 -c a.cc
$ c++ a.o
Undefined symbols for architecture x86_64:
  "void foo<int>(int)", referenced from:
      _main in a.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

The object file compiles fine, but linking fails because void foo<int>(int) is undefined. So, let's define it:

// foo-tmpl.h
#pragma once

#include "foo.h"
#include <iostream>

template <class T> void foo(T t)
{
    std::cout << t << std::endl;
}

Now if we change a.cc to include foo-tmpl.h instead of foo.h, the implicit instantiation will work fine. But instead, let's explicitly instantiate the int specialization in foo.cc, because we believe everyone and their dog will want the int specialization, and we want to save compile time:

// foo.cc
#include "foo-tmpl.h"

template <int> foo(int);

And compile:

$ c++ -std=c++11 -c a.cc
$ c++ -std=c++11 -c foo.cc
$ c++ a.o foo.o
$ ./a.out
42

Success!

Ok, but what about implicitly instantiating templates? We don't want to give up this unique power of templates. We can do it. This is why I put the implementation of foo in foo-tmpl.h instead of foo.cc. When we need to instantiate, we include the -tmpl.h instead of the .h. We should try to avoid doing this in other headers, and prefer to do it (once) in an implementation file. To demonstrate let's introduce a new function bar:

// bar.h
#pragma once

void bar();

And its implementation:

// bar.cc
#include "bar.h"
#include "foo-tmpl.h"

void bar()
{
    foo("bar");
}

Now we are implicitly instantiating void foo<const char*>(const char*), but that's ok because we included foo-tmpl.h. Now we can use bar:

// b.cc
#include "bar.h"

int main(void) {
    bar();
    return 0;
}

Compile and run:

$ c++ -std=c++11 -c b.cc
$ c++ -std=c++11 -c bar.cc
$ c++ b.o bar.o
$ ./a.out
bar

And finally, let's use them together

// c.cc
#include "foo.h"
#include "bar.h"

int main(void) {
    foo(42);
    bar();
    return 0;
}

Compile and run:

$ c++ -std=c++11 -c c.cc
$ c++ c.o foo.o bar.o
$ ./a.out 
42
bar

Just to make sure we understand what's going on under the covers, let's look at the symbols with nm, and make sure things are defined where we expect them to be:

$ nm *.o | c++filt  # manually-filtered output follows
a.o:
                 U void foo<int>(int)

b.o:
                 U bar()

c.o:
                 U bar()
                 U void foo<int>(int)

foo.o:
0000000000000000 T void foo<int>(int)

bar.o:
0000000000000000 T bar()
0000000000000075 S void foo<char const*>(char const*)

I performed these explorations with gcc 4.8.


$ c++ --version
c++ (MacPorts gcc48 4.8-20130210_0) 4.8.0 20130210 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

With C++11 you also have extern template at your disposal, which lets you avoid implicit instantiation. So if you have many files which instantiate the MyClass specialization, and don't want foo.cc to even be aware of MyClass, you can add this to MyClass.h:

// MyClass.h
#include "foo.h"
class MyClass {
    //...
};

extern template void foo<MyClass>(MyClass);

And then MyClass.cc looks something like this:

// MyClass.cc
#include "MyClass.h"
#include "foo-tmpl.h"

// explicitly instantiate templates
template void foo<MyClass>(MyClass);

MyClass::MyClass() {
    // ...
}

// ...

Now the MyClass instantiation of foo will only be compiled once in MyClass.cc, but can be used in umpteen other files.

13Aug/130

tmux C-Left in Terminal.app

I use Terminal.app on OS X, and I want to bind ctrl-left/right to cycle through tmux windows (like I did with screen).

The tmux incantation is easy to find online:

bind-key -n C-Left prev
bind-key -n C-Right next

This doesn't work though, because Terminal.app is sending ^[[5D for left instead of what tmux expects. In my case, with TERM=xterm-256color, tmux is expecting ^[[1;5D for C-Left and ^[[1;5C for C-Right. You can change this in the Terminal.app settings. Ideally Terminal.app would magically send the right values based on the TERM setting, if there is such a thing as the right values in the world of terminfo and modified arrow keys.

I would prefer to tell tmux to accept ^[[5D instead of ^[[1;5D, which is what I did in my screen config, but I can't see any way to tell tmux to take a raw escape sequence instead of logical keys. I prefer that so that I don't have to remember (or research) magical incantations to configure Terminal.app the next time I start from scratch on OS X. So if you know how, let me know.

2Aug/130

tmux 1.8 reflows text on terminal resize

This changes everything.

tmux
The diff, by Richard Woodbury

Filed under: Uncategorized No Comments
23Feb/132

Sourdough in Bread Pans

A lot of people will tell you you shouldn't put sourdough in metal. Some even go so far as to say you shouldn't use a metal spoon to stir it. That's all nonsense. It's not hydrochloric acid, it's food.

However, when you leave sourdough in a vessel for an extended period of time, and that vessel is not non-reactive, it will react. (The same as tomato sauce will.) It turns out, aluminized steel is one of those substances, and my precious Chicago Metallic pan is ruined from a few very long and sour proofs (10+ hours). Also a lot of scratches from metal knives trying to release stubborn loaves, have taken their toll. As it turns out aluminized steel is steel coated with an aluminum-silicone coating, so you should probably treat it as you would non-stick, even if it claims to be "uncoated" (meaning it doesn't have a non-stick coating). Use plastic utensils to wage war with your stubborn bread.

I'm not sure whether regular non-stick coatings are non-reactive or not, but I'm not a fan of tiptoeing around my cookware so I avoid non-stick.

So I'm buying a Stainless Steel Loaf Pan. I considered silicon too, but I hear horror stories of bad smells at high heat and not keeping their shape with a heavy loaf. And I'm not sure if they'll brown well (stainless is supposed to be less-good for browning that aluminum or aluminized steel, but oh well).

If you already have aluminized steel pans I'm sure you can bake sourdough in them, just watch out for long sour proofs, and use plastic.

6Jun/121

Code Reading on a Kindle

First, add this to your ~/.enscriptrc file:

Media: kindle 498 612 0 0 498 612

Now, here's a script (I call it kindlecode) to generate a pdf on stdout:

#!/bin/bash
enscript -Mkindle -E -p- "$@" | ps2pdf - -

Usage is something like this:

$ kindlecode *.{c,h} > /Volumes/Kindle/documents/foo.pdf

kindlecode in real life

28Apr/120

Calipers and Science

Just for kicks I dug up the original Jackson/Pollock paper for skinfold measurements for determining body fat percentage. Turns out there's also a 7-point equation that also takes circumference of waist and forearm into account.

Here's a snapshot of the equations for men from the paper ("Generalized equations for predicting body density of men" by A.S. Jackson and M.L. Pollock, 1978. I couldn't find the PDF for the women paper online).
Generalized body density equations

Important notes: skinfolds are in millimeters, circumferences are in meters, and log is the natural log (ln in most computer languages). I plugged my values from two weeks back into a spreadsheet and got the following results:

JP Equation Density %BF
Sum of seven skinfolds
S, S^2, age 1.0518 20.62%
S, S^2, age,C 1.0476 22.51%
log S, age 1.0506 21.15%
log S, age, C 1.0482 22.25%
Sum of three skinfolds
S, S^2, age (5) 1.0607 16.69%
S, S^2, age,C (6) 1.0549 19.24%
log S, age (7) 1.0578 17.95%
log S, age, C (8) 1.0574 18.14%

The most interesting thing here is that there's a large difference between 7 and 3 site measurements, and the 3 site range is significantly larger. Also very interesting to note is that the one-site (suprailiac) AccuMeasure chart is, for me, in line with the 7-site measurement (22.1%). Given other measurements I've taken and just general guesswork based on what I see in the mirror, I think that is a decent estimate.

It's also curious that there are two sets of equations given, one using logs and one using squares.

Moral of the story: more data is better, sometimes not-enough more data is worse than a simpler estimate, and interesting things can be learned when you go to the original source. (This is just a quick note, but the paper is very interesting and reading it will be an interesting exercise that sets proper expectations for, and understanding of, the JP7 skinfold method).

30Jan/123

Motorcycle Wheel Alignment

An important part of maintaining a motorcycle is keeping the correct slack on the chain. Usually this involves loosening the rear wheel nut and using two adjustment bolts (one on each side of the wheel) to set the correct tension. Care must be taken to ensure that the front and rear wheels are aligned, or you get bad wear and handling. When you know they are aligned already, you can just count the "flats" and turn the bolts the same amount. But from time to time, or whenever you're uncertain, you have to align them.

The simplest method is just using the marks on the swingarm. This is what I did the first time, but it felt like the rear tire was out of alignment. A little searching of the web confirmed that these marks are both too imprecise and often just plain wrong. What really matters is not the marks the manufacturer put on, but whether the two wheels are actually aligned.

The most common DIY method is to take a string, hold it taught so that it just touches both edges of the rear tire and extends to the ground at the front tire. Carefully measure on both sides, and adjust until the front tire is perfectly centered. I tried this method after I decided I wasn't sure my wheels were aligned. It was a big hassle, especially with just one person, but eventually I got the hang of it. It felt more accurate than the marks but it still felt wildly inaccurate. Something more rigid than string but still nice and straight may have given me more confidence, but I didn't have anything long and straight enough. It could have been placebo, but it rode a lot better after aligning this way.

By this point it had turned quixotic and I would not rest until I found an easy and accurate way to align my wheels. One search led to another and I eventually stumbled across the ProAligner. I was intrigued—how could a ruler be more accurate? Even one with "scientifically designed" red marks. Being the cheapskate engineer that I am I wasn't gong to shell out even $30 unless I knew it would work, and not if I could make my own.

If you search for more details on the ProAligner, you get not a lot of results that fall in two categories: gushing reviews that may or may not be shills, and skeptical curmudgeons that scream SPAM or dismiss even the idea of aligning your wheels. Nobody bridges the two with important details like what the theory is and why it may or may not work, or how it is even used.

Luckily for you anxious wheel aligners (Yes, I realize it is January. I live in California—deal with it! ;-), I have put the jigsaw together and will now help you decide whether to buy the ProAligner.

First, let's discuss the theory on which it works. It's simple geometry. Center front wheel relative to rear tireAlign rear wheel
You are making right triangles and adjusting the wheels until the opposite sides are the same. First you center the front wheel on the rear tire by sighting down each edge of the front tire, then you align the rear wheel by sighting down each edge of the rear tire. Adjust and repeat as necessary until the rear wheel is aligned when the front wheel is centered. Refer to the figure, and reread this paragraph until you get it because it is the key to the whole method, and the thing that ProAligner hopes to hide from all but those who have purchased their ruler. Once you know this tidbit and how it works, it's a slippery slope to realizing you don't need their product to replicate it.

I approximated their design in CAD (the exact spacing is irrelevant, I think I used centimeters and didn't fret whether my printer scaled it slightly), printed it out, and taped it onto some cardboard. Since I don't have a center stand, and my high-quality bike lift is opaque, I needed to do it on the sidestand, so I cut the cardboard to the appropriate angle.

The first time I tried to use it, I put the ruler at the rear wheel and didn't have the whole process figured out. I thought you just sighted along the front tires and soon realized that this alone was super inaccurate unless you could be sure the front wheel was centered perfectly. With the ruler at the rear wheel, it was impossible to read, even with the "scientifically designed" markings.

The second time, I put the ruler just behind the front wheel and had figured out the key idea of centering the front tire relative to the rear wheel, then sighting the rear wheel to read the adjustment. The ruler was easy to read at this distance. I think even a regular school ruler would be—it was 2–3 feet from my eye. The shadow side of my rear tire was hard to sight because it was all just dark. It would have been easier with better lighting, but it was easily remedied with a piece of masking tape on the rear edge to provide contrast. I was pleasantly surprised that it was not only easy to sight and read (aside from having to literally lie on my stomach), but the readings were consistent and reproduceable. It was fairly close to aligned (from the string method) but needed slight adjustment—it turned out I could distinguish one "flat" of the adjusting bolt. This is quite accurate, and easier than futzing about with strings.

As I see it, ProAligner is clever on several fronts. First, coming up with the idea of sighting down the edges of the tires and realizing that this is quite accurate (like sighting a rifle), that was pretty clever. Then, the folding ruler while hardly novel does make positioning it stable and flexible. Finally, I'll concede that the "scientifically designed" markings are easier to read than a regular ruler. So if you're into supporting clever independent companies or would rather spend some money than spend time making your own, then go buy yourself a ProAligner and rest assured that it is accurate and easy.

I have some other ideas for accurate measuring of alignment if lying on the ground isn't your thing. First, a string-based method that I hope would take away most of the frustration: Get a dowel or 2x4 and accurately notch the width of your rear wheel and the center point between the notches. Run the string from the rear tire (hint, wrap around the tire and anchor on a spoke—tape on the tire doesn't stick well) to the notches and wedge it under the centered front wheel. Now you just turn the bolts until the sides of the string just barely touch on both sides.

Second, a laser-pointer method. This isn't unlike this post which was my original tip on the ProAligner, but I think it's easier than his contraption. Attach two laser pointers to straight 2x4s such that they span the rear wheel and point true and level. Bungee them to the rear wheel such that the lasers hit down by the front wheel. Adjust until the front wheel is centered between the laser points. The success of this depends on how accurately you can true the pointers and whether you can keep them on (or have a friend), etc. You could also forego the boards if you have a friend and just sight the laser down the side of the rear tire (a little red on both edges, and also down on the ground by the front tire), have your friend mark with chalk, then measure.

Well, now you have all my thoughts on wheel alignment. My favorite is the ProAligner method—it's faster, simpler, feels most consistent and reliable, and you can even DIY with a ruler, some cardboard, a utility knife, and some tape.

27Nov/110

clock_getres() and clock_gettime()

In Linux kernel 2.6.33 at least, when you call clock_getres() you may not be getting the whole story if the kernel was compiled without high-res timers. (CONFIG_HIGH_RES_TIMERS)

clock_getres() returns {0, 999848}, which you might think means clock_gettime() has a resolution of about 1ms. But no, if you call clock_gettime() twice in rapid succession you find that it is far higher resolution than that—I usually get either 698 or 699 nanoseconds as the difference. So is clock_getres() wrong? No, not exactly. It is reporting the jiffy that limits clock_settime() and the timers. If you time clock_nanosleep() you find that even if you ask to sleep for 1ns you will sleep until the next jiffy boundary, i.e. as much as 1ms and about 0.5ms on average.

If you look at /proc/timer_list on this machine, it reports a tick resolution of 999848, but hrtimer functions are being used underneath the covers:


active timers:
#0: , hrtimer_wakeup, S:01, hrtimer_start_range_ns, smc_proxy/14652
# expires at 1322421490000000000-1322421490000050000 nsecs [in 1303778479239642688 to 1303778479239692688 nsecs]
clock 1:
.base: ffff88002820e680
.index: 1
.resolution: 999848 nsecs
.get_time: ktime_get

My guess is that clock_gettime() is using HRT and giving high-resolution answers even though you didn't enable using HRT for POSIX timer functions by leaving CONFIG_HIGH_RES_TIMERS unset.

A side effect of this silly situation is that gettimeofday() is also accurate (to µs), though usleep() and nanosleep(), like clock_nanosleep(), are limited to 1ms ticks.

7Jan/111

On TODO lists

Lately in my TODO usage, a pattern has emerged. It's actually rather helpful, and it's dead simple.

I just keep a text file; one for work, one for my dissertation, and one for personal stuff. It's free-form, but roughly divided into 3 sections. First the page table, then the core, and finally the metadata. Yes, I really just pretended my TODO list is a virtual memory system.

In English, the first part is a refresher/jump starter. It's just a list of what's next: what I hope to accomplish today or this week. The hardest part is always starting the next task, and I find it immensely helpful to do the prioritizing once in the morning or perhaps the beginning of the week, and then I can refer to a short and ordered list of things I plan to do, and no effort is wasted hem-hawing about what to do next. (Often, life is interrupt-driven and I don't actually get to what's on my list.)

Then I have the actual list of all the things I need to do, categorized however is useful for that particular file. For work, I have sections of the various task priorities (unbreak now, hi-pri, mid-pri, low-pri), and also groupings by project (most low-pri stuff makes more sense grouped by project because it's usually done opportunistically and/or when I feel like working on that project.) Most of the tasks of any substance actually have tasks in our task tracking thing for collaboration, and most of the details are there. These are just one-line reminders. For my dissertation, it's a more traditional list and an outline of what still needs writing. A little structure but no rules.

Finally, the "metadata" is just notes and free-form text that is relevant to the TODO list but not an actual list itself. Totally free-form.

It's been working well for me, it's surprisingly effective. Together with my notebook where I regularly write out my thoughts as a sort of log to get my juices flowing (especially when I'm feeling stuck), it's a great low(ish) tech solution to staying on top of things and avoiding that overwhelming panic feeling when you can't figure out what to do next, or worse can't remember everything you have to do.

4Jan/110

Thunderbird new message badge

Even as I am trying to get back on top of my email backlog, I find a more effective way to ignore emails and just get work done. The cycle of life, eh?

Those little red badges are annoyingly effective at getting me to drop what I'm doing and check out what's new. When the number is in the hundreds, I can't be bothered to remember what the last count was and so I don't know whether there's new mail, so I'm too frequently opening it to see what's new and whether it needs immediate action. In Thunderbird 2 on OS X, you could configure the new message badge to only show messages new since the last time you looked, not unread messages. Then, if there is a little red circle you know there is new mail that needs attention, and if not there is nothing new. Much more productive.

Initially in Thunderbird 3, this feature was removed by haughty but well-meaning developers who couldn't fathom why anyone would want to see anything but the number of unread messages. There was a beta user hissy fit (I participated), the usual stubborn standoff, a patch, and a whole bunch of inaction. I gave up and went on with my life. Apparently, sometime in the interim reason prevailed and it's back in Thunderbird 3.1. The preference is mail.biff.use_new_count_in_mac_dock.