Time  Nick      Message
00:57 Wuzzy     well grorp, its not the end of the world. the important part is that no community work on the translations themselves was erased... hopefully
00:58 Wuzzy     i wonder how many comments on strings we had before
06:57 [MatrxMT] <epickh> Can someone tell me where the main menu is located in the folder structure? It's somewhere in minetest-game, probably in the `default`-mod, I've figured that out. But where is it exactly?
06:58 [MatrxMT] <epickh> Would it be a good idea to leave minetest-game as minetest to trick search engines into finding it first but have Luanti be the engine and the ecosystem? Just a stupid thought.
07:01 MTDiscord <greenxenith> Leaving MTG is the plan
07:02 [MatrxMT] <epickh> Ah, okay. I didn't read the chat history after joining. I'm Sorry!
07:02 MTDiscord <greenxenith> And the main menu is currently part of builtin, but games provide icons/headers/backgrounds in their menu folder (top level, next to their mods)
07:03 [MatrxMT] <epickh> Oh, okay. I thought it was in minetest-game with me just being too blind to see it.
07:03 [MatrxMT] <epickh> Thanks!
07:03 MTDiscord <greenxenith> No problem
07:03 [MatrxMT] <epickh> Can I try to write a new main menu? Would that be very hard?
07:04 [MatrxMT] <epickh> And how would I have to do that? Just pushing to the master-branch somehow seems weird.
07:05 MTDiscord <greenxenith> Builtin (and the menu) is Lua, so it isn't terribly difficult in theory. People have tried before, but its mostly down to coming up with a design that fits the engine goals and people agree with.
07:05 MTDiscord <greenxenith> Generally you make your own branch for new features
07:40 MTDiscord <cscscscscscscscscscscscscscscscs> I feel like as it's been discussed way before, the main menu would end up being a new system entirely beyond just "rewriting it"
14:00 [MatrxMT] <grorp> Wuzzy: The translations themselves are fine I think, and if not we could restore the previous version from the Git repo.
14:00 [MatrxMT] <grorp> Strings with comments currently: https://hosted.weblate.org/search/minetest/minetest/?q=has%3Acomment. Looks lile only comments on the source strings survived.
14:06 [MatrxMT] <grorp> (the previous version from Weblate's Git repo)
14:12 [MatrxMT] <grorp> I can think of two options here: either 1. just unlock Weblate again (allowing translation work for the upcoming release to start)
14:12 [MatrxMT] <grorp> or 2. before unlocking, wait for reply from Hosted Weblate's support to see whether the Weblate translation history can be restored (may increase success chance for the support request, idk)
16:10 MTDiscord <cscscscscscscscscscscscscscscscs> @Luars ya there, in here?
16:11 MTDiscord <cscscscscscscscscscscscscscscscs> ive been looking at that PR and its actually mind bogglingly worse every time i look at it
16:11 MTDiscord <luatic> yes-
16:11 MTDiscord <cscscscscscscscscscscscscscscscs> cc grorp
16:11 MTDiscord <cscscscscscscscscscscscscscscscs> i didnt know anonymous unions were even possible
16:12 MTDiscord <cscscscscscscscscscscscscscscscs> so im assuming worse case, we have to zero initialize each.. union element? in the constructor
16:12 MTDiscord <cscscscscscscscscscscscscscscscs> if this is even possible
16:12 MTDiscord <cscscscscscscscscscscscscscscscs> regardless i dont effin like it and idk why Irrlicht does that
16:12 MTDiscord <luatic> tbh this smells like we should refactor it
16:12 MTDiscord <luatic> if it's doable with a manageable diff that is
16:13 MTDiscord <cscscscscscscscscscscscscscscscs> i read somewhere that its even compiler specific beyond like c++14 or something, but i probably misread
16:13 sfan5     so
16:13 sfan5     have we considered moving the memset into the constructor?
16:13 MTDiscord <cscscscscscscscscscscscscscscscs> thats apparently possible with a union constructor
16:13 MTDiscord <cscscscscscscscscscscscscscscscs> however, i havent a clue how that works with an anon constructor
16:14 MTDiscord <luatic> For a quick and dirty solution Krock's proposed change would work to silence the warning
16:14 MTDiscord <luatic> The proper solution probably is to refactor to std::variant
16:14 MTDiscord <luatic> and then of course we could do something in between
16:15 MTDiscord <luatic> either way this is just a relatively harmless compiler warning, we needn't get hung up on it right now
16:15 sfan5     https://0x0.st/X0gQ.png this does not raise a warning for me
16:15 sfan5     even better with this
16:16 sfan5     okay apparently clang doesn't warn on this
16:17 [MatrxMT] <grorp> this was actually my original approach in the PR where I introduced the constructor hack, I discarded it because it resulted in a compiler warning for me
16:17 sfan5     neither does gcc-14 on my setup
16:18 [MatrxMT] <grorp> 🤷
16:21 sfan5     it does warn in CI
16:22 MTDiscord <luatic> ah yes, the old gcc vs clang
16:27 sfan5     https://github.com/sfan5/minetest/commit/9e7080625e7820657ad41298030074bba232bc2a managed to trick clang
16:29 sfan5     gcc i mean
16:29 sfan5     except clang_11 does not like this trick
16:37 MTDiscord <paradust> what's the goal of this?
16:37 sfan5     to zero-initialize the struct without gcc complaining
16:41 sfan5     the complaint being Wclass-memaccess
16:41 sfan5     seems like I've found a working and simple (but not foolproof) way
16:43 MTDiscord <paradust> I don't even think zero-initializing the whole thing is a well defined operation in the standard. You can zero-initialize a single member of it, and that is a well-defined state.
16:44 sfan5     that may very well be but this being all POD types we know it's okay in practice
16:45 MTDiscord <paradust> What about making it std::variant ?
16:46 sfan5     then you refactor everything
17:43 MTDiscord <paradust> sfan5: Maybe... but in the meantime, what about just deleting the default constructor for SEvent. I believe that forces SEvent to be constructed using SEvent ev{}, which zero-initializes everything.
17:44 MTDiscord <paradust> i.e. SEvent() = delete;
17:49 sfan5     see the old pr
17:49 sfan5     afaict we found out that it doesn't work that way for unions
18:25 MTDiscord <cscscscscscscscscscscscscscscscs> I discussed that but its just not worth it
18:26 MTDiscord <cscscscscscscscscscscscscscscscs> i dont think its worth putting effort into "improving" Irrlicht when its been on the radar for removal/replacing
18:26 MTDiscord <cscscscscscscscscscscscscscscscs> Even compiler warnings shouldnt be a major priority, it honestly just needs to give results right now AKA just work (at least from the cases/fixes for irrlicht ive seen lately)
18:43 MTDiscord <paradust> sfan5: Every compiler on godbolt (clang, gcc, msvc, icc), clears the entire union. It seems an incredibly ungenerous reading of the standard to assume the padding does not include the entire remainder of the union. Compilers seem to have read it that way.
18:46 MTDiscord <paradust> Since the code has been relying on this behavior already (several places declare SEvent{}), I don't see the problem with continuing to do so. The only problem is that not all declarations of SEvent has explicitly zero-initialized it.
18:58 MTDiscord <paradust> (except adding the constructor to SEvent breaks that... making everything uninitialized, even with SEvent{})
18:59 MTDiscord <paradust> Nekobro: What exactly is going to replace it? And when?
19:00 MTDiscord <paradust> Refactoring could be done in a way to make the event handling less interwoven with irrlicht's event structure