Minetest logo

IRC log for #minetest-dev, 2021-01-22

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
02:56 olliy joined #minetest-dev
05:00 MTDiscord joined #minetest-dev
06:53 YuGiOhJCJ joined #minetest-dev
08:00 ShadowNinja joined #minetest-dev
08:41 calcul0n_ joined #minetest-dev
08:53 Wuzzy joined #minetest-dev
08:59 Wuzzy #10693
08:59 ShadowBot https://github.com/minetest/minetest/issues/10693 -- Builtin translate (2nd attempt) by Wuzzy2
09:04 appguru joined #minetest-dev
09:07 mizux joined #minetest-dev
09:09 YuGiOhJCJ joined #minetest-dev
09:15 Zughy[m]1 joined #minetest-dev
09:15 _Zaizen_[m] joined #minetest-dev
09:15 BakerPrime_ joined #minetest-dev
09:40 proller joined #minetest-dev
10:10 LoneWolfHT joined #minetest-dev
10:52 _Zaizen_[m] joined #minetest-dev
10:52 Newbyte joined #minetest-dev
10:52 kb1000 joined #minetest-dev
10:52 zughy[m] joined #minetest-dev
10:52 giov4[m] joined #minetest-dev
10:52 Zughy[m]1 joined #minetest-dev
11:08 Fixer joined #minetest-dev
12:50 Zughy[m]1 can I complaing about how the 2 new core devs did basically nothing? Last Pyrollo MT activity was December 5th, last review November 23th. V-rob has been focusing on his own things, great, but he reviewed 3 PRs in 3 months. MT has a huge problems with PRs and issues, and they're definitely ignoring it. So, for instance, why Pyrollo is a core dev in the first place? I've never seen him here
12:51 Zughy[m]1 * can I complain about how the 2 new core devs did basically nothing? Last Pyrollo MT activity was December 5th, last review November 23th. V-rob has been focusing on his own things, great, but he reviewed 3 PRs in 3 months. MT has a huge problems with PRs and issues, and they're definitely ignoring it. So, for instance, why Pyrollo is a core dev in the first place? I've never seen him here
12:51 Zughy[m]1 * can I complain about how the 2 new core devs did basically nothing? Last Pyrollo MT activity was December 5th, last review November 23th. V-rob has been focusing on his own things, great, but he reviewed 3 PRs in 3 months. MT has a huge problem with PRs and issues, and they're definitely ignoring it. So, for instance, why Pyrollo is a core dev in the first place? I've never seen him here
12:52 sfan5 FYI matrix sends the whole message again when you edit so it just looks like spam from this side
12:53 Zughy[m]1 oh, I'm sorry for that. I'll leave the mistakes next time
12:58 celeron55 eh what, are you saying it would be better to not have v-rob and pyrollo as core devs than to have them doing whatever they are doing?
13:00 Zughy[m]1 I'm saying it doesn't seem Pyrollo is doing anything when he's fresh meat
13:01 Zughy[m]1 and that v-rob could review more things
13:01 sfan5 to the point: aside from "basically nothing" being way too harsh, there is no required minimum level of work you have to put into to be considered an useful addition to the team of coredevs. Also you could say the same about some existing coredevs.
13:03 sfan5 There are bigger problems than PRs and issues (for example that the proposal from months ago that could help here has not been properly discussed and put into action) but either way you can't blame this on two newcomers.
13:06 rubenwardy if you start requiring minimum hours, then no one will want to become a dev
13:09 celeron55 instead of complaining, you should try to help (or continue trying to help) core devs with the issue and PR problem, and/or maybe aim for becoming a core dev yourself
13:09 MTDiscord <w​war> 🍿
13:10 rubenwardy there's value in pointing out issues, but only if systematic rather than individual lack of time
13:20 freshreplicant[m joined #minetest-dev
13:21 Zughy[m]1 <sfan5 "There are bigger problems than P"> wait, which one?
13:22 Zughy[m]1 <rubenwardy "if you start requiring minimum h"> yeah, for sure, this is not a company
13:25 sfan5 can't find the discussion now but the proposal was roughly that upon a PR being opened the devs have 1 week to reject or accept the concept
13:25 Zughy[m]1 <celeron55 "instead of complaining, you shou"> but you see, a normal contributor can't help in full, because it's still up to core devs to accept or reject a PR (and I won't ever be a core dev, I don't have an inch of your knowledge). I could make 10 PR in one day, but if no one checks them out (it's just an example) they'll lie there forever
13:27 Zughy[m]1 <sfan5 "can't find the discussion now bu"> it sounds pretty suicidal
13:27 rubenwardy <sfan5> can't find the discussion now but the proposal was roughly that upon a PR being opened the devs have 1 week to reject or accept the concept
13:27 rubenwardy This was part of the roadmap proposal
13:28 sfan5 Zughy[m]1: why is that?
13:29 sfan5 rubenwardy: these warnings are new https://0x0.st/-inl.txt
13:30 Zughy[m]1 if there's a period where only one core dev is present, that guy has to judge every new PR coming by. I saw weeks where there was at least one new PR every day. That could stress the guy and bring to rushed choices
13:30 rubenwardy that'll be because the file has changed, I haven't touched that method
13:30 rubenwardy but it should be fixed anyway
13:30 rubenwardy unless having override in any method in a class enables that warning
13:31 sfan5 well there has to be some kind of consensus, if there's only one coredev available for the entire week a PR cannot be accepted or rejected
13:31 rubenwardy there are some projects that close PRs if they're not linked to an accepted issue
13:32 Zughy[m]1 imho, it'd be better to say: "roadmap -> no -> one week time, where if no one says nothing it's automatically a no"
13:33 rubenwardy #10536
13:33 ShadowBot https://github.com/minetest/minetest/issues/10536 -- Add roadmap by rubenwardy
13:33 Zughy[m]1 so that if a core dev _really_ wants that feature, they can say "fine, let's do that". The difference is that instead of starting from "who knows" starts from "no"
13:35 rubenwardy So:
13:35 rubenwardy - Bug fixes are exempt from the roadmap, they're always prioritised
13:35 rubenwardy - Roadmap PRs are automatically accepted
13:35 rubenwardy - Non-roadmap PRs must be for an accepted issue or be accepted within a week, else they are closed
13:35 rubenwardy where "accepted" means "allowed to be left open"
13:36 Zughy[m]1 it'd be nice to change the PR form, having check boxes corresponding to the roadmap, like "goal1", "goal2", "bugfix" and "other", with a warning on the last one
13:38 Zughy[m]1 <rubenwardy "where "accepted" means "allowed "> would it be to harsh if "accepted" would mean "I'll take care of it"?
13:38 sfan5 is the assumption here that only one person would be responsible for accepting it?
13:38 rubenwardy well, if you accept a non-roadmap PR you should probably review it
13:38 Zughy[m]1 it may help the core dev to understand whether they have the time
13:39 sfan5 I fear that "we want this in principle but I certainly do not have time to review it" cases will be a problem if done like that
13:39 rubenwardy yeah
13:40 Zughy[m]1 exactly, so that if you don't retain that PR THAT important, you'll just ignore it. And the fault won't be yours, because the roadmap is clear
13:40 Zughy[m]1 with ignore I mean that it'll be closed
13:41 calcul0n__ joined #minetest-dev
13:41 Zughy[m]1 this could also push contributors on working on bugfixes instead (about 320 right now)
13:46 * Zughy[m]1 sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/ZMBicjaCVjfcxpVmHaqxRqru/message.txt >
13:47 rubenwardy source of that message:
13:47 rubenwardy Right, thoughts about the last comment of the roadmap PR? I quote:
13:47 rubenwardy "what is going to happen to old PRs not aligning with the roadmap
13:47 rubenwardy 1. closed and sayounara
13:47 rubenwardy 2. kept and merged on the go
13:47 rubenwardy 3. kept and merged when/if the next roadmap aligns with them (please no)
13:47 rubenwardy "
13:48 rubenwardy I think they should be marked as Roadmap where relevant, and non-roadmap ones would not be subject to the 1 week thing - but can be closed if necessary.  Kinda offputting for contributors though
13:48 sfan5 reevaluated by whoever looks at them and then either 1 or 2
13:48 rubenwardy yeah
13:50 sfan5 >{"address":"127.0.0.1","port":30000.0}
13:50 sfan5 floating point ports
13:51 sfan5 such advanced technology
13:51 celeron55 frankly if there's not at least someone crying about something, the change wasn't enough
13:51 celeron55 it's like if you brush your teeth and the mirror doesn't get messy, you didn't brush them properly
13:53 mizux joined #minetest-dev
13:53 rubenwardy Lua numbers are always floats, it sucks a bit
13:53 rubenwardy in future versions you do have integers
13:54 sfan5 yeah but write_json could make a difference between 30 and 30.1 just like print() does
13:54 celeron55 i think the most important effect of the proposed method is that it forces communication before making a PR, you can't just fire and forget, so hopefully it gives more value to PRs that way for both contributors and core devs
13:59 rubenwardy yeah
13:59 rubenwardy Should the port be floored (?) when saving and loading then?
14:00 rubenwardy or maybe  assert(math.floor(x) == x)
14:01 sfan5 not that important
14:02 celeron55 could make more problems
14:38 MTDiscord <w​war> > it's like if you brush your teeth and the mirror doesn't get messy, you didn't brush them properly Lol 🤣
14:39 rubenwardy merging #10085 and #10845 in 10
14:39 ShadowBot https://github.com/minetest/minetest/issues/10085 -- Use JSON for favorites, move server list code to Lua by rubenwardy
14:39 ShadowBot https://github.com/minetest/minetest/issues/10845 -- Remove dead code by rubenwardy
15:10 Krock would it make sense to arrange a meeting tomorrow?
15:10 rubenwardy yeah definitely
15:11 Krock okay, then I'll prepare the wiki and write an /engine/ post
15:18 Krock https://dev.minetest.net/Meetings#2021-01-23
15:22 pgimeno <rubenwardy> in future versions you do have integers  <-- in LuaJIT too
15:23 pgimeno what are the cons of dropping Lua and supporting only LuaJIT?
15:25 pgimeno I believe it's an option that should be given serious consideration
15:26 sfan5 uh
15:26 sfan5 I'm pretty sure luajit doesn't have an integer type like 5.3
15:27 sfan5 but it can internally store integers for performance reasons
15:27 pgimeno maybe not equivalent, but in LuaJIT you can write: a = 1LL
15:27 sfan5 > =type(1LL)
15:27 sfan5 cdata
15:27 pgimeno it's a ctype, i.e. FFI-related
15:27 pgimeno yes
15:27 pgimeno cdata*
15:28 pgimeno and you can add them and convert number to integer and all that
15:29 pgimeno there are many servers that can't run on plain Lua for performance reasons
15:30 pgimeno builtin and the API can benefit from depending on LuaJIT
15:30 sfan5 how?
15:32 pgimeno https://notabug.org/pgimeno/ffi_accel <-- this is a hack to speed up things, but without the hack, it can be much faster
15:33 pgimeno using FFI functions doesn't need switching to interpreted mode, they can be compiled
15:34 sfan5 since non-ffi needs to be supported anyway (it might not be available) we don't need to drop plain Lua support for that
15:35 pgimeno FFI not available? why?
15:35 pgimeno maybe you're confusing JIT with FFI?
15:35 sfan5 does it work all platforms luajit works on?
15:35 pgimeno yes
15:35 pgimeno JIT doesn't, but FFI does
15:36 sfan5 does it work on platforms where you need to disable JIT due to codesigning constraints (iOS)?
15:36 pgimeno yes
15:36 pgimeno it runs in interpreted mode
15:36 pgimeno sadly, in interpreted mode, FFI is actually slower
15:38 pgimeno https://love2d.org/forums/viewtopic.php?f=4&amp;t=83992&amp;p=237538#p237538
15:46 sfan5 hm
16:30 rubenwardy easy PR to review, fixes pet peeve:   #10838
16:30 ShadowBot https://github.com/minetest/minetest/issues/10838 -- Do not close game on escape in error windows by yamanq
16:34 Zughy[m]1 yes please, it's obnoxious
16:40 fluxflux joined #minetest-dev
17:35 calcul0n joined #minetest-dev
17:42 Fleckenstein joined #minetest-dev
18:03 tezcatli joined #minetest-dev
18:42 homthack joined #minetest-dev
19:26 proller joined #minetest-dev
19:44 Wuzzy rubenwardy: can I ignore the FS() in favor of F(S())? It will require everyone to update their string-collecting scripts which we will probably forget anyway... :/
19:44 rubenwardy surprised that doesn't support it already?
19:44 rubenwardy if it doesn't work that way, sure
19:45 rubenwardy I'll also have to update  conquer and my other mods :'(
19:45 rubenwardy well actually - shouldn't the script be version controlled in Minetest utils?
19:45 Wuzzy we dont have any official string-collecting script yet
19:46 Wuzzy rubenwardy: I recommend this script btw: https://github.com/minetest-tools/update_translations
19:46 Wuzzy I think this script might actually be good enough for inclusion. maybe not 100% perfect but better than nothing
19:46 Wuzzy I don't know if Python can be accepted into utils, tho
19:55 rubenwardy well, perhaps it could be another repo
20:04 Wuzzy 🙁
20:04 Wuzzy Why making things so complicated?
20:04 Wuzzy everyone will ignore this repo then
20:04 Wuzzy the bash-completion nonsense can be removed anyway
20:05 rubenwardy there did use to be python scripts in utils
20:12 sfan5 there is a python script in util/ right now, but that's dev only and not needed by users
20:31 tezcatli joined #minetest-dev
20:32 rubenwardy where does word wrap in StaticText come from?
20:32 rubenwardy It's quite broken
20:32 rubenwardy for example, it doesn't support Windows new lines and the support for unicode hyphens is wrong
20:34 rubenwardy OK, from IRrlicht
20:34 rubenwardy that explains it
20:37 rubenwardy It also has an if-statement for is   RightToLeft, and duplicates the code on each side
20:43 homthack joined #minetest-dev
20:45 rubenwardy oh right, it wraps in a direction direction but the text is stored as is
20:45 rubenwardy that's weird
20:45 rubenwardy RTL should still use the same memory layout, just be rendered the opposite way...
20:46 rubenwardy Minetest doesn't set RightToLeft to true, so I might delete it for now
21:05 absurb joined #minetest-dev
23:19 fluxflux_ joined #minetest-dev

| Channels | #minetest-dev index | Today | | Google Search | Plaintext