DreamBBS issue list

具體問題

acct_save() 有 6 個，待合併

問題敘述 (solved by 4a1da1733)

有六個 acct_save()。

IID2019_08_22

將 system() 全面取代成 execl()/execv()

需要的 piping 機制的程式碼參考

之後應該把所有的 system() 取代成 execl()/execv()，然後用 C 操作 IO redirection 和 piping。
https://stackoverflow.com/questions/8082932/connecting-n-commands-with-pipes-in-a-shell IID2019_08_22

無用的 NULL 指標判定

問題敘述 (solved by dfd63a5a91)

while (p != NULL)
{
    free(p);
}

IID2019_09_22 (Sun) 21:16 UTC+8

看板列表中的 [y]載入 字樣需要調整

問題敘述 (solved by a2e1d4a163)

話說為何按鍵說明欄中有 [y]載入？ IID2019_10_18

解決 util/utmp-dump.c 與 maple/talk.c 的內容重複

方案構想

#50: sync or merge content util/utmp-dump.c and maple/talk.c 的部分： IID2020_02_24

1. 建立可以放不同程式共用的函數庫的目錄 common/ (放在 lib/ 下也可)
2. 從 visio 分離出可獨立運作的 visio_core 移到 common/ 下。
   • 要增加 visio.h
3. 改進 xover，將 xover 分離出可獨立運作的 xover_core 移到 common/ 下。
   • 要增加 xover.h
4. 將 taik.c 與 utmp-dump.c 中的相似函數合併成 ulist 移到 common/ 下。

more() 的回傳值的處理的問題

問題敘述 (solved by 5be2e80317)

發現 DreamBBS 有幾個判斷 more() 的回傳是否為 -2 的地方，但是 more() 的回傳值不可能是 -2。
MapleBBS 3.xx 的 KEY_UP 值是 -1，而 KEY_LEFT 值是 -2。不過 DreamBBS v1.0 時被我改回正數。
DreamBBS 從 DreamBBS-2010 的 more.c 就是 itoc 版本的，當不被處理的按鍵是特殊按鍵時 (當時是 < 0)，會改回傳 'q'。
所以我拿了 WindTopBBS 3.02 rev.20040420 的 more.c 比較，發現原本在 KEY_LEFT 及 'q' 時，more() 會回傳 -2。

原本的邏輯是如果拿到 -2 就要在外面重繪畫面，但是 itoc 版改成離開呼叫 more() 的函式前一律重繪畫面。

IID2021_01_13 23:38 (Wed) UTC+8

在我的最愛按下 c 的問題

問題敘述 (solved by ff5378cd9b)

在我的最愛按下 c 會變更 necker 的顯示，但是沒作用。 IID2021_04_03

要去看板清單切換，再到我的最愛才會出現變化。 IID2021_04_03

修正 ulist_fromchange() 中的 buffer 大小不同步的問題

不確定有沒有 solved 的 r22021_04_07 (Wed) 00:30 UTC+8

問題敘述 (solved by f16570462e)

大小不同步了。

IID2021_04_03

Xover 清單翻頁時的游標清除問題

問題敘述 (solved by e330cfcf9)

游標進行跳躍時，如果向下翻頁，清除此前游標時會誤清到清單項目以上的行。

IID2021_04_08 (Thu) 18:16 UTC+8

i 是 【 Big5 碼的後半位元。 IID2021_04_08 (Thu) 18:27 UTC+8

然後因為開啟了光棒選單系統，清除游標時會把項目變暗，結果讓最上面的標題列也變暗。 IID2021_04_08 (Thu) 18:28 UTC+8

大概知道問題了。
xo_thread() 內部在找到項目時會自己設定游標，然後回傳 XO_MOVE + XO_REL (使游標相對移動 0 個選項) 代表有找到，並讓 xover() 移游標，並且要換頁的時候會再加上 XR_BODY 讓 xover() 重繪列表。
因為 xover() 會先移動游標再重繪畫面，但是 xo_thread() 已經設定過游標位置了，所以移動游標時就沒偵測到游標已換頁，結果就清到 header 及 necker 上，然後又因為只重繪 body (列表內容)，所以就沒畫回去。 IID2021_04_11 (Sun) 17:49 UTC+8

找到正確的問題所在了。
前面的猜測是錯誤的，因為 xover_cursor() 在游標目的地為目前游標位置時，會略過重繪游標 (所以 XO_MOVE + XO_REL + 0 無實際效果)，所以問題不在此。
問題在於 xover_key() 中處理呼叫 xo_thread() 後清除游標的地方，沒有考慮到翻頁的問題，所以會無條件清除游標，造成會清到列表外面的問題。 IID2021_04_12 (Mon) 02:38 UTC+8

被這個 commit 改壞的。
原本 xo_thread() 是未找到文章時回傳 XO_NONE，翻頁時回傳 XO_BODY，而未翻頁時回傳 -1。
這個 commit 將 xo_thread() 改成未找到文章時，有在 footer 上畫東西時回傳 XO_FOOT，否則回傳 XO_NONE；翻頁時回傳 XR_BODY + XO_MOVE + XO_REL，而未翻頁時回傳 XO_MOVE + XO_REL。
xover() 原本只在 -1 時清除游標，但是這個 commit 改成只要回傳的 Xover 命令包含移動命令就清除游標，所以才造成了這個問題。
https://github.com/ccns/dreambbs/commit/4940e01306d24fb244154383e9bfaee20c3898f1 IID2021_04_12 (Mon) 03:20 UTC+8

尚須實作調整畫面大小時的自動重繪的畫面

詳細清單

• 進站畫面 (6f8cd3e5aa)
• 編輯器
• Maple3 more
• pmore

IID2021_04_11 (Sun) 05:15 UTC+8

整理位元清除的運算式

問題敘述

不要一直用 XOR 來清除位元旗標。 如果確定資料寬度不超過 int 的話，最好用 &= ~BFLAG。

IID2021_04_12 (Mon) 13:18 UTC+8

因為 C 與 C++ 的算術運算子只接受寬度至少為 int 的運算元，如果運算元比 int 窄就會被整型提升為 int/unsigned int。 IID2021_04_12 (Mon) 13:33 UTC+8

要安全一點就先把 BFLAG 轉成 unsigned long long。
uintmax_t IID2021_04_12 (Mon) 13:40 UTC+8

或是寫成 flags &= ~((flags & 0) | BFLAG)。 IID2021_04_12 (Mon) 15:17 UTC+8

再硏究了一下，精確的狀況是：
用 x & ~y 清除位元時，只有在 y 的寬度 > x 且 y 是至少 unsigned int 寬的無號整數型別時，才會因爲 y 沒有 sign extension 而產生錯誤結果。
所以用 x & ~((x & 0) | y) 或是 (x | y) ^ y 才能確保萬無一失。
或是改用 Go 的 &~ 運算子 IID2022_03_14 (Mon) 15:04 UTC+8

C 與 C++ 的 bit clear 不能直接寫 x &= ~y。如果遇到 x 的型別是 int64_t 而 y 的型別是 uint32_t 之類的情況的話，就會因爲 ~y 沒有 sign extension 而出錯。得寫成 x &= ~(0 ? x : y) 來手動 promote 爲較寛的型別再取位元反相才行。
另外，C 與 C++ 的有號整數轉型成較寬的整數時，無論目標型別是有號還是無號，都會經過 sign extension，所以只要留意以上的情況就行。
Rust 遇到異型位元運算會直接擋住編譯，沒這問題。 IID2023_12_04 (Mon) 20:19 UTC+8

修正標題列的中央標題過長的處理

問題敘述

IID2021_04_24 (Sat) 06:31 UTC+8

修正排行榜在主選單上的名稱不符合內容的問題

問題敘述 (solved by a88a01fd,參考批踢踢實業坊類似功能修正用字)

這個不是上站次數排行榜。

IID2021_04_26 21:39 UTC+8

CAN_POSTFIX 的問題

問題敘述

IID2021_04_27 (Tue) 17:55 UTC+8

CAN_POSTFIX 定義時，是不是應該要讓使用者可以選擇預設文章類別才對？ IID2021_04_27 (Tue) 17:56 UTC+8

§ CAN_POSTFIX 這個名字害我誤以爲它與寄信有關。
　但看了它的相關註解，它被定義的作用應該是能夠呼叫 select_title() 進而允許使用者選擇文章類別標籤 (allow choosing the article category tag; can choose post prefix?)。
　雖然這段程式碼在 CAN_POSTFIX 定義時的語法是錯誤的，會造成建置失敗。 IID2022_01_15 (Sat) 23:09 UTC+8

要叫什麼好呢？ IID2022_01_15 (Sat) 23:13 UTC+8

• ALLOW_CHOOSING_ARTICLE_CATEGORY_TAG (?)
• HAVE_SEL_POSTTAG
• HAVE_SEL_POSTTYPE
• …

使用者名單的按鍵與 Xover 列表預設按鍵衝突

問題敘述

@r2 你的 p 撞到呼叫器了。

IID2021_04_30 19:51 (Fri) UTC+8

https://github.com/ccns/dreambbs/commit/550deb4b30ab209c920799611976d22f55c3a052#diff-857e64831907733ab494766591e0c1271cfd66886bb19d5452da70cebb6ca921
原來，本來只是想說要用 jk 所以順便的 r22021_04_30 19:54 (Fri) UTC+8

