| Time |
Nick |
Message |
| 00:03 |
Megaf |
[23:05:43] <celeron55> it pretty much has to be a condition that silently kills a thread without stopping the rest of the program |
| 00:03 |
Megaf |
OOM? |
| 00:04 |
est31 |
No! |
| 00:04 |
est31 |
threads can't be killed because of the OOM killer |
| 00:04 |
est31 |
the OOM killer kills whole processes, and not single threads |
| 00:04 |
est31 |
and, it only exists on linux afaik |
| 00:04 |
est31 |
not on windows |
| 00:05 |
Megaf |
well, the bug is creepy and weird, so, who knows |
| 00:06 |
est31 |
celeron55 is right it sounds like a horror movie for programmers |
| 00:06 |
Megaf |
but it would be nice knowing what DB backend those servers are using |
| 00:15 |
|
afflatus left #minetest-dev |
| 00:33 |
|
STHGOM joined #minetest-dev |
| 01:20 |
|
fling joined #minetest-dev |
| 01:52 |
|
Tmanyo joined #minetest-dev |
| 02:02 |
|
Grandolf joined #minetest-dev |
| 02:12 |
|
Grandolf joined #minetest-dev |
| 02:21 |
|
reg7777 joined #minetest-dev |
| 03:10 |
|
Puka_ joined #minetest-dev |
| 03:14 |
|
Rate85 joined #minetest-dev |
| 03:15 |
|
Rate85 left #minetest-dev |
| 03:18 |
|
Rate85 joined #minetest-dev |
| 03:18 |
|
Rate85 left #minetest-dev |
| 03:25 |
OldCoder |
|
| 03:25 |
OldCoder |
https://github.com/minetest/minetest/pull/4170 |
| 03:25 |
OldCoder |
https://github.com/minetest/minetest/issues/4171 |
| 03:25 |
OldCoder |
Pull Request and associated Issue, submitted as suggested ^ |
| 03:25 |
OldCoder |
|
| 03:35 |
hmmmm |
why isn't sapier the one making a pull request then? |
| 03:35 |
hmmmm |
also that doesn't fix any problems, that just stops trying to resend a packet that never gets acked |
| 03:36 |
hmmmm |
the correct solution would be to find out why that packet is never getting acked |
| 03:36 |
hmmmm |
because now with that "fix", reliable packets aren't guaranteed delivery anymore. AKA they're not reliable. |
| 03:36 |
hmmmm |
also could you PLEASE stop sending blank lines? seriously |
| 03:45 |
est31 |
hmmmm, after some time the peer is expected to time out |
| 03:46 |
est31 |
apparently that doesnt happen for some reason |
| 03:46 |
est31 |
but I am really wondering why |
| 03:46 |
est31 |
I'm rejecting my +0.5 I gave |
| 03:46 |
OldCoder |
hmmmm, Sapier has abandoned the project, correct? |
| 03:46 |
hmmmm |
i don't know |
| 03:47 |
OldCoder |
And, complete solution or not, without this patch... |
| 03:47 |
OldCoder |
It's been over a year, hmmmm |
| 03:47 |
OldCoder |
And, complete solution or not, without this patch... |
| 03:47 |
OldCoder |
MT isn't even runnable for some server hosts |
| 03:47 |
hmmmm |
really? |
| 03:47 |
OldCoder |
I was panicked in late 2014 |
| 03:47 |
hmmmm |
which server hosts are these, because I would think that if it were readily reproducible, there'd be no issue with fixing it |
| 03:47 |
OldCoder |
I'd spent 2 years on the project, and suddenly my worlds didn't work |
| 03:47 |
OldCoder |
There were about 4 at the time |
| 03:48 |
OldCoder |
Presently, I'm told there are more; Fixer seems to know who they are |
| 03:48 |
OldCoder |
One of them you know well... |
| 03:48 |
OldCoder |
I could be mistaken, ask Fixer, but supposedly Xanadu is affected |
| 03:48 |
OldCoder |
Readily reproducible BTW meant nothing in this case |
| 03:48 |
OldCoder |
I came up with my own fix, then Zeno` did... |
| 03:49 |
OldCoder |
But Sapier's fix was clearly the simplest and the safest |
| 03:49 |
OldCoder |
|
| 03:50 |
hmmmm |
i'm sure. |
| 03:50 |
est31 |
hmmmm, read the code |
| 03:50 |
est31 |
the peers get removed |
| 03:51 |
est31 |
its not that it starts not caring if there is no ack for a reliable packet |
| 03:51 |
est31 |
the thing is however |
| 03:51 |
hmmmm |
i read the code |
| 03:51 |
hmmmm |
ohh |
| 03:51 |
est31 |
why does the client not time out already above |
| 03:51 |
hmmmm |
whoops, i missed that, didn't realize it added to timeoutted_peers |
| 03:52 |
est31 |
so the patch is generally okay |
| 03:52 |
hmmmm |
needs the code style fixed though |
| 03:52 |
est31 |
just there is basically a bug client side |
| 03:53 |
est31 |
because it isnt because of a network problem |
| 03:53 |
est31 |
if it were, the client would time out normally |
| 03:53 |
est31 |
it calls isTimedOut on the client above |
| 03:55 |
hmmmm |
is that really what isTimedOut supposed to do |
| 03:56 |
OldCoder |
It's been a year, est31, so more time for a number of people to weigh in is fine. But I've posted this PR because server owners demanded it. |
| 03:56 |
est31 |
OldCoder, these are political arguments you bring |
| 03:56 |
OldCoder |
Hardly |
| 03:56 |
OldCoder |
They are practical |
| 03:56 |
est31 |
"server owners demand it" |
| 03:56 |
est31 |
that is a political argument |
| 03:56 |
OldCoder |
Oh? Is it political if... |
| 03:56 |
OldCoder |
server owners cannot run their worlds? |
| 03:56 |
OldCoder |
At all? |
| 03:57 |
OldCoder |
In my case, the logs reached, literally, 5 gigabytes of nothing but "RESEND RELIABLE" |
| 03:57 |
hmmmm |
there are two other solutions you mentioned |
| 03:57 |
OldCoder |
This patch rescued two years, at the time, of effort |
| 03:57 |
hmmmm |
why aren't those in a PR? |
| 03:57 |
hmmmm |
why hasn't this been an active issue if it's as critical as you say it is? why is the only activity happening now |
| 03:58 |
OldCoder |
hmmmm, my own patch and Zenos` are not applicable... they were to the same code and Sapier's patch is superior... |
| 03:58 |
OldCoder |
Regarding your 2nd question... |
| 03:58 |
hmmmm |
why don't you let us be the judge of which piece of code is 'superior' |
| 03:58 |
OldCoder |
There is no need to rush the discussion |
| 03:58 |
OldCoder |
Hang on... |
| 03:58 |
est31 |
Well the thing is, the current behaviour is just as fine as well |
| 03:58 |
OldCoder |
est31, Hm? Go on |
| 03:58 |
est31 |
but out of some apparent reason the client does not send ack packets |
| 03:58 |
OldCoder |
Gigabytes of RESEND RELIABLE messages are hardly fine |
| 03:59 |
est31 |
OldCoder, agreed but I am not talking about that |
| 03:59 |
OldCoder |
hmmmm, the problem has apparently increased as of 0.4.14 |
| 03:59 |
est31 |
I am talking about the patch |
| 03:59 |
est31 |
the behaviour its adding should not be needed |
| 03:59 |
OldCoder |
Which is the reason I have been asked to submit it |
| 03:59 |
OldCoder |
est31, yes, there is an underlying problem |
| 03:59 |
OldCoder |
Go on |
| 04:00 |
OldCoder |
Actually, isn't the issue... |
| 04:00 |
est31 |
hmmmm, isTimedOut is supposed to check when the client has last sent a packet |
| 04:00 |
OldCoder |
Not that the client does not send ACK packets, but that a queue fills up... |
| 04:00 |
OldCoder |
faster than expected and than can be handled? |
| 04:00 |
est31 |
and if that's too far in the past, it considers the connection to be timed out |
| 04:00 |
est31 |
OldCoder, in theory this should be called very rarely |
| 04:01 |
est31 |
not millions of times often |
| 04:01 |
OldCoder |
In practice, it's millions of times |
| 04:01 |
OldCoder |
Ninja |
| 04:01 |
OldCoder |
Right, again, there is an underlying problem |
| 04:01 |
est31 |
OldCoder, have you customized your step maybe? |
| 04:01 |
OldCoder |
est31, go on; explain? |
| 04:01 |
OldCoder |
Customized what? |
| 04:01 |
hmmmm |
est31: from what I am seeing it checks the last time a packet was received from the client |
| 04:01 |
est31 |
it can be that if you decrease the server step value that then this gets called more often |
| 04:01 |
est31 |
hmmmm, yes |
| 04:02 |
est31 |
hmmmm, so if there has been a packet received from the client it means there is no network problem |
| 04:02 |
hmmmm |
what if the client thinks the server received the ack though |
| 04:02 |
hmmmm |
and it just continues sending packets with newer acks |
| 04:02 |
OldCoder |
Note: I've emailed Sapier and asked him to discuss this if he can |
| 04:03 |
hmmmm |
also please hold on i'm reading code at the same time i'm talking |
| 04:03 |
est31 |
hmmmm, yeah something like that may be the underlying theory |
| 04:03 |
OldCoder |
est31, no, I'm using virgin MT except for your own password patch and this one |
| 04:03 |
hmmmm |
ok |
| 04:03 |
hmmmm |
from what I'm understanding |
| 04:03 |
est31 |
OldCoder, ok |
| 04:04 |
hmmmm |
ConnectionReceiveThread::receive() loops around getting data from the UDP socket, parses the lowest-level protocol headers, does some peer ID accounting |
| 04:04 |
* OldCoder |
theory in 2014 was that mobile triggered this. He does not know why 0.4.14 is more of an issue. |
| 04:04 |
hmmmm |
like if it's not already there then it'll create a new peer, get that peer's addr, and so on |
| 04:04 |
hmmmm |
directly after that set of actions, resetTimeout is called |
| 04:05 |
hmmmm |
no ack logic is done before the recv timeout is reset |
| 04:05 |
hmmmm |
in other words my theory is probably the right one |
| 04:05 |
OldCoder |
Simple to test, hmmmm ? Is there a patch I could give to Fixer... |
| 04:05 |
OldCoder |
to pass on to TenPlus1 and others to debug this? |
| 04:05 |
OldCoder |
A diagnostic patch, as opposed to a corrective one, would be fine |
| 04:08 |
est31 |
I've done connection.cpp diagnostics last week already |
| 04:08 |
est31 |
spent > 10 hours with a simple bug |
| 04:08 |
est31 |
no thanks |
| 04:08 |
|
Zeno` joined #minetest-dev |
| 04:08 |
est31 |
but generally I like the PR |
| 04:08 |
|
Zeno` joined #minetest-dev |
| 04:09 |
est31 |
just it would be bad if the underlying client bug would not be fixed |
| 04:09 |
est31 |
maybe its also a server bug in some way |
| 04:09 |
OldCoder |
Zeno`, I have submitted Sapier's network patch; you recall working on this a year ago, I assume |
| 04:09 |
OldCoder |
The primary concern is that there may be an underlying bug |
| 04:09 |
Zeno` |
yes, I don't recall the details though |
| 04:09 |
OldCoder |
That the patch does not address |
| 04:09 |
OldCoder |
https://github.com/minetest/minetest/pull/4170 |
| 04:10 |
OldCoder |
It was essentially that server owners had 5,000,000 RESEND RELIABLE messages at a time |
| 04:10 |
OldCoder |
It made for tedious reading :-) |
| 04:10 |
Zeno` |
Yeah I remember that, I just don't remember the details of the patch (looking now) |
| 04:10 |
hmmmm |
est31: I really don't know a whole lot about connection.cpp; both the server and client are responsible for acking eachother's reliable packets, right? |
| 04:10 |
hmmmm |
or does a reliable packet from the server require an ack from the client but not vice-versa? |
| 04:11 |
hmmmm |
or something other like that |
| 04:11 |
est31 |
hmmmm, yes |
| 04:11 |
est31 |
both need to ack |
| 04:11 |
hmmmm |
ook yeah |
| 04:11 |
est31 |
there is just receiving party and sending one |
| 04:12 |
est31 |
the only place connection.cpp really distinguishes between client and server is with peer ids |
| 04:12 |
hmmmm |
then imho the bug is that the case where: packets are indeed being sent, it's just that one of the packets aren't ever getting acked because the client thinks it did that already |
| 04:12 |
est31 |
the client peer id is set by the server, the server peer id is statically fixed |
| 04:12 |
hmmmm |
and right now this case isn't handled |
| 04:12 |
hmmmm |
then sapier's fix would be the right one |
| 04:12 |
hmmmm |
but i have nothing to compare it against |
| 04:13 |
OldCoder |
What would you be comparing? |
| 04:13 |
est31 |
the question is though whether the client omits an ack if it got a packet it already got before |
| 04:13 |
est31 |
or if it re-sends a second ack |
| 04:13 |
est31 |
which would be the right way to do it |
| 04:13 |
hmmmm |
shrug |
| 04:13 |
hmmmm |
Zeno: could I see your version of the fix for this? |
| 04:14 |
est31 |
line 2555 |
| 04:14 |
est31 |
/* seems like our ack was lost, send another one for a old packet */ |
| 04:16 |
Zeno` |
hmmmm, if I can find it |
| 04:16 |
Zeno` |
it was a long time ago |
| 04:16 |
hmmmm |
thanks |
| 04:17 |
|
Tmanyo joined #minetest-dev |
| 04:17 |
Zeno` |
from memory it was very similar to this PR |
| 04:17 |
hmmmm |
est31: hmmm pretty damning case for a bug on the client side then. |
| 04:18 |
est31 |
it might be that the underlying bug is now fixed even. |
| 04:18 |
est31 |
#4138 has caused RESEND RELIABLE behaviour |
| 04:18 |
ShadowBot |
https://github.com/minetest/minetest/issues/4138 -- Network: initialisation intolerant to packet reordering |
| 04:19 |
|
Tmanyo joined #minetest-dev |
| 04:19 |
est31 |
OldCoder, is the bug occuring with latest master servers? |
| 04:20 |
hmmmm |
he can't control the version of the clients connecting |
| 04:20 |
|
AnotherBrick joined #minetest-dev |
| 04:20 |
hmmmm |
prolly this is a new server paired with old clients |
| 04:20 |
est31 |
423d8c1b0d3841f6ce9756ab0d6b2e10408fc89b fixed the bug in the server |
| 04:20 |
OldCoder |
est31, what is a master server? |
| 04:20 |
est31 |
it was a server bug |
| 04:21 |
est31 |
OldCoder, its the server that manages the server list |
| 04:21 |
est31 |
OldCoder, servers.minetest.net |
| 04:21 |
OldCoder |
Ah... But, are there worlds on that server? Sorry, I would not know |
| 04:21 |
est31 |
but its unrelated to what we are discussing |
| 04:21 |
OldCoder |
O.K. |
| 04:22 |
kahrl |
"latest master" "server", not "latest" "master server" |
| 04:22 |
est31 |
oh |
| 04:22 |
est31 |
hehe |
| 04:22 |
hmmmm |
personally i feel like Connection is fucked |
| 04:23 |
hmmmm |
there's no way this bug and others is going to be fixed until it's rewritten |
| 04:23 |
Zeno` |
hmmmm, I can't find my patch (it was over a year ago and I don't seem to have pushed it anywhere) |
| 04:23 |
hmmmm |
might as well just patch it up |
| 04:23 |
est31 |
hmmmm> there's no way this bug and others is going to be fixed until it's rewritten |
| 04:23 |
est31 |
why |
| 04:23 |
hmmmm |
it's not like it's exactly some kind of artwork piece |
| 04:23 |
est31 |
I do agree its a blast site |
| 04:24 |
est31 |
but i think the discussion "lets repeal and replace every line of connection.cpp" is separate |
| 04:24 |
hmmmm |
right |
| 04:24 |
hmmmm |
my point is |
| 04:24 |
hmmmm |
manhours are best put into writing new code that is unit tested from the start, documented, and maintainable |
| 04:24 |
hmmmm |
not spending weeks on tracking down the root cause for bugs like this |
| 04:25 |
hmmmm |
so i approve of the way this patch solves the issue |
| 04:25 |
* OldCoder |
thinks the network rewrite discussion will be interesting |
| 04:25 |
hmmmm |
just... be sure to fix the style errors before merging |
| 04:25 |
est31 |
Nah, I disagree with that |
| 04:25 |
hmmmm |
maybe increase the reliable retry limit to 10 (linux's default is 15 for TCP actually) |
| 04:26 |
hmmmm |
est what part do you disagree with |
| 04:26 |
est31 |
its "lets piss on the wall because the dogs do it too and the building has to be re-built anyway" |
| 04:26 |
hmmmm |
i'm not gonna tell you how to spend your time, i'm just saying it's probably a lost cause |
| 04:26 |
OldCoder |
est31, the building needs to be occupied during renovations, true? |
| 04:26 |
OldCoder |
That is the key issue |
| 04:27 |
OldCoder |
If all of this code is going to go... |
| 04:27 |
OldCoder |
and, as many have said, it probably should go... |
| 04:27 |
OldCoder |
Things need to work in the interim |
| 04:27 |
hmmmm |
how many times has connection.cpp been patched with temporary workarounds |
| 04:27 |
hmmmm |
for bugs that people couldn't find the root cause of |
| 04:27 |
OldCoder |
Not so much in the past year? |
| 04:28 |
est31 |
In this case we can just simply add // in front of the place where we log the RESEND RELIABLE |
| 04:28 |
est31 |
OldCoder was complaining about RESEND RELIABLE using 5 gb of log place |
| 04:28 |
OldCoder |
Not a solution |
| 04:28 |
OldCoder |
It is not the disk space |
| 04:28 |
est31 |
if it doesnt get logged, there is no problem |
| 04:28 |
OldCoder |
It is the lockup |
| 04:28 |
OldCoder |
No, not true |
| 04:28 |
hmmmm |
.. |
| 04:28 |
hmmmm |
He's being sarcastic |
| 04:28 |
OldCoder |
It is close to a hard infinite loop |
| 04:28 |
OldCoder |
Hm? |
| 04:28 |
hmmmm |
est31: there is a clear happy medium |
| 04:28 |
OldCoder |
Folks, after 4 years, you know I'm literal |
| 04:29 |
hmmmm |
OldCoder: I don't really know you that well to be honest |
| 04:29 |
OldCoder |
Not the point... Not clear about how sarcasm would even be humorous here |
| 04:29 |
OldCoder |
Anyway, carry on |
| 04:29 |
hmmmm |
est31: in any case, I +1 the patch provided for my reasons provided |
| 04:30 |
est31 |
okay |
| 04:30 |
est31 |
what about the following: |
| 04:30 |
est31 |
we keep the PR open for two weeks, and give contributors a chance to find the actual cause of the bug |
| 04:30 |
est31 |
if they do, find |
| 04:30 |
est31 |
fine* |
| 04:30 |
est31 |
if they don't we merge it |
| 04:30 |
hmmmm |
well, OK |
| 04:31 |
hmmmm |
i'm fine with waiting |
| 04:31 |
OldCoder |
Ditto |
| 04:31 |
* OldCoder |
will notify Fixer the matter is under review |
| 04:31 |
est31 |
OldCoder, thats wrong |
| 04:31 |
est31 |
its no fix |
| 04:31 |
OldCoder |
est31, do you plan to look at this? Do you need a server that is manifesting the problem? |
| 04:32 |
OldCoder |
And what is no fix? |
| 04:32 |
est31 |
we are waiting for people to show up and fix it |
| 04:32 |
OldCoder |
"Fixer" is a name, BTW |
| 04:32 |
OldCoder |
Well, nobody will, you know thta |
| 04:32 |
OldCoder |
that * |
| 04:32 |
OldCoder |
If you do not plan to research this, what is the point? |
| 04:32 |
est31 |
and if not, we just add this patch and call it a day |
| 04:32 |
OldCoder |
O.K. |
| 04:32 |
OldCoder |
Seems pointless, but |
| 04:33 |
est31 |
not because the patch fixes the bug, but because it alleviates it |
| 04:33 |
* OldCoder |
is game |
| 04:33 |
OldCoder |
Right |
| 04:33 |
OldCoder |
But if you know nobody is going to go through the code... |
| 04:33 |
OldCoder |
what is the point? |
| 04:33 |
est31 |
it alleviates it better than commenting out the RESEND log message |
| 04:33 |
* OldCoder |
notes that he is being nice and not, apparently, sarcastic |
| 04:33 |
est31 |
but it is no actual fix |
| 04:33 |
OldCoder |
Right |
| 04:33 |
OldCoder |
And point? |
| 04:33 |
OldCoder |
"The show must go on" |
| 04:33 |
OldCoder |
The worlds need to run |
| 04:34 |
est31 |
OldCoder, because I do not like the attitude |
| 04:34 |
OldCoder |
"Attitude" ? There is none but your own... I've spoken simply and hmmm* is focused on the technical issues |
| 04:34 |
OldCoder |
You, he says, have been "sarcastic" |
| 04:34 |
OldCoder |
|
| 04:34 |
est31 |
lets merge this we do not know really whats happening but we dont care |
| 04:35 |
Zeno` |
+1 |
| 04:35 |
OldCoder |
Is that a proposal or sarcasm? |
| 04:35 |
OldCoder |
We do care |
| 04:35 |
est31 |
no |
| 04:35 |
est31 |
I forgot the " |
| 04:35 |
est31 |
its the attitude |
| 04:35 |
OldCoder |
See above |
| 04:35 |
est31 |
i am criticising |
| 04:35 |
est31 |
I know for you as server owner there is not much of a difference |
| 04:35 |
est31 |
but for me as developer there is |
| 04:35 |
OldCoder |
Sarcasm is "attitude". A workable fix is not. |
| 04:36 |
OldCoder |
If you wish to delay this for two weeks when you know there is no point to it... |
| 04:36 |
OldCoder |
Proceed |
| 04:36 |
OldCoder |
|
| 04:36 |
hmmmm |
|
| 04:36 |
est31 |
|
| 04:36 |
hmmmm |
|
| 04:36 |
est31 |
|
| 04:36 |
hmmmm |
|
| 04:36 |
est31 |
:) |
| 04:36 |
hmmmm |
we're coding in Whitespace |
| 04:36 |
OldCoder |
A marvelous tongue |
| 04:37 |
Zeno` |
My problem with this bug is that I tried for weeks to reproduce it (I still had mtzeno server at the time) and could not, so I couldn't really debug it. I tested this patch a year ago on my server and encountered no problems though (albiet the code path was never executed because I didn't have the issue) |
| 04:37 |
OldCoder |
Yes, it was oddly capricious |
| 04:37 |
OldCoder |
But quite real |
| 04:38 |
Zeno` |
I see that quite a few servers are experiencing it lately though |
| 04:38 |
OldCoder |
Hm... a moderate number |
| 04:38 |
OldCoder |
Not sure I'd say "quite a few" |
| 04:38 |
Zeno` |
Ok, moderate |
| 04:38 |
OldCoder |
But the issue needs to be addressed |
| 04:38 |
est31 |
OldCoder, I believe that sapier hasn't proposed this patch to be added to git master either |
| 04:38 |
OldCoder |
est31 wishes to delay the formal fix for two weeks... |
| 04:39 |
OldCoder |
est31, what is your point? He has left MT |
| 04:39 |
Zeno` |
But I've seen the issue discussed in -project by more than one person in the last aprrox. month |
| 04:39 |
OldCoder |
He told me to submit it |
| 04:39 |
OldCoder |
Anyway, it seems to be settled... |
| 04:39 |
OldCoder |
est31 wishes, I'm told, to be sarcastic (sorry, I have difficulty detecting that) and to delay the fix for two weeks... |
| 04:40 |
hmmmm |
Zeno`: Did you try connecting with an older client?? |
| 04:40 |
OldCoder |
for no purpose. But if it will settle things, the compromise seems fine. |
| 04:40 |
Zeno` |
hmmmm, I don't remember but probably not |
| 04:40 |
OldCoder |
hmmmm, 0.4.14 clients apparently demonstrate the issue |
| 04:40 |
hmmmm |
with 0.4.14 servers/ |
| 04:40 |
hmmmm |
? |
| 04:40 |
OldCoder |
And in 2014 IIRC 0.4.X clients of the period did as well |
| 04:41 |
OldCoder |
Not sure about the matchup... |
| 04:41 |
hmmmm |
you know what, I don't think this correlation means anything at all |
| 04:41 |
OldCoder |
In my case, I blamed mobile clients for triggering a server bug |
| 04:41 |
OldCoder |
O.K. |
| 04:42 |
hmmmm |
it's probably just because your server and the clients connecting to it are using potatos for network connections and it perturbs these odd bugs that somebody would never see under normal circumstances |
| 04:43 |
OldCoder |
"potatos" ? |
| 04:43 |
* OldCoder |
takes that as a metaphor for a Bell Curve of different types of connections |
| 04:44 |
hmmmm |
actually I created a protocol similar to this one for aircraft to ground station comms over satellite radios and we used IPNetSim to replicate all these types of real world scenarios |
| 04:44 |
OldCoder |
How did it work out? |
| 04:44 |
hmmmm |
wondering if there's a pure software version of IPNetSim that we can use to test this |
| 04:44 |
est31 |
there is netem |
| 04:44 |
OldCoder |
You mean, fuzz up the connections? |
| 04:44 |
est31 |
part of the linux kernel |
| 04:44 |
hmmmm |
not just fuzz up the connections |
| 04:44 |
est31 |
but I do not know how to get it work |
| 04:44 |
hmmmm |
it does all kinds of things |
| 04:45 |
hmmmm |
simulates dropped packets, saturated lines, packet re-ordering, basically all the worst case scenarios |
| 04:46 |
hmmmm |
corrupts packets too :-) |
| 04:46 |
OldCoder |
Useful in general to test MT... but we already know there will be problems |
| 04:46 |
OldCoder |
So, there is an agreement in principle on the current PR? |
| 04:47 |
OldCoder |
est31 wishes it held for 2 weeks... |
| 04:47 |
OldCoder |
despite the fact this will change nothing... and will not block it subsequently? |
| 04:47 |
OldCoder |
This is pointless, but acceptable |
| 04:47 |
hmmmm |
it's time to see if he can find the root cause |
| 04:47 |
OldCoder |
He said no, hmmmm |
| 04:47 |
est31 |
I agree with the principle of the change but I do not agree with calling it a fix for the issue |
| 04:47 |
hmmmm |
what? |
| 04:47 |
OldCoder |
He has no plans to look at it |
| 04:47 |
hmmmm |
okay then |
| 04:47 |
OldCoder |
He is waiting for somebody else to do so |
| 04:47 |
est31 |
and therefore I demand the two weeks pause |
| 04:47 |
hmmmm |
it's 2 weeks for other contribtors if they're interested in solving this |
| 04:47 |
OldCoder |
est31, correct? |
| 04:47 |
OldCoder |
Very well |
| 04:48 |
hmmmm |
i don't see any issue here |
| 04:48 |
* OldCoder |
is satisfied and thanks the parties who have spoken |
| 04:48 |
hmmmm |
again i've never personally encountered this bug |
| 04:48 |
hmmmm |
and i don't hear about it like all the time the way you make it out to seem |
| 04:48 |
OldCoder |
Right... it was frustrating, believe me, to be the... |
| 04:48 |
* OldCoder |
is quite literal, hmmmm. He states facts, not "seems". |
| 04:48 |
hmmmm |
would be way higher on our radars if it were half as prevalent as it sounds |
| 04:49 |
OldCoder |
Right... it was frustrating, believe me, to be the only person in late 2014 who was genuinely scr*wed by this |
| 04:49 |
OldCoder |
But the problem has been around for nearly 2 years |
| 04:49 |
OldCoder |
For multiple worlds |
| 04:49 |
hmmmm |
what, are you VanessaE? |
| 04:49 |
OldCoder |
hm? |
| 04:49 |
hmmmm |
the * |
| 04:49 |
OldCoder |
How does VE figure into this? |
| 04:49 |
* OldCoder |
is confused |
| 04:49 |
hmmmm |
the * |
| 04:49 |
* VanessaE |
has been pinged.. |
| 04:49 |
OldCoder |
Hm? |
| 04:49 |
hmmmm |
"G*d dammit" |
| 04:49 |
* OldCoder |
remains quite confused |
| 04:49 |
hmmmm |
wth |
| 04:50 |
hmmmm |
lol whatever |
| 04:50 |
OldCoder |
We have a settlement anyway |
| 04:50 |
OldCoder |
Ahhh |
| 04:50 |
OldCoder |
Got it |
| 04:50 |
OldCoder |
Look, just trying to maintain decorum |
| 04:50 |
OldCoder |
Figured you as moderator would appreciate it |
| 04:50 |
OldCoder |
"scr*wed" seemed more professional |
| 04:50 |
hmmmm |
I'll start randomly replacing letters with asterisks in my speech too in an attempt to fit in |
| 04:50 |
OldCoder |
Not fit in... but to abide by consensus principles |
| 04:51 |
OldCoder |
When in doubt, it's best to be cautious |
| 04:51 |
OldCoder |
Again, thank those who have talked. Let's see if there are further insights in the first half of June. |
| 04:52 |
* OldCoder |
is going to go investigate the available of a late night snack |
| 04:52 |
OldCoder |
o/ |
| 04:52 |
hmmmm |
okay, sounds G*od |
| 04:52 |
OldCoder |
thank you to hose * |
| 04:52 |
OldCoder |
hmmmm, scr*wed is hardly random |
| 04:52 |
OldCoder |
whereis G*od certainly is |
| 04:52 |
hmmmm |
Jose who? |
| 04:52 |
OldCoder |
Jose? |
| 04:52 |
* OldCoder |
is lost, now |
| 04:52 |
hmmmm |
You said thank you to hose |
| 04:52 |
hmmmm |
if hose is a name, you probably mean Jose |
| 04:52 |
OldCoder |
to those * <- typo in a typo correction |
| 04:52 |
est31 |
sapier officially left minetest? |
| 04:53 |
OldCoder |
Thank you to those who have commented |
| 04:53 |
hmmmm |
Ok i'm done screwin with you |
| 04:53 |
OldCoder |
Officially? I doubt it |
| 04:53 |
hmmmm |
later. |
| 04:53 |
OldCoder |
Very well |
| 04:53 |
VanessaE |
est31: not officially, in fact last time he showed up, he said he was just taking a long break |
| 04:53 |
VanessaE |
school or some such? can't remember |
| 04:53 |
OldCoder |
If you "do not know" me, hmmmm, be advised I do not always know when people are "screwin" with me |
| 04:53 |
OldCoder |
So, the fun to be had is limited |
| 04:53 |
est31 |
okay thanks VanessaE |
| 04:53 |
|
Tmanyo joined #minetest-dev |
| 04:53 |
OldCoder |
o/ |
| 04:54 |
hmmmm |
yaay fun |
| 04:54 |
* OldCoder |
takes people at face value initially. Eventually he likes to have fun, himself. |
| 04:54 |
OldCoder |
:D |
| 05:01 |
Zeno` |
very confusing |
| 05:01 |
Zeno` |
https://github.com/minetest/minetest/blob/master/src/script/cpp_api/s_security.cpp#L293 and then https://github.com/minetest/minetest/blob/master/src/script/cpp_api/s_security.cpp#L250 |
| 05:01 |
hmmmm |
std:: everywhere |
| 05:01 |
hmmmm |
whyyy |
| 05:01 |
Zeno` |
at line 293 the macro implements the exact code that is below line 293 |
| 05:01 |
Zeno` |
same a bit further on |
| 05:02 |
hmmmm |
looks like it was a case of confusion |
| 05:02 |
est31 |
Zeno`, its not 100% the same |
| 05:02 |
est31 |
the macro has an additional if (fd) |
| 05:03 |
est31 |
but yeah +1 I wonder why its there |
| 05:04 |
Zeno` |
Now I can't remember why I was looking at this file |
| 05:05 |
Zeno` |
est31, I think it must have been an oversight when cleaning the code up or something |
| 05:07 |
Zeno` |
the macro is actually sort of wrong because fclose(fp) can change errno IIRC |
| 05:07 |
est31 |
yeah |
| 05:07 |
est31 |
but afaik it only changes it if the fd is invalid |
| 05:08 |
|
Hunterz joined #minetest-dev |
| 05:11 |
Zeno` |
The fclose() function may also fail and set errno for any of the errors specified for the routines close(2), write(2) |
| 05:11 |
Zeno` |
or fflush(3). |
| 05:11 |
Zeno` |
*shrug* |
| 05:11 |
Zeno` |
Is there are utility to annotate source code? |
| 05:11 |
Zeno` |
I'd like to add notes for stuff I want to come back to |
| 05:12 |
Zeno` |
I suppose I could fix it now |
| 05:17 |
Zeno` |
#4172 |
| 05:17 |
ShadowBot |
https://github.com/minetest/minetest/issues/4172 -- Remove unused code in s_security.cpp by Zeno- |
| 05:17 |
Zeno` |
now back to what I was doing |
| 05:17 |
|
paramat joined #minetest-dev |
| 05:23 |
Zeno` |
est31, #3859 is ready? I note your comment regarding the return values but is there a better way? |
| 05:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/3859 -- Add minetest.check_password_entry callback by est31 |
| 05:26 |
est31 |
well shrug its all your opinion that having true/false/nil is bad |
| 05:30 |
Zeno` |
est31, http://irc.minetest.ru/minetest-dev/2016-05-28#i_4621145 |
| 05:31 |
|
emptty joined #minetest-dev |
| 05:31 |
Zeno` |
I think that's the only reason it was mentioned |
| 05:31 |
est31 |
I have heard that argument but I dont think users are that stupid |
| 05:31 |
Zeno` |
probably not |
| 05:32 |
Zeno` |
I really don't have *strong* thoughts either way but since it was mentioned in the PR comments *shrug* |
| 05:33 |
Zeno` |
I'll merge it later I guess (unless you or someone else does) |
| 05:34 |
est31 |
#4173 |
| 05:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/4173 -- Initial Gamepad support by est31 |
| 05:38 |
Zeno` |
I wish github put the .h files first but I supposed it's sorted alphabetically |
| 05:51 |
Zeno` |
Big PR est31 :) |
| 05:52 |
est31 |
worked a week on it |
| 05:55 |
Zeno` |
It looks good from what I can see. I have some minor nitpicks but I might not mention them (e.g. I don't like bs()) |
| 05:55 |
Zeno` |
but *shrug* |
| 05:56 |
Zeno` |
I'd prefer it was called bitpos() or something more obvious tbh |
| 05:56 |
Zeno` |
up to you! |
| 05:57 |
Zeno` |
now I need a gamepad :) |
| 05:57 |
est31 |
bs was meant for sparing characters |
| 05:58 |
est31 |
I do like << notation |
| 05:58 |
Zeno` |
yeah |
| 05:58 |
Zeno` |
bp then! |
| 05:58 |
Zeno` |
lol |
| 05:58 |
est31 |
perhaps I'll make JLO_B_PB a parameterized macro |
| 05:59 |
Zeno` |
maybe yeah |
| 05:59 |
Zeno` |
est31, https://github.com/minetest/minetest/pull/4173/files#diff-18513665750ef5adf42b5ec29e14162eR1615 |
| 06:00 |
Zeno` |
I'm only looking at the PR on github atm so I could be missing something, but are those functions used in more than one file? |
| 06:00 |
Zeno` |
The only reason I suggested they might be better as inline functions is for performance |
| 06:01 |
est31 |
so you mean inline bool? |
| 06:01 |
Zeno` |
yeah |
| 06:01 |
est31 |
they are only used in game.cpp |
| 06:01 |
est31 |
inline then |
| 06:02 |
Zeno` |
I know it's a small issue but for something like input I think that little performance changes do matter |
| 06:05 |
Zeno` |
I'm afk for a bit. Nice work on the gamepad est31 |
| 06:05 |
est31 |
thx |
| 06:34 |
paramat |
hi nore please could you review game#1076 game#1106 ? |
| 06:34 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1076 -- Fire: Ignite tnt, gunpowder, permanent flame above coalblock by paramat |
| 06:34 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1106 -- Default: New mese texture. Add missing texture credits by paramat |
| 06:41 |
paramat |
thanks, i'll merge some stuff to game later |
| 06:43 |
|
ssieb joined #minetest-dev |
| 06:49 |
|
nrzkt joined #minetest-dev |
| 08:09 |
|
Puka joined #minetest-dev |
| 08:15 |
|
celeron55 joined #minetest-dev |
| 08:38 |
|
OldCoder joined #minetest-dev |
| 08:57 |
|
DFeniks joined #minetest-dev |
| 09:20 |
|
lisac joined #minetest-dev |
| 09:52 |
|
Calinou joined #minetest-dev |
| 10:31 |
|
Sockbat joined #minetest-dev |
| 10:47 |
paramat |
#4163 updated and ready for review |
| 10:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/4163 -- Sky: Darker, bluer sky and improved horizon haze at night by paramat |
| 10:51 |
paramat |
will merge game#1106 game#1119 in a moment |
| 10:51 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1106 -- Default: New mese texture. Add missing texture credits by paramat |
| 10:51 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/1119 -- Doors: pass pointed_thing to on_rightclick() callback. by sofar |
| 10:57 |
paramat |
merging |
| 11:00 |
paramat |
done |
| 11:00 |
|
Fixer joined #minetest-dev |
| 11:41 |
|
rubenwardy joined #minetest-dev |
| 11:52 |
|
damiel joined #minetest-dev |
| 12:12 |
|
xunto joined #minetest-dev |
| 12:17 |
|
blaze joined #minetest-dev |
| 12:35 |
|
lisac joined #minetest-dev |
| 12:45 |
Hunterz |
will be possible implement aperoiodic tiling like this: http://imgur.com/E7X7BWv ? |
| 12:47 |
Zeno` |
is everyone happy with #3859 now? |
| 12:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/3859 -- Add minetest.check_password_entry callback by est31 |
| 12:47 |
Zeno` |
The only outstanding question, I guess, is whether a format error should log a message |
| 12:49 |
Zeno` |
If that's the only issue I'll add a message to errorstream myself while merging |
| 12:49 |
Zeno` |
(if necessary) |
| 12:55 |
paramat |
Hunterz #2746 |
| 12:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/2746 -- Randomized textures (sprite strip) |
| 12:59 |
|
DI3HARD139 joined #minetest-dev |
| 13:03 |
Zeno` |
ok, I'll merge 3859 shortly (I've added errorstream << "check_password_entry: invalid format" << std::endl; for invalid formats) |
| 13:06 |
Zeno` |
here is the patch as I will apply it: https://gist.github.com/Zeno-/9d9fe7a75e2e60aa24b1d5544e57a8f0 |
| 13:06 |
Zeno` |
only change is line 90 |
| 13:07 |
Sokomine |
i'd love to have #4169 merged. took me some time to figure out how to revoke that unwanted priv, and it wasn't just only me who didn't know. sometimes protection is desirable even in singleplayer worlds |
| 13:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/4169 -- do not grant protection_bypass priv automaticly by Sokomine |
| 13:07 |
Zeno` |
(and rebased) |
| 13:07 |
Zeno` |
it has been |
| 13:07 |
Zeno` |
:P |
| 13:12 |
Sokomine |
ah, thanks :-) ought to have checked the replies sooner |
| 13:17 |
Zeno` |
3859 merged |
| 13:22 |
|
est31 joined #minetest-dev |
| 13:22 |
|
srifqi joined #minetest-dev |
| 13:22 |
est31 |
No Zeno` |
| 13:22 |
est31 |
please amend the commit you pushed |
| 13:22 |
Zeno` |
in what way? |
| 13:22 |
est31 |
its within the ten minutes |
| 13:22 |
est31 |
either remove the errorstream entirely, or make it a warningstream |
| 13:22 |
est31 |
and add the name |
| 13:22 |
est31 |
name is important otherwise server owners cant debug |
| 13:22 |
Zeno` |
I'll change to warning |
| 13:23 |
est31 |
and errorstream gets sent to everybody |
| 13:24 |
Zeno` |
est31, add what name? |
| 13:24 |
est31 |
the player name |
| 13:24 |
|
Amaz joined #minetest-dev |
| 13:24 |
est31 |
std::string name = luaL_checkstring(L, 1); |
| 13:24 |
est31 |
^ that one |
| 13:25 |
Zeno` |
warningstream << "check_password_entry: invalid password format for " |
| 13:25 |
Zeno` |
name << std::endl; |
| 13:25 |
est31 |
and dont use check_password_entry |
| 13:25 |
est31 |
use __FUNCTION__ |
| 13:25 |
Zeno` |
is __FUNCTION__ standard now? |
| 13:25 |
est31 |
idk |
| 13:25 |
est31 |
hardcoding the function name makes life hard for people who want to rename the function |
| 13:25 |
est31 |
or well |
| 13:25 |
Zeno` |
warningstream << "Invalid password format for " name << std::endl; |
| 13:26 |
est31 |
maybe its okay to go with check_password_entry as well |
| 13:26 |
Zeno` |
It's minor, I'll leave it for now |
| 13:26 |
est31 |
what you said is okay too |
| 13:26 |
Zeno` |
ok warningstream << "Invalid password format for " << name << std::endl; it is |
| 13:28 |
Zeno` |
forced update |
| 13:32 |
srifqi |
http://stackoverflow.com/a/597081 |
| 13:35 |
|
STHGOM joined #minetest-dev |
| 13:43 |
paramat |
#4174 < hmmmm |
| 13:43 |
ShadowBot |
https://github.com/minetest/minetest/issues/4174 -- Mgv7: Always carve river channels WIP by paramat |
| 13:46 |
srifqi |
paramat, so your PR would make river to build a cave or a steep canyon? |
| 13:47 |
paramat |
no, it just means rivers are continuous and never blocked by a wall |
| 13:48 |
srifqi |
so, the place that intersect with river will be removed? |
| 13:51 |
DI3HARD139 |
How would one enable debug when compiling minetest? |
| 13:51 |
paramat |
yeah |
| 13:52 |
paramat |
as you can see in the 2nd and 3rd screenshots |
| 13:53 |
paramat |
you mean a debug build? |
| 14:31 |
|
Taoki joined #minetest-dev |
| 14:51 |
|
paramat joined #minetest-dev |
| 14:57 |
|
KaadmY joined #minetest-dev |
| 15:25 |
|
endev15_ joined #minetest-dev |
| 15:32 |
|
Void7 joined #minetest-dev |
| 15:38 |
|
Krock joined #minetest-dev |
| 15:46 |
|
jin_xi joined #minetest-dev |
| 15:51 |
|
paramat left #minetest-dev |
| 16:15 |
|
hmmmm joined #minetest-dev |
| 16:43 |
|
Hunterz joined #minetest-dev |
| 16:47 |
|
nrzkt joined #minetest-dev |
| 16:52 |
|
BrandonReese joined #minetest-dev |
| 16:53 |
|
srifqi joined #minetest-dev |
| 16:53 |
|
Void7 joined #minetest-dev |
| 16:57 |
Zeno` |
anyone here play chess? |
| 16:58 |
Zeno` |
oops, wrong channel |
| 17:11 |
sofar |
1. e4 |
| 17:29 |
|
ptv joined #minetest-dev |
| 17:44 |
hmmmm |
do you guys think use of dynamic_cast<> should be banned from minetest? |
| 17:44 |
Zeno` |
personally yes |
| 17:44 |
sfan5 |
*googles dynamic_cast c++* |
| 17:45 |
hmmmm |
i'm gonna be honest i'm a tad guilty of this |
| 17:45 |
sfan5 |
what's the use case for dynamic_cast? |
| 17:45 |
hmmmm |
i used it for knowing when to unlink schematics from decorations |
| 17:46 |
hmmmm |
sfan5, when you want to know what type of derived class a base class is |
| 17:46 |
Zeno` |
I guess I just don't like RTTI |
| 17:46 |
hmmmm |
sapier abuses it horribly everywhere |
| 17:47 |
hmmmm |
yea |
| 17:47 |
hmmmm |
soo, I guess like 2 or 3 more opinions on the matter and if we all agree then we can make it a rule? |
| 17:47 |
Zeno` |
I'd support the rule, so get the other opinions :) |
| 17:51 |
Zeno` |
a lot of libs and some major apps now have --no-rtti (or whatever the flag is) |
| 17:52 |
Zeno` |
imo it's pointless when it's trivial to solve without rtti |
| 17:53 |
hmmmm |
yup |
| 17:53 |
hmmmm |
you know, some compilers actually implement dynamic_cast by doing string comparisons with class names |
| 17:53 |
hmmmm |
blech |
| 17:57 |
Zeno` |
It might be ok in something like a word processor... but in something where performance matters I don't like it at all |
| 17:58 |
Zeno` |
adding ms (or whatever) here and there for every dynamic cast (for something that simple) is scary |
| 17:58 |
Zeno` |
a ms* or even 100ns* heh |
| 17:58 |
Zeno` |
you know what I mean |
| 17:58 |
|
STHGOM joined #minetest-dev |
| 17:58 |
|
rubenwardy joined #minetest-dev |
| 18:23 |
hmmmm |
yea |
| 18:23 |
hmmmm |
well, inefficiency is baked right in |
| 18:24 |
hmmmm |
the STL is quite allocation-happy so i doubt we're going to achieve really lean and mean code |
| 18:24 |
hmmmm |
right now dynamic_cast is only used in two areas and one of them is I/O bound (not cpu) |
| 18:45 |
|
torgdor joined #minetest-dev |
| 18:59 |
|
lisac joined #minetest-dev |
| 19:05 |
|
Samson1 joined #minetest-dev |
| 19:20 |
|
wkmanire joined #minetest-dev |
| 19:21 |
wkmanire |
Hello |
| 19:21 |
wkmanire |
If I want to build from the vanilla game from source, do I need to clone both minetest and minetest game? |
| 19:31 |
|
Tmanyo joined #minetest-dev |
| 19:50 |
Fixer |
yes |
| 20:16 |
|
hmmmmm joined #minetest-dev |
| 20:21 |
|
hmmmmmm joined #minetest-dev |
| 20:40 |
|
Void7 joined #minetest-dev |
| 20:59 |
|
Samson1 joined #minetest-dev |
| 21:10 |
|
Megaf joined #minetest-dev |
| 21:21 |
|
electrodude512 joined #minetest-dev |
| 21:27 |
|
hmmmmm joined #minetest-dev |
| 21:29 |
|
proller joined #minetest-dev |
| 21:30 |
|
troller joined #minetest-dev |
| 21:34 |
|
hmmmmmm joined #minetest-dev |
| 21:42 |
|
hmmmm joined #minetest-dev |
| 21:48 |
|
hmmmmm joined #minetest-dev |
| 22:00 |
|
jin_xi joined #minetest-dev |
| 22:12 |
|
Puka joined #minetest-dev |
| 22:29 |
|
Puka_ joined #minetest-dev |
| 22:41 |
|
Megal_ joined #minetest-dev |
| 22:45 |
|
Puka joined #minetest-dev |
