Vim 8.0 issue

工作站的 Vim 8.0 不知為何無法顯示 vimrc 裡設定的語法顯示？

Google 也沒有答案，但在看遍相關關鍵字後，得到以下的解法：

set compatilble

set nocompatible

set hlsearch

將上面三行加到原本的 vimrc 最後面即可，可以多判斷 version 來決定要不要下。

前面兩個 command 解決語法顯示的問題，後面則是切換相容模式後會失效的 command，目前只有發現這個要重設。

NS 暗黑 3 體驗

12 月中旬終於買了暗黑 3，也結束了我長達 3 年多的暗黑 2 生涯！

由於這是個很舊的遊戲了，算上 NS 版也已經是 7 年多前的老遊戲了。

再加上家機版跟 PC 版又有點差異，每個賽季主題也都不同，一時不慎之下，走了好多冤枉路，玩個遊戲嘛，又不想很認真 Google，哈。

還是記錄一下過程，免得以後忘記，雖然不太可能再開荒一次了，暗黑 3 把遊戲複雜化了，整體來說，個人還是覺得暗黑 2 好玩。

01. 可以直接冒險模式開局，不用先玩故事模式，因為有祭壇，應該可以苦痛一開局。

02. 祭壇可以不用照順序點，只要想點的節點有跟前一個相連即可，我就是那個由左往右依序點的苦主。

03. 連環戒打到一定要留一個，之後重鑄好方便出遠古。

04. 打不到牧牛杖圖紙，可以考慮戴拿各，豹女則是回故事模式。

05. 裝備詞條比較重要，每個 build 都有要注意的事。

06. 戰馬天拳流，大概巔峰 850 以上就可以 5 分鐘內刷完 100 層，只要裝備齊全，詞條不要差太多，打卡一兩件而已。

07. 上面的條件硬打可以打到 110 層，但是要小心一點就是了。

暗黑 2 真的要畢業了？

自從升上 99 後，玩遊戲已經不太提得起勁了？

雖說如此，去年還是練了一支火法，上個月又練了一支冰法XD

原本是想讓這支冰法用火弩 build，但是只有 87 等玩起來很怪，又很容易死？

最後改用 96 小老婆冰法玩火弩 build，原本的 87 等冰法再換回來。

目前 Bo 完，攻擊力為 13 ~ 16K，全身上下只有一顆 +- 4 的火珠以及滿變的閃爍火焰，配合米山的無限，8 人難度還是可以一玩。

目前暗黑 2 總時數來到 2525 左右，雖然全部大概買了 7 ~ 8 片的遊戲，第 2 時數多的遊戲應該也是玩不到 2 個小時？

有點考慮要買暗黑 3 了，老了不適合唸書了，想看書又會被看電視的老婆干擾，詩海石硯台的隱居處氛圍已蕩然無存XD

一直跟 AI 都相處不來，請他寫的程式或函數都不如自己寫來的快？

趁著連續兩個星期三上天龍國的機會買了兩本 LLM 相關的書，希望可以再給 AI 一次機會XD

雖說用 Python 寫 Code 很快，這一年工作寫到的程式，每個 py 也沒超過 1000 行，但怎麼看都像用 Python 寫 C code？

看著看著，心也累了，天涯何處是吾家呀？

花了一千多塊買了一本 Python 書，無聊就來翻翻吧XD

不知不覺，手上的 Python 書加起來應該已經超過 Golang 了？

2026/01/12 更新

12 月中旬購買了暗黑 3 後就沒開過暗黑 2 了！

最後一次玩暗黑 2 時，終於掉了塔拉夏漆甲，誰知道倉庫居然找不到頭盔？無奈之下查了一下掉落率，看起來應該惡夢墨菲斯托最容易掉落，打寶率 20X 左右打了好幾場都沒看到死亡面具類別的掉落，改試了一下 3C，馬上看到該類物品，再打個幾場果然順利掉落。

終於我也穿上了全套裝備，以火法來說，傷害等級大概掉落了好幾級，不過看在打寶率的份上，還是幫它打了一個洞，我也有了除了槌丁以外的打寶手段。

巡田水 again

最近 Kobo 工程師很乖，沒有亂改 HTML 碼XD

看一下 github 修改記錄，上一次修改已經是半年前的事了。

很好，請 Kobo 繼續保持，這樣我才有動力繼續在這裡買書XD

STDF Format

STDF 是個很有趣的檔案格式，它常用在儲存 ATE 的測試資料。

對於寫 C code 的人來說，可以很簡單的用 fread + structure 的方式無腦 parsing。

