MetaLua preprocessor for LÖVE

[Shviller]

Hello everyone. I made a thing, and while it is a part of a much larger work in progress, it might be of use for someone already.


What it is

This is a MetaLua (their current repo) preprocessor, allowing you to use macros and other compile-time metaprogramming techniques in your LÖVE code. For example, if you were ever irked by the lack of the += operator and its relatives, now you have them, right out of the box.

Please keep in mind that it is Windows only for now, and comes with LÖVE built with Lua 5.1 due to the current limitations of MetaLua.


Where to get it

If you already have Lua 5.1 with LuaRocks installed, you can get it by executing

Code: Select all

luarocks install love-preprocessor-cli --server=https://dl.dropboxusercontent.com/u/762468/Lua/rocks

If you don't, you can get the all-in-one installer (Lua, LuaRocks, all relevant rocks, plus a little extra: better-metalua, which gives you a couple more syntax extensions).


How to use it

This gives you the lovepp command. Currently the usage is just

Code: Select all

lovepp <command> <project directory>

The recognized commands are:

• new: creates a skeleton of a new project
• compile: translates all MetaLua code to Lua bytecode, giving you a directory that you can feed to LÖVE
• run: runs compile and launches the result using its internal version of LÖVE
• pack: produces a .love file
• deploy: creates an exe and zips it together with all relevant dlls

Why it exists

This is a part of ongoing work to create an object model specifically suited for game development: taking advantage of the things specific to it (such as the existence of the main loop) and easing code reuse. This is made possible by pretty involved processing of the code the game developer wrote, which requires representing code as data AND pushing said processing out of the runtime and into a separate "compilation" step. MetaLua answers both these needs (read: I tried to do without, and the result wasn't too pretty).

For example, many classes have an update method (and classes are an obvious choice for code reuse), which raises the problem of call order. Rather than specify it manually (which conflicts with reusability) I give each such method a set of tags and allow the definition of ordering constraints based on these tags. Most of these tags are best off automatically generated based on the method's source, and that requires a code walker, another tool MetaLua readily provides.

[Roland_Yonaba]

This looks nice. Would you please consider submitting the rockspec (and the rock) for installing this to Moonrocks?
It is like an official source for hosting rockspecs. Plus, it will be easier to deploy:

Code: Select all

moonrocks install love-preprocessor-cli

PS/ I was expecting this to be called : MetaLöve.

[Shviller]

This looks nice.

Thanks!

Would you please consider submitting the rockspec (and the rock) for installing this to Moonrocks?

Despite the code being packaged as a bunch (9, not counting better-metalua) of rocks, I don't feel comfortable releasing them properly yet. Mostly because they include only the stuff I needed to get this thing off the ground and almost literally nothing else, despite the libraries being quite broad in potential scope. There are, I think, 4 functions that aren't called from somewhere else. The only tests I have are for things that had bugs I already stumbled into. Not to mention two of the rocks are Windows-only. This is tolerable when it's a niche tool, but much less so when the libraries are released for everyone to see and use.

However, there is something I should probably do: add moonrocks to this installer thing. Thanks for reminding me! This also helped me notice I omitted rclauncher.c from the installer by accident. Updated. Once I get to my other PC, I'll try to figure out why moonrocks is crashing on this one and try to figure out a way to include moonrocks in the installer without dragging the entirety of MinGW with it.

Speaking of things that I've started but haven't managed to finish yet, I have started making MetaLua implementation-independent, but across this, the aforementioned 10 rocks and the actual engine I mentioned it's just too much work for one person. So far I have a replacement for MetaLua's ast_to_src.mlua that actually outputs Lua code that Lua 5.2 or LuaJIT can run, so if someone is hell-bent on using MetaLua without losing LuaJIT's performance benefits, they can.

The issues with it are that

• if you're prone to using variable names such as __1__submatch__2, then my tool can produce broken code, since MetaLua generates names for its local variables that are invalid as far as Lua's parser is concerned (this works because MetaLua generates bytecode without anything going through said parser), and therefore, they can't clash with anything. I can't easily replicate this when generating pure Lua code.
• error messages become useless, since they refer to the lines of the generated Lua code, not the MetaLua source. MetaLua, again, bypasses this by generating bytecode directly. This can be implemented by wrapping the entry point in a pcall (there seems to be no performance penalty for this in LuaJIT) which will rewrite the backtrace using a generated line number table, but as you can imagine, this is quite a bit of work.

If, however, you use sane variable naming conventions AND are sure your game is error-free (hilarious, I know), you can totally use this tool.

MetaLöve

I considered calling it Heavy Metalove, but somehow decided to be boring instead. I don't know why.