Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error detected while processing function ghcmod#util#check_version #66

Closed
dredozubov opened this issue Nov 26, 2014 · 15 comments
Closed

Comments

@dredozubov
Copy link

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
Copy link

killy971 commented Dec 2, 2014

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
Copy link

+1

@thatgim
Copy link

thatgim commented Jan 23, 2015

+1
Did anybody find a solution for this?

@anthonyquizon
Copy link

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
Copy link

+1

@l29ah
Copy link

l29ah commented Apr 29, 2015

same on 7e5f610 and ghc-mod ea03f8a935d82cfd4a5af58dd5be5ef6e4741dcc

@l29ah
Copy link

l29ah commented Apr 29, 2015

fetched 07adfa9 and applied to the HEAD; nothing changed

@l29ah
Copy link

l29ah commented Apr 29, 2015

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

@cgag
Copy link

cgag commented May 15, 2015

+1

ghc-mod version 0 compiled by GHC 7.10.1

Compiled from master today.

@DanielG
Copy link

DanielG commented May 15, 2015

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.

renhx added a commit to renhx/ghcmod-vim that referenced this issue May 24, 2015
@aloiscochard
Copy link

@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
Copy link

DanielG commented May 26, 2015

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
Copy link

On 26 May 2015 at 13:28, Daniel Gröber [email protected] 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
Copy link

DanielG commented May 26, 2015

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 ;)

@aloiscochard
Copy link

Neat!

Exactly the kind of stuff I would love to automate with a haskell tool :)

Thanks for the inspiration Daniel!

On 26 May 2015 at 13:51, Daniel Gröber [email protected] wrote:

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 ;)


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

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

expipiplus1 pushed a commit to expipiplus1/ghcmod-vim that referenced this issue Oct 26, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants