As configured in my dotfiles.
start new:
tmux
start new with session name:
Latency Comparison Numbers (~2012) | |
---------------------------------- | |
L1 cache reference 0.5 ns | |
Branch mispredict 5 ns | |
L2 cache reference 7 ns 14x L1 cache | |
Mutex lock/unlock 25 ns | |
Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
Compress 1K bytes with Zippy 3,000 ns 3 us | |
Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
As configured in my dotfiles.
start new:
tmux
start new with session name:
# Hello, and welcome to makefile basics. | |
# | |
# You will learn why `make` is so great, and why, despite its "weird" syntax, | |
# it is actually a highly expressive, efficient, and powerful way to build | |
# programs. | |
# | |
# Once you're done here, go to | |
# http://www.gnu.org/software/make/manual/make.html | |
# to learn SOOOO much more. |
#pragma once | |
#define DYN_ARR_OF(type) struct { \ | |
type *data; \ | |
type *endptr; \ | |
uint32_t capacity; \ | |
} | |
#if !defined(__cplusplus) | |
#define decltype(x) void* |
<?xml version="1.0" encoding="UTF-8"?> | |
<!DOCTYPE language SYSTEM "language.dtd"> | |
<!-- | |
Kate SCSS syntax highlighting definition | |
Modified the Kate CSS syntax highlighting definition to support SCSS. | |
This file should be merged with any updates to the normal Kate CCS definition (see note on version numbering in changelog for 1.2.03.0). | |
The latest version of this file can be found at https://gist.github.com/958598 |
State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?
There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.
Here I present a composable pattern for pure state machiness with effects,
/** | |
* @file fsm.c | |
* @brief an implementation for a FSM in C, this file contains | |
* implementation of definations. | |
* License GPLv3+ | |
* @author Ankur Shrivastava | |
*/ | |
#include "fsm.h" | |
#include<stdlib.h> |
This post also appears on lisper.in.
Reader macros are perhaps not as famous as ordinary macros. While macros are a great way to create your own DSL, reader macros provide even greater flexibility by allowing you to create entirely new syntax on top of Lisp.
Paul Graham explains them very well in [On Lisp][] (Chapter 17, Read-Macros):
The three big moments in a Lisp expression's life are read-time, compile-time, and runtime. Functions are in control at runtime. Macros give us a chance to perform transformations on programs at compile-time. ...read-macros... do their work at read-time.
/* file: "tinyc.c" */ | |
/* originally from http://www.iro.umontreal.ca/~felipe/IFT2030-Automne2002/Complements/tinyc.c */ | |
/* Copyright (C) 2001 by Marc Feeley, All Rights Reserved. */ | |
#include <stdio.h> | |
#include <stdlib.h> | |
#include <string.h> | |
/* |
(ns simple-compojure.core | |
(require | |
[ring.adapter.jetty :refer [run-jetty]] | |
[ring.middleware.params :as p] | |
[simple-compojure.middleware :as m] | |
[simple-compojure.routes :as r] | |
)) | |
(def app | |
(-> r/routes |