- Libraries - Haskell.org

Re: Takeover of hashable and uuid & uuid-types packages
by Oleg Grenrus 16 Feb '21

16 Feb '21

Thank you Johan. Could you add me as maintainer on Hackage as well, my username is phadej there as well. Cheers, Oleg. On 16.2.2021 18.59, Johan Tibell wrote: > Done. > > On Tue, Feb 16, 2021 at 5:54 PM Simon Jakobi > <simon.jakobi(a)googlemail.com <mailto:simon.jakobi@googlemail.com>> wrote: > > Sounds reasonable to me! > > Am Di., 16. Feb. 2021 um 17:42 Uhr schrieb Oleg Grenrus > <oleg.grenrus(a)iki.fi <mailto:oleg.grenrus@iki.fi>>: > > I don't disagree. Having hashable live next to > unordered-containers in > https://github.com/haskell-unordered-containers would be fine > too, if you, David, agree with that. > > - Oleg > > On 16.2.2021 18.37, David Feuer wrote: >> My general view is that it's best for each package (or >> closely allied family of packages) to have its own GitHub >> organization. >> >> On Tue, Feb 16, 2021, 11:27 AM Oleg Grenrus >> <oleg.grenrus(a)iki.fi <mailto:oleg.grenrus@iki.fi>> wrote: >> >> github.com/haskell <http://github.com/haskell> is fine >> too. I have uneasy feeling about its current "chaotic >> good" management model though, but I can live with it. >> >> OTOH, you can simply bother me about any package in >> haskellari org. Clear and simple. >> >> - Oleg >> >> On 16.2.2021 17.56, Johan Tibell wrote: >>> I'm not involved anymore so it's fine by me but why >>> not https://github.com/haskell? >>> >>> On Tue, Feb 16, 2021 at 4:26 PM Oleg Grenrus >>> <oleg.grenrus(a)iki.fi <mailto:oleg.grenrus@iki.fi>> wrote: >>> >>> I ask to take over the maintenance of hashable, uuid >>> and uuid-types >>> packages. >>> >>> I'm a maintainer of packages depending on them (most >>> notably >>> quickcheck-instances and aeson). >>> >>> I should also mention that when we (Herbert and I) >>> took over Antoine >>> Latter's packages, I took over quickcheck-instances >>> and Herbert took >>> over uuid and parsec. We should taken over together >>> in the first place. >>> >>> My first points of action would be: >>> - make a releases supporting latest versions of >>> dependencies (GHC-9.0, >>> bytestring-0.11) and >>> - move packages to https://github.com/haskellari >>> organization, so in >>> case of my absence there are people (Ryan Scott, >>> bodigrim, few others) >>> who will be able to act. >>> >>> Best regards, >>> Oleg >>> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org <mailto:Libraries@haskell.org> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org <mailto:Libraries@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

1 0

[ANN] bytestring-0.11.1.0
by Andrew Lelechenko 16 Feb '21

16 Feb '21

On behalf of maintainers I'm happy to announce that bytestring-0.11.1.0 (http://hackage.haskell.org/package/bytestring-0.11.1.0) is finally released. Highlights from the changelog (https://github.com/haskell/bytestring/blob/0.11.1.0/Changelog.md) * Performance improvements for * strict `map` (up to 30% faster), * strict `pack`, `words`, `intersperse`, `findIndex` and `findIndexEnd`, * lazy `takeWhile`, `dropWhile`, `break`, `group` and `groupBy`, * strict and lazy `stimes`. * New functions: * `compareLength` to compare lengths lazily, * `packZipWith` to zip two `ByteString`, * `findIndexEnd` for `Char8` flavours of `ByteString`, * `elemIndexEnd` and `unzip` for `Data.ByteString.Lazy.Char8`, * `takeEnd` and `dropEnd` for strict `ByteString`. * Improvements for `ShortByteString` * `SBS` constructor is now exposed directly from `Data.ByteString.Short`, * `fromShort` does not reallocate its argument, if it is already pinned. Many people contributed their time and effort to make this release happen. Just to name a few in no particular order, mostly according to `git log`: * Ben Gamari * Callan McGill * Dmitry Ivanov * Eli Kogan-Wang * gutjuri * Jaro Reinders * John Ericson * Moritz Angermann * Simon Jakobi * Sylvain Henry * Viktor Dukhovni * Vincent Orr * me Here is an incantation for `stack` folks: resolver: nightly-2021-02-12 packages: - . extra-deps: - bytestring-0.11.0.0 - binary-0.8.8.0 - directory-1.3.6.1 - text-1.2.4.1 - unix-2.7.2.2 - process-1.6.11.0 allow-newer: true Best regards, Andrew

