I choose Lua 5.1 as my application's embedded scripting language, but when I port the application to a legacy platform runs LynxOS on PowerPC, thing seems going wrong.
I get following code run up on PC and every thing looks good:
void test_lua()
{
const char *code = "foo = 5\n";
double vfoo=0;
lua_State *L = luaL_newstate();
(void)luaL_loadbuffer(L, code, strlen(code), "line");
(void)lua_pcall (L, 0, 0, 0);
lua_getglobal(L, "foo");
vfoo = lua_tonumber(L, -1);
lua_close(L);
myTrace("vfoo = %f", vfoo);
for(;;);
}
with PC (Visual C++ 6.0) I got expecting "vfoo = 5.000000"
But with LynxOS/PowerPC I got "vfoo = 0.000000".
So what's going on for Lua on LynxOS/PowerPC ? I am wondering if there are some configurations for big-endian machine, I looked for it in "luaconf.h" but find nothing. I also tried the configuration item "LUA_USE_POSIX" but no help.
I know it's not a typical platform for lua programming. However, any suggestions are welcome and be appreciated.
It is not supported by a large organisation and has not even been endorsed by the Lua team. The most sought after features of Lua are implemented and maintained by the community. If a module becomes outdated, it’s up to the community to support it.
Lua is extremely powerful as a general purpose scripting language. I have used it extensively for scripting in a systems admin position due to how small the binaries are and how efficient it is. You don’t need to worry about versioning (unlike with Powershell) when you’re dropping precompiled binaries on each machine.
There is nothing Python can do Lua can’t. There is a lot of stuff Python can’t do that is easy in Lua. Just because you might have some experience is not reason enough to ignore Lua, because those 21 keywords are quickly learned and your project will go on for a while so that you will be in the end better in Lua than you are now in Python.
The need for compile-time checks is more important in an embedded scripting language (the intended use of Lua), in my opinion, because it is more likely that it will be used by inexperienced developers. It is even more important when used for scripting games, since games tend to be more difficult to debug.
Endian-ness shouldn't affect the operation of the lua code. I have ported to several platforms that are not Win32, and I've run into times where the LUA_IEEE754TRICK that is used to convert a 64-bit double into an integer does not always work, but is enabled by default. Try undefining the LUA_IEEE754TRICK macro in luaconf.h.
I have also encountered clibs where the floating point printf/scanf functions were broken or unreliable, and I had to write my own custom version of lua_number2str.
I feel for you though. The lua engine is a large, black box that is confusing to step through and debug when something goes wrong with its internals. In my case it has usually been the compiler/clib's fault, but that doesn't make it any easier to make the 2 get along with each other.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With