Debugging support #143
Comments
|
I totally agree there should be some kind of debugging mode. Given this library is meant to be dependency free, I won't integrate I don't wanna implement just any random thing for debugging either, so I think this issue is probably a good place to discuss what useful debugging would look like in detail, including how to enable that debugging. |
|
After playing around with this multiple times, I think the only way this output can be remotely useful is if the parser is annotated with some kind of "debug name" for every major parser. I wonder if people would actually bother writing out these names everywhere? Just mentioning This is a very tricky problem to actually do well, and I'd rather not offer something with poor usability that we are then stuck with. |
|
I did just have a thought though that using the upcoming |
|
Something like this with a customizable logging function and the ability to enable/disable debug mode might be useful, but I'll need to play with it more once var debugEnabled = true;
var debugLevel = 0;
var debugIndent = '| ';
_.debugName = function(name) {
if (!debugEnabled) {
return this;
}
var self = this;
return Parsimmon(function(input, i) {
debugLevel++;
var indent = repeatString(debugIndent, debugLevel);
console.log(indent + name);
var result = self._(input, i);
debugLevel--;
return result;
});
}; |
|
Perhaps you would be interested in this Scala Parser Combinator library debugging capabilities. |
|
It might be useful just to supply a "debug" parser which simply prints out information about the current state, as well as a user supplied tag. Probably easiest as a method like |
|
At some point I made these helpers for my language's parser. It generates output that looks like this when logAnnotations is set to true. It helped me to find a few bugs that were very hard to find otherwise. And having this experience, I will probably do it differently next time. There is also sinCounter / breakOnRepeat / MAX_SINS. It helped me to locate cases that looked like alt(
seq(a, b),
seq(a, c)
) |
|
+1 for P.debug. |
|
I would love to have some optional tools for debugging Parsimmon! 👍 |
|
I'm open to ideas on how to best implement this. Needs to support browser and Node debugging with zero mandatory dependencies. |
|
I don't have ideas on the overall debugging approach yet, but I think there's a problem with the error output. Here's my proposal for improving the error messages:
This doesn't change much, but it gives more context on what is happening in the input. I'm using chalk, but it would be super easy to drop it(or replace with something that works for browser and node at the same time) |
|
@halfzebra I definitely approve of a nice text formatter like that! I would just drop chalk since it's gonna cause browser problems and I don't want to add a dependency. And then we need it to work for Buffer inputs too. Would you be interested in opening an issue and working on a PR for that? |
|
Sure, I will send a PR shortly! |
|
This function has been pretty helpful export const tap = (message: string) => <X>(x: X) => {
console.log(message, x)
return p.succeed(x)
}Then I just |
|
Yeah I'm starting to think that rather than overthink debugging right now
I'll just add a single method like this
…On Fri, Apr 27, 2018, 12:22 Chet Corcos ***@***.***> wrote:
This function has been pretty helpful
export const tap = (message: string) => <X>(x: X) => {
console.log(message, x)
return p.succeed(x)
}
Then I just .chain(tap("here")) whenever I need to. Would nice to make it
a prototype method though.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#143 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKyr6L-1XvwjJkJXaEZprAkgDPdzWyeks5ts3AQgaJpZM4LATCG>
.
|
|
The ideal solution would provide a full stack trace through all the
parsers. Seems like that shouldn’t be too hard honestly. I just want to
know what the parser did. Imagine I put that debug statement on every
single parser. That’s all I really want. Formatting can come next,
indentation, etc
…On Fri, Apr 27, 2018 at 12:25 Brian Mock ***@***.***> wrote:
Yeah I'm starting to think that rather than overthink debugging right now
I'll just add a single method like this
On Fri, Apr 27, 2018, 12:22 Chet Corcos ***@***.***> wrote:
> This function has been pretty helpful
>
> export const tap = (message: string) => <X>(x: X) => {
> console.log(message, x)
> return p.succeed(x)
> }
>
> Then I just .chain(tap("here")) whenever I need to. Would nice to make it
> a prototype method though.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#143 (comment)>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AAKyr6L-1XvwjJkJXaEZprAkgDPdzWyeks5ts3AQgaJpZM4LATCG
>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#143 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABth33QEH2REu0uHsEfrvBvqY3TRALhFks5ts3C2gaJpZM4LATCG>
.
|
|
Printing a stack trace is easy, sure ( See https://runkit.com/wavebeem/5ae4ab80f8960f001295065b See how everything is just I'm thinking for now a good compromise might be adding two methods: _.tap = function(f) {
return this.map(function(x) {
f(x);
return x;
};
};which could be used like: seq(
myCoolParser.tap(x => { console.log("here i am!", x) }),
anotherParser
)and maybe a shortcut version like |
|
I'm closing this in favor of #193 since nothing compelling has come up in the mean time |
It'd be nice to have a way to show what Parsimmon does under the hood. This should help trace bugs in complicated parsers. Maybe using debug or something similar.
For instance:
I'd like to be able to see something like:
The text was updated successfully, but these errors were encountered: