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