The current implementation simply returns the current Node, which of course works fine because it is iterable.
It is also kind of confusing because children(node) === node looks strange. I briefly thought
children(n::Node) = (c for c in n)
would be nicer, but it turns out that doesn't work with AbstractTrees:
julia> AbstractTrees.print_tree(flamegraph())
FlameGraphs.NodeData(ip:0x0, 0x01, 1:299)
ERROR: MethodError: no method matching keys(::Base.Generator{Node{FlameGraphs.NodeData},var"#9#10"})
Closest candidates are:
keys(::Core.SimpleVector) at essentials.jl:602
keys(::Cmd) at process.jl:639
keys(::Tuple) at tuple.jl:46
...
Stacktrace:
[1] pairs(::Base.Generator{Node{FlameGraphs.NodeData},var"#9#10"}) at ./abstractdict.jl:132
An array comprehension is fine, of course, but also allocates an array.
So yeah, all in all I'm how actionable that complaint is, but the current behaviour was confusing for me at least.
The current implementation simply returns the current
Node
, which of course works fine because it is iterable. It is also kind of confusing becausechildren(node) === node
looks strange. I briefly thoughtwould be nicer, but it turns out that doesn't work with AbstractTrees:
An array comprehension is fine, of course, but also allocates an array.
So yeah, all in all I'm how actionable that complaint is, but the current behaviour was confusing for me at least.