GopherLua: VM and compiler for Lua in Go

GopherLua: VM and compiler for Lua in Go.

Join the chat at https://gitter.im/yuin/gopher-lua

GopherLua is a Lua5.1 VM and compiler written in Go. GopherLua has a same goal with Lua: Be a scripting language with extensible semantics . It provides Go APIs that allow you to easily embed a scripting language to your Go host programs.

Design principle

  • Be a scripting language with extensible semantics.
  • User-friendly Go API
    • The stack based API like the one used in the original Lua implementation will cause a performance improvements in GopherLua (It will reduce memory allocations and concrete type <-> interface conversions). GopherLua API is not the stack based API. GopherLua give preference to the user-friendliness over the performance.

How about performance?

GopherLua is not fast but not too slow, I think.

GopherLua has almost equivalent ( or little bit better ) performance as Python3 on micro benchmarks.

There are some benchmarks on the wiki page .

Installation

go get github.com/yuin/gopher-lua

GopherLua supports >= Go1.9.

Usage

GopherLua APIs perform in much the same way as Lua, but the stack is used only for passing arguments and receiving returned values.

GopherLua supports channel operations. See "Goroutines" section.

Import a package.

import (
    "github.com/yuin/gopher-lua"
)

Run scripts in the VM.

L := lua.NewState()
defer L.Close()
if err := L.DoString(`print("hello")`); err != nil {
    panic(err)
}
L := lua.NewState()
defer L.Close()
if err := L.DoFile("hello.lua"); err != nil {
    panic(err)
}

Refer to Lua Reference Manual and Go doc for further information.

Note that elements that are not commented in Go doc equivalent to Lua Reference Manual , except GopherLua uses objects instead of Lua stack indices.

Data model

All data in a GopherLua program is an LValue . LValue is an interface type that has following methods.

  • String() string
  • Type() LValueType

Objects implement an LValue interface are

Type name Go type Type() value Constants
LNilType (constants) LTNil LNil
LBool (constants) LTBool LTrue, LFalse
LNumber float64 LTNumber -
LString string LTString -
LFunction struct pointer LTFunction -
LUserData struct pointer LTUserData -
LState struct pointer LTThread -
LTable struct pointer LTTable -
LChannel chan LValue LTChannel -

You can test an object type in Go way(type assertion) or using a Type() value.

lv := L.Get(-1) // get the value at the top of the stack
if str, ok := lv.(lua.LString); ok {
    // lv is LString
    fmt.Println(string(str))
}
if lv.Type() != lua.LTString {
    panic("string required.")
}
lv := L.Get(-1) // get the value at the top of the stack
if tbl, ok := lv.(*lua.LTable); ok {
    // lv is LTable
    fmt.Println(L.ObjLen(tbl))
}

Note that LBool , LNumber , LString is not a pointer.

To test LNilType and LBool, You must use pre-defined constants.

lv := L.Get(-1) // get the value at the top of the stack

if lv == lua.LTrue { // correct
}

if bl, ok := lv.(lua.LBool); ok && bool(bl) { // wrong
}

In Lua, both nil and false make a condition false. LVIsFalse and LVAsBool implement this specification.

lv := L.Get(-1) // get the value at the top of the stack
if lua.LVIsFalse(lv) { // lv is nil or false
}

if lua.LVAsBool(lv) { // lv is neither nil nor false
}

Objects that based on go structs(LFunction. LUserData, LTable) have some public methods and fields. You can use these methods and fields for performance and debugging, but there are some limitations.

  • Metatable does not work.
  • No error handlings.

Callstack & Registry size

The size of an LState's callstack controls the maximum call depth for Lua functions within a script (Go function calls do not count).

The registry of an LState implements stack storage for calling functions (both Lua and Go functions) and also for temporary variables in expressions. Its storage requirements will increase with callstack usage and also with code complexity.

Both the registry and the callstack can be set to either a fixed size or to auto size.

When you have a large number of LStates instantiated in a process, it's worth taking the time to tune the registry and callstack options.

Registry

The registry can have an initial size, a maximum size and a step size configured on a per LState basis. This will allow the registry to grow as needed. It will not shrink again after growing.

 L := lua.NewState(lua.Options{
    RegistrySize: 1024 * 20,         // this is the initial size of the registry
    RegistryMaxSize: 1024 * 80,      // this is the maximum size that the registry can grow to. If set to `0` (the default) then the registry will not auto grow
    RegistryGrowStep: 32,            // this is how much to step up the registry by each time it runs out of space. The default is `32`.
 })
defer L.Close()

A registry which is too small for a given script will ultimately result in a panic. A registry which is too big will waste memory (which can be significant if many LStates are instantiated). Auto growing registries incur a small performance hit at the point they are resized but will not otherwise affect performance.

Callstack

The callstack can operate in two different modes, fixed or auto size. A fixed size callstack has the highest performance and has a fixed memory overhead. An auto sizing callstack will allocate and release callstack pages on demand which will ensure the minimum amount of memory is in use at any time. The downside is it will incur a small performance impact every time a new page of callframes is allocated. By default an LState will allocate and free callstack frames in pages of 8, so the allocation overhead is not incurred on every function call. It is very likely that the performance impact of an auto resizing callstack will be negligible for most use cases.

 L := lua.NewState(lua.Options{
     CallStackSize: 120,                 // this is the maximum callstack size of this LState
     MinimizeStackMemory: true,          // Defaults to `false` if not specified. If set, the callstack will auto grow and shrink as needed up to a max of `CallStackSize`. If not set, the callstack will be fixed at `CallStackSize`.
 })
