Time Nick Message 00:01 iqualfragile sapier: whover cares about mingw: fix it 00:03 sapier I'm gonna stop supporting any windows thingy if I'm the only one who's required to support all different windows build variants 00:11 ShadowNinja sapier: Um, don't remove whitespace from the whole repo, just from Jthread. 00:12 sapier I had to touch all those files for jthread cleanup ... and every file I change is fixed automaticaly ... it's a all or nothing decision 00:12 PilzAdam sapier, alternatively you rebase every single pull request 00:12 sapier PilzAdam I guess I already do that the last days 00:13 sapier that damn windows build works on exactly one machine 00:14 sapier I interpret this as "not fixing trailing line ends" 00:15 PilzAdam we can fix this once and for all when our pull request list is shorter 00:16 sapier that wont ever happen PA 00:16 sapier but I don't care about I'll find out how to revert keplers default behaviour to old juno style 00:25 hmmmm I do agree that there needs to be a point when we remove all trailing whitespace 00:26 hmmmm my IDE did that for a while and it kept making a mess of my commits 00:26 hmmmm until I figured out how to disable it 00:26 hmmmm and now it's annoying to do "git diff" and have trailing whitespace highlighted in red 00:26 hmmmm so I have to go back and manually fix that 00:26 iqualfragile hmmmm: isnt there some way to ignore whitespace changes? 00:26 hmmmm shrug 00:27 sapier I don't want to waste energy on whitespace discussions while I could use it for more usefull things 00:43 ShadowNinja So, at what point will we trim the whitespace? 30 PRs? 10 PRs? 00:43 sapier never 00:51 hmmmm agh fuckfuckfifcufkcufck 00:51 hmmmm I just realized i need to keep an intermediate schematic buffer to apply the trim to 00:52 hmmmm so listen to how fast this is: 00:52 sapier https://github.com/minetest/minetest/pull/1029 what about this variant only remove trailing whitespaces from non empty lines 00:52 hmmmm 1. apply rotation 00:52 hmmmm 2. blit to intermediate buffer with probabilities 00:53 hmmmm 3. trim schematic 00:53 hmmmm 4. blit to the vmanip 00:53 hmmmm 5. blit back to the map 00:53 hmmmm that's technically 3 buffers 00:53 sapier guess it's the only way to do 00:54 hmmmm and then it does this for every single tree 00:54 hmmmm i need to do some profiling and see how horrible this is 00:55 sapier why don't you cache em? is memory usage that huge? 00:55 hmmmm well this is generalized 00:56 hmmmm if I were to cache something, it'd have to be one for every single possibility of the schematic 00:58 hmmmm http://paste.ubuntu.com/6502012/ this is what I'm doing 00:58 ShadowNinja local schemid = minetest.prepere_chematic("path", options) minetest.spawn_schematic(schemid) 00:59 ShadowNinja goto == bad. 01:00 hmmmm lol 01:01 hmmmm hmmm 01:01 hmmmm am I overgeneralizing this? 01:02 hmmmm realistically the only direction I need is -y, +y would only be for ceiling placement and I don't even have ceiling placement for schematics added 01:08 hmmmm this doesn't even fit the purpose of what I'm doing very well 01:08 hmmmm take for example a jungle tree which has a base with a specific shape 01:09 hmmmm if it generates shorter, the length would vary in the middle of the trunk, not along the edges 01:09 hmmmm somebody just tell me if generically, programatically doing this is possible or not 01:11 PilzAdam maybe propabilities per horizontal layer? 01:12 hmmmm how would you possibly 1). encode that with the current schematic format but more importantly 2). specify which slice tangential to the y axis has a probability or not 01:15 hmmmm i suppose #1 is impossible, and #2 can only be done through the player specifying the y offset through the console or something 01:16 sapier the win32 sleep fix doesn't work it needs to be used for mingw too not only for msvc 02:53 hmmmm god 02:53 hmmmm dammit 02:53 hmmmm why do i keep making retarded decisions on which order to put lua api parameters in 02:56 VanessaE don't we all make bad decisions like that sometimes? 02:56 VanessaE I went through that in plants_lib for a while before I just went with a table, remember? 08:13 thexyz mapgen v7 is broken https://gist.github.com/xyzz/ed6a340431aafb384516/raw/1aff32580c9a5cf72065e929ac9ca293414f8ecd/gistfile1.txt 08:25 VanessaE inb4 hmmmm says "aw fuck it, I'm ditching that whole mess and starting over" 13:49 thexyz hmmmm: https://gist.github.com/xyzz/ed6a340431aafb384516/raw/1aff32580c9a5cf72065e929ac9ca293414f8ecd/gistfile1.txt 13:56 hmmmm thanks 13:57 sapier what tool is this? 13:57 thexyz sapier: clang with -fsanitize=address 13:57 thexyz sapier: CC=clang CXX=clang++ cmake .. -DCMAKE_CXX_FLAGS="-O1 -g -fsanitize=address -fno-omit-frame-pointer -fno-optimize-sibling-calls" -DCMAKE_EXE_LINKER_FLAGS="-fsanitize=address" -DENABLE_FREETYPE=1 -DRUN_IN_PLACE=1 13:58 sapier interesting :-) 13:58 thexyz then run ./bin/minetest 2> log, then when it crashes you should run asan_symbolize.py < log | c++filt 13:58 hmmmm in practice that shouldn'tve happened though 13:58 hmmmm p ought to be restricted to node_min an node_max there 13:58 sapier I hope that there aren't any bugs that really should happen :-) 14:01 thexyz aand when I try to enter some /command in the chat I get this https://gist.github.com/xyzz/c8af3888a035258e8172/raw/3f4e5ab3b70e1587a072c27498baa882be578436/gistfile1.txt 14:01 hmmmm that's in irrlicht, we can't do anything about that 14:01 thexyz I don't understand this, how can it crash there? 14:01 thexyz no, it's our file 14:02 thexyz https://github.com/minetest/minetest/blob/master/src/intlGUIEditBox.cpp#L1434 14:02 hmmmm oh 14:02 hmmmm *blinks* 14:02 sapier guess this should be fixed immediatly :-) 14:03 sapier some ppl are complaining about chat crashes this could be source 14:04 hmmmm thexyz, it can crash there because that intlGUIEditBox was freed at the time setTextMarkers was called 14:05 hmmmm in other words, irr::gui::CGUIEnvironment::postEventFromUser posted the event to an already-destroyed GUI object or w/e it takes 14:05 hmmmm already-destroyed IGUIEditBox 14:06 hmmmm I guess you need to somehow unbind the event before destroying that control 14:06 sapier guess someone forgets to tell irrlicht about deletion? 14:06 hmmmm that's like javascript except even worse 14:07 sapier you always have to care if you give away pointers to other threads that's a design principle of c/c++ :-) 14:07 hmmmm I mean irrlicht though, shouldn't it automatically unbind events on delete 14:08 sapier how to notice? 14:08 hmmmm destructor...? 14:09 sapier it's our own destructor so if we don't do it in there who shall do it? 14:09 hmmmm the parent class! 14:10 sapier that'd require a event handling base class ... not sure if this is part of irrlicht 14:11 sapier but yes a full featured toolkit should do it this way ... but irrlicht is quite limited as of toolkit features 14:11 sapier https://github.com/minetest/minetest/pull/1029 anyone to review this one? (fixes windows build and removes some waste from jthread) 14:42 hmmmm how could a sem_wait or sem_post etc ever fail 14:42 hmmmm ah EINVAL 14:42 hmmmm the win32/jevent.cpp whitespace at the bottom, fix that! 14:43 hmmmm otherwise it looks fine 14:44 hmmmm I really dislike the way JThread works to be honest, it itself uses like 3 mutexes per thread for basically nonsense. i do feel like some logic could be condensed 14:45 hmmmm so, thexyz, when did you get that last error exactly? 14:49 sapier I haven't had a look at jthread thread itself 14:50 thexyz hmmmm: what error? 14:51 thexyz with chat? it happens every time 14:51 hmmmm the intlGUITextBox or whatever 14:51 hmmmm when though 14:51 sapier hmmmm those mutexes jthread uses are necessary to provide it's interface 14:51 hmmmm menu? in game? formspec? 14:52 thexyz chat, > aand when I try to enter some /command in the chat 14:52 sapier continuemutex and continuemutex2 are used for startup synchronization while runningmutex is used for shared data access 14:52 thexyz in game 14:52 hmmmm oh 14:53 hmmmm sapier, exactly, which I think is stupid 14:53 hmmmm the interface itself is unnecessary 14:53 sapier no it isn't there are good reasons to do so 14:53 hmmmm a while back i was considering scrapping jthread entirely and just adding some things to porting.cpp for threads 14:54 sapier ok wait 14:54 sapier the api doesn't even support creating a thread while not starting it 14:54 hmmmm out of those three the only thing needed is runningmutex 14:55 hmmmm yeah, some logic would have to be changed I get that 14:55 sapier good god the more I look at it the more I think jthread was written by someone doing this the first time in his live 14:55 hmmmm i'm most worried about the overall cleanness of design 14:56 sapier but still one thing is implemented 14:56 sapier jthread ensures threads are created and don't stall in non created state 14:57 sapier once you return from start you can be sure your thread is up and running 14:59 hmmmm i suppose that's a good thing, yes, but i'd say a good threading design would make such synchronization unneeded 14:59 sapier no 15:00 sapier imho it's good design to NOT rely on os scheduling assumptions 15:00 hmmmm what? today isn't a holiday 15:01 sapier think about last days 3 os 3 completely different error occurances for non threadsafe actions 15:01 hmmmm that was because of safe data access not being used, not because the thread didn't start up in time 15:02 sapier that doesn't make a difference ;-) making sure a thread is there after start is a good thing ... creating a thread isn't a lightweight operation either so those mutex locks don't change the overall performance 15:03 hmmmm of course not, it's simply uglier than i think it could be made 15:04 sapier it's not ugly just more complex ... and as complexity is hidden within jthread why bother? 15:04 sapier calender door ... wait ... now I remember what I missed 15:06 sapier I prefere more complex but safe solutions to simplistic solutions I always have to consider how to use it ... at least if their performance is almost equal 15:07 sapier ok I removed the trailing newlines ... ready for merge? 15:15 hmmmm dure 15:15 hmmmm sure* 15:23 sapier ok pushing jthread fixes now 15:55 Exio4 [21:59:50] <+ShadowNinja> goto == bad. 15:55 Exio4 why? 15:56 PilzAdam maybe he meant "goto bed"? 15:57 thexyz Exio4: are you genuinely wondering why goto is bad? 15:59 Exio4 it is just other 'tool', if you overuse exceptions, ifs, or other 'features'... 16:04 Exio4 the IRC isn't C code 16:08 thexyz wtf is going on here 16:08 hmmmm goto is fine, whoever told you it was bad is just parroting somebody's weaker assertion from the 60s about it being bad if overused just like anything 16:10 thexyz it's bad because it's easily overused 16:10 hmmmm my use case in the code sample that comment was made on is fine 16:10 thexyz by people who aren't really familiar with the language 16:11 thexyz yeah, i can agree that in this case it's okay 16:20 Exio4 thexyz: and same with exceptions, they can be easily overused 16:22 celeron55 anything can be overused; case closed 16:24 celeron55 (just imagine what kind of code someone from assembly/basic background might have written in C tens of years back in time, and then stop that and do something useful instead) 18:23 PilzAdam hmmmm, http://irc.minetest.ru/minetest-dev/2013-11-30#i_3464526 18:48 PilzAdam sapier, https://forum.minetest.net/viewtopic.php?pid=120404#p120404 18:49 PilzAdam I noticed that too, when you click on a server or a world in the server tab then your nick and password get reset 18:51 sapier nick and password? 18:52 sapier I didn't verify how password behaviour was before but as of security point of view reseting password on server switch is best to do 18:52 sapier if not done you'd send the old servers password to whoever is at new server 18:53 Exio4 *** Error in `/home/exio4/sources/minetest/build/../bin/minetest': double free or corruption (fasttop): 0x00007fffe8000950 *** 18:53 Exio4 is this known 18:53 Exio4 a double free error in master 18:54 ShadowNinja sapier: I beleive the password is sent hashed. 18:55 PilzAdam sapier, no, its just annyoing that clicking somewhere else changes the textfields 18:57 sapier security is always annoying thats not a reason 18:57 thexyz Exio4: is that reproducible? 18:57 PilzAdam sapier, how is a hashed password a security risk? 18:58 thexyz you can use it to login to any minetest server 18:58 thexyz so that's a security risk 18:58 sapier the hash is the only secret user has 18:58 sapier knowing password and username is enough to enter 18:59 thexyz but that's extremely inconvenient — I enter my nickname, password, then click some server and then I have to enter everything again 18:59 thexyz well it's not like minetest's the most secure thing ever 18:59 Exio4 thexyz: no idea, i'm getting random crashes and one of them was the double free, the other was one repated by john_minetest before 18:59 thexyz Exio4: you could try running debug build in gdb or running debug build with clang address sanitizer 19:00 sapier no I don't say its save at all ... but if we don't at least try to not tell everyone users credentials we can just skip them 19:00 sapier it's even more comfort not having to remember any password 19:00 Exio4 er 19:00 Exio4 i think i got a reproduceable crash 19:01 sapier great exio4 those are best ones to fix 19:02 Exio4 well, half of the time it is the same crash, and it is a different one that what i posted here 19:02 PilzAdam sapier, also I have the feeling that menu is slower since async, especially shutting down and starting a server/world 19:03 thexyz Exio4: please do what I asked you for 19:03 Exio4 thexyz: i'm uploading the log of thread apply all bt full 19:03 sapier as you say ... maybe sleep(1) isn't best idea ;-) ... some ms should be enough there 19:04 thexyz sapier: was the mingw build issue sfan5 was experiencing fixed in the end? 19:05 Exio4 http://dpaste.com/1489385/ ? 19:05 sapier mingw is broken and I wont fix it IMHO it's waste of time supporting 5 incompatible compilers at same os 19:05 thexyz alright be prepared for butthurt then 19:06 sapier and it's NOT broken because of things I added it's broken by design 19:07 thexyz i'm not even asking you to fix it 19:07 sapier ppl keep on telling windows in source what windows version it is ... I guess windows itself would know best but usually I'm wrong 19:09 Exio4 i got the same bug when pressing play 19:09 Exio4 :( 19:09 sapier latest master exio? 19:09 Exio4 should be 19:10 sapier guess there's still something left ... is anything within minetest threadsafe? 19:10 sapier :-) 19:11 sapier can you compile -O0 and reproduce this one exio? 19:11 Exio4 the only differences between my build and upstream, http://dpaste.com/1489393/ 19:11 Exio4 it wasn't latest pull 19:11 sapier ok then update 19:12 sapier I fixed some errors quite similar to this one last night 19:12 Exio4 ah 19:12 Exio4 the jthread cleanup? 19:12 sapier no the log thread registry thing 19:13 sapier jthread cleanup is win32 build and as I was touching it I removed useless code too 19:14 Exio4 btw, how do i build with "-O0"? i added it to CXXFLAGS with cmake-gui and it still said :P 19:14 Exio4 (such a noob question) 19:14 sapier you need to modify CMakeLists.txt ... people in here keep thinking they can debug -O1 code ;-) 19:15 sapier maybe they can ... I can't I need to know whats going on 19:18 ShadowNinja cmake -DCMAKE_CXX_FLAGS='-O0' <-- I've seen something like this used. 19:18 sapier might work too yes 19:19 sapier there are many ways to do this 19:19 ShadowNinja Does CMAKE_BUILD_TYPE='Debug' set -O0? 19:19 Exio4 no, -O1 19:20 sapier but I'd suggest updating to latest master first 19:22 Exio4 yes 19:22 Exio4 seems like the double memory was the same as the other one 19:22 Exio4 i'm not getting it 20:00 sfan5 thexyz: may I push http://pastebin.aquilenet.fr/?24b2ba01f2dbd61d#vgZkWWVCRew3+Q0+V+OpJy0zp4eNMcYV3JRTqgdUoJM= ? 20:01 thexyz sfan5: if that works for you then why not 20:01 thexyz if that breaks msvc build then I'll fix that eventually 20:01 thexyz but it seems it should work 20:01 sfan5 well... as long as MSVC does define _WIN32 it works 20:01 thexyz but, I thought sapier has decided to decrease the sleep time 20:02 thexyz sfan5: so you should rewrite it to use usleep and also decrease the interval 20:02 thexyz 100 ms should be fine 20:02 sfan5 can you say these things before you say "then why not" 20:02 sfan5 I already pushed 20:02 thexyz sfan5: nah, that's fine, then leave it as is 20:03 thexyz john_minetest: your comment doesn't add anything meaningful to the conversation 20:03 thexyz john_minetest: can you please refuse from posting comments like that in the future? 20:35 sapier please test ... https://github.com/minetest/minetest/pull/1030 ... I was annoyed about empty search tab 20:39 thexyz john_minetest: I would like to not see messages that add nothing to conversation here; I don't care about your views on javascript and shit. Moreover, that message wasn't even addressed on you. So please can we stop with the retardity? Compalining for the sake of complaining is not welcome here. 20:40 thexyz I believe no one here cares if you have javascript enabled or not. 20:42 sfan5 john_minetest: how would a script spy on you? 20:43 Calinou pastebin.com has ads though :P 20:44 thexyz and here it goes 21:02 thexyz the only one who's ever got annoyed by this just left this channel 22:34 PilzAdam sapier, https://github.com/minetest/minetest/pull/1031 is good 22:34 PilzAdam why did you make it 1 second in the first place? 22:37 kahrl why not use sleep_ms? 22:38 kahrl btw, the include guard for this file should start with L_ and not C_ 22:44 sapier I didn't realize this would cause delays in startup ... and as of closing something I usually don't care if it's 1s or 2 :-) 22:45 PilzAdam I havent noticed it at startup 22:45 PilzAdam but the menu also "closes" when you start a world.... and I guess you see the problem there 22:45 sapier that's what I meant with "startup" 22:46 kahrl imho it would be better if we used a JThread method that called either pthread_join or WaitForSingleObject 22:46 sapier kahrl thanks 22:48 sapier pthread_join and waitforsingleobeject aren't exactly compareable are they? 22:49 kahrl how so? 22:49 sapier pthread_join is a thread function is single object thread bound too? 22:49 sapier I don't know that much about win32 api 22:50 kahrl it can wait on any handle that supports some kind of "signaled" state 22:50 kahrl threads are signaled when they terminate 22:50 sapier then this might be an option too yes 23:04 sapier kahrl this way? 23:20 kahrl seems good, maybe check for errors 23:21 kahrl sapier: ^ 23:22 kahrl I don't know if they should be treated as fatal errors (using assert) or just written to stderr 23:22 kahrl fatal is probably safer 23:22 sapier if we can't rely on threading we should stop 23:22 kahrl yeah 23:27 kahrl maybe write a comment somewhere that Wait() may only be called after Start() and not after Kill() 23:31 kahrl hold on a sec 23:32 kahrl in the pthread implementation, jthread creates the threads a detached 23:32 kahrl which means they can not be joined 23:32 kahrl as* 23:32 sapier ? 23:32 sapier it does work for me? 23:32 kahrl maybe some implementation artifact? 23:33 sapier as far as I know threads aren't detached by default 23:33 kahrl pthread/jthread.cpp:87 23:34 sapier oops 23:35 sapier ok wait I guess I forget to compile prior testing the asserted version 23:36 sapier jthread is crap ... using pthread_cancel as default shutdown mechanism ... 23:37 kahrl indeed... wtf 23:38 sapier it's pure luck this doesn't crash evertim we close a thread 23:38 sapier I switch to non detached mode and cleanup in destructor maybe this works 23:39 BlockMen celeron55, here is the template for the subpages, currently without the fading out effect of the blue lines 23:39 kahrl well we do make sure every thread terminates in an orderly fashion before we destruct the corresponding JThread 23:39 sapier we can't without touching all threads 23:39 kahrl so pthread_cancel is not actually called 23:39 sapier do we? 23:40 kahrl I thought we did 23:40 sapier I haven't had a look at any single thread ;-) but I'd not be surprised if we didn't do 23:40 sapier ok I just remove the detached I don't have any idea what this should be good for 23:40 kahrl no 23:41 kahrl that creates a memory leak for every thread that Wait() isn't called on 23:41 sapier destructor ;-) 23:41 kahrl the destructor does nothing if running == false 23:42 sapier running is true as of thread has been started 23:43 kahrl if the thread terminates itself (as it should) it sets it to false again 23:44 sapier ok you're right 23:44 sapier so another variable 23:45 kahrl honestly we could just require that every thread is Wait()-ed on 23:46 kahrl btw, is it possible to consolidate SimpleThread and JThread? 23:47 sapier if we can hide this detail within jthread we should do 23:48 sapier I don't know but I guess we could as we already modified jthread that much 23:50 kahrl just wait in the destructor if the thread is running? 23:50 kahrl after killing it 23:51 sapier a little bit more to do but I guess I have a working solution now 23:54 sapier ok I hope I didn't miss a case ... do we have to do same things on windows too? 23:55 sapier I guess I should rename runningmutex to statusmutex 23:58 sapier that's not good now "kill" wont do what name tells any longer 23:58 kahrl just remove Kill() from the public interface 23:58 kahrl it's only needed in the destructor