4 ms·

TL;DR - A Lua 5.3 VM written in Javascript. I like Lua very much, and in my mind, if the stars had been aligned just a little differently, it would now occupy

by krylon 9y ago

TL;DR - A Lua 5.3 VM written in Javascript. I like Lua very much, and in my mind, if the stars had been aligned just a little differently, it would now occupy the space inhabited by Javascript. I cannot help but wonder, tough: A Lua VM implemented in Javascript? Is the performance hit not enough to make this useless for anything beyond proof-of-concept-sites/apps? A Lua to Javascript compiler would have made sense. Given all the languages you can compile to Javascript these days, it would have made sense. And in terms of semantics, both languages are close enough that I think it would not be that big a problem. Still, it is an impressive piece of work. Implementing a bytecode VM a) in Javascript, b) running in the browser must make debugging rather ... interesting.

agumonkey 9y ago
I planned to extend dillo with lua. I so far I have patch with the includes and the lua interpreter init.. annnnd that's it. I know nothing about interfacing interpreter with the browser components (dom, etc) so I stopped.
- cypher543 9y ago
  Dillo specifically avoids scripting, so I doubt the internals are well-suited to that sort of integration. You could try extending NetSurf[1], though. It uses Duktape[2] as its Javascript engine and its API is pretty similar to Lua's. 1: http://www.netsurf-browser.org/ http://www.netsurf-browser.org/ 2: http://duktape.org/ http://duktape.org/
  - agumonkey 9y ago
    Thanks, I should look how others did it. It's true that dillo never cared about scripting, I felt like plugin lua in would force a rewrite of every part..
- squarefoot 9y ago
  You may find the Luakit browser interesting. https://luakit.github.io/ https://luakit.github.io/
  - agumonkey 9y ago
    Thanks, I looked at it, I wanted a crude web browser, not a modern html5/css3/js(6). The point was to make an extremely light, yet programmatic access to web data and almost static html. When I use dillo I don't miss much, maybe a few css fix here and there. What I feel is that I want some emacs-ish capabilities in it so I can do more with less. And I love the ridiculous resource consumption of dillo, 30 dillo tabs = half a chromium one; and without parsing js and fetching scripts .. network + rendering is hard to measure.
flohofwoe 9y ago
You can just take the original Lua interpreter source code and compile that to asm.js or WebAssembly without changes. Loading dependencies from the web requires an asynchronous reimplementation of the "require" command though, but it's all quite trivial. The result is about 100 to 150 KByte compressed. The only downside (beside the added size) is that the Lua code is still running interpreted, not JITed. That's why I think that a combination of WebAssembly for performance critical code, and Typescript (compiled to Javascript) for the 'scripting part' makes more sense than WebAssembly+Lua, since this doesn't have those downside (no additional size overhead for the interpreter, and the JS will be JITed).
- sitkack 9y ago
  I have tested Lua compiled to asmjs and it is very very fast. A LuaJIT that targeted WASM would be phenomenal, but not strictly needed. Or maybe something like Terra [0] but targeted WASM. Either one would meet all of my perf needs. Lua really is the MLIR (mid-level intermediate representation) from the future. [0] http://terralang.org/ http://terralang.org/
  - __s 9y ago
    I've been working on a hand written Lua interpreter in WASM (using Lua as a macro assembler, ofc). Long term I'd like to have it jit wasm code: https://github.com/serprex/luwa https://github.com/serprex/luwa Currently in the process of porting the parser & codegen that's implemented in Javascript to Lua so that I can have the implementation bootstrap itself. Plus the codegen was for a bytecode I came up with in JS but which has evolved quite a bit since getting everything in place to happen in WASM
    - sitkack 9y ago
      This is super cool. It looks like you are in the process of porting the .js to .lua? Wasm will exist in many more places than Js will. I think I would have started with many of the Lua on Js implementations and used zero Js. Have you seen http://stefan-marr.de/2015/10/jit-data-structures-fully-reflective-vms-and-meta-circular-meta-tracing/ http://stefan-marr.de/2015/10/jit-data-structures-fully-refl... Check out this paper, https://www.cs.purdue.edu/homes/rompf/papers/amin-draft2017a.pdf https://www.cs.purdue.edu/homes/rompf/papers/amin-draft2017a... Collapsing Towers of Interpreters

