| #!/usr/bin/env bash | |
| ## FIXME: This hasn’t been tested yet – it’s just a sketch. | |
| ## `git best-merge` implements the ideal merge strategy. | |
| ## | |
| ## This will fast-forward _only_ when the branch contains a single commit with | |
| ## no conflicts. In all other cases, it will create a merge commit. | |
| ## | |
| ## __NB__: Regardless of any flexibility provided by `git merge`, the last |
| let -- The `Type` argument is needed so Dhall will let this be a `Kind`. | |
| Anc = | |
| < Abs | Rel : Type > : Kind | |
| let -- `merge` works a the type level just fine | |
| Parents | |
| : Anc → Type | |
| = λ(anc : Anc) → merge { Abs = {}, Rel = λ(_ : Type) → Natural } anc | |
| let -- `assert : {} ≡ Parents.Anc.Abs`, but Dhall doesn’t compare types |
| #!/usr/bin/env bash | |
| set -euo pipefail | |
| IFS=$'\n' | |
| ## Deletes branches (both local and remote) that have been merged upstream. | |
| function usage () { | |
| echo "Usage:" | |
| echo | |
| echo " $(basename "${BASH_ARGV0}") [-h] [-b DEFAULT_BRANCH] [-u UPSTREAM] [-o ORIGIN]" |
| ;; Adapted from jwiegley/use-package#881 and jwiegley/use-package#899. | |
| (defun custom-pseudo-theme-set-variables (theme &rest args) | |
| "This is a utility for managing custom values “outside of” a theme." | |
| (unless (memq theme custom-known-themes) | |
| (custom-declare-theme theme (custom-make-theme-feature theme))) | |
| (prog1 | |
| (apply #'custom-theme-set-variables | |
| theme | |
| (let ((comment-addendum (format "(Customized by %s.)" theme))) | |
| (mapcar |
There is a lot to Nix. We’re not going to get into it here. If you are interested, there is a lot of documentation to explore. For our purposes Nix is a tool that allows you to contribute to a project that uses a development ecosystem you are not invested in.
While there is some initial setup, you don’t need to become invested in Nix to benefit from this aspect of it.
I use git worktrees a lot, and I’ve been annoyed by the repo itself having effectively a privileged worktree that’s always there (and refuses to let any other worktree check out the branch it’s on). And then not having a good place to put my other worktrees. If I clone to $PROJECTS/this-project, where do I put my worktrees?
foo and foo-charts, it’s easy to forget that foo-charts isn’t just a worktree of foo.So, my projects tended to look like this:
$PROJECT_DIR
├── my-project # a repo
│ ├── .git
│ └── ... # but also a working tree
| -- step> | |
| (abst @ (Pair a) ($fHasRepPair @ a)) | |
| `cast` (Sub (D:R:RepPair[0] <a>_N) ->_R <Pair a>_R | |
| :: Coercible (Rep (Pair a) -> Pair a) ((a, a) -> Pair a)) | |
| -- result> | |
| . @ (->) | |
| $fCategory-> | |
| @ (Pair a) | |
| @ (Pair a) | |
| @ (a, a) |
| -- This illustrates (most of) a new(?) encoding of ad-hoc polymorphism using | |
| -- dependent types and implicits. | |
| -- | |
| -- Benefits of this approach: | |
| -- • can have multiple “ambiguous” instances without requiring things like | |
| -- Haskell’s newtypes to distinguish them; | |
| -- • can disambiguate instances with minimal information, rather than having to | |
| -- know some arbitrary instance name as you would with a system like Scala’s | |
| -- implicits; | |
| -- • implementers don’t need to know/provide the full family of instances – they |
| module OpClassesRepro | |
| record SemigroupRec (t : Type) (op : t -> t -> t) where | |
| constructor SemigroupInfo | |
| associative : (a : t) -> (b : t) -> (c : t) -> (op (op a b) c = op a (op b c)) | |
| resolveSemigroup | |
| : {auto associative : (a : t) -> (b : t) -> (c : t) -> (op (op a b) c = op a (op b c))} | |
| -> SemigroupRec t op | |
| resolveSemigroup {associative} = SemigroupInfo associative |
So, I have these declarations
which bottom out with these type aliases
but then these definitions