Lua Cheia 摘要

wiki

LuaCheia 郵件列表摘要

目前此列表僅限於小組做出的重要決策。我也會加入重要的里程碑。應每週更新一次，可能會在星期二進行更新。– ThomasWrensch

2003 年 2 月 24 日星期一

執行緒程式庫

討論使用哪一個執行緒程式庫。以下是部分建議

- Pthreads

- SDL 執行緒

-「便宜的執行緒…」文章

尚未做出決議。

用於不同平台的延伸模組

要為不同平台使用哪些延伸模組？似乎有兩種可能性：為所有系統使用標準延伸模組（例如 .x、.lux、.lch 等），或使用原生平台延伸模組。

共識似乎是使用平台標準檔案延伸模組。

CVS 架構

大量討論 CVS 架構。問題

- 要在 CVS 中包含 Lua 原始程式碼嗎？

- 建議對整體架構進行變更。

將 Lua 5.0b 原始程式碼新增至 CVS（不含「test」目錄）。多數整體架構變更建議均已同意。某些部分已變更（？）。仍處於變動中。

發布至 LuaCheia 郵件列表

是否將在 LuaCheia 郵件列表中發布的內容限制為專案參與者？

共識似乎是「是」。不這麼做的話，可能會讓決策制定變得困難。

# 註解

是否修改 LuaCheia 中的 Lua 以接受 #-line 作為註解？（實際上只需要提供一個區塊讀取函式，至少在 Lua 5.0 中是如此）。

有人建議將此解析為獨立的 readconfig() 或其他類似的函式，而非語言的一部分。無法根據郵件列表流量確認。需要確認。

Lua 腳本放置於何處？

有些問題是關於小型工具腳本（以 Lua 編寫）放置於何處。

尚未解決。

LuaCheia 模組在 Lua 中的位置

Lua 全域命名空間中 luacheia 模組的位置。此模組是否應為其自己的模組（位於全域「luacheia」中或「lib」模組結構中：lib.cheia）。

似乎傾向於使用 lib.cheia，而不是在全域空間中使用獨立的模組名稱。

listdir 函式問題

listdir 函式發生問題：無法判斷檔案是否為子目錄。建議的解決方案

- 再次使用 listdir 來判斷是否為子目錄

- 標記目錄名稱（尾隨「/」字元）

- 將子目錄設為子表

似乎傾向於使用尾隨「/」，如果能找到可攜式技術，或者如果不行，可以使用第二個 listdir。可以在 Lua 中，而不是在 C 中處理這兩種方式之間的轉換。

從 C 轉移至 Lua

建議將目前在 luacheia.c (?) 中存根的許多函式轉移至 Lua 函式，而不是 C 函式。

有幾個人同意此建議，但人數不足以形成共識。

評論風格

評論風格：將評論文字置於函式原型之前還是之後？

共識似乎是兩種方式都行，但我們應該選定其中一種做為標準。（註：選擇最終可能會轉變為之後，因為大部分現有程式碼都是這樣做）

使用 DevCPP/MinGW for Win32

轉移至 DevCPP/MinGW for windows 移植（而非 MSVC）。

似乎已形成共識（是個好主意！）

2003 年 2 月 17 日，星期一

GUI API

在前期引起了大量的討論，主要的競爭者似乎是 FLTK 和精簡版的 wxWindows。決議似乎是不先限制自己於某個特定套件，因為正在形成的整體架構可以容納各種不同的 GUI 系統。

模組

以下是建議納入 LuaCheia 的部分模組

• PCRE（perl 相容的正規表示式）
• SDL
• SDL_image
• SDL_ttf
• SDL_mixer
• FLTK
• wxWindows（僅基本 GUI）
• wxWindows.Scintilla
• wxWindows.TableControl（等）
• SQL / SQLite
• 執行緒
• BigNumbers
• 基本 OOP
• LuaSocket/LuaSock 類似的支援

這並非既定且固定的清單，應會隨著時間推移而增長和變化。

模組命名/命名空間問題

引起了許多討論，但該團隊似乎已解決採用名稱階層的方式，以「lib」為程式庫的全球根目錄，而「luacheia」為 LuaCheia 基本功能的全球名稱。也建議載入函式回傳函式表格，以便將其指定為捷徑。類似

   SDL = cheiaload("sdl.x")

這會將一個模組放置於 lib.SDL 中，也放置於 global SDL 中以供「快速」參考。

標誌（圖示）

標誌緊密貼近修改後的 Lua 標誌概念。建議了數個標誌，並將其以不同的尺寸放置於網站上

[http://luacheia.lua-users.org/images/icons.gif]

似乎所有人都滿意這些標誌中的部分/全部，但尚未做出最終決定。

Lua 版本 4 和/或 5

這似乎尚未解決，但傾向於專注於 Lua 5。主要論點如下

• Lua 5 是未來，何必繼續使用舊版本。
• Lua 4 是目前的版本，且有許多已運作的程式庫。

模組的啟動載入

提出了一種啟動/載入模組的通用方法。以下是直接從清單中擷取的內容

> 1) When Cheialib is initialised, it adds various module-loading and
> directory-scanning functions to the Lua state, in the luacheia table.
> It also adds a some variables, like a variable containing the name  
> of the platform: luacheia.platform
> 2) Luacheia then looks for a "boot script" that contains
> Lua wrappers of these low level C functions using local variables
> and setglobals(). The boot script is at a precomiled location
> (on POSIX), or in the program's own directory (on Windows),
> when all the hlua wrapper functions are defined, most of the global
> low level luacheia functions are disabled (apart from the directory
> scanning ones.).
> 3) The boot script then looks for modules it has to load,
> and loads them using the wrappers, finally retuirning control
> to the Lua interpreter.

有幾個人認為這是個良好的方法，但不足以讓我覺得這是團隊決定的結果。

靜態與動態連結

動態連結似乎是偏好選項，有幾人提出有很好的理由允許靜態連結，例如不支援動態程式庫以及建立 all-in-one 二進位檔案的作業系統。

一個新興的共識是進行動態連結，同時嘗試使建置靜態連結版本儘可能地容易。

只在滿月那天出貨

建議，而且已有不少人同意。看起來這是一個堅定的決定。