Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lua 5.4.0 beta

lua-users.org

Post reply on HN
Print view View original

81–90 of 103 posts

Re: Lua 5.4.0 beta

#81

Post by sdegutis »

yanex wrote: post #75
sdegutis wrote: post #72

Earlier quoted context omitted.

QuickJS is a Lua-like JS interpreter if you’re ok with JS.

Well, I'm not a big fan of JavaScript :) I like the direction ECMAScript is going. However, the clumsy things are going to stay because of backward compatibility. Also, QuickJS is a good initiative, but I afraid it's not production-ready yet. It doesn't even have versioning and/or changelog.

The top of https://bellard.org/quickjs/ is the changelog and each release is versioned by date.

Nobody's a fan of the quirks of JS, but you can almost entirely ignore them and only use the good parts.

Re: Lua 5.4.0 beta

#82

Post by pb82 »

MereInterest wrote: post #56
mikepurvis wrote: post #37

Earlier quoted context omitted.

My info might be a bit out of date, but something that surprised me when I looked into it was how little control I had over the embedded lua interpreter from my outer app. I basically had to hand it control by calling lua_pcall, and either wait for a result or manage a timeout from another thread. I expected to be able to do things like tell Lua to run for X milliseconds or Y opcodes or whatever, but it didn't seem t…

Running for X opcodes isn't too difficult, but isn't immediately straightforward either. Instead of calling a function with lua_pcall, start a coroutine using lua_resume. Then, you can have a callback using lua_sethook and the LUA_MASKCOUNT option, which triggers the callback after a fixed number of opcodes. Inside the hook, you make a call to lua_yield. That forces the coroutine that was running to yield control to…

Thats clever. I used the same approach with lua_sethook to run a hook every X opcodes and check if time or memory constraints have been exceeded. But instead of yielding I used longjmp to terminate execution (basically like raising an exception and catching it a few levels up in the stack).

It's not bulletproof though and the script can still block e.g. when calling into native code.

Re: Lua 5.4.0 beta

#83

Post by MereInterest »

pb82 wrote: post #82
MereInterest wrote: post #56

Earlier quoted context omitted.

Running for X opcodes isn't too difficult, but isn't immediately straightforward either. Instead of calling a function with lua_pcall, start a coroutine using lua_resume. Then, you can have a callback using lua_sethook and the LUA_MASKCOUNT option, which triggers the callback after a fixed number of opcodes. Inside the hook, you make a call to lua_yield. That forces the coroutine that was running to yield control to…

Thats clever. I used the same approach with lua_sethook to run a hook every X opcodes and check if time or memory constraints have been exceeded. But instead of yielding I used longjmp to terminate execution (basically like raising an exception and catching it a few levels up in the stack). It's not bulletproof though and the script can still block e.g. when calling into native code.

Yeah, native code can block, and in those cases requires additional checks in that exposed native code. That runs into all the usual multithreading headaches, and depends on exactly which functions have been exposed to the lua interpreter.

The advantage to this method over longjmp is that the function call is still valid and can be resumed at any point.

Re: Lua 5.4.0 beta

#84

Post by yanex »

sdegutis wrote: post #81
yanex wrote: post #75

Earlier quoted context omitted.

Well, I'm not a big fan of JavaScript :) I like the direction ECMAScript is going. However, the clumsy things are going to stay because of backward compatibility. Also, QuickJS is a good initiative, but I afraid it's not production-ready yet. It doesn't even have versioning and/or changelog.

The top of https://bellard.org/quickjs/ is the changelog and each release is versioned by date. Nobody's a fan of the quirks of JS, but you can almost entirely ignore them and only use the good parts.

Well, I won't call "New release" / "New release" a changelog. It's simply not a log of changes.

Re: Lua 5.4.0 beta

#85

Post by DonHopkins »

xorcist wrote: post #44
ecmascript wrote: post #14

People that use lua, what do you use it for and why did you pick lua?

It's really big in the gaming industry. For certain engines it's the de facto standard.

Like Factorio!

(If you haven't heard of that, then I implore you, for the love of God, don't look it up and try it out and get addicted, whatever you do! And if you do, then don't blame me for getting you hooked. Oh dammit, now I made myself want to play it again!)

Re: Lua 5.4.0 beta

#86

Post by jdance »

bbmario wrote: post #30

Wish they could improve the language syntax. It's so unnecessarily verbose. Moonscript did a good job improving Lua.

I love lua syntax, its the only language I feel I actually dont have to look up syntax when I return to it a year later. Its just stupid simple, and that has a big value for me. Maybe Java < 8 also .. also pretty simple but very verbose :)

