Re: Epoc, Lua and toLua (was EPOC memory-leak)

["Andrew Wheeler" <awheeler@...>]

> Sounds right.  And if anyone is going to use Lua with Eikon and the
> Crystal Nokia 9210 SDK, they should be aware of this snag:

                     [  snag removed for brevity. ]

Thanks for the 411.  I wonder why this machine acts different than the
standard ER5 device...is the 9210 running ER6 (is Eikon ported to ER6?), or
are the exit-changes normally disabled on the Psion devices and standard
emulator?

                                 *

> For the rest, are you people using Lua with Eikon?  And if so, are you
> using toLua or how do you do it?

I'm using Lua with Eikon: though I'm not making many Eikon calls from Lua,
if that's what you're asking.  I modified the Eikon sample
"console-application" (in the SDK at \eiktest\tcons0) to execute Lua
test-scripts, sending all STDOUT to said console.  Since Eikon is
event-driven, I can't write straightforward "procedural" scripts, nor use
the STDLIB model of getting keyboard input: i.e., I can't wait in a
tight-loop until the user types.  So my Lua scripts are broken into distinct
"pieces" - mostly callbacks for the events that occur, with a "main" script
that does all the init, sets up the callbacks, and gets things started...

> I am greatly tempted to use Lua since it runs on both SIBO and EPOC and
> nce my C program needs a rewrite anyway.  But when I get into the
> actual programming I begin to wonder if Lua actually makes a difference,
> and especially so if you already have a working C program.  The brief
> examples on the toLua page also make me wonder if the gain is great
> enough to warrant the introduction of Lua.

I'm also using toLua: it is much more "nuts and bolts" than I'd like it to
be, in that my Lua scripts look much like C++.  This is further exacerbated
by us using a component object model, a minimal COM implementation: though
it's quite neat to be able to utilize "COM" through Lua, if you've ever seen
C++ code that uses COM then you'll know it ain't pretty at all!  Since my
goal is to enable our test engineers to write cross-platform scripts that
will test our cross-platform software modules on all the systems, I'm hoping
to simplify the environment by adding many fundamental Lua functions that
will abstract much of the "infrastructure" stuff as possible...

In my case, I think Lua will pay off by enabling the test-engineers to not
depend on the software coders to compile new test-executables for each and
every platform.  But if I was only focused on a single platform I think Lua
would only get in the way of sw-testing.  Regardless, we're planning on
using Lua/toLua for much more than just sw-testing, so it's a no-brainer to
add Lua/toLua to our project...

-andrew