ezyang

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

ezyang

" 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

ezyang

The Cabal file format

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

Common formats

Version range

ezyang

" 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
" https://github.com/Valloric/YouCompleteMe/issues/2664

ezyang

#include <tuple>

struct T {};

void f(const std::tuple<T, T>&) {}

void g(T& x) {
  f(x);
}

ezyang

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

ezyang

#include <pybind11/pybind11.h>
#include <iostream>
namespace py = pybind11;
int main() {
  Py_Initialize();
  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";

ezyang

• 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

ezyang

diff --git a/word_language_model/main.py b/word_language_model/main.py
index c4ea458..7ff9b61 100644
--- a/word_language_model/main.py
+++ b/word_language_model/main.py
@@ -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)

ezyang

import torch
from torch.autograd import Variable, Function
import torch._C as _C
import sys
        
class Add(Function):
    def forward(self, a, b):
        return a.add(b)

    def backward(self, grad_output):