01/13/2012. From a lecture by Professor John Ousterhout at Stanford, class CS140
Here's today's thought for the weekend. A little bit of slope makes up for a lot of Y-intercept.
[Laughter]
#define _CRT_SECURE_NO_DEPRECATE | |
#include <stdio.h> | |
#include <string.h> | |
#include <Windows.h> | |
// This allocates a "magic ring buffer" that is mapped twice, with the two | |
// copies being contiguous in (virtual) memory. The advantage of this is | |
// that this allows any function that expects data to be contiguous in | |
// memory to read from (or write to) such a buffer. It also means that |
#!/usr/bin/env python | |
import numpy | |
import sys | |
import timeit | |
try: | |
import numpy.core._dotblas | |
print 'FAST BLAS' | |
except ImportError: | |
print 'slow blas' |
colorscheme apprentice | |
highlight Type ctermfg=103 | |
highlight cssClassName ctermfg=6 | |
highlight cssClassNameDot ctermfg=6 | |
highlight link jsFuncCall Type | |
highlight cssBraces ctermfg=fg | |
highlight htmlLink ctermfg=fg | |
highlight Function ctermfg=182 | |
highlight MatchParen ctermfg=182 ctermbg=232 | |
highlight Constant ctermfg=210 |
CertSimple just wrote a blog post arguing ES2017's async/await was the best thing to happen with JavaScript. I wholeheartedly agree.
In short, one of the (few?) good things about JavaScript used to be how well it handled asynchronous requests. This was mostly thanks to its Scheme-inherited implementation of functions and closures. That, though, was also one of its worst faults, because it led to the "callback hell", an seemingly unavoidable pattern that made highly asynchronous JS code almost unreadable. Many solutions attempted to solve that, but most failed. Promises almost did it, but failed too. Finally, async/await is here and, combined with Promises, it solves the problem for good. On this post, I'll explain why that is the case and trace a link between promises, async/await, the do-notation and monads.
First, let's illustrate the 3 styles by implementing
Author: Chris Lattner
if exists('g:loaded_qfsign') | |
finish | |
endif | |
let g:loaded_qfsign=1 | |
sign define QFErr texthl=QFErrMarker text=E | |
sign define QFWarn texthl=QFWarnMarker text=W | |
sign define QFInfo texthl=QFInfoMarker text=I | |
augroup qfsign |
# source:http://reocities.com/SiliconValley/heights/7052/opcode.txt | |
From: mark@omnifest.uwm.edu (Mark Hopkins) | |
Newsgroups: alt.lang.asm | |
Subject: A Summary of the 80486 Opcodes and Instructions | |
(1) The 80x86 is an Octal Machine | |
This is a follow-up and revision of an article posted in alt.lang.asm on | |
7-5-92 concerning the 80x86 instruction encoding. | |
The only proper way to understand 80x86 coding is to realize that ALL 80x86 |
I think I’ve figured out most parts of the cubical type theory papers; I’m going to take a shot to explain it informally in the format of Q&As. I prefer using syntax or terminologies that fit better rather than the more standard ones.
Q: What is cubical type theory?
A: It’s a type theory giving homotopy type theory its computational meaning.
Q: What is homotopy type theory then?
A: It’s traditional type theory (which refers to Martin-Löf type theory in this Q&A) augmented with higher inductive types and the univalence axiom.