09:36:33 GMT <gc89> #jboss
09:40:12 GMT <antirez> oran_agra: in your GEORADIUS issue the line should indeed be: if (step >= 26) step = 25;
09:40:25 GMT <antirez> oran_agra: did you checked if this fixes the problem?
09:41:05 GMT <antirez> btw let me check what we have in the stress test as max radius
09:42:41 GMT <oran_agra> i think i tried to change it and it didn't solve the problem.. i debugged it and watched some variables. i estimate the problem is a lot deeper.
09:42:41 GMT <antirez> oran_agra: the test is limited to 200 km indeed
09:43:00 GMT <antirez> oran_agra: ok will look into that, thanks
09:43:21 GMT <antirez> oran_agra: it will take some effort to remember all the details of the implementation, but I'll try to fix this
09:43:22 GMT <oran_agra> i tried to solve it myself, but at the end i concluded that it is beyond my current skills.
09:43:56 GMT <antirez> oran_agra: unfortunately there is a lot of domain-specific thing there, every time there is to re-learn what happens. Also I regret deeply I removed all the debugging printf() I had ;-)
09:45:24 GMT <antirez> oran_agra: all the other PRs are mostly no brainers to merge. Currently I'm debugging a crash I've with the real data types for modules but will switch between this afternoon to tomorrow morning to merge the PRs
09:46:00 GMT <oran_agra> thanks
09:46:23 GMT <antirez> thank you
10:10:41 GMT <antirez> oran_agra: did not resisted and investigated a bit the problem
10:10:54 GMT <antirez> oran_agra: it only happens for very very large radiuses, like > 19k kilometers
10:11:37 GMT <antirez> oran_agra: so basically, I'll try to investigate it properly, but if the code is incompatible with running around the size of the Earth radius, we can just revert to "take it all" in that case and filter.
10:26:14 GMT <antirez> oran_agra: the problem was in geohashBoundingBox()
10:26:42 GMT <antirez> oran_agra: it does not work with large radius, provides bogus values at all (certain vertexes are set to not-a-number)
10:39:01 GMT <oran_agra> antirez: i'm afraid that if we don't fully understand the root of the problem, we don't have a good way to decide when to revert to "take it all" approach. just choosing a random radius seems risky.. alternatively if you'll get to the bottom of this, maybe you'll have a simple fix.
10:46:12 GMT <antirez> oran_agra: root cause found and bug fixed \o/, committing
10:48:04 GMT <antirez> oran_agra: just pushed on the repository. The problem is that the Earth radius is ~6000km, but there were no checks for when a greater radius was provided.
10:51:13 GMT <oran_agra> not really my field of expertise, but the earth geometrical radius, and the surface radius we're talking about are two different things.. right?
10:51:35 GMT <oran_agra> 20,000km is a valid radius for a GEORADIUS query.
10:52:38 GMT <oran_agra> 21,000 is out of scope, but not 20,000
10:53:40 GMT <ahfeel> so we can't search in the universe :<
10:53:47 GMT <*> ahfeel  sad
10:54:21 GMT <antirez> Yes, if you consider the earth circumference, you have 40k km
10:54:36 GMT <antirez> so, you could search with a radius of 10k km
10:54:43 GMT <antirez> that will cover a whole "face"
10:54:52 GMT <antirez> for a total of 20k of area starting from the center
10:55:12 GMT <antirez> but this should work as expected
10:55:37 GMT <antirez> the problem is that in order to compute the bounding box we use the radius, as the distance between the center and the surface
10:58:28 GMT <oran_agra> ok.. seems to work.
10:58:45 GMT <antirez> yep, I want to verify that the bounding box output is correct near this measures
10:58:58 GMT <antirez> also there is to check if your assumption is ok with the code, that is, after a radius of 10k
10:59:04 GMT <antirez> that covers a whole face, what happens if you go over that?
10:59:17 GMT <antirez> in theory you want it to "wrap" to the other face, so that 20k km means: the whole earth
10:59:17 GMT <oran_agra> i'll throw it back at our QA team...
10:59:20 GMT <antirez> it should be like that AFAIK
10:59:41 GMT <antirez> the bounding box calculation however is *only* used in an optimization
10:59:49 GMT <antirez> and if it is wrong, it may break things
11:00:04 GMT <antirez> the idea is that we compute the bounding box, so that the center + 9 near squares
11:00:13 GMT <oran_agra> btw, did you also fix that >26 line?
11:00:14 GMT <antirez> are filtered to remove all the squares that are totally out of the bounding box.
11:00:35 GMT <antirez> oran_agra: yes fixed as well but stress testing that everything is ok. The 26 affects very small radiuses
11:02:15 GMT <antirez> Btw the fix should be ok for sure
11:02:19 GMT <antirez> (of the 26 thing)
11:02:23 GMT <antirez> the actual code should be:
11:02:27 GMT <antirez> +    if (step > 26) step = 26;
11:02:47 GMT <antirez> since we have 52 bits
11:02:48 GMT <antirez> since it was:
11:02:52 GMT <antirez> -    if (step > 26) step = 25;
11:03:02 GMT <antirez> it means that in the past we already were running with step = 26
11:03:12 GMT <antirez> only when it was 27 or more it was rescaled to 25
12:15:20 GMT <dorfen> Hi guys, kan i have the same value stored under multiple keys? So editing one key would update the object for all the other keys?
12:44:04 GMT <WintermeW> hi guys, got an hard time sending "complex" datastructures via the hiredis client..do you know how the %b specifier works exactly with pointers ? will it store the data it points to, or just the address ?
12:49:46 GMT <WintermeW> so as i see on stackoverflow, i have no choice but string-serialize my struct..no fucking way, that's insanely sub-optimal..
13:23:56 GMT <antirez> dorfen: Redis does not handle that, but you can do it at application level.
13:24:17 GMT <antirez> dorfen: for example each value you have could start with "v" if is a value, or "r" if is a reference to another key.
13:24:33 GMT <antirez> So if the value is "rkey123" it means "read content of key123 for the actual value"
13:24:56 GMT <antirez> but if it is "vfoo" then the value is just the string "foo".
15:11:48 GMT <Sembiance> morning everyone :)