5 ms·

why would they not use lua ? which is pretty popular (and pretty much designed) as embedded scripting languages. Not to mention much more lightweight than pytho

why would they not use lua ? which is pretty popular (and pretty much designed) as embedded scripting languages. Not to mention much more lightweight than python.. and has a much smaller footprint. Nginx is a pretty good example of this.

chungy 10y ago
GRUB already has Lua, so I imagine the answer is "because we can"
- sandGorgon 10y ago
  interesting. I never knew that... i wonder if any additional socket library dependencies were problematic in the lua world.
Bromskloss 10y ago
What is it that makes the language suitable for being embedded? Actually, what does it mean to be embedded?
- agumonkey 10y ago
  Lua is extremely small, simpler, and has a jitted version. It's been used extensively as a scripting language in video games so has more mileage in constrained environment. Never used it really, just stating what other people say. And luajit author, Mike Pall, is extremely skilled.
- imtringued 10y ago
  You can launch a lua vm with an empty environment table (in other words no standard library). This means only the functions you manually put into the environment table can be used which makes sandboxing extremely easy. I must admit I've only used luaj where interop to java boils down to something like http://stackoverflow.com/a/19629914 http://stackoverflow.com/a/19629914 and you can optionally use reflection for even easier intertop if I recall correctly.
- walkingolof 10y ago
  Lua as mentioned before is very suited to run in an embedded environment because of it small size (both when executing and the actual source code size) and its modules, which makes it trivial to remove everything except the core language (IO support etc). I'm running Lua on a DLX like processor implemented on a fpga, in this context Lua performs the same role as Basic did on many home computers in the 80's, a small IPL is setting up the machine and loading Lua on boot.
JoshTriplett 10y ago
> why would they not use lua ? The target audience for this is BIOS developers and firmware engineers. Several existing development tools in that area already support Python, including Simics and the Intel ITP, so the target audience is used to it. Lua also has several other impedance mismatches with the target audience, such as 1-based array indexing (remember, the target audience writes assembly and C). While people often describe Lua as "easy to embed", personally, I don't find Lua's stack-based C API easy at all; in particular, the references to stack-based indexes that change when you push or pop the stack feels like working with stack-based parameters in assembly without a base pointer, where the offset of a given location can change at any time. I much prefer the Python C API. Finally, Lua would require additional libraries to provide a useful environment, precisely because it can assume so little about its environment. For instance, we'd need to bundle one of the Lua socket libraries in addition to Lua itself, as well as an HTTP library. Python's "batteries included" standard library works nicely here.
- sandGorgon 10y ago
  thank you for that. That explains a lot ! But Lua is already in Grub right ? wouldnt it have been more effective to just extend that anyway ?
  - JoshTriplett 10y ago
    Lua isn't part of upstream GRUB; it lives in a separate module, "grub-extras". As far as I can tell, it also wouldn't be easy to extend that with additional functionality or modules without forking it, due to the way GRUB builds out-of-tree modules. Note that this port of Python is almost as old as grub's Lua; we've been working on BITS since ~2009, and it has had Python support since May 2011. For reference, the Python port consists of less than 1000 lines of code, most of which provides compatibility implementations of standard C and POSIX functions that Python expects. (Plus another couple thousand lines implementing additional C Python modules like "_smp", "_acpi", and "_efi", but those are getting smaller as we move more code into Python using ctypes.)
- __b__ 10y ago
  "... the target audience writes assembly and C)." In C, I make frequent use of "switch" statements. Does CPython have a switch statment?
detaro 10y ago
Speculation: At least for the given Intel use case, lightweight doesn't sound to important: they can use the entire machine. And given the fairly specialist application, porting a language experts and users are familiar with (or maybe was used in existing tooling) might be better.
SixSigma 10y ago
Why would they not use C? Or forth, or any number of alternatives. You would get the same question with the names shuffled around whichever one you chose.
- coredog64 10y ago
  If you want forth in your BIOS, buy a Sun workstation. /snark:off
  - deleted 10y ago
    [deleted]
