Axon

Axon is the core subsystem in Kamaelia

Axon forms the core of Kamaelia. The following modules in Axon are listed in importance order, and are likely to be the ones you will be interested in. (Importance in terms of the viewpoint of a user of the system)

• __init__.py
• Component.py
• Scheduler.py
• util.py
• Ipc.py
• AxonExceptions.py
• AdaptiveCommsComponent.py
• CoordinatingAssistantTracker.py

The remaining modules in Axon are listed below in importance order, and you are unlikely to be the ones you will be interested in.

• debug.py
• Linkage.py
• Axon.py
• Microprocess.py
• Postman.py
• debugConfigFile.py
• idGen.py

The following text is adapted from the README bundle that accompanies Axon's separate download...

Axon is the core of Kamaelia. The contents of this directory must be installed before the rest of Kamaelia can be used. It can also be used independently of Kamaelia.

The install procedure is python's usual dance:

• python setup.py install

Documentation is held in two places: (until this section is complete)

• The usual 'pydoc name' - probably worth starting with:
  pydoc Axon.Component
• The test suite is designed to allow you to get low level API behaviour information - "should X,Y, Z work? If so, what happens?". It's a partly retrofitted test suite, but some is TDD. (TDD took over late in the project) As a result, for example, passing a -v flag result in the docstring for each test to be dumped in a form that allows collation, and summarisation. (For an example of what we expect to automate from the test suite, see the end of this README file)

Sample producer/consumber & wrapper component system:

/-- testComponent -----------------------------------------------\
| |
| +-- Producer ----+ +-- Consumer ----+ |
| | |result|--->|source| |result|--->|_input||
| +----------------+ +----------------+ |
| |
\----------------------------------------------------------------/

The testComponent creates 2 subcomponents, creates the links in place, and takes the output from the consumer and links it to its own private/internal _input inbox. When it recieves a value from the consumer, it reports this fact and ceases operation.

• Producer sends values to its result outbox
• Consumer takes values from its source, does some work and sends results to its outbox

(It's probably worth noting that an introspection system would be possible to write/nice to see that would be able to derive the above diagram from the running system)

Example code:

class Producer(component):
Inboxes=[]
Outboxes=["result"]
def __init__(self):
self.__super.__init__()
def main(self):
i = 100
while(i):
i = i -1
self.send("hello", "result")
yield 1

class Consumer(component):
Inboxes=["source"]
Outboxes=["result"]
def __init__(self):
self.__super.__init__()
self.count = 0
self.i = 30
def doSomething(self):
print self.name, "Woo",self.i
if self.dataReady("source"):
self.recv("source")
self.count = self.count +1
self.send(self.count, "result")
def main(self):
yield 1
while(self.i):
self.i = self.i -1
self.doSomething()
yield 1

class testComponent(component):
Inboxes=["_input"]
Outboxes=[]
def __init__(self):
self.__super.__init__()
self.producer = Producer()
self.consumer = Consumer()
self.addChildren(self.producer, self.consumer)
self.link((self.producer, "result"), (self.consumer, "source"))
linkage(self.consumer,self,"result","_input", self.postoffice)
def childComponents(self):
return [self.producer, self.consumer]
def mainBody(self):
while len(self.inboxes["_input"]) < 1:
yield 1
result = self.recv("_input")
print "Consumer finished with result:", result, "!"

r = scheduler()
p = testComponent()
children = p.childComponents()
p.activate()
for p in children:
p.activate()
scheduler.run.runThreads(slowmo=0)

(It would probably be nice to have better syntactic sugar here by using dictionaries, operators (eg '|' ) and decorators. The presentation on the website on Kamaelia shows a partial semi-reimplementation of ideas using decorators to eliminate the classes above)

For various reasons it makes sense to run all Axon code using the -OO flags - this is due to the currently highly inefficient debug framework. One downside of async systems is that debuggers tend to have a hard time - but this has been thought of upfront :), the downside is that if you run with debugging enabled/possible, then the system runs like a pig. (Due to some rather heavy duty fumbling around in the garbage collector)

Michael, December 2004