Lua Cheia Summaries
 |
||
|
Lua Cheia Summaries |
|
Currently this is limited to important decisions being made by the group. I will also put up important milestones. Should be updated weekly, probably on Tuesdays. - ThomasWrensch
Threading Libraries
Discussion of which threading library to use. Some suggestions were:
No decision reached.
Extensions used for different platforms
What extensions to use for different platforms? There seems to be two possibilities: Use a standard extension for all systems (many suggestions, including .x, .lux, .lch, etc.), or use the native platform extensions.
The consensus seems to be to use the platform standard file extension.
CVS Structure
Considerable discussion of CVS structure. Issues:
Lua 5.0b sources added to the CVS (minus 'test' directory) Many of the overall structure change suggestions were agreed to. Some were made (?). Still in flux.
Posting to LuaCheia Mailing List
Limit posting to LuaCheia mailing list to people who have joined the project?
Consensus seems to be "yes". To do otherwise would make decision-making difficult.
# Comments
Modify Lua in LuaCheia to accept #-line as a comment? (Actually only requires supplying a block reading function, at least in Lua 5.0).
It's been suggested that this is resolved as a separate readconfig() or some such function that is not part of the language. Couldn't confirm based on mailing list traffic. Needs confirmation.
Where do Lua Scripts Reside?
There was some question about where small tool scripts (in Lua) reside.
Unresolved.
Placement of LuaCheia module in Lua
Placement of the luacheia module in the global namespace of Lua. Should it be its own module (in the global 'luacheia' or part of the 'lib' module structure: 'lib.cheia').
Seems to be moving toward use of lib.cheia rather than a separate module name in the global space.
listdir function issues
Problem with listdir function: can't determine if a file is a subdirectory or not. Suggested solutions:
Seems to be moving toward use of trailing '/' if a portable technique can be found, or use of a second listdir if not. May be able to handle conversion between these two in Lua rather than C.
Moving from C to Lua
Suggestion to move many of the functions currently stubbed out in luacheia.c (?) to Lua functions rather than C functions.
Several people have agreed to this, but not enough to make it a consensus.
Commenting Style
Commenting style: put comments before or after the function prototype?
Consensus seems to be that either is fine, but we should probably pick one as the standard. (Note: Choice will probably move to after because much of the existing code is done that way).
Use DevCPP/MinGW for Win32
Move to DevCPP/MinGW for windows port (rather than MSVC).
Seems to be a consensus (and a good idea to boot!)
GUI APIs
Considerable discussion early on, main contenders seem to be FLTK and a somewhat stripped down wxWindows. Decision seems to be not to limit ourselves to a particular kit yet, as the overall architecture that's emerging can accomidate multiple different GUI systems.
Modules
Here are some of the modules suggested to include in LuaCheia:
Scintilla
TableControl (etc.)
SQLite
BigNumbers
LuaSocket/LuaSock-like support
This is not a hard and fast list and should grow and change over time.
Module naming/namespace issues
A LOT of discussion, but the group seems to have settled on the use of a hierarchy of names with 'lib' as the global root for libraries and 'luacheia' as the global name for the basic LuaCheia functionality. Also suggested that the load function return the function table so that it can be assigned as a shortcut. Something like:
SDL = cheiaload("sdl.x")
Which would place a module in lib.SDL and also in the global SDL for
"quick" reference.
Logo (Icons)
Logo are sticky closely to the idea of a modified Lua logo. Several logos suggested, and placed on a web site at different sizes:
[http://luacheia.lua-users.org/images/icons.gif]
Every seems happy with some/all of these, but no final decision has been made.
Lua version 4 and/or 5
This seems to be unresolved, but leaning toward focusing on Lua 5. Major arguments are:
Startup loading of modules
A general approach to startup/loading of modules was proposed. Here it is directly from the list:
> 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.
Several people thought this was a good approach, but not enough to have me say it is emerging as a group decision.
Static versus Dynamic linking
Dynamic seems to be the preference with several people pointing out that there are very good reasons to allow for static linking, such as OSes that don't support dynamic libraries and the creating of all-in-one binaries.
There's an emerging agreement to do dynamic linking while trying to make the building of staticly linked versions as easy as possible.
Ship only on full moon
Suggested, agreed on by quite a few people. Seems to be a firm decision.
![[http://luacheia.lua-users.org/images/icons.gif]](http://luacheia.lua-users.org/images/icons.gif){kind=link}