Time Nick Message 00:16 ShadowNinja http://sprunge.us/MNYN?diff This loads player files only when they're needed, it cuts my server's memory usage in half (and should reduce CPU usage a bit). 00:16 ShadowNinja (40MiB -> 20MiB) 00:18 sapier saveAllPlayers really? even not active players? ;-) 00:20 sapier if (newplayer) {<<< newline 00:21 sapier that's true for a lot of other lines in there too 00:21 LemonLake The only problem with allowing multiple contributors is code formatting 00:21 LemonLake It makes the code look like a pile of spices poured on the floor by children 00:21 sapier why don't you follow your own coding style rules? 00:24 VanessaE ShadowNinja: nice 00:24 sapier No it's not a problem if everyone sticks to the rules, as shadow was the one bugging me for months to follow the rules I wont let him add code following the rules too ... and don't even try to change the rules once you're affected shadow ;-P 00:26 VanessaE sapier, ShadowNinja: to be fair, the engine's coding style guidelines aren't exactly written down anywhere... 00:27 sapier they are ShadowNinja kept bugging me for months with those damn "put bracket to newline" ... ;-P 00:27 VanessaE you know what I meant :P 00:36 sapier wow ... I just managed to start my current development version on a 600 MHz single core device with 320x480@3,2" 00:36 VanessaE O_o 00:36 VanessaE did it actually *work*? 00:37 sapier well <1 fps might be an issue 00:40 sapier but I never did manage to see anything but blue screen on that device by now ;-) 00:45 ShadowNinja sapier: No, There isn't supposed to be a newline before brackets. I've been telling you to remove those newlines! 00:45 ShadowNinja I'll change it to saveLoadedPlayers. 00:46 sapier you've bugged me for month to add those newlines 00:46 ShadowNinja sapier: You must have misunderstood me. 00:46 sapier if you now change your mind I want you to write down the very exact guidelines on wiki because I'm really really annoyed about having to change the codings style twice a year 00:47 sapier I don't like wasting hours of time to move around newlines 00:48 ShadowNinja sapier: https://www.kernel.org/doc/Documentation/CodingStyle -- Chapter 3 00:49 ShadowNinja I haven't changed it, you just didn't understand what I was saying. 00:49 ShadowNinja I suggest you read that document, and http://dev.minetest.net/Code_style_guidelines of course. 00:49 sapier grrrrrrrrrrrr 00:51 sapier delete that damn wiki page and define kernel coding style to be the only reference 00:51 sapier >>Use your best judgement for C++-specific syntax.<< basicaly results in "demand what you want to annoy ppl 01:03 sapier "Do not unnecessarily use braces where a single statement will do." lol apple guys must have read that sentence ... with known result 01:28 hmmmm eh 01:28 hmmmm what style to follow depends on which piece of code you're working on 01:29 hmmmm if it's old stuff it's probably better to have it fit in with the rest of that weird "if() \n {" style 01:29 sapier actually it seems to depend on the one checking it's mood 01:29 hmmmm the "irrlicht style" I guess you can call it 01:30 hmmmm the more consistent style on the other hand would be the K&R derivative 01:30 sapier I'm just annoyed because of wasting so much time on changing code style back and forward for any single commit 01:30 hmmmm you don't need to 01:30 sapier unless I want to rebase them in about 2 years I obviously have to 01:31 hmmmm we went over this 500 times.... ShadowNinja stop being such a pendant w.r.t. code style 01:31 hmmmm grrr 01:31 hmmmm I just don't think so much effort should be put into something so trivial 01:31 hmmmm as long as it's understandable and consistent, that's good enough 01:32 sapier I don't have a problem with him being pedantic as long as there's a way to decide how it's supposed to be 01:32 hmmmm I'd prefer for things to match up though, and the majority of the code on the internet (aside from GNU) do something close to K&R 01:32 hmmmm seems to do something close* 01:33 hmmmm a lot of my own code isn't conformant either 01:33 hmmmm i start function bodies with the bracket on the same line as the signature 01:34 hmmmm but i'm not going to go around explicitly changing things unless it needs to be modified at some point 01:38 sapier I try to change it around the lines I change ... but knowing how it's expected to be would be usefull 01:39 hmmmm i'll agree the current "code style guidelines" is just a list of things that pissed me off 01:39 hmmmm and it could be done much better 01:39 hmmmm and more complete 01:40 hmmmm but i'm not doing it because i have so many better things to do in life 01:40 sapier imho for some things it causes more confusion then clarification 01:40 hmmmm what, for example? 01:40 sapier >>Use your best judgement for C++-specific syntax.<< 01:40 hmmmm oh that 01:41 hmmmm well we kinda standardized on some C++ specific syntax, right? 01:41 hmmmm class scope identifiers aren't indented 01:41 hmmmm for loops with very long iterator type declarations go on separate lines 01:42 hmmmm err the type declaration goes on a different line* 01:42 sapier yes that seems to match code (at least for those locations I checked) 01:43 hmmmm do initializer lists the way they are everywhere else 01:43 sapier meaning indention 1 01:43 hmmmm that is, like Foobar() : \n\tfoo(blah),\n\tbar(53),\n\tbaz("asdfg")\n{ 01:44 sapier btw original code seems to have "public:" indented 1 level 01:44 hmmmm hmmm 01:44 hmmmm we don't want that though do we 01:44 hmmmm because it's the same sort of lexeme as a goto statement and we certainly don't indent things after a goto 01:44 hmmmm so I guess that's a change for the better 01:45 sapier for me it's fine both ways 01:45 hmmmm more indendation isn't necessarily better anyway 01:45 hmmmm I used to double indent switch statements but it always seemed inconsistent and the linux kernel code doesn't do that either 01:46 sapier old code did have { on same line as class guess that's why it had to be indented 01:47 hmmmm well as we're discussing this, point out any guidelines you don't think are correct 01:47 hmmmm class definition order is always public, protected, private 01:47 hmmmm but visibility keywords aren't very often used to begin with 01:48 hmmmm i always thought visibility restriction was just a way to annoy people when a certain abstraction turns out to be inefficient 01:48 sapier "Don't use initializer lists unless absolutely necessary" I don't think thats a reasonable suggestion for c++ code 01:48 hmmmm why not 01:48 hmmmm the only real benefit they have is static initialization of subclasses 01:49 sapier yes and compiler is able to check for order of initialization if you use them 01:49 hmmmm order of initialization shouldn't be important though 01:50 hmmmm if it is, don't you think it's something that should be done explicitly rather than implicitly? 01:50 hmmmm that's a big problem I have with C++, is that implicit ways of doing things are preferred 01:50 hmmmm hidden is bad 01:51 sapier it's not hidden in a initializer list 01:51 sapier it's just the way meant to be done in c++ 01:51 sapier thus you're able to use all those mechanisms modern compilers and check tools provide to verify it's correct 01:52 hmmmm static analyzers should be able to pick up on the same things though 01:52 hmmmm if they are functionally identical 01:53 sapier and the last thing g_ and m_ prefixes ... ok globals should be avoided anyway so it's not really relevant, but imho prefixing member variables with m_ makes code way more readable 01:53 hmmmm by initializer lists being implicit, I mean it's not part of the function body saying "here these are the actions being performed upon execution" 01:53 hmmmm yeah but 01:53 hmmmm where do you draw the line 01:54 sapier of course the one writing it knows which variables are members and which aren't, but if you just read code it's quite hard to see 01:54 hmmmm like v3f, those members don't have m_ 01:54 hmmmm structs are classes 01:55 hmmmm i think it can be hard to tell when something stops becoming a data storage structure and rather a logical grouping of functions 01:55 hmmmm which could lead to inconsistency 01:55 sapier I usually use m_ notations for classes having a "longer" livetime 01:56 sapier if a object is usually temporary only I don't need to know if it's a member or not 01:56 hmmmm my justification for m_ not being necessary is that you're usually looking at code inside of a function body 01:56 hmmmm if the function body doesn't contain any locals by that name, then it has to be a member 01:56 hmmmm but the problem is 01:56 hmmmm that only works if functions are managable in size 01:56 sapier think about functions in game or guiFormspecMenu ... there are functions bigger then a single screen 01:57 hmmmm minetest has way too many 2000 line functions going on 01:57 hmmmm alright 01:57 hmmmm so then that settles it, m_ should be used for members that have a longer lifetime...? 01:57 sapier I just had this case where I didn't know if "imagesize" is a local variable or a member stored ;-) 01:57 hmmmm doesn't your IDE show you where it's declared 01:58 sapier of course ... go to declaration ... different file, completely out of scope ;-) 01:59 sapier it's not about that information not beeing present, but just not being obvious 01:59 hmmmm yea 01:59 hmmmm I guess what I don't like about it is that what would that mean the mapgen code would look like 01:59 hmmmm all weird 01:59 hmmmm :/ 02:00 hmmmm prefixing m_ to all the noise buffers 02:00 sapier maybe something like use m_ for complex persistend classes and without m_ for small usually temporary classes/structs 02:00 hmmmm you know, about noise buffers 02:01 sapier no where to look for them? 02:01 hmmmm I have been wondering if preallocating and keeping these huge chunks of memory alive forever is a good idea 02:01 hmmmm maybe it's cheaper to keep allocating things every time i want to use them instead of trashing the cache 02:01 sapier maybe we should just remove that g_ m_ suggestion and don't suggest anything at all ;-) 02:01 hmmmm yeah that's a good idea 02:01 hmmmm let's remove that suggestion 02:02 hmmmm so initializer lists, I don't like them because they're too C++y 02:02 hmmmm so *I* discourage them 02:03 hmmmm but there are reasons to use them 02:03 sapier as we already have the rule to follow the existing conventions anyone adding a new parameter to a m_ class should add m_ members too while adding to non m_ classes should be done without m_ too 02:03 hmmmm can't you argue the same for using enums instead of #defines though 02:03 hmmmm yeah agreed with that 02:03 sapier well I usually use enums instead of defines 02:03 hmmmm that's the rule above all 02:04 hmmmm be consistent 02:04 sapier because enums provide type checking while defines don't 02:04 hmmmm I don't like enums instead of defines because now it's "type safe" and passing the values around in a generic int type cause type punning warnings 02:05 sapier that type checking is about avoiding mistakes ;-) of course if you're very carefull you don't need it ... but I am not carefull enough to rely on this for myself 02:06 hmmmm yea, I can see the theoretical benefits of very strong typing but at the same time it turns out to be more of a nuisance in practice 02:07 sapier yes if rules are checked you have to follow the rules that's the result 02:07 hmmmm how could you possibly screw up so bad that you'll store an unrelated constant in some variable 02:07 sapier but I don't think we need a rule for enums 02:07 hmmmm i can't acutally come up with a single case where that's helped 02:07 sapier there are good reasons for both 02:08 sapier switch case checking 02:08 hmmmm this is something like the yoda comparisons 02:08 ShadowNinja hmmmm: I disagree with the struct double-indenting. You've changed your mind too? 02:08 sapier if you provide a enum and do a switch case compiler will tell you about missing cases 02:08 hmmmm if (5 == bar) { <--- theoretically beneficial, but strange and never actually helped anybody in real life 02:08 hmmmm ShadowNinja, I don't like double indenting structs now because it takes up too much space 02:09 hmmmm linux kernel style has it right 02:09 hmmmm me double indenting structs is just an old habit of mine 02:09 hmmmm sapier: yeah, which is annoying ;) 02:09 hmmmm a lot of times you don't want to handle all of the cases 02:10 sapier sometimes it's helpfull too 02:10 sapier especially for switch cases where default is something like assert ;-) 02:11 ShadowNinja Enums are good, not only because of type checking but because they contain a logical choice of values. And they auto-increment. 02:11 sapier I think we shouldn't add a rule about enums to coding style rules 02:11 hmmmm you can logically group together numerical constants without enums 02:12 hmmmm the only benefit they have is the typing and that can be annoying 02:12 hmmmm along with the compiler warnings 02:12 hmmmm it's all about avoiding annoyances where C++ thinks it's helping but it's not 02:13 sapier that's your personal opinion hmmmm ;-) 02:13 hmmmm C++ is overzealous with typing, i believe, to the point where it drives people insane 02:13 sapier you know all those languages who thought they could live without explicite typing are about to add it recently? ;-) 02:14 hmmmm that's way different 02:14 hmmmm C typing I think is optimal 02:14 hmmmm (i mean that level of type-safety, not the type system itself) 02:15 sapier in c everyone used void* pointers to pass data ... that's not type-safety at all ;-) 02:15 hmmmm you can't set a void pointer to a non-pointer value 02:15 hmmmm aside from NULL 02:15 hmmmm but whatever 02:16 sapier but I haven't run into the enum/define issue by now so I don't think we need a rule ... :-) 02:16 sapier actually you can't set a void pointer to function pointer too ... yet most time it works 02:16 hmmmm people who use void * to pass data are asking for a problem because it would definitely cause a justified compiler warning and could potentially result in an overflow if it so happens that the type is greater than the maximum address type on that machine 02:17 hmmmm doesn't POSIX say something about that 02:17 hmmmm the C standard is that void * shall be large enough to store an address to any data type 02:17 sapier don't know but within c standard function and data pointers are different data types 02:18 hmmmm i believe, not certain though, that POSIX says function pointers can be stored in void pointers 02:18 sapier possible 02:18 hmmmm relying on posix I think is okay 02:18 sapier I'd not be sure about that 02:18 hmmmm it's very difficult to write posix-free code 02:19 sapier e.g. for some 32/64 bit mixed mode architectures data and function pointers really have different size 02:19 hmmmm especially when your code has to do semi-complex things 02:19 hmmmm regardless 02:19 hmmmm I don't know of a situation where anybody would mix and match function and data pointers 02:20 sapier didn't linux add something like that last year? function pointers 32bit and data pointers 64bit? 02:20 hmmmm i haven't heard of it 02:20 hmmmm it's sure possible though.. 02:23 sapier ew X32 ABI: 64-bit mode with 32-bit pointers 02:23 sapier that one 02:24 sapier hmm not exactly it's just using 64bit registers 02:25 sapier but 32bit pointers for everything 02:25 ShadowNinja Minetest data pointers for functions, but only because lua_pushlightuserdata takes a void* and LuaJIT_setmode(LUAJIT_MODE_WRAPCFUNC) uses it as a function. 02:26 sapier yes it's not an issue 02:26 sapier unless we default to luajit ;-) 02:27 hmmmm it could be an issue of truncation if a function pointer happens to be bigger than a data pointer 02:28 ShadowNinja Could a function pointer point to a completely different memory area that shares addresses with the regular memory area? 02:29 hmmmm huh? all von neumann architectures do that 02:30 sapier nx flag could cause issues ... but not sure about it as it's a pointer only and not the actual code 02:33 sapier But something completely different, I intend to merge #1200, #1332, #1302 and #1304 soon so please check and add additional comments if there's something not already mentioned 02:33 ShadowBot https://github.com/minetest/minetest/issues/1200 -- Add support for exiting formspecs by doubleclicking outside by sapier 02:33 ShadowBot https://github.com/minetest/minetest/issues/1332 -- Small cleanup of hud add/remove code by sapier 02:34 ShadowBot https://github.com/minetest/minetest/issues/1302 -- Add daemon support for linux like operating systems by sapier 02:34 ShadowBot https://github.com/minetest/minetest/issues/1304 -- Fix inventory items blinking on item preloading by sapier 02:34 sapier and now I need to get some sleep good night ;-) 10:42 celeron55 what is this supposed to mean? "quand tu peut joué a minetest avec moi" 10:42 celeron55 i guess it's something completely useless but i can't be sure because google translate can't make any sense out of it 10:49 VanessaE joué I take as a UTF-8 encoding mismatch, looks like google is trying to translate it as "On what day can I meet you to play Minetest" 10:50 VanessaE (strange question, either way) 10:53 VanessaE yeah, that should be Joué --> "When you can have minetest Played with me" 12:03 * Megaf should read teh backlog where sapier and hmmm are saying things about Linux Kernel 16:09 sapier #1343 extends fstk to be usable for in game menus too 16:09 ShadowBot https://github.com/minetest/minetest/issues/1343 -- Add support for using fstk for in game menus by sapier 16:13 Megaf sapier; !! You messed up with the linking again!? 16:13 Megaf http://paste.debian.net/102590/ 16:13 sapier I didn't change linking 16:14 sapier actually I haven't merged anything for a few days ;-) 16:15 Megaf So who messed up that? 16:16 Megaf $ git pull 16:16 Megaf Already up-to-date. 16:16 sapier those error message point at some sort of data corruption 16:17 sapier e.g. broken temporary files (did you do a make clean yet?) 16:18 sapier broken ram or broken flash (I guess you're on a flash device as usual) are other possible reasons ... or just out of memory due to make -j X 17:33 LemonLake hi every buddy 17:34 LemonLake I posted #1345 if you wanna check it out 17:34 ShadowBot https://github.com/minetest/minetest/issues/1345 -- Lua feature to hide player nametags 17:35 Calinou that's an issue, not a PR 17:35 Calinou not many people will care ;) 17:35 Calinou variables are other_player_name, not otherPlayerName 17:36 LemonLake sfan5 told me to post it 17:36 Calinou (convention in Lua and C++) 17:36 sapier hmm could be quite a lot of changes for a feature that less important 17:36 LemonLake it doesn't matter, it was just an example 17:36 Calinou (for Minetest, especially) 17:36 Calinou yeah 17:36 LemonLake sapier, how would it be a lot of changes? 17:36 Calinou I would like nametag hiding, so that you can also make the player skin transparent = invisible player (can be used by admins) 17:36 LemonLake ^ 17:36 Calinou could also have “spectator” feature: attach invisible player to another player 17:37 Calinou so, I'm all for it 17:37 LemonLake Cal, can you comment on that? 17:37 LemonLake :D 17:37 sapier nametags are shown on client thus server has to tell clients what to hide and what not 17:37 LemonLake It does the same with hud though so I don't see it being the biggest deal 17:37 sapier hud is active player only 17:38 sapier while that flag would be bound to generic entities 17:38 sapier almost generic entities 17:38 Calinou commented 17:38 Calinou (may not be very useful though) 17:38 LemonLake thanks 17:38 Calinou “Additionally, allow name tag colour changing (RGBA).” 17:39 Calinou eg. per-privilege colouring of nametags 17:39 LemonLake Actually, yeah 17:39 sapier not sure how much of work would be necessary but feels like more than obviously visible 17:39 LemonLake I like the sound of RGBA 17:39 Calinou This could allow stuff like colouring name tags based on privileges, or darkening the name tags of dead players. 17:39 LemonLake sapier, it shouldn't be too too much 17:39 sapier ok I'm waiting for someone to implement it ;-) 17:39 LemonLake :D 17:41 BrandonReese I would be happy if player name tags didn't show through opaque objects 17:41 LemonLake That would require a lot of calculation 17:43 BrandonReese The name tag would probably have to be made an entity or something 17:43 LemonLake eww 17:43 sapier entities are only loaded within very short range around player 17:44 LemonLake ^ 17:44 LemonLake Except players 17:44 LemonLake they're always loaded 17:47 RealBadAngel hi sapier 17:47 LemonLake RealBadAngel: Opinion on #1345? 17:47 RealBadAngel ive tried x86 build, and it is behaving a bit weird 17:47 ShadowBot https://github.com/minetest/minetest/issues/1345 -- Lua feature to hide player nametags 17:48 RealBadAngel sapier, day/night cycle is broken, changes are almost instant and it flickers like hell 17:49 Calinou BrandonReese, by default, they should, else it makes collaboration a pain ;) 17:50 RealBadAngel LemonLake, could be useful for specific games, yes 17:50 RealBadAngel and i agree with Calinou on additions 17:50 BrandonReese It should be an option like unlimited transfer distance 17:51 LemonLake RealBadAngel: Would you know anyone who would actually add it? 17:51 RealBadAngel sapier, and it happens in both singleplayer and on server (like Vanessa's) 17:52 RealBadAngel LemonLake, propably most of us (devs). question is who's table is empty atm ;) 17:53 LemonLake If you could pass it on to some other devs (because it's an issue so most people wouldn't see it) I would be so grateful 17:53 RealBadAngel i do have several ongoin projects, so i wont start again for sure 17:54 BrandonReese LemonLake if player_unlimited_transfer_distance is false, players also disapear like other entities base don active_object_send_range_blocks 17:54 LemonLake So either a nametag RGBA thing, settable for different players like I said (only certian players can see it for e.g.) 17:54 LemonLake I know, BrandonReese 17:54 LemonLake That's why I don't use it 17:54 RealBadAngel hell, this reminds me one thing 17:54 RealBadAngel such a change will need lotsa settings 17:54 RealBadAngel tables with visibility from one to another 17:55 LemonLake True# 17:55 RealBadAngel which means: WE DO NEED LUA API FOR STORING MODS DATA! 17:55 LemonLake ^^^ 17:55 LemonLake Yes! 17:55 LemonLake You should comment that on the post 17:55 RealBadAngel basic things first 17:59 sapier RealBadAngel: any idea what's reason for it? 18:09 RealBadAngel sapier, not yet 18:10 RealBadAngel i was just testing it before i left to work, no diggin in the code at all 18:10 RealBadAngel also another problem 18:11 RealBadAngel "theres same application already installled but with another sign" 18:11 RealBadAngel or something like that 18:11 sapier yes debug/release 18:11 sapier just uninstall the old version 18:11 RealBadAngel thats the point 18:11 RealBadAngel one should be able to update just 18:12 sapier you will be able to update once it's signed with a real key 18:12 RealBadAngel ah ok 18:13 sapier well it's a real key right now too but debug/release versions are signed with different keys by definition 18:13 RealBadAngel last version i tried wasnt flashing 18:14 sapier "flashing" as of ? 18:14 RealBadAngel in this sun/moon is is changing in like 1s cycle 18:14 RealBadAngel so lighting goes nuts 18:14 sapier isn't there some ancient bug telling a similar thing? 18:14 sapier are we talking about master or android port right now? 18:15 Megaf sapier: Linking CXX executable ../bin/minetestserver 18:15 Megaf [100%] Built target minetestserver 18:15 RealBadAngel i tried your x86 build, on android-x86 kitkat 18:15 Megaf real 76m31.243s 18:15 Megaf worked now 18:15 sapier ah :-) wow it did start? 18:15 LemonLake Megaf: Welcome to using a raspberry pi 18:15 Megaf sorry? 18:15 sapier more then an hour? wow :) 18:16 sapier you're really patient megaf 18:16 RealBadAngel or a masochist ;) 18:17 sapier RealBadAngel: maybe we'll be able to find that ancient bug on android x86 instead of the original location ;-) 18:17 Megaf sapier: nah, I just do a make, then I start cooking the lunch, then we eat lunch, then I bring my love to work, then I come home, then I go to work, then I work and then it's compiled! 18:17 Megaf to her job* 18:18 Megaf So I don't have to wait :P 18:20 ShadowNinja sapier: You leak functions into the global environment in fstk. 18:21 sapier you're not talking about the interface functions supposed to be global are you? ;-) 18:21 ShadowNinja sapier: And it seems like fstk should be an implementation detail, at least until formspecs are redone. 18:21 ShadowNinja sapier: They should be in core. 18:22 sapier it's a library not core 18:22 ShadowNinja Nothing other than generic utility functions that aren't specific to Minetest should be global. 18:23 sapier a little bit late to notice 18:25 ShadowNinja Little else is global. 18:25 ShadowNinja Builtin did leak a bit last I checked though. 18:25 LemonLake ShadowNinja, is your todo list busy? 18:29 kaeza speaking of that, /me should rebase #1324 18:29 ShadowBot https://github.com/minetest/minetest/issues/1324 -- Sort commands and privs alphabetically in `/help. by kaeza 18:29 kaeza err... not that one 18:29 kaeza this one https://github.com/minetest/minetest/pull/1341 18:30 ShadowNinja LemonLake: Yes. Why? 18:30 LemonLake Dang 18:30 LemonLake #1345 18:30 ShadowBot https://github.com/minetest/minetest/issues/1345 -- Lua feature to hide player nametags 18:31 sapier no need to mention once an hour ;-P 18:31 LemonLake Sorry, just trying to spread the word 18:31 LemonLake Normally it'd be just ignored 18:33 RealBadAngel hi nore 18:33 Krock sapier, is the ~15s long lag while saving the map a feature? 18:33 nore hi 18:33 Krock hi nore 18:33 RealBadAngel nore, ive included mg in technic_game 2.0 18:33 RealBadAngel but.... 18:33 sapier don't know but could be players instead of map Krock 18:33 RealBadAngel where the fuck are moretrees? :) 18:34 Krock sapier, well that lag only happens all 2-5 minutes, that's within the map save intrval 18:34 RealBadAngel nore, also we do have to talk about microblocks 18:34 sapier ok so not on shutdown 18:35 RealBadAngel i want l-systems trees to use them 18:35 Krock sapier, there it takes a while, too. 18:35 sapier what os, hardware and database backend are you using? 18:35 Krock Windows Vista x64, dual core 1.4GHz CPU, leveldb 18:35 sapier try sqlite backend 18:36 Krock I don't want that level corruption again. so nope. 18:36 Krock s/level/world 18:37 sapier well leveldb keeps a lot of data in memory till it's necessary to be flushed by some time 18:37 Krock sapier, so a higher save interval would solve that? 18:37 sapier sqlite keeps data in sync permanently so it's most likely not affected 18:37 sapier maybe 18:37 ShadowNinja SQLite3 is pretty stable. 18:38 Krock sapier, and I guess there's no work around which wouldn't cause a corruption? 18:38 sapier wonder if you'd run better using sqlite if you reduce save interval for leveldb 18:38 Krock example: new thread 18:38 sapier no 18:38 sapier I wonder why you expect map corruption for what I know sqlite is way more tested then leveldb 18:39 Krock sapier, I posted examples of it multiple times. re-generation of chunks 18:39 sapier I'd expect leveldb to cause more issues then sqlite 18:40 Krock yes sure but it (almost) never will reach a file size limit 18:41 sapier possible ... but if it's freezing each couple of minutes that's not helpfull too ;-) 18:41 LemonLake How can I see the 7 char commit ID on github? 18:41 Krock sapier, well then.. freeze is still better than need to backup every day for the case, it could corrupt somewhen 18:42 sapier ok 18:42 Krock sapier, lemme show you a build which haven't had such problems 18:43 Krock *grabbs link* 18:43 Krock https://forum.minetest.net/viewtopic.php?p=131204#p131204 18:43 RealBadAngel btw, which backend could be capable of storing blobs? 18:44 RealBadAngel leveldb or sqlite? 18:44 Krock sapier, also this one: https://forum.minetest.net/viewtopic.php?p=132682#p132682 18:44 sapier Krock didn't it have the issue or was the map smaller by that time? ;-) 18:45 Krock sapier, can 50 MB cause such a difference? 18:45 Krock *50 MB more/additional/whatever 18:45 sapier sometimes but I don't know about the internals of leveldb 18:47 sapier I don't know of any relevant changes within map backend the last months so we don't even have a hint where to look at 18:48 Krock sapier, crazy idea: could it be possible to split the sqlite file into 10 or 20? 18:48 Krock could it be faster? 18:48 * Krock feels some <.< around 18:48 sfan5 lolwat 18:49 sfan5 there is no way 10 or 20 files will be faster than one 18:49 sapier most likely not but you'd have to ask someone knowing minetests database backend better then me 18:49 Krock sfan5, well, isn't it harder to search something within 100mb than in a 10mb file? 18:50 sfan5 no 18:52 Krock sfan5, that means, sqlite stores the "start reading at" positions at the beginning, so it gets easier than fetch every single row until found 18:52 ShadowNinja RealBadAngel: Both of them are designed to store BLOBs. 18:52 sfan5 fetch every single row until right row found would be very inefficent 18:52 sfan5 I don't think sqlite3 does it like that 18:53 sfan5 otherwise sqlite3 would be very very slow 18:53 Krock sfan5, so it's better than I thought 18:53 Calinou LemonLake, click on commit 18:53 Calinou at the right 18:53 Krock let's hope for a fast migrate and no lags.. 18:54 Krock 18:55 LemonLake Sorry, calinou? 18:56 LemonLake Where did my issue go?? ø.ø 18:57 LemonLake Calinou, what commit? 18:57 Calinou https://github.com/minetest/minetest/issues/1345 18:57 Calinou LemonLake, you asked How can I see the 7 char commit ID on github? 18:57 LemonLake I figured out that the 7 chars is just the shortened SSH 18:58 Calinou TIL: “Our official line length limit is 90 characters” 18:58 Calinou so that'll be the guideline for my mods 18:59 LemonLake My issue isn't on the issues list 18:59 Calinou builtin uses 4-tabs however… 19:00 Calinou https://github.com/minetest/minetest/pull/1341#issuecomment-44471878 19:00 Calinou LemonLake, I see it: https://github.com/minetest/minetest/issues?state=open 19:00 Calinou at the top 19:00 Calinou sort by Recently Updated 19:00 LemonLake What kind of repository was I on ø.ø 19:01 LemonLake Oh i had a label filter (facepalm) 19:02 Calinou https://github.com/minetest/minetest/pull/1328 → does this kill ceiling torches with fire? 19:02 Calinou please keep ceiling torches, if you merge this 19:59 VanessaE don't merge 1328, that's a dead issue imho. 20:06 Calinou he says he's not using Minecraft textures, but I doubt it 20:06 Calinou he already used them in mods 20:08 ShadowNinja #1346 20:08 ShadowBot https://github.com/minetest/minetest/issues/1346 -- Only keep players loaded while theyre connected by ShadowNinja 20:11 CraigyDavi ShadowNinja, so it does not load all player files and store then up as ram as it used to? 20:13 ShadowNinja CraigyDavi: Yep. 20:14 CraigyDavi That's great! Now I don't have to keep deleting player files :) 21:46 ShadowNinja sapier: Trying to find the async bug: valgrind: the 'impossible' happened: 21:46 sapier meaning? 21:47 ShadowNinja VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting 21:47 sapier lol seems someone is really messing up memory 21:47 sfan5 you should try to debug valgrind 21:47 sfan5 if gdb crashes you're out of luck 21:49 ShadowNinja It did dump a bunch of Conditional jump or move depends on uninitialised value(s) warnings though... 21:50 ShadowNinja More than 1000 different errors detected. I'm not reporting any more. Final error counts will be inaccurate. Go fix your program! Haha. 21:50 VanessaE wait, you crashed valgrind itself? O_O 21:52 ShadowNinja Yes, something's broken so badly that valgrind gets killed apparently. 21:52 VanessaE how the... I don't even... 21:53 ShadowNinja Some of the errors are in OpenSSL. 21:54 ShadowNinja A lot of them actually. 21:54 sapier ignore the conditional jumps they're most likely irrelevant 21:58 ShadowNinja http://sprunge.us/ATeD?foo 21:58 ShadowNinja Most of the errors are in OpenSSL or CURL. 21:59 ShadowNinja Lots in JSON-CPP too. 22:09 ShadowNinja The only errors seem to be deep in Lua or unrelated. 22:11 ShadowNinja sapier: Have you poked inspected this crash? Because I still don't have any idea what's causing it, unless it's that Lua's internally broken with threads. 22:13 sapier a single lua instance never may be used from different threads that's crucial but for what I know we follow that rule .. don't we? 22:22 ShadowNinja I believe so... 22:23 ShadowNinja LuaJIT apparently has a non-threadsafe allocator though. 22:29 sapier yes but that's not relevant as long as we work on different lua states 22:32 ShadowNinja Even with different states. 22:32 sapier that'd be new 22:32 sapier malloc is threadsafe 22:32 ShadowNinja LuaLanes protects LuaJIT's allocator because of that. It uses seperate states. 22:34 sapier sorry a little bit more details 22:35 sapier I don't think it's a generic issue as it did work with comparable thread changes 22:35 sapier still others use multiple lua instances from multiple thread too so this is actually a well tested usecase 22:43 sapier I see a lot of graphics memory corruption lately maybe that's related too 22:43 sapier haven't seen that issue for quite some time 22:43 ShadowNinja https://github.com/LuaLanes/lanes/blob/master/src/lanes.c#L1568 22:45 sapier for what I understand that's just relevant if you use a single state from different threads ... our issue is independent from luajit anyway 22:47 ShadowNinja LuaLanes uses a seperate state for each thread. LuaThread is what uses one state, it requires a patched core though. And yes, this isn't the issue, but it could be an issue even if it isn't the current one. 22:49 sapier for luajit maybe but I don't see a way how luajit could mess up it's own memory unless they use global variables internaly ... 23:40 ShadowNinja \o/ I fixed the async crash with some help from sapier. 23:41 LemonLake popping* 23:45 ShadowNinja Comments on #1149? 23:45 ShadowBot https://github.com/minetest/minetest/issues/1149 -- Add AppData file by davidgumberg 23:46 VanessaE yay :) 23:52 ShadowNinja PilzAdam: ^ Does that look good now? 23:53 PilzAdam does the order of matter? 23:58 ShadowNinja PilzAdam: Doesn't seem like it, but I can easily ammend it.