| Time |
Nick |
Message |
| 00:07 |
|
twoelk left #minetest-dev |
| 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 |
| 02:22 |
|
behalebabo joined #minetest-dev |
| 03:02 |
|
specing_ joined #minetest-dev |
| 05:08 |
|
Extex joined #minetest-dev |
| 06:01 |
|
YuGiOhJCJ joined #minetest-dev |
| 07:49 |
|
olliy joined #minetest-dev |
| 08:13 |
|
tech_exorcist joined #minetest-dev |
| 08:23 |
|
tech_exorcist joined #minetest-dev |
| 08:42 |
|
Wuzzy joined #minetest-dev |
| 09:09 |
|
Fixer joined #minetest-dev |
| 09:50 |
|
calcul0n_ joined #minetest-dev |
| 10:22 |
|
calcul0n__ joined #minetest-dev |
| 10:56 |
|
entuland joined #minetest-dev |
| 13:12 |
|
BuckarooBanzai6 joined #minetest-dev |
| 13:13 |
|
Calinou_ joined #minetest-dev |
| 13:15 |
|
basxt0 joined #minetest-dev |
| 14:21 |
|
Fixer joined #minetest-dev |
| 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 |
| 14:59 |
|
specing_ joined #minetest-dev |
| 15:19 |
|
Lone_Wolf joined #minetest-dev |
| 15:39 |
|
Extex joined #minetest-dev |
| 15:42 |
|
tech_exorcist joined #minetest-dev |
| 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:03 |
|
entuland joined #minetest-dev |
| 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 |
<exe_virus> 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 |
<exe_virus> 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 |
<Warr1024> 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 |
<exe_virus> 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 |
<Warr1024> Yeah, and we have JSON serialization sprinkled around in other places too. |
| 17:21 |
MTDiscord |
<exe_virus> JSON ain't much better |
| 17:21 |
MTDiscord |
<exe_virus> Both are human readable, when not human readable is typically much better |
| 17:21 |
Krock |
serializeJsonStringIfNeeded needs to find it |
| 17:21 |
MTDiscord |
<Warr1024> 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 |
<exe_virus> 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 |
<Warr1024> 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 |
<exe_virus> Do it byte by byte. Literally memcpy |
| 17:23 |
MTDiscord |
<exe_virus> MsgPack is mediocre, in my experience. |
| 17:23 |
MTDiscord |
<exe_virus> Sadly |
| 17:23 |
MTDiscord |
<exe_virus> Might as well do JSON at that point |
| 17:23 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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:28 |
|
entuland_ joined #minetest-dev |
| 17:30 |
Krock |
if you have proper versioning from the start, maintaining compat isn't a too big pain |
| 17:31 |
|
nrz joined #minetest-dev |
| 17:32 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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:49 |
|
behalebabo joined #minetest-dev |
| 17:50 |
MTDiscord |
<josiah_wi> So stop arguing and approve my PR. (/s) |
| 18:03 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> In about 15 minutes I'll be able to prove that :-D |
| 18:12 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Benrob0329> Yes, make a PR for their fork |
| 18:17 |
MTDiscord |
<Benrob0329> GH also allows PR submitters to allow edits from project maintainers |
| 18:31 |
|
Extex joined #minetest-dev |
| 19:04 |
MTDiscord |
<josiah_wi> Ah, Irrlicht has its CMake set up to do Android, but we already tested that part. |
| 19:22 |
|
appguru joined #minetest-dev |
| 19:26 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<josiah_wi> 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 |
<Warr1024> 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 |
<josiah_wi> Irrlicht generates a CMake file that tells the Minetest CMake about itself, instead of us telling Minetest about it. |
| 19:33 |
MTDiscord |
<josiah_wi> 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 |
<josiah_wi> 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 |
<Warr1024> 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 |
<josiah_wi> 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 |
<josiah_wi> 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 |
<josiah_wi> Ah, so that's why one is always slow. |
| 20:00 |
MTDiscord |
<Warr1024> 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 |
| 20:14 |
|
calcul0n__ joined #minetest-dev |
| 23:05 |
|
Alias2 joined #minetest-dev |
