- Libraries - Haskell.org

Re: [Haskell-cafe] Requesting maintainership: bzlib-conduit and process-conduit
by Michael Snoyman 29 Jun '14

29 Jun '14

Oops, you're right. I've added libraries@ to the CC list. On Sun, Jun 29, 2014 at 7:12 PM, Mateusz Kowalczyk <fuuzetsu(a)fuuzetsu.co.uk> wrote: > On 06/29/2014 06:02 PM, Michael Snoyman wrote: > > I'd like to request to be granted maintainership of two conduit-related > > packages: bzlib-conduit and process-conduit. Both packages are maintained > > by the same author. I opened up a pull request[1] on bzlib-conduit back > in > > January, and haven't heard back yet. There's also an issue with > > process-conduit[2] which I'd like to address, but given the lack of > > response of bzlib-conduit, haven't sent a pull request yet. > > > > I also emailed the author directly five days ago regarding the > > bzlib-conduit pull request, and have not received a response. > > > > [1] https://github.com/tanakh/bzlib-conduit/pull/7 > > [2] https://github.com/tanakh/process-conduit/issues/14 > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > Two things: > > 1. Does this not need to go on libraries@ instead? > 2. I happen to know the author is an active Twitter user under the > ‘tanakh’. I will tweet him your e-mail but perhaps it's worth trying > that method of communication too. > > -- > Mateusz K. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Add instances for Functor, Monad, Applicative to Data.Monoid.First, Last
by Omari Norman 28 Jun '14

28 Jun '14

This was proposed in 2011: http://www.haskell.org/pipermail/libraries/2011-January/015552.html Any reason it did not go anywhere? Should I propose it again? Thanks. Omari

2 1

New version of vector + discussion
by Gregory Collins 26 Jun '14

26 Jun '14

Hi all, I've prepped a new minor version (0.10.12.0) of the 0.10 branch of vector so that we can release https://github.com/haskell/vector/pull/31, which I cherry-picked from master. Could someone please review this and do the upload? I'm not sure I have the right bit set. Also, in a related topic, an aside: I tried to merge 0.10 into master and got a horrorshow: # Unmerged paths: # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: Data/Vector.hs # deleted by them: Data/Vector/Fusion/Bundle/Monadic.hs # both modified: Data/Vector/Fusion/Stream.hs # both modified: Data/Vector/Fusion/Stream/Monadic.hs # both modified: Data/Vector/Fusion/Stream/Size.hs # both modified: Data/Vector/Generic.hs # both modified: Data/Vector/Generic/Mutable.hs # deleted by them: Data/Vector/Generic/Mutable/Base.hs # both modified: Data/Vector/Generic/New.hs # both modified: Data/Vector/Mutable.hs # both modified: Data/Vector/Storable.hs # both modified: Data/Vector/Unboxed.hs # both modified: Data/Vector/Unboxed/Base.hs # both added: README.md # both modified: benchmarks/vector-benchmarks.cabal # both added: changelog # both modified: internal/unbox-tuple-instances # both modified: tests/vector-tests.cabal # both modified: vector.cabal I'm curious why these branches have diverged like this, it doesn't smell good to me. Does anyone want to tackle doing this merge? G -- Gregory Collins <greg(a)gregorycollins.net>

4 9

fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
by davean 25 Jun '14

25 Jun '14

I can't find a reason https://ghc.haskell.org/trac/ghc/ticket/8621 might have stalled but it seems like it has from my perspective. Can someone tell me I'm wrong or what to do to unstall it? This is very useful functionality that is actually part of IEEE Std 1003.1. -davean

3 7

Use -Werror by default on travis-ci
by Simon Hengel 18 Jun '14

18 Jun '14

Hi, I created a PR to use -Werror by default on travis-ci. If you think this is a good idea, see any issue or have any other input, get involved in the discussion on GitHub [1]. Cheers, Simon [1] https://github.com/travis-ci/travis-build/pull/250

1 0

setlocale maintainership
by adam vogt 16 Jun '14

16 Jun '14

Hello list. http://hackage.haskell.org/package/setlocale does not compile with ghc-7.8 because it has a manually written typeable instance. I emailed the author about this one month ago (May 15), but I have received no reply. Let us wait until September 1 2014, and then I could be allowed to upload a corrected version? Regards, Adam

6 8

List.or, List.any and List.elem
by Andreas Abel 12 Jun '14

12 Jun '14

Curious on whether I should prefer List.any f over List.or . List.map f I consulted the source code at http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-List.html I found that according to the Report, they are identical, but there are fusion rules for List.any which look like I should prefer it to the said composition. What puzzled me is that later, List.elem x is List.any (x ==) according to the Report, but GHC defines it recursively, *without* fusion rules. I wonder Q1: Should I prefer List.any (x==) then, since it gives opportunity to fusion? Q2: Why is then List.elem defined recursively? Q3: Where is the comment that justifies the taken design decisions?? Cheers, Andreas #ifdef USE_REPORT_PRELUDE any p = or . map p all p = and . map p #else any _ [] = False any p (x:xs) = p x || any p xs all _ [] = True all p (x:xs) = p x && all p xs {-# NOINLINE [1] any #-} {-# NOINLINE [1] all #-} {-# RULES "any/build" forall p (g::forall b.(a->b->b)->b->b) . any p (build g) = g ((||) . p) False "all/build" forall p (g::forall b.(a->b->b)->b->b) . all p (build g) = g ((&&) . p) True #-} #endif -- | 'elem' is the list membership predicate, usually written in infix form, -- e.g., @x \`elem\` xs@. For the result to be -- 'False', the list must be finite; 'True', however, results from an element equal to @x@ found at a finite index of a finite or infinite list. elem :: (Eq a) => a -> [a] -> Bool -- | 'notElem' is the negation of 'elem'. notElem :: (Eq a) => a -> [a] -> Bool #ifdef USE_REPORT_PRELUDE elem x = any (== x) notElem x = all (/= x) #else elem _ [] = False elem x (y:ys) = x==y || elem x ys notElem _ [] = True notElem x (y:ys)= x /= y && notElem x ys #endif -- 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/

1 0

System.Directory.removeDirectoryRecursive and symlinks
by Gracjan Polak 10 Jun '14

10 Jun '14

Hi all, A crime scene: Prelude System.Directory> :!mkdir a-directory Prelude System.Directory> :!touch a-directory/a-file.txt Prelude System.Directory> :!ln -s "a-directory" "a-symlink-to-a-directory" Prelude System.Directory> :!ls a-directory a-file.txt Prelude System.Directory> :!ls a-symlink-to-a-directory a-file.txt Prelude System.Directory> removeDirectoryRecursive "a-symlink-to-a-directory" *** Exception: a-symlink-to-a-directory: removeDirectory: inappropriate type (Not a directory) Prelude System.Directory> :!ls a-symlink-to-a-directory Prelude System.Directory> :!ls a-directory Prelude System.Directory> :!ls -a a-directory . .. Prelude System.Directory> :!ls -a a-symlink-to-a-directory . .. Prelude System.Directory> removeDirectoryRecursive is removing all contents *of the directory linked* but is unable to remove the symlink itself. This behavior is surprizing if not dangerous. I understand that this mimics behavior of unlink/rmdir and DeleteFile/RemoveDirectory. but let me quote relevant manuals: man rm: The rm utility removes symbolic links, not the files referenced by the links. DeleteFile docs: If the path points to a symbolic link, the symbolic link is deleted, not the target. To delete a target, you must call CreateFile and specify FILE_FLAG_DELETE_ON_CLOSE. RemoveDirectory removes a directory junction, even if the contents of the target are not empty; the function removes directory junctions regardless of the state of the target object. Note: doesDirectoryExist and doesFileExist follow symlinks so they add more surprize to the scenario. What can we do about this? -- Gracjan

4 7

Re: Gearing up (again) for the next release: 2014.2.0.0
by Mark Lentczner 09 Jun '14

09 Jun '14

All - I've been advised that GHC 7.8.3 is imminent and fixes some important issues. No base package versions will change, except for a small bump in haddock. I plan to incorporate this into the HP as soon as they release it - and so that will be the compiler in the upcoming HP release. Any concerns?

4 5

7.8.3 for the Platform
by Austin Seipp 06 Jun '14

06 Jun '14

Hi Mark, I was planning on releasing GHC 7.8.3 very soon (in the next few days,) and I'm wondering if it is still a possible candidate for the next Haskell Platform? To be clear, there are no library updates this time around - 7.8.3 is almost 100% a pure compiler/runtime bugfix release, and some of the fixes are quite bad. https://ghc.haskell.org/trac/ghc/ticket/9078 https://ghc.haskell.org/trac/ghc/ticket/8768 https://ghc.haskell.org/trac/ghc/ticket/9148 https://ghc.haskell.org/trac/ghc/ticket/9001 The first one, #9078, would be particularly bad to let slip into the release - it affects possibly all EDSLs using mkStableName for sharing, and is very easy to trigger by allocating stable names quickly. I'd say #8768 is somewhat nasty as well. Accelerate and SBV are two examples of projects that will crash. There are currently no plans to even bump the corresponding library numbers - we didn't do so for 7.8.2, and there are no changes at all that would warrant a bump for 7.8.3. It's really a stability release more than anything and irons out several real bumps. Do let me know what you think - I'll keep this thread updated as the release gets closer if anything else goes in. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 2