lua-l archive

[Date Index] [Thread Index]

• August 01, 2020
  • Re: To-be-closed variables and coroutines, Viacheslav Usov
• August 03, 2020
  • Lua 5.4.0 patch 2 causes C stackoverflow, Vinicius Jarina
  • [ANN] Update to sig_catch power patch, Reuben Thomas
  • Usage of -Os in 5.4 causing issues, Daniel Kolesa
  • Re: Usage of -Os in 5.4 causing issues, Roberto Ierusalimschy
  • Re: Usage of -Os in 5.4 causing issues, Daniel Kolesa
  • Re: Usage of -Os in 5.4 causing issues, Ką Mykolas
  • Re: Usage of -Os in 5.4 causing issues, Roberto Ierusalimschy
  • Re: Usage of -Os in 5.4 causing issues, Ką Mykolas
• August 04, 2020
  • Re: Lua 5.4.0 manual, rexonf
• August 05, 2020
  • [ANN] Penlight 1.8.0 released, Thijs Schreijer
• August 07, 2020
  • Re: [ANN] Penlight 1.8.0 released, Russell Haley
  • Re: Dogfood released; an alternative for creating 'self running' Lua programs, Marc Balmer
  • [ANN] lrexlib 2.9.1 released, rrt
  • Re: Dogfood released; an alternative for creating 'self running' Lua programs, Mike Schmitz
  • Re: Dogfood released; an alternative for creating 'self running' Lua programs, Luiz Henrique de Figueiredo
  • Re: Dogfood released; an alternative for creating 'self running' Lua programs, Jasper Klein
• August 08, 2020
  • Re: Dogfood released; an alternative for creating 'self running' Lua programs, lyiriyah
  • SipHash for Lua 5.1.5 patch, lua
  • Re: SipHash for Lua 5.1.5 patch, Luiz Henrique de Figueiredo
  • Re: SipHash for Lua 5.1.5 patch, lua
• August 09, 2020
  • SipHash for Lua 5.4.0 patch, Sam Trenholme
  • Re: SipHash for Lua 5.4.0 patch, Sam Trenholme
• August 10, 2020
  • Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, 孙世龙 sunshilong
  • Use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function, 孙世龙 sunshilong
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Stefan
  • Re: SipHash for Lua 5.4.0 patch, Gé Weijers
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Viacheslav Usov
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Roberto Ierusalimschy
  • Re: Use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function, Roberto Ierusalimschy
  • Lua & lock manager, Thierry Fournier
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Stefan
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Roberto Ierusalimschy
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Philippe Verdy
  • Re: SipHash for Lua 5.4.0 patch, Sam Trenholme
• August 11, 2020
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Andrew Gierth
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, 孙世龙 sunshilong
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, 孙世龙 sunshilong
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, 孙世龙 sunshilong
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, 孙世龙 sunshilong
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Sean Conner
  • Re: Use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function, 孙世龙 sunshilong
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, 孙世龙 sunshilong
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Sean Conner
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Andrew Gierth
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, 孙世龙 sunshilong
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Andrew Gierth
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Gerhard Sittig
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Roberto Ierusalimschy
  • Re: Use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function, Roberto Ierusalimschy
• August 12, 2020
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, 孙世龙 sunshilong
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, 孙世龙 sunshilong
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Philippe Verdy
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, 孙世龙 sunshilong
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Philippe Verdy
  • SipHash benchmarks: I will use HalfSipHash31, Sam Trenholme
  • Re: SipHash benchmarks: I will use HalfSipHash31, Sam Trenholme
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, Andrew Gierth
  • Re: Are there some potential problems if I use a self-defined memory acquirement function instead of realloc(3) in the l_alloc function?, 孙世龙 sunshilong
  • [ANN] lualogging release 1.4.0, Thijs Schreijer
  • godawful sh/Lua polyglot, Norman Ramsey
  • Re: godawful sh/Lua polyglot, Egor Skriptunoff
  • Re: godawful sh/Lua polyglot, Sam Trenholme
  • Re: godawful sh/Lua polyglot, Marc Balmer
  • Re: godawful sh/Lua polyglot, Philippe Verdy
• August 13, 2020
  • Re: godawful sh/Lua polyglot, Egor Skriptunoff
  • Re: godawful sh/Lua polyglot, Sam Trenholme
  • Re: godawful sh/Lua polyglot, Egor Skriptunoff
  • What problems may occur if the restriction(i.e. l_alloc should not fail when shrinking the block) is broken?, 孙世龙 sunshilong
  • Re: godawful sh/Lua polyglot, Jonathan Goble
  • Since the input argument named osize has not been used in the l_alloc() function, why still pass LUA_TTHREAD to this function in lua_newstate()?, 孙世龙 sunshilong
  • Re: Since the input argument named osize has not been used in the l_alloc() function, why still pass LUA_TTHREAD to this function in lua_newstate()?, 云风 Cloud Wu
  • Re: Since the input argument named osize has not been used in the l_alloc() function, why still pass LUA_TTHREAD to this function in lua_newstate()?, 孙世龙 sunshilong
  • Re: Since the input argument named osize has not been used in the l_alloc() function, why still pass LUA_TTHREAD to this function in lua_newstate()?, v
  • Re: tracking LUA_TTHREAD in allocators, Viacheslav Usov
  • Re: What problems may occur if the restriction(i.e. l_alloc should not fail when shrinking the block) is broken?, Roberto Ierusalimschy
• August 15, 2020
  • Parallelizing a busted test suite, Hugo Musso Gualandi
  • loadStringN can write to freed memory, will fail assert in tests, Payo Nel
• August 16, 2020
  • Serializable VM, Egor Skriptunoff
  • Re: Serializable VM, Luiz Henrique de Figueiredo
  • Re: Serializable VM, Egor Skriptunoff
  • Re: Serializable VM, Soni "They/Them" L.
  • Re: Serializable VM, Jonathan Goble
  • Re: Serializable VM, Luiz Henrique de Figueiredo
• August 17, 2020
  • Re: Serializable VM, Egor Skriptunoff
  • Re: Serializable VM, Soni "They/Them" L.
  • Re: Serializable VM, Sean Conner
  • Re: Serializable VM, Egor Skriptunoff
  • Re: Serializable VM, 云风 Cloud Wu
  • Re: Serializable VM, Soni "They/Them" L.
  • Re: Serializable VM, Egor Skriptunoff
  • Re: loadStringN can write to freed memory, will fail assert in tests, Roberto Ierusalimschy
  • Re: loadStringN can write to freed memory, will fail assert in tests, Roberto Ierusalimschy
  • Re: Serializable VM, Stephen E. Baker
• August 18, 2020
  • Re: loadStringN can write to freed memory, will fail assert in tests, Petite Abeille
  • No way to get uservalue count from API; intended?, Sergey Zakharchenko
  • Re: No way to get uservalue count from API; intended?, Roberto Ierusalimschy
  • C stack overflow in Lua 5.4 in ackermann benchmark, Eduardo Bart
  • Re: No way to get uservalue count from API; intended?, Sergey Zakharchenko
  • Re: No way to get uservalue count from API; intended?, Jonathan Goble
  • Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Eduardo Bart
  • Re: No way to get uservalue count from API; intended?, Sergey Zakharchenko
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Eduardo Bart
  • Programming In Lua, Russell Haley
  • Re: Programming In Lua, Alper Pekdemir
  • Re: Programming In Lua, Luiz Henrique de Figueiredo
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Luiz Henrique de Figueiredo
  • Re: Programming In Lua, Tim McCracken
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Eduardo Bart
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Eduardo Bart
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Eduardo Bart
  • Re: Programming In Lua, Roberto Ierusalimschy
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Roberto Ierusalimschy
  • Re: C stack overflow in Lua 5.4 in ackermann benchmark, Roberto Ierusalimschy
  • Re: Programming In Lua, Jonathan Goble
  • Re: C stack overflow in Lua 5.4 in ackermann benchmark, Andrew Gierth
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Andrew Gierth
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Philippe Verdy
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Andrew Gierth
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Philippe Verdy
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Philippe Verdy
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Philippe Verdy
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Ranier Vilela
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Philippe Verdy
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Philippe Verdy
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Philippe Verdy
• August 19, 2020
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Sam Trenholme
  • Metatable check helper API proposal, Sergey Zakharchenko
  • Re: Crash in tostringbuff when -D_FORTIFY_SOURCE=2 is not defined in Lua 5.4, Philippe Verdy
  • Re: Metatable check helper API proposal, Roberto Ierusalimschy
  • Re: Metatable check helper API proposal, Andrew Gierth
  • Re: Metatable check helper API proposal, Luiz Henrique de Figueiredo
  • Re: Metatable check helper API proposal, Sergey Zakharchenko
  • Re: Metatable check helper API proposal, Gé Weijers
  • Re: Metatable check helper API proposal, Sergey Zakharchenko
  • Lua 5.4 local attribute syntax whitespace sensitivity, Sergey Zakharchenko
  • Re: Lua 5.4 local attribute syntax whitespace sensitivity, Soni "They/Them" L.
  • Re: Lua 5.4 local attribute syntax whitespace sensitivity, Sergey Zakharchenko
  • Re: Metatable check helper API proposal, 云风 Cloud Wu
  • Re: Lua 5.4 local attribute syntax whitespace sensitivity, Coda Highland
  • Re: Lua 5.4 local attribute syntax whitespace sensitivity, Philippe Verdy
  • Re: Metatable check helper API proposal, Dibyendu Majumdar
  • Re: Lua 5.4 local attribute syntax whitespace sensitivity, Roberto Ierusalimschy
  • Re: Lua 5.4 local attribute syntax whitespace sensitivity, Gavin Wraith
  • Re: Lua 5.4 local attribute syntax whitespace sensitivity, Petite Abeille
  • Lua application programming (Big message), Joao Von
  • [bug?] No readline support in Lua 5.4 REPL, Martin
• August 20, 2020
  • Re: [bug?] No readline support in Lua 5.4 REPL, Luiz Henrique de Figueiredo
  • Re: [bug?] No readline support in Lua 5.4 REPL, Luiz Henrique de Figueiredo
  • Re: [bug?] No readline support in Lua 5.4 REPL, Martin
  • Re: Metatable check helper API proposal, 云风 Cloud Wu
  • Re: Metatable check helper API proposal, 云风 Cloud Wu
  • RE: Lua application programming (Big message), Tom Becker
  • Squeezing more performance from the Lua interpreter, Eduardo Bart
  • Re: Squeezing more performance from the Lua interpreter, Gisle Vanem
  • Re: Squeezing more performance from the Lua interpreter, v
  • Re: Squeezing more performance from the Lua interpreter, Eduardo Bart
  • Re: Squeezing more performance from the Lua interpreter, Frank Kastenholz
  • Re: Squeezing more performance from the Lua interpreter, Eduardo Bart
  • Re: Lua application programming (Big message), Joao Von
  • [ANN] Luacheck 0.24.0, Hisham
  • [ANN] luacov/cluacov support for Lua 5.4, Hisham
  • Re: [ANN] luacov/cluacov support for Lua 5.4, Eduardo Bart
• August 21, 2020
  • Re: Squeezing more performance from the Lua interpreter, Dibyendu Majumdar
  • Re: Squeezing more performance from the Lua interpreter, Dibyendu Majumdar
  • Re: Squeezing more performance from the Lua interpreter, Eduardo Bart
  • Re: Squeezing more performance from the Lua interpreter, Dibyendu Majumdar
  • Re: Squeezing more performance from the Lua interpreter, Eduardo Bart
• August 22, 2020
  • Re: Parallelizing a busted test suite, Thijs Schreijer
• August 23, 2020
  • Strange way to determine whether it is Lua or C function, Egor Skriptunoff
  • Re: Strange way to determine whether it is Lua or C function, v
  • Re: Strange way to determine whether it is Lua or C function, Paul K
  • Re: Strange way to determine whether it is Lua or C function, Viacheslav Usov
  • Re: Strange way to determine whether it is Lua or C function, Egor Skriptunoff
  • Re: documentation bug: call hook [WAS: Strange way to determine whether it is Lua or C function], Viacheslav Usov
  • documentation (?) bug: call hook yields [WAS: Re: Strange way to determine whether it is Lua or C function], Viacheslav Usov
  • Re: Strange way to determine whether it is Lua or C function, Egor Skriptunoff
  • Re: documentation (?) bug: call hook yields [WAS: Re: Strange way to determine whether it is Lua or C function], Egor Skriptunoff
  • Re: Strange way to determine whether it is Lua or C function, Paul K
