github.com/milochristiansen/lua
v1.1.8
#1828 most downloaded on Go modules
milochristiansen/lua
What this package is like to depend on
Last release 1 months ago
17 Jul 2026
Ships unpredictably
gaps range from 2 weeks to 4.3 years
Most releases are documented
notes for 7 of 8 stable releases
Nothing withdrawn
no release was ever pulled
10 years old
13 releases · first in 2016
1 release in the last 12 months
see the full history below
Release timeline
13 releases · Nov 2016 to Jul 2026Releases
latest 13-
v1.1.9-0.20260717113630-b7f361b4258717 Jul 2026 pre-releaseNothing published for this version
-
v1.1.9-0.20220323145355-f20e777b03ba23 Mar 2022 pre-releaseNothing published for this version
-
v1.1.9-0.20210823151953-71460727895723 Aug 2021 pre-releaseNothing published for this version
-
v1.1.805 May 2021Nothing published for this version
-
v1.1.8-0.20191111140137-079298d6bda111 Nov 2019 pre-releaseNothing published for this version
-
v1.1.717 Mar 2019Release notes
Open source →- Function calls or parenthesized expressions that are followed by table indexers are now properly compiled (Fixed #13).
- The compiler sometimes did not always mark "used" the proper number of registers when compiling identifiers (Fixed #16).
- Fixed the table iterator not finalizing (Fixed #17).
- Removed my hacky slice library and just did things properly (Fixed #18).
- Fix
pcallnot returningtrueon success (Fixed #19). - Fixed setting a nil index in a table not raising an error (Fixed #20).
-
v1.1.7-0.20181210220906-ea1e20417de610 Dec 2018 pre-releaseNothing published for this version
-
v1.1.626 Apr 2018Release notes
Open source →Fun with tables! Ok, not so much fun.
- Fixed scripts with lots of constants overflowing RK fields in certain instructions. The proper constant load instructions are emitted in this case now.
- Tables with lots of empty space at the beginning of the array portion will no longer cause crashes when the array portion is resized.
-
v1.1.513 Nov 2017Release notes
Open source →And, another stupid little bug.
- Constructs similar to the following
[=[]==]]=]were not working properly. The lexer was not properly constructing the lexeme, and it would return the wrong number of equals signs and it would eat the last square bracket. As a bonus I greatly simplified the string lexing code. (ast/lexer.go)
- Constructs similar to the following
-
v1.1.420 Sep 2017Release notes
Open source →Not sure how I missed this one... Oh well, it should work now.
requirewas not checkingpackage.loadedproperly. (lmodpackage/functions.go)
-
v1.1.124 Jan 2017Release notes
Open source →1.1.1
More script tests, more compiler bugs fixed. Same song, different verse.
- Added another set of script tests. (script_test.go)
- Fixed unary operators after a power operator, for example
2 ^ - -2. To fix this issue I totally rewrote how operators
are parsed. (ast/parse_expr.go) - Fixed semicolons immediately after a return statement. (ast/parse.go)
- Fixed an improper optimization or repeat-until loops. Basically if the loop had a constant for the loop condition its
sense was being reversed (so a false condition resulted in the loop being compiled as a simple block, and a true condition
resulted in an infinite loop). (compile.go) - Fixed
andin non-boolean contexts. Alsoandandormay produce slightly better code now. (compile_expr.go)
-
v1.1.013 Jan 2017Release notes
Open source →1.1.0
I was a little bored recently, so I threw together a generic metatable API. It was a quick little project, based on
earlier work for one of my many toy languages. This new API is kinda cool, but it in no way replaces proper metatables!
Basically it is intended for quick projects and temporarily exposing data to scripts. It was fun to write, and so even
if no one uses it, it has served its purpose :PI really should have been working on more script tests, but this was more fun... Anyway, I have no doubt responsibility
will reassert itself soon...Anyway, I also added two new convenience methods for table iteration, as well as some minor changes to the old one (you
can still use it, but it is now a thin wrapper over one of the new functions, so you shouldn't).- Ran all code through
go fmt. I often forget to do this, but I recently switched to a new editor that formats files
automatically whenever they are saved. Anyway, everything is formatted now. (almost every file in minor ways) - Added
ProtectandRecover, simple error handlers for native code. They are to be used when calling native APIs
outside of code otherwise protected (such as by a call to PCall).Recoveris the old handler fromPCall, wrapped
so it can be used by itself.Protectsimply wrapsRecoverso it is easier to use. (api.go) - Added
ForEachRaw, basicallyForEachInTable, but the passed in function returns a boolean specifying if you want to
break out of the loop early. In other newsForEachInTableis now depreciated. (api.go) - Added
ForEach, a version ofForEachRawthat respects the__pairsmetamethod.ForEachRawuses the table iterator
directly and does much less stack manipulation, so it is probably a little faster. (api.go) - Added a new sub-package:
supermetaadds "generic" metatables for just about any Go type. For obvious reasons this
makes heavy use of reflection, so it is generally much faster to write your own metatables, that said this is really
nice for quickly exposing native data to scripts. From the user's perspective you just callsupermeta.New(l, &object)
andobjectis suddenly a script value on the top ofl's stack. Arrays, slices, maps, structs, etc should all work
just fine. Note that this is very new, and as of yet has received little real-world testing! (supermeta/supermeta.go,
supermeta/tables.go) - Added a new sub-package:
testhelpcontains a few test helper functions I find useful when writing tests that interact
with the VM. Better to have all this stuff in one place rather than copied and pasted all over... (testhelp/testhelp.go) - Modified the script tests in the base package to use the helper functions in
testhelprather than their own copies.
The API tests still have their own copies of some of the functions, as they need to be in the base package so they can
access internal APIs (stupid circular imports). (script_test.go) - Clarified what API functions may panic, I think I got them all... (api.go)
- Ran all code through
-
v1.0.222 Nov 2016Release notes
Open source →More tests, more (compiler) bugs fixed. Damn compiler will be the death of me yet...
In addition to the inevitable compiler bugs I also fixed the way the VM handles upvalues. Before I was giving each
closure its own copy of each upvalue, so multiple closures never properly shared values. This change fixes several
subtle (and several not so subtle) bugs.Oh, and
pcallworks now (it didn't work at all before. Sorry, I never used it).- Added more script tests. I still have a lot more to do... (script_test.go)
- Fixed incorrect compilation of method declarations (
function a:x() end). Depressingly the issue was only one
incorrect word, but it resulted in very wrong results (I am really starting to remember why I hated writing the
compiler, the VM was fun, the compiler... not.) (ast/parse.go) - Parenthesized expression that would normally (without the parenthesis) return multiple values (for example:
(...))
were not properly truncating the result to a single value. (compile_expr.go) - Fixed a semi-major VM issue with upvalues. Closures that should have a single shared upvalue were instead each using
their own private copy after said upvalue was closed. This required an almost total rewrite of the way upvalues are
stored internally. (all over the place, but mainly callframe.go, function.go, api.go, and vm.go) - JMP instructions created by
breakandcontinuestatements are now properly patched by the compiler to close any
upvalues there may be. (compile.go) - Fixed the
pcallscript function so it actually works. (lmodbase/functions.go) - On a recovered error each stack frame's upvalues are closed before the stack is stripped. This corrects incorrect
behavior that arises when a function stores a closure to an unclosed upvalue then errors out (the closure may still be
referenced, but it's upvalues may be invalid). (api.go, callframe.go)