by krylon 9y ago

agumonkey 9y ago

I planned to extend dillo with lua. I so far I have patch with the includes and the lua interpreter init.. annnnd that's it. I know nothing about interfacing interpreter with the browser components (dom, etc) so I stopped.

cypher543 9y ago
Dillo specifically avoids scripting, so I doubt the internals are well-suited to that sort of integration. You could try extending NetSurf[1], though. It uses Duktape[2] as its Javascript engine and its API is pretty similar to Lua's. 1: http://www.netsurf-browser.org/ http://www.netsurf-browser.org/ 2: http://duktape.org/ http://duktape.org/
- agumonkey 9y ago
  Thanks, I should look how others did it. It's true that dillo never cared about scripting, I felt like plugin lua in would force a rewrite of every part..
squarefoot 9y ago
You may find the Luakit browser interesting. https://luakit.github.io/ https://luakit.github.io/
- agumonkey 9y ago
  Thanks, I looked at it, I wanted a crude web browser, not a modern html5/css3/js(6). The point was to make an extremely light, yet programmatic access to web data and almost static html. When I use dillo I don't miss much, maybe a few css fix here and there. What I feel is that I want some emacs-ish capabilities in it so I can do more with less. And I love the ridiculous resource consumption of dillo, 30 dillo tabs = half a chromium one; and without parsing js and fetching scripts .. network + rendering is hard to measure.

flohofwoe 9y ago

You can just take the original Lua interpreter source code and compile that to asm.js or WebAssembly without changes. Loading dependencies from the web requires an asynchronous reimplementation of the "require" command though, but it's all quite trivial. The result is about 100 to 150 KByte compressed. The only downside (beside the added size) is that the Lua code is still running interpreted, not JITed. That's why I think that a combination of WebAssembly for performance critical code, and Typescript (compiled to Javascript) for the 'scripting part' makes more sense than WebAssembly+Lua, since this doesn't have those downside (no additional size overhead for the interpreter, and the JS will be JITed).

sitkack 9y ago
I have tested Lua compiled to asmjs and it is very very fast. A LuaJIT that targeted WASM would be phenomenal, but not strictly needed. Or maybe something like Terra [0] but targeted WASM. Either one would meet all of my perf needs. Lua really is the MLIR (mid-level intermediate representation) from the future. [0] http://terralang.org/ http://terralang.org/
- __s 9y ago
  I've been working on a hand written Lua interpreter in WASM (using Lua as a macro assembler, ofc). Long term I'd like to have it jit wasm code: https://github.com/serprex/luwa https://github.com/serprex/luwa Currently in the process of porting the parser & codegen that's implemented in Javascript to Lua so that I can have the implementation bootstrap itself. Plus the codegen was for a bytecode I came up with in JS but which has evolved quite a bit since getting everything in place to happen in WASM
  - sitkack 9y ago
    This is super cool. It looks like you are in the process of porting the .js to .lua? Wasm will exist in many more places than Js will. I think I would have started with many of the Lua on Js implementations and used zero Js. Have you seen http://stefan-marr.de/2015/10/jit-data-structures-fully-reflective-vms-and-meta-circular-meta-tracing/ http://stefan-marr.de/2015/10/jit-data-structures-fully-refl... Check out this paper, https://www.cs.purdue.edu/homes/rompf/papers/amin-draft2017a.pdf https://www.cs.purdue.edu/homes/rompf/papers/amin-draft2017a... Collapsing Towers of Interpreters