November 2008 - Haskell-Cafe

workarounds for Codec.Compression.Zlib errors in darcs
by Eric Kow 01 Dec '08

01 Dec '08

Hi everybody, This advisory is for people who have installed darcs 2.1.2 via the Cabal build method. As you may have noticed, the cabalised darcs sometimes fails with errors like Codec.Compression.Zlib: incorrect data check Why this happens ---------------- Older versions of darcs can to produce gzipped files with broken CRCs. We never noticed this because our homegrown wrapper around the C libz library does not pick up these errors. Lately, we have been working on adopting the Haskell zlib wrapper, which is made available by default in darcs.cabal. This new wrapper is more stringent and fails when it encounters these files. Workaround 1 : use C libz instead of Haskell zlib ------------------------------------------------- So how can you work around these errors? If you are building darcs on any Unix-y operating system (e.g. Linux or MacOS X), you can cabal configure darcs to use the old C libz binding: cabal configure -f external-zlib This will restore our homegrown wrapper which ignores the broken CRCs (note that the darcs head no longer *produces* these broken files, thanks to debugging by Matthias Andree and to a bugfix by David Roundy; http://bugs.darcs.net/issue844 for details). In principle, the same advice applies for Windows users, with more details hopefully to follow on how the C libz in a GHC-accesible location. Details to follow. In the meantime, you can either build darcs using the old configure and make technique (assuming you have MSYS and related tools), or use a binary that does not use the Haskell zlib wrapper (for example, by downgrading to http://www.haskell.org/~simonmar/darcs-2.0.2+75.zip ) Workaround 2 : fix your broken gzipped files -------------------------------------------- If you have control over the repositories with broken gzipped files, it should be possible to repair these files by gunzipping them and then redo-ing the gzip. We think that the attached script should help. Please report back if this is not the case. How we will fix this problem in the long term --------------------------------------------- I'm very sorry for the grief this has caused. To begin with, we will ensure that the 2.2 release gets more testing before releasing it in January. It will also handle these broken CRCs more gracefully. Our plan is to - either extend darcs repair or provide a Haskell script to fix these broken files - detect the broken files and advise users to run darcs repair (or the script) as needed - somewhere in the future, disallow broken CRC files whilst still advising users on how to fix their files. Many thanks! -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9

10 15

Problem with directory-1.0.0.0
by Bartosz Wójcik 01 Dec '08

01 Dec '08

Hi Folks, I'm facing problem after I've reinstalled directory-1.0.0.0 (setup configure/build/install). Since then I cannot complie anything that needs this library. It fails with following messages: Preprocessing library haddock-2.4.0... Preprocessing executables for haddock-2.4.0... Building haddock-2.4.0... /usr/bin/ar: creating dist/build/libHShaddock-2.4.0.a Linking dist/build/haddock/haddock ... /usr/local/lib/ghc-6.8.2/libHSghc.a(Coverage.o): In function `scXR_info': (.text+0x17b7c): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_lvl29_closure' /usr/local/lib/ghc-6.8.2/libHSghc.a(Coverage.o): In function `s8xU_info': (.text+0x1792c): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a43_info' /usr/local/lib/ghc-6.8.2/libHSghc.a(Coverage.o): In function `r7aC_closure': (.data+0xd18): undefined reference to `directoryzm1zi0zi0zi0_SystemziDirectory_a43_closure' collect2: ld returned 1 exit status Situation is following: Old directory-1.0.0.0 resides in /usr/local/lib/ghc-6.8.2/lib/directory-1.0.0.0. New one in /usr/local/lib/directory-1.0.0.0. Why new one doesn't work? How to force linker to use old one? Best, Bartek

2 2

getLine and ^C on Windows
by Lyle Kopnicky 01 Dec '08

01 Dec '08

Hi folks, I'm using System.IO.getLine to read input in my program. I've compiled it on Windows Vista with ghc-6.10.1. I've noticed that if I press Ctrl+C while the program is waiting for input, it will get stuck. No keypresses can get me out of the program - I have to kill the shell. I've tried cmd.exe, Powershell and cygwin - same behavior. I'm sure editline would work better, but it's overkill. I just want to read lines of text and don't need fancy edit behavior. And I think editline complicates the build process. I also want my program to work right in non-interactive mode, reading redirected input. Am I missing something? Thanks, Lyle

4 3

catting to cat gets stuck at > 135K
by Jason Dusek 01 Dec '08

01 Dec '08

I've put together a simple test case for a rather annoying problem. I've got a program that drives other programs. For example, it can drive `cat`: :; Simple cat a-file When the file is a little bit greater than 135060 bytes, this program fails to produce any output at all -- I need to use ^C to get my console back. I have a similar program that encounters the same issue a little after 139192 bytes. The inconsistency is one baffling feature of this bug. If I remove the `hClose`, the example program just hangs, no matter the size of the input. It is entirely possible that I have overlooked some subtle feature of pipe semantics -- indeed, I hope that is the case. -- _jsn import Data.ByteString.Lazy import System.Process import System.Environment import System.IO (hClose) import Prelude hiding (writeFile, readFile) main = do exe:file:_ <- getArgs bytes <- readFile file foo <- simple exe bytes [] writeFile (file ++ ".foo") foo -- Manufactures a simple stream handler from a command line utility. simple :: String -> ByteString -> [String] -> IO ByteString simple exe bytes args = do (i, o, e, p) <- runInteractiveProcess exe args Nothing Nothing hPut i bytes s <- hGetContents o hClose i return s

7 13

Re: [Haskell-cafe] Cabal
by Henning Thielemann 01 Dec '08

01 Dec '08

On Sun, 30 Nov 2008, Don Stewart wrote: > lemming: >> >> Maybe you like to add a pointer in cabal-install.cabal/Homepage field to >> this page. > > Good idea. Duncan? After I finished that article, I also found: http://hackage.haskell.org/trac/hackage/wiki/CabalInstall

2 2

Instances that shouldn't overlap
by Paul Johnson 30 Nov '08

30 Nov '08

Hi, I'm trying to set up some operators for applicative versions of prelude types. For instance: -- | Applicative Equality. class (Eq a) => AppEq f a where (.==.), (./=.) :: f a -> f a -> f Bool instance (Applicative f, Eq a) => AppEq f a where (.==.) = liftA2 (==) (./=.) = liftA2 (/=) Hopefully the intention is fairly straightforward: if "f" is an instance of Applicative then the lifted implementation of the underlying type. Otherwise I can just give my own instance, which is useful for things that "wrap" prelude types but where "fmap" doesn't work. For instance: data (Ord a) => Interval a = Interval a a instance (Ord a) => AppEq Interval a where i1@(Interval _ u1) .==. i2@(Interval _ u2) | isSingleton i1 && isSingleton i2 && u1 == u2 = Interval True True | has i1 u2 || has i2 u1 = Interval False True | otherwise = Interval False False i1 ./=. i2 = let Interval b1 b2 = (i1 .==. i2) in Interval (not b2) (not b1) isSingleton :: (Ord a) => Interval a -> Bool isSingleton (Interval lower upper) = lower == upper has :: (Ord a) => Interval a -> a -> Bool has (Interval lower upper) v = v >= lower && v <= upper You can't (easily) define fmap for Interval because the function given as an argument might not be monotonic. So instead you have to write custom implementations for each lifted function, as shown here for (.==.) and (./=.) . The same principle works for AppOrd, AppNum etc, but I'm trying to solve the problem for just AppEq for now. This compiles, but when I try to use it I get this in ghci: *Interval> let i1 = Interval 4 5 *Interval> let i2 = Interval 4 6 *Interval> i1 .==. i2 <interactive>:1:0: Overlapping instances for AppEq Interval Integer arising from a use of `.==.' at <interactive>:1:0-9 Matching instances: instance (Ord a) => AppEq Interval a -- Defined at Interval.hs:(22,0)-(27,78) instance (Control.Applicative.Applicative f, Eq a) => AppEq f a -- Defined at AppPrelude.hs:(32,0)-(34,23) In the expression: i1 .==. i2 In the definition of `it': it = i1 .==. i2 I'm puzzled, because Interval is not an instance of Applicative, so the second instance doesn't apply. Can anyone help me out? I'm using ghc 6.8.3, so its possible that this was a bug fixed in 6.10. Paul.

5 5

Permutations
by Andrew Coppin 30 Nov '08

30 Nov '08

OK, so here's something just for fun: Given a list of items, find all possible *unique* permutations of that list. (E.g., the input list is explicitly _allowed_ to contain duplicates. The output list should not contain any duplicate permutations.) I've found one simple way to do this, but I'm sure there are multiple valid approaches. So let's see what people come up with. ;-)

