July 2014 - Libraries

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

Is scanl' safe for foldr/build fusion?
by David Feuer 24 Jul '14

24 Jul '14

In a comment on trac #9345, nomeata proposed the implementation of Data.List.inits below. He indicates that the performance is very good, and wrote it in this fashion so it could fuse. My concern is that since seq is used in the argument to build, we need to make sure that fusion on the left will be safe. If I did the calculations right, this specifically requires that for all f, cons, nil, and bs, and all a≠_|_, the following "correct" expression e1 = a `cons` foldr cons nil $ foldr (\b g x -> (let b' = f x b in b' `seq` (b' : g b'))) (\b -> b `seq` []) bs a gives the same result as the fused expression e2 = a `cons` foldr (\b g x -> (let b' = f x b in b' `seq` (b' `cons` g b'))) (\b -> b `seq` nil) bs a I haven't been able to figure out how to prove this or give a counterexample, so far, but I have very little experience with such. myScanl' :: (b -> a -> b) -> b -> [a] -> [b] myScanl' 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 initsQ2 :: [a] -> [[a]] initsQ2 = map toListQ . myScanl' snocQ emptyQ

2 3

Re: At long last: 2014.2.0.0 Release Candidate 1
by Brandon Allbery 24 Jul '14

24 Jul '14

On Thu, Jul 24, 2014 at 8:09 AM, George Colpitts <george.colpitts(a)gmail.com> wrote: > Installed on the Mac, looks good, not sure if following is significant: > > ghc-pkg check > Warning: library-dirs: /opt/local/lib/ doesn't exist or isn't a directory > Warning: include-dirs: /opt/local/include/ doesn't exist or isn't a > directory > Warning: haddock-interfaces: > /Users/gcolpitts/Library/Haskell/ghc-7.8.3/lib/Cabal-1.20.0.1/doc/html/Cabal.haddock > doesn't exist or isn't a file > > did cabal install -j3 of threadscope, criterion, hlint, ghc-mod, > quickcheck, smallcheck and smartcheck > > Errrr. Whoever is making the Mac bindist should take care to avoid any MacPorts (or for that matter Homebrew) components slipping in to it; this will cause problems down the road. (The same goes for users; if you use MacPorts or Homebrew, wait for the Platform to be updated there and install from there, or you will end up with iconv etc. conflicts. Possibly a warning about this should be included in the install docs.) -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

2 1