-
-
Notifications
You must be signed in to change notification settings - Fork 257
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
[feature] Debugger: check the parser's state #852
Comments
In general, the debugger's implementation is a bit of a hack -- off the top of my head, I don't recall if there was any special reason for a position instead a state being sent (e.g. to satisfy some trait constraints for the closures). Anyway, one more other thing I found out is that the debugger's approach of using OS thread pausing doesn't work in a browser Wasm... so ideally it'll use a different approach, such as continuations, so having access to the parser state could be considered in that more universal implementation |
Ok, I've never worked with concurrent programs, or WASM, so I won't be able to help on the design choices that I think you are talking about. |
It could potentially work and be a small improvement for the current debugger; my comment was just that the current listener approach isn't ideal from the portability perspective |
The feature requested
I did not found a way to see what is happening about the stack in the debugger, and I think that it could be useful (and would have been in #338).
While I'm at it I would also like to check the atomicity of the parser since the rules of atomicity can get complex when nested.
I looked at the other informations of the parser's state in
pest::parser_state::Parser
and didn't find them to be useful in the debugger for pest user (also because I didn't dive in to understand all of them). But I think they might be useful in debugging pest itself.Comments
I looked at how the debugger is implemented. It relies on the
pest_vm::Vm
and the listener proposed by theVm
.A problem is that the listener doesn't seem to receive any information about the stack or the atomicity (which is contained by
ParserState
).If this feature was implemented it would probably change the signature of the listener, and that would be a breaking change. This might be considered unimportant as a search shows no public Github repositories (except the one in this repo for the debugger) .
I do not know why only the
state.position()
is the only part being sent to the listener. Is there a reason for that ? If there is none, could the whole&ParserState
be sent ?The text was updated successfully, but these errors were encountered: