| 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 |
<wwar> ? |
| 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 |
<wwar> > 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&t=83992&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 |