deleted 10y ago
[deleted]

chungy 10y ago

GRUB already has Lua, so I imagine the answer is "because we can"

sandGorgon 10y ago
interesting. I never knew that... i wonder if any additional socket library dependencies were problematic in the lua world.

Bromskloss 10y ago

What is it that makes the language suitable for being embedded? Actually, what does it mean to be embedded?

agumonkey 10y ago
Lua is extremely small, simpler, and has a jitted version. It's been used extensively as a scripting language in video games so has more mileage in constrained environment. Never used it really, just stating what other people say. And luajit author, Mike Pall, is extremely skilled.
imtringued 10y ago
You can launch a lua vm with an empty environment table (in other words no standard library). This means only the functions you manually put into the environment table can be used which makes sandboxing extremely easy. I must admit I've only used luaj where interop to java boils down to something like http://stackoverflow.com/a/19629914 http://stackoverflow.com/a/19629914 and you can optionally use reflection for even easier intertop if I recall correctly.
walkingolof 10y ago
Lua as mentioned before is very suited to run in an embedded environment because of it small size (both when executing and the actual source code size) and its modules, which makes it trivial to remove everything except the core language (IO support etc). I'm running Lua on a DLX like processor implemented on a fpga, in this context Lua performs the same role as Basic did on many home computers in the 80's, a small IPL is setting up the machine and loading Lua on boot.

JoshTriplett 10y ago

> why would they not use lua ? The target audience for this is BIOS developers and firmware engineers. Several existing development tools in that area already support Python, including Simics and the Intel ITP, so the target audience is used to it. Lua also has several other impedance mismatches with the target audience, such as 1-based array indexing (remember, the target audience writes assembly and C). While people often describe Lua as "easy to embed", personally, I don't find Lua's stack-based C API easy at all; in particular, the references to stack-based indexes that change when you push or pop the stack feels like working with stack-based parameters in assembly without a base pointer, where the offset of a given location can change at any time. I much prefer the Python C API. Finally, Lua would require additional libraries to provide a useful environment, precisely because it can assume so little about its environment. For instance, we'd need to bundle one of the Lua socket libraries in addition to Lua itself, as well as an HTTP library. Python's "batteries included" standard library works nicely here.

sandGorgon 10y ago
thank you for that. That explains a lot ! But Lua is already in Grub right ? wouldnt it have been more effective to just extend that anyway ?
- JoshTriplett 10y ago
  Lua isn't part of upstream GRUB; it lives in a separate module, "grub-extras". As far as I can tell, it also wouldn't be easy to extend that with additional functionality or modules without forking it, due to the way GRUB builds out-of-tree modules. Note that this port of Python is almost as old as grub's Lua; we've been working on BITS since ~2009, and it has had Python support since May 2011. For reference, the Python port consists of less than 1000 lines of code, most of which provides compatibility implementations of standard C and POSIX functions that Python expects. (Plus another couple thousand lines implementing additional C Python modules like "_smp", "_acpi", and "_efi", but those are getting smaller as we move more code into Python using ctypes.)
__b__ 10y ago
"... the target audience writes assembly and C)." In C, I make frequent use of "switch" statements. Does CPython have a switch statment?

detaro 10y ago

Speculation: At least for the given Intel use case, lightweight doesn't sound to important: they can use the entire machine. And given the fairly specialist application, porting a language experts and users are familiar with (or maybe was used in existing tooling) might be better.

SixSigma 10y ago

Why would they not use C? Or forth, or any number of alternatives. You would get the same question with the names shuffled around whichever one you chose.

coredog64 10y ago
If you want forth in your BIOS, buy a Sun workstation. /snark:off
- deleted 10y ago
  [deleted]

deleted 10y ago

[deleted]