From 40d58a80cd95c7b2f5ecb8f46523770bf0186421 Mon Sep 17 00:00:00 2001 From: Sami Vaarala Date: Sat, 16 Aug 2014 04:36:46 +0300 Subject: [PATCH] Misc RST formatting fixes --- doc/json.rst | 1 + doc/lightweight-function-value.rst | 1 - doc/logging.rst | 6 ++++++ doc/modules.rst | 5 +++++ doc/number-conversion.rst | 9 ++++++++- doc/release-checklist.rst | 27 +++++++++++++++++++++++++++ doc/sorting.rst | 6 +++++- doc/test262-status.rst | 15 +++++++++++---- doc/testcases.rst | 2 -- doc/uri.rst | 1 - 10 files changed, 63 insertions(+), 10 deletions(-) diff --git a/doc/json.rst b/doc/json.rst index 9fdb9742..9440d0b2 100644 --- a/doc/json.rst +++ b/doc/json.rst @@ -63,6 +63,7 @@ because JSON.parse() and JSON.stringify() are intended to be strict interfaces. See also: * http://json.org/ + * http://bolinfest.com/essays/json.html Notes on stringify() diff --git a/doc/lightweight-function-value.rst b/doc/lightweight-function-value.rst index 51fd93da..cc22ece8 100644 --- a/doc/lightweight-function-value.rst +++ b/doc/lightweight-function-value.rst @@ -109,4 +109,3 @@ and don't have an automatic prototype object. Even so, there are close to 200 built-in functions, so the footprint of the ``duk_hnativefunction`` objects is around 16kB, not taking into account allocator overhead. - diff --git a/doc/logging.rst b/doc/logging.rst index c5a42264..705733e8 100644 --- a/doc/logging.rst +++ b/doc/logging.rst @@ -134,7 +134,9 @@ Each logger object has as its internal prototype ``Duktape.Logger.prototype``. The prototype provides: * ``n``: a default name ('anon') + * ``l``: a default log level (2, info level) + * log writing methods for each level Lazy formatting @@ -238,9 +240,13 @@ Existing frameworks and related links ===================================== * http://ajaxpatterns.org/Javascript_Logging_Frameworks + * http://getfirebug.com/logging + * http://log4javascript.org/docs/quickstart.html + * http://log4js.berlios.de/ + * http://benalman.com/projects/javascript-debug-console-log/ Future work diff --git a/doc/modules.rst b/doc/modules.rst index ee1499f1..e121945d 100644 --- a/doc/modules.rst +++ b/doc/modules.rst @@ -252,6 +252,7 @@ have been defined. References summarizing several module frameworks: * http://addyosmani.com/writing-modular-js/ + * http://wiki.commonjs.org/wiki/Modules Module loading APIs or "formats": @@ -263,9 +264,13 @@ Module loading APIs or "formats": * CommonJS: - http://wiki.commonjs.org/wiki/Modules/1.1.1 + - https://github.com/joyent/node/blob/master/lib/module.js + - https://github.com/commonjs/commonjs/tree/master/tests/modules + - http://requirejs.org/docs/commonjs.html + - http://dailyjs.com/2010/10/18/modules/ * NodeJS, more or less CommonJS: diff --git a/doc/number-conversion.rst b/doc/number-conversion.rst index e84b499d..a341ed09 100644 --- a/doc/number-conversion.rst +++ b/doc/number-conversion.rst @@ -213,8 +213,11 @@ output. Example: * (123).toFixed(3) -> "123.000" + * (0.1).toFixed(0) -> "0" + * (0.9).toFixed(0) -> "1" (rounds up) + * (1e21).toFixed(10) -> "1e+21" (falls back to ToString()) toExponential() @@ -245,11 +248,16 @@ or if the topmost (most significant) digit has an exponent of -7 or less toPrecision() uses an exponent notation. Examples: * (1234).toPrecision(4) -> "1234" + * (1234).toPrecision(3) -> "1.23e+3" + * (9876).toPrecision(3) -> "9.88e+3" (rounding up is necessary) + * (9999).toPrecision(3) -> "1.00e+4" (rounding up and carrying over the leading digit is necessary) + * (0.000001).toPrecision(2) -> "0.0000010" + * (0.0000001).toPrecision(2) -> "1.0e-7" Note that leading fractional zeroes are prepended if necessary. Trailing @@ -730,4 +738,3 @@ Future work as arbitrary radix support, some of the precision modes etc), even if it is not fully compatible with Ecmascript semantics. The impact of custom number formatting is about 8-9 kilobytes of code footprint at the moment. - diff --git a/doc/release-checklist.rst b/doc/release-checklist.rst index 577e5d5f..e7e77dc8 100644 --- a/doc/release-checklist.rst +++ b/doc/release-checklist.rst @@ -5,9 +5,13 @@ Release checklist * Git maintenance - ensure git commits are up-to-date + - ensure branches are merged, unused branches deleted (also remotely) + - ensure branches are rebased where applicable + - git fsck --full + - git gc --aggressive * Ditz maintenance @@ -31,7 +35,9 @@ Release checklist build because dist package contains RELEASES.txt) - New release is in place + - Release log entries match ditz issues + - Release date is in place * Compilation tests: clean compile with common debug options @@ -39,16 +45,27 @@ Release checklist and with no debug options: - **FIXME: incomplete list, automate compilation tests** + - Linux x86-64 gcc + - Linux x86-64 gcc + -m32 + - Linux x86-64 clang + - Linux x86-64 clang + -m32 + - FreeBSD clang + - FreeBSD clang + -m32 + - Windows MinGW + - Windows MinGW-w64 + - Windows MSVC (cl) x86 + - Windows MSVC (cl) x64 + - Linux MIPS gcc * Ecmascript testcases @@ -58,6 +75,7 @@ Release checklist - On x86-64: - make qecmatest # quick test + - make vgecmatest # valgrind test - Run testcases on all endianness targets @@ -120,31 +138,40 @@ Release checklist * Check source dist contents - Check file list + - Grep for FIXME and XXX + - Trivial compile test for combined source + - Trivial compile test for separate sources (important because it's easy to forget to add files in make_dist.sh) * Store binaries and update website downloads page - Release date + - Link + - Date + - "latest" class * Build website - Readthrough + - Test that the Duktape REPL (Dukweb) works * Ditz release - ``ditz release vN.N`` + - git add and commit ditz issues * Git release and tag - ``git tag -l -n1`` to list current tags + - ``git tag -s -m "" vN.N.N`` * Upload and test diff --git a/doc/sorting.rst b/doc/sorting.rst index 015b12a4..b7bee1bf 100644 --- a/doc/sorting.rst +++ b/doc/sorting.rst @@ -21,10 +21,15 @@ Array.prototype.sort() Some desirable qualities: * Small code footprint + * Bounded C recursion + * In-place sorting (no large temporary allocations) + * O(n log n) average performance (weaker) + * O(n log n) worst case performance (stronger) + * Stability (don't reorder elements which compare equal) C recursion is effectively bounded if recursion depth is O(log n) for a small @@ -86,4 +91,3 @@ elements are expected to be almost always already in order. Current algorithm used is insertion sort, which works well in-place and handles already (almost) ordered cases efficiently. - diff --git a/doc/test262-status.rst b/doc/test262-status.rst index 2a9c43ac..302c48c0 100644 --- a/doc/test262-status.rst +++ b/doc/test262-status.rst @@ -36,10 +36,13 @@ cases to fail: * Duktape follows the E5.1 regexp syntax strictly (except for allowing the ``\$`` identity escape). Some things that fail in test cases: - - invalid backreferences (e.g. ``/\1/``) - - invalid identity escapes (e.g. ``/\a/``) - - invalid decimal escapes in character classes (e.g. ``[\12-\14]``) - - special characters appearing literally without escape (e.g. ``]``) + - invalid backreferences (e.g. ``/\1/``) + + - invalid identity escapes (e.g. ``/\a/``) + + - invalid decimal escapes in character classes (e.g. ``[\12-\14]``) + + - special characters appearing literally without escape (e.g. ``]``) * Duktape has a conservative limit on the C recursion required to execute regexps. This limit can cause several test cases to fail. @@ -392,9 +395,13 @@ Arrays over 2G elements long will probably have such issues. There are several similar failing test cases, e.g.: * ch15/15.4/15.4.4/15.4.4.12/S15.4.4.12_A3_T3 + * ch15/15.4/15.4.4/15.4.4.14/15.4.4.14-9-9 + * ch15/15.4/15.4.4/15.4.4.15/15.4.4.15-5-12 + * ch15/15.4/15.4.4/15.4.4.15/15.4.4.15-5-16 + * ch15/15.4/15.4.4/15.4.4.15/15.4.4.15-8-9 Fortunately these don't have much real world relevance. diff --git a/doc/testcases.rst b/doc/testcases.rst index 25a03540..8d36f01e 100644 --- a/doc/testcases.rst +++ b/doc/testcases.rst @@ -227,5 +227,3 @@ Future work * Keep simple input-output model but add includes. There is a lot of boilerplate now for basic things like dumping descriptors. - - diff --git a/doc/uri.rst b/doc/uri.rst index dc8e3cb0..5edc462f 100644 --- a/doc/uri.rst +++ b/doc/uri.rst @@ -116,4 +116,3 @@ It would be nice to be able to: Because the API requirements are strict, these cannot be added to the standard API without breaking compliance. Custom URI encoding/decoding functions could provide these extended semantics. -