I hereby claim:
- I am cybai on github.
- I am cybai (https://keybase.io/cybai) on keybase.
- I have a public key ASAKGCR8xr2NhsKcsW2xJCrrjEUhWBsmv7jMBXVY1vhKIwo
To claim this, I am signing this object:
var USELESS_PROPERTIES = []; | |
function processContainer(container) { | |
if (container instanceof CSSSupportsRule) | |
if (!CSS.supports(container.conditionText)) | |
return false; | |
if (container instanceof CSSMediaRule) | |
if (!matchMedia(container.conditionText).matches) | |
return false; | |
if (container.media && container.media.mediaText) |
I hereby claim:
To claim this, I am signing this object:
#!/bin/bash | |
set -e | |
# Building LLVM on OSX CMake setup script | |
# | |
# Required: | |
# - clang by Xcode6 or later | |
# - cmake | |
# - ninja | |
# |
This tutorial was created by Shopify for internal purposes. We've created a public version of it since we think it's useful to anyone creating a GraphQL API.
It's based on lessons learned from creating and evolving production schemas at Shopify over almost 3 years. The tutorial has evolved and will continue to change in the future so nothing is set in stone.
本文譯自 [Tokio internals: Understanding Rust's asynchronous I/O framework from the bottom up][tokio-internals]。
Thanks [David Simmons][david-simmons] for this awesome article!
[Tokio][tokio] 是 Rust 的開發框架,用於開發非同步 I/O 程式(asynchronous I/O,一種事件驅動的作法,可實現比傳統同步 I/O 更好的延伸性、效能與資源利用)。可惜的是,Tokio 過於精密的抽象設計,招致難以學習的惡名。即使我讀完教程後,依然不認為自己充分內化這些抽象層,以便推斷實際發生的事情。
從前的非同步 I/O 相關開發經驗甚至阻礙我學習 Tokio。我習慣使用作業系統提供的 selection 工具(例如 Linux epoll)當作起點,再轉移至 dispatch、state machine 等等。倘若直接從 Tokio 抽象層出發,卻沒有清楚了解 epoll_wait()
在何處及如何發生,我會覺得難以連結每個概念。Tokio 與 future-driven 的方法就好像一個黑盒子。
JavaScript in browsers has a new module system: ES modules. JavaScript in node.js has had a module system for years: CommonJS modules. JavaScript developers have nearly universally adopted node as the platform of choice for their tooling. Web application frameworks all use command-line tools written in node, pulling shared code from the npm registry, to build applications that run on the browser. Open-source code they find on npm is freely used in these applications. Browser app developers now have the following expectations:
CommonJS modules do not work in the browser, but bundling tools like browserify and webpack have allowed CommonJS modules to be built into browser-ready code. Early implementations of ES modules rely on the CommonJS module system under the hood, as Babel transpiles ESM syntax into Common
futures-rs
is the library which will hopefully become a shared foundation for everything async in Rust. However it's already become renowned for having a steep learning curve, even for experienced Rustaceans.
I think one of the best ways to get comfortable with using a library is to look at how it works internally: often API design can seem bizarre or impenetrable and it's only when you put yourself in the shoes of the library author that you can really understand why it was designed that way.
In this post I'll try to put down on "paper" my understanding of how futures work and I'll aim to do it in a visual way. I'm going to assume you're already somewhat familiar with Rust and why futures are a useful tool to have at one's disposal.
For most of this post I'll be talking about how things work today (as of September 2017). At the end I'll touch on what's being proposed next and also make a case for some of the changes I'd like to see.
If you're interested in learning more ab
module Exercise where | |
import Prelude | |
import Data.AddressBook | |
import Data.Functor ((<$>)) | |
import Data.List (filter, head, null, nubBy) | |
import Data.Maybe (Maybe) | |
-- 1. |