Re: FW: External modules was Re: Ideas for implementing commercial su pport for Lua

["mnicolet" <mnicolet@...>]

I wish to add to this topic.
My main development/production platform is QNX 4.25,
which is a superb near-POSIX-compliant one, but being real-time oriented,
lacks two features
a) simple shared library support ( UNIX style ). The method to be used is
very cumbersome, because the
main native IPC mechanism makes more simple and may be effcient to devise a
server process than a so lib.
b) virtual memory ( disk paging of memory ) ( this is only an informational
issue ).
May be because of these lack of features, QNX is nearly uncrashable, and
extremely predictable.
I will mention PostgreSQL from two viewpoints, one of which deserves some
information
PostgreSQL is easily extensible using external C libraries,
the interface for that task is well defined and ´ported´ to a
lot of platforms ( Win32 included ), and I suggest that model for the
interested people. See the source code
in www.postgresql.org.
But, on the other hand, my own ´porting´ of the ´dynamic
loader´  to my loved QNX was a sort of trickery: how to
statically link some libraries, while convincing postgres
that they are really external and dynamic. That sort of
trickery involves patching one module, and a lot of
makefiles conditionalizations. The net result was I losed
interest in postgres, because every new release is a new
hacking adventure.
I would not like to see same sort of thing interspersed
into the Lua mainstream distribution. A lot of devices
( barcode handheld collectors, to add to list ) have no
facilities for that type of execution model; even if a lot
of them offers a ´DOS platforms´ it´s not clear if memory
extenders ( pharlap, by example ) would work.
I think Lua must be maintained ´as is´: a little language,
portable to every platform for which a C compiler is
available. May be, dynamic link support would be a
´branch´ cleanly separated from the main sources.
I don´t dismiss the dynamic linkage convinience, in fact, lots of times I
think ´that would be the solution´ ,
but it seems to me that it´s easy to add that feature, than
to skip over it.
----- Original Message -----
From: "Luiz Henrique de Figueiredo" <lhf@tecgraf.puc-rio.br>
To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
Sent: Monday, November 18, 2002 9:53 PM
Subject: Re: FW: External modules was Re: Ideas for implementing commercial
su pport for Lua


> >Just calling one function in the C dll/so from Lua is not enough. Have
you
> >got plans on how the C code will actually interact with the Lua engine
> >(where it's being called from).
>
> The idea is that the "init" function will register other C functions in
Lua.
> Yes, it does receive a lua_State* -- the "init" function is Lua function
written
> in C. Could you please explain why this scheme is not enough?
>
> >This won't work across different Lua versions. Do all the modules being
used
> >need to match the Engine using them?
>
> Yes. This is a hard problem. Different Lua versions have different APIs,
> although we do take pains in trying to maintain compatibility, but
sometimes
> this compatibility is obtained via macros and so existing code must be
> recompiled.
>
> >Or do you plan on providing a limited set of features that are supposed
to
> >remain binary compatible (in the Engine) also in the future?
>
> That would be nice, but I'm not sure we're ready for binary compatibility
yet.
> --lhf