March 2011 - Glasgow-haskell-users

Fix context reduction stack overflow in dimensional
by Bas van Dijk 29 Mar '11

29 Mar '11

Dear Bjorn, Attached is a patch that fixes a context reduction stack overflow in your dimensional package. I noticed something weird though (that's why I'm CCing the ghc list). When I cabal build dimensional-0.8.2 I first get the context reduction stack overflow when I then build it again I get the error again (as expected). However when I try to build it for the third time it succeeds! Why is this? I attached the build log. Regards, Bas

3 3

OPTIONS_GHC -prof -auto-all
by Henning Thielemann 28 Mar '11

28 Mar '11

I have a large package and want to profile all functions of a single module of that package. I tried to prepend the pragma {-# OPTIONS_GHC -prof -auto-all #-} to the mentioned module, but GHC rejects this, because the profiler options are not allowed in the OPTIONS pragma. According to http://www.haskell.org/pipermail/glasgow-haskell-users/2006-December/011701… this is a known issue. I could certainly add GHC-Options: -prof -auto-all to the package Cabal description, but I expect this would add cost centres to all functions in all modules of the package. I could add SCC pragmas to all top-level functions in the profiled module, but this is cumbersome. Thus my question: Is there a straightforward way to add cost centres to all functions of a single module in a Cabal package?

2 1

downgrade HP
by Luca Ciciriello 26 Mar '11

26 Mar '11

Hi All. How can I downgrade the Haskell platform from 2011.2.0.0 to 2010.2.0.0? I've removed the HP 2011.2.0.0 and installed again the HP 2010.2.0.0, but now several important packages (like IO) are missing! My system is MacOS X 10.6.7 with Xcode 4 installed. Any idea? Thanks in advance. Luca.

1 0

Issue with SrcSpan of AbsBinds
by JP Moresmau 25 Mar '11

25 Mar '11

Hello, I'm trying to get Scion to work well with GHC7, and I found a small issue (I'm not saying it's GHC7 only, maybe it was there in GHC 6.12). I'm using 7.0.2 I have the following code, which is idiotic but proves the point: fun :: t -> [Char] -> [Char] fun _=reverse . map toUpper And the TypecheckedSource gives me something like (using the ghc-syb-utils package to dump it:) {Bag(Located (HsBind Var)): [ (L {src\Folder1\ForAll.hs:8:1-29} (AbsBinds [{Var: t}] [] [ ((,,,) [{Var: t}] {Var: Folder1.ForAll.fun} {Var: fun} (SpecPrags []))] ({abstract:TcEvBinds}) {Bag(Located (HsBind Var)): [ (L {src\Folder1\ForAll.hs:9:1-27} (FunBind (L {src\Folder1\ForAll.hs:9:1-3} {Var: fun}) (False) (MatchGroup Obviously my code starts at line 8 in that example. The issue occurs when the scion code wants to tell the user what (name+type) is a particular line/column in the source Now the scion code does something simple: to find something at a given point, it goes down the tree, and when it encounters a Located object, it checks the location spans around the point we're looking at. The issue here is that the AbsBinds has a SrcSpan that only covers the type signature, and not the rest of the code, hence (I think) we never go down the contents, and Scion cannot resolve anything when a user asks it to. If the type signature is not present, the problem doesn't occur: the AbsBinds location covers all the source code. If the type signature is present but without any type variable, there is no AbsBinds and no problem. Is that normal behavior, and hence should I code a work around in Scion? Thanks! -- JP Moresmau http://jpmoresmau.blogspot.com/

3 2

Re: ghc fails with HOME not set, fixing right now
by Christian Maeder 25 Mar '11

25 Mar '11

ghc should not fail if HOME is not set. It certainly cannot look up local packages then, but ghc should work without those, too. ghc is a compiler like gcc. Does gcc need HOME? Cheers Christian Am 25.03.2011 08:26, schrieb Joachim Breitner: > Hi, > > new FTBFS coming up: ghc fails if HOME is not set, which is apparently > the case on some buildds. I’m now setting HOME to a dummy variable in > debian/rules and building it right now in a pbuilder (with HOME not > set...). > > We’ll need to see if this affects the libraries as well. If that is the > case, it can be easily fixed in haskell-devscripts. > > Greetings, > Joachim >

2 1

7.0.3
by Ian Lynagh 24 Mar '11

24 Mar '11

Hi all, Due to a number of issues in the 7.0.2 release, we plan to put out a 7.0.3 release before finally retiring the 7.0 branch. We intend to fix: * Doc install location on Windows * Doc building on OS X (#4997) * Object splitting on OS X (with XCode >= 3.2) * Don't require the 10.5 SDK on OS X (should mean GHC works with XCode 4) We will also look into the problems with stripping and libHSghc.a (e.g. the issue building yesod #5004), and the ld warnings on OS X (#4984). We want to keep the changes in this release to a minimum, to minimise the chance of regressions, but if you think we've missed any critical issues please let us know. Thanks Ian

7 8

Re: memory slop (was: Using the GHC heap profiler)
by John Lato 22 Mar '11

22 Mar '11

Minor update, here's how I would handle this problem (using uu-parsinglib and the latest ListLike, mostly untested): import Data.ListLike (fromString, CharString (..)) import Text.ParserCombinators.UU import Text.ParserCombinators.UU.BasicInstances import Text.ParserCombinators.UU.Utils -- change the local bindings in undumpFile to: addv m s | BS.null s = m addv m s = let (k,v) = readKV s in Map.insert k v m readKV :: BS.ByteString -> (BS.ByteString, BS.ByteString) readKV s = let [ks,vs] = parse (pTuple [pQuotedString, pQuotedString]) (createStr (LineColPos 0 0 0) $ CS s) unCSf = BS.drop 1 . BS.init . unCS in (unCSf ks, unCSf vs) And of course change the type of "foldLines" and use BS.hGetLine, both to enable ByteString IO. To use uu-parsinglib's character parsers (e.g. pTuple) with ByteStrings, you need to use a newtype wrapper such as CharString from ListLike, "CS" and "unCS" wrap and unwrap the type. The "unCSf" function removes the starting and trailing quotes in addition to unwrapping. This is still quick-and-dirty in that there's no error recovery, but it's easy to add, just see the uu-parsinglib documentation and examples, particularly "pEnd". I think this will make a significant difference to your application. John L. Message: 4 > Date: Tue, 22 Mar 2011 20:32:16 -0600 > From: Tim Docker <twd2(a)dockerz.net> > Subject: memory slop (was: Using the GHC heap profiler) > To: glasgow-haskell-users(a)haskell.org > Message-ID: <4D895BB0.1080902(a)dockerz.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > -------- Map2.hs -------------------------------------------- > > module Main where > > import qualified Data.Map as Map > import qualified Data.ByteString.Char8 as BS > import System.Environment > import System.IO > > type MyMap = Map.Map BS.ByteString BS.ByteString > > foldLines :: (a -> String -> a) -> a -> Handle -> IO a > foldLines f a h = do > eof <- hIsEOF h > if eof > then (return a) > else do > l <- hGetLine h > let a' = f a l > a' `seq` foldLines f a' h > > undumpFile :: FilePath -> IO MyMap > undumpFile path = do > h <- openFile path ReadMode > m <- foldLines addv Map.empty h > hClose h > return m > where > addv m "" = m > addv m s = let (k,v) = readKV s > in k `seq` v `seq` Map.insert k v m > > readKV s = let (ks,vs) = read s in (BS.pack ks, BS.pack vs) > > dump :: [(BS.ByteString,BS.ByteString)] -> IO () > dump vs = mapM_ putV vs > where > putV (k,v) = putStrLn (show (BS.unpack k, BS.unpack v)) > > main :: IO () > main = do > args <- getArgs > case args of > [path] -> do > v <- undumpFile path > dump (Map.toList v) > return () >

1 0

Re: memory slop (was: Using the GHC heap profiler)
by John Lato 22 Mar '11

22 Mar '11

Hi Tim, Sorry I can't tell you more about slop (I know less than you at this point), but I do see the problem. You're reading each line from a Handle as a String (bad), then creating ByteStrings from that string with BS.pack (really bad). You want to read a ByteString (or Data.Text, or other compact representation) directly from the handle without going through an intervening string format. Also, you'll be better off using a real parser instead of "read", which is very difficult to use robustly. John L. > From: Tim Docker <twd2(a)dockerz.net> > Subject: memory slop (was: Using the GHC heap profiler) > To: glasgow-haskell-users(a)haskell.org > Message-ID: <4D895BB0.1080902(a)dockerz.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > On Mon, Mar 21, 2011 at 9:59 AM, I wrote: > > > > My question on the ghc heap profiler on stack overflow: > > > > > http://stackoverflow.com/questions/5306717/how-should-i-interpret-the-outpu… > > > > remains unanswered :-( Perhaps that's not the best forum. Is there > someone > > here prepared to explain how the memory usage in the heap profiler > relates > > to the "Live Bytes" count shown in the garbage collection statistics? > > I've made a little progress on this. I've simplified my program down to > a simple executable that loads a bunch of data into an in-memory map, > and then writes it out again. I've added calls to `seq` to ensure that > laziness is not causing excessing memory consumption. When I run this on > my sample data set, it takes ~7 cpu seconds, and uses ~120 MB of vm An > equivalent python script, takes ~2 secs and ~19MB of vm :-(. > > The code is below. I'm mostly concerned with the memory usage rather > than performance at this stage. What is interesting, is that when I turn > on garbage collection statistics (+RTS -s), I see this: > > 10,089,324,996 bytes allocated in the heap > 201,018,116 bytes copied during GC > 12,153,592 bytes maximum residency (8 sample(s)) > 59,325,408 bytes maximum slop > 114 MB total memory in use (1 MB lost due to fragmentation) > > Generation 0: 19226 collections, 0 parallel, 1.59s, 1.64selapsed > Generation 1: 8 collections, 0 parallel, 0.04s, 0.04selapsed > > INIT time 0.00s ( 0.00s elapsed) > MUT time 5.84s ( 5.96s elapsed) > GC time 1.63s ( 1.68s elapsed) > EXIT time 0.00s ( 0.00s elapsed) > Total time 7.47s ( 7.64s elapsed) > > %GC time 21.8% (22.0% elapsed) > > Alloc rate 1,726,702,840 bytes per MUT second > > Productivity 78.2% of total user, 76.5% of total elapsed > > This seems strange. The maximum residency of 12MB sounds about correct > for my data. But what's with the 59MB of "slop"? According to the ghc docs: > > | The "bytes maximum slop" tells you the most space that is ever wasted > | due to the way GHC allocates memory in blocks. Slop is memory at the > | end of a block that was wasted. There's no way to control this; we > | just like to see how much memory is being lost this way. > > There's this page also: > > http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/Slop > > but it doesn't really make things clearer for me. > > Is the slop number above likely to be a significant contribution to net > memory usage? Are there any obvious reasons why the code below could be > generating so much? The data file in question has 61k lines, and is <6MB > in total. > > Thanks, > > Tim > > -------- Map2.hs -------------------------------------------- > > module Main where > > import qualified Data.Map as Map > import qualified Data.ByteString.Char8 as BS > import System.Environment > import System.IO > > type MyMap = Map.Map BS.ByteString BS.ByteString > > foldLines :: (a -> String -> a) -> a -> Handle -> IO a > foldLines f a h = do > eof <- hIsEOF h > if eof > then (return a) > else do > l <- hGetLine h > let a' = f a l > a' `seq` foldLines f a' h > > undumpFile :: FilePath -> IO MyMap > undumpFile path = do > h <- openFile path ReadMode > m <- foldLines addv Map.empty h > hClose h > return m > where > addv m "" = m > addv m s = let (k,v) = readKV s > in k `seq` v `seq` Map.insert k v m > > readKV s = let (ks,vs) = read s in (BS.pack ks, BS.pack vs) > > dump :: [(BS.ByteString,BS.ByteString)] -> IO () > dump vs = mapM_ putV vs > where > putV (k,v) = putStrLn (show (BS.unpack k, BS.unpack v)) > > main :: IO () > main = do > args <- getArgs > case args of > [path] -> do > v <- undumpFile path > dump (Map.toList v) > return () >

1 0

GHC7 (on OSX.5)
by wren ng thornton 22 Mar '11

22 Mar '11

So I'm having a go of installing ghc-7.0.2 and haskell-platform-2011.2.0.0 on OSX 10.5. Since 10.5 is no longer supported I've had to compile from source. The good news is, so far as I can tell, everything works right out of the box.[1] But I've noticed when compiling the base libraries and HP a lot of warnings like the following: SpecConstr Function `a_s2Qn{v} [lid]' has three call patterns, but the limit is 1 Use -fspec-constr-count=n to set the bound Use -dppr-debug to see specialisations Though the number of call patterns and the limit vary. Googling led me to the SpecConstr file which I read briefly, so I know it has to do with optimizing away constructor allocations, but that's about it. Are these warnings I should be concerned about? [1] OSX 10.5.8 arch x86_64 (though it calls itself i386) Xcode 3.1.2 (not that it matters) gcc 4.0.1 (i686-apple-darwin9-gcc-4.0.1 Apple Inc. build 5490) ghc 6.12.1 / hp 2010.1.0.0 -- Live well, ~wren

4 5

testing 7.02-candidate
by Serge D. Mechveliani 20 Mar '11

20 Mar '11

Dear GHC team, I am testing the 7.02 candidate of ghc-7.0.1.20110217 -- compiled from source, compiled by itself, on Debian Linux, i386-family. On my DoCon program, it reports the following. 1. It requires `-fcontext-stack=_' to increase a certain stack: ... [67 of 83] Compiling Pfact__ ( Pfact__.hs, dist/build/Pfact__.o ) [68 of 83] Compiling RsePol_ ( RsePol_.hs, dist/build/RsePol_.o ) RsePol_.hs:214:28: Context reduction stack overflow; size = 21 Use -fcontext-stack=N to increase stack size to N $dSet :: Set (UPol (ResidueE Integer)) $dAddSemigroup :: AddSemigroup (UPol (ResidueE Integer)) $dAddMonoid :: AddMonoid (UPol (ResidueE Integer)) ... $dCast :: Prelude_.Cast (ResidueE (UPol (Pfact__.RseUPolRse Integer))) (UPol (Pfact__.RseUPolRse Integer)) In the first argument of `(.)', namely `ct c1' In the expression: ct c1 . toOverK . resRepr In an equation for `toC': toC = ct c1 . toOverK . resRepr ------------------------------------------- So, I add -fcontext-stack=30 to the ghc-options line in docon.cabal. Which one is better at this point, 7.0.1 or 7.0.1.20110217 ? 2. Then, DoCon is built, and the commands cd demotest ghc $doconCpOpt -O -rtsopts --make Main need to `make' the DoCon test under the DoCon library. This reports [ 1 of 17] Compiling T_detinterp ( T_detinterp.hs, T_detinterp.o ) [ 2 of 17] Compiling T_sphGeo ( T_sphGeo.hs, T_sphGeo.o ) [ 3 of 17] Compiling T_cubeext ( T_cubeext.hs, T_cubeext.o ) T_cubeext.hs:143:9: Overlapping instances for LinSolvRing (UPol k) arising from a use of `ct' Matching instances: instance [overlap ok] EuclideanRing a => LinSolvRing (UPol a) -- Defined in docon-2.12:Pol2_ instance [overlap ok] (LinSolvRing (Pol a), CommutativeRing a) => LinSolvRing (UPol (Pol a)) -- Defined in docon-2.12:Pol3_ (The choice depends on the instantiation of `k' To pick the first instance above, use -XIncoherentInstances when compiling the other instance declarations) In the first argument of `(.)', namely `ct unE' In the expression: ct unE . kToB In an equation for `kToE': kToE = ct unE . kToB -------------------------------------------------------------------- This looks like a bug of the kind appeared in a couple of earlier GHC versions. ghc-7.0.1 is free of both of these effects. What is your opinion about this? http://www.botik.ru/pub/local/Mechveliani/ghcBugs/702candBug.zip is the archive with the project to make and run under ghc-7.0.1, and ghc-7.0.1.20110217 (follow install.txt). Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1