Re: Why do we need lua in-tree again? Yet another call for actual evidence, please. (was Re: Moving Lua source codes)

[Marc Balmer <marc%msys.ch@localhost>]

Am 19.10.13 09:12, schrieb Alan Barrett:
> On Fri, 18 Oct 2013, Lourival Vieira Neto wrote:
>>> I have to point out that "interesting work" is commonly used as a
>>> sort of euphemism to refer to highly experimental work with unclear
>>> future.
>>
>> Yes. But I'm talking about "interesting *user* work". I'm not claiming
>> that they should be in the kernel. I'm just saying that, IMHO, we
>> should incorporate a small device driver that facilitates this kind of
>> development (outside the tree).
> 
> You seem to want the lua "device driver" to be inside the tree, to
> facilitate experimental work outside the tree.  Other people have asked
> why the lua(4) device driver itself can't be developed outside the tree
> (with a view to importing it later, if it ever proves to be more than an
> experiment), and I have seen no good answer to that.

I can answer that.  Lua, the library in userland, the bindings to
libararies like sqlite or gpio, and lua(4) plus luactl(8) serve a
specific purpose, namely to allow NetBSD _users_ to work with the system
in an easy to learn and more dynamic approach.  They are tools for
users.  This has been the goal that I stated in almost any talk about
the subject matter.  It's like gpio:  That is also something for users.
 Hasn't Unix alwas provided the tools, but it was up to the user to do
with them what he wanted?  Lua is a scripting language in the original
sense of the word:  It allows a user to script or change the behaviour
of software.  It is not even seen as a freestanding language by it's
inventors, but rather a hosted language, a small library to be
incorporated in other software to make it extensible and more dynamic.
Yes, there is a lua command, but that is merely an example use of the
Lua library (as stated by the Lua developers).

More and more people that were aware of the benefits of Lua, both in
userspace, but also in the form of a driver, have pushed me to finally
commit this.  Also from a marketing perspective it's a good thing (and I
speaking as a member of marketing@ now):  It makes NetBSD more
attractive for newcomers, for hardware tinkerers and such.  The can now
use their Soekris or Alix board and use GPIO lines to do play with
hardware.  I showed NetBSD with Lua at a local ham (radio amateur)
meeting and they were thrilled.  A sofar Linux only community all of a
sudden created new NetBSD users.  And that is good.

There will always be folks who don't like Lua for various reasons.
Unfortunately they are very vocal and sometimes I do think that they not
always understand what Lua is and what it's general goals are. They
should just not use it, then.

And now to give you a practical example what I personally do with lua(4)
right now:  In the past I wrote several tty line disciplines to decode
various serial formats.  Now I have a need for that again.  Doing this
in C is of course possible, but I want something more dynamic.  So I
wrote a tty line discipline that uses Lua to do all the decoding.  That
works like a charm:  Load the script, test, change the script and
reload.  Really practical.  I will release this code once I sorted out a
few remaining details.  And in the course of this work, I also found
deficencies in slattach(8).

In previous work I used Lua to create a software gpio device, a modified
version of gpiosim(4) that uses a Lua script to "mimick" a real device.
 Also handy.

In one email thread I once specifically said that Lua should not
necesseraly be used to write system software, e.g. startup scripts or so.

Even when you see no use for Lua for your personal work, I hope that you
understand that there are users that have a valid and sound use for Lua.
 Or do you really thing we do a GSoC project, go to conferences, talk
about, bring new developers on board just to annoy anyone?  No, it's
because we (the Lua users) want it, not for the sake of it, but to work
with it.

- Marc