Minetest logo

IRC log for #minetest-dev, 2015-01-24

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

All times shown according to UTC.

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/commi​t/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&amp;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/9y64​ks4xs56pqmr/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/xo23l2e76​8ljy1w/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/m​inetest/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/minetes​t/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/ac69​9798#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/commi​t/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/minet​est-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/p0ts​rq4xck5bqmm/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/g​pl-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/minetes​t/minetest_game/issues/401 -- Add an outlined crosshair by Calinou
15:21 ShadowBot https://github.com/minetes​t/minetest_game/issues/405 -- Textures Update by kilbith2
15:21 ShadowBot https://github.com/minetes​t/minetest_game/issues/407 -- Mossycobble fixes by MT-Modder
15:21 ShadowBot https://github.com/minetes​t/minetest_game/issues/410 -- Fix typo for obsidian glass door texture by Xanthin
15:21 ShadowBot https://github.com/minetes​t/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/minetes​t/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.ph​p?f=10&amp;t=4057&amp;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

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