6 13

Re: [Haskell-cafe] Re: Go Haskell! -> array libraries
by Andrew Coppin 30 Nov '08

30 Nov '08

Henning Thielemann wrote: > I suspect that this particular function is less useful than you think. > It safes one allocation and might be faster since it uses less cache, > but on the other hand, it cannot be fused. If the array is "seriously large", you don't want to have five or six versions of it sitting in memory until the GC comes along to remove it. (OTOH, presumably an unboxed array can be allocated or freed quite quickly...) At a minimum, you've going to end up with two copies in memory - the existing one, and the one being built. > I think in-place array > updates are only sensible for writing array elements in really random > order. As long as you can formulate your algorithm the way "read from > random indices, but write a complete array from left to right", there is > almost no need for mutable arrays. > Does quick-sort fit that pattern? (I'm guessing yes, since all you need to do is filtering and merging...) Yeah, generally you only need arrays if you really want random access. Except in Haskell, where an array also happens to be the only way of storing large numbers of values unboxed. So sometimes you'll use an array because you want to save space. (E.g., parsing text is usually a sequential process with no random access, but you probably want to use ByteString all the same!) I sometimes also use unboxed arrays for the increase in strictness. I guess the thing to do would be to measure the difference...

5 5

"Could not find module ... which is hidden" problem
by Belka 30 Nov '08

30 Nov '08

Hello! ----------------------------START---------------------------------- $ sudo runghc Setup configure --user Configuring HCL-1.2... $ sudo runghc Setup build Preprocessing library HCL-1.2... Preprocessing executables for HCL-1.2... Building HCL-1.2... HCL.hs:302:7: Could not find module `System.Random': it is a member of package random-1.0.0.1, which is hidden $ sudo ghc-pkg expose random Saving old package config file... done. Writing new package config file... done. $ sudo runghc Setup configure --user Configuring HCL-1.2... $ sudo runghc Setup build Preprocessing library HCL-1.2... Preprocessing executables for HCL-1.2... Building HCL-1.2... HCL.hs:302:7: Could not find module `System.Random': it is a member of package random-1.0.0.1, which is hidden ---------------------THE-END---------------------------------------- Perhaps, i'm 1000th, who asks how to solve this. Sorry that didn't search better, but it's really tiring for a newby. :-( [ http://www.haskell.org/haskellwiki/Upgrading_packages/Updating_to_GHC_6.8 Here ] found something, which maybe called "a gentle explaination" of what's going on. I have ghc ver: 6.8.2, base ver: 3.0.1.0. So there are 2 questions of mine: (1) Is there any centralized and well organized Haskell Knowledge Base, where it would be much easier to find solutions for "popular" problems? Anybody, please, your recommendations. (2) As for the topic: the only option for me would be obtaining older GHC (base?) - is that correct? So that require me reinstalling every Haskell package I have installed so far? Thanks in advance. -- View this message in context: http://www.nabble.com/%22Could-not-find-module-...-which-is-hidden%22-probl… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

3 3

Data parallelism doesn't seem to work on windows...
by Sebastian Sylvan 29 Nov '08

29 Nov '08

Hi,I can't seem to get DPH to work on 6.10.1 on Vista-64. I run the executables with +RTS -N2, and to verify that I'm doing it correctly I checked with a simple benchmark using forkIO and that does indeed use both my cores: -- compiler command line: ghc --make -O2 -threaded parr.hs -- execution command line: parr.exe +RTS -N2 main = do forkIO $ print [ True | n <- [ 1000 .. 3000], fac n == 0 ] forkIO $ print [ True | n <- [ 1000 .. 3000], fac n == 0 ] getLine return () This, on the other hand does not use more than one core: -- compiler command line (from shootout code): ghc --make -fcpr-off -threaded -fdph-par -package dph-base -Odph -XPArr parr2.hs -- execution as before main = print $ [: True | n <- [: 1000 .. 5000 :], fac n == 0 :] That's 4000 items of work there, so surely it should kick off plenty of sparks to overcome the "sparks bug"? -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862

2 1