它的 Hex 資料如上圖，這裡只框出前 5 筆 record。

每一筆 record 都帶有 4 個 byte 的 header，前兩個 byte 是 REC_LEN，後面兩個 byte，一個是 REC_TYP，另一個是 REC_SUB，header 後面就是帶有 REC_LEN 長度的資料。

一個橘色框框的是一筆 record，淺藍色的就是 REC_LEN，深藍色的是 REC_TYP + REC_SUB，沒有底線的就是該筆 record 的資料組成。

我們可以由 REC_TYP + REC_SUB 得知 record 的種類。

Spec 中也很貼心的用 C code 表達不同資料的解碼方式。

我們以第一筆 FAR record 為例，CPU_TYPE 欄位 = 0x02，屬於 IBM PC 的處理器，故其大於 1 byte 資料的順序為 Little Endian，比如說 REC_LEN 在解碼時，就必須反過來看。

隨便使用 STDF parser 當關鍵字在 github 搜尋就有 3 頁的程式碼可以參考，各類程式語言應有盡有，挑自己喜歡的來使用即可。

就像前面說的，C code 跟這種檔案格式很搭，故要快速得到一個結果，找 C code 的專案就對了。

2025/12/06 更新

剪頭髮時，因為等待的人數太多，看了一下 spec，終於知道如何分辨最新版本。

原本 FAR 的 STDF_VER 只有一個 byte，如果是 V4 其值等於 4。

而最新的版本為 V4-2007，因為版本號並沒有進位，故無法用一個 byte 來表示。

取而代之的是多了一筆 00 30 的 VUR record，他的 UPD_NAME 欄位是一個 char []，其值為 "V4-2007" 字串。

換句話說，即使沒有 STDF parser，直接打開檔案搜尋此字串即可。

另外，我有一個很奇怪的疑問，我發現我為了快速驗證用的 C library 在處理 D*n 時，有考慮到未滿 8 bit 的情況，故長度會 + 1，但網友用這個 C library 寫的 dumper，在 print_Dn 時犯了錯誤，並未印到後面 2 個 byte，但我印象在我修正 Code 後，辦公室的 Code 反而會當機，難道是我記錯了？

偏偏網路上都沒有 D*n 的 STDF 檔案可以驗證，真是好奇心殺死螞蟻呀XD

2025/12/13 更新

知道 Record 有所謂的 optional field，但從每個 Record 卻看不出來？

回過頭看前面的說明才知道，原來每個 Record Table 後面 Missing /  Invalid Data Flag 有描述的就表示是可選欄位，跟這個欄位一樣的值就表示該值沒有意義，可以忽略，但該欄位還是要存在，除了 Record 最後面的可選欄位。

另外，Initial Sequence 是必須要有的 Records，除了位在 STDF 檔案最前面外且順序如下圖。

總之，github 既然都有現成的專案可用，個人覺得了解到這樣就夠了。

Tcl 一些備忘

最近又開始用 Tcl 做一些事，之後應該會一直更新這篇。

01. array 傳遞方式

簡單來說，分別用 array get 以及 array set 來處理。

array get -> list -> array set。

02. exec 外部程式，比如 grep sed 等技巧

避免 regex 跳脫太複雜，把 regex 用 { } 包住即可。

03. Tcl 8.5 dict + upvar

從 Tcl 8.5 開始，有 dict 可用，配合 upvar 使用，array set 也可以比照辦理。

04. { } 裡面可以有 { }，不需要跳脫

exec echo 123 456 | awk {{print $1}}

05. 使用 grep 最好的方式

最好的方式就是不要用 grep，改用 sed。

因為 grep 天生遇到沒有匹配的情況會回傳 1，這會導致我們需要對結果做些事，才不會顯示 child process existed abnormally。

rm 恐慌症

雖然在工作站只有一般的權限，但因為自己寫的程式沒有地方可以 push，還是有點害怕自己在清理暫存檔時，無意間把自己的程式碼誤刪了！

昨天下班時突然想到，乾脆自己寫個簡單的 script 用 timestamp 來備份，每天早上的第一 build 便作檢查，如果當天還未備份過被順便備份，如果某天要大動刀程式碼時，也可以手動備份。

這樣應該還行吧？暫時我也沒有更好的辦法了。

順便記錄一下這個星期學到的新東西，原來 c shell 的 .rc 檔有順序性，比如 .tchsrc 已經存在，便不會再去管 .cshrc！

想想也是很合理，畢竟工作站的 /bin/csh 是 link 到 /bin/tcsh 無誤！