I get this type error:
Couldn't match type `containers-0.5.0.0:Data.Map.Base.Map
ByteString [ByteString]'
with `M.Map ByteString [ByteString]'
Expected type: M.Map ByteString [ByteString]
Actual type: Params
But Params type is Map ByteString [ByteString]
type Params = Map ByteString [ByteString]
If it is of any help, this is the full function:
import qualified Data.Map as M
categoryDoc :: Params -> Document
categoryDoc params = map (\(k,[v]) -> T.decodeUtf8 k =: T.decodeUtf8 v) $ M.toList params
Thank you.
You have encountered cabal hell.
The problem is that there are multiple versions of the containers package installed. This means that there are two versions of the Map data type, one from containers-0.5.0.0 and one from the other version. Those two won't match, and that's why you get the error.
The easiest solution to that problem is to delete the ~/.ghc (on unix) directory and rebuilt everything. But that won't protect you from such problems in future, and there is also a chance that it won't work at all. So this is not a good solution.
If you have cabal-install of at least version 1.18, you can use the cabal sandboxes feature. This allows you to create an isolated package environment for each project, and thus avoid such conflicts. Just switch to your project and run:
cabal sandbox init # Create a new sandbox
cabal install --only-dependencies # Install dependencies
cabal build # Build your project
You can also use cabal install to install your project into the sandbox or cabal repl to start GHCi with the right settings for your project.
If you do not have a new-enough version of cabal-install and can't upgrade, you can use cabal-dev to create and manage sandboxes.
Related
I put this in a file (see bottom) and got the following error when loading it in ghci (i.e. start ghci then :l file):
7:13: error:
• Couldn't match expected type ‘network-uri-2.6.1.0#network-uri-2.6.1.0-7BN1tbB3iHQ2XgvmqLAYph:Network.URI.URI’
with actual type ‘Network.URI.URI’
NB: ‘Network.URI.URI’
is defined in ‘Network.URI’
in package ‘network-uri-2.6.1.0#network-uri-2.6.1.0-80FpvaNUTSDFCPv0sSze40’
‘network-uri-2.6.1.0#network-uri-2.6.1.0-7BN1tbB3iHQ2XgvmqLAYph:Network.URI.URI’
is defined in ‘Network.URI’
in package ‘network-uri-2.6.1.0#network-uri-2.6.1.0-7BN1tbB3iHQ2XgvmqLAYph’
Have I somehow installed two slightly different versions of network-uri, or what is this? How do I resolve it?
I've hardly used cabal but tried cabal install --reinstall network-uri, went fine but problem persists.
File contents:
import Network.HTTP
import Network.URI (parseURI)
import Data.Maybe (fromJust)
myRequestURL = "http://www.virginia.edu/cgi-local/ldapweb"
myRequest :: String -> Request_String
myRequest query = Request {
rqURI = fromJust $ parseURI myRequestURL
, rqMethod = POST
, rqHeaders = [ mkHeader HdrContentType "text/html"
, mkHeader HdrContentLength $ show $ length body ]
, rqBody = body
}
where body = "whitepages=" ++ query
main :: IO ()
main = do
response <- simpleHTTP $ myRequest "poon"
putStrLn ""
EDIT Re-installed haskell-platform. After this, ghc-pkg list reports all packages to be under (?) /usr/lib/ghc/package.conf.d, and the program I tried to copy loads just fine.
EDIT 2 After running cabal install some-pkg, ghc-pkg list reports that the newly installed stuff is in another directory. Indeed, ~/.cabal/config specifies install dirs for user, as well as install dirs for global. How is all this supposed to be managed properly?
GHC understands the concept of package databases. Cabal manages multiple package databases. There's a system package database, and a user package database. When you compile something with Cabal V1, it uses the union of these package databases. This is a bit of a time bomb, because, as you see, GHC does not like it when you have multiple of the same package. When you issued cabal install network-uri, cabal decided to install one copy of that package into your user database, though you already had one in the system database. When you tried to use ghc, it picked up on the two copies and got confused. Because cabal does not support removing packages, your Haskell installation was pretty much borked, and you reinstalled. I believe you could have done a more conservative rm ~/.ghc, or, had you been really adventurous, used the low-level ghc-pkg command to edit the package database.
Now that you've reinstalled the Platform, I would heavily recommend never using cabal install again. It's old, it's broken, cabal itself tells you not to use it. If you're using the Platform, I think it has stack in it, which is a different build manager, based on Cabal, which is not prone to this kind of breakage. Or, you can just stick to the V2 series of cabal commands, which is what I prefer.
Cabal V2 does not directly support your usecase, where you install a package globally and compile a program against it. This is because doing so is fundamentally broken: global package databases really just don't work for GHC. What Cabal V2 does is install packages into your home directory, ~/.cabal/store. You then have to explicitly tell it which packages you want, and it will construct a package database that contains each required package, without any wonkiness. You can get a REPL with a certain set of packages by issuing (this will take you to a temporary directory; you may need to :cd yourself back.)
cabal v2-repl -b network-uri -b package2 -b etc
If you want to actually compile files with ghc with a set packages, you have to actually define a package with a .cabal file. Here's a stub .cabal file:
name: temporary-pkg
version: 0.0.0.0
build-type: Simple
cabal-version: >=2.0
executable main -- if there is no Main, say "library" instead of "executable <name>"
default-language: Haskell2010
main-is: Main.hs -- only valid in executable stanzas
hs-source-dirs: src -- source files go here
build-depends: base, network-uri, package2, etc -- packages go here
Create and enter a directory, place that in temporary-pkg.cabal, place your sources in src/, and you can issue stuff like cabal v2-build and cabal v2-repl and cabal v2-exec main, etc. cabal will go off and install dependencies from Hackage into ~/.cabal/store as needed. cabal v2-install is therefore not that useful here. In general, v2-installing libraries is unnecessary, but v2-installing packages with executables is useful. Again, for hygiene reasons, you have to list all the packages you are importing from, but you don't need to list their dependencies or anything insane like that.
Cabal V2 still doesn't support uninstalling packages, though the point is that should not be necessary. However, if you find ~/.cabal/store getting too large for your liking, you can just nuke it, and should be built back up as packages are requested.
I'm working on a stream of ByteStrings. I've imported ByteString via:
import qualified Data.ByteString as B
I can call every function from the ByteString library e.g.:
reverseBS :: Monad m => Conduit B.ByteString m B.ByteString
reverseBS = CL.map B.reverse
This works as intended.
I need a function to remove the trailing newline from a ByteString. I've opted to use stripSuffix from ByteString. My code looks like this:
removeNewline :: Monad m => Conduit B.ByteString m B.ByteString
removeNewline = CL.map $ B.stripSuffix "\n"
But my code won't compile and gives the following error:
Not in scope: ‘B.stripSuffix’
I've tried install the latest version of ByteString from GitHub but this didn't help.
EDIT:
I noticed that there's something wrong with my ghc-pkg list. It give me the following output:
Thomass-MacBook-Pro:src ThomasVanhelden$ ghc-pkg list
/Applications/ghc-7.10.3.app/Contents/lib/ghc-7.10.3/package.conf.d
Cabal-1.22.5.0
array-0.5.1.0
base-4.8.2.0
bin-package-db-0.0.0.0
binary-0.7.5.0
bytestring-0.10.6.0
containers-0.5.6.2
deepseq-1.4.1.1
directory-1.2.2.0
filepath-1.4.0.0
ghc-7.10.3
ghc-prim-0.4.0.0
haskeline-0.7.2.1
hoopl-3.10.0.2
hpc-0.6.0.2
integer-gmp-1.0.0.0
pretty-1.1.2.0
process-1.2.3.0
rts-1.0
template-haskell-2.10.0.0
terminfo-0.4.0.1
time-1.5.0.1
transformers-0.4.2.0
unix-2.7.1.0
xhtml-3000.2.1
/Users/ThomasVanhelden/.ghc/x86_64-darwin-7.10.3/package.conf.d
WAVE-0.1.3
abstract-deque-0.3
abstract-par-0.3.3
async-2.1.1
attoparsec-0.13.1.0
base16-bytestring-0.1.1.6
base64-bytestring-1.0.0.1
blaze-builder-0.4.0.2
bytestring-0.10.8.2
bytestring-lexing-0.5.0.2
cereal-0.5.4.0
chunked-data-0.3.0
conduit-1.2.8
conduit-combinators-1.0.8.3
conduit-extra-1.1.15
exceptions-0.8.3
extensible-exceptions-0.1.1.4
fail-4.9.0.0
hashable-1.2.4.0
lifted-base-0.2.3.8
mmorph-1.0.9
monad-control-1.0.1.0
monad-par-0.3.4.8
monad-par-extras-0.3.3
mono-traversable-1.0.1
mtl-2.2.1
mwc-random-0.13.5.0
network-2.6.3.1
network-conduit-1.1.0
parallel-3.2.1.0
parallel-io-0.3.3
parseargs-0.2.0.8
primitive-0.6.1.0
random-1.1
resourcet-1.1.8.1
scientific-0.3.4.9
semigroups-0.18.2
split-0.2.3.1
stm-2.4.4.1
streaming-commons-0.1.16
tagged-0.8.5
text-1.2.2.1
transformers-base-0.4.4
transformers-compat-0.5.1.4
unix-compat-0.4.2.0
unordered-containers-0.2.7.1
vector-0.11.0.0
vector-algorithms-0.7.0.1
void-0.7.1
word8-0.1.2
zlib-0.6.1.2
It looks like it is looking in two different directories for packages and two different versions of ByteString might be the cause of the problem. How can I solve this? Is there a simple way to uninstall bytestring-0.10.6.0?
Firs of all, it is worth mentioning that stripSuffix was indeed introduced in version 0.18 of bytestring. Quoting the changelog:
0.10.8.0 Duncan Coutts duncan#community.haskell.org May 2016
[etc.]
Added stripPrefix and stripSuffix for lazy and strict bytestrings
That sad, onward to your question:
Is there a simple way to uninstall bytestring-0.10.6.0?
No, there isn't, because, as the ghc-pkg output tells you, the 0.10.6.0 version is among the packages installed globally (i.e. system-wide rather than per-user). Uninstalling it would break all the other packages you had installed previously that depend on bytestring. When you installed bytestring from GitHub, it went to your per-user package database. To avoid further headache, the first thing I suggest is getting rid of the newer bytestring that you have installed, with:
ghc-pkg unregister bytestring-0.10.8.2
Then, to get the latest bytestring, you should update the Haskell installation in your system (for instance, the latest minimal Haskell Platform carries bytestring-0.10.8.1). Alternatively, you can use Stack to manage multiple GHC versions (as well as appropriate package databases for them) for your projects.
Program has the following import:
import Pipes.Network.TCP
import Pipes
import Pipes.Core
import qualified Data.ByteString.Char8 as C
Compilation fails like so:
Couldn't match expected type `bytestring-0.9.2.1:Data.ByteString.Internal.ByteString'
with actual type `C.ByteString'
Expected type: Proxy
Int
bytestring-0.9.2.1:Data.ByteString.Internal.ByteString
()
b0
m0
()
Actual type: Proxy Int C.ByteString () C.ByteString IO ()
I can be more specific about the code, but it looks like this is not related to code - rather some cabal whim. Perhaps, Pipes that I import are considered to use a different ByteString than the one imported with qualified name.
The program used to compile some time ago (I have its working executable), but now it stopped, and I suspect there could have been some cabal update or package installation. How to debug and fix this?
Assuming your program is built with cabal, you should re-configure it. This may highlight other problems, such as dependencies which would require re-installing or breaking other parts of the dependency tree. The "old way" to solve this is to progressively cabal install more and more things until the dependency solver agrees it's possible, e.g.
$ cabal install .
# complains that reinstalls might break lens
$ cabal install . lens
# complains that reinstalls might break bytestring
$ cabal install . lens bytestring
# complains that reinstalls might break X
$ cabal install . lens bytestring X
...etc. The "new way" is to use no-reinstall cabal. You will still need to reconfigure before you build, and may need to install some dependencies again to transition properly.
I'm pretty new to Haskell, and trying to install Yesod with Cabal, but I'm running into this compilation error:
cabal install yesod --force-reinstalls
Network/Wai/Parse.hs:106:61:
No instance for (Control.Monad.Trans.Resource.Internal.MonadThrow
(ConduitM S8.ByteString Void IO))
arising from a use of `allocate'
Possible fix:
add an instance declaration for
(Control.Monad.Trans.Resource.Internal.MonadThrow
(ConduitM S8.ByteString Void IO))
In the second argument of `($)', namely
`allocate
(do { tempDir <- getTmpDir;
openBinaryTempFile tempDir pattern })
(\ (_, h) -> hClose h)'
In a stmt of a 'do' block:
(key, (fp, h)) <- flip runInternalState internalState
$ allocate
(do { tempDir <- getTmpDir;
openBinaryTempFile tempDir pattern })
(\ (_, h) -> hClose h)
In the expression:
do { (key, (fp, h)) <- flip runInternalState internalState
$ allocate
(do { tempDir <- getTmpDir;
openBinaryTempFile tempDir pattern })
(\ (_, h) -> hClose h);
_ <- runInternalState (register $ removeFile fp) internalState;
CB.sinkHandle h;
lift $ release key;
.... }
Failed to install wai-extra-2.0.2
This is the full output when installing
I'm using the latest Haskell Platform with the ghc-clang-wrapper script.
Cabal versions:
$ cabal --version
cabal-install version 1.16.0.2
using version 1.16.0 of the Cabal library
GHC version:
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.6.3
Some of the tutorials mention using a cabal sandbox, but my version of cabal (1.16) is too old for that. If the sandbox is likely too help I'll try and get that working (had a little trouble updating cabal to 1.18).
It looks like you have several modules which when installed beside existing modules cause name collisions. Further up in the output before the error you posted there are a bunch of errors like this:
Network/HTTP/Client/Conduit.hs:37:9:
Ambiguous occurrence `MonadResource'
It could refer to either `Data.Conduit.MonadResource',
imported from `Data.Conduit' at Network/HTTP/Client/Conduit.hs:13:1-19
(and originally defined in `resourcet-0.4.10:Control.Monad.Trans.Resource.Internal')
or `Control.Monad.Trans.Resource.MonadResource',
imported from `Control.Monad.Trans.Resource' at Network/HTTP/Client/Conduit.hs:15:1-35
(and originally defined in `Control.Monad.Trans.Resource.Internal')
These may be caused by --force-reinstalls. This is basically what cabal sandbox was created for so it may be easier to post a question about whatever is going wrong in updating that. You should be able to cabal install cabal-install to update it to the newest version.
Edit:
If cabal install cabal-install is working then the first thing I would check, as Chrules mentions, is where your path is pointed at. When you install cabal via cabal it will get put in ~/.cabal/bin so that needs to be first in your path. If you do which cabal you'l probably now see something like /usr/bin/cabal, you want that to be ~/.cabal/bin/cabal. Since you're local user packages are now messed up anway here's what I would do.
rm -rf ~/.cabal ~/.ghc # This deletes everything you installed with cabal
cabal update # Reinitialize the platform cabal
cabal install cabal-install # Update cabal
cabal install yesod # This will work since you nuked your ~/.cabal and ~/.ghc
After doing this you will have nothing installed but yesod, and you probably want yesod-bin as well since that has the yesod binary (at ~/.cabal/bin).
I'm trying to get this example code to compile on my system.
When I try to compile the Chat module with ghc Chat.hs, ghc gives me this:
Chat.hs:76:39:
Couldn't match expected type `Network.Wai.Request'
with actual type `wai-0.4.3:Network.Wai.Request'
In the second argument of `eventSourceApp', namely `req'
In the second argument of `($)', namely `eventSourceApp chan req'
In a stmt of a 'do' expression:
res <- lift $ eventSourceApp chan req
I am on OS X Snow Leopard and cleared up (everything?) except the Haskell Platform like this:
rm -r ~/.cabal
rm -r ~/.ghc
rm -r ~/Library/Haskell
and installed yesod and wai-eventsource anew from hackage.
As far as I understand the error comes from a dependency problem.
wai
Synopsis: Web Application Interface.
Default available version: 1.0.0
Installed versions: 0.4.3, 1.0.0
Homepage: https://github.com/yesodweb/wai
License: BSD3
Where yesod-0.9.4.1 requires wai == 0.4.* and wai-eventsource-1.0.0 requires wai >= 1.0.
So, my question would be: Is it possible to get this example (with the official releases of yesod) to work right now? With all the change the yesod project is going through atm?
Do I have to be more precise on the versions I try to install and, if so, how?
Edit:
I wiped out ~/.ghc (or actually followed a more rigorous approach given here, just in case) and tried to install the packages with a single
cabal install yesod wai-eventsource resulting in (incomplete):
Resolving dependencies...
cabal: cannot configure yesod-0.9.4.1. It requires wai ==0.4.* and warp ==0.4.*
For the dependency on wai ==0.4.* there are these packages: wai-0.4.0,
wai-0.4.1, wai-0.4.2 and wai-0.4.3. However none of them are available.
wai-0.4.0 was excluded because wai-eventsource-1.0.0 requires wai >=1.0
...
wai-0.4.3 was excluded because wai-eventsource-1.0.0 requires wai >=1.0
For the dependency on warp ==0.4.* there are these packages: warp-0.4.0,
warp-0.4.0.1, warp-0.4.1, warp-0.4.1.1, warp-0.4.1.2, warp-0.4.2, warp-0.4.3,
warp-0.4.3.1, warp-0.4.4, warp-0.4.5, warp-0.4.6, warp-0.4.6.1, warp-0.4.6.2
and warp-0.4.6.3. However none of them are available.
warp-0.4.0 was excluded because wai-eventsource-1.0.0 requires warp >=1.0
...
warp-0.4.6.3 was excluded because wai-eventsource-1.0.0 requires warp >=1.0
Before that (with yesod and wai-eventsource installed separately) I tried ghc -hide-package wai-1.0.0 Chat.hs resulting in,
Chat.hs:77:39:
Couldn't match expected type `wai-1.0.0:Network.Wai.Request'
with actual type `Network.Wai.Request'
In the second argument of `eventSourceApp', namely `req'
In the second argument of `($)', namely `eventSourceApp chan req'
In a stmt of a 'do' expression:
res <- lift $ eventSourceApp chan req
I think you need to unregister (or hide) wai 1.0.0. The current Yesod is using wai 0.4, which is where the mismatch is coming from. (Once a newer Yesod is released, this problem will disappear.)
Alternatively, you could wipe out your ~/.ghc folder again and run cabal install yesod wai-eventsource, which should automatically install only the compatible versions.
Edit: You need to hide wai-eventsource as well, and possibly a few others. And simplest approach is to run ghc-pkg unregister wai-eventsource-1.0.0 --force.