juli/OrcaSlicer
1
1
Fork 0
mirror of https://github.com/OrcaSlicer/OrcaSlicer.git synced 2026-09-19 23:12:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

D3 was testing luck: the pair started 3 degrees from square, inside inference's snap

Browse Source 
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
This commit is contained in:
Tommaso Bianchi
2026-08-31 11:29:35 +02:00
co-authored by Claude Opus 5
parent d35d33971a
commit afb17e8889
1 changed files with 13 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
scripts/CAD/check-gui-sketching.py
+13 -2
View File
@@ -957,7 +957,13 @@ def rung_perpendicular():
clickmm(-50, -30); clickmm(30, -18)
key("Escape", 0.7); key("Escape", 0.7)
key("l", 0.6)
clickmm(30, -18); clickmm(18, 40)
# 56 degrees off the first line, not 3. The original second point put the pair within
# inference's perpendicular tolerance, so on a rig whose camera maps the click a pixel
# differently the two lines arrive ALREADY at exactly 90.000000 -- inference did the job the
# rung exists to test, and the precondition failed while every later check passed. Held on
# one fork and failed on the other from the same source, which is the signature of a rung
# that depends on luck. Start well outside any snap tolerance so the button has real work.
clickmm(30, -18); clickmm(55, 35)
key("Escape", 0.7); key("Escape", 0.7)
d0 = describe()
check("ANGLE", abs(angle_between(d0["entities"][0], d0["entities"][1]) - 90.0) > 1e-3,
@@ -969,7 +975,12 @@ def rung_perpendicular():
time.sleep(1.0)
d = describe()
ang = angle_between(d["entities"][0], d["entities"][1])
check("ANGLE", near(ang, 90.0, 1e-9), f"now {ang:.9f} deg")
# 1e-6 deg, which is 1.7e-8 radians: the LIVE solve converges to its own tolerance and lands
# at 89.999999991 from a 51 deg start. The old 1e-9 held only because the pair began 3 deg
# from square, so the correction was tiny -- it was measuring how little work the solver had
# to do, not whether the lines came out perpendicular. The round-trip check below still
# demands exactly 90: the committed feature re-solves from scratch and gets there.
check("ANGLE", near(ang, 90.0, 1e-6), f"now {ang:.9f} deg")
d2 = confirm_and_reopen()
ang2 = angle_between(d2["entities"][0], d2["entities"][1])
check("ANGLE", near(ang2, 90.0, 1e-9), f"still {ang2:.9f} deg after the round trip")