6 ms·

In case you are wondering why this exists, there is a discussion here: https://github.com/Azure/golua/issues/36 https://github.com/Azure/golua/issues/36

• wahern 8y ago
  > The VM is designed differently (I'm encouraging Brian to write a blog post about this), but in a nutshell it is designed for better error handling and for adding a debugger Looking at the VM, they implement function calls by recursively re-entering the VM in Go. The VM implements neither tail calls nor coroutines, and I don't see how they could implement the latter without some serious refactoring. Perhaps by adding a debugger they mean they implemented the VM such that they could repurpose existing Go debuggers, which is why there's a 1:1 mapping between the Lua call chain and the Go runtime call chain.
  • mfer 8y ago
    This was open sourced very early. It is being built with the intent of supporting Helm v3 and by open sourcing it early it enables other Helm maintainers to get involved and to import it into Helm v3 early. I expect more docs, details, and improvements will be coming
    • wereHamster 8y ago
      You mean this helm: https://helm.sh https://helm.sh?
  • stcredzero 8y ago
    in a nutshell it is designed for better error handling and for adding a debugger Better debugging is one of the big things holding Lua back, IMHO.
    • nikki93 8y ago
      I feel like the main thing to work on here is the frontend, given the "debug." library built into Lua(JIT). ZeroBrane has a frontend, for example.
• ioddly 8y ago
  I'd think one of the big advantages of rewriting Lua in a GC'd language would be that you could ditch the stack API, which is necessary to keep track of pointers but not so intuitive to use. Seems like they didn't take that route though.
  • wahern 8y ago
    What's the alternative to a stack API? If you look at Python and Perl they use a combination of (1) an explicit stack similar to Lua, (2) instantiation of heavy-weight list or array objects for passing arguments, (3) explicit reference counting, and (4) code generation. Lua's stack protocol can sometimes be verbose, but I find it infinitely more simple and elegant than the existing alternatives. I think you tend to see long, unwieldy code blocks that invoke Lua functions multiple times because you can, despite how tricky it can be to track the top of your stack. You rarely see this in Perl or Python because it becomes impossible to manage long before that point. So the solution for Lua is the same as for other interfaces--use shorter, simpler functions and compose them. This is usually easier and more performant to do in Lua, anyhow, because there's less fixed boiler plate and indirection necessary; not to mention Lua gives you many more facilities for stashing and managing your C state across calls (like closure upvalues, userdata values, continuation context cookies, etc) without resorting to global variables either inside or outside the VM.
    • ioddly 8y ago
      Yeah, implementing a precise GC is a pain, but in Go the hard work of that is already done for you. If I were to write my own Lua-in-Go, my inclination would be to try to make an API something like this table := lua.MakeTable() table.Set(lua.MakeString("five"), lua.MakeNumber(5)) Rather than manipulating values on the stack. But it's possible there are reasons for not doing that that I'm unaware of. Was just curious.
      • wahern 8y ago
        Why do you prefer that over lua_pushstring(L, "five"); lua_pushnumber(L, 5); The above is shorter and also significantly more efficient because you're not creating the intermediate table object. Even in Go, given Lua's coroutine and tailcall semantics (assuming they were implemented) the Go compiler would likely be forced to always heap allocate the argument list table. There's a reason PUC Lua is blazingly fast, and its partly the same reason why LuaJIT is so fast--the Lua stack protocol is a thin abstraction that easily admits a simple, efficient implementation yet still managing to provide an effective interface boundary that doesn't leak (beyond the fact of the protocol itself). I don't think there's any good middle ground here. The best options are (1) Lua's explicit stack protocol or (2) some sort of type inference that permitted a direct call, like lua_tcall(L, "five", 5), into the VM. You can actually implement the latter in C somewhat easily (at least if you stick to simple data types) by using _Generic and __VA_ARG__ macros to generate the stack pushing code. But I rarely see this done because it's a lot of magic for little gain. And where I have seen it done it's always been annoying because it's too leaky--invariably you have to fallback to the stack pushing code because there's a limit to the types of automagic type coercions you can accomplish between two drastically different languages. So you have to learn their magical wrapper routines in addition to the regular Lua API. Many years ago I abused __VA_ARG__, __builtin_types_compatible_p, and libffi so I could invoke ad hoc functions as libevent callbacks without having to proxy the call through a function that unwrapped a pointer-to-void cookie. See http://25thandclement.com/~william/projects/delegate.c.html http://25thandclement.com/~william/projects/delegate.c.html I still think it's kinda clever but I can't remember the last time I actually used it. Even in code bases already using delegate.c I ended up returning to the slightly more repetitive but transparent and idiomatic patterns for installing libevent events.
• Scarbutt 8y ago
  It doesn't say why they need this for azure.
  • gabrtv 8y ago
    Helm v3. https://helm.sh/ https://helm.sh/
• mwkaufma 8y ago
  Ah, for reliability and debugging. I guess that's why they're not too perf-concerned about dispatching opcodes through function pointers: https://github.com/Azure/golua/blob/master/lua/exec.go#L92 https://github.com/Azure/golua/blob/master/lua/exec.go#L92
  • nwmcsween 8y ago
    This is going to be horribly slow compared to say computed goto
    • mwkaufma 8y ago
      Are computed gotos even available in golang? Even in C that's a compiler extension.
• robertsd247 8y ago
  ...so Microsoft's own version of something? Got it.