 |
lua-l archive |
|
|
||
|
gluax.[ch] are heritage of the LuaX project. Both of you are right in your analysis, but there's more to them as well.
Yes, they are sort-of my personal toolkit of making Lua/C bindings.
Yes, they can be used for smoothening over Lua version descrepancies (once they again arise?).
But the essence of gluax.[ch] is the ability to create modules, completely untied to the underlying Lua library. This mode, which is currently not used, allows even language-neutral bridgings to occur (think -DGLUA_RUBY). Whether this side ever plays an important role remains to be seen. Currently, it does not.
Even so, gluax.[ch] can be considered as black boxes, from the module user's perspective. They tie macros s.a. GLUA_FUNC to something Lua 5.1 native. The macros really do make binding code way easier to comprehend (my SDL binding serves a good example). On Lanes, the distinction is not so clear since that module needs to tackle some deeper-than-average issues, due to multithreading and use of several Lua states.
About Lanes, btw, there's a new version coming out soon. Supporting timeouts for receive() and results() and some other tiny enhancements. Also 1-to-N and N-to-1 communications are included.
-asko On Thu, 10 May 2007 08:25:50 +0200 "Anders Bergh" <anders@andersman.org> wrote:
I think it is so libraries can be compatible with other versions of Lua than the version was written for, requiring only a recompile.On 5/9/07, Matt Campbell <mattcampbell@pobox.com> wrote:I recently discovered the Lua Lanes package at LuaForge. I downloaded it and noticed that it uses a C library called GluaX. Does GluaX have an official home page, or is it mainly used by Asko Kauppi in his own projects, such as Lua Lanes? Also, what was the motivation for writing GluaX? I don't find the Lua C API itself that difficult to work with.Thanks, Matt-- Anders