| Time |
Nick |
Message |
| 00:02 |
|
roniz_ joined #minetest-dev |
| 00:04 |
|
clymancer joined #minetest-dev |
| 00:19 |
VanessaE |
sapier: saw you join the server.. |
| 00:19 |
VanessaE |
something of interest? :) |
| 00:19 |
sapier |
valgrinding ... |
| 00:19 |
VanessaE |
oh ok |
| 00:20 |
sapier |
still waiting to see anything ;-) |
| 00:20 |
VanessaE |
you already timed out |
| 00:20 |
sapier |
wow |
| 00:20 |
VanessaE |
(or signed out) |
| 00:20 |
sapier |
a lot of lost memory |
| 00:20 |
VanessaE |
bad? |
| 00:20 |
sapier |
enough to be relevant |
| 00:40 |
sofar |
eh, my bukkit server is sitting at 5gb ram VIRT, minetestserver is 1853M VIRT ... I'm happy ;) |
| 00:41 |
VanessaE |
sofar: that's...a tad excessive :) |
| 00:41 |
VanessaE |
(even for minetest) |
| 00:42 |
sofar |
16176 minetest 20 0 1853m 1.6g 7392 S 12 20.8 69:35.26 minetestserver |
| 00:42 |
sofar |
3421 minecraf 20 0 4998m 3.2g 1444 S 10 42.9 7154:15 java |
| 00:43 |
|
clymancer joined #minetest-dev |
| 00:43 |
* VanessaE |
peeks over sapier's shoulder |
| 00:45 |
sapier |
wtf |
| 00:45 |
VanessaE |
sorry! I won't look anymore |
| 00:45 |
VanessaE |
;) |
| 00:46 |
sapier |
no not you VanessaE |
| 00:46 |
VanessaE |
dare I ask how bad this had to be to call for a 'wtf' ? |
| 00:49 |
sapier |
particle handling is still loosing memory |
| 00:49 |
VanessaE |
wait, I thought that was fixed? O_o |
| 00:50 |
sapier |
yes but there seem to be additional situations where it ain't fixed |
| 00:51 |
sapier |
ah there it is |
| 00:52 |
sapier |
client doesn't cleanup it's event queue on shutdown |
| 00:52 |
sapier |
sadly that leak is irrelevant for gameplay |
| 00:53 |
sapier |
and hard to fix ... at least as long as clientevents are plain datatypes |
| 00:55 |
sapier |
I'm gonna try to find a less invasive fix tomorrow |
| 00:56 |
|
sapier left #minetest-dev |
| 01:04 |
|
chchjesus joined #minetest-dev |
| 01:08 |
|
alexxs joined #minetest-dev |
| 01:41 |
|
hmmmm joined #minetest-dev |
| 01:47 |
|
acerspyro joined #minetest-dev |
| 01:49 |
|
gregorycu joined #minetest-dev |
| 01:53 |
paramat |
hi hmmmm please can this be merged #2175 ? so i can work on mgv5 during the freeze |
| 01:53 |
ShadowBot |
https://github.com/minetest/minetest/issues/2175 -- Mgv5: Speed optimise noise. Remove blobgen, add large caves. Cavegen: add mgv5 large caves by paramat |
| 02:05 |
gregorycu |
#2187 |
| 02:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/2187 -- Make the GameGlobalShaderConstantSetter use the settings callback by gregorycu |
| 02:06 |
|
OldCoder joined #minetest-dev |
| 02:06 |
VanessaE |
paramat: just fyi, feature freeze now, 0.4.12 release on the 29th |
| 02:07 |
gregorycu |
What's the feature freeze for? |
| 02:07 |
gregorycu |
Core, or mapgen, or what? |
| 02:08 |
VanessaE |
normally it's for the whole engine |
| 02:08 |
gregorycu |
Is this stuff in the forum? I should really check that out. |
| 02:08 |
gregorycu |
I'm going to look at bug #132 now |
| 02:08 |
ShadowBot |
https://github.com/minetest/minetest/issues/132 -- Jump at node edge doesnt work |
| 02:08 |
VanessaE |
no but it should be |
| 02:08 |
gregorycu |
I don't understand how some of these bugs have not been squashed yet |
| 02:08 |
hmmmm |
bFogEnabled? oh please no don't use hungarian notation |
| 02:09 |
VanessaE |
no one thought it irritating enough to fix I guess :) |
| 02:09 |
hmmmm |
I am not more enlightened now that you prefixed the variable with a 'b' |
| 02:09 |
VanessaE |
hmmmm: isn't that camelCase? |
| 02:09 |
VanessaE |
oh that |
| 02:09 |
hmmmm |
there are two kinds of hungarian notation |
| 02:09 |
gregorycu |
Sorry hmmmmm |
| 02:09 |
gregorycu |
That's my day job leaking into minetest |
| 02:09 |
hmmmm |
the useless kind that you see prevalent, and the original kind first used in microsoft office's original codebase |
| 02:09 |
gregorycu |
(I hate hungarien) |
| 02:10 |
gregorycu |
Sorry, I hate systems hungarian |
| 02:10 |
hmmmm |
the original hungarian notation was to prefix the variables with an abbreviation or letter that signifies its purpose |
| 02:10 |
hmmmm |
not... variable type |
| 02:10 |
gregorycu |
Yeah |
| 02:11 |
gregorycu |
Oh dear, that was criminal of me |
| 02:11 |
|
Miner_48er joined #minetest-dev |
| 02:12 |
VanessaE |
string his ass up. ;) |
| 02:16 |
gregorycu |
I have amended by commit, please forgive me |
| 02:32 |
hmmmm |
not quite understanding this commit https://github.com/gregorycu/minetest/commit/7cededb7b9889bb647b4277d9bcf5a58786f4cf1 |
| 02:32 |
hmmmm |
were you testing this on a 32 bit machine? |
| 02:33 |
gregorycu |
No... ? |
| 02:33 |
gregorycu |
Why do you ask? |
| 02:33 |
hmmmm |
fwiw i am guessing the majority of the savings comes from fastfaces_new.reserve(512) |
| 02:33 |
hmmmm |
because const v3s16 & should be the same speed as passing a v3s16 in theory |
| 02:33 |
gregorycu |
Oh |
| 02:34 |
hmmmm |
they're both the same size |
| 02:34 |
gregorycu |
Yes, at least on my machine, more inlining occured |
| 02:34 |
gregorycu |
So, it's a secondary effect |
| 02:34 |
hmmmm |
if it's because byval calls the default constructor first I'm going to be very upset |
| 02:35 |
|
electrodude512 joined #minetest-dev |
| 02:35 |
hmmmm |
C++ is so difficult to write optimal code for |
| 02:35 |
gregorycu |
:) |
| 02:35 |
hmmmm |
it just doesn't do the thing you expect it should do |
| 02:35 |
gregorycu |
If you think about it, it's one of the easiest |
| 02:35 |
gregorycu |
If you know what you're doing |
| 02:35 |
hmmmm |
you need to have way too much knowledge |
| 02:35 |
gregorycu |
(Compared to higher level languages where you have no control) |
| 02:35 |
gregorycu |
Yeah, that's agreed |
| 02:36 |
gregorycu |
I'd be fucked if I didn't have my profiler |
| 02:36 |
hmmmm |
the optimizer is only going to optimize things where it's absolutely 100% safe to (i.e. not have any side effects you may have possibly wanted) |
| 02:36 |
hmmmm |
but... C++ is so extensive that you never know what kind of trap features you're activating |
| 02:36 |
gregorycu |
There is one minor bug that slipped in, I'm going to fix this now |
| 02:37 |
hmmmm |
you modify n? |
| 02:37 |
gregorycu |
But yeah, most of those ref changes triggered inlining to occur |
| 02:37 |
hmmmm |
rather, n is modified? |
| 02:37 |
gregorycu |
Line 250 of src/mapblock_mesh.cpp |
| 02:37 |
gregorycu |
(The first file listed) |
| 02:38 |
gregorycu |
I should have called getNodeRefUnsafeCheckFlags |
| 02:38 |
gregorycu |
At the moment it can get values from unloaded chunks, which is bad |
| 02:38 |
hmmmm |
hmm |
| 02:38 |
hmmmm |
ahh |
| 02:38 |
gregorycu |
err... unloaded Nodes |
| 02:38 |
hmmmm |
so the client extensively utilizes flags in voxelmanipulators |
| 02:39 |
hmmmm |
from a server-side perspective, flags are useless in practice |
| 02:39 |
hmmmm |
shouldn't that be ContentIgnoreNode? |
| 02:39 |
|
paramat left #minetest-dev |
| 02:39 |
n4x |
C++ is a language where writing high-level code is hard, and low-level code is basically written in a "subset" of it called C |
| 02:40 |
gregorycu |
Yeah, it probably should |
| 02:40 |
gregorycu |
I'll fix that too |
| 02:41 |
gregorycu |
I actually had a massive secondary bunch of changes, but there wasn't enough bang-for-buck for me |
| 02:41 |
gregorycu |
Too many changes for not enough gain |
| 02:41 |
gregorycu |
Basically I just want to make safe changes that give us sizable perf improvements |
| 02:43 |
hmmmm |
i'm quite shocked a number of those modifications actually produce gains |
| 02:44 |
hmmmm |
we shouldn't be required to do such tedious micro-optimizing |
| 02:44 |
hmmmm |
they told us that the compiler will take care of it all! |
| 02:44 |
hmmmm |
what happened! |
| 02:44 |
hmmmm |
they told us not to worry! |
| 02:44 |
gregorycu |
lol |
| 02:45 |
gregorycu |
I am interested to know what type of perf gains people get on different platforms |
| 02:45 |
hmmmm |
here I am thinking I need to rewrite 3d noise functions using SIMD and NEON and here we can get significant performance gains by passing things by reference |
| 02:45 |
VanessaE |
Don't worry, they said! The compiler is magic, they said! |
| 02:46 |
hmmmm |
should just start passing things by reference |
| 02:46 |
hmmmm |
fpth |
| 02:46 |
Brains |
They were wrong... It is really the JVM/CLR/hot-fad-of-day! No, really! |
| 02:46 |
hmmmm |
because the compiler is so obnoxiously slow and it keeps explicitly calling constructors when the state of the object is clearly and easily predictable at compile time |
| 02:46 |
n4x |
the problem of C++ code is that it is too low-level to high-level optimizations and too high-level to do low-level optimizations |
| 02:46 |
hmmmm |
=/ |
| 02:47 |
n4x |
it's a bit of trying to do both things at once and doing both wrong |
| 02:47 |
hmmmm |
shit like this man |
| 02:47 |
hmmmm |
shit like this makes me want to work on gcc |
| 02:47 |
gregorycu |
Don't work on gcc |
| 02:47 |
hmmmm |
i know |
| 02:47 |
gregorycu |
Work on clang |
| 02:47 |
hmmmm |
gcc has no future |
| 02:47 |
gregorycu |
Same yourself some sanity |
| 02:48 |
Brains |
hmmmm: If you wait a little bit, you might get a chance to work on a gcc fork... One of those might be coming down the pipeline. |
| 02:48 |
gregorycu |
Save |
| 02:48 |
hmmmm |
Brains, nah I agree with gregory |
| 02:48 |
hmmmm |
gcc is insane in several ways |
| 02:48 |
gregorycu |
Clang is very exciting |
| 02:49 |
gregorycu |
Not that I've looked into it much, just second hand |
| 02:49 |
Brains |
Heh, that can be considered quite a polite phrasing of the gcc situation. |
| 02:49 |
VanessaE |
[01-23 21:50] <MichaelEh> latest build still craps out though I got to see aghostly image of where I was. |
| 02:49 |
VanessaE |
(offtopic, ish) |
| 02:49 |
gregorycu |
By the way, if we were to start using C++11, we could do other perf improvements |
| 02:49 |
hmmmm |
like what |
| 02:49 |
gregorycu |
For instance, stateful allocators |
| 02:50 |
gregorycu |
I had a look at a lighting issue someone was having |
| 02:50 |
gregorycu |
And 25% (!) of the time was spent in std::set::insert |
| 02:50 |
hmmmm |
in unlightNodes? |
| 02:50 |
gregorycu |
Almost all of that was spent in allocating memory for a set node |
| 02:50 |
hmmmm |
no offense but the lighting calculations are crap |
| 02:51 |
gregorycu |
None taken, I agree |
| 02:51 |
gregorycu |
But structures are low hanging fruit |
| 02:51 |
hmmmm |
I simply never did optimizations on the map versions of the algorithm |
| 02:51 |
hmmmm |
check out Mapgen::calcLighting() if you want to see a truly fast (but bulk) version of the same thing |
| 02:52 |
gregorycu |
I will, I have a few things I'm working on at the moment |
| 02:52 |
hmmmm |
I think Map::getNode* variants are a little too slow to use on things like this |
| 02:52 |
hmmmm |
maybe we should be fetching whole mapblocks |
| 02:52 |
hmmmm |
err, mapblock pointers |
| 02:53 |
hmmmm |
instead of doing a sector lookup and then mapblock lookup within the sector and a whole bunch of checks at the same time |
| 02:53 |
gregorycu |
The problem with that is you then have data shared across thread boudaries |
| 02:53 |
hmmmm |
don't worry about synchronization.. |
| 02:53 |
gregorycu |
I am very worried |
| 02:53 |
hmmmm |
why |
| 02:53 |
gregorycu |
Single player is very slow because of thread contention |
| 02:53 |
VanessaE |
fwiw, I am attempting to get some info from MichaelEh about his crash |
| 02:53 |
hmmmm |
you're envlocked |
| 02:54 |
gregorycu |
I don't follow? envlocked? |
| 02:54 |
hmmmm |
wait, huh? |
| 02:54 |
hmmmm |
why would single player be slow due to contention |
| 02:54 |
gregorycu |
Because that's what the profiler tells me |
| 02:54 |
gregorycu |
Have you played SP lately? |
| 02:55 |
hmmmm |
in a singleplayer world, Environment and ServerEnvironment are two separate structures |
| 02:55 |
hmmmm |
each with their own locks |
| 02:55 |
hmmmm |
the Client cannot cause contention on the Server and vice versa |
| 02:56 |
gregorycu |
To be honest, I've only just started looking into it |
| 02:56 |
hmmmm |
I play SP all the time and it seems fine to me. I heard Zeno say that 25% of the time is spent thread switching or whatever |
| 02:56 |
gregorycu |
But SP is waaaaay more jittery than server + client |
| 02:56 |
hmmmm |
need to check out the valgrind output |
| 02:56 |
gregorycu |
I actually think it should be pretty high priority |
| 02:57 |
gregorycu |
Because the first thing someone does when they download minetest, is start up singleplayer to take a look |
| 02:57 |
hmmmm |
not sure I understand the point behind the suggestion of running the server in a separate process for SP |
| 02:57 |
hmmmm |
since everything is separate |
| 02:57 |
gregorycu |
No, I don't agree with that |
| 02:57 |
gregorycu |
I agree with you in that regard |
| 02:57 |
gregorycu |
Except to say, maybe things are not as separate as they should be? |
| 02:57 |
gregorycu |
I don't know, i haven't looked at it yet |
| 02:57 |
hmmmm |
a process is just a thread with its own memory space. if you don't touch eachother's memory, how is it any different |
| 02:57 |
gregorycu |
You are correct |
| 02:57 |
hmmmm |
that being said |
| 02:58 |
gregorycu |
I suppose you get a guarantee by running it in a different process |
| 02:58 |
hmmmm |
IF there is an instance where they share the same data stucture |
| 02:58 |
hmmmm |
that's a bug and that's the thing which should be fixed |
| 02:58 |
gregorycu |
What about settings? |
| 02:58 |
gregorycu |
(just an example) |
| 02:58 |
hmmmm |
yeah :/ |
| 02:58 |
hmmmm |
that's true, in fact I think we just found our culprit |
| 02:58 |
hmmmm |
that did not occur to me |
| 02:59 |
hmmmm |
all that pressure on g_settings between client and server could be the cause |
| 02:59 |
gregorycu |
I think our best bet is to actually namespace all of our globals into a Server or a Client namespace |
| 03:00 |
hmmmm |
so instead of splitting things into separate proceses and adding more settings callbacks, why don't I write up the fast lock/wait free settings read mechanism |
| 03:00 |
hmmmm |
this way we can share it and it'd be just as fast |
| 03:00 |
hmmmm |
but i'd still rather not share it |
| 03:00 |
gregorycu |
It's better not to share it |
| 03:01 |
gregorycu |
Cause that simulates more accurately the client + server setup |
| 03:01 |
hmmmm |
the global namespace sounds good |
| 03:01 |
hmmmm |
but you're going to get pretty sick of typing "using namespace client" everywhere |
| 03:01 |
hmmmm |
and then more discression needs to be applied when working inside header files |
| 03:01 |
gregorycu |
I think it's worth it |
| 03:01 |
hmmmm |
that ought to be tricky |
| 03:02 |
gregorycu |
Yeah, it's kind of annoying there isn't a good solution for that problem |
| 03:02 |
gregorycu |
As far as I know |
| 03:02 |
hmmmm |
right |
| 03:02 |
gregorycu |
Anyway, I have a few bugs I've committed to fix, then I want to take a look at why SP is slow for me |
| 03:03 |
hmmmm |
gosh, I never felt SP being 'slow' |
| 03:03 |
gregorycu |
I just thought that was how minetest was |
| 03:03 |
gregorycu |
Then I joined a server |
| 03:03 |
gregorycu |
And I was like: "wow, how fast is this" |
| 03:04 |
gregorycu |
"The server thread must be the slow thing" |
| 03:04 |
gregorycu |
Then i took a look at task manager and the server was hovering at about 5% |
| 03:05 |
hmmmm |
well there is a reason for that which doesn't have to do with contention |
| 03:05 |
hmmmm |
simply you're not running the serverthread |
| 03:05 |
hmmmm |
you offload that other 50% or whatever SP runs at onto the remote server which you don't have a task manager for |
| 03:06 |
gregorycu |
No |
| 03:06 |
gregorycu |
I was running it local |
| 03:07 |
gregorycu |
And the CPU for the server was 5% |
| 03:08 |
gregorycu |
Sorry, I was misleading: "I joined a server" = "I started a server instance and joined it" |
| 03:11 |
VanessaE |
hmmmm: did you see what MichaelEh said? |
| 03:12 |
hmmmm |
...no |
| 03:12 |
VanessaE |
oh, well it's nothing much. I'm just having him try various settings to find a way to stop his crash. |
| 03:13 |
VanessaE |
nothing so far works, even changing video drivers. |
| 03:13 |
hmmmm |
erm.. |
| 03:13 |
hmmmm |
what is the crash? |
| 03:14 |
VanessaE |
it's windows 7 so it's just a "this program has stopped" sort of message, nothing in the logs. |
| 03:14 |
VanessaE |
and he doesn't know how to use a debugger so little chance of finding the cause :-/ |
| 03:14 |
hmmmm |
welp |
| 03:14 |
hmmmm |
can't you walk him through how to use a debugger? |
| 03:14 |
hmmmm |
no stacktrace makes this useless |
| 03:15 |
VanessaE |
the only thing of substance was the RAM usage, about 520-ish megs (out of 4GB) and that no video driver works (even software)...and that 0.4.10 worked. |
| 03:15 |
VanessaE |
crashes as soon as it starts to render the world |
| 03:15 |
VanessaE |
well I could try to walk him through it, but someone will have to walk ME through it first, I don't know windows :) |
| 03:16 |
chrisf |
collect the minidump if it's a build you've got symbols for somewhere? |
| 03:16 |
VanessaE |
minidump? |
| 03:16 |
VanessaE |
it's sfan5's latest build |
| 03:16 |
chrisf |
like a *nix core dump, for postmortem debugging |
| 03:16 |
VanessaE |
where will this minidump be located? |
| 03:17 |
VanessaE |
yeah, I kinda figured that's what it was, didn't know windows produced those. |
| 03:18 |
gregorycu |
(hmmmm, I update the PR with the change of static name you recommended, and also a bug fix to do with lighting) |
| 03:18 |
|
deltib joined #minetest-dev |
| 03:19 |
chrisf |
ah, the process has to request one be made, so not useful to you without doing some plumbing |
| 03:19 |
VanessaE |
fek. |
| 03:19 |
VanessaE |
well checking anyway in case there is one. |
| 03:19 |
chrisf |
worth adding the infrastructure to that to mt so you can solve this kind of thing |
| 03:20 |
chrisf |
i think breakpad is the easiest way to wire it all up? |
| 03:20 |
chrisf |
infrastructure for that * |
| 03:20 |
gregorycu |
Yeah, I agree chris |
| 03:21 |
chrisf |
of course this is just drive-by advice so... meh ;) |
| 03:23 |
gregorycu |
Easier said than done |
| 03:24 |
VanessaE |
well that's out, he says his machine's not even producing a minidump dir (C:\windows\minidump or C:\winnt\minidump as I read it) |
| 03:25 |
gregorycu |
Ahh, nightmare fuel |
| 03:29 |
|
Zeno` joined #minetest-dev |
| 03:29 |
VanessaE |
I'm attempting to have him install win 7 SDK to get windbg |
| 03:29 |
VanessaE |
(from here: https://msdn.microsoft.com/en-us/windows/hardware/hh852365.aspx) |
| 03:31 |
VanessaE |
and...he's giving up for the night :-/ |
| 03:32 |
gregorycu |
Hello there Zeno |
| 03:32 |
VanessaE |
\o zenop |
| 03:32 |
VanessaE |
\o Zeno` |
| 03:32 |
Zeno` |
O/ |
| 03:33 |
|
NakedFury joined #minetest-dev |
| 03:40 |
|
NakedFury joined #minetest-dev |
| 03:43 |
|
Nate123 joined #minetest-dev |
| 03:47 |
hmmmm |
a minidump would be helpful but only if he were given an -O0 build |
| 03:47 |
hmmmm |
and we'd need to know the very very specific exact version of minetest used |
| 03:47 |
VanessaE |
he'd be using 1702c34 |
| 03:48 |
Zeno` |
which version is he using? msvc or mingw? |
| 03:48 |
VanessaE |
if he's using the build I told him to use |
| 03:48 |
VanessaE |
https://sfan5.pf-control.de/minetest-builds/?f |
| 03:48 |
VanessaE |
he's tried 0.4.11-release also |
| 03:48 |
VanessaE |
and a couple of dev builds between there and 1702c34 |
| 03:49 |
Zeno` |
I can try and replicate it I guess; but I used TDM-gcc (since I can't seem to get mingw to work and it's not maintained anymore by the looks of it anyway) |
| 03:49 |
Zeno` |
It's still gcc so I might be able to replicate the issue |
| 03:51 |
Zeno` |
If nothing happens in the meantime I'll do that in an hour or so |
| 03:53 |
|
NakedFury joined #minetest-dev |
| 03:56 |
VanessaE |
got another user with a crash issue, very similar to MichaelEh's. he has 6GB of RAM (he only needs 2 for this), using a win32 build from commit 63867b1 |
| 03:56 |
VanessaE |
(except it hangs rather than crashing, but the display is the same - blank playfield, save for the player's wield and HUD) |
| 03:57 |
puhfa |
hey guys, what is this sneak_glitch override shadowninja mentions in a issue report? |
| 03:57 |
puhfa |
i was going to file one myself but wont if it is a known issue (altho i couldnt find it in github) |
| 03:58 |
VanessaE |
puhfa: sneak+jump can be used to climb zig-zagging blocks |
| 03:58 |
chrisf |
VanessaE: is mt built to be 3GB-aware? |
| 03:58 |
chrisf |
(for 32bit windows builds) |
| 03:58 |
VanessaE |
good question, but should that matter here? |
| 03:59 |
puhfa |
VanessaE: thanks |
| 03:59 |
VanessaE |
even with the mesh cache turned off, and thus using 1.5 GB, it still crashes. |
| 03:59 |
chrisf |
well, if not, then needing 2G is a recipe for heap exhaustion |
| 03:59 |
VanessaE |
puhfa: https://i.imgur.com/PP27rSg.png |
| 03:59 |
hmmmm |
instead of guessing why not just get him using an -O0 build, get a minidump, and then see for sure |
| 03:59 |
hmmmm |
i hate it when people speculate when it's so easy to check |
| 04:00 |
VanessaE |
hmmmm: he's already signed off, so I'm seeing what we can get from the other guy now. |
| 04:00 |
VanessaE |
(he being MichaelEh, the first reporter) |
| 04:01 |
puhfa |
VanessaE: yes, i was aware of that. is that possible with sneak_glitch override disabled or enabled? |
| 04:01 |
VanessaE |
I guess disabled allows climbing. |
| 04:01 |
puhfa |
ok |
| 04:07 |
|
mrtux joined #minetest-dev |
| 04:11 |
|
NakedFury joined #minetest-dev |
| 04:18 |
puhfa |
well that was quick |
| 04:19 |
gregorycu |
That's what she said |
| 04:20 |
puhfa |
oh you |
| 04:20 |
gregorycu |
;) |
| 04:21 |
VanessaE |
ha |
| 04:21 |
Zeno` |
I wonder if it has anything to do with the bug I just found |
| 04:22 |
Zeno` |
doubt it |
| 04:22 |
Zeno` |
making PR |
| 04:24 |
Zeno` |
#2189 |
| 04:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/2189 -- Fix unitialised variable occassionally being used by Zeno- |
| 04:24 |
Zeno` |
bbiab |
| 04:33 |
gregorycu |
VanessaE: I think I have a fix for #132 |
| 04:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/132 -- Jump at node edge doesnt work |
| 04:33 |
gregorycu |
There is code here that attempts to make it easier to jump onto a node |
| 04:34 |
VanessaE |
oh good |
| 04:34 |
gregorycu |
Anyway, the code adds a bit of tolerance to the collision detection |
| 04:34 |
gregorycu |
That tolerance is the "dead zone" where you can't jump |
| 04:35 |
gregorycu |
I've removed the tolerance, which fixes the bug, but I think it means it's harder to jump onto nodes |
| 04:35 |
gregorycu |
I'm trying to figure out if that's the case |
| 04:42 |
hmmmm |
alright, guys |
| 04:42 |
hmmmm |
I have a good compromise (I think) between storage space and other things |
| 04:43 |
hmmmm |
we repurpose param1 completely and store node lighting separately |
| 04:43 |
hmmmm |
instead a mapblock will have 3 modes |
| 04:43 |
hmmmm |
exposed to sunlight, no light, or "has one or more light sources" |
| 04:44 |
hmmmm |
the buffer of light values will only exist if it's the last of the three states |
| 04:45 |
|
NakedFury joined #minetest-dev |
| 04:45 |
hmmmm |
this light value buffer could be a 2kb bitmap for all 4-bit light values in the block |
| 04:45 |
hmmmm |
which the mapblock will manage a pointer to |
| 04:46 |
hmmmm |
it will not be transferred over the network or saved, but upon block activation it will be computed |
| 04:46 |
hmmmm |
this way you can have your O(1) lightval lookups |
| 04:46 |
hmmmm |
and I can have my light savings |
| 04:48 |
hmmmm |
since a mapblock containing at least one light source is a rather rare event, it shouldn't be too harsh of a memory penalty |
| 04:48 |
VanessaE |
you know, that's not so bad. |
| 04:49 |
VanessaE |
in practice, only about 25 percent of the explored top surfaces of my maps seem to have actual light sources. |
| 04:49 |
hmmmm |
as for TrueColor lighting, that's going to consume 6 times as much memory per mapblock that does have a light source though |
| 04:50 |
hmmmm |
but still WAY WAY WAY WAY less than if you were to double the size of a MapNode |
| 04:50 |
VanessaE |
didn't I suggest some time ago a flag-and-expand scheme? :) |
| 04:50 |
hmmmm |
okay so maybe we could have 4 mapblock light states, the three i listed above and then an RGB format lighting |
| 04:50 |
VanessaE |
you're just doing it at the block level (which never occurred to me) |
| 04:50 |
hmmmm |
your flag-and-expand scheme as explained was variable length encoding |
| 04:51 |
VanessaE |
right, and the other four bits in param1 just stores the total light value like it already does? |
| 04:51 |
hmmmm |
which is completely implausible for minetest |
| 04:51 |
hmmmm |
at the block level it's fine |
| 04:51 |
hmmmm |
but not nodes |
| 04:51 |
hmmmm |
no, param1 will be completely disused after this |
| 04:51 |
VanessaE |
hm, 6 bits actually |
| 04:51 |
hmmmm |
light will be a property of the block |
| 04:51 |
VanessaE |
oh right, the bitmap |
| 04:51 |
VanessaE |
derp |
| 04:51 |
VanessaE |
what are you gonna do with the rest? |
| 04:52 |
hmmmm |
for what it's worth, if you compromise for 8 light levels instead of 16, you could save 512 bytes per grayscale light bitmap |
| 04:52 |
hmmmm |
it can be used for Various Things(tm) |
| 04:52 |
gregorycu |
Is it worth it? |
| 04:52 |
hmmmm |
one in mind is a full 8 bit color palette index for colorlike nodes |
| 04:52 |
VanessaE |
I've no qualms about total number of light levels, in practice in a mod, there's no appreciable difference between say 11 and 12. |
| 04:53 |
hmmmm |
and another thing could be to store node damage (i.e how much it's been dug) |
| 04:53 |
hmmmm |
I know |
| 04:53 |
hmmmm |
that's why I wanted to use only 3 bits for light |
| 04:53 |
hmmmm |
:( dammit |
| 04:53 |
Zeno` |
merging 2189 |
| 04:54 |
hmmmm |
Zeno`: looks good |
| 04:54 |
hmmmm |
so here we get: |
| 04:54 |
hmmmm |
memory savings |
| 04:54 |
gregorycu |
VanessaE: Do you make your own builds? |
| 04:54 |
VanessaE |
hmmmm: in fact for backward compat, you could easily just double the light value when passing it back to Lua in the various get-light calls |
| 04:54 |
hmmmm |
more room for other node attributes |
| 04:55 |
hmmmm |
RGB lights are plausible |
| 04:55 |
gregorycu |
I would like you to try my fix |
| 04:55 |
VanessaE |
gregorycu: I run linux, so I just ... build, but I don't distribute the bins |
| 04:55 |
hmmmm |
but on the downside with this method, I can't expand light range |
| 04:55 |
hmmmm |
unless I expand node storage |
| 04:55 |
gregorycu |
Ok, sweet |
| 04:55 |
VanessaE |
oh sure, I can try that if you want |
| 04:55 |
hmmmm |
or wait no, I can still do that |
| 04:55 |
gregorycu |
I have a fix, but I want a few people to try it, and see if there are uninteneded side effects |
| 04:56 |
hmmmm |
we can expand light range right *now* in fact, if we wanted |
| 04:56 |
VanessaE |
hmmmm: well light *range* is just a matter of how far you want to stretch the value, not necessarily how HIGh the value goes. |
| 04:56 |
hmmmm |
yeah |
| 04:56 |
hmmmm |
we can interpolate within the range. |
| 04:56 |
VanessaE |
yep |
| 04:56 |
hmmmm |
but this makes it confusing |
| 04:56 |
hmmmm |
okay so we have two colliding light beams |
| 04:57 |
hmmmm |
one will be from a light source with a range of ... I guess 16 |
| 04:57 |
hmmmm |
the other one would have a range of 20 |
| 04:57 |
hmmmm |
the whole trick here is that the light beam doesn't always need to decay by 1 each node |
| 04:57 |
hmmmm |
for unspreadLight() all you'd need to do is change a condition to stop at >= to > |
| 04:58 |
gregorycu |
VanessaE: Are you able to modify collision.cpp, lines 547 - 550 and delete the -d and +d |
| 04:58 |
gregorycu |
And then compile, run, and try to repo? |
| 04:58 |
VanessaE |
gregorycu: sure, one moment. |
| 04:59 |
gregorycu |
I'm interested in two things: does it fix the issue, and does it make jumping unto nodes more difficult/different |
| 04:59 |
hmmmm |
some duplicate light values are going to get pidgeonholed but the problem to solve is how do we not make light seem to clump up at specific distances |
| 04:59 |
gregorycu |
Thank you, no rush |
| 05:01 |
VanessaE |
hmmmm: well if I were doing it the brute force way, on a 2d map, something like new_level = previous_level + last_source / current_distance |
| 05:01 |
VanessaE |
iterating through each light in the scene and "drawing" around that source out from 0 to the max throw distance.. |
| 05:02 |
VanessaE |
you get the idea. just something really stupidly simple :) |
| 05:02 |
hmmmm |
yeah but how are you going to perform unspreadLight() now :( |
| 05:02 |
VanessaE |
that part I don't know :-/ |
| 05:02 |
hmmmm |
with 3 or more light sources |
| 05:03 |
VanessaE |
gregorycu: there's a small jitter when I jump, but it does seem to fix the issue |
| 05:03 |
gregorycu |
jitter... |
| 05:04 |
gregorycu |
Ok, back to the drawing board |
| 05:04 |
VanessaE |
gregorycu: a slight..."bounce"? |
| 05:04 |
VanessaE |
hard to describe it |
| 05:04 |
Zeno` |
yeah I noticed that slight bounce as well |
| 05:04 |
gregorycu |
A bounce, or just getting pushed up slightly? |
| 05:05 |
VanessaE |
a bounce. |
| 05:05 |
gregorycu |
urgh |
| 05:05 |
Zeno` |
no words to describe it! |
| 05:05 |
Zeno` |
it's a thing |
| 05:05 |
Zeno` |
the thingy effect |
| 05:06 |
gregorycu |
I'm going to have trace my y position |
| 05:06 |
gregorycu |
I can't notice it |
| 05:06 |
Zeno` |
gregorycu, that's because you're used to jumping up and down (being a monkey and all) |
| 05:07 |
Zeno` |
:3 |
| 05:07 |
gregorycu |
That's racist |
| 05:07 |
VanessaE |
hmmmm: damn it, you're forcing me to look at the code. |
| 05:07 |
VanessaE |
:) |
| 05:07 |
gregorycu |
Jokes |
| 05:07 |
gregorycu |
Oh, the pic |
| 05:07 |
hmmmm |
gregory is an abbo? :p |
| 05:07 |
gregorycu |
Right :P |
| 05:07 |
gregorycu |
lol, I am actually partially abbo |
| 05:07 |
gregorycu |
Like 1/32 |
| 05:07 |
Zeno` |
I thought you were a monkey with a hat |
| 05:07 |
Zeno` |
MonkeyHat Linux |
| 05:08 |
hmmmm |
lol hahaa |
| 05:08 |
hmmmm |
I thought the same thing when I saw the thumbnail of his avatar before i looked closer |
| 05:09 |
gregorycu |
God-damnit |
| 05:09 |
gregorycu |
Could the bob be the camera? |
| 05:09 |
VanessaE |
hmmmm: *shrug* I got nuthin', man. :P |
| 05:10 |
hmmmm |
Zeno` do you have the link to that valgrind output again |
| 05:10 |
Zeno` |
hmmmm, which output? |
| 05:10 |
hmmmm |
the one with the slow SP |
| 05:10 |
hmmmm |
I think that's caused by contention on g_settings |
| 05:10 |
Zeno` |
oh, it's in an open issue somewhere. I'll find it |
| 05:10 |
|
selat joined #minetest-dev |
| 05:11 |
Zeno` |
#2145 |
| 05:11 |
ShadowBot |
https://github.com/minetest/minetest/issues/2145 -- Multi-second lag in default singleplayer game |
| 05:11 |
hmmmm |
god damn |
| 05:11 |
hmmmm |
multi-second lag :( |
| 05:11 |
Zeno` |
see that pic? |
| 05:11 |
Zeno` |
that's not really "lag" per se. it's dtime |
| 05:12 |
hmmmm |
ok |
| 05:12 |
hmmmm |
it's just so depressing because after all the time and effort you put into minetest it's still FUBAR |
| 05:12 |
hmmmm |
engineered from the ground up to be slow |
| 05:12 |
Zeno` |
the person who made the mod was confused. Although there is some correlation between TTL and dtime of the server |
| 05:13 |
Zeno` |
I know :( |
| 05:13 |
Zeno` |
but it's fast everywhere except SP :) |
| 05:13 |
gregorycu |
VanessaE: If you still have that change, can you go into 3rd person view and tell me if the... bounce looks like it happens |
| 05:13 |
gregorycu |
Or if it's just a camera thing |
| 05:13 |
VanessaE |
already reverted it |
| 05:13 |
Zeno` |
TTL? err RTT I meant |
| 05:14 |
VanessaE |
lemme put it back in, one moment. |
| 05:14 |
VanessaE |
I see my player jitter vertically relative to the camera. |
| 05:17 |
kahrl |
trivial fix for an uninitialized variable I saw in valgrind: https://gist.github.com/kahrl/ad1c5908ce3e40201101 |
| 05:17 |
kahrl |
pushing ^ in a few minutes |
| 05:18 |
Zeno` |
it's hard to make sense of the SP profiles |
| 05:18 |
Zeno` |
with everything mixed in as it is |
| 05:18 |
Zeno` |
I had a few here and they were similar to Wayward_One's |
| 05:19 |
gregorycu |
Thank you |
| 05:36 |
kahrl |
gregorycu, question about your last commit: is m_fogEnabled initialized anywhere in GameGlobalShaderConstantSetter? |
| 05:36 |
kahrl |
valgrind reports it |
| 05:37 |
kahrl |
I don't know much about that code, hence my question |
| 05:37 |
gregorycu |
When the setting is set for the first time, the callback fires |
| 05:37 |
gregorycu |
Let me double check |
| 05:38 |
gregorycu |
Maybe it's a race condition |
| 05:38 |
kahrl |
what if the setting is set before the callback is registered? |
| 05:40 |
gregorycu |
bad greg |
| 05:40 |
kahrl |
also, is the callback ever unregistered when GameGlobalShaderConstantSetter is destructed? |
| 05:41 |
gregorycu |
Wouldn't the lifetime be bound the same way settings are? |
| 05:41 |
gregorycu |
I'll take a look, these sound like legitimate concerns |
| 05:41 |
kahrl |
g_settings is global |
| 05:41 |
kahrl |
GameGlobalShaderConstantSetter is constructed and destructed per game |
| 05:42 |
kahrl |
iiuc |
| 05:42 |
gregorycu |
But the settings are per-game? Right? |
| 05:42 |
kahrl |
no |
| 05:42 |
kahrl |
per process |
| 05:42 |
gregorycu |
ok |
| 05:42 |
gregorycu |
Give me 10 minutes, I need to eat something |
| 05:43 |
kahrl |
sure |
| 05:43 |
kahrl |
don't panic ;) |
| 05:47 |
gregorycu |
Too late |
| 05:48 |
Zeno` |
I find it hard to believe that there is an 8% improvement in the loop due to making a map lookup :p |
| 05:48 |
Zeno` |
Game::run() that is |
| 05:49 |
gregorycu |
It's not the map lookup |
| 05:50 |
gregorycu |
It's the converting "true" to boolean true |
| 05:50 |
gregorycu |
Along with the map lookup |
| 05:50 |
Zeno` |
and that consumes 8% of game::run() ? |
| 05:50 |
gregorycu |
Yep |
| 05:50 |
Zeno` |
we need to start from scratch in that case |
| 05:50 |
gregorycu |
One moment, i think I have some old profiling data |
| 05:51 |
VanessaE |
hmmmm: I've been wondering about the whole param1 thing.... just how many mods out there even DO anything with param1 other than paramtype="light" anyway? |
| 05:51 |
Zeno` |
not even spreadLight() etc use 8% |
| 05:52 |
Zeno` |
VanessaE, if they do would it be undefined behaviour? |
| 05:52 |
VanessaE |
good question |
| 05:52 |
Zeno` |
we need to write the Minetest Scripting Standard |
| 05:54 |
VanessaE |
grep -ir paramtype |grep -v light |grep -v paramtype2 --> three results in my entire mods tree. two of those are bogus, one is paramtype = "facedir_simple" |
| 05:54 |
Zeno` |
If we had The Standard we could just say "hey, you relied on undefined behaviour. Bad luck! Next!" |
| 05:54 |
Zeno` |
So, I think you should write The Standard |
| 05:54 |
kahrl |
"If you don't use these functions, you can use them to store arbitrary values. [...] param1 is reserved for the engine when paramtype != "none"" -- doc/lua_api.txt |
| 05:54 |
Zeno` |
hmm |
| 05:55 |
VanessaE |
out of 1749 paramtype = foo references. |
| 05:55 |
Zeno` |
well it's not undefined then :( |
| 05:55 |
VanessaE |
hrm |
| 05:56 |
gregorycu |
Where can I upload images? |
| 05:56 |
Zeno` |
Although perhaps we draft and ratify The Standard as part of the next iteration |
| 05:56 |
VanessaE |
gregorycu: tinypic? |
| 05:57 |
VanessaE |
wait, WHO should write The Standard? |
| 05:57 |
Zeno` |
I'm getting those valgrind errors as well, btw (gregorycu) |
| 05:57 |
Zeno` |
VanessaE is writing it apparently |
| 05:57 |
VanessaE |
no fucking way |
| 05:57 |
VanessaE |
ShadowNinja should write it |
| 05:57 |
Zeno` |
Well, the Standards Committee will write it |
| 05:58 |
VanessaE |
insert "1776" "You Should Write It" reference here. |
| 05:58 |
gregorycu |
http://tinypic.com/view.php?pic=349e14j&s=8 |
| 05:59 |
Zeno` |
which column is inclusive cost? |
| 06:00 |
gregorycu |
3rd number column |
| 06:00 |
Zeno` |
that's not relative to parent? |
| 06:01 |
Zeno` |
anyway, I only mentioned it for no reason at all :) |
| 06:01 |
gregorycu |
No, it's relative to overall |
| 06:01 |
Zeno` |
hmm ok |
| 06:01 |
gregorycu |
3.65 / 37.94 |
| 06:01 |
gregorycu |
To find relative |
| 06:02 |
hmmmm |
VanessaE, any mod that reads the light value |
| 06:02 |
hmmmm |
so mobs and plantlife |
| 06:04 |
VanessaE |
hmmmm: sure but those are API calls, which can be faked. I'm talking about setting it in a node def. |
| 06:05 |
VanessaE |
s/fakes/emulated/ |
| 06:05 |
gregorycu |
I've just noticed that the settings callback stuff isn't properly locked... |
| 06:06 |
Zeno` |
where? |
| 06:07 |
gregorycu |
Settings::registerChangedCallback |
| 06:07 |
gregorycu |
Comepare to Settings::doCallbacks |
| 06:07 |
gregorycu |
doCallbacks locks the map before access, registerChangedCallback does not |
| 06:07 |
gregorycu |
bb in 5 |
| 06:13 |
gregorycu |
back |
| 06:14 |
Zeno` |
something is wrong |
| 06:15 |
Zeno` |
I used to get 1-3 fps when profiling the client using callgrind. Now I get 0 |
| 06:17 |
gregorycu |
More calls? |
| 06:17 |
kahrl |
-O0 vs. -O1? |
| 06:17 |
Zeno` |
I profile using -O3 |
| 06:17 |
Zeno` |
(callgrind that is... for valgrind/memcheck I use -O0) |
| 06:18 |
Zeno` |
I dunno gregorycu... it hasn't been *that* long since I was profiling nearly every day |
| 06:18 |
* Zeno` |
makes sure something else in his setup hasn't changed |
| 06:20 |
hmmmm |
hey Zeno? where is it that you see 25% of cpu time is being taken up by thread switching in that callgrind output |
| 06:21 |
Zeno` |
cycle 23 |
| 06:22 |
Zeno` |
25%? |
| 06:22 |
Zeno` |
it's 16 or something |
| 06:22 |
* Zeno` |
looks |
| 06:24 |
hmmmm |
that says like 69.82% |
| 06:24 |
Zeno` |
<Wayward_One> Wow! Zeno`, lag is down to about 5 seconds now :D |
| 06:25 |
hmmmm |
:D ? as of gregory's enable_fog cache? |
| 06:25 |
Zeno` |
no... |
| 06:25 |
Zeno` |
I can't find what I asked him to do |
| 06:25 |
Zeno` |
lol |
| 06:26 |
Zeno` |
<Zeno`> Wayward_One, can you make sure that enable_mesh_cache = true is NOT in your minetest.conf? |
| 06:26 |
Wayward_One |
set enable_mesh_cache = false |
| 06:26 |
Wayward_One |
lol |
| 06:26 |
Zeno` |
I asked you to do that Wayward_One because yesterday I noticed that I got better in-game performance without it |
| 06:27 |
Zeno` |
I suspect that SP uses ~1.6GB for the "cache" |
| 06:27 |
Wayward_One |
wow |
| 06:27 |
Zeno` |
so maybe there is swapping occurring |
| 06:27 |
Zeno` |
in a client only game connecting to VE-S it uses ~800MB |
| 06:27 |
Zeno` |
wait... server doesn't create the cache (I don't think?) |
| 06:28 |
Wayward_One |
i don't have swap set up btw |
| 06:28 |
Zeno` |
anyway I suspected it might have been a memory issue |
| 06:28 |
Zeno` |
so maybe check mem usage with and without that setting |
| 06:32 |
hmmmm |
how did you determine that "<cycle 23>" is a thread switch? |
| 06:32 |
Zeno` |
traced it |
| 06:32 |
Zeno` |
actually |
| 06:32 |
Zeno` |
looking at it now it looks more like a driver thing |
| 06:32 |
* Zeno` |
is on painkillers and doing too many things at once :( |
| 06:33 |
* Zeno` |
closes about 20 windows |
| 06:34 |
Zeno` |
http://i.imgur.com/eito8aF.jpg |
| 06:34 |
hmmmm |
yeah |
| 06:34 |
hmmmm |
the crappy part about this output is that it keeps conflating all the different threads together |
| 06:34 |
hmmmm |
i'm finding it very difficult to make sense of |
| 06:34 |
Zeno` |
that's what I meant earlier |
| 06:34 |
Zeno` |
when I said it was hard heh |
| 06:35 |
hmmmm |
we can't be the first ones to stumble upon this problem |
| 06:35 |
hmmmm |
maybe there's some sort of annotation option |
| 06:35 |
hmmmm |
to sort by tid |
| 06:35 |
* Zeno` |
checks callgrind docs |
| 06:36 |
hmmmm |
well, to be sure, let's find a function that we know for sure enters into a wait |
| 06:36 |
hmmmm |
like JMutex.Lock() |
| 06:37 |
hmmmm |
hum.. the call graph of that one says that <cycle 23> whatever that is calls ScopeProfiler::~ScopeProfiler and Settings::get() |
| 06:37 |
hmmmm |
no comprendo |
| 06:38 |
|
NakedFury joined #minetest-dev |
| 06:38 |
hmmmm |
you know what I just realized, like right now? |
| 06:38 |
Zeno` |
nope |
| 06:38 |
Zeno` |
I lost my mind-reading powers after the accident |
| 06:38 |
hmmmm |
it's going to be a lot tougher to make settings fetches atomic thanks to my cool settings group |
| 06:39 |
hmmmm |
dammit Zeno` |
| 06:39 |
Zeno` |
what? |
| 06:39 |
hmmmm |
you were cooler when you were able to engage in teleapthy with me |
| 06:39 |
Zeno` |
heh |
| 06:40 |
Zeno` |
--separate-threads=yes |
| 06:40 |
Zeno` |
I'll see if that actually works |
| 06:42 |
gregorycu |
Your cool settings group? |
| 06:43 |
hmmmm |
yep |
| 06:43 |
hmmmm |
I used to have really cool settings groups |
| 06:43 |
gregorycu |
I don't even know what that means |
| 06:43 |
gregorycu |
By the way, does enabling and disabling fog actually work for anyone? |
| 06:43 |
Zeno` |
does for me |
| 06:44 |
hmmmm |
lol I'm just acting dumb |
| 06:44 |
Zeno` |
well it used to. Haven't checked today ;) |
| 06:44 |
gregorycu |
Ok |
| 06:45 |
Zeno` |
drawtime=210 lol |
| 06:45 |
Zeno` |
1007! |
| 06:46 |
hmmmm |
2302! |
| 06:46 |
hmmmm |
Hrmm |
| 06:46 |
Zeno` |
oh it just keeps going up |
| 06:46 |
Zeno` |
stabilised at ~1500 |
| 06:46 |
hmmmm |
210 seconds? |
| 06:46 |
hmmmm |
I thought all times displayed were in seconds |
| 06:46 |
hmmmm |
or at least that's what celeron said |
| 06:46 |
Zeno` |
I dunno, but that's what it's saying |
| 06:46 |
hmmmm |
ms then |
| 06:47 |
hmmmm |
well |
| 06:47 |
hmmmm |
if I do implement lockfree fast settings, they can't be namespaced |
| 06:47 |
Zeno` |
this profile is going to be useless. I can't even move |
| 06:47 |
hmmmm |
there goes the entire idea of adding a "client" and "server" namespace to all the settings |
| 06:49 |
gregorycu |
Huh? |
| 06:49 |
gregorycu |
Lockfree fast settings can't be namespaced? |
| 06:49 |
hmmmm |
well it can't be namespaced by using a settings group, which is what they were primarily implemented for |
| 06:50 |
gregorycu |
Out of interest, how were you going to implement lock-free settings? |
| 06:51 |
hmmmm |
atomically swap string pointers instead of setting std::string contents |
| 06:51 |
Zeno` |
ohh |
| 06:51 |
gregorycu |
*shrug* |
| 06:52 |
gregorycu |
What are we trying to solve here |
| 06:52 |
Zeno` |
split up by threads... nice |
| 06:52 |
gregorycu |
How often do settings change? |
| 06:52 |
hmmmm |
not very often |
| 06:52 |
gregorycu |
Look, I'm kind of of the option that there should ONLY be a callback mechanism then |
| 06:52 |
hmmmm |
well |
| 06:52 |
gregorycu |
ie. You can't query, only register a callback |
| 06:53 |
gregorycu |
The first time you register, it will fire, and give you the value |
| 06:53 |
gregorycu |
But beyond that |
| 06:53 |
hmmmm |
that certainly is a way to solve the problem |
| 06:53 |
hmmmm |
but you have to modify a lot more code |
| 06:53 |
gregorycu |
That does push the synchronization requirement onto the consumer |
| 06:54 |
hmmmm |
my idea is to remove the need for locking with settings fetch |
| 06:54 |
hmmmm |
and make it a very lightweight operation in general, so there IS no need for each component to maintain a cache |
| 06:55 |
hmmmm |
and to speed up all of the other settings that currently don't maintain a cache (which is a lot of them) |
| 06:55 |
gregorycu |
There still will be a map lookup... |
| 06:55 |
hmmmm |
nope |
| 06:55 |
gregorycu |
No? |
| 06:55 |
hmmmm |
I'd store it in a vector |
| 06:55 |
gregorycu |
There are two factors here |
| 06:56 |
gregorycu |
There is the synchronization factor, and there is the hardly-ever-changing factor |
| 06:56 |
gregorycu |
You're trying to fix the thread contention issue, I'm trying to fix the general slowness issue |
| 06:56 |
hmmmm |
well this would help both |
| 06:57 |
hmmmm |
this would essentially turn it into fetching a value from an array |
| 06:57 |
hmmmm |
and in the case where it is being written to, well, it's written atomically so there are no malformed reads ever |
| 06:57 |
gregorycu |
Well, it's not an index lookup |
| 06:57 |
hmmmm |
as-is |
| 06:57 |
gregorycu |
It's a pretty fast O(n) operation though |
| 06:58 |
gregorycu |
How often is it written to? Not very often... |
| 06:58 |
gregorycu |
Oh, and the other thing I think that needs to be thought about |
| 06:58 |
hmmmm |
this would require an interface change but one that can be solved by somehow morphing text in the format of g_settings->getX("foobar") to g_settings->getX(CSET_FOOBAR) |
| 06:58 |
hmmmm |
I'm not very good with sed so |
| 06:59 |
gregorycu |
Should settings be mandated to only change at the start of a render loop |
| 06:59 |
hmmmm |
I think that makes sense |
| 06:59 |
gregorycu |
As in, can you do half your render, and then a settings change, and the other half of the render is different? |
| 06:59 |
gregorycu |
Render, or tick... whatever |
| 07:00 |
hmmmm |
but at the same time like what happens if you change the texture filtering |
| 07:00 |
gregorycu |
And it's half way through the loop? |
| 07:00 |
hmmmm |
only newly generated meshes would use the filtering set |
| 07:00 |
gregorycu |
Ahh ok |
| 07:00 |
gregorycu |
Well, how often do settings change? |
| 07:00 |
gregorycu |
lol |
| 07:00 |
gregorycu |
What are we optiming here |
| 07:00 |
hmmmm |
like i said - not often |
| 07:01 |
hmmmm |
we are optimizing the read case |
| 07:01 |
gregorycu |
optimising |
| 07:01 |
hmmmm |
the read case can't be done quickly without removing the lock, and you can't remove the lock without using an atomic write |
| 07:01 |
hmmmm |
on most architectures I realize this isn't a problem, but you can't rely on that.. |
| 07:02 |
gregorycu |
How about this, a cache, completely lockfree |
| 07:02 |
gregorycu |
With the exception of a queue, and at a certain time, you can nominate the queue to be applied to the cache |
| 07:02 |
gregorycu |
The queue is a queue of changes |
| 07:03 |
gregorycu |
So, you get your "once a render loop" changes |
| 07:03 |
gregorycu |
And the only think you need to worry about locking is when harvesting the queue |
| 07:03 |
Zeno` |
I implemented that a few months ago |
| 07:03 |
Zeno` |
the settings got updated every server (or client) tick |
| 07:03 |
Zeno` |
updated/checked |
| 07:04 |
Zeno` |
but it was a bit messy the way I did it |
| 07:04 |
Zeno` |
I have a better way 75% finished |
| 07:04 |
Zeno` |
But, honestly, most of the things that were causing slowness are now cached |
| 07:05 |
Zeno` |
calls to Settings in the client consume... let me check |
| 07:05 |
gregorycu |
Unless the settings are the cause of contention |
| 07:06 |
Zeno` |
http://i.imgur.com/xBwf8Rk.jpg |
| 07:06 |
Zeno` |
bugger all CPU |
| 07:07 |
Zeno` |
which is why I'm taking so long with the callback class |
| 07:07 |
hmmmm |
gregorycu: it is |
| 07:08 |
hmmmm |
that's literally the only possible source of contention between Server and Client |
| 07:08 |
gregorycu |
ok |
| 07:08 |
hmmmm |
because it's the only data structure shared between them |
| 07:08 |
Zeno` |
I have a nice profile split up into threads |
| 07:08 |
hmmmm |
coo |
| 07:08 |
hmmmm |
let's see it |
| 07:08 |
Zeno` |
Can't make sense of it though lol |
| 07:08 |
hmmmm |
:( |
| 07:08 |
gregorycu |
I'm fairly certain that there should be two settings objects |
| 07:08 |
Zeno` |
I'll upload it somewhere |
| 07:09 |
gregorycu |
In a regular Client + Server they are not the same object |
| 07:09 |
gregorycu |
Why is single player different |
| 07:09 |
gregorycu |
Single player should just be an emulation of Client + Server |
| 07:09 |
hmmmm |
gregorycu: you could lock-in settings changes per render loop by doing something like this, I reckon: |
| 07:10 |
hmmmm |
bool enable_fog = g_settings->get(CSET_ENABLE_FOG); bool do_other_thing = g_settings->get(CSET_OTHER_THING); ... |
| 07:10 |
hmmmm |
at the beginning of the render loop |
| 07:10 |
hmmmm |
=D |
| 07:10 |
Zeno` |
hmmmm, https://www.dropbox.com/s/9y64ks4xs56pqmr/spgame.tar.gz?dl=0 |
| 07:11 |
Zeno` |
it's only a short profile. I'll make a larger one later, I just wanted to see if I'd be able to interpret these results first |
| 07:11 |
gregorycu |
hmmmm: But then you have to pass around those guys evertwgere |
| 07:11 |
gregorycu |
everywhere |
| 07:11 |
hmmmm |
what do you mean pass them around everywhere |
| 07:11 |
gregorycu |
And for sure, someone will query the settings directly |
| 07:11 |
hmmmm |
oh |
| 07:11 |
hmmmm |
yeah well |
| 07:11 |
hmmmm |
even so, it's plenty cheap |
| 07:11 |
gregorycu |
Anyway, I'm not saying it's a hard requirement |
| 07:11 |
hmmmm |
it's one of those things nice-to-have |
| 07:11 |
gregorycu |
Just saying maybe it's desirable |
| 07:12 |
gregorycu |
In any case |
| 07:12 |
gregorycu |
I think we are going about this the wrong way |
| 07:12 |
hmmmm |
hrmm |
| 07:12 |
gregorycu |
Because there MUST already be a synchronization mechanism between Client + Server |
| 07:13 |
hmmmm |
and of course, we need to guess which thread each callgrind output is |
| 07:13 |
gregorycu |
How else do remote servers set settings in the client? |
| 07:13 |
hmmmm |
they don't |
| 07:13 |
Zeno` |
well there are only 4 main ones |
| 07:13 |
Zeno` |
in KCachegrind they're easy enough to see :) |
| 07:13 |
gregorycu |
So, the set of settings between client and server are different? |
| 07:13 |
hmmmm |
gregorycu: yes |
| 07:13 |
gregorycu |
So, shouldn't they be in different containers? |
| 07:13 |
hmmmm |
sure.. |
| 07:14 |
gregorycu |
Game settings and client settings |
| 07:14 |
hmmmm |
but that only solves the contention issue |
| 07:14 |
gregorycu |
Right |
| 07:14 |
hmmmm |
we can kill two birds with one stone by doing this |
| 07:14 |
hmmmm |
and by the time we're done talking about it, it could already be coded |
| 07:14 |
hmmmm |
could've* |
| 07:14 |
hmmmm |
could've been* |
| 07:14 |
Zeno` |
thread 6 seems to be connection thread |
| 07:14 |
gregorycu |
We talk about it now so when people ask why we did it the way we did it, we have good answers |
| 07:14 |
Zeno` |
thread 9 emerge |
| 07:14 |
Zeno` |
thread 10 mesh update |
| 07:15 |
hmmmm |
I had a really stupid "deferred thing get" mechanism in 0.4.9 that I called the NodeResolver |
| 07:15 |
gregorycu |
I have a question |
| 07:15 |
hmmmm |
reminds me a lot of this situation |
| 07:15 |
gregorycu |
Are some settings stored against the world? |
| 07:15 |
hmmmm |
yes. |
| 07:16 |
hmmmm |
they're stored in map_meta.txt |
| 07:16 |
gregorycu |
And that gets loaded into g_settings on world load? |
| 07:16 |
hmmmm |
nope, they override what g_settings set the parameters to |
| 07:16 |
gregorycu |
They override defaults? |
| 07:16 |
Zeno` |
is the server even in a thread? |
| 07:16 |
hmmmm |
Zeno`: lol, yes |
| 07:16 |
Zeno` |
oh, thread 6 |
| 07:17 |
Zeno` |
sorry, I've never tried this split profile approach before :) |
| 07:17 |
gregorycu |
*sigh* I don't really care that much, but I still don't like it how client and game settings are just all chucked together |
| 07:17 |
gregorycu |
But I'll be quiet now |
| 07:17 |
hmmmm |
gregorycu, no it's like: active_parameters.apply(g_settings); active_parameters.apply(world_specific_settings); |
| 07:18 |
Zeno` |
lol, I told you that profile would be useless |
| 07:18 |
|
NakedFury joined #minetest-dev |
| 07:18 |
Zeno` |
it never got out of send/recieve data (and I did not turn instrumentation on until the game was up and running!) |
| 07:19 |
Zeno` |
well, maybe not so useless... it was running for about 10 minutes with instrumentation on |
| 07:19 |
hmmmm |
heh |
| 07:19 |
hmmmm |
I want to see the EmergeThread |
| 07:20 |
Zeno` |
seems to be thread 9 |
| 07:20 |
Zeno` |
the one with -09 |
| 07:21 |
hmmmm |
yep |
| 07:22 |
hmmmm |
I'm not sure I'm understanding the results correctly |
| 07:22 |
hmmmm |
so for example, on the emergethread output, for CNodeDefManager::getId() |
| 07:22 |
hmmmm |
the all callers tab tells you all of the functions that called this, and how much each percentage they make up of the calls? |
| 07:23 |
hmmmm |
(well, execution time) |
| 07:23 |
Zeno` |
35% |
| 07:23 |
Zeno` |
yeah |
| 07:23 |
Zeno` |
you need... umm |
| 07:23 |
hmmmm |
what is 35%? |
| 07:23 |
hmmmm |
err oh |
| 07:24 |
hmmmm |
I'm not talking about percentage relative to the entire execution |
| 07:24 |
hmmmm |
in any case that figure of 35% sounds really shocking. so I'm trying to find out which functions call it the most |
| 07:24 |
Zeno` |
well it was called 203962362 times |
| 07:25 |
hmmmm |
now in All Callers, it has a whole bunch of 100.00 %s |
| 07:25 |
hmmmm |
but then it has two 22% and then one 0.12% |
| 07:25 |
Zeno` |
mostly by correctBlockNodIds |
| 07:25 |
hmmmm |
aren't they supposed to add up to something? |
| 07:25 |
Zeno` |
how are you viewing the results? |
| 07:25 |
Zeno` |
just as text? |
| 07:26 |
hmmmm |
no, in kcachegrind like you are |
| 07:26 |
Zeno` |
click relative to parent at the top |
| 07:27 |
hmmmm |
there's still ~87% missing |
| 07:27 |
hmmmm |
that helped for the bottom window with the Ir and Ir per call |
| 07:28 |
Zeno` |
All callers |
| 07:28 |
hmmmm |
yes that's where I am right now |
| 07:28 |
Zeno` |
mine add up |
| 07:28 |
Zeno` |
to the total inclusive cost |
| 07:28 |
Zeno` |
maybe there is something in settings that I have different |
| 07:29 |
hmmmm |
hrmm |
| 07:29 |
hmmmm |
for some reason it's as if I'm missing several |
| 07:30 |
Zeno` |
dunno why :/ |
| 07:31 |
Zeno` |
BUT I would not take those results too seriously; if you look at the other threads it never got around to doing much at all |
| 07:31 |
hmmmm |
yeah |
| 07:31 |
hmmmm |
I can tell that 10 blocks got generated |
| 07:31 |
Zeno` |
so it's 35% of nothing |
| 07:31 |
hmmmm |
err.. 10 chunks |
| 07:32 |
hmmmm |
most of the ndef->getId() happened when loading blocks from the db... that part literally can't be helped, no way to improve it |
| 07:32 |
hmmmm |
aside from improving the storage structure |
| 07:32 |
Zeno` |
I'll let it run for a few hours tonight and /ms you a link |
| 07:32 |
hmmmm |
well |
| 07:32 |
Zeno` |
I can't believe how slow it is (profiling SP game that is) |
| 07:32 |
hmmmm |
I'm not TOO interested |
| 07:33 |
Zeno` |
Well, I am. So I'll paste a link somewhere anyway :) |
| 07:33 |
hmmmm |
how do I fix the paths for missing files in the source code tab? |
| 07:34 |
Zeno` |
don't think you can :( They're generated by -g AFAIK |
| 07:35 |
Zeno` |
for Wayward_One's I setup a sym link (yuck) |
| 07:45 |
hmmmm |
wow =/ |
| 07:45 |
hmmmm |
99.25% of execution time spent loading a block is spent doing std::map lookups |
| 07:46 |
Zeno` |
oops |
| 07:46 |
Zeno` |
http://i.imgur.com/eXnPtJq.jpg |
| 07:46 |
Zeno` |
^--- I meant to post that before |
| 07:46 |
hmmmm |
that's just sad... but it's too bad callgrind doesn't tell you how much the absolute time spent is, so you can't figure out how long the loads took |
| 07:46 |
Zeno` |
you can get absolute time I think... somehow |
| 07:47 |
Zeno` |
but probably have to re-profile |
| 07:47 |
hmmmm |
that would be cool to check for lock contention as well |
| 07:47 |
hmmmm |
time to acquire != number of instructions executed :p |
| 07:47 |
hmmmm |
which is why I was saying your conclusion that 25% of the time is being spent on thread switching sounds wrong |
| 07:48 |
Zeno` |
maybe helgrind does that... never looked at it |
| 07:48 |
hmmmm |
i thought that was for catching race conditions |
| 07:49 |
Zeno` |
dunno. Haven't read what it can do |
| 07:49 |
Zeno` |
valgrind checks for memleaks |
| 07:50 |
Zeno` |
+ other stuff :p So maybe helgrind has + other stuff also |
| 07:51 |
Zeno` |
it's got "Inconsistent Lock Orderings" |
| 07:51 |
Zeno` |
dunno if that'd be helpful |
| 07:52 |
hmmmm |
yeah, a longer run with callgrind would be very helpful |
| 07:52 |
hmmmm |
possibly with mapgen v5 too |
| 07:53 |
Zeno` |
I can make longer runs easier just for server or client... it's only singleplayer that takes so @*$(@@*$(@ long |
| 07:53 |
Zeno` |
I'll run it for maybe 1 hour tonight though |
| 07:54 |
hmmmm |
hem |
| 07:54 |
Zeno` |
and see how that looks; if it's stupid, I'll run for 2 |
| 07:54 |
hmmmm |
hrm* |
| 07:54 |
Zeno` |
maybe I'll just run for 2 |
| 07:54 |
Zeno` |
save have to waste an hour if an hour is not long enough |
| 07:54 |
|
NakedFury joined #minetest-dev |
| 07:55 |
hmmmm |
you know, writes to settings are rare |
| 07:55 |
Zeno` |
very |
| 07:55 |
hmmmm |
Zeno`, try removing locking from Settings calls |
| 07:55 |
hmmmm |
and just see |
| 07:55 |
hmmmm |
if SP runs as smooth as multiplayer |
| 07:56 |
Zeno` |
reads are pretty rare as well |
| 07:56 |
Zeno` |
but I will do it |
| 07:57 |
Zeno` |
wait, reads are not locked anyway :) |
| 07:57 |
hmmmm |
erm.. they're not..? |
| 07:57 |
hmmmm |
they most definitely are |
| 07:58 |
Zeno` |
yes |
| 07:58 |
Zeno` |
didn't notice they all went back to Settings::getEntry |
| 07:59 |
hmmmm |
for what it's worth, we can do a small optimization by unlocking before we go to look up in m_defaults |
| 08:01 |
Zeno` |
well I can move at least |
| 08:03 |
Zeno` |
based on max_lag it does seem to make a difference. And it *seems* smoother |
| 08:03 |
Zeno` |
I'll try to work out a way to quantify it |
| 08:05 |
hmmmm |
hey whaddya know |
| 08:05 |
hmmmm |
from what you said though it doesn't seem like it's all the way as good as running in separate processes |
| 08:05 |
|
ImQ009 joined #minetest-dev |
| 08:06 |
hmmmm |
we should figure that part out |
| 08:06 |
Zeno` |
oh yeah, it's been like that for a long time |
| 08:06 |
Zeno` |
which is why I never noticed SP was slow |
| 08:06 |
Zeno` |
because I never ran SP games that way heh |
| 08:09 |
Zeno` |
hmmmm, https://www.dropbox.com/s/xo23l2e768ljy1w/spnosettinglocks.tar.gz?dl=0 |
| 08:09 |
Zeno` |
I didn't bother separate threads, and that's a very short run again |
| 08:09 |
Zeno` |
The profile looks quite different to my earlier ones though |
| 08:09 |
Zeno` |
anyway, in a hurry! |
| 08:10 |
Zeno` |
cyas |
| 08:10 |
hmmmm |
bye |
| 08:10 |
|
Hunterz joined #minetest-dev |
| 08:12 |
|
gregorycu joined #minetest-dev |
| 08:15 |
gregorycu |
ffs |
| 08:16 |
gregorycu |
Zeno, why is git so hard? |
| 08:16 |
gregorycu |
https://github.com/gregorycu/minetest/commits/Settings-Fixes says I am two commits ahead |
| 08:17 |
gregorycu |
Even though one of the two commits has already been merge to master |
| 08:17 |
gregorycu |
https://github.com/minetest/minetest/commits/master |
| 08:17 |
gregorycu |
"Make the GameGlobalShaderConstantSetter use the settings callback " |
| 08:37 |
|
NakedFury joined #minetest-dev |
| 08:43 |
|
Amaz joined #minetest-dev |
| 08:55 |
|
DFeniks joined #minetest-dev |
| 08:58 |
|
ImQ009 joined #minetest-dev |
| 09:08 |
|
kilbith joined #minetest-dev |
| 09:09 |
|
nrzkt joined #minetest-dev |
| 09:09 |
nrzkt |
26 ? yesterday is was 29 |
| 09:10 |
|
ImQ009 joined #minetest-dev |
| 09:10 |
gregorycu |
? |
| 09:10 |
gregorycu |
TENATIVE RELEASE DATE: 2015-01-29 |
| 09:10 |
nrzkt |
oh, i think it was old message not updated :p |
| 09:10 |
nrzkt |
it's good now, sorry |
| 09:14 |
|
NakedFury joined #minetest-dev |
| 09:22 |
|
Calinou joined #minetest-dev |
| 09:24 |
nrzkt |
WTF bug |
| 09:24 |
nrzkt |
i can cause an assert on any server with a modificated client xD |
| 09:30 |
gregorycu |
Nice bro |
| 09:31 |
* cheapie |
hands nrzkt an empty bug report to fill out |
| 09:31 |
nrzkt |
i don't do a bug report |
| 09:31 |
nrzkt |
i'll do a PR when i handle this throw which cause server to stop |
| 09:32 |
cheapie |
That works too. |
| 09:32 |
nrzkt |
(i found this because i'm working on client networking reworks) |
| 09:32 |
cheapie |
Yeah... I forgot these are mostly devs here. |
| 09:32 |
gregorycu |
Someone should create a dedicated IRC channel for the devs |
| 09:32 |
gregorycu |
Oh |
| 09:32 |
nrzkt |
it's here :D |
| 09:33 |
* cheapie |
resizes his channel list so he can see the full name of the channel instead of just "#minetest-" |
| 09:34 |
cheapie |
Meh, I'm a (lazy) mod dev. Close enough. |
| 09:34 |
* cheapie |
wanders back off to #debian |
| 09:38 |
|
roniz joined #minetest-dev |
| 09:42 |
gregorycu |
#2190 |
| 09:42 |
ShadowBot |
https://github.com/minetest/minetest/issues/2190 -- Settings related fixes by gregorycu |
| 09:42 |
sfan5 |
TIL there is a feature freeze |
| 09:45 |
gregorycu |
sfan5: Are you able to comment on my profiler fix, even if just to say "ok" #2173 |
| 09:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/2173 -- Speed up Profiler::avg by a factor of 10 by gregorycu |
| 09:45 |
sfan5 |
gregorycu: done |
| 09:46 |
gregorycu |
Thanks sfan5 :) |
| 09:49 |
gregorycu |
#2191 |
| 09:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/2191 -- Fix chat scrolling bug (trying to negate unsigned) by gregorycu |
| 09:49 |
* gregorycu |
& |
| 09:51 |
jin_xi |
hm re collision, its really bad if you make more particle spawn and have them stick around longer. |
| 09:52 |
jin_xi |
lots of false hits on node borders, resulting in grid like patterns of particles. they use same collision function as players |
| 10:05 |
nrzkt |
ok i found the issue, we test serialize < 24 but SER_FMT_VER_LOWEST is 0 |
| 10:06 |
nrzkt |
then if i set a INIT command with version < 24, server crash |
| 10:06 |
nrzkt |
... |
| 10:08 |
|
SopaXorzTaker joined #minetest-dev |
| 10:10 |
nrzkt |
Please merge #2192 |
| 10:10 |
ShadowBot |
https://github.com/minetest/minetest/issues/2192 -- Fix a crash (assert) when client set serial version < 24 in INIT command by nerzhul |
| 10:11 |
|
Krock joined #minetest-dev |
| 10:14 |
|
NakedFury joined #minetest-dev |
| 10:23 |
nrzkt |
you must commit #2192 fast, i tested it on 5 public servers, each server crash. now vulnerability is public |
| 10:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/2192 -- Fix a crash (assert) when client set serial version < 24 in INIT command by nerzhul |
| 10:23 |
kilbith |
i confirm, nrzkt has crashed a server in my presence |
| 10:25 |
Krock |
https://github.com/nerzhul/minetest/commit/ac699798#diff-a3d43cc239efc733a8a046ff0a6bc91eL532 use return; |
| 10:25 |
nrzkt |
no |
| 10:25 |
|
NakedFury joined #minetest-dev |
| 10:25 |
nrzkt |
version is set when _INIT command is sent |
| 10:25 |
Krock |
it would throw an error later |
| 10:25 |
nrzkt |
and isn't modified elsewhere |
| 10:25 |
nrzkt |
look at _INIT packet handling |
| 10:26 |
nrzkt |
the throw become useless because we handle it when client sent _INIT command with wrong serial version |
| 10:26 |
nrzkt |
then this test is useless. |
| 10:26 |
nrzkt |
in the PR we didn't see the _INIT handling, but i can tell you it's the case, because it's how i found the issue :) |
| 10:28 |
Krock |
sorry but "if(!ser_ver_supported(version))" throws an other exception now because the version is not supported anymore |
| 10:29 |
Krock |
or I just misunderstand that |
| 10:29 |
nrzkt |
if tested a 0.4.11-dev server and it works perfect |
| 10:29 |
nrzkt |
i* |
| 10:29 |
Krock |
hmh |
| 10:30 |
nrzkt |
i tested game and there are no issue after this fix. Client sent serial version 26 in 0.4.11, and we must have 24, it's the minimum for mapblock |
| 11:01 |
gregorycu |
... |
| 11:01 |
|
psedlak joined #minetest-dev |
| 11:02 |
gregorycu |
You know, I like to think I'm a guy with (slightly) above intelligence |
| 11:02 |
gregorycu |
Why the fuck am I having so much trouble with git |
| 11:03 |
gregorycu |
Like, I almost want to cry |
| 11:03 |
gregorycu |
I'm that frustrated |
| 11:05 |
jin_xi |
did you rtfm? |
| 11:06 |
gregorycu |
What do you mean? |
| 11:08 |
jin_xi |
read the fucking manual, classical non helpful reply to software frustrations |
| 11:08 |
gregorycu |
Indeed |
| 11:08 |
gregorycu |
Like, I do a git status, and everything looks fine |
| 11:09 |
gregorycu |
I then do a git push --force, and it updates other branches |
| 11:09 |
gregorycu |
Like, didn't see that coming |
| 11:09 |
gregorycu |
All because I wanted to do a small amendment to a commit |
| 11:26 |
gregorycu |
You know what never gets old, redoing the same fixes over and over again |
| 11:47 |
|
Unidan2 joined #minetest-dev |
| 11:59 |
|
alket joined #minetest-dev |
| 12:03 |
gregorycu |
#2193 |
| 12:03 |
ShadowBot |
https://github.com/minetest/minetest/issues/2193 -- Settings fixes by gregorycu |
| 12:08 |
|
ElectronLibre joined #minetest-dev |
| 12:09 |
|
MinetestForFun joined #minetest-dev |
| 12:10 |
|
leat joined #minetest-dev |
| 12:12 |
|
Unidan2 joined #minetest-dev |
| 12:12 |
|
Zeno` joined #minetest-dev |
| 12:13 |
nrzkt |
zeno please commit #2192 fast, security fix |
| 12:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/2192 -- Fix a crash (assert) when client set serial version < 24 in INIT command by nerzhul |
| 12:15 |
Zeno` |
so.. the server does not accept clients that don't use version 24? |
| 12:15 |
nrzkt |
if you set version < 24 server accept you but mapblock::serialize assert. Then die |
| 12:15 |
nrzkt |
the MIN is not set, and the throw became useless if you set the MIN_SERIAL because it's tested, before |
| 12:16 |
nrzkt |
i have tested it on 5 public servers today, it works perfect :p |
| 12:16 |
nrzkt |
sent a _INIT packet with first byte crafted and BOUM |
| 12:16 |
Zeno` |
where is the assert? |
| 12:17 |
nrzkt |
look at this PR. |
| 12:17 |
nrzkt |
or give me you server IP i connect and crash your server :p |
| 12:17 |
Zeno` |
I have, but where is the assert that fails? |
| 12:17 |
|
leat joined #minetest-dev |
| 12:18 |
nrzkt |
i don't found it, it's related to AsyncRunTask |
| 12:18 |
nrzkt |
but my fix works perfect because MIN_SERIAL is set, then client set a proper version for serial, which is >= 24 and then we don't need the throw. |
| 12:18 |
Zeno` |
surely it can be found... it doesn't give a file and line number? |
| 12:18 |
nrzkt |
no |
| 12:19 |
Zeno` |
assert() prints it to stdout |
| 12:19 |
nrzkt |
i know, thanks. |
| 12:19 |
Zeno` |
I see what you're saying and I agree this is important |
| 12:19 |
nrzkt |
i have a ASSERT 0 and it show the throw error. |
| 12:20 |
nrzkt |
not the assert line |
| 12:20 |
nrzkt |
give me your server, i connect to it and you have the stdout. |
| 12:20 |
nrzkt |
the fix is there please patch. |
| 12:20 |
Zeno` |
I believe you :p |
| 12:20 |
nrzkt |
i explained you what is the problem, fixed it properly because core dev forget to update a global variable which is very important for protocol and create a big hole |
| 12:21 |
Zeno` |
I only just joined though... give be time to digest this ;) |
| 12:22 |
nrzkt |
to be precise. When _INIT is handled, it set serial_version to client. But the test for MIN_SERIAL is to test, actually, if MIN_SERIAL < 0 (impossible, it's a u8), because DEFINE is wrong |
| 12:22 |
Zeno` |
what a mess |
| 12:22 |
Zeno` |
yeah, it's always true |
| 12:22 |
Zeno` |
I've looked at this code before |
| 12:22 |
nrzkt |
if client serial_verison is set properly, then MapBlock::serialize don't have problem because it's impossible to have a unhandled serial version |
| 12:22 |
Zeno` |
and was told "theoretically we support version 0" :/ |
| 12:22 |
Zeno` |
which is rubbish if you ask me |
| 12:23 |
nrzkt |
it's wrong, because version 0 = crash on mapblock :p |
| 12:23 |
Zeno` |
I know it's wrong :( |
| 12:24 |
Zeno` |
It's a DoS |
| 12:24 |
Zeno` |
geez |
| 12:24 |
Zeno` |
umm |
| 12:25 |
Zeno` |
when was version 24 introduced? |
| 12:25 |
nrzkt |
i don't know, but client is in version 26 |
| 12:25 |
Zeno` |
yeah I need to know when version 24 was implemented though to at least help make a decision |
| 12:26 |
nrzkt |
decision is simple, patch or i crash every server :p |
| 12:26 |
Zeno` |
there are a lot of clients out there that are still version 0.4.9 (for example |
| 12:26 |
Krock |
0.3.1 is very popular somehow |
| 12:26 |
nrzkt |
i patch for 0.4.12 |
| 12:27 |
Zeno` |
what serialization version does 0.3.1 use? |
| 12:27 |
nrzkt |
previous 0.4 release must upgrade |
| 12:27 |
Zeno` |
nrzkt, what I don't want to see happen is that people using the 0.3.1 client unable to connect to servers |
| 12:27 |
nrzkt |
0.4.x must go to 0.4.11 |
| 12:27 |
Zeno` |
this is not my decision but a decision made before I even joined the team |
| 12:27 |
nrzkt |
i look at stable-0.3 ? |
| 12:27 |
|
NakedFury joined #minetest-dev |
| 12:28 |
Zeno` |
Krock, does stable-0.3 sound reasonable? |
| 12:28 |
nrzkt |
SER_FMT_VER_HIGHEST is the value to look |
| 12:28 |
Krock |
Zeno`, I don't know |
| 12:28 |
nrzkt |
https://github.com/minetest/minetest/blob/stable-0.3/src/serialization.h |
| 12:28 |
nrzkt |
0.3 is incompatible with 0.4 |
| 12:28 |
nrzkt |
#define SER_FMT_VER_HIGHEST 20 |
| 12:28 |
Zeno` |
hmm |
| 12:28 |
nrzkt |
20 is sent to server |
| 12:29 |
nrzkt |
then server will crash :p |
| 12:29 |
Zeno` |
yes, I can see how that would happen |
| 12:29 |
nrzkt |
then 0.4 servers and incompatible with 0. |
| 12:30 |
nrzkt |
0.3, because only > 24 is supported by MapBlock::serialize |
| 12:32 |
Zeno` |
wtf is the server throwing an error for if the version is incorrect anyway? |
| 12:32 |
nrzkt |
now, we need to patch 0.4 series. Because they are ALL vulnerable |
| 12:32 |
nrzkt |
ofc, but it must be handled at connection, like now, because client CANNOT receive mapblocks. |
| 12:33 |
Zeno` |
shouldn't it just drop the connection though? |
| 12:33 |
nrzkt |
and my patch is the only solution. If we CANT serialize, we must block the client. |
| 12:33 |
nrzkt |
my solution permit to say at connection: client version incompatible. It's the right way. |
| 12:34 |
Zeno` |
please find out when ser. version was introduced |
| 12:34 |
Zeno` |
version 24 |
| 12:34 |
nrzkt |
long time ago. It's already in 0.3 |
| 12:34 |
nrzkt |
https://github.com/minetest/minetest/blob/stable-0.2/src/serialization.h |
| 12:34 |
nrzkt |
and already in 0.2 |
| 12:34 |
nrzkt |
then... FIX |
| 12:35 |
Zeno` |
your link says version 20 :P |
| 12:35 |
nrzkt |
yes, but serial version was in 0.2. it was already here. Then everytime it exists. |
| 12:35 |
kilbith |
nrzkt has crashed like 10 servers this morning |
| 12:35 |
Zeno` |
I don't deny the bug is there |
| 12:35 |
nrzkt |
now, don't search to handle things unhandled. 0.4.12 need to be stable, fix the crash is a stabilization. Handle 0.3 client isn't. |
| 12:35 |
Zeno` |
I just want to know the range of clients that will no longer be able to connect |
| 12:36 |
nrzkt |
every < 0.4 client. |
| 12:37 |
nrzkt |
here |
| 12:37 |
nrzkt |
https://github.com/minetest/minetest/commit/fd845f27f5b3e3c6587c472be76235567a7b934d |
| 12:37 |
nrzkt |
23 Jul 2012, two years and 6 month ago. |
| 12:37 |
nrzkt |
0.4.2-rc1 |
| 12:38 |
Zeno` |
ok, let me review the code again |
| 12:38 |
nrzkt |
ok, fixing MIN_SERIAL_VER block client unhandled on mapblock::serialize. This permit every client from 0.4.2 to now |
| 12:39 |
nrzkt |
because vers 24 25 and 26 are handled by server |
| 12:39 |
Zeno` |
ok, it all looks ok |
| 12:39 |
Zeno` |
I'll merge it |
| 12:39 |
nrzkt |
thanks |
| 12:47 |
Zeno` |
gregorycu, is that uninit var. fixeD? |
| 12:47 |
gregorycu |
Yes |
| 12:47 |
gregorycu |
umm... |
| 12:48 |
Zeno` |
ahh I see it is |
| 12:48 |
Zeno` |
will merge in a minute. Give me 10 to review? |
| 12:48 |
gregorycu |
#2193 |
| 12:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/2193 -- Settings fixes by gregorycu |
| 12:48 |
gregorycu |
Yep |
| 12:48 |
gregorycu |
At your leasure |
| 12:49 |
Zeno` |
I can't see where deregister() is called from (in game.cpp) |
| 12:50 |
gregorycu |
Seriously? |
| 12:50 |
gregorycu |
Yeah |
| 12:50 |
gregorycu |
ffs |
| 12:50 |
gregorycu |
I've been battling against git for the past 2 hours |
| 12:51 |
gregorycu |
Had to do that change like 3 times |
| 12:52 |
gregorycu |
(In the end I destroyed and recreated my local git repo) |
| 12:52 |
Zeno` |
:) |
| 12:52 |
gregorycu |
here is a pro tip |
| 12:53 |
Zeno` |
gawd I hate that term, but anyway... waiting heh |
| 12:53 |
gregorycu |
git push --force will force push all your changes, not just changes for the current branch |
| 12:53 |
Zeno` |
oh, yeah, it will |
| 12:53 |
gregorycu |
That's what screwed me |
| 12:53 |
gregorycu |
I had two repos, and they were fighting over the pushes |
| 12:54 |
|
n4x joined #minetest-dev |
| 12:55 |
Zeno` |
d'oh :) |
| 12:56 |
gregorycu |
it's pretty fucking retarded that there is no command to say: "I want to reclone" |
| 13:04 |
Zeno` |
gregorycu, doCallbacks() seems wrong |
| 13:05 |
Zeno` |
if the callback calls getSetting() (or whatever it's called) there is another lock |
| 13:05 |
Zeno` |
and it will be a deadlock if I'm not mistaken |
| 13:05 |
Zeno` |
which, I guess, was the reason for the tempvector in the first place |
| 13:05 |
gregorycu |
Surely the lock is reentrant |
| 13:06 |
gregorycu |
The thing is, you have to lock |
| 13:06 |
gregorycu |
The think you are dispatching to may deregister itself and get destroye |
| 13:06 |
gregorycu |
d |
| 13:06 |
gregorycu |
While you are iterating through the temp vector |
| 13:06 |
Zeno` |
hmm, yes |
| 13:07 |
gregorycu |
I didn't deadlock on myself when i was testing |
| 13:07 |
Zeno` |
ok, with your code open up a command console in a singleplayer game and press whatever the key is to enable/disable fog |
| 13:08 |
Zeno` |
doh |
| 13:08 |
Zeno` |
ok, with your code start a singleplayer game and press whatever the key is to enable/disable fog |
| 13:08 |
gregorycu |
Right |
| 13:08 |
gregorycu |
It doesn't work |
| 13:08 |
gregorycu |
It never worked |
| 13:08 |
gregorycu |
(i asked if it was working before) |
| 13:09 |
Zeno` |
testing now |
| 13:09 |
Zeno` |
it used to work for me |
| 13:09 |
Zeno` |
haven't tested in ages though |
| 13:09 |
gregorycu |
If you restart the map it takes effect |
| 13:09 |
gregorycu |
There is a cache in the game |
| 13:09 |
gregorycu |
I was going to fix it, but I have too much on my plate at the moment |
| 13:10 |
gregorycu |
Especially if the settings system will be reworked |
| 13:11 |
|
n4x joined #minetest-dev |
| 13:12 |
gregorycu |
Fucking hell, I'm segv ing |
| 13:13 |
|
Garmine joined #minetest-dev |
| 13:14 |
|
T4im joined #minetest-dev |
| 13:14 |
gregorycu |
Ok, config error |
| 13:18 |
Zeno` |
who broke fog? |
| 13:19 |
gregorycu |
There are caches in game |
| 13:19 |
gregorycu |
No idea if they get updated |
| 13:20 |
Zeno` |
seems I did |
| 13:20 |
gregorycu |
m_cache_enable_fog |
| 13:22 |
gregorycu |
Classic Zeno move |
| 13:22 |
Zeno` |
yeah I think it was left over after I removed the callback (because people didn't like it) |
| 13:23 |
gregorycu |
On the plus side, there is a new callback to use |
| 13:27 |
gregorycu |
#2193 has been updated |
| 13:27 |
ShadowBot |
https://github.com/minetest/minetest/issues/2193 -- Settings fixes by gregorycu |
| 13:31 |
kilbith |
2156 is abandonned ? |
| 13:31 |
gregorycu |
#2156 |
| 13:31 |
ShadowBot |
https://github.com/minetest/minetest/issues/2156 -- Optimise MapBlockMesh functions by gregorycu |
| 13:31 |
gregorycu |
Shouldn't be |
| 13:32 |
gregorycu |
Looks fine to me? |
| 13:33 |
Zeno` |
oh I've disabled fog :/ |
| 13:34 |
gregorycu |
That's a bit of a dick move |
| 13:35 |
Zeno` |
no, locally |
| 13:35 |
|
ImQ009 joined #minetest-dev |
| 13:37 |
gregorycu |
I really don't understand what this collision detection code was about, and I can't understand what you and V were about when you said there was bouncing after jumping |
| 13:39 |
Zeno` |
why is making a change to my local settings a dick move? :p |
| 13:40 |
gregorycu |
I thought you had checked it in and broken fog |
| 13:40 |
Zeno` |
such faith! |
| 13:42 |
gregorycu |
That's me |
| 13:42 |
gregorycu |
They don't call me faithless greg for nothing |
| 13:44 |
gregorycu |
How would you describe this bounce? |
| 13:44 |
gregorycu |
Could you describe it as an additional jump? |
| 13:44 |
gregorycu |
Cause if I hold down space, my dude jumps the second he is on the new block |
| 13:45 |
gregorycu |
Well, not the second, the moment |
| 13:45 |
Zeno` |
it's a bounce and then slow sinking |
| 13:45 |
gregorycu |
lol |
| 13:45 |
Zeno` |
:D |
| 13:46 |
gregorycu |
Fuck me, what the hell is going on |
| 13:47 |
Zeno` |
gregorycu, regarding what I said about locks... |
| 13:47 |
gregorycu |
Yeah? |
| 13:48 |
jin_xi |
collisionMoveSimple is broken in some ways for sure |
| 13:48 |
Zeno` |
a) start a single player game; b) open console; c) type /set enable_fog = false |
| 13:48 |
Zeno` |
(with your latest patch) |
| 13:48 |
gregorycu |
Ok, let me build |
| 13:48 |
Zeno` |
it'll sit there waiting for the mutex to be freed |
| 13:49 |
|
SopaXorzTaker joined #minetest-dev |
| 13:51 |
gregorycu |
Well, I'm segfaulting, which is nice |
| 13:53 |
Zeno` |
I saw from the code (before I even compiled) that the mutex would not be released and that the callback would deadlock :P~ |
| 13:55 |
gregorycu |
It worked for me |
| 13:56 |
gregorycu |
Different underlying lock? |
| 13:56 |
Zeno` |
/set enable_fog = false works for you? |
| 13:56 |
gregorycu |
Yes, and as soon as this finishes compiling, I'll confirm |
| 13:56 |
Zeno` |
well there is a different underlying lock. From memory on Linux the POSIX locks are used |
| 13:57 |
Zeno` |
On Windows... not sure |
| 13:59 |
gregorycu |
"When a thread owns a critical section, it can make additional calls to EnterCriticalSection or TryEnterCriticalSection without blocking its execution. This prevents a thread from deadlocking itself while waiting for a critical section that it already owns. " |
| 14:00 |
gregorycu |
CRITICAL_SECTION mutex; |
| 14:00 |
gregorycu |
So yeah, fine on windows |
| 14:01 |
gregorycu |
Bad on linux |
| 14:01 |
gregorycu |
What's the solution |
| 14:01 |
Zeno` |
don't call the callback until the mutex is released |
| 14:01 |
|
y joined #minetest-dev |
| 14:01 |
gregorycu |
lol |
| 14:01 |
gregorycu |
You can't |
| 14:01 |
gregorycu |
That's a race condition |
| 14:02 |
Zeno` |
yes you can |
| 14:02 |
Zeno` |
that was the whole point of the tempvector |
| 14:02 |
gregorycu |
Right, and it was a race condition |
| 14:02 |
Zeno` |
well, we have a problem then :) |
| 14:02 |
Zeno` |
right now on linux (with the patch) it deadlocks |
| 14:02 |
gregorycu |
I don't deny that is a bit of a showstopper |
| 14:03 |
Zeno` |
kinda ;) |
| 14:03 |
gregorycu |
So, a solution may involve sending the value as part of the callback call |
| 14:03 |
|
exio4 joined #minetest-dev |
| 14:04 |
gregorycu |
Another option is sending an assessor object, as part of the callback call |
| 14:04 |
gregorycu |
(So people can fetch a specific type) |
| 14:05 |
gregorycu |
Or use a reentrant lock |
| 14:05 |
Zeno` |
the race condition can be eliminated by not calling the callback(s) straight away |
| 14:05 |
Zeno` |
i.e. you lock the queue and not the settings |
| 14:05 |
Zeno` |
(the callback queue) |
| 14:05 |
gregorycu |
That's another option, separate locks for settings and callbacks |
| 14:06 |
gregorycu |
Maybe the easiest option |
| 14:09 |
Zeno` |
It's what I'd do |
| 14:09 |
Zeno` |
and call the callbacks at a location that is determinant |
| 14:09 |
Zeno` |
instead of from... well, from wherever |
| 14:10 |
gregorycu |
determinant on what? |
| 14:10 |
Zeno` |
i.e. the callstack would be known |
| 14:10 |
gregorycu |
Aren't we replacing all this? |
| 14:10 |
Zeno` |
probably |
| 14:10 |
Zeno` |
:) |
| 14:10 |
Zeno` |
But for now it has to work |
| 14:10 |
gregorycu |
Why must the callstack be known? |
| 14:11 |
Zeno` |
it doesn't need to be known; it's easier to avoid race conditions and for debugging though if you know "run callbacks" always happens from a certain place |
| 14:11 |
Zeno` |
(with it's predecessor the same) |
| 14:12 |
gregorycu |
The only thing you can't do in a callback is register another callback |
| 14:12 |
gregorycu |
Which is always bad, no matter the callstack |
| 14:12 |
gregorycu |
Anything else is always good |
| 14:12 |
Zeno` |
and, at the moment, call any of the Settings:get*() functions :) |
| 14:12 |
gregorycu |
Not when I'm through with it |
| 14:13 |
gregorycu |
You know, if we use C++11 locking, we wouldn't have this problem |
| 14:13 |
Zeno` |
can |
| 14:13 |
Zeno` |
can't :( we support pre C++11 |
| 14:13 |
gregorycu |
For how long? |
| 14:13 |
Zeno` |
2021 |
| 14:13 |
gregorycu |
C++03 is over 10 years old |
| 14:13 |
Zeno` |
it should be stable by 2021 |
| 14:13 |
gregorycu |
It is stable |
| 14:14 |
Zeno` |
not until 2021! |
| 14:14 |
Zeno` |
it always takes 10 years |
| 14:14 |
gregorycu |
C++14 is where it is at now |
| 14:14 |
Zeno` |
:p ;) |
| 14:14 |
Zeno` |
that will be stable in 2024 |
| 14:14 |
|
Amaz joined #minetest-dev |
| 14:14 |
Zeno` |
maybe 2034 |
| 14:15 |
Zeno` |
it's not needed anyway |
| 14:15 |
Zeno` |
:/ |
| 14:15 |
Zeno` |
I guess that's the point |
| 14:15 |
Zeno` |
I could do all this in c89 |
| 14:16 |
Zeno` |
if I was that crazy |
| 14:17 |
gregorycu |
Yes |
| 14:17 |
gregorycu |
I mean |
| 14:17 |
gregorycu |
You could do it all in brainfuck |
| 14:17 |
gregorycu |
Doesn't mean it's smart |
| 14:18 |
gregorycu |
How old are you? Like 40 I'm thinking? |
| 14:18 |
gregorycu |
Stuck in your ways because "I've always done it this way and I know it works" |
| 14:22 |
Zeno` |
huh? |
| 14:22 |
Zeno` |
All I'm saying is that it deadlocks on Linux. Nothing more, nothing less. |
| 14:22 |
gregorycu |
brainfuck is a programming language |
| 14:23 |
Zeno` |
yes, a turing complete language |
| 14:23 |
Zeno` |
dunno what this has to do with the discussion though |
| 14:23 |
gregorycu |
We were just talking about C++11 |
| 14:23 |
Zeno` |
the issue is this: it doesn't work on Linux and therefore probably doesn't work on Android |
| 14:24 |
gregorycu |
And you suggested you could do all of this in c89 |
| 14:24 |
Zeno` |
yeah, that was just nonsense talk |
| 14:24 |
gregorycu |
The natural extension is to do it in brainfuck |
| 14:24 |
gregorycu |
I'll have a fix soon |
| 14:26 |
Zeno` |
*sigh* |
| 14:27 |
Zeno` |
I'm not stuck in my ways, btw. I'm just sick of people relying on a language (and the abstractions such and such language or revision of the language introduces) without knowing what is being abstracted |
| 14:28 |
Zeno` |
Not sure why you turned this into an argument :/ |
| 14:29 |
gregorycu |
I did it because you are wrong. |
| 14:29 |
Zeno` |
No, I'm not wrong |
| 14:29 |
Zeno` |
there are LTS operating systems out there that do not support C++11 |
| 14:29 |
gregorycu |
Let's look at JMutex. I relied on JMutex and it appeared to work. But it does different things on different platforms. Using the standard library, and you get less varience |
| 14:30 |
Zeno` |
once they all support C++11 then fine |
| 14:30 |
gregorycu |
Fuck them |
| 14:30 |
gregorycu |
Why are we concerned with them |
| 14:30 |
Zeno` |
because that's how open source works |
| 14:30 |
gregorycu |
If I release a LTS operating system and not update for 50 years will the project get held back |
| 14:31 |
gregorycu |
You need to make an informed assessment on market share and benefit |
| 14:31 |
Zeno` |
a LTS release implies backporting bugs and fixes |
| 14:31 |
gregorycu |
What does that mean in this context? |
| 14:32 |
gregorycu |
So, i have an LTS operating system where I backport bugs and fixes |
| 14:32 |
Zeno` |
it means that there are *current* operating systems that are receiving long-term support from the vendor, by the vendor providing bug fixes and backporting of some things for a specified period |
| 14:33 |
gregorycu |
We are not the vendor |
| 14:33 |
gregorycu |
Do we have to support every LTS operating system from every vendor? |
| 14:33 |
Zeno` |
Why not? |
| 14:34 |
gregorycu |
Because the definition of vendor is hazy, as is LTS |
| 14:34 |
Zeno` |
My answer would, btw, be yes |
| 14:34 |
gregorycu |
And it holds us back |
| 14:34 |
gregorycu |
That's crazy |
| 14:34 |
Zeno` |
it doesn't hold us back |
| 14:34 |
gregorycu |
Are we using C++11? |
| 14:34 |
Zeno` |
how does it hold us back? |
| 14:34 |
Zeno` |
what can you do in C++11 that you cannot do in C++03? |
| 14:35 |
gregorycu |
rvalue references |
| 14:35 |
gregorycu |
initialiser lists |
| 14:35 |
|
NakedFury joined #minetest-dev |
| 14:35 |
Zeno` |
that's just syntax |
| 14:35 |
gregorycu |
vararg templates |
| 14:35 |
gregorycu |
I can list them all if you want |
| 14:35 |
gregorycu |
Why don't we code in C? |
| 14:35 |
gregorycu |
Why don't we code in ASM? |
| 14:35 |
Zeno` |
ASM is not portable |
| 14:35 |
gregorycu |
That's the reason? |
| 14:36 |
gregorycu |
We support only a few platforms, we could easily port the ASM |
| 14:36 |
jin_xi |
there is this previous discussion, i thought that was the conclusion: http://irc.minetest.ru/minetest-dev/2014-12-23#i_4075355 |
| 14:36 |
Zeno` |
ffs, I don't know why you're making a big deal about this. Your patch is broken. |
| 14:36 |
Zeno` |
Your initial commit is broken |
| 14:37 |
Zeno` |
I'm a nice person, but don't push me for no reason other than pointing out that something doesn't work |
| 14:37 |
gregorycu |
I didn't |
| 14:37 |
gregorycu |
Let's rewind |
| 14:37 |
Zeno` |
good :) |
| 14:37 |
nrzkt |
question, why are we using jthread instead of std::thread ? they both have same functionnalities :) |
| 14:37 |
gregorycu |
That was my point |
| 14:38 |
gregorycu |
What nrzkt just said was my point |
| 14:38 |
gregorycu |
If we were using C++11 and using std::thread we would not have silently diverging functionality of JMutex |
| 14:38 |
Zeno` |
And I've addressed that |
| 14:38 |
Zeno` |
What we need to worry about, right now, though is what we have |
| 14:38 |
Zeno` |
and currently we do not have std::thread |
| 14:39 |
gregorycu |
You addressed nothing, you starting crapping on about how C++11 is useless |
| 14:39 |
gregorycu |
Did you expect me to say nothing? |
| 14:39 |
Zeno` |
I didn't say it was useless :/ |
| 14:39 |
Zeno` |
I said that relying on something that's in a standard that we don't currently support is not a solution |
| 14:40 |
Zeno` |
at least that's what I meant to say |
| 14:40 |
nrzkt |
we need to cleanup the code and then change the c++ functionnalities, maybe for next release ? switching to c++11 before 1.0.0 will be great, and many developpers can be interested in |
| 14:40 |
Zeno` |
I said "this can be solved" |
| 14:41 |
Zeno` |
and it can be solved without c++11 |
| 14:41 |
gregorycu |
I know, we previously discussed a solution |
| 14:42 |
Zeno` |
here, have a beer |
| 14:42 |
nrzkt |
one thing by one thing. Make the core be stable and next switching the coding standards :p |
| 14:42 |
gregorycu |
I don't know what stable is |
| 14:42 |
gregorycu |
For this game |
| 14:42 |
Zeno` |
nrzkt, that is what I am implying |
| 14:42 |
Zeno` |
There is nothing stable about this game :) |
| 14:43 |
nrzkt |
at this time not |
| 14:44 |
Zeno` |
there are the current standards: http://dev.minetest.net/Code_style_guidelines (and, no, I don't agree with them all) |
| 14:44 |
nrzkt |
but we are cleaning up, many devs are working on graphic and minetest engine, i'm working on network, i hope in 1 year we will have a minetest 1.0 with great features and good code |
| 14:44 |
Zeno` |
s/there/these |
| 14:45 |
nrzkt |
i mean standards, not minetest guidelines, standards are not written by minetest :p |
| 14:45 |
Zeno` |
Notice the section on "Do not be too C++y " |
| 14:45 |
Zeno` |
nrzkt, I know what you meant ;) |
| 14:46 |
nrzkt |
when i finish to rewrite networking code and sapier and me find the best network layer handling we will have a stable and evolutive protocol |
| 14:48 |
gregorycu |
Didn't freeminer redo their network stack? |
| 14:48 |
est31 |
yea |
| 14:49 |
est31 |
but they are GPL |
| 14:49 |
gregorycu |
What are we? |
| 14:49 |
est31 |
LGPL |
| 14:49 |
gregorycu |
lol |
| 14:49 |
est31 |
LGPL->GPL is allowed but not the other way |
| 14:49 |
gregorycu |
Are we LGPL so mods can be whatever license they want? |
| 14:49 |
est31 |
dunno |
| 14:49 |
est31 |
but I guess so |
| 14:52 |
Zeno` |
I think we're LGPL so people can make a game, sell it commercially, and not have to release the source code (unless they modify the engine itself) |
| 14:53 |
T4im |
well builtin being lgpl allows mods to take other licenses too |
| 14:55 |
T4im |
instead of requiring mod authors to read up on their opensource legal situations and check if they are using gpl (freeminer?) functions in their open but non-gpl compatible mod |
| 14:55 |
Zeno` |
mods aren't compelled to be GPL even if the engine is |
| 14:56 |
T4im |
well they do use builtin/ functions though |
| 14:56 |
T4im |
engine itself is unimportant, but that interface might not |
| 14:56 |
Zeno` |
hmm |
| 14:56 |
Zeno` |
but unless they modify builtin there is no issue |
| 14:56 |
T4im |
at the moment, since its lgpl, yes :) |
| 14:57 |
Zeno` |
how so? |
| 14:57 |
T4im |
they are allowed to link it due to being lgpl, so there's no issue unless they change builtin/ |
| 14:57 |
est31 |
proller: what do you think, can freeminer mods be non-gpl? |
| 14:57 |
Zeno` |
https://www.dropbox.com/s/p0tsrq4xck5bqmm/spmgv5.tar.gz?dl=0 |
| 14:57 |
Zeno` |
oops |
| 14:57 |
nrzkt |
no mods doesn't need to be compatible with core licence. Like World of Warcraft mods have they own licence, like minecraft mods have their own licence |
| 14:58 |
T4im |
if it were gpl (without linking exception that is), you would have to ask yourself if the calling/linking of those functions is intimate enough to fall under gpl protection… I'd say in this case yes |
| 14:58 |
T4im |
nrzkt: that's because they are not compelled to |
| 14:58 |
Zeno` |
there is no linking of builtin though |
| 14:58 |
Zeno` |
they are loaded at runtime |
| 14:58 |
T4im |
a proprietary license can allow you to link to it too |
| 14:59 |
T4im |
gpl however might compell, nrzkt |
| 14:59 |
est31 |
linux is also GPL, and still you can use it with whatever license you want |
| 14:59 |
T4im |
kernel mods not |
| 14:59 |
T4im |
modules* |
| 15:00 |
Zeno` |
sure they can |
| 15:00 |
T4im |
the software running on that is according to the faq not in a intimate relationship iirc |
| 15:00 |
Zeno` |
as long as they don't modify the kernel they can be whatever license they like |
| 15:00 |
Zeno` |
modify the kernel source code* |
| 15:01 |
gregorycu |
What is the difference between LGPL and GPL? |
| 15:01 |
T4im |
est31: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation |
| 15:01 |
T4im |
"By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. " |
| 15:02 |
T4im |
Zeno`: the modules: " If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program." |
| 15:02 |
T4im |
same link |
| 15:02 |
T4im |
gregorycu: you are allowed to link to lgpl, also you grant lgpl authors a right to reverse engineer for the purpose of keeping stuff working |
| 15:03 |
T4im |
(the latter part is not so widely known) |
| 15:03 |
Zeno` |
you also grant the right to change the license to GPL |
| 15:03 |
T4im |
yes |
| 15:05 |
T4im |
there's a fuzzy line when it comes to modular software like this… minetest would probably be in a totally different situation if the api/interface would not be minetest specific, but an interface standard used by multiple different software |
| 15:05 |
T4im |
because: then the mods could run without minetest (or a derivate thereof) |
| 15:05 |
T4im |
but they cannot, they are dependend on that builtin/ stuff :/ |
| 15:05 |
T4im |
they do not constitute a separate program |
| 15:06 |
Zeno` |
lgpl is a very strange choice for something like this anyway (IMO) |
| 15:06 |
|
nore joined #minetest-dev |
| 15:06 |
T4im |
well yes… I do think a "gpl with linking exception" also known as "classpath exception" due to its usage by java (or rather the classpath project preceeding it), might be a better fit |
| 15:07 |
T4im |
its basicly a gpl with the exception: you may link to the api |
| 15:07 |
T4im |
that would allow mods to continue doing what they do without any headaches |
| 15:07 |
Zeno` |
you know the difference between dynamic and static linking, right? |
| 15:07 |
T4im |
I don't think this is important for gpl though is it? |
| 15:08 |
Zeno` |
nope. It is for the lgpl though |
| 15:08 |
T4im |
ah |
| 15:08 |
DFeniks |
how can people work like this . do you never look into freeminer code to not get your brain contaminated? |
| 15:08 |
T4im |
DFeniks: they better not… |
| 15:08 |
T4im |
:D |
| 15:09 |
Zeno` |
actually it's important for the GPL as well |
| 15:09 |
Zeno` |
a dynamically linked module can have whatever license it wants |
| 15:09 |
DFeniks |
i heard microsoft doesnt allow its employees to read opensource code. or was it a myth? |
| 15:09 |
est31 |
microsoft has its own github page with open sourced code |
| 15:10 |
est31 |
its a myth |
| 15:10 |
T4im |
Zeno`: 2 or 3? |
| 15:10 |
Zeno` |
both |
| 15:10 |
DFeniks |
ah , i thought so |
| 15:10 |
T4im |
DFeniks: they might have _some_ employees that are not allowed, see the concept of a cleanroom implementation |
| 15:10 |
DFeniks |
but you never know , its microsoft |
| 15:11 |
est31 |
MS has changed alot in the last years |
| 15:11 |
est31 |
they even release components of their OS as open source |
| 15:11 |
T4im |
that ballmer was crazy as cobble, so no surprise there |
| 15:12 |
T4im |
(that they changed somewhat after he was gone) |
| 15:12 |
DFeniks |
anyway living in this age of copyright , i dont know what is right anymore |
| 15:12 |
T4im |
anyway microsoft -> #minetest |
| 15:14 |
DFeniks |
i know my brain will try to copy and collect everything it finds useful , is it bad? but how can i do otherwise? everything i know was inspired by something |
| 15:14 |
T4im |
Zeno`: the fsf stand on that is there's no difference.. either its derivating or not |
| 15:14 |
T4im |
https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic |
| 15:14 |
T4im |
for gpl that is |
| 15:15 |
T4im |
lgpl has its own section underneath :D |
| 15:15 |
T4im |
so lgpl would only allow dynamic linking… but I think that works with mods |
| 15:18 |
Zeno` |
oh, I dunno |
| 15:18 |
Zeno` |
I'm not a lawyer |
| 15:18 |
Zeno` |
heh |
| 15:18 |
T4im |
and you can't even take any random lawer on this :P I've had some interesting re-interprations with local lawers on that stuff |
| 15:19 |
T4im |
gpl 2.0 distribution for example is interpreted in germany differently thani n the u.s. |
| 15:19 |
T4im |
gpl 3.0 changed that though |
| 15:20 |
nore |
sfan5, what about 401, 405, 407, 410, 412? |
| 15:20 |
nore |
... ShadowBot didn't add the links :( |
| 15:20 |
T4im |
missing # |
| 15:20 |
kilbith |
game#<PR> |
| 15:21 |
nore |
so: game#401, game#405, game#407, game#410, game#412 |
| 15:21 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/401 -- Add an outlined crosshair by Calinou |
| 15:21 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/405 -- Textures Update by kilbith2 |
| 15:21 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/407 -- Mossycobble fixes by MT-Modder |
| 15:21 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/410 -- Fix typo for obsidian glass door texture by Xanthin |
| 15:21 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/412 -- Default/mapgen.lua: Add dirt/sand/gravel blobs for mgv5. Select and order functions per mapgen by paramat |
| 15:21 |
nore |
yep, but previously, it added the links in mt_game if there was no "#" |
| 15:22 |
Zeno` |
I will be reverting #2187 until issues are resolved |
| 15:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/2187 -- Make the GameGlobalShaderConstantSetter use the settings callback by gregorycu |
| 15:23 |
Zeno` |
i.e. a) unitialised vars; and b) potential for dangling pointers/references |
| 15:23 |
|
selat joined #minetest-dev |
| 15:25 |
Zeno` |
can't re-open :/ |
| 15:28 |
|
Unidan2 joined #minetest-dev |
| 16:16 |
|
Zeno` joined #minetest-dev |
| 16:31 |
|
DFeniks joined #minetest-dev |
| 16:31 |
|
MinetestForFun joined #minetest-dev |
| 16:34 |
|
shadowzone joined #minetest-dev |
| 16:34 |
shadowzone |
Hello |
| 16:37 |
|
crazyR joined #minetest-dev |
| 16:50 |
|
kilbith joined #minetest-dev |
| 16:50 |
shadowzone |
Hello kilbith. |
| 16:51 |
kilbith |
hi |
| 16:52 |
|
Zeno` joined #minetest-dev |
| 16:52 |
shadowzone |
Hello Zeno` |
| 16:52 |
Zeno` |
o/ |
| 17:06 |
|
kaeza joined #minetest-dev |
| 17:13 |
|
hmmmm joined #minetest-dev |
| 17:14 |
shadowzone |
Hello hmmmm, kaeza and celeron55 |
| 17:16 |
kaeza |
hi |
| 17:22 |
|
Calinou joined #minetest-dev |
| 17:42 |
|
roniz joined #minetest-dev |
| 17:48 |
|
Hunterz joined #minetest-dev |
| 18:01 |
|
ElectronLibre joined #minetest-dev |
| 18:01 |
|
nrzkt left #minetest-dev |
| 18:02 |
|
nrzkt joined #minetest-dev |
| 18:30 |
|
Hunterz joined #minetest-dev |
| 18:36 |
|
ElectronLibre joined #minetest-dev |
| 18:38 |
|
Amaz joined #minetest-dev |
| 18:41 |
|
Kalabasa joined #minetest-dev |
| 19:07 |
|
CraigyDavi joined #minetest-dev |
| 19:11 |
|
rubenwardy joined #minetest-dev |
| 19:14 |
rubenwardy |
#2196 |
| 19:14 |
ShadowBot |
https://github.com/minetest/minetest/issues/2196 -- Mod Store Mockup Design |
| 19:15 |
* Calinou |
sighs |
| 19:18 |
|
shadowzone joined #minetest-dev |
| 19:26 |
VanessaE |
huh, I just spotted a bug in digging particles |
| 19:26 |
VanessaE |
only happens when digging a mesh node: the texture shown on the particle is the raw texture, not something a "rendered" view of the object |
| 19:27 |
VanessaE |
so you can see the UV layout of the texture in the particles |
| 19:27 |
VanessaE |
s/something/something like/ |
| 19:28 |
kahrl |
most likely by design |
| 19:28 |
VanessaE |
probably an artifact of pre-mesh design, yeah |
| 19:28 |
kahrl |
there isn't really a good way to convert the uv texture to a "rendered" one |
| 19:28 |
VanessaE |
I would suggest particles pick from the mesh's polys or something |
| 19:28 |
kahrl |
(short of rendering the whole mesh to a texture or something expensive like that) |
| 19:29 |
VanessaE |
nah, that'd be wasteful for this |
| 19:29 |
est31 |
What are mesh nodes? |
| 19:29 |
VanessaE |
est31: anything using the mesh drawtype |
| 19:30 |
kahrl |
yeah, picking an arbitrary poly might work (for low-poly meshes, at least) |
| 19:30 |
VanessaE |
such as a homedecor desk lamp or a technic slope |
| 19:30 |
est31 |
k |
| 19:30 |
kahrl |
might be hard to code though |
| 19:30 |
VanessaE |
kahrl: yeah, just random polys with each particle that is spawned would probably look fine |
| 19:30 |
VanessaE |
yeah, probably so |
| 19:32 |
kahrl |
another solution would be another field in the node definition, particle_texture = "..." |
| 19:33 |
jin_xi |
i like this idea |
| 19:34 |
VanessaE |
kahrl: that would work too I guess, or particles could be drawn from the rendered inventory image |
| 19:34 |
sfan5 |
nore: 412 ok; 407 ok; 410 is ok if it fixes something |
| 19:35 |
VanessaE |
since the game already renders one anyway |
| 19:36 |
kahrl |
they might have too much transparency |
| 19:36 |
kahrl |
but it could be worth a try |
| 19:37 |
nore |
sfan5, what about game#405? |
| 19:37 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/405 -- Textures Update by kilbith2 |
| 19:38 |
sfan5 |
nore: some of those texture don't need updating |
| 19:38 |
sfan5 |
I'll be more specific in a github comment |
| 19:38 |
nore |
ah, about 410: right now, both textures are the same |
| 19:38 |
nore |
but texture packs may want to use two different ones |
| 19:39 |
nore |
(for top/bottom of obsidian door) |
| 19:39 |
kilbith |
sfan5: i'm waiting for your feedback but i hope you have read the comments in that PR |
| 19:42 |
nore |
for 412, I'll wait for the engine dependent pull request to be merged |
| 19:43 |
kilbith |
413 is good too |
| 19:50 |
sfan5 |
nore, kilbith: https://github.com/minetest/minetest_game/pull/405#issuecomment-71334265 |
| 19:51 |
kilbith |
sfan5: https://cloud.githubusercontent.com/assets/9149204/5794247/c54dad0e-9f65-11e4-983d-5265b403e2ea.png |
| 19:51 |
sfan5 |
? |
| 19:51 |
kilbith |
the copper ingot currently doesn't follow the new copper block color |
| 19:53 |
kilbith |
and the bronze ingot is more faithful with the bronze block one |
| 19:53 |
kilbith |
you see what i'm talking about ? |
| 19:55 |
sfan5 |
hm |
| 19:55 |
sfan5 |
you're right |
| 19:55 |
kilbith |
i've updated the copper & bronze blocks recently, remember ? |
| 19:55 |
kilbith |
so i was forced to update the ingots too |
| 19:55 |
sfan5 |
changed my comment accordingly |
| 19:56 |
|
Unidan2 joined #minetest-dev |
| 19:56 |
kilbith |
as for the Mese, ok, i revert it |
| 19:56 |
sfan5 |
the other ingot textures still don't need any changing |
| 19:57 |
kilbith |
ok, will revert |
| 20:00 |
kilbith |
sfan5: reverted and squashed. |
| 20:02 |
|
shadowzone joined #minetest-dev |
| 20:10 |
|
shadowzone joined #minetest-dev |
| 20:15 |
|
shadowzone joined #minetest-dev |
| 20:40 |
|
acerspyro joined #minetest-dev |
| 20:47 |
|
prozacgod joined #minetest-dev |
| 20:55 |
|
shadowzone joined #minetest-dev |
| 21:03 |
|
MinetestForFun joined #minetest-dev |
| 21:05 |
|
acerspyro joined #minetest-dev |
| 21:39 |
|
Fadi joined #minetest-dev |
| 21:50 |
|
acerspyro joined #minetest-dev |
| 21:51 |
|
acerspyro joined #minetest-dev |
| 21:53 |
VanessaE |
hmmmm: still wasn't able to get a backtrace, but Michael continued his testing and found something interesting: https://forum.minetest.net/viewtopic.php?f=10&t=4057&p=168709#p168709 |
| 21:54 |
hmmmm |
still not very helpful |
| 22:07 |
|
diemartin joined #minetest-dev |
| 22:11 |
sofar |
14:11:01: ACTION[main]: Mod bucket is explicitly disabled in world.mt |
| 22:11 |
sofar |
awesome, I can now disable "default" mods in world.mt |
| 22:11 |
sofar |
will post patch |
| 22:12 |
|
acerspyro joined #minetest-dev |
| 22:21 |
sofar |
are there any specific pull request requirements, like S-O-B lines? |
| 22:22 |
sfan5 |
what are S-O-B lines |
| 22:22 |
sofar |
Signed-Off-By |
| 22:22 |
VanessaE |
other than mentioning what you did and things like "fixed #xxxx", avoid calling the person who broke what you're fixing a SOB. :P |
| 22:22 |
sofar |
hehehe |
| 22:22 |
VanessaE |
fixes* |
| 22:22 |
sofar |
https://github.com/minetest/minetest/pull/2197 |
| 22:23 |
sofar |
VanessaE: I should be capable of making reasonable commit messages by now ;^) |
| 22:24 |
sofar |
feedback welcome, this is the first time in 15 years or so that I've actually read more than 5 lines of C++ code (I'm a pure C type of guy) |
| 22:24 |
|
Unidan2 joined #minetest-dev |
| 22:24 |
sfan5 |
we don't use too many C++-y constructs |
| 22:24 |
sfan5 |
so.. |
| 22:25 |
sofar |
it's not too bad, but kernel style C code is so radically different |
| 22:26 |
sofar |
ah lol, typos |
| 22:27 |
* sofar |
fixes |
| 22:27 |
sofar |
actually I can pull up the worldmt settings declaration so it's not done every single loop run |
| 22:38 |
sofar |
https://github.com/minetest/minetest/pull/2198 |
| 22:39 |
sofar |
thanks for the comments |
| 22:47 |
|
roniz joined #minetest-dev |
| 22:50 |
|
crazyR joined #minetest-dev |
| 22:56 |
|
paramat joined #minetest-dev |
| 23:05 |
paramat |
hmmmmm thanks for merging the first commit from #2175 , is there an issue with the second commit? the necessary MTgame PR for replacement blobs is now ready https://github.com/minetest/minetest_game/pull/412 |
| 23:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/2175 -- Mgv5: Speed optimise noise. Remove blobgen, add large caves. Cavegen: add mgv5 large caves by paramat |
| 23:15 |
|
paramat left #minetest-dev |
| 23:15 |
|
acerspyro joined #minetest-dev |
| 23:28 |
|
AnotherBrick joined #minetest-dev |
| 23:28 |
|
shadowzone joined #minetest-dev |
| 23:35 |
hmmmm |
ermm |
| 23:35 |
hmmmm |
i thought there was only one commit for some reason |
| 23:38 |
|
compunerd joined #minetest-dev |
| 23:58 |
|
Megaf_ joined #minetest-dev |
