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

21–30 of 34 posts

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

#21

Post by emj »

_samt_ wrote: post #14
vrighter wrote: post #13

So the cases where you loadfile a file just for it to have a separate sandboxed _ENV that the function that created it, is flat out unsupported, forever?

loadfile() isn't implemented in clx, and neither are the other dynamic code-loading features. Supporting them would require runtime code interpretation, which doesn't fit clx's current AOT model. Could that change one day? Maybe, but it's not a priority right now.

I looked at your goals and Load is clearly out of scope. I think the question here is could you load your AOT compiled and executable code like we do with Lua scripts only give the compiled code access to a safe Lua env. i.e. Not giving it access to all symbols.

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

#22

Post by _samt_ »

MomsAVoxell wrote: post #20
_samt_ wrote: post #18

Earlier quoted context omitted.

Thanks! That's an interesting idea, but I'd probably lean towards a third-party clx module rather than adding Objective-C runtime support directly to clx. Since clx already exposes a C++ API and is able to link clx modules, projects like metal-cpp are a natural fit and don't require any changes to the runtime, or any FFI tricks. That keeps the core runtime small while still allowing platform-specific integrations.

Ah, that makes sense .. so I could write a clx-oriented app which chooses to load the clx-objcsend module (based on its assessment of which platform its running on of course) .. which I could then use to formulate a native GUI on MacOS/iOS. I have a few GUI libraries I've written in Lua for other projects, which depend basically on having surface-manipulation and event-management functions from the native platform av…

That sounds like a very interesting use case!

This is exactly the kind of scenario where I think third-party clx modules make sense: keep the core runtime portable and let platform-specific bindings live outside of it.

A clx-objc (or metal-cpp or any gui backend) module would be an interesting experiment, and the same approach could apply to other platforms (Win32, GTK, etc.)

Clx is still a relatively young project, so please be a bit indulgent with bugs or missing features, but I'd definitely be interested in seeing/helping what you build!

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

#24

Post by MomsAVoxell »

_samt_ wrote: post #22
MomsAVoxell wrote: post #20

Earlier quoted context omitted.

Ah, that makes sense .. so I could write a clx-oriented app which chooses to load the clx-objcsend module (based on its assessment of which platform its running on of course) .. which I could then use to formulate a native GUI on MacOS/iOS. I have a few GUI libraries I've written in Lua for other projects, which depend basically on having surface-manipulation and event-management functions from the native platform av…

That sounds like a very interesting use case! This is exactly the kind of scenario where I think third-party clx modules make sense: keep the core runtime portable and let platform-specific bindings live outside of it. A clx-objc (or metal-cpp or any gui backend) module would be an interesting experiment, and the same approach could apply to other platforms (Win32, GTK, etc.) Clx is still a relatively young project,…

I'll join you in Github once I've got a chance to catch up with clx so far .. with the work you've already done, I think the basics are there to support multi-platform GUI modules .. but I'll know more about the effort once I catch up with you. Great work!

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

#25

Post by _samt_ »

emj wrote: post #21
_samt_ wrote: post #14

Earlier quoted context omitted.

loadfile() isn't implemented in clx, and neither are the other dynamic code-loading features. Supporting them would require runtime code interpretation, which doesn't fit clx's current AOT model. Could that change one day? Maybe, but it's not a priority right now.

I looked at your goals and Load is clearly out of scope. I think the question here is could you load your AOT compiled and executable code like we do with Lua scripts only give the compiled code access to a safe Lua env. i.e. Not giving it access to all symbols.

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 change a function's `_ENV` after compilation (unlike the old `setfenv/getfenv` mechanism from Lua 5.1).

I've been considering adding environment manipulation capabilities to the CLX C++ API (while keeping Lua compatibility intact). If that happens, loading CLX modules into custom environments could become relatively straightforward.

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

#26

Post by _samt_ »

newswasboring wrote: post #23
skimmed_milk wrote: post #17

This is cool, it could be a neat way to get Love2d games on the web with wasm

I'm currently learning to make games with love2d. I'm using love.js to deploy for web. Would this have some advantage over love.js?

Probably not today.

Love.js is already a mature solution for running Love2D games in the browser through WebAssembly. Clx currently focuses on ahead-of-time compilation to native executables rather than web deployment.

The idea I was referring to is more about native distribution: compiling Lua code into standalone executables without requiring a Lua runtime on the target machine.

That said, if Clx eventually gains a WebAssembly backend, it could become an interesting alternative path for Lua-to-web deployment.

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

#27

Post by _samt_ »

MomsAVoxell wrote: post #24
_samt_ wrote: post #22

Earlier quoted context omitted.

That sounds like a very interesting use case! This is exactly the kind of scenario where I think third-party clx modules make sense: keep the core runtime portable and let platform-specific bindings live outside of it. A clx-objc (or metal-cpp or any gui backend) module would be an interesting experiment, and the same approach could apply to other platforms (Win32, GTK, etc.) Clx is still a relatively young project,…

I'll join you in Github once I've got a chance to catch up with clx so far .. with the work you've already done, I think the basics are there to support multi-platform GUI modules .. but I'll know more about the effort once I catch up with you. Great work!

Thank you!

I'd be very interested in your feedback once you've had a chance to explore the codebase. Multi-platform GUI support is definitely something I'd like to see emerge through Clx binary modules and the C++ API.

Feel free to reach out on GitHub when you're ready — additional platform expertise would be greatly appreciated.

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

#29

Post by [deleted] »

_samt_ wrote: post #25
emj wrote: post #21

Earlier quoted context omitted.

I looked at your goals and Load is clearly out of scope. I think the question here is could you load your AOT compiled and executable code like we do with Lua scripts only give the compiled code access to a safe Lua env. i.e. Not giving it access to all symbols.

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…

[deleted]

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

#30

Post by vrighter »

_samt_ wrote: post #25
emj wrote: post #21

Earlier quoted context omitted.

I looked at your goals and Load is clearly out of scope. I think the question here is could you load your AOT compiled and executable code like we do with Lua scripts only give the compiled code access to a safe Lua env. i.e. Not giving it access to all symbols.

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
Post reply on HN