r33drichards

-- bctest — does this computer's Lua load 5.1 bytecode? CC:Tweaked >= 1.109.0
-- refuses binary chunks, which disables wasmcraft's jit (compiled) mode — the
-- engine then falls back to the interpreter automatically. This prints which
-- world you're in. The probe chunk is a minimal valid 5.1 proto: "return 42".
local bc = "\27\76\117\97\81\0\1\4\4\4\8\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2\2\2\0\0\0\1\0\0\0\30\0\0\1\1\0\0\0\3\0\0\0\0\0\0\69\64\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
local f, lerr = (loadstring or load)(bc)
if type(f) == "function" then
  local okrun, v = pcall(f)
  if okrun and v == 42 then
    print("bytecode loading WORKS (got " .. tostring(v) .. ") - jit mode available")

r33drichards

-- picbench — benchmark a picatd daemon FROM ANY computer on the network:
-- the daemon runs the same Picat fib(N) program end-to-end (engine boot + solve)
-- through the tree-walking INTERPRETER and through the wasm->Lua-bytecode
-- COMPILER (jit), times each on its own clock (rednet latency excluded), and
-- this client reports both + the speedup. Jobs queue on the daemon's 'main'
-- session, so a busy daemon finishes its current work first.
--   Usage: picbench [daemon] [N] [mode]   (default: first daemon, fib(10), jit)
-- mode = the compiled leg (jit|transpile|auto), always compared vs interp.
-- jit is STRICT: on a CC build that refuses bytecode it FAILS LOUDLY - rerun
-- with mode transpile there.

r33drichards

-- sqlite ON DISK via the raw WebAssembly API, on a ComputerCraft computer.
-- Sibling of examples/sqlite.lua, but instead of ":memory:" this opens a real
-- file through the `fs` cap, so the database survives the wasm instance and lands
-- on the computer's save dir as an inspectable .sqlite file.
--
-- How the path maps (verified against the engine source):
--   * wasm.instantiate(..., { fs = "sql" }) resolves to this computer's own save
--     dir + "sql": <world>/computercraft/computer/<id>/sql   (WasmLuaAPI.resolveFs
--     + computerRoot).
--   * The `fs` cap mounts that host directory at the guest root "/"

r33drichards

-- sqlite via the raw WebAssembly API, on a ComputerCraft computer.
--
-- This loads the module straight from an OCI registry (digest-verified). For that
-- to work, wasm-cc.json must enable it:
--     "allowOciModules": true,
--     "ociRegistryAllow": ["ghcr.io"]
-- The host fetches the module itself, so only the "wasi" cap is needed here (no
-- "http" cap). The ghcr.io/r33drichards/sqlite artifact is published by the
-- release workflow (or manually via `make publish-sqlite`); until the first `v*`
-- tag is pushed this ref will not resolve yet -- meanwhile you can use the local

r33drichards

-- kelpfill.lua -- single-turtle volumetric kelp filler.
--
-- Fills an arbitrary water box with a kelp plant in EVERY cell, moving in a
-- bottom-to-top zigzag (boustrophedon), never revisiting a cell, resumable
-- across reboot/chunk-unload. Pure geometry/path/state logic is in
-- kelpfill_plan.lua (unit-tested); this is the thin program that drives the
-- real turtle: GPS self-locate, navigation, kelp/fuel polling, persistence.
--
--   Usage:  kelpfill <ax> <ay> <az> <bx> <by> <bz>
--   where (ax,ay,az) and (bx,by,bz) are two opposite WORLD corners of the box.

r33drichards

-- kelpqueue.lua -- QUEUE-BASED kelp harvester for a CC: Tweaked turtle (MC 1.21.8).
--
-- DESIGN (the user's algorithm, implemented exactly):
--   A precomputed QUEUE of surface target columns + a dead-simple per-target
--   primitive.  We DO NOT detect kelp to navigate; we navigate over LIVE water on
--   a fixed travel plane (walls/structure are reliably inspectable -- only kelp
--   detection was ever unreliable, and we never rely on it).
--
--   1. Get out of the dock and go to the first target.
--   2. For each target (a QUEUE we POP): rise inside the column to the air above

r33drichards

-- kelpqueue.lua -- QUEUE-BASED kelp harvester for a CC: Tweaked turtle (MC 1.21.8).
--
-- DESIGN (the user's algorithm, implemented exactly):
--   A precomputed QUEUE of surface target columns + a dead-simple per-target
--   primitive.  We DO NOT detect kelp to navigate; we navigate over LIVE water on
--   a fixed travel plane (walls/structure are reliably inspectable -- only kelp
--   detection was ever unreliable, and we never rely on it).
--
--   1. Get out of the dock and go to the first target.
--   2. For each target (a QUEUE we POP): rise inside the column to the air above

r33drichards

-- kelpmap.lua -- NAIVE, BAKED-MAP kelp harvester for a CC: Tweaked turtle (MC 1.21.8).
--
-- WHY (the new approach): the old slime-mold kelp.lua DETECTED kelp while moving
-- and that detection was the source of every prior bug (surface sensing missed
-- deep kelp, seagrass misread, etc.).  This harvester DOES NOT DETECT kelp at
-- all.  Instead it iterates a BAKED MAP of kelp column positions that was scanned
-- + committed once (maps/kelp_field.lua).  For each known column it navigates to
-- it over LIVE water (walls/structure ARE reliably visible to inspect -- only
-- KELP detection was unreliable, and we're not detecting kelp anymore), descends
-- the column digging top-to-bottom, leaves the base block to regrow, ascends, and

r33drichards

-- sanddiver.lua -- DOCK-DIVE sand/gravel QUARRY turtle for CC: Tweaked (MC 1.21.8).
--
-- WHY THIS EXISTS (the real failure): the sibling top-down sandminer.lua assumes
-- the turtle STARTS ON SAND and digs straight down through solid sand. In-world
-- it was placed on a DOCK over WATER, so the block directly below the start is a
-- dock plank / water, NOT sand -> a top-down sandOnly miner immediately reports
-- "rock floor at depth 0" and deposits 0. sanddiver fixes this by DIVING through
-- the dock + water column FIRST, finding the submerged sand/gravel BANK, and only
-- THEN running the (proven) boustrophedon quarry across the bank.
--

r33drichards

-- sanddiver.lua -- DOCK-DIVE sand/gravel QUARRY turtle for CC: Tweaked (MC 1.21.8).
--
-- WHY THIS EXISTS (the real failure): the sibling top-down sandminer.lua assumes
-- the turtle STARTS ON SAND and digs straight down through solid sand. In-world
-- it was placed on a DOCK over WATER, so the block directly below the start is a
-- dock plank / water, NOT sand -> a top-down sandOnly miner immediately reports
-- "rock floor at depth 0" and deposits 0. sanddiver fixes this by DIVING through
-- the dock + water column FIRST, finding the submerged sand/gravel BANK, and only
-- THEN running the (proven) boustrophedon quarry across the bank.
--