Time Nick Message 13:34 rubenwardy How do I apt-get curl dev package? 13:34 rubenwardy (linux) 13:42 sfan5 i'm just going to leave this here: https://gist.github.com/4642453 15:28 sapier can someone explain to me why deleting textures on reload may crashes server on connect of client? I've read http://irc.minetest.ru/minetest-dev/2012-11-25 and can't reproduce celerons bug with that commit included 17:46 Progers_ hi 17:46 Progers_ Hm 17:46 Progers_ Quassel IRC is working good :D 17:47 sapier are namespaces allowed within minetest code? 17:52 Calinou afaik, yes 17:52 Calinou what does irrlicht do? :P 17:53 sapier Yes but to use irrlicht you'll have to accept it ... adding namespaces to improve code readability within minetest code is another thing 17:54 sapier I wondered about using namespaces in preparation of splitting monster files within minetest 18:16 sapier celeron55 what do you think about moving RemoteClient to its own file? 18:21 rubenwardy what is this? 18:21 rubenwardy https://github.com/celeron55/minetest/tree/kwolekr_mg_r1 18:23 VanessaE that's hmmmm's mapgen v7 fork :-) 18:24 VanessaE s/fork/branch/ 18:24 darkrose if you look at the commits, it's really obvious 18:36 hmmmm everything there has already been merged into master 18:36 hmmmm still waiting on the two other patches i have pull requests for 18:36 hmmmm it's pretty tempting to just press the giant green button myself and get it over with. 18:38 VanessaE heh 18:40 hmmmm sapier, i believe scriptapi.cpp should be the first thing to get split up. 18:40 hmmmm the next course of action for me, personally, is to move all EmergeThread related things to emerge.cpp, along with the EmergeManager. 18:40 sapier yes 18:40 sapier you're right scriptapi.cpp is another monster file 18:41 hmmmm i'm pretty sure it's the single largest source file 18:41 sapier is there any chance to add subfolders? 18:41 hmmmm i'd say so 18:41 hmmmm you want to make a /script/ directory? 18:41 hmmmm that's a pretty big change though, i'd talk to more people first. 18:42 sapier in longterm I was more in direction server/client/common subdirectories with subfolders in each again 18:42 VanessaE I have a huge update to colors.txt for minetestmapper.py - which includes defaults for many popular mods. Interested? 18:42 hmmmm that's too Java project-y 18:43 hmmmm i don't believe we have as many source files that it'd take to warrant such division. 18:43 sapier what's java if you do code organization? :-) ... still as most ide's support virtual folders this is not my primary concern 18:43 sapier I've done it for myself everyone else has to do it like she/he likes 18:43 hmmmm well Java was really made with IDEs in mind 18:44 hmmmm a lot of people don't like that 18:44 hmmmm but it's because of the sheer amount of source files necessary for a java project that it really necessitates having a deep directory structure 18:44 sapier I've recognized this too ... but we have far to many files in a single folder too 18:44 hmmmm there are other projects with way more.. 18:45 hmmmm right at this moment in time i'd say it's a comfortable amount, maybe others would disagree, but 18:45 sapier I know ... I won't argue about that either as it's most likely a matter of personal preference 18:45 hmmmm if scriptapi.cpp in particular is broken up, i'd estimate it'd be divided into about 6-8 source files 18:46 hmmmm which would make it an excellent candidate for a subdirectory 18:46 sapier my definition of comfortable is if I (normaly) don't have to scroll around in file list to access files I'm working at 18:46 sapier :-) 18:46 sapier yes I know I'm lazy 18:46 hmmmm depends on what your font size is and everything, lol 18:47 sapier there are already some naturak split marks within scriptapi to start at 18:47 sapier moving each class into a own file might be a good start 18:47 hmmmm yeah 18:48 hmmmm there are a LOT of classes though, so 18:48 sapier :-) ok I'll have a look and split where it seams to be reasonable 18:48 hmmmm don't do that just yet, i need to add stuff to scriptapi.cpp 18:48 hmmmm in the latest patch 18:48 sapier ok so I'll wait 18:49 hmmmm but yeah 18:49 hmmmm i'm thinking of something like 18:49 hmmmm scriptapiobj.cpp scriptapienv.cpp scriptapinoise.cpp and so on 18:49 hmmmm scriptapi code common to everything and/or misc. things stay in scriptapi.cpp 18:50 sapier yes I thought nearly same 18:50 hmmmm ha ha, great minds think alike 18:51 sapier could you check and merge pull requests 447 and maybe 437 18:52 sapier https://github.com/celeron55/minetest/pull/447 18:52 sapier https://github.com/celeron55/minetest/pull/437 18:52 RealBadAngel +1 for idea of splitting scriptapi, its way too big 18:52 sapier its 7k lines ... so about 6k above my personal limit 18:52 hmmmm same 18:52 sapier if you need more than 1k lines something is wrong with your design 18:53 hmmmm what did celeron have to say about the assert_backtrace thing 18:53 sapier except if its a resouce file 18:54 sapier it was called "backtrace" first he said backtrace shouldn't assert so I added assert functionality to this function and renamed it to assert_backtrace ... I don't know if he did check it since then 18:54 sapier first version didn't do a parameter check too 18:55 sapier I'd use normal assert but it doesn't show a stacktrace 18:55 hmmmm do you have both a backtrace and a backtrace_asert? 18:55 sapier no only assert_backtrace .. as far as I understood evaluating stack is a destructive operation 18:55 hmmmm nonsense... of course it's not 18:55 sapier it's not? 18:56 hmmmm how would that be destructive, you're only reading things 18:56 sapier lua_pop is only reading? 18:57 Progers i have installed Kubuntu 12.10 :D 18:57 hmmmm oh, nevermind, are you sure you need lua_pop for a backtrace though? 18:59 sapier1 no I'm not sure but there already was a script_get_backtrace function 18:59 hmmmm hmmm 18:59 hmmmm yeah i was just going to ask where the actual function is 18:59 hmmmm that's in script.cpp i assume? 18:59 sapier1 yes 19:00 hmmmm p0p 19:00 hmmmm let's see here.. 19:01 hmmmm no, the get* functions push onto the stack, the pops are there for the purpose of reversing the things it did 19:01 hmmmm but that's really convenient that it has a backtrace function _for_ you already 19:01 hmmmm but in theory it shouldn't be destructive at all. 19:02 hmmmm now what does the backtrace do exactly, show you the contents of the stack or does it just show the heirarchy of function calls? 19:02 hmmmm or both? 19:02 sapier1 function call hierarchy 19:03 sapier1 no variables 19:03 hmmmm alright, i should add in my dumpstack() that i was using for testing my code 19:03 hmmmm that might be useful 19:04 hmmmm sapier, when is assert_backtrace intended to be called? 19:04 sapier yes :-) that would help a lot 19:04 sapier It's to be called in mods where you need to check function parameters 19:05 hmmmm alright, because i was going to say, luaErrorHandler already does a backtrace. 19:05 sapier e.g. mobf uses some sort of this pointer for most of it's functions if it's broken something went terribly wrong 19:05 hmmmm didn't realize it had more utility 19:06 sapier and most time you recognize this in a function called about 10 times ... which is a real pain to debug 19:08 hmmmm so wait a minute let me look at this... if do_assert is true then the function basically does nothing 19:08 hmmmm except returns nil 19:08 sapier yes like assert does 19:09 hmmmm but where does it actually perform the assert? 19:09 sapier if parameter is false: e.g. 19:09 sapier assert_backtrace(some_variable ~= nil) 19:09 sapier assert(some_variable ~= nil) 19:09 sapier it's same syntax 19:10 hmmmm oh 19:10 hmmmm haha 19:10 hmmmm that's true 19:11 hmmmm so wait, what does luaL_error do exactly 19:11 hmmmm wouldn't that call luaErrorHandler? 19:13 sapier lauxlib.c L 86 19:13 sapier its just printing the error message and line where error occured 19:14 sapier but you're right maybe script_error would be better at this place 19:15 hmmmm well you've tested this right? and it does the intended behavior 19:15 sapier yes it does show backtrace and doesn't crash application after it ... but that doesn't implie there may not be a better way to continue after backtrace 19:16 sapier my primary concern was to have that backtrace 19:16 hmmmm i mean i'm concerned with it because it looks (to me) like it would print out a duplicate backtrace 19:16 hmmmm but that's not the case 19:16 hmmmm i'd still rather wait for celeron's final say and see what he wants 19:16 hmmmm sorry 19:16 sapier no problem 19:16 sapier at least someone did look at it now :) 19:16 hmmmm nobody looks at my pull requests 19:17 sapier if you tell me what request you are talking about I'll have a look ... but I can't decide anything ;-) 19:18 hmmmm these https://github.com/celeron55/minetest/pull/441 things https://github.com/celeron55/minetest/pull/442 19:21 sapier NULL isn't best thing to use for portability issues ... but minetest uses it everywhere so I assume it's fine here too 19:24 sapier why are mapgen and mapgen params created separatly? 19:25 sapier L 168 seems to be a merge artifact 19:27 hmmmm [02:21 PM] NULL isn't best thing to use for portability issues ... but minetest uses it everywhere so I assume it's fine here too 19:27 hmmmm what..? 19:28 hmmmm mapgen and mapgen params are created separately because the mapgen needs a mapgenparams in order to be created 19:28 sapier NULL has lots of different meanings for different platforms and processors ;-) ... but I assume this doesn't matter for those minetest does support 19:29 hmmmm it always means the integer representation of 0 as per the C and C++ standard 19:29 hmmmm if NULL is something else other than the integer representation of 0, then it's not C++. 19:29 sapier :-) yes if everyone would use standard ;-) 19:29 hmmmm it's some other language. 19:29 hmmmm can you show an example where that would fail, then....? 19:30 hmmmm this is just a part of the language 19:30 sapier if it's defined as (void*) 0 for example 19:30 hmmmm it's like saying that strlen() will return a float in some implementation because not everybody uses the standard 19:30 hmmmm (void *)0 still has the integer value of 0 19:31 sapier It's what I've learned when doing embedded programming on different processors with different toolchains ;-) 19:31 hmmmm (int)((void *)0) is still 0 19:31 sapier int dummy = NULL is problematic 19:31 hmmmm give me a specific example 19:32 hmmmm and what did you do to solve the problem 19:32 sapier some compilers will fail for this because (void*) 0 is a pointer while int dummy ain't 19:32 sapier int dummy = 0 is solution 19:33 hmmmm on those platforms, NULL is indeed defined as (void *)0 19:33 hmmmm although you should be able to, i don't see why you'd set an integer to NULL... 19:33 sapier dosn't really make sense but is done in some code I've seen 19:34 hmmmm none of the minetest code at least 19:34 sapier true 19:34 hmmmm but, seriously. let's be rational here 19:34 sapier it's an academic discussion :-) so don't change anything 19:35 hmmmm if the C++ standard says that strlen() returns a size_t, let's assume that it'll always be a size_t unless we find a specific example of a platform that doesn't follow the standard that we wish to support 19:35 hmmmm for example. 19:35 sapier this is true for now but will it be true in 5, 10 15 years? 19:35 hmmmm of course 19:35 hmmmm i don't see why anything would change 19:36 hmmmm even if it does for some reason change, we can still set the compilers to use the C++11 standard where we know it to be true 19:36 sapier standards are subject to change I'm working with lots of really old code and see what asumptions where made at time of its creations ... most assumptions where true by the time of writing 19:36 sapier some where false even then but thats another problem :) 19:37 hmmmm well were they assumptions, or were they following the standard? 19:37 hmmmm one is unacceptable, the other is the goal of any coder 19:37 hmmmm let me guess, they assumed the size of a pointer is the size of a long? 19:37 sapier that code was written when there was not one single "standard" 19:37 hmmmm there is now 19:38 sapier no one was an architecture using token + offset to access memory 19:39 hmmmm oh by the way, L168 isn't a merge artifact, i put that there to separate the MapgenParams from the end of the EmergeManager things 19:39 sapier there are multiple standards today too ;-) but it's better than past 19:39 sapier ok 19:39 hmmmm it probably shouldn't be there but it does make things neater 19:40 hmmmm when I put the things above it into emerge.cpp, it'll be removed 19:40 sapier 441 doesn't seem to have any obvious problems 19:49 sapier I don't understand for what reason are you using a while loop in there? 19:49 hmmmm ? 19:49 sapier the mystrtok_r function 19:50 hmmmm because that's just how you do it 19:50 hmmmm do you mean the first while loop to skip the tokens? 19:51 hmmmm that's a necessary detail of strtok_r, a token starts with the first non-delimiter character 19:51 hmmmm so if you had ",;" as your delimeter, and you had ,,,,,;,abc, then the only things it should spit out are "abc" and then NULL 19:51 hmmmm it must have this behavior in order to follow the standard 19:51 sapier but you won't skip multiple with new version? 19:52 hmmmm well i skipped multiple with both versions 19:52 hmmmm the behavior in both are exactly the same, only difference is that i simplified the second one 19:52 sapier as far as i understand if you have two delimiters at start in new version you'll get an empty token 19:53 hmmmm no you won't, it skips over both of them, hence the loop 19:54 hmmmm that's the point of the loop 19:54 hmmmm test it and see for yourself 20:31 sapier ok .... I should have looked at full version first ... I didn't even recognize outer while loop until now :-( 20:34 sapier I know you told me ... didn't help :-) 21:52 sfan5 http://forum.minetest.net/viewtopic.php?id=4596 21:53 sfan5 anyone take a look at that