Skip to content

Latest commit

 

History

History
98 lines (61 loc) · 6.71 KB

README.md

File metadata and controls

98 lines (61 loc) · 6.71 KB
Raw

uSCXML ReadMe

Build StatusBuild statusBuild statusCoverage Status

Quick Links

What is it?

uSCXML is a platform to work with state-charts given as SCXML files. It features the fastest microstep implementation available and consists of three principal components:

  1. libuscxml: C++ library containing an interpreter and accompanying functionality.

  2. uscxml-browser: A standards compliant command-line interpreter of SCXML documents.

  3. uscxml-transform: A collection of transformation implementations to transpile SCXML, e.g. onto ANSI-C and VHDL.

The status of the various datamodels, bindings and generators with regard to the W3C IRPtests can be checked in the test table.

Installation

There are no installers yet and we do not feature any releases. Just check for open issues and build from source. If you did download and build locally, you can create installers via make packages though.

Documentation

Documentation is available at our github pages. It is created from inline comments in the source along with some dedicated markdown pages via doxygen. We try to keep it current and will update it ever again. For the most current documentation, you can run make docs in your build directory.

Licensing

uSCXML itself is distributed under the Simplified BSD license as in, do not sue us and do not misrepresent authorship. There are currently four additional libraries that are required to compile uSCXML.

Project License Comment
libcurl MIT/X derivate Used in uSCXML to fetch remote content
Xerces-C++ Apache v2 XML parser and DOM implementation
libevent 3-clause BSD Delayed event queues
uriparser New BSD Referring and resolving URIs

At configure time, the uSCXML build-process will attempt to find and link several other libraries (e.g. Lua, v8) and additional licensing terms may apply.

Getting Started

For more detailled information, refer to the documentation.

Embedded as a Library

uscxml::Interpreter scxml = uscxml::Interpreter::fromURL("...");
scxml.on().enterState([](const std::string& sessionId,
                         const std::string& stateName,
                         const xercesc_3_1::DOMElement* state) {
    std::cout << "Entered " << stateName << std::endl;
});

while(scxml.step() != uscxml::USCXML_FINISHED) {
  ...
}

Examples:

On the Command-line

# interpret state-chart from url
$ uscxml-browser https://raw.githubusercontent.com/tklab-tud/uscxml/master/test/w3c/null/test436.scxml

For Transformations

# transform given SCXML document into ANSI-C fragment
$ uscxml-transform -tc -i https://raw.githubusercontent.com/tklab-tud/uscxml/master/test/w3c/null/test436.scxml

Examples:

Changes

  • 08/01/2017:

    We selectively re-enabled support for Google's V8 ECMAScript engine, but only in version 3.23.17 and 3.14.05 and API compatible versions. These two versions are noteworthy as the first one used to be distributed via MacPorts and the second one is still found in many Linux distributions (e.g. Debian and Ubuntu). It is bordering on impossible to build them from source today as they are rather old. If you need an ECMAScript datamodel and do not have binary images of these, just go for libjavascriptcoregtk-4.0-dev. Make sure it's version 4.0 as the previous version had a bug with JSCheckScriptSyntax.

  • 07/19/2017:

    We dropped support for Google's V8 ECMAScript engine. The API is changing too fast and there is no reliable way to get / build / identify older versions. The latest branch will not work with the wrappers generated from even SWIG 4.0 and I have no time to keep up with them. Use JavaScriptCore, its API is unchanged since we started to support it in 2012. If you feel capable to maintain the send a push request. Everything will be left in place but we will ignore libv8 at configure time. I may have another look when a number of Linux distribution settled on a more recent version, most are still shipping v8 in version 3.14.

  • 07/05/2017:

    We broke the InterpreterMonitor API by substituting the Interpreter instance in the first formal parameter by its sessionId throughout all callbacks. Retrieving the actual Interpreter involved locking a weak_ptr into a shared_ptr which proved to be a performance bottleneck. You can retrieve the Interpreter from its sessionId via the new static method Interpreter::fromSessionId if you actually need.