Skip to content
This repository has been archived by the owner on Apr 9, 2024. It is now read-only.

Infinite loop countermeasure #21

Open
kkngsm opened this issue May 3, 2022 · 4 comments
Open

Infinite loop countermeasure #21

kkngsm opened this issue May 3, 2022 · 4 comments

Comments

@kkngsm
Copy link
Contributor

kkngsm commented May 3, 2022

If you build the nodes in this way and click on "👁 Set active" button, the application will crash.
image

How about providing a way for the library to avoid crashing if the loop is accidentally created?

For example, if I loop in blender, it looks like this and will not compute.
image

@kkngsm kkngsm changed the title Suggestion: Infinite loop countermeasure Infinite loop countermeasure May 9, 2022
@setzer22
Copy link
Owner

This library is mainly about creating and displaying node graphs using egui. Execution semantics is up to the user, so the meaning of a loop should not be defined by the library. However, I'm open to a solution that detects and breaks depdendency cycles for the example crate, since you're right that the current implementation gets into an infinite loop.

I didn't include this check to avoid over-complicating the example code, but maybe a simple solution using petgraph wouldn't add a lot of noise to it. I'm a bit busy currently, but I'd be happy to review and merge a PR for this 😄

@kkngsm
Copy link
Contributor Author

kkngsm commented May 27, 2022

Thank you for your response.

To add an addendum.
First, I would like the connection to turn red when an infinite loop occurs, like in Blender. It is easy to see where the loop is.
Secondly, if it should be handled on the application side, I would at least like to have a function that turns the connection red.

However, I think it would be easier to handle this on the library side.
This is because there are no applications that allow infinite loops (and even if there were, they could not be implemented in this library).
I don't think it's smart to implement the exact same implementation by all library users.

@setzer22
Copy link
Owner

setzer22 commented May 29, 2022

This is because there are no applications that allow infinite loops (and even if there were, they could not be implemented in this library).

What I mean is that everything depends on execution semantics. In a graph loops are not infinite, they're just loops, it's up to you how to interpret them. For instance, I can easily imagine a system where the node ports are used for control flow (like in UE5 blueprints or Godot's VisualScripting), where cycles in the graph are used to represent loops in the visual script. Some users of this library want to do just that, and while it's not exactly supported just yet, it's definitely something that I'd like to support.

Still, I see your point. If you're thinking about data flow "dependency" graphs like most things Blender uses graphs for, then yes, loops are quite undesirable in that situation because they represent a dependency cycle (i.e. a dependency that can never be fulfilled).

I would at least like to have a function that turns the connection red

I think this would be helpful. It is fair to assume many applications are going to want an acyclic graph, but this needs to be implemented in a way users that don't need it can disable it 👍

Still a bit busy to work on this actively, but I'd be happy to guide anyone who wants to take on this issue! 😄

@kkngsm
Copy link
Contributor Author

kkngsm commented May 30, 2022

I see! I understand now. It seems my knowledge was shallow.
I would like to work on it, but my technical skills seem to be lacking😢.

kkngsm added a commit to kkngsm/egui_node_graph that referenced this issue Aug 5, 2022
kkngsm added a commit to kkngsm/egui_node_graph that referenced this issue Aug 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants