1. 11 Mar, 2014 3 commits
  2. 10 Mar, 2014 3 commits
    • antirez's avatar
      DEBUG ERROR implemented. · eb9e1526
      antirez authored
      The new "error" subcommand of the DEBUG command can reply with an user
      selected error, specified as its sole argument:
      
          DEBUG ERROR "LOADING please wait..."
      
      The error is generated just prefixing the command argument with a "-"
      character, and replacing newlines with spaces (since error replies can't
      include newlines).
      
      The goal of the command is to help in Client libraries unit tests by
      making simple to simulate a command call triggering a given error.
      eb9e1526
    • Matt Stancliff's avatar
      Fix return value check for anetTcpAccept · a6970570
      Matt Stancliff authored
      anetTcpAccept returns ANET_ERR, not AE_ERR.
      
      This isn't a physical error since both ANET_ERR
      and AE_ERR are -1, but better to be consistent.
      a6970570
    • antirez's avatar
  3. 05 Mar, 2014 20 commits
  4. 28 Feb, 2014 1 commit
  5. 27 Feb, 2014 13 commits
    • antirez's avatar
      BITPOS fuzzy testing. · 950cb76e
      antirez authored
      950cb76e
    • antirez's avatar
      Basic BITPOS tests. · 42e3630d
      antirez authored
      42e3630d
    • antirez's avatar
      warnigns -> warnings in redisBitpos(). · 1892b562
      antirez authored
      1892b562
    • antirez's avatar
      More consistent BITPOS behavior with bit=0 and ranges. · 2c8036f7
      antirez authored
      With the new behavior it is possible to specify just the start in the
      range (the end will be assumed to be the first byte), or it is possible
      to specify both start and end.
      
      This is useful to change the behavior of the command when looking for
      zeros inside a string.
      
      1) If the user specifies both start and end, and no 0 is found inside
         the range, the command returns -1.
      
      2) If instead no range is specified, or just the start is given, even
         if in the actual string no 0 bit is found, the command returns the
         first bit on the right after the end of the string.
      
      So for example if the string stored at key foo is "\xff\xff":
      
          BITPOS foo (returns 16)
          BITPOS foo 0 -1 (returns -1)
          BITPOS foo 0 (returns 16)
      
      The idea is that when no end is given the user is just looking for the
      first bit that is zero and can be set to 1 with SETBIT, as it is
      "available". Instead when a specific range is given, we just look for a
      zero within the boundaries of the range.
      2c8036f7
    • antirez's avatar
      Initial implementation of BITPOS. · 3294f74f
      antirez authored
      It appears to work but more stress testing, and both unit tests and
      fuzzy testing, is needed in order to ensure the implementation is sane.
      3294f74f
    • antirez's avatar
      82d2e295
    • antirez's avatar
      BITCOUNT fuzzy test with random start/end added. · a3eb3f9c
      antirez authored
      It was verified in practice that this test is able to stress much more
      the implementation by introducing errors that were only trivially to
      detect with different offsets but impossible to detect starting always
      at zero and counting bits the full length of the string.
      a3eb3f9c
    • antirez's avatar
      Fix misaligned word access in redisPopcount(). · 30a92b6c
      antirez authored
      30a92b6c
    • antirez's avatar
      warnigns -> warnings in redisBitpos(). · c1cc28f2
      antirez authored
      c1cc28f2
    • antirez's avatar
      More consistent BITPOS behavior with bit=0 and ranges. · d79f9ebd
      antirez authored
      With the new behavior it is possible to specify just the start in the
      range (the end will be assumed to be the first byte), or it is possible
      to specify both start and end.
      
      This is useful to change the behavior of the command when looking for
      zeros inside a string.
      
      1) If the user specifies both start and end, and no 0 is found inside
         the range, the command returns -1.
      
      2) If instead no range is specified, or just the start is given, even
         if in the actual string no 0 bit is found, the command returns the
         first bit on the right after the end of the string.
      
      So for example if the string stored at key foo is "\xff\xff":
      
          BITPOS foo (returns 16)
          BITPOS foo 0 -1 (returns -1)
          BITPOS foo 0 (returns 16)
      
      The idea is that when no end is given the user is just looking for the
      first bit that is zero and can be set to 1 with SETBIT, as it is
      "available". Instead when a specific range is given, we just look for a
      zero within the boundaries of the range.
      d79f9ebd
    • antirez's avatar
      Initial implementation of BITPOS. · 25e2791e
      antirez authored
      It appears to work but more stress testing, and both unit tests and
      fuzzy testing, is needed in order to ensure the implementation is sane.
      25e2791e
    • antirez's avatar
      c955b47d
    • antirez's avatar
      BITCOUNT fuzzy test with random start/end added. · bfe4c560
      antirez authored
      It was verified in practice that this test is able to stress much more
      the implementation by introducing errors that were only trivially to
      detect with different offsets but impossible to detect starting always
      at zero and counting bits the full length of the string.
      bfe4c560