| 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 :] |
