maintainer: Noel Bush
previous authors: Noel Bush, Kim Sullivan, Thomas Ringate, Pedro E.
Colla
Last updated: 12 Mar 2006
The latest version of this document can always be found at http://aitools.org/programd/docs/release-notes.html. Probably.
Versions documented here:
This is a highly-recommended release which preserves AIML functionality, introduces some interesting perforamnce improvements, fixes a number of important bugs, and brings some major architectural improvements—most notably, Program D can now be deployed as a .war file to a web application server, and can interact with a web client using "Ajax" technologies.
Several strategic optimizations have dramatically increased the number of bots that Program D can handle, improved response rates, and reduced memory usage. Most notably, if you have bots that share AIML files, Program D will now detect this, and will use a shortcut at loadtime to rapidly add an association with the AIML file for the new bot, without actually re-parsing the entire AIML file.
At long last, Program D is now a "proper" web application, in J2EE terms. The bundled web server, and associated dependencies, have been removed, and you may now deploy Program D as a .war file on any J2EE web application server. Testing has been primarily with Tomcat, but theoretically this should work with any open source or commerical Java web application server.
The web pages for Program D are now JSP pages. Program D includes a couple of AIML-JSP tags that can be included in such pages.
The "simple console" and "simple GUI console" modes are still available, and of course if you only need Program D for IM/IRC connectivity, then one of these (probably the non-GUI version) will be your choice. (But please see the aitools.org web site and Program D mailing list for the latest word on IM & IRC compatibility issues with those listeners—lately there have been some problems.)
Program D can now be easily used with "Ajax" technologies. Included in the download is a simple working example, making use of the DWR Ajax toolkit. This example can be viewed by deploying the Program D .war file to a J2EE application server.
The interactive shell has a couple of new commands: /memory, which provides statistics on memory usage, and /categories, which shows the number of loaded categories.
The logging mechanism for Program D has been vastly improved by replacing the off-the-shelf JDK logging mechanism with the vastly superior Log4J library. Logging to text files, XML files, and databases is still supported, and is now configured in the log4j.xml file.
The following bugs have been fixed in version 4.6:
This was resolved in a release candidate for 4.5, but some reports indicated it may have resurfaced in the final release. In any case, this is fixed in 4.6, and what's more, the entire logging infrastructure has been redone (see above), so database logging should also show better performance and more flexibility.
This issue is resolved by the use of JSP and the web server architecture. Botmasters now have full control over which templates are used for which requests, using the application server's mechanisms for mapping URLs.
Authentication may now be configured at the application server level.
This issue was caused by a problem in the substitution mechanism, and actually affected all substitution operations (although not all operations produced incorrect results with this bug). It has been corrected, and a new test case has been added to the AIML test suite to verify it.
This has been corrected, and a new test case has been added to the AIML test suite to verify it.
This issue has been obviated by the switch to the web application architecture. There is now an error page (customizable, of course) that can be displayed when an error occurs in Program D.
This issue arose because whitespace was being "normalized" in several places in the Program D code, with the intention of obeying the specification. A solution has been implemented which does not technically match the specification, but which does not seem to preclude producing the desired results in any case. Basically, for now, whitespace is generally not normalized, but is preserved as specified in the original AIML document. The determination of how to handle whitespace is left to the client, rather than determined by the AIML interpreter. A web browser will, as usual, normalize whitespace within all elements except a <pre> element-precisely the desired behavior. This strategy actually makes more sense, since without this, the AIML interpreter would need to either (a) require that all whitespace-preserving elements have the xml:space attribute set to "preserve" (an undesirable requirement for the user to duplicate information that already exists in the DTD/schema for the foreign namespace), or (b) at runtime, access the DTD or schema for a foreign namespace, and check for xml:space attributes in that specification and process accordingly (a significant performance issue). My research indicates that the proper handling of this issue in any XML application is not a settled matter, and thus for the moment I am content to provide a solution which will in any reasonable circumstance allow the desired result to be achieved. At some future point, this may be revisited.
Listeners in general are a lot of trouble, because IM protocols, and even IRC practices, change very often. Specialized libraries exist to allow applications to communicate using these protocols, and the listeners for Program D depend on these libraries. Unfortunately, these libraries are not always well maintained, or are not Java-based, or are not open source/free. However, with all that said, the Program D core should not crash simply because a listener cannot connect or has some other error. As also noted in issue 99 (next item), the Program D code was previously much too skittish about error conditions, and pretty much gave up the ghost whenever any serious error occurred. That has now been corrected, and as a result, issues with listeners should not impact the core (even if the listeners themselves have unrelated problems).
In an attempt to motivate myself to quickly fix problems in the Program D code, I created a subclass of java.lang.Error called DeveloperError. This was to be thrown in cases where some error occurred that I felt could be reasonably blamed on the Program D code, rather than some third party. In the event of a DeveloperError, Program D was set up to terminate immediately, with a message reflecting negatively on the developer (me) and providing diagnostic information. However, it turns out that this approach was far too aggressive, and was needlessly causing the program to commit suicide in many cases where it could have reasonably recovered and continued execution. Therefore, I have re-thought this whole strategy, and made two changes: (a) DeveloperError is used far less than before, and (b) in cases where it is used, it is not allowed to kill the application. As much as possible, Program D will attempt to continue execution no matter what happens.
Kim Sullivan discovered that <srai><star/></srai> operations were improperly returning with modified <star/> contents—in other words, the initial value of the <star/> would be replaced by the new value obtained by the srai'ed match. This bug has been fixed, and a test case provided by Kim has been added to the test suite to verify the fix.
Here are notes about the release candidates.
This release includes adjustments to the script/batch files that should make installation of listeners easier. It also includes some memory use optimizations. Otherwise, nothing has changed from rc3, which seems to have done well overall.
This release improves URL resolution in an attempt to address problems with users of Tomcat on Windows.
A bug was discovered by Frank (Mehri) that caused wildcards not to work properly when loading multiple files on Windows. This has been fixed.
The requirement that Program D not be installed in a path with spaces on Windows has been removed.
A mistake in the common-functions.bat file was causing listener jars not to be found. This has been corrected.
Program D requires JDK 5.
If you want to build Program D from the source distribution, you can easily import it into a Java IDE such as Eclipse. Or you can use the included Ant buildfile, which is the same file used to create the binary distributions. You will need to have Ant installed.
To use Program D with a web interface, you will need to run a web application server. Some free/open source suggestions are: Tomcat, JBoss, or Jetty. For quick start instructions, see the Readme file.
The AIML schema's Schematron directives are not yet used at load time.
Bug 0000014 ("merge-combine incorrectly unescapes XML entities") has not been addressed.
Class-level unit testing is not yet implemented.
This is the first release of Program D in three years. During this time, Program D has remained the most widely used open source / free AIML interpreter in the world. It has been employed in numerous projects, from personal-sized art projects to large, enterprise level deployments. The stability and consistent performance achieved in version 4.1.5 have proven enduring and reliable, despite the hiatus in available support.
This new release focuses on updating the Program D technology to take advantage of progress in technologies available as part of the core Java platform. Core functionalities such as XML parsing, logging, and various architectural matters are now handled in a fashion that heightens stability, performance and maintainability.
We have finally addressed the issue of component orientation: Program D can now be easily included into any application framework as a simple "core" object, without ever involving any undesired interfaces (servlet container, IM interface, etc.). On the other hand, these optional interfaces now use a more flexible and better defined API to connect to the Core, and we are confident that additional interfaces may now be provided with far more ease than before.
Every line of code of Program D has been reviewed, and "refactored" as appropriate. The program still passes all of the AIML 1.0.1 test cases published with the previous version, as well as a few more.
Following are details of what has been addressed. Please note that, as of the final release, items originally found only under the Release Candidate Notes section have been included here, when appropriate.
The architecture of Program D has been thoroughly re-worked to make a clean separation between the "core" parts of the program-those which load AIML, parse inputs, and produce a response-and other parts, such as IM interfaces, web server interfaces, and so on. It is possible to instantiate the Program D Core object and configure it entirely programmatically, without manipulating any configuration files, if that is required.
In the simplest form, using Program D from another program looks like:
Core core = new Core();
core.setup();
core.start();
String response = core.processResponse("hello");
The Core can be (and usually is) initialized with a properties file. The additional setup() step is separated out so that, for instance, consoles can be connected to the Core before proceeding with initialization. Following setup(), there is again the opportunity to do any further setup of other components before calling start() on the Core. The getResponse() method comes in several forms, including those that allow the specification of a particular bot, and the use of a Responder object to format input and output.
For examples, see the classes provided in the org.aitools.programd.configurations package.
The old .properties file has been replaced with several XML-formatted equivalents. Configuration is broken up among optional components-all configuration of the Core happens in conf/core.xml, of the console in conf/console.xml, and so on.
Each of these configuration files corresponds to a class which is automatically generated using a simple (included) XSLT file. (The classes only need to be regenerated when the semantics of the properties are changed.) The generated class includes getter and setter methods for every property, so a Core object can be configured completely programmatically as well:
core.setRootDirectory("/usr/local/ProgramD/4.5-test");
core.setPredicateEmptyDefault("unknown");
// ...etc.
The "homegrown" XML parser included in previous releases has been replaced with a combination of SAX2 and DOM parsers now included as standard with the Java SDK. The results are very satisfactory. Not only is the new parsing performance at least as good as the old homemade stuff, but we now have built-in well-formedness checking and schema validation (see next note). The standard XML parsing technology is used in all aspects of the program where it applies: reading in AIML, parsing AIML templates at runtime, parsing bot configuration files, and parsing HTML templates (if used).
Additionally, the XML parsers in use have been configured to be namespace aware, which moves us farther in the direction of being a highly interoperable platform. For instance, any embedded HTML or XHTML must now be properly notated as to its namespace; this enables Responders and other tools to easily filter out (or not) markup belonging to one or another namespace, and to do it in an intelligent, configurable way, rather than relying on ad hoc heuristics that keep specific "knowledge" of HTML or some other format embedded in the engine.
Program D now ships with a W3C XML Schema for AIML (also available at http://aitools.org/aiml/schema/AIML.xsd). As AIML files are read in by the program, they are validated against this schema. Any errors are reported to the console and log files. As long as an error is not fatal, the remainder of the AIML continues to load.
Please note that this release includes a simple shell script (in the resources subdirectory) that cleans up the "AAA" AIML set, including various idiosyncratic errors.
Program D now uses the Java logging API to write information to log files and to the console. This provides for easier customization, and opens the door to cleaner integration with logging in larger systems.
The templates used by XML-oriented responders, like the HTMLResponder, now have a bonafide XML template language of their own. This template language includes a couple of new elements, logged-in and not-logged-in, which can be used to provide conditional output depending on the user's login status.
Substitutions (for input, gender, person and person2) are now specified as regular expressions. This lends a great deal more power and precision to the input normalization step, and to the gender, person and person2 processors. For a guide to the regular expression syntax that is available, see the JDK documentation.
The Responder architecture, especially the class formerly known as "SmartResponder" (now totally rewritten and called ServletRequestTransactionEnvelope) and the HTMLResponder, has been completely overhauled, addressing a number of serious design problems in the original. I'm open to suggestions for further improvements, but at last it is possible to say that the authentication system (a) makes sense as coded, (b) is decoupled from input and output formatting, and (c) is reasonably reusable. A complete set of example files to support user authentication is include in templates/html, and some important properties can be adjusted in conf/html-responder.xml.
Long overdue, this has at last been addressed comprehensively in 4.5. Now, if your AIML contains categories whose pattern:that:topic paths are identical, you can specify what should happen at loadtime. As your AIML is loaded, the program will decide what to do with the template in an already-loaded category whose path is matched by another category being loaded. These are the merge policy choices:
skip: Leave the currently loaded template in place and ignore the new one.
overwrite: Overwrite the loaded template with the new one.
append: Append the content of the new template to the currently loaded one.
combine: Store the new template as well, so it will have an equal chance of being used as the currently loaded one.
Albertas Mickensas's AIML testing system has been adapted to version 4.5. Now you can create test cases and test your AIML from the shell. (Uses the new shell command interface.)
The old set of AIML compliance test cases has been ported to the new test case framework. These are included in the Program D distribution. You can test Program D's adherence to the spec simply by typing /test in the shell.
A plugin architecture of sorts has been introduced; at first, this is geared only to plug-in shell commands. You can easily add a new command to be available from the shell by implementing a simple interface. To be documented.
A new shell command called /aiml now allows you to directly "execute" AIML template contents from the command line. Try, for example, typing: /aiml <date/>.
Eion Robb submitted a patch to 4.1.5 that fixed a fundamental problem with the Graphmaster.unload() method-namely, that it didn't work. His contribution has been incorporated into the current release.
All listeners have been moved out to separate package, now distributed independently (so they are not tied to engine releases). The ICQ/AIM listener was completely rewritten using a new library, and a Yahoo listener was introduced.
You can find pages describing the ICQ/AIM Listener, Yahoo Listener, and IRC Listener on the aitools.org web site.
This new version of Program D makes very extensive use of the new features introduced by JDK 5. The generics framework is used throughout the code to achieve a very high level of type safety, with far less verbosity, and virtually no (expensive) casting. Typesafe enums have also been employed to great effect in quite a few places. The enhanced for loop, which in almost all cases obviates the need for using an Iterator, has been employed everywhere possible. And in a couple of instances we make use of autoboxing/unboxing of primitive types.
Incorporating all of these improvements has made the code easier to read, and therefore to debug and maintain. In quite a few cases, performance gains also seem to have been realized.
This release also enforces tighter coding standards, including virtually all of those available from the compiler, including even the most "pedantic" conventions such as avoid unqualified access to instance variables. While some might argue that this makes the code bulkier, I would counter that Java is already bulky and wordy-this is just the nature of the beast-and it makes a lot of to take full advantage of the extensive compile-time checking that the platform can provide, in the interest of avoiding runtime errors. Why be half-hearted about it?
As always, the quest to find even better techniques for capturing runtime exceptions/errors goes onward. This release has received a thorough going-over in that regard. Each time I've found a crash-producing situation, I've avoiding fixing the error until I've found a satisfactory way to trap it, and if at all possible, log it. This kind of progress is always good, although I do think that Program D was already pretty well along with the last release.
Numerous bugs that were never widely known or reported have been fixed. Going forward, all new bugs should be visible in the bug tracking system, but there are no plans at the moment to retroactively publicly document all the problems that have already been found and corrected. Suffice it to say that the current codebase is significantly less error-prone, and more secure, than previous releases.
Here are notes about the release candidates and the final release.
Merge policies implemented-Long overdue, this has been addressed in time for the final release. Now, if your AIML contains categories whose pattern:that:topic paths are identical, you can specify what should happen at loadtime. As your AIML is loaded, the program will decide what to do with the template in an already-loaded category whose path is matched by another category being loaded. These are the merge policy choices:
skip: Leave the currently loaded template in place and ignore the new one.
overwrite: Overwrite the loaded template with the new one.
append: Append the content of the new template to the currently loaded one.
combine: Store the new template as well, so it will have an equal chance of being used as the currently loaded one.
Schema fix-The AIML schema had an incorrect definition for the pattern-side bot element, leading to incorrect error messages when loading AIML using this feature.
pattern-side bot elements-An implementation of the pattern-side bot element was missing; this was put in place.
listener packaging-All listeners were moved out to separate package, now distributed independently (so they are not tied to engine releases). The ICQ/AIM listener was completely rewritten using a new library, and a Yahoo listener was introduced.
web server script bug-The shell script and batch file for starting Program D did not properly set up the class path to be able to start the web server configuration. This was reported in several bugs. It has been corrected.
release checklist-A release checklist has been added to the build. This lists the things that will be tested before releasing a build. Any and all input on making this better will be enormously welcome.
Flash interface-Some problems that were preventing the Flash interface from working have been fixed. Daniel Ireland gave Chris Fahey's old Flash toolkit a full working-over, and now for the first time this is offered as part of the standard Program D distribution. Thanks, Dan!
AIML testing system-Albertas Mickensas's AIML testing system has been adapted to version 4.5. Now you can create test cases and test your AIML from the shell. (Uses the new shell command interface.)
AIML Compliance Test Suite-The old set of AIML compliance test cases has been ported to the new test case framework. These are included in the Program D distribution. You can test Program D's adherence to the spec simply by typing /test in the shell.
Plugin architecture-A plugin architecture of sorts has been introduced; at first, this is geared only to plug-in shell commands. You can easily add a new command to be available from the shell by implementing a simple interface. To be documented.
/aiml shell command-Added a new shell command /aiml that allows you to directly "execute" AIML template contents from the command line. Try, for example, typing: /aiml <date/>.
Listener configuration-Listeners are now configured by specifying a class name, rather than a special "label" string which is supposed to be matched by a listener class. Internally, the "ListenerRegistry" has been eliminated. This makes the listener architecture properly pluggable-you can literally write your own listener, add it to the classpath, and put configuration parameters in the configuration file, all without doing anything to the core of Program D.
other corrected bugs-Other bugs reported and discovered during the life of rc2 have been corrected, including:
0000006: XML templates reprint namespace URIs over and over again
0000008: Entire HTML response gets logged to database! (Thanks to "WildFox" for uncovering this one.)
0000009: PredicateMaster fails to save predicates after a while (Thanks to Albertas Mickensas for reporting this.)
The AIML schema did not permit element content inside the javascript or system elements. This has been corrected. Thanks to Daniel Ireland for discovering this.
This one follows hot on the heels of rc1, and includes the following fixes:
AIML Schema bug-The AIML Schema released with the previous version did not allow non-li content in condition elements; as a result, some valid AIML was rejected.
Bad default value for web-server conf-The default value of the web server configuration file, specified in core.xml, named a non-existent file. This would have caused confusion.
The first one is pretty critical, which is why this release is so soon after rc1.
Program D requires JDK 5. See above for the reasons why. The benefits available from this new release far outweigh the problem that JDK 5 is not yet available for all platforms. If you are a user of a platform that does not yet have JDK 5 support, you are strongly encouraged to get involved in hastening the day when it does.
If you want to build Program D from the source distribution, you can easily import it into a Java IDE such as Eclipse. Or you can use the included Ant buildfile, which is the same file used to create the binary distributions. Starting with 4.5(rc3), you will need to have your own copy of Ant installed.
The AIML schema includes embedded Schematron directives that fill in a validation gap that W3C XML Schemas cannot address-namely, the three forms of condition. A similar approach could probably take care of the other remaining gap of which I'm aware: the text part of mixed pattern expressions, which is currently not fully constrained by the schema. However, as of this writing, I haven't found how to process the Schematron directives as part of the loadtime validation process, so you still have the possibility of loading some limited forms of "bad AIML". You may, of course, validate your AIML using any good modern XML tool, and it will be able to use the embedded Schematron directives. Coincidentally, the reprocessed AAA AIML set available on aitools.org does pass this additional test when validated manually.
The "readme" doc ("Getting Started with Program D") has been somewhat over-redacted, since quite a lot needed to be updated to reflect changes in property names, etc. Any help in this is greatly appreciated, or it will get back to its full glory sooner or later in any case.
I have a strong desire to include unit testing at the class level, but just haven't gotten to it yet. The new test case framework (as of rc3) does a great job of testing key AIML interpreter functionality, but of course it would be very desirable to have a complete testing framework that would cover all aspects of the application. Again, it's in the pipeline....
The saga continues. Thanks for contributions, tips, assistance with this release to Anne Kootstra, Jonathan
Roewen, Sven Seelig, Denis Sheynihovich, Kim Sullivan, Andrew Teal and Richard Wallace.
- Noel
This release of Program D is significant for stability and important functionality improvements. Here is a list of highlights:
Program D now supports an unlimited number of bots running from the same process. You configure the bots in the startup.xml file. Different bots may share one or more AIML files, and memory usage is optimized to minimize duplication. Bots can be enabled or disabled easily by toggling an attribute in the startup.xml file.
The example startup.xml file has been moved to the conf directory, and is documented inline with XML comments.
The <substitutions>/* elements (<input>, <gender>, <person>, <person2>) as well as the <predicates>, <properties>, and <sentence-splitters> elements of the startup.xml file can each be assigned an href attribute pointing to a local file that contains the actual definitions. This allows multiple bots to share such definitions, or portions thereof, without needless duplication.
The example startup.xml file illustrates this configuration.
Alice Chat Listeners are now configured in the startup.xml file, and each bot can be assigned its own listener.
Because of recent changes to the ICQ protocol, the AliceICQ listener still does not function correctly (it connects and receives messages, but sent messages are never received). However, it is included in hope that a resourceful individual will be able to get it up to speed and contribute back to the community.
You can now choose to have all chats logged to a database. This facilitates a form of log viewing that is much more efficient and easier to work with than the XML approach in previous releases. A companion bundle of PHP files for viewing the log database will be released separately.
You can enable database-based logging by setting programd.logging.to-database.chat=true in server.properties. You must first create the chatlog table as per the database/logtables.script file. You also must configure your database settings properly in server.properties.
Program D now does a better job checking some aspects of your AIML syntax when files are loaded. You will be alerted to malformed categories, invalid pattern expressions, and non-AIML elements in certain locations.
A very primitive GUI-based console is available for bot interaction. (This was actually available in a previous release but not documented.) The console window will be a valuable tool for people building bots in non-English languages, because it can (or should) display all characters, not only ASCII/ISO-8859-1, correctly. The GUI provides menu commands for a couple of common shell commands, but otherwise no additional functionality.
The console can be invoked with console.bat (Windows) or console.sh (*nix).
The bot now has a "heart", of sorts, that can issue regular pulses to let you know it's alive. At present the only implemented pulse is a text message to the console, but an interface has been provided so that you can easily add modules that update a database, send email, etc.
You can set a maximum time allowed for trying to get a response. For some types of infinite loops, an arbitrary timeout is the only way to escape. This also provides a parameter for tuning scaleability of the server.
Set the response timeout by editing/adding the programd.response-timeout property in server.properties.
An optimization to the Graphmaster algorithm suggested by Richard Wallace on the alicebot-developer list has been implemented. This optimization is intended to reduce match times for patterns that include multiple consecutive wildcards.
Now you can customize the strings used as custom inputs to the bot to signal a new connection or inactivity. Also, the connect string is sent to the console user session on starting up (or switching to a new bot) so that you don't have to type it.
Customize these parameters in the server.properties file.
The targeting tool is still very much a prototype, just a cleaned-up version of what was released in Program dB, but probably many miles/kilometers away from what it ought to be. However, in this version you can actually type in the target panel, which I'd managed to mess up previously.
4.1.5 is the last release that predates the Foundation's new bug-tracking system. Subsequent releases will make use of this system to enumerate bugs and their status. The following bug descriptions are more anecdotal than we'd like to provide in the future.
A serious set of thread synchronization problems has been addressed and seems to have eliminated most or all deadlock and race conditions that were causing sporadic, enormous delays in some previous builds.
Some major problems with the substituter have been corrected.
The problems with progressively deteriorating response times seem to have been solved. Even under heavy load, a reasonably-equipped machine should see average response times in the <40ms range, very often down to 1-2ms. We intend to publish some performance test results soon.
The pathname handling for learn operations has been improved to work more "intuitively"--i.e., paths that are expressed relative to the files in which they are listed should work.
Program D 4.1.5 requires a JVM or JRE that is compatible with the Java 2 Platform version 1.4. If you do not intend to modify the source code, you can download just the JRE (Java Runtime Edition), which is significantly smaller than the SDK (about 9MB as compared with ~40!).
The current reason for the Java upgrade requirement is an internationalization-related issue that may not pertain to all users. If the upgrade is onerous for you, post to the alicebot-developer mailing list for assistance with learning the necessary steps to build a version that will be compatible with JDK 1.3.
Many people have expressed the desirability of more cleanly separating Program D from Jetty in order to allow use of better-quality servlet containers (such as Tomcat, WebLogic, JRun, etc.). This isn't done yet but appears to be a trivial task. However, presently the significant integration of the bot server with a web server other than Jetty is more hypothetical than actual.
The question of merge policies still hasn't been satisfactorily addressed.
The program can still be flummoxed by malformed AIML. The decision to require Java SDK 1.4 opens the way to using standard XML technologies now included with Java (previous linkages caused problems with the GNU GPL), but research is needed to measure the tradeoffs between improving this aspect and possible performance degradation.
Finally, the program is now at the stage where it could use a real overhaul in architecture. Several discussions are going on semi-independently about this subject.
Bug fixes and miscellany by Noel Bush.
Major cleanup and optimization work by Noel Bush. User authentication implementation sponsored by Artificial Solutions AB.
Finally it's here -- the final reference version of Program D! Big thanks to Tom and Pedro, who have
taken upon themselves the difficult task of bringing the reference implementation as close to the AIML 1.0
specification as possible. Their work has finished now -- the server is fully under the GPL, and you can
safely use version 4.1.2 as a reference base for further development. If it's good, your work may even
be incorporated into the next release!
-Kim, Tom and Pedro
Another update of the reference version by Thomas Ringate and Pedro E. Colla. It features a rewrite of the
template parser, support for stack variables, re-added some lost features (scripting, substitutions). The
way bot properties are handled also changed. For instructions on how to set up the server, see
_readme.txt.
- Kim, Tom and Pedro
This is the 'reference' version Thomas Ringate and Pedro E. Colla have been working on. It is intermediate work in progress, with the goal to make Program D AIML 1.0 compliant. Currently, in version 4.1.0 ref, the support for AIML 1.0 is partial and achieved thru quick fixes. For the most part, AIML 0.9 is yet supported.
Don't use this release as a base for further development, there will yet be major changes in the code.
The next release 4.1.1 will hopefully adress the above issues within the next 2 weeks.
-Kim, Tom and Pedro
Now comes WITHOUT any AIML, you must install an aiml set manually and configure it in the SERVER.properties
file (pointers are in the bots/readme.txt file), otherwise you will get a 'FileNotFoundException'.
You can get some AIML files (as well as the latest server release) here:
http://www.alicebot.org
ftp://ftp.alicebot.org/pub/builds
-Kim
First release out of the CVS, included Jon Baer's AIML set.
-Kim