/* no comments (part I) */

Comments have always bothered me. Not that I do not find them useful. It’s that we never know really how to use them properly. They’re also quite hard to maintain so that they follow the current state of the code. Comments tend to be written by the original programmer then never really updated to follow the latest modifications.

In addition to be concise, informative, to-the-point, comments should be written in the most precise language possible, one where words are chosen so that there are no unwanted overtones, no innuendos, and no obscene language. English is the new lingua franca, and this means that comments, in order to achieve collaboration with as many different people as possible, must be written in English. That might be a problem when you’re dealing with non-native speakers.

Epigraphs in LaTeX

There are times when part of the message, the gist, must be communicated to the reader in an out-of-band fashion, so to speak. One way of doing this is to use an epigraph to open a chapter or section, carefully chosen to convey the intended message but in the voice of another author (self-epigraphs are of very bad taste in my opinion).

is the preferred document preparation system of computer scientists, physicists, and mathematicians and if you intend to follow a career into the academia, it’s pretty much unavoidable. One day, you’ll have to learn . The thing is, is pretty much like C++: it can do just about anything, but it’s not going to help you do it. You have to rely on the innumerable packages or, if you really can’t find what you need, you can code it yourself. Let us have a look on how to code an epigraph macro in .

It’s A Fact.

(My apologies to Yann Arthus-Bertrand.)

Now on Twitter

iPod Touch Movies?

I got myself one of those “retina display” (960×640) 5th gen iPod Touch for the New Year. First impressions are that it’s rather well integrated, responsive, and has a number of fun applications. It’s even usable as an X/SSH thin client with a 10$ App.

With Permissions of Emily Carroll

But then you try to see how far you can push the use of the device with Linux (my primary operating system) and find that the support is dismal. The support is already not that impressive with Apple‘s iTunes running on Mac OS X. iTunes is really slow even when running native (i.e., without virtualization) and also does some very stupid things such as preventing you from copying a PDF you downloaded from the web back on the computer even though it has no DRMs—a behavior defective by design. Another limitation is in the iPod itself: the video formats supported are very limited.

The CFM-01

In a previous post, I presented the CFM-00, a “cluster” of 8 Pentium III at 500MHz, assembled into one MDF casing. The assembly was rather clean-cut given the rather rudimentary materials (MDF and threaded rods) but the resulting computing power is dismal (but that’s no surprise). We have about 2GHz of computing power, and at 128MB of ram per node, it makes running even just a remote shell not that responsive.

A few months ago, my friend Christopher came to me with a data center clearing deal with Pentium III 1GHz 1U rack-mount (with 512MB of RAM) servers for $15, and I got eight of them to build the CFM-01, the successor to the CFM-00. But I did not strip the motherboards from their casing this time, I built an inexpensive rack out of slotted angle steel.

The Perfect Instruction Set

The x86 architecture is ageing, but rather than looking for re-invention, it only saw incremental extensions (especially for operating system instructions and SIMD) over the last decade or so. Before getting to the i7 core, we saw a long series of evolutions—not revolutions. It all started with the 8086 (and its somewhat weaker sibling, the 8088), which was first conceived as an evolutionary extension to the 8085, which was itself binary compatible with the 8080. The Intel 8080’s lineage brings us to the 8008, a 8 bits of data, 14 bits of address micro-processor. Fortunately, the 8008 isn’t a double 4004. The successors of the 8086 include (but the list surely isn’t exhaustive) the 80186, the 80286, the 80386, first in the series to include decent memory protection for multitasking, then the long series of 486, various models of Pentium, Core 2 and i7.

So, just like you can trace the human lineage to apes, then to monkeys, and eventually to rodent-like mammals, the x86 has a long history and is still far from being perfect, and its basic weakness, in my opinion, is that it still use the 1974 8080 accumulator-based instruction set architecture. And despite a number of very smart architectural improvements (out of order execution, branch prediction, SIMD), it still suffers from the same problems the 8085 did: the instruction set is not orthogonal, it contains many obsolete complex instructions that aren’t used all that much anymore (such as the BCD helpers), and that everything has to be backwards compatible, meaning that every new generation still is more of the same, only (mostly) faster.

But what would be the perfect instruction set? In [1], the typical instruction set is composed of seven facets (to which I add an eighth):

Lost+Found: Wisdom Teeth by Don Hertzfeldt

Also by Hertzfeldt : Rejected.

Suggested Reading: Find the Bug: A Book of Incorrect Programs

Adam Barr — Find the Bug: A Book of Incorrect Programs — Addison-Wesley, 2010, 306p. ISBN 0-321-22391-8

(Buy at Amazon.com)

This short book (306 p, but a quick read) asks us to debug 50 short programs written in 5 different languages: C, Python, Java, Perl, and x86 assembly. The book offers quite verisimilar code snippets, each of which containing exactly one bug; forfeiting the results. Barr proposes a taxonomy of bugs, from the logical bug to the off by one, and we must debug the programs with him.

C++ Logging

It seems that logging is something we do in about every program we write. Logging complements the standard output with richer messages and detailed information. And each time it seems like we’re asking ourselves how to do that exactly.

Of course, there are already existing logging frameworks out there, but I was wondering how much work it implied. I wanted something that would integrate seamlessly to the existing C++ streams: it had to behave exactly as a classical ostream from the programmer’s point of view, but had to insert timestamps and manage message priorities. The simplest way to do so is probably to have a class that inherits from ostream or similar and that already overloads all the operator<<s.