• The Start-Up of You by Reid Hoffman and Ben Casnocha: A career book by a LinkedIn cofounder. Emphasizes networking as an essential tool to advance your career; unsurprisingly advocates using LinkedIn to do this.

• Ultralearning by Scott Young: The book describes an approach to learning by immersing yourself in projects which will teach you the skills you are interested in. It also discusses incorporating techniques like retrieval practice, spaced repetition into the projects to speed up your learning process.

  A lot of the learning techniques bit will be already familiar to you if you’ve read any other books about learning, but I do quite like the idea of project-based learning.

• Range by David Epstein: the main message of the book is that the world could do with a little less of everyone rushing to specialize and more of people and organization who cultivate breadth.

  Most of the book reads like the typical non-fiction book with a lot of the same examples(like the Polgar sisters who also appear in Ultralearning above) but for a change, the author also talks about his own experiences and perspectives. The chapters talking about the value of improving what the book calls match quality– finding what kind of work suits you– were pretty good.

• Digital Minimalism by Cal Newport: Contrary to what I thought coming into the book, the suggestions in the book are not at all extreme. The book urges you to be intentional about how you use your smartphone and social media. It tries to make the case that when it comes to using these technologies there is actually a lot at stake– your mental wellbeing but also how these technoligies can distract you from the things you really value in life.

• The Undoing Project by Michael Lewis: biographical book about the Daniel Kahneman and Amos Tversky. Also, goes into their research into the systematic ways in which human minds make errors. I can seem why Lewis’s other books(Money Ball, Liar’s Poker, etc) are so popular– his writing style is very engaging. This is probably also a good book to read prior to diving into Kahneman’s Thinking, Fast and Slow, which I’ve been told requires some effort to read.

• The Wright Brothers by David McCullough: a biography of the inventors of the airplane. This is an excellent book bringing to life the characters involved. It also serves as a reminder of just how amazing of feat the brothers achieved not too long ago.

  Among other things, excerpts from the letters the brothers wrote to each other and to other family members, and diary entries give a good glimpse into their minds and lives.

  I highly recommend this book.

• The Idea Factory: Learning to think at MIT by Pepper White: the book is about the author’s experience at MIT as a graduate student. There are some points in the book where the author significantly expands his personal frontiers in learning to think; those parts of the book were most interesting.

I have been familiarizing myself with WebAssembly by writing small WAT files and looking at the WASM output for some simple C functions. WebAssembly Studio is a great tool for doing this kind of exploration.

Branching in WebAssembly takes some getting used to– for one thing, the target of your branch instructions are relative to the current scope. That is, the target of the br 1 refers to the scope one level up from the current scope and the same target will be referred to as different indices depending on where the branch is being called from.

(block ;; <- this is the target block for the br below
  (block ;; <- if you wanted to refer to this, you would use `0`.
    ...
    br 1
    ))

The other thing is that the branching behaviour is a bit different depending on whether the target is a block or a loop. If the target is a block, control exits from the block. While if the target is a loop, the loop continues.

I thought I’d jot down some notes on my understanding of how branching works in WASM along with some examples.

Blocks

The branch instructions take an index– this index specifies the number of levels outward to go from the current scope:

(block
    local.get 0 ;; get 0th local, and put into stack
    i32.eqz ;; pop stack and check if it is zero, put result(boolean) into stack
    br_if 0 ;; branch out of 0th `block` if top item in stack is true
    i32.const 42
    local.set 1)

As mentioned in the comment in the code block, if the 0th local is zero, control reaches the instruction after the block.

Let’s look at a function involving nested blocks. Suppose we want to encode the following logic in WASM:

if (x == 0)
  return 42;
else if (x == 1)
  return 99;
else
  return 7;

One way to achieve this would be with the following function:

(func $foo (param i32) (result i32)
       (local i32)
       (block
           (block
               (block
                   ;; x == 0
                   local.get 0
                   i32.eqz
                   br_if 0

                   ;; x == 1
                   local.get 0
                   i32.const 1
                   i32.eq
                   br_if 1

                   ;; the `else` case
                   i32.const 7
                   local.set 1
                   br 2)
             i32.const 42
             local.set 1
             br 1)
         i32.const 99
         local.set 1)
       local.get 1)

If you actually compile the C or Rust equivalent of the code above, this is not the WASM you’ll get but this serves nicely for our purposes.

Let’s start with the “else” case first. We set the local to 7 and branch out of the block two levels up. This is the outermost block, which makes the next instruction the local.get 1. So we get the local we just set and return.

In the x == 0 case, we branch out from the innermost block, and the next three instructions are:

i32.const 42
local.set 1
br 1

Again we set the local to 42. And the index we pass to br is 1. Remember though that we branched out from a block, so branching out with index 1 means we are branching out of the outermost block again.

Loops

A branch instruction referring to a loop behaves a bit differently– if the index passed to a branch instruction is a loop, control passes to the beginning of the loop instead of exiting as happens in a block.

Here is an example showing the iterative factorial algorithm:

;; int result = 1;
;; while (i > 0) {
;;   result = result * i;
;;   i = i - 1;
;; }
(func $iterFact (param i64) (result i64)
       (local i64)
       i64.const 1
       local.set 1
       (block
           local.get 0
           i64.eqz
           br_if 0
           (loop
            local.get 1
            local.get 0
            i64.mul
            local.set 1
            local.get 0
            i64.const -1
            i64.add
            local.tee 0
            i64.eqz
            br_if 1
            br 0))
       local.get 1)

Let’s focus on just the branching statements.

The first br_if, outside the loop exits the block if the argument passed is 0.

