November 2008 - Glasgow-haskell-users

Control.Exception
by Johannes Waldmann 05 Nov '08

05 Nov '08

with 6.10, the following does not typecheck: foo `Control.Exception.catch` \ _ -> return bar Ambiguous type variable `e' in the constraint: `Control.Exception.Exception e' It is probably bad programming style anyway but what is the workaround? I found some references (in list emails) to catchAny, ignoreExceptions but these don't seem to have made it? Best regards, J.W.

9 17

Re: Control.Exception
by shelarcy 04 Nov '08

04 Nov '08

On Tue, 04 Nov 2008 19:41:58 +0900, Duncan Coutts <duncan.coutts(a)comlab.ox.ac.uk> wrote: >> >> action >> >> `catches` >> >> [ \(e :: ExitCode) -> ... >> >> , \(e :: PatternMatchFail) -> ... >> >> ] >> >> >> >> or just by using multiple catch clauses: >> >> >> >> action >> >> `catch` (\(e :: ExitCode) -> ...) >> >> `catch` (\(e :: PatternMatchFail) -> ...) >> > >> > I don't think those are equivalent. In the second case, the >> > PatternMatchFail handler scopes over the ExitCode handler. >> >> I think Duncan forgot to write parens. According to Ian's example, >> here is an equivalent code. >> >> (action >> `catch` (\(e :: ExitCode) -> ...)) >> `catch` (\(e :: PatternMatchFail) -> ...) > > David is right. If the exit code handler throws a pattern match > exception then the code behaves differently than the `catches` version. I see. I misunderstood the problem. Thanks, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/

1 0

ANNOUNCE: GHC 6.10.1 RC 1
by Ian Lynagh 03 Nov '08

03 Nov '08

We are pleased to announce that the GHC 6.10.0.20081007 snapshot is the first release candidate for GHC 6.10.1. You can download the release candidate from here: http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html This page includes: * a Windows installer * an OS X installer * bindists for amd64/Linux and ix86/Linux * the sources There is also a status page here: http://hackage.haskell.org/trac/ghc/wiki/GHC-6.10.1 where we will keep track of where the RC works, and where it is known to have problems. This is a wiki page, so please feel free to update it if you are able to add or update the information on a particular platform. Please test as much as possible; bugs are much cheaper if we find them before the release! We hope that we will be able to make the final release in around one weeks time, but of course that may slip if problems are uncovered. Thanks Ian, on behalf of the GHC team

8 15

Dilemma: DiffArray non-performance vs STArray non-readability
by Claus Reinke 03 Nov '08

03 Nov '08

I keep wanting to use DiffArray as the natural functional solution to single-threaded array use. But everytime I try, I get smacked over the head with the actual performance figures. Sometimes, even plain arrays are faster in a loop doing array updates, in spite of all the copying involved. And when copying on update dominates the runtime, using IntMap tends to be faster - the "indirections" are the wrong way round, but don't pile up, just that array lookups aren't quite constant time. But when I really need to avoid the updates, and need constant time lookup, I'm stuck: DiffArray tends to slow everything down (I vaguely recall locks and threads being at the heart of this, but I haven't checked the code recently), so my only option seems to be to transform my nice functional code into not-nice sequential code and use STArray. Is there any way out of this dilemma? What do other Ghc users use? If locks really are the issue, perhaps using STM instead of MVars in the DiffArray implementation could help. As long as my array uses are single-threaded, STM optimism might be able to avoid waiting/scheduler issues? Or am I on the wrong track? Claus PS Btw, I thought the DiffArray performance issue was ancient, but I can't find a ticket for it, nor does the haddock page for Data.Array.Diff mention this little hickup. Should I add a ticket?

4 4

cabal
by Christian Maeder 01 Nov '08

01 Nov '08

Hi, currently I've got a problem installing from hackage. using: GHC (package manager) version 6.10.0.20081019 cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library I get: Building network-2.2.0.0... Network/URI.hs:128:7: Could not find module `Data.Generics': it is a member of package base-3.0.3.0, which is hidden even with: cabal install network --constrain="base<4" (A similar problem happened with Shellac.) How is the smart selection between base-3 and base-4 going to work? Eventually, I want to install hxt-filter and Shellac-compatline. (The interface in editline changed for Shellac-editline.) Cheers Christian

4 6