LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 08-05-2020, 01:48 AM   #1
des_a
Senior Member
 
Registered: Sep 2006
Posts: 1,409
Blog Entries: 43

Rep: Reputation: 35
10 Free Cross Platform Tools and 10 Debugging Strategies for Bison and Flex Actions


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:

https://www.google.com/search?sxsrf=...4dUDCAg&uact=5

and

https://www.google.com/search?q=soft...w=1366&bih=655

I'm not asking for a specific bug, but rather to learn more about finding bugs in general, and I hope some other programmer will see this too. However, I'm asking for hopefully specific things/tools for those langauges, rather than C/C++, which they generate.

Last edited by des_a; 08-05-2020 at 01:51 AM. Reason: Needed more explanation.
 
Old 08-05-2020, 11:55 PM   #2
des_a
Senior Member
 
Registered: Sep 2006
Posts: 1,409

Original Poster
Blog Entries: 43

Rep: Reputation: 35
Okay. No response. Maybe such tools don't exist, so I'm opening it up too to anything that can be used with bison and flex for debugging, but isn't necessarily designed for those languages. As long as they can be effective in solving bugs, hopefully more effective than gdb, which doesn't seem to know about bison and flex.

Here, I'll get us started with what I know, asking for 10 total, this will make it a little less.

Techniques for debugging:
Code:
1. WRITE technique - Add output statements to your code to show you what's going on. Remove them later.
Tools:
Code:
1. gdb, even though I hate it for debugging bison and flex so far.
2. valgrind - Don't know what all it does, but recently learned about it. I'm still researching it.
That makes 8 more tools I'm looking for, and 9 more techniques.

The WRITE technique is drilled into me, and that's the one I will never forget.

Last edited by des_a; 08-05-2020 at 11:56 PM. Reason: Comment on WRITE technique
 
Old 08-06-2020, 03:40 AM   #3
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=15, FreeBSD_12{.0|.1}
Posts: 6,258
Blog Entries: 24

Rep: Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193
As no one else has stepped up...

Quote:
Originally Posted by des_a View Post
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.

Last edited by astrogeek; 08-06-2020 at 04:07 PM.
 
1 members found this post helpful.
Old 08-08-2020, 01:15 AM   #4
des_a
Senior Member
 
Registered: Sep 2006
Posts: 1,409

Original Poster
Blog Entries: 43

Rep: Reputation: 35
Lots of details in that answer. It answered without being literal. Just got done reading it.

Actually the main language I'm working on is not the main language. The main language I'm working on will be itself in itself. Then things really start to get serious and I can't afford more coding mistakes. But I need the features of C++ "++" before that is possible. But the first goal is to have the features of C.

Maybe I will work on a mini language and then rewrite these with lessons learned, which seems to be what you suggest.

Here you can find a trivial example I've written that is most useful for flex and bison:

http://github.com/smileynet000/biflex
 
Old 08-08-2020, 07:50 AM   #5
boughtonp
Senior Member
 
Registered: Feb 2007
Location: UK
Distribution: Debian
Posts: 3,573

Rep: Reputation: 2534Reputation: 2534Reputation: 2534Reputation: 2534Reputation: 2534Reputation: 2534Reputation: 2534Reputation: 2534Reputation: 2534Reputation: 2534Reputation: 2534
Quote:
Originally Posted by des_a View Post
Maybe I will work on a mini language and then rewrite these with lessons learned, which seems to be what you suggest.
Any significantly complex software starts with throwaway prototypes.

Some people realize that, and will deliberately create those prototypes for each piece of functionality; others don't and thus waste their lives patching and maintaining trash, wishing they had the time to re-write the whole system.

 
Old 08-09-2020, 12:29 AM   #6
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=15, FreeBSD_12{.0|.1}
Posts: 6,258
Blog Entries: 24

Rep: Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193Reputation: 4193
Quote:
Originally Posted by des_a View Post
Lots of details in that answer. It answered without being literal. Just got done reading it.
Really? How would anyone know?

Quote:
Originally Posted by des_a View Post
Actually the main language I'm working on is not the main language. The main language I'm working on will be itself in itself. Then things really start to get serious and I can't afford more coding mistakes. But I need the features of C++ "++" before that is possible. But the first goal is to have the features of C.
But, yet another irrelevant post about your ethereal family of languages with baseless claims of future features and development plans.

You have been asked multiple times to refrain from endless posting of irrelevant discussion related to your proposed suite of languages, most recently here a few days ago.

This will be the last request without warning to end this behavior in the Programming forum. It is pointless and wastes the time of those willing to offer help with real world questions and degrades the quality of information available to others who land on these posts from their own search results. If you persist in this behavior then you will receive a warning infraction and, per the LQ Site FAQ, may be asked to take your questions elsewhere.

Quote:
If you are unwilling or unable to ask questions in a manner that allows us to help you, it's unlikely our community will be able to provide you a solution. Unfortunately, serial offenders who show wanton disregard for this request after multiple pointers may be asked to seek help elsewhere. We truly hope that isn't necessary...
Quote:
Originally Posted by des_a View Post
Maybe I will work on a mini language and then rewrite these with lessons learned, which seems to be what you suggest.
In no way did I suggest that. Please read the above post again.

What I suggested was literally, if less bluntly, that you:

