[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Is a Lua system easily embeddable? (was Wishlists and Modules (was [ANN] libmc))
- From: Andre de Leiradella <aleirade@...>
- Date: Fri, 04 Sep 2009 17:09:08 -0300
David Given wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andre de Leiradella wrote:
[...]
I don't seem to remember the necessity that brought Lua modules to life.
Was it to make life easier for the language users? Who are the language
users?
Yup.
Lua means two things, and it's all too easy to confuse them.
The first Lua is the *language*. This is the tiny core of the system
that's been there for years (long may it not grow).
The second Lua is the *platform*. This is the complete programming
environment based around the Lua language. This consists of the
language, of course, but also the complete set of libraries to actually
get work done; and, most crucially, it also consists of the
specifications and processes in place to allow Lua to be extended
orthogonally.
It sounds like what you're after is the Lua *language*, with very little
*platform*.
What I'm after is a Lua based platform I can shape and build.
If there is the need of making a platform for people with little
knowledge of C and make to use, I don't think this should make it harder
to me or prevent me from building my own.
The thing is, they're both utterly vital things to have. Back in the Old
Days the platform was really just an afterthought to the language,
without proper modules, and everything was just hacked into the
interpreter on an ad-hoc basis. Writing standalone scripts was a
nightmare! If you tended to work solely in the embedded world, you may
not have noticed this, but trying to deploy an actual Lua *application*
was basically impossible --- there was no workable means of adding all
the necessary functionality to the user's Lua interpreter beyond
shipping a complete customised interpreter.
Which is how it's supposed to be. The Lua interpreter shipped with Lua
sources is just, IMHO, an example application of how to write a host
application which embeds Lua.
The New Way really is an improvement. It's made life vastly easier for
desktop people. It's also made life easier for embedded people, because
the module system is useful for them, too --- and if you don't need it,
you can still do things the old way and that still works fine.
>
(I work in both the embedded and desktop worlds, and in fact I would
like the distinction between the language and the environment to be
widened --- core Lua still has a number of dependency on things like
stdio that some embedded devices don't have, and it would be rather nice
to have a core CPU-only Lua library that had *no* I/O at all, with even
stuff like print, io, and loadfile() abstracted out.)
[...]
Lua has always been simple and easily embeddable. It still is. But its
libraries aren't anymore.
Weeelll...
I think you're having problems because you're wanting to have your cake
and eat it, too; you're wanting to use complex modules like luasocket
without having the complexity. That's not going to work, more or less by
definition. If you want to have mixed Lua/C modules, you need the
framework for managing mixed Lua/C modules. (And if you don't, you don't
- --- you can still load C-only modules in precisely the same way that we
used to.)
I have developed mixed libraries, and it was just a matter of
registering the C functions and executing Lua code to setup the
environment so that scripts could be run. I used them together with
other libraries and it was just a matter of initializing things in the
right order.
What you want is a set of custom loaders that provide access to C
modules via direct linkage and Lua modules via embedded chunks of Lua
code. It's not a lot of code, and would give you the ability to
dynamically load modules as needed on your filesystem-less embedded
device in precisely the same way that you would on the desktop. This has
huge implications for testing and debugging; doesn't the idea of being
able to run scripts on the desktop before running 'make' and directly
producing a firmware image for your SoC appeal to you? It does to me!
It does, but things should be made the other way around. Take the
libraries and build upon them to make modules. Start simple and make
more complex things. Do not start complex and try to remove that
complexity, it's sometimes very hard to do it.
Cheers,
Andre
That said, I *am* surprised that nobody's come up with a harness to make
this stuff easier yet. It should be nearly trivial to write a set of
loaders in C that use a big lookup table to find modules, and almost as
trivial to write a command-line tool (in Lua, naturally) that would
parse a rockspec file and automatically populate said table, complete
with turning the Lua scripts into embedded data. Am I wrong? Does
someone have such a thing? It would be dead handy --- I could have used
it for Wordgrinder.
(In fact, it would be very easy to do with Prime Mover, which supports
dynamically generated code really well. Hmm...)
- --
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────
│
│ "People who think they know everything really annoy those of us who
│ know we don't." --- Bjarne Stroustrup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFKoXaff9E0noFvlzgRApeqAKDK2O9tOI96gewdCrGV0G/pDO5tUACfd/jZ
fyoY+ryWBmVJTq9BSLpiHTc=
=ssXg
-----END PGP SIGNATURE-----