c2hs not getting installed / registered correctly - haskell

When I run cabal install c2hs, it seems to finish correctly, but doesn't register the package. The package seems as if it's not even installed: it doesn't show up in ghc-pkg list, and rerunning cabal install c2hs goes through the same install procedure, instead of saying "All the requested packages are already installed".
I'd much appreciate any help getting this up and running. I'm using the prebuilt GHC 7.4.1 binary.
cabal install output: http://pastebin.com/CRUii8mm
imports are defunct: http://pastebin.com/r0aypxRA
Thanks in advance!

I believe c2hs is an executable, not a library. The cabal install output that you provided shows that the execeutable is placed in your private .cabal/bin directory.

The C2HS module has been removed from newer versions of c2hs, since sometime prior to c2hs-0.15. If you check out the c2hs source tree, you could find it by going back through the revisions. Or some other libraries include it. There's more information in this trac ticket. C2hs is moving towards making the functions in C2HS.hs completely unnecessary, although they aren't quite there yet (floating-point formats in particular need to be manually marshalled).

Related

How to install an library in Haskell?

I try to use
Control.Monad.Extra.andM
import Control.Monad.Extra (andM)
but has an error:
Could not find module ‘Control.Monad.Extra’
Perhaps you meant
Control.Monad.Catch (needs flag -package-key exceptions-0.10.4)
Control.Monad.Error (needs flag -package-key mtl-2.2.2)
Control.Monad.Except (needs flag -package-key mtl-2.2.2)not found
This error does not make sense.
According to
https://cabal.readthedocs.io/en/3.6/installing-packages.html#installing-packages-from-hackage
3.2.1. Installing packages from Hackage
The cabal tool also can download, configure, build and install a Hackage package and all of its dependencies in a single step. To do this, run:
$ cabal install [PACKAGE...]
To browse the list of available packages, visit the Hackage web site.
Which says "in a single step", but in my experience this is too complicated and actually I have no idea how to install Control.Monad.Extra .
Usually, when a Haskeller want to install a specific library/package like this, how do you do this? There's no adequate documentations, it seems.
How to install an library in Haskell?
You don't. You should just depend on them, and then let Cabal worry about any installations that may need to be done. I.e., as you wrote
Go to the Hackage page and study which exact library to be used.
*.cabal file -> build-depends: extra >=1.7.10
This is the crucial step. Your own Cabal file is the way to both specify what libraries are needed right now, as well as ensuring that everything will still work in the future. This file needs to specify both the packages you require, as well as the modules you're defining yourself.
Probably you don't actually need >=1.7.10, but it can't hurt much to be specific there. Standard practice is to add both lower and upper bounds on the x.y level, i.e. you'd use extra >=1.7 && <1.8, and then push the upper boundary as new versions come out. Arguably this is a bit overcautious; if you only use some simple tools from a package that is unlikely to have breaking changes in the future then it may be less trouble to just leave the upper boundary out.
$ cabal install extra
You've already specified that extra is needed for your project, no need to state that again. Instead, simply build your own project now.$ cabal buildor, to get a GHCi prompt with your modules,$ cabal replor, if you have an executable with a main that you wish to execute$ cabal runor if you want to install that executable (and only then)$ cabal installCabal will then automatically figure out that extra-1.7.10 should be installed first.
(In old Cabal it would still have been necessary to run cabal install --dependencies-only first.)
Ok Self-Answered. Comment me if the information is wrong.
1. Go to the Hackage page and study which exact library to be used.
In this case, it seems extra-1.7.10.
2. *.cabal file -> build-depends: extra >=1.7.10 (among other libs)
3. $ cabal install extra
Error:
cabal: Cannot build the executables in the package extra because it does not contain any executables. Check the .cabal file for the package and make sure that it properly declares the components that you expect.
Well, I did for sure.
4. cabal install extra --lib
Finally works, but the documentation never said this.
Am I correct?
`
Is this the only method? or any other smarter way?

How to get Cabal Sandbox to install correctly linked HTML documentation?

I created a cabal library inside a sandbox with the following commands:
cabal sandbox init
cabal init
I added the line documentation: True to cabal.config to make sure that documentation is generated, and I added a dependency to the vector package in mylib.cabal. Then I ran:
cabal install --only-dependencies
I got the following output:
/scm/hs-proj/.cabal-sandbox
Configuring primitive-0.6...
Building primitive-0.6...
Installed primitive-0.6
Configuring vector-0.10.12.3...
Building vector-0.10.12.3...
Installed vector-0.10.12.3
Updating documentation index
/scm/hs-proj/.cabal-sandbox/share/doc/x86_64-osx-ghc-7.10.1/index.html
So far so good.
When I opened the index file it contained links to a lot of packages, like:
file:///scm/hs-proj/.cabal-sandbox/share/doc/x86_64-osx-ghc-7.10.1/Data-List.html
file:///scm/hs-proj/.cabal-sandbox/share/doc/x86_64-osx-ghc-7.10.1/Data-Vector.html
But of these links pointed to any real files. Note that this is the case for the extra dependencies like vector and also for built-in packages list Data.List.
So I think I've installed the documentation incorrectly. Can someone point out how I've installed the documentation incorrectly and how to do it correctly?
It's not your fault, this is a known bug in haddock.
It only affects ghc 7.10, so a workaround could be to use ghc 7.8.4 until this is fixed.

Stackage inclusive or exclusive usage

I'm attempting to start a new project using the Snap web framework. I used snap init to get my basic skeleton working. I also put http://www.stackage.org/lts/cabal.config next to my .cabal file. I didn't uncomment the line to use Stackage exclusively. So I tried to build and it failed and couldn't find the version of lens required by my .cabal file. The cabal.config file from Stackage specifies a version of lens that is not the same as the one in my .cabal file. So I deleted every constraint from my package list and did the usual cabal install --only-dep -j8 --enable-test and it worked!
However, I have always been told that package versions should be constrained. So when working with Stackage is it okay to leave package versions unconstrained? Should I downgrade my packages to the ones available in Stackage instead?
As far as I understand a cabal.config file specifies a set of dependencies with the specific versions that satisfy dependencies, so how does Stackage work? Is it just a subset of packages from Hackage that are proven to be compatible? Do they host their own packages or rely on Hackage for downloads?
Thanks in advance :)
Both options are available. The default option is what you did, and still goes to hackage to get the packages. You just added a filter to your cabal that prevents you from using any version of a package included in Stackage that was not tested to work together with all of the other packages.
The other option is to simply point your cabal repo to a Stackage url, and then you will download packages directly from the Stackage server. That server will only serve packages that are known to work together, so there is no need for additional constraints in your cabal file. I actually prefer this way of working.
In both cases, if you have additional constraints in your cabal file that are incompatible with the Stackage restrictions, your build will fail. If you use the first option, you will get dependency conflicts. When using the second option, the Stackage server will simply report that it does not have that specific package/version.

How can I resolve zlib-enum, zlib-binding, zlib-conduit conflict when installing Yesod

I am trying to install my Yesod web app on another machine.
I have it installed fine on my current machine and can cabal install it on there without any problems.
I seem to run into trouble with it on the other machine though (which is a fresh Ubuntu VM - e.g., no cabal packages where installed on it prior.
Note that I changed nothing about my setup (e.g. cabal files are exactly the same).
This is the error I keep getting:
cabal: cannot configure zlib-enum-0.2.2. It requires zlib-bindings ==0.1.*
For the dependency on zlib-bindings ==0.1.* there are these packages:
zlib-bindings-0.1.0 and zlib-bindings-0.1.0.1. However none of them are available.
zlib-bindings-0.1.0 was excluded because zlib-conduit-0.2.0.1 requires zlib-bindings >=0.0.3 && <0.1
zlib-bindings-0.1.0 was excluded because zlib-bindings-0.0.3.2 was selected instead
zlib-bindings-0.1.0 was excluded because of the top level dependency zlib-bindings ==0.0.3.2
zlib-bindings-0.1.0.1 was excluded because zlib-conduit-0.2.0.1 requires zlib-bindings >=0.0.3 && <0.1
zlib-bindings-0.1.0.1 was excluded because zlib-bindings-0.0.3.2 was selected instead
zlib-bindings-0.1.0.1 was excluded because of the top level dependency zlib-bindings ==0.0.3.2
I have tried all kind of ways to resolve this, but keep running into this same problem, no matter what path I take.
My guess is, that theses packages' versions are conflicting at this point.
How can I resolve this until it gets fixed?
This is a prime example of cabal dependency hell. Theoretically, the fault lies with zlib-enum, since it should have had a major version bump to reflect the major version bump with zlib-bindings. But really, the problem is cabal's dependency analyzer. The new one will hopefully be ready soon.
In the meanwhile, depending on zlib-enum <= 0.2.1 should work.
Also, #ehird's answer should be helpful too, though it may not entirely solve the problem.
You might want to try installing the new Yesod Platform (Hackage page):
cabal install yesod-platform
It's a metapackage that depends on specific versions of Yesod and all its dependencies, designed to avoid versioning conflicts like this.
You could also try the in-development version of cabal-install, which has the modular dependency solver Michael mentioned. If you darcs get --lazy http://darcs.haskell.org/cabal/, you should be able to run bootstrap.sh in cabal/cabal-install to install it (but you should probably wipe ~/.cabal and ~/.ghc first).1 You still have to explicitly request the modular solver by passing --solver=modular to cabal, though.
Note that, even though it's a development version, it's actually pretty stable; lots of people on GHC 7.4.1 (including me) use it, since the version on Hackage doesn't compile. I haven't had any issues so far.
1 This is for Linux; I think the relevant directory is ~/Library/Haskell on OS X. I have no idea what to do on Windows, especially since the shell script won't run there.

Could not find module `Control.Monad.Reader'

Today when I tried to compile my code in Geany I got this error
Could not find module `Control.Monad.Reader':
it was found in multiple packages: monads-fd-0.1.0.1 mtl-1.1.0.2
Compilation failed.
I get the same for the Writer monad; I thought I should remove one of those packages, but I do not want to break other packages, so now what should I do, yesterday everything worked without any problem.
It looks like you have recently installed monads-fd, perhaps as a dependency of something else you installed. Both monads-fd and mtl packages contain the module Control.Monad.Reader, so GHC doesn't know which one to use when you compile some code that imports it. You need to resolve the ambiguity somehow:
If you are using GHC or GHCi directly
either use a -hide-package <package> flag on the command line to hide one of the packages, or
hide the package by default using ghc-pkg hide <package>. You may need to use ghc-pkg --user hide <package> if the package was installed in your home directory (the default on some platforms).
You can use Cabal, and say exactly which one of the conflicting packages you depend on using the build-depends field in your .cabal file
I encountered a similar problem recently, and it was suggested that I run ghc-pkg hide {x} where '{x}' is the name of one of those packages. It worked in my situation.

Resources