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

Fix the solver abort on circle-line tangency; the CAD suite now runs complete

Browse Source 
snaporca-tkz, the last quarantined test. Root cause read out of the vendored
source rather than guessed: slvs/constrainteq.cpp, Type::ARC_LINE_TANGENT does

    ExprVector ap = SK.GetEntity(arc->point[other ? 2 : 1])->PointGetExprs();

so it dereferences the ARC'S ENDPOINTS. A full circle entity carries only
point[0], its centre. point[1] and point[2] are zero handles, FindById throws
"Cannot find handle", and the process ABORTS rather than failing the solve —
taking every later test in the binary with it. That is also the wrong equation
for a circle regardless: it only makes the line perpendicular to the radius at
an endpoint that does not exist.

CT::Tangent no longer hands a full circle to that constraint. For a circle it
emits PT_LINE_DISTANCE(centre, line) = radius, which is precisely what tangency
to a circle means. Arcs keep the ARC_LINE_TANGENT path they are built for.

One limitation, stated rather than buried: the slvs C API takes a constant
distance and offers no way to reference the circle's radius parameter, so the
radius is captured when the constraint is emitted. That is exact whenever the
radius is fixed or is simply not driven by another constraint in the same
solve, and re-solving restores tangency if something else moves it. Tying them
would need an auxiliary point constrained onto both the circle and the line.

With this and eeca6794e7, both quarantined tests are gone and the exclusion in
kernel-test.sh goes with them. A green run now means the whole CAD suite
passed, not "everything except the two we gave up on":

    149 cases / 2043 assertions, no filters.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Tommaso Bianchi
2026-07-26 09:33:50 +02:00
co-authored by Claude Opus 5
parent f599ff0ff7
commit 5026dd11a6
3 changed files with 36 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
scripts/kernel-test.sh
+5 -9
View File
@@ -31,15 +31,11 @@ IMAGE="${IMAGE:-orcacad-deps}"
# this fork at it makes the two silently trade build artefacts. docker-iter-build.sh had the
# identical defect and was fixed to orcacad_buildcache; this script was missed.
VOL="${BUILD_VOL:-orcacad_kerneltest}"
# ONE pre-existing failure is excluded by default (see [known-broken] in
# test_caddocument.cpp): it SIGABRTs inside the vendored solver and takes the
# whole process down, so without this exclusion a green run is simply unreachable and the
# suite stops after ~12 of 32 cases. It is also tagged [NotWorking], the ctest label the
# mainline fork's CI excludes, so it no longer reddens the Unit Tests job on every commit;
# it stays tracked as snaporca-tkz rather than as CI noise. The internal-thread case that
# used to sit alongside it is gone from this exclusion: its geometry was correct and the
# test's reference was wrong (snaporca-kzy), so it now runs like any other.
TAGS="${TAGS:-[CadDocument]~[known-broken]}"
# No exclusions. Both cases that used to be quarantined now run: the solver SIGABRT on
# circle-line tangency is fixed (snaporca-tkz), and the internal-thread case turned out to have
# correct geometry and a wrong reference in the test (snaporca-kzy). A green run here now means
# the whole CAD suite passed, not "everything except the two we gave up on".
TAGS="${TAGS:-[CadDocument]}"
HOST=""
while [[ $# -gt 0 ]]; do