chipx86

/*
 * ES6 classes have what may be considered unexpected behavior when
 * working with constructors. A parent class's constructor can invoke
 * a method in a subclass, but that method can't access its class's
 * own variables.
 *
 * For example, this fails:
 *
 *     class Parent {
 *         // To be provided by subclasses.

chipx86

/*
 * Layer 1: Button structure factory
 */

#cs-ns-widget-structures() {
  /**
   * Mixins for creating button structures.
   */
  .button() {
    /**

chipx86

"""Find the earliest available version of a list of Python dependencies.

This takes dependencies on the command line (package names with or without
version specifiers), looks up each in PyPI, and outputs a new list of
dependencies that specify the earliest version in each range.

See https://twitter.com/simonw/status/1473441058667130881 for the reason for
this script.

Example:

chipx86

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#define __file__ __FILE__

#define import void*
#define def int
import codecs;
import os;

chipx86

#!/usr/bin/env python
from __future__ import unicode_literals

import gc
import os
import sys
import psutil
import time
from io import BytesIO

chipx86

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Friday, May 22, 2015 - 23:33:00 PST

In order to improve the security around my PGP key, and the strength of the key
itself, I've chosen to build a new key and revoke the old one. The old key will
continue to work, but you should be using my new key instead. If anyone has
signed the old key, I'd appreciate signing the new one.

chipx86

Keybase proof

I hereby claim:

• I am chipx86 on github.
• I am chipx86 (https://keybase.io/chipx86) on keybase.
• I have a public key whose fingerprint is 17C3 9283 C77B B425 A56B CA10 72A5 1C32 9417 B5D2

To claim this, I am signing this object:

chipx86

#
# This file contains a list of AMIs that we'll reference throughout our
# templates.
#
# We keep track of the baseline AMIs (Amazon Linux) we use to build clean
# images for our servers. We also keep track of "delta" images (AMIs last
# generated for a particular server image), which we'll bootstrap new
# deployments from.
#
# Note how we're using variable references within the file to avoid repeating

chipx86

#!/usr/bin/env python
#
# Building a tar file chunk-by-chunk.
#
# This is a quick bit of sample code for streaming data to a tar file,
# building it piece-by-piece. The tarfile is built on-the-fly and streamed
# back out. This is useful for web applications that need to dynamically
# build a tar file without swamping the server.
import os
import sys