juliacollections / leftchildrightsiblingtrees.jl Goto Github PK

I am having trouble figuring out what the convert method is supposed to be for a custom struct.

using Parameters
using LeftChildRightSiblingTrees

@with_kw struct DigitalContour
    id::Int = 0
    is_outer::Bool = false
    pixels::Vector{CartesianIndex{2}} = Vector{CartesianIndex{2}}(undef, 0)
end

root = Node(DigitalContour(is_outer = false))
addchild(root, Node(DigitalContour(id = 1)))

ERROR: MethodError: Cannot convert an object of type Node{DigitalContour} to an object of type DigitalContour
Closest candidates are:
convert(::Type{T}, ::T) where T at essentials.jl:168
DigitalContour(::Any, ::Any, ::Any) at /home/zygmunt/.julia/packages/Parameters/l76EM/src/Parameters.jl:478
Stacktrace:
[1] Node{DigitalContour}(::Node{DigitalContour}, ::Node{DigitalContour}) at /home/zygmunt/.julia/packages/LeftChildRightSiblingTrees/7aS8D/src/LeftChildRightSiblingTrees.jl:45
[2] Node(::Node{DigitalContour}, ::Node{DigitalContour}) at /home/zygmunt/.julia/packages/LeftChildRightSiblingTrees/7aS8D/src/LeftChildRightSiblingTrees.jl:52
[3] addchild(::Node{DigitalContour}, ::Node{DigitalContour}) at /home/zygmunt/.julia/packages/LeftChildRightSiblingTrees/7aS8D/src/LeftChildRightSiblingTrees.jl:90
[4] top-level scope at none:0

Part of my problem is that I don't really understand how the call to convert is being called. Thanks for any advice you might have.

Once https://github.com/JuliaCollections/AbstractTrees.jl moves to JuliaCollections.

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Do the other JuliaCollections folks think this is ready to register as a package?

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.

Precompilation failure seems to happen with [email protected] but not @0.1.5. Root cause seems to be in LeftChildRightSiblingTrees.

Thanks!

[ Info: Precompiling TerminalLoggers [5d786b92-1e48-4d6f-9151-6b4477ca9bed]
ERROR: LoadError: UndefVarError: NodeType not defined
Stacktrace:
 [1] getproperty(x::Module, f::Symbol)
   @ Base ./Base.jl:31
 [2] top-level scope
   @ ~/.julia/packages/LeftChildRightSiblingTrees/ItTnK/src/abstracttrees.jl:3
 [3] include(mod::Module, _path::String)
   @ Base ./Base.jl:419
 [4] include(x::String)
   @ LeftChildRightSiblingTrees ~/.julia/packages/LeftChildRightSiblingTrees/ItTnK/src/LeftChildRightSiblingTrees.jl:1
 [5] top-level scope
   @ ~/.julia/packages/LeftChildRightSiblingTrees/ItTnK/src/LeftChildRightSiblingTrees.jl:250
 [6] include
   @ ./Base.jl:419 [inlined]
 [7] include_package_for_output(pkg::Base.PkgId, input::String, depot_path::Vector{String}, dl_load_path::Vector{String}, load_path::Vector{String}, concrete_deps::Vector{Pair{Base.PkgId, UInt64}}, source::String)
   @ Base ./loading.jl:1554
 [8] top-level scope
   @ stdin:1

Right now, addchild and addsibling require you to pass the data directly. Is it reasonable to add methods which allow you to specify child::Node{T}s rather than data::T?

I'm working with a problem where the end product is conveniently represented as a LCRS tree, but it's most sensible to build it from the bottom up, rather than the top down. This means I want to pass a subtree as a child rather than just the data, because that node has a collection of children/siblings already. Presumably we could do this with making Node{T}s which duplicate data and then graftchildren! to this duplicate node, but it seems like we could this more directly

E- This runs into the issue where you could add a Node from a tree to the tree again somewhere else, so it's not necessarily safe. That might be enough to disqualify this