Minetest logo

IRC log for #minetest-dev, 2022-05-09

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
04:00 MTDiscord joined #minetest-dev
05:05 nore joined #minetest-dev
06:32 calcul0n joined #minetest-dev
07:33 nrz_ hello, i'm not so active, but i want to say it's great to see that there is a monthly blog post about minetest, it's a very nice addition for the community. Who manages it ? 🙂
07:38 MTDiscord <ROllerozxa> I believe MisterE was the one who started it, but rubenwardy manages it in addition now when it's been made official
09:15 nrz_ it's pretty nice addition 🙂
09:15 nrz_ I should take some time at a point to lookup again on core engine performance, but not sure it has badly evolved in 2 years, and the issues remains the same, too much lua :p
09:18 erle nrz_ are you interested in improving engine performance?
09:18 erle nrz_ like, since you wrote “again”, did you do it in the past?
09:19 MTDiscord <ROllerozxa> client performance has seen some great improvements as lately as only the recent weeks, it's wonderful :)
09:21 erle ROllerozxa tell me when i can remove the ground content check from the studs mod to make the entire world into legos ;)
09:21 rubenwardy nrz_: just use a profile, don't guess
09:21 erle ROllerozxa (which improvements do you mean?)
09:27 MTDiscord <ROllerozxa> well there was #12231 being fixed which I felt caused a significant improvement in performance when there is a lot of geometry that is being rendered, but also making logging cost-free when it is not being written, nodebox culling, and then sfan's misc. performance improvements PR
09:27 ShadowBot https://github.com/minetest/minetest/issues/12231 -- HWBufferMap causes periods of low framerate and stutter
09:28 MTDiscord <ROllerozxa> oh and fixing mapblock geometry optimisation, that was broken for a while, oops :P
09:30 MTDiscord <ROllerozxa> and of course there's the irrlicht array rewrite and whatever else that hasn't been merged yet
09:44 Fixer joined #minetest-dev
09:44 YuGiOhJCJ joined #minetest-dev
09:45 MTDiscord <luatic> nrz_: Too much Lua isn't the issue, Lua can be pretty fast. Too bad algorithms (crafting, entities inside radius, etc.) are the problem.
09:46 MTDiscord <luatic> erle: your studs would require actual culling checks (checking whether the studs are occluded / "stuck" in another block) which haven't been implemented yet
09:47 erle luatic you forgot to mention 1 billion drawcalls [puts pinky finger on mouth like doctor evil]
09:47 nrz_ luatic, entites inside radius function call has been heavily optimized on my side, but maybe it's not the right solution to use, and if we can know which generic function is needed from core engine to solve this issue, let's implement it
09:47 nrz_ what is the issue with crafting algorithm ?
09:47 erle luatic yeah x2048 focused on the snow layers
09:48 MTDiscord <luatic> nrz_: The hashes are too poor
09:48 erle luatic explain “too poor”?
09:48 MTDiscord <luatic> It often falls back to hashing only by item count
09:48 MTDiscord <luatic> Which obviously means lots of collisions
09:48 MTDiscord <luatic> i.e. you get a linear search in the end
09:48 nrz_ on my side, 5 years ago i implemented the item pickup algorithm (which is in lua and pretty well written) in C++ and it make it blazing fast whereas it's pretty close algorithm 🙂
09:48 MTDiscord <luatic> How could item pickup be slow in either Lua or C++?
09:49 nrz_ same for node falling, it's pretty slow as lua, too much c++ <-> lua cross calls
09:49 MTDiscord <luatic> Did you benchmark using LuaJIT? It often provides a 5x speedup.
09:49 MTDiscord <luatic> Ah yes, the cross calls.
09:49 nrz_ i don't like using luajit, it's better yes, but i prefer a vanilla lua 😄
09:49 MTDiscord <luatic> My solution would be to make more in Lua, not less
09:49 MTDiscord <luatic> Reducing the amount of cross calls and the maintainabiltiy :)
09:49 nrz_ also optimizing calls is very painful when you do flamegraphs and you have the lua VM inside 😄
09:50 MTDiscord <luatic> (improving the maintainability)
09:50 nrz_ lua VM memory amount is limited and GC is not good
09:50 MTDiscord <luatic> GC is good :P
09:50 MTDiscord <luatic> It means less memleaks
09:50 MTDiscord <luatic> Also no, Lua VM mem isn't limited
09:50 MTDiscord <luatic> That's a LuaJIT restriction
09:50 MTDiscord <luatic> And there even exists a patch to fix it
09:51 erle bad algorithms trump everything
09:51 MTDiscord <luatic> (and if your Lua takes more than 2 GB mem you've probably messed up anyways)
09:51 MTDiscord <luatic> erle: agreed
09:51 erle luatic i wonder why so few people agree in general though
09:51 MTDiscord <ROllerozxa> is there even any single reason to use PUC Lua over LuaJIT other than "it's bundled and can't be arsed to install LuaJIT"? it's only got improvements it seems
09:51 MTDiscord <luatic> Because writing good algorithms can be pretty hard :P
09:52 erle ROllerozxa luaJIT is not the same
09:52 MTDiscord <luatic> Brute forces / linear searches / whatever inefficient algorithm you can immediately come up with are just too easy to implement correctly
09:52 MTDiscord <ROllerozxa> erle: well yes, but is there anything you're losing?
09:52 MTDiscord <luatic> LuaJIT has more features :)
09:52 MTDiscord <luatic> I suppose LuaJIT might have more crashes
09:52 nrz_ no GC is not good, when you manage properly the memory, there is no overhead, and we are in a game. GC is not good. reactivity >> all
09:53 MTDiscord <luatic> Right, you're concerned with "stop-the-world" pauses of the GC?
09:53 MTDiscord <luatic> Valid point. If those GC pauses are < 5ms though, they're very much acceptable in terms of reactivity.
09:54 nrz_ everything which impact latency. I agree GC on web is fine, and majority of the app cases, but game are real time and require the lesser latency you can,
09:54 erle i mean right now i take “oh your stuff is written in language X, it must be slow, I use C / C++” as a shibboleth for “i have no idea what algorithms are”
09:54 MTDiscord <luatic> Especially considering that Lua usually runs on the server.
09:54 nrz_ 5ms lag is big for a game, especially when rendering depend on it
09:54 MTDiscord <luatic> We don't have proper CSM yet
09:54 erle lua is server side
09:54 erle most of the time
09:54 MTDiscord <luatic> And only CSM have the potential to slow down the client
09:54 nrz_ yeah i know my work on CSM has not been finished 😄
09:54 MTDiscord <luatic> lol
09:55 erle nrz_ what is your opinion on waspsaliva?
09:55 nrz_ waspaliva ? wtf is that
09:55 MTDiscord <luatic> Anyways, TBF designing a good algorithm for MT crafts is hard
09:55 MTDiscord <luatic> cheat client
09:55 MTDiscord <luatic> erle constantly advertises it here lol
09:55 nrz_ i have no opinion except cheat is bad :p
09:55 erle nrz_ it comes with a bunch of CSMs and better CSM APIs
09:55 MTDiscord <luatic> well, it does appear to have a feature-fledged CSM API, but I haven't really looked into it
09:56 nrz_ we fixed many cheating issues in the past, with some network required breakage. Some are not fixed yet, sfan5 did some things years ago but not merged, to try to solve paret of them
09:56 erle i constantly advertise it so that people take a look at it and cherry-pick the stuff that is good https://repo.or.cz/waspsaliva.git
09:56 erle it is about engine development after all
09:56 nrz_ CSM has some interesting tiny feature, the main problem which stopped the dev was there is no consensus or CSM code deployment to clients
09:56 MTDiscord <luatic> (and there still is no SSCSM consensus)
09:56 nrz_ in years it's ... argh 😄
09:56 MTDiscord <luatic> (mainly because we hardly know how vulnerable PUC Lua / LuaJIT are)
09:57 erle nrz_ no one knows how to make SSCSM secure or performant. but stuff like hosting CSMs on CDB should be possible. fleckenstein made something called cheatDB which is like contentDB for cheats. it shows it is possible. but it is useless (bc only cheats) and often down.
09:57 MTDiscord <luatic> The Minetest CSM API would also need to be properly secured.
09:57 MTDiscord <luatic> I agree with the CSM on CDB approach
09:57 nrz_ erle, it was my primary idea, use CDB (which was pretty vanilla when i developed CSM) to host it
09:57 nrz_ but server owners said, wtf we cannot control mods isntalled on clients
09:57 MTDiscord <luatic> What?
09:58 erle nrz_ server owners that say that are by and large idiots
09:58 nrz_ my approach when design CSM was like World of Warcraft one, client should be able to tweak UI or some things to improve his experience
09:58 MTDiscord <luatic> ^
09:58 erle nrz_ that is eactly what waspsaliva does
09:58 MTDiscord <ROllerozxa> so we can't have fun because server owners said so
09:58 erle nrz_ it has stuff like autofly, where you select a waypoint and then it flies there (which obv only works when you can fly, but is a quality of life improvement)
09:58 nrz_ now you have the history from a 9 years old coredev on this project 😄
09:59 nrz_ and honestly this CSM drama tired me so much that i nearly stopped the dev on the project, but it sounds healthier today 😄
09:59 erle nrz_ if you want to make a minetest fork that has better CSM support and no SSCSM, count me in.
09:59 nrz_ no i don't want to fork project, i had similar idea 5 years ago, but no
10:00 nrz_ as i'm (maybe removed ?) a coredev i prefer to work on upstream and try to change things, my ideas were sometimes opposed to the project.
10:00 erle i think listening to server owners that think that CSM = cheat is the most stupid design decision ever
10:00 nrz_ i always have the idea that coreengine should own the most critical performance prone algorithm and no the lua part
10:00 erle nrz_ are you still a coredev?
10:01 nrz_ https://github.com/orgs/minetest/teams/engine i'd say yes 😄
10:01 erle nrz_ if you want to look at performance critical stuff, maybe improve particle rendering lol
10:01 nrz_ the most interesting part is that the core engine part has never moved in 3 years 😄
10:01 erle ROllerozxa https://blog.separateconcerns.com/2015-06-18-love-hate-luajit.html
10:01 nrz_ for particle rendering o presented a very big particle draft years ago, but paramat blocked it
10:02 erle nrz_ show
10:02 nrz_ i presented meteo system through core engine 😄
10:02 erle nrz_ meteo?
10:02 nrz_ weather: sorry taked in french 😄
10:02 erle nrz_ the problem with particles is that every particle is a billboard scene node abomination thingy with its own drawcall overhead.
10:02 nrz_ https://github.com/minetest/minetest/pull/7519
10:03 erle ROllerozxa “When you find a bug in LuaJIT, understanding it and fixing it is terribly complicated. The best I can do is usually to try to produce a small test case that reproduces the bug (even that is not always easy) and hope Mike Pall finds a fix. With PUC Lua I could probably fix it myself - but of course PUC Lua is so simple that I have never found a bug in it!”
10:03 nrz_ pretty vanilla but working 😄 and client side handled with high level api from server
10:04 erle nrz_ that reminds me of when very early (when i was maintaining minetest delta) someone submitted a weather system. that person neer cleared up their whitespace, so it never got merged!
10:05 erle neer → never
10:05 erle nrz_ i urge you to try out waspsaliva to see at least some of your vision of CSMs
10:06 erle it has automatic building from schematics (if users have the resources) and even e2e-chat
10:06 erle and stuff like “set a waypoint where you have last seen a user”
10:06 erle so you can seek them out or avoid them
10:12 erle ROllerozxa see also https://web.archive.org/web/20220509101211if_/https://news.ycombinator.com/item?id=12574290
10:13 erle >  We still would like to hire someone to work on LuaJIT. We've found it very, very hard to find anyone suitable. There are few people who understand LuaJIT internals and few who want to get into it.
10:13 erle https://web.archive.org/web/20220509100404if_/https://news.ycombinator.com/item?id=12573981
10:13 erle >  I love commentary on LuaJIT, it's like a discussion of the subtleties of an acient game whose practitioners understand and enjoy, and everyone else ignores.
10:17 nrz_ sorry but not interesting on looking for a fork or work on it 🙂
10:17 HuguesRoss joined #minetest-dev
10:29 rubenwardy [10:47] <+nrz_> luatic, entites inside radius function call has been heavily optimized on my side, but maybe it's not the right solution to use, and if we can know which generic function is needed from core engine to solve this issue, let's implement it
10:29 rubenwardy Pffft. You only did a superficial optimisation of the Lua binding iirc. The algorithm is still O(n) over all loaded entities, rather than using a spatial partition. Wouldn't consider this heavily optimized
10:31 nrz_ no one optimized it more than 3 years after i did this ? 😄
10:32 rubenwardy It's nontrivial, requires changing how objects are stored or adding an index
10:32 MTDiscord <ROllerozxa> erle: I see. yeah LuaJIT is of course larger and more complex than PUC Lua (it even has assembly code last I checked! madness!)... and maintenance is of course quite an important issue, I don't see cloning mike being viable anytime soon :P
10:50 MTDiscord <luatic> ^
10:51 MTDiscord <luatic> Worth mentioning that libspatialindex is too weak for this
10:51 MTDiscord <luatic> So we'd have to swap that out with something like https://github.com/tuxalin/THST
10:54 rubenwardy you don't need a library for spatial paritions. MapBlocks are an example of a spatial partition
10:54 nrz_ rubenwardy, ok, i have an idea in mind, let's see if i can poc it during the week or not
10:54 rubenwardy but an oct-tree is more efficient when you have a lot of objects at varying densities
10:55 MTDiscord <luatic> ^
10:55 MTDiscord <luatic> that
10:55 rubenwardy see #11973
10:55 ShadowBot https://github.com/minetest/minetest/issues/11973 -- WIP: Performance improvements for entity collision by JosiahWI
10:55 MTDiscord <luatic> although I don't want an oct-tree, I want an R-tree
10:55 celeron55 take into account also that there will be large amounts of objects added and removed from the spatial index
10:55 celeron55 so adding and removing has to be fast
10:55 MTDiscord <luatic> rubenwardy: yes, we collaborated on that PR
10:55 MTDiscord <luatic> it uses an R-tree
10:55 MTDiscord <luatic> and as said, we need THST unless we want to reimplement R-trees
10:57 sfan5 would reimplementing r-trees be that bad or
10:58 rubenwardy using a fixed partition (like MapBlocks do) gives you the best case for add/remove time, and the lookup case isn't that bad if the density doesn't vary insanely
11:01 sfan5 couldn't a simpler data structure work too? something like std::map<v3s16, std::vector<ServerActiveObject*>>
11:01 rubenwardy that's a fixed partition
11:01 sfan5 yes
11:01 rubenwardy We had a PR for that in the past by numberZero, it was merged and then reverted
11:01 sfan5 though the issue you have regardless of approach is keeping the data structure and object position in sync
11:03 erle why was it reverted
11:03 rubenwardy there were some issues and it was a week before a release
11:03 rubenwardy it being the revert
11:04 rubenwardy #6587 and #7539
11:04 ShadowBot https://github.com/minetest/minetest/issues/6587 -- Optimize entity-entity collision by numberZero
11:04 ShadowBot https://github.com/minetest/minetest/issues/7539 -- Revert 6587 - Optimize entity-entity collision by lhofhansl
11:05 erle ROllerozxa basically every comment on LuaJIT is a variation of “you need to have a deep understanding of *both* lua and JITs before you even try to make sense of this”
11:06 erle does anyone have an opinion on strict mode? i.e. not turning typos into nils?
11:07 erle https://web.archive.org/web/20200131012133/http://metalua.luaforge.net/src/lib/strict.lua.html
11:18 MTDiscord <exe_virus> Sfan is thinking along the same lines as me. I want an unordered map aligned with mapblocks, because objects get unloaded with mapblocks, and so we should align the index to that.   But having a vector for every single mapblock is quite memory intense, so obviously any empty mapblock is just going to be a null pointer. But even that 8 bytes • number of possible mapblocks is like 393 GB, so we need a fixed octtree hierarchy of
11:18 MTDiscord mapblocks. There are 3750 by 3750 by 3750 total mapblocks, and so having probably two more levels is reasonable, say one of 50•50•50 and each of those made up of 75'75'75 mapblocks.   The only level that must be loaded in ram is the top, which 50 • 50 • 50 • 8 bytes = 1 MB.   We can do a vector or a map as the bottom storage container, probably map for fast insertion and deletion.   That's just my design, focusing on fixed box sizes so
11:18 MTDiscord we can do math really fast. I believe R trees are flexible in size, and so we can't optimize for it nearly as well. (Goes my thinking)
11:19 MTDiscord <exe_virus> Then, entities must store their previous index position, and update it each of their steps.
11:20 celeron55 and then, what about the case where we extend the node space to more than 16^3 bits?
11:26 erle ROllerozxa given that issues like https://github.com/LuaJIT/LuaJIT/issues/203 exist, i bet the end game of “hard depend on LuaJIT” would be to integrate it into the minetest codebase to make it less modular hehe ;>
11:28 nrz_ i think we can do simpler, and remember that you just offload the position radius check to mapblock search + inside radius checking. The kissier (and thread_safe) we can do is the better
11:43 Baytuch joined #minetest-dev
12:15 Zughy[m] so, should we warn players that maps are not compatible anymore between a version and another? #12005
12:15 ShadowBot https://github.com/minetest/minetest/issues/12005 -- Old maps are upgraded to ZSTD block compression, making it impossible to load the world in 5.4
12:17 rubenwardy Given 5.5 has been released, looks like no
12:20 erle it still has not been widely packaged
12:20 Zughy[m] closing then
12:46 Taoki joined #minetest-dev
13:24 Taoki joined #minetest-dev
13:28 proller joined #minetest-dev
13:42 sfan5 Zughy[m]: the release notes contain warning
13:44 sfan5 +a
14:12 josiah_wi joined #minetest-dev
14:17 josiah_wi irr#84 is ready for review, or if it's unlikely to get reviewed it'd be good to know so I can stop working on it.
14:17 ShadowBot https://github.com/minetest/irrlicht/issues/84 -- Restore some unit tests by JosiahWI
14:24 erle josiah_wi, wasn't it RFR months ago?
14:25 josiah_wi RFR?
14:25 erle josiah_wi, why did you remove the driver thing? apart from it not belonging in a test arguably, isn't it important info?
14:25 erle ready for reviewo
14:25 erle ready for review
14:25 josiah_wi Yes, but it wasn't passing.
14:26 josiah_wi The CI that is.
14:26 josiah_wi I removed the driver test temporarily because it was segfaulting on MacOS.
14:26 josiah_wi I still have it in my working tree to fix.
14:27 erle i absolutely hate the “you are not allowed to add tests that are not passing” idea, but i see why you did it
14:27 erle i think that “does the CI pass tests” should not be intimately coupled with “is this mergable”
14:28 erle at least not to this degree
14:28 erle simply making sure that a test that passed last time is not non-passing this time would be enough IMO
14:28 erle (then you could add new tests that fail before fixing the implementation all the time)
14:28 erle so, bad CI if you ask me
14:28 erle bad CI *policy*
14:29 rubenwardy You are allowed to add tests that are not passing if they're whitelisted/skipped and about a planned feature
14:30 nrz_ strange way of development :p
14:30 josiah_wi I opted not to add it yet because I don't know why it isn't passing, and at this point I just want to get something useful merged.
14:46 MTDiscord <exe_virus> celeron55: in that case, the 50•50•50 top level just gets increased, the question is, are we trying to go full infinite size or just a larger world? Either way 50•50•50 leaves room for a solid 206 more slots for the same efficiency, and there's nothing except ram stopping us from going larger. The ram requirements for 256•256•256 Is 16 MB, and that gets you a 300,000 node cube width... The second layer could also be
14:46 MTDiscord larger, with little to no cost, raising from 75 to 256 and yielding a 1.2 million edge side. I really can't think of a case where you don't hit computer limits of RAM and Storage for such a large map before this index hits issues
14:58 erle exe_virus just how many mapblocks do you want to forceload at the same time? (or does this even matter)
15:06 erle rubenwardy this is funny because both minetest 5.3 and minetest 5.4 were released with tests not passing on my machine and tests passing even if they should not have passed (test contains unconditional UB) ^^
15:06 erle i.e. the CI is both too strict and not strict enough :P
15:06 rubenwardy your machine is a bit of an edge case
15:06 erle nah, most of it has nothing to do with the gcc x86 rounding stuff
15:07 erle if anyothing is an edge case, it's me complaining about it
15:08 erle also the “tests passing if they arguably should not” is a general thing that is hard to address as long as merges are not allowed with failing tests, unless you commit the fix for it at the same time.
15:08 erle after all, any fix would literally make the test fail haha
15:09 erle (i have no good solution for this)
15:14 josiah_wi One "fix" would be to intentionally break the test once before committing it, to verify that it fails correctly.
15:14 josiah_wi If we know of some tests that are passing even though they shouldn't, perhaps we should remove or rewrite them (depending on why they are passing).
15:24 MTDiscord <exe_virus> Erle: none, the thinking is the top level stores just null pointers for empty areas, but areas that are filled go down the tree. I might make a gif explaining it or something
15:32 erle josiah_wi i'll wait with any concrete actions regarding testing until your stuff is merged. if it is not merged, there is simply not enough interest IMO.
15:41 josiah_wi At the moment I'm interested in figuring out what things are highest priority for increasing the project quality. I think testing is probably pretty low priority.
15:42 erle well, they are low priority, but that's a policy decision, not a technical one
15:42 erle IMO you don't get much better low-effort QA than having a bunch of automated tests
15:43 josiah_wi What long-term result are we expecting from having more automated tests?
15:43 erle i expect fearless refactoring
15:43 erle if a component is well-tested, you can be sure it behaves similarly
15:43 erle before and after a refactor
15:43 sfan5 so people stop accidentally breaking things
15:44 erle that's a different way to phrase it, yes
15:44 sfan5 (not necessarily during refactors)
15:44 erle true
15:44 sfan5 but irrlicht tests are indeed low-priority, most code is known to work and either 1) planned to be kept unmodified or 2) not planned to be refactored but rather be replaced entirely
15:45 josiah_wi That's fair. If we can implement the tests necessary (for Minetest) for that then maybe it's higher priority than I thought.
15:45 josiah_wi Are there areas of Minetest that aren't tested well?
15:46 sfan5 yes, almost everything
15:46 josiah_wi Yikes. Can we write those tests without restructuring anything? I'd be quite surprised if that's possible...
15:46 erle tests also make it easy to find more crashes through fuzzing the remains of irrlicht
15:47 sfan5 depends on which part
15:47 sfan5 for example the devtest unittests could be expanded greatly to test the interaction and functioning of large parts of lua_api.txt
15:48 nrz_ yeah devtest is one of the best addition we did to replace minimal, when we refactored the part to have some lua tests for new features. If i remember i started with some new functions and wuzzy followed and then everyone ❤️
15:48 josiah_wi If I'm seeing this right, paradust7 pulled in the Catch2 library recently.
15:49 erle wuzzy has many good ideas for testing, i suggest to ask wuzzy
15:49 nrz_ for the C++ part it's not so easy to test. our codebase is huge and the object separation is not sufficient to cover so much code
15:49 erle one of the funniest was “attach entities in circles like A → B → C → A”
15:51 erle there is a lot of low-hanging fruit though. about every function that processes coordinates for example.
15:54 josiah_wi Has there ever been a discussion of replacing Minetest's test runner with a framework? I can't find any issues about it, but it'd make it a lot easier to write tests.
15:55 sfan5 would it?
15:56 josiah_wi Good question. IIRC Minetest does have macros for doing assertions.
15:57 rubenwardy Self-registering tests are very nice
15:57 rubenwardy not that you need a framework for it https://blog.rubenwardy.com/2019/02/17/cpp-self-registering-test-macros/
15:57 rubenwardy the bigger reason would be IDE integration and report generation
15:58 rubenwardy and assert utils
15:58 rubenwardy might take a while though
15:59 josiah_wi Yes, I like the example outlined by Ruben. Self registering tests would be very convenient.
16:00 josiah_wi Report generation can be done by CTest and shouldn't depend too much on how the tests are set up internally.
16:00 erle there are some cases that need to be addressed by a test framework though
16:01 josiah_wi It looks like there's never been an issue opened to discuss using ctest.
16:01 erle for example, optimization-unstable code.
16:01 erle josiah_wi usually requirements come first (i.e. what we are doing now), are you sure you are not putting the cart before the horse?
16:02 josiah_wi Writing all the tests before deciding how to structure them would certainly be putting the cart before the horse.
16:02 erle rubenwardy i am a big fan of test frameworks being small and fitting a single header file
16:02 josiah_wi erle, have you seen doctest (for C++)?
16:05 erle josiah_wi i have looked it up just now. never heard of it before. i am a bit rusty on this kind of thing: i might have used µnit once, not sure.
16:06 erle no, i think it was minunit?
16:06 erle josiah_wi, basically this https://github.com/siu/minunit/blob/master/minunit.h
16:06 erle anyways, good luck!
16:10 josiah_wi joined #minetest-dev
16:12 erle josiah_wi you wrote “There's a lot of unnecessary media that I accidentally committed. I'll be removing that.” – are you aware of interactive rebase? you can remove them from the history entirely. if you add something in a commit and remove it later, it may still bloat the repository
16:12 sfan5 we don't do merges so that's irrelevant
16:13 josiah_wi git is hard. I goofed up quite a bit in that PR.
16:14 erle josiah_wi i wanted to point you to something that may help you to fix similar things in the future, not chastise you.
16:14 josiah_wi Yep, thank you!
16:20 josiah_wi Hey, we have some new warnings in master, one of which looks serious.
16:20 erle show and tell
16:20 josiah_wi There's a comparison in the serverpackethandler I think it was that is always false due to the range of the data type.
16:20 josiah_wi I may need to recompile to get a log.
16:22 sfan5 the code works as intended, it just so happens that the lowest support version is 0 which is also the lowest possible number
16:22 sfan5 +ed
16:23 josiah_wi Ah, shouldn't the warning be fixed?
16:24 sfan5 how?
16:26 josiah_wi By changing the data type? If that isn't a solution, then there should be a comment in the code. Maybe there is - I haven't found the line yet.
16:27 josiah_wi But wait, if the comparison is always false, then why have it at all?
16:28 sfan5 I will be useful in the future if the minimum version becomes > 0
16:28 sfan5 it*
16:30 josiah_wi There's probably a way to declare the minimum version so that the compiler understands it won't always be 0.
16:31 MTDiscord <Warr1024> Makes sense.  In real world project, "code" and "configuration" are not really separate things but exist on a continuum, and you choose a more or less arbitrary cutoff for what gets done in a code language and what is done in a config language, if you employ one.  A compiler can't tell the difference, though.
16:32 josiah_wi Ah, I see now.
16:33 josiah_wi What about the -Wmaybe-unititialized warnings in e.g. frame_length_ms, nodedef.cpp line 727?
16:34 erle i think such a warning is probably there because it ensures you take into account the dead code elimination will make the compiler emit no machine code for stuff that the compiler knows to be always true or always false
16:35 erle josiah_wi by “changing the type” you mean having an enum instead of a number, right?
16:35 fluxionary joined #minetest-dev
16:35 josiah_wi sfan5, Minetest master just segfaulted
16:35 josiah_wi I was trying to join YourLand server with a clean build.
16:36 josiah_wi erle, "changing the type" was due to a misunderstanding of the warning.
16:36 josiah_wi I see now that it can't really be avoided.
16:37 MTDiscord <Warr1024> Re: segfaults, it's a bit of a PITA to run MT under gdb, so generally you'd only do it if you're anticipating a crash, but there's this nice catchsegv program that you can just run it under always, and at least get some useful information out of unexpected/rare crashes.  I haven't seen a measurable performance impact.
16:38 josiah_wi Sounds good. I need to rebuild in Debug mode first anyways, and I should probably rebuild the Release build because I had a duplicate config that was causing some warnings.
16:43 josiah_wi Nevermind, those weren't due to the other config.
16:43 josiah_wi Some symbols are redefined in a few places.
16:44 josiah_wi Anyway, is the world creation menu not scaling to the resolution a bug?
16:45 josiah_wi Warr1024, this is not necessarily an "unexpected/rare" crash. It happens on singleplayer as well.
16:45 josiah_wi I assume I can reproduce this crash consistently with this build.
16:47 josiah_wi "0x0000555555cb9093 in irr::scene::COBJMeshFileLoader::cleanUp() ()
16:47 josiah_wi 0x0000555555cb9093 in irr::scene::COBJMeshFileLoader::cleanUp() ()
16:47 josiah_wi Whups, sent twice.
16:47 josiah_wi That's what gdb reports.
16:47 josiah_wi Perhaps I should rebuild IrrlichtMT.
17:01 erle josiah_wi depending on what kind of crash it is, you might get some very nice messages with ubsan or asan (though the latter makes the game unreasonably slow, so while it is useful for stuff like “crash during join”, i would not want it for much more)
17:13 josiah_wi Sorry, it works with irrlicht master.
17:20 sfan5 by the way you can use the "RelWithDebInfo" to get a release build but with debug symbols = meaningful backtraces
17:21 sfan5 and you can run gdb in batch mode to automatically generate a backtrace upon crash but not interfere with program execution otherwise
17:26 josiah_wi Excellent.
17:27 josiah_wi Would it be helpful for me to submit a PR to fix a bunch of these warnings? Is someone else already doing it?
17:29 sfan5 sounds good
17:32 sfan5 don't bother with the one in src/server.cpp, a future commit by me will fix it anyway
17:52 Zughy[m] should Devtest related issues be subject to the "Roadmap" approval rule? Like #12307
17:52 ShadowBot https://github.com/minetest/minetest/issues/12307 -- DevTest: Add item meta editor by Wuzzy2
17:53 Zughy[m] Also, "Devtest game" could be a component of its own ("@ Devtest game")
17:53 Zughy[m] *on
17:57 rubenwardy It probably comes under maintenance/code quality
17:57 rubenwardy And yeah, it should be @
17:58 Zughy[m] yeah, almost every issue/PR with "Devtest game" has no other component, that's why I said that
18:04 josiah_wi I did fix the -Wtype-limits warning: the cleanest solution I could find was to define a constexpr function that simply returns the constant.
18:08 erle i think devtest would work much better on cdb tbh
18:09 erle rubenwardy i have a mod dependency riddle: why does my mod mcl_lever_status_indicator lead to installing doors?
18:10 erle rubenwardy oh i figured it out just now, it depends on mesecons_wallleve, which is provided by mcl5 but also by mesecons, but the mesecons draws in doors lol
18:10 erle mesecons_walllever
18:10 erle rubenwardy do you think minetest should maybe evaluate the dependencies for download differently, if the base game selected already has them? or did i do something wrong maybe?
18:16 rubenwardy Already does
18:27 Krock will merge #12270 #12241 #12239 and game#2951 in 15 minutes
18:27 ShadowBot https://github.com/minetest/minetest_game/issues/2951 -- Carts: Improve movement behaviour by SmallJoker
18:27 ShadowBot https://github.com/minetest/minetest/issues/12270 -- HUD: Update selection mesh every frame by appgurueu
18:27 ShadowBot https://github.com/minetest/minetest/issues/12241 -- Fix Minetest blaming the wrong mod for errors by appgurueu
18:27 ShadowBot https://github.com/minetest/minetest/issues/12239 -- Docs: Recommend `entity.name` by appgurueu
18:41 Krock merging
18:44 Krock done
19:19 sfan5 merging #12274
19:19 ShadowBot https://github.com/minetest/minetest/issues/12274 -- Add more Prometheus metrics by sfan5
19:24 rubenwardy Are there any plans to add more benchmarks? Having e2e stress tests for block emerging would be useful
19:25 rubenwardy Although I can see that being painful to set up
19:26 sfan5 you want to test mapgen or just how long it takes from a disk read to the client in general
19:26 sfan5 ?
19:26 rubenwardy Haven't thought about it that much tbh
19:29 erle rubenwardy emerge stress tests, you mean like mcl_engine_workarounds? https://git.minetest.land/Mineclonia/Mineclonia/src/branch/master/mods/MISC/mcl_engine_workarounds/init.lua#L141
19:30 erle you can easily modify the loop there to emerge more stuff (i.e. let it take longer)
19:53 erle rubenwardy amazing news: if you modify mcl_engine_workarounds just a little bit, i think you can trick minetest into running an emerge callback forever
19:53 erle rubenwardy, you just need to give it a minpos with x=32767
19:55 erle then minetest will do nothing except try to emerge this thing, fail at it, then try to do it again. possibly several times a second.
19:57 erle tested with commit a66e6d4df
19:57 erle i hope this is enough stress testing for you :)
20:03 rubenwardy just for context, I was thinking about more things to add to https://www.minetest.net/benchmarks/dev/bench/
20:08 josiah_wi :q
20:08 josiah_wi Whups, pretend you did not see that.
21:00 rubenwardy Isn't "No core dev support long term" kinda redundant given "Won't add" and "Won't fix"
21:00 rubenwardy last used 2020-09-10.  Delete?
21:00 rubenwardy also only on closed issues
21:01 erle rubenwardy i guess a WONTDO file would be a better idea. but why remove it?
21:01 erle it sounds broader than a WONTFIX
21:02 erle also if you remove it wouldn't you need to tag all the issues it was used for as WONTFIX
21:02 rubenwardy removing unnecessary labels is good
21:02 rubenwardy GH has some bulk functionality
21:02 rubenwardy won't add and won't fix can probably be merged
21:28 erle rubenwardy any issues with me submitting mods to CDB that a) trigger engine crashes b) apply workarounds for those, mainly checking arguments? i think that's the easiest way to get engine updates to older versions of minetest.
21:28 erle i was thinking of two modpacks, one that you can use to check if your engine version crashes, then the other you install to make it not crash anymore.
21:36 sfan5 the simplest way to get engine updates is to update
21:41 erle i think you have extremely unrealistic expectations about what kind of update a typical user is going to do
21:41 erle laste i checked, there were *still* people complaing that mineclone5 does not run with minetest 5.3
21:41 erle on their raspi or something
21:45 sfan5 and why is that? is it because users do not want to update?
21:50 erle since minetest has not suddenly increased any HW requirements, my suspicion is that their distribution is not remotely up to date
21:50 erle but given that ubuntu LTS users will be on minetest 5.4.1 for the forseeable future, i doubt this will change much
22:21 beanzilla joined #minetest-dev
22:23 Zughy[m] rubenwardy: "No core dev support long term" sounds redundant indeed
22:25 Zughy[m] The other two, heh, I guess there is a difference as for the current names, but maybe another name can be found to represent both and remove one of them
22:27 Zughy[m] also, "Incompatible change" was last used in 2015
22:30 MTDiscord <Warr1024> My understanding of "no core dev support long term" is that it basically means "probably won't fix but I'm not willing to like commit to that."  Seems reasonable to remove it since leaving things in a non-committal state is sort of a thing the new triage system is supposed to get rid of, right?
22:34 panwolfram joined #minetest-dev
23:07 AliasAlreadyTake joined #minetest-dev
23:29 Pexin the impression I got when I ran into ncdslt was, "it might be a neat addition, but will require a coredev to care enough to be sufficiently familiar with its complexity for - in this case - obviously inevitable refactoring later"
23:30 Pexin or more briefly "I *kinda* like it, but I don't want to get stuck maintaining it"
23:31 MTDiscord <Warr1024> Haha, I thought that was the criteria for "one approval" :-)
23:31 rubenwardy ncdslt?
23:32 MTDiscord <Warr1024> ncdslt.
23:34 rubenwardy oh the tag
23:34 rubenwardy maybe say "the label"
23:35 Pexin the cumbersome length of The Tag may itself be an indicator it should be dropped   :]

| Channels | #minetest-dev index | Today | | Google Search | Plaintext