March 2015 - Libraries

ansi-wl-pprint
by Edward Kmett 27 Mar '15

27 Mar '15

ansi-wl-pprint sits underneath a large chunk of our infrastructure: test-framework, criterion, trifecta, etc. Transitively through those dependencies it affects a very large percentage of the Haskell packages we have today, because you can't build almost anybody's testing and benchmarking frameworks without it. We recently had to push out an non-maintainer update for GHC 7.10-rc3 compatibility, and due to NMU update guidelines meant we had to wait 2 weeks before we could do anything. This pretty much ensured that the entire 7.10-rc3 release cycle went by with very very few people able to run their test suites, and little testing was able to be performed in the allotted window. Fortunately, Neil managed to find a rather large regression on his own during this time: http://neilmitchell.blogspot.com/2015/03/finding-ghc-bug.html That said, given that we found issues with linear caused by the changes to Typeable, once we fixed the test suite, this gives me pause. I'm pretty sure nobody downstream of linear tried to run their test suites on rc3. I'd like to not find ourselves in that situation again. We have a policy of considering requests for maintainership transfer after ~6 months of inactivity. Max has been inactive for over a year. I'd like to invoke that today, and formally request to take over maintainership of ansi-wl-pprint. All of the visible activity on https://github.com/batterseapower in the last year or so is on java projects. We've already adopted test-framework. In the event Max returns to active status in the Haskell community, I'd happily relinquish control. Thank you for your consideration, -Edward

4 4

quick report using GHC 7.10 RC3
by Mark Lentczner 26 Mar '15

26 Mar '15

I built up a provisional HP 2015.2.0.0 based on GHC 7.10 RC3, and then when testing it, built my medium-ish project Plush with it all. This is my first brush with 7.10 and the new base libs, Applicative, FTP and all. For the most part, it all worked, but here are some observations: *1. Cabal-1.22.1.2 isn't on Hackage* Boot strapping HP now needs to bootstrap cabal-install in order to be able to build with 7.10. My fancy-pants build system for HP doesn't do that (yet), so I did it by hand. Only hitch: Cabal 1.22.1.2 isn't on hackage, so I had to build with 1.22.1.1 - so the bootstrap wasn't perfect, but good enough to work. *2. Still need old-local and old-time* Because....wait for it... cabal-install needs them! So do cgi and HTTP packages. *3. Slower compilation* The platform used to take about 20min. to compile. Now it takes a full hour. Did GHC really slow down that much? The newer OpenGL and OpenGLRaw packages are significantly larger and slower, and that might account for about half the extra time... but still GHC seems much slower. *4. GHC is a disk monster* Now weighing in at 900+MB! That is 100MB over 7.8! *5. Warnings Galore* Of course most of the packages compile with tons of warnings. I mean tons! Looking at my own packages, since I usually compile -Wall, I will need tons of work to remove these. The saddness is that if I want my package to continue to work on 7.8 I'll have to put in tons of CPP statements. *6. Bit by additions to the Prelude* In particular, Word, since I had a data type named that. (It was in a grammar for the shell, and since Data.Word was no where near this, I claim it was a reasonable choice of name.) I had to add tons of import Prelude hiding (Word) statements. Adding common words as new exports from the Prelude is a real pain! *7. Cabal incompatible API change* In particular, the api that a custom Setup.hs uses. Distribution.Simple.UserHooks changed the type of a hook. It should not, it should have added another to do what it wanted. The poblem is you can't use CPP in Setup.hs. And so now anyone using the testHook hook is in a pickle: Your Setup.hs can't work in both 7.10 and 7.8! *8. Haddock messaging* What has gotten into Haddock? There is so much terminal output now - I just have to ignore it all. It spews more than the compiler does. *9. Library divergence* We have random... and now we'll have to have tf-random, too, because alex and QuickCheck both need it. So now we'll have two random libraries. Couldn't we have folded tf-random into random? On a similar front, we've got attoparsec, pulling in scientific. Couldn't that have gone somewhere? I realize that the trend is for many small minimal libs... but for the core that is going to all be there always anyway - and more closed set works better I think. Summary: 1, 2 & 8 are minor, 3 & 4 are sad. 5 ~ 7 will make the job of anyone who wants their code to work with even one prior major GHC rev. hard, and ugly. 9 is what makes me worry most... — Mark

3 2

Generalize filterM to Applicative
by David Feuer 26 Mar '15

26 Mar '15

Currently, filterM :: (Monad m) => (a -> m Bool) -> [a] -> m [a] filterM p = foldr go (return []) where go x r = do flg <- p x ys <- r return (if flg then x:ys else ys) We could change this to filterM :: (Applicative f) => (a -> f Bool) -> [a] -> f [a] filterM p = foldr go (pure []) where go x r = f <$> p x <*> r where f flg ys = if flg then x:ys else ys

7 12

TLS Support
by Dominic Steinitz 25 Mar '15

25 Mar '15

I don’t often venture an opinion here but I would be very much *against* using OpenSSL given the number of vulnerabilities it continues to experience. There’s http://www.mitls.org/wsgi/home which has been formally verified and our own https://hackage.haskell.org/package/tls. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com On 25 Mar 2015, at 09:08, libraries-request(a)haskell.org wrote: > Also, to this day we don't have any TLS library support in the platform, > which also is subject to debate of which crypto-library to use (and > there's also the question whether to use OpenSSL via FFI or a native TLS > reimpl). So the platform-included `HTTP` package is not even able to > access `https://` URLs which is quite sad, as this also holds back > `cabal-install`'s ability to access `https://`-only repositories.

1 0

