29 Commits (9446e07f6acba905481e2e71c0a37774e479be70)

Author SHA1 Message Date
David Majda 9717dc3417 Talk about "undefined rules" instead of "missing rules" internally
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.
8 years ago
David Majda 2fd77b96fc Revert "Use literal raw text in error messages"
I no longer think that using raw literal texts in error messages is the
right thing to do. The main reason is that it couples error messages
with details of the grammar such as use of single or double quotes in
literals. A better solution is coming in the next commit.

This reverts commit 69a0f769fc.
9 years ago
David Majda 45de51a881 Consistently talk about generating (not building) a parser 9 years ago
David Majda f4504a93fe Rename the "buildParser" function to "generate"
In most places, we talk about "generating a parser", not "building a
parser", which the function name should reflect. Also, mentioning a
parser in the name is not necessary as in case of a parser generator
it's pretty clear what is generated.
9 years ago
David Majda 0847a69643 Rename the "PEG" variable to "peg"
So far, PEG.js was exported in a "PEG" global variable when no module
loader was detected. The same variable name was also conventionally used
when requiring it in Node.js or otherwise referring to it. This was
reflected in various places in the code, documentation, examples, etc.

This commit changes the variable name to "peg" and fixes all relevant
occurrences. The main reason for the change is that in Node.js, modules
are generally referred to by lower-case variable names, so "PEG" was
sticking out when used in Node.js projects.
9 years ago
David Majda 810567d865 UMD parsers: Allow specifying parser dependencies
Introduce two ways of specifying parser dependencies: the "dependencies"
option of PEG.buildParser and the -d/--dependency CLI option. Specified
dependencies are translated into AMD dependencies and Node.js's
"require" calls when generating an UMD parser.

Part of work on #362.
9 years ago
David Majda b87268ade6 UMD parsers: Allow generating parsers in UMD format from the API
Introduce new "format" and "exportVar" options to PEG.buildParser which
together allow generating parsers in UMD format.

Part of work on #362.
9 years ago
David Majda e61c23c634 ESLint: Set environments better
Instead of setting ESLint environment to "node" globally, set it on
per-directory basis using separate .eslintrc.json files:

  Directory   Environment
  -----------------------
  bin         node
  lib         commonjs
  spec        jasmine

It was impossible to use this approach for the "benchmark" directory
which contains a mix of files used in various environments. For
benchmark/run, the environment is set inline. For the other files, as
well as spec/helpers.js, the globals are declared manually (it is
impossible to express how these files are used just by a list of
environments).

Fixes #408.
9 years ago
David Majda 04f8b50f80 Fix ESLint errors in spec/api/plugin-api.spec.js
Fix the following errors:

   59:35  error  "options" is defined but never used  no-unused-vars
   91:11  error  "plugin" is defined but never used   no-unused-vars
  102:35  error  "options" is defined but never used  no-unused-vars
  128:35  error  "options" is defined but never used  no-unused-vars

Note that ESLint revealed a real problem where the test supposedly
verifying receiving options by a plugin didn't actually verify anything.
9 years ago
David Majda 47ac688ce9 Fix ESLint errors in spec/api/generated-parser-api.spec.js
Fix the following errors:

  65:20  error  Unexpected console statement  no-console
  66:20  error  Unexpected console statement  no-console
  67:20  error  Unexpected console statement  no-console
  68:20  error  Unexpected console statement  no-console
  69:20  error  Unexpected console statement  no-console
  70:20  error  Unexpected console statement  no-console
9 years ago
David Majda 768ece28e6 Use ESLint instead of JSHint
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.
9 years ago
David Majda 69a0f769fc Use literal raw text in error messages
Fixes #127.
9 years ago
David Majda 60ebd9e695 Simplify JSHint directives 9 years ago
David Majda a4b4a57569 Custom tracers specs: s/'/"/
The convention is to use single quotes only for strings containing code.
9 years ago
David Majda 1d38b973ee Custom tracers specs: Simplify code slightly 9 years ago
David Majda 671c22e80f Avoid using |console| in default tracer and its tests when not defined
This makes default tracer and its tests work in IE 8-10.
9 years ago
David Majda e8b379f945 Rewrite |trace| option tests to avoid using |console|
This makes them cleaner and also makes them work in IE 8-10.
9 years ago
David Majda 969d39e8d9 Remove trailing commas in object literals
They broke IE 8-9.
9 years ago
Arlo Breault 12c169e7b5 Convert PEG.js code to strict mode
* Issues #323
10 years ago
David Majda d1fe86683b Improve location info in tracing events
Replace |line|, |column|, and |offset| properties of tracing events with
the |location| property. It contains an object similar to the one
returned by the |location| function available in action code:

  {
    start: { offset: 23, line: 5, column: 6 },
    end:   { offset: 25, line: 5, column: 8 }
  }

