- Glasgow-haskell-users

doCorePass
by Colin Paul Adams 01 Apr '09

01 Apr '09

Between 6.8 and 6.11, function doCorePass in module SimplCore has changed types from: CoreToDo -> HscEnv -> UniqSupply -> RuleBase -> ModGuts -> IO (SimplCount, ModGuts) to: CorePass (== CoreToDo) -> ModGuts -> CoreM ModGuts and it isn't easy for me to figure out the relationship between the two types. Is there some sort of formula I can follow to convert a function with the first type to the second? -- Colin Adams Preston Lancashire

2 1

ANNOUNCE: GHC version 6.10.2
by Ian Lynagh 01 Apr '09

01 Apr '09

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 6.10.2 ============================================================== The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.10.1, including some performance fixes, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.10.2/html/users_guide/release-6-10-2.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

1 0

Unable to compile ghc from darcs
by Colin Paul Adams 01 Apr '09

01 Apr '09

I was getting errors somewhere in haddock about some ambiguous function, so I did a darcs pull to see if that would pull in a fix for the problem (unfortunately I didn't make a note of the errors). But now the compile fails earlier with errors in deSugar/DsMeta.hs: deSugar/DsMeta.hs:471:48: Not in scope: type constructor or class `TH.InlineSpecQ' deSugar/DsMeta.hs:504:16: Not in scope: type constructor or class `TH.TyVarBndr' deSugar/DsMeta.hs:538:50: Not in scope: type constructor or class `TH.TyVarBndr' deSugar/DsMeta.hs:640:29: Not in scope: type constructor or class `TH.Kind' etc. Is the code in darcs supposed to be compilable normally? And what can I do about such situations? Just report them here? -- Colin Adams Preston Lancashire

5 22

GADTs with strict fields?
by Conal Elliott 01 Apr '09

01 Apr '09

Do strict fields work with GADTs? If so, what's the syntax for the strictness annotations? - Conal

2 2

spurious "non-exhaustive" pattern warnings?
by Conal Elliott 31 Mar '09

31 Mar '09

-- Why do I get warnings about non-exhaustive pattern matches in the -- following code? Is the compiler just not clever enough to notice that -- the uncovered cases are all type-incorrect? (ghc 6.11.20090115) {-# LANGUAGE TypeFamilies, EmptyDataDecls, TypeOperators , GADTs, KindSignatures , FlexibleInstances, FlexibleContexts #-} {-# OPTIONS_GHC -Wall #-} import Control.Applicative (Applicative(..)) data Z data S n infixr 1 :< data Vec :: * -> * -> * where ZVec :: Vec Z a (:<) :: a -> Vec n a -> Vec (S n) a -- todo: infix op for SVec instance Functor (Vec n) where fmap _ ZVec = ZVec fmap f (a :< u) = f a :< fmap f u instance Applicative (Vec Z) where pure _ = ZVec ZVec <*> ZVec = ZVec -- Warning: Pattern match(es) are non-exhaustive -- In the definition of `<*>': -- Patterns not matched: -- (_ :< _) _ -- ZVec (_ :< _) instance Applicative (Vec n) => Applicative (Vec (S n)) where pure a = a :< pure a (f :< fs) <*> (x :< xs) = f x :< (fs <*> xs) -- Warning: Pattern match(es) are non-exhaustive -- In the definition of `<*>': -- Patterns not matched: -- ZVec _ -- (_ :< _) ZVec

2 1

Control.Parallel.Strategies.parMap CPU usage
by Christian Hoener zu Siederdissen 30 Mar '09

30 Mar '09

Greetings, when using parMap (or parList and demanding) I see a curious pattern in CPU usage. Running "parMap rnf fib [1..100]" gives the following pattern of used CPUs: 4,3,2,1,4,3,2,1,... The fib function requires roughly two times the time if we go from fib(n) to fib(n+1), meaning that calculating the next element in the list always takes longer than the current. What I would like is a version of parMap that directly takes a free CPU and lets it calculate the next result, giving the usage pattern 4,4,4,4,... Below you find the simple Haskell program, which gives these results, please compile with "ghc --make -threaded -O2 Para.hs" and run on a machine with at least two cores and "./Para +RTS -N2" or better. I am not filing a bug yet as I would prefer to be told that I did it wrong and here is a better way: ... Thanks, Christian (Please assume that later on, "fib" will be replaced by something meaningful ;) # ghc --version # The Glorious Glasgow Haskell Compilation System, version 6.10.1 module Main where import Control.Parallel.Strategies -- parallel computation of fibonacci numbers in slow fib :: Int -> Int fib n | n < 1 = error "n < 1" | n == 1 = 1 | n == 2 = 1 | otherwise = fib (n-1) + fib(n-2) fibs = parMap rnf fib $ [1..100] -- fibs = let fs = map fib $ [1..100] in fs `demanding` (parList rnf fs) main = do mapM_ (putStrLn . show) $ zip [1..] fibs

4 5

copyFile and thread safety
by Neil Mitchell 30 Mar '09

30 Mar '09

Hi, Using GHC 6.8.3, the copyFile routine isn't thread safe - it crashes when two threads try and open the same file. I think that improvements were made to avoid security race conditions in GHC 6.10.1 (or the base library associated with it), and as a nice side effect they seem to have fixed the copyFile issues. However, it would be nice if someone could assure me that the copyFile issues were real but are now fixed. Replicating them is hard, but they randomly occur during a 1-hour build on my laptop, but not my desktop. I also note that copyFile starts with the process id and increments looking for a free filename. While that's fantastic if you are avoiding races with other processes (as I think the improvements were intended to address), it's not so great for avoiding races within the same process when different threads attempt to copy lots of files at once. In doing this, I suspect I've suffered lots of retries in the temporary name creation algorithm - should I be concerned about the performance aspect of this? Would an atomicModifyIORef and global temp file counter be a good idea? For now, I've got no immediate problems as I simply shell out to "cp" to do the copying - but it would be nice if the Haskell worked too. Thanks Neil

1 0

Few problems with building GHC
by Zachary Turner 30 Mar '09

30 Mar '09

Hi, This is my first time trying to compile GHC, so forgive me if these issues are mentioned somewhere. I couldn't find them anywhere on the wiki. First, I had originally installed a binary distribution and then tried to compile another program (a Haskell editor) that recommended I have source available for all libraries, since it would be able to give me better info in the editor. So this is why I decided to compile GHC from source in the first place. So I compiled GHC, and did make install, and I was _expecting_ that all of the library sources would end up in the directories alongside the binaries as well and that this is how the editor would be able to locate the source. But this did not happen, and instead my library folders look exactly like they do in the binary distribution that I installed by downloading the prepacked installer from the website. However, at one point I had downloaded some packages from Hackage and installed them with runhaskell configure, runhaskell build, runhaskell install on each of these new libraries, and the source did end up in the library directories alongside the binaries. So I feel like I'm doing something wrong in building GHC, and that when I install there should be a way to have the source of the libraries copied to the target directories. Can someone elaborate on how this is supposed to work for other programs that depend on the library sources to be able to find them? I know that of the 2 Hackage packages that I installed, the editor printed a message saying that it did find source for those two, but not for any other libraries. Second, I cannot create a windows build of GHC under cygwin. Looking at the Building Guide on the wiki suggests that this is indeed supported. However, when I try to build it I get cabal-bin.exe: Cannot find the program 'ghc' at '/cygdrive/c/dev/haskell/ghc/ghc-6.10.1/bin/ghc' or on the path make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/cygdrive/c/dev/haskell/ghc/ghc-6.10.1-src/libraries' make: *** [stage1] Error 2 There seems to be some unix/windows confusion here, because it's looking for an executable file named "ghc", when the actual executable name is "ghc.exe". However, building under MSYS everything works perfectly. Is Cygwin just not supported, or do I need to change something here? I don't see any point in cluttering up my system with tons of extra software like MinGW, msys, etc if Cygwin works fine. Last, after building GHC when I go to run make install, I want the target location to be the original location of the compiler that I used to build GHC in the beginning. In other words, I want to have it overwrite the old version of GHC instead of going to the default install location under /usr/bin, etc... How can I specify the target install location?

2 3

Loop unrolling + fusion ?
by Don Stewart 27 Mar '09

27 Mar '09

Hey guys, We have nice fusion frameworks now. E.g. stream fusion on uvector, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uvector Takes something like this: import Data.Array.Vector import Data.Bits main = print . productU . mapU (*2) . mapU (`shiftL` 2) $ replicateU (100000000 :: Int) (5::Int) and turns it into a loop like this: $wfold :: Int# -> Int# -> Int# $wfold = \ (ww_sWX :: Int#) (ww1_sX1 :: Int#) -> case ww1_sX1 of wild_B1 { __DEFAULT -> $wfold (*# ww_sWX 40) (+# wild_B1 1); 100000000 -> ww_sWX } Now, that's fine in my book. Going via -fasm, we get: Main_zdwfold_info: .LcYt: movq %rdi,%rax cmpq $100000000,%rax jne .LcYx movq %rsi,%rbx jmp *(%rbp) .LcYx: incq %rax imulq $40,%rsi movq %rax,%rdi jmp Main_zdwfold_info Ok: $ time ./product 0 ./product 0.31s user 0.00s system 96% cpu 0.316 total Going via C, however, we get: Main_zdwfold_info: cmpq $100000000, %rdi je .L6 .L2: leaq (%rsi,%rsi,4), %rax leaq 1(%rdi), %rdi leaq 0(,%rax,8), %rsi jmp Main_zdwfold_info Nice! $ time ./product 0 ./product 0.19s user 0.00s system 97% cpu 0.197 total So now, since we've gone to such effort to produce a tiny loop like, this, can't we unroll it just a little? Sadly, my attempts to get GCC to trigger its loop unroller on this guy haven't succeeded. -funroll-loops and -funroll-all-loops doesn't touch it, Anyone think of a way to apply Claus' TH unroller, or somehow convince GCC it is worth unrolling this guy, so we get the win of both aggressive high level fusion, and aggressive low level loop optimisations? -- Don

9 33

Int vs Word performance?
by Marco Túlio Gontijo e Silva 27 Mar '09

27 Mar '09

Hello, sorry for breaking the thread, I just got in the list. Simon Peyton-Jones simonpj at microsoft.com : > PS: in the case that no one gets around to creating such a patch, > creating a ticket that documents the problem and points to the needed > specialisations would be a start Was this created? I could not find something about it in the GHC trac. Greetings. -- marcot http://marcot.iaaeee.org/

2 1