Closed ghost closed 7 years ago
From marin...@gmail.com on May 13, 2010 08:10:29
Have you looked at how JSoar does I/O? It's also a slimmed down approach with some additional plusses (e.g., being able to run each agent in its own thread).
This page contains links to additional info: https://code.google.com/p/jsoar/wiki/JSoarUsersGuide
Cc: daveray
From joseph...@gmail.com on May 13, 2010 09:47:40
From a very brief look it appears that JSoar communication only takes place in a shared memory space, which is not what I'm aiming for here. I'm also not particularly fond of threads in general. But I think it would be easier to implement what I'm proposing here on top of JSoar than CSoar. In fact it would probably be trivial given what is there already.
From dave...@gmail.com on May 13, 2010 10:09:40
I was going to say about the same thing. JSoar's API is different and more powerful than SML's but not a ton simpler. Implementing your protocol in JSoar would be pretty trivial. JSoar's "quick" memory stuff is kind of similar, but still in-process: http://darevay.com/jsoar/0.8.0/docs/jsoar-core/api/org/jsoar/kernel/io/quick/QMemory.html http://darevay.com/jsoar/0.8.0/docs/jsoar-core/api/org/jsoar/kernel/io/quick/SoarQMemoryAdapter.html you basically just read and write path/value pairs and all the callbacks and thread safety stuff is taken care of.
Did you have any thoughts on run control? That is, does the environment have any control over whether the agent is running? Or is that handled by something else?
Is the protocol blocking, i.e. will the agent wait for output to be handled before proceeding?
Finally, is the copy of the output link just a list of WMEs, and the client is responsible for traversing it? If so, then you could also just send output as a list of changes like input. This would be tricky in SML, but this is how the output-link code in the raw kernel and JSoar already work so it would be really easy there.
Are strings always quoted to differentiate from ids? How are newlines escaped?
I think it's a cool idea.
From joseph...@gmail.com on May 13, 2010 10:43:17
I was thinking that all run control and debugging related functionality should be handled separately from the environment communication protocol. The simplest way, and the way I was thinking of doing it, was just to let the user enter commands into the stdin of the Soar process and have any output go to stdout. This way io handling in the Soar kernel will be very straightforward and we can get rid of all the XML calls. If we want to get fancier with a graphical debugger, we can just write a program that communicates with Soar's stdio and presents the output differently to the user. We'd have to change the output format of Soar a little to be more machine friendly but still clear to humans. For example it shouldn't try to arbitrarily wrap long lines like it does now. If there needs to be coordination between running the agent and running the environment, the user can always spawn a third process that controls the execution of both the Soar and environment processes via stdin of both processes.
The protocol as I've implemented it in python is blocking. If we want asynchronous execution of the environment and Soar, we can always write a program that acts as a message buffer that sits between Soar and the environment.
Sending changes for the output link is definitely a possibility. I had thought that this might present a synchronization issue but now I don't think this would be a problem. The key is to not allow the environment to create arbitrary wmes on the output link as SML does. Since status attributes are so conventional, I've currently compromised by allowing the environment to send string status values for every command, but make it solely up to the Soar side what to do with these. In other words the environment shouldn't expect that the statuses will be reflected in the next state of the output link in any way.
As for string quoting and all that, they're details that need to be worked out. I'm thinking of going with single quotes and backslash escapes that are conventional in unix. So newlines would be represented as \n.
From dave...@gmail.com on May 13, 2010 18:04:51
It seems like your approach is doable, but I'll take a slightly more conservative approach. Add your I/O system to the base kernel, but leave SML (and all the XML and other stuff) in place. Then when you need a debugger or whatever, SML is still there to provide that. I can't say whether SML would be amenable to additional I/O stuff going on behind it's back, but I think this would give the best of both worlds. If I added this to JSoar, I'd leave the existing I/O and run control stuff alone and just hang this socket based code off the agent as another I/O provider.
Does the protocol allow multi-valued attributes? It's not really necessary, especially if the idea is to keep things simple.
Finally, randomly, since it's a synchronous protocol, I wonder if using HTTP might make sense. In most scripting languages setting up an HTTP server is usually one line of code. If anything, it's a simple protocol that almost everyone understands.
From voigtjr@gmail.com on May 13, 2010 19:07:50
Does the protocol allow multi-valued attributes?
Speaking of multi-valued attributes, do any of these input schemes allow other-than- string attributes? Apologies for asking instead of looking this up. I think any future IO system should support all legal symbol types for attributes.
From joseph...@gmail.com on May 13, 2010 19:08:07
Well I already have the SML implementation that lets me run and debug environment programs in a separate process, and I'm pretty satisfied with that. In fact that was the main reason I made this thing in the first place. I don't see too much incentive in rewriting the protocol to be native to the kernel except as an experiment to rip out SML. I'm going to hold off on that until I'm reasonably sure that the protocol can accommodate most use cases. Also, the protocol will probably evolve, and I'd rather evolve 200 lines of python than a couple thousand of C.
I was looking at previous Soar workshop talks today and it was interesting to see that SGIO, GSKI, and SML were all introduced in consecutive years. A lot of code must have been typed in the name of Soar connectivity those 3 years. The thing I still don't understand is why all those systems unified communication and control. It seems most natural to me to separate the two issues. Control is naturally more coupled to execution, and a separate concern from communication.
I didn't make any special provisions for multi-valued attributes but I don't see why they wouldn't be supported.
I guess I don't see why HTTP would be necessary. As it stands the messages are sent without any headers, wrappers, or handshaking protocols. Is this naive?
From joseph...@gmail.com on May 13, 2010 19:13:27
The python version expects only string attributes and since it uses SML that implementation is stuck with it. But there's nothing in principle preventing the communication of identifier or numeric attributes.
From dave...@gmail.com on May 13, 2010 20:34:45
Yeah, when I got this message I thought "it wouldn't be Soar workshop time if there wasn't a new I/O system implementation" :)
HTTP is a random idea. It probably doesn't make any difference.
Integrating directly into the kernel is something I wouldn't want to do either. Java's not that fun to write either, but at least it has support for silly stuff like sockets. If the Python interface works, stick with it.
I'd be interested to know what kinds of environments this is appropriate for. For example, would you build Eaters or TankSoar with it? Only "batch" runs?
From joseph...@gmail.com on May 13, 2010 00:35:03
Currently I see several problems with SML:
It seems to me that it should not require such a large library to facilitate communication between Soar agents and task environments. 99% of what is needed is just communicating WM state. So I'm proposing an alternate interface for Soar:
(a|d|u) []
...
%
where a = add, d = delete, u = update. The % marks the end of the message. Output link contents will be sent as lines of triples