- Libraries - Haskell.org

'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

transformers 0.4: change in accessor function exports?
by Michael Snoyman 07 May '14

07 May '14

One of the changes[1] in transformers 0.4 is as follows: 0.3: newtype Identity a = Identity { runIdentity :: a } 0.4: newtype Identity a = Identity a runIdentity (Identity x) = x While this may seem benign, I've already seen three cases where this caused breakage[2][3][4]. Is there a reason for this change in 0.4? If not, I'd like to request moving back to the previous formulation to avoid unnecessary breakage. Michael [1] http://hdiff.luite.com/cgit/transformers/commit/Data/Functor/Identity.hs?id… [2] https://github.com/fpco/streaming-commons/pull/5 [3] https://github.com/ekmett/exceptions/pull/29 [4] https://github.com/ekmett/mtl/commit/d1a6253886a99215d5ff6afe3632b27e696d40…

15 31

Re: geniplate bump to template-haskell-2.9
by Carter Schonwald 04 May '14

04 May '14

Ok good! I did it earlier today / yesterday. (Happy to hear that it's kosher on your side ) On Sunday, May 4, 2014, Augustsson, Lennart <Lennart.Augustsson(a)sc.com> wrote: > I’ve been away on vacation, but I totally approve of the bump. > > > > *From:* Carter Schonwald [mailto:carter.schonwald@gmail.com<javascript:_e(%7B%7D,'cvml','carter.schonwald(a)gmail.com');>] > > *Sent:* 04 May 2014 17:23 > *To:* Andreas Abel > *Cc:* admin(a)hackage.haskell.org<javascript:_e(%7B%7D,'cvml','admin(a)hackage.haskell.org');>; > Ulf Norell; Haskell Libraries; Augustsson, Lennart > *Subject:* Re: geniplate bump to template-haskell-2.9 > > > > Since this has apparently been blocking agda release for over a month, > i've taken action. > > > > Note that because Lennart doesnt have a publicly available repository for > geniplate, 0.6.0.4 is just a bumped version of 0.6.0.3, > > > > This does raise the question of what the default hackage admin/trustee > policy for libraries that need a fix like this should be, where the > maintainer is active in the community but is hard to reach for a month or > so. > > > > (and whether any particular default policy should be "opt in" vs "opt > out".) > > > > > > anyways, ship the new agda goodness please :) > > > > > > > > On Sat, May 3, 2014 at 1:27 PM, Carter Schonwald < > carter.schonwald(a)gmail.com> wrote: > > ok, cool! NB: i will try to email lennart one more time after the "block > leave" on his auto reply is over (at EdwardK's suggestion), so may 6th, and > if that doesn't get a reply in a day or so, i've the thumbs up from 2+ core > libraries committee members to push the fix myself > > > > On Sat, May 3, 2014 at 7:30 AM, Andreas Abel <abela(a)chalmers.se> wrote: > > Dear Carter, > > thanks for taking care of this. I have no desire of becoming > maintainer of geniplate. > > The only changes to geniplate required are version bumps. The new > cabal file has been attached to several of my message, and also in the > one publicly linked (far) below, but voila, here is it again. > > It also puts some constraints on mtl to avoid using the broken 2.1. > > Cheers, > Andreas > > P.S.: Sorry for the slow response, I have been moving and had problems > sending email. > > > On 01.05.2014 01:15, Carter Schonwald wrote: > > looks like "I will be on block leave from April 18 to May 5." for Lennart > > > > could you link me to the fixes needed? I'll ping several other admins > > for their thoughts, and then if its reasonable i'll do the upload > > > > > > On Wed, Apr 30, 2014 at 7:11 PM, Carter Schonwald > > > <carter.schonwald(a)gmail.com <mailto:carter.schonwald@gmail.com>> wrote: > > > > since i don't recall seeing the original thread on the libraries > > list (seriously, i never saw it on the libraries list!), and i don't > > see the email to lennart, i'm CCing lennart to double check, > > > > @andreas, what fixes are needed to Geniplate, could you provide a > > link? If they're conservative, I can upload them as a trustee later > > this evening, and then we can sort out maintainership in the next > > week (and not have Agda's ghc-7.8 friendly release be blocked). > > > > > > > > > > On Wed, Apr 30, 2014 at 5:20 PM, Andreas Abel > > > <andreas.abel(a)ifi.lmu.de <mailto:andreas.abel@ifi.lmu.de>> wrote: > > > > Dear hackage admins, [CC: libraries(a)haskell.org > > > <mailto:libraries@haskell.org>] > > > This email and any attachments are confidential and may also be > privileged. If you are not the intended recipient, please delete all copies > and notify the sender immediately. You may wish to refer to the > incorporation details of Standard Chartered PLC, Standard Chartered Bank > and their subsidiaries at > http://www.standardchartered.com/en/incorporation-details.html > > Insofar as this communication contains any market commentary, the market > commentary has been prepared by a sales and/or trading desk of Standard > Chartered Bank or its affiliate. It is not and does not constitute research > material, independent research, recommendation or financial advice. Any > market commentary is for information purpose only and shall not be relied > for any other purpose, and is subject to the relevant disclaimers available > at > http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx. > > Please visit > http://wholesalebanking.standardchartered.com/en/capabilities/financialmark… important information with respect to derivative products. >

2 1

Re: geniplate bump to template-haskell-2.9
by Andreas Abel 04 May '14

04 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear hackage admins, [CC: libraries(a)haskell.org] Another week has passed without action from either package maintainer or hackage admins. Am I following this protocol correctly? http://www.haskell.org/haskellwiki/Taking_over_a_package If I am lacking, let me know where, otherwise please do your part. Sincerly, Andreas On 23.04.2014 18:35, Andreas Abel wrote: > Dear Lennart, > > since we want to release Agda-2.3.4 soon to work with ghc-7.8, we > need a version of geniplate that works with new template haskell. > All that is required is an update of version bounds in the cabal > file (attached). > > Since you have not responded to our request, I am following > procedure > > http://www.haskell.org/haskellwiki/Taking_over_a_package > > to be able to upload an updated version of geniplate. > > Dear Hackage admins, > > here is proof of my public request for the update of geniplate: > > http://osdir.com/ml/libraries@haskell.org/2014-04/msg00191.html > > Please give me rights to upload a new version or do the dependency > bumps yourself (new cabal file attached). > > Cheers, AndreasAbel (hackage account id) > > - -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www2.tcs.ifi.lmu.de/~abel/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNhaQkACgkQPMHaDxpUpLMSXgCfeU4ENXuReT6GeGhX4GVOWpXs JS0An016Bmq4MEA4EmwXJpmWgmRCUXoe =K9mb -----END PGP SIGNATURE-----

4 6

Re: RFC: include a cabal-install executable in future GHC releases
by Johan Tibell 04 May '14

04 May '14

Thanks. Between you and Mikhail we got the Windows side covered. :) On Sun, May 4, 2014 at 11:13 AM, Niklas Larsson <metaniklas(a)gmail.com>wrote: > Hi! > > I put a Windows build here: > https://www.dropbox.com/s/at7wc1dh0lfr7lc/cabal.exe.zip > > Niklas > 2014-05-04 2:24 GMT+02:00 Johan Tibell <johan.tibell(a)gmail.com>: > > I just uploaded 1.20.0.1 so there's only an OS X binary so far. I'm >> waiting for someone to send me a Windows one. >> >> >> On Sun, May 4, 2014 at 2:06 AM, Ashley Yakeley <ashley(a)semantic.org>wrote: >> >>> I couldn't find them, and they're not listed at < >>> http://www.haskell.org/cabal/download.html> (except OS X), or at < >>> http://www.haskell.org/haskellwiki/Cabal-Install>, or at < >>> http://hackage.haskell.org/package/cabal-install>. >>> >>> -- Ashley >>> >>> >>> On 2014-05-03 17:00, Carter Schonwald wrote: >>> >>>> I think there's now hosted official cabal install binaries online. I'm >>>> Afk but they should be a short google away. Should be linked more >>>> prominently though >>>> >>>> On Saturday, May 3, 2014, Ashley Yakeley <ashley(a)semantic.org <mailto: >>>> ashley(a)semantic.org>> wrote: >>>> >>>> So I want to install GHC + cabal on a new system, building cabal >>>> packages with profiling and documentation. Here's what I have to do: >>>> >>>> 1. Download, unpack and install GHC. >>>> >>>> 2. Download and unpack cabal-install, and run bootstrap.sh. As >>>> part of the bootstrap, it will download and build a bunch of >>>> packages. >>>> >>>> 3. Delete the downloaded packages ("rm -rf ~/.ghc/*") because they >>>> were built without profiling or documentation. >>>> >>>> 4. Call "cabal update" to get a default .cabal/config file. >>>> >>>> 5. Edit .cabal/config to switch on library-profiling, >>>> executable-profiling, and documentation. >>>> >>>> 6. Build my stuff. >>>> >>>> This would be much simplified if binary versions of cabal-install >>>> were available. (It would be even simpler if they were just >>>> included in the GHC builds -- I could eliminate 2 & 3.) >>>> >>>> -- Ashley Yakeley >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users(a)haskell.org >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>>> >>>> >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >>> >> >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> >

1 0