The engine's and dependencies' versions are the ones I've tested with.
Lower version will probably work too, but I don't want to spend more
time testing now so I'll play it safe.
Calling the parsing function could have been done without the ugly table
using |eval|, but this seemed to degrade performance significantly (by
about 3 %). This is probably because engines optimize badly in presence
of |eval|.
The method used in this patch does not change the benchmark suite
execution speed statistically significantly on V8.
Detailed results (benchmark suite totals):
---------------------------------
Test # Before After
---------------------------------
1 38.24 kB/s 38.28 kB/s
2 38.35 kB/s 38.15 kB/s
3 38.43 kB/s 38.40 kB/s
4 38.53 kB/s 38.20 kB/s
5 38.25 kB/s 38.39 kB/s
---------------------------------
Average 38.36 kB/s 38.39 kB/s
---------------------------------
Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.151 Safari/534.1
The previous default name was "exports.parser". This meant that to use
the generated parser in Node.js, you had to use code like this:
var parser = require("./my-cool-parser").parser;
parser.parse(...);
Now you can shorten it a bit:
var parser = require("./my-cool-parser");
parser.parse(...);
The shorter version makes sense since no other objects except the parser
are exported from the module.
Originally I wanted to be very explicit with accesses to global object,
but since all this file is about extending it, the |global.| qualifier
seems more like noise.
Require PEG only in the "parser" task -- it may not exist when executing
the "build" task. Also don't make the "build" task dependent on the
"parser" to break a dependency circle.
Or, swapped Ruby dependency for a Node dependency.
The build script was also modified to always regenerate the parser (in
case of the "parser" task) or rebuild the library (in case of the
"build" task) even if the source files were not modified. Not doing this
led to problems when the generating code changed but the files didn't
(which happened often during development).
This patch prevents portability problems. In particular, it fixes a
problem where "SyntaxError: Invalid range in character class." error
appeared when using command-line version on Widnows (see GH-13).
David Majda