From nxadm@apt-get.be

Hi,

I having a go at adding syntax checking support to vim using the syntastic plugin (https://github.com/scrooloose/syntastic). My plugin, syntastic-perl6 (https://github.com/nxadm/syntastic-perl6), adds Perl 6 support and so far it seems to work.

Syntastic upstream accepted my PR adding support to Perl 6 (so regular users would get Perl 6 support out of the box), but the changes live for now in a test branch. I agree with upstream that error parsing for languages that don't spit out structured data is fragile (Perl 6 is not alone) and thus needs tesing.

And the error parsing is fragile indeed (e.g. ignoring new types of errors) as it's based on vimscript regular expressions of the rather irregular "perl6 -c" error output.

As jnthn suggested on irc, maybe an additional JSON error output would be great solution for this. This would make error parsing for external tooling very easy and stable. And good tooling is one of the things that Perl 6 needs at the moment.

So, consider this as a post-it note in case you run out of bugs. I am looking now at the rakudo internals, but I doubt I know it enough to implement it myself.

Regards,

C. (El_Che)

From @zoffixznet

On Thu Aug 18 06​:08​:06 2016, nxadm wrote​:

As jnthn suggested on irc, maybe an additional JSON error output would
be great solution for this. This would make error parsing for external
tooling very easy and stable.

I rather not add anything specific like that and dream bigger (or smaller, depending on how you look at it). It should be possible to expose to module-space the point where all of our Exception objects
currently get flattened into the text the user sees on the screen.

So then I could write a module Exceptions​::JSON that will convert received Exception objects to JSON and have all of the exceptions dumped as JSON. Or write Exceptions​::Rollbar and have the exceptions be shipped off to rollbar.com. Or write Exceptions​::Rust and output Rust-like exceptions with expressive pointers to code. Or write Exceptions​::Russian and have all of the errors be translated to Russian language.

There are far many more desired options for exceptions output. We should make it possible for module-space to implement all of those options rather than add a specific one in core.

The RT System itself - Status changed from 'new' to 'open'

From nxadm@apt-get.be

Hi Zoffix,

You indeed have a point. More abstraction is always the right answer :).

Some generic framework exposing the necessary information is a very elegant
solution. WIth two buts​:

1. For something as basic and fundamental as simple syntax checking it's
preferably -imho- not to ask the user to install a lot of external
dependencies and track their releases (are they in sync with the latest
Rakudo release?). If a default/model implementation is part of core (let's
say JSON or whatever), you can have your cake and eat it too.
2. I suspect that the JSON-only addition was a quick-fix to give tools a
simple and stable interface to errors today. A more elegant solution may
take a lot of time?

Regards,

C.

On Fri, Aug 19, 2016 at 2​:37 PM, Zoffix Znet via RT <
perl6-bugs-followup@​perl.org> wrote​:

On Thu Aug 18 06​:08​:06 2016, nxadm wrote​:

As jnthn suggested on irc, maybe an additional JSON error output would
be great solution for this. This would make error parsing for external
tooling very easy and stable.

I rather not add anything specific like that and dream bigger (or smaller,
depending on how you look at it). It should be possible to expose to
module-space the point where all of our Exception objects
currently get flattened into the text the user sees on the screen.

So then I could write a module Exceptions​::JSON that will convert received
Exception objects to JSON and have all of the exceptions dumped as JSON. Or
write Exceptions​::Rollbar and have the exceptions be shipped off to
rollbar.com. Or write Exceptions​::Rust and output Rust-like exceptions
with expressive pointers to code. Or write Exceptions​::Russian and have all
of the errors be translated to Russian language.

There are far many more desired options for exceptions output. We should
make it possible for module-space to implement all of those options rather
than add a specific one in core.

From @zoffixznet

This has been implemented using RAKUDO_EXCEPTIONS_HANDLER env var, with JSON included with Rakudo.

On Fri Aug 19 20​:27​:03 2016, nxadm wrote​:

Hi Zoffix,

You indeed have a point. More abstraction is always the right answer
:).

Some generic framework exposing the necessary information is a very
elegant
solution. WIth two buts​:

1. For something as basic and fundamental as simple syntax checking
it's
preferably -imho- not to ask the user to install a lot of external
dependencies and track their releases (are they in sync with the
latest
Rakudo release?). If a default/model implementation is part of core
(let's
say JSON or whatever), you can have your cake and eat it too.
2. I suspect that the JSON-only addition was a quick-fix to give tools
a
simple and stable interface to errors today. A more elegant solution
may
take a lot of time?

Regards,

C.

On Fri, Aug 19, 2016 at 2​:37 PM, Zoffix Znet via RT <
perl6-bugs-followup@​perl.org> wrote​:

On Thu Aug 18 06​:08​:06 2016, nxadm wrote​:

As jnthn suggested on irc, maybe an additional JSON error output
would
be great solution for this. This would make error parsing for
external
tooling very easy and stable.

I rather not add anything specific like that and dream bigger (or
smaller,
depending on how you look at it). It should be possible to expose to
module-space the point where all of our Exception objects
currently get flattened into the text the user sees on the screen.

So then I could write a module Exceptions​::JSON that will convert
received
Exception objects to JSON and have all of the exceptions dumped as
JSON. Or
write Exceptions​::Rollbar and have the exceptions be shipped off to
rollbar.com. Or write Exceptions​::Rust and output Rust-like
exceptions
with expressive pointers to code. Or write Exceptions​::Russian and
have all
of the errors be translated to Russian language.

There are far many more desired options for exceptions output. We
should
make it possible for module-space to implement all of those options
rather
than add a specific one in core.

@zoffixznet - Status changed from 'open' to 'resolved'