- Libraries - Haskell.org

Re: Applicative-based definitions in Data.Foldable
by Isaac Elliott 24 Jan '19

24 Jan '19

I used `anyA` today, to run predicates on things contained in IORefs. On Fri, Dec 21, 2018 at 10:37 AM Isaac Elliott <isaace71295(a)gmail.com> wrote: > With the introduction of the 'Ap' monoid in base-4.13, it seems like > Applicative based definitions for common folds would be appropriate in base. > > For example: > >> allA :: (Applicative f, Foldable t) => (a -> f Bool) -> t a -> f Bool >> allA f = fmap getAll . getAp . foldMap (Ap . fmap All . f) >> > > >> all :: Foldable t => (a -> Bool) -> t a -> Bool >> all f = runIdentity . allA (Identity . f) > > > I've personally written the Applicative version in everyday code. Thoughts? > > Isaac >

1 0

postgresql-simple broken in GHC 8.6.3 on Windows
by Yitzchak Gale 22 Jan '19

22 Jan '19

First of all, many thanks to Oleg for taking on maintainership of postgresql-simple. Oleg, your new github fork of postgresql-simple - which is now the official source of this package - does not have issues enabled. Where is the right place to report issues? In particular, the library is not building for us on Windows with GHC 8.6.3. One of our devs has a guess that it's related to GHC bug #16057. In any case, we'd like to file an issue for postgresql-simple. https://ghc.haskell.org/trac/ghc/ticket/16057 The evidence that this GHC bug may be at play is that compilation hangs in Database.PostgreSQL.Simple.FromField, which uses some TH splices. That is the same behavior we are seeing for ofther packages that are hit by this GHC bug on Windows. Thanks, Yitz

2 2

Discussion: traversals for Data.Set
by David Feuer 21 Jan '19

21 Jan '19

Julian Ospald has opened a pull request[*] for containers to add a traversal operation to Data.Set. Julian specifically requested forM :: (Ord b, Monad m) => Set a -> (a -> m b) -> m (Set b) Personally, I think it would be better to offer the unflipped versions: -- The most general version traverse :: (Ord b, Applicative f) => (a -> f b) -> Set a -> f (Set b) traverse f = fmap fromList . traverse f . toList -- A more efficient, strictly accumulating version for "strict" -- monads like IO, strict State, etc. mapM :: (Ord b, Monad m) => (a -> m b) -> Set a -> m (Set b) mapM f s0 = foldr go return s0 empty where go x r s = f x >>= \y -> r $! insert y s The latter can also be written, perhaps less efficiently, as mapM :: (Ord b, Monad m) => (a -> m b) -> Set a -> m (Set b) mapM f = foldM go empty where go s x = f x >>= \y -> pure $! insert y s As usual, the main question is what names are appropriate. Typically, containers assumes that users import its modules qualified, and therefore we should just use `traverse` and `mapM`. But clashing with well-known and widely-used names often causes breakage anyway, so I figured I should bring the matter to the libraries list. Thanks, David Feuer [*] https://github.com/haskell/containers/pull/592

2 1

Request for review of proposed strict-concurrency improvements
by Yitzchak Gale 19 Jan '19

19 Jan '19

During the past few days, David Feuer has proposed a number of improvements to the strict-concurrency library. Thanks very much for this work! That, in turn, was triggered by some ideas of Eric Crockett - again, thanks very much for this! Since there are some subtle nuances at play here, I am asking the community to give this a brief review. Please comment directly in the PRs or issues, links below, not here on the list. Absent any comments, I will merge these PRs in about a week. If it's needed sooner than that, please let me know. Thanks, Yitz PRs: https://github.com/ygale/strict-concurrency/pull/9 https://github.com/ygale/strict-concurrency/pull/10 Issues: https://github.com/ygale/strict-concurrency/issues/2 https://github.com/ygale/strict-concurrency/issues/3 https://github.com/ygale/strict-concurrency/issues/4 https://github.com/ygale/strict-concurrency/issues/5 https://github.com/ygale/strict-concurrency/issues/6 https://github.com/ygale/strict-concurrency/issues/7 https://github.com/ygale/strict-concurrency/issues/8

1 0

Re: Asynchronous exceptions in threadWait
by Bev 18 Jan '19

18 Jan '19

