Time  Nick       Message
10:18 sfan5      ~tell appguru varargs has limits so that's not the best idea
10:18 ShadowBot  sfan5: OK.
11:05 MTDiscord  <luatic> sfan5: I went with a table, it's indeed preferable here; no need to worry about stack space (and also better for modders to work with). See #13987.
11:05 ShadowBot  https://github.com/minetest/minetest/issues/13987 -- Proof-of-concept of limiting object observers by appgurueu
13:26 sfan5      ok
13:26 sfan5      @luatic also yes, MT is at c++17
13:27 sfan5      we should probably start replacing const std::string& with std::string_view in places
13:28 erle       what's the advantage? making sure it's readonly?
13:28 MTDiscord  <luatic> https://forum.minetest.net/viewtopic.php?p=430404 opinions?
13:29 MTDiscord  <luatic> (thread title is "how do we increase modder involvement in engine development?", I just opened the thread)
13:30 erle       luatic i am pretty sure i can name 3 or 4 people whose answer would be “let the shape of the API be designed by what people want to do, not what is easy to implement“ but a) that is a recurring complaint b) *someone* needs to implement the stuff and ultimately it only matters what they do
13:31 erle       like they are not even necessarily correct here
13:31 MTDiscord  <luatic> erle: this is not limited to API design
13:31 celeron55  ask the modders to learn more C++?
13:31 MTDiscord  <luatic> we have a feature freeze for example, but few modders seem to use this time window to ensure that their mods still work
13:31 celeron55  ah that kind of involvement
13:32 MTDiscord  <luatic> I opened this thread because I opened a draft PR for a feature I thought would be useful for modders, and I'd like their input, and esp. testing.
13:32 MTDiscord  <luatic> There is much involvement that does not require the deep C++ knowledge core devs have, which is what this thread focuses on.
13:34 celeron55  maybe there should be a well defined channel where engine developers could post when opportunities to help arise from people with no C++ knowledge. like when a feature freeze starts, post a call to test mods with the nightly build
13:35 MTDiscord  <luatic> sounds useful
13:35 celeron55  these calls are already being made, but they are dispersed in various issues and PRs and everywhere. they are probably difficult to find even if you wanted to
13:36 MTDiscord  <luatic> well, to be fair I believe pretty much every PR / issue could probably benefit from involved modders
13:36 erle       maybe the blog could also highlight API news? like, what kind of things are being discussed and added?
13:36 erle       (with a focus on discussed, because, well “details for their usecase may be missing”)
13:37 celeron55  i don't know if there's any other realistic option for that other than a forum thread or a forum (sub)section
13:37 MTDiscord  <luatic> Ideally I'm hoping that modders just watch development activity, giving their input on issues and PRs that relate to them, and use dev versions.
13:37 erle       unrealistic, but possible once setup: have a VM that downloads every mod on CDB with the version at feature freeze and simply tests if the game crashes if the mod is loaded.
13:38 celeron55  erle: that would be a nice project for someone
13:39 celeron55  luatic: if we assume the calls for help are already in issues and ORs, there are two options then: tag them with a "non-C++ help needed" tag so that they are easy to find, or make a channel (e.g. a forum topic) where links to relevant issues and PRs are posted
13:40 celeron55  the forum is quite useful in that you can subscribe by email to a topic. almost like a mailing list. not sure if anyone would like to follow that closely though
13:40 celeron55  s/ORs/PRs/
13:40 celeron55  i'm not sure if you can subscribe on github to specific tags being added
13:41 celeron55  that would be very useful
13:49 MTDiscord  <josiah_wi> erle, yes std:string_view is readonly, non-owning, and very cheap to copy (always passed by value).
14:00 erle       yeah okay but for function arguments const & is cheaper, not?
14:07 MTDiscord  <josiah_wi> I do not think that is the case.
14:08 MTDiscord  <josiah_wi> std::string_view is typically used for arguments instead of std::string const&.
14:10 Krock      T const&  is generally the same as T const* which implies another pointer dereference of the string instance. depending on the implementation of string_view, this could be optimized to only deference the internal char* data
14:10 Krock      *dereference
14:10 erle       https://stackoverflow.com/questions/39564457/when-would-i-pass-const-stdstring-instead-of-stdstring-view
14:10 MTDiscord  <josiah_wi> Well put, Krock.
14:10 erle       > f you do not need a null-terminated string, and you do not need to take ownership of the data, then you should use string_view.
14:11 erle       oh, there is an even better answer, is that true?
14:11 erle       > If you accept and store a string_view, it might become invalid when string internal buffer reallocates.
14:11 MTDiscord  <josiah_wi> Yes.
14:12 erle       wow the speed up here using string view is ridiculous o.0 https://stackoverflow.com/questions/40127965/how-exactly-is-stdstring-view-faster-than-const-stdstring/40129046#40129046
14:13 erle       neat
14:13 MTDiscord  <josiah_wi> Also, you can pass a C string as an argument to a string_view parameter.
14:13 MTDiscord  <josiah_wi> And it's also fast. So you get a more flexible interface at the same time.
14:14 erle       i see, thx
14:37 Krock      Meeting in 23 minutes
15:00 Krock      Meeting notes: https://dev.minetest.net/Meetings#2023-11-12  ping sfan5 @srifqi Desour @Zughy
15:01 [MTMatrix] <Zughy> o/
15:01 Krock      5.8.0 milestone: https://github.com/minetest/minetest/milestone/22
15:02 Krock      the last item standing is #13822 - is this a requirement for 5.8.0?
15:02 ShadowBot  https://github.com/minetest/minetest/issues/13822 -- Regression in splitting inventory stacks on Android
15:03 Krock      #13872 attempts to fix it but well... not well enough
15:03 ShadowBot  https://github.com/minetest/minetest/issues/13872 -- Formspec: Allow multiple mouse button click for touch-screen by srifqi
15:05 Krock      might there be anyone with an Android build system set up to have a look into this?
15:06 Krock      it is a rather annoying bug so reverting the commit 252c79d might be an option too so that it could be fixed in 5.9.0-dev
15:06 [MTMatrix] <Zughy> https://github.com/minetest/minetest/issues/13822#issuecomment-1773789974 "Item tooltips don't show anymore on Android" that sounds bad. I had no idea people could see tooltips on Android though
15:07 Krock      afaik the tooltips would appear on tap
15:09 [MTMatrix] <Zughy> Not a core dev, but from a UX perspective reverting 13146 sounds a huge step backward
15:10 Krock      I hoped srifqi would be around to give a short status update on their progress but well...
15:10 [MTMatrix] <Zughy> can't we wait a little longer or, worst case scenario postpone 13822 to 5.9? I mean, it's not like Android was doing great anyway.. and a few PRs definitely improved the Android UX in these months
15:11 Krock      I'm asking this now so that we're not again in the same spot in 2 weeks
15:12 Krock      i.e. to clarify who's got time to work on it - or if not - what to do instead.
15:12 appguru    Well, which UX is worse: not having 13146, or not seeing tooltips and the stack splitting regression?
15:12 grorp      I already spent some time on the bug, I didn't make any progress
15:13 [MTMatrix] <Zughy> appguru: imho the former
15:14 Krock      grorp: to me it seems that the lack of a proper state machine makes it overall more complicated to figure out what's happening in that code
15:15 Krock      the last request on a similar matter was postponed for later (TM) https://github.com/minetest/minetest/pull/13146#issuecomment-1562518320
15:15 erle       i want to point out that i have not yet made the patch to fix the filtering regressions, but i'd really want that to get into 5.8.0 because at least part of it seems to affect how anisotropic filtering looks on intel GPUs (all, not just mine) if i understand.
15:15 erle       (i simply did not have time, but i will from around 9PM europe/berlin in the evening)
15:18 Krock      erle: intel GPUs have various feature deficits and/or flaws that I've noticed through the years. Looking forward to a solution to one of those.
15:19 Krock      sfan5: is #13978 now OK for you?
15:19 ShadowBot  https://github.com/minetest/minetest/issues/13978 -- Add new flags to minetest.features for 5.8.0 features by Desour
15:22 Krock      aside from that there's not much left for 5.8.0 which is a good thing to see for the next meeting
15:26 [MTMatrix] <Zughy> I guess next point?
15:30 Krock      which one would you like to discuss?
15:31 Krock      perhaps #13813
15:31 ShadowBot  https://github.com/minetest/minetest/issues/13813 -- CJK characters looks been filtered in chat_message while the GUI could display them collectly
15:33 [MTMatrix] <Zughy> I wanted to remind about "Final answer about internal discussion #71 (Zughy)". It's two months today, I would like to bring it to a conclusion
15:33 ShadowBot  https://github.com/minetest/minetest/issues/71 -- make paths modifiable by hasufell
15:33 Krock      well I don't mind so that's a dead end for my side
15:34 [MTMatrix] <Zughy> so neutral?
15:34 Krock      yes
15:35 [MTMatrix] <Zughy> ok, thanks. I'll post a final message asking people to please express themselves (+1, / or -1)
15:36 Krock      you could set up a poll in the discussion and have the 3 options there in case they missed this meeting
15:38 [MTMatrix] <Zughy> I've tagged minetest/engine, I think it sends a notification to everyone (I hope)
15:39 [MTMatrix] <Zughy> about 13813, I definitely don't have the knowledge, so if you want to end the meeting I totally understand :) (since neither sfan nor srifqi are here)
15:41 Krock      replied there
15:42 Krock      I couldn't find anything helpful in the logs
15:43 erle       Krock the anisotropic filtering + GL_NEAREST thing is just undefined sadly and intel does it one thing, amd another and nvidia either like amd or maybe a third way. literally no good way to solve it.
15:44 erle       zughy is “internal discussion #71” a secret thing or do you have a link so others can see it?
15:44 ShadowBot  https://github.com/minetest/minetest/issues/71 -- make paths modifiable by hasufell
15:45 [MTMatrix] <Zughy> internal discussions can't be seen by non-staff members
15:45 [MTMatrix] <Zughy> e.g. security issues
15:49 Krock      as for the "One Approval" PRs - I will try to find some time next week to have a look at these, especially bugfixed
15:49 Krock      *bugfixes
15:54 erle       i have a topic. there are many things fixed in 5.8.0 that are security issues. they do not have CVEs.
15:55 erle       i can message the debian or other teams about them. this will lead to CVEs. will anyone be upset if i say “this commit fixes a security vulnerability” and then ppl create a CVE for it? the purpose is for distributors to update or patch minetest.
15:55 erle       e.g. obj/tga/bmp loader issues
15:56 erle       i think it is important to do this. ideally no one has a problem with me doing it, since the bugfixes are out, the discussions i am aware of happened in public, and minetest 5.8.0 will have the fixes.
15:56 erle       so the mitigation is “update to the latest version”
15:56 Krock      from what I've seen, many of those fixes already made their way into upstream (irrlicht); and even originated from there
15:56 erle       yes, but they have no CVEs
15:56 erle       and the CVEs will at least apply to minetest and irrlicht
15:56 rubenwardy which things in particular?
15:56 erle       i see CVEs as a stick to point linux distributions with it to update minetest
15:57 Krock      I don't understand what you're trying to achieve with CVE's
15:57 erle       tell distributions that distribute minetest <5.8.0 to update or backport fixes
15:57 erle       (hopefully update)
15:57 rubenwardy it's a workaround to Debian's kink for outdated software. If you have a CVE then they'll patch older versions
15:58 erle       debian is actually very good with this. i mostly mean random distributions. they will get flagged if CVes apply to them.
15:58 erle       in some scanners (that they hopefully use)
15:58 erle       as i said, i see it as a tool to make them update faster
15:58 erle       so anyone has an issue with me telling them those commits and what the problem is? if so, before release or after?
15:59 Krock      it's best to release first and then take care about distributing it
15:59 Krock      (at least in my opinion)
15:59 erle       i mean a github security advisory can also be created, but i can not do it
15:59 erle       (i can write text, but not create it i think)
16:00 rubenwardy just looked through the changelog and can't see any security related fixes there
16:00 rubenwardy unless it's in "inventory code fixes" or "many various code fixes"
16:00 erle       prob because they occured in irrlichtmt
16:00 Krock      the changelog only contains information interesting to players from modding and gameplay perspective
16:01 erle       yeah
16:01 erle       security stuff can go in there, but why should it?
16:01 erle       it's not like it changes much for legit usage
16:01 Desour     the irrlicht file loader fixes were not the only security fixes. there were also for example the inventory uaf fixes
16:02 rubenwardy we have https://github.com/minetest/minetest/security/advisories and should make sure to use it
16:02 Krock      security fixes in Minetest are by far nothing unusual. many of those were simply fixed by a single commit without gaining any specific interest
16:02 erle       yes
16:02 Desour     I somewhat doubt you can easily find all security related changes. and even if you did, I'm very sure we're still vulnerable due to other bugs
16:02 erle       yeah so?
16:03 erle       what does that change? i know some. probably at least 5 or 6 or so that were fixed in 5.8.0 and other software sharing a lineage (i.e. stemming from irrlicht, or irrlicht itself) may have it.
16:03 erle       debian is good at figuring out what stuff that applies to, but you have to tell them
16:04 erle       like, give their security team a PDF parser bug and they can tell you which library and reader has it
16:04 erle       the stuff i saw fixed was stuff irrlicht just did wrong for a long time
16:06 Krock      any other pressing topics?
16:08 Desour     I don't know a reason why I should have anything against someone reporting about security fixes somewhere. but we shouldn't do it officially, as that would lead to a false sense of completeness, imho
16:08 erle       lol
16:08 erle       Desour sorry, but what makes you think that creating a report about fixed security issues creates the impressin that ”these are all of them”?
16:09 erle       impression
16:10 erle       i mean minetest is not exactly the kind of software that is ever “done”. and even if it were, it would be an enormous amount of work to make it provably secure (this is true for any non-trivial c++ project).
16:10 Desour     erle: well, if we give them a list, they might get the idea to name their version with the few backports as "minetest with all the security bug fixes"
16:11 erle       no, what happens in reality is that they name it like 5.6.1debian+3 or whatever (i.e. append a suffix)
16:11 erle       and that happens regardless of who does it
16:12 erle       distributions apply patches pretty liberally to software anyway
16:12 rubenwardy I definitely think we should be reporting actual vulnerabilities on  https://github.com/minetest/minetest/security/advisories  , it's best practice and important to ensure users are secure
16:12 erle       btw, i do agree with rubenwardy: the security advisories exist, ideally stuff should be listed there.
16:13 erle       i still remember when i asked how to set the main menu from a mod lol https://github.com/minetest/minetest/security/advisories/GHSA-663q-pcjw-27cc
16:15 erle       anyway i'll try to prepare a list and post it here first
16:17 Krock      okay then. Moving it to the past meetings
16:20 Krock      done. thanks for participating. Until next time we'll hopefully have a fix for Android ready to ship 5.8.0
16:20 erle       Desour btw issues i could see with reporting security issues elsewhere may be a) unduely creating the impression minetest is more insecure than it was (you know my language is not too friendly at times) b) doing duplicate work that is already done elsewhere (e.g. if someone was already preparing security advisories for after release) c) it might be a good idea to collaborate to account for every possibility and not misinterpret
16:20 erle       something that is not security-relevant as security-relevant … there might be more reasons.
16:21 erle       Krock the android black screen issue you mean?
16:21 Krock      erle: how did you come up with that? I meant the stack splitting issue
16:22 Krock      (see first topic in the meeting)
16:22 erle       Krock lack of context probably (i have a smaller working memory than others and this makes me a dumbo at times)
18:48 MTDiscord  <josiah_wi> Good to see https://github.com/minetest/minetest/issues/13962.
18:53 Krock      will merge #13978 and #13976 in 15 minutes
18:53 ShadowBot  https://github.com/minetest/minetest/issues/13978 -- Add new flags to minetest.features for 5.8.0 features by Desour
18:53 ShadowBot  https://github.com/minetest/minetest/issues/13976 -- Fix UB in modulo360f (bugfix for #13960) by superfloh247
19:07 Krock      merging
19:09 Krock      done
20:00 srifqi     hello. sorry, i missed the meeting
20:00 srifqi     regarding #13872, i still can not find a way to restore the behaviour. the solution that i might found later might be a hack, rather than a proper changes
20:00 ShadowBot  https://github.com/minetest/minetest/issues/13872 -- Formspec: Allow multiple mouse button click for touch-screen by srifqi
20:00 srifqi     but that comes with a big if (when i found it)
20:02 erle       srifqi bisect and revert is impossible?
20:03 erle       ig that would probably unfix #13146 if the assumption is correct that it was that
20:03 ShadowBot  https://github.com/minetest/minetest/issues/13146 -- Inventory mouse shortcut improvements by OgelGames
20:04 srifqi     the cause is the inventory improvement PR #13146
20:04 ShadowBot  https://github.com/minetest/minetest/issues/13146 -- Inventory mouse shortcut improvements by OgelGames
20:04 erle       yeah, that
20:04 srifqi     my bad for not testing thoroughly on touch-screen/Android
20:05 erle       “This is a massive improvement and one of the best features in years.”
20:05 erle       i think given the general state of minetesting this is just bound to happen, especially with such a cool thing
20:06 rubenwardy the inventory movement system needs to be unit tested completely as every single change to it results in regressions
20:06 erle       like i would not say it is your fault personally
20:06 erle       yeah, basically what rubenwardy says
20:06 erle       i wonder if the equivalence here is fishy actually hehe https://github.com/minetest/minetest/pull/13976/files
20:07 srifqi     the proper internal state suggested by Krock might require a big change/changes in lot of place i guess. the hack might be to just add somewhat working internal state only for touch-screen devices (using compiler flag)
21:00 srifqi     oh, i also have posted a temporary solution in #13822 in (the worst) case that nobody has found a solution
21:00 ShadowBot  https://github.com/minetest/minetest/issues/13822 -- Regression in splitting inventory stacks on Android
21:00 erle       nothing lasts as long as a temporary solution though
21:00 erle       and also that's more like an inconvenient workaround