fmdkdd

A Few Emacs Tricks

2019-07-23T00:00:00+00:00

Here are some Emacs Lisp stuff I have in my configuration, which others may find useful. I don’t want to publish them on MELPA, because I have no intention to maintain them. They probably contain bugs, haven’t been tested thoroughly etc. Feel free to grab them if they fit your needs, but don’t complain if they don’t work!

Automatically reload the browser when editing HTML

When I do web programming in HTML/CSS/JS, I like to have a browser to test my changes quickly. Switching to the browser and refreshing it got old rather quickly, so I scripted it.

reload-browser.el provides a function which reloads multiple browser windows. The first time you call it, it turns your cursor into a box, asking you to click in the window you want to reload. After that, calling the function again will reload the window you selected. You can even select multiple windows (e.g., Firefox and Chrome) if you pass a numeric prefix argument. With a keybinding to save the current buffer and reload all browser windows, I don’t need a more fancy setup.

Behind the scenes it simply calls xdotool to do the heavy lifting. It’s mostly straightforward, but it turns out that Chromium requires to be in focus to be reloaded, whereas Firefox does not, so the script has to handle that as well.

One sentence per line for editing shared LaTeX

I usually write text with auto-fill-mode, which wraps lines at 80 characters so the result is readable in any text editor. When writing papers in LaTeX though, I want to keep one sentence per line, as it makes reviewing the diffs and handling conflicts much easier when working with other people. Of course, I want my editor to fill that way automatically.

ospl.el redefines auto-fill-function to break after a sentence, and provides an ospl-paragraph function which refills the current paragraph to one sentence per line. The trick here is to detect where sentences end so you can insert newlines. Emacs can recognize sentences by looking for a colon, but note that abbreviated acronyms also end by colons (“e.g.”, “i.e.”). The best way to handle this unambiguously is to use a double space after a sentence, and a single space after other colons (see the variable sentence-end-double-space).

Unfortunately, not everyone has recognized that the double space is the superior form, so ospl assumes you use a single space, and avoids breaking after common acronyms, which makes it slightly more complex than it should be.

Preview definitions when editing assembly

Lately I’ve been dabbling in 6502 assembly, and when navigating code, I often found the need to look at the definition for the label under point. So I wrote an xref backend for assembly (xref-asm.el), so that I could jump to the definition and back using the standard keybindings. But for most labels, I didn’t really need to jump to the definition, I only needed to see a couple of lines at or below the label, so I could remember what it was doing.

So I wrote xref-posframe.el, another package which previews the definition using posframe. Posframe lets you create one-shot Emacs frames without window decorations, which is more convenient and configurable than overlays for displaying stuff on top of the current buffer, but still fast enough to be usable. With xref-posframe, I can preview a definition in one key:

Pressing the key a second time, I can even jump to the definition.

And it works everywhere xref is supported, not just for assembly.

Highlight TODO keywords

This one is pretty simple. I want keywords in comments like TODO: and FIXME: to use a custom font, so I can see them pop out at me, screaming to be fixed. This can be done by adding keywords to font lock:

(defun add-watchwords ()
  "Add TODO: words to font-lock keywords."
  (font-lock-add-keywords
   nil '(("\\(\\<TODO\\|\\<FIXME\\|\\<HACK\\|@.+\\):"
          1 font-lock-warning-face t))))
(add-hook 'prog-mode-hook #'add-watchwords)

This method has one drawback: it highlights these words anywhere they appear in a programming buffer, even outside of comments. There are complex packages that do this in a more robust way, making sure to only highlight these words in comments. I don’t think these are worth the added complexity. For me, 99.99% of the time the method above works fine. When there is a false positive, I just ignore it.

Lately I’ve been using more descriptive keywords like @Correctness: or @Optimize:, so I’ve added a wildcard at the end to handle all words between “@” and “:”. Even then, false positives are not an issue.

Insert screenshots into Org documents

I take a lot of notes on what I’m working on in Org. Whenever I’m working on something that can be visualized, I prefer to include screenshots as they are often more helpful in conveying what’s going on. To reduce the friction of taking the screenshot, cropping it, and inserting the link into the Org file, I’ve written a bit of Elisp to do it for me:

