Skip to content
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

Closed
mitchmindtree opened this issue Mar 25, 2019 · 0 comments · Fixed by #45
Closed

Implement Node for Graph<N> where N Node #20

mitchmindtree opened this issue Mar 25, 2019 · 0 comments · Fixed by #45

Comments

@mitchmindtree
Copy link
Member

Currently an implementation exists in the graph.rs module where each of the methods are unimplemented!().

To implement this properly this requires Inlet and Outlet nodes to specify inputs and outputs of the expression to generate for the graph. n_inputs and n_outputs would then be the number of Inlet and Outlet 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.

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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant