>>25458
debugging makes sense, I wasn't thinking about the rest

now that you say it, it could be used to print text on ImGui widgets for debugging, testing, profiling, etc... about the state of the emulator, but for that you'd need access to all the internal data structures and memory areas of the emulator. I'm not sure how you'd implement that without a writing marshalling functions for each data sturcture, since a language like Lua couldn't directly read memory using pointer and if it could it would be oblivious of the struct types...

>>25459
Same I just like tinkering

>>25461
i had to close this when the skellington appeared
2spoopy4me

>>25460
luajit has ffi built-in that lets you operate on raw memory pointers, for vanilla lua you'd need a separate ffi library.

>>25463
>ffi
of course ... it shouldn't be too much boilerplate compared to what I was thinking
I was thinking it would be nice to have a systems language with an associated scripting language that could directly understand the types of the systems language, but it would be hard to make interact code with manual memory managment and the scripting code using a GC, in a memory safe way

>>25460
>I'm not sure how you'd implement that without a writing marshalling functions for each data sturcture, since a language like Lua couldn't directly read memory using pointer
It can actually, just take a look at CheatEngine which can be scripted from Lua and can read arbitrary data from pointers for debugging purposes.

>>25464
>I was thinking it would be nice to have a systems language with an associated scripting language that could directly understand the types of the systems language
Depending on what you mean by this, you might just be talking about userdata. Lua lets you create an arbitrary C object and have it be managed by Lua VM/GC, and you just write the metatables as C functions.
https://www.lua.org/pil/28.1.html
If you mean "without any boilerplate at all" then no, the boilerplate is really small though.

>>25289
the textadept creator has a degree in rocket science, not even kidding

lua?

>>25468
Lua!

>>25285
Sorry anon, Lua is a neat but unfortunately this is a #895129 thread so Python is preferred over any #FFFFFF language.

>>25470
Lua is Brazillian doe

>>25455
sauce now OP

>>25465
>CheatEngine which can be scripted from Lua and can read arbitrary data from pointers for debugging purposes
read but not write?
>>25466
>Depending on what you mean by this
What I mean is that when a C/C++ program use an embedded scripting language, the scripting language doesn't know the types of used by the program so if you want to read or write structs of the C program with the scripting language, you are forced to defined the struct definition a 2nd time in the scripting language for the FFI. Even if the scripting language is statically typed, has structs and arbitrary memory access with pointers castings, it still needs that duplicated struct definition. Each time the main application is changing, the Lua code or whatever will have to be kept in sync.

If the systems language had already the scripting language included in its syntax (or rather they would have mostly the same syntax but the scripting language's code would be lighter because it would use a GC and supposing the systems language is type inferred, the scripting language would need far less type annotations), then the same frontend could be used for both language, the systems language could directly call scripting language functions and vice versa, the scripting language could directly read and write the systems language data because they would share the same type system. No duplicate type definitions needed, no need to keep the 2 in sync, only one source of truth.

>Lua lets you create an arbitrary C object and have it be managed by Lua VM/GC, and you just write the metatables as C functions.
What I'd like to have is receive a pointer to struct from C, which is already allocated by the C code, and being able to read/write its fields it directly (having prealably declared the struct definition with the FFI library) without converting the struct to a table first and then later converting the table back to the struct. Too much overhead.
>If you mean "without any boilerplate at all"
yes

>>25285
I think Lua-tan is lightweight enough to apply the small angle approximation, so let's just call it Lua. Or is it bloated, that's why you call it Lua-tan? In than case I won't use it

>>25473
>read but not write?
It can do both.

>>25473
You might be interested in https://terralang.org/
Not a great language but a good proof of concept

>>25473
>without converting the struct to a table first and then later converting the table back to the struct. Too much overhead.
Userdata isn't fully within the criteria if what you're asking for, because the Lua VM manages the memory of a userdatum, but there is no conversion to a table when interacting from Lua. You write something like obj.foo = bar, and the Lua VM calls the __newindex metamethod, a C function. And the C function does Lua VM stack manipulation or reads data off the stack directly.

>>25477 (me)
obj in this case is an object with type "userdata" (not table) which is literally just a C pointer.

>>25455
me

>>25449
typescript and lua are good lang for slopcoding, idk why it sucked for vanilla js

>>25285
I am using Love2D to make a game because I am too stupid to install pygame.

It is what it is.

>>25285
>It's very fast and compatible because it's written in ANSI C
Actually- performance-wise Lua is utter shite. You need to rely on the unofficial LuaJIT runtime for compiled performance, a runtime which is now abandoned by its main developer and sole driving force behind keep its parity with the official runtime. LuaJIT is 5~10x more performant than the official runtime, and V8 - yes the JAVASCRIPT ENGINE V8, in Node.js, Chromium, etc. - runs circles around LuaJIT and has been doing so since 2022. Real-world benchmarking suites implemented in both Lua and JS show V8 at about 2.3x the performance of LuaJIT. In short, official Lua is up to TWENTY times slower than the best official supported embeddable JS runtime.


Furthermore, Lua's language revisions are hard-tied to runtime version and different minor language revisions have behavior that is neither backwards nor forwards compatible. The one cardinal sin worse than the runtime not being portable? The actual stuff you write in it, not being portable.

Lua is a failure.
It was originally written as a simple thought experiment for process-automation in chemical plants, and somehow it broke loose into the real world. It should've been put down like the mangy mutt it was, but then the videogame industry got its claw on it, in a time where Flash was on its way out.

>>25298
JavaScript also can, in non-strict mode. There if you assign to an undeclared local, it creates it on the global object. In strict mode, it will throw instead. As any good language should.

>>25452
>Tables and metatables are the same thing as objects/prototypes (not superficially) but with better semantics.
Metatables are a very loose mechanism that you can use to express prototypal inheritance, for sure. But the looseness of metatables means you have zero guarantees of cross-compatibility with third-party code understanding how your prototypes work, and vice-versa. Method vs non-method function calls are also caller controlled, meaning whether or not you get passed the proper 'this' is up to caller responsibility, which means the caller also continuously needs awareness of which methods to call with period and which with colon. It's such a poor fucking language convention, it gives fucking PHP displaced embarassment.

Which also means that
>Lua has only 1 feature for every task which makes it more elegant.
deserves only one response, and that is: lol. lmao even.