· manage multiple, separate ECMAScript runtime environments,
· evaluate instances of user-supplied ECMAScript program text, and
· expose your application's objects to those programs.
· Compiling SEE requires an ANSI C compiler. Although the SEE library is essentially self-contained, it does depend on you (the host application developer) providing the following:
· an IEEE 754 floating point type
· Most modern compilers have this, but if you are developing for some obscure architecture, you should check.
· a garbage-collecting memory allocator
· The free Boehm gc is highly recommended.
· SEE uses scripts from GNU autoconf to determine if these are available, and also to determine other system-dependent properties. Host applications should #include < see/see.h > to access all the macros and functions prototypes.
Here are some key features of "Simple ECMAScript Engine":
· · Support for C++ exceptions
· · Host class convenience constructors
· · Thread safety
· · 3-term BSD licence
· · ECMA-357
· SEE does not provide a document object model. However, the API was designed with the goal of binding a SEE objects to a DOM.
· Please read the SEE library documentation for examples of using of SEE, and the data types it exposes. (You may wish to compare SEE with the Spidermonkey API.)
What's New in This Release: [ read full changelog ]
· Bug 141: allow commas at the end of object literals only for JS1.1+
· Bug 140: don't segfault when re-using 'with' scopes outside of defining func
· Bug 139: detect NetBSD/powerpc in dtoa
· Bugs 133, 135: add -lpcre, -lgcc to output from libsee-config --libs
· Bugs 131, 132: control can leave bytecode exception handlers correctly
· Bug 126: properly close inputs in SEE_call_args's UTF8 handler
· Bug 122: AST field was uninitialized in parser
· Bug 120: library compiled with -DNDEBUG missed SEE_throw() debug point
· Bug 119: library compiled with -DNDEBUG missed _SEE_intern_assert()
· Bug 116: Support eval.call and eval.apply in compatibility mode
· Bug 18: refactored parser