Who are all you people and why am I receiving emails from you? Please stop. Take me off list. Thanks On Thursday, January 17, 2019 Andrew Martin <andrew.thaddeus(a)gmail.com> wrote: Ah, that makes sense. They certainly differ in the guarantees they provide around when unregisterFd_ is called. Although I think the exception would still be raised in the caller of threadWait regardless of which way it was written. Sent from my iPhone > On Jan 17, 2019, at 5:58 PM, Michael Walker <mike(a)barrucadu.co.uk> wrote: > > So, something like this? > > threadWait :: Event -> Fd -> IO () > threadWait evt fd = do > (m, mgr, reg) <- mask_ $ do > m <- newEmptyMVar > mgr <- getSystemEventManager_ > reg <- registerFd mgr (\_ e -> putMVar m e) fd evt M.OneShot > pure (m, mgr, reg) > evt' <- takeMVar m `onException` unregisterFd_ mgr reg > if evt' `eventIs` evtClose > then ioError $ errnoToIOError "threadWait" eBADF Nothing Nothing > else return () > > I'm not sure this is semantically equivalent. > > GHC can pre-empt a thread whenever it allocates memory, and I assume > it can deliver exceptions at that granularity too. So if > `onException` allocates memory before the exception handler is set up, > then an exception could possibly be delivered in that brief window, > which would result in `unregisterFd_ mgr reg` never being called, and > an exception being raised in the caller of `threadWait`. > >> On Thu, 17 Jan 2019 at 22:43, Andrew Martin <andrew.thaddeus(a)gmail.com> wrote: >> >> Thanks. That makes sense. So, in the code I’m looking at, since takeMVar is the last effectful thing that happens, there is no semantic difference between having mask_ extend all the way down to the bottom of the block (as it currently does) and cutting it off right before the line involving takeMVar? >> >> Sent from my iPhone >> >> On Jan 17, 2019, at 5:23 PM, Michael Walker <mike(a)barrucadu.co.uk> wrote: >> >>>> Although the entire function has asynchronous exceptions masked, the call to takeMVar uses onException to deal with the possibility of an exception. According to the docs in Control.Concurrent, takeMVar can throw exceptions. But my understand (which may be wrong) is that the only exception this could throw would be something like BlockedIndefinitelyOnMVar, which I don't believe can happen here. >>> >>> That's not quite right. The mask_ function blocks asynchronous >>> exceptions from being delivered to the thread while it's not >>> "interruptible". Most blocking functions, such as takeMVar, make the >>> thread interruptible while they're blocked. So any asynchronous >>> exception (such as ThreadKilled) could be delivered to the thread if >>> it blocks in the takeMVar. >>> >>> -- >>> Michael Walker (http://www.barrucadu.co.uk) > > > > -- > Michael Walker (http://www.barrucadu.co.uk) _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 0

Asynchronous exceptions in threadWait
by Andrew Martin 17 Jan '19

17 Jan '19

3 6

Re: taking over `bitvec`, `gamma`, `hs-hd5f` etc.
by Marco Zocca 17 Jan '19

17 Jan '19

Hi all, I had also tried recently to contact James Cook regarding maintainership of `gamma` (https://github.com/mokus0/gamma/pull/4) and three years ago about `hs-hdf5` (https://github.com/mokus0/hs-hdf5/issues/4#issuecomment-244511986) but he seldom checks email and github issues it seems. First of all, I hope he is well, and second, I once more volunteer to help with the maintenance of these packages. Best, Marco > Today's Topics: > > 1. Taking over maintainership of bitvec (Andrew Lelechenko) > > I would like to take over `bitvec` package > (https://hackage.haskell.org/package/bitvec) > > Unfortunately, the source code has not been updated for years and the > test suite does not build nowadays. There are also known issues. I > have prepared patches and tried to reach its maintainer James Cook > (cced) by email, but have not heard back. > > There was a takeover of another James' package in October 2018 > (https://mail.haskell.org/pipermail/libraries/2018-October/029062.html) > In that case James appeared to be out of reach. > > -- > Best regards, > Andrew >

2 1

Taking over maintainership of bitvec
by Andrew Lelechenko 16 Jan '19

16 Jan '19

I would like to take over `bitvec` package (https://hackage.haskell.org/package/bitvec) Unfortunately, the source code has not been updated for years and the test suite does not build nowadays. There are also known issues. I have prepared patches and tried to reach its maintainer James Cook (cced) by email, but have not heard back. There was a takeover of another James' package in October 2018 (https://mail.haskell.org/pipermail/libraries/2018-October/029062.html) In that case James appeared to be out of reach. -- Best regards, Andrew

1 0

How about a "deriving defaulted" deriving strategy
by Andrew Martin 14 Jan '19

14 Jan '19

I was just doing the usual incantation for an exception type: data DatagramException = ... deriving stock (Eq,Show) instance Exception Datagram And it suddenly hit me what a shame it was that I cannot put the Exception instance in a deriving clause like the others. It would be more visually pleasing to write: data DatagramException = ... deriving stock (Eq,Show) deriving defaulted (Exception) -- -Andrew Thaddeus Martin

2 2

Data.List.maximumBy uses counter-intuitive ordering
by Johannes Waldmann 08 Jan '19

08 Jan '19

Dear all, this was brought up on the GHC tracker (not by me) https://ghc.haskell.org/trac/ghc/ticket/15921 and it was suggested for discussion here. my summary: Data.List.maximumBy is right-biased, minimumBy is left-biased, and none of this is documented. - J.W.

8 7