February 2012 - Libraries

Proposal: Use time rather than old-time in directory
by Ian Lynagh 17 Sep '14

17 Sep '14

Hi all, This proposal is to change directory to use the time package rather than the old-time package. This will hopefully be a significant step towards actually making the transition in general. I'm not sure if POSIXTime or UTCTime is the better type to use. Does anyone know? I started off with UTCTime, then switched to POSIXTime as UTCTime didn't have a Show instance. I've since found that actually UTCTime has both Show and Read instances, but they are orphaned. So actually, if UTCTime is the better type then switching back to UTCTime would allow us to fix this comment in hpc: -- We would rather use ClockTime in Mix, but ClockTime has no Read instance and simplify the code slightly. Attached are patches for directory, hpc and ghc. Suggested discussion period: Until 5th Nov 2011. Thanks Ian

14 35

Changes to Typeable
by Simon Peyton-Jones 26 Nov '12

26 Nov '12

Friends (Ian pointed out that I should have sent this to the libraries list): The page describes an improved implementation of the Typeable class, making use of polymorphic kinds. Technically it is straightforward, but it represents a non-backward-compatible change to a widely used library, so we need to make a plan for the transition. http://hackage.haskell.org/trac/ghc/wiki/GhcKinds/PolyTypeable Comments? You can fix typos or add issues directly in the wiki page, or discuss by email Simon

25 54

Proposal: Add newUniqueSTM to Data.Unique
by Edward Kmett 27 Apr '12

27 Apr '12

Data.Unique's newUnique uses atomically internally to update a TVar. Consequently attempting to "unsafeIOToSTM newUnique" to allocate a Unique within an STM transaction blows you sky high. The proposal is to split the definition of newUnique into: newUnique = atomically newUniqueSTM and expose newUniqueSTM. Alternately, since bug #3838 has been resolved, we could revert to using an IORef, which would avoid the wart of having us have an overtly IO action detonate because of an internal implementation detail of using STM. Since, there are two paths forward, I haven't put forward a patch, but wanted to open a discussion. Discussion Period: 2 weeks. -Edward Kmett

6 12

documentation patch for process
by Evan Laforge 16 Apr '12

16 Apr '12

I recently burned some time because I didn't realize that System.Process.createProcess doesn't report when the binary isn't found. I guess I was used to that behaviour from python's subprocess module, which goes to some effort to report the error from the fork()ed child when exec() fails. After a failed solution, I did some poking around in the source to see exactly what haskell's process does. In the interests of saving someone else that time, I submit a patch to process to add some documentation. I'm not sure how to do a 'darcs send' with git, but here's the patch: % git log | head commit 5a46937961b3400fa58ccffc785d0de8c1c01d94 Author: Evan Laforge <qdunkan(a)gmail.com> Date: Wed Feb 8 13:25:16 2012 -0800 More detailed haddock for createProcess: document what happens if the binary is not found commit c8b30a6f1d493ab724f2da05dbc49496b119a051 Author: Simon Marlow <marlowsd(a)gmail.com> Date: Mon Jan 16 16:25:34 2012 +0000 % git diff HEAD\^ diff --git a/System/Process.hs b/System/Process.hs index f3a8f9b..a372228 100644 --- a/System/Process.hs +++ b/System/Process.hs @@ -234,9 +234,18 @@ To create a pipe from which to read the output of @ls@: To also set the directory in which to run @ls@: > (_, Just hout, _, _) <- -> createProcess (proc "ls" []){ cwd = Just "\home\bob", +> createProcess (proc "ls" []){ cwd = Just "/home/bob", > std_out = CreatePipe } +Note that this does /not/ throw an error if the binary is not found, +or not executable. Instead, the process will fail with the exit code 127. +But you can't rely on it failing quickly, because it may e.g. hang up +searching the PATH on a slow NFS mount. Since there's no way to tell when +the exec() has succeeded, the only way to reliably know if the createProcess +failed is to 'waitForProcess'. + +If the CreateProcess record's 'cwd' directory doesn't exist, the exit code +will be 126. -} createProcess :: CreateProcess diff --git a/System/Process/Internals.hs b/System/Process/Internals.hs index 11de1f4..2a6c047 100644 --- a/System/Process/Internals.hs +++ b/System/Process/Internals.hs @@ -199,7 +199,8 @@ data CmdSpec = ShellCommand String -- ^ a command line to execute using the shell | RawCommand FilePath [String] - -- ^ the filename of an executable with a list of arguments + -- ^ The filename of an executable with a list of arguments. + -- The PATH is searched for the executable. data StdStream = Inherit -- ^ Inherit Handle from parent

2 3

Proposal: System.Environment.getEnv should return Maybe
by Evan Laforge 14 Mar '12

14 Mar '12

It's awkward and surprising how getEnv throws an exception when an env var is not set, since it's very common for env vars to be optional, and it's not convenient to catch exceptions in haskell (I have to look up Control.Exception every time, and then add LANGUAGE ScopedTypeVariables). I wind up using 'fmap lookup k Environment.getEnvironment' instead. So I propose a function: lookupEnv :: String -> IO (Maybe String) Then getEnv can be deprecated and eventually removed. Or maybe not if people want to argue the current getEnv is useful and deprecation warnings would be too annoying. Yeah, it's a trivial thing, but it's nice to sand off some of these rough edges. Discussion: 2 weeks, March 7

16 20

Re: Proposal: System.Environment.getEnv should return Maybe
by John Lato 13 Mar '12

13 Mar '12

