[Haskell-cafe] .hi inconsistency bug.
jfredett at gmail.com
Wed Mar 18 18:35:27 EDT 2009
I seem to have fixed this bug, only to find another- the issue was that
I misunderstood what Cabal means by "exposed modules" upon exposing all
of the modules MainTypes uses, the problem resolved itself. I now have
another problem, having to do with importing the file from
$HOME/.hackmail, but I'm going to take a crack at it before bothering
the list again. Thanks very much Daniel,
Daniel Gorín wrote:
>> So, if I understand correctly, the interpreter is compiling MainTypes
> No, the interpreter is trying to compile types that were already
> compiled by the compiler when building your application. The resulting
> types are incompatible.
>> Could this be a result of having two outputs (one executable and one
>> library) in my .cabal file? it _does_ compile those things twice...
>> If I create a second cabal file which separates these two different
>> packages, would that fix it?
> I don't think so. If you already have your application split in
> library part + executable part, then everything should be fine (as
> long as the library is installed before running your application).
>> The issue is, the (dynamic) interpreter part of my code is part of
>> the main loop of the program, and is (as far as I can see)
>> inseparable from the rest of the code.
> What you need to separate is the code you are planning to interpret in
> runtime. For example, say you have:
> and SomePlugin.hs is loaded by the interpreter, then you may want to
> reorganize your files like
> and set the source path to "plugins" directory (using something like
> unsafeSetGhcOption "-i./plugins", or set [searchPath :=
> ["./plugins"]], if using the darcs version).
>> I'll give the cabal thing a try, given the incredible triviality of
>> doing everything with cabal, I should be done testing the solution
>> before I hit the send button... Cabal guys, you rock.
>> Thanks again, Dan.
>> Daniel Gorín wrote:
>>> Just a wild guess but maybe the interpreter is recompiling (in
>>> runtime) code that has already been compiled to build your
>>> application (in compile-time). This may lead to inconsistencies
>>> since a type such as HackMail.Data.Main.Types.Filter may refer to
>>> two different (and incompatible) types.
>>> To see if this is the case, make sure your "dynamic" code is not
>>> located together with your base code (i.e., move it to another
>>> directory, and set the src file directory for the interpreter
>>> accordingly). Now you may get another runtime error, something along
>>> the lines of "Module not found: HackMail.Data.MainTypes". This
>>> basically means that you need to make your (already compiled) types
>>> available to the interpreter. I think the simplest way is to put all
>>> your support types in a package, register it with ghc, link your
>>> application to it, and ask the interpreter to use this package (with
>>> a "-package " flag).
>>> Hope this helps!
>>> On Mar 17, 2009, at 11:52 PM, Joe Fredette wrote:
>>>> I've got this project, source on patch-tag here
>>>> It's a nice little project, I've got the whole thing roughly
>>>> working, it compiles okay, everything seems to work, until I try to
>>>> run it, specifically when I run it in ghci, or when I run the main
>>>> executable (which uses hint), and look at any type involving my
>>>> "Email" type, it gives me the following error:
>>>> Type syonym HackMail.Data.MainTypes.Filter:
>>>> Can't find interface-file declaration for type constructor or
>>>> class HackMail.Data.ParseEmail.Email
>>>> Probable cause: bug in .hi-boot file, or inconsistent .hi file
>>>> Use -ddump-if-trace to get an idea of which file caused the error
>>>> As far as I understand, it wants to find the interface-file
>>>> declaration for a specific type (Email) exported by the ParseEmail
>>>> module, all of the exports (I think) are in order. I've tried
>>>> mucking around with it a bit, but I don't fully understand what the
>>>> error even means, much less how to fix it.
>>>> Other relevant info, Email is exported in a roundabout way, namely
>>>> by importing a module MainTypes, which exports a module Email,
>>>> which exports a the ParseEmail Module, which exports the datatype
>>>> The "Filter" delcaration it _actually_ complains about (it's just
>>>> the first place the email type is invoked) is:
>>>> type Filter a = ReaderT (Config, Email) IO a
>>>> nothing particularly special.
>>>> Any help fixing this is greatly appreciated, I did find this bug
>>>> report which seems like it might be relevant.
>>>> But trying to unregister -> cabal clean -> cabal install doesn't
>>>> fix it. I've also tried manually removing the dist/ folder, and
>>>> also unregistering the package.
>>>> Thanks again.
>>>>  http://patch-tag.com/repo/Hackmail/browse
>>>>  http://hackage.haskell.org/trac/ghc/ticket/2057
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 296 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090318/2d45189b/jfredett.vcf
More information about the Haskell-Cafe