Linter setting doesn't work with the newest linter update

[LukaHorvat]

I get this error

[Linter] Invalid Linter received
These issues were encountered while registering a Linter named 'Unknown'
  • Linter.name must be a string

Seems like a relatively easy fix.

[lierdakil]

Uh... I'm tempted to say it's a linter package issue. First it added name field, now it's apparently mandatory, all without changing protocol version despite breaking changes. However, I'm in the process of rewriting and rewiring things, which should eventually fix this as well. I'll try to get it out faster. In the meantime, you could complain to @steelbrain if you're so inclined :)

чт, 16 мар. 2017 г., 12:31 Luka Horvat notifications@github.com:

I get this error

[Linter] Invalid Linter received These issues were encountered while registering a Linter named 'Unknown' • Linter.name must be a string

Seems like a relatively easy fix.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/atom-haskell/haskell-ghc-mod/issues/208, or mute the thread https://github.com/notifications/unsubscribe-auth/AG8EZr7IG_FN1GFgSsuUoY8Del4WAfmYks5rmQFzgaJpZM4MfCaD .

[steelbrain]

Hi @lierdakil

Linter didn't break it while in v1, we bumped major so it was supposed to have some incompatibilities. Anyways instead of forcing the providers, I'll try to make linter as compatible as possible

I've opened https://github.com/steelbrain/linter/pull/1371 to fix this

[Valdsonjr]

Strangely, I've got, instead of an error, this when using other providers that didn't set name:

[steelbrain]

That's the expected behavior, it has to fill in something for the provider, so it sets unknown for those who don't specify it

[lierdakil]

@steelbrain, while you bumped package version, service version is still 1.0.0, so the general expectation is that it should behave the same =\

[quchen]

Although Linter has had two bugfix updates and is now on 2.1.2, the problem still persists. :-/

[lierdakil]

@quchen, are you referring to the error or to the "unknown" thingy?

[lierdakil]

Anyway, since planned updates take way longer than expected, I've released a patch that should fix this on our end.

[quchen]

Using Linter 2.1.2:

Updated to the just released new haskell-ghc-mod 1.19.8, I now get

Thanks for trying to fix this by the way, despite the error not being on your end! :-)

[lierdakil]

Well, that's different =\

I'm not sure where the problem lies exactly, but there are a few cases where result might not be an Array (or rather, Promise<Array>), but rather undefined. Here they are:

1. h-g-m didn't start internal process tracking. Not very likely, unless package was deactivated due to update or manually, and for some reason Linter didn't dispose of it in time.
2. Neither onChangeCheck/Lint and onSaveCheck/Lint are enabled in h-g-m settings.
3. Text editor is empty. There is nothing to check/lint.

Since everything seems to work more or less as expected on my end, I would guess that one of the three above is going on for you. If it's not (2) or (3), then we have a problem. Otherwise, well, (2) should be easy to fix yourself, and (3) is kind of a weird outlier, but it's an easy fix for me.

Soo... does any of this sound at least remotely probable?

[lierdakil]

Well, anyway, I pushed another patch that should work as a band-aid to this particular problem. Let me know if it works for you.

[quchen]

Thanks, now it works as intended! I did indeed have all linters disabled (i.e. HLint wasn’t called because it was buggy recently, ignoring the HLint.hs configuration file). Since this is a valid use case I think it should not throw an error.

Anyway, thanks for the fix! I hope it’s a band aid you can remove in the future again, and not something we’re stuck with forever.

[lierdakil]

Well, the intention is to move Linter support to ide-haskell, so that not only h-g-m can use Linter as frontend, but also ide-haskell-cabal and ide-haskell-repl. And since h-g-m is severely crippled without ide-haskell, well, it's a bit of a requirement anyway. But that particular change, as well as some other, are currently work-in-progress, and will remain so for a bit longer (probably till after Easter). I'll try to make the eventual transition as effortless for the end-user as possible.