- Libraries - Haskell.org

Re: Proposal: Add strict iterate' (and a discussion of possible new RULES)
by David Feuer 30 Jul '14

30 Jul '14

I'm pushing hard to get unfoldr fixed ASAP, and looking to take advantage of that. Specifically, I like the idea of using the fusion that (I dearly hope) will come with unfoldr to make a variety of other things fuse that currently need their own special rules. I also want to extend fusion by one or two general rules. One that looks very good is similar to the rejected foldr/cons rule, but seems somewhat less likely to cause problems while still enhancing fusion in general: {-# RULES "cons/build" forall x (g::forall b . (a->b->b)->b->b) . x : build g = build (\c n -> x `c` g c n) #-} This will allow foldr/build fusion to look past conses. So for example, foldr f q (x : build g) will be rewritten (cons/build) to foldr f q (build (\c n -> x `c` g c n)) and then (fold/build) to (\c n -> x `c` g c n) f q This reduces to f x (g f q) A discussion about foldr k z (x1:x2:x3:...:x2000:build g), a possible way to fix it, and why I don't think it's important anyway. This means the same thing as foldr k z ([x1,x2,x3,...,x2000] ++ build g) The current ++ rule rewrites this to foldr k z (augment (\c n -> foldr c n [x1,...,x2000]) (build g)) Then foldr/augment: (\c n -> foldr c n [x1,..,x2000]) k (foldr k z (build g)) Then foldr/build: (\c n -> foldr c n [x1,...,x2000]) k (g k z) Then beta reduction: foldr k (g k z) [x1,...,x2000] So to take the example from earlier, foldr f q (x : build g) is currently bad, but foldr f q ([x] ++ build g) will end up foldr f (g f q) [x] and then in this case the foldr/single rule will give f x (g f q) but if more than one element were in the list, we'd end up with a fold over the literal list (not bad in general). This suggests a fix, but one that may be difficult to implement within GHCs stage framework as is (I'm not quite sure; someone who knows more about the system may see a way to do this, but I think it wants to happen before the ++ rule, which I think happens at the beginning of time): Translate x1:x2:x3:...:build g to [x1,x2,x3,...] ++ build g Then let everything else happen as usual. I think, however, that this is probably overkill. Just implement cons/build and tell users that if they want x1:x2:x3:....:x2000:foo not to expand under foldr then they need to write [x1,x2,x3,...,x2000]++foo instead.

1 0

Re: Overlapping and incoherent instances
by Felipe Lessa 29 Jul '14

29 Jul '14

On 29-07-2014 20:41, Stephen Paul Weber wrote: >> instance {-# OVERLAPPABLE #-} Show a => Show [a] where ... > >> instance {-# OVERLAPPING #-} Show [Char] where ... > > This, to me, is an admission that developers are not going to want to turn > overlapping on globally in general, and so the current language extensions > would not make sense to get adopted into the core language at any point. > I agree with this idea, and so would second the proposal mentioned at > <http://www.reddit.com/r/haskell/comments/2c136i/xoverlappinginstances_and_x…> > that a language extension that adds actual keywords to tag instances that > should be allowed to overlap be added, instead of resorting to pragmas. > This seems like an approach that could be useful in general and one could > imagine moving "past" an extension to the core language at some point, > potentially. OTOH, the pragma is mostly harmless for older GHC versions, while the keyword approach needs a preprocessor. -- Felipe.

1 0

Re: Haskell Platform 2014.2.0.0 Release Candidate 2
by Brandon Allbery 29 Jul '14

29 Jul '14

On Tue, Jul 29, 2014 at 7:45 AM, George Colpitts <george.colpitts(a)gmail.com> wrote: > Installation worked fine. However I encountered a problem that looks like > a regression, although it may be a problem with new versions of the package > I am trying to install: It's not an H-P problem; Apple's started using their BLOCKS C extension in system headers, and gtk2hsc2hs doesn't understand it. (And possibly is not using cpp properly when processing headers.) You'll need to take this up with the gtk2hs folks. #ifdef __BLOCKS__ int scandir_b(const char *, struct dirent ***, int (^)(const struct dirent *), int (^)(const struct dirent **, const struct dirent **)) __DARWIN_INODE64(scandir_b) __OSX_AVAILABLE_STARTING(__MAC_10_6, __ IPHONE_3_2); #endif /* __BLOCKS__ */ -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

Haskell Platform 2014.2.0.0 Release Candidate 2
by Mark Lentczner 28 Jul '14

28 Jul '14

The long anticipated Haskell Platform 2014.2 release, including GHC 7.8.3, and numerous updated packages, is almost here! We have created "Release Candidate 2" installers for OS X and Windows, and believe, barring show stopper issues, creepers exploding, or other bizarre phenomenon, these will likely be blessed as the final in a few days time. If you would like to be an early adopter, please try 'em out... - source tarball: haskell-platform-2014.2.0.0-RC2.tar.gz <http://www.ozonehouse.com/mark/platform/haskell-platform-2014.2.0.0-RC2.tar…> - source repo: haskell/haskell-platform at 2014.2.0.0-RC2 <https://github.com/haskell/haskell-platform/tree/2014.2.0.0-RC2> - windows 32bit: hskellPlatform-2014.2.0.0-i386-RC2-setup.exe <http://www.ozonehouse.com/mark/platform/hskellPlatform-2014.2.0.0-i386-RC2-…> - windows 64bit:hskellPlatform-2014.2.0.0-x86_64-RC2-setup.exe <http://www.ozonehouse.com/mark/platform/hskellPlatform-2014.2.0.0-x86_64-RC…> - os x 64bit: Haskell Platform 2014.2.0.0 64bit RC2.signed.pkg <http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202014.2.0.0%206…> - travis-ci build: haskell/haskell-platform <https://travis-ci.org/haskell/haskell-platform> *Notes for RC2, since RC1:* *Windows* *Extra thanks to Randy Polen for burning the midnight-oil to get ths out* - removed unneeded python (et al) files from the GHC bindist for 64-bit Windows (referenced in GHC ticket #9014 <https://ghc.haskell.org/trac/ghc/ticket/9014>) - added HTML "view source" pages for the GHC packages that was missing from the GHC bindist for both 32- and 64-bit Windows. *Mac OS X* *If you installed RC1, you can remove first with the command *sudo uninstall-hs only 7.8.3 --remove *Run it without *--remove* to see what it will do before running, it if you like. In theory you can just install this one right on top of RC1.... but hasn't been tested.* - file layout on the Mac... improved slightly (again). In particular, executables are now installed directly in $prefix/bin dirs, rather than within the package dir - fix the bug with haddock master index not being updated correctly - works on 10.6! (and 10.7, 10.8, and 10.9) with gcc or clang based Xcodes - works on 10.10!!! (Yosemite, developer preview 4 release) *Source tarball* - missing sources in hptool now present - platform.sh improved somewhat (in particular, handles host cabal being pre-sandbox) *Timetable* - These can "soak" amongst the intreped on these lists for a few hours. - On Monday evening (PST) I'll announce to haskell-cafe and reddit - End of next week (from my vacation, I'll point out), we'll declare success and ship. — Mark *SHA-256 sums:* 62f39246ad95dd2aed6ece5138f6297f945d2b450f215d074820294310e0c48a Haskell Platform 2014.2.0.0 64bit RC2.signed.pkg 7c7d3585e89e1407461efea29dcaa9628c3be3c47d93a13b5a4978046375e4fd haskell-platform-2014.2.0.0-RC2.tar.gz 6eedd76aafb266d9a09baff80cd2973498ab59195c771f7cd64425d40be29c49 hskellPlatform-2014.2.0.0-i386-RC2-setup.exe b22115ed84d1f7e747d7f0b47e32e1489e4a24613d69c91df4ae32052f88b130 hskellPlatform-2014.2.0.0-x86_64-RC2-setup.exe

1 0

Issues resulting from inlining build
by David Feuer 28 Jul '14

28 Jul '14

I think I finally figured out the deeper problem behind an issue I was having getting some things to fuse fully. I'm hoping someone has a brilliant idea for getting around it. Of course, it may be that someone else has thoroughly studied the matter and determined that there's no good solution. Suppose we write crazy :: T -> [U] crazy x = some $ long $ fusion $ pipeline oops f = map f $ crazy x uhOh c n = foldr c n $ crazy Pig ohMy = take bignum $ crazy amigo When GHC compiles crazy, it rewrites the pieces of the pipeline to build/foldr forms, fuses them, and produces crazy x = build someBigFunction In then inlines build, producing crazy x = anotherBiggy So far, this looks reasonably sensible, but it's likely bad. The problem is that GHC will (rightly) conclude that `build someBigFunction` is too big to inline, and therefore the fusion will break at that boundary and we'll produce intermediate lists in the functions that use crazy. Now if we were playing the part of the compiler by hand, we would likely factor out someBigFunction and then *refrain from inlining build*. That is, we would get {-# NOINLINE crazyB #-} crazyB x = someBigFunction crazy = nonInliningBuild crazyB Since we've factored out someBigFunction into crazyB, we can now safely inline crazy itself, allowing the pipeline to continue beyond it. The problem, of course, is that when we *don't* fuse beyond, there is some performance penalty (I have not tried to measure it yet) to passing in (:) and [] at runtime instead of fixing them at compile time.

3 3

Fusion of list functions
by Simon Peyton Jones 28 Jul '14

28 Jul '14

David, and other Haskell library folk You’ve been doing lots of work on making more Prelude functions fusible – thank you! This is really a library question, so I have not been following the details of the discussion, but I hope Edward and the Core Libraries Committee have been doing so; I’m cc’ing them. I’m more than happy to help with any questions if you all get stuck. Don’t forget to update the user manual http://www.haskell.org/ghc/docs/latest/html/users_guide/rewrite-rules.html#… to say which functions are good producers/consumers. Actually, it might be better instead to state this in their Haddock comments, and remove or shrink this section of the user manual instead. It’s very hard to keep it up to date. I think it pre-dates Haddock. Many thanks. Simon From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of Michael Snoyman Sent: 27 July 2014 06:08 To: Carter Schonwald Cc: Haskell Libraries Subject: Re: Am I missing something about unfoldr? One I saw not too long ago was where someone created an infinite Vector and then consumed it immediately. With optimizations turned on, the intermediate Vector was fused away. With optimizations turned off, it wasn't fused away, and the program eventually crashed when it ran out of memory for holding the infinite Vector. On Sat, Jul 26, 2014 at 11:28 PM, Carter Schonwald <carter.schonwald(a)gmail.com<mailto:carter.schonwald@gmail.com>> wrote: its worth point out that many uses of fusion in haskell libs punt on preserving bottoms, that is, fusion can make *more* programs terminate. I don't have a good example off hand mind you On Sat, Jul 26, 2014 at 4:02 PM, David Feuer <david.feuer(a)gmail.com<mailto:david.feuer@gmail.com>> wrote: Hmm... I found something I missed. I need to prove that this doesn't break when the arguments to unfold use seq (if in fact it doesn't). I will have to look into it later. On Jul 26, 2014 3:34 PM, "David Feuer" <david.feuer(a)gmail.com<mailto:david.feuer@gmail.com>> wrote: The current definition: unfoldr :: (b -> Maybe (a, b)) -> b -> [a] unfoldr f b = case f b of Just (a,new_b) -> a : unfoldr f new_b Nothing -> [] I haven't yet looked over the Core to see if GHC is able to do a worker/wrapper transformation to inline it, but we definitely want to inline it (in some appropriate phase), because doing so has the potential to erase the Maybes. It also isn't a good producer for foldr/build. However, if we (re)write it like this: unfoldrB f b c n = go b where go b = case f b of Just (a,new_b) -> a `c` go new_b Nothing -> n unfoldr f b = build (unfoldrB f b) then we get some really nice fusion: foldr c n (unfoldr f b) = foldr c n (build (unfoldrB f b)) = unfoldrB f b c n The list is gone, and there are no new closures or data structures in its place. As a side benefit, we could write groupBy as an unfoldr, and make it a somewhat better producer, especially when the groups are small. I don't *think* there's any way to make groupBy a good consumer for foldr/build, unfortunately. _______________________________________________ Libraries mailing list Libraries(a)haskell.org<mailto:Libraries@haskell.org> http://www.haskell.org/mailman/listinfo/libraries _______________________________________________ Libraries mailing list Libraries(a)haskell.org<mailto:Libraries@haskell.org> http://www.haskell.org/mailman/listinfo/libraries

1 0

Would it be a good or bad idea to make dropWhile try to fuse?
by David Feuer 26 Jul '14

26 Jul '14

As Graham Hutton describes in "A tutorial on the universality and expressiveness of fold", dropWhile p = fst . foldr go ([], []) where go x (ys, xs) = (if p x then ys else x:xs, x:xs) We can write this for real: dropWhile :: forall a . (a -> Bool) -> [a] -> [a] dropWhile p list = build dropWhile' where dropWhile' :: forall b . (a -> b -> b) -> b -> b dropWhile' c n = fst $ foldr go (n, n) list where go x (ys, xs) = let xs' = x `c` xs in (if p x then ys else xs', xs') This is generally awful, because it could copy a large portion of the list with no benefit. However, if it fuses, it will sometimes give good results. For example, compiling f m n = foldr (+) 0 $ dropWhile (<m) $ map (+1) [1..n] yields Core that does not produce a intermediate list. Does anyone have any thoughts about whether this one is worth pursuing? David Feuer

4 7

Proof that scanl' is fusion-safe
by David Feuer 25 Jul '14

25 Jul '14

This proof is horribly inefficient. I imagine it could be fixed by appealing to the universal property of foldr or something like that, but I don't have time to look at that right now, so I'll just show you what I have right now; I'm hoping someone will be willing to verify that I haven't made any major errors. scanl' :: (b -> a -> b) -> b -> [a] -> [b] scanl' f a bs = build $ \c n -> a `seq` a `c` foldr (\b g x -> let b' = f x b in b' `seq` (b' `c` g b')) (\b -> b `seq` n) bs a -- Inlining build in scanl' gives scanl' f a bs = a `seq` a : foldr (\b g x -> let b' = f x b in b' `seq` (b` : g b')) (\b -> b `seq` []) bs a foldr evil wrong (scanl' f a bs) = foldr evil wrong $ a `seq` a : foldr (\b g x -> let b' = f x b in b' `seq` (b` : g b')) (\b -> b `seq` []) bs a -- Call this e1 a bs =?= (\c n -> a `seq` a `c` foldr (\b g x -> let b' = f x b in b' `seq` (b' `c` g b')) (\b -> b `seq` n) bs a) evil wrong -- Call this e2 a bs -- Expanding the outer foldr of e1 one step: e1 a bs = a `seq` evil a (foldr evil wrong $ foldr (\b g x -> let b' = f x b in b' `seq` (b' : g b')) (\b -> b `seq` []) bs a) --Beta reduction of e2 gives e2 a bs = a `seq` a `evil` foldr (\b g x -> let b' = f x b in b' `seq` (b' `evil` g b')) (\b -> b `seq` wrong) bs a -- Now if a = _|_, these are clearly both _|_, so for the rest of all eternity, -- assume a /= _|_. This eliminates one `seq`: e1 a bs = evil a $ foldr evil wrong $ foldr (\b g x -> let b' = f x b in b' `seq` (b' : g b')) (\b -> b `seq` []) bs a e2 a bs = evil a $ foldr (\b g x -> let b' = f x b in b' `seq` (b' `evil` g b')) (\b -> b `seq` wrong) bs a -- We will work by induction on the structure of bs, assuming that bs = -- b1:b2:...:[] or b1:b2:...:_|_ I believe that the proof for the -- partially defined case will somehow magically cover the infinite -- case too by some general principle, but I don't know how that magic -- works. -- The base cases are kind of dull, so I'll start with the -- inductive case. Assume that e1 bs = e2 bs e1 a (q:bs) = evil a $ foldr evil wrong $ foldr (\b g x -> let b' = f x b in b' `seq` (b' : g b')) (\b -> b `seq` []) (q:bs) a = evil a $ foldr evil wrong $ (\b1 g1 x1 -> let b1' = f x1 b1 in b1' `seq` (b1' : g1 b1')) q (foldr (\b g x -> let b' = f x b in b' `seq` (b' : g b')) (\b -> b `seq` []) bs) a = evil a $ foldr evil wrong $ (\g1 x1 -> let b1' = f x1 q in b1' `seq` (b1' : g1 b1')) (foldr (\b g x -> let b' = f x b in b' `seq` (b' : g b')) (\b -> b `seq` []) bs) a = evil a $ foldr evil wrong $ (let b1' = f a q in b1' `seq` (b1' : (foldr (\b g x -> let b' = f x b in b' `seq` (b' : g b')) (\b -> b `seq` []) bs) b1' -- Since foldr is strict in its list argument, we can move the first `seq` outward: = evil a $ let b1' = f a q in b1' `seq` foldr evil wrong $ (b1' : (foldr (\b g x -> let b' = f x b in b' `seq` (b' : g b')) (\b -> b `seq` []) bs) b1' = evil a $ let b1' = f a q in b1' `seq` evil b1' (foldr evil wrong $ (foldr (\b g x -> let b' = f x b in b' `seq` (b' : g b')) (\b -> b `seq` []) bs) b1') = evil a $ let b1' = f a q in b1' `seq` e1 b1' bs e2 a (q:bs) = evil a $ foldr (\b g x -> let b' = f x b in b' `seq` (b' `evil` g b')) (\b -> b `seq` wrong) (q:bs) a = evil a $ (\b1 g1 x1 -> let b1' = f x1 b1 in b1' `seq` (b1' `evil` g1 b1')) q (foldr (\b g x -> let b' = f x b in b' `seq` (b' `evil` g b')) (\b -> b `seq` wrong) bs) a = evil a $ let b1' = f a q in b1' `seq` (evil b1' (foldr (\b g x -> let b' = f x b in b' `seq` (b' `evil` g b')) (\b -> b `seq` wrong) bs) b1') = evil a $ let b1' = f a q in b1' `seq` e2 b1' bs scanl' f a bs = a `seq` a : foldr (\b g x -> (let b' = f x b in b' `seq` (b` : g b'))) (\b -> b `seq` []) bs a -- The first base case is bs = _|_ e1 _|_ = evil a $ foldr evil wrong $ foldr (\b g x -> (let b' = f x b in b' `seq` (b' : g b'))) (\b -> b `seq` []) _|_ a -- Since foldr is strict in its list argument, this reduces to e1 _|_ = evil a $ foldr evil wrong $ _|_ a = evil a (_|_ a) = evil a _|_ -- Next we look at e2 _|_ e2 _|_ = evil a $ foldr (\b g x -> (let b' = f x b in b' `seq` (b' `evil` g b'))) (\b -> b `seq` wrong) _|_ a = evil a (_|_ a) = evil a _|_ -- The second base case is bs = []. e1 [] = evil a $ foldr evil wrong $ foldr (\b g x -> (let b' = f x b in b' `seq` (b' : g b'))) (\b -> b `seq` []) [] a = evil a $ foldr evil wrong $ (\b -> b `seq` []) a = evil a $ foldr evil wrong (a `seq` []) -- Since we haven't reached the end of all eternity yet, a /= _|_ e1 [] = evil a $ foldr evil wrong [] = evil a wrong e2 [] = evil a $ foldr (\b g x -> (let b' = f x b in b' `seq` (b' `evil` g b'))) (\b -> b `seq` wrong) [] a = evil a $ (\b -> b `seq` wrong) a = evil a (a `seq` wrong) = evil a wrong -- Eternity passes so slowly!

1 0

At long last: 2014.2.0.0 Release Candidate 1
by Mark Lentczner 25 Jul '14

25 Jul '14

*Even I find it hard to believe that it's finally here!* *I'm happy to announce the RC1 release of Haskell Platform 2014.2.0.0.* You can find builds for Windows (32bit and 64bit), Mac (64bit), as well as a source tarball, and a tag in the repo: - source tarball: haskell-platform-2014.2.0.0-RC1.tar.gz <http://www.ozonehouse.com/mark/platform/haskell-platform-2014.2.0.0-RC1.tar…> - source repo: https://github.com/haskell/haskell-platform/tree/2014.2.0.0-RC1 - windows 32bit: HaskellPlatform-2014.2.0.0-i386-RC1-setup.exe <http://www.ozonehouse.com/mark/platform/HaskellPlatform-2014.2.0.0-i386-RC1…> - windows 64bit: HaskellPlatform-2014.2.0.0-x86_64-RC1-setup.exe <http://www.ozonehouse.com/mark/platform/HaskellPlatform-2014.2.0.0-x86_64-R…> - os x 64bit: Haskell Platform 2014.2.0.0 64bit RC1.signed.pkg <http://www.ozonehouse.com/mark/platform/Haskell%20Platform%202014.2.0.0%206…> - travis-ci build: 20 <https://travis-ci.org/haskell/haskell-platform/builds/30723884> *Notes:* General - Built with the new shake based build system - cgi package not included as it doesn't build under 7.8, and no word from the maintainer in quite some time - hscolour is included as a tool, mostly as it is used to build the platform itself on win and mac... but we should probably officially decide to include it - the haskell-platform package itself is not in these releases... not sure if we actually need it as it doesn't contain anything other than dependencies. Windows - The Haskell Platform now provides a native Windows 64-bit installation (haskell-platform issue #54 <https://github.com/haskell/haskell-platform/issues/54>) - All included packages built without --enable-split-objs (GHC 7.8 FAQ <https://ghc.haskell.org/trac/ghc/wiki/GHC-7.8-FAQ#Cabal>) - All included packages built without --enable-shared (GHC ticket #8228 <https://ghc.haskell.org/trac/ghc/ticket/8228>) - All html document links are relative and everything links nicely together now, including the master index and cross-package links - If other Haskell Platform installations are detected during the installation of Haskell Platform 2014.2.0.0, a warning is displayed to the user that this is not recommended since problems will arise due to how the PATH is used in many cases to find ancillary build tools - Using ghci to build an executable that links against a DLL may result in numerous warnings about symbols (GHC ticket #9297 <https://ghc.haskell.org/trac/ghc/ticket/9297>) - On Windows 64-bit, some unneeded python files are included (GHC ticket #9014 <https://ghc.haskell.org/trac/ghc/ticket/9014>) - The Haskell Platform for Windows, both 32-bit and 64-bit, now includes an updated version of the OpenGL Utility Toolkit (GLUT) from the FreeGLUT project, utilizing the pre-built distribution from http://www.transmissionzero.co.uk/software/freeglut-devel/ with the MinGW build (freeglut-MinGW-2.8.1-1.mp.zip). (haskell-platform issue #81 <https://github.com/haskell/haskell-platform/issues/81>) Mac OS X - Distributed with a build of 7.8.3 that differs from the released bindist in two ways: a) it was built split-objs for smaller resulting executables, b) it includes Cabal-1.18.1.4 which fixes a particularly nasty problem with haddock, -XCPP, and clang based systems. This ghc-7.8.3 bindist is available as well: - ghc-7.8.3-x86_64-apple-darwin-r3.tar.bz2 <http://www.ozonehouse.com/mark/platform/ghc-7.8.3-x86_64-apple-darwin-r3.ta…> - haddocks finally cross link between packages correctly - includes a new experimental activate-hs command that can switch between multiple installed versions of the platform - includes a slightly updated uninstall-hs command - the cabal command is wrapped to provide a smoother file layout on the Mac... the wrapping only updates the ~/.cabal/config file the first time you run it.. please pay attention to its output - if you have a custom config file, you'll want to update it, as Cabal's defaults have changed - works on 10.7 (tested), 10.8 (assumed!), 10.9 (tested) - both with gcc and clang based Xcode installs. (Next RC will support back to 10.6!) - 64bit only build this time... anyone still want the 32bit build? Source tarball - Quite some changes from last time - notably now includes the new build machinery, not the old. - The build machinery is well tested (see the travis-ci link above) from a repo... not tested much from a source repo - It isn't clear the source repo is of much interest... anyone need it? anyone need anything beyond the haskell-platform.cabal file in it? Timetable - These can "soak" amongst the intreped on these lists for 48 hours. - On Saturday, I'll release any needed updated RCs, and announce to a wider audience - End of next week (from my vacation, I'll point out), we'll declare success and ship. — Mark P.S.: sha256 sums for the reasonably wary: 860cba2d65bc1790ec3b8a0a62c8aaf19f5b18e9070aa1ec3c468b7c6ca82697 Haskell Platform 2014.2.0.0 64bit RC1.signed.pkg 8ca8a994334bf846ac6a41ada381c51634b2fce0d68dc70b2dadf59cb8748397 haskell-platform-2014.2.0.0-RC1.tar.gz b034e2daa595e0d3827860b062afca05f62df64434b0923559acc99bd82ef1e9 HaskellPlatform-2014.2.0.0-i386-RC1-setup.exe e31fe5e0cb9dca330e6f0c62ac49bf70b79f555bfe11e8f04c47739fef224145 HaskellPlatform-2014.2.0.0-x86_64-RC1-setup.exe 8e479d9dd504b1c603cd51f3be0fa57ecdc996e842d655e39d97faafff3c2d31 ghc-7.8.3-x86_64-apple-darwin-r3.tar.bz2

2 7

Enhancement: Default cabal to `-p` profiling enabled
by Andrew Pennebaker 24 Jul '14

24 Jul '14

I love GHC's profiling support, and like to use it to analyze the performance of my Haskell applications. However, profiling an application is difficult when it depends on any third-party libraries, as cabal doesn't include profiling information by default. Fortunately, cabal can reinstall a library with profiling support, with: cabal install --reinstall -p <library> Unfortunately, cabal is a bit of a simpleton, so this will fail unless that libraries dependencies are also installed with profiling enabled: cabal install --reinstall -p <libraryX> <libraryY> <libraryZ> ... For example, a user who wants to profile his die-rolling program must run: $ sudo apt-get install haskell-platform haskell-platform-doc haskell-platform-prof $ sudo cabal install --reinstall -p mwc-random rvar random-fu random-source mersenne-random-pure64 stateref flexible-defaults th-extras MonadPrompt math-functions erf vector-th-unbox monad-loops random-shuffle MonadRandom And that long list of packages must be slowly grown one at a time, starting from random-source, based on many attempts at running cabal install --reinstall -p ..., waiting several minutes for compilation to partially complete, and scrolling back up through the logs to track down which dependencies also neglected to compile with profiling enabled. It can take a while to get a list of this long, full dependency chain. It would be much easier if cabal simply enabled `-p` by default, so we didn't have to think about it. What do you think? -- Cheers, Andrew Pennebaker www.yellosoft.us

9 11