Minetest logo

IRC log for #minetest-dev, 2015-10-17

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

All times shown according to UTC.

Time Nick Message
00:13 hmmmm yes, very good
00:13 hmmmm that's exactly how I would've fixed it
00:28 luizrpgluiz joined #minetest-dev
00:30 luizrpgluiz joined #minetest-dev
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/ma​nual/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 luizrpgluiz left #minetest-dev
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/bugzill​a/show_bug.cgi?id=67114#c4
04:22 shadowzone joined #minetest-dev
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:56 paramat joined #minetest-dev
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/3​31536/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:43 nrzkt joined #minetest-dev
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:50 Hunterz joined #minetest-dev
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:03 paramat joined #minetest-dev
08:10 ShadowNinja https://github.com/ShadowNinja/minetest/comm​it/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/minetes​t/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_modpac​k/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/vi​ewtopic.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
09:30 Calinou joined #minetest-dev
09:35 Krock joined #minetest-dev
09:44 paramat left #minetest-dev
09:55 Darcidride joined #minetest-dev
11:01 CraigyDavi joined #minetest-dev
11:06 PilzAdam joined #minetest-dev
11:23 H-H-H joined #minetest-dev
11:52 technics joined #minetest-dev
12:38 julienrat joined #minetest-dev
12:55 Darcidride joined #minetest-dev
12:58 waressearcher2 left #minetest-dev
13:15 Player2 joined #minetest-dev
13:33 zupoman joined #minetest-dev
14:13 luizrpgluiz joined #minetest-dev
14:30 jin_xi joined #minetest-dev
14:44 younishd joined #minetest-dev
14:55 Warr1024 joined #minetest-dev
14:56 luizrpgluiz left #minetest-dev
15:16 leat1 joined #minetest-dev
15:27 leat1 joined #minetest-dev
15:30 nm0i joined #minetest-dev
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:46 Darcidride joined #minetest-dev
15:50 zat joined #minetest-dev
15:54 Krock Haxx the clinent
16:07 julienrat joined #minetest-dev
16:08 julienrat left #minetest-dev
16:12 paramat joined #minetest-dev
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:41 hmmmm joined #minetest-dev
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
17:06 paramat left #minetest-dev
17:14 Gael-de-Sailly joined #minetest-dev
17:15 VirusJones joined #minetest-dev
17:37 Darcidride joined #minetest-dev
17:46 nore joined #minetest-dev
18:08 leat2 joined #minetest-dev
18:20 leat2 joined #minetest-dev
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:30 est31 joined #minetest-dev
18:39 PilzAdam est31, should #3258 also replace minetest.conf.example with the generated one? it would look like this: https://gist.github.com/Pil​zAdam/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_set​tings/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:36 proller joined #minetest-dev
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:17 younishd joined #minetest-dev
20:18 Gael-de-Sailly joined #minetest-dev
20:20 PilzAdam https://forum.minetest.net/vi​ewtopic.php?f=18&t=13427
20:20 PilzAdam est31, I'll upgrade in 2017 when support is dropped
20:22 FR^2 joined #minetest-dev
20:22 est31 your xgettext is older than 0.18.4 right=
20:22 est31 ?
20:22 est31 https://github.com/minetest/minetest/commi​t/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/artic​les/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:29 Warr1024 joined #minetest-dev
20:30 younishd joined #minetest-dev
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:12 Darcidride joined #minetest-dev
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:49 sloantothebone joined #minetest-dev
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:00 hmmmmm joined #minetest-dev
22:04 Miner_48er joined #minetest-dev
22:41 Sokomine joined #minetest-dev
22:45 kilbith joined #minetest-dev
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:47 DFeniks joined #minetest-dev
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:35 OldCoder joined #minetest-dev
23:55 est31 joined #minetest-dev
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

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