1 0

Takeover of hashable and uuid & uuid-types packages
by Oleg Grenrus 16 Feb '21

16 Feb '21

I ask to take over the maintenance of hashable, uuid and uuid-types packages. I'm a maintainer of packages depending on them (most notably quickcheck-instances and aeson). I should also mention that when we (Herbert and I) took over Antoine Latter's packages, I took over quickcheck-instances and Herbert took over uuid and parsec. We should taken over together in the first place. My first points of action would be: - make a releases supporting latest versions of dependencies (GHC-9.0, bytestring-0.11) and - move packages to https://github.com/haskellari organization, so in case of my absence there are people (Ryan Scott, bodigrim, few others) who will be able to act. Best regards, Oleg

1 0

Maintenance of text-icu (Bryan O'Sullivan)
by Andreas Abel 14 Feb '21

14 Feb '21

Package text-icu (Bryan O'Sullivan) seems to be unmaintained since 2017 https://github.com/haskell/text-icu/issues/30 with the last release in 2015 https://hackage.haskell.org/package/text-icu-0.7.0.1 Unfortunately, the latest release is incompatible with ICU 68. Has anyone heard from Bryan recently? I mean, he is a Haskell celebrity... His last activity on github.com was in August 2017. Anyone interested in maintaining this package? Since Agda depends on text-icu, I could stand in as a temporary maintainer to at least merge the most important pull requests, until there is a new maintainer. Best regards, Andreas

3 5

Unix package maintenance
by chessai 07 Feb '21

07 Feb '21

All, The unix package, a core library, has been stalling. (just some examples, going back up to 6 years: [1] [2] [3] [4]). Previously, unix was maintained by HVR, a prolific maintainer and open source contributor of the Haskell ecosystem. His work to date has been invaluable for many of us today. However, recently, he's been increasingly unavailable, which happens and is perfectly understandable - life happens. But, the ecosystem cannot stall (eg [5], [6]) because of a single contributor, regardless of that contributor's merits or previous work. Right now, we have many useful (and in some cases necessary for other work, e.g, for hackage-server 2.0) patches to unix which need to be acted on. Additionally, there are potential maintainers willing to do the work ([7], [8], [9], [10]). On behalf of the CLC, which owns unix, I am announcing that the unix library will henceforth be under maintainership of the aforementioned individuals, who are all trusted and knowledgeable members of the community, looking to improve the library. I appreciate everyone who has contributed code to unix, maintained unix in the past, and those who stepped forward to help maintain it going forward. I hope that these changes will help facilitate positive growth for the library and ultimately the community, as they have with other core libraries which have recently been given new supplies of maintainers. [1]: https://github.com/haskell/unix/pull/145 [2]: https://github.com/haskell/unix/pull/21 [3]: https://github.com/haskell/unix/pull/110 [4]: https://github.com/haskell/unix/pull/122 [5]: https://github.com/haskell/zlib/pull/37 [6]: https://github.com/haskell/zlib/pull/39#issuecomment-774598088 [7]: https://github.com/hs-viktor [8]: https://github.com/Bodigrim [9]: https://github.com/emilypi [10]: https://github.com/davean

2 1

Bikeshedding the cstringLength name?
by Viktor Dukhovni 26 Jan '21

26 Jan '21

An equivalent function of course already exists outside base: $ hoogle 'CString -> IO CSize' Data.ByteString.Internal c_strlen :: CString -> IO CSize unsurprisingly defined as: foreign import ccall unsafe "string.h strlen" c_strlen :: CString -> IO CSize Would it make sense to give the proposed new Foreign.C.Types function the same "c_strlen" name? And then at some point in the future, Data.ByteString.Internal can just re-export it? Would using `cstringLength`, as proposed, be too confusable with the `cstringLength#` primop? -- Viktor.

2 2

Improving the instances of Data.Functor.{Product,Sum}
by chessai . 25 Jan '21

25 Jan '21

Consider the Eq instance for these types. Currently we rely on: (Eq1 f, Eq1 g, Eq a) But some potential improvements include changing to: (Eq (f (g a))) (FlexibleContexts) or (forall x. Eq x => Eq (f x), forall x. Eq x => Eq (g x), Eq a) (QuantifiedConstraints) There was a discussion sometime last year about the same thing regarding Semigroup/Monoid instances for `Compose` [1]. Additionally, the question has been raised again for Data.Functor.{Product,Sum} on Gitlab [2, 3]. There has been no consensus in either case, but that's not too worrying as both discussions have been brief. I'm currently not happy with the {Eq,Ord,Show}{1,2} family of classes, and would hope to work toward their removal, or at least the shrinking of their presence in base. Even though the linked proposals are about a single type, I think it's important that we come up with a decision and stick with it. Having different APIs for different types here would be pretty confusing, and some could even say sloppy. Please let me know your thoughts. [1]: https://mail.haskell.org/pipermail/libraries/2019-July/029771.html [2]: https://gitlab.haskell.org/ghc/ghc/issues/17015 [3]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1704

10 22

Proposal: Add atomic IORef operations to Data.IORef
by David Feuer 25 Jan '21

25 Jan '21

GHC.IORef currently exports atomicModifyIORef2 :: IORef a -> (a -> (a,b)) -> IO (a, (a, b)) atomicSwapIORef :: IORef a -> a -> IO a atomicModifyIORef2 is a lot like atomicModifyIORef, but it returns both the old value in the IORef and the full result of applying the user-supplied function to that. This is a pretty thin wrapper around the newish atomicModifyMutVar2# primop, which has replaced the less powerful atomicModifyMutVar#. atomicSwapIORef atomically installs a user-supplied value in an IORef and returns the old value. It is currently implemented using atomicModifyIORef2, but it can and should be reimplemented using its own, more efficient primop. I propose to add both of these functions to Data.IORef. David

4 8

expose strlen from Foreign.C.String
by chessai 23 Jan '21

23 Jan '21

I've wanted the following before: foreign import ccall unsafe "strlen" cstringLength# :: Addr# -> Int# cstringLength :: CString -> Int cstringLength (Ptr s) = I# (cstringLength# s) A natural place for this seems to be Foreign.C.String. Thoughts?

7 14

Re: Proposal: Add atomic IORef operations to Data.IORef
by David Feuer 15 Jan '21

15 Jan '21

Please do feel free to suggest a better name. I would certainly have named it better had I been able to think of one. On Fri, Jan 15, 2021 at 3:33 PM <olivercharles(a)fastmail.com> wrote: > > I would suggest better naming that suffixing with '2', if the suggestion was to add them with the same names as GHC.IORef > On 15 Jan 2021, 20:05 +0000, David Feuer <david.feuer(a)gmail.com>, wrote: > > GHC.IORef currently exports > > > atomicModifyIORef2 :: IORef a -> (a -> (a,b)) -> IO (a, (a, b)) > > atomicSwapIORef :: IORef a -> a -> IO a > > > atomicModifyIORef2 is a lot like atomicModifyIORef, but it returns > > both the old value in the IORef and the full result of applying the > > user-supplied function to that. This is a pretty thin wrapper around > > the newish atomicModifyMutVar2# primop, which has replaced the less > > powerful atomicModifyMutVar#. > > > atomicSwapIORef atomically installs a user-supplied value in an IORef > > and returns the old value. It is currently implemented using > > atomicModifyIORef2, but it can and should be reimplemented using its > > own, more efficient primop. > > > I propose to add both of these functions to Data.IORef. > > > David > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 0