mitchellh

I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I've typed up this response so many times that I've decided to just put it in a gist so I can reference it whenever it comes up again.

I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who says any particular strategy is the right answer 100% of the time is wrong, but I think there is considerable acceptable leeway in when you use each. What follows is my personal and professional opinion:

Hirrolot

(* The syntax of our calculus. Notice that types are represented in the same way
   as terms, which is the essence of CoC. *)
type term =
  | Var of string
  | Appl of term * term
  | Binder of binder * string * term * term
  | Star
  | Box

and binder = Lam | Pi

evancz

module Hints exposing (..)

import List
import Html exposing (..)
import Html.Attributes as A

{-----------------------------------------------------------

      SYNTAX HINTS (OCaml -> Elm)

stedolan

module Int64Array : sig
  module Array : sig
    type t
    val create_uninitialised : int -> t
    val get : t -> int -> int64
    val set : t -> int -> int64 -> unit
    val unsafe_get : t -> int -> int64
    val unsafe_set : t -> int -> int64 -> unit
  end
end = struct

ryyppy

ReasonReact + useReducer hooks

This Gist is based on a tweet & blog post by Prateek Pandey on how to use a record based reducerComponent with ReasonReact : https://blog.theporter.in/reason-react-component-29fbffd784d6

It's based on the old record API, so I wanted to make an example which uses the newest ReasonReact API which is based on React hooks. IMO the hooks based API is much more lightweight and easier to understand. You can find more infos about it in the official ReasonReact docs.

Below you will find a similar solution to the Loadable state tracking as described in the blog post. The first example shows state tracking via a reducer (useReducer), the second example shows a more simplistic version with useState (the one I would prefer for this sp

dustypomerleau

An introduction to alternative keyboard layouts

This is a post to satisfy your curiosity about alternative keyboard layouts, why some people use them, and whether they're for you. It is intended to discuss the topic in broad terms, but I will share my personal preferences towards the end. Due to time constraints and my own limited knowledge, I will focus on layouts optimized for the English language (ANSI variants, with an occasional nod to ISO).

First off, it's important to understand how much debate there is about how we got here: I will not even attempt to settle the issue of who invented the 'first' typewriter layout, because the modern device had many predecessors going back centuries. The usual legend of typewriter evolution holds that American Christopher Latham Sholes debuted the typewriter in 1868 with a 2-row layout that was (nearly) alphabetical. A horizontal stagger between the rows made room for the lever arms attached to each key:

 3 5 7 9 N O P Q R S T U V W X Y Z
2 4 6 8 . A B C D E

lattner

Swift Concurrency Manifesto

Author: Chris Lattner

Chinese Translation by Jason Yu

Contents

• Introduction
• Overall Vision

rneswold

open Lwt.Infix

exception Source_terminated

type 'a node = N of ('a * 'a node Lwt.t)

type 'a t = 'a node Lwt.t

let push ref_waker v =
  let new_node, new_waker = Lwt.wait () in

itod

• Kinesis Freestyle (Terrible key switches. Mushy and un-lovable)

• Kinesis Freestyle Edge (Traditional layout with too many keys, mech switches, proably too big to be tented easily/properly)

• Matias Ergo Pro (Looks pretty great. Have not tried.)

• ErgoDox Kit (Currently, my everyday keyboard. Can buy pre-assembled on eBay.)

• ErgoDox EZ (Prolly the best option for most people.)

aisamanra

#include <stdio.h>

typedef struct {
	int tag;
	union {
		int l;
		struct {
			char* fst;
			float snd;
		} r;