Time Nick Message 00:13 hmmmm yes, very good 00:13 hmmmm that's exactly how I would've fixed it 01:14 hmmmm https://github.com/kwolekr/minetest/commit/a02a094a2f5c3c4121b142fd53d7167140cc3b5a PTAL 01:35 est31 looking 01:35 est31 why is abc_t not posix compliant? 01:35 est31 so you say having content_t is bad? 01:36 hmmmm come to think of it, yeah it is 01:36 hmmmm damn 01:36 hmmmm any identifier ending with _t is reserved by posix 01:36 est31 all these things should be ... documented 01:37 hmmmm wow okay content_t has a problem too 01:38 hmmmm alright you know what, I'm going to roll that change back to threadid_t and if it does happen to cause a name collision on some supported platform, then we'll have a reason to change it 01:38 est31 fine 01:38 hmmmm http://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html 01:38 hmmmm read this 01:39 est31 oh 01:39 est31 CPÅžP11? 01:40 hmmmm what is that character 01:40 est31 its in your patch 01:40 hmmmm ermm 01:40 est31 ive thought its dirt on my monitor 01:40 est31 then I've scrolled and the dirt moved 01:40 hmmmm oh you mean CPP11 01:40 est31 https://github.com/kwolekr/minetest/commit/a02a094a2f5c3c4121b142fd53d7167140cc3b5a#diff-92729a668babc433abcbe4987f8e14e6R71 01:40 hmmmm whaat 01:41 hmmmm the fuck 01:42 est31 also I wonder... do we have c++11 threads right now, or not? 01:42 hmmmm I would imagine freeminer would use that mode 01:42 est31 bc ShadowNinja's patch had them at the start 01:42 est31 but it was dropped until it got merged, no? 01:42 hmmmm they're optionally supported only if the cpp version is high enough 01:43 hmmmm yeah okay this is crazy 01:43 hmmmm I really have no idea at all how that character got there 01:45 hmmmm anyway I think we should document our conscious decision to ignore POSIX reserved name rules 01:46 est31 either of those, but documenting is never bad 01:46 hmmmm removing __ and _ prefixed names is fine and all because that could cause a bigger problem and they're not already ubiquitous throughout the code 01:46 hmmmm and it's an ISO C language violation 01:46 est31 yeah _something looks ugly as well 01:46 est31 smells of snakes 01:46 est31 duck typed snakes 01:46 hmmmm this on the other hand is a POSIX violation and doesn't actually make a difference unless just by chance some new revision adds it 01:46 hmmmm at which point we could simply... change the name 01:47 hmmmm where should this be documented? 01:47 est31 http://dev.minetest.net/Code_style_guidelines ? 01:48 hmmmm this doesn't quite have to do with code style 01:48 hmmmm more like "project design decisions/agreements" 01:48 est31 there should be some place however where it can be added 01:49 hmmmm yeah the POSIX name restrictions are way too broad. for example, any identifier starting with "ENet" is invalid 01:49 est31 I really doubt it needs a new wiki page 01:49 est31 well if you implement them, you are on the safe side 01:49 hmmmm and even the major GNU project libgmp uses mpz_t 01:49 est31 if you don't you are on the fun sid 01:49 est31 e 01:49 est31 yea 01:49 hmmmm if such a big project ignores it then that kind of sets a precedent 01:50 est31 all gnu libraries I've seen have someting_t 01:53 est31 there we have the real reason why GNU isn't certified UNIX 01:53 hmmmm another violation is our handling of pthread_t 01:53 hmmmm you cannot compare a pthread_t using ==, you must use pthread_equal() 01:54 hmmmm but the problem is that std::map in debug.cpp 01:54 est31 your patch fixes it doesnt it? 01:54 hmmmm if you override the comparator for that map to use pthread_equal(), it's not going to be well-ordered because you can't compare "greater than" between two pthread_ts 01:54 est31 ah there is an std::map? 01:55 hmmmm so you need to implement something to make pthread_ts arbitrarily well-ordered 01:55 est31 yeah 01:55 est31 injection into well ordered se 01:55 est31 t 01:55 hmmmm I have no good ideas on how to do that 01:56 hmmmm in any case, it only matters on platforms where pthread_t is a struct 01:56 est31 what exactly does the map do? 01:56 hmmmm something about debugstacks 01:58 hmmmm for what it's worth, gdb maps pthread_ts to an arbitrary integer ordinal so it doesn't have these problems 01:58 hmmmm sorta wondering if we should do the same 01:59 hmmmm or maybe it's really too much work for something that's a non-issue on our supported platforms 01:59 est31 perhaps let the preprocesor issue a warning if its not an integral type? 02:00 hmmmm for what it's worth, according to the spec, pthread_t could be an ordinal and comparison would still cause problems 02:00 hmmmm imagine the case where pthread_equal is implemented as thr1->kernel_thread_id == thr2->kernel_thread_id and the other members are like uhh... no idea 02:01 hmmmm some implementation dependent sutff 02:01 hmmmm but the point is that they could be different /pointers/ with equivalent threads 02:01 hmmmm subtle breakage 02:01 est31 yeah 02:02 est31 thats the problem with too lose standards 02:02 hmmmm FWIW, google chrome has their Chromium Base Library which implements a thread class just like our own 02:02 hmmmm it completely ignores the "problems" behind pthread_t 02:02 hmmmm is that a good enough precedent to follow, would you say? 02:03 est31 well, that means we would at least run at all platforms chromium runs at 02:03 hmmmm the thing is 02:03 est31 majority of the devices out there 02:04 est31 idc whether minetest runs on some exotic HP workstation 02:04 hmmmm because of all this broken dependency on pthread_t being a comparable ordinal number, the effective standard has been changed 02:04 hmmmm nobody in their right minds would not make pthread_t a struct due to the amount of breakage 02:04 hmmmm s/would not/would/ 02:05 est31 well, if the standard creators were smart, they'd have added a pthread_get_id() function 02:05 hmmmm I have an HP Visualize B1000 with HP-UX 11.11u, want me to test minetest compatibility with that? :) 02:05 hmmmm the thing is, pthread_t is *supposed* to be the thread ID 02:05 est31 well, then the standard shouldnt make it opaque 02:06 hmmmm yeah the standard is dumb imho 02:06 est31 I mean that pthread_get_id() function could just return the passed argument on most platforms 02:07 est31 and for your example it could return thr->kernel_thread_id 02:07 est31 done 02:15 hmmmm what's done? 02:21 hmmmm https://github.com/kwolekr/minetest/commit/6be74d17df75714066b36cfa6ae40081526ef477 02:30 est31 looks good 03:48 hmmmm https://github.com/kwolekr/minetest/commit/765a834cd04473afeb4b86b445dee901e0d0c83c PTAL 04:11 kahrl heh, even the gnu libstdc++ devs are having issues with pthread_t: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114#c4 04:48 ShadowNinja hmmmm: ... I just started that a few minutes before your message... 04:49 ShadowNinja Why the m_ for private vars though? Then you have to rename itif you make it public/protected. 04:51 hmmmm code rules say that private/protected need to have the m_ prefix 04:52 hmmmm if you make it public/protected, you might need to rethink your encapsulation 04:59 ShadowNinja Hrm, name should probably be private, I wonder why it isn't. 05:00 hmmmm probably because threads won't be able to set it outside of an initializer list 05:00 hmmmm i don't think it really matters that much 05:01 ShadowNinja setName(); 05:02 hmmmm you know what, you're right 05:02 hmmmm this makes no sense the way it is 05:02 ShadowNinja Er, no, that doesn't update the var.. 05:03 hmmmm ahh 05:03 ShadowNinja I'll fix that. 05:03 hmmmm then you'd need to make it a non-static variable 05:03 hmmmm :).... 05:04 ShadowNinja My patch merges threads.h into thread.h instead of keeping them oddly seperate. 05:04 hmmmm whose patch are we using then? 05:04 ShadowNinja I also removed the include from porting.h, since itisn't actually used there. 05:05 ShadowNinja Eh, mine? I'm adding in your changes now. 05:05 hmmmm I'd rather not duplicate effort 05:05 hmmmm would you rather base yours off of mine? 05:05 ShadowNinja Moment, I'll give you my patch so you can see what I'm doing. 05:05 ShadowNinja Yes. 05:05 hmmmm alright, I'll push what's currently there, then 05:06 VanessaE can someone please address the shadow bug in mgv7 w/moretrees? 05:06 hmmmm plate's full 05:07 ShadowNinja This is what I've got so far: http://ix.io/ls8/diff\ 05:07 ShadowNinja hmmmm: er. 05:07 ShadowNinja I mean I'd merge your changes into mine manually, rebasing it would probably be harder. 05:08 hmmmm let me think about this 05:08 hmmmm I don't like defining a type as a member of a class like that 05:08 hmmmm Thread::Id 05:08 paramat Vanessa is it perhaps due to very tall trees reaching y = 47? maybe when the chunk above has not been generated yet? 05:08 hmmmm I know it "makes sense" from an organizational point of view, but can't we just leave well enough alone? :/ 05:09 VanessaE paramat: doubt it, even some of the shorter trees spawning at sea level (say, a palm tree on a beach) do it. 05:09 VanessaE it's probably the chunk-above part, but not the Y>47m part. 05:10 ShadowNinja hmmmm: I'm also O.K. with ThreadId, but I don't like threadid_t. 05:10 hmmmm why not? 05:10 ShadowNinja It doesn't use the PascalCase type name convention. 05:10 paramat okay 05:10 hmmmm so?? 05:11 hmmmm PascalCase is for classes 05:11 hmmmm not necessarily types 05:11 ShadowNinja hmmmm: So I don't like it :-P 05:11 hmmmm just my personal opinion, I think you're going a little too crazy with the refactoring 05:11 hmmmm would be better to focus on bug fixes/features/etc. 05:12 hmmmm or documentation updates 05:12 hmmmm like these are the things that totally don't matter but break a lot of pull requests and add merge conflicts 05:12 hmmmm the reason why I did that threading refactor was because I needed it for my envlock PR 05:14 hmmmm ShadowNinja: but the main point is that I originally changed threadid_t to ThreadId, just like you said, but I went back on that decision because it'd cause more inconsistency for very little benefit 05:17 ShadowNinja hmmmm: How was it more inconsistent? 05:17 hmmmm because then we have all the other custom types that end with _t 05:17 hmmmm there's content_t, and I'm sure there are others that I can't think of at the moment 05:17 hmmmm you're not really going to do a global find+replace on content_t, are you....? 05:18 hmmmm like that's a little bit too ridic 05:18 hmmmm how is that helping minetest other than breaking everybody's PRs 05:21 ShadowNinja hmmmm: content_t may be hard to change, but this is easy, and it's more consistent with how the standard library does it (in C++11). 05:22 hmmmm who said that being more C++y is better though 05:22 hmmmm this sort of thing is something we should get consensus on first before you do it i think 05:29 ShadowNinja hmmmm: Why'd you change the thread priority enum to a list of constants? 05:29 hmmmm because anonymous enums are dumb 05:30 hmmmm on windows, those constants are defines also 05:30 ShadowNinja Why are they dumb? 05:30 hmmmm because they have no advantages whatsoever 05:30 ShadowNinja And why clib -> lib.h? 05:31 hmmmm because lib.h is more universal 05:31 hmmmm are there any reasons for those changes at all to begin with...? 05:31 ShadowNinja The enum syntax is nicer and the clib versions are rewuired by the standard. 05:32 hmmmm why is enum syntax nicer? you use them in the same exact way 05:32 hmmmm and you don't get to define their type 05:32 hmmmm with a define, if you want something to be a specific type, you just add a cast to the macro definition 05:33 hmmmm it just so happens that on Windows that parameter is an int, so it works fine without any implicit conversions 05:34 hmmmm what if there's code that expects those constants to be macros? 05:34 ShadowNinja The syntax is nicer because the "#define " and value isn't necessary. Also, you changed a comment from "// For..." to "// for...". The original was correct. 05:34 hmmmm capitalizing a letter? 05:34 hmmmm that's not a sentence 05:35 hmmmm all these miniscule autistic details that don't really need to be changed get changed and detract from the actual changes 05:35 ShadowNinja Yes, it's supposed to be capitalized. And it is a sentence, there's an implicit "This is " before it. 05:36 ShadowNinja hmmmm: But you made these changes... 05:36 hmmmm you made them first 05:36 hmmmm then how come there's no period then? 05:36 hmmmm jeez just leave those things the way they are 05:44 ShadowNinja hmmmm: You also switched from _beginthreadex to CreateThread. CreateThread doesn't set up the runtime in the new thread. 05:45 ShadowNinja http://stackoverflow.com/questions/331536/windows-threading-beginthread-vs-beginthreadex-vs-createthread-c 05:47 hmmmm I don't think _beginthreadex does anything different other than sets up TLS 05:47 hmmmm we don't use TLS. 05:51 hmmmm in fact it doesn't even do that anymore, according to a comment in that very webpage you posted: http://stackoverflow.com/a/20901790/4751863 05:58 hmmmm oh I remember why I changed the thread priority values back to defines 05:58 hmmmm it's because they're fundamentally not an enum, the way I had it set up those were arithmetic values that just happened to be sequential in value 05:58 hmmmm i do arithmetic on them 06:26 paramat hmmmm do you approve of #3248 as it is? i've rebased and renamed the field to "catch_up" 06:26 ShadowBot https://github.com/minetest/minetest/issues/3248 -- ABMs: Make catch-up behaviour optional by paramat 06:27 hmmmm lmao 06:27 hmmmm getting tired of ketchup jokes huh 06:28 VanessaE heh 06:28 hmmmm erm, yeah, +1 from me, looks good. 06:29 paramat hehe thanks 06:29 ShadowNinja hmmmm: You call cleanup on thread start, which clears the thread name before the OS ever learns about it. 06:30 ShadowNinja And apparently you've already merged it. 06:30 hmmmm whoops 06:32 hmmmm you can't put cleanup() at the end of wait(), because there's nothing saying the user absolutely needs to wait after stopping 06:33 hmmmm after wait() is when the user would call getReturnValue() and do whatever operation is needed 06:33 ShadowNinja If you need to clear stuff it should brobably be done by the thread itself. 06:33 hmmmm so it really does need to get put at the beginning of start() 06:34 ShadowNinja name never needs to be cleared though/ 06:34 hmmmm erm, I don't think that works for C++11 threads 06:34 hmmmm okay, so just take the name clearing out 06:34 hmmmm that fixes everything 06:35 hmmmm also add a cleanup() after the wait() in the if (!m_running) { claus in thread::kill 06:37 hmmmm paramat, look at this: https://github.com/kwolekr/minetest/commit/ae4e9cc71262fef154cee6c35539638780961796 06:38 * paramat looks 06:38 paramat oooh 06:38 hmmmm it's not done yet but the basic idea is to acquire a VManip somehow 06:38 hmmmm run core.envlock_release() 06:38 hmmmm do your mapgen 06:38 hmmmm then run core.envlock_acquire() 06:38 hmmmm blit the vmanip back to the map 06:39 hmmmm comments/concerns with the way it's done? 06:40 hmmmm VanessaE? 06:41 hmmmm though this one wouldn't be as pertinent to you since you use all set_node() 06:41 paramat so the lock can be released to run the heavy processing part of a lua mapgen threaded? 06:41 VanessaE your basic idea seems reasonable anyway 06:41 hmmmm right 06:41 hmmmm and you can also use Lua Lanes to have a lua multithreaded mapgen, for what it's worth 06:41 hmmmm lol that's gonna be ridic' 06:41 paramat nice because most of the processing is working on the nodes in the lvm 06:42 * VanessaE shudders 06:42 paramat good to see this going ahead 06:42 hmmmm but how's the interface 06:42 hmmmm are you missing anything from it, or do you not want the functions to throw errors? 06:42 hmmmm etc 06:43 paramat seems okay, nice and simple 06:44 paramat throwing errors is probably a good thing for this 06:45 paramat .. because it's dangerous 06:48 hmmmm this is gonna be fun when i split map locking into mapblock areas 06:49 hmmmm core.request_area({MinEdge={...}, MaxEdge={...}}) 06:49 hmmmm blocks until there are no locks overlapping with the requested area 06:49 hmmmm still need to work out the details but what i fear is that this is going to take too many locks 06:50 paramat 8. 06:50 hmmmm no definitely more than that 06:50 hmmmm i need to do research on how "heavy" futexes are on our target platforms 06:50 hmmmm or maybe come up with my own synchronization primitive altogether if necessary 06:51 hmmmm might have to use spinlocks instead if it's too much 06:51 hmmmm which sort of defeats the purpose 06:52 nrzkt hmmmm, did you tried mutex perf mapsector first ? 06:52 hmmmm no 06:59 ShadowNinja hmmmm: On my computer I can do 39000 lock/unlock pairs per milisecond. (minetest --speedtests) 07:03 ShadowNinja Actually locking the mutex should take almost no time, the issue is contention. 07:03 hmmmm what i'm concerned about is if initializing a mutex does anything in kernel mode 07:06 ShadowNinja Moving the Mutex into the loop brings it down to 29000/ms. 07:08 ShadowNinja I'm not sure how expensive a syscall is, but the speed seems more than adequate. 07:09 ShadowNinja Of course, this is Linux 4.x with recent libraries, other OSes may do much worse. 07:17 hmmmm alright i just checked 07:17 hmmmm on Windows it does create an event object 07:22 hmmmm i think i'd rather come up with a new form of synchronization that's actually designed for this type of task 07:28 hmmmm what i'm thinking of is somehow blocking on a data structure (let's start out with iterating over a list...) until there are no intersections with your requested area 07:28 hmmmm could do this with events 07:28 hmmmm but then i'd be waking up every single time a maplock is released 07:29 hmmmm hell of a lot better than having a kernel mode event object for every single mapblock 07:30 hmmmm okay this will work, and the naive approach would still work (but not very well) because it'd need to loop over a volume of mapblocks and block on each waiting to acquire 07:31 hmmmm if I write this, nobody is going to bother to try improving it 07:32 hmmmm I have a reason to use est's areastore :-) 08:10 ShadowNinja https://github.com/ShadowNinja/minetest/commit/5b1c01126e026539a5bea2eebc63af85be38becd 08:10 ShadowNinja G'night folks. 08:18 paramat will merge #3248 when checks are done 08:18 ShadowBot https://github.com/minetest/minetest/issues/3248 -- ABMs: Make catch-up behaviour optional by paramat 08:30 paramat uh the windows bulds failed, something to do with thread.cpp 08:32 paramat minetest/src/threading/thread.cpp:170:10: error: expected initializer before '==' token 08:36 paramat that line was altered by hmmmm's recent commit 08:36 paramat i'll wait for his return then 08:39 paramat now merging game#705 08:39 ShadowBot https://github.com/minetest/minetest_game/issues/705 -- Default/trees: Add requirement of light level 13 for sapling growth by paramat 08:40 VanessaE wait 08:40 VanessaE what's the light level for a torch? 08:40 VanessaE (if placed right next to the sapling) 08:41 VanessaE oh hell 08:41 VanessaE you already addressed that. 08:41 VanessaE paramat: frankly, I'd have to veto that. 08:42 paramat oh sorry, torches are not bright enough 08:42 paramat but could be made level 14 08:42 VanessaE minetest's lighting system needs revamped first, imho 08:42 VanessaE that's just the problem 08:43 paramat you have a need to grow saplings by torchlight? 08:43 VanessaE a torch should be perhaps even dimmer than it is now, but then a bright source like a mese lamp should be FAR brighter than it is (I mean how far it throws the light, too) 08:43 VanessaE actually I do that sometimes, if I'm in a hurry to get a sapling to grow. 08:43 VanessaE if anything, you should vary the grow time based on light level 08:43 VanessaE rather than just grow-or-don't 08:44 paramat we could consider making torches level 14, although that erases the difference between torches and bright lamps 08:46 VanessaE if consistency is the issue, 08:46 VanessaE wouldn't it be better to lower the light requirement for the other plants (as pilz alludes to)? 08:46 VanessaE and make it take longer to grow if the light is too low 08:47 VanessaE I do something like this with bushes_classic -- if they're planted on farming soil, they regrow their fruits faster than on plain dirt/grass. 08:48 VanessaE https://github.com/VanessaE/plantlife_modpack/blob/master/bushes_classic/nodes.lua#L123 08:48 paramat perhaps open an issue about lowering the threshold for all plants. but it seems right to me that torches should never be bright enough to grow a plant 08:48 VanessaE why shouldn't they? 08:48 paramat it'll inconvenience some players true but tough :) 08:49 paramat because they're torches 08:49 VanessaE so? :) 08:49 VanessaE a dim light still grows things, they just grow less. 08:50 paramat nah a dim light should never grow anything in any timescale 08:50 paramat think of hydroponics grow lights, you'll just have to use meselamps or mod lamps instead 08:51 * VanessaE shrugs 08:51 VanessaE now what happens if the light isn't right next to the object? 08:51 paramat anyway see what the other devs think 08:51 VanessaE doesn't a light source of '14' produce 13-and-below in the neighboring nodes? 08:52 paramat yeah, the lamp needs to be immediately beside the plant 08:52 paramat just as with wheat, cotton 08:52 paramat diagonally-neighbouring doesn't work 08:53 VanessaE that also means now it's impossible to create a hydroponics mod 08:53 VanessaE if the resultant plants are more than 1 node tall 08:54 VanessaE a mese lamp or other grow light of equal brightness, suspended with 2 meters of air space between it and the ground is going to give the sapling/seedling on that ground a light level of 12 08:54 paramat well my pr is only for saplings, mod plants could have a lower threshold 08:55 paramat yeah falloff of 1 per node 08:55 paramat https://forum.minetest.net/viewtopic.php?p=194951#p194951 08:56 paramat each lamp can grow 4 plants around it 08:56 VanessaE sorry to say, but I hate that behavior 08:56 VanessaE it's too crowded 08:57 paramat then it's worth suggesting a lower threshold for all plants 08:57 VanessaE I just did :) 08:57 paramat hehe 08:59 VanessaE light sources only being able to spread 14 meters or so, and barely lighting up a scene, is a real problem 09:00 VanessaE I've got a 60W (equivalent) CFL bulb lighting up my computer room. In minetest, this same room looks about half as bright 09:00 VanessaE (I have my house modeled in minetest) 09:03 paramat personally i might approve of a plant threshold of 12, but only if torches are reduced by 1 so they can't be used as grow lamps 09:06 paramat but dimmer torches may be unpopular. so i think things are ok as they are 15:32 nm0i Morning 15:32 nm0i Is set_timeofday only way to contol brightness of sunlight? 15:33 Calinou yes, nm0i. 15:33 Calinou you can't change sun color server-side. 15:36 nm0i Thanks. Just making darker storms... 15:54 Krock Haxx the clinent 16:13 paramat can anyone +1 #3264 ? all builds fail due to this 16:13 ShadowBot https://github.com/minetest/minetest/issues/3264 -- Fix == to = by Rui914 16:15 Krock +1 16:15 Krock > anyone 16:15 paramat heh 16:16 paramat well it's trivial i'll merge it 16:19 paramat now merging 3264 16:24 paramat done 16:59 paramat #3265 16:59 ShadowBot https://github.com/minetest/minetest/issues/3265 -- findSpawnPos: Allow spawn up to 16 nodes above water level by paramat 18:24 OldCoder Which MT release added local map saving to the core? 18:27 PilzAdam OldCoder, 0.4.11 18:27 OldCoder PilzAdam, thank you. It is kind of you to respond. 18:27 PilzAdam see http://dev.minetest.net/Changelog 18:27 OldCoder Very well. FYI this is to facilitate tweaks to RedCrab which is now rescued. 18:39 PilzAdam est31, should #3258 also replace minetest.conf.example with the generated one? it would look like this: https://gist.github.com/PilzAdam/3503a574bf3277078e05 18:39 ShadowBot https://github.com/minetest/minetest/issues/3258 -- New Lua main menu settings by PilzAdam 18:41 est31 I'm generally not sure how we should manage that. 18:41 est31 if minetest.conf.example is autogenerated, should we keep it in git tracking? 18:42 est31 if yes, when and how should it updated 18:42 hmmmm 08:30 paramat uh the windows bulds failed, something to do with thread.cpp 18:42 hmmmm WTF, I ran it on Jenkins 18:42 est31 if no, same question 18:42 hmmmm precisely so this does not happen 18:43 PilzAdam est31, same handling as updating translation files 18:43 hmmmm damn, int ret == WaitForSingleObject(... 18:43 PilzAdam it should be done in feature freeze before release, so translators have time to translate it 18:44 est31 hrmm, I run it every two months 18:45 hmmmm 08:59 VanessaE light sources only being able to spread 14 meters or so, and barely lighting up a scene, is a real problem 18:45 hmmmm this is literally because of the number of bits 18:45 hmmmm :( 18:45 PilzAdam est31, auto-generating it, for example every startup, is not possible, since some distros may keep their doc folder in weird / non-writeable places 18:45 est31 well, it is advantageous hmmmm as well 18:45 hmmmm when I get rid of that asinine day/light bank thing we can have light from light sources expanding out to 256 meters 18:45 est31 bc we dont have tons of lightning updates 18:45 est31 only kilos :) 18:46 hmmmm yeah true 18:46 hmmmm I don't know man there's too many things to work on 18:46 hmmmm gotta take it one at a time 18:46 hmmmm I am really psyched about the map region locking mechanism I came up with last night and it seems it'd solve practically all of our problems 18:47 est31 PilzAdam, perhaps it should give a way to do it over console, or at least with removing comments from some parts of the settings tab file? 18:48 est31 hmmmm, tell us 18:49 PilzAdam est31, https://github.com/PilzAdam/minetest/blob/lua_settings/builtin/mainmenu/tab_settings.lua#L484-L498 18:49 hmmmm I described the basics in the logs, don't have any of the details of synchronization written out yet 18:49 hmmmm but basically each wait object will require a semaphore 18:49 hmmmm there's two lists, one of regions currently locked, and then the second of regions currently waiting to get locked 18:50 hmmmm a region lock is acquired by acquiring the region list lock and then using whatever spacial data structure to determine if any regions intersect with the requested region 18:51 hmmmm if so, then the requested region gets added to the pending lock list along with a pointer to its semaphore structure 18:51 hmmmm if not, it just adds its region to the locked region list 18:51 hmmmm when a region is released, it checks the pending region list and if the area it's releasing overlaps with anything pending, it'll trigger the event in the list 18:52 hmmmm the other thread then wakes up and rescans to see if it is able to lock 18:52 hmmmm if so it acquires the lock and begins execution on that region 18:52 hmmmm of course there are some details that need to be worked out 18:53 est31 you write you want to use areastore, thats great 18:53 hmmmm of course, but first I'm going to keep it simple and use a linear list for the proof of concept :-) 18:53 hmmmm that enhancement can be added later on once this is a proven technology 18:54 est31 okay 18:54 hmmmm we can roll this out little by little by emulating "envlock" as it is right now by acquiring the entire map as the region 18:54 hmmmm and then make small changes to restrict locks to the specific region they're actually checking or modifying 18:54 hmmmm by the time we're done, nothing will use the global map lock any longer 18:55 PilzAdam kahrl, would you be ok with merging #3258 now? the aggregated settings view can be done later, but it would need to be redone anyway 18:55 ShadowBot https://github.com/minetest/minetest/issues/3258 -- New Lua main menu settings by PilzAdam 18:56 est31 perhaps the settings_translation_file can be generated as well? 18:59 PilzAdam est31, and put it in po/, next to minetest.pot? 18:59 PilzAdam sounds good 18:59 PilzAdam I'll modify the script, too 19:01 est31 it should contain a comment explaining that its autogenerated 19:01 PilzAdam yep 19:16 kahrl PilzAdam, allow me to do some bikeshedding 19:16 kahrl the white-on-black gives me the impression that the settings are very technical (like in a terminal) 19:17 kahrl I think making the background transparent would reduce that feeling: https://gist.github.com/kahrl/73545042400dd226c831 19:19 kahrl For the boolean settings, I think double-clicking them or pressing enter should simply toggle them, not display the edit page 19:20 kahrl (the edit button should still get you to the edit page, so that you can see the description if you want) 19:26 PilzAdam kahrl, done 19:27 PilzAdam "no rule to make target `../po/settings_translation_file.c/minetest.po'" what? 19:27 est31 that toggle thing can be seen to be against least suprise 19:27 PilzAdam :-/ 19:27 est31 hrmm, perhaps it should not be put there... 19:27 est31 src? 19:28 PilzAdam misc? 19:28 est31 updatepo.sh only checks src/ and builtin/ 19:28 PilzAdam est31, I already thought earlier about a fast way to toggle booleans; I would say it's quite intuitive 19:29 kahrl est31: honestly I was confused at first when it opened an extra dialog for a boolean 19:29 kahrl but I can see what you mean 19:29 PilzAdam est31, I'll put it in src/ 19:32 kahrl from a functionality perspective I think the PR can be merged now (once the translation file stuff is dealt with) 19:32 kahrl I haven't reviewed the code, should I? 19:32 PilzAdam no, better don't look at it ;-) 19:32 kahrl hehe 19:32 PilzAdam est31 already looked at it 19:33 kahrl yeah I was mostly asking est31 whether he wanted someone else to look at it as well 19:34 est31 kahrl, if you want, look at it, then you can be blamed as well when a bug gets discovered :) 19:35 est31 when not if :p 19:35 PilzAdam your assumption that my code contains bugs is wrong 19:36 PilzAdam the one you discovered earlier was just a test to check if you review correctly ;-) 19:40 PilzAdam can I merge it now? 19:40 est31 it seems kahrl is commenting 19:41 kahrl yeah, I'm peephole reviewing 19:42 PilzAdam github doesn't auto-update commit comments in the PR view 19:46 est31 okay, having had a close look at GnuTLS, I've come to the conclusion that implementing encryption ourselves is much easier than using gnutls for rolling out dtls. 19:47 kahrl lol 19:50 est31 ill try a bit some more with gnutls, and if i give up ill get libnettle and do some aes(counter,packet) 19:51 est31 tls was designed for TCP, dtls is a modification of it 19:51 est31 also, tls is 99% used with certificates 19:51 est31 we use tls with PSK (pre-shared-key) 19:51 est31 so we dont need most of the parts of TLS 19:53 kahrl ok, I'm through 19:53 kahrl looks good except what I commented 19:54 kahrl (as I said, I peephole-reviewed, so I only looked at small parts at a time, I didn't review the big picture) 19:55 PilzAdam ah, good catch on the pairs() 19:55 kahrl est31: wait, I thought ipairs was the one that preserved order 19:56 PilzAdam previously I used the setting names as keys in the table, but then I decided to keep the order 19:56 kahrl for the type variable, it's not an issue at the moment, but it could trip up someone that tries to modify this code later 19:57 PilzAdam I'll change it 19:58 est31 kahrl, sorry you are right 19:59 PilzAdam fixed 20:00 kahrl looks all good now 20:01 kahrl +1 for merging from me. est31? 20:01 est31 yes 20:01 est31 +1 20:02 PilzAdam lets if I can still merge... it's been quite some time since my last time 20:02 PilzAdam +see 20:07 PilzAdam done 20:08 PilzAdam I'll write a forum post 20:08 est31 nice 20:09 est31 why have you edited updatepo.sh? 20:12 est31 --add-location is bad 20:12 PilzAdam I added po/settings_translation_file.c to it, and later removed it 20:12 est31 --add-location=file omits the number 20:13 est31 line number 20:13 PilzAdam it failed to run for me with =file 20:13 PilzAdam feel free to add it back 20:13 est31 your os is too old :) 20:13 est31 recent xgettext has it 20:20 PilzAdam https://forum.minetest.net/viewtopic.php?f=18&t=13427 20:20 PilzAdam est31, I'll upgrade in 2017 when support is dropped 20:22 est31 your xgettext is older than 0.18.4 right= 20:22 est31 ? 20:22 est31 https://github.com/minetest/minetest/commit/94961b3364f76d5861913af321e9be6200d080b3 20:23 PilzAdam 0.28.1 20:23 PilzAdam *18 20:23 Krock PilzAdam, why [Cancel] [Save]? Usually it's the other way 20:23 est31 i dont think that 20:23 est31 its mixed across applications 20:23 PilzAdam Krock, it's consistent with the world creation dialog 20:24 PilzAdam est31, it's also mixed inside of Minetest 20:24 PilzAdam Krock, eh, not world creation; the configure world dialog 20:24 Krock Found some stuff to read :) http://www.nngroup.com/articles/ok-cancel-or-cancel-ok/ 20:24 PilzAdam world creation is exactly other way round 20:25 PilzAdam Krock, feel free to create PR to make it consistent across Minetest 20:25 Krock Okay, I'll do so 20:27 PilzAdam kahrl, is it possible to automatically select the entry in the table when clicking the "+" to open a tree node? 20:27 PilzAdam that way it would be way less "jumpy" 20:28 PilzAdam currently the table gets updated when clicking +; and when updating the view always adjusts to contain the selected line 20:31 kahrl PilzAdam: it's possible (but not from lua, GUITable has to be changed) 20:31 kahrl or perhaps updating the table should not scroll to the selected row 20:35 PilzAdam kahrl, it would also be nice if the tree would be automatically extend so that the selected node is visible 20:35 PilzAdam that way it would look the same when returning from the change dialog 20:36 kahrl good idea 20:38 PilzAdam not scrolling the table to the selected row would also fix other updates, e.g. toggling the "Show technical names" checkbox 20:39 PilzAdam however, maybe that would the e.g. the world list to not show the currently selected world when starting up the game 20:39 PilzAdam s/the/cause/ 20:48 kahrl I tried the automatic extending to the selected item 20:49 kahrl it seemed to work, but then I noticed that you can no longer close a subtree if one of its children is selected 20:50 PilzAdam that would be fixed if clicking + would select this line 20:50 PilzAdam wouldn't it? 20:50 kahrl maybe 20:59 PilzAdam this new settings commit closed 5 issues; mostly requesting single settings to be present in GUI :D 21:39 Krock #3267 makes the "helper formspecs" look better - comments please :) 21:39 ShadowBot https://github.com/minetest/minetest/issues/3267 -- Standardize the menu button order and sizes by SmallJoker 21:48 kahrl #3268 21:48 ShadowBot https://github.com/minetest/minetest/issues/3268 -- Fix GUITable selection issues with trees by kahrl 21:56 est31 looks good 21:56 est31 have you tested it kahrl ? 21:56 kahrl yes 21:57 est31 good for merge then 21:57 kahrl thanks :) merge incoming 22:46 kilbith guys, i just fresh-cloned from latest commit with a virgin config and now you always spawn underground and the mapgen is fuckin screwed : https://lut.im/0vN7SbmIn4/NGGN7HUCRRalniYO.png 22:52 kilbith no idea if it's related : WARNING[Main]: NodeDefManager: Ignoring CONTENT_IGNORE redefinition 22:53 kahrl kilbith: nah, I also get that message but the spawn and mapgen is fine 22:54 kahrl what game version are you using? 22:55 kilbith minetest_game you mean ? 22:55 kahrl yeah 22:55 kilbith latest commit 22:55 kahrl same here. Very weird 22:55 kilbith i also compiled with clang 22:56 kahrl hrmm 22:56 kahrl it would be very strange but it could have an effect 22:56 kahrl see e.g. https://github.com/minetest/minetest/issues/3237#issuecomment-147662882 22:57 kahrl so strictly speaking, mapgen is architecture and compiler dependent at the moment 22:57 kahrl at least for lua mapgens. Not sure about minetest_game 22:57 kilbith well no i highly doubt it's compiler fault 22:58 kilbith no idea :( i closely checked my config and all from a fresh start 22:59 kahrl if there's some undefined behaviour in minetest, then compilers can do whatever they want and it's not their fault ;) 23:00 kilbith i'll inquire furthermore... 23:55 est31 ahh the po file display bug is still there 23:55 est31 somehow it got missed... 23:55 * est31 trying to fix