LÖVE

Posted: **Sat Nov 20, 2021 10:36 pm**

ReFreezed wrote: ↑Sat Nov 20, 2021 10:01 pm And my opinion is that the C preprocessor does suck.

Maybe I shouldn't have used an absolute statement there and instead should've said that it would suck even more if it required a separate build step. I'm not a fan of the cpp either, but it has its place. I'm sorely missing an easy to use assert macro (or log) in my code that doesn't suck or requires me to rethink my entire build process.

Making things as easy as possible to use seems like it's a good thing, but we can of course have different opinions on that.

Should require() write the processed files somewhere while you're in dev mode so that the release build can load those as fallback when LuaPreprocess isn't available?

It's easily possible to seamlessly write your stuff in an entirely different language that solves that problem in a few lines of code, so it's not really an unsolvable task to make a preprocessor work the same way; all implementation details aside.

It's your thing and it's cool if you don't want it to work that way - it doesn't hurt to ask anyway, right? Gonna have to make my own thing then, heh. Or I'm gonna have to make the jump to YueScript instead - it has a nice macro feature.

Posted: **Sun Nov 21, 2021 1:32 am**

Ok, I misunderstood your stance on the C preprocessor.

It sounds to me like you want something even simpler than what LuaPreprocess is, if what you want is basically just to remove some assert calls at time of release (although you're talking about switching to another language to make it happen which seem like an infinitely larger leap, but I digress). (I also assume you mean the feature is missing from Lua specifically.) But if you already have a build system in place I don't feel like it should be much work to incorporate usage of the library in the process. You literally just require the library, give it a file path, and you get executable code back. There's no need to rethink the entire build process. If you don't have a build system - that's what the command line program is there for (for which I'm adding support for stdin/stdout for piping, as requested).

If having multiple files and usage of request() is a problem you could use @insert"path" feature (which will simply insert the contents of the specified file as-is in-place) in your main file, something like this:

Code: Select all

package.preload["functions"]     = function() @insert "src/functions.luapart"     end
package.preload["game"]          = function() @insert "src/game.luapart"          end
package.preload["entities"]      = function() @insert "src/entities.luapart"      end
package.preload["gui"]           = function() @insert "src/gui.luapart"           end
package.preload["loveCallbacks"] = function() @insert "src/loveCallbacks.luapart" end

Now you only need to process the main file and all other files gets processed automatically. You'll end up with one big file in the end, but that's probably not very important. No build system or runtime functionality needed.

All this seem very easy to me, but maybe that's because I'm biased. (I hope I'm not sounding like a jerk here. I do with for my software to be useful.)

Posted: **Sun Nov 21, 2021 1:59 am**

ReFreezed wrote: ↑Sat Nov 20, 2021 4:35 am It expects the value to be a string containing Lua code - the same as !!(). It doesn't make sense to allow other values as no other value can represent Lua code (except maybe functions, but there isn't really a good way to turn functions back into code).
Code: Select all
_BAR = toLua(5) -- This happens to produce the string "5".

just to clarify, the $ doesnt work when the reference is a function where you can pass a parameter right?
like

Code: Select all

function test(a) return "test" .. a end

$test("b")

--
Just to chime in, is there a plan to support additional functionality like switch -> if-statement for luapreprocess?
Something like

Code: Select all

local a = 1
@switch(a)
  @case 1: print(1)
  @case 2: print(2)
  
 --output
 if (a == 1) then print(1)
elseif (a == 2) then print(2)

idk maybe a better syntax or token would be better, or maybe thats too farfetched for this lib

Posted: **Sun Nov 21, 2021 2:08 am**

yetneverdone wrote: ↑Sun Nov 21, 2021 1:59 am just to clarify, the $ doesnt work when the reference is a function where you can pass a parameter right?

Yeah, no arguments for $. That's what the slightly bulkier macro syntax is for.

Code: Select all

!function test(a)  return "test" .. a  end

@@test("b")

-- Output:
test"b"

Posted: **Sun Nov 21, 2021 2:17 am**

ReFreezed wrote: ↑Sun Nov 21, 2021 2:08 am
yetneverdone wrote: ↑Sun Nov 21, 2021 1:59 am just to clarify, the $ doesnt work when the reference is a function where you can pass a parameter right?
Yeah, no arguments for $. That's what the slightly bulkier macro syntax is for.
Code: Select all
!function test(a)  return "test" .. a  end

@@test("b")

-- Output:
test"b"

is there a significant difference (preprocessing time?) between using the two that achieves the same output?

Code: Select all

--main.lua
!(
--some other data
function get_res(id)
	local str = ""
	for i, t in ipairs(t[id]) do
		local l = toLua(t) .. ",\n"
		if i ~= 1 then
			l = "\t\t" .. l
		end
		str = str .. l
	end
	return str
end
)

--usage 1
@@get_res(ui) --ive noticed here that passing string "ui" does not work

--usage 2
!!(get_res("fnt_inventory"))

Posted: **Sun Nov 21, 2021 3:10 am**

