September 2008 - Glasgow-haskell-users

Is FPH implemented in GHC?
by Wolfgang Jeltsch 13 Sep '08

13 Sep '08

Hello, is FPH implemented in GHC? If yes, will it be part of GHC 6.10.1? Best wishes, Wolfgang

4 8

gcc-looking error when building GHC 6.8.3 from source - "directives may not be used inside a macro argument"
by Jeff Evans 13 Sep '08

13 Sep '08

Hi everyone, I am trying to build GHC 6.8.3 from source in a slightly nonstandard environment (mostly with regard to the filesystem). The build setup, however, is fairly standard (32-bit x86 RHEL, gcc 3.4, glibc 2.3). I managed to get the bootstrap installation from the "ghc-6.6.1-x86_64-unknown-linux" tarball (downloaded from http://www.haskell.org/ghc/download_ghc_661.html#x86linux) working without much trouble. Now I'm trying to use that to build 6.8.3 from source. But I am hitting an error in the build target, apparently for this rts component. Output snippet here: http://hpaste.org/10252 The first of the ghc errors is "RtsFlags.c:1120:1: directives may not be used inside a macro argument" which is followed by many more (I think this is the real cause though). I searched around and it seems like a gcc "limitation" (not supporting something that is not part of the C standard but people still wanted). But even then it has supposedly been supported since gcc 3.2, and I'm using 3.4. To be honest, I don't know anything about the interaction between ghc and gcc at this juncture so I'm a bit in the dark. Any advice is appreciated. I can also provide more complete output/details if it would be useful. Thank you!

2 2

Making GHC work on BSD
by Simon Peyton-Jones 12 Sep '08

12 Sep '08

Dear BDS hackers We'd like GHC to be buildable on BSD, but at the moment it isn't. We support GHC on Linux, Windows, Mac, but we really need help with BSD. Alas, we didn't get much response to Simon's message below. (One, I think -- thank you to that person! I think it was Kili, but I'm not sure.) So this message is to say: if you'd like GHC on BSD, please help! No help probably means no GHC. Time is short before GHC 6.10. "Help" means more than "can offer a remote login", but less than "solve it by yourself". We'll try hard to support you if you can invest a bit of time at your end. Many thanks Simon -----Original Message----- From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Simon Marlow Sent: 02 September 2008 13:37 To: GHC Users Mailing List Cc: cvs-ghc(a)haskell.org Subject: *BSD GHC hackers needed... While perusing the tickets in the 6.10.1 milestone I spotted 3 that look to be FreeBSD-specific: 2476 internal error: awaitEvent: descriptor out of range 2502 segfault with GHC.Handle.fdToHandle' 2511 unix package doesnt load in ghci on freebsd/amd64 It's unlikely that we'll get to these in time for 6.10.1. Any FreeBSD hackers out there want to take a look? Help/advice is available as usual. There's also one NetBSD-specific ticket: 2351 NetBSD defines ELF_ST_TYPE (that one is easy), and one that I think applies to all the *BSDs: 2063 Breackage on OpenBSD due to mmap remap (actually the latter one is a top priority, because without it GHCi can't work, so we need it fixed for 6.10.1). Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

7 9

(no subject)
by Mitchell, Neil 08 Sep '08

08 Sep '08

Hi Claus, I was reading your instructions on the GHC wiki page, http://hackage.haskell.org/trac/ghc/wiki/Building/Windows, and they are wonderful - exactly what I wanted. However, they don't work. When downloading Cygwin you are told to add haskell.org/ghc/cygwin as a path so it can pick up the setup.ini file. However, in the latest version of Cygwin it obvious wants signatures for all the .ini files: --------------------------- Cygwin Setup --------------------------- Unable to get http://www.haskell.org/ghc/cygwin/setup.ini.sig from <http://www.haskell.org/ghc/cygwin> --------------------------- OK --------------------------- Could someone please add the appropriate signature file? Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================

2 2

rebinding arrow notation
by Peter Gavin 04 Sep '08

04 Sep '08

Section 8.3.5 of the documentation says: Arrow notation (see Section 8.9, “Arrow notation ”) uses whatever arr, (>>>), first, app, (|||) and loop functions are in scope. But unlike the other constructs, the types of these functions must match the Prelude types very closely. Details are in flux; if you want to use this, ask! I want to do this. Is there anything special I should know? Pete

2 2

Arrow without `>>>'
by Valery V. Vorotyntsev 03 Sep '08

03 Sep '08

Hi, friends, I've built GHC from darcs, and... Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' method? 1. http://darcs.haskell.org/packages/base/Control/Arrow.hs $ ghci GHCi, version 6.9.20080104: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m + Control.Arrow Prelude Control.Arrow> :i Arrow class (Control.Category.Category a) => Arrow a where arr :: (b -> c) -> a b c pure :: (b -> c) -> a b c first :: a b c -> a (b, d) (c, d) second :: a b c -> a (d, b) (d, c) (***) :: a b c -> a b' c' -> a (b, b') (c, c') (&&&) :: a b c -> a b c' -> a b (c, c') -- Defined in Control.Arrow instance Arrow (->) -- Defined in Control.Arrow instance (Monad m) => Arrow (Kleisli m) -- Defined in Control.Arrow Prelude Control.Arrow> Leaving GHCi. I can't build[2] arrows-0.3 package without `>>>' in Arrow. 2. vvv@fun:~/src/arrows$ darcs w { hunk ./Control/Arrow/Operations.hs 36 +import Control.Category ((>>>)) hunk ./Control/Arrow/Transformer/CoState.hs 23 +import Control.Category ((>>>)) } vvv@fun:~/src/arrows$ runhaskell Setup build Preprocessing library arrows-0.3... Building arrows-0.3... [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) Control/Arrow/Transformer/CoState.hs:29:7: `>>>' is not a (visible) method of class `Arrow' The question arises "should I?", but this is one of lambdabot's[3] depencies. 3. http://code.haskell.org/lambdabot/ Thanks a lot! -- vvv

3 3

*BSD GHC hackers needed...
by Simon Marlow 02 Sep '08

02 Sep '08

While perusing the tickets in the 6.10.1 milestone I spotted 3 that look to be FreeBSD-specific: 2476 internal error: awaitEvent: descriptor out of range 2502 segfault with GHC.Handle.fdToHandle' 2511 unix package doesnt load in ghci on freebsd/amd64 It's unlikely that we'll get to these in time for 6.10.1. Any FreeBSD hackers out there want to take a look? Help/advice is available as usual. There's also one NetBSD-specific ticket: 2351 NetBSD defines ELF_ST_TYPE (that one is easy), and one that I think applies to all the *BSDs: 2063 Breackage on OpenBSD due to mmap remap (actually the latter one is a top priority, because without it GHCi can't work, so we need it fixed for 6.10.1). Cheers, Simon

1 0

GADT pattern match in non-rigid context
by Wolfgang Jeltsch 02 Sep '08

02 Sep '08

Hello, I have some code giving me the error message: “GADT pattern match in non-rigid context for … Tell GHC HQ if you'd like this to unify the context”. I reduced my code to the following example which still gives this error message: > data T a b where > > C :: T a [b] > > f :: (forall a'. T a' b) -> T a b > f t = case t of C -> C How do I work around this error? Some former e-mail discussion gave the hint of adding a type signature but this probably doesn’t work in my case. Note also that specializing the type of the argument t to T a b inside the definition of f is not an option since in the real code I need the first argument of T to be universally quantified for calling another function which needs this quantification. I use GHC 6.8.2. Don’t know whether this problem still shows up with GHC HEAD but am interested in hearing whether this is the case. I’m thankful for any help. Best wishes, Wolfgang

2 1

Windows snapshot binaries
by Mitchell, Neil 02 Sep '08

02 Sep '08

Hi, Looking at: http://www.haskell.org/ghc/dist/current/dist/ The latest Windows binary appears to be the 22nd of June, and thus is before things such as the Control.Exception changes, and will not work with the current version of Haddock. Is it possible to get an updated binary? From what I remember, these snapshots are also used for the Windows binary release, so will have to be fixed before 6.10 can be released. Thanks Neil ============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ==============================================================================

1 0

Where STM is unstable at the moment, and how we can fix it
by Sterling Clover 01 Sep '08

01 Sep '08

This email is inspired by the discussion here: http:// hackage.haskell.org/trac/ghc/ticket/2401 As the ticket discusses, unsafeIOToSTM is, unlike unsafePerformIO or unsafeInterleaveIO, genuinely completely unsafe in that there is no way to use it such that a segfault or deadlock is not at least somewhat encouraged. The code attached to the ticket creates a deadlock solely through using it to write to stdout. But, for the same reason that unsafeIOToSTM is unstable, unsafeInterleaveIO now is very unstable as well -- conceivably, data generated from functions with lazy IO (including those in the prelude) could cause deadlocks within STM, and even segfaults. In summary, a "validation" step is performed on all threads inside atomically blocks during garbage collection. This validation step will, on encountering invalid threads (i.e. ones which should be rolled back) immediately kill them dead and retry. This is different than the implementation described in the STM paper, where rollbacks only occur on commit. However, it does add a measure of efficiency. The problem is that the validation code disregards exception handlers, since rollback is not an exception, and so anything embedded in STM that brackets an IO action, for example, can be rolled back without the final part of the exception even being called. As Simon M. notes, the obvious solution would be to turn rollbacks into regular exceptions, but this would open a number of cans of worms. A start, though not sufficient, would be for stm validation to respect blocked status -- not to block on it, obviously, but simply to refuse to rollback a transaction within it. Validation on GC is, after all, only an efficiency trick and implementation detail, and if it lets the occasional invalid transaction stand due to its blocked status, that transaction will simply be cleaned up later anyway. A more thorough solution would be, as I suggest at the end of the ticket, to add a new primitive with similar semantics to block -- blockRollback, of type STM () -> STM (). Anything that took place within blockRollback could not be stopped by validation. Finally, we could "split the difference" between block and blockRollback, by simply setting a rollbackBlocked flag on a *top level* invocation of block within STM, and thenceforth, not unsetting it until that block is exited, regardless of calls to unblock nested inside. This would effectively, without introducing a new primitive, ensure that rollback did not disrupt things terribly, and thus would be the solution that handled the lazyIO issue the best as well. There are lots of interesting applications of STM that require the ability to extend its semantics. To do this is going to require unsafeIOToSTM, just as unsafePerformIO is used on occasion as a low level tool to create safer and better things on top of (or as unsafeCoerce is, for that matter). However, the current state of STM means that writing these extensions of STM semantics safely is 100% impossible. I'm not sure which, if any, of the solutions that I'm presenting seem the most reasonable. However, without some sort of resolution for this issue, STM is far less powerful and useful than it can and should be. --Sterl.

2 1