我覺得 p 與 n 不要用來移動。 IID2021_04_30 19:52 (Fri) UTC+8

可以啊 r22021_04_30 19:54 (Fri) UTC+8

不然就要把 Xover 的 KeyFuncList 按鍵變成優先於 Xover 預設按鍵。
但這樣怕被亂設定。 IID2021_04_30 19:52 (Fri) UTC+8

n 與 p，我記得是從前 PirateBBS 不支援方向按鍵而用的。
但是太不直覺。 IID2021_04_30 19:52 (Fri) UTC+8

previous next 可以這樣理解吧 r22021_04_30 19:58 (Fri) UTC+8

上上下下時很不方便。 IID2021_04_30 19:58 (Fri) UTC+8

又不會拿來打音樂遊戲 (X
不過既然有衝突，加上沒多少人用
就丟掉吧 r22021_04_30 19:58 (Fri) UTC+8

j 塞了。

IID2021_04_30 22:42 (Fri) UTC+8

無法自動踢除閒置訪客

問題敘述 (未再遭遇)

爲何 guest 能一直佔著？

IID2021_04_30 22:51 (Fri) UTC+8

https://github.com/ccns/dreambbs/commit/d164a323758e4db1b85543fb5a7e5a6b775140d4 是不是這個沒弄好? r22021_04_30 22:53 (Fri) UTC+8

[中略……]

bbsd 會加預設 userlevel。
只是 guest 的 cuser.userlevel 在登入時的瞬間會成爲 0。
但是隨後就不再 0 了。
用是不是 0 判斷身份是不對的。 IID2021_04_30 23:00 (Fri) UTC+8

再仔細看了 bbsd，發現不是這個問題。用 gdb 驗證發現是可以觸發閒置踢 guest 的，所以應該另有原因。
程式邏輯上是閒置達到 56 分鐘時警告；閒置達到 60 分鐘時踢人。
不過因爲每次鍵盤輸入逾時時，逾時時間會增加 1 分鐘，所以如果登入後直接閒置的話，理論上會在閒置達到 66 分鐘時直接被踢。 IID2021_09_15 05:44 (Wed) UTC+8

在編輯器中的原始文字模式中，雙位元組字元後的 ANSI 控制碼會被誤判爲雙位元組字元

問題敘述與構想 (solved by b6f6e6e744 & a2bffc7150)

因爲編輯器程式用以取得 DBCS 狀態所呼叫的 str_nstate_ansi()，其中用以忽略 ANSI 控制碼而呼叫的 str_nmove_ansi()，被設計爲內部游標初始位置位於 ANSI 控制碼的非 ESC 字元上時，其結果並沒有特別定義。

正確做法是在非 ANSI 預覽模式下改呼叫 str_nstate() 以取得 DBCS 狀態。

IID2021_05_06 (Thu) 02:55 UTC+8

str_nmove_ansi() 有會導致越界存取的情況

問題敘述 (solved by 1a0838a9c4)

內部游標往後移動時，在最後處跳過 ANSI 控制碼時，讀取字元的時候沒有確認是否已到達字串結尾。

IID2021_05_06 (Thu) 17:48 UTC+8

個人上站紀錄的在 pmore 顯示時的不正確的換行

問題敘述

因爲換行符號被填到了橫座標爲畫面的半形字元寬度 - 1 處，而 pfterm 在此時會進行自動換行，導致實際顯示時多出一個空行。

IID2021_05_06 (Thu) 18:15 UTC+8

Esc- 瀏覽器端雙位元字自動重複按鍵的過濾不正確

問題敘述 (solved by 0db749149b & 95fc710dd2)

如果使用者快速按下 Esc 、Right，而瀏覽軟體因爲全形字偵測而送出 Esc、Right-Right 時，伺服器端應該要判斷爲單個 Esc-Right。 但在目前的夢大上會判斷爲 Esc-Right、Right，而自動重複送出的 Right 沒被濾掉。 IID2021_06_18 (Fri) 03:29 UTC+8

cleanrecommend.c 的推文解析不正確

問題敘述 (solved by 599fbaf999 & 0a4a688c58)

IID2021_11_13 (Sat) 14:26 UTC+8 推文編輯壞掉了。
看來 so/cleanrecommend.c 該重寫了。 IID2021_11_13 (Sat) 14:27 UTC+8

要改成沒有推文也允許使用 o 進入推文編輯介面。
因爲 DreamBBS v3 Xover 支援空清單 (用 XO_POSF 標示需要非空清單的操作按鍵)，所以可以簡單地做到。 IID2021_11_13 (Sat) 18:49 UTC+8

看板目錄的敘述文字顯示不正確

問題敘述 (solved by 2bd076be2b)

r22021_11_18 (Thu) 21:15 UTC+8

r22021_11_18 (Thu) 21:16 UTC+8 你有空再研究發生什麼事了@@ r22021_11_18 (Thu) 21:16 UTC+8

這個造成的嗎？

IID2021_11_18 (Thu) 22:14 UTC+8 因爲我是直接 hardcode 長度的，沒考慮到會切到字。
應該是中文敘述的第一個字元被切了。 IID2021_11_18 (Thu) 22:15 UTC+8

看板分類列表的看板數量計算問題

問題敘述

WindTopBBS 顯示看板分類時，會用 DFS 計算分類目錄中的看板數量，並隱藏沒有看板的目錄。
這有兩個缺點： ⒈ 計算繁重 ⒉ 如果遇到分類目錄有以下狀況（注意：這種目錄配置是能直接在 MapleBBS 3 系統上製作出來的）： - @class - @a - @b - @b - @a 就會進入無窮迴圈。

• 可能的解決方法之一，是在建立看板映像時，就以 BFS 求得分類目錄中的看板數量，並且不重複計算已計算過的分類目錄。
• 而在顯示目錄中的看板數量時，僅計算此目錄的項目數量，或直接顯示看板映像中所記錄的項目數量（包含隱藏看板）。
• 如果要直接顯示項目數量，可增加支援「隱藏分類」，與隱藏看板共同顯示爲「資料保密」（模仿精華區），以使使用者不能藉此推斷有隱藏看板的存在。

IID2021_12_19 (Sun) 18:15 UTF+8

itoc 式彈出選單在 Visio screen 下的問題

問題敘述

發現使用 visio screen 時，itoc 式的彈出式選單的顯示會出錯。
移動游標時，選單右側會多出亂碼，而且如果原本右側的字數夠多的話，會導致換行。
使用 pfterm 時無此問題。
有可能是 visio screen 在計算行長 (slp->len) 時，或是 window.c 中針對 visio screen 的版本的 draw_line() 的處理有問題。
這是本來就有的問題。先暫時略過。 IID2022_04_01 (Fri) 10:57 UTC+8

螢幕過高時，畫面捲動不正常的問題

問題說明 (solved by 6d786c0c8a)

IID2022_06_09 (Thu) 04:26 UTC+8

進某文章 → 右鍵翻頁（壞） → 回去（壞）
機器人邊緣瀏覽器。 IID2022_06_09 (Thu) 04:26 UTC+8 可能是 PttChrome 的問題？ IID2022_06_09 (Thu) 04:27 UTC+8

我猜是 scroll() 出問題了。（可能是伺服器或瀏覽器其一的問題） IID2022_06_20 (Mon) 03:42 UTC+8

發現 row 數 > 50 時，pfterm 的上捲與下捲似乎會壞掉。 IID2022_08_14 (Sun) 01:09 UTC+8 找到 50 是從哪裏來的了。

IID2022_08_14 (Sun) 01:13 UTC+8 夢大限制最大畫面大小是 (50×120)。
pfterm 則是限制最大 (100×320)。 IID2022_08_14 (Sun) 01:16 UTC+8

發現原因是 pfterm 處理 scroll() 與 rscroll() 時，沒考慮實際螢幕高度與系統內部的畫面高度不符的狀況。 IID2022_08_14 (Sun) 01:20 UTC+8

這個時候，rscroll()（螢幕上捲，畫面下挪）時只是多了畫面底部的尾巴；但 scroll()（螢幕下捲，畫面上挪）時無法向上挪，會造成螢幕畫面與 pfterm 內部不同步。 IID2022_08_14 (Sun) 01:29 UTC+8

pfterm 的下捲是挪到它認爲的畫面底部後輸出數個換行，但是當實際螢幕高度超過 pfterm 內部的畫面高度時，前幾個換行不會超出畫面而沒有用。 IID2022_08_14 (Sun) 01:39 UTC+8

https://github.com/ptt/pttbbs/pull/120 pfterm 的 "scroll up" 其實是指 scroll down，而 "scroll down" 其實是指 scroll up。 IID2022_11_29 (Tue) 18:14 UTC+8

不離站就無法存取的功能

問題說明

去掉 (G)oodbye 後暫時無法存取的功能：

• 熱訊處理：清空熱訊或存爲備忘錄（變爲一律保留）
• 寄信給站長群（訪客）
• 在留言板留言

IID2022_11_06 (Sun) 22:46 UTC+8

解決方案：

• 在熱訊紀錄處加進清空熱訊與匯出爲備忘錄的功能
  • 要提供用 tag 全選後操作的方式嗎？
• 開放主選單選項「寄信給站長群」給未認證使用者
  • 另外，由於可使用 Ctrl-Z 選單査看熱訊紀錄，可能也可以開放對應的主選單選項給未認證使用者。
• 在觀看留言板處加入留言的選項
  • 要在進入前還是觀看後給選項？

IID2022_11_07 (Mon) 08:01 UTC+8

閒置未重設問題 (v3.1.0-rc.1)

問題說明 (solved by dabb0317a6)

我操作的間距不到十秒，但閒置時間怎麼不會清零？ IID2022_11_24 (Thu) 01:56 UTC+8

不過畫面大小變更時會清零。 IID2022_11_24 (Thu) 02:02 UTC+8

懂子，現在的邏輯是偵測到 IAC 命令才會清零閒置時間，但是是錯的。 https://github.com/ccns/dreambbs/blob/9b3e98f9d7fe418f2b67212e546b5121b9efca7d/maple/visio.c#L1876 IID2022_11_24 (Thu) 02:10 UTC+8 正確的邏輯應該是： 有不是 IAC 命令的輸入時，清零閒置時間。 IID2022_11_24 (Thu) 02:15 UTC+8

處理轉信程式時區的多餘無效程式碼

問題敘述

取得轉信文章的 HDR::date (日期) 時，應該先把時間字串的秒數 60 改成 59，再依時區調整爲 UTC 時間，再轉換成 UNIX time（無時區之別、不包含閏秒）。不然遇到閏秒時間戳時有機會轉錯。 BBS 系統本身的時區應該設定在 UTC，由 BBS 程式自行調整時區。 IID2023_01_06 (Fri) 01:00 UTC+8

目前看起來，夢大的轉信程式要在 UTC 時區下執行才會正確。 IID2023_01_06 (Fri) 01:15 UTC+8 其它 MapleBBS-itoc 應該也是如此。 IID2023_01_06 (Fri) 01:17 UTC+8

夢大在呼叫 gmtime() 時有設定：

#ifndef __CYGWIN__
        ptime.tm_zone = "GMT";
        ptime.tm_gmtoff = 0;
#endif

但根據 glibc 的文件，這沒用。 https://www.gnu.org/software/libc/manual/html_node/Broken_002ddown-Time.html

Calling mktime also sets the current time zone as if tzset were called; mktime uses this information instead of brokentime’s initial tm_gmtoff and tm_zone members. Portability note: mktime is essentially universally available. timegm is rather rare. For the most portable conversion from a UTC broken-down time to a simple time, set the TZ environment variable to UTC, call mktime, then set TZ back. IID2023_01_06 (Fri) 01:32 UTC+8

[中略……]

那這樣文章清單中的日期會被搞錯嗎? r22023_01_06 (Fri) 01:48 UTC+8 有可能。 IID2023_01_06 (Fri) 01:48 UTC+8

[中略……]

講錯，是少八小時。 IID2023_01_06 (Fri) 02:04 UTC+8 不過看程式碼好像又多餘地補了回去。 IID2023_01_06 (Fri) 02:06 UTC+8

所以邏輯上把這兩行刪除才是正確的，但實際上這兩行沒用，所以結果還是正確的。 IID2023_01_06 (Fri) 02:09 UTC+8

是在哪邊補啊? 主要我在想萬一 BBS+轉信程式在其他時區跑, 不知道會不會出狀況 r22023_01_06 (Fri) 02:11 UTC+8

#ifndef __CYGWIN__ // 當 UTC 轉換（沒用）
        ptime.tm_zone = "GMT";
        ptime.tm_gmtoff = 0;
#endif // 實際：當目前時區轉

        datevalue = mktime(&ptime);
        /* 如果有 +0100 或 -1000 等註明時區，先調回 GMT 時區 */
        zone = str;
        zone += strcspn(zone, "+-");  /* Seek `'+'` or `'-'` */
        if (*zone)
            datevalue -= ((*zone == '-') ? -1 : 1) * ((strtol(zone+1, NULL, 10) / 100) * 3600 + (strtol(zone+1, NULL, 10) % 100) * 60);
        /* Convert it to the local timezone */ // 補當目前時區到當 UTC 的時間差
        zone = INNBBS_UTCZONE;
        zone += strcspn(zone, "+-");  /* Seek `'+'` or `'-'` */
        if (*zone)
            datevalue += ((*zone == '-') ? -1 : 1) * ((strtol(zone+1, NULL, 10) / 100) * 3600 + (strtol(zone+1, NULL, 10) % 100) * 60);

IID2023_01_06 (Fri) 02:25 UTC+8

夢大的話 INNBBS_UTCZONE 會在編譯時代入目前時區，所以在哪裏跑都一樣。 IID2023_01_06 (Fri) 02:26 UTC+8

站外信功能失效問題 (DreamBBS v3.0.0)

詳細說明 (solved by bbe95d4fa3, 2c06d59eff, & dae07f76ef)

送信好像塞住了。 IID2021_04_01 (Thu) 17:10 UTC+8

找到原因了。因爲 dns_open() 被我改壞了。這裏應該是寫 cp 不是 buf。 已經在夢大上修正了。 https://github.com/ccns/dreambbs/commit/0cdb3a4705#diff-bc3c7c1f254efb2e90a22a42dcfe56b54179da3a101f228b79f4400fa7b875a0R608-R612 IID2023_02_21 (Tue) 01:34 UTC+8 現在會直接跳送信失敗的訊息。 IID2023_02_21 (Tue) 01:38 UTC+8

原本會把域名的 ALT1 當作 IPv4 位址而連到 65.76.84.49。 IID2023_02_21 (Tue) 02:40 UTC+8

找到原因了。因爲 dns_openip() 也被我改壞了。這裏應該是寫 sizeof(addr_str) 不是 sizeof(port_str)。 已經在夢大上修正了。 https://github.com/ccns/dreambbs/commit/0cdb3a4705#diff-bc3c7c1f254efb2e90a22a42dcfe56b54179da3a101f228b79f4400fa7b875a0R509 IID2023_02_22 (Wed) 04:09 UTC+8

找到最後的原因了。因爲 bstmp() 也被我改壞了。SMTP 命令 DATA 的回覆是 354 不是 250。也已經在夢大上修正了。可以正常寄站外信了。 https://github.com/ccns/dreambbs/commit/8d94c154c34b68fa73bbc1e791b9ea3da73c525d#diff-70a0ba713bfd90fed724138e82ee9b22f737fbd200479de814a9085fa1933ce2R350-R352 IID2023_02_22 (Wed) 04:28 UTC+8

構想

新增 pfterm 的 "256 color" 與 "true color" 的支援

構想方案

[前略…]
該開始來做 pfterm 的 indexed color ("256 color") 與 direct color ("true color") 的支援了。

• 先在 fterm_exec() 裡實作讀取這些 ANSI escape sequence 的邏輯，並用 down sampling 的方式把色彩降成 8 色
• 改寫 ftattr 和 ftcolor 資料結構，讓其在對應的編譯選項開啟後，可以記錄足夠的色彩資訊
• 改寫使用了上述資料結構的相關程式碼
• 在 fterm_chattr() 中實作將這些資料結構輸出成 ANSI escape sequence 的邏輯。

不過在這之前：

• 將 pfterm 程式碼與 PttBBS 上的同步，只保留必要的邏輯修改與格式修正。

IID2019_09_30

又硏究了其它在 pfterm 上記錄 true color 與 256-color 色彩資料的方案，並且比較這些方案記錄彩現屬性所需的記憶體空間。
最佳情況：畫面中沒有使用任何需要 map 的前景及背景色彩。
最壞情況：畫面每一格都使用了不同的需要 map 的前景及背景色彩。

IID2021_07_27 (Tue) 05:14 UTC+8

整體看起來，Row map true-color & 256-color + direct 8-color + 8-color only rows 雖然最複雜，最壞情況的表現也非最好，但是考慮到 true-color 及 256-color 並沒有很常用，這個方案的效果最好。 IID2021_07_27 (Tue) 05:18 UTC+8

這個方案限制了畫面長寬皆不能超過 256。 IID2021_07_27 (Tue) 05:34 UTC+8

pfterm 的 true color/256 color 的部份，應該會繼續實作了。PttChrome 的部份也要配合實作。

• 目前想以輸出 \x1b[<普通色碼>;<原色碼>，並避免原色碼含有常被未支援擴充色彩的 terminal 支援的色碼的方式，來達到最佳相容效果。
• 可以給使用者一個允許直接使用色碼 38/48 的選項。

IID2021_12_18 (Sat) 06:52 UTC+8

新增短於 6 行的簽名檔的支援

構想

覺得可以考慮實作：允許三個簽名檔的其中任一個可以短於六行。
預設是每六行斷開，但用了單獨一行的特殊分隔線，像是 -- 的話，會提早從分隔線所在的行斷開。
範例：

C18   # 第一個簽名檔
C11
C99
C89
C87
C876  # 結束
C++17  # 第二個簽名檔
C++14
C++11
C++03
C++98  # 結束
--
B  # 第三個簽名檔  # 結束

IID2019_10_18

Big5 轉 UTF-8 的實作

實作參考

看起來轉 utf8 時，會設定 pfterm 成自動去除一色雙字。
https://github.com/ptt/pttbbs/blob/master/include/convert.h IID2019_11_29

https://github.com/ptt/pttbbs/blob/master/mbbsd/convert.c
之後得加轉 utf8 的功能。 IID2019_11_29

想到一種自動判斷終端機編碼的方法。
連線時送出 UTF-8 編碼的測試字串，然後送 \x1b[6n 以取得終端機游標位置。如果游標位置與測試字串的預期長度相符，就假設終端機使用的是 UTF-8 編碼。 IID2021_04_08 (Thu) 20:19 UTC+8

例如送 "\n正在偵測 BBS 瀏覽器編碼……\x1b[6n\n"，然後立即讀 BBS 瀏覽器的回應。 如果回應不符合，就假設是 Big5 編碼。 IID2021_04_08 (Thu) 20:23 UTC+8

然後在登入畫面上顯示 Using UTF-8/Big5; press , for Big5/UTF-8 的字樣，在 vget() 裏偵測使用者按下 , 的動作來即時切換編碼 。 但是限制只能按 3 次，防止被機器人濫用。 IID2021_04_08 (Thu) 20:48 UTC+8

在 Footer 上顯示 [UTF-8] Big5 (,) Switch encoding/UTF-8 [Big5] (,) Switch encoding 的字樣。 IID2021_04_08 (Thu) 20:54 UTC+8

原理是漢字在等寬字體中爲 2 columns 寬，而 UTF-8 中的常見漢字常爲 3 字元，直接解讀爲 Big5 會變成 3 columns 寬。
若能利用控制碼 \1b[6n 取得終端機輸出測試字串後的游標位置 (此時控制碼會回傳 \1b[r;cR)，就能得知終端機是否使用了 UTF-8 編碼。 IID2022_04_15 (Fri) 15:43 UTC+8

Prove of Concept. (?)

IID2022_05_25 (Wed) 19:18 UTC+8

實作有橫向選項的彈出式選單

staled TODO r22021_04_07 (Wed) 00:37 UTC+8

• [中略…]

問題敘述

新版彈出式選單的構想圖。

IID2020_03_16

預計 v3.1 推出的 Xover 系統底層的改進

計畫說明

計畫未來對 xover 系統的改動 (預計在 v3.1 推出)： IID2020_12_21

• 廢除 struct XZ，相關的 data members 併入 struct XO
  • 可以解決使用 XZ_OTHER 時，使用者模式的設定問題
• 將所有 XO 都放至 xo_root 以及 XO::nxt 所串連的 singly linked list 上
  • 解決有些 XO 的游標會儲存，有些不會的不一致
  • 需要在 struct XO 中加入標明其所屬的 zone 的 data member，或是直接比較 XO::cb，以免取到別的列表去，雖然不會造成程式不安全運作
    • 例如點歌看板既可用來點歌，也可單純瀏覽，其對應的列表不同，需要區分

使用新的 "xover tab" 架構取代原本的 xover zone 設計

方案構想

• 增加 XO::up 來描述 XO 之間的階層關係，並且由 xover tab 記錄最末層的 XO，取代 xover stack 的設計
• 將 XO_ZONE + idx 重新解釋為切換至此 tab 從最底往上數第 idx 層 (0-indexed) 的 XO
• 要進入新 XO 列表時，先將新的 XO 的 up 設為目前 tab 上的 XO，然後將新的 XO 放至目前的 tab 上，再回傳 XZ_ZONE + XZ_INIT + key (語法待議) 讓 xover 系統處理即可，避免函式 stack 變高
• 離開列表時，如要回收 XO 物件，則可以回傳 XZ_ZONE + XZ_FINI + key (語法待議) 取代 XO_QUIT，讓 xover 系統進行 XO 的回收
  • 不想讓 XO 留在 xo_root 的 linked list 上時，可以執行此指令，不用刻意避免呼叫 xo_get
  • 可以處理目前啟用動態函式庫的 hotswap 時，防止還在使用的函式庫被 swap 掉的上鎖與解鎖機制
• 主選單的 XO 放在第一個 tab，快速選單切換到的 XO 則放在最前面的空 tab；沒空位時則提示 tab 已滿
• 回到上層選單時，先看 XO::up，再看前面一個 tab，再沒有就離站
• 再增加 tab 的切換選單，則可解決現行 xover stack 開到極限時，只能先退出才能再存取其它功能的問題；此外不切換 tab 的話，回上層的具體行為會與現在完全相同

IID2020_12_21

對 xo_root 結構進行改進

構想

如果不考慮自動回收機制的話，可以用 hash table 取代 xo_root，增加存取效率。
不過考慮自動回收機制的話，則可以將 xo_root 分兩堆：使用中的與未使用的，先找使用中的再找未使用的。
未使用的可以繼續用 singly linked list，並限制長度，回收 list 末端超出限制的 XO。 IID2020_12_21

對 Xover 系統擴充的構想

構想

• 支援 xterm-style SGR mouse-tracking mode
• 從 xover 獨立出函式 xover_exec 與 xover_key
• 實作 XO_MISS 來進行未知按鍵的 fallback 處理
  • 支援用 XO_MISS + key 強制呼叫 fallback 的按鍵功能
• 增加指標 XO::disp 來存放 XO 的顯示參數，並將目前 XO 的顯示參數移至其中，以免 XO 變得太複雜
• 廢除 XO_TALL，增加 XO::disp->rows 與 XO::disp->cols 指定一次要顯示多少橫排與直排，達到 amaki patch 的 XO_XTALL 功能
• 增加 XO::disp->y、XO::disp->x 指定選單的起始座標，以及 XO::disp->height 與 XO::disp->width 指定一個元素的長寬，以達到 amaki patch 的 XO_OFFSET 功能
• 增加 XO_ITEM 指令來重繪某項
  • 目前是叫 XO_CUR，避免與某些分支既有的 XO_ITEM 衝突，但又與 Formosa BBS 的僅重繪游標的 CX_CUR 名稱衝突，計畫改成 XO_ELEM
• 新增 XO::knee 用來放置要在 XR_PART_KNEE 執行的繪圖函式

IID2020_12_21

• 我覺得可以把 thread 命令統合進 Xover 命令中。
  DreamBBS v3.0 的 Xover 命令值域中，XR_* + {XO_WRAP|XO_SCRL} + key 的值域還未使用，可以用來放 thread 命令。
  https://github.com/ccns/dreambbs/wiki/Xover-List-System-zh_tw#dreambbs-v3-的-xover-callback-key-value-的分配 IID2021_01_16 (Sat) 17:07 UTC+8

  • 合了。用了 XR_* + XO_RS + RS_*。
    其中 XO_RS = XO_SCRL，剛好都有 R 與 S 兩個字母。 IID2021_12_16 (Thu) 08:02 UTC+8

• Xover 清單系統應該改成用加在 callback key 上的 bit flag 區分有 pos 參數與無 pos 參數的 callback 函式。
  而發現清單為空時就顯示空的訊息，並且只能執行無 pos 參數的 callback 函式。
  這樣就不用再在 *_body() 函式中手動確認清單是否為空，然後還要用 vget()/vans() 另外處理按鍵。 IID2021_02_22 (Mon) 19:05 UTC+8

  • [前略……] 不過反過來說，可以設計成用 cb_key | XO_POS (XO_POS = XO_REL) 指定 callback 函式有 pos 參數。 IID2021_02_22 (Mon) 19:34 UTC+8
  • 註：XO_POS 實作時已改名為 XO_POSF。

• 新增 XO_EMPTY 命令用以顯示空列表畫面。
  #define XO_EMPTY (XO_WRAP + 0)？ IID2022_05_23 (Mon) 14:21 UTC+8

• XO_REL + x 類的命令應該限制命令的相對移動範圍在 -512 – 511 內，因爲未來不打算支援超過 256 橫行的畫面（目前的編碼限制暫時在 512 橫行）。
  這樣最多可以放 512 個相對移動的命令在 XO_REL + x 區，很充足。 IID2022_05_23 (Mon) 19:45 UTC+8

  • XO_NONE = 0x40000，512 = 0x200，這樣剛好分配地很均衡。 IID2022_05_24 (Tue) 00:16 UTC+8

支援 Xover 清單在含有超大量文章時的絕對移動

這兩個 TODO 或 memo 也 unpinned, 理由一樣, 盡量整理在同一個地方 r22021_04_07 (Wed) 00:56 UTC+8

問題敘述

如果要支援超大量文章的話，就要直接判斷移動範圍，太遠時就直接設定 xo->pos。
大概是

xo->pos = pos;
return XR_BODY + XO_REL + 0;

這樣。 IID2021_04_06

• 替代方案：

return XO_DMOVE + pos;

其中 XO_DMOVE (Xover distant movement) 爲 XO_DL。

IID2021_09_30 (Thu) 20:04 UTC+8

實作以 Tab 字元劃分欄位的推文的顯示

這兩個 TODO 或 memo 也 unpinned, 理由一樣, 盡量整理在同一個地方 r22021_04_07 (Wed) 00:56 UTC+8

問題敘述

我想，要讓推文有完整時間與 IP 來源的話，可以利用 Tab。
因為 vget() 不允許輸入 Tab 字元，所以 Tab 可以拿來當作分隔字元。
大概像這樣：
→ ID：推文內容<tab>2001:288:7001:249::140<tab>2021/04/03 13:42:23
然後實際顯示時根據畫面寬度決定要顯示多少。 IID2021_04_07

在使用者介面上顯示過長的文字時，加上刪節號，並正確處理 DBCS 文字的截斷

實作構想

• 新增 STR_ELLIPSIS 表示刪節號字串
• 實作 strlen_ellipsis() 以傳回可顯示的文字位元組長度，不含刪節號
• 實作 strlen_ellipsis_dbcs() 以處理 DBCS 字元的截斷
• 在使用者介面上需要截斷文字的地方使用這兩個函式 IID2021_04_26 (Mon) 17:30 UTC+8

實作在連續刪除的文章標題上隨機生成的圖案

功能敘述

Ptt 的「本文已被吃掉」的隨機刪除訊息是怎麼實作的？ https://pttpedia.fandom.com/zh/wiki/卡卡獸 IID2021_04_26 17:04 (Mon) UTC+8 https://www.ptt.cc/bbs/PttNewhand/M.1224678027.A.552.html IID2021_04_26 17:09 (Mon) UTC+8

支援時間精度最大 48-bit 且允許一秒多篇文章的唯一文章編號與閱讀紀錄

參考資料與構想

之後想引入 PttBBS 的 AIDS 系統。

PttBBS 文章編號系統 AIDS 的說明: https://github.com/ptt/pttbbs/blob/master/docs/aids.txt
PttBBS 的文章檔名格式是：

• <文章類型>.<開始編輯時間的十進位制數字>.A(.<同秒唯一編號的 3 位十六進位制數字>)

文章類型：M 爲普通文章、G 爲文摘文章、X (檔案系統上)/L (資料結構上) 爲已鎖定文章、. 爲已刪除文章。

AIDu 是二進制整數形式，格式是：

• (共 64 bits) <16 bits: 空白> <4 bits: 文章類型><32 bits: 開始編輯時間値><12 bits: 同秒唯一編號値> 允許的文章類型的値與對應類型：0 (M)、1 (G)。
  AIDc 是字串形式，是經過 base64url 編碼的 AIDu。

MapleBBS 3 的文章檔名格式是：

• <檔案類型><發表時間的 7 位 radix32 編碼數字 (35-bit)>
  檔案類型：A 爲文章檔、F 爲目錄檔。

之後實作時，我會以 64-bit time_t 爲基礎，更改 MapleBBS 3 文章檔名格式爲：

• <檔案類型><時間的 13 位 radix32 編碼數字 (65-bit)>.<同秒唯一編號的 3 位十六進位制數字>

並且更改 AIDu 格式爲：

• (共 64 bits) <4 bits: 文章類型><48 bits: 文章時間値><12 bits: 同秒唯一編號値>

其中文章類型在 MapleBBS 3 上會固定爲 0。
不過這樣的 AIDu 格式只能使用到公元 8,92 1,564 年，到時要再調整格式。

然後還要考慮閱讀紀錄的實作。

PttBBS BRC 的說明: https://github.com/ptt/pttbbs/blob/master/docs/brc.txt
BRC 可視為 MapleBBS 3 的 BRH 的前身。
BRC 是採用一篇文章一個紀錄的方式記錄閱讀紀錄，並且分開記錄文章與修改時間。
但是 BRH 是採用閉區間的方式記錄閱讀紀錄，沒有辦法單獨記錄文章的修改時間，所以修文與推文的閱讀紀錄部份，只能恢復一篇文章一個紀錄的紀錄方式。

PttBBS BRC 並沒有考慮文章的同秒唯一編號値。所以只要讀了一篇文章，其他同秒文章也會變成已讀。

之後實作 BRH v3/4 時，我會使用 AIDu 格式：

• (共 64 bits) <4 bits: 額外的 flags><48 bits: 發文時間値><12 bits: 同秒唯一編號値>

並且讓同秒唯一編號値隨發文順序嚴格遞增，以處理同秒發文的狀況。
另外，也要確保 AIDu 的 <48 bits: 發文時間値><12 bits: 同秒唯一編號値> 的部份爲唯一値。

PttBBS 中，使用者發文的機制：
發表新文章 (do_post_article()) 時，會先由 stampfile() -> fhdr_stamp() 決定檔案名稱（會不斷嘗試隨機產生同秒唯一編號以保證檔名唯一），然後才由 vedit() 編輯文章。

MapleBBS 3 中，使用者發文的機制：
發表新文章 (do_post()) 時，文章會暫時由 vedit() -> ve_filer() 寫到 usr/<user_suffix>/<user>/note，然後由 hdr_stamp() 決定實際的檔案名稱並使用 hard link 的方式建立文章檔（會不斷逐秒增加發表時間以保證檔名唯一），隨後會 unlink() 使用者目錄下的原檔。
在同一個使用者同時登入並同時發表文章時，可能會發生問題，需要把暫時檔案也引進同秒唯一編號値。

IID2021_04_28 17:19 (Wed) UTC+8

https://www.ptt.cc/bbs/PttNewhand/M.1483200003.A.415.html 就將就著參考吧 r22021_11_24 (Wed) 00:32 UTC+8

雖然系統不同，不確定 Maple3 是不是還這樣 r22021_11_24 (Wed) 00:33 UTC+8

現在的夢大應該就是這樣的，而我沒改這部份的行爲，也就是說 Maple 3.xx 應該也是這樣的 。
不過因爲現在的夢大是先選簽名檔再進入編輯器，不會有送出時間與文章列表上的時間不一樣的問題，除了同一秒發文時會有 spinlock 延遲而使文章列表上的時間不同秒。
印出內文時間的程式碼：https://github.com/ccns/dreambbs/blob/3f19b27454d36b7650db181107d54667dd6f5b02/maple/edit.c#L1322 IID2021_12_26 (Sun) 18:56 UTC+8

擬似 spinlock IID2021_12_26 (Sun) 18:58 UTC+8

如果要避免延遲的話，需要在文章檔名後加上去混淆號碼。
但 BRH 需要文章列表照檔案編號（時間碼加去混淆碼）遞增以良好發揮。
我想到的是在 BRD 中加個去混淆編號資料成員，比如 BRD::uniq，初始化爲 0。
hdr_stamp() 對 BRD::uniq 以 compare and swap 的方式增加 1，成功且未發現同名檔案的話就以原値當作檔名，失敗就以新値重做；發現時間秒數大於 BRD::blast 時則用 compare and swap 的方式歸零。 IID2021_12_26 (Sun) 19:21 UTC+8

分開新文章與新修文／推文的顯示

方案構想

爲何不用不同顏色或圖案區分新文章與推文或修文？ IID2021_05_11 (Tue) 14:02 UTC+8

要怎麼設計？

☆ —— 無新文章、修文、或推文
★ (紅) —— 新文章
★ (藍) —— 無新文章，有新修文或推文
—— 文章、修文、及推文均已讀
+ (暗白) —— 文章未讀
+ (亮白或靑藍) —— 原文章已讀，新修文或推文未讀

或是色彩對換，只是因爲新文章比較多而修文及推文少，怕不習慣。 IID2021_05_11 (Tue) 14:43 UTC+8

PttBBS 是用 ~ 表示文章有修文或推文未讀。IID2021_07_08 (Tue) 02:53 UTC+8 mbbsd/bbs.c: readdoent()IID2021_07_08 (Thu) 02:54 UTC+8 不過符號種類太多會對使用者造成困擾。 用顏色區分比較容易看得懂。IID2021_07_08 (Thu) 02:56 UTC+8

UTMP Ownership

方案構想

總之構想了這樣的系統。

IID2021_07_11 (Sun) 23:57 UTC+8

BBS UTMP Ownership 構想

重複登入時，只允許 owner 爲空的連線存取交易功能。
如果擁有者登出，就將 ownership 傳給下一個連線。
取得擁有權的步驟：(0→3)

若擁有者的 owner 不爲空，就暫時禁止取得擁有權。

2021-07-11 Iweidieng Iep⁠

Review: 不應該用登入階段區隔，應該用互斥鎖，對使用者而言更方便。 IID2022_11_06 (Sun) 23:25 UTC+8

主選單的 Ctrl- 快速鍵所對應的功能增加各畫面通用的 Esc- 的按法

方案構想

Esc- 按鍵	既有按鍵	對應函式	功能
Esc‍‍-‍Z	Ctrl‍-‍Z	every_Z()	叫出快速切換列選單
Esc-U	Ctrl-U	every_U()	叫出使用者名單
Esc-S	Ctrl-S	every_S()	快速切換看板
Esc-B	Ctrl-B	every_B()	快速鎖定畫面

IID2021_09_29 (Wed) 20:10 UTC+8

對動態看板系統的擴充

詳細計畫

看到有個 HAVE_RAND_INCOME 的設定，可以隨機取進站畫面。
但是實際看了原始碼，發現它是在 util/camera.c 跑的時候隨機取一篇，而不是全部載入再在進站時隨機選擇 (像 MapleBBS 3.10-itoc 那樣)。 IID2022_01_15 (Sat) 23:55 UTF+8

如果要做到允許任意畫面包含多篇的話，應該把 FCACHE 的資料結構改成：

<offset-welcome> <offset-etc>… <offset-welcome-k for k in [0, n)>… (<offset-etc-k for k in [0, n)>…)… <welcome-k-data for k in [0, n)>… (<etc-k-data for k in [0, n)>…)…

或是用 C 表示：

#define FLIM_INDEX_MAX FLIM_INDEX_MOVIE
#define FILM_COUNT (FILM_INDEX_MAX + 1)
typedef struct {
    int32_t cate[FILM_COUNT];
    int32_t shot[MOVIE_MAX];
    char film[MOVIE_SIZE];
} FCACHE;

• 我想將 FILM_<category> 更名爲 FILM_INDEX_<category>，但會不會太冗？

  • 雖然已經有 XZ_INDEX_<zone> 了，但那主要是給 Xover 系統內部使用用的。

IID2022_01_16 (Sun) 00:19 UTF+8

• FILM_<category> → MZ_INDEX_<category> for "menu zone index".

  • Parallels to XZ_INDEX_<category>, for "Xover zone index".

  • Mark Zuckerberg index

IID2022_01_16 (Sun) 00:36 UTF+8

如果要像 PttBBS 一樣有隨主選單區域而變的動態看板的話…… IID2022_01_16 (Sun) 01:15 UTF+8

1. 改成能用這個方式定義：

INTERNAL_INIT MENU menu_mail[] =
{
    // ...
    {{.menu = menu_main}, PERM_MENU + 'R', FILM_MMENU + M_MMENU,
    "電子郵件"}
};

• • :huisha:

2. 直接看 MENU::umode。
   • 可是沒彈性。

BBS 使用者群組系統

詳細敘述

BBS 使用者群組系統：
使用者可以建立「使用者群組」，並邀請其他使用者加入。使用者群組 ID 固定會有特別符號的前綴或後綴。
由使用者群組所建立的文章，所有該群組的人都能執行該文章的作者所能執行都操作。 IID2022_03_03 (Thu) 21:51 UTC+8

BBS 站臺設定

詳細敘述

看有沒有機會切割包成 docker images, 或是幫一個乾淨的環境寫 ansible 來自動化部署 r22022_03_27 (Sun) 20:32 UTC+8

技術上，還需要將站臺設定改成執行時期決定的，而不是編譯時期編死。 IID2022_03_27 (Sun) 20:33 UTC+8

我想先用 dotenv 與 getenv() hack 一下。 IID2022_03_27 (Sun) 20:34 UTC+8

喔，只是要包成 docker image 的話，自己準備一份 dreambbs.conf 就足夠了。 IID2022_03_27 (Sun) 20:37 UTC+8

目前的設計是：config.h 包含預設設定，而 dreambbs.conf 用來覆寫 config.h 中的設定。 IID2022_03_27 (Sun) 20:44 UTC+8 但是有個缺點：無法定義預設爲開的開關型設定，除非調整 include 的順序。 IID2022_03_27 (Sun) 20:48 UTC+8 應該要整理一下 config.h 的內容，分出 config_default.h (預設設定) & feat.h (無實際作用或被自動推導的設定)，在 config.h 中以 config_default.h → dreambbs.conf → feat.h 的順序統整設定。 IID2022_03_27 (Sun) 20:52 UTC+8

閒置連線的處理

詳細敘述

如果不送 keep alive 訊息，BBS server 就不知道連線還在不在。
如果每 client 定時送，站上連線數過多，會訊息傳遞過多。尤其是許多連線在週期某一點附近建立時，會造成負載尖峰。
一種折衷的解方是改由單個執行緒週期地逐個送訊息，可以消除負載尖峰。
另一種是維持每 client 定時送，但送時用 mutex 鎖並故意 sleep 一瞬間（17 毫秒內的 sleep 不容易被肉眼察覺）。如果被 mutex 擋 𝑛 次就延長自己的週期爲 𝑛 倍，並在下次解 mutex 時重設自己的週期。 IID2022_06_17 (Fri) 13:25 UTC+8

送的週期的參考值可以設成 𝐦𝐚𝐱(站方可接受的週期長下限, 期望的全 clients 皆送一次的時間 / 𝐦𝐚𝐱(1, 目前 client 數))。 IID2022_06_17 (Fri) 13:36 UTC+8 不過試送一個 \0 字元就足以確認是否爲 broken pipe 了。 IID2022_06_17 (Fri) 13:39 UTC+8

講錯，是 server 中對應 client 的執行緒主動送給瀏覽器端。 IID2022_06_17 (Fri) 13:49 UTC+8

其實我比較好奇如果實作斷線後登入 attach 會原本的 session 可不可行, 以及人多(線上1X萬)後這樣會不會增加負擔 r22022_06_17 (Fri) 13:54 UTC+8

可行。看看 logind 是怎麼實作的。
但實際上無法分辨存在的 session 是閒置還是斷線。需要利用強制中斷重複登入連線的選項。 IID2022_06_17 (Fri) 14:01 UTC+8

擴充了的方案 連線時：

在 既有登入階段表.找所有(符合 新連入連線的位址與埠) 對所有 登入階段.送去(保活訊息).是失敗的 且 登入階段.閒置時間 < 快速附著時限 的 登入階段 做
    登入階段.重新附著(新連線)
    不做了

登入時：

若 使用者.既有諸登入階段.數量 >= 登入階段數量上限 的話
    連線.警告重複登入()
若 使用者.既有諸登入階段.數量 > 0 的話
    若 連線.問去("是否接續既有登入階段？").是肯定的 的話
        使用者.既有諸登入階段.找(最好 登入階段.送去(保活訊息).是失敗的 次之 最大 登入階段.閒置時間 的 登入階段).重新附著(連線)
    若 連線.問去("是否踢除既有登入階段？").是肯定的 的話
        在 使用者.既有諸登入階段 對所有 登入階段 做
            登入階段.登出()
            執行緒.睡(安全登出間隔時長)
    建立新 登入階段.重新附著(連線)
若 使用者.既有諸登入階段.新增(連線).是失敗的 的話
    連線.回報重複登入()
    連線.關閉()

IID2022_10_29 (Sat) 00:31 UTC+8

總推文數模式

詳細敘述

我想加個顯示總推文數的模式。應該改成分開記錄推文次數與分數（不過都可以直接算出來），不過得加欄位，或是用另外的資料結構存。 IID2022_07_13 (Wed) 16:01 UTC+8

新彈出式選單樣式

詳細方案

試著用

:pause_button: 的風格修改了風之塔彈出視窗。
看了圓角邊框後發現直角邊框很刺眼

IID2022_08_11 (Thu) 01:02 UTC+8

希望看起來有圓角邊框的錯覺。

IID2022_08_11 (Thu) 03:48 UTC+8

進階推文動態顯示

詳細說明

想讓文章瀏覽器顯示推文樓層與誰正在推文。
應該與使用者資料代碼的實作有所類似。 IID2022_08_11 (Thu) 20:42 UTC+8

加大推文數顯示上下限

方案說明

計劃把文章列表的格式改成：
> 3674m 01 06/20 IID
>19937m128k11/02 IID
這樣可以準確顯示推文數量。 IID2022_08_12 (Fri) 02:35 UTC+8

不過置底文會是 > ★m 02/24 IID 可能會變醜。 IID2022_08_12 (Fri) 02:39 UTC+8

效果預覽。

IID2022_08_12 (Fri) 02:50 UTC+8

不能，這樣變成沒有 tag 標示的空間。 IID2023_04_11 (Tue) 01:17 UTC+8

登入位址管理方案

詳細方案

MapleBBS 3 有 ACL (access control list) 系統，主要是用來限制管理員可登入的位址。
4D 加強的版本應該是：

• 所有有認證信箱或聯絡信箱的使用者都能夠使用。
• 限制操作，只能新增目前位址或刪除既有位址。
• 若登入位址不在 ACL 允許清單中，就寄一封有安全碼的信件給使用者的聯絡信箱。
• 如果使用者輸入安全碼或是回寄信件，就把目前位址加入 ACL 並允許登入。 IID2022_11_04 (Fri) 18:55 UTC+8

新增編輯器的語法色彩強調

問題敘述

我覺得編輯器應該要 highlight 控制序列，像是 * (Esc 字元)，不然要按 Ctrl-V 才看得出來到底是普通星號還是 esc。
也許和 BBS-Lua / pmore 的 syntax highlight 一起實作。 IID2019_10_18

改用較新的系統函式

詳細計畫

之後的計畫：

• 把 shared memory 的操作函數從 System V 換成 POSIX 的。
• 把 semaphore 操作函數從 System V 換成 POSIX 的。
• 用 epoll() 取代 select()。

http://man7.org/linux/man-pages/man7/shm_overview.7.html http://man7.org/linux/man-pages/man7/sem_overview.7.html http://man7.org/linux/man-pages/man7/epoll.7.html IID2019_12_05

Unicode 支援計畫

詳細計畫

編碼相關的計畫： IID2019_12_05

• 支援從 Big-5 UAO 轉 utf-8，以及反向轉換 (參考 PttBBS)
• 支援 utf-8 文章
  • HDR 要增加編碼的 flag，或是自動辨識編碼，誤判時再讓使用者選擇編碼
  • 最好讓 pfterm 支援完整的 utf-8
  • 要有辦法支援 unicode 全形字元的的一字雙色
• 將系統說明文件全部轉成 utf-8
• 把系統 UI 轉成 utf-8 (參考 FormosaBBS；可能不會實行)
  • 把訊息字串改成 utf-8
    • 至少要把訊息從原始碼中分離
  • 轉換所有有放字串的資料結構，或是增加相關 flag
    • 有點複雜，而且這樣要把放字串的空間調大，可能不會實行

專案目錄結構重整的計畫

詳細計畫

計畫： IID2020_02_24

1. 重整專案目錄結構：
   • 建立可以放不同程式共用的函數庫的目錄 common/ (放在 lib/ 下也可)
     • 避免在 lib/ 下建子目錄；盡量讓整個專案結構扁平化
       • 禁止第 3 層次的 Makefile
         • 之前試著編譯 MapleBBS-itoc 時很挫折，因為有些目錄下的子目錄有自己的 Makefile
       • 目前整個 DreamBBS 專案只有 scripts/wsproxy/ 一個內層目錄，但沒有自己的 Makefile
   • 把 xchatd 從 maple/ 移出，放到 xchatd/ 下
   • 可把 maple/ 改叫 bbsd/，或學 PttBBS 改叫 mbbsd
2. 重整理 header 檔：
   • 將不同支程式要 include 的 header 分開，不要全部都 #include "bbs.h"，這樣很難控制哪些程式該使用哪些函數
     • 將 bbs.h 拆成 system.h (deprecated), common.h, bbsd.h/mbbsd.h 三部分
       • include/ 可以有子目錄，因為子目錄不需要自己的 Makefile
   • 參考 MapleBBS-itoc，將各個 header 內的特殊值整理出來
     • 可能需要將 struct.h 拆開
   • 避免在原始碼中自行宣告函數，統一使用 #include，不然容易出錯，而且用 C++ 編譯時容易失敗

夢大行動版的方案構想

構想

行動版夢大構想： IID2020_03_16

• 偵測畫面寬度，小於 80 時改變排版，使其適應窄螢幕。
• 需要實作 XO_KNEE 相關功能，以額外顯示在窄螢幕下沒有空間可顯示的資訊。
  • 實作 int *_knee(XO *xo)，其中不同的 knee 的繪畫函數放在 xo->xyz 中 (或 xo->knee)，而 *_knee() 會去呼叫 xo 中所指定的函數；為 NULL 時則不畫出 knee。
  • 注意 *_knee() 不一定要畫在列表內容之下，而是可以覆蓋部分列表內容。
• 在窄螢幕下預設開啟 XO_KNEE。

然後是畫面大小，我覺得使用 pfterm 時可以考慮改限制畫面的長寬乘積，這樣更容易控制記憶體使用量。
使用 visio screen 時，因為畫面的資料結構的 row 與 column 大皆為固定大小，只能分開限制畫面長寬。 IID2020_03_16

應該要可以隱藏網址列。 https://developers.google.com/web/fundamentals/native-hardware/fullscreen?hl=zh-tw IID2021_04_08 (Thu) 21:43 UTC+8

Xover & mmap() 相關議題

詳細說明

你覺得夢大三要繼續用 mmap 做 xover 列表載入嗎？ IID2020_11_18 (Wed) 20:20 UTC+8

優點：

• 顯而易見地是可以直接 map 整個列表，程式碼較簡單，不用考慮 buffer read
• 有 lazy loading 的效果：只需要呼叫 mmap 一次，之後要存取時系統才會去讀取資料；需要寫入時才會複製資料到 user space 的記憶體中佔用記憶體空間；適合在同一列表中長時間瀏覽的狀況
• 未來可以銜接列表資料底下的記憶體的跨 process 共用

缺點：

• 沒有禁止對 mmap 的記憶體寫入的話會使用多倍於原本實作的記憶體
• 呼叫 mmap 時的 system call 的 overhead 較大，重複呼叫會造成效能不佳，不適合常常切換列表的狀況
• 有時候會遇到底下的檔案變小，而這個變更立即反映在 mmap 的記憶體中，造成原本取最後一項的程式存取到合法範圍以外的記憶體的問題 (partially solved by 604fba7455)

有種折衷的方法，就是熱門的看板用 mmap 載入，而其它看板就用 buffer read 載入。
目前分類看板的實作是用 shared memory，如果改寫成用 posix shared memory API 的話就相當於用 mmap 載入。
至於其它小且不經常使用的列表，繼續使用 mmap 應該即可。 IID2020_11_18 (Wed) 20:37 UTC+8

MapleBBS 4 Roadmap

詳細計畫

MapleBBS 4 Roadmap，TODO 格式: IID2020_12_06

• 整理尚未記載的重要資料至 DreamBBS wiki
  • 轉信設定、BBS 信箱設定等系統設定（可參考 PttBBS）
  • sample/ 及 scripts/ 下各腳本的使用時機及使用方式
  • MapleBBS-itoc 精華區資源（需取得原作者同意）
• 將目前夢大的系統說明檔案移到 DreamBBS 專案中
• 架站時不再依賴 dreambbs_snap 的資料夾骨架，像 Pirate BBS 一樣有初始化資料夾結構的腳本，可以從零開始架站
• 必要核心功能與附加功能的分離
  • 整理出哪些功能是 BBS 系統的必要功能
  • 將非必要功能模組化並移出主程式資料夾（bbsd/）
  • 將選單與按鍵功能的設定的相關程式碼獨立出來，並移出主程式資料夾（bbsd/）
  • 整合其它 MapleBBS 3 主要分支的核心功能的修正與改進
• MapleBBS 4 釋出計畫（專案成熟後再行考慮）
  • 寫專案總覽文件，簡述與 MapleBBS 3 的主要差異、以及目前 MapleBBS 3 各分支的開發狀況
  • 與 MapleBBS 原開發群討論名稱問題

分類看板＝精華佈告欄子區 ∧ 我的最愛＝信件精華區＝個人精華區 架構整合計畫

詳細說明

‌　　我想可以用精華區的架構，將分類看板、我的最愛、信件精華區（夢大未啟用）系統合而爲一。
結合後，我的最愛 = 信件精華區 = 個人精華區，只是多加是否開放自由新增文章的站臺設定。這樣系統應該會比較簡潔。
　　分類看板是精華公佈欄中的 @Class，只是預設進入看板而非精華區（同目前 WindTopBBS 與 MapleBBS-itoc 的設計）。只是多使用 acpro 將分類看板載入共用記憶體（此程式源自 WindTopBBS；DreamBBS v3.0 把 account 中建立分類看板的工作移到 acpro，不然根本沒用到）。 IID2021_12_02 (Thu) 23:17 UTC+8

‌　　至於使用者選單介面，我想就維持現在這樣。

• 不過我想把 Tab 鍵擴充，將以下畫面循環切換（Shift-Tab/z 鍵反向切換）：
  • 看板→精華區→文摘（列出所有 g 文，如果要實作的話）
  • 分類看板/專業看板→精華公佈欄的對應頁面
  • 使用者信箱→我的最愛

IID2021_12_02 (Thu) 23:25 UTC+8

現在沒辦法循環的原因是，進入精華區時的 call graph：
xover.c xover() -> xover_exec_cb() -> xover_exec_cb_pos() -> post.c post_gem() -> gem.c XoGem() -> xover.c xover() -> ……，
會消耗堆疊空間。
得改用類似 gem_main() 的設定 xo 後即退出函式的方式，只是設定對象是目前的 xo 物件。
而且要記錄一開始進入看板時是進入文章列表模式還是精華區模式。若左鍵退出時不在一開始進入的模式，則先回到該模式，不然才退出看板。 IID2021_12_03 (Fri) 01:40 UTC+8

檔案以 Radix32 尾碼分散之設計，是否延續至 MapleBBS 4D？

詳細說明

踩到洞：camera 假設動態看板檔名是 archive32，不支援 @name 格式。 IID2022_11_06 (Sun) 16:43 UTC+8

MapleBBS 4D 或之前會取消檔案以 radix32 尾碼分散至 32 個目錄的「feature」。 IID2022_11_08 (Tue) 11:06 UTC+8

現在常見的 ext4 在啟用 dir_index 與 dir_nlink 的狀態下，沒有子目錄數量的限制。 夢大現在的檔案系統也沒有這個限制。 IID2022_11_08 (Tue) 11:20 UTC+8

https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Directory_Entries ext4 有 hash tree directories。 IID2022_11_08 (Tue) 11:42 UTC+8

在現行我的最愛 ~bbs/usr/i/iid/MF/favorite 建立資料夾 → 目錄是 ~bbs/usr/i/iid/M7/F01234567 → 無此目錄 → 失敗 將我的最愛改爲 ~bbs/usr/i/iid/MF/.DIR → 建立資料夾 → 目錄是 ~bbs/usr/i/iid/MF/7/F01234567 → 無此目錄 → 失敗 hdr_stamp() 應判斷路徑是否需 radix32 分散。 IID2022_11_08 (Tue) 13:07 UTC+8

文件上的 TODO

撰寫系統管理細節

問題敘述

要不要把夢大的系統管理細節寫在 GitHub wiki 頁面上？
例如怎麼設定轉信，以及 sample/ 底下各腳本的使用時機與方式。
如果使用 PttBBS 的設定方式也可以的話，可以在相關條目直接用外部連結的方式連到 PttBBS 的 GitHub wiki 頁面，再輔以在 DreamBBS 上設定時要另外注意的事項。

專案的說明文件應該與專案放在一起，不要分開。
應該也把現在夢大的按鍵說明檔案移到程式專案中維護，避免按鍵說明檔案與實際按鍵愈偏愈遠的情況繼續發生。

舉個負面例子：TJAPlayer3。它的原始說明檔案是維護在原開發者的個人網站上的，但後來原開發者不維護專案了，之後適逢個人網站更新，於是就把專案頁面連同說明檔案一齊刪除了。 IID2020_12_06

需要完成的其它紀錄文件

詳細計畫

TODO: IID2021_01_17

• 新增 wsproxy 與 PttChrome 安裝步驟至 GitHub wiki
• 將 DreamBBS Development 播放清單中，未完成的影片說明悉數完成
• 更新 DreamBBS 的 VERSION
  • 保留 WindTop BBS 格式，並加上可能遺漏的版本的著作權宣告
  • 現在版本的著作權宣告，改用更正式的英文名字，而非僅有暱稱或代號
• 寫 GitHub 頁面說明 DreamBBS git 版本以來的程式修改部分的著作權授權
• 更新 README.md，加上夢之大地與 DreamBBS 的相關文化歷史資訊

雜項

未完成的 TODO

• 修正公告未讀判斷 IID2020_11_16
  • (partially solved by 3a73b1a423)
  詳細說明

  • 我應該找到強制閱讀看板的判斷會失準的原因了。
    force_board() 的判斷，是檢査 brd->blast 的時間點值是否在閱讀紀錄中爲未讀。但是 brd->blast 的值並沒有與任何看板文章直接同步。
    當有人發表文章或編輯文章時，正確的作法是將 hdr->blast 更新爲 hdr->chrono (發表) 或 hdr->pushtime (編輯)，但 do_post() 與 edit_post() 卻直接呼叫 time(0) 將 brd->blast 更新爲當時的時間，可能造成 brd->blast 的值落在閱讀看板文章所能涵蓋的已讀時間範圍之外。（不過推文的處理 (post_recommend()) 反倒正確）。
    尤其是編輯文章時所更新的 hdr->pushtime，在閱讀紀錄中僅會有一秒的紀錄，只要 hdr->pushtime 與 brd->blast 的值相差一秒就會造成無法退出公告板的問題。
    
    不過單純修改程式只能解決造成錯誤的原因，無法消除既有的資料錯誤，所以需要使用其它方式修正或更新 brd->blast。 IID2022_03_22 (Thu) 03:34 UTC+8

  • 而設定已讀能退出的原因，是因爲 brd_visit(false) 會將閱讀紀錄內容改爲 ([0, time(0)])，因此理論上必定能包含到 brd->blast。 IID2022_03_22 (Thu) 03:37 UTC+8

  • 若是文章的前一篇與後一篇皆未讀，或是前一篇過於久遠 (不記錄) 且後一篇未讀，hdr->chrono 在閱讀紀錄中也會只有一秒的紀錄 (…, [hdr->chrono, hdr->chrono], …)。 IID2022_03_22 (Thu) 02:02 UTC+8

  • … (after applying 3a73b1a423)

  • 發文的人使用新版本即可。 IID2022_03_23 (Thu) 17:05 UTC+8

  • 但是應該還不能正確處理刪除文章的情況。 IID2022_03_23 (Thu) 17:06 UTC+8

  • 所以不要刪除最新所新增或更新的那篇文章。 IID2022_03_23 (Thu) 17:10 UTC+8

• 編輯 DreamBBS-202X v0 release note IID2021_01_02

初步整理的 v3.1 的 TODO

詳細計畫

DreamBBS v3.1 TODO: IID2021_03_12

• 合併 so/*.c 的 XO 初始化程式碼
• 增加 FOR_IDX 與 FOR_PTR 巨集

#bbs-dev 中的部份 TODO（剩下長期 TODO 未完成）

詳細計畫

TODO (搬移自 #bbs-dev):
[中略…]
長期 TODO IID2021_01_22

• TODO: 檢視所有 C-style 顯式轉型，消除會困惑程式碼讀者或是會引發未指定行為的指標轉型 IID2020_12_10
• 新增 wiki 頁面補充 SGR (ESC '[' ... 'm') 的 parameter 與對應功能的說明 (https://github.com/ccns/dreambbs/wiki/ANSI-Escape-Code-Standard-Format-zh_tw) IID2021_01_06
• 整理近期 MapleBBS 3.0x 發展的參考資料至 in2 討論板

  我用最近挖掘的證據鬧板看看好了。 IID2021_01_10

近期目標

詳細計畫

Long term TODO (大致定為這學期的目標): IID2021_01_17

• 設定更多自動化開發工具，協助專案維護
• 設定編輯程式碼所使用的開發環境，增進開發效率
• 在 GitHub wiki 上記錄如何設定以上工具
• 在 GitHub wiki 上撰寫針對 BBS 使用者的簡易使用介紹以及使用介面截圖
• 建立 DreamBBS 專案的 GitHub page，內容包含：
  • GitHub wiki 的定期備份
  • 程式碼導覽 (內容類似先前實驗過的 Doxygen 頁面)

夢大 Bug List - 2017-10-20, by @r2#7033

• Updated on 2021-01-21, by IID (@Dom2112#3054)

詳細內容

1. 簽名檔:
   • 有三個可選，但只能編輯一個 (已經改善提示介面)
2. 看板:
   • 如果採用(B)回文模式，在看板上的推文會與信件底下的同步
     • IID: 預期動作是什麼？沒說明改不了。 IID2021_12_06
     • r2: 預期動作應該是看板上的文章內容與信件內容各自獨立，有人在看板上的回文推文，該內容不會在信箱內的回文內容更新。 r22023_12_19
   • 進不去看板但看板state仍會顯示該板板名，且會累積人氣… http://cpu.tfcis.org:8080/bmore?itoc&10484

     • 見 https://github.com/ccns/dreambbs/commit/347f33a66baa946ac6bdf010e3a320d865ab89b8，我把確認可否進入看板的邏輯，往前移到了函數開頭處 IID2019_10_19

   • 看板閱讀紀錄(.BRH)會壞掉
     • (solved (undefined behavior: memcpy() optimization) by bc67fbb220 & 2f64941529) IID2021_12_06

• 3.轉寄:
  • 大 F 因為權限相關安全問題停到現在… (不太好解決orz)
    • postfix 問題近期找時間解決
    • 權限問題再看 code 能解決多少

    • 見 https://github.com/ccns/dreambbs/commit/c2ecedc0be94c88468a8582b6f7e079940197789 及 https://github.com/ccns/dreambbs/commit/f3130caeae0647a94a38601dda7e6c589bd4cd78，
      先前問題在於轉寄／轉貼多篇文章時，即使其中幾篇已經被權限系統擋下，界面上仍然是顯示轉寄／轉貼成功；
      我加了「成功計數器」解決了這個問題，
      順便解決了可以透過無效轉貼文章刷個人文章數的問題 我利用這個 bug 把自己的文章數刷到超過一百萬篇 IID2019_10_19

    • IID: 權限檢查由 xover.c xover_key() -> xo_forward() 處理 (同 DreamBBS-2010)，但判斷的方式應該沒問題。已由 r2 重新啟用：a89e9b604c IID2021_12_06

4. 最愛:
   • 在我的最愛那邊時，使用者名單顯示的動態是顯示該人上一個Q的ID…
     • 現在變成顯示主選單…@@

     • 見 https://github.com/ccns/dreambbs/commit/39510cd5055238851b7aa80d11d4c9c46d7005d5，
       問題在於沒有定義到 M_MYFAVORITE 的 xover zone，造成取 XZ_MYFAVORITE 時發生 out-of-bounds accessing；補上去就修好了) IID2019_10_19

     • (solved (buffer overrun of xz[]) by 39510cd505) IID2021_12_06
   • h 功能目前有 bug 未解 (solved)
     • (IID: 什麼 bug？) IID2022_01_21
   • + 在那邊 s 進看板出來後，上面的指令提示選項還是 for 看板文章目錄… (solved)
5. 好讀版:
   • 圖片影片連結已經無法預覽。
     • (現在已經暫停服務@@)
     • (其他細節待補)
6. 人氣:
   • 記錄顯示人氣的daemon爆掉了。 (人氣自動+n*10)
     • (重開機後觀察暫時是解決了)
     • IID: 並沒有這個 daemon。疑似是發生了 race condition，待修正 IID2021_12_06
7. 點歌:
   • 確定點歌嗎 [Y/n]： 預設是 n，應該改成 確定點歌嗎 [y/N]： (done)
     • so/song.c: 327
8. 遊戲:
   • 小雞檔案缺漏，導致不正常斷線 (待補) (done)
9. 點歌:
   • 點歌次數無法累積! (solved)
10. 精華區:
    • gopher 還沒拔乾淨
11. terminal:
    • #A1D3KR3E (P_r2) 接收特定控制碼會異常斷線
      • IID: 看不到原文，不知是什麼控制碼。 IID2021_12_06
      • (probably solved by 29a66c8169 & 02dce8457e) IID2021_12_06
12. 聊天室:
    • 特定網路位置無法連線、
    • chat.so 傳送給 xchatd 相關資訊的敏感內容未經過處理
13. Every_Z:
    • 進去我的最愛會造成無限迴圈最後 SegFault
      • (solved (原因同 4.)) IID2021_12_06

其它 issue 連結

• DreamBBS 官方 Git repository 的 issue 清單：https://github.com/ccns/dreambbs/issues
• IID 的 issue 清單：https://github.com/IepIweidieng/dreambbs/projects