05:27:03 GMT <dudeji> does redis commands accept wild card ??
07:13:46 GMT <antirez> itamarhaber: just replied about Josiah concerns about Lua scripting.
07:14:19 GMT <antirez> itamarhaber: as you pointed out, it's a feature, and there is also a fundamental need for it in order for Lua to be able to return to Redis whatever redis.call() returns to it.
07:53:20 GMT <colo-work> I'm planning to migrate a redis master to another host. the redis release will stay the same, although the details of how the binary was built and hat libs (and compiler/lib versions) it links will change. I guess I can just stuff the rdb file of the old master into the location the new one expects it to, and this will work.
07:53:42 GMT <colo-work> I was questioning if there's another way to this though, that involves replication. can a redis slave be "promoted" to master somehow?
07:54:49 GMT <antirez> colo-work: Redis RDB files can be read by any other Redis, in different architectures even if the file was produced with a 64 bit system and the reader is 32 bit
07:55:33 GMT <antirez> colo-work: however yes, you can move things with replication as well: setup the new instance as a slave of the old one, when you are done send the SLAVEOF NO ONE command to promote it to master. However in redis.io you find exact documentation of this process which is sensitive to errors, so I would read thed ocs
07:55:35 GMT <antirez> the docs
07:59:28 GMT <colo-work> antirez, awesome, thanks a lot :)
08:00:29 GMT <antirez> you are welcome
08:13:51 GMT <greg__> I would like to update a webpage with the latest data from Redis. Is it possible to use websocket with Redis? If so, where should I be looking to go from here?
08:31:32 GMT <antirez> oran_agra: in case you get 5 min to talk about C undefined behaviors, I could definitely use some help...
08:38:57 GMT <oran_agra> sure. my favourite subject...
08:39:40 GMT <antirez> oran_agra: thanks, the topic is conversions between signed and unsigned
08:39:42 GMT <oran_agra> (i mean: any dark corner in C is)
08:39:52 GMT <antirez> haha, yeah I got this feeling :-)
08:40:17 GMT <antirez> So I read the C99 standard yesterday about that part
08:40:36 GMT <antirez> assume our "i" and "u" are both the same number of bits, like int and unsigned int.
08:41:14 GMT <antirez> The standard says that, if we convert from signed to unsigned, and the value does not fit into the unsigned, since it's negative, than what happens is that during the conversion, UINT_MAX+1 is added to the original value of 'i'.
08:41:40 GMT <antirez> so if i = -5 and we write "u = i", u will contain -5 + UINT_MAX + 1
08:42:02 GMT <antirez> that is exactly equivalent to doing nothing... from the point of view of bits, on two's complement representation
08:42:08 GMT <antirez> (so far everything resonates with you?)
08:42:29 GMT <oran_agra> yeah... doing nothing is exactly what i expect (move bits from one place to the other)
08:42:39 GMT <oran_agra> don't know why they bothered to mention the numeric values.
08:43:05 GMT <antirez> In order to standardize it in an arch-independent way I imagine... so that the behavior is well specified and "happens" to be "NOP" in most systems
08:43:32 GMT <antirez> However, the contrary is not specified behavior, that is, to convert from unsigned to signed *IF* the value does not fit
08:43:48 GMT <antirez> so if we have u set to INT_MAX+1, converting to i will be not specified
08:44:09 GMT <antirez> my need is to reconstruct 'i' from 'u', without any unspecified behavior, basically...
08:44:23 GMT <antirez> so far that's what I'm doing.
08:44:42 GMT <antirez> 1) Test if u > INT_MAX. If so, then it means that UINT_MAX+1 was added during the conversion, that is, i was negative.
08:44:44 GMT <antirez> makes sense?
08:47:16 GMT <oran_agra> let me make sure i understand:
08:47:43 GMT <oran_agra> your concern is to restore the original value you've put into the bitfield.
08:48:02 GMT <antirez> this error is also present in the bitfield code, but in this case is about RDB
08:48:14 GMT <antirez> basically I've a set of APIs in RDB to store unsigned values
08:48:22 GMT <oran_agra> the original value was signed and you stored it as unsigned, and now you need to undo whatever the conversion happened in order to get the signed you stored?
08:48:24 GMT <antirez> I want to create wrappers to use signed values
08:48:45 GMT <antirez> but without touching the original code, just creating wrappers that operate a signed -> unsigned conversion when storing, and the reverse when loading.
08:49:38 GMT <oran_agra> ok, got it.
08:50:03 GMT <oran_agra> sec, re-reading the above.
08:50:18 GMT <antirez> ok, let me gist-ify a thing
08:52:11 GMT <antirez> oran_agra: so that's what I hope could work: https://gist.github.com/antirez/4cd940880cc0f3f553b9d4cb72c6f315
08:54:32 GMT <antirez> just found an error... it overflows actually
08:57:25 GMT <antirez> gist updated
09:01:01 GMT <oran_agra> previous version did signed-unsigned (where the unsigned was bigger than max-signed)
09:01:25 GMT <oran_agra> this version looks right, mathematically, and doesn't violate anything...
09:02:04 GMT <oran_agra> i.e. conversion is done on a range in which the behaviour is defined and, and the rest of the math is just signed math.
09:03:09 GMT <oran_agra> however, i feel that this is too a lot of code to accomplish nothing... i bet that although this might be technically an undefined behavoiur.. any compiler that will rely on that for optimization will break most of the code in the universe.
09:04:25 GMT <antirez> oran_agra: yes :-(
09:04:34 GMT <antirez> oran_agra: also... my code assumes that UINT_MAX and INT_MAX have a specific relation
09:04:42 GMT <antirez> that's probably not true according to the standard.
09:04:42 GMT <oran_agra> since these are oportunistic optimizations though, we can't just construct an experiment that will test that.
09:05:20 GMT <antirez> I can still assert for that, but... how to assert for that without overflowing? It's also a lot of code :-) LOL
09:05:37 GMT <oran_agra> i think the assumption above is surelly ok... this is defined in limit.h and won't change with optimization level.
09:05:38 GMT <antirez> can't just assert(...); needs ifs and stuff to make sure no overflow happens
09:06:12 GMT <antirez> oran_agra: yes but probably writing: assert(UINT_MAX == INT_MAX*2+1) is not specified
09:06:47 GMT <oran_agra> i see 3 options:
09:06:54 GMT <antirez> since if INT_MAX > than expected, it overflows during the multiplication
09:07:07 GMT <oran_agra> 1) take the naive approach and just cast, and hope for the best.
09:07:19 GMT <oran_agra> 2) take the slow code and never look back.
09:08:06 GMT <oran_agra> 3) take the slow code and add a verification check that crashes the server if the naive approach and the mathematical approach don't produce the same result.
09:08:30 GMT <oran_agra> then in 3) after some mileage, we can remove the complicated code.
09:09:04 GMT <oran_agra> this will not gurentee that what we do is correct.. just that there's no compiler that decided to use any insane optimization on that piece of redis code.
09:10:12 GMT <antirez> I'm a bit biased for 1 or 2
09:10:29 GMT <antirez> in this moment BITFIELD Is broken btw since does "1"
09:10:59 GMT <oran_agra> is it broken, or just theoretically broken? (did you experiance any error?)
09:11:13 GMT <antirez> no no... works as expected with the fuzzing and all
09:11:15 GMT <antirez> just in theory
09:12:59 GMT <oran_agra> i would vote for 1.  but if you don't feel comfortable, then take 3 (it it has no performance overhead, and at least we'll learn something in a year or two)
09:13:19 GMT <WintermeW> hi, do you know of a good Redis c++ client which natively supports storing/retrieving of STL containers as binary data ? So far i'm using hiredis and it works, but i had to make some dirty sh** to do so.
09:13:38 GMT <oran_agra> actually if you call assert, it will mean a branch and no inlinining... but if you just generate a segfault.. that's fast
09:14:24 GMT <antirez> oran_agra: I could just assert in main() in theory...
09:15:22 GMT <oran_agra> still a branch though. but that can be the first place in redis where we use an unlikely() hint.
09:15:38 GMT <antirez> I mean, assert at startup and never assert again
09:15:49 GMT <antirez> so that the server will stop at startup or continue without asserting again
09:16:09 GMT <oran_agra> you can't assert in main, since that's an opportunistic optimization.. it can happen in one piece of your program and not in another.
09:16:38 GMT <antirez> yep I was thinking at "2" and asserting that UINT_MAX = INT_MAX*2+1
09:16:47 GMT <oran_agra> what matters is that it didn't introduce errors into redis code.
09:16:49 GMT <oran_agra> ohh
09:16:59 GMT <antirez> I think that "3" could not detect what we hope it could
09:17:07 GMT <oran_agra> i don't think that's something to assert for.. it is defined in limit.h and will never change.
09:17:33 GMT <oran_agra> 3 will detect it as soon as you store any negative number in a piece of code the compiler decided to optimize
09:17:35 GMT <antirez> oran_agra: yes but what if limit.h has a different value? There is no standard value for what is inside limit.h as INT_MAX
09:18:48 GMT <oran_agra> that doesn't concern me... i don't think that will happen in the next 20 years.... but optimizations can change between versions of compilers every few weeks.
09:19:06 GMT <antirez> yes, that's true
09:20:01 GMT <antirez> ok, given that for now both of this instances are not in particularly speed critical code, I think I'll try to just use the code that should not produce issues (the one in the gist)
09:20:28 GMT <antirez> so that we protect against compilers...
09:21:02 GMT <antirez> even if I've some feeling that for something that we don't understand
09:21:07 GMT <antirez> my code could be as undefined as "1"
09:21:18 GMT <antirez> because truly the standard is a mess... full of strange corners
09:21:39 GMT <antirez> but
09:21:46 GMT <antirez> clang has a special flag that traps unspecified behaviors
09:21:53 GMT <antirez> so maybe this could be useful while testing
09:23:40 GMT <oran_agra> ok, you can take "2" and add a comment on why you did that complicated thing.. but i still curious to know if that'll ever happen.
09:24:26 GMT <oran_agra> if you take "3" it will crash any server *as soon as any negative value is read* if the compiler decided to optimize.
09:25:00 GMT <antirez> oran_agra: there is... 4) use an union so that we can get exact-bit conversions ...
09:25:09 GMT <oran_agra> so i don't think this will cause someone to loose data in production.. and 2 years from now, we can learn something..
09:25:57 GMT <antirez> I just found that:
09:25:57 GMT <antirez> http://stackoverflow.com/questions/19490240/does-cast-between-signed-and-unsigned-int-maintain-exact-bit-pattern-of-variable
09:26:08 GMT <oran_agra> interesting.. i wanted to suggest getting the address of the variable and convert it from uint* to int* but that's an optimization no-no too.
09:26:22 GMT <oran_agra> i guess that with unions the compiler skips these optimizations.
09:26:22 GMT <antirez> where I learned that for stdint.g types, the compiler *must* use two complement representation (!)
09:27:27 GMT <antirez> yes
09:27:39 GMT <antirez> if we use an union however we are assuming that all the archs will use the same representation
09:27:45 GMT <antirez> but remarkably this is a lot a safer bet
09:27:51 GMT <antirez> VS compiler optimizations I mean...
09:28:00 GMT <antirez> everything is 2's complement and will be for decades
09:29:15 GMT <oran_agra> what's stdint.g? i don't see it mentioned
09:29:39 GMT <antirez> stdint.h sorry, typo
09:29:42 GMT <antirez> uint64_t & company
09:30:17 GMT <antirez> She/he writes " In case of two's complement representations without padding - which is mandatory for the fixed-with integer types - this distinction does not matter and the cast will indeed be a noop."
09:30:44 GMT <antirez> so if we use those types we are safe?
09:30:56 GMT <antirez> let's search for the relevant standard stuff...
09:36:19 GMT <antirez> ok casting has the same rules, but they are guaranteed to be 2's complement
09:36:28 GMT <antirez> and no padding, just that
09:36:46 GMT <antirez> but this means that the code I wrote in the gist is always safe in that case, which is good
09:37:14 GMT <oran_agra> ok, but why not use the union?
09:43:15 GMT <antirez> oran_agra: yep... that's probably the simplest approach
09:45:19 GMT <antirez> doing this for bitop.c to start, let's see
09:53:50 GMT <antirez> oran_agra: https://github.com/antirez/redis/commit/2503acfc83753e78045346c4b4993d5d34cf57d2
10:03:43 GMT <antirez> oran_agra: thanks for the help, today definitely I learned something new about C...
10:18:25 GMT <oran_agra> gladly.. thank you!
13:30:34 GMT <oran_agra> antirez: any reason why the geo test is not part of the full test suite (make test)?
14:10:43 GMT <ash_workz> why would `"start": "if-env NODE_ENV=production && npm run start:prod || npm run start:dev",` fail but running `ode_modules/if-env/bin/if-env.js NODE_ENV=production && npm run start:prod || npm run start:dev` works
14:24:21 GMT <antirez> oran_agra: really?!
14:24:25 GMT <antirez> oran_agra: checking
14:25:46 GMT <antirez> oran_agra: wow it was not listed in the main file
14:25:54 GMT <antirez> MAIN FAIL actually
14:25:56 GMT <antirez> adding it, thanks
14:29:52 GMT <bobbob> hello
14:30:08 GMT <antirez> itamarhaber: Hey Itamar
14:30:18 GMT <antirez> itamarhaber: I think there was a reason why SPOP was blacklisted! :-)
14:30:23 GMT <bobbob> is it sort of the done thing to attempt to keep one data-type in one database, or does mixing not matter really?
14:31:36 GMT <bobbob> hmm...actually both my datatypes are strings, just for different uses, so maybe it doesnt matter anyway
14:37:07 GMT <itamarhaber> antirez: really? what could it be?
14:40:12 GMT <antirez> itamarhaber: there was an explicit test for it :-)
14:40:22 GMT <antirez> itamarhaber: so nobody touched it I guess haha
14:40:36 GMT <antirez> I'm not sure *why* SPOP in the test
14:40:45 GMT <antirez> it is a generic test... about not being allowed to call certain commands
14:43:16 GMT <itamarhaber> Well, since it wasn't permitted I think the risk of allowing it is small in terms of backward compatibility. The test will need to be changed for something more "forbidden" in scripts.
14:44:21 GMT <antirez> itamarhaber: changed it to BLPOP already
14:44:24 GMT <antirez> (just pushed)
14:46:51 GMT <itamarhaber> So we're safe until scripts can do blocking commands... good :)
15:07:01 GMT <ash_workz> it was a malformed webpack.config.js
15:07:30 GMT <ash_workz> I'm so glad that the react-router tutorial has working packages at every step
15:07:42 GMT <ash_workz> so if you mess up you can just compile the step and compare your outputs
15:08:07 GMT <ash_workz> I was missing '/' for publicPath (that wasn't in the docs though)
15:08:28 GMT <ash_workz> also I was missing a comma before my plugins
15:08:52 GMT <ash_workz> and one of my lines I accidentally copied over
15:09:25 GMT <ash_workz> oh
15:09:29 GMT <ash_workz> I'm on redis
15:09:32 GMT <ash_workz> HAH
15:09:35 GMT <ash_workz> sorry
15:48:27 GMT <nepot> Hi, I have a pretty bizzare issue on 3.0.7 where I deleted a list that was being repeatedly BLPOPd from and now it is in an indeterminate state. KEYS, DEBUG, OBJECT * all act like it no longer exists, LPUSHing to it returns success (length 1) but following LLENs show it is empty, and oddly enough BLPOPing from it returns entries that were in the list before I deleted it. I tried looking around
15:48:27 GMT <nepot> to see if this was a known issue or pebkac but can't seem to find anything. Has anyone seen something like this before or have any suggestions as to what my next steps for throubleshooting this could be?
16:00:35 GMT <itamarhaber> nepot: that's weird indeed - never encountered this behavior. Do EXISTS/TYPE find the key?
16:03:34 GMT <_nepot> itamarhaber: Nope, they return 0 and none respectively
16:03:55 GMT <saml> given a zset, is there a way to dump all content? so that i can grep
16:04:10 GMT <saml> something like   redis-cli hgetall myhash  | grep yolo
16:04:12 GMT <itamarhaber> saml: zrange key 0 -1
16:04:15 GMT <saml> thanks
16:05:34 GMT <minus> eventually add withscores if you care about those
16:08:08 GMT <itamarhaber> btw, what's pebkac?
16:08:22 GMT <_nepot> problem exists between keyboard and chair
16:08:32 GMT <itamarhaber> oh, layer 8
16:08:35 GMT <_nepot> haha
16:10:49 GMT <saml> there's no way to get all key-values of hash that matches glob, right?  something like  keys foo*;     hkeys myhash foo*
16:11:33 GMT <saml> oh hscan
16:13:53 GMT <saml> HSCAN myhash 0 MATCH foo*
16:13:56 GMT <saml> i don't think this works
16:19:20 GMT <itamarhaber> neopot: while this could always be a defect, is there a chance that some process is still still pushing/popping stuff on that list? CLIENT LIST and MONITOR helps to rule this out...
16:31:55 GMT <itamarhaber> saml: HSCAN should work the way you put it, but make sure you understand SCAN's behavior.
16:32:48 GMT <_nepot> itamarhaber: layer 8 indeed.... somebody is still LPUSHing & BLPOPing on that list in a tight loop, so it appears to never be there unless I issue a blocking pop myself... thanks for the help!
16:34:56 GMT <itamarhaber> haha - great!
17:50:35 GMT <saml> ah i see.   hscan myhash 0 match foo* count 100000  works
17:50:54 GMT <saml> looks like i have to keep follow cursors until matches come up
18:12:48 GMT <cliluw> How is Redis pronounced? "reed-is" or "red-is"?
18:30:56 GMT <minus> latter, i guess
18:48:36 GMT <saml> there's no way to match hashed values right?
18:48:40 GMT <saml> only keys can be matched
18:49:34 GMT <saml> red dis
18:49:50 GMT <minus> saml: yes, redis does never look into values