Time Nick Message 00:36 \o` src/migratesettings.h line 29 g_settings->remove("disable_anticheat"); <-- is that right? 00:37 \o` I mean, in the previous lines it might be set -- if (g_settings->getBool("disable_anticheat")) -- why immediately then remove it? 00:46 \o` Sorry, KDE froze on me 00:49 \o` ignore my previous messages btw 00:54 \o` I understand the reasoning now. What I don't understand is why it's a .h file without #pragma once or include guards 02:14 nekobro remove might throw an exception or something? 02:15 nekobro id have to look closer 02:16 nekobro For EnlightenmentWM, we have a good system for this, on setup, we check which version or such something was removed, then run it through a pragma, then we move it all into its own steps 02:16 nekobro pragma? ifdef i mean, based on our version info 02:16 nekobro sometimes we run other steps, like changing a variable name or converting it 02:16 nekobro ..if im understanding whats going on here 14:17 MTDiscord it's a file that is (and should be) included only in a single place. there is no need for #pragma once or include guards. in fact those would let you accidentally include it multiple times. 15:39 MTDiscord @Lars wrong again, i meant just #if 15:39 MTDiscord just a version check 15:40 MTDiscord the current way we do the initial config is disgusting though 15:41 MTDiscord initializer list? 15:42 MTDiscord some lambdas for additional checks 18:16 MTDiscord wdym, "wrong again"? i was replying to \o` who was asking "why it's a .h file without #pragma once or include guards" 19:24 MTDiscord ohh, myb 20:02 sfan5 merging #15251, #15273, #15255, #15265 in 15m 20:02 ShadowBot https://github.com/minetest/minetest/issues/15251 -- [no sq] Safety and other fixes by sfan5 20:02 ShadowBot https://github.com/minetest/minetest/issues/15273 -- Add missing setting callbacks for display_density_factor by grorp 20:02 ShadowBot https://github.com/minetest/minetest/issues/15255 -- Ensure that null C strings do not break logging by paradust7 20:02 ShadowBot https://github.com/minetest/minetest/issues/15265 -- Fix hotbar alignment with hud_hotbar_max_width by cx384 20:40 sfan5 just got ninja'd by @appguru by posting a PR 20:41 nore About #14726, can I approve the PR (after reviewing the current version), or is it not possible since I wrote the original code? 20:41 ShadowBot https://github.com/minetest/minetest/issues/14726 -- (Adoption) Gettext and plural support for client-side translations by y5nw 20:41 sfan5 sounds fine to me if you were to approve it 20:42 MTDiscord is it really a ninja if yours is more comprehensive? 20:43 nore Ok, will review it in detail now; feature freeze still isn't passed, right? 20:43 sfan5 i think so 20:43 MTDiscord i think we still have this weekend iirc (?) 20:44 nore thanks, that's a good reason for me to review it now and not delay then :) 20:45 MTDiscord @y5nw ^ pr has a conflict that needs resolving btw 20:47 MTDiscord i just realized i can fix the json quirk 20:51 MTDiscord gah why did we need to document that parse_json outputs an error message 20:52 MTDiscord guess i'll have to add an enable_sanity param 20:53 sfan5 why is that a problem 20:54 MTDiscord the sane thing for us to do would be to return nil, err to then let modders handle that, consistent with other lua apis 20:55 MTDiscord but since we've documented that we output an error message i can't change that leaving mods that relied on it without such an error message 20:55 sfan5 hm i guess 20:56 MTDiscord I could make a new minetest.read_json with sanity enabled and deprecate (or merely discourage use of) minetest.parse_json though... 21:02 [MatrxMT] wsor4035: I am aware that #14726 needs to be rebased. I was mainly reluctant to do that because we are quite close to feature freeze 21:02 ShadowBot https://github.com/minetest/minetest/issues/14726 -- (Adoption) Gettext and plural support for client-side translations by y5nw 21:12 [MatrxMT] nore: feature freeze will happen in about 19 hours 21:13 MTDiscord Zughy: I thought feature freeze happens at the end of the meeting, not at the start? So that the meeting can still merge something and then the rest gets frozen? 21:14 [MatrxMT] yes, but there is also the rename, and I guess that will require time. Rushing things during a meeting doesn't sound like a great idea 21:14 [MatrxMT] *Rushing features 21:15 sfan5 i think if we're at the point where we need to decide if the freeze starts before, during, or after the meeting just so we can merge something last-minute without violating the rules, we should better just not do that 21:15 [MatrxMT] +1 21:16 nore @y5nw approved the PR, just a single important but simple check to add 21:16 [MatrxMT] gettext in 5.10? :o 21:19 [MatrxMT] Hard to tell given the timing, but I will make it ready (hopefully) tonight 21:21 nore thanks a lot! I'm really happy you adopted this PR, I hadn't had the energy to work on it for a long time, it means a lot to me that it was not abandonned! :)