Leksah metadata problem
Bjorn Buckwalter
Leksah 0.10.0.4 does not seem to find meta data for my installed
packages. From the console at startup:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Using default Yi configuration
Yi Control Do Layout
(process:37909): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
Now updating system metadata ...
***server start
Bind 127.0.0.1:26411
Metadata collector has nothing to do
Metadata collection has finished
Now loading metadata ...
packageInfo not found for zlib-bindings-0.0.0
packageInfo not found for digest-0.0.0.9
packageInfo not found for fingertree-0.0.1.0
packageInfo not found for executable-path-0.0.2
packageInfo not found for file-embed-0.0.4.1
packageInfo not found for hjsmin-0.0.14
...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Apparently Leksah knows which packages I have installed but is unable
to find their "packageInfo". When rebuilding metadata (leksah-server
-osb +RTS -N2 -RTS) I get the following messages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
***server start
update_toolbar 0.0
update_toolbar 1.3157894736842105e-2
Creating interfaces...
Checking module Data.Array...
Ghc failed to process: Bad interface file:
/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/base-4.3.1.0/Prelude.hi
magic number mismatch: old/corrupt interface file? (wanted 129742,
got 33214052)
...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The last three lines (Ghc failed...) seem to repeat for most packages.
Is Leksah picking up the wrong "base"?
I am on Mac OS X using Haskell Platform 2011.2.0.1. Any ideas?
Thanks,
Bjorn
jutaro
sorry for the late reply. Did you already find a way around the
problem?
What is frequently the case, is that Leksah server has to be compiled
with the same ghc version you are actually using. We should add some
check to leksah, which gives a warning in this case.
Jürgen
Bjorn Buckwalter
No, I didn't find a work around and decided to stick with vim for the
time being. I'm using the prebuilt binary for "OS X 10.6 users using
GHC 7.0.3", which is consistent with my setup so it seems the problem
is something other than what you suggested?
Thanks,
Bjorn