May 2014 - Libraries - Haskell.org

Fwd: Re: Gearing up (again) for the next release: 2014.2.0.0
by Christian Maeder 28 May '14

28 May '14

forwarded to libraries(a)haskell.org (as I'm not on haskell-platform(a)projects.haskell.org) -------- Original-Nachricht -------- Betreff: Re: Gearing up (again) for the next release: 2014.2.0.0 Datum: Wed, 28 May 2014 15:55:18 +0200 Von: Christian Maeder <Christian.Maeder(a)dfki.de> An: Mark Lentczner <mark.lentczner(a)gmail.com> Kopie (CC): haskell-platform(a)projects.haskell.org <haskell-platform(a)projects.haskell.org>, Johan Tibell <johan.tibell(a)gmail.com>, Ganesh Sittampalam <ganesh(a)earth.li> Am 28.05.2014 07:05, schrieb Mark Lentczner: > *Please check over the current state of the packages and versions for > 2014.1: > * > > https://github.com/haskell/haskell-platform/blob/new-build/hptool/src/Relea… At least the packages network and HTTP have newer versions on hackage. Cheers Christian

1 0

Proposal: derive Typeable for Data.Monoid types
by Roman Cheplyaka 27 May '14

27 May '14

I was surprised to find out that wrappers like Last do not have Typeable instances. Let's add them. Roman

5 6

Re: [containers] Proposal: Change to the Data.Map Monoid
by Alec 21 May '14

21 May '14

On Wed, May 21, 2014 at 12:11 PM, David Thomas wrote: > For what it's worth, I'd find Semigroup v => Monoid (Map k v) both > more useful and less surprising There is something somewhat surprising about the (Monoid v) => Monoid (Map k v) instance never using v's mempty. > ...than the current unqualified monoid instance for all maps Also (and I may have missed this argument being made already, apologies if so): It would be weird if Data.Map had the new monoid behavior but Data.IntMap didn't. And then of course, it would be weird if Data.Map had it but Data.HashMap didn't. Data.Set should probably remain the same, though it might feel a bit weird that Map k () wasn't isomorphic to Set k. Anyway, the real upshot is that unordered-containers would probably need to move along with containers, and that in addition to the social problem of moving the community in general, there would be additional gnashing of teeth from implementors of other map types who have followed the convention laid down in the "signature" for Data.Map. -A

2 1

Is it an error to call hGetLine on a non-blocking Handle?
by Alain O'Dea 19 May '14

19 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks: I could really use an expert eye on this. I'm trying to get to the bottom of a very tenacious bug in the GHC Builder. The details of how this happens are documented separately for reference: https://gist.github.com/AlainODea/dc841046524cd7833da8 The Handles involved are returned by System.Process.runInteractiveProcess. They are non-blocking at the Illumos kernel level. It appears that maybeFillReadBuffer (called by hGetLine under the hood) treats EAGAIN as an error: http://hackage.haskell.org/package/base-4.7.0.0/docs/src/GHC-IO-Handle-Text… Is it expected that runInteractiveProcess would return non-blocking Handles for stdout and stderr? Is it an error to call hGetLine on a non-blocking Handle? Thanks, Alain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTaG1jAAoJEP0rIXJNjNSAxpwH/immeV301FEZx9o6Q0ODCuqK AUBnDHcjS9VBqhJ7XnuwkWXi83qNJhoi9P4RjamL3EGnScHVfa1mnpkX5T1IWCb4 S4lWxICbVH4tmFYOwHmElzi8vzBvgmsCueiU5uMJc66dteR4U2e9FHb9Vaurg222 dDwfIYu7mIEb/Fld4dqN+qFp9ZbVPxjBASVPlIDpZFY95+0hMq/s331B5T6zi/ZZ o63pYR2xkIScIlocEYaYJT67OssYxHScu6F/dOu4F4dllV013cP0x6/6ov4KCpBi fqM5WRid1UyTtCco2dXg7eRkzQxEMoVL0TpEQbDn/iWKJS99+rG3YSt5JYDbhTY= =xtDH -----END PGP SIGNATURE-----

3 4

'temporary' package
by Roman Cheplyaka 15 May '14

15 May '14

Hi Max, are you still maintaining the 'temporary' package? There's a breakage waiting to be fixed (with a patch): https://github.com/batterseapower/temporary/pull/12 If I don't hear from you in two days, I'll request maintainership and/or fork the package. Roman

22 50

Moving PrimMonad from the primitive package to base
by Johan Tibell 12 May '14

12 May '14

Hi, I'm pondering adding unfoldM, as generalization of fromList, to the unordered-containers package. unfoldM could, just like fromList, be implemented using mutation followed by freezing internally, making it much more efficient the repeatedly calling insert when building a HashMap. A typical use case of unfoldM would be constructing a HashMap from the content of a file. Here's the annoying issue: unfoldM could work in both ST and IO, but exposing those two versions to users is a bit annoying. Either I have to have to * provide unfoldIO, unfoldST, etc for all functions I want to expose that work over either ST or IO or * depend on primitive, which is mostly unmaintained since Roman got busy with other things. Even if primitive was maintained, having to add extra library dependencies to "bottom layer" libraries like unordered-containers is often not worth the cost (more dependency management, risk of breakages, etc.) Furthermore, the pixie dust that makes abstracting over ST and IO possible, is quite tightly tied to GHC and abstracting over it there makes sense to me. So I'm proposing we consider moving parts of primitive into base, in particular the Control.Monad.Primitive module (in some form)*. This is not a formal proposal at this point, just a request for thoughts. * Ideally I think GHC should provide some more abstraction on top of the primops. More or less every library that uses arrays/bytearrays (e.g. text, unordered-container, vector) define the same trivial wrappers around indexArray# etc. -- Johan

2 1

Strictifying monadic values, take 3
by David Luposchainsky 12 May '14

12 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (HTML-rendered version of the text below see [1]) Strictifying Monadic values =========================== Half a year ago, Johan Tibell proposed adding a strict equivalent to fmap [2]. This discussion got lost in details, it was reopened, it ended in bikeshedding again. This is a third attempt to get this through, with individual options and no alternatives proposed, compiled from the two more popular responses in the other threads. Please do not propose alternative implementations here, we've been through this twice already. Vote ±1 on each point to show (dis)agreement. I think this functionality should be in the standard libraries in one way or another, regardless of how it's named in the end. 1. Add a strict version of <$>, named <$!>. ```haskell infixl 4 <$!> (<$!>) :: Monad m => (a -> b) -> m a -> m b f <$!> m = do x <- m return $! f x ``` This is closely related to fmap in terms of functionality, but requires a Monad constraint. This would allow defining ```haskell seqM m = id <$!> m ``` if such a function is needed. 2. Add a seqM function that evaluates the "contents" of a monadic action to WHNF. ```haskell seqM :: Monad m => m a -> m a seqM m = do x <- m return $! x ``` This is less close to fmap, but allows building other strict operations (locally and as needed) based on it easier, for example ```haskell f <$!> x = seqM ( f <$> x) mf <*!> mx = seqM (mf <*> mx) mf <*! mx = seqM (mf <* mx) mf *!> mx = seqM (mf *> mx) ``` If these operators then turn out to be used (and locally reinvented) very often by different people, reconsider adding them as well. A voting period of two weeks (until 10-05-2014) should be sufficient to allow everyone to join in. Greetings, David Links: [1]: https://github.com/quchen/articles/blob/master/seqm_proposal.md [2]: http://www.haskell.org/pipermail/libraries/2013-November/021728.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTXAWmAAoJELrQsaT5WQUs9GgH/3Vr2nDUDyX7pU24Vs0Dfq6e 43xcgY5ZBXCk/v/L6b14DA2br+jc32GkAnwkoWvJYQDNc6E6QwdPUnyaFpNPthA3 7NDcuGukJPzpkkA/YCVqq4Yu6jIwjcVm/xMQaRmASWMnlJxEypFuuMirWVUgg+ED Zl9x2VUoFUoRq6TpE1TGcOS0eoevqvu7LDdTJkGEC7wNxZOD4a2hjyiv90e2LmYL mP0pPKVj2NfSjIfDa/q+ONIHN+hrQqriku9OJSGU8UVxOfAvi86W42xsFV6fNdVE OKc/TTKM4V23G7qw3Dpz1EGnXqqLdYlv1ck2EF05tmSOjJ6Bx2lAUBypRyjX6IA= =+wNo -----END PGP SIGNATURE-----

5 5

Re: 'temporary' package
by James Curbo 11 May '14

11 May '14

To add to this remark, Debian has an explicit process for situations just like this called Non-Maintainer Uploads (NMUs) which you can read about here: https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu It seems like having a similar capability within Hackage, or more defined policy about when it kicks in, would be a good idea. The way it works in Debian, the original maintainer is not stripped of his role and a fork is not necessary. NMUs are often only done in extreme cases where the changes are small. (extreme breakage of a library, fixing security vulnerabilities, and so on) Of course, collaborative maintenance helps as well, but ultimately it's helpful to have some process to deploy quick fixes in a timely manner. James Michael Alan Dorman wrote: > I will observe that over the years, the Debian project has gradually > evolved toward shared, or even group, maintainership for important > packages---for the same reason: someone fafiates and the whole ecosystem > starts piling up behind an important package whose maintainer is > unresponsive. > > Mike. > > Niklas Hambüchen<mail(a)nh2.me> writes: > >> It's also worth mentioning that Hackage 2 has a nice "multiple >> maintainers" functionality, see for example this: >> >> http://hackage.haskell.org/package/tasty/maintainers/ >> >> It's not a very visible feature though, the package page doesn't like it >> and it's not visible how many maintainers a package has (where having >> more than one could be a good quality metric that maybe should be >> advertised). >> >> How about automatically bothering single maintainers with a "do you not >> want to add another maintainer on Hackage" email once they exceed some >> popularity threshold? >> >> As an example, the "6289 downloads in last 30 days" would make a nice >> popularity indicator. >> >> On 09/05/14 18:05, Niklas Hambüchen wrote: >>> On 09/05/14 16:14, Carter Schonwald wrote: >>>> You do raise a good point, should taking over maintainership of a >>>> library adhere to PVP expectations? >>> I don't think so - taking over maintainership should be a last >>> resort in >>> my opinion. >>> >>> Having backup maintainers becoming common seems a better solution. >>> _______________________________________________ >>> Libraries mailing list >>> Libraries(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries >>> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries

4 3

Haddock issue tracker is now on GitHub.
by Mateusz Kowalczyk 10 May '14

10 May '14

Greetings, The Haddock issue tracker now lives at [1]. The reasoning is that a lot of people have a GitHub account already and signing up just for Trac is tedious. Hopefully this will also allow people to see more easily what's going on. This also removes the maintenance load from Haskell infrastructure: the Trac instance has been bitrotting quite a bit and recently even sending out e-mail about tickets stopped working. Old issues have been migrated over so the ticket numbers still correspond. Please file any new issues or make issue comments on GitHub. If you do not wish to use GitHub (which is fairly understandable) then please send me the report directly and I will create one for you. Thanks. [1]: https://github.com/haskell/haddock/issues?state=open -- Mateusz K.

1 0

Re: 'temporary' package
by Roman Cheplyaka 09 May '14

09 May '14

* Jake McArthur <jake.mcarthur(a)gmail.com> [2014-05-07 08:38:29-0400] > It's more than just pushing a button. Who knows what kind of free time > somebody has (they might only be able to bother with github stuff once a > week...) Having backup maintainers is the answer. http://ro-che.info/articles/2014-02-08-my-haskell-will.html > or what kind of procedures they have for verifying a package meets > their standards before blessing it? The change is trivial. > This seems unreasonable, to me. Ok. > On May 7, 2014 8:36 AM, "Roman Cheplyaka" <roma(a)ro-che.info> wrote: > > > No. In my opinion, there's no good reason why a package should remain > > broken for > > more than a day, given that there are people who has found, reported, and > > fixed > > the issue. All the actual work is done, now someone just has to push a > > button. > > > > * Oliver Charles <ollie(a)ocharles.org.uk> [2014-05-07 13:29:40+0100] > > > Isn't a 4 day turn around on a pull request a little hasty? > > > > > > - ocharles > > > > > > > > > On Wed, May 7, 2014 at 8:50 AM, Roman Cheplyaka <roma(a)ro-che.info> > > wrote: > > > > > > > Hi Max, > > > > > > > > are you still maintaining the 'temporary' package? > > > > There's a breakage waiting to be fixed (with a patch): > > > > https://github.com/batterseapower/temporary/pull/12 > > > > > > > > If I don't hear from you in two days, I'll request maintainership > > and/or > > > > fork the package. > > > > > > > > Roman > > > > > > > > _______________________________________________ > > > > Libraries mailing list > > > > Libraries(a)haskell.org > > > > http://www.haskell.org/mailman/listinfo/libraries > > > > > > > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > >

4 5