Time Nick Message 09:03 MTDiscord The minetestdevs PPA seems to have been broken somehow? apt install minetest leaves me with 202103092118+5.4.0+13b50f55a-ppa~ubuntu20.04.1 as the newest version (which claims to be 5.5-dev in it's title despite having 5.4 in it's APT version string). It seems MT hasn't been built since march? 09:18 sfan5 yeah we don't suggest using it anymore 09:23 MTDiscord What should be used instead? 09:27 sfan5 for the average user probably the AppImages built by the gitlab pipeline 09:59 MTDiscord And for the average apt fan? 10:00 erlehmann bully debian devs into upgrading? 10:01 erlehmann they will probably absolutely hate the irrlicht situation 10:01 MTDiscord I suck at bullying 10:01 erlehmann but it was good until mt 5.4.1 right? 10:01 MTDiscord yep 10:02 erlehmann well than that will be the next long term targeted version once 5.3 usage goes away i guess 10:02 erlehmann luatic you could probably file a bug on the package or offer your help 10:02 erlehmann i must admit i do not know myself what the issue is 10:20 sfan5 the PPA is "maintained" by us, not debian devs 10:25 erlehmann sfan5 yeah but it is only necessary bc debian devs stay on 5.3 ig? 10:27 sfan5 it's more that debian takes a version when they release their OS and never upgrade 10:28 sfan5 though there's backports these days(?) 10:28 sfan5 being slow to update is another thing, but debian has 5.4.1 in 'unstable' now 10:28 erlehmann ah 10:28 erlehmann good 10:30 sfan5 @luatic actually, were you looking to install a stable version or 5.5-dev? 10:30 sfan5 what I said is for the latter 10:31 sfan5 for stable literally follow the download page: flatpak/snap (preferred) or your distro package 10:31 MTDiscord I was looking for 5.5-dev 10:32 MTDiscord Would something like make install work? 10:34 sfan5 sure it would 10:34 sfan5 you'll have fun manually removing leftover files when you want to uninstall or upgrade MT then 10:47 MTDiscord Alright. Entirely different question: Does entity staticdata get compressed with other mapblock data? 10:50 sfan5 5.5: yes, 5.4 and below: no 13:20 MTDiscord erlehmann: I have a polyfill for minetest.encode_png using pure Lua + minetest.compress :) 13:25 erlehmann luatic the PNG encoder in minetest is abysmal though 13:26 erlehmann if it is really about size, minetest should use libpng and preserve TGA support (as it is more efficient for very small textures <16×16) 13:27 erlehmann (or can be more efficient, it really depends on the texture – the map images are too big) 13:27 erlehmann luatic nevertheless, i appreciate it! 13:28 MTDiscord "too big"? 13:29 erlehmann from my experiments i remember that above about 16x16 image dimensions a TGA image will basically never beat a PNG, below the PNG overhead is big enough that RLE TGA is the better option (easy test: try an image with all the same color and encode it) 13:31 erlehmann luatic my guess is that you can manage to make an RLE TGA encoder, you'll probably either figure out why PNG loses if your picture is less than about 100 bytes or find an error i my judgement 13:31 MTDiscord well, I assume PNG has more overhead 13:31 MTDiscord 8 bytes signature 13:31 MTDiscord 13 bytes IHDR 13:31 MTDiscord CRC checksum per chunk 13:31 MTDiscord IEND chunk 13:32 MTDiscord all of those aren't strictly necessary 13:32 MTDiscord but do those couple bytes really matter? 13:33 erlehmann if you want to have the strictly smallest filesize, yes. since hecks and sfan5 argued that TGA can never beat PNG, i guess it plays a role? in real terms ofc, TGA will need to be supported forever if people figure out that you can actually get small filesizes. 13:34 MTDiscord but why do you need the "strictly smallest filesize"? 13:35 erlehmann no idea, but some ppl are obsessed with it. honestly, it does not matter. 13:36 erlehmann it is just the same situation as with “stuff all the stuff in sqlite to have a better filesystem”, ppl have one benchmark in mind that is not their actual use case and then try to extrapolate from that 13:37 erlehmann whereas you have to benchmark the actual case that you have in the code to be able to accurately judge it 13:37 erlehmann for example, i only considered reading speed of NTFS in dirs with many files, but what sfan5 wrote about zip extraction makes sense! 13:38 erlehmann like, my prototypical use case is different than his (and both is not the same as what actually is important) 13:38 erlehmann luatic where is your encoder though? 13:38 MTDiscord stuffing it into modlib right now 13:39 erlehmann yeah, stuff the stuff in the stuff! 13:39 erlehmann luatic do you need a review? 13:40 MTDiscord I don't "need" one, but I'd sure like one! https://github.com/appgurueu/modlib/commit/578d5045754d67f900b8edc2ee63da8efc968022 13:41 erlehmann not now though 13:41 erlehmann i have to work 13:43 erlehmann luatic how do you handle gamma? 13:44 erlehmann luatic test coverage of this code is 0%, so this does not pass my review (not a joke, in case you think that) 13:45 erlehmann luatic really i am interested in the gamma thing. what is the rendering intent? 13:50 MTDiscord when are we getting an in-game unit testing framework in modlib? :P 13:50 MTDiscord erlehmann: there are indeed no automated tests ATM 13:51 MTDiscord but I did do exactly three manual ones 13:51 MTDiscord I don't handle gamma. It's literally just compressed RGBA data. 13:51 MTDiscord The rendering intent is screen RGB you could say. 13:54 erlehmann luatic i suggest to add automated tests that prove that it is exactly as good (or, arguably, bad) as the current minetest implementation 13:54 erlehmann like just use the devtest images as input, assert you get the same output 13:54 MTDiscord Indeed, I could compare it against that quite easily 13:54 erlehmann for differences, investigate 13:54 erlehmann but do not use the actual API, hardcode the images 13:54 erlehmann the test vectors i mean 13:55 MTDiscord Hmm 13:55 MTDiscord I actually haven't looked at the MT's implementation yet, so I wonder whether the output will actually be equal... 13:56 erlehmann it is a naive implementation, so it will probably be largely the same? no idea really 13:57 erlehmann honestly, i am just the devil on your shoulder reminding you that you have not tested your code well enough to be sure 13:57 MTDiscord it apparently is the same 13:57 erlehmann and i only looked into it enough to figure out that whoever wrote it does not really “get” what makes PNG so good 13:58 erlehmann like some of the test textures are *way* too big 13:58 MTDiscord they presumably do "get" it, but it's not worth the effort really 13:58 erlehmann you can use optipng on them or pngcrush 13:58 erlehmann in this case it actually is 13:59 erlehmann i think the checkerboard texture was a good example 13:59 erlehmann run that one through optipng or pngcrush and see 13:59 MTDiscord Hmm, I don't support the byte string yet. I should fix that. 13:59 sfan5 there you go again accusing people of not knowing what they're doing 13:59 erlehmann sfan5 no, not caring 14:00 MTDiscord the checkerboard would probably be represented best using a palette 14:00 erlehmann i think “you don't care enough to make a complex implementation” is not an insult as much as “you stupid lol” 14:00 MTDiscord erlehmann, if you can improve it do so. 14:00 erlehmann and it is entirely understandable to not want to care about PNG complexities 14:01 erlehmann strangely enough, the naive encoder actually does better than gimp at saving some of the things 14:01 sfan5 "whoever wrote it does not understand PNG (enough)" is literally what you said 14:01 sfan5 if it isn't what you mean don't write it 14:01 MTDiscord sigh, I should put more work into webp so this whole conversation can be done, it would be smaller than TGA, PNG, etc for 15x16 images 14:01 sfan5 I doubt webp helps here 14:01 erlehmann sfan5, oh i thought you meant the ”does not really “get” what makes PNG so good” part 14:02 sfan5 yes exactly that part 14:02 erlehmann i think especially in programming people can understand how mechanically stuff works, but they don't “get” it 14:02 erlehmann take PNG filters 14:02 erlehmann it is just not obvious why they are so good 14:02 MTDiscord sorry, I figured th conversation was still about how TGA or something was dropped from our support 14:02 erlehmann even if you go through all of them 14:03 erlehmann mechanically 14:03 erlehmann or maybe it is to you 14:03 erlehmann sfan5 i promise to be more accurate with my critcism, but for example defaulting to RGBA just wastes a bunch of bits 14:03 erlehmann if you never have transparency 14:04 sfan5 it does and so does not using a palette or any filters 14:04 MTDiscord There are times when it is wise to stay silent. People will weary of you "getting" everything they apparently don't, and telling them to fix it. 14:04 sfan5 these are known and intentional limitations 14:04 sfan5 @exe_virus no it was relevant, but I doubt that webp files are any smaller at that size 14:04 erlehmann josiah_wi i don't “get” it either. i am much better. 14:04 erlehmann sfan5 this will have to be benchmarked, of course. 14:05 erlehmann josiah_wi i don't “get” it either. i am much better at pointing out whats wrong than how to do it right. 14:05 erlehmann sorry 14:05 erlehmann lol 14:05 erlehmann the previous comment, courtesy of a brainfart 14:05 erlehmann i apologize, i am much worse! 14:06 erlehmann what i want to say, i literally can't write you a better PNG encoder right now, i can just tell you the one there is low-effort. also, people seem to not take my takes literally, so i need to be more careful. 14:06 erlehmann for example, hecks understood low-effort as low-quality. 14:06 erlehmann but that is orthogonal to each other 14:07 MTDiscord Yeah, what you'll learn is that pointing out what's wrong isn't helpful. It's figuring out how to do things right that moves things forward and gets people excited. 14:07 erlehmann i work in IT security, so my entire job is pointing out what is wrong (or figuring out nothing is) 14:08 erlehmann maybe that changes how you see my comments on code quality, it certainly did in mcl2 14:08 erlehmann pointing out what is wrong often helps people to figure out what is right 14:09 erlehmann like i bet if luatic has tests the implementation will magically improve bc of the results if it has any bugs 14:09 MTDiscord Yes it very much is smaller sfan5, take MTG's already optipng compressed default_acacia_bush_sapling.png, it's 151 Bytes. In webp lossless, it's 102 bytes. 14:10 sfan5 huh 14:10 MTDiscord hence my desire to get it into our engine haha 14:10 MTDiscord but as always, time is a constraint.... 14:11 erlehmann sfan5 that is what i mean with not “getting” it. you are not dumb, but your intuitions do not line up with the benchmark, even though you probably *know* how webp works. 14:11 MTDiscord I could give it a shot, but I haven't worked with image stuff ever before so I will 100% not "get" what I'm doing. 14:11 erlehmann i also did not “get” it 14:11 erlehmann i thought webp would barely make a difference 14:12 erlehmann sfan5, i hope you are not insulted, did i make myself clear now? 14:14 erlehmann (i do not wish to go around hurling insults by accident) 14:22 sfan5 erlehmann: I don't know how webp lossless works so that was just a guess 14:23 sfan5 ..based on 16*16 not being a lot of bytes and with a palette and zlib already there the optimization potential is tight 14:24 erlehmann luatic btw, regarding small filesize differences, if you save default_cloud.png as TGA using gimp, it goes from 83 to 79 bytes. that is not enough to justify converting stuff to TGA, but anyone who will tell me PNG is “more efficient” or TGA is bad enough to be deprecated will definitely get at least some eyeroll (or snarky comment) from me. 14:25 MTDiscord Usually the worst case is considered when talking about efficiency 14:25 MTDiscord Or at least the average case 14:25 MTDiscord But rarely the best case 14:26 erlehmann well in this case you have the unusual circumstance that what is worse for almost all typical use cases may be about the same for small pixel art, of which minetest has a lot 14:26 MTDiscord Anyways, totally different topic: The client should be managing HUD elements in a (sorted) map with z-index as key. 14:26 sfan5 submit a PR 14:27 sfan5 and rewrite the rest of the code too so it can keep state for each HUD element 14:27 sfan5 or rather s/rewrite/refactor/ 14:27 erlehmann luatic as said before, the thing i want to point out is mostly that everyone who talks about stuff being better or worse needs to consider the actual use case, not whatever random benchmark they have in mind. 14:27 MTDiscord A multi-map actually 14:27 erlehmann but i am repeating myself, so i shut my mouth for a while now 14:35 erlehmann luatic oh btw, if you want to figure out how good/bad the included PNG encoder is, try re-encoding default_chest_inside.png and see how it blows up 14:37 erlehmann i think it is a good test case, also to show how bad formats can be (re-encoding the file it as a TGA makes it 4 times the size for example, i guess a bad PNG encoder will manage to do similar stuff) 15:24 jonadab That's interesting. The smallest I can make it is 40 bytes larger than the original. 15:43 definitely_a Hello, I found out there is no simple textures for pine needles and aspen leaves, it just renders the new no_texture.png node. :P 15:44 sfan5 this used to work, please open a bug 15:45 definitely_a I have no Github account, could a dev open an issue please? Thanks a lot! 15:46 definitely_a I believe it's just those two nodes. 15:48 sfan5 ah sure 16:31 erlehmann That's interesting. The smallest I can make it is 40 bytes larger than the original. 16:31 erlehmann jonadab using which tool? 16:32 erlehmann jonadab did you use “optipng -o7 -strip all” ? 16:33 rubenwardy ./util/bump_release.sh fails when going from 5.4.1 -> 5.4.2 16:33 rubenwardy it tries to release 5.4.1 again 17:11 jonadab erlehmann: Hmm, I was using pngcrush (via a script I had previously written). 17:11 jonadab After exporting from Gimp.l 17:12 jonadab Was not aware of optipng. 17:13 jonadab The reason I started using pngcrush, is actually not for size optimization, but to remove certain kinds of information that recent versions of Gecko flagrantly mis-interpret. 17:13 jonadab And by recent, I mean since version 3.something. 17:14 jonadab Err, since _Firefox_ version 3.something. 17:15 erlehmann jonadab tell me more about it pls 17:19 jonadab erlehmann: Basically, images generated by normal image editing software (such as Gimp) usually contain stock meta-information that's technically optional. If it's there, Gecko significantly darkens the image. I have not found *any* other software that does this, only Gecko. 17:19 jonadab The good news is that pngcrush can remove the metadata, and they aren't actually _needed_ for anything. 17:21 jonadab erlehmann: I wrote it up with screenshots here: http://mistersanity.blogspot.com/2011/06/firefox-why-i-refuse-to-upgrade.html?m=1 17:26 erlehmann jonadab do you have a ff bug to point to? 17:26 jonadab erlehmann: I think I did at one time? But it was years ago and I don't remember now. 17:26 erlehmann they sometimes fix bugs after years 17:26 jonadab I stopped using Firefox a year or two after writing up that post. 17:27 jonadab Yes, it's vaguely possible that that bug may have been fixed at some point, but if so I'm not aware of it. 17:28 jonadab It hadn't been fixed last time I checked, which was a couple of years after it started happening. 17:28 jonadab But that was a while ago now. 17:31 erlehmann https://bugzilla.mozilla.org/show_bug.cgi?id=440093 17:31 erlehmann > Closed Bug 440093 Opened 14 years ago Closed 10 years ago 17:31 erlehmann hahaha 17:36 jonadab Yeah, that one I *knew* when they fixed, because I was still tracking it at that point. 17:38 jonadab Figuring out what was going on with that one, is one of the biggest software nightmares I've ever experienced. 17:47 Fixer welcome back erlehmann 20:26 MTDiscord Did we axe all the unit tests from Irrlicht? Now I want to implement unit tests for WebP, and I look to see how to do it properly and poof, there are no unit tests. 20:40 MTDiscord I'm thinking I can get some of the itty gritty stuff out of the way; build settings (if any), compiler definitions, function stubs etc. and I was hoping I could test whatever I write. 20:47 erlehmann > Did we axe all the unit tests from Irrlicht? 20:47 erlehmann hecktest noticed that the reckless removals broke stuff 20:47 erlehmann so instead of fixing the tests, the tests were removed 20:47 erlehmann i still think it is dishonest to imagine anyone reviewed that PR that removed all that stuff 20:48 erlehmann i also used the unit tests and found out e.g. how broken software rendering is on irrlicht lol 20:49 erlehmann josiah_wi i think you can still build minetest with old irrlicht? 20:49 sfan5 I am repeating myself: nobody knew how to run the test, to which extent they worked and how much they relied on features that we were removing 20:50 sfan5 tests* 20:50 erlehmann a friend once tried out linux and i think he deleted /usr or /lib bc it was just cluttering the disk and why was it there anyway 20:51 erlehmann i am aware that irrlicht is deeply broken btw sfan5 20:51 erlehmann the tests revealed it 20:51 erlehmann but that's kinda why they are useful 20:51 sfan5 so you did get them to run? 20:52 erlehmann let me look up what i did 20:52 erlehmann remember the thing where i reported a bunch of crashing textures? i used some of the code that hecks deleted and instrumented it and modified it to use afl to compile 20:52 erlehmann but i did it without a plan 20:52 erlehmann so i have to look at it 20:53 erlehmann brb 20:55 sfan5 just to be clear I am talking about the former tests/ folder, examples/ does and did not contain tests 20:59 MTDiscord I would have gladly taken the time to set up CMake to run the tests. 21:00 MTDiscord Now that the tests are gone, and I am significantly busier than I was, this isn't as appealing to me. 21:02 MTDiscord So now I have to ask. Should I implement unit tests at all? How should I test my code? I could create a new example - I already have a branch with a working example - but that would be most convenient for demonstrating full functionality, which I may not necessarily implement. 21:04 MTDiscord I could also go back in the git history, revive the unit tests, fix or disable all the broken tests, and then write new ones. Or I could just write some little scripts, maybe using the examples mechanism, to do some simple one-time testing and assume it's good. 21:05 MTDiscord Actually, erlehmann could help me revive the unit tests. It seems like it's related to his area of expertise. 21:06 erlehmann my area of expertise is literally complaining, but yeah i also write test cases for money 21:06 erlehmann so i am prob a professional in some way lol 21:06 erlehmann so i got back to an earlier revision 21:06 erlehmann and typed "make" in the tests directory 21:07 erlehmann now i have a bunch of compiled files 21:07 erlehmann lets see 21:07 erlehmann (it is easier to figure it out that way than to dissect my fuzzing setup) 21:07 MTDiscord Do you happen to know the commit ref of the last revision with the unit tests intact? If not I should be able to find it. 21:08 erlehmann 1.9.0mt2 has them i think 21:10 MTDiscord Ah, the version tags! That should work; I just need to remember how to shuffle directories across commit refs. xD 21:12 MTDiscord Ah yes, git checkout with the -p option. 21:16 MTDiscord I'm running a very large update on my dev workstation at < 1mpbs so it may be a long time before I'm ready to mess around with this... 21:17 erlehmann huh the git history of irrlichtmt is rather short 21:17 erlehmann botched import? 21:18 MTDiscord In fact I don't even need the -p option. What do you mean by botched import? 21:25 erlehmann botched import of irrlicht version history? 21:26 MTDiscord i'm pretty sure the only thing botched is irrlicht itself 21:29 MTDiscord Oh, you're suggesting that git revisions were lost in the import? I noticed that there is a changelog in the repo, so if necessary that could serve as a version history. Not a very good one maybe, but it's better than nothing. 21:30 MTDiscord C++ is botched too 21:30 MTDiscord The grass is always greener on the other side of the fence. 21:32 MTDiscord its also greener where the septic tank is 21:33 MTDiscord Thanks, that made me smile. ? 21:43 erlehmann sfan5 josiah_wi so to compile the tests you have to type „make“ in the tests directory, i tried it in 1.9.0mt2. it will complain about a single variable named MAX_TEXTURES_USED which is somehow not in scope somewhere, which is why i would like to have a git history 21:43 erlehmann if you fix it, it compiles the the tests 21:43 erlehmann my conclusion, no one ever tried to understand the error message, deleting all of it is more satisfying (in a way) 21:44 erlehmann i botched it by just using MAX_TEXTURES where it was in scope 21:44 erlehmann this is probably horribly wrong 21:44 erlehmann but it does compile 21:44 erlehmann predictably, the tests do not pass 21:44 erlehmann in fact, test 4 gives me a segfault :D 21:45 erlehmann so yeah, if someone knows how to get MAX_TEXTURES_USED in scope in the tests thing, you have tests 21:45 erlehmann i'll try to figure out why it segfaults 22:07 erlehmann oh i am reminded again why i hate cmake and make 22:07 erlehmann i can spot the broken deps by now 22:07 erlehmann cmake is kinda patching over the problems of make in a way 22:07 erlehmann (not relevant to most or all of you ig) 22:15 erlehmann ok, so predictably, my changes have broken the tests 22:15 erlehmann who would have known 22:27 erlehmann yeah so i got the test cases to run on 1.9.0mt0 22:27 erlehmann using clang++ 22:29 erlehmann sadly i can't just make a PR with a shell script that compiles and runs them because they were removed, so i guess we'll wait until someone reverts the commit that did it 22:29 erlehmann in a less snarky tone, anyone planning to bring the test cases back by git revert? 22:29 erlehmann i can't make them not fail, but i can make them compile 22:30 erlehmann i'll now try to figure out if the tests were actually not compiling bc they were broken 22:30 erlehmann josiah_wi take note 22:34 MTDiscord erlehmann, I'm bringing the tests back by re-adding them in a new branch. I've actually already done this, just now. 22:34 MTDiscord I think before we work on fixing test cases, we should get it integrated with our CMake build system. 22:36 erlehmann yeah no idea how to do that 22:36 erlehmann and also i think it is probably a bad idea, but i have actually written a build system so i may be a bit biased 22:36 erlehmann just do it, do you need my help for that? 22:37 erlehmann like can i give you pointers somewhere how to make it compile or did i write enough 22:37 MTDiscord If I need any assistance I will let you know right away. 22:37 erlehmann josiah_wi could you actually keep the history of the tests in some way? 22:37 erlehmann ok! 22:37 erlehmann i am happy we'll have tests 22:38 erlehmann in the mantime, i will try to figure out what broke 22:38 MTDiscord The history of the tests that already exists will stay there. 22:41 erlehmann can you somehow keep the shitty giant commit out of it via branch rewriting? 22:41 erlehmann it breaks so much tooling 22:41 erlehmann like no one expects a commit that big 22:41 erlehmann gitg for example just crashes 22:41 erlehmann and git log is pretty unusable 22:42 erlehmann i have no idea how to do that though 22:44 MTDiscord I don't either. 22:57 erlehmann honestly, can someone just rewrite the branch and force heck to remove piecs in human-digestible commits with actual discussion 22:57 erlehmann pieces 22:57 MTDiscord erlehmann, for now I put the entire thing in a single test. I haven't run tests with CMake before, so I'm going to play around a bit and figure out whether I should split them up into seperate tests. 22:58 erlehmann like the more i think about it the more it seems like this will pop up over and over again precisely because it guts stuff without understanding why it was there (and yes, i get it, minetest is not using the vast majority of it, but it is not hurting anyone, or is it?) 22:58 MTDiscord I am building the tests with the same default options specified in the old Makefile (-wall, -ansi, -pedantic, -fno-exceptions) 22:58 erlehmann josiah_wi it builds a single test binary by default, yes 22:58 erlehmann that is certainly suboptimal 22:59 erlehmann no idea what cmake does there 22:59 erlehmann but the makefile spits out a bin/Linux/tests binary 22:59 MTDiscord Ok! We've got myriads of compile errors! 23:00 erlehmann wdym 23:00 erlehmann myriads? 23:00 erlehmann do you have a functional binary like me? 23:01 erlehmann or do you mean ubsan vptr complaints? 23:01 erlehmann where it comes to you at runtime 23:01 erlehmann to tell you that the code does not compile 23:01 MTDiscord I mean I have a whole screen full of compile errors about missing members and undeclared variables. Which is expected, since hecks axed so much. 23:01 erlehmann oh that one 23:01 erlehmann you are not going back to an old revision like me 23:01 erlehmann gooooood luck ig 23:01 MTDiscord Right, I'm re-adding the tests to the new revision. Otherwise they won't be useful. 23:02 MTDiscord wdym good luck, either you stop complaining or you help me fix this, buddy. xD 23:02 erlehmann honestly, i doubt that thing is fixable without a “let's only tear down fences when you know why they were built” work ethic 23:02 erlehmann with good luck i mean it seems like a very hard task 23:02 erlehmann to fix it 23:03 erlehmann i just realized that 23:03 erlehmann like basically to make the tests run you need to bring back all code that they covered 23:03 erlehmann then you can start poking at it 23:03 MTDiscord Right. ? I'm willing to work on it though. If we start by disabling all the tests and then re-enable the ones you think are most important and get them working, we'll be getting somewhere. 23:04 MTDiscord And we can have working tests to show for it at each stage. 23:04 erlehmann well the point is some already don't work in the first place 23:04 erlehmann even without any gutting of the library 23:04 erlehmann i'd rather have it working first, then remove or change stuff 23:05 MTDiscord It would technically "work" if we disabled all the tests. 23:05 erlehmann bc obviously the workflow where ppl randomly delete code they think is useless is making a LOT more work than it saves 23:05 erlehmann yeah lol 23:05 erlehmann ofc that is why hecks deleted them 23:05 erlehmann easier than making them pass ig 23:06 erlehmann i'll try to figure out what is legit broken from the start now 23:06 erlehmann do you have *any* test that passs? 23:06 MTDiscord Oh wow. There's a test that's indented with spaces instead of tabs. 23:06 erlehmann passes 23:06 MTDiscord Someone didn't do code review hahaha. 23:07 erlehmann there is at least 2 kinds of reactions to this 23:07 erlehmann one is trying to clean it up 23:07 erlehmann the other is trying to make a bigger mess xD 23:08 erlehmann but yeah, this thing is cursed 23:08 MTDiscord I'm going to at least get this to a point where people can actually make unit tests. 23:09 MTDiscord And because this is something in your area of expertise it's something I imagine you could create solutions to instead of just opening issues all the time. 23:11 erlehmann i can def make regression tests if you give me a skeleton 23:11 erlehmann would be good for making mapgen predictable 23:12 MTDiscord undefined reference to symbol dlclose@@GLIBC_2.2.5 23:12 MTDiscord DSO missing from command line 23:12 MTDiscord Looks like I botched something hehe. 23:12 MTDiscord I have just the 1 initial test enabled, and everything else commented out. 23:19 MTDiscord I need to eat, then I will work on resolving this. Maybe there's a library I need to link. 23:21 erlehmann i am correcting myelf, i am at 1.9.0mt1 the whole time 23:30 MTDiscord Oh. Well, the tests shouldn't have changed too much between those versions, I hope. 23:32 erlehmann i am trying to figure out what else the xml removal broke 23:32 erlehmann i bet some random thing besides fonts depended on it 23:32 erlehmann seriously, i think there should be mandatory code reviews 23:33 erlehmann the tests do not help *much* there bc they are already pretty broken from the start 23:33 erlehmann which makes me wonder, how did that thing ever work 23:33 erlehmann so i have to compile the lib twice 23:33 erlehmann then diff the test binary output 23:34 erlehmann and suppress the vptr complaints 23:34 erlehmann that should do it 23:34 erlehmann sadly it takes forever 23:49 pgimeno the tests do not help *much* there bc they are already pretty broken from the start <-- maybe that's why they were removed? 23:52 erlehmann pgimeno i doubt it 23:53 erlehmann pgimeno, IIRC hecks explicitly stated that they would not put effort in fixing them. also, tests that previously passed, were removed as well. 23:53 erlehmann i have seen no evidence that anyone there tried to discern the wheat from the chaff, so to speak 23:55 erlehmann again, i think the single “let's delete the parts of irrlicht we probably don't use” PR was a collosal mistake and should not only not have been done, but should be undone, so the features that are removed are removed in a structured way, like sfan5 disabled the software renderer or something like that. 23:56 erlehmann whenever something is more than a “git revert $commit” away, it is insanely hard to untangle that 23:56 erlehmann i am not saying it is malicious, but it is creating a lot of work 23:58 erlehmann and so far nothing i have seen has even remotely justified that level of breakage 23:59 erlehmann honestly, if it had not happened, i would not be here even, lol