diff options
Diffstat (limited to 'ocaml/ROADMAP.md')
| -rw-r--r-- | ocaml/ROADMAP.md | 108 |
1 files changed, 108 insertions, 0 deletions
diff --git a/ocaml/ROADMAP.md b/ocaml/ROADMAP.md new file mode 100644 index 0000000..046b206 --- /dev/null +++ b/ocaml/ROADMAP.md @@ -0,0 +1,108 @@ +as of 20-october 2025 (Effects + Performance benchmarked!) + + ✅ What We Have Built + + Core Runtime: + - ✅ noun.ml - Noun type system (atom/cell) + - ✅ nock.ml - Full Nock interpreter (all 12 opcodes) + - ✅ bitstream.ml - Bit-level I/O (optimized for large atoms) + - ✅ serial.ml - Jam/cue serialization (iterative, handles 3M+ nouns) + - ✅ state.ml - State management (event counter, kernel storage, snapshots, eventlog) + - ✅ boot.ml - Pill loading (ivory + solid with lifecycle formula!) + - ✅ eventlog_lmdb.ml - LMDB-based event persistence matching Vere + + Working Features: + - ✅ Ivory pill boot via lifecycle formula (loads Arvo kernel) + - ✅ Solid pill boot via lifecycle formula (CORRECT approach matching Vere!) + - ✅ Lifecycle formula [2 [0 3] [0 2]] - batch processes all boot events + - ✅ Mixed event list structure (bot bare, mod/use timestamped) matching Vere + - ✅ Event application via poke (for runtime events after boot) + - ✅ Snapshot/restore capability + - ✅ Fast cue (~1.5s for 3.2M nouns) + - ✅ LMDB event persistence - Write events to disk matching Vere exactly + - ✅ Event replay - Load from disk on restart + - ✅ Pier directory structure - Create .urb/log/ with LMDB files + - ✅ Event timestamping - Events wrapped as [timestamp event_data] + - ✅ Proper eventlog close/sync + + Boot Process (Matching Vere Exactly!): + - ✅ Parse solid pill: [%pill %solid bot mod use] + - ✅ Add 4 system events to mod (wack, whom, verb, wyrd) + - ✅ Add boot event to use + - ✅ Build mixed event list: bot (bare) + mod/use (timestamped) + - ✅ Run lifecycle formula on full list: [2 [0 3] [0 2]] + - ✅ Extract kernel from slot 7 of result + - ✅ Boot complete with working Arvo kernel! + + LMDB Event Log Implementation (Matches Vere!): + - ✅ Two databases: "EVENTS" (uint64 → bytes) and "META" (string → bytes) + - ✅ 1TB map size (0x10000000000, matches Vere's default) + - ✅ Event format: 4-byte murmur3 mug + jammed noun (matches Vere exactly) + - ✅ Tested with 10 events (13MB total LMDB database) + - ✅ Handles massive events: 8.6MB (3.2M+ nodes), 4.1MB events work perfectly + - ✅ Uses MDB_INTEGERKEY for efficient uint64 event number indexing + - ✅ Proper transaction handling for atomicity + + Event Timestamping: + - Events wrapped as [timestamp event_data] like Vere + - Urbit time: 128-bit atom (seconds + fractional seconds) + - Each event increments by 2^48 (~15.26 microseconds, 1/2^16 seconds) + - Matches Vere's time format exactly (verified with python script) <- huh? what's python to do with anything + + 🚀 What's Needed to Boot a Real Ship + + Phase 1: Effects & I/O (CRITICAL - Need this first!) + ════════════════════════════════════════════════════ + The runtime is solid. We can boot pills, run Nock, persist events. + What's missing: Arvo returns EFFECTS that need to be executed! + + 1. ❌ Effects Processing - Parse and dispatch effects from poke results + - Effects are returned as the head of [effects new-kernel] + - Need to route to appropriate I/O drivers (Dill, Ames, Eyre, etc.) + - This is THE critical missing piece! + + 2. ❌ Terminal I/O (Dill driver) - FIRST I/O DRIVER TO IMPLEMENT + - Handle %blit effects (print to terminal) + - Handle %belt events (keyboard input from terminal) + - Parse and render ANSI/styled text + - This will let us SEE the ship boot and INTERACT with it! + + 3. ❌ Event Loop - Main loop to process events and effects + - Read input (keyboard, network, HTTP) + - Send to Arvo via poke + - Process returned effects + - Route effects to I/O drivers + - Persist events to LMDB + + Phase 2: Full Connectivity + ════════════════════════════════════════════════════ + 4. ❌ HTTP I/O (Eyre driver) - Web interface + - Handle HTTP requests + - Serve web interface (Landscape) + - WebSocket connections for live updates + + 5. ❌ Networking (Ames driver) - Ship-to-ship communication + - UDP networking for peer-to-peer + - Packet routing and encryption + - NAT traversal + + Phase 3: Production Features + ════════════════════════════════════════════════════ + 6. ❌ Metadata persistence - Save ship identity in LMDB META database + 7. ❌ Event replay on startup - Boot from existing pier + 8. ❌ Jets - Performance optimizations for hot paths + 9. ❌ Snapshot system - Periodic kernel snapshots to speed up replay + 10. ❌ Crash recovery - Handle corrupted state gracefully + + 🎯 IMMEDIATE NEXT STEPS TO BOOT: + ════════════════════════════════════════════════════ + 1. Parse effects from poke results + 2. Implement basic Dill driver (%blit for output, %belt for input) + 3. Create event loop that: + - Boots solid pill (DONE - we can do this!) + - Processes terminal input as %belt events + - Sends to Arvo via poke + - Displays %blit effects to terminal + 4. Test: Can we type commands and see responses? + + Once Dill works, we have an INTERACTIVE URBIT SHIP! 🎉 |