Version information is already present in package.json and no code uses
the VERSION file anymore. It doesn't make sense too keep it just for the
sake of following an old convention as it is a maintenance burden.
The core of the transition is getting rid of Makefile and replacing it
with gulpfile.js. The rest is details (fixing dependencies, changing all
references to "make", etc.).
Target/task names mostly stay the same, so in most cases "gulp foo" does
what "make foo" did before. The only exceptions are "make browser" and
"make browserclean", which are now "gulp browser:build" and "gulp
browser:clean" (it feels more systematic).
Functionality is mostly unchanged (modulo Gulp clutter in the console),
but there are two small exceptions:
gulp spec
The reporter now displays just dots while previously it displayed
spec descriptions. There is also a deprecation warning (most likely
because I used an old version of gulp-jasmine in order to support
Jasmine 1.x). I kept these issues unfixed because I plan to switch
to Mocha soon (#409).
gulp browser:build
The copyright header is now added manually both to the development
and minified build. Before, it was added only to the development
build and the minified build relied on preserving it using "uglify
--comments". This was broken since switching to //-style comments.
There is now also an empty line between the header and the source
code.
Fixes#444.
Note the update required disabling the "no-control-regex" rule, which
started reporting following errors:
/Users/dmajda/Programming/PEG.js/pegjs/lib/compiler/js.js
22:16 error Unexpected control character in regular expression no-control-regex
27:16 error Unexpected control character in regular expression no-control-regex
28:16 error Unexpected control character in regular expression no-control-regex
51:16 error Unexpected control character in regular expression no-control-regex
52:16 error Unexpected control character in regular expression no-control-regex
/Users/dmajda/Programming/PEG.js/pegjs/lib/parser.js
76:16 error Unexpected control character in regular expression no-control-regex
77:16 error Unexpected control character in regular expression no-control-regex
90:16 error Unexpected control character in regular expression no-control-regex
91:16 error Unexpected control character in regular expression no-control-regex
Rename compiler passes as follows:
reportLeftRecursion -> reportInfiniteRecursion
reportInfiniteLoops -> reportInfiniteRepetition
This reflects the fact that both passes detect different ways of causing
the same problem (possible infinite loop when parsing).
The new terminology is more precise and in line with commonly used
programming languages.
The change involves mainly renaming related compiler pass and files
associated with it.
Implement the swap and change various directives in the source code. The
"make hint" target becomes "make lint".
The change leads to quite some errors being reported by ESLint. These
will be fixed in subsequent commits.
Note the configuration enables just the recommended rules. Later I plan
to enable more rules to enforce the coding standard. The configuration
also sets the environment to "node", which is far from ideal as the
codebase contains a mix of CommonJS, Node.js and browser code. I hope to
clean this up at some point.
Travis CI builds with Node.js 0.8.x started to fail:
https://travis-ci.org/dmajda/pegjs/jobs/26691570
Rather than investigating what's wrong I decided to stop supporting Node
0.8.x. Node.js 0.10.x is here for over a year, which should be enough
time for everyone to upgrade in the fast-paced Node.js world.
Split lib/utils.js into multiple files. Some of the functions were
generic, these were moved into files in lib/utils. Other funtions were
specific for the compiler, these were moved to files in lib/compiler.
This commit only moves functions around -- there is no renaming and
cleanup performed. Both will come later.
Before this commit, the |expected| and |error| functions didn't halt the
parsing immediately, but triggered a regular match failure. After they
were called, the parser could backtrack, try another branches, and only
if no other branch succeeded, it triggered an exception with information
possibly based on parameters passed to the |expected| or |error|
function (this depended on positions where failures in other branches
have occurred).
While nice in theory, this solution didn't work well in practice. There
were at least two problems:
1. Action expression could have easily triggered a match failure later
in the input than the action itself. This resulted in the
action-triggered failure to be shadowed by the expression-triggered
one.
Consider the following example:
integer = digits:[0-9]+ {
var result = parseInt(digits.join(""), 10);
if (result % 2 === 0) {
error("The number must be an odd integer.");
return;
}
return result;
}
Given input "2", the |[0-9]+| expression would record a match
failure at position 1 (an unsuccessful attempt to parse yet another
digit after "2"). However, a failure triggered by the |error| call
would occur at position 0.
This problem could have been solved by silencing match failures in
action expressions, but that would lead to severe performance
problems (yes, I tried and measured). Other possible solutions are
hacks which I didn't want to introduce into PEG.js.
2. Triggering a match failure in action code could have lead to
unexpected backtracking.
Consider the following example:
class = "[" (charRange / char)* "]"
charRange = begin:char "-" end:char {
if (begin.data.charCodeAt(0) > end.data.charCodeAt(0)) {
error("Invalid character range: " + begin + "-" + end + ".");
}
// ...
}
char = [a-zA-Z0-9_\-]
Given input "[b-a]", the |charRange| rule would fail, but the
parser would try the |char| rule and succeed repeatedly, resulting
in "b-a" being parsed as a sequence of three |char|'s, which it is
not.
This problem could have been solved by using negative predicates,
but that would complicate the grammar and still wouldn't get rid of
unintuitive behavior.
Given these problems I decided to change the semantics of the |expected|
and |error| functions. They don't interact with regular match failure
mechanism anymore, but they cause and immediate parse failure by
throwing an exception. I think this is more intuitive behavior with less
harmful side effects.
The disadvantage of the new approach is that one can't backtrack from an
action-triggered error. I don't see this as a big deal as I think this
will be rarely needed and one can always use a semantic predicate as a
workaround.
Speed impact
------------
Before: 993.84 kB/s
After: 998.05 kB/s
Difference: 0.42%
Size impact
-----------
Before: 1019968 b
After: 975434 b
Difference: -4.37%
(Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
The |expected| function allows users to report regular match failures
inside actions.
If the |expected| function is called, and the reported match failure
turns out to be the cause of a parse error, the error message reported
by the parser will be in the usual "Expected ... but found ..." format
with the description specified in the |expected| call used as part of
the message.
Implements part of #198.
Speed impact
------------
Before: 1146.82 kB/s
After: 1031.25 kB/s
Difference: -10.08%
Size impact
-----------
Before: 950817 b
After: 973269 b
Difference: 2.36%
(Measured by /tools/impact with Node.js v0.6.18 on x86_64 GNU/Linux.)
David Majda
Mingun
Joseph Frazier
Arlo Breault