Getting closure in JavaScript

wooden heart

If you’re coming from an imperative programming background, closures in JavaScript can be pretty hard to grok. Here is yet another attempt to explain them. It assumes you are familiar with how lexically scoped, imperative languages like C, C++, and Java work.

In JavaScript every function call creates its own lexically scoped context. Normally that context is destroyed at the end of the function call. However, you can keep that context alive by creating a closure.

The function inner below creates a closure. Because there exists a reference to the inner function from the calling code after the function returns, neither the inner function nor its context are destroyed. In other words, inner‘s context (including vars local to countFrom) lives on after the call to countFrom returns.

function countFrom(num) {
    var counter = num;
    var inner = function() {
        // return the value of counter before increment.
        return counter++;
    }
    // return a reference to the inner function.
    return inner;
}

var countFromOne = countFrom(1);
/* countFromOne now refers to inner()
   with a unique, persistent context. */

window.alert( countFromOne() );  // alerts 1
window.alert( countFromOne() );  // alerts 2
window.alert( countFromOne() );  // alerts 3

var countFrom42 = countFrom(42);
/* countFrom42 refers to inner()
   with different, persistent context. */

window.alert( countFrom42() );  // alerts 42
window.alert( countFrom42() );  // alerts 43
window.alert( countFrom42() );  // alerts 44

/* The context associated with the inner from
   countFromOne is not affected by the above. */
window.alert( countFromOne() ); // alerts 4

Once you get the basic concept, you should be able to follow other examples that show how they can be useful.

P.S. Neckbeards think not naming things is cool, so here’s an anonymousy version of the function above.

var countFrom = function(num) {
    var counter = num;
    return function() {
        return counter++;
    };
};

Getting good PDF output from KiCad in Linux

kicad-appicon-128
Update: Turns out SVG might be a better base than PostScript for this. See PDF output from KiCad in Linux from SVG.

I’ve tried to get decent PDF output from KiCad‘s Eeschema a few different ways, but what I’ve found to work most reliably is to first export to PostScript (File > Plot > Plot PostScript) and then use the ps2pdf command from ghostscript to convert to PDF. (The Arch wiki has a good writeup on ps2pdf.)

The biggest problems with this are:

  1. It’s a lot of typing to get the conversion to happen (the minutia of which you won’t have memorized).
  2. It leaves you with both a PostScript and a PDF of the document(s), one of which is likely to get out of sync with the other, which may or may not be in sync with the actual schematic, etc.

To help with this, I use the script below. I drop a copy of it into the root of my KiCad projects and edit the OPTIONS as needed for the project. Then whenever I want PDFs of my schematics, I export PostScript from Eeschema and then click on this script in my file manager. Note that running this script will destroy any *.ps files in the directory—that’s by design.

#!/bin/bash

# DESTRUCTIVELY convert all postscript files
# in working directory to PDF.
# Requires ghostscript.

# Mithat Konar 2013 [http://mithatkonar.com]

OPTIONS="-dOptimize=true -sPAPERSIZE=11x17"

FILES=$(ls -1 *.ps)

for file in $FILES
do
  ps2pdf $OPTIONS $file && rm $file
done

I’ve not tried the script on any PostScript files other than those produced by Eeschema, but I’ve got no reason to think it won’t work on other PS files as well.

Processing: Capture is a PImage

Ds8_roll

Something the documentation on Processing’s Capture class doesn’t mention is that Capture is derived from PImage. I went digging into the Capture source code to figure that out:

public class Capture extends PImage implements PConstants { ...

This means all the methods and fields available to PImage objects should also be available to Capture objects. This makes video processing a lot easier!

Thoughts on Free Communication redux

broken-cell-phone

I’m doing some international traveling at the moment. Wanting to stay in touch with loved ones has me contemplating Thoughts on Free Communication once again. It seems that all the pieces are there … I wish I had the headroom to set something up.

An alternative I hadn’t considered is Mumble+Murmur. An old post from Keshav Khera has turned me onto the idea that gamers might inadvertently lead the way toward decentralized and self-controlled realtime communication, and Mumble+Murmur seems to hold some promise in that area. AFAIK, it doesn’t support video and the Android clients don’t seem so very awesome, but at least one of them is FOSS. Something to look more deeply into.

FPAleksandr

FPAleksandr is a theme for FlatPress that I am porting from Mat Wiseman’s insanely awesome Aleksandr, originally made for Textpattern.

It’s available in my Bitbucket, and there’s also a FlatPress forum discussion.

I tried to remain as faithful as possible to the original, but some things were just not going to translate directly—the footers, for instance. The best solution I was able to arrive at for the footers takes away some of the elegance of the original, but given the limits of the platform I don’t think it’s all that bad.

There are still some bugs to squash and lipstick to be applied, but it’s basically usable as-is.

First commercial PCB layout using libre tools

I recently delivered my first printed circuit board layout project using libre software. It’s an actively regulated, high current power supply for an audio equipment manufacturer, and it should be on the shelves in a month or so. The software used was KiCad (GPL2), though I did use FreeRouting (gratisware) to help route the board. I am quite happy with the results and the process. The work was done completely in Linux (Debian Wheezy, if you’re curious), proving that libre EDA–including the OS–is entirely possible.

Except for autorouting, the overall experience was comparable to working with my previous go-to package: the now-defunct WinQCad. While FreeRouting’s autorouter seems comparable to the best that other high-value EDA tools can presently offer, WinQCad’s was in a class of its own. FreeRouting still gets the job done, but it needs more hand-holding and prodding.

In addition to using it for PC layout, I am also using KiCad as a front-end schematic capture tool for SPICE simulations. Now that I’m over the worst of the learning curve, I’m really looking forward to doing more work in KiCad.