[Haskell-cafe] .hi inconsistency bug.

[Daniel Gorín]

> So, if I understand correctly, the interpreter is compiling  
> MainTypes twice?

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:

src/HackMail/Main.hs
src/HackMail/Data/Types.hs
src/SomePlugin.hs

and SomePlugin.hs is loaded by the interpreter, then you may want to  
reorganize your files like
this:

src/HackMail/Main.hs
src/HackMail/Data/Types.hs
plugins/SomePlugin.hs

and set the source path to "plugins" directory (using something like  
unsafeSetGhcOption "-i./plugins", or set [searchPath := ["./ 
plugins"]], if using the darcs version).

Daniel

> 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.
>
> /Joe
>
> Daniel Gorín wrote:
>> Hi
>>
>> 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!
>>
>> Daniel
>>
>> On Mar 17, 2009, at 11:52 PM, Joe Fredette wrote:
>>
>>> List,
>>>
>>> I've got this project, source on patch-tag here[1]
>>>
>>> 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  
>>> Email.
>>>
>>> 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[2] 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.
>>>
>>> /Joe
>>>
>>> [1] http://patch-tag.com/repo/Hackmail/browse
>>> [2] http://hackage.haskell.org/trac/ghc/ticket/2057
>>> <jfredett.vcf>_______________________________________________
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
> <jfredett.vcf>