Time Nick Message 08:31 rubenwardy I suggest dropping #14999 from the milestone and releasing today 08:31 ShadowBot https://github.com/minetest/minetest/issues/14999 -- minetest 5.9 mapblock flickering depending on camera view 08:36 [MatrxMT] It's already fixed for 5.9.1 btw 09:16 [MatrxMT] It's a nightmare https://github.com/minetest/minetest/pull/15137#issuecomment-2351461045 09:19 [MatrxMT] But yes, please, let's release today, I don't wanna rush the name change and it's not like FOSDEM will wait for us if we decide to apply 09:31 MTDiscord Please review #15061, it's basically almost finished. Only a few minor issues are left to fix. 09:31 ShadowBot https://github.com/minetest/minetest/issues/15061 -- Texture atlas for mapblocks meshes by Andrey2470T 10:26 Krock updating changelog 10:36 Krock sfan5: changelog is ready, draft of the forum page too. Would you have time today to provide the Windows binaries as usual? 10:37 Krock as for macos - it's very likely that the users still have to sign it manually 10:37 sfan5 the CI provides the windows binaries 10:38 Krock oh perfect. so merge, tag and release is straightforward 10:38 Krock my bad. it's even documented in the Wiki 10:40 TenPlus1 hi folks o/ 10:40 Krock Is there anyone who would like to have some more time for testing the backport branch? If not, I'd go ahead merging the branch and creating the release 10:40 Krock hi TenPlus1 10:41 TenPlus1 hey krock :) 10:41 Krock time-wise: in a few hours 10:42 TenPlus1 I may have found a but in new async mapgen feature, or a memory leak at least 10:42 Krock TenPlus1: a mod to reproduce it would be highly appreciated 10:42 TenPlus1 https://codeberg.org/tenplus1/farming/commit/e3bf5f92a7d6faccce0f6e0f8569d43d20ddf897 10:43 TenPlus1 using yesterdays farming redo, make new world, enable mod, fly straight and soon memory shootsup past 1gb 10:43 TenPlus1 today's farming redo, using older register_on_generated, enable mod, fly straight, memory sits around 600mb 10:45 TenPlus1 one of my players noticed huge memory spikes just flying around and it seems register_mapgen_script was the issue 10:46 Krock what's affected, server or client? 10:47 TenPlus1 his tests were in singleplayer mostly, as were mines when memory shot up, xanadu server has 16gb so shouldnt be affected too much 10:49 Krock the additional Lua instances do need some memory, but I don't know how much. It could be possible that 5 instances are spawned that each have a footprint of 100 MB 10:49 TenPlus1 would that also be for every player connected to a server and generating new map ? 10:49 TenPlus1 if so that could get scarey high in memory usage 10:50 Krock the map is only generated once, then loaded from memory or disk 10:50 Desour Krock: there's always only 1 emerge thread, so only 1 async mapgen lua state 10:50 TenPlus1 I mean if 5 players were online all wandering around generating new map areas, would it still be around 5 instances per player ? 10:50 Krock Desour: unless num_emerge_threads > 1 10:51 Desour well, yes 10:51 Krock TenPlus1: not per player. global limit. 10:51 TenPlus1 ah kewl, jsut checking 10:52 Krock also check your num_emerge_threads setting. if that's set and >1, then it might explain a thing or two 10:52 TenPlus1 num_emerge_threads is default, so 1 10:59 TenPlus1 will revert to using the older on_generated for now in my mods until the new async one is tried and tested 11:00 Krock please open a new issue so that it's not forgotten 11:00 TenPlus1 will do, any wording tips to get it noticed ? 11:01 Krock include as much helpful information as you can 11:08 TenPlus1 is this ok https://github.com/minetest/minetest/issues/15169 11:21 MTDiscord I've converted the atlas PR from the draft to the ready for review status 11:29 Desour merging #15113 in 0.6 kis 11:29 ShadowBot https://github.com/minetest/minetest/issues/15113 -- Add support for Tracy profiler by Desour 11:36 Krock TenPlus1: good enough. Thank you. 11:37 TenPlus1 thanks dude, the comment you left, the 604mb was with today's commit, and 1.4gb was before todayt's commit ? 11:38 TenPlus1 I dont understand the ~1 part 11:44 Desour Krock: is this fine? https://github.com/minetest/minetest/pull/15113#discussion_r1760028819 11:45 Krock TenPlus1: use collectgarbage("collect") as a workaround at the end of the callback when running in a mapgen thread 11:45 Krock commitsha~1 refers to one commit prior 11:46 TenPlus1 ah kewl, thanks :) and I'll check out the collectgarbage 11:46 Krock this should be triggered automatically. I don't yet know why it doesn't happen for the mapgen threads. 11:47 TenPlus1 some mapgen mods I usually clear the vm data value at the end manually 11:47 Krock Desour: well sure whatever. fortunately it's only for development purposes 11:47 Desour merging then now :) 11:47 Krock but it's strange how commits wouldn't work when branches do... 11:48 TenPlus1 thanks for the help :) laters o/ 11:49 Desour Krock: see https://cmake.org/cmake/help/latest/module/ExternalProject.html#git for the mentioned docs btw 11:50 Krock Desour: thanks. 11:56 Krock Desour: what do you mean in https://github.com/minetest/minetest/issues/15169#issuecomment-2351557530 ? The function is called. LuaJIT does not optimize that. 11:57 Krock the table data is created too. the C++ side forces Lua to do it. 11:57 Desour but it's only created once, not once per register_on_generated callback call 11:58 Desour get_light_data() allocates a new large table if you don't pass it one 11:59 Krock yes, but the memory usage would need to decrease at some point 11:59 Krock there might be not enough going on in the Lua mapgen thread to give Lua a chance to run the cleanup 12:00 Desour yep. and in the green area of the diff of 11's commit, there's no get_light_data() call 12:01 Desour (green because it's a revert commit) 12:01 Krock indeed. that's another hint for optimization in mods 12:02 Krock (if get_light_data() or get_data() are used) 13:03 Krock SFENCE: https://github.com/minetest/minetest/pull/15137#issuecomment-2351461045 the only change that could possibly cause such thing in 5.9.1 is the network improvement. Did you yet reproduce the issue on 5.9.0? 13:28 pgimeno the problem at #15169 is quite common, see https://love2d.org/forums/viewtopic.php?p=259618#p259618 13:28 ShadowBot https://github.com/minetest/minetest/issues/15169 -- async mapgen memory leak 13:28 pgimeno btw I guess it can be closed now? 13:30 Krock pgimeno: shouldn't the mapgen memory be freed after a while? the main Lua instance is used very often, thus this happens regularly there. but not for mapgen threads 13:31 Krock on the other hand, Lua keeps the memory for re-using later thus it's also technically correct to keep it as-is 13:31 pgimeno yes, it should but I don't think they generate enough garbage as to colloect it 13:31 pgimeno one possible solution is to tune the mapgen threads' Lua garbage collector to be more aggressive 13:32 pgimeno a more manual approach is the one that love2d took: to provide means for the user to free the bulk of the big object, leaving only the Lua side 13:32 pgimeno (Object:release() is what does that in case of love2d) 13:33 Krock the used memory in question is entirely on Lua side. nothing on C++ side needs cleanup 13:35 pgimeno ah sorry, I didn't know that 13:37 pgimeno then there's little that can be done: if that uses a lot of memory and is used by every thread, each thread needs its own copy, and if it's live (in use) then it can't be GC'd 13:38 MTDiscord could luajit's table.clear somewhat work for that(?) 13:46 SFENCE_arch Krock: No, i see it during playing/testing on 5.9.1. But I do not play so long on 5.9.0, so it can be also there. 13:55 Krock SFENCE_arch: do you know roughly the hours until failure on 5.9.1 and how many hours that were tested on 5.9.0 ? 14:43 MTDiscord frogTheSecond: No, table.clear isn't helpful here; clearing a table also doesn't free the memory. This is about userdata objects which may be big, but Lua doesn't know that so its GC heuristic can't properly take it into account. 14:44 pgimeno that was my hypothesis but according to Kroc.k it's not userdata 14:46 pgimeno either way, table.clear wouldn't help 14:47 MTDiscord To begin, we should probably use collectgarbage("count") to determine whether this is a Lua heap usage problem or a C++ heap usage problem. 14:48 MTDiscord After that we'd need to look into heap profiling. 14:48 MTDiscord Ah I see Krock already did the collectgarbage("count") part, it does in fact appear to be a Lua heap usage problem. 14:49 MTDiscord That should make it easier to analyze at least. 14:50 pgimeno it looks like just a case of too much garbage generated (because big tables with lots of objects get allocated on ever generate() call), so Desour's solution should suffice 14:50 pgimeno s/ever/every/ 14:51 MTDiscord Still I'm surprised that the GC heuristic would be performing this poorly 14:52 pgimeno tuning the mapgen threads' Lua garbage collector to be more aggressive is still an option 14:53 pgimeno apparently that's one of the strong points of Luau, memory management 14:55 Desour 1GB memory usage doesn't sound like poor GC performance to me. why would it collect so eagerly by default? 14:59 MTDiscord Desour: GC pause and GC mul defaults are 200%. ("pause GC until memory is 200%, run GC at 200% of allocation speed"). These are both tunable btw. 15:03 Desour does luajit adhere to these values? 15:04 MTDiscord this is from LuaJIT's luaconf.h, I see no indication that it wouldn't 15:06 SFENCE Krock: It is hard to say. Pause time probaly has no effect on it. I played today from morning, but with long pauses between. Something like one to three hours active in game time it takes I estimate. 15:07 Desour @luatic: ah, ok. (it's also documented in lua reference) 16:06 cx384 Interesting, not long ago I noticed high memory usage while trying out Minetest with a lot of recent and heavy mods, including mapgen mods. 16:06 cx384 I thought it was the problem of a poorly written mod, but while profiling the memory I didn't find much and couldn't reproduce it consistently, so I just moved on. 16:06 cx384 A async mapgen garbage collection problem would certainly explain this. 16:48 MTDiscord Is there the meeting today? 16:55 cx384 I think so. 16:58 SFENCE Krock: Ok, I just reproduced it on 5.9.0. 17:02 Krock SFENCE: good thanks 17:02 Krock Yes, meeting today. Nothing was announced but it's good to do it before the release 17:04 cx384 Can anyone here create an account on the dev wiki for me? I have one for the normal wiki, but it seems like I never got one for the dev wiki. 17:04 MTDiscord I don't have an account on either wiki 17:07 [MatrxMT] Thanks for handling the meeting this week Krock 17:07 [MatrxMT] Was too busy to remember 17:12 MTDiscord is it just me or is GitHub syntax highlighting on PRs broken 17:12 MTDiscord i'm looking at https://github.com/minetest/minetest/pull/14543/files#diff-eed156eda45af76b19e24f3f291ac7cd0d1986c991a4b56323f842544ceab99a for example 17:15 cx384 Hm, for me it works on the .lua files, but not on the .cpp files. 17:18 Krock it was broken in the past and is broken today. maybe they'll fix it next week. 17:19 Krock cx384 @luatic : It might be best to ask ruben or post it here https://forum.minetest.net/viewtopic.php?p=437468 (which cx384 already did) 17:19 cx384 I asked on the forum for a dev wiki account now, but I hope I don't have to wait for more than 6 months like some other people who left some post in the topic. 17:22 Krock it would be nice to have the privileged people written down somewhere, such as https://dev.minetest.net/Organisation 17:22 Krock in the past Calinou was the primary contact, who's now largely inactive when it comes to Minetest 17:23 MTDiscord iirc roller used to make people on the regular wiki, till the email part of it broke 17:25 MTDiscord frankly i'm wondering what the benefit of the (dev) wiki is at this point. the meeting notes could be kept in public github discussions just as well. 17:25 MTDiscord in fact everything could be kept on GH - in repos, issues, discussions, or wikis. and since GH has a public API there is no risk of lock-in. 17:26 MTDiscord i agree with you. also has the added benefit of not being galactically slow/503 (as the wiki has been multiple times in the past) 17:27 celeron55_ there have been attempts to get rid of the devwiki in the past but none of them had enough punch to actually make it completely irrelevant. i'd be glad if that effort was finished some day 17:28 [MatrxMT] Hurray, more stuff on GH for the vendor lock-in :/ 17:28 [MatrxMT] Oh silly me not being able to read :)))) 17:29 MTDiscord today on reading is hard 17:33 celeron55_ i'm open to alternatives which don't involve megacorporations (which always turn to crap), and also don't involve me being a web admin (which i absolutely hate doing). what i can do is pay the bills (i have a spotless track record in doing that) 17:37 MTDiscord what actually of value is on the dev wiki other than meeting announcements/notes 17:38 MTDiscord and release notes 17:38 cx384 I personally like to have a wiki separate from github, but I think one wiki is enough maybe we can merge the dev wiki into the normal wiki. 17:38 Krock @wsor4035 MT release process and rules 17:42 celeron55_ what if there was simply a git repo which contained all of that, and it was hosted on github pages for the time being? then anyone from the core team could add stuff to it and it would be backed up everywhere as distributed repos, and vendor lock-in would be minimal 17:43 celeron55_ and M$ will cover the hosting for the time being 17:44 celeron55_ the only reason to not do it this way is if people who don't know git or aren't in the core team need to edit it, but that's not the case for the dev wiki content 17:45 celeron55_ (and github even provides UI for editing the stuff in the browser, for when you don't want to actually use git) 17:46 celeron55_ i know it's kind of lame, but it github pages is such a good deal 17:46 celeron55_ -it 17:46 MTDiscord makes sense 17:47 cx384 The most popular MediaWiki alternative is Google Docs -.- https://alternativeto.net/software/mediawiki/ 17:47 celeron55_ the regular wiki is a bigger problem and it's chronically bad and my fault and i should improve it. but let's not go into that now 17:48 celeron55_ that's funny, google docs is insanely clunky for almost every imaginable purpose 17:48 celeron55_ it works for simple office folk though and isn't M$ so there's that 17:49 MTDiscord google docs is pretty decent. infinitely better than microsoft office online (o365) 17:49 celeron55_ yes of course 17:50 celeron55_ but when considering it as a wiki replacement, it's insanity 17:50 MTDiscord agreed 17:55 MTDiscord i could live with a repo + GH pages. though i don't see a significant advantage over using other GH features, both when it comes to lock-in and ease of use. 17:55 MTDiscord btw c55, what ever happen with yn5w becoming a core dev? 17:55 MTDiscord *happened 18:00 Krock Who's available for the meeting? 18:02 Krock meeting points: https://dev.minetest.net/Meetings#2024-09-15 18:03 SFENCE_arch I am here. Do not expect that it helps. 18:04 MTDiscord likewise 18:07 MTDiscord I am here too 18:07 Krock > 5.9.1 18:08 Krock after this meeting I'll push the branch to stable-5, tag release and post the forum topic 18:08 Krock thanks to SFENCE_arch for reproducing the last concern on 5.9.0, hence we are good to go. 18:08 Krock comments? 18:09 MTDiscord seems fine 18:09 SFENCE_arch I am fine with it too. 18:11 Krock > next #14543 18:11 ShadowBot https://github.com/minetest/minetest/issues/14543 -- Add gameid aliases by nauta-turbidus 18:12 Krock @herowl what would you like to discuss? 18:13 Krock and what is this? https://github.com/minetest/minetest/pull/14543/files#diff-eed156eda45af76b19e24f3f291ac7cd0d1986c991a4b56323f842544ceab99aR167 18:14 Krock a "goto" replacement, I presume 18:14 MTDiscord goto for breaking an outer loop is fine IMO 18:14 MTDiscord I'm re-reviewing the PR btw 18:15 Krock same. this notation looks unusual and if the compiler isn't smart enough, it might even create a cursed, separate function for it. 18:24 Krock no response in 10 minutes. continuing with 18:24 Krock > Thoughts on the latest proposed core dev 18:25 Krock Zughy: context? when it comes to internal team discussions, that page on GitHub is commonly the best choice 18:25 MTDiscord i assume https://github.com/orgs/minetest/discussions/81#discussioncomment-10534184 since no one responded 18:25 MTDiscord and might as well say the one above as well 18:26 Krock question is whether we benefit from more cooks 18:26 MTDiscord 1,2k issues and 111 prs would say yes 18:26 SFENCE_arch Is not this the same developer as celeron ask for opinions after previous meeting? 18:27 MTDiscord the one above is, not the linked one 18:28 Krock @wsor4035 I meant it in the sense whether there will be more activity this way. It can motivate, I suppose. 18:28 SFENCE_arch red-001 looks to have some knowleadge about security. it can be helpful. :) 18:31 MTDiscord anyways, ultimately both requires celeron55 input 18:34 Krock right. It's not too urgent and it'll pop up sooner or later 18:34 Krock Any other points? 18:34 MTDiscord nope, next topic? 18:34 [MatrxMT] I can't think of any 18:35 Krock there's the general reminder to have a look at the one approval PRs 18:36 MTDiscord didnt > (low priority) Future development cycle idea by pgimeno. Almost permanent feature freeze. (again, Krock) get skipped? 18:37 Krock yes. honestly I have my doubts whether this is easily feasible at all 18:37 Krock the development cycle is simply slow 18:37 MTDiscord probably more applicable to discuss when more people are here 18:38 Krock Unfortunately the meetings are very poorly attended as of lately... hopefully we'll have a more active one in the future 18:40 SFENCE_arch Maybe another change of time. Does last change of time helps? 18:41 Krock The meetings used to be around this time prior to srifqi's request 18:42 MTDiscord Krock: my battery had died 18:45 MTDiscord Anyway the whole point was to get another review round 18:50 Krock okay. The reviews will follow. I might have a look at it too. 18:50 Krock alright then. doing the release part now. 19:02 celeron55_ yes please discuss about y5nw 19:02 Krock rubenwardy or nrz: would you please be so nice to provide signed apk's for the GitHub downloads? 19:03 celeron55_ i will quote myself: "i talked with y5nw about adding them to the core team. y5nw would be starting slowly as they don't know that much of the codebase but would be ready to join. so, i'm asking for comments from the core team" "y5nw is also fine with joining later. so alternatively we can e.g. schedule it, or whatever. but that feels awfully arbitrary to me, so i'm proposing just adding to the 19:04 celeron55_ team" 19:04 [MatrxMT] https://matrix.org/_matrix/media/v1/download/matrix.org/vFbOwsnkzXAjNRvdkHEpRAYr 19:04 [MatrxMT] they're merging into one 19:05 MTDiscord i get nice json errors from that link 19:05 MTDiscord i think matrix broke the way they did images 19:05 MTDiscord c55, only a triager, but that makes sense 19:06 MTDiscord images used to be just plain links to images accessible to anyone, now you essentially need to auth? so hence the matrix bridge which just forwards the links is now broken. it would have to download the image and reupload it for discord. 19:06 [MatrxMT] It's a screenshot saying 19:06 [MatrxMT] "macOS 12 support (sfance)" 19:06 MTDiscord https://cdn.discordapp.com/attachments/747163566800633906/1284953581304414218/vFbOwsnkzXAjNRvdkHEpRAYr.png?ex=66e881c7&is=66e73047&hm=b20be3e57ba3195b6c0647635a9f8a5a87f95c96086e717386145bc5ede22dd6& 19:07 MTDiscord any relation to sfen5? 19:07 MTDiscord will be publically viewable for whatever discords limits on images now 19:07 Krock Zughy: broken link. I'll fix the typo. also adding the release date. 19:11 [MatrxMT] since there a few of us here, can we start talking about the rename? For instance, do we really need GitLab as a mirror due to Codeberg? 19:12 [MatrxMT] I can personally look into the Liberapay renaming, and I invite everyone to share their two cents about the gh org name (in the internal discussion, NOT in here) https://github.com/orgs/minetest/discussions/99 19:14 Krock celeron55_: or we could add them as Triager first and then move to the core devs when they're more familiar with the codebase? I have the feeling that in the past, nominees had a longer history of minetest contributions - but that might just be me. After all there's no entrance rules. 19:14 MTDiscord triager is completely different than core dev.... 19:14 MTDiscord wsor: +1 19:14 Krock @wsor4035 allows for issue management at first, without dangerous repository access 19:15 Krock granted, it's for a different purpose. you're right. 19:15 [MatrxMT] I actually have dangerous repository access :^] 19:15 Krock Zughy: oh no please don't delete the 1200 issues 19:15 [MatrxMT] :,( 19:15 MTDiscord so sad 19:26 [MatrxMT] celeron55: may I propose moving the discussion about me to the 2024-10-13 meeting? (mainly due to personal reasons) 19:33 celeron55_ y5nw: certainly. (altough, we don't tend to have agendas set so far into the future) 20:09 MTDiscord Rebased #15061 20:09 ShadowBot https://github.com/minetest/minetest/issues/15061 -- Texture atlas for mapblocks meshes by Andrey2470T 20:19 [MatrxMT] merging #15163, #15164 in 30 min or so 20:19 ShadowBot https://github.com/minetest/minetest/issues/15163 -- Avoid cloud jump when switching between mainmenu and loading screen by grorp 20:19 ShadowBot https://github.com/minetest/minetest/issues/15164 -- Don't use fixed pipeline lighting for stars by grorp 21:15 sfan5 https://github.com/flathub/net.minetest.Minetest/pull/67 does anyone want to test this before I merge it 21:18 sfan5 also structural feedback welcome for #15151 21:18 ShadowBot https://github.com/minetest/minetest/issues/15151 -- [no sq] Divorce map database locking from env lock by sfan5 21:36 [MatrxMT] grorp: forgot? 21:51 MTDiscord sfan5: installed, doesn't blow up 21:51 MTDiscord i can play CTF with it 23:44 MTDiscord Any ideas on what's the best way to separate the Ambient Occlusion from the light data here: https://github.com/minetest/minetest/blob/4aec4fbe6f62688bc7dee3c227c0241eee977c7e/src/client/mapblock_mesh.cpp#L148-L250 ? 23:45 MTDiscord Is making it return an u32 instead of u16 and adding it as a separate parameter a good idea? 23:47 MTDiscord Considering there are only 4 possible values of ambient occlusion in this function (none or one of the 3 from the lookup table near the bottom of function), another option would be to devote just 7 bits to light_day and light_night each and have remaining 2 bits encode the ambient occlusion... 23:47 MTDiscord Another option is passing a pointer as a parameter to place the ambient occlusion outcome directly where it'd be used later... 23:52 MTDiscord It seems that the ultimate outcome of this function ends up either at https://github.com/minetest/minetest/blob/4aec4fbe6f62688bc7dee3c227c0241eee977c7e/src/client/content_mapblock.cpp#L262 or at https://github.com/minetest/minetest/blob/4aec4fbe6f62688bc7dee3c227c0241eee977c7e/src/client/content_mapblock.cpp#L472 where it's disassembled and put in a struct anyway