https://bugzilla.wikimedia.org/show_bug.cgi?id=47104
--- Comment #7 from Brad Jorsch bjor...@wikimedia.org ---
(In reply to comment #6)
I like the idea of having a table that can be set and is preserved
across invoke calls, but that wasn't what was asked for in this
bug request.
And that's
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104
--- Comment #6 from darklama darkl...@gmail.com ---
(In reply to comment #5)
I like the idea of having a table that can be set and is preserved
across invoke calls, but that wasn't what was asked for in this
bug request. loadData can appear to
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104
Martijn Hoekstra martijnhoeks...@gmail.com changed:
What|Removed |Added
CC|
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104
darklama darkl...@gmail.com changed:
What|Removed |Added
Blocks||48176
Depends
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104
--- Comment #4 from Brad Jorsch bjor...@wikimedia.org ---
(In reply to comment #3)
Actually, darklama's comment makes me wonder. Could that solution be adapted
so that the loadData tables aren't read only? More specifically, could the
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104
darklama darkl...@gmail.com changed:
What|Removed |Added
CC||darkl...@gmail.com
---
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104
--- Comment #2 from Tim Starling tstarl...@wikimedia.org ---
Cloning it (i.e. copying the key/value pairs individually) would defeat the
purpose. It'd be faster to use require(), which does give a writable table.
You can use the index
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104
--- Comment #3 from Robert Rohde ro...@robertrohde.com ---
(In reply to comment #2)
Cloning it (i.e. copying the key/value pairs individually) would defeat the
purpose. It'd be faster to use require(), which does give a writable table.
This
https://bugzilla.wikimedia.org/show_bug.cgi?id=47104
Andre Klapper aklap...@wikimedia.org changed:
What|Removed |Added
Priority|Unprioritized |Low
--
You are