The br_if inside the loop also exits the block(and hence also the loop), although note that this time the same block is referred to as index 1 instead of 0.

The final br 0(the penultimate line in the code block above) branches to the beginning of the loop, thus continuing the loop.

• Issola by Steven Brust:

  [spoiler] The Jenoine, the alien species that created Dragaerans and who once ruled the earth, kidnap Morrolan and Aliera in order to try to get Vlad to kill Verra. This turns out to be part of a bigger plan to use the earth’s Lesser Sea of Chaos to create their own Orb. Lady Teldra gets killed in a battle between gods and Jenoine, and Spellbreaker turns into a Great Weapon where Lady Teldra lives on. [/spoiler]

• Open Borders by Bryan Caplan and Zach Weinersmith: a comic book advocating for open borders. So good it makes you wonder why there aren’t more non-fiction comic books(or graphic novels or whatever you want to call them)– I found myself thinking of Scott McCloud’s Understanding Comics often while reading this book.

  Besides the excellent use of the medium, Caplan makes a compelling case for opening up borders and addresses many common arguments against immigration. The book even acknowledges how opening up borders completely is a radical idea and argues that it’s still worth making a case for it.

• Dzur by Steven Brust: Tenth book in the series. Early in the series, you do begin to notice that all the books follow a certain pattern, but this one felt a bit anti-climactic.

  I also realized that the Vlad Taltos books have comprised most of the fiction reading I’ve done this year. Which is just as well, they’re good books but I’ll try to read other things next year.

Of late, my main side project has been rug, a stripped-down Git implementation which I’m building in Rust. I’m following along James Coglan’s excellent book Building Git where he lays out how he went about building the same project, in Ruby.

In essence, my project boils down to porting James’s code¹ into Rust. But why bother with this at all? After all, porting code from one language to another is probably not on your top ten list of cool project ideas. Building something new will always be exciting. But I do think that at least as far as personal projects are concerned, porting a piece of code gets a bad rap. They can be a great learning experience and while it may not match the thrill of starting something afresh, can be plenty exciting to work on.

Working to re-write a piece of software in another language is a great way to dive deep into how the project works. With Git, you learn how the files, directories and commits in a repo are stored as objects, what happens as you are staging each hunk of your work and how diffing works. And so much more. To be sure, you could read an article or watch a video explaining how any of these things work but grappling with actual code to implement a functionality will give you a far superior understanding of things.

Besides the technical nuances of the software’s functionality, porting code will also expose you to how the project itself is architected. What are the entities the project deals with and what is the high-level structure of the project? What layers are there and why is it layered this way and not some other way? These are problems you will face when working on your own personal and professional projects. Choosing a well-designed system to study and port can give you some new perspectives on how to think about such things.

Translating a project from one language to another can also be a great opportunity to get acquainted with a new language. I had done some Rust before working on rug but this project has been large enough that I’ve been able to go deeper into both the language and the ecosystem. For example, the last two days I’ve been working on replacing the ad-hoc CLI argument parsing code with a wonderful Rust library called clap. With Rust, there are plenty of new concepts, and sometimes it just takes some practice using it to get used to the language.

Hopefully, I’ve convinced you that choosing to port a piece of software as your next programming side-project is at least worth considering. As I said earlier, building something entirely new has it’s thrills. But diving into a codebase and understanding it deeply enough to be able to port it to another language can also be immensely satisfying.

When you run git diff on a project where you’ve made more than a screenful of changes, the output is automatically redirected to a pager and you can browse through your changes using the familiar less interface. This post shows a minimal example piping output to less.

To achieve this, git creates a pipe and spawns a new process, whose purpose is to exec the pager.

int fds[2];
if (pipe(fds) == -1) {
  perror_die("pipe");
}
int child_pid = fork();

Let’s start by looking at the parent process, even though in the code this case is handled last. The STDOUT of the parent process is aliased to the write end of the pipe, so any further printing in the parent process writes stuff to fds[WRITE_END]. Once we’re done, we close the write end of the pipe to signal EOF to the child process.

We wait for the child process to exit since otherwise control returns to the shell.

switch (child_pid)
// ...
  default: { /* Parent */
    /* STDOUT is now fds[WRITE_END] */
    dup2(fds[WRITE_END], STDOUT_FILENO);
    /* parent doesn't read from pipe */
    close(fds[READ_END]);

    /* "Business" logic which determines what to actually print */
    int num_lines = 1024;
    if (argc > 1) {
      num_lines = atoi(argv[1]);
    }
    print_n_lines(num_lines);


    fflush(stdout);

    /* Signal EOF to the pager process */
    close(STDOUT_FILENO);

    int stat_loc;
    waitpid(child_pid, &stat_loc, 0);
    break;
  }

The STDIN of the new process is aliased to the read end of the pipe. Anything being printed in the parent process is thus now an input to the pager process. After setting up STDIN, this process runs less.

switch (child_pid) {
case 0: {    /* Child(pager) */
    /* Pager process doesn't write to pipe */
    close(fds[WRITE_END]);

    /* Make READ_END of pipe pager's STDIN */
    dup2(fds[READ_END], STDIN_FILENO);

    /* F -> quit-if-one-screen */
    /* R -> preserve color formatting */
    /* X -> don't send some special instructions eg. to clear terminal screen before starting */
    char *less_argv[] = {"less", "-FRX", NULL};
    int exec_status = execvp(less_argv[0], less_argv);

    fprintf(stderr,
            "execvp failed with status: %d and errno: %d\n", exec_status, errno);
    break;
  }
  
// ...
} // switch

The full example can be found in this gist. You can also check out the Ruby and Rust implementations of this.