- Libraries - Haskell.org

Re: Who remembers HP 2013.4.0.0...?
by Mark Lentczner 06 Jan '14

06 Jan '14

Okay - the pre-release branch has been updated. Please check that haskell-platform.cabal and see if it makes sense to you! https://github.com/haskell/haskell-platform/blob/pre-release/haskell-platfo… - Mark

2 2

hackage helpers!!
by Carter Schonwald 05 Jan '14

05 Jan '14

hey all, isn't there supposed to be an ACLs level for hackage helpers? (ie folks who can force docbuilders to rebuild docs for packager, edit pkg info stuff, etc?) Am I correct in thinking no ones in that group yet? (i know duncan asked for volunteers, but I don't think anyone's been put in that group yet!) cheers! -Carter

1 0

Re: Who remembers HP 2013.4.0.0...?
by Mark Lentczner 05 Jan '14

05 Jan '14

On Sat, Jan 4, 2014 at 2:41 PM, George Colpitts <george.colpitts(a)gmail.com>wrote: > Any reason why alex wouldn't be 3.1.3 and happy 1.19.2? > Nope, none at all. Bumped.

1 0

Re: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
by Thomas Schilling 29 Dec '13

29 Dec '13

Also, adding a function should bump the third component, not the fourth. On 11 December 2013 16:57, Thomas Schilling <nominolo(a)googlemail.com> wrote: > There's a typo in line: > > +#ifndef HAVE_FDAYASYNC > > I assume it should read HAVE_FDATASYNC > > Did you try to compile this on a system that has fdatasync? > > On 7 December 2013 20:20, Ricardo Catalinas Jiménez > <jimenezrick(a)gmail.com> wrote: >> Hi, >> >> Please review this pull request: >> https://github.com/jimenezrick/unix/compare/master...file-utils.patch >> >> If you find interesting this patch, then: >> git pull https://github.com/jimenezrick/unix.git file-utils >> >> /Ricardo >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries

6 12

cabal sandboxes executable path
by Konstantine Rybnikov 27 Dec '13

27 Dec '13

Hi! After I do `cabal install`, I get two binaries: - in `dist/dist-sandbox-$ID/build/Foo/Foo` - in `.cabal-sandbox/bin/Foo` They seem to be different. Is this ok? Which one of them is the right one? Sorry if I missed this in docs. Thanks.

4 6

Adding a finalizer to a TVar
by Sebastiaan Visser 23 Dec '13

23 Dec '13

Hi, Both MVar and IORef have specialized functions to attach a finalizer to there inner identifiable (stable) reference cell. I happen to need something similar for TVars, but that one doesn't seem to exist. The documentation of System.Mem.Weak tells me: "Finalizers can be used reliably for types that are created explicitly and have identity, such as IORef and MVar. However, to place a finalizer on one of these types, you should use the specific operation provided for that type, e.g. mkWeakIORef and addMVarFinalizer respectively (the non-uniformity is accidental). These operations attach the finalizer to the primitive object inside the box (e.g. MutVar# in the case of IORef), because attaching the finalizer to the box itself fails when the outer box is optimised away by the compiler." Does it make sense to add a similar function to the STM package? What I do now is hack around it by adding an IORef next to my TVar which I attach the finalizer to. Because my outer datatype is opaque I expect both variables to go out of scope and get garbage collected simultaneously. As you might expect, this isn't a very satisfiable solution. Thanks, Sebastiaan

4 3

Proposal: Add a strict version of <$> for monads
by Johan Tibell 22 Dec '13

22 Dec '13

Hi all, I propose we add a strict version of <$> to base: -- | A strict version of 'Data.Functor.<$>' for monads. (<$!>) :: Monad m => (a -> b) -> m a -> m b f <$!> m = do a <- m return $! f a {-# INLINE (<$!>) #-} infixl 4 <$!> It works on Monads instead of Functors as required by us inspecting the argument. This version is highly convenient if you want to work with functors/applicatives in e.g. parser and avoid spurious thunks at the same time. I realized that it was needed while fixing large space usage (but not space-leak) issues in cassava. I believe Edward Kmett discovered the need for it independently as well. Deadline: 3 weeks Cheers, Johan

13 26

Proposal: die to System.Exit (and/or Prelude)
by Simon Hengel 21 Dec '13

21 Dec '13

Hi! I propose to add die :: String -> IO () die err = hPutStrLn stderr err >> exitFailure to System.Exit. Reasoning: (1) It's a frequently required functionality. Almost every command-line program has code similar to this. (2) The definition is relatively short, but in addition to the definition, you need two import statements. (3) It's frequently done wrong (e.g. writing to stdout instead of stderr, or not using exitFailure, or both). I haven't done any extensive research on Hackage, but I quickly looked at Haddock. Here we have a definition of die [1], but we also print to stdout at a couple of place and then call exitFailure [2]. Personally, I think it should be re-exported from Prelude. But this may be controversial. So let's have two separate votes: Add System.Exit.die: +1 Re-export it from Prelude: +1 (discussion until December, 28th) Cheers, Simon [1] https://github.com/ghc/haddock/blob/8d4c94ca5a969a5ebbb791939fb0195dc672429… [2] https://github.com/ghc/haddock/blob/c6faeae064668125721b0d5e60f067f90c53893…

18 38

Re: Removing MonadFail from Monad
by David Luposchainsky 17 Dec '13

17 Dec '13

Hey Andreas, On 16.12.2013 23:39, Andreas Abel wrote: > "Only one data constructor" should be understood hereditarily; the > description is not entirely accurate: > > -- Only one data constructor: do not add MonadFail constraint > do (Only x) <- computation >>> let f (Only x) = more > more >>> in computation >>= f > > (Only x) should be pat such that every constructor in pat is an > "only-one" constructor. Do you mean in case patterns of nested "Only" types appear, like `Only (Only' x)`? I hadn't thought of that, good point. >> - The case of one data constructor should emit a warning if the data >> type is defined via `data`: adding another data constructor can make >> patterns in unrelated modules refutable. > > I don't understand the restriction "is defined via data" since I am not > aware of defining constructors outside of data or with something other > than the data keyword. Please clarify. I meant "data and not newtype". If "Only" is a newtype data constructor, the pattern is irrefutable by design, is it not? Greetings, David/quchen

3 4

cabal: question on compiling build prerequisites
by selinger＠mathstat.dal.ca 14 Dec '13

14 Dec '13

This may be a silly question, but I can't seem to find the answer in the documentation. I would like to create a Cabal package where some of the source files use a custom pre-processor. The pre-processor is itself a Haskell program, let's say MyPreProc.hs in the package's root directory. I figured out how to activate the preprocessor, for example, cabal build --ghc-options="-F -pgmF ./MyPreProc" I also figured out how to achieve the same effect using hooks. However, there is one problem: how can I tell cabal to actually compile MyPreProc.hs before any of the commands using the preprocessor are run? The package's Setup.hs file is automatically compiled during "cabal configure". I would like MyPreProc.hs to be compiled at the same time as well - or at least some time before the proprocessor needs to be used. The .cabal file contains all kinds of related variables, such as "build-depends" (but only packages can be listed here, not programs to be compiled), "other-modules" (but these modules would already require the pre-processor, so the pre-processor should be compiled first), "build-tools" (but this only refers to external programs). My current solution is to make the pre-processor a shell script, rather than a Haskell program. But this is ugly and not portable (won't work in Windows, for example). To clarify: my custom preprocessor is local to this package. It has no independent value, so it would not make sense to publish it as a separate package just so that I can add it to build-depends. Is there a known solution to this problem? Thanks, -- Peter

5 11