Minetest logo

IRC log for #minetest-dev, 2021-10-21

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

All times shown according to UTC.

Time Nick Message
00:07 proller joined #minetest-dev
01:42 v-rob joined #minetest-dev
02:28 queria^clone joined #minetest-dev
02:34 queria^clone joined #minetest-dev
02:45 v-rob joined #minetest-dev
03:46 specing joined #minetest-dev
03:51 v-rob joined #minetest-dev
04:00 MTDiscord joined #minetest-dev
05:12 tekakutli joined #minetest-dev
07:51 MTDiscord joined #minetest-dev
08:10 hendursa1 joined #minetest-dev
09:03 MTDiscord <luatic> 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 <luatic> What should be used instead?
09:27 sfan5 for the average user probably the AppImages built by the gitlab pipeline
09:56 v-rob joined #minetest-dev
09:59 MTDiscord <luatic> 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 <luatic> I suck at bullying
10:01 erlehmann but it was good until mt 5.4.1 right?
10:01 MTDiscord <luatic> 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 <luatic> I was looking for 5.5-dev
10:32 MTDiscord <luatic> 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:41 olliy joined #minetest-dev
10:47 MTDiscord <luatic> Alright. Entirely different question: Does entity staticdata get compressed with other mapblock data?
10:50 sfan5 5.5: yes, 5.4 and below: no
11:12 calcul0n_ joined #minetest-dev
13:15 proller joined #minetest-dev
13:20 MTDiscord <luatic> 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 <luatic> "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 <luatic> well, I assume PNG has more overhead
13:31 MTDiscord <luatic> 8 bytes signature
13:31 MTDiscord <luatic> 13 bytes IHDR
13:31 MTDiscord <luatic> CRC checksum per chunk
13:31 MTDiscord <luatic> IEND chunk
13:32 MTDiscord <luatic> all of those aren't strictly necessary
13:32 MTDiscord <luatic> 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 <luatic> 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 <luatic> 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 <luatic> 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 <Sublayer plank> when are we getting an in-game unit testing framework in modlib? :P
13:50 MTDiscord <luatic> erlehmann: there are indeed no automated tests ATM
13:51 MTDiscord <luatic> but I did do exactly three manual ones
13:51 MTDiscord <luatic> I don't handle gamma. It's literally just compressed RGBA data.
13:51 MTDiscord <luatic> 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 <luatic> 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 <luatic> Hmm
13:55 calcul0n__ joined #minetest-dev
13:55 MTDiscord <luatic> 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 <luatic> 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 <luatic> 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 <luatic> 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 <luatic> 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 <josiah_wi> 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 <exe_virus> 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 <exe_virus> 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 <josiah_wi> 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 <josiah_wi> 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 <exe_virus> 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 <exe_virus> hence my desire to get it into our engine haha
14:10 MTDiscord <exe_virus> 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 <josiah_wi> 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:22 appguru joined #minetest-dev
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 <luatic> Usually the worst case is considered when talking about efficiency
14:25 MTDiscord <luatic> Or at least the average case
14:25 MTDiscord <luatic> 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 <luatic> 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 <luatic> A multi-map actually
14:27 erlehmann but i am repeating myself, so i shut my mouth for a while now
14:28 Fixer joined #minetest-dev
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:41 definitely_a joined #minetest-dev
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:45 specing_ joined #minetest-dev
15:46 definitely_a I believe it's just those two nodes.
15:48 sfan5 ah sure
15:52 Extex joined #minetest-dev
15:53 hendursaga joined #minetest-dev
16:05 fluxionary joined #minetest-dev
16:25 Extex joined #minetest-dev
16:31 erlehmann <jonadab> 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
18:05 fluxionary joined #minetest-dev
20:07 Extex joined #minetest-dev
20:26 MTDiscord <josiah_wi> 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 <josiah_wi> 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 <josiah_wi> I would have gladly taken the time to set up CMake to run the tests.
21:00 MTDiscord <josiah_wi> Now that the tests are gone, and I am significantly busier than I was, this isn't as appealing to me.
21:02 MTDiscord <josiah_wi> 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 <josiah_wi> 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 <josiah_wi> 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 <josiah_wi> 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 <josiah_wi> Ah, the version tags! That should work; I just need to remember how to shuffle directories across commit refs. xD
21:12 MTDiscord <josiah_wi> Ah yes, git checkout with the -p option.
21:15 proller joined #minetest-dev
21:16 MTDiscord <josiah_wi> 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 <josiah_wi> 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 <Jordach> i'm pretty sure the only thing botched is irrlicht itself
21:29 MTDiscord <josiah_wi> 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 <luatic> C++ is botched too
21:30 MTDiscord <josiah_wi> The grass is always greener on the other side of the fence.
21:32 MTDiscord <Jonathon> its also greener where the septic tank is
21:33 MTDiscord <josiah_wi> 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 <josiah_wi> 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 <josiah_wi> 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 <josiah_wi> 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 <josiah_wi> 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 <josiah_wi> I don't either.
22:46 Sokomine joined #minetest-dev
22:49 erlehmann joined #minetest-dev
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 <josiah_wi> 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 <josiah_wi> 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 <josiah_wi> 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 <josiah_wi> 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 <josiah_wi> Right, I'm re-adding the tests to the new revision. Otherwise they won't be useful.
23:02 MTDiscord <josiah_wi> 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 <josiah_wi> 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 <josiah_wi> 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 <josiah_wi> 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 <josiah_wi> Oh wow. There's a test that's indented with spaces instead of tabs.
23:06 erlehmann passes
23:06 MTDiscord <josiah_wi> 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 <josiah_wi> I'm going to at least get this to a point where people can actually make unit tests.
23:09 MTDiscord <josiah_wi> 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 <josiah_wi> undefined reference to symbol dlclose@@GLIBC_2.2.5
23:12 MTDiscord <josiah_wi> DSO missing from command line
23:12 MTDiscord <josiah_wi> Looks like I botched something hehe.
23:12 MTDiscord <josiah_wi> I have just the 1 initial test enabled, and everything else commented out.
23:13 Alias2 joined #minetest-dev
23:19 MTDiscord <josiah_wi> I need to eat, then I will work on resolving this. Maybe there's a library I need to link.
23:21 hendursaga joined #minetest-dev
23:21 erlehmann i am correcting myelf, i am at 1.9.0mt1 the whole time
23:30 MTDiscord <josiah_wi> 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 <erlehmann> 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 proller joined #minetest-dev
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:56 calcul0n__ joined #minetest-dev
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

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