> From: Jon Fairbairn <jon.fairbairn(a)cl.cam.ac.uk> > > Brandon Allbery <allbery.b(a)gmail.com> writes: > >> On Wed, Feb 22, 2012 at 18:51, John Meacham <john(a)repetae.net> wrote: >> >>> On Wed, Feb 22, 2012 at 3:05 PM, Evan Laforge <qdunkan(a)gmail.com> wrote: >>> > It's awkward and surprising how getEnv throws an exception when an env >>> > var is not set, since it's very common for env vars to be optional, >>> > and it's not convenient to catch exceptions in haskell (I have to look >>> >>> For true IO exceptions, you should be using the Prelude.catch mechanism. >>> >> >> This still assumes that it's an exceptional condition that is being >> modeled. It is not; it is correctly modeled as a Maybe. > > +1. And it?s always irritated me that read at EOF raises an > exception. Files having ends is not exceptional! (This is partly > addressed by iteratees, I imagine, but I haven?t found time to > get my head round those yet.) This irritates me too; I don't think that Haskell exceptions should be used for much of anything, exceptional condition or not. +1 for the proposal. Also, the unix-bytestring package (http://hackage.haskell.org/package/unix-bytestring) exposes IO functions that don't raise exceptions at EOF. John L.

5 8

Proposal: add 'findLess' and variants to containers
by Twan van Laarhoven 04 Mar '12

04 Mar '12

Hello all, == Overview == I have several times needed functions to find items less than a given key in a container. So I propose we add these to the containers library: -- | /O(log n)/. -- Find the largest element in the set that is @<@ the query. findLess :: Ord a => a -> Set a -> Maybe a -- | /O(log n)/. -- Find the largest element in the set that is @<=@ the query. findLessEqual :: Ord a => a -> Set a -> Maybe a -- | /O(log n)/. -- Find the smallest element in the set that is @>@ the query. findGreater :: Ord a => a -> Set a -> Maybe a -- | /O(log n)/. -- Find the smallest element in the set that is @>=@ the query. findGreaterEqual :: Ord a => a -> Set a -> Maybe a And for Maps: findLess, findLessEqual, findGreater, findGreaterEqual :: Ord a => a -> Map a b -> Maybe (a,b) As well as the equivalent functions for IntSet and IntMap. == Previous proposal and related functions == There was a previous proposal to add such functions about two years ago [1]. That proposal died due to concerns over adding related 'delete' and 'update' functions, and that the API would become too large. I think the 'find' functions should be added regardless of whether we also add 'update' and 'delete' variants. On the other hand, for consitency it would be better to also add 'deleteLess', etc. We should perhaps mimic the findMin/findMax functions. The only issue with that idea is that findMin does not return a Maybe, but rather fails for an empty container. I think that not returning its result in a Maybe would make the findLess useless in practice, since there is no such easy precondition for findLess. As for the API size: This proposal would add a lot of functions to Data.Map and Data.Set (especially when we also include 'update' and 'delete' variants). However, the mental burden of these new functions is not so large. Library users already know what 'find', 'update' and 'delete' mean. Moreover, there is a nice symmetry between the 4 different conditions, which means that you can almost think of them as one thing. == Bikeshedding / naming == There are several possible names for these functions: 1. findLess / findLessEqual / findGreater / findGreaterEqual 2. findMaxLT / findMaxLE / findMinGT / findMinGE 3. findLower / findFloor / findHigher / findCeiling I personally prefer either 1 or 2. To me option 3 (which Java uses) is very confusing. == Implementation == These functions can be implemented in terms of split, but it is a pain (and error prone) to do so: findLess a m = findMax' (fst (split a m)) findLessEqual a m = case splitLookup a s of (_,Just b,_) -> Just (a,b) (m',Nothing,_) -> findMax' m' findGreater a m = findMin' (snd (split a m)) findGreaterEqual a m = case splitLookup a m of (_,Just b,_) -> Just (a,b) (_,Nothing,m') -> findMin' m' where findMin' = fmap fst . minViewWithKey findMax' = fmap fst . maxViewWithKey This is really something that shouldn't have to be done by users of the library. And we might also be able to come up with a more efficient implementation. == Discussion period == Discussion deadline: 2 weeks from now; Sunday, 26 February 2012. Twan [1] http://www.haskell.org/pipermail/libraries/2010-February/013060.html continued here: http://www.haskell.org/pipermail/libraries/2010-March/013062.html

9 17

Functor instance for Set?
by Daniel Gorín 01 Mar '12

01 Mar '12

