The Magic Farm¶
A collection of objects, each a magic.Ball, some that start and run.
Connected in a graph.
Each edge of the graph, an information pipeline.
A magic.Shepherd to take care of it all, also a magic.Ball.
Connections to the outside world such as teakhat.Hat.
Wouldn’t it be nice if the farm could sort out itself, connect things up so it all runs along?
Perhaps a magic.RoundAbout or two will help?
Unix philosophy¶
Think of magic.Ball as a process and all the edges just unix files, streams of bytes. Except each stream is a stream of python objects.
It is tempting to restrict things to having at most one input and at most one output. In this case we would have:
information sources: no input, one output
information sinks: one input, no output
filters: one input, one output
cpu hogs? no input, no output
But even filters might also need to listen to keyboard input asking to change the filter parameters?
In general, a process has no idea what its inputs and outputs really are.
It would be good to be able to write something like:
value = await self.input.get()
In a way that lets other objects manipulate self.input.
So perhaps, the following for getting things in and putting things out:
data = await self.magic.get()
status = await self.magic.put(data)
And if you want to use something other than the default queues:
key = await self.magic.get('event')
status = await self.magic.put(data, 'image')
Ball.get and Ball.put actually work with ball.radii which is some sort of magic.RoundAbout.
So have a shepherd or two or more to take care of all the balls and roundabouts.
Graphs showing connection, one shepherd per connected graph in the bigger picture.
File systems¶
If farm graph is a tree?
Queue names as pathlib.Path
stdin, stdout, stderr ?
And finally…¶
Here’s the docs from the `blume.farm` module.
Split the farm from magic.
The reason for this split is a growing belief that almost everything in the farm, and the Farm itself should be some sort of Ball.
And wanting the default Farm to have a basic structure running with everything a typical Ball might need, it needs to import some examples from other modules. Since those modules use magic, the end result is a circular import.
This splt also allows me to think about what lives where. And how everything relates.
Plan¶
This Farm is currently just a directed graph. It feels like round abouts should be the graph nodes, with their edges being the graph edges.
That should simplify things a little from the current code.
I would like to change how the graph connects objects dynamically, in a similar way to the way I can change attributes of running Ball’s with the magic.Interact object.
The Farm seems the right place – or maybe the Shepherd?
Objects with a start and a run.
That might start and run each other.
Balls can write things to a queue.
The plan in magic land is to get the magic roundabout working.
At the moment there is a magic roundabout for each Ball.