From 1f5b5885a99d1eb1582dc9c1166990bc573fa5e6 Mon Sep 17 00:00:00 2001 From: Stefan Radomski Date: Wed, 30 Oct 2013 18:01:20 +0100 Subject: Fixed RADME.md layout --- README.md | 112 +++++++++++++++++++++++++++++++------------------------------- 1 file changed, 56 insertions(+), 56 deletions(-) diff --git a/README.md b/README.md index 1dbe133..049f5e2 100644 --- a/README.md +++ b/README.md @@ -5,35 +5,35 @@ uSCXML is a SCXML interpreter written in C/C++. It is mostly feature-complete an It runs on Linux, Windows and MacOSX, each 32- as well as 64Bits as well as iOS. There are still a few rough edges though, especially with the plugins and custom extensions. - * Datamodels - * Full [ECMAScript datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/ecmascript) using Google's v8 (and JavaScriptCore on MacOSX and iOS) - * Simplified support for [Web Storage](http://www.w3.org/TR/2013/REC-webstorage-20130730/) in document.localStorage - * Support for binary data via [TypedArrays](https://www.khronos.org/registry/typedarray/specs/latest/) (will not throw exceptions yet) - * Full [NULL datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/null) with required In predicate - * Early [Prolog datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/prolog/swi) using SWI prolog - * Rudimentary support for [XPath datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/xpath) - * Invokers - * scxml: Invoke a nested scxml interpreter - * dirmon: Watches a directory for changes to files - * scenegraph: Simplified 3D scenegraphs with custom markup - * heartbeat: Periodically sends events - * umundo: Subscribe to channels and publish events - * DOM - * DOM Core Level 2 + XPath extensions available for ecmascript datamodel - * Namespace aware to embed custom markup for special invokers - * Communication - * Features the standard basichttp io-processor - * Features the required SCXML io-processor - * No DOM io-processor - * Can actually respond to HTTP requests with data via <response> - * Language Bindings - * PHP module for apache and cli interpreter +* Datamodels + * Full [ECMAScript datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/ecmascript) using Google's v8 (and JavaScriptCore on MacOSX and iOS) + * Simplified support for [Web Storage](http://www.w3.org/TR/2013/REC-webstorage-20130730/) in document.localStorage + * Support for binary data via [TypedArrays](https://www.khronos.org/registry/typedarray/specs/latest/) (will not throw exceptions yet) + * Full [NULL datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/null) with required In predicate + * Early [Prolog datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/prolog/swi) using SWI prolog + * Rudimentary support for [XPath datamodel](https://github.com/tklab-tud/uscxml/tree/master/src/uscxml/plugins/datamodel/xpath) +* Invokers + * scxml: Invoke a nested scxml interpreter + * dirmon: Watches a directory for changes to files + * scenegraph: Simplified 3D scenegraphs with custom markup + * heartbeat: Periodically sends events + * umundo: Subscribe to channels and publish events +* DOM + * DOM Core Level 2 + XPath extensions available for ecmascript datamodel + * Namespace aware to embed custom markup for special invokers +* Communication + * Features the standard basichttp io-processor + * Features the required SCXML io-processor + * No DOM io-processor + * Can actually respond to HTTP requests with data via <response> +* Language Bindings + * PHP module for apache and cli interpreter ## Test Reports - * We continuously run the [W3C IRP tests](http://www.w3.org/Voice/2013/scxml-irp/) for SCXML. - * Have a look at the [result](http://uscxml.tk.informatik.tu-darmstadt.de/cdash/index.php?project=uscxml) for the various platforms. - * The manual and XPath specific tests are [excluded](https://github.com/tklab-tud/uscxml/blob/master/contrib/ctest/CTestCustom.ctest.in). +* We continuously run the [W3C IRP tests](http://www.w3.org/Voice/2013/scxml-irp/) for SCXML. +* Have a look at the [result](http://uscxml.tk.informatik.tu-darmstadt.de/cdash/index.php?project=uscxml) for the various platforms. +* The manual and XPath specific tests are [excluded](https://github.com/tklab-tud/uscxml/blob/master/contrib/ctest/CTestCustom.ctest.in). uSCXML still fails the following ecmascript tests: @@ -89,44 +89,44 @@ In order to use the interpreter, you need to #include "uscxml/Interpreter.h" objects of uscxml::Interpreter. ### Non-Blocking Interpretation with SCXML from URL - Interpreter scxml = Interpreter::fromURL("http://www.example.com/fancy.scxml"); - scxml.start(); // non-blocking + Interpreter scxml = Interpreter::fromURL("http://www.example.com/fancy.scxml"); + scxml.start(); // non-blocking There are some cases, i.e. with graphical invokers, where the main thread is required in order to react to UI events. You will have to deligate control flow from the main thread into the interpreter every now and then: - interpreter.runOnMainThread(25); + interpreter.runOnMainThread(25); This will perform a single iteration on the invoked components with a maximum of 25 frames per seconds or return immediately. You will have to call this method every now and then if you are using e.g. the scenegraph invoker. ### Blocking Interpretation with inline SCXML - Interpreter scxml = Interpreter::fromXML(""); - scxml.interpret(); // blocking + Interpreter scxml = Interpreter::fromXML(""); + scxml.interpret(); // blocking ### Callbacks for an Interpreter You can register an InterpreterMonitor prior to start in order to receive control-flow upon various events in the Interpreter. - class StatusMonitor : public uscxml::InterpreterMonitor { - void onStableConfiguration(Interpreter) {} - void beforeCompletion(Interpreter) {} - void afterCompletion(Interpreter) {} - void beforeMicroStep(Interpreter) {} - void beforeTakingTransitions(Interpreter, const Arabica::XPath::NodeSet&) {} - void beforeEnteringStates(Interpreter, const Arabica::XPath::NodeSet&) {} - void afterEnteringStates(Interpreter) {} - void beforeExitingStates(Interpreter, const Arabica::XPath::NodeSet&) {} - void afterExitingStates(Interpreter) {} - }; - - StatusMonitor statMon; - Interpreter scxml = Interpreter::fromXML(""); - scxml.addMonitor(&statMon); - scxml.start(); + class StatusMonitor : public uscxml::InterpreterMonitor { + void onStableConfiguration(Interpreter) {} + void beforeCompletion(Interpreter) {} + void afterCompletion(Interpreter) {} + void beforeMicroStep(Interpreter) {} + void beforeTakingTransitions(Interpreter, const Arabica::XPath::NodeSet&) {} + void beforeEnteringStates(Interpreter, const Arabica::XPath::NodeSet&) {} + void afterEnteringStates(Interpreter) {} + void beforeExitingStates(Interpreter, const Arabica::XPath::NodeSet&) {} + void afterExitingStates(Interpreter) {} + }; + + StatusMonitor statMon; + Interpreter scxml = Interpreter::fromXML(""); + scxml.addMonitor(&statMon); + scxml.start(); This will cause the interpreter to invoke the callbacks from the monitor whenever the corresponding internal phase is reached. @@ -135,15 +135,15 @@ internal phase is reached. The uSCXML interpreter can be extended by introducing new - 1. DataModels as embedded scripting languages (e.g. ECMAScript, Prolog and XPath) - 2. Invokers to represent external components that deliver and accept events (e.g. iCal, SceneGraph, DirectoryMonitor) - 3. I/O-Processors to provide communication with external systems (e.g. BasicHTTP, SCXML). - 4. Elements for Executable Content (e.g. <respond>, <fetch>, <postpone>). +1. DataModels as embedded scripting languages (e.g. ECMAScript, Prolog and XPath) +2. Invokers to represent external components that deliver and accept events (e.g. iCal, SceneGraph, DirectoryMonitor) +3. I/O-Processors to provide communication with external systems (e.g. BasicHTTP, SCXML). +4. Elements for Executable Content (e.g. <respond>, <fetch>, <postpone>). The basic approach to extend the interpreter is the same in all cases: - 1. Write a class inheriting the abstract base class (e.g. DataModelImpl, InvokerImpl, IOProcessorImpl, ExecutableContentImpl). - 2. Instantiate your class and register it as a prototype at the Factory via one of its static register* methods. - 1. You can register at the global Factory Singleton via Factory::register*(prototypeInstance) - 2. Or provide a new Factory instance to selected interpreters as an in-between. - 3. Write an interpreter using your new functionality. +1. Write a class inheriting the abstract base class (e.g. DataModelImpl, InvokerImpl, IOProcessorImpl, ExecutableContentImpl). +2. Instantiate your class and register it as a prototype at the Factory via one of its static register* methods. + 1. You can register at the global Factory Singleton via Factory::register*(prototypeInstance) + 2. Or provide a new Factory instance to selected interpreters as an in-between. +3. Write an interpreter using your new functionality. -- cgit v0.12