| Time |
Nick |
Message |
| 00:00 |
|
hendursaga joined #minetest-dev |
| 00:45 |
MTDiscord |
<exe_virus> for the record, the TGA version of that single default_acacia_bush_sappling was larger than png by 25 bytes. |
| 00:54 |
MTDiscord |
<exe_virus> For a test of the simplest image: a 1x1 dot of RGB = 0,0,0, we get: JPEG: 284 bytes PNG: 67 bytes TGA: 48 bytes WEBP: 30 Bytes |
| 01:00 |
|
AliasAlreadyTake joined #minetest-dev |
| 01:33 |
MTDiscord |
<exe_virus> Also, there's been new developements that are quite relevant to this discussion: Webp2 is being worked on, AVIF is awesome, so is JPEG-XL, and there's BPG. I.e. There's a lot of active development on the subject. I was not aware of all of them because they're all 2019+. Last time I did all the research was... 2019 haha |
| 01:35 |
|
Extex joined #minetest-dev |
| 01:36 |
|
olliy joined #minetest-dev |
| 01:40 |
MTDiscord |
<exe_virus> Interesting, this site is super helpful for testing: https://squoosh.app/ It lets you play with compression sizes and comparisons in real time. Looks like webp2 when it's done will be a better replacement: it's a solid 19 bytes for the single black dot. For the acacia bush, it comes out at 66 Bytes, vs png's 151 and webp's 102. Now I wonder if we should just wait to support webp2 when its released |
| 01:46 |
|
v-rob joined #minetest-dev |
| 02:03 |
MTDiscord |
<Jordach> xkcd standards pls |
| 02:32 |
|
pgimeno joined #minetest-dev |
| 02:53 |
|
hendursaga joined #minetest-dev |
| 03:00 |
|
v-rob joined #minetest-dev |
| 03:02 |
v-rob |
I never saw what was the problem with plain PNG, or JPEG if you have a huge texture. It's not like the difference is more than a few bytes for the vast majority of textures regardless of format... |
| 03:02 |
v-rob |
And every image editor under the sun will support them |
| 03:28 |
|
queria joined #minetest-dev |
| 03:30 |
MTDiscord |
<exe_virus> It's a decent compression nowadays. I'll have to test with webp2, but webp1 compressed MTG textures is a solid 20% smaller than current pngs. Based on my testing with acacia bush, I'd expect the webp2 sizes to be almost 50% of the original PNG sizes. It matter because of bandwidth reductions, both for cdb hosting and server new player joins. Lowering that barrier always increases player uptake |
| 03:31 |
MTDiscord |
<exe_virus> As for support, webp has gimp support, so that one makes a lot of sense |
| 03:31 |
MTDiscord |
<exe_virus> And it's not like we're dropping jpeg or png support |
| 03:31 |
MTDiscord |
<exe_virus> Just trying to get more bang for the buck on our game engine |
| 03:34 |
|
queria joined #minetest-dev |
| 03:45 |
|
v-rob joined #minetest-dev |
| 04:00 |
|
MTDiscord joined #minetest-dev |
| 04:01 |
|
specing_ joined #minetest-dev |
| 04:09 |
|
tekakutli joined #minetest-dev |
| 04:23 |
MTDiscord |
<exe_virus> As for lossy compression, AFIV is about 20% of the original size for equal quality compared to jpeg. So that discussion for lossy is quite quite important |
| 04:24 |
MTDiscord |
<exe_virus> i.e. 60 KB->9.63B (sorry, 16% of original in my test case) |
| 07:36 |
|
MTDiscord joined #minetest-dev |
| 08:05 |
|
hendursa1 joined #minetest-dev |
| 09:54 |
|
erlehmann joined #minetest-dev |
| 09:58 |
|
tech_exorcist joined #minetest-dev |
| 10:02 |
erlehmann |
i have found a case in which shaders make an object black, no shaders make it white |
| 10:02 |
erlehmann |
very unfunny |
| 10:02 |
erlehmann |
i am bisecting the issue |
| 10:30 |
MTDiscord |
<luatic> The "single pixel" is biased towards low overhead formats. v-rob makes a good point: PNG support is ubiquitous. WebP support is not. |
| 10:31 |
erlehmann |
luatic the single pixel is obv the extreme case to figure out the minimum amount of overhead, not a true benchmark |
| 10:32 |
erlehmann |
btw, for anyone wondering what i meant with the dependencies being underspecified: every time you have to delete CMakeCache.txt to actually get minetest to build, you probably have encountered such a bug. |
| 10:33 |
erlehmann |
one way i managed to get to that is during bisection, by building a commit much newer than 5.4.1, then trying to build 5.4.1. |
| 10:34 |
erlehmann |
it fails, unless I delete CMakeCache.txt – even if i instruct make to build everything (from which i conclude the problem is cmake) |
| 10:35 |
|
proller joined #minetest-dev |
| 10:38 |
|
Fixer joined #minetest-dev |
| 11:27 |
MTDiscord |
<exe_virus> Just because it's ubiquitous, doesn't mean we can't support newer formats also. Heck we have .b3d, the least ubiquitous 3d object format, and we won't probably rip that out ever |
| 11:30 |
erlehmann |
oh i'm sure some clown will advocate for that eventually |
| 11:34 |
erlehmann |
anyways, does *anyone* have an idea how this could happen? the book is supposed to be textured: https://mister-muffin.de/p/Dm8y.png |
| 11:35 |
erlehmann |
with shaders, book is solid black. without shaders, book is solid white. |
| 11:40 |
MTDiscord |
<exe_virus> What image format? |
| 11:40 |
MTDiscord |
<exe_virus> And can you post that file? |
| 11:41 |
MTDiscord |
<exe_virus> Wait, this might be related to a certain compression for png, is this an optimized png with transparency? |
| 11:41 |
MTDiscord |
<exe_virus> Long story short there's a big with AMD built-in GPUs with transparency and I believe mipmaps when the png is in a compressed filter mode, very very specific |
| 11:42 |
MTDiscord |
<exe_virus> Bug* |
| 11:44 |
sfan5 |
textures are expanded to RGBA in software before they touch the cpu, such details will never affect the rendering result |
| 11:48 |
erlehmann |
this is the enchantment table, the bug happens in mineclone2 and mineclonia from 5.4.0 onwards (i did not check older versions) |
| 11:49 |
erlehmann |
so cora said it works in 5.4, but only with shaders and does not work in 5.5-dev |
| 11:50 |
erlehmann |
exe_virus, i'll look for the file |
| 11:50 |
|
calcul0n__ joined #minetest-dev |
| 11:57 |
MTDiscord |
<exe_virus> It's affected it before sfan5. When we compressed mtg default textures using optipng a couple months ago we had to restrict it from some filtering options on transparency pngs because I think we did something wrong with the binary alpha rendering. |
| 11:58 |
erlehmann |
yeah if anyone says “this can't be happening” during debugging, it's best to not believe them until you checked |
| 11:58 |
erlehmann |
software bugs are literally dark magic |
| 11:58 |
MTDiscord |
<exe_virus> Oh don't worry, sfan5 knows that |
| 11:58 |
erlehmann |
i have the file |
| 11:58 |
erlehmann |
exe_virus how do i determine if the png is bad? |
| 11:58 |
MTDiscord |
<exe_virus> Host it somehow and post a link haha |
| 11:59 |
MTDiscord |
<exe_virus> I'll have to test it today sometime |
| 11:59 |
erlehmann |
i can do that but this *screams* for some code that outputs a warning on bad pngs |
| 11:59 |
MTDiscord |
<exe_virus> Nah, it's not the pngs fault |
| 12:00 |
erlehmann |
uh? |
| 12:00 |
MTDiscord |
<exe_virus> How dare it use its own format |
| 12:00 |
erlehmann |
oh well, on PNGs the engine can't handle |
| 12:00 |
MTDiscord |
<exe_virus> Right, we should just handle them better |
| 12:00 |
erlehmann |
or warn if you can't |
| 12:01 |
erlehmann |
exe_virus this is the code for the bad entity https://git.minetest.land/Mineclonia/Mineclonia/src/branch/master/mods/ITEMS/mcl_enchanting/init.lua#L174 |
| 12:01 |
erlehmann |
i mean the bugged entity |
| 12:03 |
erlehmann |
exe_virus is that enough? |
| 12:03 |
erlehmann |
i actually expect this not to be bugged everywhere |
| 12:03 |
sfan5 |
@exe_virus that's not about filtering options but about throwing away colors for pixels that are transparent, these are meaningful to Minetest since they're used for opaque leaves |
| 12:04 |
erlehmann |
uh, why would anyone throw away colors for pixels that are transparent? you need those for blending |
| 12:04 |
erlehmann |
but yes, that seems the PNG optimizers fault |
| 12:04 |
erlehmann |
or rather the fault of whoever chose the options |
| 12:04 |
sfan5 |
well it's fine for most things |
| 12:05 |
erlehmann |
i run into this kind of bug usually when i encounter naive gradient implementations |
| 12:06 |
erlehmann |
they tend to try to blend to transparent black |
| 12:06 |
erlehmann |
which works as well as you think it would, not at all |
| 12:06 |
MTDiscord |
<exe_virus> Ah gotcha, thanks sfan |
| 12:06 |
sfan5 |
OpenGL does that too |
| 12:07 |
pgimeno |
it should work in premultiplied alpha mode I believe |
| 12:07 |
erlehmann |
yeah pgimeno |
| 12:07 |
MTDiscord |
<exe_virus> Yeah my test plan is to run mt in debug mode and to see if the file loads differently |
| 12:07 |
erlehmann |
true |
| 12:07 |
MTDiscord |
<exe_virus> For each version |
| 12:07 |
MTDiscord |
<exe_virus> Maybe I can dump the contents or something easy |
| 12:07 |
erlehmann |
exe_virus additional information, i compile with clang++ |
| 12:08 |
erlehmann |
uh, or rather i don't |
| 12:08 |
MTDiscord |
<exe_virus> Haha, no worries it shouldn't be that kind of big |
| 12:08 |
erlehmann |
what does “IrrlichtMT project is missing a CMake target?!” mean? |
| 12:08 |
MTDiscord |
<exe_virus> You need to configure the project basically |
| 12:08 |
erlehmann |
there is already code that has 100% different results when compiled with gcc or clang (the biome UB) |
| 12:08 |
MTDiscord |
<exe_virus> IrrlichtMT specifically |
| 12:09 |
erlehmann |
but i did build irrlichtmt in lib/irrlichtmt |
| 12:09 |
erlehmann |
like cmake . && make -j8 -B |
| 12:09 |
MTDiscord |
<exe_virus> "shrug?" I don't have that much build experience sadly |
| 12:09 |
erlehmann |
the build system is so cursed |
| 12:15 |
erlehmann |
nevermind, i fixed it, i had irrlichtmt1.9.0mt0 by accident |
| 12:15 |
erlehmann |
i once again want to remind everyone that git submodules exist |
| 12:16 |
erlehmann |
like, if you are tightly coupling a library to an application program (removing/changing interfaces), there should be a way to automagically make it work |
| 12:16 |
erlehmann |
so far the CI seems to just paper over it |
| 12:17 |
erlehmann |
by hardcoding irrlichtmt version tag for the nightlies |
| 12:19 |
sfan5 |
breaking build system changes are annoying when bisecting but we should be past that now |
| 12:23 |
erlehmann |
sfan5, a bunch of shell scripts that try to reproducibly build a specific version of mt, good idea or bad? |
| 12:24 |
sfan5 |
good obviously but I don't think they should be put into the repo if that's what you're thinking of |
| 12:24 |
erlehmann |
why not |
| 12:25 |
erlehmann |
like what is the problem with making it easier to build mt? |
| 12:27 |
sfan5 |
needing to automatically build arbitrary revisions is a specialized usecase, normal people just clone master and read the instructions |
| 12:27 |
erlehmann |
look, normally, the build system would be able to handle that |
| 12:27 |
erlehmann |
uh |
| 12:27 |
erlehmann |
packagers for distributions need that |
| 12:28 |
MTDiscord |
<Sublayer plank> packagers just have their own buildscript they maintain usually |
| 12:28 |
erlehmann |
the build system is stupid though, and i doubt i'll be able to change that. a bunch of scripts that made “the canonical binary” would help so much. |
| 12:28 |
sfan5 |
packagers don't need arbitrary revisions, they need to build releases which happens at most twice a year |
| 12:29 |
erlehmann |
and by “i doubt i'll be able to change that”, i mean every time i point out pain points, it is “not a big deal”, or an “edge case” |
| 12:29 |
sfan5 |
additionally packagers would never use that script no matter how super convenient it is |
| 12:29 |
erlehmann |
uh, i build arbitrary revisions. and i know an arch linux packager of my own software, that guy packages every little revision. |
| 12:30 |
erlehmann |
also, some server admins do not run master, but patch it |
| 12:31 |
sfan5 |
I was thinking of packages maintained by the distribution, unofficial packagers can do whatever of course |
| 12:32 |
erlehmann |
look, forget about it. i already figured out there seems to be little interest in small, incremental improvements. but you should know that i am not the only person debugging minetest and trying out different versions and it has become harder, not easier, to do that. i am merely the most obnoxious ones. |
| 12:32 |
erlehmann |
one |
| 12:32 |
erlehmann |
the last person i encouraged to report difficulties to the devs flat-out rejected it |
| 12:33 |
erlehmann |
you should really try to not reject convenience things bc *you* don't need them |
| 12:33 |
sfan5 |
I am not preventing you from writing that script or publishing it |
| 12:33 |
erlehmann |
yeah but if i publish it on some random website it won't help for the future |
| 12:34 |
|
pgimeno left #minetest-dev |
| 12:34 |
erlehmann |
sfan5, would a single script that compiles the current revision fit in though? |
| 12:35 |
erlehmann |
i mean like the CI stuff, but actually using the appropriate version of irrlichtmt |
| 12:35 |
erlehmann |
and not hidden in CI stuff |
| 12:37 |
sfan5 |
would that script just clone irrlichtmt and run cmake + make? |
| 12:37 |
erlehmann |
no, it would also make sure that all the workarounds are applied |
| 12:38 |
sfan5 |
so it'd delete all build files first too |
| 12:38 |
erlehmann |
i think you need to delete CMakeCache.txt in both directories and give make the -B option |
| 12:39 |
erlehmann |
also for compiling with OGLes it would need to change stuff |
| 12:39 |
sfan5 |
giving make any funny options sounds like it'd contribute to breaking it |
| 12:39 |
erlehmann |
do you even know what make -B does? |
| 12:39 |
sfan5 |
yes |
| 12:39 |
erlehmann |
well, how can unconditionally making all targets break anything? |
| 12:40 |
erlehmann |
it's the *only* way to get a reliable result with make |
| 12:40 |
erlehmann |
you know, this is bikeshedding |
| 12:42 |
sfan5 |
not all targets are for compiling files, cmake also does some internal stuff so I'm just guessing that it's not totally safe |
| 12:42 |
erlehmann |
i just want to contribute to minetest so i can finally do meaningful code reviews (which is about the only thing i am really interested in) :/ |
| 12:45 |
sfan5 |
anyway what I had in mind with my question is that the script would have to be configurable for users to pass arbitrary options to cmake |
| 12:45 |
sfan5 |
or perhaps swap 'make' for 'ninja' |
| 12:45 |
sfan5 |
so if it's just about irrlichtmt maybe a script that clones the right revision of irrlichtmt would be better (and leave the rest for the user) |
| 12:46 |
erlehmann |
ninja is equally broken as make for this purpose, but i don't particularly care which broken system you use |
| 12:46 |
erlehmann |
> the script would have to be configurable for users to pass arbitrary options to cmake |
| 12:46 |
erlehmann |
ofc |
| 12:50 |
|
calcul0n_ joined #minetest-dev |
| 13:50 |
MTDiscord |
<exe_virus> No worries, I have been thinking about running a new mine test repo for test scripts, build scripts, etc. Basically one that has extraneous stuff that we don't want mucking up the main repo |
| 13:51 |
MTDiscord |
<exe_virus> Then hopefully I toss on a CI to it and it runs whenever a new commit goes to minetest master |
| 13:51 |
MTDiscord |
<exe_virus> Or irrlichtmt |
| 13:52 |
MTDiscord |
<exe_virus> At the end of the day it's nearly impossible to make build scripts better, because there is no way to enforce the same system on every single dependency, especially old libraries. Just be thankful most are at least on cmake now |
| 13:53 |
MTDiscord |
<exe_virus> This isn't python where there is only one way to do things haha |
| 14:01 |
erlehmann |
exe_virus pretty sure i know how to make build scripts incrementally better at least on linux, but almost everyone stops listening once i start with “strace the compiler so you 100% get all dependencies” |
| 14:52 |
|
proller joined #minetest-dev |
| 14:53 |
|
olliy1or joined #minetest-dev |
| 15:35 |
|
fluxionary joined #minetest-dev |
| 15:40 |
MTDiscord |
<exe_virus> Well, put it in a repo and I'll look at it sometime soon, this is a long term learning process haha. We're also slow to adopt change as a community, so there's that. We eventually make the needed changes basically every time, it just takes time;) |
| 15:51 |
|
Extex joined #minetest-dev |
| 16:02 |
|
specing_ joined #minetest-dev |
| 16:25 |
|
olliy joined #minetest-dev |
| 16:31 |
erlehmann |
sofar does the parkour in “inside the box” rely on sneak jump glitches? if yes, you should probably look at this PR https://github.com/minetest/minetest/pull/11367 |
| 16:57 |
|
tech_exorcist joined #minetest-dev |
| 17:07 |
MTDiscord |
<GreenXenith> ITB disables sneak grabbing entirely |
| 17:14 |
rubenwardy |
#11567 is marked as needs approval, but has active discussion. Worth deciding on something |
| 17:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/11567 -- Use an sqlite database for the media cache by Desour |
| 17:15 |
rubenwardy |
I'm not too worried about one time downloads, but any issues with locks from multiple MT instances could be a problem for me (as I often start multiple at the same time to test something) |
| 17:19 |
MTDiscord |
<exe_virus> For the record, zlib compression yields no gains for pngs and jpeg, but does helped with plaintext awful .obj |
| 17:20 |
rubenwardy |
What's the plan for irrlichtmt? Is it being reduced in size, rewriting, and then eventually merged into the minetest/minetest repo? |
| 17:21 |
MTDiscord |
<Sublayer plank> the sqlite media cache PR feels overengineered tbh |
| 17:21 |
rubenwardy |
yeah I agree, it's complicated |
| 17:25 |
MTDiscord |
<Sublayer plank> anyways yeah irrlichtmt is supposed to be absorbed into minetest soon enough |
| 17:26 |
MTDiscord |
<Sublayer plank> most of the rendering code will probably be thrown out for hecks' rendering engine in the near future |
| 17:31 |
MTDiscord |
<exe_virus> Nice |
| 17:31 |
|
erlehmann joined #minetest-dev |
| 18:02 |
Krock |
will merge #11467 #11722 game#2904 game#2888 in 15 minutes |
| 18:02 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2904 -- Add Japanese translation by nogajun |
| 18:02 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/2888 -- Use itemstack name in door on_place by LoneWolfHT |
| 18:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/11467 -- Add joystick layout for DragonRise GameCube controller by Izzette |
| 18:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/11722 -- Apply shadow only to the naturally lit part of the fragment color by x2048 |
| 18:06 |
|
Extex joined #minetest-dev |
| 18:17 |
Krock |
merging |
| 18:36 |
|
tech_exorcist joined #minetest-dev |
| 18:38 |
|
hendursaga joined #minetest-dev |
| 18:45 |
|
hendursaga joined #minetest-dev |
| 19:26 |
|
tech_exorcist joined #minetest-dev |
| 19:26 |
|
Wuzzy joined #minetest-dev |
| 19:32 |
Wuzzy |
#11665 |
| 19:32 |
ShadowBot |
https://github.com/minetest/minetest/issues/11665 -- Decouple liquid pointing from liquidtype by Wuzzy2 |
| 19:44 |
erlehmann |
regarding https://github.com/minetest/minetest/pull/11367 – does this influence “sneak glitch fence jumping”? |
| 19:45 |
erlehmann |
when a player wants to jump across a fence that is too high |
| 19:45 |
erlehmann |
they press sneak |
| 19:45 |
erlehmann |
to get on the fence |
| 19:45 |
erlehmann |
that has been a game mechanic since forever i think? |
| 19:45 |
erlehmann |
would be a shame if something happened to it |
| 19:53 |
Wuzzy |
only if Sneak Glitch is enabled. but obviously this PR needs testing since it touched move code |
| 20:07 |
erlehmann |
i am really irritated by the desire of some developers to change APIs in mostly-backwards-incompatible ways in the name of elegance when they could just as well introduce a new function that does what they want. |
| 20:08 |
erlehmann |
Wuzzy the rail/road end tile thing looks very nice |
| 20:09 |
Wuzzy |
thx |
| 20:10 |
erlehmann |
> Under the new rules, non-roadmap non-bugfix PRs have 7 days to be concept approved, otherwise they should be closed. |
| 20:10 |
erlehmann |
LOL |
| 20:12 |
MTDiscord |
<Jonathon> the roadmap is a joke |
| 20:12 |
erlehmann |
with the amount of reviews that are going on vs amount of open PRs, i suspect a lot of stuff will be closed soon |
| 20:12 |
rubenwardy |
people complain when we don't have one, people complain when we do |
| 20:13 |
rubenwardy |
can't win in open source |
| 20:13 |
erlehmann |
nah, having one is good |
| 20:15 |
|
tech_exorcist joined #minetest-dev |
| 20:37 |
erlehmann |
i think the 7 days thing is a perfect rule to get rid of all these annoying contributors |
| 20:37 |
erlehmann |
the drive-by PRs that fire code into the general direction of minetest |
| 20:37 |
erlehmann |
and then speed off, only to reload |
| 20:39 |
sfan5 |
are you being sarcastic |
| 20:40 |
MTDiscord |
<Jonathon> unfortunately they probably arent |
| 20:40 |
erlehmann |
only half. when i was maintaining things 10 years ago, it was a problem that github popularized the drive-by shooting style of PR where ppl would dump a bunch of code, then vanish |
| 20:40 |
rubenwardy |
it doesn't really stop drive-by PRs necessarily - our rules on Action needed / draft PRs helps with that |
| 20:41 |
rubenwardy |
it allows us to focus on PRs that are most needed right now, by codafying what that means |
| 20:42 |
erlehmann |
sfan5, the other half is “ppl like cora and fleck are maintaining their own clients” btw. |
| 20:43 |
erlehmann |
they are probably not the only ones and i doubt it is primarily for cheating in all cases |
| 20:43 |
MTDiscord |
<Jordach> oh it is |
| 20:43 |
MTDiscord |
<Jordach> i guarantee it# |
| 20:47 |
erlehmann |
i shouldn't have mentioned that |
| 20:48 |
erlehmann |
good night |
| 20:48 |
|
erlehmann left #minetest-dev |
| 21:30 |
|
Extex joined #minetest-dev |
| 21:37 |
|
Extex joined #minetest-dev |
| 21:56 |
|
v-rob joined #minetest-dev |
| 22:05 |
|
longerstaff13 joined #minetest-dev |
| 22:06 |
|
proller joined #minetest-dev |
| 22:21 |
rubenwardy |
merging #11110 and #11656 in 10 |
| 22:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/11110 -- Fix number of tool uses being off by 1..32767 by Wuzzy2 |
| 22:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/11656 -- Add variable to use existing IrrlichtMt build by JosiahWI |
| 22:21 |
rubenwardy |
#9847 is something easy to review |
| 22:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/9847 -- Add bitop library by Lejo1 |
| 22:22 |
rubenwardy |
sfan5: would you like me to merge #11729 and #11690 as well? |
| 22:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/11729 -- [no squash] Buildbot improvements by sfan5 |
| 22:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/11690 -- Update Android to new dependency repo by sfan5 |
| 22:22 |
sfan5 |
yes |
| 22:22 |
sfan5 |
re 9847 might be worth adding an unittest that starts up a script env and checks for the library |
| 22:23 |
sfan5 |
(not necessarily in that PR) |
| 22:23 |
sfan5 |
the opportunity could also be used to verify that the basics of the sandbox is working |
| 22:23 |
sfan5 |
s/ is / are / |
| 22:23 |
rubenwardy |
is that something we've done before? Other than dev test |
| 22:24 |
rubenwardy |
well, devtest's integ tests don't run in CI (unless they do, I vaguely recall work on that) |
| 22:24 |
sfan5 |
testing script env from unittests would be a first |
| 22:24 |
sfan5 |
I haven't found any tests inside devtests that could be run in an automated fashion during integration tests |
| 22:25 |
rubenwardy |
the tests I wrote are intended to run automatically |
| 22:25 |
rubenwardy |
although, I can't remember how they exit on success/failure |
| 22:28 |
|
v-rob joined #minetest-dev |
| 22:28 |
rubenwardy |
https://github.com/minetest/minetest/tree/master/games/devtest/mods/unittests |
| 22:28 |
rubenwardy |
looks like they use `assert()` |
| 22:28 |
rubenwardy |
so on failure, it would crash with code 1 |
| 22:28 |
rubenwardy |
and on success it would keep running |
| 22:28 |
rubenwardy |
so just need to solve the halting problem |
| 22:29 |
sfan5 |
oh huh that stuff is there |
| 22:56 |
|
Extex joined #minetest-dev |
| 23:03 |
|
v-rob joined #minetest-dev |
| 23:30 |
sfan5 |
hmm something about automatially copying the mingw files didn't work |
| 23:30 |
|
v-rob joined #minetest-dev |
| 23:31 |
sfan5 |
runtime_dlls= |
| 23:31 |
sfan5 |
-DEXTRA_DLL="$runtime_dll" \ |
| 23:31 |
sfan5 |
spot the mistake |
| 23:32 |
rubenwardy |
? |
| 23:32 |
rubenwardy |
at least it's not a mistake that would delete player's worlds. That's something I was worried about with the Android scoped migration |
| 23:33 |
sfan5 |
copying worlds first in the migration was a good idea actually, the later you do the more likely the user is going to interrupt it |
| 23:34 |
rubenwardy |
Implying that was intentionly considered |
| 23:35 |
MTDiscord |
<Jonathon> heh, number of open prs just got axed a lot |
| 23:35 |
rubenwardy |
in true halloween fashion |
