| Time |
Nick |
Message |
| 00:11 |
|
grorp left #minetest-dev |
| 00:23 |
|
SFENCE joined #minetest-dev |
| 00:41 |
|
SFENCE joined #minetest-dev |
| 00:49 |
|
SFENCE joined #minetest-dev |
| 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 |
| 01:24 |
|
SFENCE joined #minetest-dev |
| 01:44 |
|
SFENCE joined #minetest-dev |
| 01:55 |
|
SFENCE_arch joined #minetest-dev |
| 02:16 |
|
Fleckenstein joined #minetest-dev |
| 02:19 |
|
SFENCE joined #minetest-dev |
| 02:40 |
|
SFENCE joined #minetest-dev |
| 02:58 |
|
SFENCE joined #minetest-dev |
| 03:33 |
|
SFENCE joined #minetest-dev |
| 03:40 |
|
Fleckenstein joined #minetest-dev |
| 03:52 |
|
SFENCE joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:11 |
|
SFENCE joined #minetest-dev |
| 04:31 |
|
SFENCE joined #minetest-dev |
| 04:49 |
|
SFENCE joined #minetest-dev |
| 04:50 |
|
hwpplayer1 joined #minetest-dev |
| 05:18 |
|
SFENCE joined #minetest-dev |
| 05:38 |
|
SFENCE joined #minetest-dev |
| 06:02 |
|
YuGiOhJCJ joined #minetest-dev |
| 06:13 |
|
SFENCE joined #minetest-dev |
| 06:49 |
|
SFENCE joined #minetest-dev |
| 06:56 |
|
v-rob joined #minetest-dev |
| 06:57 |
|
v-rob joined #minetest-dev |
| 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:04 |
|
SFENCE joined #minetest-dev |
| 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:21 |
|
SFENCE joined #minetest-dev |
| 07:34 |
|
SFENCE joined #minetest-dev |
| 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" |
| 08:14 |
|
hwpplayer1 joined #minetest-dev |
| 09:28 |
|
YuGiOhJCJ joined #minetest-dev |
| 10:03 |
|
SFENCE_arch joined #minetest-dev |
| 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) |
| 14:42 |
|
hwpplayer1 joined #minetest-dev |
| 14:49 |
|
pgimeno joined #minetest-dev |
| 15:13 |
|
pgimeno joined #minetest-dev |
| 15:56 |
|
whosit joined #minetest-dev |
| 16:01 |
|
v-rob joined #minetest-dev |
| 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:36 |
|
hwpplayer1 joined #minetest-dev |
| 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:31 |
|
SFENCE joined #minetest-dev |
| 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 |
| 19:49 |
|
v-rob joined #minetest-dev |
| 20:03 |
|
Desour joined #minetest-dev |
| 20:08 |
|
SFENCE joined #minetest-dev |
| 20:26 |
|
SFENCE joined #minetest-dev |
| 20:52 |
|
SFENCE joined #minetest-dev |
| 20:55 |
|
hwpplayer1 joined #minetest-dev |
| 21:26 |
|
SFENCE joined #minetest-dev |
| 22:24 |
|
SFENCE joined #minetest-dev |
| 22:42 |
|
SFENCE joined #minetest-dev |
| 22:54 |
|
SFENCE joined #minetest-dev |
| 23:12 |
|
SFENCE joined #minetest-dev |
| 23:17 |
|
behalebabo joined #minetest-dev |
| 23:30 |
|
SFENCE joined #minetest-dev |
| 23:33 |
|
panwolfram joined #minetest-dev |
| 23:40 |
|
v-rob joined #minetest-dev |
| 23:46 |
|
v-rob_ joined #minetest-dev |
| 23:47 |
|
Sharpman joined #minetest-dev |
| 23:55 |
|
SFENCE joined #minetest-dev |