defer L.Close()

Option defaults

The above examples show how to customize the callstack and registry size on a per LState basis. You can also adjust some defaults for when options are not specified by altering the values of lua.RegistrySize, lua.RegistryGrowStep and lua.CallStackSize.

An LState object that has been created by *LState#NewThread() inherits the callstack & registry size from the parent LState object.

Miscellaneous lua.NewState options

  • Options.SkipOpenLibs bool(default false)
    • By default, GopherLua opens all built-in libraries when new LState is created.
    • You can skip this behaviour by setting this to true .
    • Using the various OpenXXX(L *LState) int functions you can open only those libraries that you require, for an example see below.
  • Options.IncludeGoStackTrace bool(default false)
    • By default, GopherLua does not show Go stack traces when panics occur.
    • You can get Go stack traces by setting this to true .

API

Refer to Lua Reference Manual and Go doc(LState methods) for further information.

Calling Go from Lua

func Double(L *lua.LState) int {
    lv := L.ToInt(1)             /* get argument */
    L.Push(lua.LNumber(lv * 2)) /* push result */
    return 1                     /* number of results */
}

func main() {
    L := lua.NewState()
    defer L.Close()
    L.SetGlobal("double", L.NewFunction(Double)) /* Original lua_setglobal uses stack... */
}
print(double(20)) -- > "40"

Any function registered with GopherLua is a lua.LGFunction, defined in value.go

type LGFunction func(*LState) int

Working with coroutines.

co, _ := L.NewThread() /* create a new thread */
fn := L.GetGlobal("coro").(*lua.LFunction) /* get function from lua */
for {
    st, err, values := L.Resume(co, fn)
    if st == lua.ResumeError {
        fmt.Println("yield break(error)")
        fmt.Println(err.Error())
        break
    }

    for i, lv := range values {
        fmt.Printf("%v : %v\n", i, lv)
    }

    if st == lua.ResumeOK {
        fmt.Println("yield break(ok)")
        break
    }
}

Opening a subset of builtin modules

The following demonstrates how to open a subset of the built-in modules in Lua, say for example to avoid enabling modules with access to local files or system calls.

main.go

func main() {
    L := lua.NewState(lua.Options{SkipOpenLibs: true})
    defer L.Close()
    for _, pair := range []struct {
        n string
        f lua.LGFunction
    }{
        {lua.LoadLibName, lua.OpenPackage}, // Must be first
        {lua.BaseLibName, lua.OpenBase},
        {lua.TabLibName, lua.OpenTable},
    } {
        if err := L.CallByParam(lua.P{
            Fn:      L.NewFunction(pair.f),
            NRet:    0,
            Protect: true,
        }, lua.LString(pair.n)); err != nil {
            panic(err)
        }
    }
    if err := L.DoFile("main.lua"); err != nil {
        panic(err)
    }
}

Creating a module by Go

mymodule.go

package mymodule

import (
    "github.com/yuin/gopher-lua"
)

func Loader(L *lua.LState) int {
    // register functions to the table
    mod := L.SetFuncs(L.NewTable(), exports)
    // register other stuff
    L.SetField(mod, "name", lua.LString("value"))

    // returns the module
    L.Push(mod)
    return 1
}

var exports = map[string]lua.LGFunction{
    "myfunc": myfunc,
}

func myfunc(L *lua.LState) int {
    return 0
}

mymain.go

package main

import (
    "./mymodule"
    "github.com/yuin/gopher-lua"
)

func main() {
    L := lua.NewState()
    defer L.Close()
    L.PreloadModule("mymodule", mymodule.Loader)
    if err := L.DoFile("main.lua"); err != nil {
        panic(err)
    }
}

main.lua

local m = require("mymodule")
m.myfunc()
print(m.name)

Calling Lua from Go

L := lua.NewState()
defer L.Close()
if err := L.DoFile("double.lua"); err != nil {
    panic(err)
}
if err := L.CallByParam(lua.P{
    Fn: L.GetGlobal("double"),
    NRet: 1,
    Protect: true,
    }, lua.LNumber(10)); err != nil {
    panic(err)
}
ret := L.Get(-1) // returned value
L.Pop(1)  // remove received value

If Protect is false, GopherLua will panic instead of returning an error value.

User-Defined types

You can extend GopherLua with new types written in Go. LUserData is provided for this purpose.

type Person struct {
    Name string
}

const luaPersonTypeName = "person"

// Registers my person type to given L.
func registerPersonType(L *lua.LState) {
    mt := L.NewTypeMetatable(luaPersonTypeName)
    L.SetGlobal("person", mt)
    // static attributes
    L.SetField(mt, "new", L.NewFunction(newPerson))
    // methods
    L.SetField(mt, "__index", L.SetFuncs(L.NewTable(), personMethods))
}

// Constructor
func newPerson(L *lua.LState) int {
    person := &Person{L.CheckString(1)}
    ud := L.NewUserData()
    ud.Value = person
    L.SetMetatable(ud, L.GetTypeMetatable(luaPersonTypeName))
    L.Push(ud)
    return 1
}

