November 2011 - Haskell-Cafe

Poll: Do you want a mascot?
by heathmatlock 01 Dec '11

01 Dec '11

Question: Do you want a mascot? Answers: Yes No -- This is an attempt to figure out if this idea is going anywhere.

26 30

Haskell Platform 64 bit
by Philippe Sismondi 30 Nov '11

30 Nov '11

I just tried to install the Haskell Platform 64-bit on OS X Snow Leopard 10.6.8. The install fails with "an error". This is all I see in /var/log/install.log: 11-11-25 6:22:01 PM Installer[53992] The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance. Is it known to be broken? I find something in haskell-cafe archives from last spring about a such a problem, but I don't know where to look for anything more recent. I may be blind, but I cannot see anything in the tickets under "known problems". I have been successfully running the 32-bit version for quite a while, but have begun to run into problems with linking haskell stuff against various 64-bit macports libraries. - Phil -

3 3

Re: [Haskell-cafe] containers-deepseq?
by John Lato 29 Nov '11

29 Nov '11

> Message: 22 > Date: Tue, 29 Nov 2011 12:18:41 +0200 > From: Michael Snoyman <michael(a)snoyman.com> > Subject: Re: [Haskell-cafe] containers-deepseq? > > By the way, this is the part of situation that cabal-src is coming to > solve, and it *is* solved... except that the result is a lot of > re-compiling. How is cabal-src different from cabal-dev? John

2 1

minor refactoring problem
by Martin DeMello 29 Nov '11

29 Nov '11

I have the following functions: makePair :: (String, String) -> IO PairBox parseFile :: String -> [(String, String)] importFile :: Editor -> String -> IO () importFile ed path = do s <- readFile path ps <- mapM (\x -> makePair (x, "")) (lines s) es <- return $ V.fromList ps writeIORef ed es loadFile :: Editor -> String -> IO () loadFile ed path = do s <- readFile path ps <- mapM makePair (parseFile s) es <- return $ V.fromList ps writeIORef ed es The problem is that loadFile and importFile are so similar it seems a shame not to combine them somehow, but anything I can think of doing leaves the code looking more rather than less messy. Any nice ideas? martin

4 6

Re: [Haskell-cafe] minor refactoring problem
by Martin DeMello 29 Nov '11

29 Nov '11

On Tue, Nov 29, 2011 at 2:54 AM, Martin DeMello <martindemello(a)gmail.com> wrote: > On Tue, Nov 29, 2011 at 2:29 AM, Holger Siegel <holgersiegel74(a)yahoo.de> wrote: >> >> fromRawFile, fromSavedFile :: String -> IO [PairBox] >> fromRawFile = mapM (\x -> makePair (x, "")) . lines >> fromSavedFile = mapM makePair . parseFile >> >> setEditor :: Editor -> [PairBox] -> IO () >> setEditor ed = writeIORef ed . V.fromList >> >> importFile, loadFile :: Editor -> String -> IO () >> importFile ed = readfile >=> fromRawFile >=> setEditor >> loadFile ed = readfile >=> fromSavedFile >=> setEditor > > Wow, very nice! First time I've truly grasped what >=> is good for. > I'll need to go see where else I can use it in my code. Quick question: what's the difference between importFile ed = readfile >=> fromRawFile >=> setEditor ed and importFile = readfile >=> fromRawFile >=> setEditor that the former compiles but the latter doesn't? martin > > martin >

2 1

containers-deepseq?
by Michael Snoyman 29 Nov '11

29 Nov '11

Hi all, Since the release of deepseq 1.2, we've had a bit of a problem: when using the newest versions of packages on Hackage, there is no NFData instance available for the containers types. When GHC 7.4 comes out with its newer version of containers, this will be addressed, but we'll still have problems for users of older GHC releases. I'd like to suggest a solution: a new package called containers-deepseq. Using conditional compilation, it will provide an orphans NFData instance for all containers types when deepseq >= 1.2 and containers < 0.5. Packages (e.g., aeson) would then depend on containers-deepseq and simply import the module whenever they rely on the NFData instances. When GHC 7.4 comes out, the package will essentially be a no-op. Does this make sense? Michael

2 5

Overloaded Strings as default
by Daniel Díaz Casanueva 29 Nov '11

29 Nov '11

Hi Cafe, I only feel curious about what would be the consequences of becoming the Overloaded Strings feature (currently, an extension) to be default in Haskell. This is not a proposal. I just want to know what pros and cons there are. Thanks!

3 2

(no subject)
by Willem Obbens 29 Nov '11

29 Nov '11

Hello, I get this error when I try to derive an instance of the Show typeclass: Abc.hs:21:60: Couldn't match expected type `Vector' with actual type `[Point]' In the first argument of `show'', namely `xs' In the second argument of `(++)', namely `show' xs' In the second argument of `(++)', namely `", " ++ show' xs'Failed, modules loaded: none. Here's the faulty code: newtype Point = Point Intinstance Show Point where show (Point a) = [chr $ a + 48] data Vector = Vector [Point]instance Show Vector where show (Vector ys) = let show' (Vector [z]) = show z show' (Vector (x:xs)) = show x ++ ", " ++ show' xs show' (Vector []) = [] in "(" ++ show' ys ++ ")" What I'm trying to do, is to print out a vector like "Vector [Point 1, Point 2, Point 3]" as "(1, 2, 3)".My question is: what should I change in order to make it work? Best regards, William

5 4

Built-in LLVM exception handling
by Gregory Crosswhite 28 Nov '11

28 Nov '11

Purely out of curiosity, would it be more efficient for GHC to use the new built-in exception handling instructions in LLVM? http://blog.llvm.org/2011/11/llvm-30-exception-handling-redesign.html Cheers, Greg

1 0

Drawing charts over a lot of data
by Eugene Kirpichov 28 Nov '11

28 Nov '11

Hi cafe, Are there any (possibly unfinished?) libraries dedicated to drawing charts over large amounts of data? I mean, such amounts that you don't want to store the whole set of input data in memory and instead you prefer to do one or a few passes over the input, calling the library's drawing functions for each data point. I'm currently using the excellent Chart package http://hackage.haskell.org/package/Chart , but it seems to require quite a bit of work to become usable in this mode (I haven't looked really deep yet). So, I'd be happy if someone pointed me to an existing package (I didn't find one on hackage) or if someone expressed interest in making Chart avoid having the whole input in memory. -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/

5 4