Re: Cabal and simultaneous installations of the same package
by Michael Snoyman 25 Mar '15

25 Mar '15

I replied on the GSoC proposal itself, but since it was cross-posted to the mailing list, I'll include my comments here too: I've reviewed this proposal, and I think it outlines a step in a good direction. As I've discussed with Duncan in the past, my biggest concern around a system like this is the complexity of the UI for a developer; having to juggle different environments just to get basic work done could be a significant hurdle. As long as attention is paid to ensuring no "UI regression" for simple cases, I think this is worth pursuing. On Tue, Mar 24, 2015 at 7:17 PM Vishal Agrawal 1<vishal4556(a)gmail.com> wrote: > I am already planning to do a GSoC project based on it with a slightly > larger aim. You can find my work in progress proposal at > https://gist.github.com/fugyk/37510958b52589737274. Also I have written a > patch to make cabal non-destructive at > https://github.com/fugyk/cabal/commit/45ec5edbaada1fd063c67d6109e69efa0e732…. > Can you review the proposal and give me suggestions. >

1 0

Fixing Fix
by David Feuer 25 Mar '15

25 Mar '15

There are a good number of different packages that define either newtype Fix f = Fix (f (Fix f)) or something equivalent except for naming. Most of the name variation is in the name of the data constructor and/or record selector. This does not look like an ideal situation to me. Most problematically, the only way to convert one to another is with unsafeCoerce. I think it would be rather nice to choose one canonical place for this definition, and let everyone else use it. Ideally, it would be nice to use some GHC pattern magic and such to paper over the differences between the data constructor names, but I don't know if that's possible or not. David Feuer

6 15

Re: Cabal and simultaneous installations of the same package
by Vishal Agrawal 25 Mar '15

25 Mar '15

I am already planning to do a GSoC project based on it with a slightly larger aim. You can find my work in progress proposal at https://gist.github.com/fugyk/37510958b52589737274. Also I have written a patch to make cabal non-destructive at https://github.com/fugyk/cabal/commit/45ec5edbaada1fd063c67d6109e69efa0e732…. Can you review the proposal and give me suggestions.

1 0

Type roles for UArray?
by wren romano 24 Mar '15

24 Mar '15

So I was working on porting my libraries to work for GHC 7.10 and I ran into a snag. Unlike the concrete type Data.Array.Array, the concrete type Data.Array.Unboxed.UArray is defined as being nominal in the second type argument— is this a bug? If not, then why must it be nominal? Shouldn't (UArray a New) and (UArray a Old) have the same representation in memory? Using unsafeCoerce has always been safe here in the past... -- Live well, ~wren

5 6

Re: [haskell-infrastructure] wither the Platform
by Miëtek Bak 24 Mar '15

24 Mar '15

On 2015-03-23, at 18:13, Andrew Farmer <afarmer(a)ittc.ku.edu> wrote: > I personally just download the latest bindist from the GHC site and > bootstrap cabal myself. Partly this is because my work requires me to > have the latest GHC, so maybe I'm not in the HP's target demographic. > That said, I would love if there was a platform that just did that (+ > whatever is needed to get that to work). Maybe at the end of the > minimal install, give me a choice between stackage and hackage and set > the remote-repo in my cabal file appropriately. I’m happy to say `halcyon install --cabal-remote-repo=…` does just that. See the Halcyon tutorial and reference for details: https://halcyon.sh/tutorial/#install-ghc-and-cabal https://halcyon.sh/reference/#halcyon_cabal_remote_repo -- Miëtek https://mietek.io

1 0

Re: [haskell-infrastructure] wither the Platform
by Gershom B 24 Mar '15

24 Mar '15

On Mon, Mar 23, 2015 at 11:20 AM, Anthony Cowley <acowley(a)gmail.com> wrote: > > I don't understand this attitude. You say that neither new users nor package > authors agree with your stance on the HP, so you want to force their hands. > Presumably package authors know what they're doing for themselves, and the > majority of evidence we have is that new users who stick with the language > do not like the way the HP works > <https://reddit.com/r/haskell/comments/2zts44/wither_the_platform/>. No, this is not what I said. I was explaining that it rather difficult, even if we wanted to force their hands, to imagine that we could do so. I will say that I do not share your belief that package authors know what they are doing, in general. If they did, I would imagine that nearly all packages would ensure they would work with the current platform. But getting programmers to all agree on something like that is herding cats, and all it takes is a few people saying "feh on the platform" but nonetheless producing otherwise good packages that come into widespread use to _in general_ mean that many packages which directly or indirectly want to use those dependencies must also now split off from support for the platform. So I agree that people have voted with their feet, and we need to catch up to that. In fact, it seems to me from this discussion that there are only _two_ things we need to do to make the platform the recommended install path for all platforms again: 1) Incorporate the improvements to windows builds that have been pioneered by the MinGHC project (in particular so that platform-installed windows ghc can build the network package properly, and perhaps even the GL stuff). 2) Address the problem that in a sandbox you will get a different install plan depending on your global package db. I would suggest this be done by setting a default preference of the sandbox to ignore global packages, and allow that to be overridden with an easily configurable flag or setting or the like. That way, new users can pay the longer compile price for a guaranteed-safer experience, and more experienced users can choose to use / build up a broader library of packages they can share across sandboxes. (Certainly some "nix-like tricks" in cabal could also help address the repeated builds problem, but a flag can be implemented much more quickly as a short-term measure). All that said, I think it would _still_ be better if more package authors paid attention to backwards-compatibility across releases, and it would _still_ be better for new users if they didn't go off and bash their heads against the newest and least stable packages around. But that is indeed a different problem. Cheers, Gershom

1 0