| Time |
Nick |
Message |
| 01:13 |
|
appguru joined #minetest-dev |
| 01:30 |
|
appguru joined #minetest-dev |
| 04:56 |
|
Miner_48er joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:38 |
|
YuGiOhJCJ joined #minetest-dev |
| 07:53 |
|
calcul0n__ joined #minetest-dev |
| 09:48 |
|
YuGiOhJCJ joined #minetest-dev |
| 12:36 |
|
appguru joined #minetest-dev |
| 13:22 |
|
imi joined #minetest-dev |
| 15:13 |
|
appguru joined #minetest-dev |
| 16:51 |
|
Desour joined #minetest-dev |
| 17:02 |
sfan5 |
rubenwardy: I think it'd be useful to limit the CDB update check to once every 30m or once during the runtime of the MT process |
| 17:02 |
sfan5 |
right now just going in/out of a world will cause a recheck |
| 17:06 |
rubenwardy |
Makes sense. It's currently cached as a global but that won't persist when the mainmenu env dies |
| 17:08 |
sfan5 |
you could use core.get_once / core.set_once |
| 17:08 |
rubenwardy |
that's not documented in menu_lua_api.txt? |
| 17:09 |
sfan5 |
indeed |
| 17:09 |
sfan5 |
but it exists :) |
| 17:31 |
|
appguru joined #minetest-dev |
| 17:41 |
sfan5 |
it seems MT does not actually check the protocol version properly |
| 17:41 |
sfan5 |
if you connect to a 0.4.x server it will try to do SRP and stuff and only abort because it doesn't understand the itemdef version |
| 18:12 |
|
json joined #minetest-dev |
| 19:00 |
rubenwardy |
SDL2 should be documented as a dependency in doc/compiling |
| 19:04 |
rubenwardy |
Debian 10 (end of life June 2024) only has SDL 2.09 in the repos. Minetest seems to require at least SDL 2.0.18 |
| 19:05 |
rubenwardy |
given the EOL is so close, we could stop supporting Debian |
| 19:05 |
rubenwardy |
+10 |
| 19:09 |
sfan5 |
@paradust do you have time to PR fixes for the logging-related crash/issues? |
| 19:14 |
MTDiscord |
<paradust> for mingw? |
| 19:15 |
sfan5 |
yes |
| 19:15 |
sfan5 |
I remember you had some general improvments in mind that'd be better not just specifically on MinGW |
| 19:18 |
MTDiscord |
<paradust> I didn't really find a way to make mingw not crashy in some way. The options I identified are 1) replace all "thread_local" with a wrapper that uses a mutex and lookup table based on pthread_self(), or 2) same thing, but use a single thread-local initialized in Thread::run() to avoid the mutex |
| 19:19 |
MTDiscord |
<paradust> even after removing all the loggiing code, it was still crashing (not as frequently, but maybe 10% of the time) from other thread locals |
| 19:19 |
sfan5 |
well that's unfortunate |
| 19:20 |
sfan5 |
time to drop windows support? |
| 19:23 |
MTDiscord |
<paradust> maybe mingw support. What would be the downside of shipping an MSVC or ClangCl build? |
| 19:23 |
rubenwardy |
for my own project, I gave up on MinGW due to threading issues as well and just ship MSVC |
| 19:29 |
MTDiscord |
<zmv7> Irrlicht built with SDL doesnt accept input if you switch to second layout(e.g. ru_RU) on wayland btw. This doesnt happen on xorg |
| 19:30 |
MTDiscord |
<zmv7> Also it doesnt accept input from some keys(e.g. OEM 3 aka `) on both xorg and wayland |
| 19:49 |
[MTMatrix] |
<Zughy> It'd be great to see some sfence PRs merged, as we might be faced with a potential core dev that can reduce (and invert?) the PR stacking we've been seeing recently |
| 21:30 |
|
grorp joined #minetest-dev |
| 21:30 |
grorp |
merging #14126, #14199 in 15 min |
| 21:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/14126 -- Method add_pos for object/player by sfence |
| 21:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/14199 -- Comply with base64 library license terms by appgurueu |
| 21:49 |
grorp |
done |
| 22:10 |
|
Desour joined #minetest-dev |
| 22:40 |
sfan5 |
@paradust there are some minor disadvantages to using MSVC but no dealbreakers |
| 22:41 |
sfan5 |
C++ standards support is thankfully not an issue anymore |
| 22:57 |
sfan5 |
1. coredevs who use linux can no longer produce builds, verify issues or help with the windows workflow |
| 22:58 |
sfan5 |
2. getting our deps from vcpkg moves some control out of our hands e.g. lib versions |
| 22:59 |
sfan5 |
and last time I checked they also patch some libraries weirdly. the ones I build are 100% upstream source code and in some cases I also disable unused features to save binary size. |
| 23:00 |
sfan5 |
3. not sure if gdb can read msvc debug information. I have no expertise with msvc's debugger and neither does MT's '--debugger' option. |
| 23:02 |
sfan5 |
4. I think there's more weird msvc workarounds in the code than weird mingw workarounds :) |
| 23:03 |
sfan5 |
that's all I can think of, time for bed |
| 23:04 |
rubenwardy |
Don't you need a Windows VM anyway to verify issues? |
| 23:05 |
MTDiscord |
<warr1024> If you're thinking you may have to retire Windows official support due to lack of developers who are willing/able to work on it, maybe it's best to announce a call for volunteers soon and see if you can net any. |
| 23:05 |
MTDiscord |
<jordan4ibanez> Wow, I didn't think this day would come |
| 23:06 |
sfan5 |
'<+sfan5> time to drop windows support?' was a joke fyi |
| 23:07 |
sfan5 |
rubenwardy: cross-compiling and using a random vm / grabbing some windows computer is easy; MSVC + relevant stuff is tedious to install |
| 23:13 |
MTDiscord |
<warr1024> I don't think it makes sense to voluntarily drop Windows support, but if nobody is willing to actually support it then it's not really voluntary anymore. You can only choose whether to lie about it or not at that point. |
| 23:29 |
MTDiscord |
<paradust> It would be worth spending a little more time trying to figure out why SegmentHeap makes the thread_local problems so much worse. And coming up with a minimal example (a single .cpp file) that demonstrates a consistent crash. Maybe the mingw folks will take it seriously then. |
| 23:30 |
MTDiscord |
<paradust> Not sure we want to tie ourselves to MingW32 / 64 anyway, which seem to be in a bad shape |
| 23:30 |
MTDiscord |
<paradust> Maybe WSL has taken a big chunk of their potential user base? |
| 23:36 |
|
panwolfram joined #minetest-dev |
