Skip Menu |

This queue is for tickets about the JSON-Relaxed CPAN distribution.

Report information
The Basics
Id: 122462
Status: open
Priority: 0/
Queue: JSON-Relaxed

People
Owner: Nobody in particular
Requestors: json-relaxed [...] lists.ewheeler.net
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Add line or character number offset within JSON::Relaxed::Parser::Token
Date: Wed, 12 Jul 2017 22:20:38 +0000 (UTC)
To: bug-JSON-Relaxed [...] rt.cpan.org
From: Eric Wheeler <json-relaxed [...] lists.ewheeler.net>
Hello, I really like JSON::Relaxed for our config file because it simplifies the end-user's experience while being a familiar format. I noticed that it is difficult to tell where there is an error (like a missing comma). Would it be possible to include the line number and/or character offset in the JSON::Relaxed::Parser::Token object when being tokenized? This would allow the error functions to report the line number or offset into the string that the error occurred. It looks like you could retrieve the line number information in the invalid_token sub when returning the error information since most if not all error reports use this function. For example, if I update invalid_token like so: - return 'string'; + return 'string: ' . $token->as_perl(); Then I can get a little bit more output for an error like the following: { foo bar, baz } unknown-token-after-key: expected comma or closing brace after a hash key, but got string: bar instead This helps because we know that the problem is near bar, but if we can add line numbers and make it even better that would be great! Do you have any ideas here that might provide a trivial update for a 0.06 release that would annotate the error messages as such? -- Eric Wheeler
Subject: Re: [rt.cpan.org #122462] Add line or character number offset within JSON::Relaxed::Parser::Token
Date: Thu, 13 Jul 2017 09:29:38 -0400
To: bug-JSON-Relaxed [...] rt.cpan.org
From: "Miko O'Sullivan" <miko [...] idocs.com>
Hi, Eric! I'm really glad to find out that someone is benefiting from this module. Unfortunately, I don't work with Perl anymore, and I've got a lot going on, so I can't dive into creating this feature. (I had to change to Ruby because it's more supported out there. Ruby is *awful*. I can't believe the world has chosen it over Perl, but that's the world I'm stuck with.) Would you like to take over stewardship of JSON::Relaxed? That way you can add whatever you like and other users would benefit. Miko On Wed, Jul 12, 2017 at 6:21 PM, Eric Wheeler via RT <bug-JSON-Relaxed@rt.cpan.org> wrote: Show quoted text
> Wed Jul 12 18:21:54 2017: Request 122462 was acted upon. > Transaction: Ticket created by json-relaxed@lists.ewheeler.net > Queue: JSON-Relaxed > Subject: Add line or character number offset within JSON::Relaxed::Parser::Token > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: json-relaxed@lists.ewheeler.net > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=122462 > > > > Hello, > > I really like JSON::Relaxed for our config file because it simplifies the > end-user's experience while being a familiar format. > > I noticed that it is difficult to tell where there is an error (like a > missing comma). Would it be possible to include the line number and/or > character offset in the JSON::Relaxed::Parser::Token object when being > tokenized? This would allow the error functions to report the line number > or offset into the string that the error occurred. > > It looks like you could retrieve the line number information in the > invalid_token sub when returning the error information since most if not > all error reports use this function. > > For example, if I update invalid_token like so: > > - return 'string'; > + return 'string: ' . $token->as_perl(); > > Then I can get a little bit more output for an error like the following: > > { > foo > bar, > baz > } > > unknown-token-after-key: expected comma or closing brace after a hash key, > but got string: bar instead > > > This helps because we know that the problem is near bar, but if we can add > line numbers and make it even better that would be great! > > Do you have any ideas here that might provide a trivial update for a 0.06 > release that would annotate the error messages as such? > > -- > Eric Wheeler