You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, gantz uses a very ad-hoc approach of passing slices of Any trait objects into the evaluation functions in order to provide access to state for nodes and nested graphs. There are two major issues with this approach:
The approach of passing slices of references to state is awkward and could easily lead to borrow-checker issues in cases where the user is trying to retrieve multiple mutable references from the same state-storing data structure. The unsafety of switching to raw pointers would be amplified by the awkwardness of the API and make it even more likely to trigger UB accidentally.
It would be nice to come up with some kind of type-safe abstraction that could solve both of these issues. This will likely have to wrap a raw pointer at the boundary, but at least if these raw pointers could be created and downcasted behind some safer API there would be less chance of any issues.
Here are some goals of what should be possible with node state:
Easy to read and write to node state within application code (outside of graph evaluation). This is necessary to allow for custom serialization approaches, to allow for GUI to reflect the state of nodes within the graph and to pass the results of graph evaluation to and from I/O where necessary. This seems to imply that the user should likely own all state within the application process code itself and only references when necessary to the graph evaluation process.
Easy to pass mutable access of node state to the graph for graph evaluation. We want to avoid borrow-checker awkwardness and unsafety as mentioned above.
Application state should be accessible when creating new nodes and in turn new node states. This probably rules out having the graph just own all the state and using something like Default to initialize new instances. That said, it might be possible to provide some trait or something that allows for application state to be accessible when creating new node instances.
Potential Solution
Perhaps one solution might be to create a data structure in which the user is expected to store all state. Maybe this could be a kind of rose tree constructed using Vecs whose ordering precisely matches the node ordering within the gantz graph? We would need to ensure that this data structure and the graph itself are always updated together in order to be able to guarantee that their indices match and can be relied upon when retrieving references for graph evaluation. It's not yet clear to me whether or not the graph should own this state or the application should. In a way, the application will own the graph state either way as it also owns the graph, but the indirection may get frustrating from a usability point of view.
The text was updated successfully, but these errors were encountered:
This is a quick hack to get the nested graph working as a proof of
concept. The test successfully calls the root graph which in turn calls
into the inner nested graph to produce the correct result for the
following assertion. nannou-org#44 should be addressed next.
Closesnannou-org#20.
This is a quick hack to get the nested graph working as a proof of
concept. The test successfully calls the root graph which in turn calls
into the inner nested graph to produce the correct result for the
following assertion. nannou-org#44 should be addressed next.
Closesnannou-org#20.
Currently, gantz uses a very ad-hoc approach of passing slices of
Any
trait objects into the evaluation functions in order to provide access to state for nodes and nested graphs. There are two major issues with this approach:Any
trait becomes unusable for this approach once non-std types are involved (seestd::any::TypeId
returns different results for the same non-std type in different binaries. Switch to something else for feeding state through nested graphs. #43). We can work around this by simply using*mut ()
instead and casting them to the expected type internally, but this is obviously highly unsafe and would easily lead to a lot of errors with the current, awkward slice-passing approach.It would be nice to come up with some kind of type-safe abstraction that could solve both of these issues. This will likely have to wrap a raw pointer at the boundary, but at least if these raw pointers could be created and downcasted behind some safer API there would be less chance of any issues.
Here are some goals of what should be possible with node state:
Default
to initialize new instances. That said, it might be possible to provide some trait or something that allows for application state to be accessible when creating new node instances.Potential Solution
Perhaps one solution might be to create a data structure in which the user is expected to store all state. Maybe this could be a kind of rose tree constructed using
Vec
s whose ordering precisely matches the node ordering within the gantz graph? We would need to ensure that this data structure and the graph itself are always updated together in order to be able to guarantee that their indices match and can be relied upon when retrieving references for graph evaluation. It's not yet clear to me whether or not the graph should own this state or the application should. In a way, the application will own the graph state either way as it also owns the graph, but the indirection may get frustrating from a usability point of view.The text was updated successfully, but these errors were encountered: