Error detected while processing function ghcmod#util#check_version

[dredozubov]

I get this when i open new vim window and open arbitrary *.hs file:

"src/FareBasisRule.hs" 59L, 1948C
Error detected while processing function ghcmod#util#check_version:
line    3:
E684: list index out of range: 0
E15: Invalid expression: a:version[l:i] > l:ghc_mod_version[l:i]
E684: list index out of range: 1
E15: Invalid expression: a:version[l:i] > l:ghc_mod_version[l:i]
E684: list index out of range: 2
E15: Invalid expression: a:version[l:i] > l:ghc_mod_version[l:i]

:GhcModType and other commands still work after this. This error happens only while opening first haskell-filetype file.

:GhcModDiagnostics output:

Current filetype: haskell
filetype detection:ON  plugin:ON  indent:ON
ghcmod.vim version: 1.2.0
ghc-mod is executable: 1
vimproc.vim: 800
ghc-mod version:
ghc-mod debug command: ghc-mod -g -i/Users/dr/workspace/contractor/dist/build/autogen -g -I/Users/dr/workspace/contractor/dist/build/autogen -g -optP-inclu
de -g -optP/Users/dr/workspace/contractor/dist/build/autogen/cabal_macros.h -g -i/Users/dr/workspace/contractor/dist/build/contractor/contractor-tmp -g -I/
Users/dr/workspace/contractor/dist/build/contractor/contractor-tmp debug
Root directory:      /Users/dr/workspace/contractor
Current directory:   /Users/dr/workspace/contractor
Cabal file:          Just "/Users/dr/workspace/contractor/contractor.cabal"
GHC options:         -i/Users/dr/workspace/contractor/dist/build/autogen -I/Users/dr/workspace/contractor/dist/build/autogen -optP-include -optP/Users/dr/w
orkspace/contractor/dist/build/autogen/cabal_macros.h -i/Users/dr/workspace/contractor/dist/build/contractor/contractor-tmp -I/Users/dr/workspace/contracto
r/dist/build/contractor/contractor-tmp -global-package-db -no-user-package-db -package-db /Users/dr/workspace/contractor/.cabal-sandbox/x86_64-osx-ghc-7.8.
3-packages.conf.d -XHaskell2010 -optP-include -optP/Users/dr/workspace/contractor/dist/build/autogen/cabal_macros.h
Include directories: /Users/dr/workspace/contractor /Users/dr/workspace/contractor/dist/build /Users/dr/workspace/contractor/dist/build/autogen /Users/dr/w
orkspace/contractor/src
Dependent packages:  Glob-0.7.5, aeson-0.8.0.2, base-4.7.0.1, containers-0.5.5.1, fclabels-2.0.2, mtl-2.1.3.1, text-1.2.0.0, time-1.4.2
System libraries:    /Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3

[killy971]

I'm having roughly the same problem

Error detected while processing function ghcmod#util#check_version:
line    9:
E684: list index out of range: 0
E15: Invalid expression: a:version[l:i] > s:ghc_mod_version[l:i]
E684: list index out of range: 1
E15: Invalid expression: a:version[l:i] > s:ghc_mod_version[l:i]
E684: list index out of range: 2
E15: Invalid expression: a:version[l:i] > s:ghc_mod_version[l:i]

[seantalts]

+1

[thatgim]

+1
Did anybody find a solution for this?

[anthonyquizon]

For my case, it seems like it was using the wrong version of the repo.
I think I must have used a different branch or commit sometime back.

Anyway, It looks to be fixed for me now that I've specified the branch name.

NeoBundle 'eagletmt/ghcmod-vim', 'master'

[beloglazov]

+1

[l29ah]

same on 7e5f610 and ghc-mod ea03f8a935d82cfd4a5af58dd5be5ef6e4741dcc

[l29ah]

fetched 07adfa9 and applied to the HEAD; nothing changed

[l29ah]

‰ ghc-mod --version
ghc-mod version 0 compiled by GHC 7.10.1
;[

[cgag]

+1

ghc-mod version 0 compiled by GHC 7.10.1

Compiled from master today.

[DanielG]

FYI version 0 is supposed to equal to a build from master and plugins should probably disable any feature checking when version == 0.

For anyone having this specific problem there's an easy fix just replace the Version: 0 line in the cabal file with something like Version: 5.3.0.0 or any other four component version number and then rebuild.

[aloiscochard]

@DanielG Thanks for the tips.

I don't think it's reasonable to expect plugins or anyone treat version 0 specifically.

Why not simply using the odd/even numbering convention, and then have proper version on master?

(I'm referring to the convention used by GHC/Cabal/... where odd number are for dev version and even for stable release, so master have a proper version and not zero)

[DanielG]

On Tue, May 26, 2015 at 03:56:31AM -0700, Alois Cochard wrote:

I don't think it's reasonable to expect plugins or anyone treat
version 0 specifically.

It's just as reasonable as expecting plugins to tread odd/even
versions specially.

Why not simply using the odd/even numbering convention, and then
have proper version on master?

I originally made that change just so I don't accidetally upload
unfinished versions from master to hackage before I have inserted the
version numbers in the appropriate places, since there was at least
one release where I forgot to change the version of the elisp
frontend.

[aloiscochard]

On 26 May 2015 at 13:28, Daniel Gröber notifications@github.com wrote:

On Tue, May 26, 2015 at 03:56:31AM -0700, Alois Cochard wrote:

I don't think it's reasonable to expect plugins or anyone treat
version 0 specifically.

It's just as reasonable as expecting plugins to tread odd/even
versions specially.

Sorry if I was not clear, I did not mean to say that authors should treat
odd/even version specially, just that this way it would have prevented the
problem we see here.

I don't think asking anyone to treat any version specifically is a good
idea :-)

Why not simply using the odd/even numbering convention, and then
have proper version on master?

I originally made that change just so I don't accidetally upload
unfinished versions from master to hackage before I have inserted the
version numbers in the appropriate places, since there was at least
one release where I forgot to change the version of the elisp
frontend.

I see thanks for explaining, I can understand this can sadly happen even
with the odd/even convention.

FWIW I'm working on a tool to automate releasing cabal libraries[1], which
should automate the process of handling version number... anyway it's just
in a very early stage, but that could help solve such issues without
loosing version during dev.

[1] https://github.com/aloiscochard/cabal-release

—

Reply to this email directly or view it on GitHub
#66 (comment).

Λ\ois
http://twitter.com/aloiscochard
http://github.com/aloiscochard

[DanielG]

I already built myself a script to do that: https://github.com/kazu-yamamoto/ghc-mod/blob/master/scripts/bump.sh it also keeps the elisp version in sync, forces me to update the ChangeLog and tags the resulting commit in git ;)