Re: Lua 5.4.0 beta

#87

Post by dottrap »

nomadluap wrote: post #12

I'm looking through the new reference manual and there doesn't seem to be any mention of const variables, or any mention of how the new to-be-closed variables work. Do you just define the __close metamethod and lua takes care of the rest?

I haven't tried them yet, but in the work reference manual, look at: 3.3.7 – Local Declarations and 3.3.8 – To-be-closed Variables

I think the syntax use is: local x = 5 local filename = "/etc/fstab" local fh = io.open(filename, "r")

Re: Lua 5.4.0 beta

#88

Post by dottrap »

hugomg wrote: post #59
johnisgood wrote: post #40

Earlier quoted context omitted.

Indeed. Mike Pall blows them out of the water single-handedly. I wonder if Lua developers have learnt anything from him with respect to performance. I would like to see how Lua 5.4.0 would perform in comparison.

It is no surprise that the benchmarks on the LuaJIT website are going to show it ahead of PUC-Lua, is it? In truth the performance comparison is a bit more complicated than that. :) For a pure Lua comparison LuaJIT is typically going to beat Lua by a large margin. For code that can be JIT compiled you might see ~10x performance improvements and for code that doesn't you might still see around a ~2x improvement becaus…

> I wonder if Lua developers have learnt anything from him with respect to performance.

It cannot be emphasized enough that PUC-Lua and LuaJIT have different goals. One goal for PUC-Lua is that it must be portable everywhere and be implementable in pure ANSI C (no platform or architecture specific calls). LuaJIT in contrast contains much handwritten assembly for the specific architectures it supports.

PUC-Lua also cares deeply about interoperating with C and hence why the Lua-C interface is formally part of the language spec, and as the parent thread mentioned, LuaJIT using the traditional Lua-C interface can be really slow.

That said, PUC-Lua has learned a lot from Mike Pall. It was Pall that helped them get fully yieldable coroutines across pcall boundaries. I'm sure Pall's lengthy analysis of unimpressive garbage collection performance in both Lua 5.1 and LuaJIT was read by all of them and a motivation for them to try the generational garbage collector now finally working in 5.4.

But finally, there is a new project called Pallene (not being pedantic, formerly known as Titan). It is inspired by all the lessons of LuaJIT. The name 'Pallene' is a nod to Mike Pall. Pallene is a statically typed sister language to Lua that is designed for performance and easy C/Lua bridging, but in a way that doesn't bring in all the downsides of JIT. The language is glued at the hip to Lua so there is also easy interoperability between Pallene and Lua code. Pallene introduces static types not for the sake of type safety, but for the purpose of inferring what things can be optimized. Pallene brings in a AOT compiler into the mix and generates optimized binaries. But these binaries also look like any other Lua/C native library so they are callable from normal Lua too and the user doesn't know if they were implemented in C or Pallene.

Pallene was previously discussed on HN here:

https://news.ycombinator.com/item?id=18038619

Also look for the original Titan talk from one of the Lua Workshops a few years ago.

Re: Lua 5.4.0 beta

#89

Post by i_feel_great »

yanex wrote: post #24
i_feel_great wrote: post #19

Earlier quoted context omitted.

What would you use coroutine.close () for?

I suppose, just to close to-be-closed variables declared inside a sleeping coroutine.

Why not let the function in the coroutine exit normally?

Maybe I should go read the docs. Killing a coroutine from the outside looks like poor design/bad idea.

Re: Lua 5.4.0 beta

#90

Post by sitkack »

unbendable wrote: post #22

We use lua 5.3 on an embedded Platform for scripting and it has been a roller coaster ride. Not a fun one, unfortunately. You want luasocket? The stable one is not compatible with 5.3. Packages are sometimes outdated (for years no updates) and there is no replacement. The lua point releases have breaking changes. The source code itself is a macro hell which is hard to debug. And the code is not very readable. The doc…

Lua point releases, 5.1, 5.2, etc. are major releases. The numbering scheme isn't semver. It is only accidentally that Lua even has an ecosystem. It is meant entirely for embedding within a larger application and not used as a stand alone application server.
Post reply on HN