X → Graph → Effect<A, E, R>
│ │ │ │ │
│ │ │ │ └─ what each node needs (§5)
│ │ │ └──── where the graph breaks (§4)
│ │ └─────── what flows through nodes (§2)
│ │
│ └─ nodes = functions, edges = data flow
| /dts-v1/; | |
| / { | |
| nintendo,buildrevision = "f7aea707909d02195e61ea649b0d9637a354fca2"; | |
| nintendo,buildrevisiondate = "2024-06-06T08:07:35Z"; | |
| compatible = "nintendo,ounce-mp", "nintendo,ounce"; | |
| #address-cells = <0x2>; | |
| #size-cells = <0x2>; | |
| interrupt-parent = <0x1>; | |
| model = "Nintendo Ounce, MP"; |
You are building a fully decentralized peer-to-peer ridehailing mobile app. Zero centralized servers. The entire system runs on user devices and the Solana blockchain.
- A rider opens the app, sets a destination, and the app calculates a fare client-side using Haversine distance.
- The rider posts a ride request on-chain containing a blinded zone ID (ZK proof of zone membership), the offered fare, and escrowed SOL.
- Nearby drivers discover the request via libp2p GossipSub and on-chain queries.
- Drivers submit offers on-chain — they can accept the rider's fare or counter-offer (capped at 2x the rider's price).
| export type ResizeObserverEntryCallback = (entry: ResizeObserverEntry) => void; | |
| export class ResizeObserverManager { | |
| #elementMap = new WeakMap<Element, Set<ResizeObserverEntryCallback>>(); | |
| #elementEntry = new WeakMap<Element, ResizeObserverEntry>(); | |
| #vo = new ResizeObserver((entries) => { | |
| for (const entry of entries) { | |
| this.#elementEntry.set(entry.target, entry); | |
| this.#elementMap.get(entry.target)?.forEach((callback) => callback(entry)); |
| package html_builder | |
| import "core:fmt" | |
| import "core:strings" | |
| Attr :: struct { | |
| name: string, | |
| value: string, | |
| } |
| ****** SemanticTextStore.db : | |
| CREATE TABLE si_db_info ( | |
| schema_version INTEGER | |
| ); | |
| CREATE TABLE si_items ( | |
| id BLOB(16) PRIMARY KEY NOT NULL | |
| ); | |
| CREATE TABLE si_diskann_graph ( | |
| id INTEGER PRIMARY KEY, |
| // 3D Dom viewer, copy-paste this into your console to visualise the DOM as a stack of solid blocks. | |
| // You can also minify and save it as a bookmarklet (https://www.freecodecamp.org/news/what-are-bookmarklets/) | |
| (() => { | |
| const SHOW_SIDES = false; // color sides of DOM nodes? | |
| const COLOR_SURFACE = true; // color tops of DOM nodes? | |
| const COLOR_RANDOM = false; // randomise color? | |
| const COLOR_HUE = 190; // hue in HSL (https://hslpicker.com) | |
| const MAX_ROTATION = 180; // set to 360 to rotate all the way round | |
| const THICKNESS = 20; // thickness of layers | |
| const DISTANCE = 10000; // ¯\\_(ツ)_/¯ |
inspired by a friend’s fledgling language design and motivated by the JeanHeyd Meneide RustConf Fiasco™ and improving the story for compile-time introspection, i decided i needed a place to spew the last year’s musings on variadic generics in Rust in one mighty, less-than-understandable catharsis.
i think somewhere in here is a considered and reasonable design, so that’s neat!
perhaps i’ll make this an RFC one day. probably not. you have my express permission to do that yourself.
this nugget of language jargon encapsulates the idea that we might want to bind to an arbitrarily large list of generic parameters, all at once. there are many reasons to want to do this:
- we might want to implement a trait for all tuples, where each element of the tuple implements the same trait. [
bevy_ecs'sBundletrait](https://github.com/bevyengine/bevy/blob/87f7d013c0d4f45a93a4c29e5d48237f4b512ca2/crates/bevy_ecs/src/bundle.