Time |
Nick |
Message |
01:33 |
|
appguru joined #minetest-dev |
01:38 |
|
MTDiscord1 joined #minetest-dev |
04:24 |
|
YuGiOhJCJ joined #minetest-dev |
05:00 |
|
MTDiscord joined #minetest-dev |
05:31 |
|
fluxionary_ joined #minetest-dev |
06:41 |
|
ivanbu joined #minetest-dev |
08:41 |
|
YuGiOhJCJ joined #minetest-dev |
09:10 |
|
calcul0n joined #minetest-dev |
09:15 |
sfan5 |
curious but largely irrelevant issue: the relative mouse mode changes cause Minetest to not be controllable over VNC |
10:43 |
pgimeno |
I missed yesterday's meeting, but I certainly expected CONTRIBUTING.md to be in the top level directory, as doc/ sounds more like documentation of the project, and contribution guidelines have no place there IMO. If it's in a non-intuitive directory like that, please at least mention it in the README. |
10:45 |
pgimeno |
sfan5: was it ever? I never managed to play Minetest via VNC |
11:01 |
sfan5 |
well vnc can't reset your cursor, but you could look around by carefully moving your cursor around the crosshair and moving it back to keep it still |
11:01 |
sfan5 |
with relative mouse mode that doesn't work at all for me, the view just spins on the ground |
13:30 |
|
calcul0n joined #minetest-dev |
14:10 |
|
calcul0n joined #minetest-dev |
15:03 |
|
Desour joined #minetest-dev |
15:18 |
|
appguru joined #minetest-dev |
15:35 |
MTDiscord |
<luatic> our code style guidelines still say we're at C++ 14 btw, when we really are at C++ 17 |
15:37 |
ROllerozxa |
> We are using C++14; Boost will never be an option. |
15:38 |
ROllerozxa |
lol |
15:42 |
rubenwardy |
boost will never be an option |
15:42 |
rubenwardy |
C++17 filesystem is nice |
15:57 |
nrz |
clearly no option for boost and no need. C++17 filesystem interface is nice, but as far i tested 4 years ago (maybe better now), FS is faster using linux primitives that the CPP implementation in glibc |
15:58 |
nrz |
and far more faster in primitives, which is weird. I suspect the CPP implement to load more data than we need in majority of cases |
16:17 |
|
fluxionary_ joined #minetest-dev |
16:38 |
|
fluxionary_ joined #minetest-dev |
16:57 |
|
appguru joined #minetest-dev |
17:06 |
|
whosit joined #minetest-dev |
17:10 |
appguru |
merging #13992 in 15m i am |
17:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/13992 -- Tool specific pointing and blocking pointable type by cx384 |
17:13 |
|
calcul0n joined #minetest-dev |
18:52 |
|
grorp joined #minetest-dev |
18:53 |
grorp |
sfan5: can I merge #14266? |
18:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/14266 -- Save the settings in more cases to avoid losing setting changes by grorp |
18:54 |
sfan5 |
commented. |
19:00 |
appguru |
merging #14297 in 5m |
19:00 |
ShadowBot |
https://github.com/minetest/minetest/issues/14297 -- Address `set_player_privs` footgun by appgurueu |
19:31 |
Krock |
I hope those deprecation messages don't spam the logs |
19:32 |
Krock |
furthermore I never considered this as a footgun. it's just a bit tiresome to get and then set the privs |
20:06 |
Krock |
sfan5: https://i.postimg.cc/HkXwZTQX/grafik.png http://i2.kym-cdn.com/photos/images/original/000/173/580/Wat.jpg |
20:07 |
MTDiscord |
<luatic> I think you're like a year or so late to the party 😄 |
20:08 |
Krock |
what do you mean? the commit is brand new(ly force-pushed after a rebase) |
20:10 |
MTDiscord |
<luatic> The first time this commit was pushed was a while ago |
20:12 |
MTDiscord |
<luatic> Krock: re "is it a footgun": with the previous state of docs, it definitely was. the docs neither clarified whether it was incremental, nor precisely which format the privs were expected in. both can be inferred wrongly. i've seen this happen at least 3 times. and i also wanted to tackle the main use case being rather inconvenient, yes. |
20:13 |
MTDiscord |
<luatic> re "log spam": just like any other minetest.log("deprecated", "thing"), these messages will be repeated. we could set once = true in the C++ for all these, that'd be a trivial change and i don't really see a downside to it, if the source (stacktrace) is properly taken into account when deduplicating. are there any messages that we want to be repeated? |
20:17 |
Krock |
I cannot think of any right now |
20:59 |
MTDiscord |
<luatic> pushing https://gist.github.com/appgurueu/3dd56692814532d61caa02c941fa691b in 10m. (this bug was reported to me by luk. it is not new.) |
21:01 |
Krock |
what is the problem? |
21:01 |
Krock |
false and nil should both remove the priv |
21:01 |
MTDiscord |
<luatic> No, false does not remove the priv |
21:02 |
Krock |
why not? |
21:02 |
MTDiscord |
<luatic> Because the engine treats it as a set, it only looks at the keys |
21:03 |
MTDiscord |
<luatic> (That's the footgun I was talking about) |
21:03 |
MTDiscord |
<luatic> one of the footguns, that is |
21:04 |
Krock |
grant has the same condition |
21:05 |
MTDiscord |
<luatic> I don't think it matters there because prev_privs comes from the engine or a proper auth handler. It should only have true values. |
21:05 |
Krock |
ah I see. the core_auth object is limited to this script only |
21:06 |
MTDiscord |
<luatic> But to be safe, checking against nil there too might be a good idea. |
21:06 |
Krock |
> Because the engine treats it as a set, it only looks at the keys |
21:07 |
Krock |
then I'd rather fix that instead? interpreting false and nil as the same would make sense to me |
21:07 |
MTDiscord |
<luatic> It would not be backwards compatible however |
21:08 |
Krock |
do bugs have to be backwards-compatible? |
21:09 |
Krock |
perhaps I'm misunderstanding the situation - correct me if I'm wrong |
21:09 |
MTDiscord |
<luatic> Depends. This is not an obvious bug as in "specification says one thing, we do another". |
21:09 |
MTDiscord |
<luatic> The specification says nothing here, so people probably tested or assumed. I'd prefer not to break their code. |
21:10 |
MTDiscord |
<luatic> I think the deprecation warning as it currently stands is a decent solution. Having the privs be a "set" (only keys matter) is not unreasonable. |
21:11 |
MTDiscord |
<luatic> If you don't mind, I'd like to push https://gist.github.com/appgurueu/3dd56692814532d61caa02c941fa691b now. It will certainly make things less broken than before. |
21:11 |
Krock |
on the other hand, it is easier to check "if not privs.foo then" than "if foo.privs == nil then" |
21:12 |
Mantar |
not unreasonable, but it should be documented clearly |
21:12 |
MTDiscord |
<luatic> Mantar: check the current docs, feel free to propose adjustments (I've updated them recently) |
21:12 |
Mantar |
having privs of "server = false" equal to "server = true" violates the principle of least surprise IMO |
21:12 |
Mantar |
luatic: cool |
21:13 |
Krock |
I don't think that's the correct fix. It also does not seem to be directly related to your PR |
21:13 |
Krock |
as in: the affected code was not touched |
21:13 |
MTDiscord |
<luatic> Mantar: I think the deprecation warning (which says that it's most likely a bug), plus proper docs is a good compromise between backwards compatibility and not surprising the unsuspecting modder :) |
21:14 |
MTDiscord |
<luatic> Krock: That's because it isn't directly related to my PR. |
21:14 |
MTDiscord |
<luatic> I'm not saying it is the correct fix. I'm saying it is a correct fix. |
21:16 |
MTDiscord |
<grorp> @Lars looks like you got some indentation wrong (screenshot from api.minetest.net) |
21:16 |
MTDiscord |
<grorp> https://cdn.discordapp.com/attachments/747163566800633906/1199100302167638016/Screenshot_2024-01-22-22-15-00-89_3aea4af51f236e4932235fdada7d1643.jpg?ex=65c1502e&is=65aedb2e&hm=c59a9b1aa61f11291044417fcdbbb2e93a334ca5cae1d78c4b0f5203ff10845e& |
21:16 |
Mantar |
documentation changes look good to me |
21:17 |
Krock |
somewhat messed up |
21:17 |
MTDiscord |
<grorp> It does render correctly on Github though |
21:18 |
MTDiscord |
<luatic> what markdown library does api.minetest.net use? |
21:18 |
MTDiscord |
<luatic> Anyways indeed I used 2 space indentation for the bullet points, inconsistent with 4 space indentation for other items. |
21:20 |
MTDiscord |
<grorp> You can make a PR together with the Github "NOTE!" thingy :) |
21:20 |
MTDiscord |
<luatic> yeah I thought about that too |
21:21 |
MTDiscord |
<luatic> though this really doesn't warrant a PR, I'd just commit that directly after giving you a few mins to look at it. |
21:21 |
MTDiscord |
<grorp> anway, your fix looks good to me. but changing the check in prev_privs too would be better. |
21:24 |
Krock |
l_auth.cpp L106 also does not make use of the value |
21:24 |
Krock |
okay then - even though I'd prefer to accept both - nil and false on Lua and C++ side.... just an opinion. |
21:25 |
MTDiscord |
<luatic> okay, I'll push it then |
21:26 |
MTDiscord |
<luatic> thanks for your input |
21:27 |
MTDiscord |
<mistere_123> Does anyone have a latest dev build and want to help with the blog? I need two screenshots for the blog's engine section: https://github.com/minetest/blog/pull/142#issuecomment-1904836093 |
21:27 |
MTDiscord |
<luatic> next thing, https://gist.github.com/appgurueu/9dd1964f82625c28e7636ffd176d5ed2, "Minor documentation formatting fixes" |
21:29 |
Krock |
fine by me |
21:29 |
MTDiscord |
<grorp> wait a minute, I have another thing for you |
21:29 |
MTDiscord |
<luatic> MisterE: when do you intend to publish the article? |
21:29 |
MTDiscord |
<luatic> grorp: okay, the more the merrier :) |
21:29 |
Krock |
> `privs` is a **set** of privileges: |
21:29 |
MTDiscord |
<mistere_123> ASAPISH |
21:29 |
Krock |
this is a bit confusing because it's not an std::set |
21:29 |
Krock |
perhaps I'm thinking in the wrong direction |
21:30 |
MTDiscord |
<luatic> "set" is meant conceptually / mathematically here |
21:31 |
MTDiscord |
<luatic> I call Lua values with only "true" keys "sets", just like I call tables with consecutive integer keys from 1 to n "lists", according to what they are conceptually |
21:31 |
MTDiscord |
<grorp> 1. "value of matching node/entity name" should be indented as well 2. the priority list should be a numbered list |
21:31 |
MTDiscord |
<grorp> https://cdn.discordapp.com/attachments/747163566800633906/1199104107500281896/Screenshot_2024-01-22-22-30-07-93_3aea4af51f236e4932235fdada7d1643.jpg?ex=65c153b9&is=65aedeb9&hm=7cc661ea6bd2e0a36d561e2d41ce623f510be83b4d7af454e9083435bffacdf4& |
21:32 |
MTDiscord |
<luatic> s/Lua values/Lua tables |
21:32 |
MTDiscord |
<luatic> and s/keys/values (but only the first occurrence) |
21:33 |
jonadab |
The largest downside to not repeating deprecation messages in logs, is probably that it reduces motivation for people to fix modules to not trigger them. |
21:33 |
Krock |
@luatic sets look like { 1, 2, 3, 4, apple, orange } which somewhat resembles the plain array. terminology is complicated. |
21:34 |
Krock |
anyway, the changes up to this point look good. I'll be away now. gn. |
21:34 |
MTDiscord |
<luatic> grorp: ah dang the old tabs vs spaces. we should look into setting up some kind of linter for this. |
21:34 |
MTDiscord |
<luatic> gn Krock |
21:37 |
MTDiscord |
<luatic> okay, new diff: https://gist.github.com/appgurueu/9dd1964f82625c28e7636ffd176d5ed2 |
21:40 |
MTDiscord |
<luatic> pushing in 5m |
22:34 |
|
appguru joined #minetest-dev |
23:37 |
|
panwolfram joined #minetest-dev |