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