Cannot find package

[claudeha]

Hi, thanks for this interesting program!

I have up to now been using https://github.com/claudeha/Hugs/tree/OverloadedStrings but suffer bad problems like the dreaded Hugs Control Stack Overflow with more complicated programs.

But there seems to be some issue with mhs (or mcabal), which claims it can't find packages (e.g. transformers) that have been installed (and have indeed been successfully used to install dependent package, e.g. mtl):

$ # add ~/.mcabal/bin to PATH
$ git clone https://github.com/augustss/MicroHs.git
...
$ cd MicroHs
$ make install
...
$ cd ..
$ mcabal +RTS -H10M -RTS install transformers
$ git clone https://github.com/augustss/mtl.git
...
$ cd mtl
$ mcabal +RTS -H10M -RTS install
$ cd ..
$ git clone https://github.com/haskell/containers.git
...
$ cd containers
$ mcabal +RTS -H10M -RTS install
$ cd ..

$ git clone https://code.mathr.co.uk/godwit.git # a06d586
$ cd godwit
$ make compiler/Lexer.hs # using alex + cpphs
$ make compiler/Parser.hs # using happy + cpphs
$ mcabal +RTS -H10M -RTS install
mcabal: Building executable godwit
mcabal: Build dist-mcabal/bin/mhs/godwit with mhs
Warning: cannot derive Read yet, "compiler/Type.hs": line 17, col 13
Warning: cannot derive Read yet, "compiler/Lexer.hs": line 7649, col 22
Warning: cannot derive Read yet, "compiler/Expr.hs": line 38, col 13
Warning: cannot derive Read yet, "compiler/Expr.hs": line 100, col 13
Warning: cannot derive Read yet, "compiler/Expr.hs": line 273, col 22
Warning: cannot derive Read yet, "compiler/Expr.hs": line 302, col 22
Warning: cannot derive Read yet, "compiler/Infix.hs": line 14, col 22
Warning: cannot derive Read yet, "compiler/Parser.hs": line 2541, col 13
Warning: cannot derive Read yet, "compiler/CCC.hs": line 33, col 13
mhs: error: Cannot find package transformers
mhs: error: callCommand: failed 256, "mhs -i -icompiler -icompiler/ghc -idist-mcabal/autogen '-DVERSION_base=\"4.19.1.0\"' '-DMIN_VERSION_base(x,y,z)=((x)<4||(x)==4&&(y)<19||(x)==4&&(y)==19&&(z)<=1)' '-DVERSION_containers=\"0.7\"' '-DMIN_VERSION_containers(x,y,z)=((x)<0||(x)==0&&(y)<7||(x)==0&&(y)==7&&(z)<=0)' '-DVERSION_mtl=\"2.3.1\"' '-DMIN_VERSION_mtl(x,y,z)=((x)<2||(x)==2&&(y)<3||(x)==2&&(y)==3&&(z)<=1)' '-DVERSION_process=\"1.6.18.0\"' '-DMIN_VERSION_process(x,y,z)=((x)<1||(x)==1&&(y)<6||(x)==1&&(y)==6&&(z)<=18)' '-DVERSION_transformers=\"0.6.1.2\"' '-DMIN_VERSION_transformers(x,y,z)=((x)<0||(x)==0&&(y)<6||(x)==0&&(y)==6&&(z)<=1)' -a. -odist-mcabal/bin/mhs/godwit compiler/Main.hs"

(The +RTS -H10M -RTS is to avoid OOM kill, my test machine has only 2GB RAM + 1GB swap..)

Am I doing something wrong or is this a bug?

[augustss]

That looks like a bug.

[AlexandreTunstall]

The package handling between MicroCabal and MicroHs could use improvement.
I've been packaging the projects into Nix builds and have run into various issues with it.

1. Setting MHSDIR to something non-default completely breaks mhs's ability to find the base and mhs packages. This happens because the ancestor of MHSDIR is added to the package search path only when the variable is the default value.
2. Similarly, setting MHSDIR breaks mcabal install for libraries because MicroCabal relies on MicroHs finding the package directory on its own.
3. mcabal install does not honour CABALDIR when installing libraries for the same reason.
4. As far as I can tell, MicroCabal does not support setting a separate directory for the install destination of mcabal install. It always installs in CABALDIR. This would be fine if it were possible to install without building the package when you have a cached build, since you could build with a different CABALDIR.
5. MicroHs supports multiple package search paths, but MicroCabal only supports one.
6. If MicroHs and MicroCabal disagree over what the package search paths are, one could find a package while the other cannot. For robustness sake, MicroCabal should either always query MicroHs for package lookups or it should always pass its own search path to MicroHs.

Notes about the peculiarities of the Nix build environment:

• There is no ~. This can already be worked around with CABALDIR.
• The existing package database is read-only.
• Since each build has its own output path, each package ends up in a different CABALDIR. MicroHS already supports multiple package search paths, but MicroCabal doesn't. This can be worked around by merging the paths into one tree of symlinks.

As for your own issues, have you tried running the failing command with -v -v -v?
At a sufficiently high verbosity, mhs prints out its package search path.
I suspect that the default search path is missing ~/.mcabal/microhs-$ver, so MicroCabal can find the package via the default CABALDIR, but MicroHs can't (see issue 6 in my list).

[augustss]

Yes, MicroCabal needs a lot of changes for any non-standard use case (i.e., not my use case).

[claudeha]

instrumenting with some prints shows that it was trying to load transformers.pkg instead of transformers-${VERSION}.pkg

fix that seems to work for me:

diff --git a/src/MicroHs/Compile.hs b/src/MicroHs/Compile.hs
index 2ed6923e..bea76d0c 100644
--- a/src/MicroHs/Compile.hs
+++ b/src/MicroHs/Compile.hs
@@ -434,16 +434,16 @@ loadDependencies flags = do
   loadedPkgs <- gets getPkgs
   let deps = concatMap pkgDepends loadedPkgs
       loaded = map pkgName loadedPkgs
-      deps' = [ p | (p, _v) <- deps, p `notElem` loaded ]
+      deps' = [ pv | pv@(p, _v) <- deps, p `notElem` loaded ]
   if null deps' then
     return ()
    else do
     mapM_ (loadDeps flags) deps'
     loadDependencies flags  -- loadDeps can add new dependencies
 
-loadDeps :: Flags -> IdentPackage -> CM ()
-loadDeps flags pid = do
-  mres <- liftIO $ openFilePath (pkgPath flags) (packageDir </> unIdent pid <.> packageSuffix)
+loadDeps :: Flags -> (IdentPackage, Version) -> CM ()
+loadDeps flags (pid, pver) = do
+  mres <- liftIO $ openFilePath (pkgPath flags) (packageDir </> unIdent pid ++ "-" ++ showVersion pver <.> packageSuffix)
   case mres of
     Nothing -> error $ "Cannot find package " ++ showIdent pid
     Just (pfn, hdl) -> do

at least my code now gets past that stage and reports an error about Double not being a valid FFI type (and I can't convert CDouble to Double because no Real CDouble).

[augustss]

You can Data.Coerce.coerce between Double and CDouble. But I'll fix that bug.