| Time |
Nick |
Message |
| 00:18 |
|
Noisytoot joined #minetest-dev |
| 02:04 |
|
Noisytoot joined #minetest-dev |
| 02:07 |
|
Noisytoot joined #minetest-dev |
| 02:19 |
|
SFENCE joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 09:11 |
|
MTDiscord joined #minetest-dev |
| 10:59 |
[MTMatrix] |
<Zughy> Release candidate today? |
| 11:00 |
rubenwardy |
release candidate yesterday |
| 11:00 |
rubenwardy |
https://forum.minetest.net/viewtopic.php?t=30853 |
| 12:37 |
celeron55 |
might be worth it to write some kind of SDL2 pros/cons and future expectations statement in that forum topic. the keybinding issue is probably very weird to users without some background |
| 12:45 |
celeron55 |
here's a draft: the situation has been that we have to get rid of irrlicht's legacy windowing and input code at some point, and now is the time, with SDL2 being the up-to-date replacement. it allows things like touchscreen input on desktop builds, and in the future full gamepad support. it causes changes to keyboard input handling. the keyboard input handling is in some ways more capable, but it |
| 12:45 |
celeron55 |
breaks old keyboard layout specific keybinds - this is because it binds keys based on their position on the keyboard, instead of the symbol on the key |
| 13:36 |
|
SFENCE joined #minetest-dev |
| 13:55 |
celeron55 |
^ thoughts? |
| 13:59 |
|
Noisytoot joined #minetest-dev |
| 14:02 |
[MTMatrix] |
<Zughy> I can make you wait months so you know how it feels :^] |
| 14:02 |
[MTMatrix] |
<Zughy> But yes, imho makes sense |
| 14:06 |
celeron55 |
i'm good at that game, let me get back to this in 2025 :^^) |
| 14:09 |
celeron55 |
the initial response does make me feel like a bit more workarounds to support the default keys might not hurt. but then again maybe it would hurt in the long run |
| 14:09 |
celeron55 |
like, what does one have to say to make users accept the bit of a sting this is making |
| 14:09 |
celeron55 |
where's the PR department |
| 14:12 |
MTDiscord |
<josiah_wi> 🙂 |
| 14:25 |
|
SFENCE joined #minetest-dev |
| 14:42 |
MTDiscord |
<mistere_123> After reading the explanation... I still am confused what the problem is. Â On windows, and on linux the way I do it, every time I install a new minetest version, nothing is saved that I don't manually import from the old version |
| 14:43 |
MTDiscord |
<mistere_123> If the keybinds have a different internal mapping... I simply wouldn't notice as long as it works |
| 15:00 |
|
SFENCE joined #minetest-dev |
| 15:12 |
|
SFENCE joined #minetest-dev |
| 15:34 |
|
SFENCE joined #minetest-dev |
| 15:44 |
|
SFENCE joined #minetest-dev |
| 15:50 |
|
SFENCE joined #minetest-dev |
| 16:05 |
|
SFENCE joined #minetest-dev |
| 16:15 |
MTDiscord |
<herowl> Update through distro repo or through flatpak, or through git by fetch/pull, checkout and build... all those methods keep everything that is user data intact. |
| 16:23 |
MTDiscord |
<mistere_123> Hm. yeah, it will break some players' default settings. It's not that hard to reset your keybinds again though. |
| 16:29 |
|
SFENCE joined #minetest-dev |
| 16:36 |
MTDiscord |
<herowl> You won't be able to make a compound keybind yet though |
| 16:56 |
|
SFENCE joined #minetest-dev |
| 16:58 |
|
SFENCE joined #minetest-dev |
| 17:15 |
MTDiscord |
<exe_virus> Woohoo! Now to spin up my performance testing stuff again, almost time for feature unfreeze |
| 17:40 |
|
SFENCE joined #minetest-dev |
| 17:42 |
|
SFENCE joined #minetest-dev |
| 18:02 |
|
SFENCE joined #minetest-dev |
| 18:20 |
|
SFENCE joined #minetest-dev |
| 18:55 |
|
SFENCE joined #minetest-dev |
| 18:59 |
|
SFENCE joined #minetest-dev |
| 19:15 |
|
SFENCE joined #minetest-dev |
| 20:05 |
|
SFENCE joined #minetest-dev |
| 20:40 |
|
SFENCE joined #minetest-dev |
| 20:46 |
MTDiscord |
<mistere_123> So, to be clear, it has been decided that the limiting object observers PR is not going into 5.9? |
| 20:55 |
rubenwardy |
correct |
| 21:00 |
|
SFENCE joined #minetest-dev |
| 21:18 |
|
SFENCE joined #minetest-dev |
| 21:28 |
MTDiscord |
<landarvargan> For some reason installer builds don't work when the build type is Release. https://github.com/LoneWolfHT/minetest-installers-windows/raw/master/Minetest-5.9.0-win64.msi |
| 21:29 |
MTDiscord |
<landarvargan> Exception thrown at 0x00007FFA4CD73080 (msvcp140.dll) in minetest.exe: 0xC0000005: Access violation reading location 0x0000000000000000. |
| 21:29 |
MTDiscord |
<landarvargan> https://cdn.discordapp.com/attachments/747163566800633906/1270493967359672390/image.png?ex=66b3e736&is=66b295b6&hm=510dd48fabfb69d308f912cea835eb4b50dccd3170691eb6ba7e66dfea8a5247& |
| 21:30 |
MTDiscord |
<josiah_wi> That’s standard library code. Can you go up a frame? |
| 21:31 |
MTDiscord |
<landarvargan> Logger::registerThread in log.cpp |
| 21:31 |
MTDiscord |
<landarvargan> g_logger.registerThread("Main"); in main.cpp |
| 21:33 |
MTDiscord |
<josiah_wi> Ooh a global object. Those can be uninitialized for a time at the beginning of the program. |
| 21:33 |
MTDiscord |
<josiah_wi> Fun fun, does registerThread acquire a mutex? |
| 21:33 |
MTDiscord |
<landarvargan> cpp void Logger::registerThread(const std::string &name) { Â Â std::thread::id id = std::this_thread::get_id(); Â Â MutexAutoLock lock(m_mutex); Â Â m_thread_names[id] = name; } |
| 21:34 |
MTDiscord |
<josiah_wi> I’m betting g_logger is uninitialized. |
| 21:35 |
MTDiscord |
<josiah_wi> Thus the m_mutex field is uninitialized and the access to the lock’s member data is invalid. |
| 21:36 |
MTDiscord |
<josiah_wi> UBSan might detect the issue, or printing from where it’s initialized and where the method gets called might show the issue as well. |
| 21:37 |
MTDiscord |
<josiah_wi> The order in which globals get initialized across translation units is undefined and turning on optimization flags could switch it around. |
| 21:44 |
MTDiscord |
<landarvargan> Breakpoint before the crash |
| 21:44 |
MTDiscord |
<landarvargan> https://cdn.discordapp.com/attachments/747163566800633906/1270497769177616394/image.png?ex=66b3eac0&is=66b29940&hm=26e23dea649c2b6898df0d3e35f0a4acdd5061de6f767f02cb68d282682a76f7& |
| 21:45 |
pgimeno |
doesn't that mean that g_thread is in fact initialized? |
| 21:46 |
pgimeno |
g_logger* |
| 21:48 |
MTDiscord |
<landarvargan> https://cdn.discordapp.com/attachments/747163566800633906/1270498653030842408/image.png?ex=66b3eb93&is=66b29a13&hm=19cfeacf488a814bba172f410115ec9b4de9741bce51815b4c00945172ce9923& |
| 21:52 |
MTDiscord |
<josiah_wi> Hmm, since it's accessed from main, it should be initialized by then, I think. |
| 21:54 |
|
SFENCE joined #minetest-dev |
| 21:59 |
MTDiscord |
<josiah_wi> Yes, that's correct. |
| 21:59 |
MTDiscord |
<josiah_wi> Or it will be initialized when its translation unit is used. So that's not the issue. |
| 22:03 |
MTDiscord |
<josiah_wi> It looks like the address of g_thread changed between the breakpoints? |
| 22:13 |
|
SFENCE joined #minetest-dev |
| 22:32 |
|
panwolfram joined #minetest-dev |
| 22:49 |
|
SFENCE joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
| 23:06 |
|
Pexin joined #minetest-dev |
| 23:07 |
MTDiscord |
<landarvargan> I'm way out of my depth at this point |
| 23:25 |
|
SFENCE joined #minetest-dev |
| 23:36 |
MTDiscord |
<josiah_wi> I feel like I am, too. I haven’t run into this beginning that I recall, so I’m not recognizing the issue. |
| 23:36 |
MTDiscord |
<josiah_wi> I hope it’s not caused by UB. I would recommend building with UBSan just to rule that out. |
| 23:43 |
|
SFENCE joined #minetest-dev |
| 23:47 |
MTDiscord |
<landarvargan> AFAIK that's not a thing Visual Studio? |
| 23:47 |
MTDiscord |
<landarvargan> *for Visual Studio |
| 23:48 |
MTDiscord |
<luatic> LandarVargan: How do you produce these builds? |
| 23:48 |
MTDiscord |
<landarvargan> Visual Studio 2022 with RUN_IN_PLACE=FALSE |
| 23:48 |
MTDiscord |
<landarvargan> I see an option called ASAN, I'll try that |
