This page, and its associated code, record my initial experiences using the Lua-Ada bindings. Just to note their location, the bindings are linked from this page at github.
This test code is available for anyone to try, and may be fetched with:
git clone git://ftp.niestu.com/alua
And built with:
make
The resulting executables will be in the bin directory.
It all started with this comment on IRC:
Feb 10 06:46:28 <rothwell> not sure it can call external shell commands, can it?
Upon more careful reading, I think he was actually talking about GNAT's project-file build system. But I took it to mean running Lua from Ada, since I'd just been talking with him about his bindings which I'd managed to build only hours before. Having built it, I figured it might be nice to see if I could actually use it, and that seemed a simple-enough test.
So I copied one of his unit-test programs, called execstring, and
changed only the string it tried to exec, to "os.execute ('ls')".
Bleh, no joy. Turns out, his program had this:
Lua.Lib.Open_Base (State);
But that doesn't load the "os" library, oops. And for some odd reason, there's currently no separate binding to load just the os library, so I eventually tried this, which worked:
Lua.Lib.Open_Libs (State);
That loads all the standard libraries, including os; a bit of overkill, but eh, who's counting. And voila, my Ada program did an "ls". A couple of debugging strings are commented out in the Ada source, and I think I'll leave them there, much as I usually hate commented-out source.
Now that I was successfully building Lua-Ada code, I needed to understand how it worked. So I copied an example I found on the Lua wiki and renamed it "runit", which is not short for "r-unit", but for "run-it". Brilliant, no?
The Ada code creates a table on the Lua API stack, calls a short code chunk that expects such a table, prints what it gets, sums the contents, and returns the sum as its result. The Ada code then prints that result.
And holy jeepers, that worked too. So now I was on a roll.
The gettbl program was intended to be closer to a real-world
example. I specifically had in mind my little "ship" program when I
wrote it, and envisioned writing a simple AI in Lua that controlled
the ship, by getting some data from the Ada code, manipulating it,
then returning its results. The "get table" implied by the name is
the Ada code getting a table back from the Lua script.
In this test, the data passed to the script is the same table from the
runit program, which it prints and then promptly ignores. The
result it returns is a table that acts as a record, envisioned to be
changes to the ship's thrust: heading ("h"), elevation ("e"), and
magnitude ("t" for "thrust"). Any of the three can be present or
omitted, and the Ada code checks and notes which value(s) it received
from the script. In practice, the Lua would probably get a table of
bodies, including their heading, elevation, and G force, and
presumably a command to execute, like "fly to/near body X at all
possible speed, with an acceleration limit of N G's". Or whatever.
I think this demo code shows how that could be done, although I'd need
to see exactly which sort of data would be best to pass to the AI.
This time there are some commented-out lines in the Lua code (in
scripts/ship-ai.lua), which again I've left in place because they're
instructive and useful.
The callproc proggie was the culmination of this round of Lua-Ada
testing. It defines an Ada function that is callable from Lua, and
then execs a short code chunk that calls it. That Ada function both
receives values from Lua and passes back a result, to show how each is
done. Presumably a nice set of Ada support functions that provided
complex and/or app-dependent computation to Lua scripts would make
writing things like AIs and other embedded scripts a snap, or at least
less of a chore.
And that's the lot for now. I think it illustrates how to do everything I currently want to do with embedded Lua.
Last Updated: 22 Feb 2011 09:03:54