Files
OrcaSlicer/scripts/CAD
Tommaso BianchiandClaude Opus 5 afb17e8889 D3 was testing luck: the pair started 3 degrees from square, inside inference's snap
Port of snaporca b3221f8a12; this is the fork the fault surfaced on.

The perpendicular rung drew its two lines 93.5 degrees apart and then asserted they did
NOT start perpendicular. On this rig, whose camera maps the same click a pixel differently,
they arrived at exactly 90.000000 -- inference had already done the job the rung exists to
test, so the precondition failed while every later check passed. Held on the other fork and
failed here from identical source: the rung depended on where a click happened to land, not
on the app.

The second point now starts the pair 56 degrees off, well outside any snap tolerance, so
the button has real work to do.

That immediately exposed a second, milder fault in the same rung. From a 51 degree start
the LIVE solve converges to its own tolerance and lands at 89.999999991; the old 1e-9
assertion held only because the correction used to be tiny -- it was measuring how little
work the solver had to do, not whether the lines came out perpendicular. It is 1e-6 degrees
now, which is 1.7e-8 radians. The round-trip check still demands exactly 90 and gets it,
because the committed feature re-solves from scratch.

Full ladder 118/118 on BOTH rigs after this, each driving its own fork's binary. This fork
had never had a green gesture ladder before today (snaporca-eoj1).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MrMzTpAf78U4NG2M8jfvHY
2026-08-31 11:29:35 +02:00
..

Design-tab scripts

Everything here supports the parametric Design tab (src/libslic3r/CAD/, src/slic3r/GUI/CAD/). Nothing here is needed to build or run OrcaSlicer — these are the development and verification tools for that one feature.

The verb in the name is the role:

build-… produce a binary
start-… bring something up and leave it running
run-… run a suite and report pass/fail
check-… one specific assertion, usually driving a live app

Verification

Script What it proves Needs
run-kernel-tests.sh The CAD kernel builds and the Catch2 [CadDocument] tags pass — every case builds a document, recomputes it and asserts on real geometry. Exit 0 is the verification contract. Docker only. No display.
run-all-checks.sh Every check below, in one command. The gate before pushing a Design-tab change. Docker + the GUI container
check-sketch-engine.py A ladder of 2D sketches of increasing complexity, judged on loop count, closure and void attribution rather than on area. Kernel only
check-sketch-engine-corpus.py The same ladder graded against a systematic sample of real drawings instead of shapes we chose. Kernel + corpus
check-gui-sketching.py The same profiles drawn the way a person draws them — synthetic mouse gestures and typed values. Headless GUI
check-gui-context-menu.py That right-click is the pivot of the design gesture, and adapts to what was clicked. Headless GUI
check-mcp-sketch.py The sketch layer driven over the MCP socket, asserting what decides whether a profile is buildable. Headless GUI + SNAPORCA_MCP

run-kernel-tests.sh is the only one CI can run. The rest need a live application with an OpenGL canvas and synthetic input, which hosted runners do not have. The kernel suite itself is already in CI by an ordinary route: the cases are registered in tests/libslic3r/CMakeLists.txt under if (SLIC3R_CAD), so they are part of libslic3r_tests and run under ctest on every platform like any other unit test. This script exists for the local loop, where it is a two-minute round trip instead of a full application build.

Build and run

Script Purpose
build-gui.sh Build the GUI binary in a throwaway container, writing into the build-cache volume the long-lived GUI container reads.
build-gui-incremental.sh Incremental build against the deps-baked image, for a fast edit/compile loop.
start-headless-gui.sh Bring the app up on a headless X display (Xvfb + a window manager), ready to drive or attach to over VNC.

Two constraints that are not obvious and have each cost a session:

  • Never build inside the GUI container. Its baked source tree silently reconfigures the shared build directory and this fork's targets vanish.
  • A window manager is required. Without one, windows are never focused, and an unfocused GTK app ignores synthetic keys — which looks exactly like a code bug.

docs/rig_build_traps.md documents these and three more, with symptoms and exact recovery commands. Read it before debugging a configure or link failure one of these scripts reports.