plasmodic/ecto — pull request #260 by stonier (2014-08-02 07:36:07+00:00)
Title: Directed graph configuration

Currently the configuration process that occurs when you do `configure_all` is an unsorted process. I would like to push this through a directed graph, so the results of one cell's configuration can be transferred to the next so that it can configure itself appropriately.

The current workaround is to execute such a directed graph once, which is somewhat awkward, because it now means I have cells hanging around for the whole execution whose only purpose is for configuration AND I have to have branching code in the process call which checks to see if variables have been initialised or not.

e.g. I would like to have a cell which accepts a yaml string that converts to a camera info structure. This yaml string can come from various places depending on the program. Some example cell configurations:

```
# A testing configuration when I have the yaml configuration locally
loadYaml -> camerainfo
```

```
# gets the yaml string as a package from across a socket connection to the image board
image_bridge -> camerainfo
```

```
# A useful configuration when running a bag
rosparam2yaml -> camerainfo
```

Even the camera info cell itself is only needed at configuration time - doesn't need to hang around for execution.

So...directed configuration? I wonder if this was originally intended. I noticed that the incoming and outgoing tendrils as part of the `configure` function arguments are currently just dangling and good for nothing. So I suspect this is something that was originally planned.

Anyway, code for such a directed configuration is in this pull request. Has minor modifications - most important points:

* Uses boost's depth first sort (for simplicity) rather than the custom breadth first sort built into the scheduler. I don't know the original motivation for the bfs (there's a todo in the comments in the scheduler), so if there is a good reason for that, we can certainly pull that code out and share it with the plasm like I have for the move_input/move_output calls.

* `invoke.cpp/invoke.hpp` -> `graph_utils.hpp/graph_utils.cpp` : just takes the old code out of the ecto::schedulers namespace which would be strange from the plasm's perspective.