(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
<!-- | |
1. Download the Android Jelly Bean fonts and the Symbola font: | |
https://www.dropbox.com/s/tvtzcnzkvbe0nrt/jelly-bean-fonts.zip | |
http://users.teilar.gr/~g1951d/Symbola707.zip | |
2. unzip the files and put AndroidEmoji.ttf and Symbola.ttf (and any of the other fonts that strike your fancy) | |
in your ~/.fonts/ directory | |
3. run `fc-cache -f`. You can check to make sure the new fonts | |
were installed with `fc-list`. You'll probably want to grep the copious output for Symbola or Emoji |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
This is a small demo of how to create a library in Rust and call it from Python (both CPython and PyPy) using the CFFI instead of ctypes
.
Based on http://harkablog.com/calling-rust-from-c-and-python.html (dead) which used ctypes
CFFI is nice because:
ctypes
These commands generate and use private keys in unencrypted binary (not Base64 “PEM”) PKCS#8 format. The PKCS#8 format is used here because it is the most interoperable format when dealing with software that isn't based on OpenSSL.
OpenSSL has a variety of commands that can be used to operate on private
key files, some of which are specific to RSA (e.g. openssl rsa
and
openssl genrsa
) or which have other limitations. Here we always use
Consumer key: IQKbtAYlXLripLGPWd0HUA
Consumer secret: GgDYlkSvaPxGxC4X8liwpUoqKwwr3lCADbz8A7ADU
Consumer key: 3nVuSoBZnx6U4vzUxf5w
Consumer secret: Bcs59EFbbsdF6Sl9Ng71smgStWEGwXXKSjYvPVt7qys
Consumer key: iAtYJ4HpUVfIUoNnif1DA
# Concrete syntax: | |
# | |
# ``` | |
# let | |
# pi | |
# : float/64 | |
# = 3.1415 | |
# identity ||< The polymorphic identity function | |
# : [ A : Type ||< The input type. | |
# , a : A ||< The input. |
{ | |
"record.term": { | |
"fields": { | |
"identity": { "node": "$identity" }, | |
"compose": { "node": "$compose" }, | |
"Unit": { "node": "$Unit" }, | |
"Bool": { "node": "$Bool" }, | |
"Option": { "node": "$Option" } | |
}, | |
"nodes": { |
An overly-ambitious attempt to re-think the core calculus of dependent type theory by basing it on graphs as opposed to lambdas, Π-types, Σ-types, etc. The hope is that this might allow us to investigate dependency more closely, and allow us to refine programs to target different environments in an easier way than with traditional programming representations.
Notation | Meaning |
---|---|
l ? T |
abstract node in T |
l : T |
concrete node in T |
l = t |
node equal to t |
default = t |
reduce to this node if all nodes are concrete |
{ ... } |
graph term |
t1.{ l = t2 } |
updates node l in t1 to be t2 |
t.l |
gets the value of node l in t |
t.{ l1 -> l2 } |
renames l1 to l2 in t |