* Are not likely to find tools specifically for debugging Flex or Bison action code, but should learn and apply common C/C++ skills.
* Actually learn the basics of the tools and languages you are trying, apparently unsuccessfully, to work with.
* Make use of the built in debugging facilities of those languages and tools, which you are apparently not doing.
* Learn the basic strategy and programming skills of working incrementally and with certainty at each step.
* If you want to ever write an actual language, set your distracting imaginary project aside and learn to actually work through the basics of the lexer and parser syntax analysis (grammar) and semantics (action code) with specific, repeatable, testable examples.

There is no substitute for actually knowing what you are doing. Pointing you in that direction was the entire purpose of my post. Please consider it.

Quote:
Originally Posted by des_a View Post
Here you can find a trivial example I've written that is most useful for flex and bison:
No thank you. I have no interest in looking further into your code until I see unambiguous evidence that you are serious about learning how to design it and write it.
 
1 members found this post helpful.
Old 08-09-2020, 04:39 AM   #7
ondoho
LQ Addict
 
Registered: Dec 2013
Posts: 19,872
Blog Entries: 12

Rep: Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053Reputation: 6053
I don't understand much of these things at all, but I will add that I was put off by the topic title, and 1st sentence:
Quote:
Originally Posted by des_a View Post
Can anybody list 10 free cross platform tools and 10 debugging strategies for debugging bison and flex actions. Not the syntax, the actions.
Why exactly 10 of such a precisely formulated demand?
This is just going to alienate people.
Why not ask for friendly recommendations?

Then, adding injury to insult, asking us to click on links like these:
Quote:
http s://www.google.com/search?sxsrf=ALeKk024iQvt8Hg-sJjI7t2ywsjNhagyLg%3A1596609462061&source=hp&ei=tlMqX56IAcz9-gS-2LNI&q=how+to+debug+bison+and+flex+actions&oq=how+to+debug+bison+and+flex+actions&gs_lcp=CgZwc3ktYWI QAzoECCMQJzoICAAQsQMQgwE6CwguELEDEMcBEKMCOgUIABCxAzoOCC4QsQMQgwEQxwEQowI6AgguOggILhDHARCjAjoECAAQAzo CCAA6CAguELEDEIMBOgUILhCxAzoHCCMQ6gIQJzoNCC4QxwEQrwEQJxCTAjoGCAAQFhAeOggIIRAWEB0QHjoFCCEQqwI6BQghEKA BOgcIIRAKEKABULQNWLB-YLOAAWgNcAB4AoABhAOIAdEtkgEJMjcuMTkuMi4ymAEAoAEBqgEHZ3dzLXdperABBg&sclient=psy-ab&ved=0ahUKEwieu9DeuYPrAhXMvp4KHT7sDAkQ4dUDCAg&uact=5
 
Old 08-10-2020, 02:12 AM   #8
des_a
Senior Member
 
Registered: Sep 2006
Posts: 1,409

Original Poster
Blog Entries: 43

Rep: Reputation: 35
Quote:
Why exactly 10 of such a precisely formulated demand?
This is just going to alienate people.
Why not ask for friendly recommendations?
10 was chosen so that I had an amount where we knew we were done. But really, I meant the above. A friendly recommendation. That's why I marked as solved when I did. I got the answer. Sorry for the misleading title.
 
Old 08-10-2020, 02:21 AM   #9
des_a
Senior Member
 
Registered: Sep 2006
Posts: 1,409

Original Poster
Blog Entries: 43

Rep: Reputation: 35
Quote:
What I suggested was literally, if less bluntly, that you:
Probably I just confused on the meaning of literal.

Quote:
* Are not likely to find tools specifically for debugging Flex or Bison action code, but should learn and apply common C/C++ skills.
* Actually learn the basics of the tools and languages you are trying, apparently unsuccessfully, to work with.
* Make use of the built in debugging facilities of those languages and tools, which you are apparently not doing.
* Learn the basic strategy and programming skills of working incrementally and with certainty at each step.
* If you want to ever write an actual language, set your distracting imaginary project aside and learn to actually work through the basics of the lexer and parser syntax analysis (grammar) and semantics (action code) with specific, repeatable, testable examples.
Points taken, as well as:

Quote:
But, yet another irrelevant post about your ethereal family of languages with baseless claims of future features and development plans.
Trying to be brief, This is the way I should've just posted, and what I really meant:

Code:
Thank you. You solved the problem, because I was not really looking for a literal 10, but a friendly recommendation. I just put 10 on so that we know when we're done if we reached that number.
...That was what I meant. I just have trouble being brief. I'm trying to do better. I find that trouble in my writing at school (college), sometimes too.

I'm not going to say anything more on this thread, unless it ABSOLUTELY warrents it. But I am going to take these things to heart if able.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] parsing with gnu-flex and bison fails for space and brace RudraB Programming 9 05-25-2013 05:41 PM
[Flex & Bison] How to check which state Flex is in? courteous Programming 0 06-03-2011 11:46 AM
Is there any support for bison-bridge and bison-locations in flex on windows systems? rami alkhateeb Linux - Software 0 12-29-2010 09:10 AM
installing bison and flex rameshsena Linux - Software 10 06-21-2010 11:33 AM
bison, flex and make problem ChimpFace9000 Programming 4 05-19-2002 07:49 PM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 08:27 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration