| Time |
Nick |
Message |
| 00:21 |
paramat |
i'll push this trivial fix later game#485 |
| 00:21 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/485 -- Default/mapgen: Fix missing num_spawn_by = 1 line for papyrus by paramat |
| 00:27 |
|
est31 joined #minetest-dev |
| 00:28 |
est31 |
paramat, I think game#485 is small enough to be merged directly. |
| 00:28 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/485 -- Default/mapgen: Fix missing num_spawn_by = 1 line for papyrus by paramat |
| 00:29 |
paramat |
yes i was going to merge it without approval =) |
| 00:30 |
paramat |
the ice PR can wait for the mtg team to see it on sunday |
| 00:35 |
paramat |
now pushing game#485 |
| 00:35 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/485 -- Default/mapgen: Fix missing num_spawn_by = 1 line for papyrus by paramat |
| 00:38 |
paramat |
done |
| 00:54 |
|
paramat left #minetest-dev |
| 01:02 |
|
Wayward_One joined #minetest-dev |
| 01:15 |
|
Taoki joined #minetest-dev |
| 02:04 |
|
roniz joined #minetest-dev |
| 02:17 |
est31 |
Merging in 5 minutes: http://pastie.org/10074257 |
| 02:26 |
hmmmm |
looks good to me |
| 02:27 |
kahrl |
that was more than 5 minutes later :P |
| 02:28 |
est31 |
now its pushed |
| 02:30 |
ShadowNinja |
est31: Don't remove newlines at the ends of files. |
| 02:31 |
ShadowNinja |
Also, should be 115 mins IIRC. |
| 02:31 |
ShadowNinja |
15 rather. |
| 02:31 |
est31 |
ShadowNinja, why? |
| 02:31 |
ShadowNinja |
est31: Because they're supposed to be there. |
| 02:31 |
est31 |
why that? |
| 02:33 |
ShadowNinja |
est31: Lets you can them together, start editing at the end easily, some tools require it. |
| 02:33 |
ShadowNinja |
It could be changed if there are good reasons though. |
| 02:33 |
ShadowNinja |
est31: Have you read all of http://dev.minetest.net/All_rules_regarding_to_development ? |
| 02:33 |
est31 |
ok, noted. |
| 02:35 |
est31 |
ShadowNinja, I think I have read most, but I guess reading it all again is a good idea |
| 02:38 |
|
Miner_48er joined #minetest-dev |
| 02:39 |
kahrl |
huh, why was the "rule 1" stuff removed from http://dev.minetest.net/Git_Guidelines? |
| 02:39 |
hmmmm |
who wrote all this stuff |
| 02:39 |
hmmmm |
i didn't even know those pages existed |
| 02:40 |
est31 |
This isn't done at all: http://dev.minetest.net/Merging_core_pull_requests_to_upstream |
| 02:50 |
|
misprint joined #minetest-dev |
| 03:05 |
est31 |
#2602 looks good except of style issues and it needs to be squashed. they use a map now instead of a vector. What do you think, can I merge it when I squash and fix the style? |
| 03:05 |
ShadowBot |
https://github.com/minetest/minetest/issues/2602 -- move particle spawners to env by obneq |
| 03:05 |
* est31 |
needs a second +1. |
| 03:06 |
hmmmm |
hopefully those are going to get squashed... |
| 03:06 |
|
misprint joined #minetest-dev |
| 03:07 |
hmmmm |
est31, are you sure that pull request is ready? |
| 03:07 |
VanessaE |
est31: wait a bit - jin_xi has more stuff he's doing |
| 03:07 |
hmmmm |
yes, please don't be so ready to merge PRs unless there's been actual discussion |
| 03:08 |
VanessaE |
#2587 in particular |
| 03:08 |
ShadowBot |
https://github.com/minetest/minetest/issues/2587 -- wip irrlicht particles 2 by obneq |
| 03:08 |
est31 |
I have seen that one |
| 03:09 |
est31 |
its only a "move A out of server.cpp" PR, nothing functional |
| 03:09 |
est31 |
(read it in one of those wiki rules that server.cpp has to be shortened.) |
| 03:10 |
est31 |
I'll let jin_xi do it themselves |
| 04:04 |
|
est31 joined #minetest-dev |
| 04:27 |
hmmmm |
agh |
| 04:27 |
hmmmm |
i never tried compiling with leveldb before, but now that I am, I get an error |
| 04:27 |
hmmmm |
precisely because I'm using gcc |
| 04:27 |
hmmmm |
compile with clang, no problem |
| 04:27 |
hmmmm |
but at the same time i have no debugging info |
| 04:39 |
ShadowNinja |
I am now a l33t net pro ;-) #2604 |
| 04:39 |
ShadowBot |
https://github.com/minetest/minetest/issues/2604 -- Add support for multiple listen addesses by ShadowNinja |
| 04:52 |
est31 |
my craft speedup patch #2596 works with deadbeef power |
| 04:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/2596 -- Crafting speedup by est31 |
| 04:52 |
est31 |
did you know that 0xdeadbeef allocates exactly 32 bytes? |
| 04:59 |
ShadowNinja |
est31: Um, you mean (void* (*)(void))(0xdeadbeef)()? (call that address as a function returning a void*). |
| 05:00 |
est31 |
you know, dead beef is so salty, so that I can use it for salting... |
| 05:00 |
ShadowNinja |
est31: Or you mean it's 32 bits because it's a 8-char hex string? |
| 05:02 |
ShadowNinja |
est31: It looks like you're basically just making a custom std::unordered_map. |
| 05:02 |
est31 |
yes that one. 8 characters times 4 bits per character are 32 bit |
| 05:02 |
est31 |
mhh |
| 05:02 |
est31 |
dammit I have 32 bit free space |
| 05:02 |
est31 |
byte |
| 05:02 |
est31 |
we have to live with the zeroes |
| 05:03 |
est31 |
we don't want to use too much salt do we |
| 05:05 |
ShadowNinja |
est31: Why do you need a salt? |
| 05:05 |
est31 |
bc I'm hashing. |
| 05:05 |
est31 |
would live well with 0 too I guess |
| 05:06 |
est31 |
but as the method requires a salt to be passed... |
| 05:06 |
ShadowNinja |
est31: This kind of change should come with a lot of comments, or someone is going to go "why all this complexity?" |
| 05:06 |
est31 |
see commit message |
| 05:07 |
ShadowNinja |
est31: The code should be understandable without reading through the commit history for the commit that added the code. |
| 05:08 |
ShadowNinja |
The commit message should only describe what the commit does, not what the code does. |
| 05:10 |
est31 |
ShadowNinja, I can move paragraphs 2, 3 and 4 into comments somewhere in the code, is that sufficient? |
| 05:11 |
ShadowNinja |
est31: Add comments anywhere that might be confusing. |
| 05:11 |
est31 |
lol |
| 05:11 |
ShadowNinja |
I read the commit message but I still don't understand what it does, except that it apparently involved three hashtables. |
| 05:12 |
ShadowNinja |
Maybe I'm just tired though. |
| 05:12 |
est31 |
you made #2604 thats alot of work |
| 05:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/2604 -- Add support for multiple listen addesses by ShadowNinja |
| 05:12 |
hmmmm |
jesus christ |
| 05:13 |
hmmmm |
well that's not overkill or anything |
| 05:13 |
est31 |
hmmmm, my change or ShadowNinja's? |
| 05:13 |
hmmmm |
yours :p |
| 05:14 |
est31 |
you want to have the server to spend the quarter of a second searching for sth to craft? |
| 05:14 |
hmmmm |
no, but that's a false dichotomy |
| 05:14 |
hmmmm |
you could've gained roughly the same speed increase just using std::map |
| 05:16 |
hmmmm |
i don't quite understand the whole "layers" thing |
| 05:16 |
hmmmm |
ahh I see what you did |
| 05:17 |
est31 |
craft definitions with groups in their grid are a problem otherwise |
| 05:17 |
hmmmm |
hrmm |
| 05:17 |
hmmmm |
what is the hash output size of xxhash? |
| 05:17 |
est31 |
32 bytes |
| 05:17 |
hmmmm |
yikes |
| 05:17 |
est31 |
(u32) |
| 05:17 |
hmmmm |
erm, u32 is 32 bits |
| 05:18 |
hmmmm |
32 bytes would be something like SHA-2 |
| 05:18 |
est31 |
ok |
| 05:18 |
hmmmm |
that's a lot of stuff going on just for 4 bytes of hashing |
| 05:19 |
hmmmm |
unless the collision properties are superior to that of a 64-bit murmur hash, why not just use that one instead? |
| 05:19 |
est31 |
I'm ok with other algs too, just want to have 4 bytes at the end |
| 05:19 |
hmmmm |
1). murmur hash is already there |
| 05:19 |
hmmmm |
2). it has twice as big of a space |
| 05:19 |
hmmmm |
hash space |
| 05:19 |
hmmmm |
3). it doesn't need to be "initialized" |
| 05:19 |
est31 |
? |
| 05:19 |
hmmmm |
but maybe this is better, i need to understand the layers better |
| 05:20 |
est31 |
ah initialisation is still needed |
| 05:20 |
est31 |
its because we allow aliasses to be defined after craft definition |
| 05:20 |
est31 |
otherwise we would need to change even minetest_game |
| 05:21 |
hmmmm |
hmm |
| 05:21 |
hmmmm |
in the header file it actually compares against murmur hash |
| 05:21 |
hmmmm |
this appears to be twice as fast |
| 05:21 |
hmmmm |
key word appears :p |
| 05:21 |
est31 |
or not, because we dont use aliases there in craft definitions, but what I have checked is that the files get loaded in the wrong order |
| 05:21 |
hmmmm |
i'd just prefer to not have unnecessary stuff |
| 05:22 |
hmmmm |
and like this is a whole huge new file |
| 05:23 |
est31 |
murmur seems to be ok too. |
| 05:25 |
est31 |
I'll let it do murmur |
| 05:25 |
hmmmm |
you don't have to change things if this works fine |
| 05:25 |
hmmmm |
the work has already been done |
| 05:26 |
* hmmmm |
scratches head |
| 05:26 |
est31 |
its a single line commit for the usage, and a texteditor u32->u64 replace |
| 05:26 |
hmmmm |
okay, so tell me if this is how it works: |
| 05:26 |
hmmmm |
different *parts* of the CraftDefinition get hashed based on something |
| 05:27 |
hmmmm |
each "level" controls how much of the definition is hashed |
| 05:27 |
hmmmm |
yes or no so far? |
| 05:27 |
|
nore joined #minetest-dev |
| 05:27 |
est31 |
tough descision |
| 05:27 |
est31 |
the deeper the "level" the more the collision rate |
| 05:28 |
est31 |
so yes to that one |
| 05:28 |
est31 |
and yes to the first |
| 05:28 |
hmmmm |
but wait that doesn't make sense |
| 05:28 |
hmmmm |
if you have more data being hashed, wouldn't that lower the collision rate? |
| 05:29 |
hmmmm |
actually nevermind, that's true for things below the hash size |
| 05:29 |
est31 |
for me the highest level is the one thats checked first, the CRAFT_HASH_TYPE_ITEM_NAMES |
| 05:29 |
hmmmm |
how likely is it that there's a collision to begin with? |
| 05:30 |
est31 |
at that layer you can collide if you have two reorderings of the same craft grid |
| 05:30 |
hmmmm |
and so what if there is a collision? shouldn't you have a collision resolution mechanism already? |
| 05:30 |
est31 |
yes |
| 05:30 |
est31 |
there is one |
| 05:30 |
hmmmm |
what is it? |
| 05:30 |
est31 |
the map maps to a vector |
| 05:30 |
est31 |
(from the hash) |
| 05:31 |
hmmmm |
can't you just use a multimap? |
| 05:31 |
* est31 |
googles |
| 05:31 |
hmmmm |
std::multimap |
| 05:31 |
est31 |
is it stable? |
| 05:32 |
hmmmm |
in which sense? |
| 05:32 |
hmmmm |
like a stable sort? |
| 05:32 |
est31 |
yes |
| 05:32 |
hmmmm |
why do things need to be sorted? |
| 05:32 |
est31 |
so when I enter two elements with the same key in a certain order, do I also get them with that order |
| 05:33 |
est31 |
its so that later craft definitions can override earlier ones |
| 05:33 |
est31 |
some mods do that |
| 05:33 |
hmmmm |
the answer is that i don't know |
| 05:33 |
* est31 |
reads doc |
| 05:34 |
hmmmm |
i *would* assume it uses std::sort internally but i have no way of knowing that for sure |
| 05:35 |
est31 |
it seems its not stable http://bytes.com/topic/c/answers/480984-std-multimap-stable |
| 05:35 |
est31 |
by standard |
| 05:35 |
est31 |
but all implementations keep it stable |
| 05:36 |
hmmmm |
ahh |
| 05:36 |
hmmmm |
looks like you should stick with your map/vector implementation then |
| 05:36 |
est31 |
yea |
| 05:39 |
hmmmm |
so the levels are in this order: |
| 05:40 |
hmmmm |
CRAFT_HASH_TYPE_COUNT, CRAFT_HASH_TYPE_ITEM_NAMES, then CRAFT_HASH_TYPE_UNHASHED as the lowest level |
| 05:40 |
hmmmm |
correct? |
| 05:40 |
est31 |
yes |
| 05:40 |
est31 |
no |
| 05:40 |
est31 |
no |
| 05:40 |
est31 |
item names and count flipped |
| 05:40 |
hmmmm |
okay :) |
| 05:40 |
est31 |
like they are defined in the enum |
| 05:41 |
hmmmm |
so a count of the items has more uniqueness than the names of the hash types? |
| 05:41 |
hmmmm |
err, the name of the items |
| 05:41 |
est31 |
no, read above |
| 05:42 |
hmmmm |
yeah my questions still stands |
| 05:42 |
hmmmm |
so why not make the hash just use *both* item names and count? |
| 05:42 |
est31 |
count of the items has less uniqueness agreed |
| 05:43 |
est31 |
the hash already does that internally, by adding the \n occurences into the result |
| 05:43 |
est31 |
but thats not the point |
| 05:43 |
est31 |
the point is that there are craft definitions where names dont help |
| 05:44 |
est31 |
thats all craft defs where you have one element which is group:something |
| 05:44 |
est31 |
then you can't add group:something to the hash |
| 05:44 |
hmmmm |
ahhh |
| 05:44 |
hmmmm |
ahhhhh |
| 05:44 |
est31 |
you dont know to check that on the other side |
| 05:44 |
hmmmm |
i just realized that a craft def lookup is actually sort of complicated |
| 05:44 |
est31 |
you could make a brute force search |
| 05:45 |
est31 |
horribly expensive |
| 05:45 |
hmmmm |
by the way, if you don't specify a = number in an enum, it's 0 by default |
| 05:45 |
hmmmm |
so starting an enum by ELEMENT_NAME_HERE = 0 is redundant |
| 05:45 |
est31 |
nice |
| 05:46 |
hmmmm |
looks good to me |
| 05:46 |
hmmmm |
+1 |
| 05:46 |
hmmmm |
you *could* switch to murmur hash if you'd like |
| 05:46 |
est31 |
yaay |
| 05:46 |
hmmmm |
it's in util/numeric.h |
| 05:46 |
est31 |
will switch to murmur |
| 05:46 |
est31 |
yea found it |
| 05:46 |
est31 |
and will remove the =0 |
| 05:46 |
hmmmm |
yea I added that for alphanumeric seeds |
| 05:47 |
hmmmm |
i'm glad it's being useful somewhere else too |
| 05:48 |
hmmmm |
ugh so it looks like i'm gonna have to disable leveldb for now |
| 05:56 |
|
leat joined #minetest-dev |
| 05:57 |
|
leat joined #minetest-dev |
| 06:22 |
|
Megaf_ joined #minetest-dev |
| 06:25 |
|
Hunterz joined #minetest-dev |
| 06:31 |
hmmmm |
speaking of which I just found a bug with murmur_hash_64_ua() |
| 06:31 |
hmmmm |
I wonder if the memcpy() call was there originally in the code I got it from or did I add that?? |
| 06:37 |
est31 |
github is stupid |
| 06:37 |
est31 |
I've pushed to the branch, but nothing changed |
| 06:38 |
est31 |
https://github.com/minetest/minetest/pull/2596 |
| 06:38 |
est31 |
here an old version of my commit is shown |
| 06:38 |
est31 |
and on my branch, the new version is shown: https://github.com/est31/minetest/tree/craftingspeedup |
| 06:39 |
est31 |
this is the new version https://github.com/est31/minetest/commit/927c33309b06d0c1c96e87efc04eadfd055c0cc2 |
| 06:39 |
est31 |
the old version still has the xxhash thingy |
| 06:41 |
est31 |
ShadowNinja, can you confirm that there are enough comments now? |
| 06:52 |
|
leat joined #minetest-dev |
| 07:03 |
|
leat joined #minetest-dev |
| 07:07 |
|
selat joined #minetest-dev |
| 07:11 |
est31 |
ShadowNinja is asleep as it seems |
| 07:14 |
est31 |
I have however made the code document |
| 07:15 |
est31 |
added some hints here and there |
| 07:18 |
est31 |
idk should I wait for him? |
| 07:23 |
est31 |
I think I'll merge, as I mostly did what he requested. |
| 07:23 |
est31 |
pushing #2596 now |
| 07:23 |
ShadowBot |
https://github.com/minetest/minetest/issues/2596 -- Crafting speedup by est31 |
| 07:41 |
|
jin_xi joined #minetest-dev |
| 07:46 |
|
leat joined #minetest-dev |
| 07:59 |
|
Krock joined #minetest-dev |
| 08:08 |
|
kilbith joined #minetest-dev |
| 08:13 |
|
err404 joined #minetest-dev |
| 08:47 |
|
OldCoder joined #minetest-dev |
| 09:07 |
|
leat joined #minetest-dev |
| 09:15 |
|
nrzkt joined #minetest-dev |
| 09:17 |
nrzkt |
hi, i pushed two changes: some uninitialized variabled into ConnectionEvent and also return 0 after assert in est31 craftdef code to make clang happy |
| 09:58 |
|
leat joined #minetest-dev |
| 10:14 |
|
cib0 joined #minetest-dev |
| 10:26 |
|
leat joined #minetest-dev |
| 10:30 |
|
leat joined #minetest-dev |
| 10:36 |
|
lordfingle joined #minetest-dev |
| 10:37 |
lordfingle |
hello |
| 10:56 |
kilbith |
[Alert] nrzkt, 8804c47e still cause a crash near the signs_lib : http://pastie.org/10074694 |
| 10:57 |
kilbith |
it was fine before that commit |
| 10:57 |
kilbith |
https://github.com/minetest/minetest/commit/8804c47e59b550ec9a533de662f086af623d68c1 |
| 10:59 |
nrzkt |
ugh. wtf we only catch an error without doing nothing else |
| 10:59 |
nrzkt |
i think the problem was never solved in fact |
| 11:00 |
kilbith |
it was fine before that commit (bis) |
| 11:00 |
kilbith |
ie. no crash |
| 11:00 |
nrzkt |
this commit does nothing |
| 11:00 |
kilbith |
i have crashes with it, none before |
| 11:02 |
nrzkt |
please retest without the commit it's impossible. This commit only add a catch for packet error on client side to catch PacketError when the packet is unreliable |
| 11:02 |
nrzkt |
then the crash was also present before |
| 11:03 |
kilbith |
factually, it is |
| 11:03 |
kilbith |
i'm not talking about theory man |
| 11:03 |
nrzkt |
also, please note the catching error is not in this function but in processActiveObjectMessage |
| 11:03 |
|
selat joined #minetest-dev |
| 11:03 |
nrzkt |
and processActiveObjectMessage hasn't changed. Then the problem was here before. |
| 11:04 |
|
leat joined #minetest-dev |
| 11:18 |
|
leat joined #minetest-dev |
| 11:22 |
|
ElectronLibre joined #minetest-dev |
| 11:38 |
|
nrzkt joined #minetest-dev |
| 12:40 |
|
roniz joined #minetest-dev |
| 13:04 |
|
chchjesus joined #minetest-dev |
| 13:28 |
|
SopaXorzTaker joined #minetest-dev |
| 13:46 |
|
cib0 joined #minetest-dev |
| 13:46 |
|
est31 joined #minetest-dev |
| 14:18 |
|
hmmmm joined #minetest-dev |
| 14:37 |
est31 |
breaking the network with git versions of minetest that are newer than the latest release *is* allowed, isnt it? |
| 14:38 |
est31 |
because I don't like to avoid breaking it when I want to change sth the protocol changed |
| 14:38 |
est31 |
e.g. master has a new packet |
| 14:38 |
est31 |
and I want to remove a flag |
| 14:38 |
est31 |
from that packet |
| 14:38 |
est31 |
then I dont want to make a new protocol version just because |
| 14:39 |
est31 |
of course, compat with releases needs to be maintained |
| 14:40 |
est31 |
hmmmm, ^ |
| 14:40 |
hmmmm |
man i'm trying to get minetest to compile |
| 14:40 |
hmmmm |
and you're over there talking about protocol changes |
| 14:43 |
est31 |
I just asked because nrzkt seemed to have other things in mind in a comment on a PR (not related to my example). |
| 14:43 |
est31 |
and I had plans to change packets that were introduced in protocol version 25. |
| 14:45 |
est31 |
to not make it overly complicated (having legacy logic for protocol versions that only clients/servers have that use a custom source build of un-released (as in release) minetest) |
| 14:45 |
hmmmm |
if there are protocol changes within a version we try to coordinate and batch them all together |
| 14:45 |
est31 |
ok |
| 14:46 |
est31 |
I'm not sure what nrzkts auth plans are, my ideas require those packet changes. |
| 14:47 |
est31 |
thanks for answering, I'm off now. the PR I mentioned was 2592 btw |
| 14:47 |
hmmmm |
okay. |
| 14:47 |
hmmmm |
pfth |
| 14:48 |
hmmmm |
looks like I got a minimal test case for my issue |
| 15:24 |
|
SopaXorzTaker joined #minetest-dev |
| 15:45 |
|
leat joined #minetest-dev |
| 15:58 |
|
leat joined #minetest-dev |
| 16:07 |
|
MinetestForFun joined #minetest-dev |
| 16:21 |
Megaf_ |
Man, I never get nrzkt online |
| 16:54 |
|
cib0 joined #minetest-dev |
| 17:06 |
|
MinetestForFun joined #minetest-dev |
| 18:16 |
|
jin_xi joined #minetest-dev |
| 18:18 |
|
rubenwardy joined #minetest-dev |
| 18:29 |
|
paramat joined #minetest-dev |
| 18:32 |
paramat |
nore, sfan5, please could you review/approve game#484 ? Since PilzAdam's comment i have added more screenshots showing why icesheet caves are so messy |
| 18:32 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/484 -- Default/nodes: Make ice not ground content by paramat |
| 18:50 |
|
Calinou joined #minetest-dev |
| 19:07 |
|
MinetestForFun joined #minetest-dev |
| 19:07 |
|
MinetestForFun joined #minetest-dev |
| 19:27 |
|
fz72 joined #minetest-dev |
| 19:36 |
|
err404 joined #minetest-dev |
| 20:42 |
|
ud1_ joined #minetest-dev |
| 20:44 |
|
Taoki joined #minetest-dev |
| 20:59 |
hmmmm |
do you guys think the currently executing mod name should be available after initialization? |
| 21:22 |
|
Jordach joined #minetest-dev |
| 21:38 |
paramat |
erm, can't think of a use for that at the moment |
| 21:39 |
|
ElectronLibre left #minetest-dev |
| 21:45 |
paramat |
because this is more of a mapgen issue i will probably go ahead and push game#484 soon, seems obvious to me there should not be caves in icesheet. highlighting hmmmm and sfan5 |
| 21:45 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/484 -- Default/nodes: Make ice not ground content by paramat |
| 21:47 |
sfan5 |
paramat: seems ok |
| 21:51 |
paramat |
thanks, alternatively i could edit mgv6 caves to check for ice, this may be better i will think on it |
| 21:54 |
|
est31 joined #minetest-dev |
| 21:54 |
hmmmm |
paramat +2 |
| 21:54 |
paramat |
thanks |
| 21:54 |
est31 |
hmmmm, this isn't possible: http://irc.minetest.ru/minetest-dev/2015-04-05#i_4214025 |
| 21:55 |
est31 |
we have a common lua context after loading |
| 21:55 |
est31 |
it is possible to e.g. use the stack, but that isn't nice either, imagine library mods. |
| 21:55 |
hmmmm |
mods register callbacks on loading |
| 21:55 |
est31 |
? |
| 21:56 |
hmmmm |
so you just register the name of the mod associated with the callback |
| 21:56 |
hmmmm |
then every time it's called, set the context |
| 21:57 |
est31 |
if we do it that way, the fact whether we register something for that special mod should be settable by flag |
| 21:57 |
est31 |
but mh |
| 21:58 |
est31 |
your solution works without that flag too |
| 21:58 |
hmmmm |
the mod api is basically a miniature OS with cooperative multitasking |
| 21:59 |
hmmmm |
setting the context before making a callback is akin to setting segment descriptors to point to the correct processes' PEB before handing over execution |
| 22:01 |
est31 |
!g PEB process operating system |
| 22:01 |
ShadowBot |
est31: https://msdn.microsoft.com/en-us/library/windows/desktop/aa813706(v=vs.85).aspx | Indicates whether the specified process is currently being debugged. The PEB structure, however, is an internal operating-system structure whose layout may ... |
| 22:01 |
paramat |
ah.. v5/v7 cavegen already check for ice (as well as checking 'is ground content') and don't remove it. v6 cavegen doesn't check for 'is ground content' or for ice, i will update it. so the simplest fastest solution is making ice not ground content .. will do this |
| 22:01 |
est31 |
yeah |
| 22:01 |
est31 |
(to hmmmm) |
| 22:02 |
hmmmm |
that being said |
| 22:02 |
hmmmm |
it would be very nice if we had more advanced scheduling constructs for modding |
| 22:02 |
est31 |
is luajit multithreadable? |
| 22:03 |
paramat |
(..perhaps better and simpler i can also make water and lava not ground content) |
| 22:03 |
hmmmm |
multithreading is absolutely useless because of the scope of the locks held |
| 22:04 |
hmmmm |
what would be nice is if mods could be pre-empted however |
| 22:04 |
est31 |
yes |
| 22:04 |
est31 |
then they dont cause lags |
| 22:05 |
est31 |
or still do, but dont stop the whole server |
| 22:06 |
paramat |
(..this will reduce checks for more speed, will do) |
| 22:06 |
est31 |
problem is however: data can change |
| 22:07 |
hmmmm |
yeah |
| 22:07 |
hmmmm |
the solution to this would be to take a snapshot of the map or whatever it is at that point in time it's being called |
| 22:07 |
hmmmm |
and each time the thread is resumed, it'd read the map out of that snapshot |
| 22:07 |
hmmmm |
the problem is that old mods wouldn't be able to do this... |
| 22:08 |
hmmmm |
so it'd break compatibility? |
| 22:08 |
est31 |
even if, how do you feed back the changes? |
| 22:08 |
hmmmm |
you have a transaction list |
| 22:08 |
est31 |
this still would require certain locks |
| 22:08 |
hmmmm |
yeah there's locking any way you look at it, but this modifies the scope of locks |
| 22:09 |
est31 |
yea |
| 22:09 |
est31 |
umm no |
| 22:09 |
est31 |
your idea is to dynamically cache something, but that can end up bad |
| 22:09 |
hmmmm |
how so? |
| 22:09 |
hmmmm |
explain. |
| 22:11 |
est31 |
what is when mod A does something on place X and adds them to the transaction log. then player B comes, modifies sth on place X and then mod C sees what A has done and adds something else to the transacion log too, overriding the players modifications. |
| 22:12 |
hmmmm |
if another mod attempts to read a MapBlock that has a pending write transaction it should take the most recent version |
| 22:13 |
hmmmm |
so it's like this: |
| 22:13 |
est31 |
also, if we have this model implemented, nothing stops us from multithreading, does it? |
| 22:13 |
hmmmm |
mod A expresses its intent to read an area of nodes from (4, 3, 10) to (20, 19, 26) |
| 22:14 |
hmmmm |
so it atomically sets a little flag on each of them that means they're currently being read |
| 22:15 |
hmmmm |
then if another mod comes around to write on any one of those, it notices the flag and it instead adds a pending transaction to that |
| 22:15 |
hmmmm |
this is kind of like the idea behind RCU |
| 22:16 |
est31 |
you basically want to implement area-based locking? |
| 22:16 |
hmmmm |
it's not area-based locking because there are never any waiters |
| 22:17 |
hmmmm |
the only time a lock does happen, it's to do something with the transaction list, which is very well defined and bounded |
| 22:17 |
hmmmm |
so we know the lock operation will take at the very most, say, 1 ms |
| 22:17 |
hmmmm |
and yes, this would allow for multithreading |
| 22:19 |
hmmmm |
but let's think about the broader problem than ways to efficiently lock the map structure |
| 22:19 |
hmmmm |
what is it we're actually trying to accomplish? |
| 22:19 |
est31 |
when both mod A and B add transactions, mod A places dirt, mod B places stone. |
| 22:19 |
hmmmm |
access to the environment needs to be synchronized because __________________________________ ? |
| 22:20 |
est31 |
mod A starts from (3,0,0), B starts from (0,0,0) |
| 22:20 |
est31 |
and both work in opposite directions |
| 22:20 |
hmmmm |
note this would only work if the mods define the bounds in which they intend to operate |
| 22:21 |
hmmmm |
if they attempt to access a piece of the map that hasn't been snapshotted, it'll have to incur a penalty |
| 22:21 |
est31 |
we can get in the log: (A, dirt (3,0,0,)), (b, stone, (0,0,0)), (A, dirt (2,0,0,)), (B, stone (1,0,0,)), (A, dirt (1,0,0,)), (B, stone (2,0,0,)), (A, dirt (1,0,0,)), (B, stone (3,0,0,)), (A, dirt (0,0,0,)) |
| 22:22 |
hmmmm |
that's not an issue. |
| 22:22 |
est31 |
then in the end, we have (stone, 3,0,0) (stone, 2,0,0) (dirt, 1,0,0) (dirt 1,0,0) |
| 22:22 |
hmmmm |
er |
| 22:23 |
est31 |
basically and config possible, depending on scheduling |
| 22:24 |
hmmmm |
by definition, mod B is taking a snapshot of the current state of the map |
| 22:25 |
hmmmm |
perhaps there could be a R/W flag |
| 22:25 |
hmmmm |
if one mod takes an R/W snapshot of a mapblock, then another mod later on can be notified of this |
| 22:26 |
hmmmm |
"hey there's another mod that intends to modify this area of map, so you might not be looking at the most recent" |
| 22:26 |
est31 |
so we allow the mod to either wait, or not wait |
| 22:26 |
hmmmm |
at this point it could say it's either OKAY with that |
| 22:27 |
hmmmm |
or it's not okay, and it wants a callback when that mod has no pending writers that came before it |
| 22:28 |
est31 |
that sounds better |
| 22:28 |
est31 |
mods who intend to write should also have this option: is there currently any mod reading that block? |
| 22:28 |
hmmmm |
but, in practice, all mods are going to want the most up-to-date version, even when they won't really need it |
| 22:29 |
hmmmm |
so there's this |
| 22:29 |
est31 |
its locking, again, btw |
| 22:29 |
|
paramat left #minetest-dev |
| 22:29 |
est31 |
not that I'd think its bad |
| 22:30 |
est31 |
(locking with the option, nah I ignore) |
| 22:30 |
hmmmm |
how about having a reader/writer lock |
| 22:30 |
hmmmm |
multi-reader/single writer |
| 22:31 |
hmmmm |
hrmm http://en.wikipedia.org/wiki/Seqlock |
| 22:33 |
hmmmm |
that's conceptually simpler but probably less useful |
| 22:34 |
hmmmm |
as far as I can tell, the only reason why there currently needs to be an envlock is contention between serverthread and emergethreads |
| 22:35 |
est31 |
seems so |
| 22:35 |
hmmmm |
if emergethread sticks to creating only new blocks (i.e. we stop doing shenaningans in others pieces of the map outside of chunk boundaries) then in theory it wouldn't need synchronization |
| 22:36 |
est31 |
if the data structures dont need it, yes |
| 22:36 |
hmmmm |
the data structures can be made wait-free |
| 22:36 |
est31 |
? |
| 22:37 |
est31 |
ah |
| 22:37 |
hmmmm |
before the ServerThread enqueues mapblocks for emerging, it could reserve the nodes or whatever in the std::map//std::vectors |
| 22:37 |
hmmmm |
and set it to NULL |
| 22:37 |
hmmmm |
it'd also pass pointers to these newly created nodes in the data structures as part of the block-making data |
| 22:38 |
hmmmm |
then when the emergethread is completely finished with making the blocks and initializing them, it'll atomically swap in the mapblock pointers |
| 22:38 |
est31 |
what is this exactly supposed to do? |
| 22:38 |
hmmmm |
it's just an idea |
| 22:38 |
hmmmm |
it would become a useless idea if true mod multithreading were added |
| 22:39 |
hmmmm |
i'm just saying that an envlock isn't strictly 100% necessary |
| 22:39 |
est31 |
yes |
| 22:39 |
est31 |
I dont know though how hard current envlock is |
| 22:43 |
est31 |
As a first step on the multithread route, we can do it like freeminer, and move basic server tasks out of the thread that does the mods. |
| 22:44 |
est31 |
so e.g. chat or moving SAOs aroung will still work, even when the server is busy doing other things |
| 22:44 |
est31 |
around* |
| 23:18 |
|
chchjesus joined #minetest-dev |
| 23:38 |
hmmmm |
sure |
| 23:38 |
hmmmm |
we should continue this discussion on the dev mailing list, don't you think? |
| 23:38 |
est31 |
good idea |
| 23:38 |
VanessaE |
we have a mailing list? :P |
| 23:39 |
est31 |
http://lists.minetest.net/archives/minetest-dev/2015-April/thread.html |
| 23:39 |
est31 |
very testy |
| 23:44 |
est31 |
ShadowNinja still hasnt said why my provider is greylisted |
| 23:44 |
est31 |
also idk what that even means |
| 23:44 |
VanessaE |
it means your provider is thought to be a source of spam. |
| 23:45 |
est31 |
whatever, I didnt have to give them my mobile phone number |
| 23:45 |
est31 |
which is good |
| 23:45 |
VanessaE |
didn't say it was such a source :) just that that's what I got when I looked it up yesterday |
| 23:46 |
VanessaE |
(looked up "greylist" that is) |
| 23:49 |
est31 |
btw, what happened of that nice ascii art network protocol comment? |
| 23:49 |
est31 |
did it get deleted? |
| 23:50 |
VanessaE |
? |
| 23:50 |
VanessaE |
on the list? I see only one post at the moment. |
| 23:50 |
est31 |
somewhere in network src, there was an ascii art |
| 23:50 |
VanessaE |
oh |
| 23:51 |
hmmmm |
you know |
| 23:51 |
hmmmm |
I seriously wonder how much contention the envlock really has |
| 23:51 |
hmmmm |
locks aren't slow, contention in locks is |
| 23:55 |
VanessaE |
looks like it was removed, est31. I don't find it anyway from a quick skim of the network code |
| 23:55 |
VanessaE |
(unless it's just so small I missed it) |
| 23:56 |
est31 |
nono was bit larger |
| 23:56 |
est31 |
I guess nrzkt didnt want to maintain it |
| 23:57 |
VanessaE |
est31: then I guess it's gone. good luck finding the commit that nuked it though |
| 23:57 |
est31 |
even if if it isnt maintained, its of no use |
| 23:58 |
hmmmm |
so right now the client message model is that the game loop grabs events from multiple sources, e.g. network and environment |
| 23:59 |
hmmmm |
we know this /works/, but does this make sense? |
| 23:59 |
hmmmm |
shouldn't the game loop maintain a thread-safe message loop that it exposes to event producers, such as the environment and network? |
| 23:59 |
VanessaE |
hmmmm: sure, it makes perfect sense, if we can guarantee that no one event will ever take longer to process than the minimum amount of time that it'll take for another event to arrive |
