| Time |
Nick |
Message |
| 00:26 |
|
appguru joined #minetest-dev |
| 00:42 |
|
Noisytoot joined #minetest-dev |
| 03:02 |
|
behalebabo joined #minetest-dev |
| 04:19 |
|
v-rob joined #minetest-dev |
| 05:00 |
|
MTDiscord joined #minetest-dev |
| 05:48 |
|
calcul0n joined #minetest-dev |
| 06:33 |
|
izzyb joined #minetest-dev |
| 09:22 |
|
Warr1024 joined #minetest-dev |
| 09:46 |
|
Warr1024 joined #minetest-dev |
| 10:18 |
sfan5 |
~tell appguru varargs has limits so that's not the best idea |
| 10:18 |
ShadowBot |
sfan5: OK. |
| 10:37 |
|
appguru joined #minetest-dev |
| 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:10 |
|
imi joined #minetest-dev |
| 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:24 |
|
Desour joined #minetest-dev |
| 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:01 |
|
appguru joined #minetest-dev |
| 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 |
|
grorp joined #minetest-dev |
| 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 |
|
appguru joined #minetest-dev |
| 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) |
| 17:14 |
|
appguru joined #minetest-dev |
| 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 |
| 19:56 |
|
srifqi joined #minetest-dev |
| 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 |
| 21:25 |
|
appguru joined #minetest-dev |
| 21:34 |
|
v-rob joined #minetest-dev |
| 22:27 |
|
diceLibrarian joined #minetest-dev |
| 22:31 |
|
appguru joined #minetest-dev |
| 22:41 |
|
v-rob joined #minetest-dev |
| 23:24 |
|
YuGiOhJCJ joined #minetest-dev |
| 23:32 |
|
panwolfram joined #minetest-dev |
