ranger-compiler 3.5.1 → 3.5.2

package/dist/lib/evg/inspect/README.md

@@ -0,0 +1,415 @@
+# The EVG inspector
+
+Dev tools for a picture a browser cannot read.
+
+```bash
+npm run evg:inspect:demo     # the dashboard, WebGL, with the panel
+npm run pptx:html:serve      # the slide editor, SVG — add ?inspect=1
+npm run evg:inspect:test     # the gates, no browser
+npm run evg:inspect:web      # the panel, in a real browser
+npm run evg:inspect:live     # a rule on disk → the painter, end to end
+npm run evg:inspect:shots    # remake the pictures below
+```
+
+An EVG app in a browser is one `<canvas>`. Open the browser's dev tools on it
+and you get exactly that: one element, no children, no styles, no box model.
+The DOM painter is not much better — a flat pile of `<rect>` and `<path>` in
+paint order, with no names and no nesting. You can see the picture. You cannot
+ask it anything.
+
+This is the panel that answers. Add `?inspect=1` to a host that has been wired
+to it and you get the element hierarchy, the box model drawn over the real
+pixels, the computed style, and the draw commands each element emitted.
+
+Edit `gallery/ui/demo/*.css` while the demo page is open and the picture
+follows on save. That is not a reload of the page and nothing is patched — see
+[the stylesheet is an input](#the-stylesheet-is-an-input).
+
+![the dashboard, inspected](shots/dashboard.png)
+
+## The fourth channel
+
+Three descriptions already come out of an EVG app, and `gallery/ui/demo/main.js`
+names them in its own header:
+
+```
+  displayListJson()   what to draw
+  hitId(x, y)         what is under the pointer
+  a11yJson()          what it MEANS
+```
+
+They share the property this design is built on: **each is derived from the
+same laid-out tree, on the same pass.** `EVGA11yFromTree` says why in its
+header — an app that describes its tree a second time has two descriptions to
+keep in step, and the one nobody can see is the one that rots.
+
+`EVGInspect` is the fourth — **what it IS** — and obeys the same rule. Every
+rectangle it reports is the one `EVGLayout` computed and `EVGDisplayList` drew,
+read off `calculatedX` and its neighbours. Nothing here has a second opinion
+about geometry, so the panel cannot disagree with the picture.
+
+```
+                    EVGElement tree (laid out)
+                             │
+        ┌────────────┬───────┴───────┬──────────────┐
+        ▼            ▼               ▼              ▼
+  EVGDisplayList  EVGHitTest   EVGA11yFromTree   EVGInspect
+   what to draw   what is      what it means     WHAT IT IS
+                  under here
+```
+
+That is also why it works on both painters and off the browser entirely: it is
+attached to the tree, not to a canvas. The WebGL page and the SVG page are the
+same panel with the same code, and the module compiles to every target
+`EVGDisplayList` does.
+
+## Wiring a host to it
+
+The panel knows nothing about any app. It is handed an adapter of small
+functions, and everything past `tree` degrades rather than fails — which is
+what lets one panel serve a slide editor and a dashboard without either
+knowing about the other.
+
+```js
+import { attach } from "…/lib/evg/inspect/evg-inspect.js";
+
+attach({
+  surface,                    // the <canvas> or <svg> the app paints into
+  app: {
+    tree:  () => app.inspectJson(gen),        // REQUIRED
+    node:  (path) => app.inspectNodeJson(path),
+    hit:   (x, y) => app.inspectHitPath(x, y),
+    frame: () => app.inspectFrameJson(),
+    transform: () => app.inspectTransform(),  // {x, y, k}, when the tree is
+    viewport: () => [w, h],                   // drawn inside a larger surface
+    css:   () => ({ name, text, href, errors }),
+    setCss: (text) => app.inspectSetCss(text),
+    saveCss: (text) => fetch(href, { method: "PUT", body: text }),
+    force: (path, bits) => app.inspectForce(path, bits),
+  },
+});
+```
+
+**Every one of these may return a promise.** A host in the same page answers
+synchronously and the panel does not notice; the directions that are not in the
+same page — a DevTools extension over `inspectedWindow.eval`, a native target
+over a socket, a paused page answering out of a snapshot — are all the same
+shape, which is that the answer does not arrive on the same tick. The two
+exceptions are `transform` and `viewport`, read once per refresh and cached,
+because a highlight that arrives a tick after the pointer is a highlight that
+lags.
+
+On the Ranger side that is four one-liners, because `EVGInspect` carries the
+statics:
+
+```ranger
+fn inspectJson:string (gen:int) {
+    this.displayListJson()
+    def r:EVGElement (unwrap root)
+    def w:double (this.widthPx())
+    def h:double (this.heightPx())
+    return (EVGInspect.treeOf(r "Dashboard demo" gen w h))
+}
+fn inspectNodeJson:string (path:string) { … EVGInspect.nodeOf(r path) }
+fn inspectHitPath:string (px:double py:double) { … EVGInspect.hitOf(r px py) }
+fn inspectFrameJson:string () { … EVGInspect.frameOf(r) }
+```
+
+`hitOf` and `nodeOf` should be given the layout that is already there
+(`laidOut()`), not a fresh render. On the dashboard `hitId` costs 11 ms and
+`hitIdCached` costs 0.007 ms, and the whole difference is a page rebuilt to
+answer a question about geometry that had not moved.
+
+## Identity is a path
+
+`EVGElement.id` is not an identity: it is optional, it is the app's own test
+id, and most elements have none. So a node is named by where it sits:
+
+```
+  "0"            the root
+  "0/3"          its fourth child
+  "0/3/k:share"  a child with `key` set uses the key instead of the index
+```
+
+The same trick `EVGComponentHost` plays with `enter`/`leave`: a name unique
+among siblings composes into a name unique in the tree, with no registry.
+
+It is **structural**, and the cost is honest — insert an unkeyed row above the
+selected one and the path names a different element. Keyed children are immune,
+which is the set a list rebuild actually reorders. When a path stops resolving
+the panel drops the selection and says so in its footer; re-pointing it at
+whatever is now at that index would be a lie.
+
+## Which commands did this element draw
+
+![a slide, inspected](shots/pptx-slide.png)
+
+`EVGDrawCmd` carries the element that emitted it, as an index into the inspect
+walk, and writes it into the JSON as `"n"` — **only while attribution is on**.
+Off, the list is byte-identical to the one built before the field existed, and
+that is a gate rather than a hope (`inspect-check.mjs`, gate 5).
+
+It is stamped in one place. `EVGDisplayList.walk` sets `curNode` for the
+element it is walking and puts back what was there on the way out; `addCmd` is
+the only thing that reads it, and every one of the twenty append sites in that
+file goes through `addCmd`. A child cannot leave its slot behind for the
+commands its parent emits afterwards.
+
+This is worth more than the highlight it was added for. "Which element drew
+these three commands" is the question behind the class of bug
+[`gl/README.md`](../gl/README.md) describes: five painters each deciding again
+what a box means, and border-radius working in PDF and silently not in PNG
+because one painter read `box.borderRadius` and another a stale
+`el.borderRadius`. With attribution the command that is wrong names the element
+that is wrong.
+
+In the picture above, the ellipse on slide 4 is selected and the commands pane
+says it became a `RECT` and a `BORDER` at 456,288, 288×192, radius 96 — which
+is how a preset ellipse is drawn.
+
+## Which classes reach this element
+
+This cascade selects on **classes and nothing else** — an `EVGStyleRule` carries
+a class, a state, a theme and a media block, and the subset of CSS it implements
+has nothing else in a selector. That is a limitation with a useful side: the set
+of rules that can ever touch a node is exactly the set written against one of
+its classes, so the panel can list them completely rather than guessing, and
+that list is the answer to *where do I go to change this*.
+
+Two things are shown with it, and both matter before you edit anything:
+
+* **how many elements each class reaches.** `.db-card` is four cards. There is
+  no way to reach one of them without giving it a class of its own, so a panel
+  that let you edit `.db-card` without saying that would be inviting a surprise.
+* **an element with no class at all is unreachable.** `applyTo` returns
+  immediately when `className` is empty, so no rule can ever style it, and
+  whatever it looks like was set on it directly. The panel says so instead of
+  showing an empty rule list that looks like a bug.
+
+The rules themselves come out of the plan, in cascade order, winners and losers
+together:
+
+```
+  RULES, STRONGEST LAST
+  .db-card                                          4 elements
+    display          flex
+    border-radius    14px
+    background-color ▪ #ffffff
+```
+
+Nothing is scored here and no selector is re-matched. `buildPlan` calls
+`planGroup` in the four passes that **are** the precedence — plain, themed,
+stateful, themed-and-stateful — and the last write wins, so "which declaration
+won" is read off the end of the list. The panel cannot disagree with the engine
+about who won because it is not deciding, it is reading. That is gate 6.
+
+The record itself is one int per planned declaration in `EVGStyleSheet.planRules`,
+pushed beside the name and value `planGroup` already pushes. It is **per plan,
+not per element**: a 1600-row table has a handful of plans and a hundred
+thousand applications of them, and the same record made at apply time would be
+paid a hundred thousand times over.
+
+A declaration that lost to an inline value is marked separately from one that
+lost to another rule — see below.
+
+## The stylesheet is an input
+
+![the sheet, edited in the panel](shots/css.png)
+
+This is why the panel can edit at all, and why it needs no override layer.
+
+**The element tree is an app's output.** Edit it and the next rebuild throws
+the edit away — which is exactly why a DevTools style edit dies on a React
+re-render, and why editing the tree would need a table of overrides re-applied
+after every pass, an invalidation story, and a way to detect the app writing
+over you.
+
+**The stylesheet is an app's input.** `init(css)` is how every demo here starts.
+Hand back a changed one and the app re-parses and re-cascades exactly as it did
+at startup; the layout, the display list and the hit test follow because they
+always did. Nothing is intercepted, no value is held over the app's head, and
+**the text in the editor is the text that goes in the file** — there is no
+"copy as CSS" step because there is nothing to translate.
+
+Two routes into the same operation, and they cannot drift:
+
+```
+  the panel's CSS pane ─┬─► app.inspectSetCss(text) ─► EVGStyleSheet.reload
+                        │        ▲
+  a save on disk ───────┼────────┘
+     │                  │
+     └─ serve.mjs watch ─► SSE ─► the page fetches and hands it over
+                        │
+  "save to disk" ───────┴─► PUT ─► serve.mjs writes the file
+                                    …which the watch then sees, so every other
+                                    page open on that sheet re-cascades too
+```
+
+The PUT is deliberately narrow — a `.css` file directly inside
+`gallery/ui/demo`, and nothing else. This server exists to serve a demo on a
+developer's own machine, and a write that could reach further would be a worse
+thing than the convenience is worth. The page that saved keeps the text it
+sent, so its own save coming back round the watch is not applied twice.
+
+`npm run evg:inspect:live` gates the whole path and checks the **colour of a
+rectangle in the display list**, not the element and not the panel: a value
+that reached the element and stopped there would be a frame still showing the
+old colour, and that is the failure worth catching.
+
+### `reload`, and the trap it exists for
+
+`EVGStyleSheet.reload(css)` is not `new EVGStyleSheet()` at the call site, and
+both reasons are silent when got wrong.
+
+`parse` **appends**. It drops the plans and adds rules; it does not remove what
+is already there. Parsing twice into one sheet leaves every rule in it twice,
+which mostly looks like it worked because the duplicates agree — until one of
+them is edited.
+
+And `generation` starts at 1, so a fresh sheet is at 2 after its first parse —
+exactly where the sheet it replaced was. `applyTo` skips an element whose
+`styleGen` already equals the generation, so **every retained element would be
+skipped and the new CSS would land on nothing.** Worse, it fails asymmetrically:
+a page that rebuilds its tree hands the cascade fresh elements with `styleGen`
+0 and works fine. It would pass in the tree-literal demos and fail in an app
+that keeps its tree — which the dashboard does, so gate 7 is run against it
+deliberately.
+
+### What CSS editing cannot reach, and why that is worth showing
+
+* **A value the app set on the element itself.** `inlineProps` is the cascade's
+  own record of what the authoring layer wrote directly, and an inline value
+  outranks every rule. The panel strikes those declarations through and marks
+  them as beaten by inline rather than by another rule — so "why did my edit do
+  nothing" is answered on the spot instead of being a mystery.
+* **`position` in a rule.** `EVGElement.setAttribute` has no branch for it, so
+  the cascade never writes the field; an element is out of flow because it has
+  offsets, an overlay flag, or a `<Layer>` tag. The panel therefore reports the
+  position the **layout used**, not the field, and gate 6 is what would catch a
+  rule that says `position: absolute` with no offsets — the engine ignores it
+  silently today.
+* **Geometry that came from data.** A PPTX slide's shapes are placed by the
+  file, not by a sheet. CSS editing serves that app's chrome; the slide is a
+  different question and the panel does not pretend otherwise.
+
+## Holding a state on
+
+![a hover, held on while the pointer is elsewhere](shots/state.png)
+
+A `:hover` rule cannot be read while the only way to make it true is to keep
+the pointer somewhere other than this panel. So the four interaction bits can
+be **held on** for the selected node — the same thing Chrome's `:hov` toggles
+do, and for the same reason.
+
+Nothing was taught to the cascade. `EVGPseudo.holds` reads `isHovered`,
+`isFocused`, `isPressed` and `a11yDisabled`, and a held bit is one of those
+fields being true — so the rule that wins is the ordinary `.db-brand:hover`
+rule, matching for the ordinary reason. The panel above shows exactly that: the
+initial value struck under it, the base rule, and the hover rule on top.
+
+The table is **keyed by node path, not by element**, and that is the whole
+reason it works here. This page throws its element tree away on every input, so
+a flag written onto an element would last one frame; a path is a fact about the
+tree's shape and names whatever is in that position on the next pass too. It
+lives in `EVGInspectForce`, a singleton, applied by
+`EVGInspect.applyForced(root)` — which a host calls at one specific moment:
+
+```ranger
+this.markStates(r)            ; what the app says is hovered
+EVGInspect.applyForced(r)     ; plus what the panel is holding
+s.applyTree(r "")             ; then ask the sheet what that makes true
+```
+
+That ordering is the only thing a host has to get right, and the cost when
+nothing is held is one array length.
+
+On, not off. Forcing a state *off* would be arguing with the app about what is
+happening rather than holding still something that already is, and the browser
+does not offer it either.
+
+## A tree drawn inside a larger surface
+
+The dashboard's tree *is* the page: the boxes are in the surface's own
+coordinates and the transform is the identity. A slide is not — the editor
+draws it fitted and centred inside a window with a toolbar, a thumbnail strip
+and a properties panel around it.
+
+So the adapter can hand the panel a `transform` (`{x, y, k}`, where the tree's
+coordinates land on the surface and how big they are drawn) and a `viewport`
+(how big the surface is in its own units). The panel applies both to the
+overlay and inverts both for the picker, so an adapter never has to know where
+on the page its picture ended up. `PptxWeb.inspectTransform` derives `k` from
+the two widths rather than assembling it from `ptScale` and the converter's
+scale factor: one number instead of two that have to agree.
+
+## The overlay is DOM, not draw commands
+
+The four rings are absolutely positioned `<div>`s over the surface, in the four
+colours a browser uses. They are **not** pushed into the display list, and that
+is deliberate twice over: a screenshot taken while the panel is open is still a
+screenshot of the app, and one implementation then serves both painters,
+because the WebGL canvas and the SVG one are the same rectangle on the page.
+
+## What is gated
+
+`npm run evg:inspect:test` runs five differences against a real app in Node —
+a second description of something is only worth having if it is differenced
+against the first, which is the habit the painters already keep:
+
+| | |
+| --- | --- |
+| the tree is a tree | one root, every parent present, no path twice |
+| the box model closes | content + padding + borders is the border box, on all 470 nodes |
+| attribution lands inside | a command is inside the box of the element that emitted it — with two exceptions that are real and asserted as such: a text run may overhang by the font's side bearings, a shadow by its blur |
+| the hit test agrees | when it answers, the answer contains the point |
+| off costs nothing | a list built without attribution carries none |
+| the cascade agrees | the winning rule's value is the value on the element, over 2000 properties |
+| a reload lands | a rule added to the sheet reaches a **retained** tree, and the frame |
+| a reload does not double | applying the same text twice leaves the plan the same size |
+| the class counts are the tree's | what the panel says `.db-card` reaches is what the tree has |
+| a held state is an ordinary state | the real `:hover` rule wins, the value follows, it survives a rebuild, and letting go puts it back |
+
+The hit-test gate is deliberately one-sided, and the first version of it was
+wrong in a way worth recording: it expected every node to be reachable. The
+dashboard's table is 552px tall inside a 414px scroll box, so half its rows sit
+at coordinates the page does not show, and `EVGHitTest` drops a clipping box's
+whole subtree when the point is outside it — its header says why, and it is
+right: a row scrolled out of view that is still clickable is the worst of both.
+"Nothing is there" is the correct answer, so the gate asserts the other half —
+nothing may be named under a pointer that is not over it — plus that most of
+the page does answer, so it cannot pass by never being asked.
+
+`npm run evg:inspect:web` gates the part that only exists in a page: that
+`?inspect=1` attaches, that the tree it read has rows, and that the panes
+filled. It runs against the SVG editor because that needs no GPU.
+
+`npm run evg:inspect:live` gates the part that only exists across processes:
+the real dev server, a real save, the real page and the real WebGL painter, in
+both directions — a rule written to the file reaching the painter, and the
+panel's "save to disk" reaching the file. It also checks that the watch fires
+**once** per save: `fs.watch` reports the truncate and the write separately,
+and a sheet reloaded three times per keystroke would relayout three times.
+
+## What is not built yet
+
+[`../PLAN_INSPECTOR.md`](../PLAN_INSPECTOR.md) is the whole design. Built:
+the walk and the panel, attribution, the cascade view, and CSS as a live input.
+Not here yet, in the order they are worth doing:
+
+* **editing a rule in place** rather than appending to the sheet. The
+  provenance names the rule and the panel prints its selector; what is missing
+  is finding that block in the text and writing back into it. Until then an
+  edit is appended, which always wins and is easy to strip, but does not teach
+  you where the value really lives.
+* **a second host with a live sheet.** Only the dashboard is wired to
+  `css()`/`setCss()` today. The other seventeen demos each have one, and the
+  PPTX editor takes chrome CSS through `setChromeCss` — the wiring is four
+  methods and a line in the demo registry.
+* **the transports the async adapter now allows** — a DevTools extension over
+  `inspectedWindow.eval`, a native target over a socket, a paused page
+  answering out of a snapshot. The panel no longer assumes any of them answer
+  on the same tick, which was the part that had to be decided early.
+* **component debug notes** — a component saying *why*, which no channel
+  carries today.
+* **the offline bundle** — one frame in a file, openable with no app running,
+  and attachable to a failing CI gate.

package/dist/lib/evg/inspect/browser-smoke.mjs

@@ -0,0 +1,115 @@
+#!/usr/bin/env node
+// SPDX-License-Identifier: MIT
+//
+// The panel, in a real browser, over the PPTX slide editor.
+//
+//   npm run evg:inspect:web
+//
+// `inspect-check.mjs` gates the four channels in Node, where the app is an
+// object. This gates the half that only exists in a page: that `?inspect=1`
+// actually attaches something, that the tree it read has rows in it, and that
+// selecting a node fills the panes. The wiring between a host and the panel is
+// three functions long and therefore exactly the kind of thing that breaks
+// without any test noticing.
+//
+// The SVG editor is the target because it needs no GPU: `--dump-dom` in
+// headless Chromium is enough, and the page draws the same picture the WebGL
+// one does.
+
+import fs from "node:fs";
+import http from "node:http";
+import path from "node:path";
+import { spawn } from "node:child_process";
+import { fileURLToPath } from "node:url";
+
+const HERE = path.dirname(fileURLToPath(import.meta.url));
+const ROOT = path.resolve(HERE, "..", "..", "..");
+const DIST = path.join(ROOT, "gallery/pptx/web/html/dist");
+const PORT = 8117;
+const MIME = {
+  ".html": "text/html; charset=utf-8", ".js": "text/javascript; charset=utf-8",
+  ".mjs": "text/javascript; charset=utf-8", ".css": "text/css", ".json": "application/json",
+  ".ttf": "font/ttf", ".txt": "text/plain; charset=utf-8", ".svg": "image/svg+xml",
+  ".pptx": "application/vnd.openxmlformats-officedocument.presentationml.presentation",
+  ".odp": "application/vnd.oasis.opendocument.presentation", ".png": "image/png",
+};
+
+function findChrome() {
+  const named = [process.env.CHROME_PATH, "/usr/bin/chromium", "/usr/bin/chromium-browser",
+    "/usr/bin/google-chrome", "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"].filter(Boolean);
+  for (const c of named) { try { if (fs.existsSync(c)) return c; } catch { /* keep looking */ } }
+  const pw = process.env.PLAYWRIGHT_BROWSERS_PATH || "/opt/pw-browsers";
+  try {
+    for (const dir of fs.readdirSync(pw)) {
+      const c = path.join(pw, dir, "chrome-linux", "chrome");
+      if (fs.existsSync(c)) return c;
+    }
+  } catch { /* none */ }
+  return null;
+}
+
+function serve() {
+  const server = http.createServer((req, res) => {
+    const rel = decodeURIComponent((req.url || "/").split("?")[0]);
+    const file = path.join(DIST, rel === "/" ? "index.html" : rel);
+    if (!file.startsWith(DIST) || !fs.existsSync(file)) { res.writeHead(404); res.end("no"); return; }
+    res.writeHead(200, { "content-type": MIME[path.extname(file)] || "application/octet-stream", "cache-control": "no-store" });
+    res.end(fs.readFileSync(file));
+  });
+  return new Promise((r) => server.listen(PORT, "127.0.0.1", () => r(server)));
+}
+
+function runChrome(bin, args) {
+  return new Promise((resolve) => {
+    const child = spawn(bin, args, {
+      env: { ...process.env, HTTP_PROXY: "", HTTPS_PROXY: "", http_proxy: "", https_proxy: "", NO_PROXY: "*", no_proxy: "*" },
+    });
+    let out = "", err = "";
+    const kill = setTimeout(() => child.kill("SIGKILL"), 120000);
+    child.stdout.on("data", (d) => (out += d));
+    child.stderr.on("data", (d) => (err += d));
+    child.on("close", (status) => { clearTimeout(kill); resolve({ stdout: out, stderr: err, status }); });
+    child.on("error", (error) => { clearTimeout(kill); resolve({ stdout: out, stderr: err, status: -1, error }); });
+  });
+}
+
+if (!fs.existsSync(path.join(DIST, "pptx_web.js"))) {
+  console.error("no build in " + path.relative(ROOT, DIST) + " — run: npm run pptx:html");
+  process.exit(1);
+}
+const chrome = findChrome();
+if (!chrome) { console.error("no Chrome found — set CHROME_PATH to one"); process.exit(1); }
+
+const server = await serve();
+let failed = 0;
+const ok = (name, cond, detail) => {
+  if (cond) console.log("  ok " + name);
+  else { failed++; console.log("  FAIL " + name + (detail ? " — " + detail : "")); }
+};
+
+try {
+  // The panel opens on the root, so a dumped DOM already carries a selection
+  // and a filled pane — no script has to be injected to make it interesting.
+  const url = `http://127.0.0.1:${PORT}/index.html?inspect=1`;
+  const run = await runChrome(chrome, ["--headless=new", "--no-sandbox", "--no-proxy-server",
+    "--proxy-bypass-list=<-loopback>", "--disable-dev-shm-usage",
+    "--virtual-time-budget=25000", "--dump-dom", url]);
+  const dom = run.stdout || "";
+  if (process.env.SMOKE_DEBUG) fs.writeFileSync("/tmp/evg-inspect-dom.html", dom);
+
+  ok("the panel attached", /class="evgi"/.test(dom));
+  const rows = (dom.match(/class="evgi-row/g) || []).length;
+  ok("the tree has rows", rows >= 3, rows + " rows");
+  const foot = (dom.match(/class="evgi-foot"[^>]*>([^<]*)/) || [])[1] || "";
+  ok("the footer counted nodes and commands", /\d+ nodes/.test(foot) && /\d+ commands/.test(foot), JSON.stringify(foot));
+  ok("the box-model diagram is there", /evgi-bm/.test(dom));
+  ok("the overlay is mounted over the picture", /class="evgi-ov"/.test(dom));
+  ok("a node is selected", /evgi-row sel/.test(dom));
+  ok("the panes filled", /evgi-kv/.test(dom));
+  if (failed && process.env.SMOKE_DEBUG !== "1") console.log("\n  re-run with SMOKE_DEBUG=1 to dump the DOM to /tmp");
+} finally {
+  server.close();
+}
+
+console.log(failed ? `\n${failed} failed\n` : "\nthe inspector attached to the slide editor and read its tree\n");
+process.exit(failed ? 1 : 0);