elm-community / graph

Functional Graph Library in Elm.

Home Page:http://package.elm-lang.org/packages/elm-community/graph/latest

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

recursion error spliting a node

a-teammate opened this issue · comments

When you uncomment 194 and recompile, the app throws a runtime error..
https://ellie-app.com/cGXzxTNw4gza1

Why? Where?

Works:

  updatedGraph =
      StdGraph.insert newNode store.graph

doesnt work:

  updatedGraph =
      StdGraph.insert newNode store.graph
          |> StdGraph.update previousNodeId (Maybe.map (\a -> updatedPreviousNode))

How can I achieve this behavior "split this node" otherwise?
Manually using nodes edges, altering the list and rebuilding the graph using fromNodesAndEdges ?

Judging from the surrounding code, I suspect you want StdGraph.update newNodeId (Maybe.map (\a -> updatedPreviousNode)) (or just StdGraph.insert newNodeId updatedPreviousNode), not previousNodeId.

But an endless loop is a bug in the library nonetheless. Could you perhaps come up with a more minimal and standalone example, preferrably a test case that I can include in https://github.com/elm-community/graph/blob/master/tests/Tests/Graph.elm?

Hm well I try to split an item, so i need to modify the item (modifying its connections), but also add the new item.

https://ellie-app.com/cH23wNGHn63a1 is a bit more minimal.
Changing line 133 will cause the recursion error here

Well, still: I don't know what exact semantics "split an item has", but are you sure that your update should introduce a loop on previousNodeId? Because that's what your code is doing. I fixed it in https://ellie-app.com/cHk8gq3SqJZa1. Now I see how #27 (comment) didn't help: I replaced the wrong occurrence of previousNodeId there.

Still, it would be great if you could just provide me with a standalone expression I can evaluate that reproduces the endless loop.
I think it's due to an internal invariant being hurt, in which case the code just enters an infinite loop (since Elm got rid of Debug.crash).

ah dang! such a stupid mistake!
Thank you for spotting that!
I guess forbidding this kind of endless loop needs to be done in my user code instead, i.e. it must only allow acyclic graphs to be rendered.
Feel free to close if you share that opinion.

No, as I said: I think there might still be a bug in the code, because the documentation for update doesn't state any preconditions and endless loop pretty much means "an invariant was broken". That means a bug in library code, because it better preserves that invariant. If you could come up with a small expression that I could add to the testsuite as a regression test, other users won't stumble over the same problem in a few years of time.

Ah, I thought that it is not a lib bug, because the crash happens inside the user code:
Creating a DOM Tree, I walked the graph.
But I didnt consider the graph might have cycles.
So the graph is intact afterwards, just my manual walk of the graph was endless.
If you consider that something one could help to avoid (users doing stupid endless walks), then I agree: the lib can be improved.

For me, it would have helped if I had a walking method to allow "I want to have shuffle my graph to become a tree, then map the tree to be rendered elm-ui tree"
I guess its possible to do that already, but instead I used Graph.get and ended up in a cyclic state.

Alright, if you are certain the bug was in user code, I'll close this.