Add test_result_view.lua; fix minor bugs in result_view.lua.

2 files changed, 65 insertions, 8 deletions

diff --git a/indra/newview/scripts/lua/require/result_view.lua b/indra/newview/scripts/lua/require/result_view.lua
index 4a58636f2f..d53d953c24 100644
--- a/indra/newview/scripts/lua/require/result_view.lua
+++ b/indra/newview/scripts/lua/require/result_view.lua
@@ -23,7 +23,8 @@ local function result_view(key_length, fetch)
                 -- can we find this index within the current slice?
                 local reli = i - this.start
                 if 0 <= reli and reli < #this.slice then
-                    return this.slice[reli]
+                    -- Lua 1-relative indexing
+                    return this.slice[reli + 1]
                 end
                 -- is this index outside the overall result set?
                 if not (0 <= i and i < this.length) then
@@ -31,16 +32,17 @@ local function result_view(key_length, fetch)
                 end
                 -- fetch a new slice starting at i, using provided fetch()
                 local start
-                this.slice, start = fetch(key, i)
+                this.slice, start = fetch(this.key, i)
                 -- It's possible that caller-provided fetch() function forgot
                 -- to return the adjusted start index of the new slice. In
                 -- Lua, 0 tests as true, so if fetch() returned (slice, 0),
-                -- we'll duly reset this.start to 0.
-                if start then
-                    this.start = start
-                end
-                -- hopefully this slice contains the desired i
-                return this.slice[i - this.start]
+                -- we'll duly reset this.start to 0. Otherwise, assume the
+                -- requested index was not adjusted: that the returned slice
+                -- really does start at i.
+                this.start = start or i
+                -- Hopefully this slice contains the desired i.
+                -- Back to 1-relative indexing.
+                return this.slice[i - this.start + 1]
             end,
             -- We purposely avoid putting any array entries (int keys) into
             -- our table so that access to any int key will always call our
diff --git a/indra/newview/scripts/lua/test_result_view.lua b/indra/newview/scripts/lua/test_result_view.lua
new file mode 100644
index 0000000000..304633a472
--- /dev/null
+++ b/indra/newview/scripts/lua/test_result_view.lua
@@ -0,0 +1,55 @@
+-- Verify the functionality of result_view.
+result_view = require 'result_view'
+
+print('alphabet')
+alphabet = "abcdefghijklmnopqrstuvwxyz"
+assert(#alphabet == 26)
+alphabits = string.split(alphabet, '')
+
+print('function slice()')
+function slice(t, index, count)
+    return table.move(t, index, index + count - 1, 1, {})
+end
+
+print('verify slice()')
+-- verify that slice() does what we expect
+assert(table.concat(slice(alphabits, 4, 3))  == "def")
+assert(table.concat(slice(alphabits, 14, 3)) == "nop")
+assert(table.concat(slice(alphabits, 25, 3)) == "yz")
+
+print('function fetch()')
+function fetch(key, index)
+    -- fetch function is defined to be 0-relative: fix for Lua data
+    -- constrain view of alphabits to slices of at most 3 elements
+    return slice(alphabits, index+1, 3), index
+end
+
+print('result_view()')
+-- for test purposes, key is irrelevant, so just 'key'
+view = result_view({'key', #alphabits}, fetch)
+
+print('function check_iter()')
+function check_iter(...)
+    result = {}
+    for k, v in ... do
+        table.insert(result, v)
+    end
+    assert(table.concat(result) == alphabet)
+end
+
+print('check_iter(pairs(view))')
+check_iter(pairs(view))
+print('check_iter(ipairs(view))')
+check_iter(ipairs(view))
+print('check_iter(view)')
+check_iter(view)
+
+print('raw index access')
+assert(view[5]  == 'e')
+assert(view[10] == 'j')
+assert(view[15] == 'o')
+assert(view[20] == 't')
+assert(view[25] == 'y')
+
+print('Success!')
+