As no one else has stepped up...
Quote:
Originally Posted by des_a
Can anybody list 10 free cross platform tools and 10 debugging strategies for debugging bison and flex actions. Not the syntax, the actions. What to do when the action code doesn't work right. And if you can, they should be things that are unique to these languages. Not something that is mostly used for C.
Quick search, finds this so far:
...
|
I am unaware of any tools specific to
debugging Flex and Bison action code (which doesn't mean there aren't any!), but you are looking in the right direction when thinking about a
strategy for dealing with parser projects!
The
action code is just C/C++ and there is really nothing unique to Flex and Bison in the action code, so don't expect to find any magic bullets specific to Flex or Bison to use for debugging it.
What is unique to parser development is the structure of the overall program, the flow of control, and of course, the grammar it is intended to parse. The grammar specification essentially defines a set of symbols, or tokens which may appear in the input stream, and a set of finite states the parser may enter based on the subset and ordering of those tokens appearing at runtime. The action code tells it what to do in each possible state, and a good development strategy will be one that avoids ambiguity and provides a good level of certainty both when writing and evaluating each of the parts which goes into the whole.
Putting second things first, make use of Flex and Bison's built in debugging features. One of the early results in your first search above covers most of what you will need to be informed of the current state of the parser for troubleshooting. Answer #1
in this post covers the all important basics - enable Bison debug trace with
yydebug and enable Flex tracing with
-d or
--debug.
That post mentions another important part of a usable
development strategy - "
it's worth getting into the habit writing your scanner in a way that it can be compiled independently of the parser". For most non-trivial projects, I maintain the lexer, or scanner if you prefer, separately from the parser, along with a test suite of code (often a Bison generated controller) and input data which allows me to
validate the lexer rules and interactions independently of the target parser. This improves the maintainability of the overall project considerably by allowing reliable, testable modification of the lexer and parser independently.
I would also add that you should make use of
locations and implement a useful error handler before you even start writing your grammar rules and their action code.
Also learn to understand and make use of the parser states report generated using
-v or
--report=all flags to Bison.
And first things second, implement your
well specified grammar incrementally. Identify a set or subset of symbols from the grammar and work up a lexer and associated test suite first, and know with certainty that it works as expected before writing the parser rules.
When you begin writing the parser implementation, focus on validating syntax analysis of your grammar as much as possible in isolation from the details of functional action handlers. In other words, validate with certainty that the parser does in fact enter the states expected for the grammar and input stream, and correctly produces errors for illegal input syntax.
Only then begin implementation of the functional action handling code, incrementally, with certainty at each point.
I strongly suggest working through a simple but non-trivial development project that does not involve your actual target grammar, as a very useful way of quickly building your successful strategy without getting lost in other concerns. When I first needed to build my own strategy for taking on a much more complex parser project, I set the goal of implementing a calculator which could correctly understand input and produce output using either numeric symbols or english language expressions, or both. The result was a development method, a parser development strategy I understand and can use reliably.
Rather than search for 10 magic bullets or a 12 step program for parsers, I recommend you set your main project aside and write a specification for some such simple grammar, make one up, then figure out how to implement it with Flex and Bison, including proper error handling. When you return to your main project most of your questions will have simple answers and you will have a strategy you understand!
By way of encouragement, here is an example session of the result of my own exercise...
Code:
./alnums
> six times (sixteen divided by four plus (negative two times six))
negative forty eight
> numeric
> 123 + 44
167
> both
> 12 minus seven
five (5)
> twelve twenty six
1.8-1.13: error syntax error
> quit
Bye!
Good luck!
UPDATE: I neglected to summarize my main point...
That point being that thinking of "
debugging action code" as something separate and special requiring dedicated tools will likely lead you down a blind path or two.
Instead, understand the place and purpose of your action code, and all other parts, within the overall strategy you have adopted for your parser and your overall development strategy. Those strategic views will largely define
how you identify and troubleshoot errors in your parser.