documentation patch for process

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 <at> 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 <at> 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@:

Proposal: Add getStdGenState and stdGenFromState

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

Proposal: Derive Typeable instance for StdGen

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

From ce812701f8e68e67fc55ebdfdd7770f88d00ef60 Mon Sep 17 00:00:00 2001
From: Bas van Dijk <v.dijk.bas <at> gmail.com>
Date: Mon, 6 Feb 2012 16:32:53 +0100
Subject: [PATCH] Derive a Typeable instance for StdGen

---
 System/Random.hs |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/System/Random.hs b/System/Random.hs
index 9a970c4..7269abc 100644
--- a/System/Random.hs
+++ b/System/Random.hs
@@ -1,3 +1,5 @@
+{-# LANGUAGE DeriveDataTypeable #-}
+
 #if __GLASGOW_HASKELL__ >= 701
 {-# LANGUAGE Trustworthy #-}
 #endif

"missing" Eq instance for ErrorCall

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

Cabal-install bug

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?

Oddity with 'cabal install' in GHC 7.4.1

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Proposal: Remove Control.OldException

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

Something's weird about System.Directory.removeDirectoryRecursive

http://hackage.haskell.org/packages/archive/directory/1.1.0.1/doc/html/System-Directory.html#v:removeDirectoryRecursive

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.

printf too strict?

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Broken Packages (and Maintainers) for poppler, hsc2hs

All,

Sorry if I'm a bit bitter - just ran into breakage of poppler, hsc2hs,
and zlib in a 20 minute stretch.

If the maintainers are here:

1) Please set a proper e-mail address (one that isn't a protected ML).
2) Please at least make sure the installation works (or the file at
least parses!) via cabal-install.

Cheers,
Thomas

Proposal: more general unionWith for Data.Map

2012/1/24 Johan Tibell <johan.tibell <at> gmail.com>
>
> On Tue, Jan 24, 2012 at 9:35 AM, Christian Sattler
> <sattler.christian <at> gmail.com> wrote:
> > There are some high-level operations on maps which take two tree traversals
> > only because the interface fails to expose sufficiently general functions.
> > This proposal is concerned with an analogue of unionWithKey of type Ord k =>
> > (k -> a -> a -> Maybe a) -> Map k a -> Map k a -> Map k a, with the intended
> > semantics that if a key is present in both maps and the operation applied to
> > the key and corresponding values returns Nothing, the key is deleted from
> > the result.
>
> Is union really an appropriate name here? I expect the following to hold:
>
> forall k ∊ (keys m1) ∪ (keys m2) => k ∊ (m1 ∪ m2)
>
> This means that keys must not be deleted by the union operator.
> Perhaps 'merge' is a better name.
>
> Cheers,
> Johan

I don't care much about the naming, but note that the analogous
property already fails for the generalized intersectionWithKey in the
development version.

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries