Time  Nick       Message
00:51 sofar      IhrFussel: I've been actually skeptical of the claim that it isn't threadsafe, but I have no data or evidence to support that MT's use of it is thread safe (it could be an MT implementation issue after all)
00:52 paramat    i'll check with nerz, see why he wrote that
00:53 sofar      well, here's the catch
00:53 sofar      setting the sqlite threading mode is done at *compile time* of sqlite
00:54 sofar      in most distro's that means you're using the distribution libsqlite3.so
00:54 sofar      so you might be safe on one distribution, but not another
00:54 sofar      I just checked clearlinux and we don't change the default, so, on clearlinux, sqlite3 should be serialized and thus threadsafe for minetest
00:55 sofar      but, you have to check (every | your own) distro, or compile sqlite3 statically
00:59 sofar      heck you can ask during runtime if sqlite3 was built thread safe with sqlite3_threadsafe()
01:17 paramat    ah hm
01:18 paramat    so MT code should check it
09:14 IhrFussel  sofar, yeah now I realize it depends on the distribution's binary of sqlite ... but not sure why one would choose another mode by default, makes little sense to me
13:06 Sokomine   i still wish mapblocks would store when they where created, when last changed, how many blocks digged and placed by players. that could fascilitate making backups and removing mapchunks exploring players visited once and which just take away disk space
13:41 Fixer      Sokomine: even easier way is don't save mapblock if no changes were made to it
13:49 Sokomine   fixer: hmm. what about mapblocks close to spawn that are never changed? compute them anew all the time? that's no real solution either...
13:50 Fixer      Sokomine: no, it is different, once you change it once, it get saved all the time
13:51 Sokomine   yes. still, even in densely populated areas, there may be many mapblocks that didn't receive a single change. the surface of the world is big
13:52 Sokomine   there's another problem: mapgen works in mapchunks. so if you don't save part of it, it'll all generate anew. which isn't exactly desired if other mapblocks in the chunk contain changed data
13:53 Sokomine   and if your mapgen changes inbetween, you're bound for even more trouble. what you suggest may be a solution for cases where disk space is extremly rare
13:54 Sokomine   if there where a date of creation and last change as a reference, map shrink tools might identify hotspots and keep mapblocks around those hotspots intact, even taking care of how mapgen as such works
13:56 Sokomine   might also be intresting to keep a history of how a server developed. if you have a date as a reference and a database, you can store more than one mapblock with the same coordinates and switch back to previous incarnations if necessary
13:58 Sokomine   just...players digging tunnels in mines and placing the occasional torch, cobble, dirt or whatever to climb up or down is not particulary intresting
17:08 Krock      IhrFussel: u_i is running stable, I guess? I'd like to merge the PR tomorrow; or it would have to wait until next weekend
17:39 IhrFussel  Krock, it didn't cause crashes at least since I updated it and no player complained about something broken
17:46 Krock      nice, thank you :)
18:17 IhrFussel  Krock, it can still cause lags of up to about 1 second...but those are probably just exceptions
18:18 IhrFussel  - on_player_receive_fields[2] .......................  |         1 |   1118034 |       437
18:19 Krock      check out the average value. is it the 437us?
18:25 IhrFussel  Yes but that one also counts when the formspec is just ""
18:26 IhrFussel  So it doesn't only run when the fields match the function
18:26 IhrFussel  I will restart in 15 minutes...will add a custom timer now
18:31 IhrFussel  Krock, which var can I use to get the item crafted? I wanna log it as 'PLAYER crafted '..amount..' '..item..' within...'
18:33 IhrFussel  I mean the itemstring like 'default:bookshelf'
18:35 IhrFussel  Maybe 'output'?
18:35 IhrFussel  local output = unified_inventory.current_item[player_name] or ""
18:35 Krock      craft.output
18:36 Krock      or output, yes.
18:36 Krock      two times the same thing
18:40 IhrFussel  Resrarting now...then we have actual numbers for the funtion running
18:40 IhrFussel  Restarting*
18:40 IhrFussel  function* ... keyboard dying
18:44 IhrFussel  When I take away a few stacks from the craft grid and press the buttons it takes much longer
18:45 IhrFussel  2019-03-03 19:42:46: ACTION[Server]: CRAFT TIMER: IhrFussel crafted 30 default:bookshelf within 3524 µs
18:45 IhrFussel  This is when all my items are in my inventory and I press buttons
18:46 IhrFussel  If I now shift click a few stacks from the craft grid back into my inventory and press the button again
18:46 IhrFussel  2019-03-03 19:44:07: ACTION[Server]: CRAFT TIMER: IhrFussel crafted 30 default:bookshelf within 360646 µs
18:48 IhrFussel  'crafted' is maybe wrong...should be 'moved'
18:50 IhrFussel  Yep... as soon as I take one stack out of the craft grid again and press button the execution time suddenly jumps
18:52 IhrFussel  Will make a video of it
18:55 Calinou    how do I effectively load intllib's S, NS into many files in the most DRY way possible?
18:55 Calinou    https://github.com/minetest-mods/intllib/blob/master/doc/developer.md doesn't explain it, I feel like it should be clarified
18:56 Krock      local S, NS = dofile(MP.."/intllib.lua");  mymodnamespace.S, mymodnamespace.NS = S, NS;  then re-use in the other files
18:56 Calinou    thanks :) that's what I thought
18:57 Calinou    I had tried this:
18:57 Calinou    local S, NS = dofile(modpath .. "/intllib.lua")
18:57 Calinou    moreblocks.intllib = {S, NS}
18:57 Calinou    but that doesn't work as they're considered table values
18:57 Krock      you might want to have a fallback, though
18:57 Krock      well it does, but then you'll use
18:57 Krock      local S = moreblocks.intllib[1]  on top of each file
18:58 IhrFussel  Krock, https://ihrfussels-server.de/craftdemo.mp4
18:59 Calinou    right now, I need this at the top of each file:
18:59 Calinou    local S = moreblocks.S
18:59 Calinou    local NS = moreblocks.NS
18:59 Calinou    so I don't have to use moreblocks.S() all the time, which is quite verbose
18:59 Calinou    (I can remove NS if a file doesn't need it)
19:00 Krock      IhrFussel: 2ms sound about right
19:00 Krock      oh shit
19:00 Krock      why the heck is that happening. Every time?
19:01 IhrFussel  Yes as soon as the code needs to skip over empty craft grid slots
19:01 Krock      did you mean: skip over occupied slots?
19:02 IhrFussel  The 2nd move action in the video shows that I took 1 slot away from the grid which resulted in the high time
19:02 IhrFussel  I guess the more slots I take away the higher the time...let me check
19:03 IhrFussel  YES
19:03 IhrFussel  I reached 416ms with only 1 slot of books left before clicking the 'to craft grid' button
19:04 Krock      https://github.com/minetest-mods/unified_inventory/pull/123/commits/2a729185
19:04 Krock      should be faster with that, as it skips the "groups" check
19:05 Krock      moment
19:05 Krock      amending the commit for further improvement
19:05 Krock      nvm, I thought that I didn't skip empty slots. false alert
19:05 IhrFussel  You really think that's the cause? Cause it clearly only happens when I take away stacks from the craft grid so that there are 'holes' before clicking the button
19:06 Krock      it's weird indeed
19:06 IhrFussel  I will apply your lines and check again
19:07 Calinou    alright, updated intllib support in my mods, thanks :)
19:07 Krock      will be off in ~10 minx
19:07 Krock      np
19:07 Calinou    I'll switch to .po files when I have time
19:07 Calinou    (and use string formatting more liberally)
19:11 IhrFussel  Nope, still same... as soon as I take away 1 slot from the craft grid the time jumps to 100+ ms
19:12 IhrFussel  Even when I only press '10' it's still 90ms
19:12 Krock      weird
19:13 IhrFussel  No engine bug I hope
19:14 IhrFussel  For some reason the mod takes a lot longer to check SOME empty stack slots and fill them vs all slots being empty
19:15 Krock      the amount of time spent must be proportional to the empty slots
19:16 IhrFussel  WAIT...it doesn't happen when either the first or last slot are non-empty
19:16 Krock      ????
19:16 IhrFussel  Making another quick video one sec
19:19 Krock      that's not logical at all
19:19 IhrFussel  https://ihrfussels-server.de/craftdemo2.mp4
19:19 IhrFussel  It's weird...but it seems to depend on the slots I remove
19:21 IhrFussel  The last one was by another player, my time was 3 ms
19:22 IhrFussel  Last line in terminal*
19:23 Krock      will debug further next weekend
19:23 Krock      could be some nasty C++ bug or table reference
21:00 kaeza      Greetings.
21:15 Fixer      kaeza: Hi
21:39 benrob0329 Hello