Verify Permissions
diskutil verifyPermissions /
Repair Permissions
diskutil repairPermissions /
... or Why Pipelining Is Not That Easy
Golang Concurrency Patterns for brave and smart.
By @kachayev
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
// Let's define a basic Swift class. | |
class Fruit { | |
var type=1 | |
var name="Apple" | |
var delicious=true | |
} | |
// We can get at some info about an instance of an object using reflect(), which returns a Mirror. | |
reflect(Fruit()).count | |
reflect(Fruit())[1].0 |
(ns three.demo) | |
(def THREE js/THREE) | |
(def camera (THREE.PerspectiveCamera. 75 (/ (.-innerWidth js/window) | |
(.-innerHeight js/window)) 1 10000)) | |
(set! (.-z (.-position camera)) 1000) | |
(def scene (THREE.Scene.)) | |
(def geometry (THREE.CubeGeometry. 200 200 200)) | |
(def obj (js/Object.)) | |
(set! (.-color obj) 0xff0000) | |
(set! (.-wireframe obj) true) |
RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.
On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.
So, many developers have started going straight t
ClojureScript does not have a standalone macro system. To write ClojureScript macros, one must write them in Clojure and then refer to them in ClojureScript code. This situation is workable, but at a minimum it forces one to keep ClojureScript code and the macros it invokes in separate files. I miss the locality of regular Clojure macros, so I wrote something called maptemplate
that gives me back some of what I miss. The technique may be useful in other scenarios.
Suppose you're wrapping functionality in another namespace or package so that you can have your own namespace of identically named but otherwise decorated functions:
ClojureScript:
Steps to install and run PostgreSQL 9.2 using Homebrew (Mac OS X) | |
(if you aren't using version 9.1.5, change line 6 with the correct version) | |
1. launchctl unload -w ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist | |
2. mv /usr/local/var/postgres /usr/local/var/postgres91 | |
3. brew update | |
4. brew upgrade postgresql | |
5. initdb /usr/local/var/postgres -E utf8 | |
6. pg_upgrade -b /usr/local/Cellar/postgresql/9.1.5/bin -B /usr/local/Cellar/postgresql/9.2.0/bin -d /usr/local/var/postgres91 -D /usr/local/var/postgres | |
7. cp /usr/local/Cellar/postgresql/9.2.0/homebrew.mxcl.postgresql.plist ~/Library/LaunchAgents/ |
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 |
;; | |
;; NS CHEATSHEET | |
;; | |
;; * :require makes functions available with a namespace prefix. | |
;; | |
;; * :use makes functions available without a namespace prefix | |
;; (i.e., refers functions to the current namespace). | |
;; | |
;; * :import refers Java classes to the current namespace. | |
;; |