Hi I was always under the impression that the fact that Data.Set.Set can not be made an instance of Functor was a sort of unavoidable limitation. But if we look at the definition of Data.Set.map: map :: (Ord a, Ord b) => (a->b) -> Set a -> Set b map f = fromList . List.map f . toList we see that 1) "Ord a" is not really used and 2) "Ord b" is only needed for the final fromList. Since every interesting function in Data.Set requires an Ord dictionary anyway, one could implement fmap using only the "List.map f . toList" part and leave the "fromList" to the successive function calls. It appears to me, then, that if "Set a" were implemented as the sum of a list of a and a BST, it could be made an instance of Functor, Applicative and even Monad without affecting asymptotic complexity (proof of concept below). Am I right here? Would the overhead be significant? The one downside I can think of is that one would have to sacrifice the Foldable instance. Thanks, Daniel import qualified Data.Set as Internal import Data.Monoid import Control.Applicative data Set a = This (Internal.Set a) | List [a] toInternal :: Ord a => Set a -> Internal.Set a toInternal (This s) = s toInternal (List s) = Internal.fromList s toAscList :: Ord a => Set a -> [a] toAscList (This s) = Internal.toAscList s toAscList (List s) = Internal.toAscList $ Internal.fromAscList s toList :: Set a -> [a] toList (This s) = Internal.toList s toList (List s) = s -- Here we break the API by requiring (Ord a). -- We could require (Eq a) instead, but this would force us to use -- nub in certain cases, which is horribly inefficient. instance Ord a => Eq (Set a) where l == r = toInternal l == toInternal r instance Ord a => Ord (Set a) where compare l r = compare (toInternal l) (toInternal r) instance Functor Set where fmap f = List . map f . toList instance Applicative Set where pure = singleton f <*> x = List $ toList f <*> toList x instance Monad Set where return = pure s >>= f = List $ toList s >>= (toList . f) empty :: Set a empty = This Internal.empty singleton :: a -> Set a singleton = This . Internal.singleton insert :: Ord a => a -> Set a -> Set a insert a = This . Internal.insert a . toInternal delete :: Ord a => a -> Set a -> Set a delete a = This . Internal.delete a . toInternal instance Ord a => Monoid (Set a) where mempty = This mempty mappend (This l) (This r) = This (mappend l r) mappend l r = This . Internal.fromAscList $ mergeAsc (toAscList l) (toAscList r) where mergeAsc :: Ord a => [a] -> [a] -> [a] mergeAsc [] ys = ys mergeAsc xs [] = xs mergeAsc ls@(x:xs) rs@(y:ys) = case compare x y of EQ -> x : mergeAsc xs ys LT -> x : mergeAsc xs rs GT -> y : mergeAsc rs ys

4 7

ReadP and choice
by Ian Lynagh 26 Feb '12

26 Feb '12

Hi all, The code below defines a ReadP parser which can parse either a keyword "wrapper" or an arbitrary identifier. I was hoping that it would give the output (CWrapper1,"") (CWrapper2,"") (CFunction "wrapper","") but it actually gives (CWrapper2,"") (CFunction "wrapper","") (CWrapper1,"") i.e. completed parses are returned before the parse that needs to "look" at the remaining input. I can see the logic behind the current behaviour, but in this case at least it's quite inconvenient. What do you think? Did I miss a better way to solve the problem? Should the behaviour be changed? If so, is changing it easy? import Data.Char import Control.Applicative ((<$>)) import Text.ParserCombinators.ReadP as ReadP main :: IO () main = mapM_ print test test :: [(CImportSpec, String)] test = readP_to_S parse "wrapper" where parse = do r <- choice [ token "wrapper" >> return CWrapper1, string "wrapper" >> return CWrapper2, CFunction <$> many1 (satisfy isAlpha) ] eof return r token str = do _ <- string str toks <- look case toks of c : _ | isAlpha c -> pfail _ -> return () data CImportSpec = CFunction String | CWrapper1 | CWrapper2 deriving Show Thanks Ian

2 1

Vector memory usage
by Ben Gamari 24 Feb '12

24 Feb '12

Recently I stumbled upon a rather non-obvious behavior in what seems like a fairly common use a vector[1]. It appears that, despite the claim of the documentation, dropWhile can result in copies, resulting in a 1MB vector ballooning to several gigabytes within a few seconds. This has been reproduced with ghc 7.4.1 and 7.0.3 with -O and -prof. My knowledge of the internals of vector is quite limited, so I'll leave potential explanations to those with better understanding; below I've attached some relevant discussion from #haskell. Let me know if there's anything at all I could do to help. Cheers, - Ben [1] http://hackage.haskell.org/trac/ghc/ticket/5893 Test case: import qualified Data.Vector.Unboxed as V type Time = Int spansPhotons :: V.Vector Time -> [(Time,Time)] -> [V.Vector Time] spansPhotons ts spans = map (\(start,_)->V.takeWhile (<start) ts) spans main = do let times = V.generate 1000000 (*100) spans = [(10000*i, 10000*i+5000) | i <- [1..10000]] let bursts = spansPhotons times spans print $ sum $ map V.length bursts print $ map (const 1) $ bursts 00:16 < rwbarton> there the problem is that the bursts aren't sharing the same memory 00:17 < rwbarton> like they would if you wrote a similar program with ByteString 00:17 < rwbarton> the thing is that the Vector implementation of dropWhile is good for the stream fusion situation where you have a pipeline of operations 00:17 < quintessence> Yeah, I don't think dropWhile can participate in stream fusion and not copy 00:18 < rwbarton> but not good when you want to dropWhile many different times on the same input 00:18 < rwbarton> right 00:18 < quintessence> because when you have dropWhile p . map f the thing you want to share with doesn't exist 00:18 < rwbarton> so I don't know what the resolution would be 00:18 < bgamari> ouch 00:18 < rwbarton> besides giving some more manual control over stream fusion perhaps 00:19 < bgamari> Yep 00:20 < bgamari> That is a tricky one 00:20 < dmwit> dropWhileFusable + dropWhileCopy 00:20 < dmwit> err... 00:21 < dmwit> dropWhileFusable + dropWhileDoesn'tCopy, I guess 00:21 < quintessence> Could you implement dropWhile the non-fusing way and then have a RULE for dropWhile p . unstream = unstream . S.dropWhile p? 00:21 < rwbarton> at the least you could implement dropWhile' the non-fusing way; maybe that already exists somewhere in Data.Vector 00:21 < tibbe> Isn't there a function to explicitly copy? Like ByteString's clone? 00:21 < rwbarton> there is 00:21 < rwbarton> but the goal here is to not copy 00:22 < tibbe> I'm joining this discussion late I'm afraid :) 00:22 < tibbe> it should be possible to write rules that only fire when fusion doesn't happen 00:22 < rwbarton> the issue is a program like http://hpaste.org/64262#a64263 ends up allocating a bunch of nonoverlapping vectors 00:22 < tibbe> they could do sharing, but the performance model might turn out to be confusing 00:22 < rwbarton> when it could share them (and the documentation would have you believe it does) 00:23 < tibbe> how would you document dropWhile? Might share the underlying vector? 00:23 < bgamari> tibbe: the performance model is already a bit confusing ;) 00:23 < tibbe> :) 00:24 < bgamari> I'm surprised I'm the first person to encounter this 00:25 < bgamari> The bug report is http://hackage.haskell.org/trac/ghc/ticket/5893#comment:1 00:29 < bgamari> rwbarton, Do you mind if I quote you in a message to libraries@?

2 1

Hackage documentation down?
by wren ng thornton 24 Feb '12

24 Feb '12

Hello all, I posted a minor update to unix-bytestring a few days ago in order to deal with the Num not implying Eq thing in GHC 7.4, but it looks like the documentation still hasn't been made (nor the built-on field). Are the Hackage builders down intentionally since the recent crash, or accidentally? -- Live well, ~wren

1 0

Wait... System.Posix.IO.ByteString reads data into a *String*?
by Ryan Newton 23 Feb '12

23 Feb '12

I was very surprised to find "fdRead" returning a String in the ByteString version of the library: http://hackage.haskell.org/packages/archive/unix/2.5.1.0/doc/html/System-Po… Unlike, for example the fdRead in unix-bytestring: http://hackage.haskell.org/packages/archive/unix-bytestring/0.3.5/doc/html/… I belatedly found the below thread when trying to figure out what went down with unix-2.5.1.0, and it seems that the impetus for the ".ByteString" modules was to change file path representation, not the representation of file contents. But I'm missing why this would be. If it is a distinct module namespace, why would there be any backwards compatibility concerns? And if taking this one step towards ByteString why not go all the way? (Especially as file contents are much larger and therefore more performance critical than file names.) -Ryan On Fri, Nov 11, 2011 at 11:23 AM, Simon Marlow <marlowsd(a)gmail.com> wrote: > I propose to commit the attached patch to the unix package and release it > with GHC 7.4.1. The commit log is reproduced below. Comments please! > > The unix version number will of course be bumped appropriately. > > Cheers, > Simon > > commit d5e43be90d3c6f8869dd2b0c65800c**9a6dd0ac70 > Author: Simon Marlow <marlowsd(a)gmail.com> > Date: Fri Nov 11 16:18:48 2011 +0000 > > Provide a raw ByteString version of FilePath and environment APIs > > The new module System.Posix.ByteString provides exactly the same API > as System.Posix, except that: > > - There is a new type: RawFilePath = ByteString > > - All functions mentioning FilePath in the System.Posix API > use RawFilePath in the System.Posix.ByteString API > > - RawFilePaths are not subject to Unicode locale encoding and > decoding, unlike FilePaths. They are the exact bytes passed to > and returned from the underlying POSIX API. > > - Similarly for functions that deal in environment > strings (System.Posix.Env): these use untranslated ByteStrings > in System.Posix.Environment > > - There is a new function > > System.Posix.ByteString.**getArgs :: [ByteString] > > returning the raw untranslated arguments as passed to exec() > when the program was started. > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries > >

4 5

Num instances for Sum and Product
by Dan Burton 22 Feb '12

22 Feb '12

Data.Monoid in the base package specifies newtypes Sum and Product. It would be convenient if these newtypes had appropriate Num instances, which are trivial to write in plain Haskell: import Data.Monoid liftTy2 wrap unwrap op x y = wrap $ unwrap x `op` unwrap yliftTy wrap unwrap f = wrap . f . unwrap liftSum = liftTy Sum getSumliftSum2 = liftTy2 Sum getSum instance (Num a) => Num (Sum a) where (+) = liftSum2 (+) (-) = liftSum2 (-) (*) = liftSum2 (*) abs = liftSum abs negate = liftSum negate signum = liftSum signum fromInteger = Sum . fromInteger liftProd = liftTy Product getProductliftProd2 = liftTy2 Product getProduct instance (Num a) => Num (Product a) where (+) = liftProd2 (+) (-) = liftProd2 (-) (*) = liftProd2 (*) abs = liftProd abs negate = liftProd negate signum = liftProd signum fromInteger = Product . fromInteger Or with a few extensions (as noted by Daniel Wagner): {-# LANGUAGE StandaloneDeriving, GeneralizedNewtypeDeriving #-} import Data.Monoid deriving instance Num a => Num (Sum a)deriving instance Num a => Num (Product a) -- Dan Burton

1 0

enummapset merge into containers
by Ben Gamari 22 Feb '12

22 Feb '12

Not so long ago, it was suggested[1] that enummapset[2] might be a good candidate for merge into containers. Having found this package to be very useful in the past, I would find this quite nice. Would others find this a reasonable proposal? If so, what needs to be done to make this happen? Cheers, - Ben [1] http://blog.ezyang.com/2011/08/changes-to-intmap/comment-page-1/#comment-28… [2] http://hackage.haskell.org/package/enummapset

4 6

Fwd: New STM?
by wren ng thornton 19 Feb '12

19 Feb '12

-------- Original Message -------- Message-ID: <4F3E9E3E.3070804(a)freegeek.org> Date: Fri, 17 Feb 2012 13:36:46 -0500 To: GHC-users List <glasgow-haskell-users(a)haskell.org> Hello all, I had some patches committed to STM a while back[1], and for some reason I was expecting them in the new GHC release. Does STM only ship with the Platform? If not, then any idea when the next version of STM will be released? [1] http://hackage.haskell.org/trac/ghc/ticket/5104 http://www.haskell.org/pipermail/cvs-libraries/2011-April/012914.html -- Live well, ~wren

1 0

Proposal: Remove Control.OldException
by Ian Lynagh 19 Feb '12

19 Feb '12

Hi all, We've had Control.OldException, and the new Control.Exception, since GHC 6.10.1, and since 6.12.1 using Control.OldException has given the deprecation message Future versions of base will not support the old exceptions style. Please switch to extensible exceptions. I propose that we now remove it from base. If some people still cannot use the new Control.Exception for some reason, then it could be maintained in an old-exception package. Discussion deadline: 18 Feb 2012. Thanks Ian

8 11

generalization of maybeToList
by Jeff Shaw 15 Feb '12

15 Feb '12

I find myself using this function quite a lot. I believe it should be included in Data.Maybe. import Control.Monad maybeTo :: (MonadPlus m) => Maybe a -> m a maybeTo = maybe mzero return

5 9

RE: Changes to Typeable
by Simon Peyton-Jones 14 Feb '12

14 Feb '12

| Should there perhaps be a NewTypeable module which could then be renamed | into Typeable once it is sufficiently well established? I started with that idea, but there would be a 2-stage process: * Step 1: (when PolyTypable becomes available) People change to import Data.PolyTypeable * Step 2: (when PolyTypeable becomes Typeable) People change back to Data.Typeable I was hoping to avoid that. Notice that even if we replace Typeable immediately with the new polymorphic one, doing so has very limited impact: for users who just use "deriving Typeable" and "typeOf", that will work fine with the new thing too. But I'm sure that some "seams" would show through. It's a balance. Simon

3 2

Something's weird about System.Directory.removeDirectoryRecursive
by John Millikin 09 Feb '12

09 Feb '12

http://hackage.haskell.org/packages/archive/directory/1.1.0.1/doc/html/Syst… The documentation says that removeDirectoryRecursive follows symlinks. However, the implementation doesn't (in most cases, see below). ------------------------------------------------------------------------------------------------------------ $ mkdir test-removeDirectoryRecursive $ cd test-removeDirectoryRecursive $ mkdir a b $ touch a/a.txt b/b.txt $ ln -s $PWD/b a/ $ ln -s $PWD/b/b.txt a/ $ ls -l a total 8.2k -rw-rw-r-- 1 john john 0 2012-01-27 23:33 a.txt lrwxrwxrwx 1 john john 65 2012-01-27 23:33 b -> /home/john/test-removeDirectoryRecursive/b lrwxrwxrwx 1 john john 71 2012-01-27 23:34 b.txt -> /home/john/test-removeDirectoryRecursive/b/b.txt # OK, a/ has a normal file and two symlinks in it. Let's recursively remove a/ and see what happens. $ ghci Prelude> import System.Directory Prelude System.Directory> removeDirectoryRecursive "a" Prelude System.Directory> Leaving GHCi. $ ls -l a b ls: cannot access a: No such file or directory b: total 0 -rw-rw-r-- 1 john john 0 2012-01-27 23:33 b.txt # a/ was removed -- good! # # b/ and its contents are untouched, good, but goes against the docs ------------------------------------------------------------------------------------------------------------ Now, there is one case where this function *will* follow symlinks. However, I believe it is a bug because it produces odd behavior: ------------------------------------------------------------------------------------------------------------ $ sudo mkdir a [sudo] password for john: $ sudo ln -s $PWD/b a/ $ ls -l a b a: total 4.1k lrwxrwxrwx 1 root root 65 2012-01-27 23:38 b -> /home/john/test-removeDirectoryRecursive/b b: total 0 -rw-rw-r-- 1 john john 0 2012-01-27 23:33 b.txt # Now a/ has a symlink, which cannot be deleted, because its containing directory is read-only to the current user. $ rm a/b rm: remove symbolic link `a/b'? y rm: cannot remove `a/b': Permission denied # What happens if removeDirectoryRecursive is called now? $ ghci Prelude> import System.Directory Prelude System.Directory> removeDirectoryRecursive "a" *** Exception: a/b: removeDirectory: permission denied (Permission denied) Prelude System.Directory> Leaving GHCi. $ ls -l a b a: total 4.1k lrwxrwxrwx 1 root root 65 2012-01-27 23:38 b -> /home/john/test-removeDirectoryRecursive/b b: total 0 # a/ is untouched, but b/ has been emptied! ------------------------------------------------------------------------------------------------------------ So what is the expected behavior of this function? What should it do in the presence of symlinks? IMO, the function should be documented as *not* following symlinks, and the directory check should be changed so that it returns False for symlink-to-directory.

3 2

Re: [Haskell-cafe] The State of Testing?
by Thomas Tuegel 09 Feb '12

09 Feb '12

On Wed, Feb 8, 2012 at 4:42 AM, Christoph Breitkopf <chbreitkopf(a)googlemail.com> wrote: > Hello Thomas, > > On Wed, Feb 8, 2012 at 4:03 AM, Thomas Tuegel <ttuegel(a)gmail.com> wrote: >> >> First, as author of the test suite code, let me apologize for the >> terrible documentation. >> >> This is absolutely NOT how coverage reports are supposed to work. If >> you configure with '--enable-tests --enable-library-coverage', Cabal >> will take care of _everything_ else for you, including excluding the >> test module from the coverage report. You should not have to put any >> flag gymnastics in your .cabal file. > > > I get only "cabal: unrecognized option `--enable-library-coverage'" when > doing that. Which cabal version do I need? > Can you point me to any docs about this? I'm still using test type > exitcode-stdio-1.0, because I could not get detailed-1.0 to work. You need Cabal 1.12 for '--enable-library-coverage'. The only place it's documented is in 'cabal configure --help' (a major oversight on my part). The online docs for Cabal are only from version 1.10 anyway, so that wouldn't have helped. I'm sorry for your struggles getting the detailed type to work. It's a known issue: the detailed test interface is intentionally disabled in all the released versions because it's going to change. That's why none of the test libraries support it yet and why you weren't able to get it to work. -- Thomas Tuegel

1 0

Template Haskell: dataToExpQ and constructor mis-match
by Conal Elliott 08 Feb '12

08 Feb '12

I'm looking for a reliable way to turn values into Template Haskell expressions. I thought dataToExpQ from Language.Haskell.TH.Quote was the ticket, but it appears to produce constructors different from those produced by [| ... |], including [], (:), (), and (,). Here's an example run for (). I'm using template-haskell-2.5.0.0: GHCi, version 7.0.4: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Data Prelude Data.Data> import Language.Haskell.TH Prelude Data.Data Language.Haskell.TH> :set -XTemplateHaskell Prelude Data.Data Language.Haskell.TH> import Language.Haskell.TH.Quote Prelude Data.Data Language.Haskell.TH Language.Haskell.TH.Quote> u1 <- runQ (dataToExpQ (const Nothing) ()) Prelude Data.Data Language.Haskell.TH Language.Haskell.TH.Quote> u2 <- runQ [| () |] Prelude Data.Data Language.Haskell.TH Language.Haskell.TH.Quote> u1 ConE () Prelude Data.Data Language.Haskell.TH Language.Haskell.TH.Quote> u2 ConE GHC.Unit.() Prelude Data.Data Language.Haskell.TH Language.Haskell.TH.Quote> u1 == u2 False Any suggestions? -- Conal

2 1

Re: [Haskell-cafe] The State of Testing?
by Thomas Tuegel 08 Feb '12

08 Feb '12

On Tue, Feb 7, 2012 at 3:23 PM, Austin Seipp <mad.one(a)gmail.com> wrote: > If you're writing a library, you need to compile the library with > `-fhpc`, i.e. put it in the library stanza, not the testsuite stanza, > and then you can compile the test program using your library - the > resulting 'tix' file will contain the library coverage reports. You > can link a HPC-built library into an executable not compiled with HPC > just fine. > > Normally I only compile the library under HPC mode, link it in a test, > and distribute the results from that. That way your coverage reports > don't include the test module (which may or may not be relevant.) > > I normally add a cabal flag called 'hpc' which optionally enables > coverage reports for my library, e.g. > > flag hpc > default: False > > library > ... > ... > if flag(hpc) > ghc-options: -fhpc > > Then when you want coverage reports, just say 'cabal install -fhpc > --enable-tests' and the resulting properties executable will spit out > the results when run. First, as author of the test suite code, let me apologize for the terrible documentation. This is absolutely NOT how coverage reports are supposed to work. If you configure with '--enable-tests --enable-library-coverage', Cabal will take care of _everything_ else for you, including excluding the test module from the coverage report. You should not have to put any flag gymnastics in your .cabal file. If this doesn't work for you, please let me know, because it's a bug. Thanks! -- Thomas Tuegel

2 1

Proposal: Add getStdGenState and stdGenFromState
by Bas van Dijk 08 Feb '12

08 Feb '12

Dear Ryan, all, To quote the documentation of System.Random: "The Show and Read instances of StdGen provide a primitive way to save the state of a random number generator." Primitive it is indeed. Currently the only way to serialize (using cereal or binary) a StdGen is to convert it to a String and then serialize this String. This takes up many more bytes than are actually needed. I would like to propose a more efficient way of serializing the state of the random number generator by providing the following two functions: getStdGenState :: StdGen -> (Int32, Int32) getStdGenState (StdGen s1 s2) = (s1, s2) stdGenFromState :: (Int32, Int32) -> StdGen stdGenFromState (s1, s2) = StdGen s1 s2 Of course this satisfies: (stdGenFromState . getStdGenState) g == g Alternatively, instead of using (Int32, Int32) we can use an Int64: getStdGenState :: StdGen -> Int64 getStdGenState (StdGen s1 s2) = fromIntegral s1 `unsafeShiftL` 32 .|. fromIntegral s2 #if !MIN_VERSION_base(4,5,0) where unsafeShiftL = shiftL #endif stdGenFromState :: Int64 -> StdGen stdGenFromState s = StdGen (fromIntegral (s `unsafeShiftR` 32)) (fromIntegral s) #if !MIN_VERSION_base(4,5,0) where unsafeShiftR = shiftR #endif I don't really care which one we use but I think the latter is a bit easier to use. Oh, I don't really care about the names either. Regards, Bas

5 7

Re: [Haskell-cafe] The State of Testing?
by Ryan Newton 07 Feb '12

07 Feb '12

By the way, has anyone else had trouble with "cabal test" diverging? I've been running into this issue with cabal 0.10.2, but ONLY in conjunction with GHC 6.12.3. It's hard to make a small reproducer for (and therefore I haven't filed a bug yet), but you can see the below Jenkins run stalled for 2.5 days, whereas it should take minutes: http://tester-lin.soic.indiana.edu:8080/job/monad-par_github_master/JENKINS… Note that it *doesn't* burn CPU -- it deadlocks rather than spins. I replaced "cabal test" with a direct call to the test executable and I haven't seen this problem since. -Ryan On Tue, Feb 7, 2012 at 4:23 PM, Austin Seipp <mad.one(a)gmail.com> wrote: > If you're writing a library, you need to compile the library with > `-fhpc`, i.e. put it in the library stanza, not the testsuite stanza, > and then you can compile the test program using your library - the > resulting 'tix' file will contain the library coverage reports. You > can link a HPC-built library into an executable not compiled with HPC > just fine. > > Normally I only compile the library under HPC mode, link it in a test, > and distribute the results from that. That way your coverage reports > don't include the test module (which may or may not be relevant.) > > I normally add a cabal flag called 'hpc' which optionally enables > coverage reports for my library, e.g. > > flag hpc > default: False > > library > ... > ... > if flag(hpc) > ghc-options: -fhpc > > Then when you want coverage reports, just say 'cabal install -fhpc > --enable-tests' and the resulting properties executable will spit out > the results when run. > > On Tue, Feb 7, 2012 at 3:16 PM, Michael Craig <mkscrg(a)gmail.com> wrote: > > Thanks for the advice, all. I've got test-framework, quickcheck, and > cabal's > > test-suite all working together nicely. > > > > Cabal seems to support using hpc to check test coverage. If I add -fhpc > to > > the ghc-options under the test-suite, I get output like "Test coverage > > report written to dist/hpc/html/tests/hpc_index.html" and "Package > coverage > > report written to dist/hpc/html/test-0.0.0/hpc_index.html", but those > html > > files are just empty tables. How does this work? > > > > Mike Craig > > > > > > > > > > On Thu, Feb 2, 2012 at 8:45 PM, Ivan Lazar Miljenovic > > <ivan.miljenovic(a)gmail.com> wrote: > >> > >> On 03/02/2012 12:22 PM, "Johan Tibell" <johan.tibell(a)gmail.com> wrote: > >> > > >> > On Thu, Feb 2, 2012 at 4:46 PM, Conrad Parker <conrad(a)metadecks.org> > >> > wrote: > >> >> > >> >> On 3 February 2012 08:30, Johan Tibell <johan.tibell(a)gmail.com> > wrote: > >> >> > On Thu, Feb 2, 2012 at 4:19 PM, Conrad Parker < > conrad(a)metadecks.org> > >> >> > wrote: > >> >> >> > >> >> >> I've followed what Johan Tibbell did in the hashable package: > >> >> > > >> >> > > >> >> > If I had known how much confusion my childhood friends would > unleash > >> >> > on the > >> >> > Internet when they, at age 7, gave me a nickname that's spelled > >> >> > slightly > >> >> > differently from my last name, I would have asked them to pick > >> >> > another one. > >> >> > ;) > >> >> > >> >> lol, sorry, I actually double-checked the number of l's before > writing > >> >> that but didn't consider the b's. For future reference I've produced > a > >> >> handy chart: > >> >> > >> >> > >> >> > >> >> Letter | Real-name count | Nickname count > >> >> -------+-----------------+--------------- > >> >> b | 1 | 2 > >> >> l | 2 | 0 > >> >> -------+-----------------+--------------- > >> >> SUM | 3 | 2 > >> >> > >> > > >> > Excellent. I will tattoo it on my forehead. > >> > >> There is, of course, a simpler (but not necessarily easier :p) solution: > >> change your name to match your nickname! > >> > >> > > >> > > >> > _______________________________________________ > >> > Haskell-Cafe mailing list > >> > Haskell-Cafe(a)haskell.org > >> > http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > > >> > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe(a)haskell.org > >> http://www.haskell.org/mailman/listinfo/haskell-cafe > >> > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > -- > Regards, > Austin > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

2 1

Re: [Haskell-cafe] The State of Testing?
by Michael Craig 07 Feb '12

07 Feb '12

Thanks for the advice, all. I've got test-framework, quickcheck, and cabal's test-suite all working together nicely. Cabal seems to support using hpc to check test coverage. If I add -fhpc to the ghc-options under the test-suite, I get output like "Test coverage report written to dist/hpc/html/tests/hpc_index.html" and "Package coverage report written to dist/hpc/html/test-0.0.0/hpc_index.html", but those html files are just empty tables. How does this work? Mike Craig On Thu, Feb 2, 2012 at 8:45 PM, Ivan Lazar Miljenovic < ivan.miljenovic(a)gmail.com> wrote: > On 03/02/2012 12:22 PM, "Johan Tibell" <johan.tibell(a)gmail.com> wrote: > > > > On Thu, Feb 2, 2012 at 4:46 PM, Conrad Parker <conrad(a)metadecks.org> > wrote: > >> > >> On 3 February 2012 08:30, Johan Tibell <johan.tibell(a)gmail.com> wrote: > >> > On Thu, Feb 2, 2012 at 4:19 PM, Conrad Parker <conrad(a)metadecks.org> > wrote: > >> >> > >> >> I've followed what Johan Tibbell did in the hashable package: > >> > > >> > > >> > If I had known how much confusion my childhood friends would unleash > on the > >> > Internet when they, at age 7, gave me a nickname that's spelled > slightly > >> > differently from my last name, I would have asked them to pick > another one. > >> > ;) > >> > >> lol, sorry, I actually double-checked the number of l's before writing > >> that but didn't consider the b's. For future reference I've produced a > >> handy chart: > >> > >> > >> > >> Letter | Real-name count | Nickname count > >> -------+-----------------+--------------- > >> b | 1 | 2 > >> l | 2 | 0 > >> -------+-----------------+--------------- > >> SUM | 3 | 2 > >> > > > > Excellent. I will tattoo it on my forehead. > > There is, of course, a simpler (but not necessarily easier :p) solution: > change your name to match your nickname! > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

Improve System.Environment haddocks
by Gwern Branwen 07 Feb '12

07 Feb '12

17:52:34 < goodgrue> Is there a way to change the environment variables associated with Xmonad.Prompt.Shell at runtime? e.g. I'd like to be able to modify $http_proxy and have that affect subsequently launched processes. 17:55:31 < gwern> goodgrue: that'd be kind of hard. you could prepend a mpodification of $HTTP_PROXY to each command 17:56:10 < gwern> ideally you'd modify xmonad's own environment 17:56:33 < goodgrue> gwern: yeah, the latter is what I was thinking of. is that possible? 17:57:08 < gwern> shell uses `getEnv` from System.Environment but there's no setEnv! 17:57:21 < gwern> if there were, you could probably bind it to a key and use a prompt 17:58:44 < goodgrue> Hm...sounds like this may be a nice piece of missing functionality. is there any reason you can think of that i wouldn't be able to implement setEnv myself? 17:59:04 < gwern> http://hackage.haskell.org/trac/ghc/ticket/3587 17:59:14 < gwern> looks like 'putEnv' may be the real name -- gwern http://www.gwern.net

2 3

Proposal: Derive Typeable instance for StdGen
by Bas van Dijk 06 Feb '12

06 Feb '12

Dear all, I would like to propose deriving a Typeable instance for System.Random.StdGen. Discussion deadline: 2 weeks from now: Monday, 20 February. Regards, Bas

3 3

"missing" Eq instance for ErrorCall
by Simon Hengel 06 Feb '12

06 Feb '12

Is there a good reason for not having an Eq instance for Control.Exception.ErrorCall? Somewhat related, what are the Ord instances (e.g. for ArithException) meant for? Cheers, Simon

1 0

Oddity with 'cabal install' in GHC 7.4.1
by Conal Elliott 06 Feb '12

06 Feb '12

Since upgrading to 7.4.1, if I 'cabal install' successfully and then 'cabal install' a second time without first doing a 'ghc-pkg unregister <package-name>', I get the following complaint: cabal: The install plan contains reinstalls which can break your GHC > installation. You can try --solver=modular for the new modular solver that > chooses such reinstalls less often and also offers the --avoid-reinstalls > option. You can also ghc-pkg unregister the affected packages and run > ghc-pkg > check to see the effect on reverse dependencies. If you know what you are > doing you can use the --force-reinstalls option to override this reinstall > check. > The only path I've found so far that's willing to rebuild or even say nothing needs rebuilding (when nothing does) is to 'ghc-pkg unregister' and then 'cabal install' again. I'm getting the same behavior on Red Hat 5 and Mac OS 10.6.8, both compiled from sources. Does anyone know what's going on here? -- Conal

4 9

Cabal-install bug
by wren ng thornton 05 Feb '12

05 Feb '12

Hello all, The cabal/cabal-install bug tracker seems to be down, so I'm not sure if this is a known issue or not... When playing around with JHC earlier I ran into the following errors: $> cabal --version cabal-install version 0.10.2 using version 1.10.2.0 of the Cabal library $> cabal install --dry-run --jhc --verbose base Reading available packages... Resolving dependencies... cabal: internal error: impossible $> cabal install --dry-run --ghc --verbose base Reading available packages... Resolving dependencies... cabal: Distribution/Client/Dependency/TopDown.hs:171:37-73: Non-exhaustive patterns in lambda $> cabal install --dry-run --verbose base Reading available packages... Resolving dependencies... cabal: Distribution/Client/Dependency/TopDown.hs:171:37-73: Non-exhaustive patterns in lambda I've seen that problem before, though I can't recall where off-hand. Anyone know if this (a) has been reported, (b) has been fixed? -- Live well, ~wren

2 2

Add meaningful instances to ZipList
by Daniel Peebles 01 Feb '12

01 Feb '12

I noticed that the ZipList newtype in Control.Applicative has no derived instances at all. We can't show a ZipList, check it for equality, or do anything to it except unpack it or treat it like an Applicative or Functor. It seems fairly uncontroversial to suggest adding some instances for it, but there are some minor questions to address: the obvious instances to add might be Eq, Ord, Show, Read, and possibly Typeable and/or Data. Are there any others I've missed? For the Read/Show instances, do we want manual ones that don't use the verbose record-style output? Since it's just defined as data ZipList a = ZipList { getZipList :: [a] } to get an easy accessor (does anyone actually use getZipList as a field for record updates?), it might be easier to write the projection manually and change the definition to data ZipList a = ZipList [a] with a separate getZipList function, so the deriving mechanism can give us a less noisy Show instance. Discussion period: 2 weeks, I guess - Dan

6 9