fix(closet_llm): replace non-ASCII symbols in progress output (#1034) - #1100
Conversation
f70ba83 to
4d567a4
Compare
|
Rebased on latest develop. The |
4d567a4 to
bec1f6e
Compare
|
Friendly ping — this one's been quiet for a week. CI is green across all 6 checks (linux 3.9/3.11/3.13, windows, macos, lint), branch is merge-clean, last activity was the rebase on 2026-04-23. Happy to adjust anything if you'd like changes. |
|
Second ping after a week. CI is green across all 6 checks (linux 3.9/3.11/3.13, windows, macos, lint), branch is merge-clean, no merge conflicts despite 100+ commits landing on develop since. @igorls — looping you in given you've been active on the encoding cluster (#1214/#1215 merged yesterday, #1373/#1371 follow-ups in flight as #1408/#1409 today). This one is the narrow closet_llm.py slice; #1104 is the broader sweep that closes #1034. Happy to fold this into #1104 and close #1100 if that's cleaner, or rework either approach if a different direction would land better. |
|
Rebased on |
bec1f6e to
91bf9b8
Compare
|
Friendly ping — post-3.3.6 release this is still mergeable on |
…ace#1034) GBK consoles (Windows PowerShell/CMD default) cannot encode U+2713 (✓), U+2717 (✗), and U+2014 (—). The same class of UnicodeEncodeError fixed in miner.py via MemPalace#681 affects closet_llm.py and cli.py. Replace with ASCII equivalents: [OK], [FAIL], [!], and hyphen.
91bf9b8 to
29db125
Compare
What and Why
closet_llm.pyprints✓,✗, and—(U+2713, U+2717, U+2014) duringmempalace closets regen. These characters cannot be encoded in GBK (Windows PowerShell/CMD default), causingUnicodeEncodeErroron the same code path fixed inminer.pyvia #681.cli.pyhas the same problem on thesweeperror path (✗).Root Cause
closet_llm.py:244——in dry-run bannercloset_llm.py:266—✗+—in LLM-failed messagecloset_llm.py:303—✓+—in success messagecli.py:187—✗in sweep error messageChange Summary
Replace non-ASCII symbols with ASCII equivalents:
[OK],[FAIL],[!], and-.Test Plan
ruff checkcleanCloses #1034