• August 24, 2020
  • Re: documentation (?) bug: call hook yields [WAS: Re: Strange way to determine whether it is Lua or C function], Viacheslav Usov
  • Re: Strange way to determine whether it is Lua or C function, Viacheslav Usov
  • Question about luaH_newkey, 重归混沌
  • Re: Parallelizing a busted test suite, Hugo Musso Gualandi
  • Re: Strange way to determine whether it is Lua or C function, Egor Skriptunoff
  • Re: Question about luaH_newkey, Roberto Ierusalimschy
  • Re: Strange way to determine whether it is Lua or C function, Viacheslav Usov
  • Re: Parallelizing a busted test suite, Javier Guerra Giraldez
  • Re: Strange way to determine whether it is Lua or C function, Egor Skriptunoff
  • luaclose_mylib function (inverse of "luaopen_mylib" C function), bel
  • Re: luaclose_mylib function (inverse of "luaopen_mylib" C function), Roberto Ierusalimschy
  • Re: luaclose_mylib function (inverse of "luaopen_mylib" C function), bel
  • Re: luaclose_mylib function (inverse of "luaopen_mylib" C function), Viacheslav Usov
  • Re: luaclose_mylib function (inverse of "luaopen_mylib" C function), bel
  • Job: Lua programmer for satellite/IoT project, Bogdan Marinescu
• August 25, 2020
  • Re: Question about luaH_newkey, 重归混沌
  • Re: luaclose_mylib function (inverse of "luaopen_mylib" C function), Andrew Gierth
  • Do strings move around?, Francisco Olarte
  • Re: Do strings move around?, Javier Guerra Giraldez
  • Re: Do strings move around?, Francisco Olarte
  • Re: Do strings move around?, v
  • Re: Do strings move around?, Roberto Ierusalimschy
  • Re: Do strings move around?, Francisco Olarte
  • Dogfood v1.0.2 has been released; an alternative for building self contained Lua executables, Jasper Klein
  • Re: Do strings move around?, Roberto Ierusalimschy
  • Re: Dogfood v1.0.2 has been released; an alternative for building self contained Lua executables, Luiz Henrique de Figueiredo
  • Re: luaclose_mylib function (inverse of "luaopen_mylib" C function), bel
  • Re: luaclose_mylib function (inverse of "luaopen_mylib" C function), Andrew Gierth
  • Re: Do strings move around?, Andrew Gierth
  • Re: Question about luaH_newkey, 重归混沌
• August 26, 2020
  • Re: Question about luaH_newkey, 重归混沌
  • Re: Do strings move around?, Francisco Olarte
  • Re: Do strings move around?, Roberto Ierusalimschy
  • Re: Do strings move around?, Gé Weijers
  • Re: Do strings move around?, Roberto Ierusalimschy
  • Re: Do strings move around?, Viacheslav Usov
  • Re: Dogfood v1.0.2 has been released; an alternative for building self contained Lua executables, Jasper Klein
• August 27, 2020
  • Re: Do strings move around?, Andrew Gierth
  • Re: Do strings move around?, Roberto Ierusalimschy
  • Re: Dogfood v1.0.2 has been released; an alternative for building self contained Lua executables, Jasper Klein
• August 28, 2020
  • Re: luaclose_mylib function (inverse of "luaopen_mylib" C function), Philippe Verdy
• August 29, 2020
  • Minor correctness issue with l_str2d's use of ltolower, Ahmed Charles
• August 31, 2020
  • Memory corruption in in luaV_execute (lua/Test_lua/lua/lvm.c:1784), secwx weizhenvul
  • Re: Memory corruption in in luaV_execute (lua/Test_lua/lua/lvm.c:1784), Viacheslav Usov
  • Re: Memory corruption in in luaV_execute (lua/Test_lua/lua/lvm.c:1784), Luiz Henrique de Figueiredo
  • Re: Memory corruption in in luaV_execute (lua/Test_lua/lua/lvm.c:1784), Viacheslav Usov
  • Re: Memory corruption in in luaV_execute (lua/Test_lua/lua/lvm.c:1784), Andrew Gierth
  • Re: Memory corruption in in luaV_execute (lua/Test_lua/lua/lvm.c:1784), Philippe Verdy
  • Re: Squeezing more performance from the Lua interpreter, Sven Olsen

---

Mail converted by MHonArc 2.6.19