Data.ByteString.Char8 does not export stripSuffix - haskell

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.

Related

Why is GHC not importing Semigroup ((<>))

I've been given code by my lecturer that doesn't build in GHCI. As far as I know, it has been building correctly for my classmates.
The code I'm refering to is
import Data.Semigroup (Semigroup ((<>)))
GHCI is throwing this error at me
Module ‘Data.Semigroup’ does not export ‘Semigroup((<>))’
Should this work? Is there perhaps something wrong with my version of GHC? All other import statements are working.
Final Edit
Is there perhaps something wrong with my version of GHC?
Absolutely yes, there is something wrong, is too old, to be precise:
GHC-6.12 / base-4.2 (from 2010, which is the time of the Semigroup package) -- thanks so much #leftaroundabout and #Thomas M. DuBuisson for the contribution!
And that package has not the (Semigroup ((<>))) function. Hence the error you see.
Edit 2
After comments, I tried to reproduce the OP environment to reproduce the error too, I installed in stack the ghc version 7.10.3, this is how looks the stack.yaml file:
resolver: lts-6.27
system-ghc: false
packages:
- .
And after ruining a base stack project with a Main.hs file containing:
module Main where
import Data.Semigroup
main :: IO ()
main = do
putStrLn "Hello"
putStrLn "World"
the error I got is
/home/damian/test-semigroup/app/Main.hs:3:8:
Could not find module ‘Data.Semigroup’
Use -v to see a list of the files searched for.
-- While building package test-semigroup-0.1.0.0 using:
/home/damian/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_1.22.5.0_ghc-7.10.3 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.5.0 build lib:test-semigroup exe:test-semigroup-exe --ghc-options ""
Process exited with code: ExitFailure 1
The same happend with older versions:
LTS 3.22 for ghc-7.10.2,
I couldt try with:
LTS 2.22 for ghc-7.8.4, published 4 years ago
Because they where to old to run with cabal
and
- LTS 0.7 for ghc-7.8.3, published 5 years ago
Because they I cannot install it in a 64bit OS...
So, to be absolutely sure I tried with all the newer LTS versions one by one, yes... one by one, It took some time but worth the shot:
LTS 13.29 for ghc-8.6.5, published today
LTS 13.19 for ghc-8.6.4, published 3 months ago
LTS 13.11 for ghc-8.6.3, published 4 months ago
LTS 12.26 for ghc-8.4.4, published 7 months ago
LTS 12.14 for ghc-8.4.3, published 9 months ago
LTS 11.22 for ghc-8.2.2, published 11 months ago
LTS 9.21 for ghc-8.0.2, published a year ago
LTS 7.24 for ghc-8.0.1, published 2 years ago
None of those ghc version could reproduce your log error, so I thought to try a typo maybe:
import Data.Semigroup (Semigroup ((<$>)))
or
import Data.Semigroup (Semigroup ((=>>)))
And those gave me your error:
/home/damian/test-semigroup/app/Main.hs:3:24: error:
Module ‘Data.Semigroup’ does not export ‘Semigroup(())’
That means, that the Data.Semigroup module exists in your ghc
Semigroup((<>)) is not part of that module
Meaning, you must have one of the oldest ghc versions...
So, I just can think that you can try:
Reinstall your ghc, and try it to run it again.
Please, consider using some tool such as stack
Check your code, look out for some typos or something odd
I stand that my first answer was close though:
Edit 1
It has been added in ghc version 8.0.1
A quick search in hoogle always helps:
Here first link is semigroup <>, (<>) :: Semigroup a => a -> a -> a
and it says:
This versions is able since May 2016, and it ghc version is 8.0.1.
To see all versions of ghc with its base versions:
https://wiki.haskell.org/Base_package
ThomasM.DuBuisson found what must have been the problem (discussion in comments): there are three different packages defining a Data.Semigroup module –
base. As of GHC-8, Haskell ships with the semigroup class and -module out of the box, so you don't need to take care for anything. See Damian Lattenero's answer for details.
semigroups. In GHC-7, there was no semigroups class in base but the semigroups package was semi-official part of the base libraries. In fact, this exact module was just copied over to base. The way to write really backwards-compatible code with semigroups is still to depend on the semigroups package: when compiling against new GHC versions, that package just uses the base module, only in old versions does it provide the module itself. See the .cabal configuration
if impl(ghc < 7.11.20151002)
-- starting with GHC 8 these modules are provided by `base`
hs-source-dirs: src-ghc7
exposed-modules:
Data.Semigroup
Data.List.NonEmpty
Semigroup is an obsolete package back from 2010. It too exports a Data.Semigroup module, but unlike the semigroups one this is not compatible with the official base module. It does have a Semigroups class, but its method is called .++. rather than <> (probably, to not clash with the operator from Data.Monoid – that is by now not an issue, because in very new versions <> is now in the prelude and already works on semigroups).
So, what happened for you is probably the following:
You tried to compile your code
GHC complained Could not find module ‘Data.Semigroup’. That's because you're running an old compiler.
At this point, what you should have done would be installing/depending on the semigroups package. Instead you installed the Semigroup package, which is unfortunately incompatible.
There are two solutions:
Use Cabal-install and allow for your old compiler. IMO this is ok, though you should be prepared to run into other dependency troubles in the future. If you do this, you need to add the semigroups package in the build-depends of your .cabal file.
Or use Stack to enforce a recent compiler. Select e.g. lts-12.14.

Encountering error while adding MaybeT dependency in stack project

I am following this tutorial webScraper using HXT.
I am using Stack here.
While adding dependency for MaybeT, it asked to:
Recommended action: try adding the following to your extra-deps in /Users/***/Haskell Development/Scraper/stack.yaml:
MaybeT-0.1.2
Now doing so to ended up with this message on running stack build:
In the dependencies for MaybeT-0.1.2:
base-4.9.0.0 must match <4.8 (latest applicable is 4.7.0.2)
needed due to Scraper-0.1.0.0 -> MaybeT-0.1.2
Being new to Stack, I am unable to solve the problem, in my cabal file the
the dependency:
build-depends: base >= 4.7 && < 5
, hxt
, url
, HTTP
, MaybeT
In stack.yaml
resolver: lts-7.12
extra-deps: [MaybeT-0.1.2]
What is it that I have missed. How can I solve this?
The solution for your concrete problem is switching from the outdated MaybeT package to the MaybeT transformer offered by the transformers package in Control.Monad.Trans.Maybe.
That said, note that the version mismatch involves base. If you actually needed to use the MaybeT package, you would have to switch the Stack resolver to a snapshot such as lts-6.26, which uses base-4.8 or below (i.e. GHC 7.10.3 or below). base versions are coupled to GHC versions, and everything else depends on base, so there is no easy way of switching just base to an older version, as it might be possible, given some luck, with other packages.

Type mismatch after cabal update?

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.

Snap: Params type error

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.

Yesod wai-eventsource example. Package dependency issue?

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.

Resources