The 1st problem should be straightforwardly do-able with Marpa, is my guess.
Repairing broken stack traces is interesting. If I were pursuing it, I'd think Marpa's power might be useful -- look for the first match of something like <random lines> <valid stacktrace> Since you take the first match, it should match after as few random lines as possible -- this may be 0 lines. At that point you know where there is a valid stacktrace, and you know what the lines are that you need to attempt repair on. You'd need to work out a lexing discipline that both accumulates the random lines and allows the parsing of the valid stacktraces. Again, this is just some thoughts about the approach I'd look at 1st if I were trying to solve this in a Marpa-powered way. Note that, if you have to fall back to ordinary hacks, Marpa allows all of these. I hope this helps, jeffrey On Mon, Nov 13, 2017 at 1:36 PM, Ron Savage <[email protected]> wrote: > Marpa allows you to discard parts of the input stream. And the tokens to > be discarded can have various forms. But you may well be better off > matching what you can be certain does appear. That means both defining > exactly what you want to find and somehow proving that what's in the part > you wish to ignore never matches the part to be captured. See also: Marpa's > home page <https://savage.net.au/Marpa.html> > > -- > You received this message because you are subscribed to the Google Groups > "marpa parser" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "marpa parser" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
