This is the first of many commits that gradually convert PEG.js's test
suite from QUnit to Jasmine, cleaning it up on the way.
Main reason for the change is that Jasmine allows nested contexts,
allowing to structure the tests in a better way than QUnit. Moreover,
the tests needed to be cleaned up a bit.
This option enables/disables the results cache in generated parsers.
Until now, it was always enabled, but after this commit it needs to be
enabled explicitly (i.e. the |cache| option default value is |false|).
The reason is that parsing without it is *much* faster according to the
benchmark.
Note that disabling the cache breaks the linear parsing time guarantee,
meaning that with some grammars you can get exponential parsing time
with respect to the input length. This, together with the possibility of
improving the cache performance in the future, is the reason to keep it
as an option.
Speed impact
------------
Before: 214.08 kB/s
After: 827.52 kB/s
Difference: 286.54%
Size impact
-----------
Before: 1045396 b
After: 949783 b
Difference: -9.15%
(Measured by /tools/impact with Node.js v0.6.6 on x86_64 GNU/Linux.)
The "|| trick" is too brittle in this case -- it wouldn't work e.g. for
options with default value |true| and passed value |false|, enforcing
inconsistent default values handling.
This commit makes the library define the |PEG| global variable (for
browser export) and possibly assign it into |module.exports| (for
Node.js export) later. The |module.exports| assignment is done *outside*
the main library |function| statement.
The big idea behind this is to make copy & paste inclusion of the
library into another code easier -- one just needs to strip the last
three lines.
Both the browser and the command-line version of the benchmark suite
runner now allow users to specify a value of the |trackLineAndColumn|
option. In case of the command-line version this required a minor CLI
redesign.
This option makes the generated parser track line and column during
parsing. Tracked line and column are made available inside actions and
predicates as |line| and |column| variables.
Note that in actions these variables denote start position of the
action's expression while in predicates they denote the current
position. The slightly different behavior is motivated by expected
usage.
This simplifies the code a bit and makes the AST more regular (each node
type has a fixed set of properties). The latter may get useful later
when generalizing visitors.
David Majda