Time Nick Message 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 15:35 MTDiscord 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 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 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 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 The first time this commit was pushed was a while ago 20:12 MTDiscord 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 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 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 No, false does not remove the priv 21:02 Krock why not? 21:02 MTDiscord Because the engine treats it as a set, it only looks at the keys 21:03 MTDiscord (That's the footgun I was talking about) 21:03 MTDiscord one of the footguns, that is 21:04 Krock grant has the same condition 21:05 MTDiscord 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 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 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 Depends. This is not an obvious bug as in "specification says one thing, we do another". 21:09 MTDiscord The specification says nothing here, so people probably tested or assumed. I'd prefer not to break their code. 21:10 MTDiscord 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 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 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 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 Krock: That's because it isn't directly related to my PR. 21:14 MTDiscord I'm not saying it is the correct fix. I'm saying it is a correct fix. 21:16 MTDiscord @Lars looks like you got some indentation wrong (screenshot from api.minetest.net) 21:16 MTDiscord 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 It does render correctly on Github though 21:18 MTDiscord what markdown library does api.minetest.net use? 21:18 MTDiscord Anyways indeed I used 2 space indentation for the bullet points, inconsistent with 4 space indentation for other items. 21:20 MTDiscord You can make a PR together with the Github "NOTE!" thingy :) 21:20 MTDiscord yeah I thought about that too 21:21 MTDiscord 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 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 okay, I'll push it then 21:26 MTDiscord thanks for your input 21:27 MTDiscord 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 next thing, https://gist.github.com/appgurueu/9dd1964f82625c28e7636ffd176d5ed2, "Minor documentation formatting fixes" 21:29 Krock fine by me 21:29 MTDiscord wait a minute, I have another thing for you 21:29 MTDiscord MisterE: when do you intend to publish the article? 21:29 MTDiscord grorp: okay, the more the merrier :) 21:29 Krock > `privs` is a **set** of privileges: 21:29 MTDiscord 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 "set" is meant conceptually / mathematically here 21:31 MTDiscord 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 1. "value of matching node/entity name" should be indented as well 2. the priority list should be a numbered list 21:31 MTDiscord 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 s/Lua values/Lua tables 21:32 MTDiscord 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 grorp: ah dang the old tabs vs spaces. we should look into setting up some kind of linter for this. 21:34 MTDiscord gn Krock 21:37 MTDiscord okay, new diff: https://gist.github.com/appgurueu/9dd1964f82625c28e7636ffd176d5ed2 21:40 MTDiscord pushing in 5m