mirai

Solid

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 396 stars 34 forks Updated today MIT

Install

View on GitHub

Quality Score: 91/100

Stars 20%
87
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
6 months ago
Last Updated
today
Language
R
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

mir-backend-ruby-rails

Make It Right (Rails module). Ruby on Rails 7+ specific reliability augmentation. Use alongside mir-backend and mir-backend-ruby when the target stack is Rails — carries the mechanical footguns the framework-agnostic skills deliberately omit: ActiveRecord N+1 and eager-loading strategies, strong parameters and mass-assignment safety, callback side-effect timing (after_commit vs after_save), transaction semantics and nested transactions, migration safety on populated tables (the #1 Rails production incident class), and connection pool sizing tied to Puma threads. TRIGGER only when the Ruby backend is Rails — building, reviewing, or debugging a Rails controller, model, concern, migration, or background job that uses ActiveRecord. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-ruby (YARV runtime: GVL, Puma fork-safety, CoW memory, job hygiene); this module only adds Rails/ActiveRecord library mechanics. SKIP for Sinatra, Hanami, pure Rack apps, or non-Ruby runtimes.

12 Updated 2 weeks ago
anantbhandarkar
AI & Automation Listed

mir-backend-ruby

Make It Right (Ruby runtime tier). YARV/MRI Ruby 3.3+ runtime reliability footguns shared across EVERY Ruby backend framework (Rails, Sinatra, Hanami, Sidekiq 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), Puma's forked-worker + thread model, fork-safety of DB/Redis connections, copy-on-write memory and per-worker bloat, background job hygiene (Sidekiq/GoodJob idempotency, retries), and GC/frozen-string pressure. 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 framework-library mechanics (those live in the framework module).

12 Updated 2 weeks ago
anantbhandarkar
AI & Automation Listed

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 (compile error or deadlock), 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, 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 (e.g. mir-backend-rust-axum). SKIP for Python/Node/JVM/Go/.NET/Ruby/PHP/BEAM runtimes (each has its own mir-backend-<runtime> tier), and for framework-library mechanics (those live

12 Updated 2 weeks ago
anantbhandarkar