| Time |
Nick |
Message |
| 03:21 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:06 |
|
Blockhead256 joined #minetest-dev |
| 07:50 |
|
Juri joined #minetest-dev |
| 09:36 |
|
Desour joined #minetest-dev |
| 15:36 |
|
v-rob joined #minetest-dev |
| 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:03 |
|
grorp joined #minetest-dev |
| 18:03 |
|
v-rob joined #minetest-dev |
| 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:10 |
|
grorp left #minetest-dev |
| 19:12 |
|
v-rob joined #minetest-dev |
| 19:37 |
|
CloudZen joined #minetest-dev |
| 19:37 |
|
Captain8771 joined #minetest-dev |
| 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 |
|
Captain8771 left #minetest-dev |
| 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. |
| 22:33 |
|
panwolfram joined #minetest-dev |
| 23:05 |
|
Eragon joined #minetest-dev |
| 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 |
| 23:51 |
|
v-rob joined #minetest-dev |
