gonum/graph: Unmarshaling DOT subgraph attribute
Satoru Kobayashi
Is it possible to parse subgraph attributes when unmarshaling DOT on gonum/graph?
In my understanding, a subgraph is considered only as a Vertex of edge end.
When the SetAttribute method is called for AttrStmt in subgraphs, the AttributeSetter cannot access subgraph-related values stored in the generator object.
The DOTAttributeSetters (graphAttr, nodeAttr, edgeAttr) are assigned only once in the copyGraph function, which means we cannot update graphAttr for subgraphs.
Therefore, it seems there is no way to differentiate global graph attributes and subgraph attributes.
I appreciate all your help.
Dan Kortschak
I agree with your assessment. It looks like we either need a graph
stack or a work list to make this work. This would need to be added.
Dan
Satoru Kobayashi
Dan Kortschak
> Hi Dan,
>
> Thank you for your comment.
> As the feature is necessary for my product, I will try to make it on
> my fork (perhaps on the graph-stack approach).
> If the fork works fine, let me propose a pull request.
> (Of course it is better if gonum experts can make it with more
> manageable code before that.)
graphAttr, nodeAttr and edgeAttr with a []attr where attr is struct{
graphAttr, nodeAttr, edgeAttr encoding.AttributeSetter } and then using
the top of the slice for appying attributes. The only subtlety would be
that before an attr is pushed onto the stack with a nil field the nil
should be replaced with the corresponding field from the current stack
top.
Dan
Satoru Kobayashi
Hi Dan,
Thank you for your hints.
Still, it seems []attr is not enough.
Users also want to parse the corresponding nodes to the subgraph for practical use.
To parse them, we should assume the Builder implements Subgrapher (to keep consistency with encode.go).
In that case, a generator needs not only []attr but a stack of subgraphs ([]graph.Graph).
The subgraphs need to be stored because Subgrapher.Subgraph is called on pushSubgraph to generate AttributeSetters for the subgraph and is also required up to popSubgraph to add subgraph nodes.
It also means there can be two kinds of subgraphs: user-defined graph.Graph to be parsed (for Subgrapher case) and simple node sets to represent edge vertex (for non-Subgrapher case).
These might be better unified into graph.Graph.
Satoru
Dan Kortschak
> Hi Dan,
>
>
> Still, it seems []attr is not enough.
> Users also want to parse the corresponding nodes to the subgraph for
> practical use.
> To parse them, we should assume the Builder implements Subgrapher (to
> keep consistency with encode.go).
> In that case, a generator needs not only []attr but a stack of
> subgraphs ([]graph.Graph).
> The subgraphs need to be stored because Subgrapher.Subgraph is called
> on pushSubgraph to generate AttributeSetters for the subgraph and is
> also required up to popSubgraph to add subgraph nodes.
>
> It also means there can be two kinds of subgraphs: user-defined
> graph.Graph to be parsed (for Subgrapher case) and simple node sets
> to represent edge vertex (for non-Subgrapher case).
> These might be better unified into graph.Graph.
>
> Satoru
graph.Builder can return nodes that implement Subgrapher. There would
need to be some kind of fallback that gives a reasonable outcome in the
face of a non-implementer. There is not really a symmetry between
encode and decode since DOT expresses more than the basic graph.Builder
API does.
I think we avoided adding this because its relatively complicated to
get a full implementation of a graph.Graph that incorporates the
entirety of DOT and what we had satisfied the needs that we had. It
would probably be helpful to make a toy case of a DOT description and
show how it fails to satisfy the needs that you have and then work from
there.
I can't spend a lot of time on this, but I can help you out if you
would like to try to add the implementation.
Dan
Satoru Kobayashi
Hi Dan,
I tried to implement it on my own idea, but the code changes diverged, and there seemed no end in sight.
To make it, we need to sort out many potential specifications on the conversion from DOT to gonum.graph.
Now I understand that it is difficult to fully support DOT expressions with graph.Builder completely.
I plan to use other DOT parser tools on golang and then convert it to gonum.graph with ad-hoc code for my use case.
Sorry that I cannot contribute to the improvement of gonum.
Thank you again for your help.
Satoru
Dan Kortschak
> Hi Dan,
>
> diverged, and there seemed no end in sight.
> To make it, we need to sort out many potential specifications on the
> conversion from DOT to gonum.graph.
> Now I understand that it is difficult to fully support DOT
> expressions with graph.Builder completely.
>
> I plan to use other DOT parser tools on golang and then convert it to
> gonum.graph with ad-hoc code for my use case.
> Sorry that I cannot contribute to the improvement of gonum.
> Thank you again for your help.
>
> Satoru
you are on the end of having to implement what it does.
I hope you are able to achieve what you want in your project. Let me
know if you need any other support.
Dan