You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Improve debugging: peek show next data in errors #46
It would probably help a lot if error messages showed some of the upcoming data in parse errors with streams where this is possible (I don't know if parsy supports iterators).
I'm a bit hesitant to change the behaviour regarding error messages here, because it could affect so many users, and I don't know how to do it in a way that is generically useful. Do you have any ideas @jneen ?
Parsy certainly doesn't have advanced features for syntax error reporting. If you are needing to pass on detailed parsing error message to end users (e.g. for a programming language), then it probably requires you to build this yourself, or use a different more heavyweight tool (e.g. lark perhaps?)
For building parsers for small "languages", I've found it usually pretty easy to debug my code, by ensuring that I'm building up progressively larger parsers from smaller ones and testing piece by piece. I'm not sure what your use case is.
I don't use combinators myself these days, for the exact reason that other approaches (for me, skeleton trees) result in better error messages. @deliciouslytyped do you mean debugging your parser or providing debugging information for your user? If it's the latter, I'd point you to the index parameter of the Failure object, which you can use to index into the source string and find the "upcoming data".
I'm talking about debugging my own parsers. Maybe it's just lot's of PEBCAK.
I just wrote almost the exact thing you just did 5 minutes ago for debug(), so that's a step in the right direction at least.
A lot of the time I can't tell which part of my code is responsible for the error messages I'm getting.
Activity
deliciouslytyped commentedon Sep 25, 2020
I don't know if I'm missing something but I've been messing with parsy for a couple days and it's really hard to debug?
spookylukey commentedon Sep 25, 2020
I'm a bit hesitant to change the behaviour regarding error messages here, because it could affect so many users, and I don't know how to do it in a way that is generically useful. Do you have any ideas @jneen ?
Parsy certainly doesn't have advanced features for syntax error reporting. If you are needing to pass on detailed parsing error message to end users (e.g. for a programming language), then it probably requires you to build this yourself, or use a different more heavyweight tool (e.g. lark perhaps?)
For building parsers for small "languages", I've found it usually pretty easy to debug my code, by ensuring that I'm building up progressively larger parsers from smaller ones and testing piece by piece. I'm not sure what your use case is.
jneen commentedon Sep 25, 2020
I don't use combinators myself these days, for the exact reason that other approaches (for me, skeleton trees) result in better error messages. @deliciouslytyped do you mean debugging your parser or providing debugging information for your user? If it's the latter, I'd point you to the
indexparameter of the Failure object, which you can use to index into the source string and find the "upcoming data".jneen commentedon Sep 25, 2020
For debugging your own parsers, it may also be useful to add something like:
or
deliciouslytyped commentedon Sep 25, 2020
I'm talking about debugging my own parsers. Maybe it's just lot's of PEBCAK.
I just wrote almost the exact thing you just did 5 minutes ago for debug(), so that's a step in the right direction at least.
A lot of the time I can't tell which part of my code is responsible for the error messages I'm getting.
Edit: rest of post moved to #48.
Progressively building up parsers in small steps certainly does help.