Oh- I see, so The portion of code I have to interpret is already
separated -- it's not even compiled. The only interpreted code is a
configuration file in the users home directory. It needs to import some
chunk of the library (namely, MainTypes and Deliverable) so as to be
able to export a single routine (filterMain) which gets interpreted at
run time. But as it stands, I don't even get as far as running that
code. The problem lies solely in MainTypes proper, which has no dynamic
code in it or even associated with it. I tried compiling separately and
together, no dice either way. Somehow, the Email datatype isn't being
exported from ParseEmail.
However, wrt this:
> and set the source path to "plugins" directory (using something like
unsafeSetGhcOption "-i./plugins", or set [searchPath
> := ["./plugins"]], if using the darcs version).
I don't think my hint-related code does this- since my Hint code is
entirely:
-- Returns a pair, a path to the inbox location (where new emails
enter the system) and also
-- a Filter, the filter delivers (it's a Reader + IO monad) the
email based on the config+options.
getFilterMainStuff :: FilePath -> Interpreter (Path, Filter ())
getFilterMainStuff fMainLoc = do
loadModules [fMainLoc]; setTopLevelModules [(takeWhile
(/='.') fMainLoc)]
inboxL <- parse <$> interpret "(inboxLoc)" infer
fMain <- (interpret "(filterMain)" infer)
return (inboxL, fMain)
That is, I load a module, set the TopLevel to include that module, read
two functions out of that module (one containing the location of the
inbox to poll, on with the filtering main function) and return them. I
don't think I need to set any search paths, since fMainLoc is a full
path. Could this be where my problem is?
Really, I'm just trying to isolate whether it's really Hint causing the
problem, or something else, because I could always do what xmonad does
wrt to this- which is (from what I can tell) statically import your
config file from a given location, which would alleviate all of this, if
the problem is hint. Perhaps I'll just try that in any case... see if it
helps.
Thanks again 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/2d2a2f69/jfredett.vcf