lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

This sounds like a far more daunting task than your original post suggested.

If you have to....

1. Write scripts to interact with an existing (black box) program that is
using some unknown method of linking to / C-side controlling a Lua state.
2. Through these scripts you must interface to a second program/process.

As a first blind stab here, I have to ask....

Does the program with the Lua interface provide access to the Lua io
If so then you can make a quick solution (albeit not necessarily a terribly
efficient one) by writing the data out to files and reading from them in the
other program.

If not then you are indeed going to face some serious difficulties.

If the "engine" you are connecting to allows Lua scripts to use loadlib to
load external C libraries then you can begin to consider writing C-code to
work with your scripts.  However, your main problem (other than the fact
that you need to go study the Lua manual for a little while) is that you are
going to have to risk using more than one instance of the Lua code (i.e. you
will have to link it in to your DLL so that you can use the C-API).  These
instances may not be identical, and even if they were, they won't use the
same C-runtime data.  Mainly this means that you are likely to get crashes
in calls to free due to the fact that the memory to be freed can't be found
in the heap of that particular instance of the C-runtime.  This will of
coarse come up at GC time.

Someone may have a much brighter idea, but it sounds to me like you are
"doomed" to end up modifying the Lua sources to attempt to somehow work
around this issue.

In an optimistic light, it is Of course completely possible that this
"engine" offers some helpful information / hooks for this kind of extending.

-----Original Message-----
[]On Behalf Of Gene Buckle
Sent: Thursday, March 11, 2004 2:41 PM
To: Lua list
Subject: RE: shared memory access from within a Lua script..

> With those changes it works great with shared memory in Windows when
> linking Lua statically.  I have been using this is a commercial product
> for a while now with no problems.  If you do this, other Lua DLL modules
> may not work properly but if working with a closed system it works like
> a charm.  You can link Lua statically in your app and in DLLs and they
> will not have memory issues this way.
> - Brett

Brett, my problem is that I can't change Lua at all.  It's built into a
commercial product that I don't have the sources for.

My task is this - The product I'm working with (a game) will provide some
special Lua functions for reading data from the game internals and
functions for setting states within the game engine.  I have to use those
functions to interface with the real world in the simplest and most
efficient manner possible.  I also have to accomplish this without
changing the Lua interpreter from what you'd normally find in a default

I spend all day writing Delphi and VB database code.  I'm _not_ a C
programmer by any stretch of the word.  I can read it fairly well, but I
have little experience writing it.  You can understand why I find this a
daunting task. :)