Time  Nick      Message
07:09 Krock     Why does 'gui_scaling_filter' exist?
07:19 Krock     https://github.com/luanti-org/luanti/pull/2536
07:34 sfan5     now that I look at the docs it seems -Wnull-dereference is actually redundant
07:34 sfan5     the gcc manual is just not totally obvious with it
07:35 sfan5     >This option is only active when -fdelete-null-pointer-checks is active, which is enabled by optimizations in most targets.
07:35 Krock     the option is certainly active and does already spit out a few false-negatives
07:36 sfan5     the google AI summary however says that it *requires* -fdelete-null-pointer-checks, not that this option automatically *enables* it
07:36 sfan5     Krock: in the CI? I remember looking there
07:36 Krock     local, GCC 14.2.0
07:37 Krock     scene::ISceneNode::getTransformedBoundingBoxEdges  where `set_used` ensures that .pointer() does not return NULL
07:40 sfan5     red-001: at least the x64 run seems to already cache correctly https://github.com/luanti-org/luanti/actions/runs/32492485972/job/96803149878
08:18 Krock     hmmm https://gcdnb.pbrd.co/images/7qRr-nH33uG_.png
08:28 red-001   sfan5: it seems inconsistent, I'm thinking maybe the execution environment for github actions is just inconsistent or they are doing a roll-out of a new build of the container and not all CIs get the same build environment, in any case I think should make the change since this should make it more stable going forward
08:40 red-001   sfan5 investigated further it looks like there's a rollout by github switching the runner image from 20260810.198.2 to 20260818.207.1 the x64 build that created the cache got the new image, the x86 build that created the cache got an old image, so 64-bit caching should work for another week or two now that the rollout is more or less done, but the x86 cache will be broken
08:41 red-001   my suggestion of disabling compiler tracing and having it download it's own powershell and cmake (as binaries so it's fast) to get a more consistent ABI hash is unchanged
08:43 red-001   that or could just make it part of the key ig
08:44 red-001   the runner image that is
08:44 red-001   I don't think that's viable, you would have each pull request fighting for cache space when github does another roll out which they seem to like doing often
08:45 red-001   and there's only space for about 10 including the main branch
08:46 red-001   and they won't be able to re-use each others caches due to how github decided to force everyone to use github cache
14:53 MTDiscord <the4spaceconstants2181> well that looks scary
15:58 MTDiscord <herowl> Can anyone explain to me why is VoxeLibre suddenly crashing with Luanti 5.17? I know that adding a mod dependency in one place fixes it, but I'd like to know the reason for that.
16:00 MTDiscord <luatic> if VL missed a dependency, then the mod loading is extremely brittle. it's possible that something changed there (maybe how dependencies are sorted? i vaguely remember this was touched) so now you get the "unlucky" order.
16:02 MTDiscord <luatic> we recommend the random_mod_load_order setting in development to catch such things early
17:49 sfan5     also setting up CI is a good idea
21:37 Sokomine  hope https://github.com/luanti-org/luanti/pull/17375 gets merged soon. i notice that i dislike joining servers because greeting and chatting - important activities - got very stressful with the added space. please merge the fix!