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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
<jfredett.vcf>
begin:vcard
fn:Joseph Fredette
n:Fredette;Joseph
adr:Apartment #3;;6 Dean Street;Worcester;Massachusetts;01609;United States of America
email;internet:jfred...@gmail.com
tel;home:1-508-966-9889
tel;cell:1-508-254-9901
x-mozilla-html:FALSE
url:lowlymath.net, humbuggery.net
version:2.1
end:vcard
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
