2 Commits

Include renames

Author	SHA1	Message	Date
Umut CANandClaude Opus 5	e27071ab48	fix(com): except pywintypes.com_error raised NameError without pywin32 ... Python evaluates an `except` clause on the way out of every failed call, not only the ones it is meant to catch. `pywintypes` is bound only when `sys.platform == "win32"` and the import succeeded, so on any host without pywin32 -- all of Linux, and Windows installed without the `[com]` extra -- an ordinary exception leaving `ComBackend._run` hit that clause and became `NameError: name 'pywintypes' is not defined`, burying the real error. Every Linux CI leg failed on exactly this, in test_ordinary_errors_are_unchanged. The timeout tests survived only because they matched an earlier `except`; nothing else in the suite sends a non-timeout exception through `_run`. Fixed with a module-level `_COM_ERROR` tuple: `(pywintypes.com_error,)` where the import worked, `()` where it did not. An empty tuple catches nothing, which is correct when no com_error type exists to be raised -- a placeholder Exception subclass would be worse than the bug, silently swallowing unrelated errors. Reproduced on Windows before fixing by deleting the module attribute, which resolves the name the same way the absent import does; that is now a test, alongside one pinning `_COM_ERROR` as a tuple. Verified through the locked environment CI uses: 1244 passed, 1 xfailed. README test-count snapshot 1243 -> 1245. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-06 10:22:49 +03:00
Umut CANandClaude Opus 5	b03a7615b1	release: v1.5.0 — discovery layer, honesty debt closed, Wave A ... Tool count 131 -> 154; 474 -> 1242 collected tests. The release exists for two measured reasons. A 149-tool catalog costs a client ~40,300 tokens before it has asked for anything, and a drafter searching the way drafters think -- FILLET, BPOLY, QSELECT, WBLOCK -- scored df=0 against the stock index, because those words were simply not in the data. Discovery and batching - DISCOVERY_MODE=search replaces the catalog with search_tools + call_tool, ranked over an AutoCAD command and synonym corpus (discovery/aliases.py) on top of fastmcp's BM25 index. Measured: 40,305 -> 356 tokens advertised. - cad_batch runs a step list in one round trip; fields= projects result-heavy responses. The `core` profile is gone -- discovery replaced it. Honesty debt (Tier 0) - OCS/ECS: `extrusion` appeared nowhere in this codebase, so mirrored and rotated geometry reported coordinates that were quietly wrong. backends/ocs.py translates at the backend boundary; every tool coordinate is WCS on both engines, and a tilted plane refuses rather than answering with a number that looks fine. - drawing_save_as(fmt="dwg") wrote DXF bytes to a .dwg path. drawing_audit never repaired. analysis_measure_area shoelaced points the caller typed in. - ezdxf calls gained a per-call timeout, so one hung call can no longer wedge a server whose document lock is a single asyncio.Lock. Architecture - The 1854-line backend ABC is 19 contract modules; @capability(key, reason=) makes optional methods declarative and a gate fails on undeclared holes. - 8 layout/viewport tools, CHSPACE, CAD_PROGID escape hatch. - Wave A: selection filters, boundary tracing, hatch depth, annotation objects, measurement -- 13 tools of a planned 39. The REGION and 2D-boolean family was cut on evidence: add_region() yields zero ACIS bytes and the greiner_hormann substitute loses 28.2% of the area on a square with one semicircular edge. Verified against a live AutoCAD 2026, which found four COM defects no amount of reading would have caught -- AcadPViewport has no ViewCenter, and the line that set it had been swallowed by a bare except since v1.4. Benchmark v3 (15 tasks) and what it caught - v2 scored this server 10/10, which carried no information: every task in it exercised something the server was built around. Five tasks were added because they can fail, and three did while being written -- a hatch could not be measured though the refusal listed HATCH as measurable, the boundary tools and the measure tool disagreed about the same shape (139.2177 vs 139.2699), and a circle stored as two bulged vertices measured 0.0. - Competitor reports are NOT re-scored. They are pinned v1.4 runs against v2 and were never asked these five questions; the chart shows those rows `not run`. - Correctness A/B: 21/24 -> 24/24, zero regressions. Performance, stated plainly The published v1.4 perf report was recorded on CPython 3.14 and the new one on 3.11.15, so the apparent 2-6x speedup is the interpreter, not this release. Re-measured on one interpreter, v1.5.0 is 28% slower creating entities and 22% slower on the 10k roundtrip. Fully attributed: EZDXF_CALL_TIMEOUT=0 restores v1.4.0's exact numbers. That is the deadlock fix being paid for, the knob is documented, and winning it back is on the 1.6 roadmap. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-06 09:45:20 +03:00