visionA

jim800121/visionA

Fork 0

Commit Graph

Author	SHA1	Message	Date
jim800121chen	34bc361527	fix(app): Python 相依檢查不得阻斷啟動上一個 commit 讓 Windows 完全開不了：階段 2 直接失敗，「python runtime unavailable: no python runtime available」。根因：健康檢查的 probe 環境與實際跑推論的環境不一致。 `import kp` 在 import 當下就要載入 6 個 native DLL（libkplus / libusb / libwdi 等），這些不在 Windows 預設搜尋路徑。專案裡每一處真正用 kp 的地方都自己補了路徑（kl720_driver.go:142 注入 PATH、platform_windows.go:68 用 add_dll_directory），只有新加的 probe 是裸跑 python -c "import kp"。於是健康的 venv 被判成壞掉 → 重裝 wheels → 用同一個壞 probe 再驗一次 → 仍失敗 → 回 error → 連 app 都進不去。使用者前一天才手動重建好、推論正常的環境，裝上新版就完全無法啟動。修正： - reuseExistingVenv 不回傳 error。venv 存在時的回傳值恆等於舊版（永遠是 pythonBin, nil），要退化成阻斷版必須改簽章，不會不小心發生 - 首次安裝路徑區分致命與非致命：pip 真的失敗才算致命，probe 沒過就放行並記 warning - probe 在 import 前補上 DLL 搜尋路徑，對齊 kl720_driver.go 的實際做法 - 新增 GetPythonDepsWarning binding，讓提示出現在 app 內而非啟動阻斷點原本要解的「wheels 半套安裝永久卡住」仍然有解，但改為非阻斷：修不好也讓使用者進到 app 看見具體原因，而不是擋在啟動畫面外。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 00:18:13 +08:00
jim800121chen	f9fbc778be	fix: input size 優先序錯誤導致 Windows 推論失敗 + venv 半套安裝永久卡住 ## input size 優先序（Windows Error 12 的根因）先前把使用者手填的 inputSize 排在檔名解析之前，Windows 上 SDK 讀不到 shape 時就用了隨手填的 640x640（模型實際 224x224）→ 推論回 KP_ERROR_INVALID_PARAM。改動前靠檔名 fallback 的 224 反而是對的。新優先序（可信度由高到低）： SDK > 檔名明確解析 wNNNhNNN > 使用者宣告 > 已知 model id > 寫死預設檔名排在宣告之前，因為它由編譯工具鏈產生、沒有人為亂填空間；宣告不降到最底，是因為使用者若刻意填對，仍比無資訊時的預設值貼近現實。配套：_size_from_name_or_none 讓「真的解析到」與「用了 default」可區分（舊版兩者回傳型別相同，預設值會偽裝成檔名來源蓋掉宣告值）。 ## KneronPLUS 3.1.2 相容 3.1.2 把 shape 搬進巢狀 union，TensorDescriptor 不再有 shape_onnx： 2.0.0 TensorDescriptor.shape_onnx 3.1.2 TensorDescriptor.tensor_shape_info.data → V1 .shape_onnx / V2 .shape 舊碼 getattr 失敗被 except 靜默吃掉，SDK 層在 Windows 永遠落空。現在兩版都支援，不依賴 enum 版本判斷。 ## Error 12 診斷 KP_ERROR_INVALID_PARAM 對使用者無法理解，現在附上當前 input size 與來源，並針對 declared 來源提示「此尺寸來自手動填寫欄位，請優先確認」。原始錯誤保留不吞。 ## venv 半套安裝 app.go 原本只檢查 python.exe 存在就跳過安裝，導致 wheels 裝到一半中斷後每次啟動都跳過、永遠卡住且無提示，使用者必須手動刪整個 runtime 目錄。改為比對 wheel 清單指紋（快路徑不啟動 process），不符才實跑 import kp/numpy/cv2 驗證，失敗則只重跑 wheels 安裝。標記檔僅在 pip 成功且 import 驗過後才寫入，不留「已就緒」假象。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-22 23:41:19 +08:00

Author

SHA1

