Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve debugging: peek show next data in errors #46

Open
deliciouslytyped opened this issue Sep 24, 2020 · 5 comments
Open

Improve debugging: peek show next data in errors #46

deliciouslytyped opened this issue Sep 24, 2020 · 5 comments

Comments

@deliciouslytyped
Copy link

deliciouslytyped commented Sep 24, 2020

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).

@deliciouslytyped
Copy link
Author

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
Copy link
Member

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
Copy link
Contributor

jneen commented 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 index parameter of the Failure object, which you can use to index into the source string and find the "upcoming data".

@jneen
Copy link
Contributor

jneen commented Sep 25, 2020

For debugging your own parsers, it may also be useful to add something like:

class Debug(namedtuple('Debug', 'stream index')):
    pass

debug = Parser(lambda stream, index: Result.success(index, Debug(stream, index)))

or

def debug_log(p, *args):
    @Parser
    def debug_parser(stream, index):
        result = p(stream, index)
        print(f"debug@{index}: '{stream[index:index+10]}' = {result}")
    return debug_parser

@deliciouslytyped
Copy link
Author

deliciouslytyped commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants