September 2012 - Libraries

Haskell Platform proposal: Add the vector package
by Johan Tibell 08 Oct '12

08 Oct '12

Hi, I am, with Roman's support, making a formal proposal to have the vector package included in the Haskell Platform: http://trac.haskell.org/haskell-platform/wiki/Proposals/vector See the wiki page for details, and a list of open issues for discussion. The vector package itself can be found on Hackage: http://hackage.haskell.org/package/vector I have set the deadline to 13 August 2012 (~2 months' time), with comments due by 13 July 2012 (~one month). There's plenty of time before the next platform release anyway (scheduled for 12 November 2012). -- Johan

16 82

Compilation of directory package on GHC 7.4
by Dominique Devriese 05 Oct '12

05 Oct '12

Dear maintainers, The directory package is currently not compiling on GHC 7.4, leading to a compile failure of packages that depend on it. Hackage has a build failure log for GHC 7.4. I propose the attached patch, although I have not tested it on GHC 7.6. Can this (or an alternative fix) please be considered? Thanks in advance, Dominique Devriese

4 4

makeRelative
by Jon Fairbairn 01 Oct '12

01 Oct '12

I have an application where I want to use relative paths in symlinks (so that rsyncing to a different machine with a different root directory produces something with the same effect). So I want makeRelative "/var/www/this_server/foo/bar/" "/var/www/this_server/bob" to return "../../bob" (which would then be used to create a symlink) so that if I copy the tree below /var/www/this_server to /var/www/that_server (perhaps on a different machine, but copying the symlinks without rewriting them), the symlinks point to the same files. On posix at least, this would permit isRelative (makeRelative a b) always to be True, which is a pleasant property for it to have. Is there any reason that System.FilePath.Posix.makeRelative should not do this? I don’t know enough about non-posix filesystems to know whether it even makes sense elsewhere. -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk

6 7

Re: need package maintainer's input for Haskell Platform
by Mark Lentczner 29 Sep '12

29 Sep '12

For the upcoming HP 2012.4.0.0 release I'd like package maintainers to confirm of which version should go in the release. I have not received input on the following packages, listed with who I think the maintainer is (which might be wrong): - *cgi* — Anders Kaseorg - *html* — Don Stewart - *parsec* — Antoine Latter - *regex-base*, *regex-compat*, *regex-posix* — Christopher Kuklewicz If these are your packages, please see the message below and contact me directly ASAP. If you know these please please ping them gently for me. :-) If I don't hear from them, I'll use the same version that is in 2012.2.0.0, which will not be the latest version. (Except for html, so I suppose Don is off the hook... but I'd still like to hear confirmation!) I will release the version list on Monday, October 1st. - Mark On Fri, Sep 21, 2012 at 6:06 AM, Mark Lentczner wrote: > You are receiving this e-mail as hackage lists you as the maintain of one > or more packages that are part of Haskell Platform (or are being considered > in active proposals). The list I have is given below - you are all bcc'd so > that replies will go directly to me. > > I need your help to get the next release of Haskell Platform out: > > *1. **If you are not the current maintainer of the package(s)* I think > you are, please let me know immediately. If you are a mailing list, please > let me know the key individual contact for this sort of communication, as > it is going to happen with every HP release. > > 2*. **Which version of your package(s) should be in the next release of > HP?* In the past we always bumped to lastest on Hackage, but that has > caused some instability of the HP build, and stability is what it's all > about. So, please, let me know the exact version of your package that > should be in HP 2012.4.0.0. > > > At present it looks like HP 2012.4.0.0 will go out with GHC 7.4.2, so > versions should build against that. Please let me know if there would be a > difference if we shipped with GHC 7.6.x. > > — Mark >

2 2

Data.Foldable.foldr1 too strict
by Henning Thielemann 28 Sep '12

28 Sep '12

I found that the default implementation of foldr1 in Data.Foldable is too strict (and foldl1, too). It always evaluates the complete spine of an input list: -- taken from base-4.6:Data.Foldable.foldr1 foldr2 f xs = fromMaybe (P.error "foldr1: empty structure") (Fold.foldr mf Nothing xs) where mf x Nothing = Just x mf x (Just y) = Just (f x y) -- lazier version, only evaluates one item ahead foldr3 f xs = fromMaybe (P.error "foldr1: empty structure") (Fold.foldr mf Nothing xs) where mf x = Just . maybe x (f x) *Data.NonEmpty> foldr2 (P.++) $ "abc" : "def" : P.undefined "*** Exception: Prelude.undefined *Data.NonEmpty> foldr3 (P.++) $ "abc" : "def" : P.undefined "abc*** Exception: Prelude.undefined

6 5

Hackage2 server testing
by Ian Lynagh 25 Sep '12

25 Sep '12

Dear Haskellers, I am pleased to announce that a test instance of the Hackage 2 server is now running at http://new-hackage.haskell.org/ The plan is to test the new server for 3 weeks (until Monday 24 September), before switching over to Hackage 2 for real. The server has a mirror of Hackage from about a month ago, but more recent uploads are not automatically mirrored. In order to upload packages to it, you will need to sign up for an account and then mail the Hackage admins (hackage-admin(a)haskell.org) telling them your username and asking to be added to the 'uploaders' group. If you run into any problems, please either file a ticket tagged 'hackage2' at https://github.com/haskell/cabal/issues or send an e-mail to the cabal-devel(a)haskell.org mailing list. A few more details about the plan: Assuming no major issues are found, the plan for after Monday is to disable uploads to the current Hackage server, to make an up-to-date mirror of it, and then to switch over to Hackage 2. Finally, I would like to thank the Industrial Haskell Group (http://industry.haskell.org/) for funding this work. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

6 17

Proposal: Adding generics-based rnf-helper to `deepseq`
by Herbert Valerio Riedel 25 Sep '12

25 Sep '12

Hello Simon (et al.), Some time ago, the `generic-deepseq` package was announced to the haskell-cafe list, and some discussion took place[1], and the suggestion came up that it might useful to be included to `deepseq` somehow. IMHO, a least introduing way (which I've been using myself) would be to add something along the code below to the `Control.DeepSeq` module (only `genericsRnf` shall be exported, thus avoiding a PVP-major-bump): -- | Generics-based 'rnf' implementation genericsRnf :: (Generic a, GNFData (Rep a)) => a -> () genericsRnf = grnf_ . from {-# INLINE genericRnf #-} -- | Hidden type-class, /not/ exported class GNFData f where grnf_ :: f a -> () instance GNFData U1 where grnf_ !U1 = () {-# INLINE grnf_ #-} instance NFData a => GNFData (K1 i a) where grnf_ = rnf . unK1 {-# INLINE grnf_ #-} instance GNFData a => GNFData (M1 i c a) where grnf_ = grnf_ . unM1 {-# INLINE grnf_ #-} instance (GNFData a, GNFData b) => GNFData (a :*: b) where grnf_ (x :*: y) = grnf_ x `seq` grnf_ y {-# INLINE grnf_ #-} instance (GNFData a, GNFData b) => GNFData (a :+: b) where grnf_ (L1 x) = grnf_ x grnf_ (R1 x) = grnf_ x {-# INLINE grnf_ #-} this way, the client code can then chose to use a Generics-derived `rnf` implementation expliclity by simply declaring: instance NFData FooBar where rnf = genericsRnf ...does this sound sensible? cheers, hvr [1]: http://www.haskell.org/pipermail/haskell-cafe/2012-February/099551.html --

6 13

Call for consensus: addition of split package to platform
by Brent Yorgey 25 Sep '12

25 Sep '12

Hi everyone, Following the great feedback I got on the initial proposal, and after testing with the GHC 7.6 release candidate, I have just released split-0.2.0.0, which I am proposing for inclusion in the HP. The full proposal, links to previous discussion, etc. can be found on the wiki: http://trac.haskell.org/haskell-platform/wiki/Proposals/split Comments, questions, constructive criticism, etc. are still welcome, but this time around I hope we can build a consensus as to whether it should go in the platform or not. I would also like people's opinions on the one big question remaining: whether to use cabal's mechanisms to conditionally include some code, allowing the 'build' function to be taken from GHC.Exts when available, or defined manually otherwise. This would make split fully H2010-compatible. The currently released version does NOT include this, so it is H2010-compatible but GHC specific. The options are: 1) just use a generic version of 'build' (simplest option) 2) use only GHC's version of build (slightly faster) 3) do the conditional thing to choose between 1) and 2) at compile time (most general but most complicated/cumbersome) -Brent

2 2

HP 2012.4.0.0 -- No more proposals, Time to nail things down
by Mark Lentczner 21 Sep '12

21 Sep '12

As per the schedule, the call for proposals has ended. While the HP process allows proposals at anytime, I've set a cut off for those that will be included in the next release, HP 2012.4.0.0. The proposals before us, and my rough reading on state of the consensus of each, are: - *async* - general agreement to includ - *split* - general agreement to includ - *time-extras* - general agreement to exclude, as the instances it provided are now provided by *time* itself. - *vector* - rough agreement that the functionality should be in the platform with two sticking points: - remove the .Safe modules, I believe Roman has prepared a new version with this change - reconsider the name of the dependent *primitive* package, which would also have to be included. There is one more issue: *OpenGL* and *GLUT* in the platform are very down-rev, because later versions were split into a number of packages which didn't meet with agreement for inclusion in the platform. There has been discussion on what to do about this situation, but no proposals were made. We may run into a build issue, which might force a decision later in this release cycle. Now is the time for any further discussion of these matters. I will need to make go/no-go decisions for the 2012.4.0.0 release in little over a week: - *September 17th, 2012* - Call for proposals ends (no more proposals considered) - *October 1st, 2012* - Proposals decided, Initial version list - *October 15th, 2012* - First candidates — Mark *keep them doggies movin'* Lentczner**

1 0

MIN_VERSION_foo() macro vs. CABAL-flag directed API-adaption
by Herbert Valerio Riedel 20 Sep '12

20 Sep '12

Hello, When I noticed the recently released HTTP-4000.2.5[1] package used a CABAL-flag based approach[2] for what I expected the use of a macro MIN_VERSION_network(2,4,0) to be more appropriate (see [3]), I wasn't totally sure whether there was any down-side with the MIN_VERSION_-approach. So my question is: Is it always desirable to prefer the MIN_VERSION_ approach over a CABAL-flag approach for supporting multiple API versions of a dependent package (if both ways are possible)? And if not, when should I prefer which approach? [1]: http://hackage.haskell.org/package/HTTP-4000.2.5 [2]: https://github.com/haskell/HTTP/commit/7a266219284ff33d66fa5e3f67f406c2616f… [3]: https://github.com/haskell/HTTP/pull/30 cheers, hvr --

5 6