Message

Date

jim800121chen

34bc361527

fix(app): Python 相依檢查不得阻斷啟動

上一個 commit 讓 Windows 完全開不了：階段 2 直接失敗，
「python runtime unavailable: no python runtime available」。

根因：健康檢查的 probe 環境與實際跑推論的環境不一致。
`import kp` 在 import 當下就要載入 6 個 native DLL（libkplus / libusb /
libwdi 等），這些不在 Windows 預設搜尋路徑。專案裡每一處真正用 kp 的地方
都自己補了路徑（kl720_driver.go:142 注入 PATH、platform_windows.go:68
用 add_dll_directory），只有新加的 probe 是裸跑 python -c "import kp"。

於是健康的 venv 被判成壞掉 → 重裝 wheels → 用同一個壞 probe 再驗一次 →
仍失敗 → 回 error → 連 app 都進不去。使用者前一天才手動重建好、推論正常
的環境，裝上新版就完全無法啟動。

修正：

- reuseExistingVenv 不回傳 error。venv 存在時的回傳值恆等於舊版
  （永遠是 pythonBin, nil），要退化成阻斷版必須改簽章，不會不小心發生
- 首次安裝路徑區分致命與非致命：pip 真的失敗才算致命，probe 沒過就放行
  並記 warning
- probe 在 import 前補上 DLL 搜尋路徑，對齊 kl720_driver.go 的實際做法
- 新增 GetPythonDepsWarning binding，讓提示出現在 app 內而非啟動阻斷點

原本要解的「wheels 半套安裝永久卡住」仍然有解，但改為非阻斷：修不好也讓
使用者進到 app 看見具體原因，而不是擋在啟動畫面外。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-07-23 00:18:13 +08:00

jim800121chen

f9fbc778be

fix: input size 優先序錯誤導致 Windows 推論失敗 + venv 半套安裝永久卡住

## input size 優先序（Windows Error 12 的根因）

先前把使用者手填的 inputSize 排在檔名解析之前，Windows 上 SDK 讀不到
shape 時就用了隨手填的 640x640（模型實際 224x224）→ 推論回
KP_ERROR_INVALID_PARAM。改動前靠檔名 fallback 的 224 反而是對的。

新優先序（可信度由高到低）：
  SDK > 檔名明確解析 wNNNhNNN > 使用者宣告 > 已知 model id > 寫死預設

檔名排在宣告之前，因為它由編譯工具鏈產生、沒有人為亂填空間；宣告不降到
最底，是因為使用者若刻意填對，仍比無資訊時的預設值貼近現實。

配套：_size_from_name_or_none 讓「真的解析到」與「用了 default」可區分
（舊版兩者回傳型別相同，預設值會偽裝成檔名來源蓋掉宣告值）。

## KneronPLUS 3.1.2 相容

3.1.2 把 shape 搬進巢狀 union，TensorDescriptor 不再有 shape_onnx：
  2.0.0  TensorDescriptor.shape_onnx
  3.1.2  TensorDescriptor.tensor_shape_info.data → V1 .shape_onnx / V2 .shape

舊碼 getattr 失敗被 except 靜默吃掉，SDK 層在 Windows 永遠落空。現在
兩版都支援，不依賴 enum 版本判斷。

## Error 12 診斷

KP_ERROR_INVALID_PARAM 對使用者無法理解，現在附上當前 input size 與
來源，並針對 declared 來源提示「此尺寸來自手動填寫欄位，請優先確認」。
原始錯誤保留不吞。

## venv 半套安裝

app.go 原本只檢查 python.exe 存在就跳過安裝，導致 wheels 裝到一半中斷
後每次啟動都跳過、永遠卡住且無提示，使用者必須手動刪整個 runtime 目錄。

改為比對 wheel 清單指紋（快路徑不啟動 process），不符才實跑
import kp/numpy/cv2 驗證，失敗則只重跑 wheels 安裝。標記檔僅在 pip 成功
且 import 驗過後才寫入，不留「已就緒」假象。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-07-22 23:41:19 +08:00

2 Commits