1. 17 Nov, 2015 2 commits
  2. 09 Nov, 2015 1 commit
    • antirez's avatar
      Scripting: fix redis.call() error reporting. · 1b5d24eb
      antirez authored
      Arguments arity and arguments type error of redis.call() were not
      reported correctly to Lua, so the command acted in this regard like
      redis.pcall(), but just for two commands. Redis.call() should always
      raise errors instead.
      1b5d24eb
  3. 05 Nov, 2015 2 commits
  4. 04 Nov, 2015 1 commit
  5. 30 Oct, 2015 6 commits
  6. 01 Oct, 2015 1 commit
  7. 27 Jul, 2015 1 commit
  8. 26 Jul, 2015 6 commits
  9. 16 Jul, 2015 1 commit
  10. 14 Jul, 2015 1 commit
  11. 03 Jun, 2015 1 commit
  12. 22 Mar, 2015 1 commit
  13. 20 Jan, 2015 3 commits
  14. 09 Jan, 2015 1 commit
  15. 09 Oct, 2014 1 commit
    • Matt Stancliff's avatar
      Lua: Add bitop · 3fecb961
      Matt Stancliff authored
      A few people have written custom C commands because bit
      manipulation isn't exposed through Lua.  Let's give
      them Mike Pall's bitop.
      
      This adds bitop 1.0.2 (2012-05-08) from http://bitop.luajit.org/
      
      bitop is imported as "bit" into the global namespace.
      
      New Lua commands: bit.tobit, bit.tohex, bit.bnot, bit.band, bit.bor, bit.bxor,
      bit.lshift, bit.rshift, bit.arshift, bit.rol, bit.ror, bit.bswap
      
      Verification of working (the asserts would abort on error, so (nil) is correct):
      127.0.0.1:6379> eval "assert(bit.tobit(1) == 1); assert(bit.band(1) == 1); assert(bit.bxor(1,2) == 3); assert(bit.bor(1,2,4,8,16,32,64,128) == 255)" 0
      (nil)
      127.0.0.1:6379> eval 'assert(0x7fffffff == 2147483647, "broken hex literals"); assert(0xffffffff == -1 or 0xffffffff == 2^32-1, "broken hex literals"); assert(tostring(-1) == "-1", "broken tostring()"); assert(tostring(0xffffffff) == "-1" or tostring(0xffffffff) == "4294967295", "broken tostring()")' 0
      (nil)
      
      Tests also integrated into the scripting tests and can be run with:
      ./runtest --single unit/scripting
      
      Tests are excerpted from `bittest.lua` included in the bitop distribution.
      3fecb961
  16. 29 Sep, 2014 1 commit
  17. 10 Sep, 2014 1 commit
  18. 01 Sep, 2014 1 commit
  19. 13 Aug, 2014 1 commit
  20. 07 Aug, 2014 1 commit
  21. 12 Jun, 2014 1 commit
    • antirez's avatar
      Fix semantics of Lua calls to SELECT. · 96e0fe62
      antirez authored
      Lua scripts are executed in the context of the currently selected
      database (as selected by the caller of the script).
      
      However Lua scripts are also free to use the SELECT command in order to
      affect other DBs. When SELECT is called frm Lua, the old behavior, before
      this commit, was to automatically set the Lua caller selected DB to the
      last DB selected by Lua. See for example the following sequence of
      commands:
      
          SELECT 0
          SET x 10
          EVAL "redis.call('select','1')" 0
          SET x 20
      
      Before this commit after the execution of this sequence of commands,
      we'll have x=10 in DB 0, and x=20 in DB 1.
      
      Because of the problem above, there was a bug affecting replication of
      Lua scripts, because of the actual implementation of replication. It was
      possible to fix the implementation of Lua scripts in order to fix the
      issue, but looking closely, the bug is the consequence of the behavior
      of Lua ability to set the caller's DB.
      
      Under the old semantics, a script selecting a different DB, has no simple
      ways to restore the state and select back the previously selected DB.
      Moreover the script auhtor must remember that the restore is needed,
      otherwise the new commands executed by the caller, will be executed in
      the context of a different DB.
      
      So this commit fixes both the replication issue, and this hard-to-use
      semantics, by removing the ability of Lua, after the script execution,
      to force the caller to switch to the DB selected by the Lua script.
      
      The new behavior of the previous sequence of commadns is to just set
      X=20 in DB 0. However Lua scripts are still capable of writing / reading
      from different DBs if needed.
      
      WARNING: This is a semantical change that will break programs that are
      conceived to select the client selected DB via Lua scripts.
      
      This fixes issue #1811.
      96e0fe62
  22. 11 Jun, 2014 1 commit
    • antirez's avatar
      Scripting: Fix for a #1118 regression simplified. · 73fefd0b
      antirez authored
      It is more straightforward to just test for a numerical type avoiding
      Lua's automatic conversion. The code is technically more correct now,
      however Lua should automatically convert to number only if the original
      type is a string that "looks like a number", and not from other types,
      so practically speaking the fix is identical AFAIK.
      73fefd0b
  23. 10 Jun, 2014 1 commit
    • Matt Stancliff's avatar
      Scripting: Fix regression from #1118 · 76efe122
      Matt Stancliff authored
      The new check-for-number behavior of Lua arguments broke
      users who use large strings of just integers.
      
      The Lua number check would convert the string to a number, but
      that breaks user data because
      Lua numbers have limited precision compared to an arbitrarily
      precise number wrapped in a string.
      
      Regression fixed and new test added.
      
      Fixes #1118 again.
      76efe122
  24. 04 Jun, 2014 2 commits
    • antirez's avatar
      Fixed dbuf variable scope in luaRedisGenericCommand(). · 3758f27b
      antirez authored
      I'm not sure if while the visibility is the inner block, the fact we
      point to 'dbuf' is a problem or not, probably the stack var isx
      guaranteed to live until the function returns. However obvious code is
      better anyway.
      3758f27b
    • antirez's avatar
      Scripting: better Lua number -> string conversion in luaRedisGenericCommand(). · 072982d8
      antirez authored
      The lua_to*string() family of functions use a non optimal format
      specifier when converting integers to strings. This has both the problem
      of the number being converted in exponential notation, which we don't
      use as a Redis return value when floating point numbers are involed,
      and, moreover, there is a loss of precision since the default format
      specifier is not able to represent numbers that must be represented
      exactly in the IEEE 754 number mantissa.
      
      The new code handles it as a special case using a saner conversion.
      
      This fixes issue #1118.
      072982d8
  25. 20 May, 2014 1 commit