Treetop - parsing to nil result

Discussion in 'Ruby' started by Christopher Rose, Feb 16, 2011.

  1. Hello All,
    please forgive a very novice question on what may be an arcane topic. I
    have a Treetop grammar defined, the 'tt' compiler seems to digest it
    without complaint, I get no errors when I create a new parser instance.
    I parse a smallish, syntactically correct example input and get a nil
    result, like this;

    irb(main):178:0> pA = VHDLParser.new
    => #<VHDLParser:0x8b5bc6c @consume_all_input=true>

    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
    from :0


    The description at treetop.rubyforge.org seems to suggest that if the
    parse fails, the methods failure_reason, failure_line, and
    failure_column would exist in such a way as to point to and describe the
    reason for failure.

    Can someone please suggest some other avenues for debugging this?


    Thanks -

    --
    Posted via http://www.ruby-forum.com/.
    Christopher Rose, Feb 16, 2011
    #1
    1. Advertising

  2. Christopher Rose

    Ryan Davis Guest

    On Feb 16, 2011, at 13:13 , Christopher Rose wrote:

    > irb(main):178:0> pA =3D VHDLParser.new
    > =3D> #<VHDLParser:0x8b5bc6c @consume_all_input=3Dtrue>
    >=20
    > irb(main):188:0> resA =3D pA.parse(exA)
    > =3D> nil
    >=20
    > irb(main):189:0> resA.failure_reason
    > NoMethodError: undefined method `failure_reason' for nil:NilClass
    > from (irb):189
    > from :0
    >=20
    > The description at treetop.rubyforge.org seems to suggest that if the
    > parse fails, the methods failure_reason, failure_line, and
    > failure_column would exist in such a way as to point to and describe =

    the
    > reason for failure.
    >=20
    > Can someone please suggest some other avenues for debugging this?


    nil is nil... so once you get it there is no reason to call unrelated =
    methods on it. The doco suggests asking the parser object, not the =
    result object:

    parser =3D ArithmeticParser.new
    result =3D parser.parse('4+=3D3')

    if !result
    puts parser.failure_reason
    puts parser.failure_line
    puts parser.failure_column
    end

    via http://treetop.rubyforge.org/using_in_ruby.html
    Ryan Davis, Feb 16, 2011
    #2
    1. Advertising

  3. 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.
    Clifford Heath, Feb 16, 2011
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Brian Candler

    puts nil generates "nil\n"

    Brian Candler, Nov 6, 2004, in forum: Ruby
    Replies:
    1
    Views:
    103
  2. John Carter
    Replies:
    64
    Views:
    623
    Klaus Stein
    May 19, 2005
  3. Michael Tan
    Replies:
    32
    Views:
    937
    Ara.T.Howard
    Jul 21, 2005
  4. Christoffer Sawicki
    Replies:
    5
    Views:
    240
    Christoffer Sawicki
    Sep 2, 2006
  5. Philipp Kempgen

    Parsing, BNF, TreeTop, GhostWheel, ...

    Philipp Kempgen, Aug 12, 2010, in forum: Ruby
    Replies:
    11
    Views:
    296
    Clifford Heath
    Sep 7, 2010
Loading...

Share This Page