[Haskell-cafe] .hi inconsistency bug.

[Joe Fredette]

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,

/Joe

Daniel Gorín wrote:
>> 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>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jfredett.vcf
Type: text/x-vcard
Size: 296 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20090318/2d45189b/jfredett.vcf