View travis-deploy-notes.md
  • 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/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)
View grad.py
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):
View gist:56a87cd1675d037c1d228c33db359c9f
New summary by @ezyang.
The goal of this task is to add a new command `Setup doctest`, which runs the doctest command on all of the modules of each component in a package, in much the same way `Setup haddock` runs `haddock` on all the modules of each component in a package.
There are a number of steps to implementing this:
1. You have to add the boilerplate for setting doctest up as a new command. Grepping for occurrences of haddock should give you an idea for what you have to edit; the key files are `Cabal/Distribution/Simple/Setup.hs`, adding a case to `defaultMainHelper` in `Cabal/Distribution/Simple.hs`, and a new file to actually contain the logic. I'd recommend against putting too many flags into `DoctestFlags` when starting off.
2. The overall logic of the driver should be something like this:
View .vimrc
" https://github.com/tpope/vim-pathogen
" Pathogen is good because you can keep plugins together in logical
" units, without blasting them throughout your directory structure.
execute pathogen#infect()
" 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...
View render.md

| Str.String| Str.Text| Str.Text.Lazy ---| ---| ---| --- Str | ✔| ✔| ✔ Chr | ✔| ✔| ✔ Index | ✔| ✔| ✔ empty | ✔| ✔| ✔ singleton | ✔| ✔| ✔ pack | ✔| ✔| ✔ unpack | ✔| ✔| ✔ cons | ✔| |

View haskell-on-windows.md

Haskell on Windows

These are empirical observations about running Haskell on Windows. If your experiences have been different, I'd love to hear about it.

Install

You'll need to get the

View building.rst

In Backpack, we both typecheck packages with holes (producing only interface files) and compile fully instantiated packages (producing interface files and object files). While doing this, we try to minimize the amount of work the compiler does. In particular:

  1. Any package with holes is typechecked exactly once, in its most general form (with no instantiations). Partially instantiated packages are never typechecked; instead, we just rename the most general interfaces according to the instantiation "on the fly."
View GhcSort.hs
module GhcSort where
import GHC
import GhcPlugins
import DriverPhases
import Control.Monad
import Data.List
import Data.Maybe
import System.FilePath
View ghc-make.rst

How ghc --make works

In abstract, the job of ghc --make is very simple: compute a dependency graph between modules, and rebuild the ones that have changed. Unfortunately, the code in GhcMake is quite a bit more complicated than that, and some of this complexity is essential to the design of GHC:

  • Interaction with GHCi involves mutating process-global state.