| Time |
Nick |
Message |
| 00:05 |
|
paramat joined #minetest-hub |
| 00:13 |
|
kaeza joined #minetest-hub |
| 00:37 |
|
Sokomine joined #minetest-hub |
| 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:15 |
|
benrob0329 joined #minetest-hub |
| 01:17 |
paramat |
ah hm |
| 01:18 |
paramat |
so MT code should check it |
| 01:33 |
|
kaeza joined #minetest-hub |
| 01:52 |
|
Miner_48er joined #minetest-hub |
| 03:11 |
|
paramat joined #minetest-hub |
| 04:34 |
|
diemartin joined #minetest-hub |
| 06:52 |
|
GreenDimond joined #minetest-hub |
| 07:44 |
|
Emerald2 joined #minetest-hub |
| 08:26 |
|
CWz joined #minetest-hub |
| 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 |
| 10:21 |
|
_Xenon joined #minetest-hub |
| 10:50 |
|
Fixer joined #minetest-hub |
| 12:33 |
|
calcul0n joined #minetest-hub |
| 12:49 |
|
Unarelith joined #minetest-hub |
| 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:10 |
|
calcul0n joined #minetest-hub |
| 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 |
| 14:25 |
|
aerozoic joined #minetest-hub |
| 14:56 |
|
entuland joined #minetest-hub |
| 15:47 |
|
_Xenon joined #minetest-hub |
| 17:02 |
|
Krock joined #minetest-hub |
| 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:27 |
|
benrob0329 joined #minetest-hub |
| 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:12 |
|
rdococ joined #minetest-hub |
| 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:21 |
|
_Xenon joined #minetest-hub |
| 18:23 |
|
_Xenon joined #minetest-hub |
| 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:39 |
|
_Xenon joined #minetest-hub |
| 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 |
| 19:39 |
|
kaeza joined #minetest-hub |
| 19:51 |
|
GreenDimond joined #minetest-hub |
| 20:22 |
|
garywhite joined #minetest-hub |
| 20:23 |
|
garywhite joined #minetest-hub |
| 20:25 |
|
Unarelith joined #minetest-hub |
| 20:58 |
|
FrostRanger joined #minetest-hub |
| 21:00 |
kaeza |
Greetings. |
| 21:15 |
Fixer |
kaeza: Hi |
| 21:33 |
|
T4im joined #minetest-hub |
| 21:37 |
|
pauloue joined #minetest-hub |
| 21:39 |
benrob0329 |
Hello |
| 21:58 |
|
T4im joined #minetest-hub |
| 22:23 |
|
_Xenon joined #minetest-hub |
