Re: Moving Lua source codes

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

Taylor,

>    I found out that several programs already have Lua bindings, but for
>    unknown reasons that code is not enabled by default, which is kind of
>    weird given that the Lua library is in base...  So we have Lua bindings
>    in our code, whe have Lua as well, but yet we don't enable it and
>    continue to whine about nothing using Lua, that's weirder than weird ;)
> 
> Bindings do not an application make.  For years, many people have been
> asking you for real, working Lua code that (a) serves some nontrivial
> purpose beyond mapping between the C world and the Lua world, and (b)
> has a compelling reason to rely on Lua in base rather than Lua in
> pkgsrc.  But so far, all I've seen is a few bindings to C libraries.

Lua is a scripting language in the original sense of the word, a
language to be embedded in a hosting program, to make this program
extensible.  As such, Lua bindings in hosting programs are key.

But not only there, it also important to provide access to key
functionality in the form of Lua bindings.  That is why Lua modules like
sqlite, pgsql, json, gpio, or whatever exist.

Lua provides an easy to use, easy to learn, yet powerful interface to
the system.  It is a tool not only for developers, but also for users of
NetBSD.

It's like a shell:  We provide it to our users so that they can do magic
with it.  It's a tool.

httpd(8) uses Lua by default.  You can use Lua to create dynamic
content, like you do with a CGI script, but the startup time is faster.
 You can access SQLite3 database files from it, creating e.g. a fast
blog or whatever web application.  Lua is a tool, it's your imagination
that sets the limits.

> It is entirely plausible to me that we could benefit from using Lua in
> base, or sysinst, or maybe even in the kernel.  But that argument must
> be made by showing evidence of real, working code that has compelling
> benefits, together with confidence in its robustness -- not by saying
> that if we let users do it then it will happen.

There is real word, real working code.  In userland and in kernel space.
 There are developers waiting for the kernel parts to be committet, so
they can continue their work as well.

I myself use Lua since years in the kernel, sysinst, and now also in
httpd(8).

I did not commit all uses of Lua, because they are very specific to
_our_ (i.e. my company) uses.  And that is what Lua is about:  I can use
it to taylor (no pun intended) a certain piece of software to my needs.
 I agree that the sysinst Lua integration should be commited.

We use Lua in sysinst since ever to install pkgsrc packages during
install time, btw.  I use Lua in the kernel to simulate certain types of
devices.

> Why don't you experiment with some more radical changes for Lua in a
> branch, mbalmer-lua?  You needn't worry about anyone else's approval,
> you can break anything you want, and you can let others review and
> play with your work.

There is nothing radical about Lua.  In userland we already have it, no
need for a branch.  Use it, if you like.   Adding Lua to your software
is easy and straightforward and will not bloat it.  In the kernel space,
all of Lua we did so far are loadable modules, no existing kernel
subsystem needed to be changed source code wise.  So it's perfectly self
contained and does not interfere with the existing kernel code.  Again
no branch needed.  Kernel mode Lua is a few kernel modules plus a
utility luactl(8) to control matters from userland.  A new tty line
discipline attachment program will probably make use of kernel mode Lua.

I see no need for a branch.  A branch would probably only mean that no
one will ever look at this code anyways.  -current is where development
should take place.  And I am careful enough that this development does
not interfere with the work of others.

- Marc