// Checks whether the first lua argument is a *LUserData with *Person and returns this *Person.
func checkPerson(L *lua.LState) *Person {
    ud := L.CheckUserData(1)
    if v, ok := ud.Value.(*Person); ok {
        return v
    }
    L.ArgError(1, "person expected")
    return nil
}

var personMethods = map[string]lua.LGFunction{
    "name": personGetSetName,
}

// Getter and setter for the Person#Name
func personGetSetName(L *lua.LState) int {
    p := checkPerson(L)
    if L.GetTop() == 2 {
        p.Name = L.CheckString(2)
        return 0
    }
    L.Push(lua.LString(p.Name))
    return 1
}

func main() {
    L := lua.NewState()
    defer L.Close()
    registerPersonType(L)
    if err := L.DoString(`
        p = person.new("Steeve")
        print(p:name()) -- "Steeve"
        p:name("Alice")
        print(p:name()) -- "Alice"
    `); err != nil {
        panic(err)
    }
}

Terminating a running LState

GopherLua supports the Go Concurrency Patterns: Context .

L := lua.NewState()
defer L.Close()
ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
defer cancel()
// set the context to our LState
L.SetContext(ctx)
err := L.DoString(`
  local clock = os.clock
  function sleep(n)  -- seconds
    local t0 = clock()
    while clock() - t0 <= n do end
  end
  sleep(3)
`)
// err.Error() contains "context deadline exceeded"

With coroutines

L := lua.NewState()
defer L.Close()
ctx, cancel := context.WithCancel(context.Background())
L.SetContext(ctx)
defer cancel()
L.DoString(`
    function coro()
          local i = 0
          while true do
            coroutine.yield(i)
                i = i+1
          end
          return i
    end
`)
co, cocancel := L.NewThread()
defer cocancel()
fn := L.GetGlobal("coro").(*LFunction)

_, err, values := L.Resume(co, fn) // err is nil

cancel() // cancel the parent context

_, err, values = L.Resume(co, fn) // err is NOT nil : child context was canceled

Note that using a context causes performance degradation.

time ./glua-with-context.exe fib.lua
9227465
0.01s user 0.11s system 1% cpu 7.505 total

time ./glua-without-context.exe fib.lua
9227465
0.01s user 0.01s system 0% cpu 5.306 total

Sharing Lua byte code between LStates

Calling DoFile will load a Lua script, compile it to byte code and run the byte code in a LState.

If you have multiple LStates which are all required to run the same script, you can share the byte code between them, which will save on memory. Sharing byte code is safe as it is read only and cannot be altered by lua scripts.

// CompileLua reads the passed lua file from disk and compiles it.
func CompileLua(filePath string) (*lua.FunctionProto, error) {
    file, err := os.Open(filePath)
    defer file.Close()
    if err != nil {
        return nil, err
    }
    reader := bufio.NewReader(file)
    chunk, err := parse.Parse(reader, filePath)
    if err != nil {
        return nil, err
    }
    proto, err := lua.Compile(chunk, filePath)
    if err != nil {
        return nil, err
    }
    return proto, nil
}

// DoCompiledFile takes a FunctionProto, as returned by CompileLua, and runs it in the LState. It is equivalent
// to calling DoFile on the LState with the original source file.
func DoCompiledFile(L *lua.LState, proto *lua.FunctionProto) error {
    lfunc := L.NewFunctionFromProto(proto)
    L.Push(lfunc)
    return L.PCall(0, lua.MultRet, nil)
}

// Example shows how to share the compiled byte code from a lua script between multiple VMs.
func Example() {
    codeToShare := CompileLua("mylua.lua")
    a := lua.NewState()
    b := lua.NewState()
    c := lua.NewState()
    DoCompiledFile(a, codeToShare)
    DoCompiledFile(b, codeToShare)
    DoCompiledFile(c, codeToShare)
}

Goroutines

The LState is not goroutine-safe. It is recommended to use one LState per goroutine and communicate between goroutines by using channels.

Channels are represented by channel objects in GopherLua. And a channel table provides functions for performing channel operations.

Some objects can not be sent over channels due to having non-goroutine-safe objects inside itself.

  • a thread(state)
  • a function
  • an userdata
  • a table with a metatable

You must not send these objects from Go APIs to channels.

func receiver(ch, quit chan lua.LValue) {
    L := lua.NewState()
    defer L.Close()
    L.SetGlobal("ch", lua.LChannel(ch))
    L.SetGlobal("quit", lua.LChannel(quit))
    if err := L.DoString(`
    local exit = false
    while not exit do
      channel.select(
        {"|<-", ch, function(ok, v)
          if not ok then
            print("channel closed")
            exit = true
          else
            print("received:", v)
          end
        end},
        {"|<-", quit, function(ok, v)
            print("quit")
            exit = true
        end}
      )
    end
  `); err != nil {
        panic(err)
    }
}

func sender(ch, quit chan lua.LValue) {
    L := lua.NewState()
    defer L.Close()
    L.SetGlobal("ch", lua.LChannel(ch))
    L.SetGlobal("quit", lua.LChannel(quit))
    if err := L.DoString(`
    ch:send("1")
    ch:send("2")
  `); err != nil {
        panic(err)
    }
    ch <- lua.LString("3")
    quit <- lua.LTrue
}

