Minetest logo

IRC log for #minetest-dev, 2024-01-22

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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&amp;is=65aedb2e&amp;hm=c59a9b1aa61f11291044417fcdbbb2e93a334ca5cae1d78c4b0f5203ff10845e&amp;
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&amp;is=65aedeb9&amp;hm=7cc661ea6bd2e0a36d561e2d41ce623f510be83b4d7af454e9083435bffacdf4&amp;
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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext