I can build a convert function that turns the static arrays into lists, which then get passed out. The problems:
- Whenever the field is accessed, it goes through the static array conversion
- Pickle doesn’t “just work”
- Pickle, in fact, has to go through another set of conversions and have setter methods as well, which it just doesn’t want to do
I’ve posted to the python-c++ list to ask if there is a Better Way. There are three options (a) there IS a Better Way (b) I manually extract the data from the objects once it’s in Python, building up native python objects or (c) rewrite SSPS in Python.
Given the current situation, I’m going to work on (b).
Here’s the doc page for the Python
logging facility.
…Is actually very easy. lxml for Windows is distributed as an egg file, which can be installed with a single command (once you have the egg utility). Egg is part of the
Python Enterprise Application Kit (PEAK). After some initial drama finding the correct version of Python on my system, I got lxml working pretty quickly. Using it is very simple:
from lxml import etree
agentschema="agent-schema.xsd"
tree=etree.parse(filename)
schema_doc=etree.parse(agentschema)
if (tree.xmlschema(schema_doc)):
print "***Processed " + filename + " successfully."
else:
print "***Error in " + filename + "!"
This parses and validates an xml file according to a schema (in this case, agent-schema.xsd). Once it has been parsed and validated, XPath is probably the best choice of tree navigation to use, as it provides a simple way to query elements; it’s definitely more pleasant than walking the tree manually. The lxml page has good instructions on how to use XPath.
Writing Schema, on the other hand, is a bit trickier. www.w3schools.com has a good tutorial on how to build schema (just note that it seems to incorrectly use xs instead of xsd throughout the examples– it is in fact xsd:schema, etc. for the tags). In addition, I’ve written up most of the CML language from Funge as an schema already, but I still need to go back to his masters thesis to find the full grammar for it. This will give us at least a starting point for bringing in agent definitions for the core.
The Python
generator functions seem like a very useful tool for the agent core. The yield statement causes a function to return a generator function when called. The generator function doesn’t do anything until the .next() method is called on them, and then it runs until it hits the first
yield statement, which returns a value. Execution is halted until .next() is called again, but all state is saved.
So it seems like the possible building blocks of an agent could be classes with generator functions, which can be assembled into a full agent brain. The first couple of yields could return quick and dirty heuristic output, and subsequent calls can improve upon the initial guess. This gives us a nice way to set up for anytime processing. The only question is how much overhead is involved in saving and restoring generator state.
I think it comes down to threads vs. generators. Using the generators would help avoid some of the messiness of using threads and potentially provide more predictability of the code, but at some performance cost.