0

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?

duplode
  • 33,731
  • 7
  • 79
  • 150
Thomas Vanhelden
  • 879
  • 8
  • 20

1 Answers1

3

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.

Community
  • 1
  • 1
duplode
  • 33,731
  • 7
  • 79
  • 150
  • 1
    Upgrading GHC seems like overkill. Why not give instructions for building using the user package database (which already has an appropriate version of bytestring available) instead? – Daniel Wagner Dec 11 '16 at 03:03
  • @DanielWagner Perhaps I'm missing something, but wouldn't that require rebuilding all installed packages that depend on *bytestring* (which includes *binary* and *unix* in the global database, as well as a large chunk of the user database)? – duplode Dec 11 '16 at 03:28
  • Yes, and managing that build work is what cabal was invented for. – Daniel Wagner Dec 11 '16 at 03:33
  • @DanielWagner When using *cabal-install*, I generally assumed that, in order to avoid diamond dependency headaches, it was best to not update the core, globally installed packages. Distancing myself from my assumptions, I can see how overriding the default choices of package databases, [perhaps as in this Q&A](http://stackoverflow.com/q/30685248/2751851), might be a feasible solution. Would you consider adding an alternative answer? (I guess you would be able to explain the relevant workflow better than me.) – duplode Dec 11 '16 at 04:05
  • 1
    I plan to write such an answer, but writing it well requires a few more details in the question (which I have asked about in a comment). – Daniel Wagner Dec 11 '16 at 20:16