mirai

Featured

Help users write correct R code for async, parallel, and distributed computing using mirai. Use when users need to run R code asynchronously or in parallel, write mirai code with correct dependency passing, set up parallel workers, convert from future or parallel, use mirai_map, integrate with Shiny or promises, or configure cluster/HPC computing.

AI & Automation 497 stars 48 forks Updated yesterday MIT

Install

View on GitHub

Quality Score: 92/100

Stars 20%
90
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

mirai is a minimalist R framework for async, parallel, and distributed evaluation, built on nanonext. ## Core Principle: Explicit Dependency Passing mirai evaluates expressions in a **clean environment** on a daemon process. Nothing from the calling environment is available unless passed explicitly — this is the #1 source of mistakes. ```r # WRONG: my_data and my_func are not available on the daemon m <- mirai(my_func(my_data)) ``` There are two ways to pass objects, and the names used **must match** the names referenced in the expression. ### `.args` (recommended) Objects in `.args` populate the expression's **local evaluation environment** — available directly by name inside the expression. ```r m <- mirai(my_func(my_data), .args = list(my_func = my_func, my_data = my_data)) ``` ### `...` (dot-dot-dot) Objects passed via `...` are assigned to the **daemon's global environment**. Use this when objects need to be found by R's standard scoping rules (e.g., helper functions called by other functions). ```r m <- mirai(my_func(my_data), my_func = my_func, my_data = my_data) ``` ### Shortcut: pass the whole calling environment ```r # .args form — populates local eval env process <- function(x, y) mirai(x + y, .args = environment()) # ... form — single unnamed environment, populates daemon global env df_matrix <- function(x, y) mirai(as.matrix(rbind(x, y)), environment()) ``` ### When to use which | Scenario | Use | |----------|-----| | Data and simple functions | `....

Details

Author
posit-dev
Repository
posit-dev/skills
Created
9 months ago
Last Updated
yesterday
Language
R
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Solid

mir-backend-ruby

Make It Right (Ruby runtime tier). YARV/MRI Ruby 4.0 runtime reliability footguns shared across EVERY Ruby backend framework (Rails, Sinatra, Hanami, Sidekiq/Solid Queue workers) — distinct from the generic backend gates and from any one framework's mechanics. Covers: the GVL (threads give no CPU parallelism, like Python's GIL), the reworked Ractor API in Ruby 4.0, YJIT/ZJIT enablement, Puma's forked-worker + thread model, fork-safety of DB/Redis connections, copy-on-write memory and per-worker bloat, background job hygiene (idempotency, retries), GC/string-literal pressure, and the Rack/Puma/Bundler security layer every Ruby web app inherits. TRIGGER when the backend runtime is Ruby — sits between mir-backend (generic) and the framework module (e.g. mir-backend-ruby-rails). SKIP for Node/JVM/Go/Rust/.NET/Python/PHP/BEAM runtimes (each has its own mir-backend-<runtime> tier), and for Rails/ActiveRecord library mechanics — N+1, strong parameters, callbacks, migrations, Active Storage — which belong to mir-back

15 Updated 1 weeks ago
anantbhandarkar
AI & Automation Solid

mir-backend-rust

Make It Right (Rust runtime tier). Async Rust on Tokio runtime reliability footguns that are shared across EVERY Rust backend framework (Axum, Actix-web, Warp, Poem) — distinct from the generic backend gates and from any one framework's mechanics. Covers: blocking the async runtime (std::thread::sleep / blocking I/O inside async tasks starves Tokio worker threads), holding a std::sync::MutexGuard across an .await point (Send error on a multi-thread runtime, silent deadlock on a current-thread one), cancellation safety (futures dropped at any .await under timeout/select!/disconnect leaving partial state), panic-poisoned Mutexes, Arc-based shared state with 'static bounds on spawned tasks, async fn in traits and the still-unsolved Send-bound problem, spawn_blocking thread-pool exhaustion, bounded vs unbounded channels for backpressure, and timeout discipline on every outbound call. TRIGGER when the backend runtime is Rust — sits between mir-backend (generic) and the framework module. SKIP for Python/Node/JVM/Go

15 Updated 1 weeks ago
anantbhandarkar
AI & Automation Solid

mir-backend

Make It Right (backend pillar). Constraint-first backend planning protocol for AI coding agents — AI makes code that WORKS on the happy path; this makes it RIGHT under concurrency, failure, and load. Forces the model OUT of pattern-completion ('autocomplete from latent space') and INTO explicit constraint discovery before any code is written. Use whenever a task involves backend logic that changes state, touches money/inventory/auth, spans multiple tables or services, runs under concurrency, or persists data beyond a single request. Runs a hard-gated pipeline: Intent → Constraint Interrogation → Assumption Ledger → Invariants & Failure Modes → Risk Register → Design Review → Implementation → Production-Readiness Review. Spawns specialized reviewer sub-agents. Chains into a runtime tier (e.g. mir-backend-python for CPython concerns) and a framework module (e.g. mir-backend-python-fastapi for FastAPI/SQLAlchemy/Alembic). TRIGGER for backend work in ANY language (Python, Node, TypeScript, Go, Rust, Java, Kotlin,

15 Updated 1 weeks ago
anantbhandarkar