Time  Nick        Message
16:51 sfan5       hmm it seems to be a general problem that our logging isn't flushing on abort()
16:57 sfan5       or apparently printing to std::cerr locks up logging?
16:59 MTDiscord   <paradust> log should flush on every newline
17:03 sfan5       https://0x0.st/XE3r.png I am facing a mystery
17:03 sfan5       I don't see how this is possible
17:04 sfan5       apparently I am trying to print a null pointer
17:09 sfan5       in other news lua_tostring is not equivalent to calling tostring() in Lua
17:14 MTDiscord   <paradust> i'm not able to reproduce. Is there anything else that could be affecting it?
17:18 sfan5       rawstream << "hello" << std::endl;
17:18 sfan5       rawstream << static_cast<const char*>(0) << std::endl;
17:18 sfan5       rawstream << "this won't show up" << std::endl;
17:18 sfan5       this reproduces for me
17:29 MTDiscord   <paradust> ooh
17:29 MTDiscord   <paradust> it doesn't happen if you use nullptr
17:31 MTDiscord   <paradust> i wonder if it is putting the ostream into a bad state
17:31 MTDiscord   <paradust> so that it no longer functions at all
17:36 MTDiscord   <luatic> It's UB: https://stackoverflow.com/questions/7019454/why-does-stdcout-output-disappear-completely-after-null-is-sent-to-it
17:37 MTDiscord   <paradust> yea
17:37 MTDiscord   <paradust> std::stringstream ss; ss << "hello" << std::endl; ss << static_cast<const char*>(0) << std::endl; ss << "this won't show up" << std::endl; fprintf(stderr, "%s", ss.str().c_str());
17:37 MTDiscord   <paradust> this only prints "hello"
17:38 MTDiscord   <paradust> logging should definitely detect the error state and reset the stream
17:49 MTDiscord   <paradust> It's sleep time for me but i'll look into it tomorrow
17:50 MTDiscord   <luatic> logging should just assert that char ptrs passed to it aren't null
17:53 MTDiscord   <paradust> maybe special handling for (const char*)0 is warranted. But I would just as much presume to have it print "(null)" instead of crashing
17:54 MTDiscord   <paradust> But it is also a good idea to handle the general case, because there might be other things that cause ostream to enter an error state
17:56 MTDiscord   <luatic> Since it's UB I don't think we can rely on ostream entering an error state
17:59 MTDiscord   <paradust> true
18:00 MTDiscord   <paradust> It could push "(null)" into the stream on null string. And "(stream error)" if it detects error bit, then reset.
18:02 sfan5       just the latter would be good enough to avoid wasting lots of time wondering why the logging isn't working
18:04 grorp       does any other core dev have an opinion on the new bloom API's default value? https://github.com/minetest/minetest/pull/15231#discussion_r1786382872
18:04 grorp       I'd like to merge that PR tomorrow otherwise
18:13 sfan5       sounds okay
19:39 Captain8771 hi, on behalf of a friend here, is there any particular reason "removeSecureSettings" seems to be indiscriminately called no matter what? from what i understand, the secure settings are supposed to give access to stuff like http and whatnot, yet they seem to be removed from the config no matter what? maybe im just missing something in the code?
19:39 Captain8771 (relevant code: https://github.com/minetest/minetest/blob/master/src/content/subgames.cpp#L385
19:40 sfan5       why would you not expect it to be called?
19:41 Captain8771 ...so you can set the settings? like secure.http_mods or secure.enable_security?
19:41 Krock       the main menu can. your editor can. mods cannot and should not.
19:41 sfan5       @paradust you can see here I added a log before the assert(0) https://github.com/minetest/minetest/pull/15251/commits/4b9ef722beb78fd4b53edc3cb46f8f8840a152e4#diff-6e2c4b9b20724da3a838eca7677179a2805c18ac96ecfa5c84951c5f0bdf2e55R512
19:42 Krock       ( Captain8771 )
19:42 sfan5       yet the log message is nowhere to be seen https://github.com/minetest/minetest/actions/runs/11222470498/job/31194980801?pr=15251#step:5:247
19:42 Captain8771 Krock: i dont mean from the mod; i mean setting them in minetest.conf
19:42 Captain8771 from what i see they're just ignored by minetest's code?
19:42 Captain8771 (server environment)
19:42 sfan5       Captain8771: the code you linked is not applied to the user minetest.conf
19:43 Captain8771 wait huh
19:43 Krock       games are not allowed to overwrite the global defaults. that's what the code means.
19:43 Captain8771 ah, i see
19:45 Krock       if you're wondering about the settings precedence (priority): https://github.com/minetest/minetest/blob/1037ee2a55a4f94926c48aebba6dade7d8dcdb3b/src/settings.h#L65-L70
19:46 Krock       if you need to have *secure.*" settings, you should add them to the global minetest.conf file. either using an editor or the main menu dialogue
19:47 Captain8771 is that the /etc/minetest.conf or the one in the minetest folder
19:47 Krock       ~/minetest/minetest.conf  probably. it's a per-user file
19:48 Captain8771 alright thanks
19:48 Krock       use a file search in your home directory, I suppose. I don't know the exact location
19:53 sfan5       https://github.com/minetest/minetest/blob/1037ee2a55a4f94926c48aebba6dade7d8dcdb3b/src/main.cpp#L749
19:54 sfan5       hmm we should probably get rid of that "legacy" path
19:55 MTDiscord   <cscscscscscscscscscscscscscscscs> sfan5: nullptr stdout streams are bullshit and as lars said, undefined
19:55 MTDiscord   <cscscscscscscscscscscscscscscscs> i think they just used to not work or something
19:55 MTDiscord   <cscscscscscscscscscscscscscscscs> i cast it to int i think
19:55 sfan5       or maybe not
19:57 MTDiscord   <cscscscscscscscscscscscscscscscs> for best results, esp in a logger, just do cout << endl
19:59 Krock       the RUN_IN_PLACE case could be removed because `porting::path_user` points to the directory that contains bin/, games/, worlds/  etc. one level up would already suffice (L752-753)
19:59 MTDiscord   <cscscscscscscscscscscscscscscscs> you know what sfan
19:59 MTDiscord   <cscscscscscscscscscscscscscscscs> hear my roar. Fuck streams.
19:59 MTDiscord   <cscscscscscscscscscscscscscscscs> lets use c++20 someday
19:59 MTDiscord   <cscscscscscscscscscscscscscscscs> and std::print
20:00 CloudZen    Krock & Sfan5, thanks for your help, we found that the file in the base minetest directory was missing, and we had mistaken it for the one installed at /etc/minetest (not sure what this one does), so now the security settings are being applied properly.
20:00 MTDiscord   <cscscscscscscscscscscscscscscscs> streams are a bug disguised as a feature
20:00 Krock       CloudZen: nice. thanks for the update.
20:01 MTDiscord   <cscscscscscscscscscscscscscscscs> when are we switching to c++20
20:30 pgimeno     we just switched to C++17 so expect 3 years or so
20:43 MTDiscord   <cscscscscscscscscscscscscscscscs> my personal rule of thumb is to wait 4 years or so
20:44 MTDiscord   <cscscscscscscscscscscscscscscscs> i switched to c++17 back in 2020
20:44 MTDiscord   <cscscscscscscscscscscscscscscscs> c++20 would be 2024
20:44 MTDiscord   <cscscscscscscscscscscscscscscscs> the std isnt fully modularized yet i think but regardless its all supported essentially, at least everything one would care about
20:44 MTDiscord   <cscscscscscscscscscscscscscscscs> now, c++20 was a big release, so one might want to wait 6 years maybe
20:44 MTDiscord   <cscscscscscscscscscscscscscscscs> but c++11 adoption was pretty fast for some projects
21:33 MTDiscord   <herowl> Well, here it depends on compiler support, and Debian doesn't have gcc that would support it.
22:07 MTDiscord   <cscscscscscscscscscscscscscscscs> Who in the world rightfully develops on Debian
22:07 MTDiscord   <cscscscscscscscscscscscscscscscs> C++ let alone. So much crap is out of date I could never possibly write code on it.
23:16 nekobit     sfan5, and anyone who is familiar with irrlicht graphics: we discussed it in discord a bit, and its probably not gonna happen for a good while, but what are the considerations for something like bgfx, or as a last resort, raylib?
23:17 nekobit     bgfx supports a lot of graphics backends, like metal, native webgpu, vulkan, directX, without any extra crust on the side. No window/input handling (i think), making sdl2/3 still responsible for that.
23:18 nekobit     the current solution ive seen was just stubbing out irrlicht's gpu code and writing raw opengl calls, or just wrapping them with some graphics backend.
23:18 nekobit     but i feel like using an ultimately battle-tested graphics library would be the smartest move than doing it all ourselves
23:19 nekobit     if theres a greenlight (or a yellowlight), then i want to push all of this to a GitHub issue
23:19 nekobit     it wont happen for ages im sure, but for any effort in removing irrlicht, it is something that will have to happen
23:20 nekobit     We are on the edge for stuff like Apple support, considering they have threatened to remove OpenGL for a while now (its "deprecated atm), and android and all that is a bit of a mess i believe but dont quote me
23:20 nekobit     so we definitely cant roll with what we have forever.
23:23 [           what's actually wrong with irrlicht's gpu code?
23:31 nekobit     its irrlicht
23:32 nekobit     newer platforms expose more apis, and bgfx certainly exposes those too when necessary, so im sure we're going to be limited