cchandler

cchandler

#
# Automatically generated file; DO NOT EDIT.
# crosstool-NG  Configuration
#
CT_CONFIGURE_has_cxx11=y
CT_CONFIGURE_has_lzip=y
CT_CONFIGURE_has_curl=y
CT_CONFIGURE_has_make_3_81_or_newer=y
CT_CONFIGURE_has_make_4_0_or_newer=y
CT_CONFIGURE_has_libtool_2_4_or_newer=y

cchandler

#!/bin/bash

set -x

OUTPUT_DIR=`pwd`
LLVM_HOME=/usr/local/Cellar/llvm/8.0.0/
RUSTUP_TOOLCHAIN_LIB=/Users/chris/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib
cargo rustc --verbose -- -v -C save-temps --emit=llvm-ir

cd target/debug/deps

cchandler

extern crate clokwerk;
extern crate log;

use clokwerk::{Scheduler, TimeUnits};
use std::thread;
use std::time::Duration;
use log::{info, trace, warn};

fn main() {
    simple_logger::init().unwrap();

cchandler

#!/bin/bash

set -x

OUTPUT_DIR=`pwd`
LLVM_HOME=/usr/local/Cellar/llvm/8.0.0/
RUSTUP_TOOLCHAIN_LIB=/Users/chris/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib

# Build main with temporary files preserved and emit LLVM-IR
rustc -C save-temps --emit=llvm-ir main.rs

cchandler

fn main() {
    println!("Hello!");
}

cchandler

If I were going to expand on the point, it's not that testing in production is good or desirable, but rather that
the long-tail of eventualities+inputs real-world code will face over time is not "testable" in the classic sense.
There's no unit/integration test for "a chiller failed in the datacenter and half my servers are exhibiting heat-related failure"
or "this particular version of linux in production has a probabilistic XFS locking bug that kills my thread"

To be crystal clear, I am in no way advocating _against_ unit or integration testing. I think both are critical. I am just also
cognizant of how complex things breakdown over time. I'm thinking of operational maturity as how well an organization writes
software to embrace the certainty of failure and improve telemetry/introspectibility to deal with said disaster.

cchandler

/*
Sometimes you get bored on flights between MDW and SFO and decide
to explore numerical drift and round off errors in doubles. 
Here's the difference between a linear fold over a list and 
using pyramidal/tree folds.

Theoretically the tree-like fold would minimize round-off error
as the operation propagates up the tree, but I'd need to double
check my numerical methods stuff to be sure :-).

cchandler

module Projection
  MAP_WIDTH = [128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072, 262144, 524288, 1048576, 2097152, 4194304, 8388608, 16777216, 33554432, 67108864, 134217728, 268435456, 536870912, 1073741824, 2147483648, 4294967296, 8589934592, 17179869184, 34359738368, 68719476736, 137438953472]
  LNG_SCALE_AT_ZOOM = [0.7111111111111111, 1.4222222222222223, 2.8444444444444446, 5.688888888888889, 11.377777777777778, 22.755555555555556, 45.51111111111111, 91.02222222222223, 182.04444444444445, 364.0888888888889, 728.1777777777778, 1456.3555555555556, 2912.711111111111, 5825.422222222222, 11650.844444444445, 23301.68888888889, 46603.37777777778, 93206.75555555556, 186413.51111111112, 372827.02222222224, 745654.0444444445, 1491308.088888889, 2982616.177777778, 5965232.355555556, 11930464.711111112, 23860929.422222223, 47721858.844444446, 95443717.68888889, 190887435.37777779, 381774870.75555557, 763549741.5111111]
  LAT_SCALE_AT_ZOOM = [40.74366543152521, 81.48733086305042, 162.97466172610083,

cchandler

module ChrisScope
  def self.included(base)
    base.extend(ClassMethods)
  end
end

module ClassMethods
  define_method(:color, lambda {puts "Hello"})
end