11–20 of 34 posts
- 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
Earlier quoted context omitted.
Yes, Clx generates C++20. The main motivation wasn't a particular C++20 feature, but using GCC, Clang and MSVC as a portable optimization and code generation backend instead of LLVM or custom machine code generation. As for coroutines, no. Clx doesn't use C++20 coroutines because Lua coroutines are stackful, so the runtime uses platform-specific context switching instead.
My understanding of the original question is: what motivated you targeting C++20 instead of e.g. C++17
In practice, the code generator doesn't rely heavily on C++20-only features, so targeting C++17 would likely be possible with some adjustments.
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?
Could that change one day? Maybe, but it's not a priority right now.
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
- 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 use an open-addressed hash table. That keeps common accesses cache-friendly and avoids a lot of pointer chasing.
I have not dug into it deeply enough yet - saving a deep dive for the weekend - but meantime .. what are your thoughts about having objc_msgSend included in the runtime so that native MacOS (and eventually iOS) GUI's can be made using this technique:
https://medium.com/@michael.mogenson/write-a-macos-app-with-...
As a Lua fanboy, I have to say this is really, really great! I have not dug into it deeply enough yet - saving a deep dive for the weekend - but meantime .. what are your thoughts about having objc_msgSend included in the runtime so that native MacOS (and eventually iOS) GUI's can be made using this technique: https://medium.com/@michael.mogenson/write-a-macos-app-with-...
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.
This is cool, it could be a neat way to get Love2d games on the web with wasm
Since clx generates portable C++, targeting WebAssembly through Emscripten is theoretically possible.
The challenge is that Love2D does not really expose its backend as a reusable library.
A more natural fit could be a game library like SFML or raylib, used as the base of a game engine provided as a third-party clx module.
As a Lua fanboy, I have to say this is really, really great! I have not dug into it deeply enough yet - saving a deep dive for the weekend - but meantime .. what are your thoughts about having objc_msgSend included in the runtime so that native MacOS (and eventually iOS) GUI's can be made using this technique: https://medium.com/@michael.mogenson/write-a-macos-app-with-...
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.
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 available .. I might have a go at porting these once I dive a bit deeper into clx. I've used other Lua-based engines in the past to accomplish a 'one codebase/GUI runs on all platforms' target in the past, but those engines have faded away - mostly due to the dependency on LuaJIT and the subsequent brickwalling of JIT in iOS, where the apps were making their revenue - so having clx at hand is an exciting opportunity .. assuming I can get the GUI code ported in a way that it is functional on at least the major platforms .. will ping you on GitHub if I make some progress on this, I've been meaning to bring the GUI code from those older projects into the modern context, and clx may well be the way to do it ..