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

Show HN: Clx – Compile Lua to Native Executables Through C++20

github.com

Post reply on HN
Print view View original

31–34 of 34 posts

Re: Show HN: Clx – Compile Lua to Native Executables Through C++20

#31

Post by _samt_ »

vrighter wrote: post #30
_samt_ wrote: post #25

Earlier quoted context omitted.

That's an interesting idea. Loading precompiled CLX modules is a different problem though. In theory, a native module could be loaded and executed with a restricted environment, similar to how Lua modules receive a specific `_ENV`. It's not something CLX supports today, but it's much closer to the project's goals than runtime compilation of Lua source code. One challenge is that standard Lua does not provide a way to…

so a kind of setfenv type thing, but only from c++. That could work

Yes that's it

Re: Show HN: Clx – Compile Lua to Native Executables Through C++20

#32

Post by jxndbdbd »

_samt_ wrote: post #15
jxndbdbd wrote: post #11

Interesting project! I have not looked to closely at the source so forgive me for asking - Are you doing a source to source or byte code to source transformation? - How are you beating lua performance, since the naive implementation of a dynamic language would require tons of tables with pointer chasing

Thanks! - clx compiles directly from Lua source code. It has its own parser and C++20 code generator; it does not use Lua bytecode - The goal isn't necessarily to beat Lua, but some workloads benefit from the optimizations performed by modern C++ compilers. As for tables, clx doesn't use a naive boxed-object model. Tables have a split array/hash layout: integer keys are stored in a contiguous array, while other keys…

Thanks for the explanation!

Re: Show HN: Clx – Compile Lua to Native Executables Through C++20

#34

Post by _samt_ »

1vuio0pswjnm7 wrote: post #33

FYI https://github.com/samyeyo/clx/releases/download/v0.2.0/clx-... Extracts to current directory instead of clx-linux-x86_64

Good catch, thanks.

The release archive currently extracts directly into the working directory. I'll package future releases into a dedicated top-level directory to avoid cluttering the extraction location.

Post reply on HN