yetneverdone wrote: ↑Sun Nov 21, 2021 1:59 am
Code: Select all
local a = 1
@switch(a)
  @case 1: print(1)
  @case 2: print(2)

No, that kind of syntax is the kind of thing I want to avoid adding. Note that LuaPreprocess doesn't know what you're outputting and thus wouldn't know where to put the last 'end' in the example.

Just for fun, this example does work (even though it's a terrible way of programming):

Code: Select all

!(
local conditionCode, isFirstCase

local function switch(_conditionCode)
	conditionCode = _conditionCode
	isFirstCase   = true
end

local function case(valueCode)
	if not isFirstCase then
		outputLua("else")
	end
	outputLua("if ", conditionCode, " == ", valueCode, " then")
	isFirstCase = false
end

local function switchend()
	outputLua("end")
end
)

local a = 1
@@switch(a)
	@@case(1) print(1)
	@@case(2) print(2)
@@switchend()

-- Output:
local a = 1
if a == 1 then print(1)
elseif a == 2 then print(2)
end

You should really just write what's in the output directly - normal freaking Lua if-statements. lol

yetneverdone wrote: ↑Sun Nov 21, 2021 2:17 am is there a significant difference (preprocessing time?) between using the two that achieves the same output?

You should use the feature that best suits the situation: $func is short and sweet but takes no arguments or anything, @@func() converts the arguments to Lua code strings before calling the function, and !!() allows any arbitrary expression to run in the metaprogram (nothing special happening). More clarification:

Code: Select all

!local function noop() return "" end

!!(noop("x", 7))  -- 1
@@noop("x", 7)  -- 2
$noop  -- 3 (No arguments for this method)

-- The above essentially does the same as this:
!(
-- 1: Nothing special happening.
outputLua(noop("x", 7))

-- 2: Arguments are converted to strings with Lua code.
outputLua(noop("\"x\"", "7"))

-- 3: The value is either outputted, or called with the returned value outputted instead.
if type(noop) == "function" then
	outputLua(noop())
else
	outputLua(noop)
end

You can inspect the generated metaprogram (*.meta.lua, if debug mode is enabled) to maybe get some better idea what's happening.

The preprocessing time is probably not very important here, but as the example above may suggest, the !!() method is the most simple, and @@macros() do the most amount of extra work.

Posted: **Sun Nov 21, 2021 3:19 am**

Welp. Nevermind the switch statement haha.

I see. thanks for the insight about !! and @@

--

I forgot that youre developing Gloa. Im really excited for that language. It might be my defacto language for love.
Is there anything you need help with that? perhaps with testing?

Posted: **Sun Nov 21, 2021 8:17 am**

ReFreezed wrote: ↑Sun Nov 21, 2021 1:32 am All this seem very easy to me, but maybe that's because I'm biased. (I hope I'm not sounding like a jerk here. I do with for my software to be useful.)

Nah man, no worries. Thanks for the examples.

Posted: **Sun Nov 21, 2021 6:11 pm**

grump wrote: ↑Sun Nov 21, 2021 8:17 am Nah man, no worries. Thanks for the examples.

Cool. ^_^

grump wrote: ↑Sat Nov 20, 2021 10:36 pm I'm sorely missing an easy to use assert macro (or log) in my code

By log, do you mean a macro that outputs a print statement only if a "log level" parameter is set low enough at build time? Like so:

Code: Select all

function oldFunc()
  @@log("warning", "oldFunc is deprecated - use newFunc instead!")
end

-- Output if error level is or is lower than "warning":
function oldFunc()
  print("Warning: oldFunc is deprecated - use newFunc instead!")
end

Posted: **Mon Nov 22, 2021 8:08 pm**

Update 1.17

Changes since 1.16:

Library:

Added predefined macros @@ASSERT() and @@LOG().
Added `params.release` and `params.logLevel` for controlling aspects of the predefined macros. (See processFile().)
Added `params.macroPrefix` and `params.macroSuffix` (e.g. make @@FOO() call the function MACRO_FOO()).

Command line program:

Added support for using stdin/stdout as input/output. (Specify "-" as the file path.)
Added options --release and --loglevel.
Added options --macroprefix and --macrosuffix.

LÖVE

LuaPreprocess - straightforward preprocessor with simple syntax

Re: LuaPreprocess - straightforward preprocessor with simple syntax

Re: LuaPreprocess - straightforward preprocessor with simple syntax

Re: LuaPreprocess - straightforward preprocessor with simple syntax

Re: LuaPreprocess - straightforward preprocessor with simple syntax

Re: LuaPreprocess - straightforward preprocessor with simple syntax

Re: LuaPreprocess - straightforward preprocessor with simple syntax

Re: LuaPreprocess - straightforward preprocessor with simple syntax

Re: LuaPreprocess - straightforward preprocessor with simple syntax

Re: LuaPreprocess - straightforward preprocessor with simple syntax

Re: LuaPreprocess - straightforward preprocessor with simple syntax