[Toybox] G'day, and thoughts about lua.

[Rob Landley]

On 11/19/2011 05:36 AM, David Seikel wrote:
> G'day.  You might know me from the Aboriginal Linux mailing list.

Hello.

> I know that lua has been considered for toybox, but I don't think
> there's been any movement on that.

The language is great, the libraries weren't there.

The problem with lua is there's no standard posix bindings.  There's an
aftermarket library, but it was incomplete and development is
intermittent.  (If I recall, it didn't even have a public mailing list.)
 I worked out that in order to implement the set of commands busybox
currently has, I'd need two install at least two lua support packages on
top of lua itself, and probably wind up doing C extensions anyway.

If I have to extend it in C, I might as well write it in C in the first
place, which is what I'm doing now.

> I've recently been doing major work on the Enlightenment Foundation
> Libraries (EFL) lua support.  Turning it from a proof of concept demo
> into something actually useful.  I'm using it in a project in
> combination with Aboriginal Linux, so I know what the minimal
> dependencies are, and other useful experience.  Some of that work might
> be useful for toybox.

Cool, but at the moment I'm doing a pure C version.  I might work on a
lua version after I've got that working.

My original C version rolled to a stop because being in the same niche
as busybox (with its 10 year headstart, 3 years of which were my own
work, and over a dozen active develoeprs including my own handpicked
successor) wasn't really my idea of fun.

But a BSD-licensed one isn't really in the same niche. (The license is
what's kept Busybox out of most Android deployments.)  Plus my
enthusiasm for working on busybox never recovered due to the giant
hairball it's turned into (hit 300 commands without breaking stride, and
still going...  No fun anymore.)

> Basically my work has been implementing more of the EFL API as lua
> functions for lua scripters.  Largely that's boilerplate code to wrap
> existing C functions.  So I spent a lot of time factoring out the
> boilerplate to make it all a lot easier and smaller.

Hmmm...

> For what it's worth, the EFL lua stuff is BSD licensed, and lua itself
> is MIT licensed.  Should be no problem with those.

What I _would_ like to do is have a native build control image that
builds LUA for each target.  If I could produce a binary lua tarball you
could put on arm/mips/ppc, that would be really cool.

But that's an aboriginal list issue, not a toybox issue. :)

> This is using C hosted lua embedded in EFL apps as a sandboxed internal
> scripting language, the way lua was meant to be used.  Toybox does not
> need the sandbox, as parts of it pretty much HAS to dig deep into the
> guts of the OS.  "sudo rm -fr /" implemented in lua has to work, even if
> it's a silly idea.

I was looking into this back around January in preparation for meeting
@agladysh when I was in Moscow.  We wound up not connecting up and I'm
unlikely to go back there in the forseeable future.

> So I would think that lua in toybox would be similar, but without the
> sandboxing.  The existing toybox C code, with lua embedded in it, lua
> API wrapped around useful common infrastructure, plus start to write new
> stuff in lua where it makes sense.   If that's the way you want it,
> then I'd be happy to bring the relevant bits of my current lua work to
> toybox.  Even if it's just an experiment to see if it's worthwhile.
> 
> What do you think?

I'm quite interested in lua, but I spent well over a year going "I
should do lua" with toybox... and never did.  I _started_ working on it
a half dozen times, and just never got traction.  Whenever I tried to do
anything nontrivial, the language just wouldn't hold any weight without
C extensions.

You're proposing embedding lua in C, which doesn't get you away from
cross compiling.  (One of the big points of a scripting language is it's
target agnostic.)  Instead this essentially acts like an extra build
dependency along the lines of zlib or ncurses.  It may do great things,
but I don't want external dependencies...

Rob

 1321750963.0