Skip to content

Instantly share code, notes, and snippets.

Caleb Meredith calebmer

Block or report user

Report or block calebmer

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
View PostVirtualizedComments.tsx
import {
} from "react-native";
import {Font, Space} from "../atoms";
View 00-GroupTable.ts
import {AccountID, GroupID, PostID} from "@connect/api-client";
import {GroupMemberTable} from "./GroupMemberTable";
import {PGTable} from "../pg/PGTable";
import {PGType} from "../pg/PGType";
export const PostTable = PGTable.define({
name: "post",
columns: {
id: as PGType<PostID>,
group_id: as PGType<GroupID>,
View SQL.ts
// Heavily inspired by my (Caleb’s) old [`pg-sql`][1] module. Updated now that
// I’ve learned a thing or two. Main differences include:
// - A more efficient implementation.
// - Symbol stamps to avoid SQL injection attacks using JSON.
// Also takes inspiration from Benjie’s fork, [`pg-sql2`][2].
// [1]:
// [2]:
View proof.txt
∀(∅) ∀b.T b ⊑ ∀b.T b
───────────────────────── (Eq-Free)
∀(∅) ∀(b, b).T b ⊑ ∀b.T b
───────────────────────── (R-Context)
∀(b) ∀b.T b ⊑ T b
─────────────────────────────────────── (I-Context)
∀(b) ∀(a ≥ ∀b.T b).T a ⊑ ∀(a ≥ T b).T a
───────────────────────────────────────────── (R-Context)
∀(∅) ∀(b, a ≥ ∀b.T b).T a ⊑ ∀(b, a ≥ T b).T a
───────────────────────────────────────────── (Eq-Free)
View bad-component.js
function MyComponent() {
// 40 conditions
if (c) {} else {}
if (c) {} else {}
if (c) {} else {}
if (c) {} else {}
if (c) {} else {}
if (c) {} else {}
if (c) {} else {}
if (c) {} else {}
View .bash_profile
export PS1="\[\033[0m\]\W \[\033[00;95m\]❯\[\033[0m\] "
# export EDITOR="code -r"
export CLICOLOR=1
export TERM=xterm-color
function nm_notify_done() {
if [ $previous -eq 0 ]; then
osacript -e "display notification \"Done\" with title \"Node Modules Install\"";
View proof.txt
fresh(a') fresh(s')
(row-var) ─────────────────────────────────────────
s ≃ { p: a' | s' } : [s ↦ { p: a' | s' }] q ≠ p a ∉ ftv(a') r ∉ ftv({ q: b | s' })
(row-swap) ─────────────────────────────────────────────────────────────── (uni-varl) ───────────────── (uni-varl) ───────────────────────────────────────
{ q: b | s } ≃ { p: a' | { q: b | s' } } : [s ↦ { p: a' | s' }] a ∼ a' : [a ↦ a'] r ∼ { q: b | s' } : [r ↦ { q: b | s' }]
(uni-row) ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
{ p: a | r } ∼ { q: b | s } : [r ↦ { q: b | s' }, s ↦ { p: a | s' }]

In this case, it looks like TypeScript unifies the function type parameters. Flow does not unify function type parameters. Instead Flow defines “bounds” for function type parameters. Which is the more expressive choice when type-checking JavaScript.

Consider the following function:

function choose<T>(a: T, b: T): T {
  return Math.random() > 0.5 ? a : b;
calebmer /
Last active Dec 8, 2017
Tiny GraphQL Client Ideas



  1. The client must help create applications that are very small. This means not only should the runtime be small, but also the query artifacts that will be included in the bundle. Including the entire query AST could be counter to this goal. Other options are only including the query text, or only including a query identifier (persisted queries) in the bundle.
  2. In order to serve the first principle queries must be statically defined outside of JavaScript. GraphQL AST “selection sets” should be transformed into minimal viable data shape representations to inform the client. These transformed “data shapes” can be imported and used by the client.
  3. Static type checking of query data should be a feature of the client and not an afterthought. GraphQL is statically typed after all. Since we are building query files, and importing the built artifcats adding types should be easy.
  4. Data from newer queries must be merged with data from older queries automatically so the UI stays consistent.
calebmer /
Created Nov 7, 2016
Caleb’s Open Source Software Feature Wishlist

Caleb’s Open Source Software Feature Wishlist

Every once and a while there will be a feature in open source software that I (Caleb) want, but needs a PR to implement. This document is a collection of issues around such features. This list is to track such features and allow me, or others, to find issues to fix whenever the time and interest arises.

Some issues will be easier than others, but hopefully all are more then possible given an afternoon. Ideally the issue has enough context to get rolling.

You can’t perform that action at this time.