func main() {
    ch := make(chan lua.LValue)
    quit := make(chan lua.LValue)
    go receiver(ch, quit)
    go sender(ch, quit)
    time.Sleep(3 * time.Second)
}
Go API

ToChannel, CheckChannel, OptChannel are available.

Refer to Go doc(LState methods) for further information.

Lua API
  • channel.make([buf:int]) -> ch:channel
    • Create new channel that has a buffer size of buf. By default, buf is 0.
  • channel.select(case:table [, case:table, case:table ...]) -> {index:int, recv:any, ok}
    • Same as the select statement in Go. It returns the index of the chosen case and, if that case was a receive operation, the value received and a boolean indicating whether the channel has been closed.
    • case is a table that outlined below.
      • receiving: {"|<-", ch:channel [, handler:func(ok, data:any)]}
      • sending: {"<-|", ch:channel, data:any [, handler:func(data:any)]}
      • default: {"default" [, handler:func()]}

channel.select examples:

local idx, recv, ok = channel.select(
  {"|<-", ch1},
  {"|<-", ch2}
)
if not ok then
    print("closed")
elseif idx == 1 then -- received from ch1
    print(recv)
elseif idx == 2 then -- received from ch2
    print(recv)
end
channel.select(
  {"|<-", ch1, function(ok, data)
    print(ok, data)
  end},
  {"<-|", ch2, "value", function(data)
    print(data)
  end},
  {"default", function()
    print("default action")
  end}
)
  • channel:send(data:any)
    • Send data over the channel.
  • channel:receive() -> ok:bool, data:any
    • Receive some data over the channel.
  • channel:close()
    • Close the channel.
The LState pool pattern

To create per-thread LState instances, You can use the sync.Pool like mechanism.

type lStatePool struct {
    m     sync.Mutex
    saved []*lua.LState
}

func (pl *lStatePool) Get() *lua.LState {
    pl.m.Lock()
    defer pl.m.Unlock()
    n := len(pl.saved)
    if n == 0 {
        return pl.New()
    }
    x := pl.saved[n-1]
    pl.saved = pl.saved[0 : n-1]
    return x
}

func (pl *lStatePool) New() *lua.LState {
    L := lua.NewState()
    // setting the L up here.
    // load scripts, set global variables, share channels, etc...
    return L
}

func (pl *lStatePool) Put(L *lua.LState) {
    pl.m.Lock()
    defer pl.m.Unlock()
    pl.saved = append(pl.saved, L)
}

func (pl *lStatePool) Shutdown() {
    for _, L := range pl.saved {
        L.Close()
    }
}

// Global LState pool
var luaPool = &lStatePool{
    saved: make([]*lua.LState, 0, 4),
}

Now, you can get per-thread LState objects from the luaPool .

func MyWorker() {
   L := luaPool.Get()
   defer luaPool.Put(L)
   /* your code here */
}

func main() {
    defer luaPool.Shutdown()
    go MyWorker()
    go MyWorker()
    /* etc... */
}

Differences between Lua and GopherLua

Goroutines

  • GopherLua supports channel operations.
    • GopherLua has a type named channel.
    • The channel table provides functions for performing channel operations.

Unsupported functions

  • string.dump
  • os.setlocale
  • lua_Debug.namewhat
  • package.loadlib
  • debug hooks

Miscellaneous notes

  • collectgarbage does not take any arguments and runs the garbage collector for the entire Go program.
  • file:setvbuf does not support a line buffering.
  • Daylight saving time is not supported.
  • GopherLua has a function to set an environment variable : os.setenv(name, value)

Standalone interpreter

Lua has an interpreter called lua . GopherLua has an interpreter called glua .

go get github.com/yuin/gopher-lua/cmd/glua

glua has same options as lua .

How to Contribute

See Guidlines for contributors .

Libraries for GopherLua

  • gopher-luar : Simplifies data passing to and from gopher-lua
  • gluamapper : Mapping a Lua table to a Go struct
  • gluare : Regular expressions for gopher-lua
  • gluahttp : HTTP request module for gopher-lua
  • gopher-json : A simple JSON encoder/decoder for gopher-lua
  • gluayaml : Yaml parser for gopher-lua
  • glua-lfs : Partially implements the luafilesystem module for gopher-lua
  • gluaurl : A url parser/builder module for gopher-lua
  • gluahttpscrape : A simple HTML scraper module for gopher-lua
  • gluaxmlpath : An xmlpath module for gopher-lua
  • gmoonscript : Moonscript Compiler for the Gopher Lua VM
  • loguago : Zerolog wrapper for Gopher-Lua
  • gluacrypto : A native Go implementation of crypto library for the GopherLua VM.
  • gluasql : A native Go implementation of SQL client for the GopherLua VM.
  • purr : A http mock testing tool.
  • vadv/gopher-lua-libs : Some usefull libraries for GopherLua VM.
  • gluaperiphery : A periphery library for the GopherLua VM (GPIO, SPI, I2C, MMIO, and Serial peripheral I/O for Linux).
  • glua-async : An async/await implement for gopher-lua.
  • gopherlua-debugger : A debugger for gopher-lua

Donation

