This gist is my attempt to list all projects providing proof automation for Agda.
When I say tactic, I mean something that uses Agda's reflection to provide a smooth user experience, such as the solveZ3
tactic from Schmitty:
_ : ∀ (x y : ℤ) → x ≤ y → y ≤ x → x ≡ y
_ = solveZ3
#lang racket | |
;; An introduction to procedure inlining following a simplification of GHC's | |
;; inliner from: | |
;; https://www.microsoft.com/en-us/research/wp-content/uploads/2002/07/inline.pdf | |
;; | |
;; This version is a simplification in that: | |
;; 1. It picks loop breakers naively | |
;; 2. It ONLY inlines procedures (not other bound expressions) | |
;; 3. All calls are direct, so it's not context sensitive (although the |
module FoldsAndUnfolds where | |
import Data.List -- for unfoldr | |
class Functor f => Recursive f t | t -> f where | |
project :: t -> f t | |
cata :: (f a -> a) -> t -> a | |
cata alg = go where go = alg . fmap go . project |
# Here's a probably-not-new data structure I discovered after implementing weight-balanced trees with | |
# amortized subtree rebuilds (e.g. http://jeffe.cs.illinois.edu/teaching/algorithms/notes/10-scapegoat-splay.pdf) | |
# and realizing it was silly to turn a subtree into a sorted array with an in-order traversal only as an | |
# aid in constructing a balanced subtree in linear time. Why not replace the subtree by the sorted array and | |
# use binary search when hitting that leaf array? Then you'd defer any splitting of the array until inserts and | |
# deletes hit that leaf array. Only in hindsight did I realize this is similar to the rope data structure for strings. | |
# Unlike ropes, it's a key-value search tree for arbitrary ordered keys. | |
# | |
# The main attraction of this data structure is its simplicity (on par with a standard weight-balanced tree) and that it | |
# coalesces subtrees into contiguous arrays, which reduces memory overhead and boosts the performance of in-order traversals |
#! Aaaaaaaaaaa this is JS!!! | |
// https://github.com/tc39/proposal-hashbang | |
// This file is mixing all new syntaxes in the proposal in one file without considering syntax conflict or correct runtime semantics | |
// Enjoy!!! | |
// Created at Nov 23, 2018 | |
for await(const x of (new A // https://github.com/tc39/proposal-pipeline-operator | |
|> do { // https://github.com/tc39/proposal-do-expressions | |
case(?) { // https://github.com/tc39/proposal-pattern-matching | |
when {val}: class { |
#lang racket | |
(require redex) | |
;; Run to explore all of the gradual typings of the example | |
(define (main) | |
(traces -> (term example))) | |
(define-term example | |
(λ (x : ?) | |
(λ (y : ?) |
The Linux kernel is written in C, so you should have at least a basic understanding of C before diving into kernel work. You don't need expert level C knowledge, since you can always pick some things up underway, but it certainly helps to know the language and to have written some userspace C programs already.
It will also help to be a Linux user. If you have never used Linux before, it's probably a good idea to download a distro and get comfortable with it before you start doing kernel work.
Lastly, knowing git is not actually required, but can really help you (since you can dig through changelogs and search for information you'll need). At a minimum you should probably be able to clone the git repository to a local directory.
; Math48 Floating Point Package | |
; Version 1.1 Revision 1 | |
; by Anders Hejlsberg | |
; 2532 Bytes | |
;HOPTABEL | |
JP FPADD | |
JP FPSUB | |
JP FPMUL |
; https://web.archive.org/web/20190701203222/https://www.pcengines.ch/tp3.htm | |
; The disassembler was applied to a copy of TP 3.01A downloaded from WinWorld. | |
; I postprocessed the disassembly with a script to clean up spacing and column alignment. | |
; *** TURBO PASCAL version 3.01 A source code | |
; *** | |
; *** commented by Pascal Dornier | |
; *** all rights reserved | |
; "*** | |
cseg $100 ; "COM file... |