September 2014 - Libraries

Re: Taking over random-fu
by Dominic Steinitz 14 Sep '14

14 Sep '14

Thanks very much for this. I should have guessed you had had children as that is one of the main reasons for folks having less time. Enjoy them (the children that is). Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com On 13 Sep 2014, at 16:58, James Cook <mokus(a)deepbondi.net> wrote: > Sorry about the lack of responsiveness, life has been pretty crazy since I had kids. If you're willing to take it on, that's probably best for the community right now. I will make those changes now. > > -- James > > On Sep 12, 2014, at 12:45 AM, Dominic Steinitz <dominic(a)steinitz.org> wrote: > >> Hi James, >> >> I have quite a few changes I would like to make to the package and I haven’t heard anything from you. I think they are all for the good. >> >> This >> >>> http://www.haskell.org/haskellwiki/Taking_over_a_package >> >> >> suggests you can add me as a maintainer by going to >> >>> http://hackage.haskell.org/package/random-fu/maintainers/ >> >> >> and clicking on edit. I am DominicSteinitz on hackage. >> >> Also you would have to give me permission to update the repo on github where I am idontgetoutmuch. >> >> Many thanks, >> >> Dominic Steinitz >> dominic(a)steinitz.org >> http://idontgetoutmuch.wordpress.com >> >

1 0

PROPOSAL: Add newBroadcastChan :: IO (Chan a) to Control.Concurrent.Chan
by Merijn Verstraaten 14 Sep '14

14 Sep '14

Ola! Control.Concurrent.STM.TChan has the “newBroadcastTChan :: STM (TChan a)”, this creates a “write-only” TChan to avoid any space leaks when a Chan is written too but never read from (for example, when dupTChan is used to hand a copy to threads). Unfortunately, no such variant seems to exist for the normal Chan? I have the following code: foo :: Chan a -> IO Foo foo broadcast = do newListener <- dupChan broadcast forkIO $ doStuffWith newListener This means the original Chan is never read from and much like the problem with TChan, values keep piling up in the original channel, causing a space leak. I propose adding newBroadcastChan :: IO (Chan a) The obvious Chan equivalent of newBroadcastTChan, which creates a write-only channel without read end, thus avoiding this space leak. Discussion: 2 weeks? Cheers, Merijn

1 1

PROPOSAL: re-export 'Typeable' type-class from Prelude
by Herbert Valerio Riedel 12 Sep '14

12 Sep '14

TL;DR ===== Re-export 'Data.Typeable.Typeable' from 'Prelude' Motivation ========== Since GHC 7.8 the ubiquitous 'Typeable' instances can only be auto-derived via `... deriving Typeable`, moreover there's a new extension `-XAutoDeriveTypeable` which implicitly auto-derives 'Typeable' for all defined types in modules for which that extension is enabled. However, even if you enable `-XAutoDeriveTypeable` you still need to explicitly bring the 'Typeable' class into scope, with e.g. import Data.Typeable (Typeable) otherwise GHC complains with Not in scope: type constructor or class ‘Typeable’ Since at this point it's become current practice to have 'Typeable' instances for most types, it would be beneficial to save an 'import Data.Typeable (Typeable)' line for the sole purpose of deriving such instances. By having 'Prelude' re-export 'Typeable' from GHC 7.10 on (should this proposal be implemented) it would suffice to have a default-extensions: -XAutoDeriveTypeable` in the Cabal file and have 'Typeable' instance auto-derived for all types defined in a package w/o any source changes (unless there's a name-clash with 'Typeable') Discussion period ================= The usual 2 weeks

11 13

Taking over random-fu
by Dominic Steinitz 12 Sep '14

12 Sep '14

Hi James, I have quite a few changes I would like to make to the package and I haven’t heard anything from you. I think they are all for the good. This > http://www.haskell.org/haskellwiki/Taking_over_a_package suggests you can add me as a maintainer by going to > http://hackage.haskell.org/package/random-fu/maintainers/ and clicking on edit. I am DominicSteinitz on hackage. Also you would have to give me permission to update the repo on github where I am idontgetoutmuch. Many thanks, Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

1 0

HTTP package - supported GHC versions
by Ganesh Sittampalam 11 Sep '14

11 Sep '14

Hi, The HTTP package supports a whole load of old GHCs - the current version should actually work with GHC 6.10. For future releases I plan to drop most of these. Any opinions about how far back it should support? I'm thinking restricting it to either 7.4+ or 7.6+, but I'm open to keeping support for older versions too if there's a real need. Cheers, Ganesh

6 13

Re: bedandbreakfast needing a release
by Adam Bergmark 11 Sep '14

11 Sep '14

Wow, I totally forgot about "if impl(ghc>=7.8)". That's the way to go of course! On Thu, Sep 11, 2014 at 12:04 AM, Herbert Valerio Riedel <hvriedel(a)gmail.com > wrote: > On 2014-09-10 at 20:41:27 +0200, Adam Bergmark wrote: > > Hi Mike, something like this should do the trick (untested): > > > > ``` > > flag ghc78 > > description: Using GHC >= 7.8 > > default: True > > > > library > > if flag(ghc78) > > build-depends: > > base >= 4.7 > > bedandbreakfast >= 5 > > else > > build-depends: > > base < 4.7 > > bedandbreakfast >= 4 > > ``` > > > > This uses a non-manual flag so cabal will toggle it if it needs to. > > btw, why not simply use a "if impl(ghc>=7.8)" conditional w/o resorting > to flags? >

1 0

bedandbreakfast needing a release
by Mike Meyer 10 Sep '14

10 Sep '14

I've got a library that needed some simple matrix computation, so I added the bedandbreakfast package. While my library builds fine on both 7.6 and 7.8, the last released version of that package won't build on 7.8. However, the current HUB was update a couple of weeks ago, and now builds on 7.8. Is there some way to capture that information in a cabal file? That if you're using GHC 7.8, you need bedandbreakfast >= 5.*, but for GHC7.6 you can use bedandbreakfast >= 4.*? I did send an email to the maintainer a little over a week ago asking if he could do a release, and haven't gotten either a reply or a release. Any suggestions on what I should do about releasing the updated version of my library?

3 4

ANNOUNCE time-1.5
by Ashley Yakeley 10 Sep '14

10 Sep '14

time-1.5 is now available from Hackage. <http://hackage.haskell.org/package/time> The source for time has now moved to GitHub: <https://github.com/haskell/time>. Send bug reports to the associated issue tracker. * Fixed a bug where tzset was not getting called on Windows. The other changes relate to Data.Time.Format: * time no longer depends on old-locale. The TimeLocale from old-locale has been replaced by a new one defined in Data.Time.Format. * The "intervals" field from TimeLocale has been removed, as it's not used. * The way time-zone abbreviations are parsed has changed. The parsing functions parse single-letter military abbreviations, and also time-zones found in the new "knownTimeZones" field of TimeLocale. Note that (knownTimeZones defaultTimeLocale) contains only the ten zone abbreviations mentioned in RFC822 sec. 5. This is the only standardised list of time-zone abbreviations I know of. Since the abbreviations are a many-to-many mapping, this should encourage people to think carefully about what abbreviations they expect. * New parsing functions parseTimeM, parseTimeOrError, readSTime, readPTime replace now-deprecated parseTime, readTime, readsTime. The new functions have a flag to control parsing of leading and trailing whitespace. -- Ashley Yakeley

3 2

Proposal: Use uninterruptibleMask for cleanup actions in Control.Exception
by Eyal Lotem 06 Sep '14

06 Sep '14

I'd like to propose a change in the behavior of Control.Exception to help guarantee cleanups are not accidentally lost. For example, bracket is defined as: bracket before after thing = mask $ \restore -> do a <- before r <- restore (thing a) `onException` after a _ <- after a return r This definition has a serious problem: "after a" (in either the exception handling case, or the ordinary case) can include interruptible actions which abort the cleanup. This means bracket does not in fact guarantee the cleanup occurs. For example: readMVar = bracket takeMVar putMVar -- If async exception occurs during putMVar, MVar is broken! withFile .. = bracket (openFile ..) hClose -- Async exception during hClose leaks the file handle! Interruptible actions during "before" are fine (as long as "before" handles them properly). Interruptible actions during "after" are virtually always a bug -- at best leaking a resource, and at worst breaking the program's invariants. I propose changing all the cleanup handlers to run under uninterruptibleMask, specifically: *bracket, bracketOnError, bracket_, catch, catchJust, finally, handle, handleJust, onException* should all simply wrap their exception/cancellation handler with uninterruptibleMask. The danger of a deadlock is minimal when compared with the virtually guaranteed buggy incorrect handling of async exceptions during cleanup. -- Eyal

10 14

Re: Formal proposal: replace Data.List.inits
by David Feuer 06 Sep '14

06 Sep '14

Minor errors in copying/memory: initsHO = map ($[]) . scanl q id where q f x = f . (x :) On Sun, Jul 20, 2014 at 2:03 AM, David Feuer <david.feuer(a)gmail.com> wrote: > As previously discussed, Data.List.inits has terrible performance: > something as simple as > > print $ length $ inits [100000] > > will take an absurdly long time. The simplest decent improvement seems to be > > initsHO = map ($[]) . scanl q [] > where > q f x = f . (q :) > > A slight transformation of this by Andrew Seniuk (rasfar on #haskell) > gives the slightly faster > > initsR = map reverse . scanl (flip (:)) [] > > As Henning Thielemann and Edward Kmett pointed out, these perform > poorly when calculating things like `map head $ drop 100000 $ inits > [100050]` because the costs of the reverses or compositions are > monolithic and unshared. Edward Kmett pointed out that this could > probably be fixed by using a queue (although he isn't sure it's worth > doing so). As it turns out, it can, and with only a trivial penalty in > other cases. The following uses a stripped-down partial implementation > of Okasaki's banker's queue (see the attached file for a version with > explanatory comments as well as the benchmark code): > > import Data.Bits (popCount) > import Data.Word (Word) > > data Queue a = Queue {-# UNPACK #-} !Word [a] [a] > > queue :: Word -> [a] -> [a] -> Queue a > queue lp1 f r > | popCount lp1 /= 1 = Queue lp1 f r > | otherwise = Queue lp1 (f ++ reverse r) [] > > emptyQ :: Queue a > emptyQ = Queue 1 [] [] > > snocQ :: Queue a -> a -> Queue a > snocQ (Queue lp1 f r) x = queue (lp1 + 1) f (x:r) > > toListQ :: Queue a -> [a] > toListQ (Queue _ f r) = f ++ reverse r > > initsQ :: [a] -> [[a]] > initsQ = map toListQ . scanl snocQ emptyQ > > > This implementation appears to take care of the performance wrinkle in > initsR and initsHO, while being only very slightly slower in other > contexts. It's longer, certainly, but it's not long. > > I have attached the Criterion report produced by the attached program > comparing initsR to initsQ. Previous tests definitively showed that > initsHO is a small constant factor worse than initsR, and > Data.List.inits is incomparably worse, so I limited this round to > initsR and initsQ. > > I therefore propose that we should replace the current implementation > of inits with initsQ, the queue-based one, unless someone comes up > with something faster and/or simpler very soon.

4 10