Cleanups for 1.3.0 release

[svaarala]

• Recheck bytecode dump/load number constant loading: should have fastint check
• Executor restart after NEW operation to support debugger breakpoints correctly
• Side effect torture; fake call in every refzero queue pump? Add refzero finalizer torture config option #304
• Side effect torture; mark-and-sweep fake finalizer Add mark-and-sweep finalizer torture option #313
• Add refzero and mark-and-sweep finalizer torture to release checklist
• duk_tval pointer warning without DUK_OPT_FASTINT
• Release notes: Duktape.modLoaded[] cache entry change
• Release notes: behavior change for module load error (de-register module instead of keeping partial module in cache)
• Release notes: debugger breakpoint behavior change
• Expand code policy check coverage to Ecmascript testcases and example code
• Clean up FIXMEs from Ecmascript testcases and expand code policy check coverage
• JSON stringify fastpath portability assumption ("%lld" format and "long long" type) => postponed to More JSON.stringify() fast path cleanups #325
• Add a minimal Travis test (codepolicycheck)
• Extend Travis setup to run the basic API and Ecmascript tests
• Remove hard Ant/Java dependency from make dist (needed for closure which is not critical)
• Add .gitattributes for LF Add a .gitattributes file with eol=lf #317
• Add C++ comments to code policy check
• Allow build with codepolicycheck failures, but reject Travis test
• Mark bufferobject API calls experimental (minor tweaks may happen in 1.4)
• Finalize release notes
• Cleanup for make dist, see: 1288329#commitcomment-13002075
• Fix issues from side effect torture tests => tracked in Protect call handling and longjmp handling from finalizer side effects #314, fixed after 1.3.0 unless there are issues that can be triggered with actual user code (and not just by internal torture testing)
• Update index page LOC, lowmemory startup size, code footprint (with buffer support)
• Update index page and README features list, check that they match
• Review experimental API call tags
• Compilation test: Linux x86 and x64, gcc and clang
• Compilation test: Linux x32 gcc
• Compilation test: Windows x86 and x64, MSVC and Cygwin/Mingw, Windows DLL
• Compilation test: OSX
• Compilation test: Linux MIPS gcc
• Compilation test: Linux ARMEL gcc
• Compilation test: Linux SH4 gcc
• Compilation test: embedded mixed endian ARM Linux, gcc - works but has some cast issues (already present in 1.2), Bufferobject field write sign handling issues on an exotic old ARM platform #336

[fatcerberus]

So, how far off is 1.3? 😉

[svaarala]

For minor releases the release scope doesn't need to be fixed in advance, so I'm not really sure :)

But I'd at least want to complete the buffer-related changes so that they didn't need further changes right away. There are also several small performance improvements to be completed and merged, but none of them are mandatory to make the release a useful improvement over the previous one.

I had originally planned to incorporate an initial step for the duk_config.h change (#64) in this release. That's still possible but I'd want to make sure the disruption to users is minimal so it'd also be possible to postpone that to the next release.

[svaarala]

I'm doing some issue pruning for 1.3 release - unfortunately some wish list items must be postponed so that the new features in 1.3 (over 1.2) can make an official release. Sorry! :( Feel free to point out if I postponed something critical.

[svaarala]

Moved a few more issues to 1.4 - the stuff left for 1.3 is basically buffer and duk_config.h cleanups which should be possible to complete in by early next week.

[svaarala]

The main thing left for 1.3 will be compiler and platform testing and checking for warning-free compilation (at least with defaults).

[svaarala]

There are compile warnings with all low memory options enabled (in particular non-verbose error messages). These were also present in 1.2 and are quite messy to try to eliminate.

[svaarala]

Mixed endian ARM linux target with a gcc-3 based toolchain has warnings:

duk_tval.c:22: warning: `duk_tval_set_number_chkfast' declared inline after being called
duk_tval.c:70: warning: `duk_tval_get_number_packed' declared inline after being called
duk_util_bufwriter.c:281: warning: `duk_raw_read_u16_be' declared inline after being called
duk_util_bufwriter.c:293: warning: `duk_raw_read_u32_be' declared inline after being called
duk_util_bufwriter.c:305: warning: `duk_raw_read_double_be' declared inline after being called
duk_util_bufwriter.c:323: warning: `duk_raw_write_u16_be' declared inline after being called
duk_util_bufwriter.c:334: warning: `duk_raw_write_u32_be' declared inline after being called
duk_util_bufwriter.c:345: warning: `duk_raw_write_double_be' declared inline after being called
duk_replacements.c:78: warning: `duk_repl_isinf' defined but not used

There seems to be some variability in older compilers in where inline attributes are allowed/warned about. This will need revisiting after 1.3 release.

[svaarala]

There's also a double-to-integer cast issue on the same exotic ARM target, which is triggered by Node.js Buffer and DataView, tracked in #336. Similar issues are possible on targets where double-integer casts are broken.

[svaarala]

To clarify above, these double-to-integer cast issues have been present before and affect other libraries too, so it's not a new issue introduced in this release.

[fatcerberus]

Oddly, there appear to be double-to-integer cast issues with MSVC instrumented profiling as well. I mentioned this before, but the double-to-int64 self-test fails on some machines under the profiler.

You wouldn't thinking converting float to integer would be this hard... :)

[svaarala]

Minor trivia is merged to master now. I'm starting the release prep branch and finalize the release in a few hours. If you have any issues with master, now is the time to say so :-)

[fatcerberus]

Yay, Duktape 1.3 is coming! From what I've seen already, it was worth the wait. 😄

[svaarala]

Still running release checklist tests, these torture tests and assertion enabled tests take a lot of time :) Hopefully they'd be automated one day, not yet though 🐶

[svaarala]

Release is tagged and binaries built. Next up is updating the website.

[svaarala]

Website is updated now also :-) 🍺

[fatcerberus]

Thanks Sami, now I can move forward with minisphere 2.0 and make ArrayBuffers a more pervasive part of my API. 😄

[svaarala]

You're welcome :)

[svaarala]

Posted the performance numbers to the Wiki here: http://wiki.duktape.org/Performance130.html

[fatcerberus]

Nice, a solid improvement across the board. One thing jumps out at me though: The buffer object tests. The performance on those improved by A LOT! What changed?

[svaarala]

I added a fast path for them so that working with buffer objects would be similar to working with plain buffers. Prior to that buffer objects didn't have a fast path - which basically meant every numbered index lookup would cause a string conversion for the key etc.