June 2009 - Libraries

Bug in old-locale?
by Deniz Dogan 11 Jul '09

11 Jul '09

Hi Is there a bug in the old-locale package? I tried the following simple program: import Data.Time import System.Locale main = do time <- getCurrentTime putStrLn $ formatTime defaultTimeLocale rfc822DateFormat time The above program prints: Mon, d Apr 2009 15:23:56 UTC Notice "Mon, d", where "d" should be the day of the month. Looking at the source code in the package, I see: rfc822DateFormat = "%a, %_d %b %Y %H:%M:%S %Z" So what's up with %_d? -- Deniz Dogan

4 6

Adding swap to Data.Tuple
by roconnor＠theorem.ca 10 Jul '09

10 Jul '09

I have a new proposal to add swap and swap' to Data.Tuple http://hackage.haskell.org/trac/ghc/ticket/3298 -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

6 11

exposing hidden packages with runghc
by Iain Barnett 08 Jul '09

08 Jul '09

I'm trying to install HTTP-3000.0.0 (because I don't have cabal-install, and it's a dependency for cabal-install 0.4.9) This is on a Debian 5.1 machine with GHC 6.8.2 and 6.8.3 on it. The command: sudo runghc Setup configure -p && sudo runghc Setup build && sudo runghc Setup install The error: Could not find module `Data.Array.MArray': it is a member of package array-0.1.0.0, which is hidden ghc-pkg does list the hidden package. I've seen other threads on this "hiding" problem and searched through the GHC user guide, but I haven't actually found a solution, just explanation. I've tried sending the -package flag through to GHC by adding it to the runghc command, but I'm not doing this right, obviously. Would someone be able to point me in the right direction? It would be much appreciated. Iain

4 10

base library and GHC 6.12
by Ian Lynagh 01 Jul '09

01 Jul '09

Hi all, There has been some discussion recently about the base library. In particular, base is supposed to follow the PvP, which means that certain sorts of changes require increasing the version number. When the version number is increased, this makes work for lots of people, as any packages correctly using an upper bound on base's version number need to be updated. For modules like Data.List this makes sense, but base also contains a number of modules in the GHC.* hierarchy which, while exposed, are really internal, and much less stable than the "public" API. There is also another issue: Currently, it is not possible for a package to specify, in its dependencies, whether or not it uses these GHC.* modules. We therefore can't easily tell whether a package is sensitive to changes in those modules, or whether it can be used with hugs, nhc98, etc. We've come up with 3 possible ways forward. Comments, suggestions and criticisms welcomed! Option 1 -------- In order to solve the version number issue, we could simply state that "base follows the PvP, but only for shared module hierarchies". However, it would be impossible for packages which /do/ need GHC.* modules to give accurately versioned dependencies, and it wouldn't solve the other issue at all. Option 2 -------- Another possible solution would be to rename the base package to base-internals, and to make base only re-export the "public" modules. This would require either renaming each module M to Internal.M, or for every implementation to support something like GHC's PackageImports extension. Option 3 -------- The other alternative is to try to split base into two parts: The shared "public" modules, and the internal GHC.* modules. Then GHC would have ghc-base, hugs would have hugs-base, etc, and there would be a common base package built on top of the appropriate impl-base. To do this with minimal loss of code sharing is a large task, and hard to just do in a branch, as merging changes made in the base HEAD is a pain when the file the patch applies to has moved to another repository. Thus in the short term we would expect to give up a reasonable amount of code sharing, but we hope that once we have separate impl-base packages it will be easier to untangle their contents (as impl-base will be significantly smaller than base currently is, and because we can rearrange imports and code inside impl-base without having to worry about breaking other implementations), and then regain as much sharing as possible. I've had a look at what can be done, and the first cut looks like this: We start off with 143 modules in base, 89 of which are public and 54 of which are GHC.*. Afterwards, base has 53 modules, 2 of which are GHC.*: * GHC.Exts, which could be moved into ghc-base, but would take Data.String with it, or it could go into a ghc-exts package. As this is "more public" than the other GHC.* modules, this seems like a reasonable thing to do anyway * GHC.Desugar, which could be put into its own package if nothing else Here's the module graph, which looks quite sane: http://community.haskell.org/~igloo/base-small.png That leaves 90 modules in ghc-base, 52 of which are GHC.*, and 38 of which are in the portable namespace. So almost all GHC.* modules have moved, and more than half of the portable modules are in base. These 38 are the interesting ones: Control.Exception.Base Control.Monad Data.Bits Data.Char Data.Dynamic Data.Either Data.HashTable Data.Int Data.List Data.Maybe Data.Tuple Data.Typeable Data.Word Foreign Foreign.C Foreign.C.Error Foreign.C.String Foreign.C.Types Foreign.ForeignPtr Foreign.Marshal Foreign.Marshal.Alloc Foreign.Marshal.Array Foreign.Marshal.Error Foreign.Marshal.Pool Foreign.Marshal.Utils Foreign.Ptr Foreign.StablePtr Foreign.Storable Numeric System.IO.Error System.IO.Unsafe System.Posix.Internals System.Posix.Types Text.ParserCombinators.ReadP Text.ParserCombinators.ReadPrec Text.Read.Lex Text.Show Unsafe.Coerce Some of them are easy to move back into base, e.g. Foreign contains no code, and Numeric is only needed so that GHC.Ptr can use showHex for its Show instance. Some are more integral to the implementation of the rest of GHC.*. I've only tried this for amd64/Linux, so it's possible that dependencies on other platforms could cause additional problems. Here's the module graph, which is somewhat messier than base's: http://community.haskell.org/~igloo/ghc-base-small.png As with option 2, for each implementation, either impl-base needs to rename the public modules M to Impl.M, or it needs to implement something like GHC's PackageImports extension. Thanks Ian

