ErikAugust

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#ifdef _MSC_VER
#include <intrin.h> /* for rdtscp and clflush */
#pragma optimize("gt",on)
#else
#include <x86intrin.h> /* for rdtscp and clflush */
#endif

ferd

Originally from: http://erlang.org/pipermail/erlang-questions/2017-August/093170.html

For a safe and fast Erlang SSL server, there's a few 
configuration values you might want by default:

    [{ciphers, CipherList},      % see below
     {honor_cipher_order, true}, % pick the server-defined order of ciphers
     {secure_renegotiate, true}, % prevent renegotiation hijacks
     {client_renegotiation, false}, % prevent clients DoSing w/ renegs
     {versions, ['tlsv1.2', 'tlsv1.1']}, % add tlsv1 if you must

jsdf

const immutableJSFormatter = {
  header(x) {
    if (x && x.toJS) return ['span', {}, x.toString()];
    return null;
  },
  hasBody(x) {
    return x && x.toJS;
  },
  body(x) {
    return ['span', {}, JSON.stringify(x.toJS(), null, 2)];

cemerick

(ns whatever.cljs
  (:require [cljs.compiler :refer (munge)])
  (:refer-clojure :exclude (munge defonce)))

(defmacro defonce
  [vname expr]
  (let [ns (-> &env :ns :name name munge)
        mname (munge (str vname))]
    `(when-not (.hasOwnProperty ~(symbol "js" ns) ~mname)
       (def ~vname ~expr))))

cmeiklejohn

• CRDTs
  • What are CRDTs?
• Vector clocks
  • How do these related to dotted version vectors?
• Causal consistency
  • CAC proof
• Rack awareness and multi-data center deployments
  • What is this?
  • Why is this important?
• Wait-free synchronization

taliesinb

Equal
SameQ
MatchQ
MemberQ
Take
Drop
Head
Most
Rest
Part

KonTrax

#### ALL CLASSES
# Unsorted at the moment
|===========================|======|==================|====================|=================|========|==================|
|           CLASS           | TYPE |    ATTRIBUTES    |     PROPERTIES     | FONT.PROPERTIES | LAYERS | LAYER.PROPERTIES |
|===========================|======|==================|====================|=================|========|==================|
| auto_complete             |      |                  | row_padding        |                 | layer0 | tint             |
|                           |      |                  | dark_content       |                 |        | opacity          |
|---------------------------|------|------------------|--------------------|-----------------|--------|------------------|
| auto_complete_label       |      |                  | fg                 |                 |        |                  |
|                           |      |                  | match_fg           |                 |        |                  

pbailis

A friend asked me for a few pointers to interesting, mostly recent papers on data warehousing and "big data" database systems, with an eye towards real-world deployments. I figured I'd share the list. It's biased and rather incomplete but maybe of interest to someone. While many are obvious choices (I've omitted several, like MapReduce), I think there are a few underappreciated gems.

###Dataflow Engines:

Dryad--general-purpose distributed parallel dataflow engine
http://research.microsoft.com/en-us/projects/dryad/eurosys07.pdf

Spark--in memory dataflow
http://www.cs.berkeley.edu/~matei/papers/2012/nsdi_spark.pdf

kevsmith

-module(bench).

-export([run_suite/3, run/1]).

run_suite(Name, Passes, Messages) ->
    Results = run_suite1(Passes, Messages, []),
    Avg = lists:sum(Results) / Passes,
    StdDev = math:sqrt(lists:sum([math:pow(X - Avg, 2) || X <- Results]) / Passes),
    Summary = [{avg, Avg}, {stddev, StdDev}, {min, lists:min(Results)},
               {max, lists:max(Results)}],

pbailis

RapGenius has an interesting post about Heroku's randomized load balancing, complaining about how random placement degrades performance compared to prior omniscient approaches. RapGenius ran some simulations, including an experiments with a "Choice of Two" method:

Choice of two routing is the naive method from before, with the twist that when you assign a request to a random dyno, if that dyno is already busy then you reassign the request to a second random dyno, with no regard for whether the second dyno is busy

This differs subtly but substantially from the standard "Power of Two Choices" randomized load balancing:

each [request] is placed in the least loaded of d >= 2 [Dynos] chosen independently and uniformly at random

Take a look at the difference in queue lengths below, for 200 Dynos, 100