BTC: 1NEDSyUmo4SMTDP83JJQSWi1MvQUGGNMZB

License

MIT

Author

Yusuke Inuzuka

Owner
Yusuke Inuzuka
Software developer from Japan. Explicit is better than implicit.
Yusuke Inuzuka
Comments
  • Allow installing some but not all of the standard modules.

    Allow installing some but not all of the standard modules.

    Currently you can have all, or no standard modules. This produces problems when, for example, you need everything but os and io to be available.

    The fix for this is trivial, just export the openXYZ functions so that users can install modules piecemeal if they wish.

  • Support Teal

    Support Teal

    • [ ] GopherLua is a Lua5.1 implementation. You should be familiar with Lua programming language. Have you read Lua 5.1 reference manual carefully?
    • [x] GopherLua is a Lua5.1 implementation. In Lua, to keep it simple, it is more important to remove functionalities rather than to add functionalities unlike other languages . If you are going to introduce some new cool functionalities into the GopherLua code base and the functionalities can be implemented by existing APIs, It should be implemented as a library.

    Please answer the following before submitting your issue:

    1. What version of GopherLua are you using? : I am using glua that I just retrieved via go get and it says GopherLua 0.1 Copyright (C) 2015 -2017 Yusuke Inuzuka when it starts up.
    2. What version of Go are you using? : go1.15.7
    3. What operating system and processor architecture are you using? : darwin/amd64
    4. What did you do? : Tried to enable Teal support by downloading tl.lua and running local tl = require("tl") and tl.loader()
    5. What did you expect to see? : No output, I think?
    6. What did you see instead? : An error, as below.
    GopherLua 0.1 Copyright (C) 2015 -2017 Yusuke Inuzuka
    > local tl = require("tl")
    > tl.loader()
    <string>:1: attempt to index a non-table object(nil) with key 'loader'
    stack traceback:
    	<string>:1: in main chunk
    	[G]: ?
    

    I admit that I'm not super familiar with Lua, more with Go, but I'm interested to use Teal in this VM so I'm curious if this is a simple fix or entirely out of the question.

  • Passing LTable to CallByParam

    Passing LTable to CallByParam

    • [x] GopherLua is a Lua5.1 implementation. You should be familiar with Lua programming language. Have you read Lua 5.1 reference manual carefully?
    • [x] GopherLua is a Lua5.1 implementation. In Lua, to keep it simple, it is more important to remove functionalities rather than to add functionalities unlike other languages . If you are going to introduce some new cool functionalities into the GopherLua code base and the functionalities can be implemented by existing APIs, It should be implemented as a library.

    Please answer the following before submitting your issue:

    1. What version of GopherLua are you using? : https://github.com/yuin/gopher-lua/commit/1cd887cd7036
    2. What version of Go are you using? : go version go1.13.3
    3. What operating system and processor architecture are you using? : linux/amd64
    4. What did you do? : Exactly like this issue : https://github.com/yuin/gopher-lua/issues/178
    lTable.RawSetString("varTest", "test")
    L.CallByParam(lua.P{
    	[...],
    }, &lTable)
    

    When I print my lTable in Go, I get something like that : {<nil> [] map[] map[varTest:test] [varTest] map[varTest:0]}

    And in my test function in LUA :

    
    function Test(tableTest)
    	print("tableTest:", tableTest)
    end
    

    (I tried .Metatable() too, in case)

    1. What did you expect to see? : The keys and values in my lTable
    2. What did you see instead? : I get a nil
  • how do you think of supporting closure serialization of lua?

    how do you think of supporting closure serialization of lua?

    Closure serialization, which means code and it's context partly evaluated. In my business, If a closure can be serialized, it can be passed to remote service to apply with the input provided by the remote service.

    a closure(args1...N) -----> remote service( apply(closure,input) )

    This feature is quite useful in distributed system, for example:

    1. Data broker
    2. Remote data warehouse analyze

    Without this, I can only implement Context(some arguments provided) + Code Snippet String (not evaluated) to remote service and Apply(Context, Args, Code)

    How do you think of this?

    PS: https://github.com/jeremeamia/super_closure

  • Accessing comments through AST

    Accessing comments through AST

    I would like to annotate Lua code through comments, much like Go to generate documentation. However, I don't see the comments when I call parse.Dump.

    How should I access the comments through the AST?

    -- relase <var> [optionalVar]
    function target.relase(var, optionalVar)
    
    end
    
  • Question: LState pooling

    Question: LState pooling

    Thanks for the great project!

    Please answer the following before submitting your issue:

    1. What version of GopherLua are you using? : v0.0.0-20200603152657-dc2b0ca8b37e
    2. What version of Go are you using? : go version go1.16.5
    3. What operating system and processor architecture are you using? : linux/amd64

    I have a question to validate, if my assumption and tests are correct and are fine to use.

    To summarize I am maintainer of https://github.com/zalando/skipper proxy and we have a lua() filter that uses this project to implement it. A filter is an instance that is part of a route. It's not shared between routes. A user just needs to define code like this to execute lua code in request and response path:

    function request(ctx, params) 
        print(c.request.url); 
    end
    function response(ctx, params) 
        print(c.response.status_code); 
    end
    

    Right now we use for every filter instance a separate lua statepool, but if you think about having 40000 routes and maybe 4000 routes with lua() filters we would have a huge amount of wasted memory or we would have to create LStates all the time.

    Right now I am testing it more in depth and tried to share the LState pool. Basically I create at startup 10000 LState and put these into a buffered channel of size 10000. The function to create the LState:

     func newState() (*lua.LState, error) {
        L := lua.NewState()
        L.PreloadModule("base64", base64.Loader)
        L.PreloadModule("http", gluahttp.NewHttpModule(&http.Client{}).Loader)
        L.PreloadModule("url", gluaurl.Loader)
        L.PreloadModule("json", gjson.Loader)
        L.SetGlobal("print", L.NewFunction(printToLog))
        L.SetGlobal("sleep", L.NewFunction(sleep))
        return L, nil
       }
    

    When the filter is called, we get a LState from the pool and pass it and the compiled lua code from the filter to execute:

    func createScript(L *lua.LState, proto *lua.FunctionProto) (*lua.LState, error) {
        L.Push(L.NewFunctionFromProto(proto))
        err := L.PCall(0, lua.MultRet, nil)
        if err != nil {
            L.Close()
            return nil, err
        }
        return L, nil
    }
    

    As far as I see it's not a documented behavior that we can reuse LState and overwrite the Request and Response functions with L.Push(), but it seems to work (tested locally with vegeta and some 10000s of requests).

    Is it a safe assumption that overwriting a Function is fine? Maybe there is a better or safer way to do this. Do we leak resources that we need to cleanup?

    Thanks, sandor

  • Bug: Incorrect result for multi-assignment

    Bug: Incorrect result for multi-assignment

    • [ ] GopherLua is a Lua5.1 implementation. You should be familiar with Lua programming language. Have you read Lua 5.1 reference manual carefully?
    • [x] GopherLua is a Lua5.1 implementation. In Lua, to keep it simple, it is more important to remove functionalities rather than to add functionalities unlike other languages . If you are going to introduce some new cool functionalities into the GopherLua code base and the functionalities can be implemented by existing APIs, It should be implemented as a library.

    Please answer the following before submitting your issue:

    1. What version of GopherLua are you using? : GopherLua 0.1 Copyright (C) 2015 -2017 Yusuke Inuzuka
    2. What version of Go are you using? : go version go1.15.7
    3. What operating system and processor architecture are you using? : darwin/amd64
    4. What did you do? : Execute glua ./repro.lua where the file contains:
    local a = {}
    local d = 'e'
    local f = 1
    
    f, a.d = f, d
    
    print(f..", "..a.d)
    
    1. What did you expect to see? : The result of 1, e
    2. What did you see instead? : The result of d, e

    Somehow the property-access in the multi-assignment causes f to contain the name of the second variable on the right side instead of the value of the 1st variable on the right side.

    As a note, swapping the sequence results in the correct behavior: a.d, f = d, f

    Reference: #314

  • Auto growing stack and registry

    Auto growing stack and registry

    Fixes #197 .

    Changes proposed in this pull request:

    • Memory savings:
      • Can optionally set the LState's callstack to grow / shrink automatically (up to a max size)
      • Can optionally set the LState's registry to grow automatically (up to a max size)

    It's been a long time since I opened #197 , sorry for the delay. Please feel free to feedback on this PR or ask for changes.

    There are two parts to this PR - first the registry can be set to auto grow as needed. Originally, the registry was implemented as a fixed size slice. This PR simply allows this slice to be reallocated if it runs out of space. A maximum upper size to be set in the Options struct, as well as a grow step size. By default the RegistryMaxSize will be 0, which disables the auto grow behaviour and makes the code behaviour exactly the same as previously. As there is no penalty in this case, other than an inlined if statement, I have not abstracted the registry growth functionality via an interface.

    The second part of this PR is the more complicated, it allows the callstack to be automatically resized as needed. This has been implemented now via an interface with the LState being configured on construction to either use the previous fixed size callstack, or the new auto growing callstack from this PR. The Options struct dictates which one should be used.

    Abstracting the callstack into an interface is good in that it allows us to switch between implementations depending on the requirements : the auto growing one will use minimal memory, but has a slight performance penalty, whereas the fixed one will always use "worst case" memory, but will have predicable and fast performance.

    Abstracting the callstack to be behind an interface has meant disabling the inlining which was in place for manipulating the stack from within the LState. I have added benchmarks which just do stack manipulation and I did not think the performance hit was so bad, but it might be worth benchmaking the new code (in both the fixed and auto growing configurations) against some actual lua benchmarking scripts, to see how it fares in actual usage.

  • Allow for optional disabling of library opening and stdin/stdout control

    Allow for optional disabling of library opening and stdin/stdout control

    These two changes are to make https://github.com/jtolds/go-manhole work.

    I'd be okay if we just merged the second change (the optional skipping of library opening), as it makes the first change (control of stdout/stdin/stderr) unnecessary for my purposes.

    Thanks!

  • inspect.lua doesn't work

    inspect.lua doesn't work

    Hi, I've just played with inspect.lua (https://github.com/kikito/inspect.lua) but it seems it doesn't work correctly.

    for example)

    macbook% ../bin/glua bug.lua
    
    inspect.lua:300: attempt to index a non-table object(nil)
    stack traceback:
    inspect.lua:300: in inspect.lua:297
    (tailcall): ?
    bug.lua:2: in main chunk
    [G]: ?
    macbook% lua bug.lua
    "hello"
    

    https://gist.github.com/chobie/bcff5c74c915422a3075

    also, I've tested above script with lua 5.1.5 and lua 5.2.3 and it works fine. can you check this if you have a chance?

    Thanks,

  • Add defer to gopher Lua

    Add defer to gopher Lua

    • [ yes] GopherLua is a Lua5.1 implementation. You should be familiar with Lua programming language. Have you read Lua 5.1 reference manual carefully?
    • [ yes] GopherLua is a Lua5.1 implementation. In Lua, to keep it simple, it is more important to remove functionalities rather than to add functionalities unlike other languages . If you are going to introduce some new cool functionalities into the GopherLua code base and the functionalities can be implemented by existing APIs, It should be implemented as a library.

    Please answer the following before submitting your issue:

    1. What version of GopherLua are you using? : 5.1
    2. What version of Go are you using? : 1.15
    3. What operating system and processor architecture are you using? :windows/x64
    4. What did you do? :add lua defer
    5. What did you expect to see? : defer in lua
    6. What did you see instead? : no

    function foo() defer print 'defer 1' end

    do
        defer print 'defer 2' end
    end
    
    defer print 'defer 3' end
    
    print 'end'
    

    end

    https://github.com/peete-q/lua-defer

  • feat: add the ability to load a Lua filesystem instead of from OS

    feat: add the ability to load a Lua filesystem instead of from OS

    Changes proposed in this pull request:

    This feature extends the Options to load a Lua filesystem instead of loading directly from the OS. This extension uses an interface to allow for user level overrides by requiring Open and Stat functions utilized by LState.

  • Issue #417: support nil params on os.date()

    Issue #417: support nil params on os.date()

    Fixes #417 .

    Changes proposed in this pull request:

    • nil params passed to os.date are interpreted as the default values

    couldn't use L.OptString because unlike L.CheckString, it does not convert numbers to strings and lua allows os.date(2) = "2"

  • os.date(nil) gives an error instead of acting like os.date()

    os.date(nil) gives an error instead of acting like os.date()

    • [X] GopherLua is a Lua5.1 implementation. You should be familiar with Lua programming language. Have you read Lua 5.1 reference manual carefully?
    • [X] GopherLua is a Lua5.1 implementation. In Lua, to keep it simple, it is more important to remove functionalities rather than to add functionalities unlike other languages . If you are going to introduce some new cool functionalities into the GopherLua code base and the functionalities can be implemented by existing APIs, It should be implemented as a library.

    Please answer the following before submitting your issue:

    1. What version of GopherLua are you using? : latest from git master
    2. What version of Go are you using? : 1.19.3
    3. What operating system and processor architecture are you using? : Debian stable on amd64
    4. What did you do? : I ran print(os.date(nil))
    5. What did you expect to see? : the same thing as if I had run print(os.date())
    6. What did you see instead? : <string>:1: bad argument #1 to date (string expected, got nil)

    Very minor issue but I thought I'd get it tracked here just for the record.

  • GetTop() is incorrect after SkipOpenLibs

    GetTop() is incorrect after SkipOpenLibs

    L := lua.NewState(lua.Options{SkipOpenLibs: true, CallStackSize: 256, RegistrySize: 256 * 20})
    lua.OpenBase(L)
    lua.OpenString(L)
    lua.OpenTable(L)
    lua.OpenMath(L)
    defer L.Close()
    ctx, cancel := context.WithTimeout(context.Background(), time.Duration(timeout)*time.Second)
    defer cancel()
    L.SetContext(ctx)
    if err := L.DoString(`
    function a(c,v)
    	--io.open()
    	--print(_G)
    	return c+v
    end
    local ccc ={}
    ccc["1123"] = 123456
    print(ccc)
    `); err != nil {
    	return "", err
    }
    value := L.GetTop()
    fmt.Println("GetTop", value)
    
  • Bug with `debug.getlocal` (mismatch compared to official Lua 5.1)

    Bug with `debug.getlocal` (mismatch compared to official Lua 5.1)

    You must post issues only here. Questions, ideas must be posted in discussions.

    Please answer the following before submitting your issue:

    1. What version of GopherLua are you using? : latest version (commit 6581935)
    2. What version of Go are you using? : Go 1.19
    3. What operating system and processor architecture are you using? : linux/amd64
    4. What did you do? :

    I ran this program:

    if true then
        local not_visible = "true"
    else
        local not_visible = "false"
    end
    
    function get_locals(func)
        local n = 1
        local locals = {}
        while true do
            local lname, lvalue = debug.getlocal(2, n)
            if lname == nil then break end
            locals[lname] = lvalue
            n = n + 1
        end
        return locals
    end
    
    local should_exist = "foo"
    
    local vars = get_locals(1)
    
    print("should not exist:", vars["not_visible"])
    print("should exist:", vars["should_exist"])
    
    1. What did you expect to see? :

    The get_locals function should return a table that does not have not_visible as a key, and does have should_exist as a key. I would expect it to print:

    should not exist:	nil
    should exist:	foo
    

    That is what the official Lua5.1 interpreter prints when it runs this file.

    1. What did you see instead? :

    Instead I see

    should not exist:	function: 0xc0000fb080
    should exist:	nil
    

    For some reason not_visible exists and is a function, and should_exist is nil.

    For this case, glua does not produce the same output as lua5.1, which is a bug.

  • Add ForEachWithError to LTable

    Add ForEachWithError to LTable

    Provide a break capable, as well as error capable implementation of ForEach, allowing for early short-circuit and deep logging of error messages. Implement it underneath the current version, keeping only one code path for maintenance purposes, but allow multiple ways of calling this functionality as needed.

    Changes proposed in this pull request:

    • Adds LTable.ForEachWithError()
    • Implements LTable.ForEach() as a call to LTable.ForEachWithError()
