Community
Participate
Working Groups
The variables window seems to display tables in the wrong order. When the index > 9 the elements come first For example: the following code local t = {} for i = 1, 15 do table.insert(t, i) end ends up showing the table {10,11,12,13,14,15,1,2,3,4,5,6,7,8,9} instead of {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15} I do not recall this behavior before but not sure if I just didn't pay attention or not. This seems to be an issue with the print routine in general as it prints the wrong order too in the interactive console. (I use my own print routine which prints the correct order)
This is a problem on IDE side, because the debugger engine reports table as a "sequence" with keys in order. I think the IDE sort keys as strings (so "10" is smaller than "2"), but it should convert them in numbers for sequences, at least (regular table has no particular order of iteration anyway).
Let's try to have a look for 0.9M1
Created attachment 220191 [details] path proposal The Eclipse debug model plugin try to sort the variable tree of the variable view. And a sequence in this view is composed of variable for each item (you can see them by expending the sequence is the tree). For Lua we have attached to the model a LuaVariableComparator in order to filter global variables, because there are many variable and it's hard to find a specific one when they are not ordered. So the attached patch fix the LuaVariableComparator to handle sequence item variable and sort it. But this fix is based on a regex that complicates and decreases performances of the comparator. So I am asking if anyone have a better idea to solve this problem. And also the comparator manage some variable typed "special", if someone can explain what this is... Thanks, Marc
Partially fixed with commit 47d9fa18d40ea45c5e85767b8def2ab1b2f78c5e The Ide side now sort properly the elements of tables. But only 32 by 32 elements because the debugger send the tables elements by page of 32 and DLTK sort on block reception. The following code show the problem: local t = {} for i = 0,32/2,0.5 do t[i] = "hello" .. i; end print (t) <- breakpoint here On the breakpoint stop, the last elements of t in the variable view is at index 2.5 instead of 16. Using the attached DLTK patch allow to sort elements 100 by 100. The sort is limited to 100 elements, because for tables with more than 100 elements a visual pagination is done for each bench of 100 variables. This allow lasy loading, and only the elements of the current page are send to the IDE. As the IDE side doesn't have all the values, he can't make a proper sort for the whole index of the tables. The following code show the problem: local t = {} for i = 0,4*32 do t[i] = "ricard" .. i; end t[1.5] = "ricard sPecial" print (t) <- breakpoint here On the breakpoint stop, the first elements of t in the variable view in the page 100..128 is [0] instead of [101] So here a question, do you think it's a good idea to modify the degugger to sort the variables on the Lua side before sended it to the IDE ? so when a block of 100 variables is requested, we will send the right block according to the sorting.
Created attachment 237388 [details] DLTK patch to sort elements at the last moment.
I just found another issue. Depending of the Lua locale of the Lua interpreter, floating tables indexes can have different formats. For example, when printing the key value of a table, the result can be [1.5] for en_US locale and [1,5] for fr_FR (the separator between integer and decimal numbers can be a point or a coma). The problem is that the Java IDE side of the debugger doesn't know about the locale used by the Lua debugger so he can't decode and sort the tables indexes if the format separator is not a point. Maybe a fix should be to use an unique formating into the Dbgp messages regardless the Lua interpreter locale.
