View tensor-type-prototype.cpp
#include <cstdint>
// Placeholder for asserts; ignore them for now
#define AT_ASSERT(cond, ...)
// ArrayRef (comes from LLVM, ATen uses it, we think it's pretty good)
//===--- ArrayRef.h - Array Reference Wrapper -------------------*- C++ -*-===//
// The LLVM Compiler Infrastructure

Formulas which explain themselves

Your goal is to write an AnnotatedBool class which behaves like a plain boolean, but also has the ability to print out an explanation of how the boolean was computed. The class needs to support:

  • Function var(string, bool), which takes a variable name and a boolean setting
  • Operator AnnotatedBool && AnnotatedBool, which ANDs two bools together
  • Operator AnnotatedBool || AnnotatedBool, which ORs two bools together
  • Implicit conversion to bool, which gives the concrete boolean value of the expression
  • Method explain(), which returns an HTML string which explains how the boolean value of the expression was computed
View .vimrc
" Make, but with a few improvements: write before we try it, suppress
" the output (it's going to show up in the quickfix buffer) and induce
" a redraw, because some output might leak out anyway
map m :w<CR>:silent make<CR>:redraw!<CR>
" Make the quickfix buffer only three lines high, so we conserve screen estate
au FileType qf call AdjustWindowHeight(3, 6)
function! AdjustWindowHeight(minheight, maxheight)
let l = 1
let n_lines = 0
View cabal-file-format.rst

The Cabal file format

This document is a comprehensive reference manual for the Cabal file format.

Common formats

Version range

View .vimrc
" This just turns on per-filetype plugins. Vim ships with file
" indentation/plugin/syntax rules for highlighting. The highlighting
" is nice. Sometimes the indentation is a bit annoying though because
" it REINDENTS my stupid code when I didn't want it to. It's annoying
" to track down why it's doing that...
filetype indent on
filetype on
filetype plugin on
" This MUST be before highlight comment, see
View accepted-by-osx-clang.cpp
#include <tuple>
struct T {};
void f(const std::tuple<T, T>&) {}
void g(T& x) {
View gist:c8b307f6109da965a99c539042eb3ee0
mlstm(43): 108.806 msecs
mlstm(44): 108.450 msecs
mlstm(45): 109.188 msecs
mlstm(46): 108.555 msecs
mlstm(47): 108.345 msecs
mlstm(48): 108.452 msecs
mlstm(49): 108.334 msecs
mlstm(50): 137.128 msecs
mlstm(51): 147.267 msecs
mlstm(52): 150.047 msecs
View test.cpp
#include <pybind11/pybind11.h>
#include <iostream>
namespace py = pybind11;
int main() {
auto gil = PyGILState_Ensure();
PyObject *l = PyFloat_FromDouble(3.14);
//PyObject *l = PyBytes_FromString("foo");
auto n = py::cast<py::bytes>(l);
std::cerr << "No problem yet...\n";
  • Matrix DOES work with deploy; deploy gets run for each matrix entry, environment variables carry over
  • Non-tag releases behave strangely: Travis creates an "untagged" tag for each matrix entry (so you end up with multiple tags), and each show up as separate releases
  • If you tag the release, each matrix entry gets bundled up in the same release. Untagged releases and draft releases get done separately.

Conclusion: do tagged releases only

  • Bash condition is useful; you can use this to distinguish between matrix entries. This can help you filter out non-release matrix entries.

Is it a good idea to put the release build script and the regular build script together? You might think to create separate matrix entries for release and non-release.

  • Problem: you can't "disable" matrix builds conditionally: everything in the matrix always runs
View word.diff
diff --git a/word_language_model/ b/word_language_model/
index c4ea458..7ff9b61 100644
--- a/word_language_model/
+++ b/word_language_model/
@@ -81,6 +81,8 @@ test_data = batchify(corpus.test, eval_batch_size)
ntokens = len(corpus.dictionary)
model = model.RNNModel(args.model, ntokens, args.emsize, args.nhid, args.nlayers, args.dropout, args.tied)
+import torch.jit
+model = torch.jit.verify_model(model)