A Lua VM in Go

A Lua VM in pure Go go-lua is a port of the Lua 5.2 VM to pure Go. It is compatible with binary files dumped by luac, from the Lua reference implement

Jan 4, 2023
Go -> Haxe -> JS Java C# C++ C Python Lua
Go -> Haxe -> JS Java C# C++ C Python Lua

go2hx Compile: Go -> Haxe -> Js, Lua, C#, C++, Java, C, Python warning: heavily experimental still a ways to go before an alpha. Come give feedback on

Dec 14, 2022
Promise to the Go compiler that your Reads and Writes are well-behaved

noescape go get lukechampine.com/noescape noescape provides Read and Write functions that do not heap-allocate their argument. Normally, when you pas

Dec 22, 2022
Go compiler for small places. Microcontrollers, WebAssembly, and command-line tools. Based on LLVM.

TinyGo - Go compiler for small places TinyGo is a Go compiler intended for use in small places such as microcontrollers, WebAssembly (Wasm), and comma

Jan 4, 2023
A compiler from Go to JavaScript for running Go code in a browser

GopherJS - A compiler from Go to JavaScript GopherJS compiles Go code (golang.org) to pure JavaScript code. Its main purpose is to give you the opport

Dec 30, 2022
Automated compiler obfuscation for nim