9 14

zlib and dependencies in general
by Iain Barnett 30 Jun '09

30 Jun '09

I've been trying to build zlib (any version) onto a Debian 5.1 machine, and had a few problems. I've solved these now, but one of them was a dependence on not only zlibc/zlib1g as you'd expect, but zlib1g-dev as well, and wasn't actually in any of the error messages. I ended up relying on a solution given for a similar problem with mySQL installation. I noticed that Hackage only lists Haskell library dependencies - might it be an idea to list other non-Haskell ones, too? cabal-install won't install without zlib, so there's no ease of installation to rely on, and not everyone would have found/read the mySQL post. Just a thought. Iain

3 6

Bug in Data.LargeWord
by Dominic Steinitz 29 Jun '09

29 Jun '09

Someone sent me a bug report for this. Unfortunately, my email has not worked since 9 June so it is lost. Did anyone see it? Could the poster resend? Many thanks, Dominic.

1 0

BerkeleyDBXML linking problems.
by Sebastiaan Visser 27 Jun '09

27 Jun '09

Hello all, After manually specifying where to find the appropriate include and library directories for the dbxml distribution, I succeeded to install both the BerkeleyDB and the BerkeleyDBXML Haskell bindings. They both nicely show up in `ghc-pkg list'. But when I try to compile my own test or the demo program included in the BerkeleyDBXML package it will kindly present me a dozen or so pages of linking errors. The top lines are: Undefined symbols: "std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_M_destroy(std::allocator<char> const&)", referenced from: __xmlDocument_setContent in libHSBerkeleyDBXML-0.6.2.a(dbxml_helper.o) ... Do I have to tell GHC where to find the original dbxml libraries when compiling my BerkeleyDBXML aware Haskell programs? Small system overview: - Mac OS X 10.5.7 - GHC 6.10.3 - BerkeleyDB 0.7.1 - BerkeleyDBXML 0.6.2 - gcc/g++ 4.0.1 Any clue on how to fix this? Thanks, -- Sebastiaan Visser

2 1

Revamping the module hierarchy (was: ANNOUNCE: OpenGLRaw 1.0.0.0)
by Johan Tibell 25 Jun '09

25 Jun '09

All, On Fri, Jun 12, 2009 at 11:24 AM, Sven Panne <Sven.Panne(a)aedion.de> wrote: > One point here is debatable: Do we really need the ".Rendering" part in the > package name or would simply "Graphics.OpenGL.Raw" be enough? We discussed > the > structure of the hierarchy when hierarchical packages were in their > infancy, > many years ago, and it was consensus then to distinguish between > "Graphics.Rendering" and "Graphics.UI". I don't have very strong feelings > about ".Rendering" and ".UI", and if the consensus nowadays is to remove > it, > I'll be happy to change this. But let's move the discussion about this to > the > libraries mailing list. > Perhaps it's time to overhaul the hierarchy. Some top level module namespaces like Network have become very crowded. Network is a very generic name that it conveys very little information today when most software has a network component. I suggest that parts of it be broken out into new top level modules. As a first step I suggest we create a new Http (and not HTTP with all caps please) module where we can have: Http.Client Http.Server Http.UrlEncoding Http.Cookies etc. Cheers, Johan

12 17

darcs patch: Fix detection of libiconf.
by Matthias Kilian 24 Jun '09

24 Jun '09

Sat Jun 20 14:21:59 CEST 2009 Matthias Kilian <kili(a)outback.escape.de> * Fix detection of libiconf. It's not enough to try to link against libiconv and look for a symbol iconv_open, because iconv may be installed in a way that internally renames iconv_foo to libiconv_foo in the library and adds corresponding #define iconv_foo libiconv_foo to iconv.h. This patch is needed on OpenBSD (but it's not enough, since cabal suffers from the same problem).

3 13

Proposal: Add Foldable and Traversable instances for ((,) a)
by Yitzchak Gale 23 Jun '09

23 Jun '09

These instances are pretty obvious, and no more or less trivial than the existing instances for Prelude types. I have found them to be useful. > instance Foldable ((,) a) where > foldMap f (_, y) = f y > foldr f z (_, y) = f y z > foldl f z (_, y) = f z y > foldr1 _ (_, y) = y > foldl1 _ (_, y) = y > instance Traversable ((,) a) where > traverse f (x, y) = (,) x <$> f y In the spirit of the world's finest legislative bodies, I am attaching two unrelated amendments to this proposal. One amendment is to add a few additional explicit method implementations in the Foldable and Traversable instances for Prelude types. These might sometimes be slightly more efficient, and they better match the strictness and style of the existing explicit method implementations. For lists: > sequence = Control.Monad.sequence For Maybe: > foldMap _ Nothing = mempty > foldMap f (Just x) = f x > foldr1 _ Nothing = error "foldr1 of Nothing" > foldr1 _ (Just x) = x > foldl1 _ Nothing = error "foldl1 of Nothing" > foldl1 _ (Just x) = x For arrays: > foldl f z = Prelude.foldl f z . elems > foldr1 f = Prelude.foldr1 f . elems > foldl1 f = Prelude.foldl1 f . elems The other amendment is to fix the documentation for the functions fmapDefault and foldMapDefault in Data.Traversable. Contrary to what is stated, these cannot be used as methods in superclasses, since the superclasses must already exist before these functions can be defined. Instead, I have paraphrased what is stated in the documentation above: that the corresponding superclass methods should be equivalent to these. http://hackage.haskell.org/trac/ghc/ticket/3324 Discussion period: two weeks.

2 3