- Notifications
You must be signed in to change notification settings - Fork59
SCXML interpreter and transformer/compiler written in C/C++ with bindings to Java, C#, Python and Lua
License
tklab-tud/uscxml
Folders and files
| Name | Name | Last commit message | Last commit date | |
|---|---|---|---|---|
Repository files navigation
uSCXML is a platform to work with state-charts given asSCXML files. It features thefastest microstep implementation available and consists of three principal components:
libuscxml:C++ library containing an interpreter and accompanying functionality.uscxml-browser: A standards compliantcommand-line interpreter of SCXML documents.uscxml-transform: A collection oftransformation implementations to transpile SCXML, e.g. onto ANSI-C and VHDL.
The status of the various datamodels, bindings and generators with regard to theW3C IRPtests can be checked in thetest table.
There are no installers yet and we do not feature any releases. Just check foropen issues andbuild from source. If you did download and build locally, you can create installers viamake packages though.
Documentation is available at ourgithub pages. It is created from inline comments in the source along with some dedicated markdown pages viadoxygen. We try to keep it current and will update it ever again. For the most current documentation, you can runmake docs in your build directory.
uSCXML itself is distributed under theSimplified BSD license as in, do not sueus 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.
For more detailled information, refer to thedocumentation.
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:
- uscxml-browser.cpp (C++)
- test-state-pass.cpp (C++)
- TestStatePass.cs (C#)
- test-state-pass.py (Python)
- JexlDataModelTest.java (Java)
# interpret state-chart from url$ uscxml-browser https://raw.githubusercontent.com/tklab-tud/uscxml/master/test/w3c/null/test436.scxml# transform given SCXML document into ANSI-C fragment$ uscxml-transform -tc -i https://raw.githubusercontent.com/tklab-tud/uscxml/master/test/w3c/null/test436.scxmlExamples:
- test-gen-c.cpp (C++)
- WaterPump.cxx (C++ on Arduino)
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 version4.0 as the previous version had a bug withJSCheckScriptSyntax.07/19/2017:
Wedropped 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
libv8at 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:
Webroke 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::fromSessionIdif you actually need.
About
SCXML interpreter and transformer/compiler written in C/C++ with bindings to Java, C#, Python and Lua
Topics
Resources
License
Uh oh!
There was an error while loading.Please reload this page.
Stars
Watchers
Forks
Packages0
Uh oh!
There was an error while loading.Please reload this page.
Contributors9
Uh oh!
There was an error while loading.Please reload this page.