Denim Makes compiling nim code with obfuscator-llvm easy! Windows only for now, but do you even need compiler obfuscation on other platforms? Setup In

Dec 31, 2022
JIT compiler in Go

jit-compiler This is a Golang library containing an x86-64 assembler (see 'asm/') and a higher level intermediate representation that compiles down in

Dec 24, 2022
Compiler for a small language into x86-64 Assembly

Compiler This project is a small compiler, that compiles my own little language into X86-64 Assembly. It then uses yasm and ld to assemble and link in

Dec 13, 2022
The Project Oberon RISC compiler ported to Go.

oberon-compiler This is a port of the Project Oberon compiler for RISC-5 (not to be confused with RISC-V) from Oberon to Go. The compiled binaries can

Dec 6, 2022
The golang tool of the zig compiler automatically compiles different targets according to the GOOS GOARCH environment variable. You need to install zig.

The golang tool of the zig compiler automatically compiles different targets according to the GOOS GOARCH environment variable. You need to install zig.

Nov 18, 2022
Logexp - Logical expression compiler for golang

Logical Expression Compiler Functions: - Compile(exp string) - Match(text string

Jan 24, 2022
A compiler for the ReCT programming language written in Golang

ReCT-Go-Compiler A compiler for the ReCT programming language written in Golang

Nov 30, 2022
Grumpy is a Python to Go source code transcompiler and runtime.

Grumpy: Go running Python Overview Grumpy is a Python to Go source code transcompiler and runtime that is intended to be a near drop-in replacement fo

Jan 7, 2023
High-performance PHP application server, load-balancer and process manager written in Golang
High-performance PHP application server, load-balancer and process manager written in Golang

RoadRunner is an open-source (MIT licensed) high-performance PHP application server, load balancer, and process manager. It supports running as a serv

Dec 30, 2022
Mathematical expression parsing and calculation engine library. 数学表达式解析计算引擎库

Math-Engine 使用 Go 实现的数学表达式解析计算引擎库,它小巧,无任何依赖,具有扩展性(比如可以注册自己的函数到引擎中),比较完整的完成了数学表达式解析执行,包括词法分析、语法分析、构建AST、运行。 go get -u github.com/dengsgo/math-engine 能够

Jan 3, 2023
Runcmd - just golang binary that runs commands from url or local file and logs output

runcmd just golang binary that runs commands from url or local file and logs out

Feb 2, 2022
GopherLua: VM and compiler for Lua in Go

GopherLua: VM and compiler for Lua in Go. GopherLua is a Lua5.1 VM and compiler written in Go. GopherLua has a same goal with Lua: Be a scripting lang

Dec 31, 2022
GopherLua: VM and compiler for Lua in Go

GopherLua: VM and compiler for Lua in Go. GopherLua is a Lua5.1 VM and compiler written in Go. GopherLua has a same goal with Lua: Be a scripting lang

Jan 9, 2023
🎀 a nice lil shell for lua people made with go and lua

Hilbish ?? a nice lil shell for lua people made with go and lua It is currently in a mostly beta state but is very much usable (I'm using it right now

Jan 3, 2023
LuaHelper is a High-performance lua plugin, Language Server Protocol for lua.
LuaHelper is a High-performance lua plugin, Language Server Protocol for lua.

LuaHelper is a High-performance lua plugin, Language Server Protocol for lua.

Dec 29, 2022