Time Nick Message 01:06 sofar ""Refer to the documentation of the setting for a list of valid placeholders."" 01:06 sofar what does that even mean? 01:06 sofar it's not a setting API, it's a method 01:06 sofar there are no settings in the call 01:06 sofar ... 01:06 sofar https://github.com/minetest/minetest/blob/f4d8cc0f0bf33a998aa0d6d95de4b34f69fb31db/doc/lua_api.txt#L4944 14:46 Krock would it be a problem if minetest.settings:get("key") would return a Settings object (groups)? The format of each setting is known, hence this wouldn't break mods unless they do some kind of settings parsing 15:45 Krock actually that's a bad idea. introducing Groups to the Lua API would arise many new issues regarding circular references and that fallbacks aren't working 17:16 Krock erm guys I. I think I found a way to speed up the serialization by 26x for large item metadata by using strstr rather than custom loops 17:18 MTDiscord Nice. I figured our minetest.serialize and deserialize were total crap. 17:19 sfan5 why does serialization need to find something in a string? 17:19 MTDiscord Like why do we serialize to something that can be directly read into a variable via Lua code, rather than using straight up binary 17:19 MTDiscord We serialize to lua code because in theory the lua code parser is faster than a binary parser written in lua would be. 17:20 MTDiscord But it's less effecicient size wise and typically the same speed? 17:20 sfan5 item metadata does not use Lua serialization btw 17:21 MTDiscord Yeah, and we have JSON serialization sprinkled around in other places too. 17:21 MTDiscord JSON ain't much better 17:21 MTDiscord Both are human readable, when not human readable is typically much better 17:21 Krock serializeJsonStringIfNeeded needs to find it 17:21 MTDiscord They all have trade-offs. A big advantage of JSON is usability with external tools. 17:21 sfan5 item metadata is not straight json either 17:22 MTDiscord Fair, but why not dump to binary for all of our serializations? 17:22 sfan5 binary-safety is a bit of an issue 17:23 MTDiscord If we adopted an existing but already efficient standard like MsgPack that would be ideal in theory, but in practice it would probably end up meaning xkcd 927 and now we have 4 different serialization formats. 17:23 MTDiscord Do it byte by byte. Literally memcpy 17:23 MTDiscord MsgPack is mediocre, in my experience. 17:23 MTDiscord Sadly 17:23 MTDiscord Might as well do JSON at that point 17:23 MTDiscord I mean we could also just spend eternity bikeshedding about our favorite serialization formats too :-) 17:23 Krock oh god I'm just somewhat stupid 17:24 Krock it felt too good to be true because that's a LT and GT comparison in said function 17:25 Krock it would be great if we could entirely switch to binary format (length + data) but that won't be easily done 17:26 sfan5 serializeJsonStringIfNeeded could use SIMD, you just have to do it yourself 17:26 Krock Inventory stuff is currently formatted in the old per-player-files style 17:27 Krock yeah. compare 8 bytes of spaces or quotation marks each 17:28 MTDiscord I had some mods where I switched to a more binary-like format, taking advantage of Lua's string's 8bitness ... but I ended up having to heuristically check for the old serialization format and convert that data automatically, so it ended up being a mess. It was also a lot harder to manually tweak stuff in the new serialization format and making a proper editor for it was too much of a pain. 17:30 Krock if you have proper versioning from the start, maintaining compat isn't a too big pain 17:32 MTDiscord So instead of 4 serialization formats, we'd end up with 2 versioning schemes, one with 3 serialization formats and 1 with 1 more... ? 17:34 MTDiscord If past experience is any indication, adding version metadata to a thing is a good way to ensure that there's only ever one version of the standard, so maybe if we'd have done that this wouldn't be a problem in a different way :-D 17:34 sfan5 when you have enough forethought to add a version you design it well from the beginning 17:34 sfan5 ;) 17:37 MTDiscord True, though it takes surprisingly little forethought to avoid all mistakes entirely: you just need to spend enough time planning that you never actually complete the project ;-D 17:50 MTDiscord So stop arguing and approve my PR. (/s) 18:03 MTDiscord Hmm, that reminds me, I was going to try building and testing android with your PR... 18:04 sfan5 android does not use cmake so there is no difference 18:04 MTDiscord In about 15 minutes I'll be able to prove that :-D 18:12 MTDiscord https://github.com/minetest/minetest/pull/11378#issuecomment-881022321 really makes me wonder if it would make sense to have an API for games/mods to define their own "game mode" type info to display in that section of the menu. 18:13 MTDiscord Game name and (where known) version would be nice, and maybe games have other modal info that would be meaningful in lieu of what's being elided... 18:14 MTDiscord Can I submit a PR to a PR, i.e. submit a PR to have someone merge changes into a branch that they're using for a PR for MT, i.e. so that if they accept my changes into their branch then it will effectively update the original PR? 18:17 MTDiscord Yes, make a PR for their fork 18:17 MTDiscord GH also allows PR submitters to allow edits from project maintainers 19:04 MTDiscord Ah, Irrlicht has its CMake set up to do Android, but we already tested that part. 19:26 MTDiscord I was able to successfully build. Presumably that should be enough to assume it actually works and I don't have to test that thoroughly? 19:27 MTDiscord I can't actually say that I fully understand the PR well enough to make a call on principle, so I'd have to look at comprehensive empirical evidence to be able to support it myself. I mean, in principle I like the concept very much, it's just hard for me to say that I'm confident it doesn't break something important. 19:27 sfan5 if if something is supposedly important and not in CI then it's either not important or not testable 19:29 MTDiscord Unless somebody maintains something for some obscure platform and is going to chime in, I'm getting inclined to approve it based a "sound concept and I can't find a problem with the implementation" standard. 19:30 MTDiscord I mean, if it turns out it DOES break something, we can just revert it probably, right? It's not like I haven't submitted PRs myself that introduced regressions, pushed to get them merged, and then had to fix the regressions in a hurry later... 19:30 MTDiscord I need to learn to write good descriptions that explain what things do in a concise way, but of course that's the difficult part of good documentation. 19:31 MTDiscord As I understand it, you're basically just deleting a bunch of redundant crap that we only had in the first place because of the "external" status of Irrlicht, so the only risk would be from a mismatch in version/behavior that shouldn't have been allowed to exist in the first place, right? 19:32 MTDiscord Irrlicht generates a CMake file that tells the Minetest CMake about itself, instead of us telling Minetest about it. 19:33 MTDiscord Btw sfan, dous the CI test both static and dynamic linking? I tested both multiple times during development but that's the type of thing that one could work and the other could have an issue. 19:34 MTDiscord I'm not concerned there's any problem now, but I'm wondering whether both are tested in case things are modified in tde future and one could break. 19:35 sfan5 gitlab-ci does static linking since it uses lib/irrlichtmt 19:36 MTDiscord how much testing is actually included in our CI? Do we cover mulitple platforms? Do we have like regression tests or something to ensure things actually behave correctly rather than just compiling? 19:38 sfan5 have you ever expanded the list of ci builds? 19:38 MTDiscord If you look at the CI build you can see that it builds on Ubuntu with some various project configurations, and different computers (Clang and g++) and Mingw. Also some code analysis checks. 19:39 MTDiscord compilers* 19:39 sfan5 ^ that plus android, almost all of them run unittests, once under valgrind, there's a small client-server integration test 19:39 MTDiscord Ah, so that's why one is always slow. 20:00 MTDiscord Ah, okay, then I probably shouldn't have to worry about those kinds of regressions, I mostly just need to test stuff that has UX impact