ANN: Lua 4.0 for EPOC (& musings thereon)

[Reuben Thomas <rrt1001@...>]

I've compiled up Lua 4.0 for EPOC, and it's on my web site (URL below,
choose "Lua ports" from the menu).

I hope people find it useful. As yet it's a very BASIC port, but I'm working
on the technology. Unfortunately the EPOC headers are broken, but I have
made some progress: I've found remove() (in unistd.h, doh!), and it looks as
though there may be signal support (it doesn't link normally, perhaps I'm
not using the right libraries or something...).

I've also managed to get liblua.a into a DLL (though a quick test gave a
kernel panic (not serious under EPOC), which I've not managed to reproduce;
it was running one of my bitwise library operations at the time, which is
pretty simple...works fine now).

Anyway, although I'm keen to make further progress, it's not high on my
priority list, so I'd appreciate offers of help. Also, I'd like to know if
anyone actually uses Lua on EPOC (it seems to be ideal as it's fast,
portable and small), and if so, what they'd like to see improved.

A note on DLLs: EPOC needs *two* macros for DLL-exported functions: one to
export them (when building the DLL) and one to import them (when using the
library). This can be handled with -DLUA_API=foo and -DLUALIB_API=foo.
Thanks, Lua team!

One final thing: I can't compile liblualib.a as a DLL, because EPOC DLLs
don't allow static data. This has now been removed from liblua.a (it wasn't
in 4.0 alpha, the last time I built for EPOC), but the static data in
liblualib.a looks as though it's there to stay (it's all constant, so
doesn't present a problem for multithreading). If anyone knows a workaround,
I'd be grateful to hear it. I'm trying to move all my changes out of the Lua
source so that my port is more easily maintainable, and making the static
data accessed by functions is therefore not a good option.

-- 
http://sc3d.org/rrt/ | impatience, n.  the urge to do nothing