From 8b0ea9c00d11b11582030dd7418574a494e2e791 Mon Sep 17 00:00:00 2001 From: Alex Zhou Date: Sat, 10 Oct 2026 17:45:46 +0800 Subject: [PATCH] =?UTF-8?q?windows:=20fix=20issue=20#128=20=E2=80=94=20con?= =?UTF-8?q?verter=20path=20robustness,=20ASCII-safe=20output,=20engine=20v?= =?UTF-8?q?ersion=20probe,=20dependency=20preflight?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fresh-install validation by @Lexlangel (issue #128) reported four repo-level issues on Windows 8B; all four are addressed (internal ledger commit f442324): - cross-check gate base path: verify_against_base() hardcoded /windows/models/... while the app converts into ~/.edge0/models, so the GUI Download->Convert path hit FileNotFoundError on end-user machines (a dev repo's local models/ masked it). The base GGUF path is now an explicit argument; the converter passes its own --out artifact as --base, standalone runs derive the conventional -gguf sibling. Missing base fails with an E-BASE-MISSING line pointing at --base. - Windows console output: every non-ASCII glyph in converter-chain print lines (-> ⇒ ✔ × ·) is replaced with ASCII, and the five entry points reconfigure(sys.stdout, utf-8/backslashreplace) as a guard. The app pipes the converter's stdout, where Python falls back to the ANSI code page — U+2192 in the final DONE line raised UnicodeEncodeError after an otherwise successful conversion (issue #128 report 4). Codec-level tests: cp1252-strict reproduces the crash, pure ASCII always passes, reconfigure rescues. - engine version probe: failures were cached in a OnceLock