1 / 6

An Uncoupled Interface to Soar using SML

An Uncoupled Interface to Soar using SML. Pearson, Marinier, Stokes Dunham, Voigt. System Architecture. Soar Kernel. Soar 8.6 Kernel (C). gSKI. Higher-level Interface (C++). Encodes/Decodes function calls and responses in XML (C++). KernelSML. SML. Soar Markup Language.

adonis
Download Presentation

An Uncoupled Interface to Soar using SML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. An Uncoupled Interface to Soar using SML Pearson, Marinier, Stokes Dunham, Voigt

  2. System Architecture Soar Kernel Soar 8.6 Kernel (C) gSKI Higher-level Interface (C++) Encodes/Decodes function calls and responses in XML (C++) KernelSML SML Soar Markup Language Encodes/Decodes function calls and responses in XML (C++) ClientSML Wrapper for Java/Tcl (Not needed if app is in C++) SWIG Language Layer Application Application (any language)

  3. Features • Embedded or socket connections • Multiple language support for applications • Combined debugging and I/O interface • Dynamic connection/disconnection • Tools less tightly tied to particular Soar version • Often faster than 8.5.2 interfaces • Logical structure to output from kernel

  4. Why SML + gSKI? • Why not SGIO? • SGIO couldn’t support debugging a kernel embedded in a simulation • Difficult to extend as embedded/remote decision happens at top level of SGIO, so two internal implementations for all commands/structures • Kept the SGIO interface (largely) for clients connecting through SML • Why not C API • No direct support for remote connections • No support for dynamic connection/disconnection • Tight binding between tools and the kernel, so a change to either requires a rebuild of both • Not as clean of an API as gSKI • Filled the same role as gSKI but with less encapsulation of objects

  5. Optional Use Models • Ignore SML completely and just link to gSKI • Send raw XML data to/from the kernel • Build on our client side implementations which hide most of XML communication • Use just the “SGIO” portion to build an I/O interface • Use just the “debugger” portion to build a debugger or command line tool • Use it all to build a combination tool or something we’ve not seen before

  6. Future (as of April 2005) • Improve the robustness of interactions between SML systems (it’s still early days here) • Applications • Java Eaters • Java TankSoar • Extend the Java Debugger to new capabilities we haven’t had before • Make better use of the new structured (XML) output from the kernel • Add new features to support debugging to the kernel • Embed Java Debugger and Visual Soar inside Eclipse as plug-ins to create an IDE.

More Related