| Time |
Nick |
Message |
| 00:30 |
|
troller joined #minetest-dev |
| 00:31 |
|
Alias2 joined #minetest-dev |
| 02:16 |
|
kilbith_ joined #minetest-dev |
| 02:21 |
|
kilbith joined #minetest-dev |
| 03:29 |
|
queria joined #minetest-dev |
| 03:34 |
|
queria joined #minetest-dev |
| 03:52 |
|
Extex joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 06:02 |
|
Thomas-S joined #minetest-dev |
| 06:02 |
|
Thomas-S joined #minetest-dev |
| 06:02 |
|
pmp-p joined #minetest-dev |
| 06:02 |
|
Evergreen joined #minetest-dev |
| 06:02 |
|
ShadowNinja joined #minetest-dev |
| 06:04 |
|
book` joined #minetest-dev |
| 06:10 |
|
book`_ joined #minetest-dev |
| 06:23 |
|
tekakutli joined #minetest-dev |
| 07:31 |
|
tekakutli joined #minetest-dev |
| 08:58 |
|
tekakutli joined #minetest-dev |
| 10:10 |
|
calcul0n joined #minetest-dev |
| 11:05 |
|
tekakutli joined #minetest-dev |
| 11:07 |
|
Fixer joined #minetest-dev |
| 11:18 |
MTDiscord |
<luatic> kilbith: That's a rather poor hack |
| 11:19 |
sfan5 |
having a preprocessor is the only choice, I think it's neat |
| 11:19 |
MTDiscord |
<luatic> 1. It will be applied to comments |
| 11:20 |
MTDiscord |
<luatic> sfan5: Yes, but it's a poor pattern-based preprocessor |
| 11:20 |
MTDiscord |
<luatic> It will be very, very error prone |
| 11:20 |
MTDiscord |
<luatic> What about precedency, for instance |
| 11:21 |
sfan5 |
a proper implementation should use an AST |
| 11:22 |
MTDiscord |
<luatic> Yes |
| 11:27 |
MTDiscord |
<luatic> @kilbith: You can't get your Lua tooling to ignore syntax errors |
| 11:28 |
MTDiscord |
<luatic> This preprocessor is it's only language and effectively not Lua anymore |
| 11:28 |
MTDiscord |
<luatic> You could try linting the generated Lua |
| 11:28 |
MTDiscord |
<luatic> it's own* |
| 11:29 |
sfan5 |
its own* |
| 11:34 |
MTDiscord |
<luatic> kilbith: you should split the input only once |
| 11:34 |
MTDiscord |
<luatic> currently it has worst case quadratic complexity |
| 11:37 |
MTDiscord |
<luatic> the expression pattern, "[%w%.%[%]"'_]+", looks very broken to me (arguably Lua expressions can't be matched using Lua patterns) |
| 11:37 |
MTDiscord |
<luatic> It won't be able to match bracketed expressions |
| 11:38 |
MTDiscord |
<luatic> It will incorrectly match expressions that use bracketed expressions, such as (a).b++ -> .b = .b + 1 |
| 11:39 |
MTDiscord |
<luatic> it also assumes lines as statement delimiters |
| 12:30 |
|
appguru joined #minetest-dev |
| 12:56 |
|
troller joined #minetest-dev |
| 13:43 |
|
erlehmann joined #minetest-dev |
| 13:52 |
|
kilbith joined #minetest-dev |
| 13:56 |
kilbith |
Luatic: I am aware of the limits of the implementation, it wasn't made to handle everything but since it's for my own use and I know what not to do, IMO it's the best thing you can get for a quick hacking around operators |
| 13:58 |
kilbith |
Luacheck is my biggest problem though, I can't get it ignoring syntax errors with the inline `-- luacheck: ignore` above code, it only ignores warnings |
| 14:14 |
|
kilbith_ joined #minetest-dev |
| 14:17 |
|
proller joined #minetest-dev |
| 14:37 |
|
olliy joined #minetest-dev |
| 14:47 |
|
kilbith joined #minetest-dev |
| 14:47 |
erlehmann |
kilbith why would you even want luacheck to ignore stuff that is obviously not legal lua? |
| 14:48 |
sfan5 |
consider reading the backlog |
| 14:48 |
kilbith |
because it's /controlled/ errors |
| 14:48 |
erlehmann |
sfan5 i did read it, kilbith is writing spaghetti code. i just don't get why it is important to get the linter to not complain. |
| 14:48 |
erlehmann |
if you extend the grammar that way, why care about the linter |
| 14:49 |
kilbith |
in which way it's spaghetti? |
| 14:49 |
erlehmann |
grammars for several languages in one line |
| 14:49 |
kilbith |
coming from a MCL author, it's a compliment :] |
| 14:50 |
erlehmann |
kilbith i hate the convoluted mcl stuff as much as you hate it, probably more even |
| 14:51 |
erlehmann |
kilbith i see that your thing seems useful, but wouldn't it be a good thing to use the linter at a later stage, when the preprocessing is done? |
| 14:52 |
kilbith |
how can you tell Luacheck not analysing the static files? |
| 14:53 |
kilbith |
btw Luatic: https://github.com/minetest-mods/i3/blob/main/tests/test_operators.lua#L26 (RE: "won't be able to match bracketed expressions") |
| 14:56 |
erlehmann |
kilbith, i am sorry, i do not know that. |
| 14:59 |
erlehmann |
kilbith, i think i would have set it up differently, so that i actually had static lua files coming out of the preprocessor. you seem to do it at runtime. |
| 15:00 |
erlehmann |
i see the advantage of having no intermediate output, i.e. no explicit compile step. but i doubt luacheck will work with it unless you coax it to *also* check the stuff at runtime. |
| 15:00 |
erlehmann |
which would be at least a bit weird |
| 15:00 |
kilbith |
Luacheck only checks static data |
| 15:02 |
erlehmann |
then i see no way around making the intermediate explicit |
| 15:02 |
erlehmann |
.lua is the wrong ending for stuff that is lua plus whatever you came up with anyway |
| 15:04 |
kilbith |
well yes I guess you raise a good point, it should have a different extension |
| 15:08 |
erlehmann |
otherwise i agree with luatic and sfan5 btw, that thing should use a proper parser |
| 15:08 |
erlehmann |
i doubt you'll want that, no one ever wants that |
| 15:08 |
kilbith |
so that I can implement !foo without breaking the syntax coloring in the text editor |
| 15:08 |
erlehmann |
oh good point |
| 15:08 |
kilbith |
(about custom extension) |
| 15:09 |
erlehmann |
is the ultimate purpose of this thing to a) make it more readable b) make it easier for you to work with c) achieve theoretical purity? |
| 15:10 |
kilbith |
a&b |
| 15:17 |
|
asdflkj_sh joined #minetest-dev |
| 15:21 |
MTDiscord |
<luatic> kilbith: I should have been more specific. The expression itself can be enclosed within brackets, but the operands may not use brackets / other operands / subexpressions. |
| 15:21 |
MTDiscord |
<luatic> "(1 & 1) | 1" for instance is impossible |
| 15:23 |
erlehmann |
you come with a regular expression knife to a fight where the other person is wielding something more complex than a deterministic pushdown automaton |
| 15:24 |
MTDiscord |
<luatic> Huh? |
| 15:24 |
MTDiscord |
<luatic> Lua's grammar is context-free |
| 15:24 |
MTDiscord |
<luatic> Patterns aren't regular expressions, they're even less expressive |
| 15:25 |
MTDiscord |
<luatic> RegExes would be enough for Lua tokenization (excluding long strings), which would be enough to substitute operators as long as you don't care about precedency |
| 17:08 |
|
Extex joined #minetest-dev |
| 17:45 |
|
kilbith_ joined #minetest-dev |
| 17:46 |
|
jonadab joined #minetest-dev |
| 18:17 |
|
kilbith joined #minetest-dev |
| 18:28 |
|
v-rob joined #minetest-dev |
| 19:00 |
|
v-rob joined #minetest-dev |
| 19:11 |
|
fluxionary joined #minetest-dev |
| 19:28 |
|
proller joined #minetest-dev |
| 19:58 |
|
v-rob joined #minetest-dev |
| 20:04 |
|
appguru joined #minetest-dev |
| 20:14 |
|
proller joined #minetest-dev |
| 20:22 |
|
unexploredtest[m joined #minetest-dev |
| 20:31 |
|
Pexin joined #minetest-dev |
| 21:42 |
|
erlehmann joined #minetest-dev |
| 21:44 |
|
proller joined #minetest-dev |
| 21:44 |
|
v-rob joined #minetest-dev |
| 21:44 |
|
fluxionary joined #minetest-dev |
| 21:44 |
|
kilbith joined #minetest-dev |
| 21:44 |
|
jonadab joined #minetest-dev |
| 21:44 |
|
Extex joined #minetest-dev |
| 21:44 |
|
olliy joined #minetest-dev |
| 21:44 |
|
Fixer joined #minetest-dev |
| 21:44 |
|
calcul0n joined #minetest-dev |
| 21:44 |
|
hlqkj joined #minetest-dev |
| 21:44 |
|
Chpy0 joined #minetest-dev |
| 21:44 |
|
nrz_ joined #minetest-dev |
| 21:44 |
|
BuckarooBanzai joined #minetest-dev |
| 21:44 |
|
Krock joined #minetest-dev |
| 21:44 |
|
celeron55 joined #minetest-dev |
| 21:44 |
|
Lone_Wolf joined #minetest-dev |
| 21:44 |
|
\ joined #minetest-dev |
| 21:44 |
|
Sokomine joined #minetest-dev |
| 21:45 |
|
nrz joined #minetest-dev |
| 22:13 |
|
v-rob joined #minetest-dev |
| 22:47 |
|
tekakutli joined #minetest-dev |
| 23:46 |
|
proller joined #minetest-dev |
