Upgrading packages/Updating to GHC 6.10: Difference between revisions
RossPaterson (talk | contribs) (more info on boot packages) |
(document another bytestring API change) |
||
Line 44: | Line 44: | ||
=== Data.ByteString api changes === | === Data.ByteString api changes === | ||
Data.ByteString.packCStringLen is no longer a pure function; its signature has changed from | |||
<haskell>packCStringLen :: Foreign.C.String.CStringLen -> ByteString</haskell> | |||
to | |||
<haskell>packCStringLen :: Foreign.C.String.CStringLen -> IO ByteString</haskell>. | |||
module Data.ByteString.Base has been split into two. The "unsafe" functions moved to Data.ByteString.Unsafe and the others moved into Data.ByteString.Internal. The stable API going forward is all the modules exposed by the bytestring package except for the .Internal modules and the .Fusion module. | module Data.ByteString.Base has been split into two. The "unsafe" functions moved to Data.ByteString.Unsafe and the others moved into Data.ByteString.Internal. The stable API going forward is all the modules exposed by the bytestring package except for the .Internal modules and the .Fusion module. | ||
Line 53: | Line 58: | ||
The crucial difference is that in the latter representation we can unpack the strict bytestring into the <hask>Chunk</hask> constructor which reduces the number of indirections to get at the string data from two to one. | The crucial difference is that in the latter representation we can unpack the strict bytestring into the <hask>Chunk</hask> constructor which reduces the number of indirections to get at the string data from two to one. | ||
<haskell>packCStringLen</haskell> |
Revision as of 20:11, 29 September 2007
A list of things that need updating when porting packages to newer library/cabal versions.
Updating to GHC 6.8 and Cabal 1.2
Cabal configuration support
Cabal API changes
Many packages that use non-default Setup.hs or Setup.lhs files need to be updated as they use Cabal APIs that have changed. In many cases new features in Cabal-1.2 allow these packages to go back to using the default Setup.hs.
A more detailed survey of the packages from the hackage collection is here: http://www.haskell.org/pipermail/libraries/2007-September/008265.html
base package split up
The base package was split up, and new dependencies are now required;
- array: Data.Array and below
- bytestring: Data.ByteString and below
- packedstring: Data.PackedString (deprecated)
- containers: Data.{Graph,IntMap,IntSet,Map,Sequence,Set,Tree}
- random: System.Random
- pretty: Text.PrettyPrint and below
- process: System.Cmd, System.Process and below
- directory: System.Directory
- old-time: System.Time
- old-locale: System.Locale
(dependency graph of the boot libraries)
These boot packages are included with ghc-6.8. If your package imports any of these modules, you need only add the corresponding packages to the build-depends line in your cabal file. However if you want to support both ghc-6.6 and ghc-6.8 you need to use the configurations feature in your .cabal file. For example:
flag splitBase description: Choose the new smaller, split-up base package.
library if flag(splitBase) build-depends: base >= 3, pretty, directory, old-time, process, containers else build-depends: base < 3
This is a simplified excerpt from Cabal's own Cabal.cabal file.
Data.ByteString api changes
Data.ByteString.packCStringLen is no longer a pure function; its signature has changed from
packCStringLen :: Foreign.C.String.CStringLen -> ByteString
to
packCStringLen :: Foreign.C.String.CStringLen -> IO ByteString
module Data.ByteString.Base has been split into two. The "unsafe" functions moved to Data.ByteString.Unsafe and the others moved into Data.ByteString.Internal. The stable API going forward is all the modules exposed by the bytestring package except for the .Internal modules and the .Fusion module.
The lazy bytestring representation type has changed. Instead of a newtyped list:
newtype ByteString = LPS [Strict.ByteString]
it is now:
data ByteString = Empty | Chunk !Strict.ByteString ByteString
The crucial difference is that in the latter representation we can unpack the strict bytestring into the Chunk
constructor which reduces the number of indirections to get at the string data from two to one.
packCStringLen