Deeper table debugging

[Rick]

It looks like currently we can only go so deep in the tables/nested tables. It would be nice if we could maybe configure how far we want to go. When I'm debugging some things I can't go as deep as I'd like to and it's really limiting the debug functionality in that respect.

[Josh]

Presently I think they are limited to three layers deep, to prevent infinite loops. But there might be a way to improve this.

[Crazycarpet]

Presently I think they are limited to three layers deep, to prevent infinite loops. But there might be a way to improve this.

 

You can just loop to as many levels as you want and 'break' when the object returned from debug.getinfo(level) is nil.

[Josh]

THat's what I did. And I wanted three.

[Crazycarpet]

THat's what I did. And I wanted three.

 

You may as well go up to like 50-100 because it's not going to slow things down... it'll print as many as it should then 'break' out of the loop.

[blueapples]

The traditional way to solve infinite recursion problem in dump/copy routines (which are basically the same thing) is to keep a list of seen objects and pass it to each nested call, similar to this copy function:

 

function copy(obj, seen)
 if type(obj) ~= 'table' then return obj end
 if seen and seen[obj] then return seen[obj] end
 local s = seen or {}
 local res = setmetatable({}, getmetatable(obj))
 s[obj] = res
 for k, v in pairs(obj) do res[copy(k, s)] = copy(v, s) end
 return res
end

 

Obviously instead of returning an already seen object you would return something like "Recursion <Object ID>". In combination with a searchable debug sidebar the user could then find that object wherever it first showed up in the tree.

 

Using this method there does not need to be a depth limit.