Browse Source

Merge pull request #1245 from svaarala/cleanup-2.0-releases-and-release-notes

Releases 2.0.0 entry cleanups, 2.0 release notes cleanups
pull/1246/head
Sami Vaarala 8 years ago
committed by GitHub
parent
commit
4695c31685
  1. 695
      RELEASES.rst
  2. 172
      doc/release-notes-v2-0.rst

695
RELEASES.rst

@ -683,7 +683,7 @@ Released
sigsetjmp() (with savesigs set to 0) can be a lot faster than setjmp() sigsetjmp() (with savesigs set to 0) can be a lot faster than setjmp()
if the platform's setjmp() implementation saves the signal mask (GH-55) if the platform's setjmp() implementation saves the signal mask (GH-55)
* Default to ``_setjmp`` for long control transfers on OSX/iPhone (when * Default to _setjmp() for long control transfers on OSX/iPhone (when
__APPLE__ is defined) (GH-55) __APPLE__ is defined) (GH-55)
* Add SuperH detection support * Add SuperH detection support
@ -1684,50 +1684,104 @@ Released
call blocks) so that other native threads may execute while the thread is call blocks) so that other native threads may execute while the thread is
blocked (GH-893, GH-909) blocked (GH-893, GH-909)
Planned 2.0.0 (2016-12-31)
=======
2.0.0 (XXXX-XX-XX)
------------------ ------------------
* Incompatible change: remove feature option (DUK_OPT_xxx) support entirely, Tooling:
use tools/configure.py (or tools/genconfig.py) or edit duk_config.h manually
* Incompatible change: remove feature option (DUK_OPT_xxx) support, use
tools/configure.py (or tools/genconfig.py) or edit duk_config.h manually
to use custom config options (GH-949) to use custom config options (GH-949)
* Incompatible change: remove Duktape.Buffer custom built-in, ArrayBuffer * Incompatible change: tools/configure.py is the new frontend tool for
now serves its place; the following new bindings provide functionality configuring Duktape: it generates both a duk_config.h config header,
roughly equivalent to Duktape.Buffer: Uint8Array.allocPlain() and prepares amalgamated source files for build, and supports ROM built-ins;
Uint8Array.plainOf(), however, the ability of doing a 1:1 buffer-to-string raw input source files are included in the end user distributable to
coercion (using buffer data directly as the internal string representation) allow tools/configure.py to be used without a repo checkout (GH-949, GH-927,
has been removed (GH-875, GH-1005) GH-928, GH-929)
* Incompatible change: rework buffer types and their Ecmascript and C API * Genconfig.py is still available (moved to tools/genconfig.py) but is no
behavior: plain buffers now behave like Uint8Arrays and inherit from longer recommended for configuring Duktape, use tools/configure.py instead
Uint8Array.prototype; there are a lot of associated small changes in (GH-949, GH-927, GH-928, GH-929)
how built-ins behave for plain buffer arguments, for example, enumeration,
Object.prototype.toString() output, JSON serialization (GH-864, GH-1197)
* Incompatible change: allow a plain buffer or a lightfunc as a constructor * util/dist.py no longer supports ROM built-ins, use tools/configure.py
"replacement object" return value (GH-1197) instead (GH-949, GH-929)
* Incompatible change: plain buffers now test false in duk_is_primitive() * Add support for converting ROM function property values into lightfuncs in
which is more consistent with how they behave in Ecmascript coercions genbuiltins.py to reduce code footprint for ROM-based built-ins and custom
(GH-864) bindings; footprint reduction is around 14-15kB on 32-bit targets (GH-872)
* Incompatible change: ArrayBuffer no longer has non-standard properties * Fix genconfig.py forced option boolean comparison; for forced numeric option
(.length, .byteOffset, virtual index properties) (GH-867, GH-1197) value 0 genconfig would emit "#undef XXX" (instead of "#define XXX 0") and
for forced numeric option value 1 it would emit "#define XXX" (instead of
"#define XXX 1") (GH-954)
* Incompatible change: DataView no longer has non-standard properties Configuration:
(.length, virtual index properties) (GH-1197)
* Incompatible change: typed array .subarray() and Node.js buffer .slice() * Incompatible change: remove Duktape internal and user "InitJS" support
result internal prototype is now the default prototype of the result (DUK_USE_BUILTIN_INITJS and DUK_USE_USER_INITJS) which were very rarely
type (e.g. initial value of Uint8Array.prototype) rather than being used and required minify tools to make a dist package (GH-899)
copied from the argument (GH-864)
* Incompatible change: minor changes to buffer object behavior when buffer * Require a DUK_USE_DEBUG_WRITE() macro for handling debug writes when
types are mixed (e.g. Node.js Buffer as an argument to typed array calls) DUK_USE_DEBUG is enabled; this avoids a platform I/O dependency and allows
(GH-864) debug log filtering and retargeting (GH-782)
* Use DUK_USE_DEBUG_LEVEL for debug print level control rather than the
previous DUK_USE_DPRINT, DUK_USE_DDPRINT, and DUK_USE_DDDPRINT defines
(GH-783)
* Add support for dropping built-in bindings entirely when they are disabled
in configuration, e.g. the Proxy and buffer object bindings will be absent
instead of being replaced by functions throwing an error; this is more
in line with how applications detect supported features and also reduces
footprint (GH-988)
* Remove no longer needed platform wrappers in duk_config.h: DUK_ABORT(),
DUK_EXIT(), DUK_PRINTF(), DUK_FPRINTF(), DUK_FOPEN(), DUK_FCLOSE(),
DUK_FREAD(), DUK_FWRITE(), DUK_FSEEK(), DUK_FTELL(), DUK_FFLUSH(),
DUK_FPUTC(), DUK_STDOUT, DUK_STDERR, DUK_STDIN, duk_file (GH-787, GH-761)
* Make coroutine support optional (DUK_USE_COROUTINE_SUPPORT); disabling
coroutines reduces code footprint by about 2kB (GH-829)
* Make finalizer support optional (DUK_USE_FINALIZER_SUPPORT); disabling
coroutines reduces code footprint by about 0.8kB (GH-936)
* Reduce RAM built-ins initdata limitations for custom bindings by using a
shared varuint encoding in the bit-packed initdata stream (GH-1151, GH-1152)
* Remove support for refcounting-only (= no mark-and-sweep) memory management
option as too error prone: without mark-and-sweep garbage containing
reference loops or created during debugger paused state (with or without
reference loops) would seemingly leak until heap destruction (GH-1168)
* Add DUK_USE_GET_RANDOM_DOUBLE() config option to allow an application
to override the built-in random number generator (which is very simple
and low footprint optimized) with something faster or better (GH-824)
* Make Array property read/write fast path optional to reduce footprint
for footprint optimized builds (ensure DUK_USE_ARRAY_PROP_FASTPATH is
disabled for low memory builds) (GH-934)
Buffers:
* Incompatible change: rework buffer types and their Ecmascript and C API
behavior: remove Duktape.Buffer; provide Uint8Array.allocPlain() and
Uint8Array.plainOf() to replace Duktape.Buffer; plain buffers now behave
like Uint8Arrays and inherit from Uint8Array.prototype; plain buffers now
test false in duk_is_primitive() which is more consistent with their
Ecmascript coercion behavior; many small changes in how built-in functions
behave for plain buffer arguments e.g. in enumeration, JSON serialization,
and Object.prototype.toString() output (GH-875, GH-1005, GH-864, GH-1197)
* Incompatible change: remove the ability to do a 1:1 buffer-to-string
coercion (using buffer data directly as the internal string representation)
from the default Ecmascript bindings, an encoding (usually UTF-8) is now
always applied (GH-875, GH-1005)
* Incompatible change: remove non-standard properties from ArrayBuffer
instances (.length, .byteOffset, virtual index properties) and DataView
instances (.length, virtual index properties) (GH-867, GH-1197)
* Incompatible change: when DUK_USE_BUFFEROBJECT_SUPPORT is disabled, don't * Incompatible change: when DUK_USE_BUFFEROBJECT_SUPPORT is disabled, don't
support coercing plain buffers to Uint8Arrays, or any other buffer object support coercing plain buffers to Uint8Arrays, or any other buffer object
@ -1740,13 +1794,46 @@ Planned
Buffer.prototype.toString() does UTF-8 decoding (previously buffer data Buffer.prototype.toString() does UTF-8 decoding (previously buffer data
was copied into internal string representation as is) (GH-1020) was copied into internal string representation as is) (GH-1020)
* Incompatible change: change Object constructor argument coercion policy * Incompatible change: typed array .subarray() and Node.js buffer .slice()
to match ES2015 requirements for .keys(), .getOwnPropertyNames(), result internal prototype is now the default prototype of the result
.getOwnPropertyDescriptor(), .getPrototypeOf(), .freeze(), .isFrozen(), type (e.g. initial value of Uint8Array.prototype) rather than being
.seal(), .isSealed(), .preventExtensions(), and .isExtensible(); copied from the argument (GH-864)
instead of rejecting non-objects with a TypeError, they are now coerced
to objects or treated as non-extensible objects with no own properties * Incompatible change: minor changes to buffer object behavior when buffer
(GH-1028, GH-1164) types are mixed (e.g. Node.js Buffer as an argument to typed array calls)
(GH-864)
* Incompatible change: allow a plain buffer as a constructor "replacement
object" return value (GH-1197)
* Reject ArrayBuffers with a view offset/length in Node.js Buffer .slice()
rather than accept such ArrayBuffers without actually respecting the
view offset/length (GH-1197)
* Disable JSON stringify fastpath for plain buffers for now so that the
virtual index properties get serialized correctly; fastpath to be added
back separately (GH-1197)
* As a side effect of fixing JSON serialization of buffer objects, JSON
fast path is aborted when encountering buffer objects; the fast path
doesn't currently handle buffer object virtual properties correctly
so to remain compliant fall back to slow path for now (GH-867)
* Fix duk_push_buffer_object() ArrayBuffer .byteLength to use 0 and .byteOffset
to use view's (byteOffset + byteLength), so that accesses to the ArrayBuffer
at the view's .byteOffset match the view at index 0 as normally expected;
previously .byteOffset and .byteLength were copied from the view as is which
makes the ArrayBuffer indices behave inconsistently with respect to the
view's .byteOffset (GH-1229)
* Fix buffer object (duk_hbufobj) JSON serialization (bug present in 1.5.0):
buffer objects were omitted from serialization when they should be
serialized as normal objects instead (GH-867)
Other type changes:
* Incompatible change: allow a lightfunc as a constructor "replacement
object" return value (GH-1197)
* Incompatible change: plain pointer values now test true in instanceof * Incompatible change: plain pointer values now test true in instanceof
(plainPointer instanceof Duktape.Pointer === true) (GH-864) (plainPointer instanceof Duktape.Pointer === true) (GH-864)
@ -1759,71 +1846,22 @@ Planned
coerced to a full Function object if the call target is non-strict (this coerced to a full Function object if the call target is non-strict (this
matches e.g. string and plain buffer behavior) (GH-864) matches e.g. string and plain buffer behavior) (GH-864)
* Incompatible change: add a userdata argument to duk_safe_call() to make it Debugger:
easier to pass C pointers to safe functions (GH-277, GH-727)
* Incompatible change: remove built-in print() and alert() bindings which,
being dependent on stdout/stderr, are often a portability issue (GH-745)
* Incompatible change: remove the built-in logging framework (Duktape.Logger,
duk_log(), duk_log_va()); now provided as an extra (GH-746, GH-790)
* Incompatible change: remove the built-in module loading framework (global
require() call, Duktape.modSearch() etc); now provided as an extra (GH-821)
* Incompatible change: rename duk_debugger_attach_custom() API call to * Incompatible change: rename duk_debugger_attach_custom() API call to
duk_debugger_attach() to eliminate an unnecessary API call variant duk_debugger_attach() to eliminate an unnecessary API call variant
(GH-735, GH-742) (GH-735, GH-742)
* Incompatible change: remove duk_dump_context_{stdout,stderr}() to avoid a
dependency on stdout/stderr which is a porting issue (GH-736, GH-743)
* Incompatible change: remove file related Duktape C API calls to avoid a
dependency on platform file I/O which is a porting issue; removed calls
(which were moved into extras): duk_push_string_file(), duk_compile_file(),
duk_pcompile_file(), duk_eval_file(), duk_eval_file_noresult(),
duk_peval_file(), duk_peval_file_noresult() (GH-788)
* Incompatible change: debug protocol version bumped from 1 to 2 to indicate * Incompatible change: debug protocol version bumped from 1 to 2 to indicate
version incompatible protocol changes in the 2.0.0 release (GH-756) version incompatible protocol changes in the 2.0.0 release (GH-756)
* Incompatible change: make callstack level mandatory for most debugger * Incompatible change: make callstack level mandatory for most debugger
commands which accept one (GH-747, GH-1109) commands which accept one (GH-747, GH-1109)
* Incompatible change: require a DUK_USE_DEBUG_WRITE() macro for handling
debug writes when DUK_USE_DEBUG is enabled; this avoids a platform I/O
dependency and allows debug log filtering and retargeting (GH-782)
* Incompatible change: use DUK_USE_DEBUG_LEVEL for debug print level control
rather than the previous DUK_USE_DPRINT, DUK_USE_DDPRINT, and
DUK_USE_DDDPRINT defines (GH-783)
* Incompatible change: remove the distinction between panic and fatal errors,
and simplify the fatal error handler function signature to
``void my_fatal(void *udata, const char *msg);`` (GH-781)
* Incompatible change: remove error code argument from duk_fatal() API
call to match revised fatal error handler function signature (GH-781)
* Incompatible change: default fatal error handler (similar to panic handler
in Duktape 1.x) calls abort() without printing anything to stdout or stderr
(which avoids unnecessary platform dependencies); this behavior can be
overridden by defining DUK_USE_FATAL_HANDLER() in duk_config.h (GH-781,
GH-1218)
* Incompatible change: change some debugger artificial property names to match * Incompatible change: change some debugger artificial property names to match
internal renames: compiledfunction -> compfunc, nativefunction -> natfunc, internal renames: compiledfunction -> compfunc, nativefunction -> natfunc,
bufferobject -> bufobj (GH-798) bufferobject -> bufobj (GH-798)
* Incompatible change: remove Duktape specific error codes DUK_ERR_ALLOC_ERROR,
DUK_ERR_API_ERROR, DUK_ERR_ASSERTION_ERROR, DUK_ERR_INTERNAL_ERROR,
DUK_ERR_UNCAUGHT_ERROR, DUK_ERR_UNIMPLEMENTED_ERROR,
DUK_ERR_UNSUPPORTED_ERROR; use standard error types instead (GH-827)
* Incompatible change: map API related errors (which previously used
DUK_ERR_API_ERROR and a plain Error for Ecmascript representation) into
TypeErrors and RangeErrors to match common Ecmascript conventions (GH-827)
* Incompatible change: add a "ctx" argument to the debugger detached_cb to * Incompatible change: add a "ctx" argument to the debugger detached_cb to
allow easier reattachment in detached callback (GH-758, GH-853) allow easier reattachment in detached callback (GH-758, GH-853)
@ -1832,70 +1870,21 @@ Planned
related changes; instead, an artificial property "length" is available via related changes; instead, an artificial property "length" is available via
GetHeapObjInfo (GH-703, GH-856) GetHeapObjInfo (GH-703, GH-856)
* Incompatible change: remove Duktape internal and user "InitJS" support * Add ability to perform an indirect debugger Eval with non-empty callstack by
(DUK_USE_BUILTIN_INITJS and DUK_USE_USER_INITJS) which were very rarely sending null for the callstack level (GH-747)
used and required minify tools to make a dist package (GH-899)
* Incompatible change: bytecode opcode format reworks drop maximum function
and constructor call argument count from 511 to 255, and maximum Ecmascript
function constant count from 262144 to 65536 (GH-903)
* Incompatible change: genconfig.py has been relocated to tools/genconfig.py
in the end user distributable (GH-929)
* Incompatible change: util/dist.py no longer supports ROM built-ins, use
tools/configure.py instead (GH-929)
* Incompatible change: remove duk_to_defaultvalue() which invoked the
[[DefaultValue]] specification algorithm removed in ES2015 (it was folded
to ToPrimitive()), use duk_to_primitive() instead (GH-984)
* Incompatible change: duk_gc() no longer allows a NULL context pointer
for consistency with other API calls (GH-1129)
* Incompatible change: Duktape.info() output has been changed from an array
(which is difficult to version and work with) to an object with named
properties; the properties are not under versioning guarantees (GH-1125)
* Add support for dropping built-in bindings entirely when they are disabled
in configuration, e.g. the Proxy and buffer object bindings will be absent
instead of being replaced by functions throwing an error; this is more
in line with how application code detects active features and reduces
footprint (GH-988)
* Change return from of duk_throw(), duk_error(), and duk_fatal() from void
to duk_ret_t which allows them to be called using the idiom
"return duk_error(ctx, DUK_ERR_TYPE_ERROR, "invalid argument");"
(GH-1038, GH-1041)
* Add convenience API calls to throw specific error types; for example,
duk_type_error(), duk_type_error_va(), duk_range_error(), etc (GH-1040)
* Add convenience API calls duk_get_prop_lstring(), duk_put_prop_lstring(),
duk_del_prop_lstring(), duk_has_prop_lstring(), duk_get_global_lstring(),
duk_put_global_lstring() (GH-946, GH-953)
* Add a ToString (later, ToPropertyKey) coercion to duk_def_prop() key
argument to allow e.g. numbers to be used in the key slot (GH-836, GH-1130)
* Add duk_get_prop_desc() API call which pushes a property descriptor object
for a target object and key, similar to Object.getOwnPropertyDescriptor()
(GH-1087)
* Add duk_suspend() and duk_resume() which allow a native thread running a * Rename debugger protocol artificial property "bound" to "boundfunc" for
Duktape/C function to be suspended temporarily (e.g. when a native system consistency with an internal flag rename (GH-703)
call blocks) so that other native threads may execute while the thread is
blocked (GH-893, GH-909)
* Include raw input sources and a prepare-and-config tool in the distributable, Ecmascript 2015+ and real world compatibility:
which allow user code to regenerate a config file and source code files for
specified options; this is more comprehensive than just running genconfig.py
and makes it possible to e.g. use ROM built-ins directly from the end user
distributable (GH-927, GH-928)
* Add support for converting ROM function property values into lightfuncs in * Change Object constructor argument coercion policy to match ES2015
genbuiltins.py to reduce code footprint for ROM-based built-ins and custom requirements for .keys(), .getOwnPropertyNames(),
bindings; footprint reduction is around 14-15kB on 32-bit targets (GH-872) .getOwnPropertyDescriptor(), .getPrototypeOf(), .freeze(), .isFrozen(),
.seal(), .isSealed(), .preventExtensions(), and .isExtensible();
instead of rejecting non-objects with a TypeError, they are now coerced
to objects or treated as non-extensible objects with no own properties
(GH-1028, GH-1164)
* Add experimental support for ES2015 Symbol built-in (disabled by default, * Add experimental support for ES2015 Symbol built-in (disabled by default,
enable using DUK_USE_SYMBOL_BUILTIN), duk_is_symbol() API call (GH-982, enable using DUK_USE_SYMBOL_BUILTIN), duk_is_symbol() API call (GH-982,
@ -1917,7 +1906,7 @@ Planned
yet supported (GH-985, GH-1190, GH-1193) yet supported (GH-985, GH-1190, GH-1193)
* Add support for ES2016 exponentiation and exponentiation assignment * Add support for ES2016 exponentiation and exponentiation assignment
operators, e.g. "2 ** 10" evaluates to 1024, avoiding the cost of an operators, e.g. "2 \*\* 10" evaluates to 1024, avoiding the cost of an
Ecmascript call to Math.pow() while also being more readable (GH-987, Ecmascript call to Math.pow() while also being more readable (GH-987,
GH-997) GH-997)
@ -1925,7 +1914,7 @@ Planned
features like constructor retargeting require ES2015+ semantics and are thus features like constructor retargeting require ES2015+ semantics and are thus
not yet supported (GH-1025) not yet supported (GH-1025)
* Add support for ES2015 \u{H+} escape syntax for source code string literals * Add support for ES2015 \\u{H+} escape syntax for source code string literals
and identifiers, no RegExp support yet (requires RegExp /u Unicode mode) and identifiers, no RegExp support yet (requires RegExp /u Unicode mode)
(GH-1001) (GH-1001)
@ -1942,10 +1931,6 @@ Planned
* Add support for ES2015 Object.is() and duk_samevalue() API call (GH-1068) * Add support for ES2015 Object.is() and duk_samevalue() API call (GH-1068)
* Add TextEncoder and TextDecoder built-ins (the Encoding API) which allow
Ecmascript code to read and write text stored in an ArrayBuffer or a plain
buffer (GH-975)
* Respect ES2015 enumeration order (array index keys, other keys in insertion * Respect ES2015 enumeration order (array index keys, other keys in insertion
order) for Object.getOwnPropertyNames(), also use the same order in order) for Object.getOwnPropertyNames(), also use the same order in
for-in, Object.keys(), and duk_enum() even though that's not strictly for-in, Object.keys(), and duk_enum() even though that's not strictly
@ -1966,10 +1951,134 @@ Planned
e.g. RegExp.prototype.source (from ES2017 draft) is supported for real e.g. RegExp.prototype.source (from ES2017 draft) is supported for real
world code compatibility (GH-1178) world code compatibility (GH-1178)
* Remove no longer needed platform wrappers in duk_config.h: DUK_ABORT(), * Update UnicodeData.txt and SpecialCasing.txt used for building internal
DUK_EXIT(), DUK_PRINTF(), DUK_FPRINTF(), DUK_FOPEN(), DUK_FCLOSE(), Unicode control data to Unicode version 9.0.0 (GH-931)
DUK_FREAD(), DUK_FWRITE(), DUK_FSEEK(), DUK_FTELL(), DUK_FFLUSH(),
DUK_FPUTC(), DUK_STDOUT, DUK_STDERR, DUK_STDIN, duk_file (GH-787, GH-761) * Change parsing of legacy octal literals so that 077 is parsed as octal
(= 63) but 078 is parsed as decimal (78) rather than causing a SyntaxError;
this aligns better with behavior of other engines (GH-1057)
* Change parsing of octal escapes in string literals to better align with
ES2015 and other engines; "\078" is now accepted and is the same as
"\u00078", "\8" and "\9" are accepted as literal "8" and "9" (GH-1057)
* Change bound function .name property handling to match ES2015 requirements;
for a target function with name "foo", bound function name is "bound foo"
(GH-1113)
* Change bound function internal prototype handling to match ES2015 requirements;
bound function internal prototype is copied from the target function
instead of always being Function.prototype (GH-1135)
* Change Function.prototype.toString() output to match ES2015 requirements;
the output no longer parses with eval() but causes a SyntaxError instead
(GH-1141)
* Make function instance .name and .length properties configurable (but
non-writable and non-enumerable) to match ES2015 requirements; also change
.fileName to follow the same attribute convention (GH-1153, GH-1177)
* Remove anonymous function own .name property to match ES2015 requirements;
anonymous functions inherit an empty string as their name from
Function.prototype.name (GH-1183)
* Change functions created using new Function() to have the .name
"anonymous" to match ES2015 requirements (GH-1183)
* Make Error instance .fileName and .lineNumber properties configurable
but non-writable and non-enumerable to match function instance property
behavior; this only matters when tracebacks are disabled and concrete
error instance properties are in use (GH-1153)
* Change NativeError (TypeError, RangeError, etc) constructor to inherit
from the Error constructor rather than Function.prototype directly as
required by ES2015 (GH-1182)
* Change object literal getter/setter to match ES2015 requirements: no automatic
.prototype property, and the functions are non-constructable (GH-1188)
* Allow duplicate property names in object literals as required by ES2015
(GH-1190)
* Change typed array constructor chain to match ES2015, e.g. Uint8Array
constructor inherits from intrinsic %TypedArray% constructor (GH-1191)
* Move typed array properties .byteLength, .byteOffset, and .buffer to
prototype objects and make them (inherited) accessors to better match
ES2015 requirements; .length remains a virtual own property (GH-1197)
WHATWG Encoding API:
* Add TextEncoder and TextDecoder built-ins (the Encoding API) which allow
Ecmascript code to convert between buffers and strings using the UTF-8
encoding (GH-975)
Other C API changes:
* Incompatible change: add a userdata argument to duk_safe_call() to make it
easier to pass C pointers to safe functions (GH-277, GH-727)
* Incompatible change: remove duk_dump_context_{stdout,stderr}() to avoid a
dependency on stdout/stderr which is a porting issue (GH-736, GH-743)
* Incompatible change: remove file related Duktape C API calls to avoid a
dependency on platform file I/O which is a porting issue; removed calls
(which were moved into extras): duk_push_string_file(), duk_compile_file(),
duk_pcompile_file(), duk_eval_file(), duk_eval_file_noresult(),
duk_peval_file(), duk_peval_file_noresult() (GH-788)
* Incompatible change: remove the distinction between panic and fatal errors,
and simplify the fatal error handler function signature to
"void my_fatal(void \*udata, const char \*msg);" (GH-781)
* Incompatible change: remove error code argument from duk_fatal() API
call to match revised fatal error handler function signature (GH-781)
* Incompatible change: default fatal error handler (similar to panic handler
in Duktape 1.x) calls abort() without printing anything to stdout or stderr
(which avoids unnecessary platform dependencies); this behavior can be
overridden by defining DUK_USE_FATAL_HANDLER() in duk_config.h (GH-781,
GH-1218)
* Incompatible change: remove Duktape specific error codes DUK_ERR_ALLOC_ERROR,
DUK_ERR_API_ERROR, DUK_ERR_ASSERTION_ERROR, DUK_ERR_INTERNAL_ERROR,
DUK_ERR_UNCAUGHT_ERROR, DUK_ERR_UNIMPLEMENTED_ERROR,
DUK_ERR_UNSUPPORTED_ERROR; use standard error types instead (GH-827)
* Incompatible change: map API related errors (which previously used
DUK_ERR_API_ERROR and a plain Error for Ecmascript representation) into
TypeErrors and RangeErrors to match common Ecmascript conventions (GH-827)
* Incompatible change: remove duk_to_defaultvalue() which invoked the
[[DefaultValue]] specification algorithm removed in ES2015 (it was folded
to ToPrimitive()), use duk_to_primitive() instead (GH-984)
* Incompatible change: duk_gc() no longer allows a NULL context pointer
for consistency with other API calls (GH-1129)
* Change return from of duk_throw(), duk_error(), and duk_fatal() from void
to duk_ret_t which allows them to be called using the idiom
"return duk_error(ctx, DUK_ERR_TYPE_ERROR, "invalid argument");"
(GH-1038, GH-1041)
* Add convenience API calls to throw specific error types; for example,
duk_type_error(), duk_type_error_va(), duk_range_error(), etc (GH-1040)
* Add convenience API calls duk_get_prop_lstring(), duk_put_prop_lstring(),
duk_del_prop_lstring(), duk_has_prop_lstring(), duk_get_global_lstring(),
duk_put_global_lstring() (GH-946, GH-953)
* Add a ToPropertyKey() coercion to duk_def_prop() key argument to allow
e.g. numbers to be used in the key slot (GH-836, GH-1130)
* Add duk_get_prop_desc() API call which pushes a property descriptor object
for a target object and key, similar to Object.getOwnPropertyDescriptor()
(GH-1087)
* Add duk_suspend() and duk_resume() which allow a native thread running a
Duktape/C function to be suspended temporarily (e.g. when a native system
call blocks) so that other native threads may execute while the thread is
blocked (GH-893, GH-909)
* Add duk_is_buffer_data() API call to reliably test whether a value stack * Add duk_is_buffer_data() API call to reliably test whether a value stack
entry is a plain buffer or any buffer object (GH-1221) entry is a plain buffer or any buffer object (GH-1221)
@ -1994,36 +2103,28 @@ Planned
* Add duk_set_length() API call and change duk_get_length() limits from * Add duk_set_length() API call and change duk_get_length() limits from
uint32 to size_t supported range (GH-1123) uint32 to size_t supported range (GH-1123)
* Add ability to perform an indirect debugger Eval with non-empty callstack by
sending null for the callstack level (GH-747)
* Add a human readable summary of 'new MyConstructor()' constructor call
target when the target is non-constructable (GH-757)
* Add a safe summary for "uncaught error" fatal error (GH-832)
* Remove duk_{get,put,has,del}_var() calls from API header; they were not * Remove duk_{get,put,has,del}_var() calls from API header; they were not
fully implemented and not part of the documented public API (GH-762) fully implemented and not part of the documented public API (GH-762)
* Allow a bound Ecmascript function as an argument to new Duktape.Thread() Other Ecmascript binding changes:
(GH-1134, GH-1157)
* Minor changes to error messages for errors thrown by Duktape internals * Incompatible change: remove built-in print() and alert() bindings which,
(GH-827, GH-839, GH-840, GH-1016) being dependent on stdout/stderr, are often a portability issue (GH-745)
* Make coroutine support optional (DUK_USE_COROUTINE_SUPPORT); disabling * Incompatible change: remove the built-in logging framework (Duktape.Logger,
coroutines reduces code footprint by about 2kB (GH-829) duk_log(), duk_log_va()); now provided as an extra (GH-746, GH-790)
* Make finalizer support optional (DUK_USE_FINALIZER_SUPPORT); disabling * Incompatible change: remove the built-in module loading framework (global
coroutines reduces code footprint by about 0.8kB (GH-936) require() call, Duktape.modSearch() etc); now provided as an extra (GH-821)
* Add an internal type for representing Array instances (duk_harray) to * Incompatible change: Duktape.info() output has been changed from an array
simplify array operations and improve performance; this also changes the (which is difficult to version and work with) to an object with named
key order of Object.getOwnPropertyNames() for sparse arrays (arrays whose properties; the properties are not under versioning guarantees (GH-1125)
internal "array part" has been abandoned) (GH-703)
* Rename debugger protocol artificial property "bound" to "boundfunction" * Allow a bound Ecmascript function as an argument to new Duktape.Thread()
for consistency with an internal flag rename (GH-703) (GH-1134, GH-1157)
Extras:
* Add an extra module (extras/duk-v1-compat) providing many Duktape 1.x API * Add an extra module (extras/duk-v1-compat) providing many Duktape 1.x API
calls removed in Duktape 2.x (multiple Github issues) calls removed in Duktape 2.x (multiple Github issues)
@ -2055,19 +2156,31 @@ Planned
allocator which supports runtime resizing of pool counts to specified allocator which supports runtime resizing of pool counts to specified
memory target and realloc shrinking (GH-847) memory target and realloc shrinking (GH-847)
* As a side effect of fixing JSON serialization of buffer objects, JSON Portability:
fast path is aborted when encountering buffer objects; the fast path
doesn't currently handle buffer object virtual properties correctly
so to remain compliant fall back to slow path for now (GH-867)
* Add a minimal alloc/realloc/free self test to the (optional) internal * Miscellaneous portability improvements: remove dependency on fmin() and
self test (GH-877) fmax() (GH-1072); remove signed shifts in lightfunc handling (GH-1172)
* Fix ARM64 platform detection for some Android targets (GH-1062)
* Fix AmigaOS3 portability issue by enabling math function replacements
automatically for AmigaOS on M68K, regardless of OS version or compiler
(GH-932)
* Fix Cygwin warning about shadowed 'accept' variable (GH-1098)
* Fix Cygwin/MinGW math issues related to pow2() and atan2() semantics
(GH-1099)
* Add an fmod() self test (GH-1108)
* Add an FP rounding mode self test (Duktape assumes rounding mode is * Add an FP rounding mode self test (Duktape assumes rounding mode is
IEEE 754 round-to-nearest, C99 FE_TONEAREST) (GH-606) IEEE 754 round-to-nearest, C99 FE_TONEAREST) (GH-606)
* Update UnicodeData.txt and SpecialCasing.txt used for building internal * Add a minimal alloc/realloc/free self test to the (optional) internal
Unicode control data to Unicode version 9.0.0 (GH-931) self test (GH-877)
Performance:
* Simplify call related bytecode opcodes for better performance; as a * Simplify call related bytecode opcodes for better performance; as a
result maximum argument count to normal and constructor calls dropped result maximum argument count to normal and constructor calls dropped
@ -2075,70 +2188,19 @@ Planned
native eval()) via the identifier 'eval' doesn't get tailcall native eval()) via the identifier 'eval' doesn't get tailcall
optimization (GH-896) optimization (GH-896)
* Make Array property read/write fast path optional to reduce footprint * Internal performance improvement: rework bytecode format to use an 8-bit
for footprint optimized builds (ensure DUK_USE_ARRAY_PROP_FASTPATH is opcode field (and 8-bit A, B, and C fields) to speed up opcode dispatch
disabled for low memory builds) (GH-934) by around 20-25% and avoid a two-level dispatch for EXTRA opcodes; the
performance optimized build is ~10kB larger while footprint optimized
* Add DUK_USE_GET_RANDOM_DOUBLE() config option to allow an application build is slightly smaller (GH-903)
to override the built-in random number generator (which is very simple
and low footprint optimized) with something faster or better (GH-824)
* Change default built-in PRNG algorithm to xoroshiro128+ with SplitMix64
seed mixing; previous algorithm (Shamir's three-op algorithm) is still
used for low memory targets and targets without 64-bit types (GH-970)
* Change parsing of legacy octal literals so that 077 is parsed as octal
(= 63) but 078 is parsed as decimal (78) rather than causing a SyntaxError;
this aligns better with behavior of other engines (GH-1057)
* Change parsing of octal escapes in string literals to better align with
ES2015 and other engines; "\078" is now accepted and is the same as
"\u00078", "\8" and "\9" are accepted as literal "8" and "9" (GH-1057)
* Change bound function .name property handling to match ES2015 requirements;
for a target function with name "foo", bound function name is "bound foo"
(GH-1113)
* Change bound function internal prototype handling to match ES2015 requirements;
bound function internal prototype is copied from the target function
instead of always being Function.prototype (GH-1135)
* Change Function.prototype.toString() output to match ES2015 requirements;
the output no longer parses with eval() but causes a SyntaxError instead
(GH-1141)
* Make function instance .name and .length properties configurable (but
non-writable and non-enumerable) to match ES2015 requirements; also change
.fileName to follow the same attribute convention (GH-1153, GH-1177)
* Remove anonymous function own .name property to match ES2015 requirements;
anonymous functions inherit an empty string as their name from
Function.prototype.name (GH-1183)
* Change functions created using new Function() to have the .name
"anonymous" to match ES2015 requirements (GH-1183)
* Make Error instance .fileName and .lineNumber properties configurable
but non-writable and non-enumerable to match function instance property
behavior; this only matters when tracebacks are disabled and concrete
error instance properties are in use (GH-1153)
* Change NativeError (TypeError, RangeError, etc) constructor to inherit
from the Error constructor rather than Function.prototype directly as
required by ES2015 (GH-1182)
* Change object literal getter/setter to match ES2015 requirements: no automatic
.prototype property, and the functions are non-constructable (GH-1188)
* Allow duplicate property names in object literals as required by ES2015
(GH-1190)
* Change typed array constructor chain to match ES2015, e.g. Uint8Array * Internal performance improvement: add optional fast path for dense arrays in
constructor inherits from intrinsic %TypedArray% constructor (GH-1191) Array.prototype operations like push() and pop() (GH-584, GH-1154)
* Move typed array properties .byteLength, .byteOffset, and .buffer to * Add an internal type for representing Array instances (duk_harray) to
prototype objects and make them (inherited) accessors to better match simplify array operations and improve performance; this also changes the
ES2015 requirements; .length remains a virtual own property (GH-1197) key order of Object.getOwnPropertyNames() for sparse arrays (arrays whose
internal "array part" has been abandoned) (GH-703)
* Add a fastint check for duk_put_number_list() values (GH-1086) * Add a fastint check for duk_put_number_list() values (GH-1086)
@ -2146,30 +2208,35 @@ Planned
opcode (fastint downgrade check is intended to be applied to unary plus opcode (fastint downgrade check is intended to be applied to unary plus
only) (GH-903) only) (GH-903)
* Add an fmod() self test (GH-1108) * Miscellaneous performance improvements: avoid one extra shift when computing
reg/const pointers in the bytecode executor (GH-674); avoid value stack for
* Reduce RAM built-ins initdata limitations for custom bindings by using a Array .length coercion (GH-862); value stack operation optimization
shared varuint encoding in the bit-packed initdata stream (GH-1151, GH-1152) (GH-891); call related bytecode simplification (GH-896); minor bytecode
opcode handler optimizations (GH-903); refcount optimizations (GH-443,
* Remove support for refcounting-only (= no mark-and-sweep) memory management GH-973, GH-1042); minor RegExp compile/execute optimizations (GH-974,
option as too error prone: without mark-and-sweep garbage containing GH-1033); minor IEEE double handling optimizations (GH-1051); precomputed
reference loops or created during debugger paused state (with or without duk_hstring array index (GH-1056); duk_get_{type,type_mask}() optimization
reference loops) would "leak" until heap destruction (GH-1168) (GH-1077); explicit lexenv/varenv fields in duk_hcompfunc struct (GH-1132)
* Disable JSON stringify fastpath for plain buffers for now so that the Footprint:
virtual index properties get serialized correctly; fastpath to be added
back separately (GH-1197)
* Reject ArrayBuffers with a view offset/length in Node.js Buffer .slice() * Miscellaneous footprint improvements: RegExp compiler/executor (GH-977);
rather than accept such ArrayBuffers without actually respecting the internal duk_dup() variants (GH-990); allow stripping of (almost) all
view offset/length (GH-1197) built-ins for low memory builds (GH-989); remove internal accessor setup
helper and use duk_def_prop() instead (GH-1010); minor IEEE double handling
optimizations (GH-1051); precomputed duk_hstring array index (GH-1056);
internal value stack access improvements (GH-1058); shared bitpacked string
format for heap and thread initialization data (GH-1119); explicit
lexenv/varenv fields in duk_hcompfunc struct (GH-1132); omit duk_hcompfunc
_Formals array when it is safe to do so (GH-1141); omit duk_hcompfunc
_Varmap in more cases when it is safe to do so (GH-1146); reduce initial
bytecode allocation in Ecmascript compiler for low memory targets (GH-1146);
packed arguments for some internal helper calls (GH-1158, GH-1172); misc
internal helpers to reduce call site size (GH-1166, GH-1173); config options
for function .name and .fileName control (GH-1153); internal helper
duk_push_hstring_empty() (GH-1186, GH-1220)
* Fix duk_push_buffer_object() ArrayBuffer .byteLength to use 0 and .byteOffset Other bug fixes:
to use view's (byteOffset + byteLength), so that accesses to the ArrayBuffer
at the view's .byteOffset match the view at index 0 as normally expected;
previously .byteOffset and .byteLength were copied from the view as is which
makes the ArrayBuffer indices behave inconsistently with respect to the
view's .byteOffset (GH-1229)
* Fix JSON stringify fastpath handling of array gaps in JX and JC; they * Fix JSON stringify fastpath handling of array gaps in JX and JC; they
incorrectly stringified as 'null' (like in JSON) instead of 'undefined' incorrectly stringified as 'null' (like in JSON) instead of 'undefined'
@ -2205,10 +2272,6 @@ Planned
are in the same value stack slot (which is unusual but conceptually are in the same value stack slot (which is unusual but conceptually
clear) (GH-959) clear) (GH-959)
* Fix buffer object (duk_hbufobj) JSON serialization (bug present in 1.5.0):
buffer objects were omitted from serialization when they should be
serialized as normal objects instead (GH-867)
* Fix compilation error triggered when using pointer compression and the * Fix compilation error triggered when using pointer compression and the
default string table implementation (probe-based rather than chained) default string table implementation (probe-based rather than chained)
(GH-850) (GH-850)
@ -2239,26 +2302,10 @@ Planned
DUK_FILE_MACRO and DUK_LINE_MACRO, which matters if the standard file/line DUK_FILE_MACRO and DUK_LINE_MACRO, which matters if the standard file/line
macros have been replaced in duk_config.h (GH-897) macros have been replaced in duk_config.h (GH-897)
* Fix ARM64 platform detection for some Android targets (GH-1062)
* Fix AmigaOS3 portability issue by enabling math function replacements
automatically for AmigaOS on M68K, regardless of OS version or compiler
(GH-932)
* Fix Cygwin warning about shadowed 'accept' variable (GH-1098)
* Fix Cygwin/MinGW math issues related to pow2() and atan2() semantics
(GH-1099)
* Fix two-argument Math function (like Math.atan2()) argument coercion * Fix two-argument Math function (like Math.atan2()) argument coercion
order; the order was not guaranteed but specification requires left-to-right order; the order was not guaranteed but specification requires left-to-right
ordering (GH-943) ordering (GH-943)
* Fix genconfig.py forced option boolean comparison; for forced numeric option
value 0 genconfig would emit "#undef XXX" (instead of "#define XXX 0") and
for forced numeric option value 1 it would emit "#define XXX" (instead of
"#define XXX 1") (GH-954)
* Reduce harmless "unused function" warnings for GCC and Clang by using * Reduce harmless "unused function" warnings for GCC and Clang by using
__attribute__ ((unused)) for internal function declarations (GH-916, __attribute__ ((unused)) for internal function declarations (GH-916,
GH-942) GH-942)
@ -2276,43 +2323,23 @@ Planned
* Fix compile error when using 16-bit fields and disabling refcounting at * Fix compile error when using 16-bit fields and disabling refcounting at
the same time (GH-1207) the same time (GH-1207)
* Miscellaneous portability improvements: remove dependency on fmin() and Miscellaneous:
fmax() (GH-1072); remove signed shifts in lightfunc handling (GH-1172)
* Internal performance improvement: rework bytecode format to use an 8-bit * Incompatible change: bytecode opcode format reworks drop maximum function
opcode field (and 8-bit A, B, and C fields) to speed up opcode dispatch and constructor call argument count from 511 to 255, and maximum Ecmascript
by around 20-25% and avoid a two-level dispatch for EXTRA opcodes; the function constant count from 262144 to 65536 (GH-903)
performance optimized build is ~10kB larger while footprint optimized
build is slightly smaller (GH-903)
* Internal performance improvement: add optional fast path for dense arrays in * Add a human readable summary of 'new MyConstructor()' constructor call
Array.prototype operations like push() and pop() (GH-584, GH-1154) target when the target is non-constructable (GH-757)
* Miscellaneous performance improvements: avoid one extra shift when computing * Add a safe summary for "uncaught error" fatal error (GH-832)
reg/const pointers in the bytecode executor (GH-674); avoid value stack for
Array .length coercion (GH-862); value stack operation optimization
(GH-891); call related bytecode simplification (GH-896); minor bytecode
opcode handler optimizations (GH-903); refcount optimizations (GH-443,
GH-973, GH-1042); minor RegExp compile/execute optimizations (GH-974,
GH-1033); minor IEEE double handling optimizations (GH-1051); precomputed
duk_hstring array index (GH-1056); duk_get_{type,type_mask}() optimization
(GH-1077); explicit lexenv/varenv fields in duk_hcompfunc struct (GH-1132)
* Miscellaneous footprint improvements: RegExp compiler/executor (GH-977); * Minor changes to error messages for errors thrown by Duktape internals
internal duk_dup() variants (GH-990); allow stripping of (almost) all (GH-827, GH-839, GH-840, GH-1016)
built-ins for low memory builds (GH-989); remove internal accessor setup
helper and use duk_def_prop() instead (GH-1010); minor IEEE double handling * Change default built-in PRNG algorithm to xoroshiro128+ with SplitMix64
optimizations (GH-1051); precomputed duk_hstring array index (GH-1056); seed mixing; previous algorithm (Shamir's three-op algorithm) is still
internal value stack access improvements (GH-1058); shared bitpacked string used for low memory targets and targets without 64-bit types (GH-970)
format for heap and thread initialization data (GH-1119); explicit
lexenv/varenv fields in duk_hcompfunc struct (GH-1132); omit duk_hcompfunc
_Formals array when it is safe to do so (GH-1141); omit duk_hcompfunc
_Varmap in more cases when it is safe to do so (GH-1146); reduce initial
bytecode allocation in Ecmascript compiler for low memory targets (GH-1146);
packed arguments for some internal helper calls (GH-1158, GH-1172); misc
internal helpers to reduce call site size (GH-1166, GH-1173); config options
for function .name and .fileName control (GH-1153); internal helper
duk_push_hstring_empty() (GH-1186, GH-1220)
* Internal change: rework shared internal string handling so that shared * Internal change: rework shared internal string handling so that shared
strings are plain string constants used in macro values, rather than strings are plain string constants used in macro values, rather than
@ -2332,3 +2359,15 @@ Planned
of fastint and non-fastint aware code (GH-702) of fastint and non-fastint aware code (GH-702)
* Internal change: source code policy changes (GH-1169) * Internal change: source code policy changes (GH-1169)
Planned
=======
1.7.0 (XXXX-XX-XX)
------------------
2.1.0 (XXXX-XX-XX)
------------------
3.0.0 (XXXX-XX-XX)
------------------

172
doc/release-notes-v2-0.rst

@ -7,23 +7,42 @@ Release overview
Main changes in this release (see RELEASES.rst for full details): Main changes in this release (see RELEASES.rst for full details):
* Improve buffer bindings: plain buffers now behave like Uint8Arrays, * New tools/configure.py frontend tool replaces genconfig.py for configuring
and Duktape.Buffer has been removed with Uint8Array taking its place. and preparing Duktape sources for build.
* Many built-in behaviors have been aligned with ES2015 or ES2016, so * Buffer handling has been simplified: Duktape.Buffer has been removed and is
there are small behavioral changes throughout. replaced by Uint8Array, plain buffers now behave like Uint8Array objects.
Node.js Buffer behavior aligned with more recent Node.js Buffer API.
* FIXME * Implement more ES2015 and ES2016 functionality, and align some ES5.1
semantics with ES2015/ES2016. Implement WHATWG Encoding API with
TextEncoder() and TextDecoder() bindings.
* Some incompatible API changes, and several API additions. API and config
changes to avoid I/O dependencies (such as printf() and fopen()) in core
Duktape code to simplify porting.
* More configuration flexibility in dropping Duktape specific functionality
from build, e.g. coroutines and finalization.
* Disabled Ecmascript bindings are no longer present (instead of being present
but throwing a TypeError).
* Built-in functionality moved to optional extras: print/alert bindings,
logging, and module loader. New optional extras include a Node.js-like
module loader and a 'console' binding.
* Bug fixes, performance and footprint improvements.
The release has API incompatible changes, see upgrading notes below. The release has API incompatible changes, see upgrading notes below.
Upgrading from Duktape 1.5.x Upgrading from Duktape 1.x
============================ ==========================
There are API incompatible changes in this release. Whenever possible the There are API incompatible changes in this release. Whenever possible the
incompatible changes cause a compilation error (or warning) so that fixing incompatible changes cause a compilation error (or warning) so that fixing
call sites should be straightforward. Below are instructions on how to call sites should be straightforward. Below are instructions on how to
migrate from 1.5.x to 2.0.0. There are also bug fixes and other minor migrate from 1.x to 2.0.0. There are also bug fixes and other minor
behavioral changes which may affect some applications, see ``RELEASES.rst`` behavioral changes which may affect some applications, see ``RELEASES.rst``
for details. for details.
@ -42,7 +61,7 @@ and 2.x in the same application. For example::
rc = duk_safe_call(ctx, my_safe_call, 1 /*nargs*/, 1 /*nrets*/); rc = duk_safe_call(ctx, my_safe_call, 1 /*nargs*/, 1 /*nrets*/);
#endif #endif
If you're developing against Duktape master before 2.x release, ``DUK_VERSION`` If you're developing against Duktape master before 2.0 release, ``DUK_VERSION``
is set to 19999 so that you can use:: is set to 19999 so that you can use::
#if (DUK_VERSION >= 19999) #if (DUK_VERSION >= 19999)
@ -68,7 +87,7 @@ Or you can detect features specifically::
DUK_OPT_xxx feature option support removed DUK_OPT_xxx feature option support removed
------------------------------------------ ------------------------------------------
Duktape 2.x no longer supports ``DUK_OPT_xxx`` options given via the compiler Duktape 2.0 no longer supports ``DUK_OPT_xxx`` options given via the compiler
command line. Instead, all options are encoded in ``duk_config.h``. command line. Instead, all options are encoded in ``duk_config.h``.
To use custom Duktape options, use the ``tools/configure.py`` tool to create To use custom Duktape options, use the ``tools/configure.py`` tool to create
@ -92,7 +111,7 @@ See http://wiki.duktape.org/Configuring.html for details and examples.
To upgrade: To upgrade:
* If you're using the Duktape default configuration (and no ``DUK_OPT_xxx``) * If you're using the Duktape default configuration and no ``DUK_OPT_xxx``
compiler options, no actions are needed. compiler options, no actions are needed.
* Otherwise, remove ``DUK_OPT_xxx`` options from the compilation command and * Otherwise, remove ``DUK_OPT_xxx`` options from the compilation command and
@ -109,8 +128,8 @@ To upgrade:
``DUK_OPT_HAVE_CUSTOM_H``, use ``--fixup-line '#include "duk_custom.h"'`` ``DUK_OPT_HAVE_CUSTOM_H``, use ``--fixup-line '#include "duk_custom.h"'``
in ``tools/configure.py`` options. in ``tools/configure.py`` options.
- Finally, you can remove your custom header and add the equivalent options - Finally, you can in some cases remove your custom header and use
to ``tools/configure.py`` when possible. equivalent config options for ``tools/configure.py``.
Config option changes Config option changes
--------------------- ---------------------
@ -118,6 +137,11 @@ Config option changes
There are several new config options and some existing config options have There are several new config options and some existing config options have
been removed. been removed.
To upgrade:
* Review any ``DUK_OPT_xxx`` or ``DUK_USE_xxx`` options in use against
``config/config-options/*.yaml``.
Built-ins disabled in configuration are now absent Built-ins disabled in configuration are now absent
-------------------------------------------------- --------------------------------------------------
@ -167,8 +191,8 @@ There are some tooling changes in this release:
* The tooling includes a new ``tools/configure.py`` tool which creates * The tooling includes a new ``tools/configure.py`` tool which creates
a ``duk_config.h`` and matching prepared sources simultaneously. This a ``duk_config.h`` and matching prepared sources simultaneously. This
allows use of ROM built-ins from the distributable (previously required a allows use of ROM built-ins from the distributable. Previously ROM
manual ``dist.py --rom-support ...`` command. built-ins required a manual ``dist.py --rom-support ...`` command.
* The ``make_dist.py`` utility in Duktape main repo has been renamed to * The ``make_dist.py`` utility in Duktape main repo has been renamed to
``dist.py`` and no longer supports ``--rom-support``, ``dist.py`` and no longer supports ``--rom-support``,
@ -185,18 +209,19 @@ To upgrade:
* If you're just using the default sources and ``duk_config.h`` in the * If you're just using the default sources and ``duk_config.h`` in the
distributable, no changes are needed. distributable, no changes are needed.
* If you're using ``genconfig.py``, check the path; correct path is now * If you're using ``genconfig.py`` considering using ``tools/configure.py``
``tools/genconfig.py``. Consider replacing genconfig.py with configure.py. instead. If you keep on using ``genconfig.py``, update path to
``tools/genconfig.py``.
* If you're using ROM built-ins via ``make_dist.py``, change your build to * If you're using ROM built-ins via ``make_dist.py``, change your build to
use ``tools/configure.py`` instead, and rename ``--user-builtins-metadata`` use ``tools/configure.py`` instead, and change ``--user-builtins-metadata``
options to ``--builtin-file``. option argument(s) to ``--builtin-file``.
Dist package file changes Dist package file changes
------------------------- -------------------------
* Configuration metadata is now in unpacked form in ``dist/config`` to match * Configuration metadata is now in unpacked form in ``dist/config`` to match
the Duktape master repo and make config files more convenient to patch. the Duktape master repo and to make config files more convenient to patch.
The ``dist/tools/genconfig.py`` tool no longer accepts a tar.gz metadata The ``dist/tools/genconfig.py`` tool no longer accepts a tar.gz metadata
argument. argument.
@ -218,15 +243,16 @@ Dist package file changes
Buffer behavior changes Buffer behavior changes
----------------------- -----------------------
There are a lot of buffer behavior changes in the 2.x release; see detailed There are a lot of buffer behavior changes in the 2.0 release; see detailed
changes below. Here's a summary of changes: changes below and in RELEASES.rst. Here's a summary of changes:
* ``Duktape.Buffer`` has been removed. Plain buffers now behave like * ``Duktape.Buffer`` has been removed. Plain buffers now behave like
``Uint8Array`` instances to the extent possible. They don't have a property ``Uint8Array`` instances to the extent possible. They don't have a property
table, however, which causes some limitations. There are many small changes table, however, which causes some limitations. Plain buffers ToObject()
to how plain buffers are treated by standard built-ins as a result. For coerce to an actual Uint8Array object with the same backing buffer. There
example, string coercion (``String(plainBuffer)``) now mimics Uint8Array and are many small changes to how plain buffers are treated by standard built-ins
usually results in the string ``[object Uint8Array]``. as a result. For example, string coercion (``String(plainBuffer)``) now
mimics Uint8Array and usually results in the string ``[object Uint8Array]``.
* Plain buffers have an inherited ``.buffer`` getter property which returns an * Plain buffers have an inherited ``.buffer`` getter property which returns an
ArrayBuffer object backing to the same underlying plain buffer. Because ArrayBuffer object backing to the same underlying plain buffer. Because
@ -237,9 +263,9 @@ changes below. Here's a summary of changes:
view (such as Uint8Array), the ArrayBuffer's .byteOffset will be set to 0 view (such as Uint8Array), the ArrayBuffer's .byteOffset will be set to 0
and its .byteLength will be set to view.byteOffset + view.byteLength. This and its .byteLength will be set to view.byteOffset + view.byteLength. This
ensures that accessing the ArrayBuffer at view.byteOffset returns the same ensures that accessing the ArrayBuffer at view.byteOffset returns the same
value as when accessing view at index 0, which is the common relationship. value as when accessing view at index 0, which is the usual relationship
Up to Duktape 1.6.x the ArrayBuffer's .byteOffset and .byteLength would be between a view and its backing ArrayBuffer. Up to Duktape 1.6.x the
the same as the view's. ArrayBuffer's .byteOffset and .byteLength would be the same as the view's.
* Non-standard properties, such as virtual indices and ``.length`` have been * Non-standard properties, such as virtual indices and ``.length`` have been
removed from ArrayBuffer and DataView. The ``.byteOffset``, ``.byteLength``, removed from ArrayBuffer and DataView. The ``.byteOffset``, ``.byteLength``,
@ -289,7 +315,15 @@ To upgrade:
v0.12.1 and v6.9.1 in general. v0.12.1 and v6.9.1 in general.
* If you're using plain buffers, review their usage especially in Ecmascript * If you're using plain buffers, review their usage especially in Ecmascript
code. code, in particular:
- Because plain buffers now mimic Uint8Array (a view), they are treated as
initializer values when used as typed array constructor arguments. For
example, ``new Uint32Array(plainBuffer)`` will create a new Uint32Array
rather than a view into the plain buffer.
- To create a view into the plain buffer, use the same approach as with a
Uint8Array, e.g. ``new Uint32Array(plainBuffer.buffer)``.
* Regardless of buffer type(s) in use: * Regardless of buffer type(s) in use:
@ -320,8 +354,8 @@ Some detailed changes, not exhaustive; see ``RELEASES.rst`` and
- ``plainBuffer instanceof Uint8Array`` is true. - ``plainBuffer instanceof Uint8Array`` is true.
* Plain buffer Object.prototype.toString() now usually (assuming no overridden * Plain buffer Object.prototype.toString() now usually, assuming no overridden
.toString()) yields ``[object Uint8Array]`` instead of ``[object Buffer]``. .toString(), yields ``[object Uint8Array]`` instead of ``[object Buffer]``.
* Plain buffer inherits from Uint8Array.prototype instead of * Plain buffer inherits from Uint8Array.prototype instead of
Duktape.Buffer.prototype. Duktape.Buffer.prototype.
@ -358,7 +392,7 @@ Some detailed changes, not exhaustive; see ``RELEASES.rst`` and
* ``new ArrayBuffer(plainBuffer)`` no longer creates a new ArrayBuffer with * ``new ArrayBuffer(plainBuffer)`` no longer creates a new ArrayBuffer with
the same underlying plain buffer; instead, the plain buffer gets coerced to the same underlying plain buffer; instead, the plain buffer gets coerced to
zero and creates a zero-length ArrayBuffer. This matches how an ArrayBuffer zero and creates a zero-length ArrayBuffer. This matches how a Uint8Array
argument is handled in ``new ArrayBuffer()``. argument is handled in ``new ArrayBuffer()``.
- ``new Buffer(plainBuffer)`` no longer special cases plain buffer and gets - ``new Buffer(plainBuffer)`` no longer special cases plain buffer and gets
@ -403,6 +437,8 @@ Some detailed changes, not exhaustive; see ``RELEASES.rst`` and
* Node.js ``Buffer`` and ``Buffer.prototype`` methods now accept plain buffers. * Node.js ``Buffer`` and ``Buffer.prototype`` methods now accept plain buffers.
* A plain buffer is accepted as a constructor "replacement value".
Pointer behavior changes Pointer behavior changes
------------------------ ------------------------
@ -435,6 +471,8 @@ There are very minor changes to lightfunc value behavior:
lightfuncs themselves are considered strict functions, this only happens lightfuncs themselves are considered strict functions, this only happens
when the call target is not a lightfunc but the "this" binding is. when the call target is not a lightfunc but the "this" binding is.
* A lightfunc is accepted as a constructor "replacement value".
To upgrade: To upgrade:
* If you're using lightfuncs, review their handling. * If you're using lightfuncs, review their handling.
@ -835,6 +873,36 @@ To upgrade:
or logging yourself and using AppNotify (``duk_debugger_notify()``) to or logging yourself and using AppNotify (``duk_debugger_notify()``) to
forward print/alert or logger text. forward print/alert or logger text.
Internal duk_harray affects debugger array inspection
-----------------------------------------------------
Duktape 2.x introduces an internal ``duk_harray`` type to represent arrays.
The array ``.length`` property is no longer stored in the property table of
the array but is a C struct field in ``duk_harray`` and the property visible
to Ecmascript code is virtual.
As a result, array ``.length`` is not visible when inspecting ordinary array
properties using e.g. GetObjPropDesc or GetObjPropDescRange. Instead, array
``.length`` is an artificial property ``"length"`` returned by GetHeapObjInfo.
To upgrade:
* If the debug client uses array ``.length`` for e.g. UI purposes, ensure
the artificial property ``"length"`` is used instead.
Other debugger changes
----------------------
* Artificial properties renamed for consistency with internal renaming:
- ``compiledfunction`` -> ``compfunc``
- ``nativefunction`` -> ``natfunc``
- ``bufferobject`` -> ``bufobj``
- ``bound`` -> ``boundfunc``
Debug print config options changed Debug print config options changed
---------------------------------- ----------------------------------
@ -878,36 +946,6 @@ To upgrade:
- Convert debug level options from ``DUK_USE_{D,DD,DDD}PRINT`` to the - Convert debug level options from ``DUK_USE_{D,DD,DDD}PRINT`` to the
equivalent ``DUK_USE_DEBUG_LEVEL`` (0, 1, or 2). equivalent ``DUK_USE_DEBUG_LEVEL`` (0, 1, or 2).
Internal duk_harray affects debugger array inspection
-----------------------------------------------------
Duktape 2.x introduces an internal ``duk_harray`` type to represent arrays.
The array ``.length`` property is no longer stored in the property table of
the array but is a C struct field in ``duk_harray`` and the property visible
to Ecmascript code is virtual.
As a result, array ``.length`` is not visible when inspecting ordinary array
properties using e.g. GetObjPropDesc or GetObjPropDescRange. Instead, array
``.length`` is an artificial property ``"length"`` returned by GetHeapObjInfo.
To upgrade:
* If the debug client uses array ``.length`` for e.g. UI purposes, ensure
the artificial property ``"length"`` is used instead.
Other debugger changes
----------------------
* Artificial properties renamed for consistency with internal renaming:
- ``compiledfunction`` -> ``compfunc``
- ``nativefunction`` -> ``natfunc``
- ``bufferobject`` -> ``bufobj``
- ``bound`` -> ``boundfunc``
Fatal error and panic handling reworked Fatal error and panic handling reworked
--------------------------------------- ---------------------------------------
@ -1050,6 +1088,8 @@ Small changes related to adding symbol support:
Other incompatible changes Other incompatible changes
-------------------------- --------------------------
Incompatible changes (not exhaustive, also see RELEASES.rst):
* Normal and constructor function call argument limit is now 255, down from * Normal and constructor function call argument limit is now 255, down from
the previous 511. the previous 511.
@ -1060,9 +1100,9 @@ Other incompatible changes
other API calls. A NULL pointer not causes memory unsafe behavior, as with other API calls. A NULL pointer not causes memory unsafe behavior, as with
all other API calls. all other API calls.
* ``duk_def_prop()`` now ToString() coerces its argument rather than requiring * ``duk_def_prop()`` now ToPropertyKey() coerces its argument rather than
the key to be a string. This allows e.g. numbers to be used as property requiring the key to be a string. This allows e.g. numbers to be used as
keys. property keys.
* ``duk_char_code_at()`` and ``String.charCodeAt()`` now return 0xFFFD (Unicode * ``duk_char_code_at()`` and ``String.charCodeAt()`` now return 0xFFFD (Unicode
replacement character) if the string cannot be decoded as extended UTF-8, replacement character) if the string cannot be decoded as extended UTF-8,

Loading…
Cancel
Save