(defun insert-screenshot (file-name)
  "Save screenshot to FILE-NAME and insert an Org link at point.

This calls the `import' from ImageMagick to take the screenshot,
and `optipng' to reduce the file size if the program is present."
  (interactive "FSave to file: ")
  ;; Get absolute path
  (let ((file (expand-file-name file-name)))
    ;; Create the directory if necessary
    (make-directory (file-name-directory file) 'parents)
    ;; Still, make sure to signal if the screenshot was in fact not created
    (unless (= 0 (call-process "import" nil nil nil file))
      (user-error "`import' failed to create screenshot %s" file))
    (if (executable-find "optipng")
        (start-process "optipng" nil "optipng" file))
    (insert
     ;; A link relative to the buffer where it is inserted is more portable
     (format "[[file:%s]]"
             (file-relative-name file
                                 (file-name-directory buffer-file-name))))
    (when (eq major-mode 'org-mode)
      (org-redisplay-inline-images))))

This snippet asks for a filename, then calls import to select just the area I want to screenshot, saves it and then insert an org-format image link at point. In org-mode, it redisplays inline images so I can see the result right away. If optipng is installed, it even compresses the screenshot to save space.

Insert, delete or change delimiters

In Spacemacs and Vim, there’s a nifty way to quickly surround a part of text with quotes, braces, and other delimiters. When I went back to vanilla Emacs, adding quotes by hand seemed tedious.

delimiter.el solves this. It’s very straightforward: delimiter-surround will prompt for a delimiter char and surround the current region with it. If no region is active, it surrounds the current sexp. So in two quick key presses, I can quote a word. Some delimiters go in pairs, so giving an opening brace “{” will use the matching closing brace “}” as closing delimiter.

There is also delimiter-change to change an existing delimiter pair to something else, and delimiter-delete which is self-explanatory.

Note that the deletion is purposefully not clever: if you have nested delimiters, it will just delete the ones closest to point, so in the following situation (the caret | marks point):

(he|re (is) a list)

invoking M-x delimiter-delete ( RET will yield:

he|re (is a list)

where one may expect to eat the outermost parens:

he|re (is) a list

If you want clever behavior, you should look elsewhere.

Auto-revert without the lag

Just yesterday I wanted to explore the assembly output of GCC for some simple C file. I opened two windows: one with the C code, and one with the output assembly. I put the latter in auto-revert-mode so I could quickly see the result after recompilation.

Turns out, auto-revert-mode had some weird lag on my machine, where it could take a few seconds to revert the buffer so I could see the result. Opening a terminal with watch -n 0.1 cat a.s was better.

I wrote a small minor mode that reverts the buffer after getting change events from inotify, and it was constantly instantaneous.

Later, I checked out the source to auto-revert-mode, and found that it does more or less the same as my minor mode, using filenotify watchers first, and falling back on polling if filenotify isn’t supported or fails. Yet, it can still take seconds to refresh whereas my minor mode just works.

If you have the same issue with auto-revert-mode, you may want to try inotify-revert.el.

Ludum Dare 43 Post-Mortem

2018-12-21T00:00:00+00:00

We made another game for the latest Ludum Dare game jam. It’s called QUELTRIS, and you can play it right here.

In this post I want to describe the game design process: how we came up with the idea, how the initial idea wasn’t fun at all, and how we turned that around to find something that was worth playing.

The idea

The theme this time was Sacrifices must be made. We started by brainstorming around that theme, trying to find an interesting setting and a gameplay idea that would fit. We took the theme rather literally and quickly gravitated around the idea of an Aztec god asking you to sacrifice pawns.

On the gameplay side, I suggested to do a match-3 (think Bejeweled). Partly because we had been playing PuyoPuyo vs. Tetris the night before, and partly because I thought it was an easier target for the allotted 72 hours. In Münster, not only the game was much shorter than envisioned, but the gameplay felt wonky due to falling short on time. For Bright Plateau we did manage to make a decent-sized game (for a Ludum Dare), but as I designed the levels the last day, we didn’t know how fun the game would end up being until a few hours before the deadline. This time, we focused on getting a good gameplay first.

Of course, we didn’t want to just do a Bejeweled clone, so we sketched some ideas on how to iterate on the formula in an original way: maybe using a different swap mechanism? Or changing the grid? We looked at QbQbQb, a game where you put pieces around a planet, and at Block Out, a first-person Tetris that has you looking down the well in 3D as a tetromino.

Trying to sketch how a circle grid would work for us, Merwan had an idea: what if we had a round, bottomless well, and the player would sacrifice pieces by push them down the well? We both instantly loved that idea: it was a simple mechanism (push) that perfectly fitted the theme (sacrifice).

Now, at this point we didn’t know if the idea was enough. We had a good idea, but needed to see it in motion. I started making a playable prototype while Merwan began working on the visuals.

The prototype

At 21:19 on the first day we had a playable prototype:

The player moves the white triangle at the top to switch columns, and can push the current column down in order to match three of more pieces of the same color. Every move consumes blood from the gauge, while making matches fills it back. When the gauge is empty, you lose.

The first thing to note is that it is nearly a complete game. In that sense, our focus on prototyping was a success. Adding a little polish here and there, and we could have submitted it! Needless to say, we felt pretty good about our progress.

Except for one thing: the game wasn’t fun. At all.

In the video above I’m just pressing buttons at random, without thinking about whether my move will make a match. I don’t need to: most moves will make a match. Since we are moving a whole column down, 7 pieces change position, making 7 places for a potential match. As I keep pressing the down button, I make many matches, just at random. The game does not challenge me, so I’m not engaging with the game. It’s just not fun.

The blood gauge was actually an addition I made after finding out that the push mechanism was simply not enough. Adding the gauge was supposed to force the player to consider each move, but as matches were easily made, the balance was still off.

We were in a crisis. We had a good idea, or a least we thought we did, but it wasn’t fun. How could we salvage it?

Finding the fun

We can feel when a game isn’t fun, but how do we add fun back in? How do we improve the mechanisms?

A first step is to understand why the game isn’t fun in the first place. Here, I feel the game is lacking meaningful choices. At any given time, the player has three moves at his disposal: move left, move right, and push the column down. Now, a low number of low-level moves isn’t necessarily a bad thing; some games manage with as many, or even fewer. What is more important is what decisions these moves enable. There are seven columns, and the player has to choose one column to push down in order to progress; that’s exactly seven choices at a given time. Seven is a low number of alternatives to weight, which might make the game trivial. But worse: actually weighing these alternatives is pointless, since matches come so easily. You can pick any column, push it down a few times without thinking about it, and you will probably make a match. If you don’t, just move to the next column. Even if you try to play thoughtfully, looking for matches is trivial. Since we have too few interesting decisions to make, the game ends up feeling boring.

Doubt cast over our enthusiasm. After grabbing a bite, we looked at how other games with similar mechanisms managed to be fun. Tetris mixes two levels of decisions: at the tactical level you have to move the falling pieces where they won’t create too many holes, and at the strategical level you have to think about leaving space for an eventual ‘I’ piece. PuyoPuyo has the same depth, but here the strategy is about scaffolding for combos long, juicy combos. In both these games, the player is constantly trying to clear the well while the game keeps throwing more stuff to handle, which creates a nice tension. In Bejeweled and Hexic the tension arises by creating matches while managing the random pieces coming from the top. Both also have strategic aspects: Bejeweled lets you setup combos for more points, and Hexic requires you to build “flowers” patterns in order to win.

Other games succeed at using match-3 mechanism on the tactical level, but mixing that with another genre altogether at the strategic level. In Might and Magic: Clash of Heroes the strategic level is about managing your pieces to launch attacks at your opponent while keeping enough pieces around to defend yourself. In Puzzle Quest, the match-3 mechanism is greatly enhanced by the character-building aspects taken from role-playing games. Henry Hatsworth in the Puzzling Adventure mixes match-3 and platformers, while 10000000 uses match-3 at the tactical level to power a dungeon crawler. Although combining genres this way can make for an excellent game, we wanted a simpler game . After all, Tetris is fun enough on its own!

To make the game more fun, we tried to expand the decisions the player had to make by allowing pushing from the sides in order to match. To avoid committing too much time pursuing these variants, we built paper prototypes. But even with more options, the game still felt too easy and uninteresting.

Feeling we had exhausted the search space, Merwan suggested we rotate pieces instead of pushing them. This was an intriguing twist, but it also meant that we would lose the “push pawns down a well” aspect of the push mechanism which so lovely tied into the theme. Still, it’s better to have a fun game that loosely fits the theme than the reverse, so we pursued it.

Turning it around

I went back to add rotation to the prototype. After two hours, I had rotation working, complete with animations. There was no matching; just rotation. But the rotation already felt fun. I spent quite a bit of time just toying with it, which is always a good sign:

One reason it’s fun is that you have many more options at your disposal: you can go anywhere in the grid and rotate four pieces right or left. It turns out that this is enough to re-arrange pieces in any shape (except for the fringe pieces). This observation led us to the idea of matching “runes”: patterns of colors. You would rotate pieces in order to build these patterns and satisfy the angry god.

Initially we envisioned large runes: letters-like shapes around 4x5 or even 6x6. We could have made the grid larger to accomodate that, but even before implementing the pattern matching we thought it would be more satisfying to chain smaller patterns rather than build towards larger ones. Large patterns require more moves, and felt more tedious to build.

Now, there only so many shapes you can make in a 2x3 grid, so we ended up with the familiar tetrominoes. At first, I tried to be original and had the green pattern be the following:

OO.
O.O

But it turns out that a disconnected pattern like this is harder to recognize on the board. It also made sense to have shapes with the same number of squares, in order to make sure they have the same probability being assembled on the grid. This also cut down on the possibilities. In the end, the game leans on the player’s familiarity with the tetrominoes, but you still have to get used to recognize situations that can make a pattern in one or two moves.

When I tried out the prototype, it had a great feel. Just at the tactical level, the player has interesting options. Do I go for the blue shape that’s a bit further, or do I try to assemble these four yellow squares lying around? Oh wait, now I’m seeing that this pattern of red squares is actually one move away from a match. It was fun just to look for near-match configurations. As you learn to recognize these configurations for all the patterns, you see potential matches everywhere.

Emergent gameplay

I’m always fascinated when the combination of simple mechanisms creates unanticipated and interesting gameplay opportunities. So when I discovered that our game had some, I was rather excited.

There is balance between the colors that naturally emerges from the rules. If you focus on matching the red shapes, you will have less red and more of the other three colours. Thus, you are forced to match other shapes, pulling you out of your comfort zone. This balance arises in other match-3 games as well, as long as all colors have equal spawning chances.

But playing with the prototype also revealed rich opportunities at the strategic layer. I categorized four of them: multi-matches, overlaps, combos and chains.

A multi-pattern match (or multi-match) is when one move matches two or more different patterns:

A multi-match can be tricky to setup, as you have to be careful of not matching the pattern prematurely while you move pieces around. Though messing up a multi-match can be comical, pulling one off is rewarding. It’s also fun to figure out the different ways to build them, and to learn the configurations leading to them.

An overlap is when one move matches two or more instances of the same pattern:

Overlaps are quite rewarding to build for the same reasons that make multi-matches fun. Overlaps are perhaps easier to setup due to requiring fewer pieces, and focusing on only one color.

Combos are pretty much a given, due to borrowing the random top row of pieces from match-3 games:

Though in the submitted game you don’t really have the time to arrange the grid in order to build elaborate combos, it’s still satisfying to pull a small one. Having a combo happen due to the random pieces falling is always nice as well. Had we had more time, we might have added a puzzle mode where you have to build the largest combo for a given board.

Finally, one of the more interesting ways to play the game is to aim for chains. A chain is a sequence of moves where every rotation you make is a match. Here is a 5-chain (starting with a multi-match and ending with a combo):

Unfortunately, in the final game we did not have time to signal these different trick moves to the player explicitly. Though combos, overlaps and multi-matches award you bonus points, and the god face reacts to combos, the connection is not obvious.

The timer forces you to play fast and safe, which tends to reward chains, but at the detriment of large overlaps and clever combo scaffolding. I would have liked to encourage the player to aim for these tricks more, as just matching the base patterns feels stale rather quickly. It’s a flaw that I would like to address in a remake, but I haven’t found the perfect solution so far.

The takeaway

We initially pursued a simpler ‘push’ mechanism that was a great fit for the theme, but ended up being too trivial to be fun. By looking at other games for inspiration, and by trying different ideas out, we iterated to find a core mechanism that, although not obviously tied to the them, at least felt good to play. From then on, we added visuals and animations to polish the game and better fit the theme.

The lesson here is: don’t be afraid to prototype a lot, and don’t be too attached to seemingly good ideas.

In the end, we aimed to build a fun take on match-3, and although the game could be improved to be more engaging, I think we succeeded.

A Personal History of Reading

2018-06-19T00:00:00+00:00

I love learning new things, potentially more than knowing things. I’m talking about big, meaningful things: concepts, systems, algorithms. I’m interested in understanding how the universe and its pieces work, but not necessarily what you had for dinner yesterday.

Much of that precious knowledge I seek, I get from reading. Nowadays, reading comes in many different flavors; books of course, but also journals, magazines, comics, websites, pages, blogs, forums… While some of these differ in purpose, it’s still pretty much text. For this particular discussion, it doesn’t matter if the rays of light that carry the words to your retina come from a computer monitor, a phone, or a candle. So, for this post, I will use the word book to refer to any word source, because it rings better than “text”. Book. Boo-ook. BOOK!

This post is about reading books.

A naive start

When I was growing up, I did not have many friends (well I still don’t, but that may be a topic for another day). Part of the reason was a shyness bordering on the pathological, but maybe another cause was that I did (and still do) enjoy a quiet solitude. While other children gleefully sportsballed outside, I favored playing in my mind rather than in the physical world. And until I found a computer keyboard in my hands, reading was certainly my favorite activity.

For the longest time, I believed that the sole act of reading books would make me smarter. The reasoning might have went a bit like this:

books are written by smart folks;
their writing distills smart-stuff into words;
reading their prose is like drinking smart-full nutrients;
like absorbed nutrients fuel my body, absorbing words with my eyes fuels my brain;
thus, reading their words makes me smarter. QED.

But, mainly, it might just have been the social stigma that being a book worm is a prerequisite for a career path into knowledge-oriented jobs. Being paid to play in my mind all day seemed like a good value proposition, and so I read.

Now, while I have mostly outgrown this belief, it has impacted many of my past reading behavior. I want to reminisce on some of its most embarrassing consequences later, but first I want to discuss its hypotheses.

Finding the good books

You might object to assumptions #1 and #2, and, in an all my naïveté, I was aware that these did not hold for all literature known to mankind; i.e., not all books may be worth reading. Or rather, I suspected that books came in varying levels of quality, which in turn meant various amounts of knowledge to absorb. To keep the culinary analogy going, some books are like fast-food: cheap and full of saturated fat and sugars to give you a short but potent high, while others are more like légumes: less thrilling, but more nutritious. In a healthy diet, you want less of the former and more of the latter. Mens sana in corpore sano calls for a healthy reading diet.

A quick back-of-the-envelope calculation shows that the number of books one can reasonably manage to read in a lifetime has been eclipsed by the number of books in circulation since around … five centuries ago. Clearly, in my eternal quest of wisdom, I would need to devise a system to part the wheat from the chaff.

From an early age, I caught on that recommendations were an effective solution. I have a simple formula: the likelihood of me reading a book is proportional to the number of times that book was recommended to me (directly by a friend, or indirectly through word of mouth), weighted by the area of overlap between the recommender’s interests and mine. In other words, if we both are passionate about waffles, and you tell me about this book on Belgian wafflology after the first World War, then the likelihood of me reading it is very high. On the other hand, if we have diverging interests, then chances are low that I will get out of my way to find a copy of that Shoelace Makers of the Renaissance you keep raving about (even though it does sound a little intriguing!). But if I keep hearing about it, I just might get one. Of course, other factors come into play, and I do not actually carry out calculations to rank books that were recommended to me in order to pick my next bedside companion. But even loosely applied, I do get good mileage out of this formula; and it can be extended to other media like films, video games and music.

Also of importance is the nature of the book. Some books have explicit pedagogical value: textbooks, scientific articles, historical treaties, encyclopedias, user manuals and the like. It is easy to see how one could want to download all their factual contents directly into one’s brain. Other kinds of books, like fiction, have a different value proposition: they primarily entertain you with a gripping story. One may then question the utility of cramming one’s head with the intricacies of Bridget Jones’ failings at finding love. Aside from the trivial observation that, yes, sometimes, it is good to be entertained, even by clichés, I would argue that even fictional writings may hold valuable insights. Stories have a way of making a mark in our collective imagery, and their characters can often be used in daily conversations to draw one’s point home more vividly. Greek mythology is rife with figures whose actions gave us useful analogies and even common words: Odysseus’ sirens, Icarus’ flight, Tantalus’ punishment, Narcissus’ fatal narcissism, Sisyphus’ Sisyphean plight, etc.

All of that to say that while I favor reading technical books because they will more often hold actionable knowledge, other literary pursuits may still be worthwhile for expanding my horizons, or even just for fun.

Reading habits

Now, having no shortage of wonderful books to discover, I want to reflect on behaviors that may have been brought about by that forementioned belief.

I used to read books from front to back, without missing a letter. Footnotes and back-cover blurb included. Carefully sieving each page, in search of nuggets of wisdom. I was once appalled at a fellow student who revealed to me that her so-called speed-reading technique involved skipping whole paragraphs. I couldn’t bear the thought of glancing over a sentence in fear of missing out some important tidbit; skipping paragraphs was heresy.

Nowadays, I skip by leaps and bounds when the text does not seem to be relevant to what I’m after. Though I tend to read fiction at a more leisurely pace, perhaps because there, half of the delight is in the composition of the words. Textbooks may be engaging, but their prose is too often stifled.

I had an unhealthy fixation on quotes. Assuredly, quotes contained the words that were the most potent, the most meaningful of the book they came from, otherwise they wouldn’t be worth quoting! I was fascinated by the mysterious force of some quotes that are part of the vernacular, passed down generation after generation to be used as thought-terminating clichés around Christmas dinner.

I got a quote dictionary: that’s a book with quotes for every word. Two quotes for “berry”, three quotes for “lion”. One quote for every occasion. Each quote was seemingly very profound, solemn in its brevity—the shorter the quote, the stronger its impact. My agenda even had quotes for each day; one was simply:

D’oh!

— Homer Simpson

Over time, I realized that quotes drew most of their power from two sources: their author, and their generality. Quoting famous figures is an effective way to argue from authority. And, like horoscopes, quotes thrive not because of what they actually say, but because of what we read into them.

Their effects started to wane when I tried to match quotes to their context. Quotes lose their luster when you realize that their point is made better by the surrounding paragraphs of the text that harbor them. You come to appreciate the intricacies and nuances of the author’s argument; quoting then too often feels like cargo-culting one cherry-picked part.

I still like a good quote, especially of the whimsical variety.

Quixotic quests for knowledge

Once upon a time, I imagined that I could expand my vocabulary tremendously by reading the dictionary cover to cover. Mind you, I must have been around ten. Having somewhat more ambition than diligence, that attempt ended before reaching the word ‘abacus’.

Still, I clinged to the prospect of absorbing knowledge from such ponderous volumes.

I ardently coveted the Junior Woodchucks’ Guidebook. This encyclopedic little tome seemingly contained all the answers to all the questions one could ever ask. Alas, it was fictional. Remember that there was no Wikipedia; and I had no Internet access. But we did have encyclopedias.

The one we had was a sort of insidious scam. Initially, you would just buy a magazine containing a few interesting articles. These were nicely written articles, quite didactical, and well illustrated. They even came with punched holes so you could reorganize them in a binder. But still, the magazine only came with a dozen of them, and thus you had a large binder with just a handful of articles, and a child with a consuming curiosity, so what did you do? You bought a subscription to receive more articles every week in the mail. Each Tuesday, I would get a new batch of fresh knowledge; I fondly remember reading about a wide range of topics, from medieval conflicts to relativity, from sound waves to giraffes. After reading, I would dutifully transfer the articles to the binder, putting each one in its proper category. As months went by, the articles piled up, and the binder became too small to hold them all. Of course, the publishing house also sold official binders for a pretty penny. That was all part of the scam: they got you with initial low costs and a promise to “pay as you go”, but as the costs slowly accrued over time, the total cost may have rivaled the price of a twenty-volume encyclopedia. We ended the subscription after I had filled my fifth binder.

Even though it occupied a whole shelf, and thus was roughly ten times larger than the Woodchucks’ Guidebook, it was obvious that it did not, in fact, contain the sum knowledge of all humanity. Reality crushed the magic of the Guidebook, but the idea of a tome containing all the answers never really left me.

At University I was fascinated with data structures. They have the elegance of simplicity on the outside, and the beauty of intricacies on the inside. It seemed they were crucial to solving many fundamental problems in computer science, and as I wanted to become the very best, I had to catch them all.

I started compiling all the information I could find on each structure in a personal encyclopedia. I documented their applications, their big-oh complexity, trade-offs of implementation… My goal was for it to be the one place of reference I would ever need for all my curriculum.

Its sole article was, and still is, the Linked List.

After that, I realized that exhaustivity of information was not only unachievable, but often undesirable. For informative books to be useful, they need to maintain a high signal-to-noise ratio; they must focus on the essential and forget trivia.

Counterexamples

While these events did alter my perception of knowledge and its acquisition, they did not altogether dispel my belief that reading alone would grant me its author’s wisdom. Other observations, however, came to clash with this theory.

First, since reading a book should have conferred me its powers, I should have been able to write the exact same book after having finished reading it. Yet, it never was the case. Au contraire: some books I would have difficulties to explain or describe when asked. As if reading the words was not enough to really comprehend what they said.

This was the most evident when reading books whose contents were well out of reach. I tried to push forward, reading each word but not getting them. It felt as if I was reading a text in an unknown language, even though it was all written in my mother’s tongue. Maybe I was hoping that, when I finally got to that last page, after clutching my way through the tortuous sentences and unfamiliar jargon, I would be rewarded? Hoping that, after having been seeded by these fuzzy morphemes, some part of my brain would just click? It is difficult to know beforehand if some text is badly written, is intentional gibberish, or if you are in fact not smart enough to make sense of it.

In time, I have learned that reading requiring some effort on my part is a good sign: it is a signal that my brain is learning. If I’m cruising, then the material is certainly nothing new; if on the other hand I struggle with each sentence, then the contents are probably out of my league (for now). There is a fine line, and I have to surf it.

But the final counterexample to that quaint theory was reading the same book for the second time. Surely, if one is supposedly “gets” all the book by merely reading it once, then reading it twice would be a clear waste of time. Yet it wasn’t. Even worse, when re-reading books I would find some new insights—not just some leftover knowledge bits that I had previously missed, but insights that replaced the ones I had gotten from previous readings. As if I had previously misinterpreted the book, and it was only in this second reading that I had attained its true meaning.

But it wasn’t misinterpretation. It didn’t feel like misinterpretation.

Helpful little lies

Books can only teach you what you read into them. That sounds vacuous, but it emphasizes one key point: the reader’s own knowledge determines the outcome as much as the sequence of words in the book. There’s an interplay between the two. My experience of reading The Lord of the Rings, and what I retained from it, may be vastly different from yours.

After reading some words off the page, the process of digesting them mostly feels like a reorganization of thought. The words need to be integrated with my existing mental organization. It feels like introducing a stranger into some long-standing fellowship. In any group of people, there is an established dynamic at work, and any stranger will have to learn that dynamic in order to fit in. The same applies to foreign-knowledge-bearing words trying to get into my brain. Their concepts must be adapted to the way my mental models are already set up. And in this adaptation, which is dictated by my past experiences, my reading of the words is irremediably different than yours.

So there was the explanation. When years had passed between my two readings of the same book, the contents of the book had been the same, but I had changed. These intervening years are what altered my perception of the same words. Much like source code isn’t complete without an interpreter, the reader is what gives meaning to the book. What good is a book if there is no one to read it?

Thinking that the words alone bore all the knowledge was naive, even foolish. It was a simple explanation—too simple, but one has to start somewhere. We use theories in order to make sense of the world, in order to survive. Our theories are like spiders’ shells: they protect us as we troddle around the world. Eventually we outgrow these shells; we shed them and develop other, more sophisticated and more nuanced theories which improve on the previous one’s shortfalls. Shed after shed, our grasp on the world grows, ever-changing. And yet, we are only ever catching glimpses of the full picture.

Ludum Dare 39 Post-Mortem

2017-08-08T00:00:00+00:00

So, Merwan and I made another game for Ludum Dare. It had been two years since our last entry, You Are The Münster (YATM henceforth), which we had a really great time making. Ever since, we have been meaning to get together for another round, but never managed to align our schedules until now.

You can play Bright Plateau right here. The rest of this post is a recollection of the 72 hours we spent making it, and contains minor spoilers (you should try the game first).

Day 0: Warming-up

In our timezone, the theme is announced at 3AM, in the night from Friday to Saturday. Merwan arrived Friday evening and, after we exchanged pleasantries, we spent a few hours throwing ideas at each other, talking about games we liked, why we liked them, what we thought they were lacking. I remember talking about simulations and tycoons, and how they can they can double as teaching tools for understanding complex systems. These genres would come up again later.

We went through the list of themes in the final voting round for this LD, which at the time was:

Signal lost

Parallel worlds

Moving fortress

Running out of power

You are alone

Start with nothing

Machines

Running out of space

On / Off

Connections

Protect it

You are not the main character

1 vs 100

It spreads

Different perspective

1 HP

We liked “Moving Fortress”, “Parallel Worlds”, “Running out of space”, “On / Off”, “Connections”; I remember discussing “You are not the main character” and concluding it was a dead-end, on the basis that any mechanism we could find would make the player-controlled character the main character in the eyes of the player. We felt pretty good about “Running out of space” winning, but we did not cast our votes, as we didn’t even have accounts to the new LD site at the time.

We then checked out a few of the top games from the last Ludum Dare for inspiration:

Out of these six games, we played: Honey Home, The Deep, Super Kaiju Dunk City and Snowed In. Little Lands looked awesome, but was Windows only, so we skipped it. For each game, we tried to understand its appeal, how they used the theme to good effect, and summarized what we liked/disliked.

I showed Merwan another LD game I had stumbled upon prior: Twin Condition. I really liked the clean aesthetic, the smooth animations, and the fact that you had to play both part of the levels differently, but at the same time:

I also showed him this prototype by rezoner, the author of Playground.js (among other nice things); I liked the effectiveness and look of the low-resolution 3D graphics:

This low-resolution is achieved simply by drawing to a small canvas (say, 320x180), then scaling it in the browser:

<canvas width="320" height="180" style="width: 960px; height: 540px;">

The browser will use a linear filter by default when drawing the scaled canvas, which looks buttery (as above). You can use a nearest filter for maximum crispness with the image-rendering CSS property.

Though unbeknownst to us, the visual presentation of Bright Plateau has been definitely influenced by these two games.

Then it was already 1AM. For our previous LD, we stayed up until the theme had been announced, started scribbling game ideas on paper, and went to bed only after we had nothing further to write down. This time though, we elected to start off with a good night’s sleep and to find out the theme in the morning.

Day 1: Finding the game idea

We woke up at around 9AM to discover the winning theme:

Running out of power

Well, we quickly skirted that one the night before, as it hadn’t inspired anything to us. But now the choice had been made. We started throwing ideas:

We quickly gravitated to the idea in lower right: “Puzzle based around the power grid”. Although at first the game was quite different than what we ended up with.

I remember pushing for a tycoon-like: there would be houses and plants to consume power, and you would buy and put power generators on the map to supply them. The power consumers would have different consumption profiles: plants would need a lot of power with low downtime, while houses would consume mostly in the day, but less at night. The consumption would not be fixed, but could vary from house to house. The generators would also produce a varying amount of power, depending on environmental conditions (wind for wind turbine, sunlight for solar panels), maintenance, efficiency… You earned money by providing power to consumers. Maybe this money would have been your score, maybe it would have allowed you to upgrade your generators. You can make out some of that on the doodles above.

With our previous game, we had learned that it was quite tempting to aim for a much larger game than we had the time budget (and ability) to build. In YATM, we had planned for a large world with four areas, each guarded by a boss that would be designed around the item kept in its area. In the end, we only had two areas, and zero boss.

This time around, we agreed to focus our design in order to have a game that would feel whole. Merwan suggested simpler rules; less simulation, more puzzle. What if instead of houses and plants, we had only houses? What if, instead of money, you would have a simple goal: power all the houses? What if, instead of a varying power distribution, we had only a binary state: on and off?

We thought about how that would work. You would put generators on the map to supply houses. Each generator would supply power to all the houses in an area around it, but it would also have a fixed distribution in time. So, for instance, the solar panel would power all the houses in a disc around it, but it would have a 50/50 distribution over 24 hours: 100% in daylight, 0% at night.

We tried to play with the idea in our heads. Would that be easy to understand? How would you play the game? How would you visualize the constraint of validating the power distribution over time? The time distribution was equivalent to a distribution in a third spatial dimension. So, instead of placing generators on a plane, you were really placing them in space. But how would that work, exactly? Placing objects in space on a 2D screen is not the easy to grasp, even when accustomed. Maybe display the time dimension below, like in Shenzhen I/O:

Merwan suggested to simplify, again. What if, instead of 24 slices of a day, we had only two: one slice for the day, one for the night. Then, we could show the grid in the day, have a little sun floating in the sky, and you would pick up the sun and drag to the right to see the grid at night. The coverage of the generators would change at night, and to solve the puzzle you would have to power all the houses at day and night simultaneously.

While I liked the idea of dragging the sun, I felt that going back and forth between the day and night would make playing unnecessarily frustrating, so I pushed for having them side-by-side. Merwan argued that it might be difficult to explain to players the sudden split between day and night. But then again, finding out that you could drag the sun away would not necessarily be more intuitive. And having the day and night portions side-by-side would probably be easiest to get right. We thought about potential ways to present this to the player, but did not find a satisfying solution, and elected to review this once we had the game running. In the end, we never reviewed it: the night levels are introduced without any explanation, but so far no player has complained about not understanding that they have to light all the houses on both sides to solve the level.

At this point, we felt this might be an interesting game: simple coverage alone would quickly be boring, but solving coverage with two slightly different sets of constraints? A tricky twist!

Prototyping on paper

We took this idea for a spin on paper before committing to code it.

What should the coverage for the generators be? Again, we went for the simplest thing we could think of: the solar panel would power a straight line, and the wind turbine would power its immediate neighbors (in the final game, we did it the other way around, as it felt more natural while playing). I cut small lines and crosses out of paper, and drew a few levels to get started:

The number represent the amount of houses you have to power up. Each generator provides 1 unit of power to each tile it covers, so you have to overlap the coverage area of multiple generators to supply power to tiles with 2 or more houses.

In designing these levels, I went for the simplest non-trivial configurations of lines and crosses I could find, then simply numbered some of the tiles covered by the shapes. Numbering all the covered tiles would have given away the placement of the generators, and would have over-constrained the solution. Solving the levels would have been easy and boring. By not giving away too much information, you leave the player guessing. By not over-constraining, you also let the player solve the level in different ways, and that makes it more interesting. Although, you have to try to make sure there are no trivial solutions that you didn’t think of. Obstacles are a good way to prevent trivial solutions.

I handed these levels to Merwan, and he tried to solve them. He got one very quickly, and got stumped on another one. “Are you sure there is a solution?” he asked. “I think so” I replied, and I thought: this is challenging, he looks like he is having fun! Then I double-checked, and as it turned out, my level had no solution. When I fixed it, he solved it quite easily. I then made another one, this time making sure it had a solution, and one that was not too obvious. He solved it in around 1 minute.

We felt that the process of solving the levels was fun enough to go forward with this idea.

Solving the night conundrum

We really felt like we had to have the night in there, as it would make the game more unique. But how exactly would that work?

Maybe the houses you need to power would not be the same at night? Maybe, some houses would only need power during the day, and some would need power during the night? We felt that would make the puzzles hard to design. As we wanted to display the day and night side-by-side, your generators would necessarily be in the same place on the plateau in both sides, otherwise you wouldn’t be solving the same level, but really two separate levels. So, we went for simple again, and the houses you need to power would have to be the same on each side.

We wanted to have a real interplay between the day and night portions: you would have to go back and forth to satisfy the constraints on both sides. We needed to find a mechanism that would let you solve the day side, but you would have to refine your solution in order to solve the night side.

We started by reducing the coverage of wind turbines and solar panels by half. Now, we had to somehow overcome this power disparity between night and day. We thought about adding a third power generator that would work only at night. What would be its coverage area? We thought of a battery that would spread power to neighboring houses. Maybe we could charge the battery in the day, and depending on the amount of charge, it would power that many houses? If two generators are powering it in the day, it provides two units power at night. But how would we decide which houses would be powered by the battery at night? If the battery has one unit of power, but two neighboring houses, which one is powered? And more importantly, how to communicate that rule to the player? We didn’t know, so we changed it: what if the battery gives power to all the neighboring houses, regardless of its charge? That would be less annoying, as you wouldn’t have to care about the orientation of the battery. The battery would still need to be powered during the day, but receiving one unit of power would be enough. That made the day and night sides feel connected.

We did a quick check on the paper levels to see if the battery would still allow you to solve the levels we had. It wasn’t clear at this time whether the battery mechanism was interesting to play or not, but it was already 4PM, and we ought to start coding at some point.

Getting to a playable state

We both felt that an isometric view would be right for the game, and a very good pretext to play with THREE.js. We threw together a skeleton made of THREE.js and Playground.js (though we didn’t use much of the latter in the end) and got to work.

I took care of the game logic: first a grid you could put things on. Things are consumers, generators or obstacles. A consumer is just be a number: how many houses are on the tile. A generator has a coverage area, and we use that coverage in order to validate the level configuration: make sure every consumer gets as many units of power as it requires. Here is the first iteration of the level validation code:

let counters = new Map();
for (let th of this.things.keys())
  if (th instanceof Consumer)
    counters.set(th, 0);

for (let th of this.things.keys())
  if (th instanceof Generator)
    // Let the generator add to the power counters
    th.distributePower(this, counters);

// Gather any mispowered (unpowered/overloaded) consumer,
// with the current value
let mispowered = [];
for (let [counter, power] of counters.entries())
  if (counter.size !== power)
    mispowered.push({counter, current_power: power});

// If there are no mispowered consumers, the level is solved!
let solved = mispowered.length === 0;

I revisited it later to have separate counters for the night as well, and to handle the case of the battery distributing power at night only when powered in the day. But the principle remains the same.

For editing the levels, I simply represented them as strings in a JS file:

let LEVELS = [
  {
    generators: 'SS',
    map: `....1.2...`,
  },

  {
    generators: 'SSW',
    map: `.....
          .....
          .221.
          .2.1.
          .....`,
  },

For YATM, we had used the Tiled editor, and while it had its downsides, it got the job done. However, using an external editor, there is an extra export step that gets in the way when you need to design levels quickly.

With the levels in a string, I just wrote a simple parser that emitted instances of the relevant objects according to the current character. It made editing levels trivial, as I just had to change a few characters in a text editor and reload the game to immediately see the result. This allowed me to iterate on the levels rather quickly on Day 3, when I put the bulk of the levels in the game.

By the end of Day 1, we could load a level, move and place generators, and the game could tell us whether the level was solved or not, and which tiles were lacking power. All of that in the console, not on the screen. Merwan was in charge of everything visual (he has the credentials for that), but we didn’t plug the view and the logic together until Day 2.

Day 2: Adding the visuals

Here are a few screenshots of the visual progress for the first two days:

Why are wind turbines floating in the air in the bottom two screenshots, you ask? This is the inventory that we cut from the game. If you look back to the level data higher up, you will see a generators line. Initially, you were supposed to pick the generators from the inventory area before placing them on the plateau. The code was a bit tricky to get right, as we needed to have a separate render pass just for the inventory, and specific picking code since the inventory would live in a separate world space. Plus, we had extra logic that dealt with taking things from the inventory and putting them back in it. But then, it occurred to me that we didn’t need the inventory: we could place the generators directly on the plateau, and the player would simply move them. It made the code simpler, and the game more intuitive! I immediately told Merwan, who agreed it was the right call—but only after initially hating me for cutting the feature he had spent the last two hours working on.

The lower-right screenshot shows the side-by-side day and night views working. It was a bit simpler than anticipated to get working (THREE.js had example code for multiple views), but it was still tricky to get everything right. At first, we thought about duplicating the day scene into a night scene and keep the two scenes in sync with the model. Merwan suggested an alternative of rendering the same scene, but changing a few parameters on the fly. For instance, lights could be toggled on and off, or switched directions before rendering the night scene, and reset before rendering the day scene. This worked nicely.

The tricky part was rendering the coverage area of the generators, as they were actually different objects. The visual feedback for powered houses would also necessarily be different in both scene, as a house could be powered at day but not receive any power at night. We ended up rebuilding the coverage areas every time we set up the day or night scene, that is, at 120Hz. This is grossly inefficient and keeps the garbage collector quite busy, but as we only show the coverage for the generator currently under the cursor, it has not been an issue in practice. The feedback for powered house is less wasteful: it’s simply a list of objects that we give to an outline pass; we update this list before rendering the day and night scenes.

At the end of Day 2, we had something playable, although with only 5 levels, and the visual feedback was still rough. We parted ways as Merwan had to travel back home, and we kept hacking on the game remotely with regular updates over the phone, right until the deadline.

Day 3: night levels and polish

The last day was probably the longest as we stayed up right until the deadline to put everything we could in the game, and make a coherent whole.

Merwan worked hard on making sure the rules of the games were intelligible through the visuals. You can see in the collage above some iterations of the coverage areas and visual feedback for powered houses: from orange tiles signaling unpowered houses, to individual outlines around houses.

He also worked on visual polish: the dust particles when you plop a generator on the plateau, or making the day and night scene have a different feel, so it would be obvious to players that it was, in fact, the same plateau at different times of the day. The sun and the moon were a nice touch on that front, but then the shadow directions were all wrong, and we had issues with the moon coming in front of generators in the night scene. We would have loved keeping them, but due to lack of time, he cut them and opted for a starry background instead. He still took the time to put a YATM easter egg in the stars though!

I spent the day making the level validation work for the night levels, as we settled on the exact behavior of the battery. I then designed the night levels; we still had only one at that point. I aimed for 3 night levels, as I wasn’t really sure I could stretch the idea without making the levels feel repetitive. In the end, I managed to make quite a few levels more! I then spent around two hours making the sound effects in sfxr and the music in Sunvox. I was quite satisfied with the music, as the end result was about what I had in mind when I started. We also worked on buttons for navigating between the levels, and transitions.

When the game felt whole, I asked Marie to test it from start to finish. Having a fresh set of eyes on the game is crucial, as there are things that are obvious to the developers who have been working on it from the start, but may not be to players who might not devote more than a few minutes to the game. Her feedback helped me nail down the level difficulty progression, and gave us a roadmap of things to improve in the last hours of the jam.

Ten minutes before the deadline, I hit the “Submit” button on the LD page. We pat each other’s back over the phone on a job well done. We had made a game!

Aftermath

It’s a weird feeling, to know that three days earlier you had no clue of what your game would look like, or if you would even be able to get something fun working this time around. But, now, we have a game we can show to friends and colleagues. The feedback on the LD page has also been overwhelmingly positive. It’s a great feeling!

I would without a doubt recommend to anyone who has ever wanted to make a game, to participate in a game jam. I feel it is a good way to learn how to focus your game design and coding efforts in order to make something playable and complete. It forces you to relentlessly cut, cut and cut, until you have a core that is both fun enough and realizable. This is quite different from the greenfield development of side projects.

And even if you don’t finish or submit your game, the experience itself is something that is worth going through, as it will create memories that you will gladly reminisce later down the road. I know I will.

Against Simplification

2016-05-24T00:00:00+00:00

Our minds build theories, models of the world in order to function. To communicate, we build models of reality through language, gestures, paintings, music…

When reading an essay, or any piece of literature really, I read a simplified view of the world. A view that can fit into a page of words. Reality in a can.

Reality can be experienced, that’s for certain. We do experience it every day. It can be argued that we do not experience all of it, because all our experiences are filtered by our senses. Our senses shape our reality, as do our minds. The mind mixes the sensorial inputs to form a pleasant arrangement, one that conforms to our memories and expectations. So maybe, my reality is not the same as your reality. But in any case, we do experience it by living and breathing.

And, maybe I’m not a very eloquent person, but I can’t think of any sequence of words, or any amount of epithets, that would describe that experience in its full. Any description is dumbing down. And because everyone’s experience of reality is slightly different, any one description will always be influenced by the perception of its author. But even if the description were apt, reading about a thing is not experiencing the thing. Reading is an experience, and can be quite an enjoyable one, but no description can substitute to the experience itself.

All models are wrong, but some are useful. Our minds are seemingly incapable of capturing our experience of reality. The function of the brain is to capture the infinite in a finite medium. It compresses. It classifies. It categories. It put small labels on things, and put them in separate boxes. Then, it generalizes. It constructs theories about the things in the same box, so that we don’t always have to deal with individual things, only with boxes. It chunks. And it continues to chunk as we absorb more information, as we experience. It puts the boxes of things in larger boxes, and those boxes in other boxes and so on. It abstracts.

Our mind devour theories. A good theory, for our mind, is like finding a free box on the street. When you have a lot of junk, free boxes are always a good thing. Even more so when the box is accompanied with a list of the things it should hold. So finding a good theory is an opportunity to compress some more, without having to do the work of devising it. Extra space, no effort. A good essay is a coherent slice of reality, carefully chosen and assembled in a way that’s easily digestible by our mind.

There are interesting side-effects to this way the mind works. Soon enough, we start seeing relationships at the “box” level that were not apparent at the “thing” level. Things that had seemingly nothing in common now share abstract characteristics. Before, you saw lamps, wheels, bottle caps, mugs, and holes; now you are seeing circles.

Abstraction is a powerful tool. Everything we know about a circle, we can apply to any object that has a circle shape, or contains a circle-shaped part. Instead of devising theories for each individual thing, we discover facts and solve problems for whole categories of things, at once. Mathematics are a constant reminder of the power of thinking with abstractions.

But abstractions are simplifications. By abstracting, we strip the details, we remove the ornaments, trim the superfluous, the extraneous, to keep only what is essential. But what is essential to a thing is not absolutely determined; it may depend on the context. A detail for one observer may be the essence for another, and vice-versa. Some models may be useful, but all are wrong.

The danger is to mistake these abstractions for reality. Abstractions are artifacts, manifest side-effects of the way our brains make space for new information. Abstract relationships are illusions forged by our minds. Trying to shape the world around us according to our abstractions, our very personal, and very peculiar, illusions, is indistinguishable from madness.

The experience of reality is rich, complex in millions of little ways, and ultimately chaotic. But it is the only one there is, and we should embrace it in full, even if it is irreconcilable with the way our main organ to experience it works.

But that’s only my, very own, simplification.

The Many Ways to Build Objects in JavaScript

2014-10-24T00:00:00+00:00

In JavaScript, the dominant pattern to declare objects is to write a constructor function and append each method to its prototype property. To create an instance of the object, one must then use the new keyword on a call to the constructor function.

function Set() {
  this.items = [];
}

Set.prototype.add = function(e) { this.items.push(e); }
Set.prototype.size = function() { return this.items.length; }

Here Set is the constructor function; in its body, this is a reference to a newly-created object that will be returned after a call to the constructor with the new keyword. By convention, constructor functions begin with a capital.

var s = new Set();
s.add(1);
s.size() // 1

Note that Set is just a regular function, i.e. we can call it without the new keyword. Though usually it is not what you want, since Set will return undefined and will bind this to the global object in the absence of a caller.

var s = Set();
s.add(1); // error: s is undefined
this.items; // [] -- Global objects is polluted

The new keyword applied to the Set function has the following effect:

An empty object o is created.
The [[Proto]] property of o is bound to Set.prototype. In other words, the prototype of o is set to Set.prototype.
The function Set is called with o is bound to this.
When the function returns, it returns o instead of undefined.

That is why methods of the object must be attached to the Set.prototype object: it is the prototype of every instance of Set.

I always found this pattern verbose and confusing. The new keyword was made to be familiar for Java programmers, but there is no mention of classes, only prototypes. In fact, it can be misleading to relate to Java, since the receiver of a method is not bound statically in JavaScript.

var s = new Set();
s.add(1);
var add = s.add;    // Aliasing the method
add(2);             // error: `this.items` is undefined

The call to add(2) has no explicit caller, so this is bound to the global object, which doesn’t have an items object.

Also, functions have a unique prototype property that is unfortunately not the same thing as the [[Proto]] property that every object – including functions – have.

Languages that compile to JavaScript, like CoffeeScript, TypeScript, Dart and even the next version of EcmaScript all provide syntactic sugar to hide this pattern.

Luckily, there are alternatives to this pattern in vanilla JS. By not trying to mimic class-based languages, but harnessing the simplicity of the prototype model, one finds flexible and terse ways to create objects.

Object factories

JavaScript has objects literals, which are great for building singleton objects.

var bag = {
  items: [],

  add: function(e) { this.items.push(e); },
  size: function() { return this.items.length; },
};

bag.add(1);
bag.size(); // 1

Attributes and methods are now just properties of the same object. In this respect, this form is more regular than the first pattern.

What if we want another instance of this object? In other prototype-based languages, we would just clone the first one; in JavaScript, there’s no built-in clone function. Instead, we can create a factory function.

function mkSet() {
  return {
    items: [],

    add: function(e) { this.items.push(e); },
    size: function() { return this.items.length; },
  };
}

var s1 = mkSet();
var s2 = mkSet();
s1.add(1);
s2.size(); // 0

The mkSet function puts out new objects of identical initial state. Compared to the previous example, we have lost a bit of flexibility. The bag was usable right away, but here we must call the factory to create a new object before beginning to use it.

This form also has another downside: the methods are recreated separately for each object. The add method of s1 and s2 are not the same. Not only if this wasteful, but leaves us no way of adding or altering methods for all objects of the same factory.

We can correct the latter defect by putting the methods in a separate setProto object. Then, in the factory method we must set the [[Proto]] property to this setProto object.

var setProto = {
  add: function(e) { this.items.push(e); },
  size: function() { return this.items.length; },
};

function mkSet() {
  return {
    __proto__: setProto,
    items: [],
  };
}

var s1 = mkSet();
var s2 = mkSet();
s1.add(1);
s2.size(); // 0

This way, all objects created by the factory mkSet share the same methods. We can easily extend the functionality of all sets by appending methods to setProto.

setProto.clear = function(e) { this.items.length = 0; };

Note that we did not correct the first defect: we must still use the factory to begin using sets. However, we essentially recreated the first pattern: mkSet() does what new Set() did, and setProto is Set.prototype. It is less verbose, but now the methods and constructor are separate entities, which makes even less sense. As a result setProto, is not a usable object on its own. We would like to reunite the two.

Reuniting prototype and constructor

Since the constructor is just a function, why not put it inside the prototype object itself?

var Set = {
  new: function() {
    return {
      __proto__: Set,
      items: [],
    };
  },

  add: function(e) { this.items.push(e); },
  size: function() { return this.items.length; },
};

var s1 = Set.new();
var s2 = Set.new();
s1.add(1);
s2.size(); // 0

Set is still the prototype object, but the constructor is part of its definition. Calling Set.new() creates new objects inheriting from Set. In fact, new is a method of all Set objects.

s1.new(); // Exactly the same as Set.new()

While this is unusual for class-based languages like Java, where constructors are special methods, here we see they are just regular functions that return new objects.

There is a bit of redundancy there, namely the Set in the line __proto__: Set. Since we will call the constructor with Set.new(), why not use this instead?

var Set = {
  new: function() {
    return {
      __proto__: this,
      items: [],
    };
  },

  ...
};

var s1 = Set.new();

Now Set.new() and s1.new() are no longer equivalent. The latter create an object that have s1 as prototype, not Set. This means that we can specialize objects in branches, not only as a whole.

var s1 = Set.new();
var s2 = Set.new();
var s11 = s1.new();

Set.clear = function(e) { this.items.length = 0; };
s1.forEach = function(f) { this.items.forEach(fn); };

Here, s1, s2 and s11 all have the clear method, but only s1 and s11 have forEach.

Prototypes as default objects

We should try to correct the first defect. As it stands, the only method that makes sense to call on Set is new. Why not make Set a fully functional instance of itself?

var set = {
  new: function() {
    ...
  },

  ...
}.new();

set.add(1);
var s2 = set.new();

Just by calling new() on the object defining the set prototype, we are giving it an items array. Somehow we lost the direct reference to the original prototype, but it does not matter since all set objects will be derived from set itself (and we can still access it from set.__proto__).

Cloning is just another method

Finally, when creating objects we might want to make a deep copy of an existing copy – not start from a fresh state. This can be achieved by adding a clone method that defines the deep cloning of each attribute. It also binds [[Proto]] of course.

var set = {
  ...

  clone: function() {
    return {
      __proto__: this,
      items: new Array(this.items),
    };
  },

  ...
}.new();

set.add(1);
var s1 = set.clone();
s1.size(); // 1

Here s1 begins as an identical copy of set, but not sharing the reference to the items array. If we want shallow cloning, we can just use Object.create(set). And if we want to branch, we can call set.new. We also can use set right away as a set. All objects derived from set will inherit from changes made to their prototype, which allow to specialize and extend their behavior as befit.

This last form is not only more flexible than the dominant pattern of the first example, it is more terse and regular. But more importantly, it illustrates the orthogonality of the core concepts of JavaScript: object literals, first-class functions and prototypes.

Suspend Troubles in Ubuntu 14.04

2014-08-19T00:00:00+00:00

My laptop is a Vaio Z13 with an Nvidia GT330M discrete graphics card and an integrated Intel graphics controller. A physical switch above the keyboard is used to toggle the discrete card. The Nvidia card is useful for games and hooking an external monitor via the HDMI port, but is a battery hog. When the Nvidia card is off, the Intel controller is sufficient for everything else, and can also control an external monitor via the VGA port.

After a fresh install of Ubuntu 14.04, both graphics controllers are correctly detected, and everything looks like it is run by the Intel driver. But the Nvidia card is also turned on, eating away at the battery while I cannot use its benefits.

Since Ubuntu 12.10, I had been relying on Bumblebee to turn off the Nvidia card on boot, and use the optirun command to run GPU-hungry applications under the Nvidia card whenever I needed. It was a setup good enough for my needs.

Alas, under 14.04, installing Bumblebee only turned off the Nvidia card, without the ability to run it later using optirun. Also, the laptop would not suspend any more. Bummer.

After many hours of trying different Nvidia drivers and mucking with the Bumblebee configuration, I failed to find a way to get suspend to work.

Getting suspend to work with nvidia-prime

So I purged Bumblebee and the existing Nvidia drivers.

sudo ppa-purge ppa:bumblebee/stable
sudo apt-get purge 'bumblebee*'
sudo apt-get purge 'nvidia*'

Then tried the alternative that’s apparently officially supported in 14.04, nvidia-prime. All I needed was:

sudo apt-get install nvidia-331

On reboot, I was running under the Nvidia card, but the Intel controller was also correctly handling brightness controls. Suspend also worked. I went to the nvidia-settings panel to toggle the Nvidia card off, and logged out as requested to apply the change.

And then I was greeted by the “low-graphics mode” dialog, unable to get log back using only the Intel controller. As it turns out, it appears to be a race condition between the nvidia driver and lightdm, as logging into tty1 and restarting lightdm did the trick.

To make lightdm wait a bit longer on boot and on toggling, I added a sleep 2 just before the exec lightdm line in /etc/init/lightdm.conf.

Now the Nvidia card is turned off and can be turned on after logging out. More importantly, suspend worked correctly again. Though it now takes ~20 seconds to put the machine in sleep mode, I can live with this minor hassle.

Turning wifi on after resume

And then I wireless was turned off on resume. Toggling the physical switch did not help. Thankfully, the solution can easily be found by browsing the web.

Functional JavaScript Wizardry

2014-03-28T00:00:00+00:00

Since EcmaScript 5, JavaScript has gotten nice collection functions like Array.map, Array.forEach, Array.filter and the usual suspects. However, they can be a bit clunky to use when dealing with objects. Look at the following piece of code:

[" fun", " ction ", "  al"].map(function(str) { return str.trim(); })
                           .join("");
//=> 'functional'

I map over an array of strings, trim each string, then join the resulting array of trimmed strings. Except it’s a bit too verbose for my tastes. I would like to write (and read) this instead:

[" fun", " ction ", "  al"].map(trim).join("");

The straightforward way to do that is to define the anonymous wrapper function that calls trim beforehand:

var trim = function(str) { return str.trim(); };
[" fun", " ction ", "  al"].map(trim).join("");
//=> 'functional'

Okay. Except that I don’t want to call just trim, I might call any function on Array, or Object, or any custom created object for that matter. And I certainly don’t want to write stupid wrapper functions each time.

The trim function already has a name: String.prototype.trim. But unfortunately, I cannot just write the following:

[" fun", " ction ", "  al"].map(String.prototype.trim).join("");
// TypeError: String.prototype.trim called on null or undefined

Because here map will call trim on each string in the array, but without any context object (a value for this). Instead, I would like map to pass each string as the context object to trim, in turn. We could redefine a custom version of map that works that way, but there’s a simpler solution.

Abstracting wrappers

What we really need is a function that transforms method calls into function calls. We need a function m2f to transform o.m(args) calls into f(o, args) calls, where f = m2f(o.m). Easy enough in JavaScript (bar the ugliness of dealing with the arguments special object):

function m2f(fun) {
  return function(/* args */) {
    var args = [].slice.apply(arguments);
    return fun.apply(args.shift(), args);
  };
}

var trim = m2f(String.prototype.trim);
[" fun", " ction ", "  al"].map(trim).join("");
//=> 'functional'

Good! Now I can use m2f on any “method”, and get back a more flexible function. For instance, I can use map on any “array-like” objects like strings, the special arguments object, NodeList and so on:

var map = m2f([].map); // Saving a few chars over `Array.prototype.map`
var up = m2f(String.prototype.toUpperCase);
map("abc", up)
// [ 'A', 'B', 'C' ]

map({0: 'albatros', 1: 'albatros', length: 2}, up);
// [ 'ALBATROS', 'ALBATROS' ]

function(){ return map(arguments, up) }(1, 2, 'abc', 'z')
// [ '1', '2', 'ABC', 'Z' ]

And of course, I can use m2f on any method, not just map. Here I populate an array object with functions from Array.prototype that work on any array-like object:

var array = {};
function isFunction(x) { return typeof x === 'function'; }
var names = Object.getOwnPropertyNames(Array.prototype);
names.forEach(function(name) {
  if (isFunction(Array.prototype[name]))
    array[name] = m2f(Array.prototype[name]);
})

array
// { join: [Function],
//   pop: [Function],
//   ... }

array.slice([0,1,2], -1)
//=> [ 2 ]

This replicates the Mozilla-specific “Array generics” extension. This extension is not available in V8-powered environment like nodejs.

This m2f function is quite handy when you are used to a functional style of programming. You can find it in Fogus’ Functional JavaScript under the name ‘invoker’. However, there is another way to define m2f using a powerful corner of EcmaScript 5.1, bind.

Calling and binding functions

Earlier, I said I could not just write:

var trim = String.prototype.trim;

Because JavaScript methods are really just functions. Now my trim is pretty useless on its own, because it expects a context object.

trim("  a ");
// TypeError: String.prototype.trim called on null or undefined

There’s a way to provide one to it, using call:

trim.call("  a ");
// 'a'

The call function takes a context, some arguments, and calls the receiver (a function) with them.

Another way to provide the context is to use the bind function. As its name implies, bind will return a function with the supplied context bound to it. Let’s see how it works:

var trimA = trim.bind("  a ");
trimA();
// 'a'

trimA.call("b");
// 'a'

Whenever trimA is called, it will call trim with "a" as context, even if trimA is supplied another context with call.

Binding call

Where does that lead us? Well, if we look at the precedent example again,

trim.call("  a ");

we see that trim.call is essentially the function we want. But we’d rather use trim directly, without calling call on it. How to achieve that?

Notice that call is itself a method call. So we can extract it on its own, and use it to call trim. But since it’s an extracted method, we still need to use call on it,

var call = trim.call;

call(trim, "  a ");
// TypeError: object is not a function

call.call(trim, "  a ");
// 'a'

Since we are calling call on itself, the notation is a bit overloaded, but it works. Note that now, trim is just an argument; we can put any other method in there,

call.call([].map, "abc", up);
// [ 'A', 'B', 'C' ]

In fact, there’s nothing tying call to trim. We could have defined call without trim, by taking it on Function.prototype directly,

var call = Function.prototype.call;

Nevertheless, the greatest benefit of this transformation is that we can now use bind to fix the first argument of call to a specific function.

var map = call.bind([].map);

map("abc", up);
// [ 'A', 'B', 'C' ]

And we just redefined m2f!

var m2f = call.bind;
var map = m2f([].map);
// TypeError: Bind must be called on a function

Except it doesn’t work … because we did not provide a context to bind. Putting it all together,

var call = Function.prototype.call;
var bind = call.bind;
var m2f = bind.bind(call);

Alternatively, since bind is not tied to call, it might be clearer to just write:

var call = Function.prototype.call;
var bind = Function.prototype.bind;
var m2f = bind.bind(call);

Which finally gives this one-liner gem:

var m2f = Function.prototype.bind.bind(Function.prototype.call);

A very useful tool for writing terse JavaScript.

A variant of this form was given by Dave Herman and explained by Erik Kronberg, which I read thrice without really understanding what was going on. This article is my attempt to derive this magic one-liner in a way that makes sense for me.

Walking

2013-09-26T00:00:00+00:00

I like to walk. Walking, at my own pace, sometimes for hours. Walking, under the trees, alongside a river, on the beach, or in the mountains. Walking, alone with my thoughts, or chatting with my friends. Walking, among the crowd, to feel like a part of the world; or walking in the countryside, to get away from it all.

I don’t walk for the exercise; though it’s not an unhealthy leisure. I don’t walk as a means of transportation, to get somewhere; there are far more efficient ways to transit. I could run and I could cycle, that would get me farther, further away, faster. But I just want to take my time, to take the time to not be anywhere. When I walk, I’m out there. No duties, no tasks, no deadlines, no pressure. No information, no social conventions, no morale, no legitimacy, nothing. No me.

Walking, you appreciate the beauty of nature, the richness and complexity of a tree’s trunk, of a flower’s corolla, of a ladybug’s elytra. Walking, I can hear, see, smell the world without feeling overwhelmed. Walking gives me perspective.

I wish research was more like walking. I feel like a lot of the organization around research is goal-oriented. You must have a goal before deciding which path to take. A goal that is enticing enough to get you grants. Once the goal is set, you must take the most rewarding route to get there: the one that holds the greater number of publishable results.

Both pressures for grants and for publications greatly limit the number of acceptable research trails. You have to take the most efficient, most trodden path with sure benefits – and you certainly can’t take your time to contemplate the landscape. You have to go fast, have to be the first. You must get in the car and take the highway.

But it’s not the goal that empowers you, it’s the journey. Results may get you respect, recognition, fame; but only the journey will bring you enlightenment, joy and, ultimately, freedom. Choose the path for beauty and for truth. Then, don’t rush it; take your time, pay attention.

Walk.

Inspired by: Bill Waterson, Alfred Einstein, The Oatmeal

My Setup

2012-04-21T00:00:00+00:00

There’s this neat concept over at The Setup where (more-or-less) famous people describe their computer setup. Every interviewee get asked the same four questions:

Who are you and what do you do?
What hardware are you using?
And what software?
What would be you dream setup?

By browsing their answers, you can finally find out which hardware and software help your personal heroes (or nemeses) conceive their great works. They usually list their day-to-day gizmos as well as their invaluable instruments.

However, if you expect them to use life-changing tools you never heard of, you’d better lower you expectations or you will probably be disappointed. Most of the hardware setups presented on the site are merely a subset of the Apple product line. Their software stack is usually much more interesting, since they help solving specific use-cases. You may discover unsuspected gems which will end up completing your own setup.

I wanted to describe my own setup for future reference, and since I’m unlikely to be interviewed by the team behind the site, I’ll answer the questions right here.

Who are you and what do you do?

I’m a CS student with a knack for languages. My main activities are learning and research; both are powered by reading and writing articles, books and computer programs.

What hardware are you using?

Although I have a desktop machine, nowadays I mostly use my Vaio Z laptop. It’s a fast, comfortable, elegant and very light machine. All components are high-end. The screen is gorgeous, with very accurate colors, and a large 1600x900 resolution under 13”1 of matte glass. The keyboard is similar to those found in Apple products, and it’s my favorite keyboard yet: responsive and quiet. Though my standards might be a bit on the low end, since I’ve never tried a mechanical keyboard. The battery usually lasts around 4 hours with WiFi on, which is sufficient for my current needs. On the inside, it hides a dual-core i5 M560 running at 2.67Ghz and 4Gb of RAM. The killer feature though is the 128Gb SSD. I fear the speed upgrade it brought made me less patient around computers running on hard disk drives.

There are two downsides to this machine however. The first is the price. Depending on the configuration, and especially if you add an SSD, it can add up to quite a lot: the price range is $1600~$4500. Looking at the competition, and after more than one year of daily use, I don’t regret buying it, but the investment is not trivial. The second drawback is the poor support of the NVIDIA graphics card under Linux. There are two graphics solutions: one integrated Intel chipset, capable of playing video and modest games, and an NVIDIA GT330M when more graphics muscle is required. Switching between the “stamina” mode and the “performance” mode works well under Windows, but Linux only supports the Intel chipset. Though I need to state that every single other thing works like a charm under Linux, which is laudable considering the sophistication of the hardware and the lack of cooperation from Sony. This last point alone has convinced me to consider thoroughly all options before buying another Sony product.

My companion computer which lives in my pocket is a Samsung Galaxy Nexus. I’m happy with it for the moment, since it’s fast and useful. The display is large and comfortable to browse the web with. I just hope I don’t have to replace it too soon, since these costly gadgets tend to have a very short shelf life.

And what software?

I’ve used Ubuntu continuously since version 8.04 I think. The Debian package system works well, the system is stable, but more importantly, everything just works. No need to muck with drivers or config files for things I don’t care about. WiFi, external monitors, SD card and even the proprietary Memory Stick reader. My laptop runs Ubuntu 11.04 since the upgrade from 10.10 to 11.04 broke a few things I had to fix afterward, and I don’t want to go through trouble again.

However, when I do want a fine-tuned configuration, I turn over to the latest Arch Linux. My previous laptop couldn’t run the bloat of a full-featured Ubuntu, so I took time going through the ArchWiki and related fora in order to build a more lightweight system. Since then, I’ve grown fond of this distribution. The rolling releases mean I don’t need to upgrade the entire system to get a new major version of specific software. Once you get to know your way around, the configuration is not so bad for desktops; exotic peripherals can take some time to get working though. I’ve heard good things about Gentoo as well, and might try it on a spare computer when I find myself in a curious mood.

On top of this OS, my window manager of choice is Xmonad. I’ve used Gnome, Unity, and OpenBox before settling on Xmonad. The tiling paradigm aptly fits my work flow, and it liberates screen estate from useless widgets. Save for a thin status bar, the whole screen is devoted to applications. No longer do I have to move overlapping windows out of the way. All new windows get a share of the current workspace, or their own workspace. Xmonad is also deeply customizable, though you need to be able to parse Haskell.

Growing up with a computer, I never took a good look at the keyboard layout I was using, and just typed away until my fingers knew it by heart. It was only when my hands and wrists began to hurt after repeated long typing sessions that I finally questioned the merit of AZERTY. Even though it’s the de facto standard French layout, there are letters in the French alphabet you can’t type without the help of additional software, like œ, or É. In addition, pairs of brackets, braces and parentheses are never side by side, which is a pain when programming in most languages. There are plenty of alternative, carefully designed layouts you can choose from. I personally use Colemak, since it seemed easier to learn than Dvorak, while being equivalently comfortable for typing. Switching hampered my productivity for a few months, but was worth it in the long run.

Aside from a keyboard and its layout, a good text editor is also essential for typing greatness. This is why my most cherished piece of software is Emacs. Obviously, I edit all source code with it, and all my version control is done by using Git from Emacs with Magit. I also manage my research notes and draft articles with Org mode, read and write email with Gnus, navigate in projects with projectile, etags and ack… I could write a whole article to enumerate the ways I use Emacs and again another article to describe my Emacs configuration file.

A well-designed monospace font is a primordial part of a programmer’s toolbox. Again, there are many free, good-looking fonts suited for programming to choose from. Personally, I find the Ubuntu Mono font fantastic. Before its release, I used the DejaVu Sans Mono from Bitstream, but the Ubuntu monospace variant has more charm and perfect legibility.

My email setup is a tad convoluted, but for good reason. I use Gmail for my main email address. I use IMAP for all my email accounts since I want to read my emails from my phone, laptop or desktop machine. In addition, I want to regularly backup all mail in case any funny business arises in Google’s headquarters. Toward this end, I copy everything with OfflineIMAP to a local Dovecot server. Then I use the already-mentioned Gnus reader to compose and read emails. Nowadays I also read short emails or write quick answers from my phone.

Apart from Emacs, the application I launch everyday is a web browser. These days I’m back to Firefox (trunk builds). I have a battery of privacy extensions, and can sync my bookmarks, history and open tabs with other devices. I used Chrome for a while, but let it go due to its smaller offering of add-ons and its annoying habit of going to Google search instead of relying on browsing history. The speed difference between these two is getting narrower, and the developer tools are comparable.

The remaining programs deserving mention are: most of the GNU coreutils, Gnome terminal, Evince and other Gnome apps, and zsh.

What would be your dream setup?

My truly ideal setup would have the following characteristics:

A large display I can read and write on for hours on end without straining my eyes,
Talking, thinking and handwriting input,
A way to conceive and develop programs without caring for minute details,
No need to wade through a hundred pages of documentation to configure or fix something in the computer.

While this may be ideal, it might not be realistic, yet. Though we live in interesting times, and I do hope that someday I can tick a few or all of these items.

Notes on a Thesis Defense

2011-11-27T00:00:00+00:00

Tuesday was a very special day for my friend Karim. He defended his thesis. After nearly five years of work, during which much teases and jokes were made about his thesis pace (three years is the norm here), he finally finished his dissertation and defended successfully.

It was also a very interesting afternoon for me, as I got to watch and learn. Especially, I focused on the jury’s reactions during both his talk and the following Q&A, as I was seated just behind the six of them. I also took note of specific points I think he got right during his defense, and some others I would have done differently.

Focus on content, not on style

Nearly everyone uses Beamer at my University. It’s not particularly a joy to work with, but it produces clean slides. The downside is, your slides tend to look the same as those of other Beamer users. It’s particularly true when one doesn’t take the time to question the default Warsaw theme. The blue and black color scheme has become as tiring as Times New Roman for me, and I cringe every time I see it. And I cringed when Karim launched his talk.

However, Karim quickly made me forget the atrocious theme after two minutes or so, because the content was interesting. The theme may be ugly, but at least it’s not distracting.

Only show what’s relevant

At one point, Karim showed us one of his algorithms on one slide. An entire, forty-something lines algorithm on just one slide. In a talk, a slide stays between one and two minutes on screen. I can’t grok a forty lines algorithm in two minutes. Nevertheless, I am able to get the gist of it if you highlight the relevant parts, as Karim did.

Still, I would have preferred a high-level description of the algorithm rather than the whole thing. I can always check his dissertation for the details.

State your point clearly, and hammer it

When you have the luxury of a one-hour talk, everyone should get your main point, even your family at the end of the room who came to cheer on you. This is especially true of a thesis defense. Everyone should know your thesis, and how you tackled it. Make one slide with only your thesis on it, and show it a least three times during your talk. Start with it, show it when you switch sections, and begin your conclusion with it. You don’t want the jury to ask you to state the aim of your thesis during Q&A, so print it on a t-shirt just to be safe.

Don’t worry

Karim worked nearly five years on his thesis. Of the two algorithms he offered, one was developed in the last year, and the other he developed over the last six months. He spent the best part of four years trying to come up with the perfect model, and the best suited algorithm. When he ran overtime, he settled on those two algorithms and completed his thesis. While not perfect, the end result is still very interesting, and was enough to satisfy the jury who awarded him his doctorate with the highest honors.

A thesis is just the beginning of an academic career, not its zenith. Try your best, but stay away from the best if you want to finish someday. You can always continue working on the subject after your defense.

If you want to read more on the subject, Olin Shivers has some good thesis advice, and Gian-Carlo Rota’s Ten Lessons I Wish I Had Been Taught is a good read on teaching and giving presentations.

Unity Backlight Color Algorithm

2011-09-03T00:00:00+00:00

With the release of Ubuntu 11.04, the new Unity interface was introduced to users. While it has its issues, I have been satisfied with it overall. I find it cleaner than the Gnome 2 default bottom panel, and I can quickly launch any application or find recent files without leaving the keyboard.

Ever since I began using it however, one detail caught my attention: the colored backlight behind applications icons.

Backlight color

Notice how every icon has a square with rounded corners behind it? This square is colored for currently open applications. This is the backlight.

First, notice the backlight color is not constant: Emacs has a rich purple matching its icon, while the Firefox icon has an orange backlight, but a deeper orange than Update Manager (the box with the orange arrow). Thus, the backlight color seems to match the icon contents. But how exactly is the color determined?

Algorithm hypothesis

Initially, we might guess that the backlight algorithm picks the icon’s most abundant color. It is a good fit for the icons of Emacs, Firefox and Empathy (the two blue heads). However, it falls flat when considering the Update Manager icon, as the orange arrow is smaller than the beige box, but the backlight color is orange and not beige. This is also demonstrated by GIMP’s icon. Our hypothesis is not far from the truth however.

The catch is, we did not define what “most abundant color” meant. Should we scan the icon and keep a count of each pixel color, returning the most frequent color? That could lead to surprising results when considering high resolution icons with gradients. Our eyes might easily differentiate between the blue globe and the humping fire fox around it, but such an algorithm would not. Individual RGBA values are all the algorithm considers, but humans look at the whole picture at once and see continents, a tail, a paw, ears and a muzzle. There are algorithms for detecting image features, but they are far too complex for the task at hand. In fact, the actual algorithm is quite simple.

The code

Diving into the source code for Unity, we find the relevant function in the LauncherIcon class, named ColorForIcon. Here is the entire function:

void LauncherIcon::ColorForIcon (GdkPixbuf *pixbuf,
                                 nux::Color &background,
                                 nux::Color &glow)
{
  unsigned int width = gdk_pixbuf_get_width (pixbuf);
  unsigned int height = gdk_pixbuf_get_height (pixbuf);
  unsigned int row_bytes = gdk_pixbuf_get_rowstride (pixbuf);

  long int rtotal = 0, gtotal = 0, btotal = 0;
  float total = 0.0f;


  guchar *img = gdk_pixbuf_get_pixels (pixbuf);

  for (unsigned int i = 0; i < width; i++)
  {
    for (unsigned int j = 0; j < height; j++)
    {
      guchar *pixels = img + ( j * row_bytes + i * 4);
      guchar r = *(pixels + 0);
      guchar g = *(pixels + 1);
      guchar b = *(pixels + 2);
      guchar a = *(pixels + 3);

      float saturation = (MAX (r, MAX (g, b)) - MIN (r, MIN (g, b))) / 255.0f;
      float relevance = .1 + .9 * (a / 255.0f) * saturation;

      rtotal += (guchar) (r * relevance);
      gtotal += (guchar) (g * relevance);
      btotal += (guchar) (b * relevance);

      total += relevance * 255;
    }
  }

  float r, g, b, h, s, v;
  r = rtotal / total;
  g = gtotal / total;
  b = btotal / total;

  nux::RGBtoHSV (r, g, b, h, s, v);

  if (s > .15f)
    s = 0.65f;
  v = 0.90f;

  nux::HSVtoRGB (r, g, b, h, s, v);
  background = nux::Color (r, g, b);

  v = 1.0f;
  nux::HSVtoRGB (r, g, b, h, s, v);
  glow = nux::Color (r, g, b);
}

The code is rather straightforward. Even without GDK experience, the calls are self-explanatory. The backlight color is close to a mean of each pixel’s color, except each color channel is weighted by a relevance factor before contributing to the icon total. The relevance of each pixel is proportional to its saturation and alpha value. This explains the orange backlight for Update Manager: even though the beige box is larger, the orange arrow is more saturated, weighting more than beige in the backlight total. Thus the result is more orange than beige, but not quite the same backlight color as for the Firefox icon, which has more saturated orange pixels.

Finally, there is also some saturation normalization:

if (s > .15f)
    s = 0.65f;
  v = 0.90f;

Every backlight color that is saturated enough will be normalized to 65%. I guess this is done in order to achieve a more unified feel, and to avoid highly-saturated backlight colors.

Programming Languages Names Etymology

2011-08-27T00:00:00+00:00

Do you ever wonder where the name of your favorite programming language comes from? I do. The first to struck me was Python.

Why Python?

At first we might associate it with the large, constricting snake, star of many B-movies about people in beige shorts being swallowed whole by not-so-mythological beasts. The official logo strongly indicates that this is the intended meaning behind the name. The actual origin has a more British flair, as it comes from the Monty Python’s Flying Circus BBC show. Quoting Guido van Rossum, the language’s author, in Foreword to Programming Python:

Over six years ago, in December 1989, I was looking for a “hobby” programming project that would keep me occupied during the week around Christmas. My office (a government-run research lab in Amsterdam) would be closed, but I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately: a descendant of ABC that would appeal to Unix/C hackers. I chose Python as a working title for the project, being in a slightly irreverent mood (and a big fan of Monty Python’s Flying Circus).

Jolly good! As a testament to this ancestry, the literature concerning the Python language often references Monty Python skits (see the official tutorial for an example), but seldom mentions reptiles.

It’s not a snake … or is it?

But wait, where did the snake logo came from then? There must be some connection, otherwise it would not ornate the official homepage of the language. Guido van Rossum provides the answer in an interview with Computer World:

Are you a Monty Python fan (given the name and other elements of the language derive from Monty Python’s Flying Circus)?

Yes, this is where I took the language’s name. The association with the snake of the same name was forced upon me by publishers who didn’t want to license Monty-Python artwork for their book covers. I’m also into the Hitchhiker’s Guide to the Galaxy, though I’m not into much other staples of geek culture (e.g. no sci-fi or fantasy, no role playing games, and definitely no computer gaming).

So, Monty Python artwork licensing difficulties on Python books introduced the association with snakes. I guess the serpentine imagery stuck, and ended up replacing the legacy logo.

I wonder which publishers van Rossum refers to though. Perhaps the publisher of the aforementioned Programming Python, who coincidentally happens to favor putting animals on their book covers. In that case, the elegant compromise would have been to choose a dead parrot.