I have recently created a set of tools for testing/Analyzing/Debugging .Net Antlr4 parsers. The project is Grun.Net. The project started out with the goal of implementing the standard testrig functionality but in a set of .Net tools so I didn’t have to rebuild in Java when I wanted to test my grammar assembly. After that, it expanded into a lot more. I am constantly iterating on the software and improving it. I am hoping that people will find it useful and that I will get lots of constructive feedback.
It was pointed out to me that the software only works with the Antlr4.Runtime current and not the standard runtime. I was unaware of the major difference until recently, but have begun tackling support for both.
The software project is entirely open source and I will happily accept pull requests as well as constructive feedback. You may find the repository below, along with an instructional video demonstrating the tools.
It took me a while to get back to focusing on my tool, but I now have a version that supports the old .Net ANTLR4 runtime and a version that supports the standard runtime. It also has some nice new features.
I’m back working on the tool again and will have a new version of both the original runtime and runtime.standard editions. These will include a number of enhancements that make the tool more usable if you happen to use a giant code sample with a very complex language parser. Currently this can lead to freezing of the UI (not good). The tree view will now lazy load nodes to be more responsive when building trees of thousands of nodes. clicking nodes on the visual graph layout will also result in the corresponding tree view node being brought into view. I also added a menu option that allows naming graph nodes using any labels from the grammar (this is the new default). This can make it easier to read graphs where you have a parser rule with many alternatives and labels for each.
I hope to publish the official installers for the new version in early July.
In the future I will also be making the lexer/parser calls async just to avoid any delays from that. Currently even with giant source samples it seems very responsive, but I thought I might as well while I’m addressing other issues that can slow down the UI.