On 02/17/11 08:13, Christopher Rose wrote:
> I parse a smallish, syntactically correct example input and get a nil
> result, like this;

A nil result means your parser failed to parse all the input.
Have you tried with minimal inputs?
Have you tested the parser rules from the bottom up, or only started from the head rule?
It's important to develop these grammars incrementally.

> irb(main):188:0>  resA = pA.parse(exA)
> =>  nil
> irb(main):189:0>  resA.failure_reason
> NoMethodError: undefined method `failure_reason' for nil:NilClass
>    from (irb):189

failure_reason is a method on the parser object, not on the result.

> Can someone please suggest some other avenues for debugging this?

By default, Treetop starts with the first rule in your grammar,
but you can direct it to start elsewhere by passing the :root option
to the parse method. Also, a common trap is that the grammar must
consume all the input, unless you pass :consume_all_input => false.
So when you use :root, either feed it a fragment of input that matches
the root rule exactly, or set consume_all_input so that won't matter.

Another trap that strikes people coming from other parser generators
is that Treetop has no implicit white-space skipping. Your grammar must
account for every byte of input.

Another hardcore debugging trick is to use a semantic predicate to
insert a call to the debugger. After requiring 'ruby-debug', insert
this somewhere:

&{|s| debugger; true }

s will be set to an array of the SyntaxNodes that have been parsed so far
in this rule (or sub-rule, if you used parentheses). You can look at
the variables "input" and "offset", or more usefully, input[offset, 50].
Of course, you don't have to use a debugger, you can just print something.
Just remember to return true, or that rule fails.

If you can't make progress, contact us on the Treetop developers ML at
<http://groups.google.com/group/treetop-dev/> and post the problem parts
of your grammar somewhere.

Clifford Heath, Treetop maintainer.