Fix taking-fire ally misclassification; Windows build fixes; Field Gun
OCR (src/fenigma/ocr.py):
- A "taking fire" report's reporting unit was added as a hostile Target,
not a friendly Ally -- no "Friendly"/"Hostile" prefix word exists in
that grammar for the usual inference to key off of, so it silently
defaulted to not-ally. Fixed with an explicit force_ally override
(_TAKING_FIRE_RE), and the shell/deadline (which an Ally tuple has no
fields for) now always splits into a synthetic StrikeRequest target at
the reporting position, even for the no-offset "on our position" case
that previously kept them on the entity itself.
- "Enemy <Type>#<id> Destroyed" kill-feed lines were silently dropping
for shorter/less distinctive type words (e.g. "Enemy Field Gun#1") --
_ALLY_PREFIX_RE only ever stripped "Friendly"/"Hostile", never
"Enemy", so the whole "EnemyFieldGun" token got alias/fuzzy-matched
against "Artillery" and missed by a mile. Longer type words
("Enemy Mechanized Infantry#2") only ever worked by fuzzy-match
accident. Now strips "Enemy" too (lookahead guards a BARE "Enemy#N"
report, which IS TargetType.ENEMY itself, from being stripped to an
empty, unresolvable string).
- "Field Gun" added to _TYPE_WORD_ALIASES as plain Artillery under
another name (confirmed by the user), not a missing unit type.
7 new/updated regression tests, 54 total passing.
Windows build (packaging/windows/): three real bugs found and fixed by
actually booting and driving the build VM live (VNC), not just guessing
from the README's "UNTESTED end to end" note:
- install.bat's MSYS2/WiX provisioning previously left NOTHING behind
once C:\OEM stopped existing (a 2-day-old BUILD_REQUEST sat unclaimed
the whole time) -- the build.bat/watch_build.bat persistence fix
(C:\FenigmaBuild instead of C:\OEM) is real and now confirmed live:
after a full container restart, the watcher auto-starts on login and
picks up a pending request with zero manual intervention.
- pip install pytesseract needs --break-system-packages (MSYS2's
mingw64 Python enforces PEP 668).
- mingw-w64-x86_64-opencv is the C++ library only; the actual Python
bindings are the separate mingw-w64-x86_64-python-opencv package,
never in install.bat's dependency list.
With all three, import fenigma.app succeeds and a real build attempt
gets through source copy, sanity check, dist-tree assembly, and WiX
harvest+compile -- further than this pipeline has ever gotten. Full
findings, including the still-open light.exe timeout and the OCR
multi-shell/deadline-phrasing/phantom-header gaps found along the way,
logged in TODO.md.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Claude Sonnet 5
@@ -57,7 +57,7 @@ if errorlevel 1 (
|
||||
exit /b 1
|
||||
)
|
||||
|
||||
copy /y C:\OEM\product.wxs C:\build\product.wxs >nul
|
||||
copy /y C:\FenigmaBuild\product.wxs C:\build\product.wxs >nul
|
||||
|
||||
echo [build.bat] compiling (candle) ... >> %LOG%
|
||||
C:\wix\candle.exe -dDistDir=C:\build\dist -dAppVersion=%APPVER% -out C:\build\ C:\build\product.wxs C:\build\files.wxs >> %LOG% 2>&1
|
||||
|
||||
@@ -18,6 +18,24 @@ REM besides silence during the one-time provisioning run.
|
||||
setlocal enabledelayedexpansion
|
||||
call :log "starting FEnigma build-VM provisioning"
|
||||
|
||||
REM -- Stage the OTHER oem/ files somewhere that outlives C:\OEM itself,
|
||||
REM done first, before anything else. Confirmed on a real run: C:\OEM
|
||||
REM (dockur's /oem copy target) does NOT reliably persist once Windows
|
||||
REM Setup finishes and you're at the desktop -- it's fundamentally a
|
||||
REM Windows Setup-time staging mechanism ($OEM$ folders, copied by WinPE
|
||||
REM "right after the Windows image is applied ... and before the first
|
||||
REM reboot" per Microsoft's own docs), not guaranteed permanent storage,
|
||||
REM and in practice `dir C:\OEM` came back "File Not Found" once actually
|
||||
REM checked from an interactive desktop session. build.bat/product.wxs/
|
||||
REM watch_build.bat all get referenced again AFTER install.bat's own
|
||||
REM process has exited (by the Startup-folder entry below, potentially
|
||||
REM much later), so they need a home install.bat itself controls and
|
||||
REM knows persists -- a plain folder on C:, not the OEM staging area.
|
||||
mkdir C:\FenigmaBuild 2>nul
|
||||
copy /y C:\OEM\build.bat C:\FenigmaBuild\build.bat >> C:\OEM\install.log 2>&1
|
||||
copy /y C:\OEM\product.wxs C:\FenigmaBuild\product.wxs >> C:\OEM\install.log 2>&1
|
||||
copy /y C:\OEM\watch_build.bat C:\FenigmaBuild\watch_build.bat >> C:\OEM\install.log 2>&1
|
||||
|
||||
REM -- MSYS2: the "base" self-extracting archive, not the GUI installer --
|
||||
REM (the GUI installer has no reliable non-interactive/silent flag across
|
||||
REM versions; the base sfx archive is what CI pipelines actually use).
|
||||
@@ -47,10 +65,23 @@ C:\msys64\usr\bin\bash.exe -lc "pacman -Syuu --noconfirm" >> C:\OEM\install.log
|
||||
C:\msys64\usr\bin\bash.exe -lc "pacman -Syuu --noconfirm" >> C:\OEM\install.log 2>&1
|
||||
|
||||
call :log "installing GTK4/libadwaita/PyGObject/build deps ..."
|
||||
C:\msys64\usr\bin\bash.exe -lc "pacman -S --noconfirm --needed mingw-w64-x86_64-python mingw-w64-x86_64-python-pip mingw-w64-x86_64-python-gobject mingw-w64-x86_64-gtk4 mingw-w64-x86_64-libadwaita mingw-w64-x86_64-python-numpy mingw-w64-x86_64-python-pillow mingw-w64-x86_64-opencv mingw-w64-x86_64-tesseract-ocr" >> C:\OEM\install.log 2>&1
|
||||
REM mingw-w64-x86_64-opencv is the C++ library ONLY -- confirmed live on a
|
||||
REM real VM that `import cv2` fails without it, the actual Python bindings
|
||||
REM are the separate mingw-w64-x86_64-python-opencv package. Don't try to
|
||||
REM paper over a missing one with `pip install opencv-python-headless`
|
||||
REM either: MSYS2's mingw64 Python uses a different ABI than PyPI's Windows
|
||||
REM wheels (cp3XX-mingw_x86_64_msvcrt_gnu vs win_amd64), so pip can never
|
||||
REM use a prebuilt wheel there, only build from source, which then needs a
|
||||
REM full separate native toolchain (ninja/cmake/gcc) this VM doesn't have.
|
||||
C:\msys64\usr\bin\bash.exe -lc "pacman -S --noconfirm --needed mingw-w64-x86_64-python mingw-w64-x86_64-python-pip mingw-w64-x86_64-python-gobject mingw-w64-x86_64-gtk4 mingw-w64-x86_64-libadwaita mingw-w64-x86_64-python-numpy mingw-w64-x86_64-python-pillow mingw-w64-x86_64-opencv mingw-w64-x86_64-python-opencv mingw-w64-x86_64-tesseract-ocr" >> C:\OEM\install.log 2>&1
|
||||
|
||||
call :log "pip install pytesseract (pure python, no wheel needed) ..."
|
||||
C:\msys64\mingw64\bin\python3.exe -m pip install pytesseract >> C:\OEM\install.log 2>&1
|
||||
REM --break-system-packages: MSYS2's mingw64 Python enforces PEP 668
|
||||
REM ("externally-managed-environment"), confirmed live -- a plain
|
||||
REM `pip install` here fails outright without this flag. Safe here: this
|
||||
REM VM's whole mingw64 Python install exists only to run FEnigma, there's
|
||||
REM no system package manager relying on it staying untouched.
|
||||
C:\msys64\mingw64\bin\python3.exe -m pip install --break-system-packages pytesseract >> C:\OEM\install.log 2>&1
|
||||
|
||||
REM -- WiX v3 toolset (candle/light/heat), a plain zip of standalone exes,
|
||||
REM no installer needed. Fixed versioned URL, no scraping required.
|
||||
@@ -72,8 +103,8 @@ REM SYSTEM task with no session of its own. Startup-folder entries run
|
||||
REM in whichever user's session actually logs in, inheriting their
|
||||
REM drive mappings correctly.
|
||||
call :log "registering build watcher (Startup folder) ..."
|
||||
copy /y C:\OEM\watch_build.bat "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\FenigmaBuildWatcher.bat" >> C:\OEM\install.log 2>&1
|
||||
start "" cmd /c C:\OEM\watch_build.bat
|
||||
copy /y C:\FenigmaBuild\watch_build.bat "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\FenigmaBuildWatcher.bat" >> C:\OEM\install.log 2>&1
|
||||
start "" cmd /c C:\FenigmaBuild\watch_build.bat
|
||||
|
||||
call :log "provisioning done"
|
||||
echo DONE > C:\OEM\provisioned.marker
|
||||
|
||||
@@ -1,5 +1,8 @@
|
||||
@echo off
|
||||
REM Runs persistently from system boot (see install.bat's scheduled task).
|
||||
REM Runs persistently from login (see install.bat's Startup-folder entry --
|
||||
REM this file itself gets copied to C:\FenigmaBuild\ and to the Startup
|
||||
REM folder by install.bat, not run from C:\OEM, which does not reliably
|
||||
REM survive past Windows Setup finishing, see install.bat's own note).
|
||||
REM Polls the host-shared Z:\ drive for a build request and, when one
|
||||
REM shows up, runs build.bat against it. This is what lets build_windows.sh
|
||||
REM on the Linux host trigger a build without any RDP/remote-exec: it's
|
||||
@@ -17,14 +20,14 @@ if not exist Z:\ (
|
||||
if exist Z:\BUILD_REQUEST (
|
||||
REM Claim the request before acting on it -- if watch_build.bat somehow
|
||||
REM ended up running twice this boot (install.bat starts it once
|
||||
REM immediately, the ONSTART task could also fire the same boot), only
|
||||
REM immediately, a fresh login could also start another copy), only
|
||||
REM one of them wins this move and actually builds.
|
||||
move /y Z:\BUILD_REQUEST Z:\BUILD_REQUEST.claimed >nul 2>&1
|
||||
if exist Z:\BUILD_REQUEST.claimed (
|
||||
del Z:\BUILD_REQUEST.claimed
|
||||
del /q Z:\BUILD_DONE 2>nul
|
||||
del /q Z:\BUILD_FAILED 2>nul
|
||||
call C:\OEM\build.bat
|
||||
call C:\FenigmaBuild\build.bat
|
||||
)
|
||||
)
|
||||
timeout /t 5 /nobreak >nul
|
||||
|
||||
Reference in New Issue
Block a user