-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement Node
for Graph<N>
where N
Node
#20
Comments
mitchmindtree
added a commit
to mitchmindtree/gantz
that referenced
this issue
Jun 13, 2019
This allows for optionally specifying the full types of the inputs and outputs of a `Node` during implementation by allowing to specify a full, freestanding function, rather than only an expression. The function's arguments and return type will be parsed to produce the number of inputs and outputs for the node, where the number of arguments is the number of inputs, and the number of tuple arguments in the output is the number of outputs (1 if no tuple output type). Some of this may have to be re-written when addressing a few follow-up issues including nannou-org#29, nannou-org#19, nannou-org#21 and nannou-org#22, but I think it's helpful to break up progress into achievable steps! Closes nannou-org#27 and makes nannou-org#20 much more feasible.
mitchmindtree
added a commit
to mitchmindtree/gantz
that referenced
this issue
Jun 13, 2019
This allows for optionally specifying the full types of the inputs and outputs of a `Node` during implementation by allowing to specify a full, freestanding function, rather than only an expression. The function's arguments and return type will be parsed to produce the number of inputs and outputs for the node, where the number of arguments is the number of inputs, and the number of tuple arguments in the output is the number of outputs (1 if no tuple output type). Some of this may have to be re-written when addressing a few follow-up issues including nannou-org#29, nannou-org#19, nannou-org#21 and nannou-org#22, but I think it's helpful to break up progress into achievable steps! Closes nannou-org#27 and makes nannou-org#20 much more feasible.
mitchmindtree
added a commit
to mitchmindtree/gantz
that referenced
this issue
Jun 15, 2019
This is a WIP implementation of the **Node** trait for graph types of nodes that also implement the **Node** trait. This work goes toward allowing nesting of graphs within graphs, the primary form of abstraction for gantz graph projects. This works by producing an **Evaluator::Fn** from the **Node::evaluator** method, where the number of inputs to the generated function declaration match the number of inlets, and the output type matches the number of outlets. The implementation is generic over all graph types, so long as they are able to generate a function body for the generated declaration mentioned above. This requirement is specified via the **graph::EvaluatorFnBlock** trait. An implementation exists for the graph type used within the project module - it is currently incomplete but specifies the necessary steps for completion once state handling is added. Progress on nannou-org#20.
mitchmindtree
added a commit
to mitchmindtree/gantz
that referenced
this issue
Jun 17, 2019
This adds rough support for node state that persists between calls to evaluation functions. Currently, node state is made available in evaluation functions via an added `&mut [&mut dyn std::any::Any]`. Eventually, this should be changed to a friendlier `node::States` type or something along these lines, however this will first require some way to make such a type available to the generated crate. This might mean splitting this type into its own crate so that it may be shared between both gantz, generated crates and user crates. For now, the `Any` slice only requires `std` and seems to work as a basic prototype. A simple counter.rs test has been added in which a small graph containing a counter node is composed, compiled, loaded, evaluated three times and the result is asserted at the end. I'm not sure if Rust's unstable ABI will begin causing more issues with larger types, but for now this seems to be working consistently OK with primitive types on Linux. This should make it possible to finish nannou-org#20. Closes nannou-org#19.
mitchmindtree
added a commit
to mitchmindtree/gantz
that referenced
this issue
Jun 17, 2019
This adds rough support for node state that persists between calls to evaluation functions. Currently, node state is made available in evaluation functions via an added `&mut [&mut dyn std::any::Any]`. Eventually, this should be changed to a friendlier `node::States` type or something along these lines, however this will first require some way to make such a type available to the generated crate. This might mean splitting this type into its own crate so that it may be shared between both gantz, generated crates and user crates. For now, the `Any` slice only requires `std` and seems to work as a basic prototype. A simple counter.rs test has been added in which a small graph containing a counter node is composed, compiled, loaded, evaluated three times and the result is asserted at the end. I'm not sure if Rust's unstable ABI will begin causing more issues with larger types, but for now this seems to be working consistently OK with primitive types on Linux. This should make it possible to finish nannou-org#20. Closes nannou-org#19.
mitchmindtree
added a commit
to mitchmindtree/gantz
that referenced
this issue
Jun 17, 2019
This adds rough support for node state that persists between calls to evaluation functions. Currently, node state is made available in evaluation functions via an added `&mut [&mut dyn std::any::Any]`. Eventually, this should be changed to a friendlier `node::States` type or something along these lines, however this will first require some way to make such a type available to the generated crate. This might mean splitting this type into its own crate so that it may be shared between both gantz, generated crates and user crates. For now, the `Any` slice only requires `std` and seems to work as a basic prototype. A simple counter.rs test has been added in which a small graph containing a counter node is composed, compiled, loaded, evaluated three times and the result is asserted at the end. I'm not sure if Rust's unstable ABI will begin causing more issues with larger types, but for now this seems to be working consistently OK with primitive types on Linux. This should make it possible to finish nannou-org#20. Closes nannou-org#19.
mitchmindtree
added a commit
to mitchmindtree/gantz
that referenced
this issue
Jul 26, 2019
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. Closes nannou-org#20.
mitchmindtree
added a commit
to mitchmindtree/gantz
that referenced
this issue
Jul 26, 2019
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. Closes nannou-org#20.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently an implementation exists in the graph.rs module where each of the methods are
unimplemented!()
.To implement this properly this requires
Inlet
andOutlet
nodes to specify inputs and outputs of the expression to generate for the graph.n_inputs
andn_outputs
would then be the number ofInlet
andOutlet
nodes respectively.The
expr
implementation might be tricky. Generating a function with the same number of inputs and outputs doesn't make sense, as different inputs might be triggered with different numbers of connections (see #17). The easy way would be to simply inline evaluation of the whole graph in a large code block, but this likely wouldn't be friendly to compilation times. A proper solution might follow solving #19 by using some state to help manage the inlet and outlet boundaries.The text was updated successfully, but these errors were encountered: