Note: This was originally posted in another thread about things people might want to do with parse events, but discussing the needs of this particular tool warrants its own thread.
Because debugging parse rules can be painful, I created a Rebol 2 visual parse debugger of sorts (parse-analysis-view.r). Parse events are needed to track the input position and log each rule's Test, Succeed, or Fail. The events were mapped to screen coordinates to be able to step forwards/backwards through the parse steps and to be able to find the active rules under a mouse cursor position. Mapping strings was easy, mapping block input was a pain.
Running the visual debugger thing:
visualise-parse t j/grammar [parse/all t j/grammar/json]
While we don't have a desktop GUI at the moment, the WebAssembly build has the full browser available, and I'm on board for making sure UPARSE can give the hooks to help put something like this together. It would make for a neat demo.
In the visual tooling category: I'll mention for anyone who doesn't know that Red's "DiaGrammar" now has a demo version you can try out. The trial download link is hiding at the bottom of the page.
They don't seem to have any stepwise debugging feature, but they do have a way to do mapping between matched text and the rule that matched it:
"Not only can you see if an input matches your entire grammar, you can select specific rules and find where they match parts of your input."
I fiddled with it for 10 minutes and it didn't immediately work the way I thought...at least the generating sample input didn't. If someone else can fiddle and report on it for me that would be helpful.
(So @Brett, if you can kind of tinker with it and explain the difference between what they're doing and what you did, I'm sure it would be illuminating.)
Hmmm, didn't know it existed. Well I had a bit of a look. Brief comments and thoughts:
I was amused to see ABNF as the demo on the page, funny coincidence..
I noted the large number of rule sets - kudos.
Drawing the railroad diagrams is interesting but I don't get why you'd bother for a parse rule editor. I've never seen anyone actually read them, they're hard to read.
I don't understand why you would have two languages on the same page saying the same thing (rebol parse rules and railroad diagrams).
Named rules are the focus, like my solution.
The generate thing doesn't really work that I can see. A fellow years ago on the rebol list, showed the usefulness of creating test data by generating from parse rules, his seemed to work.
They find a rule match in the test like I do with my buttons.
They have a "live" rule editing feature, which I assume means run parse in a loop.
I'm uninterested in styling the interface.
Looks like a work in progress.
I'm horrified that they'd advertise to charge $129 USD for a what looks like a proof of concept. I suppose it is free if you find the link.
While mine was not sexy, it is free, allows stepwise forward and backward, display rules at cursor, etc. just sayin...
Perhaps I missed something major, but I believe there are fairly sophisticated tools on the market that would make people scoff at this.
I can't imagine that they'd be doing much different under the hood, to what I did, you have to track parse event input positions to do this stuff.
My first version was 2004, their "product" doesn't make me feel like 2021. I'm getting old...
But because DiaGrammar is not open source we don't have immediate access to whether it uses that. And because Red isn't LGPL'd we don't know what kind of hacked up version of Red they have; it's not a proof of what the language itself is capable of as pitched.
(I explained my rationale behind LGPL'ing Ren-C a year ago. People shouldn't look at it as "restricting their rights" to distribute their binaries without source... but rather as making a promise, that Ren-C won't be enhanced and folded into some project without letting you know what's going on...leaving those who've bought in without support...)
Well this is why they have to cut features in PARSE. If it had too many features it would be too slow to run in a loop.
If programming history looks back on them and scoffs, they can't say I didn't warn them...
I think the slow-and-steady scrutiny of things piece-by-piece is really the only way to get to the future vs. repeat the past.
And I'm not giving up on Ren-C. In fact, I just got back to my coding bunker after a couple months of enjoying what will likely be a narrow window of coronavirus freedom. I will be digging in for the rest of the year, seeing how much I can get done.
Would be something it would be possible to integrate the Wasm build with...
(BTW: The approach I suggest above is showing some real promise, but while writing the prototype for it I got stuck on some bugs...so I'm going back and doing some needed toughening on the code before continuing to tackle it.)
I'm a bit confused because I thought Red offered some kind of events back from PARSE as callbacks and this would be based on that, but I see no indication that the call to PARSE uses the /TRACE refinement. Without an in-depth analysis of uncommented code, I assume it's probably using methods that parallel parse-analysis-view.r.
There's one comment, about needing to "extract the names":
;; I haven't found any other way to extract the names
;; I tried collecting first words of the 'fetch' event,|
;; but sometimes it may be at 'opt name' and who knows what other cases are possible
Similar, though if I've understood on my brief glance, it looks like it's attempting to scan the rules to track events. I went with the dumber/simpler/possibly less fragile - let the user decide which rules to track and wrap those to create the event tracking.
or won nearly 20 years ago 