For the |rule.match| event, |start| refers to the position at the
beginning of the matched input and |end| refers to the position after
the end of the matched input.

For |rule.enter| and |rule.fail| events, both |start| and |end| refer to
the current position at the time the rule was entered.
10 years ago
David Majda da57118a43 Implement basic support for tracing
Parsers can now be generated with support for tracing using the --trace
CLI option or a boolean |trace| option to |PEG.buildParser|. This makes
them trace their progress, which can be useful for debugging. Parsers
generated with tracing support are called "tracing parsers".

When a tracing parser executes, by default it traces the rules it enters
and exits by writing messages to the console. For example, a parser
built from this grammar:

  start = a / b
  a = "a"
  b = "b"

will write this to the console when parsing input "b":

  1:1 rule.enter start
  1:1 rule.enter   a
  1:1 rule.fail    a
  1:1 rule.enter   b
  1:2 rule.match   b
  1:2 rule.match start

You can customize tracing by passing a custom *tracer* to parser's
|parse| method using the |tracer| option:

  parser.parse(input, { trace: tracer });

This will replace the built-in default tracer (which writes to the
console) by the tracer you supplied.

The tracer must be an object with a |trace| method. This method is
called each time a tracing event happens. It takes one argument which is
an object describing the tracing event.

Currently, three events are supported:

  * rule.enter -- triggered when a rule is entered
  * rule.match -- triggered when a rule matches successfully
  * rule.fail  -- triggered when a rule fails to match

These events are triggered in nested pairs -- for each rule.enter event
there is a matching rule.match or rule.fail event.

The event object passed as an argument to |trace| contains these
properties:

  * type   -- event type
  * rule   -- name of the rule the event is related to
  * offset -- parse position at the time of the event
  * line   -- line at the time of the event
  * column -- column at the time of the event
  * result -- rule's match result (only for rule.match event)

The whole tracing API is somewhat experimental (which is why it isn't
documented properly yet) and I expect it will evolve over time as
experience is gained.

The default tracer is also somewhat bare-bones. I hope that PEG.js user
community will develop more sophisticated tracers over time and I'll be
able to integrate their best ideas into the default tracer.
10 years ago
David Majda 3308807d22 Behavior specs cleanup: Move spec/api/generated-parser-behavior.spec.js
Move spec/api/generated-parser-behavior.spec.js to
spec/behavior/generated-parser-behavior.spec.js. It's not an API test,
strictly speaking.
10 years ago
David Majda 84473db3ce Specs cleanup: Small description cleanups/fixes 10 years ago
David Majda 178d56699a Update GitHub project URLs
See https://groups.google.com/d/msg/pegjs/4a6zWKQSG6U/n8Pm257Lz6wJ.

I didn't update CHANGELOG.md as I consider issue URLs there historical artifacts
;-)
10 years ago
David Majda e101e1b6f3 Specs cleanup: Implement generated parser API specs
The generated parser API specs are mostly extracted from
generated-parser.spec.js, which got renamed to
generated-parser-behavior.spec.js to better reflect its purpose.
11 years ago
David Majda 94c8b08acf Specs cleanup: Implement plugin API specs 11 years ago
David Majda d0ff834a3d Specs cleanup: Implement PEG.js API specs
Some parts were previously part of generated parser specs, these were
moved.
11 years ago
David Majda 0306a76152 Specs cleanup: Rename & simplify |varyAll|
Rename |varyAll| to |varyOptimizationOptions|, because that's what the
function does. Simplify as we don't need a fully generic solution.
11 years ago
David Majda 3d637173ee Specs cleanup: Split specs into unit and API specs
Unit specs are unit tests of internal stuff. API specs are tests of the
user-visible APIs and behavior.

I think it makes sense to make this distinction because then the public
API line is more clearly visible e.g. when using the specs as
documentation.
11 years ago