Re: Lua libraries

[Ignacio Castaño <castanyo@...>]

Thatcher Ulrich wrote:
> > I was going to write a simpler example, but with my exams was not having
> > enough time to do so. I've seen you have separated the lua vm and the
lua
> > executable to avoid memory allocation conflicts. Is that also necesary
on
> > *nix or only in win32?
>
> Not sure -- I started on Linux, and ran into core dumps, and flailed
> around trying to fix it, but only later commented out the Lua API
> calls to register the library handle.  So possibly it's not necessary?

hmm... maybe not, I'm testing it on win32 and it works right. I will try to
test it on linux and solaris tomorrow at the university. Note that if you
don't register the library handle, the gc tag method won't be called, and
the library won't be released, producing a resource leak. Anyway, I will
study that code in detail to see if there's something wrong.


> On Win32, I don't think the issue is memory allocation (as long as you
> use the MSVCRT C library, which is thread and DLL aware I think).  The
> issue is that DLL's that call the Lua API won't be able to see the Lua
> code in the core .exe, but they will see it if it's a DLL.

woah, I didn't know that! using MSVCRT solved all the allocation problems
:-)
Anyway the dll approach is still cleaner and does not repeat the code twice.


> Another observation: the Lua core makefiles are *almost*
> nmake-compatible; all they really need is the definition of macros to
> change the file extension conventions (use .obj instead of .o, .lib
> instead of .a, etc).  One approach to a "more universal" core Lua
> distribution would be to add those macros, and then have a
> "config.win32" or instructions for Win32 folks, so they could compile
> with "nmake".  I guess this could be a PowerPatch.

Personaly, I've never used "nmake", but that seems like a good idea.


Ignacio Castaño
castano@asidesoft.com



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com