- Libraries - Haskell.org

Cabal, list of include files or directories
by Maurício CA 10 Dec '09

10 Dec '09

Hi, I would like to check for a few include files, and read them, in my Setup file. However, the only structure where I can find info about include files seems to be BuildInfo, and this could only come from HookedBuildInfo in preConf and confHook. Both, however, give empty HookedBuildInfos. Thanks, Maurício

1 0

Checking dependencies with Distribution
by Maurício CA 10 Dec '09

10 Dec '09

Hi, Can you help me understand how to check C library dependencies using Distribution.*? So far, reading Setup.hs from HDBC-mysql gave me a quick start. I believe what I need to do is to write a 'preConf' user hook. This preConf would probably mimic the behavior of autoconf macros provided by the library. Say, if that macro opens an include file and checks a string to confirm the version, that is what my preConf should do. But then I'm lost. Although my preConf probably doesn't need to add any information to the build process, I can't find how to actually break it if the proper version wasn't found, or how to emit a message saying "you need a newer version of library X". Thanks, Maurício

2 1

Re: [GHC] #3709: Data.Either.partitionEithers is not lazy enough
by Malcolm Wallace 04 Dec '09

04 Dec '09

> #3709: Data.Either.partitionEithers is not lazy enough > > This is a behavioural change, e.g.: > Main> case partitionEithers1 [Left 'a', error "Not me"] of (x : _, > _) -> x > Program error: Not me > Main> case partitionEithers2 [Left 'a', error "Not me"] of (x : _, > _) -> x > 'a' Yes, and isn't that the point of the bugfix? No non-bottoming program has changed, but fewer programs fail now. I find it hard to imagine that anyone could have been relying on getting a crash here. > Shouldn't it be discussed on the libraries list first? Possibly, although I believe we have never treated a change towards being more lazy as an API change before. Making something more strict usually provokes discussion, because it causes more programs to crash, but making things lazier is usually considered a bugfix. Copying to libraries@, to see if there are any objections. If there are, feel free to back out the patch. -> See http://hackage.haskell.org/trac/ghc/ticket/3709 Regards, Malcolm

5 5

HaXR, maintainer
by Gracjan Polak 02 Dec '09

02 Dec '09

Hi libraries! There is a beautiful HaXR XML-RPC client and server library out there that I use in connection with BlogLiteratively. I needed to change HaXR a bit to support my language encoding (Polish). http://hackage.haskell.org/package/haxr If nobody else steps up I'd like to take maintainership of HaXR. I have preliminary encouragement from Sigbjorn Finne, the original author. So, let the patches flow to me! -- Gracjan

1 1

Patches and forks for GHC 6.12
by Robin Green 02 Dec '09

02 Dec '09

Some packages will need modifications to build or work with GHC 6.12 (in some cases, just modifications to the .cabal file). I've created this wiki page to track work people have done on that which hasn't yet been included into official packages or repositories: http://haskell.org/haskellwiki/Patches_and_forks_for_GHC_6.12 Please add any ones you know of (or just email me and I'll add them for you). -- Robin

1 0

MTL vs Transformers. Any status update?
by Erik de Castro Lopo 01 Dec '09

01 Dec '09

HI all, Has any progress been made on this? There are a couple of things I would like to package for Debian (also use myself of cource) and they can't progress until the current mess of mtl vs transformers has been sorted out. Is there anything I can do to progress this? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

11 23

Guarantees regarding finalizers
by Mietek Bąk 01 Dec '09

01 Dec '09

Hello, I'm writing a binding to a C library, which requires an explicit cleanup call before program termination. While looking for a way to automatize this, I noticed a discrepancy in the standard library documentation. The Foreign.Concurrent documentation states: "The only guarantee is that the finalizer runs before the program terminates." (http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-Concurre…) On the other hand, the Foreign.ForeignPtr documentation states: "Indeed, there is no guarantee that the finalizer is executed at all; a program may exit with finalizers outstanding." (http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-ForeignP…) Note that Foreign.Concurrent.newForeignPtr is implemented in GHC as GHC.ForeignPtr.newConcForeignPtr. The newConcForeignPtr comments also state: "There is no guarantee of promptness, and in fact there is no guarantee that the finalizer will eventually run at all." (http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-ForeignP…) As much as I would like the Foreign.Concurrent guarantee to be true, this seems to me like a documentation bug. Best regards, -- Mietek Bąk

2 3

[network] new tickets submission unavailable
by Valery V. Vorotyntsev 01 Dec '09

01 Dec '09

> Example in the haddock documentation for `getAddrInfo' function is > rendered incorrectly And what's the purpose of issue tracking system, which even _registered_ user cannot create a ticket for? http://trac.haskell.org/network/wiki "What the bug?" -- vvv

3 4

[network] getAddrInfo: invalid haddock (+ patch)
by Valery V. Vorotyntsev 30 Nov '09

30 Nov '09

Example in the haddock documentation for `getAddrInfo' function is rendered incorrectly: http://is.gd/57LgX -----BEGIN PATCH----- --- Network/Socket.hsc.orig 2009-11-30 15:08:57.869477201 +0200 +++ Network/Socket.hsc 2009-11-30 15:08:28.328452505 +0200 @@ -1972,9 +1972,10 @@ -- to make partial application easier. -- -- Example: +-- -- @ -- let hints = defaultHints { addrFlags = [AI_ADDRCONFIG, AI_CANONNAME] } --- addrs <- getAddrInfo (Just hints) (Just "www.haskell.org") (Just "http") +-- addrs <- getAddrInfo (Just hints) (Just \"www.haskell.org\") (Just \"http\") -- let addr = head addrs -- sock <- socket (addrFamily addr) (addrSocketType addr) (addrProtocol addr) -- connect sock (addrAddress addr) -----END PATCH----- -- vvv

1 0

GHC 6.12 + zlib + Mac OS 10.6
by Antoine Latter 30 Nov '09

30 Nov '09

Hello folks, Everything has been going beautifully with the latest versions of GHC 6.12, except that anything involving zlib dies at run-time. In ghci: > :m Codec.Compression.Zlib > :m +Data.ByteString.Lazy.Char8 > :s -XOverloadedStrings > compress "hello" *** Exception: user error (Codec.Compression.Zlib: incompatible zlib version) I'm running OS X 10.6 on a 64-bit machine. I've heard of folks running into this with GHC 6.10 on OS X 10.6, who got rid of it by removing mac-ports. I tried that and it didn't change anything. My mac-ports install should have all been universal binaries anyway. I imagine I'm somehow building against a 64-bit version of the zlib library, but I'm not sure at what step I'm supposed to do things different, or what precisely I'm supposed to do different. Thanks, Antoine

6 12