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.
Related
I'm getting an error that says the module doesn't exist when I try to runhaskell. It's odd because I try to install it first and says its up to date. Any idea how to fix this?
You could try creating the package environment in the local directory that holds your project, like this:
c:\Users\...\ex1haskell> cabal install --lib --package-env . QuickCheck
This should create a file of the form .ghc.environment.xxx in ex1haskell, which hopefully should be picked up by runhaskell/ghci/ghc invocations.
In ghci sessions, a sign that the environment is being picked up is the following message while starting:
Loaded package environment from ...
When the --package-env location is not given explicitly, a default location is used. According to the docs:
By default, it is writing to the global environment in
~/.ghc/$ARCH-$OS-$GHCVER/environments/default. v2-install provides the
--package-env flag to control which of these environments is modified.
But it seems that runhaskell is having problems to find the environment file in that default location.
Note. When creating a package environment, it's possible to specify multiple packages simultaneously, like this:
cabal install --lib --package-env . QuickCheck random aeson transformers
Also, package environments are just text files, so local environments can be deleted and recreated at will. The actual package binaries reside elsewhere and can potentially be reused by cabal.
A Common Environment
It is hard to debug if/when the actual tooling differs so let's first get a unified setup. I'll use docker to get GHC 8 and Cabal 3.x:
docker run --rm -it haskell bash
Understand that this isn't arbitrary or even preemptive. What you have shown - cabal install --lib ... and runhaskell ... does work for sane tool installations. You might have a bad installation or an old version of a tool that has different behavior.
Running a single file with runhaskell
Now we need a project:
root#8a934c302dba:/# mkdir Ex1
root#8a934c302dba:/# cd Ex1
root#8a934c302dba:/Ex1# cat <<EOF >Main.hs
> import Test.QuickCheck
>
> main :: IO ()
> main = print =<< (generate arbitrary :: IO Int)
> EOF
And test failure:
root#8a934c302dba:/Ex1# runhaskell Main.hs
Main.hs:1:1: error:
Could not find module `Test.QuickCheck'
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
1 | import Test.QuickCheck
And install the library:
root#8a934c302dba:/Ex1# cabal update && cabal install --lib QuickCheck
And successful run:
root#8a934c302dba:/Ex1# runhaskell Main.hs
15
So my comment above was wrong - we don't need to explicitly list the package as it is already exposed after installation.
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.
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.
I'd like to use Data.HashSet in Haskell. So I put import Data.HashSet at the beginning of my program. GHCi complains: Could not find module Data.HashSet.
My questions are:
How can I get Data.HashSet to work?
I've read somewhere that this is part of a hidden module or package. Why is the module hidden? Does "hidden" mean that I should not use it?
If I should not use it, is there a better alternative for a haskell data structure with a near-constant lookup time?
Data.HashSet is a module in the unordered-containers package, and also in the hashmap package. If you have either package installed,
import Data.HashSet
should work out of the box, since it is an exposed module of both packages. To install it (using unordered-containers, since that is the commonly used one),
cabal update
cabal install unordered-containers --dry-run
-- check that it wouldn't reinstall anything, if all's fine
cabal install unordered-containers