From trac at galois.com Fri Aug 1 03:20:57 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 03:20:55 2008 Subject: [GHC] #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode In-Reply-To: <049.31db7471187fa0b39e4d12923cd80edb@localhost> References: <049.31db7471187fa0b39e4d12923cd80edb@localhost> Message-ID: <058.b9525516dd4648c1212009f681ffbe8e@localhost> #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode -------------------------------------+-------------------------------------- Reporter: jcpetruzza | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 1 07:13:16 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 07:13:13 2008 Subject: [GHC] #2477: -package-conf flag makes runghc fail Message-ID: <043.3badf8aec8b2932c76550c9b14657312@localhost> #2477: -package-conf flag makes runghc fail ------------------------+--------------------------------------------------- Reporter: fons | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- I haven't been able to test this with 6.8.3 or HEAD but it seems that runghc doesn't work properly when the -package-conf flag is provided. {{{ echo [] > foo.conf # empty package.conf file echo 'main = putStrLn "foo"' > Main.hs runghc -package-conf foo.conf Main.hs # this doesn't work runghc Main.hs # this works }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 1 07:24:30 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 07:24:26 2008 Subject: [GHC] #1312: runghc doesn't respect -main-is In-Reply-To: <047.0ad50b74545f6e5e0f2d7fb1521d3937@localhost> References: <047.0ad50b74545f6e5e0f2d7fb1521d3937@localhost> Message-ID: <056.e0cd90572101381eb9ac2d0a354be200@localhost> #1312: runghc doesn't respect -main-is ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.6.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Unknown | ----------------------+----------------------------------------------------- Comment (by fons): According the runghc's help message: {{{ runghc [-f GHC-PATH | --] [GHC-ARGS] [--] FILE ARG }}} Shouldn't {{{runghc -- -main-is foo -- bar.hs}}} suffice (without the {{{--ghc-arg}}} flag) ? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 1 08:24:09 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 08:24:04 2008 Subject: [GHC] #2478: Assertion failure in type checker Message-ID: <046.2c7a75307faaed6cba46d8a9903f5b6b@localhost> #2478: Assertion failure in type checker ----------------------------------------+----------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- Doaitse reports: It appears we ran into a bug which has been reported before. We ran into it in a desperate attempt to follow some suggestions made by referees to simplify our library for transformations of typed abstract syntax . Unfortunately the paper was rejected, but we decided to try once more. The program fragment is probably erroneous, and we know how to repair it by taking away a context constraint and putting in some kind annotations, but we thought it would be good to report it anyway. {{{ loeki:Desktop doaitse$ ghci Bug.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( Bug.hs, interpreted ) Var/Type length mismatch: [] [env2{tv aul} [tau]] Ok, modules loaded: Main. }}} Code is {{{ data Ref a env where Zero :: Ref a (a,env') Suc :: Ref a env' -> Ref a (x,env') newtype T e s = T {unT :: forall x . Ref x e -> Ref x s} class Extendable state t where extend :: t a s -> state t s env -> state t s (a,env) data Extendable st t => Trafo st t a b = Trafo ( forall env1 s. a s -> st t s env1 -> TrafoE st t a b env1 s ) data Extendable st t => TrafoE st t a b env1 s = forall env2 . TrafoE (T env2 s -> (b s, T env1 s , st t s env2)) newSRef :: (Extendable env t) => Trafo env t (t a) (Ref a) newSRef = Trafo (\ta env -> TrafoE (\(T tr) -> ( tr Zero , T (tr . Suc) , extend ta env ) ) ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 1 08:26:49 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 08:26:44 2008 Subject: [GHC] #2478: Assertion failure in type checker In-Reply-To: <046.2c7a75307faaed6cba46d8a9903f5b6b@localhost> References: <046.2c7a75307faaed6cba46d8a9903f5b6b@localhost> Message-ID: <055.28c9b262c464415c10465bba0adc8a34@localhost> #2478: Assertion failure in type checker --------------------------------------------+------------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2478 | Architecture: Unknown Os: Unknown | --------------------------------------------+------------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T2478 * owner: => igloo * type: bug => merge Comment: Fixed by {{{ Fri Aug 1 13:22:23 BST 2008 simonpj@microsoft.com * Fix Trac #2478 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 1 08:29:01 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 08:28:56 2008 Subject: [GHC] #2478: Assertion failure in type checker In-Reply-To: <046.2c7a75307faaed6cba46d8a9903f5b6b@localhost> References: <046.2c7a75307faaed6cba46d8a9903f5b6b@localhost> Message-ID: <055.9ec95460332debf23d2b9db111aa5d91@localhost> #2478: Assertion failure in type checker --------------------------------------------+------------------------------- Reporter: simonpj | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2478 | Architecture: Unknown Os: Unknown | --------------------------------------------+------------------------------- Old description: > Doaitse reports: > It appears we ran into a bug which has been reported before. We ran > into it in a desperate attempt to follow some suggestions made by > referees to simplify our library for transformations of typed abstract > syntax . Unfortunately the paper was rejected, but we decided to try > once more. The program fragment is probably erroneous, and we know how > to repair it by taking away a context constraint and putting in some > kind annotations, but we thought it would be good to report it anyway. > > {{{ > loeki:Desktop doaitse$ ghci Bug.hs > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > [1 of 1] Compiling Main ( Bug.hs, interpreted ) > Var/Type length mismatch: > [] > [env2{tv aul} [tau]] > Ok, modules loaded: Main. > }}} > Code is > {{{ > data Ref a env where > Zero :: Ref a (a,env') > Suc :: Ref a env' -> Ref a (x,env') > > newtype T e s > = T {unT :: forall x . Ref x e -> Ref x s} > > class Extendable state t where > extend :: t a s -> state t s env -> state t s (a,env) > > data Extendable st t => Trafo st t a b = > Trafo ( forall env1 s. a s -> st t s env1 -> TrafoE st t a b env1 > s ) > data Extendable st t => TrafoE st t a b env1 s = > forall env2 . TrafoE > (T env2 s -> (b s, T env1 s , st t s env2)) > > > newSRef :: (Extendable env t) => Trafo env t (t a) (Ref a) > newSRef > = Trafo > (\ta env -> > TrafoE > (\(T tr) -> > ( tr Zero > , T (tr . Suc) > , extend ta env > ) > ) > ) > }}} New description: Doaitse reports: It appears we ran into a bug which has been reported before. We ran into it in a desperate attempt to follow some suggestions made by referees to simplify our library for transformations of typed abstract syntax . Unfortunately the paper was rejected, but we decided to try once more. The program fragment is probably erroneous, and we know how to repair it by taking away a context constraint and putting in some kind annotations, but we thought it would be good to report it anyway. {{{ loeki:Desktop doaitse$ ghci Bug.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( Bug.hs, interpreted ) Var/Type length mismatch: [] [env2{tv aul} [tau]] Ok, modules loaded: Main. }}} Code is {{{ data Ref a env where Zero :: Ref a (a,env') Suc :: Ref a env' -> Ref a (x,env') newtype T e s = T {unT :: forall x . Ref x e -> Ref x s} class Extendable state t where extend :: t a s -> state t s env -> state t s (a,env) data Extendable st t => Trafo st t a b = Trafo ( forall env1 s. a s -> st t s env1 -> TrafoE st t a b env1 s ) data Extendable st t => TrafoE st t a b env1 s = forall env2 . TrafoE (T env2 s -> (b s, T env1 s , st t s env2)) newSRef :: (Extendable env t) => Trafo env t (t a) (Ref a) newSRef = Trafo (\ta env -> TrafoE (\(T tr) -> ( tr Zero , T (tr . Suc) , extend ta env ) ) ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 1 09:02:54 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 09:02:49 2008 Subject: [GHC] #2419: Extensible exceptions In-Reply-To: <044.f010ed756089aa253e6a05c76683fcdc@localhost> References: <044.f010ed756089aa253e6a05c76683fcdc@localhost> Message-ID: <053.5ff6967aadd3035ac0dac814eb21c215@localhost> #2419: Extensible exceptions ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: The concensus was that something should be done, although opinions differed on the finer points (e.g. whether to replace the old `Control.Exception` or add `Control.NewException`). I have applied more or less my original patches, although I will be further tweaking them shortly to incorporate some ideas from the thread (e.g. using `onException` rather than `catchAny`, and removing the `catchAny` function). There was also some discussion of the hierarchy, and of the difference between errors and exceptions. Designing (or evolving) a good hierarchy remains to be done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 1 09:07:35 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 09:07:31 2008 Subject: [GHC] #2475: debugger gives "Can't unify" when stopped at an exception In-Reply-To: <044.67056a89ea8901dff63b307a4127f5ba@localhost> References: <044.67056a89ea8901dff63b307a4127f5ba@localhost> Message-ID: <053.dd3f520a43560131529508aaeda56895@localhost> #2475: debugger gives "Can't unify" when stopped at an exception --------------------------------+------------------------------------------- Reporter: igloo | Owner: mnislaih Type: bug | Status: assigned Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: break011, break024 | Architecture: Unknown Os: Unknown | --------------------------------+------------------------------------------- Changes (by mnislaih): * status: new => assigned * owner: => mnislaih * cc: mnislaih@gmail.com (added) Comment: Thanks, I'll give it a look soon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 1 10:49:38 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 10:49:38 2008 Subject: [GHC] #1993: "RegAllocLinear.getStackSlotFor: out of stack slots" when compiling SHA1.hs in darcs In-Reply-To: <047.e84806530b859709e5179210f10fbc2c@localhost> References: <047.e84806530b859709e5179210f10fbc2c@localhost> Message-ID: <056.d2bd72622934b460c01127f28e24c7ba@localhost> #1993: "RegAllocLinear.getStackSlotFor: out of stack slots" when compiling SHA1.hs in darcs ----------------------------+----------------------------------------------- Reporter: apstrand | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (NCG) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Multiple | ----------------------------+----------------------------------------------- Changes (by guest): * cc: tom.davie@gmail.com (added) * os: Windows => Multiple Comment: Duplicated on Ubuntu 8.04 (32 bit intel), with ghc6.9.20080615. No -prof was used -- just bailed during compiling darcs-2.0.2. -fregs-graph produced a stack overflow message +RTS -K10M produced the error noted by alatter. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 1 10:57:09 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 10:57:05 2008 Subject: [GHC] #2477: -package-conf flag makes runghc fail In-Reply-To: <043.3badf8aec8b2932c76550c9b14657312@localhost> References: <043.3badf8aec8b2932c76550c9b14657312@localhost> Message-ID: <052.60b8cd0845cc44b6bc5e1821e0ea790d@localhost> #2477: -package-conf flag makes runghc fail ----------------------+----------------------------------------------------- Reporter: fons | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: You need to tell `runghc` that `foo.conf` is a GHC flag, and not the program to run: {{{ $ runghc -package-conf --ghc-arg=foo.conf Main.hs foo }}} This certainly works in 6.8.3 (and the HEAD), but I don't remember if this flag was in 6.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 1 10:59:13 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 10:59:10 2008 Subject: [GHC] #1312: runghc doesn't respect -main-is In-Reply-To: <047.0ad50b74545f6e5e0f2d7fb1521d3937@localhost> References: <047.0ad50b74545f6e5e0f2d7fb1521d3937@localhost> Message-ID: <056.4fd7f6b65c76989017b881b5f341362d@localhost> #1312: runghc doesn't respect -main-is ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.6.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): No: If we see `--` then that forces the current set of arguments to end, but if we decide to end the arguments when we see `foo` then we don't look ahead to see if a `--` is coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 1 11:39:03 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 11:38:57 2008 Subject: [GHC] #2479: Crash on printing a ClockTime with a negative value for number of seconds since the epoch Message-ID: <044.bff11f5ab5badcdd959ca4c031b8f51f@localhost> #2479: Crash on printing a ClockTime with a negative value for number of seconds since the epoch -----------------------+---------------------------------------------------- Reporter: wozer | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------+---------------------------------------------------- This happened on a Windows XP machine. Example program: {{{ import System.Time import Control.Exception main= do let agesAgo = TOD (-1000) 0 putStrLn "created" test <- evaluate agesAgo putStrLn "evaluated" putStrLn $ show test -- crashes putStrLn "printed" }}} Output: {{{ created evaluated Segmentation fault/access violation in generated code }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 1 11:39:49 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 11:39:47 2008 Subject: [GHC] #2465: View + Pattern Match not fused sufficiently In-Reply-To: <044.d33f6438c82e85b6cd4f00a3e01e2de0@localhost> References: <044.d33f6438c82e85b6cd4f00a3e01e2de0@localhost> Message-ID: <053.371e4a7fe07ec8e475b819dda9c641e0@localhost> #2465: View + Pattern Match not fused sufficiently ------------------------------------------+--------------------------------- Reporter: ryani | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------------------+--------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: I don't understand the example. Can you point to the exact code in the Core output that you think should be different, and what you are expecting to see instead? Note also that `dnaView` is recursive, which sharply limits how much inlining GHC can do. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 1 13:50:09 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 13:50:05 2008 Subject: [GHC] #2465: View + Pattern Match not fused sufficiently In-Reply-To: <044.d33f6438c82e85b6cd4f00a3e01e2de0@localhost> References: <044.d33f6438c82e85b6cd4f00a3e01e2de0@localhost> Message-ID: <053.54dd58b4aa3a4d9c1d6dc4f118cc3d2d@localhost> #2465: View + Pattern Match not fused sufficiently ------------------------------------------+--------------------------------- Reporter: ryani | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------------------+--------------------------------- Comment (by ryani): I intentionally put the most pie-in-the-sky example in my bug; I realize this is a hard problem. The code I actually used, which still didn't get any fusion, only examined a small finite amount of the result of dnaView, following it by a recursive call to "consts'" using (dnaDrop n dna). In the "secrets of the GHC inliner" paper, I seem to recall reading that loop unrolling is just inlining of recursive functions, so I'd hope that dnaView gets loop-unrolled 2 or 3 times which would solve that problem. That said, I do think it's possible to get from "consts + dnaView" (code which I feel is beautiful & slow) to "optConsts" (which is ugly, hand- optimized code to match what I would like the compiler to generate for this case). So, some thoughts... Is there a better way to write recursive functions that allows GHC to inline them better? I've seen several examples of this format: {{{func a b c = go a b c where go Something = base case go SomethingElse = combiner (SomeResult) (go RestOfData)}}} If that really helps, it seems like a trivial transformation to do to simple recursive functions at compile-time. I can experiment with a few different constructions of the program, but my point is that this is what most users would write as the direct specification -> implementation of this problem, the performance is pretty bad, and the "right" answer seems tantalizingly close. When the optimizer is good, it's amazingly good, but when it goes wrong it looks so much worse by comparison. There isn't much of a "graceful falloff" in performance, you either get blazing fast or bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 1 13:51:32 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 13:51:29 2008 Subject: [GHC] #2465: View + Pattern Match not fused sufficiently In-Reply-To: <044.d33f6438c82e85b6cd4f00a3e01e2de0@localhost> References: <044.d33f6438c82e85b6cd4f00a3e01e2de0@localhost> Message-ID: <053.ee2caa3bbf1ad83a53f2e659b782e253@localhost> #2465: View + Pattern Match not fused sufficiently ------------------------------------------+--------------------------------- Reporter: ryani | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------------------+--------------------------------- Comment (by ryani): Ugh, sorry about the formatting; forgot to click "preview". {{{ func a b c = go a b c where go Something = base case go SomethingElse = combiner SomeResult (go RestOfData) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 1 14:02:58 2008 From: trac at galois.com (GHC) Date: Fri Aug 1 14:03:00 2008 Subject: [GHC] #2465: View + Pattern Match not fused sufficiently In-Reply-To: <044.d33f6438c82e85b6cd4f00a3e01e2de0@localhost> References: <044.d33f6438c82e85b6cd4f00a3e01e2de0@localhost> Message-ID: <053.3bef5f5330d16950c3f4c57f603e4329@localhost> #2465: View + Pattern Match not fused sufficiently ------------------------------------------+--------------------------------- Reporter: ryani | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------------------+--------------------------------- Comment (by ryani): Also, to answer your question directly... what in the core should be different? The list thunk allocations in [http://hackage.haskell.org/trac/ghc/attachment/ticket/2465/plzoptimize.core#L490 $sdnaView (line 490)] and [http://hackage.haskell.org/trac/ghc/attachment/ticket/2465/plzoptimize.core#L521 dnaView (line 521)] immediately get destructed by [http://hackage.haskell.org/trac/ghc/attachment/ticket/2465/plzoptimize.core#L386 $wconsts (line 386)], causing a lot of allocator churn. If those two functions are fused, as they are in optConsts, the code runs ~5-10x faster (from my recollection). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 2 04:54:21 2008 From: trac at galois.com (GHC) Date: Sat Aug 2 04:54:16 2008 Subject: [GHC] #1123: Impredicativity bug: forall not hoisted properly In-Reply-To: <075.8f9fdc9da9c29da565119ca8bb13ea93@localhost> References: <075.8f9fdc9da9c29da565119ca8bb13ea93@localhost> Message-ID: <084.a0c8663914f6e142c1543d408f5cb077@localhost> #1123: Impredicativity bug: forall not hoisted properly --------------------------------------------------+------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------------------+------------------------- Changes (by guest): * cc: emertens@gmail.com (added) Comment: I believe I've run into this same bug with a simpler test case. runA2 is the one that I've prefer to be able to write but am unable to. {{{ data A s = A { unA :: () } runA1 :: (forall s. A s) -> () runA1 a = unA a -- doesn't work :( runA2 :: (forall s. A s) -> () runA2 (A a) = a runA3 :: (forall s. A s) -> () runA3 a = case a of A x -> x runA4 :: (forall s. A s) -> () runA4 a = let A x = a in x runA5 :: (forall s. A s) -> () runA5 a = go a where go (A a) = a }}} The following error is generated by GHC 6.8.3 {{{ Couldn't match expected type `forall s. A s' against inferred type `A s' In the pattern: A a In the definition of `runA2': runA2 (A a) = a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 2 06:49:45 2008 From: trac at galois.com (GHC) Date: Sat Aug 2 06:49:39 2008 Subject: [GHC] #2479: Crash on printing a ClockTime with a negative value for number of seconds since the epoch In-Reply-To: <044.bff11f5ab5badcdd959ca4c031b8f51f@localhost> References: <044.bff11f5ab5badcdd959ca4c031b8f51f@localhost> Message-ID: <053.918db586a5efab93afa30e5a7a6ad228@localhost> #2479: Crash on printing a ClockTime with a negative value for number of seconds since the epoch -------------------------+-------------------------------------------------- Reporter: wozer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Windows -------------------------+-------------------------------------------------- Comment (by wagstaff): Duplicate 2425? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 2 07:57:21 2008 From: trac at galois.com (GHC) Date: Sat Aug 2 07:57:23 2008 Subject: [GHC] #2425: Crash constructing a ClockTime too far into the future In-Reply-To: <047.a9abcd98ff397aed55603869406274e9@localhost> References: <047.a9abcd98ff397aed55603869406274e9@localhost> Message-ID: <056.d6773c6697aa22719c91a0d00e501e3f@localhost> #2425: Crash constructing a ClockTime too far into the future ----------------------------------+----------------------------------------- Reporter: wagstaff | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries (old-time) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------------+----------------------------------------- Comment (by igloo): See also #2479 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 2 07:58:30 2008 From: trac at galois.com (GHC) Date: Sat Aug 2 07:58:54 2008 Subject: [GHC] #2479: Crash on printing a ClockTime with a negative value for number of seconds since the epoch In-Reply-To: <044.bff11f5ab5badcdd959ca4c031b8f51f@localhost> References: <044.bff11f5ab5badcdd959ca4c031b8f51f@localhost> Message-ID: <053.e1805891f127c28a48704f314c3cfb21@localhost> #2479: Crash on printing a ClockTime with a negative value for number of seconds since the epoch ----------------------+----------------------------------------------------- Reporter: wozer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Yup, looks like a duplicate of #2425; thanks wagstaff. To echo that ticket: `System.Time` is indeed deprecated, you should use the new `time` package preferably. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 2 08:56:57 2008 From: trac at galois.com (GHC) Date: Sat Aug 2 08:56:50 2008 Subject: [GHC] #2480: error function is not lazy Message-ID: <051.ecb98bd3181d9ab4e7aa4d8a7990d204@localhost> #2480: error function is not lazy -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Windows -----------------------------+---------------------------------------------- {{{ C:\Neil\Temp>type Test.hs main = error $ cycle "Hello\n" C:\Neil\Temp>ghc --make Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test.exe ... C:\Neil\Temp>test -- hangs forever }}} The error message seems to get buffered, which means long/infinite messages are never displayed. GHCi does evaluate error lazily. The error function is particularly useful for debugging, which is where I encountered this problem. It appears trace has a similar issue of buffering in GHC compiled programs, but I am not certain. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 2 20:28:00 2008 From: trac at galois.com (GHC) Date: Sat Aug 2 20:27:52 2008 Subject: [GHC] #2442: Heuristics to improve error messages for badly referenced things In-Reply-To: <053.d96b74737451be892238b37815ca44b6@localhost> References: <053.d96b74737451be892238b37815ca44b6@localhost> Message-ID: <062.7116b3ab91ac76c5414c2fcedf72365d@localhost> #2442: Heuristics to improve error messages for badly referenced things ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by guest): I've solved the performance problem purely by making use of an edit- distance algorithm based on bit-vectors. This is /very fast/. For future reference, I've actually released it's implementation (plus some other edit distances, QuickCheck tests for it all etc) on Hackage (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/edit- distance). My stress test was compiling GHC.hs with the Module import commented out. This generates a number of unbound name errors, each of which has to do a full scan of the (huge) imported name set. This takes 1 second on my modified GHC compared with 0.3 seconds on an unmodified one. If this is not an acceptable speed I can pursue the other performance-improving possibilities above. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 3 01:03:48 2008 From: trac at galois.com (GHC) Date: Sun Aug 3 01:03:39 2008 Subject: [GHC] #2480: error function is not lazy In-Reply-To: <051.ecb98bd3181d9ab4e7aa4d8a7990d204@localhost> References: <051.ecb98bd3181d9ab4e7aa4d8a7990d204@localhost> Message-ID: <060.2d4947e06e7a57e5d241f5f5bb3ed12f@localhost> #2480: error function is not lazy -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Windows -----------------------------+---------------------------------------------- Comment (by ajd): Trace does indeed have a similar issue, I reported this at [http://www.haskell.org/pipermail/libraries/2008-July/010199.html]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 3 07:28:55 2008 From: trac at galois.com (GHC) Date: Sun Aug 3 07:28:55 2008 Subject: [GHC] #2481: ghci: :f fmap -> can't unify Message-ID: <044.bb22267ef7664b8c3af7a80d0a7ef05d@localhost> #2481: ghci: :f fmap -> can't unify -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Typing ':f fmap' at the GHCi prompt gives a panic (Can't unify). See below: {{{ $ ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :f fmap ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for x86_64-unknown-linux): Can't unify Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude> }}} This is with the ghc package distributed with Debian testing/lenny (version 6.8.2-5). Vincent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 3 13:35:03 2008 From: trac at galois.com (GHC) Date: Sun Aug 3 13:34:51 2008 Subject: [GHC] #2316: Add Applicative instances for all MTL Monads In-Reply-To: <047.6c77bc0cfe5b195806e995b0a81d8474@localhost> References: <047.6c77bc0cfe5b195806e995b0a81d8474@localhost> Message-ID: <056.2356ba200218f9d6c4cde149a72669bf@localhost> #2316: Add Applicative instances for all MTL Monads -------------------------------+-------------------------------------------- Reporter: sjanssen | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by guest): * cc: haskell@henning-thielemann.de (added) Comment: If base-2 is not available you can import: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/special- functors -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 3 16:00:42 2008 From: trac at galois.com (GHC) Date: Sun Aug 3 16:00:30 2008 Subject: [GHC] #2482: Documentation of STUArray: type argument name mismatch Message-ID: <044.473dec5fe610a9994dfae768714f70b4@localhost> #2482: Documentation of STUArray: type argument name mismatch ------------------------+--------------------------------------------------- Reporter: wozer | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.8.3 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- See: http://haskell.org/ghc/docs/latest/html/libraries/array/Data-Array- ST.html#t%3ASTArray STUArray is introduced as: {{{ data STUArray s i a }}} but then "a" is referred to as "e". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 3 20:24:57 2008 From: trac at galois.com (GHC) Date: Sun Aug 3 20:24:44 2008 Subject: [GHC] #2483: mapException type under extensible exceptions Message-ID: <051.38739bb0dd93087fbe6409fe08ce9466@localhost> #2483: mapException type under extensible exceptions -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- The old type is {{{mapException :: (Exception -> Exception) -> a -> a}}} e.g. you might map have mapped a !DivZeroError to a dynamic exception of some sort (gee, I don't know). Of course the "dynamic exception" will be less of a hack when the code is converted to extensible exceptions. In any case that doesn't work with the 6.9-current signature {{{mapException :: (Exception e) => (e -> e) -> a -> a}}} because !DivZeroErrors are not necessarily the same type as the exceptions you're throwing, obviously! The old signature is closer in meaning to {{{mapException :: (SomeException -> SomeException) -> a -> a}}} which is isomorphic to {{{mapException :: (Exception e1, Exception e2) => (e1 -> e2) -> a -> a}}} which I think is the inferred type, and ought to be the explicit type too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 3 20:34:05 2008 From: trac at galois.com (GHC) Date: Sun Aug 3 20:33:53 2008 Subject: [GHC] #2483: mapException type under extensible exceptions In-Reply-To: <051.38739bb0dd93087fbe6409fe08ce9466@localhost> References: <051.38739bb0dd93087fbe6409fe08ce9466@localhost> Message-ID: <060.f7910b120f8fb03aba26147c6d7d890a@localhost> #2483: mapException type under extensible exceptions ----------------------------+----------------------------------------------- Reporter: Isaac Dupree | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown Comment: Makes sense, and I think we discussed it in the proposal thread; I'll make the change. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 4 08:38:43 2008 From: trac at galois.com (GHC) Date: Mon Aug 4 08:38:31 2008 Subject: [GHC] #1123: Impredicativity bug: forall not hoisted properly In-Reply-To: <075.8f9fdc9da9c29da565119ca8bb13ea93@localhost> References: <075.8f9fdc9da9c29da565119ca8bb13ea93@localhost> Message-ID: <084.568ff36a4cbff9056d7ba2a799ee98dd@localhost> #1123: Impredicativity bug: forall not hoisted properly --------------------------------------------------+------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------------------+------------------------- Comment (by simonpj): No, this is a different problem. The type sig for `runA2` says that the argument must be polymorphic, but then you are matching against a monomorphic pattern. This is sound -- the type signature is more restrictive than the pattern -- but GHC doesn't currently support it, because I've not found any convincing uses. What's wrong with {{{ runA2 :: forall s A s -> () }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 4 12:11:22 2008 From: trac at galois.com (GHC) Date: Mon Aug 4 12:11:07 2008 Subject: [GHC] #2478: Assertion failure in type checker In-Reply-To: <046.2c7a75307faaed6cba46d8a9903f5b6b@localhost> References: <046.2c7a75307faaed6cba46d8a9903f5b6b@localhost> Message-ID: <055.e56da460508fdfc0fef91312df368b60@localhost> #2478: Assertion failure in type checker --------------------------------------------+------------------------------- Reporter: simonpj | Owner: Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2478 | Architecture: Unknown Os: Unknown | --------------------------------------------+------------------------------- Changes (by igloo): * owner: igloo => * milestone: => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 4 12:33:24 2008 From: trac at galois.com (GHC) Date: Mon Aug 4 12:33:08 2008 Subject: [GHC] #1930: infix type constructors are printed incorrectly by GHC In-Reply-To: <044.4cf3e6fbd26fe995daaaaeb63fab91ac@localhost> References: <044.4cf3e6fbd26fe995daaaaeb63fab91ac@localhost> Message-ID: <053.fdbe1926ee411b3293babe815c3ff3b5@localhost> #1930: infix type constructors are printed incorrectly by GHC ----------------------------------+----------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ghci/scripts/ghci033 | Architecture: Unknown Os: Unknown | ----------------------------------+----------------------------------------- Changes (by simonpj): * testcase: => ghci/scripts/ghci033 Comment: I have fixed the bug in the commend from Frisby: {{{ Mon Aug 4 17:10:39 BST 2008 simonpj@microsoft.com * Fix the bug part of Trac #1930 }}} However, the original report is a different point. In Haskell `(+)` is a type variable not a type constructor. So saying {{{ undefined :: a+b }}} means {{{ undefined :: forall (+), a, b. (+) a b }}} Now, you could argue that the type variable `(+)` should be printed infix. But I'm planning to make `(+)` into a type '''constructor''', as described here http://hackage.haskell.org/trac/haskell- prime/wiki/InfixTypeConstructors. So I am disinclined to fix the original report in #1930. Still I'll leave it open to remind me to do the infix-type-constructor thing. Yell if you think that the infix type constructor proposal is a Bad Idea. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 4 12:35:17 2008 From: trac at galois.com (GHC) Date: Mon Aug 4 12:35:02 2008 Subject: [GHC] #2467: orphan instance warnings are badly behaved In-Reply-To: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> References: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> Message-ID: <054.656e458b28b5c32f9ed01efb9f52e09d@localhost> #2467: orphan instance warnings are badly behaved ----------------------+----------------------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => igloo * difficulty: => Unknown Comment: Good suggestion. I've fixed this {{{ Mon Aug 4 17:21:29 BST 2008 simonpj@microsoft.com * Fix Trac #2467: decent warnings for orphan instances }}} You must pull the `array` and `mtl` libraries too, because they have orphan modules that die with `-Werror` unless you do. ToDo: Ian: look into de-orphanising those modules. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 4 12:38:38 2008 From: trac at galois.com (GHC) Date: Mon Aug 4 12:38:22 2008 Subject: [GHC] #2433: standalone deriving Typeable shouldn't need data constructors in scope? In-Reply-To: <044.c3db89885eba9cc62656744d598e567c@localhost> References: <044.c3db89885eba9cc62656744d598e567c@localhost> Message-ID: <053.6b50a764c71cf6f017d3a9dab18dd4c2@localhost> #2433: standalone deriving Typeable shouldn't need data constructors in scope? --------------------------------------------+------------------------------- Reporter: claus | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2433 | Architecture: Unknown Os: Unknown | --------------------------------------------+------------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T2433 * owner: => igloo * type: bug => merge Comment: Good point. Fixed by {{{ Mon Aug 4 15:15:03 BST 2008 simonpj@microsoft.com * Fix Trac #2433 (deriving Typeable) }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 4 13:03:31 2008 From: trac at galois.com (GHC) Date: Mon Aug 4 13:03:21 2008 Subject: [GHC] #2465: View + Pattern Match not fused sufficiently In-Reply-To: <044.d33f6438c82e85b6cd4f00a3e01e2de0@localhost> References: <044.d33f6438c82e85b6cd4f00a3e01e2de0@localhost> Message-ID: <053.cf0f8c188e98706639631b739c1ac7ca@localhost> #2465: View + Pattern Match not fused sufficiently ------------------------------------------+--------------------------------- Reporter: ryani | Owner: Type: compile-time performance bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------------------+--------------------------------- Changes (by simonpj): * priority: normal => low * milestone: => _|_ Comment: Fusion of recursive functions is a very interesting and well-studied area. GHC offers so-called "short-cut deforestation" for lists. (Search for that string.) If you write `dnaView` using `build` (to make it a good producer), and `consts'` using `foldr` (to make it a good consumer) you may get better results. Also worth a look is Coutts/Leschinskiy et al on stream fusion. But GHC isn't going to fuse recursive functions all by itself anytime soon. So I'll refile this as low priority. Don't let this discourage you from suggesting other optimisation "misses" though. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 4 15:05:01 2008 From: trac at galois.com (GHC) Date: Mon Aug 4 15:04:49 2008 Subject: [GHC] #2484: ghc 6.8.2 broken after Security Update 2008-005 (PPC) on Mac OS 10.4.11 Message-ID: <044.a2618a27f261a948044540a6bc0d6d47@localhost> #2484: ghc 6.8.2 broken after Security Update 2008-005 (PPC) on Mac OS 10.4.11 ------------------------+--------------------------------------------------- Reporter: knarF | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: powerpc | Os: MacOS X ------------------------+--------------------------------------------------- This weekend I installed Apple's Security Update 2008-005 (PPC). This morning I discovered that ghc, ghci and runhaskell are not working. (I am certain that ghc and runhaskell were working in the last two weeks.) For instance, when compiling the simple file randil.hs (attached) I see: {{{ ghc-6.8.2: internal error: stg_ap_pv_ret (GHC version 6.8.2 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap }}} Running that via ./randil.hs yields {{{ runhaskell: waitForProcess: interrupted (Interrupted system call) }}} and a crash log (attached). On the other hand, a simple hello world program (attached) does compile and execute as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 4 17:04:26 2008 From: trac at galois.com (GHC) Date: Mon Aug 4 17:04:21 2008 Subject: [GHC] #2485: Installed ghci wrapper refers to nonexistent file Message-ID: <044.2c0bcbfdb00152697f27863db8618203@localhost> #2485: Installed ghci wrapper refers to nonexistent file -----------------------+---------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- After running `make install` on HEAD, I cannot run the wrapper script for `ghci`. The other wrappers (`ghc`, `runghc`, etc.) seem to work fine. (For reference, I configured using `--prefix=$HOME/tmp/ghc-stage`) {{{ $ ~/tmp/ghc-stage/bin/ghc ghc: no input files Usage: For basic information, try the `--help' option. $ ~/tmp/ghc-stage/bin/ghci /Users/judah/tmp/ghc-stage/bin/ghci: line 4: /Users/judah/tmp/ghc- stage/lib/ghc-6.9.20080730/ghc-6.9.20080730: No such file or directory /Users/judah/tmp/ghc-stage/bin/ghci: line 4: exec: /Users/judah/tmp/ghc- stage/lib/ghc-6.9.20080730/ghc-6.9.20080730: cannot execute: No such file or directory $ ls -d ~/tmp/ghc-stage/lib/ghc-6.9.20080730/ghc* /Users/judah/tmp/ghc-stage/lib/ghc-6.9.20080730/ghc /Users/judah/tmp/ghc-stage/lib/ghc-6.9.20080730/ghc-asm /Users/judah/tmp/ghc-stage/lib/ghc-6.9.20080730/ghc-pkg /Users/judah/tmp/ghc-stage/lib/ghc-6.9.20080730/ghc-prim-0.1 /Users/judah/tmp/ghc-stage/lib/ghc-6.9.20080730/ghc-split }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 4 18:07:34 2008 From: trac at galois.com (GHC) Date: Mon Aug 4 18:07:20 2008 Subject: [GHC] #1123: Impredicativity bug: forall not hoisted properly In-Reply-To: <075.8f9fdc9da9c29da565119ca8bb13ea93@localhost> References: <075.8f9fdc9da9c29da565119ca8bb13ea93@localhost> Message-ID: <084.0aa038e44f69bc92b346f37510f5e5e8@localhost> #1123: Impredicativity bug: forall not hoisted properly --------------------------------------------------+------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------------------+------------------------- Comment (by guest): the runA2 case was a simplification of the following code: {{{ newtype M s a = M (StateT (UnionFind (RevertArray s) (STRef s) (ST s)) (ChoiceT (ST s)) a) deriving (Monad, MonadPlus) runM :: Int -> (forall s. M s b) -> [b] runM n (M m) = runST (do uf <- newUnionFind n findAll $ fmap fst $ runStateT uf m) -- The following declarations are included to explain the types of the functions in scope newUnionFind :: PersistentArray a => Int -> ST s (UnionFind a s) newUnionFind = undefined findAll :: Monad m => ChoiceT m a -> m [a] findAll = undefined runStateT :: i -> StateT i m a -> m (a, i) runStateT = undefined }}} My solution was to write an un-newtyping function ( M s a -> StateT (UnionFind (RevertArray s) (STRef s) (ST s)) (ChoiceT (ST s)) a ) and call that inside the "runST" but it wasn't clear why I would be required to do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 4 22:43:24 2008 From: trac at galois.com (GHC) Date: Mon Aug 4 22:43:09 2008 Subject: [GHC] #2486: Code specialization regression in 6.8.3 Message-ID: <044.2aa9bce2a7a3fda66c24d4bd23fa1ccd@localhost> #2486: Code specialization regression in 6.8.3 -----------------------------------------+---------------------------------- Reporter: dolio | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -----------------------------------------+---------------------------------- Greetings. I'd recently heard rumblings about the "recursive" benchmark on the shootout not being great for functional languages, so I thought I'd look at the Haskell version to see if it could be improved at all. Much to my surprise, it ran very slowly on 6.8.3 (much slower than on the shootout site, which uses 6.8.2). I'll attach the benchmark to this report, as it's a relatively short test case. It turns out, the latest GHC is no longer specializing fib and tak to their Int and Double versions respectively. They are both left fully polymorphic, complete with dictionary passing and destruction in every iteration. This causes a factor of 5-7 slowdown. Here are examples of the differing core for the two versions. First, 6.8.2: http://www.cs.bris.ac.uk/home/rb6822/Recursive682-core.html Next 6.8.3: http://www.cs.bris.ac.uk/home/rb6822/Recursive683-core.html Which displays quite a difference (The 6.8.3 core almost looks loop unrolled or some such, leading to giant code). Adding SPECIALIZE pragmas when compiling with 6.8.3 brings back the 6.8.2 performance (and core), but I think the 6.8.2 behavior is probably more desirable in this case, if it's possible to get it back. Cheers. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 5 04:35:33 2008 From: trac at galois.com (GHC) Date: Tue Aug 5 04:35:17 2008 Subject: [GHC] #1123: Impredicativity bug: forall not hoisted properly In-Reply-To: <075.8f9fdc9da9c29da565119ca8bb13ea93@localhost> References: <075.8f9fdc9da9c29da565119ca8bb13ea93@localhost> Message-ID: <084.fd0c6d0c0bf51281f001da4062979cb3@localhost> #1123: Impredicativity bug: forall not hoisted properly --------------------------------------------------+------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------------------+------------------------- Comment (by simonpj): You are definitely required to do so! Consider this simpler version: {{{ data M s a = M (ST s a) runM :: forall b. Int -> (forall s. M s b) -> b runM n (M m) = runST m }}} What type does `m` have in the RHS of `runM`? You want it to have type `forall s. ST s b`. So you want the pattern matching on `(M m)` to first specialise the argument and then re-generalise. I can see why you might think that'd work, but try writing it in System F: {{{ runM = /\b. \n:Int. \x:(forall x. M s b). case (x ???) of M m -> runST (/\s. ???) }}} The only way to make this work is to move the pattern match inside the big lambda thus: {{{ runM = /\b. \n:Int. \x:(forall x. M s b). runST (/\s. case (x s) of M m -> m) }}} And that is just what your un-newtyping function does. I'm leaving the bug open for its original report though. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 5 06:31:51 2008 From: trac at galois.com (GHC) Date: Tue Aug 5 06:31:37 2008 Subject: [GHC] #2487: ghci baulks when trying the Glade tutorial Message-ID: <044.8297c42c48047f0618ee54f4905346bf@localhost> #2487: ghci baulks when trying the Glade tutorial ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- I'm just reporting what ghci asked me to do. [[BR]] I was running through the Glade tutorial, http://www.haskell.org/gtk2hs/docs/tutorial/glade/ [[BR]] All well, except the tutorial says it can be tried out in ghci. This is the report I got: [[BR]] C:\Documents and Settings\BT\Desktop\Gtk2Hs Folder>ghci [[BR]] GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help [[BR]] Loading package base ... linking ... done. [[BR]] Prelude> :load hellogtk2hs [[BR]] Ok, modules loaded: Main. [[BR]] Prelude Main> main [[BR]] Loading package array-0.1.0.0 ... linking ... done. [[BR]] Loading package bytestring-0.9.0.1.1 ... linking ... done. [[BR]] Loading package mtl-1.1.0.1 ... linking ... done. [[BR]] Loading package glib-0.9.13 ... : Unknown PEi386 section name `.rel [[BR]] oc' (while processing: C:/Gtk2Hs/HSglib.o) [[BR]] : panic! (the 'impossible' happened)[[BR]] (GHC version 6.8.3 for i386-unknown-mingw32): [[BR]] loadObj: failed [[BR]] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [[BR]] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 5 06:50:13 2008 From: trac at galois.com (GHC) Date: Tue Aug 5 06:50:02 2008 Subject: [GHC] #2488: ByteString hGet documentation is incomplete Message-ID: <042.180b053b7dabbf116ac00f7d05a45f02@localhost> #2488: ByteString hGet documentation is incomplete -------------------------+-------------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- All four versions of hGet for the various Data.!ByteString implementations claim that it "[reads] n bytes into a !ByteString." This is not always the case. For example, it appears that on EOF less than n bytes are read. The conditions under which it will not succeed in reading n bytes into a !ByteString (be it less than n, or it raising some sort of error) should be documented. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 5 07:19:28 2008 From: trac at galois.com (GHC) Date: Tue Aug 5 07:19:13 2008 Subject: [GHC] #2449: panic with GeneralizedNewtypeDeriving and a .hs-boot file In-Reply-To: <044.e61299c07a3173d5bd1857190eae6cdf@localhost> References: <044.e61299c07a3173d5bd1857190eae6cdf@localhost> Message-ID: <053.3c85f97cda7d1c359f0013a29f12c62a@localhost> #2449: panic with GeneralizedNewtypeDeriving and a .hs-boot file ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => igloo Comment: Good bug. As the user manual says, you can't put deriving clauses in hs- boot files. I've made GHC check properly for this now. {{{ Tue Aug 5 11:54:02 BST 2008 simonpj@microsoft.com * Fix Trac #2449 Deriving isn't allowed in hs-boot files (says the user manual) This patch checks properly instead of crashing! }}} IAN: I'm not sure how to add a test case whose source file is a `hs-boot` file. Could you do so please? The one above will do fine. Thanks. Then close. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 5 08:00:54 2008 From: trac at galois.com (GHC) Date: Tue Aug 5 08:00:38 2008 Subject: [GHC] #2220: Subprocesses do not close open FDs In-Reply-To: <045.c8c0847f8d8ff9265acf5e0d94c0a49c@localhost> References: <045.c8c0847f8d8ff9265acf5e0d94c0a49c@localhost> Message-ID: <054.a5014aad05dc7b99c4dde7bbba63268f@localhost> #2220: Subprocesses do not close open FDs -------------------------------+-------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/process | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Comment (by duncan): Replying to [comment:1 Baughn]: > If setting FD_CLOEXEC (close on exec) is picked, then.. since it has to be set in a separate call after opening the FD, there is a potential race condition if any other thread calls exec. Note that on Linux, as of version 2.6.27, this can be done without any race condition. See http://udrepper.livejournal.com/20407.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 5 08:11:46 2008 From: trac at galois.com (GHC) Date: Tue Aug 5 08:11:28 2008 Subject: [GHC] #2470: read for StdGen fails for arbitrary string In-Reply-To: <044.1c7efcca6223ef9fb0b4c86a69ee284e@localhost> References: <044.1c7efcca6223ef9fb0b4c86a69ee284e@localhost> Message-ID: <053.26bdc25d85571f5123bafb42aaeb872d@localhost> #2470: read for StdGen fails for arbitrary string ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/random | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: StdGen read | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------+--------------------------------------------- Comment (by ross): Replying to [comment:2 igloo]: > Strings that are the result of showing a StdGen work fine as part of structures [...] > > For reading a random string you can use `reads` to avoid the exception. The description quoted in the bug report, including "It guarantees to succeed on any string" is in the Haskell 98 Report. Not implementing that would be a bug, wouldn't it? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 5 09:18:35 2008 From: trac at galois.com (GHC) Date: Tue Aug 5 09:18:22 2008 Subject: [GHC] #2470: read for StdGen fails for arbitrary string In-Reply-To: <044.1c7efcca6223ef9fb0b4c86a69ee284e@localhost> References: <044.1c7efcca6223ef9fb0b4c86a69ee284e@localhost> Message-ID: <053.5e0b2c977791a8ff9f8238bdcf780f9f@localhost> #2470: read for StdGen fails for arbitrary string ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/random | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: StdGen read | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------------+--------------------------------------------- Comment (by Isaac Dupree): The Haskell 98 report is buggy; that behavior is unimplementable when applying (`read::String->StdGen`) to an infinite list. Actually, no, that's not quite right. (`readsPrec::Int->ReadS StdGen`) == (`readsPrec::Int->String->[(StdGen,String)]`). So readsPrec could be defined to read only a finite amount of the string, and unconditionally return `[(result,"")]` so that "read" always succeeded. But that breaks the read/show identities (e.g. `(read.show)::[StdGen]->[StdGen]` would break), and in general breaks the expected behavior for the `reads` functions, so I don't think it's worth it to pretend the standard isn't broken there. -Isaac -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 5 10:59:38 2008 From: trac at galois.com (GHC) Date: Tue Aug 5 10:59:20 2008 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM Message-ID: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM ------------------------+--------------------------------------------------- Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Component: None Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- This bug is related to #1515. The installer shouldn't create any keys under HKCU, and should use system-wide HKLM instead. Now, the registry key is accessible only to the user who installed the GHC. Other users don't have the installation path in the registry, and this breaks all tools which rely on getting the installation path from the registry. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 5 11:54:59 2008 From: trac at galois.com (GHC) Date: Tue Aug 5 11:54:58 2008 Subject: [GHC] #2231: ASSERT failed! file typecheck/TcMType.lhs line 442 t_a7Fa{tv} [tau] In-Reply-To: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> References: <044.d4bb1e8e3d1948707d5b62e9fdca3bb9@localhost> Message-ID: <053.a5f1f192ac607ea87ff4ef020c57a779@localhost> #2231: ASSERT failed! file typecheck/TcMType.lhs line 442 t_a7Fa{tv} [tau] -------------------------------------+-------------------------------------- Reporter: guest | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: I think this is a duplicate of #2212. I'm going to close this one, and point to it from #2212 for testing. (The line number difference in the ASSERT failure is just 6.8 vs 6.9. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 5 11:55:54 2008 From: trac at galois.com (GHC) Date: Tue Aug 5 11:55:42 2008 Subject: [GHC] #2212: Double assignment to coercion variable In-Reply-To: <046.ad4e8af6cf182013c618bfd8fa17eb5c@localhost> References: <046.ad4e8af6cf182013c618bfd8fa17eb5c@localhost> Message-ID: <055.ab8b29a7e1438b1fc8a06a373bfdc720@localhost> #2212: Double assignment to coercion variable ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: equal | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): See also #2231 which I believe is a duplicate. Make sure to check #2231 works when closing this bug. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 5 17:07:36 2008 From: trac at galois.com (GHC) Date: Tue Aug 5 17:07:18 2008 Subject: [GHC] #2490: GHC allows sections with out parenthesis in tuples Message-ID: <049.41558d2f5e8f1685b5dfab51d362bd22@localhost> #2490: GHC allows sections with out parenthesis in tuples ---------------------------+------------------------------------------------ Reporter: JeremyShaw | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ---------------------------+------------------------------------------------ GHC gladly accepts: > f x = (`head` x, ()) but the Haskell 98 Report (section 3.5) seems to indicate that additional parens are required, like this: > f x = ((`head` x), ()) It's unclear if this is a bug in GHC, an undocumented feature, or valid H98 if you read the report in just the right way. Hugs and lambdabot don't like it. More importantly, the trhsx preprocessor used by HSX/HSP does not like it. So, we are wondering if we should extend trhsx to allow it, and if so, what the rules are. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 5 19:20:35 2008 From: trac at galois.com (GHC) Date: Tue Aug 5 19:20:22 2008 Subject: [GHC] #2491: ghc-pkg unregister should complain about breaking dependent packages Message-ID: <045.cb2eb75581a4ebbb8a9616da61bf4689@localhost> #2491: ghc-pkg unregister should complain about breaking dependent packages --------------------------------+------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Currently it is easy to silently break installed packages. This is particularly bad when users unregister things like 'old' versions of Cabal or bytestring (usually after having installed a new version) because this breaks packages like the ghc api package which cannot be re-installed. So ghc-pkg unregister should report an error if there are packages that depend on the package being unregistered (at least within the same package db). The error message should report which packages still need the package that the user was trying to unregister and should mention that if they're really really sure that they want to break other said packages that they can run the command again with `--force`. With `--force` inplace it should probably still print the warning (for the benefit of log files in packaging systems that may need to use `--force` if they do not guarantee an order of unregistering). Example user interaction: {{{ $ ghc-pkg unregister bytestring-0.9.0.1 ghc-pkg: bytestring-0.9.0.1 should not be unregistered because the following registered packages depend on it: ghc-6.8.2. Use --force to unregister anyway and break these packages. You can use ghc-pkg check at any time to see what packages in the broken state due to missing dependencies. $ ghc-pkg unregister bytestring-0.9.0.1 --force ghc-pkg: Warning: due to the forced unregistering of the package bytestring-0.9.0.1, the following packages are now in the broken state: ghc-6.8.2 }}} Incidentally, we should also install a package.conf.shipped to help people recover their ghc installations after they've unwisely and over-zealously gone round unregistering 'old' packages. Debian and Gentoo already do this and it's saved many users. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 6 04:27:12 2008 From: trac at galois.com (GHC) Date: Wed Aug 6 04:26:58 2008 Subject: [GHC] #2277: GHCi silently aborts on 'take' computation In-Reply-To: <046.02df5e44a831fb20777998dee9adae29@localhost> References: <046.02df5e44a831fb20777998dee9adae29@localhost> Message-ID: <055.6e421c66e6bbdd9f1eaa56bf92a7124c@localhost> #2277: GHCi silently aborts on 'take' computation ---------------------+------------------------------------------------------ Reporter: cdsmith | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: GHCi | Version: 6.9 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------+------------------------------------------------------ Comment (by simonmar): A fix has been checked in upstream, although I've not had a chance to test it yet. [http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/tty.c.diff?r1=1.25&r2=1.26] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 6 08:22:00 2008 From: trac at galois.com (GHC) Date: Wed Aug 6 08:21:49 2008 Subject: [GHC] #2480: error function is not lazy In-Reply-To: <051.ecb98bd3181d9ab4e7aa4d8a7990d204@localhost> References: <051.ecb98bd3181d9ab4e7aa4d8a7990d204@localhost> Message-ID: <060.4246127f2dc173250754f980f2ad6d25@localhost> #2480: error function is not lazy --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: cg016 | Architecture: Unknown Os: Windows | --------------------------+------------------------------------------------- Changes (by simonmar): * testcase: => cg016 * difficulty: => Unknown Comment: Trace is supposed to work like this, the idea is that trace messages don't get interleaved with each other. For error, the exception is passed to the RTS for printing, because in a Windows non-console program the error will pop up in a message box. Passing the message to the RTS of course involves serialising it. I suppose we could detect whether the program was running on the console and use lazy output, but the program will still hang in a non-console environment. Incedentally, test cg016 tests something very similar (nested errors). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 6 08:28:53 2008 From: trac at galois.com (GHC) Date: Wed Aug 6 08:28:35 2008 Subject: [GHC] #2487: ghci baulks when trying the Glade tutorial In-Reply-To: <044.8297c42c48047f0618ee54f4905346bf@localhost> References: <044.8297c42c48047f0618ee54f4905346bf@localhost> Message-ID: <053.e0c717ab652fa1e935d628d4df7f6cdf@localhost> #2487: ghci baulks when trying the Glade tutorial ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: dup of #2485, thanks for reporting anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 6 08:57:27 2008 From: trac at galois.com (GHC) Date: Wed Aug 6 08:57:06 2008 Subject: [GHC] #2439: Missed optimisation with dictionaries and loops In-Reply-To: <041.4a9e022e22f0d06a0023c060ae99c7bb@localhost> References: <041.4a9e022e22f0d06a0023c060ae99c7bb@localhost> Message-ID: <050.dcd35e2a599d503de693dbf8f13435c2@localhost> #2439: Missed optimisation with dictionaries and loops --------------------------------------+------------------------------------- Reporter: rl | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Interesting example. I've thought about it a bit, and I don't see an obvious, general transformation that would help. The loop ''is not'' strict in the dictionary; it's just this particular call that is. A long-standing thing I've wanted to try is to make ''all'' dictionary arguments strict, and see where that takes us. After all, evaluating a dictionary should always terminate. I'll leave this ticket open to help me remember to try that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 6 12:01:20 2008 From: trac at galois.com (GHC) Date: Wed Aug 6 12:01:00 2008 Subject: [GHC] #2431: allow empty case analysis In-Reply-To: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@localhost> References: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@localhost> Message-ID: <057.e2965d98c4989086423439f020101d67@localhost> #2431: allow empty case analysis ---------------------------------+------------------------------------------ Reporter: RalfHinze | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: Keywords: empty case analysis | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------+------------------------------------------ Changes (by simonpj): * priority: normal => low * milestone: 6.12 branch => _|_ Comment: OK so I don't like GHC crashing, ever, so I have done the following: * In the renamer and typechecker, I allow empty `HsCase`. * In Core I still don't allow empty `Case`. I have no idea what stuff would break if empty `Case` was allowed; but even finding the type of an expression might become impossible. (Yes, at the moment `Case` records its result type, but with the new FC stuff that's not necessary and I may remove it.) And I see no reason to support it. * In the desugarer, I desguar empty `HsCase` to a call to `error`. (The simplifier already does this if it can figure out that a case is empty; see `Simplify.rebuildCase`.) So now Neil's TH example works instead of crashing. The parser prevents you doing this in source code, so I have not added a flag. To go the full distance we still need: * Parser to accept empty case expressions (currently rejected by parser) * -X flag to control this language extension * Test somewhere (in renamer) to check that empty case only happens when flag is on. * User manual docs * Regresssion tests in test suite. All easy but tiresome. If you care about this, send a patch! I've done the slightly-tricky bits. So I'll leave this bug open at low priority, milestone bottom. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 6 15:08:11 2008 From: trac at galois.com (GHC) Date: Wed Aug 6 15:07:50 2008 Subject: [GHC] #2480: error function is not lazy In-Reply-To: <051.ecb98bd3181d9ab4e7aa4d8a7990d204@localhost> References: <051.ecb98bd3181d9ab4e7aa4d8a7990d204@localhost> Message-ID: <060.1e3b1efa0f95e6ed55ff31d1d15a54f0@localhost> #2480: error function is not lazy --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: cg016 | Architecture: Unknown Os: Windows | --------------------------+------------------------------------------------- Comment (by Isaac Dupree): well, at least it could be split up into two pieces: the fact that there is an error, and the contents of the error, if possible. Usually it's rather useful to know it's not just an infinite loop. Perhaps there is some way to make two RTS calls, and have the first one put up an "Error" dialog and the second one (if it ever happens) add the error's contents? (e.g. `fix error` and `error (fix ('a':))` both cannot have their error strings serialized.) It might be useful to have a third division, say, the first 500 characters of the error message, or however many characters have been successfully generated within, say, 3 seconds of CPU time. Hmm, seems a bit complicated :-/ but going to an effort to print whatever you have of the error message will be useful for tracking where it came from (where the bug is -- which error call it is). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 6 15:43:56 2008 From: trac at galois.com (GHC) Date: Wed Aug 6 15:43:35 2008 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.462b8ef3ca63210b17e6fd6583fac8ea@localhost> #1338: base package breakup ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by igloo): Updated proposal. I'll attach `packagegraph.png` showing the package deps. This block is mostly as before, except timeout has to be in its own package so that unique can sit in the middle: {{{ timeout: System.Timeout unique: Data.Unique concurrent: Control.Concurrent Control.Concurrent.Chan Control.Concurrent.MVar Control.Concurrent.QSem Control.Concurrent.QSemN Control.Concurrent.SampleVar }}} st can be pulled out: {{{ st: Control.Monad.ST Control.Monad.ST.Lazy Control.Monad.ST.Strict Data.STRef Data.STRef.Lazy Data.STRef.Strict }}} control should probably actually be merged with containers, but making it its own package made my experimenting simpler: {{{ control: Control.Applicative Data.Foldable Data.Monoid Data.Traversable ghc-exts: GHC.Exts GHC.PArr }}} The `System.Mem` modules don't really seem to fit here, but I didn't have anywhere better to put them, and they are under `System` after all. {{{ system: System.CPUTime System.Environment System.Exit System.Info System.Mem System.Mem.StableName System.Mem.Weak numeric: Data.Complex Data.Fixed Data.Ratio generics: Data.Generics Data.Generics.Aliases Data.Generics.Basics Data.Generics.Instances Data.Generics.Schemes Data.Generics.Text Data.Generics.Twins version: Data.Version }}} Little misc packages; we might want to fold some of these back in later, but for now I just wanted to get them out of the way: {{{ getopt: System.Console.GetOpt debug: Debug.Trace printf: Text.Printf }}} Again, these I was just getting out of the way. They're internal to GHC, so where they end up shouldn't much matter: {{{ ghc-bits: GHC.ConsoleHandler GHC.Desugar GHC.Environment GHC.TopHandler }}} The rest of base I currently have cut in 2, with a `foreign` package stuck in the middle. If things don't improve here then I expect we'll stick them all back together for 6.10: {{{ base-top: Control.Exception Control.OldException Control.Category Control.Arrow Control.Monad.Fix Control.Monad.Instances Text.Show Text.Show.Functions System.IO.Error System.IO System.Posix.Types System.Posix.Internals Data.Ix Data.Function Prelude foreign Foreign Foreign.C Foreign.C.Error Foreign.C.String Foreign.Concurrent (GHC-only) Foreign.ForeignPtr Foreign.Marshal Foreign.Marshal.Alloc Foreign.Marshal.Array Foreign.Marshal.Error Foreign.Marshal.Pool Foreign.Marshal.Utils Foreign.Ptr Foreign.StablePtr base: Control.Monad Data.Bits Data.Bool Data.Char Data.Dynamic Data.Either Data.Eq Data.HashTable Data.IORef Data.Int Data.List Data.Maybe Data.Ord Data.String Data.Tuple Data.Typeable Data.Word Foreign.C.Types Foreign.Storable Numeric System.IO.Unsafe Text.ParserCombinators.ReadP Text.ParserCombinators.ReadPrec Text.Read Text.Read.Lex Unsafe.Coerce (plus a load of GHC-only internal modules) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 6 19:40:34 2008 From: trac at galois.com (GHC) Date: Wed Aug 6 19:40:14 2008 Subject: [GHC] #2492: ghc-pkg insists on having HOME environment variable set Message-ID: <045.533f5b01d030726f747ccf757a3c72f8@localhost> #2492: ghc-pkg insists on having HOME environment variable set ------------------------+--------------------------------------------------- Reporter: gnezdo | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Linux ------------------------+--------------------------------------------------- Even in cases when it should not need it, ghc-pkg still fails if HOME is unset: {{{ % env - ~/bin/ghc-pkg --global list ghc-pkg.bin: HOME: getEnv: does not exist (no environment variable) }}} Yet, if I just set the variable to a dummy value, ghc-pkg is happy: {{{ % env - HOME=/non-existent ~/bin/ghc-pkg --global list .../lib/ghc-6.8.2/package.conf: Cabal-1.2.3.0, HUnit-1.2.0.0, QuickCheck-1.1.0.0, array-0.1.0.0, base-3.0.1.0, bytestring-0.9.0.1, cgi-3001.1.5.1, containers-0.1.0.1, directory-1.0.0.0, fgl-5.4.1.1, ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 6 20:10:55 2008 From: trac at galois.com (GHC) Date: Wed Aug 6 20:10:33 2008 Subject: [GHC] #2493: implement proposed Qualified Operator syntax Message-ID: <051.85a6e8a5d506f432836c995c200eacbf@localhost> #2493: implement proposed Qualified Operator syntax --------------------------------+------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- proposed for haskell', we like the idea, we should implement it. http://hackage.haskell.org/trac/haskell-prime/wiki/QualifiedOperators http://thread.gmane.org/gmane.comp.lang.haskell.prime/2439/focus=2449 Need to decide on a name for the LANGUAGE flag (hmm.. !SanerQualifiedOperators?), as well as implementing the modified syntax( as a toggle-able thing). while searching the wiki to see if the ticket existed already, I found an old ticket of mine that seems mentioned an instance of the exact syntax we've proposed, #1383 :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 6 20:53:29 2008 From: trac at galois.com (GHC) Date: Wed Aug 6 20:53:09 2008 Subject: [GHC] #2490: GHC allows sections with out parenthesis in tuples In-Reply-To: <049.41558d2f5e8f1685b5dfab51d362bd22@localhost> References: <049.41558d2f5e8f1685b5dfab51d362bd22@localhost> Message-ID: <058.10cf6ef496a2c10aa2bb8f6f1c30807f@localhost> #2490: GHC allows sections with out parenthesis in tuples ---------------------------+------------------------------------------------ Reporter: JeremyShaw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ---------------------------+------------------------------------------------ Comment (by JeremyShaw): Christian Maeder noted the following: Also (+ x, ()) ((), + x) ((), + x, ()) are accepted by GHC This looks like a bug to me, because (+, ()) ((), x +) are rejected. Sections need to be in parens. If one allows sections as tuple components, then the latter should may be made legal, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 6 21:29:22 2008 From: trac at galois.com (GHC) Date: Wed Aug 6 21:28:59 2008 Subject: [GHC] #2490: GHC allows sections with out parenthesis in tuples In-Reply-To: <049.41558d2f5e8f1685b5dfab51d362bd22@localhost> References: <049.41558d2f5e8f1685b5dfab51d362bd22@localhost> Message-ID: <058.2ee93039c33cbcf9fd2ce560926035b1@localhost> #2490: GHC allows sections with out parenthesis in tuples ---------------------------+------------------------------------------------ Reporter: JeremyShaw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ---------------------------+------------------------------------------------ Comment (by JeremyShaw): ack. I didn't notice that the wiki formatting ate my characters on the web page version of this bug. To summarize, GHC accepts these: {{{ f x = (`head x`, ()) (+ x, ()) ((), + x) ((), + x, ()) }}} But not these: {{{ (+, ()) ((), x +) }}} And H98 seems to indicate none of them should be accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 6 23:26:51 2008 From: trac at galois.com (GHC) Date: Wed Aug 6 23:26:29 2008 Subject: [GHC] #2494: Panic in tcSimplifyRuleLhs Message-ID: <041.cc78c90da661d834f8200361ebf7eb74@localhost> #2494: Panic in tcSimplifyRuleLhs ------------------------+--------------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- With this module, both 6.8.3 and the HEAD panic in `tcSimplifyRuleLhs`: {{{ {-# LANGUAGE Rank2Types, ScopedTypeVariables #-} module Foo where foo :: (forall m. Monad m => Maybe (m a) -> Maybe (m a)) -> Maybe a -> Maybe a foo _ x = x {-# RULES "foo/foo" forall (f :: forall m. Monad m => Maybe (m a) -> Maybe (m a)) (g :: forall m. Monad m => Maybe (m b) -> Maybe (m b)) x. foo f (foo g x) = foo (f . g) x #-} }}} Note that the rule is incorrectly typed; with the correct types, no panic happens. Incidentially, I'm not sure if `ScopedTypeVariables` should be required here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 7 03:26:10 2008 From: trac at galois.com (GHC) Date: Thu Aug 7 03:25:48 2008 Subject: [GHC] #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode In-Reply-To: <049.31db7471187fa0b39e4d12923cd80edb@localhost> References: <049.31db7471187fa0b39e4d12923cd80edb@localhost> Message-ID: <058.175b4eee581bc45c894165945ee59aec@localhost> #2452: Add a flag to disable the implicit qualified import of every available module in interactive mode -------------------------------------+-------------------------------------- Reporter: jcpetruzza | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Done: {{{ Tue Aug 5 08:17:30 PDT 2008 Simon Marlow * Add -fno-implicit-import-qualified (#2452) The flag is off by default, but GHCi turns it on (in Main.hs). For GHCi it can be overriden on the command-line or using :set. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 7 04:27:47 2008 From: trac at galois.com (GHC) Date: Thu Aug 7 04:27:26 2008 Subject: [GHC] #2495: Source dist should include Happy/Alex-generated sources Message-ID: <047.edfee026faeed124911f8a005cc577d9@localhost> #2495: Source dist should include Happy/Alex-generated sources -----------------------------+---------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- For 6.10.1 we need to make sure that the source dist contains the generated files, so that building from the source tarball doesn't require Happy or Alex. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 7 05:37:21 2008 From: trac at galois.com (GHC) Date: Thu Aug 7 05:36:58 2008 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version Message-ID: <044.b515c7a01d17e019028e237b73b96edc@localhost> #2496: Invalid Eq/Ord instances in Data.Version -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- (From Adrian Hey) In Data.Version we have: {{{ data Version = Version {versionBranch :: [Int] ,versionTags :: [String] } instance Eq Version where v1 == v2 = versionBranch v1 == versionBranch v2 && sort (versionTags v1) == sort (versionTags v2) -- tags may be in any order instance Ord Version where v1 `compare` v2 = versionBranch v1 `compare` versionBranch v2 }}} The "laws" for valid Eq/Ord instances were argued about recently but the H98 report seems reasonably clear that (==) is supposed to test for equality and the compare method is supposed to define a total ordering. There is also an implied but not explicitly stated law that: {{{ (x == y = True) <-> (x `compare` y = EQ) }}} and also this I guess.. {{{ (x == y = False) <-> ~(x `compare` y = EQ) }}} This law is implied by the Eq constraint on the Ord class (which seems to serve no purpose otherwise). See also: [http://www.haskell.org/pipermail/haskell-prime/2008-March/002330.html] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 7 06:15:55 2008 From: trac at galois.com (GHC) Date: Thu Aug 7 06:15:31 2008 Subject: [GHC] #2497: Weird scoping for tyvars in rules Message-ID: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> #2497: Weird scoping for tyvars in rules ------------------------+--------------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- This rule: {{{ {-# RULES "id" forall (x :: a). id x = x #-} }}} compiles fine with no `LANGUAGE` options but fails if I add `Rank2Types`: {{{ Not in scope: type variable `a' }}} It compiles fine again if I additionally include `ScopedTypeVariables`. This looks wrong to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 7 06:21:29 2008 From: trac at galois.com (GHC) Date: Thu Aug 7 06:21:05 2008 Subject: [GHC] #2498: RULES pragma broken in the head Message-ID: <041.31ecd942feb0616590c88e5b3074c464@localhost> #2498: RULES pragma broken in the head ------------------------+--------------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- This module: {{{ module Foo where {-# RULES "id" forall x. id x = x #-} }}} compiles fine with 6.8.3 but the HEAD says (twice): {{{ Foo.hs:2:0: Unrecognised pragma }}} Adding `-frewrite-rules` has no effect. But with `-XRank2Types`, it compiles fine for some reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 7 06:28:48 2008 From: trac at galois.com (GHC) Date: Thu Aug 7 06:28:25 2008 Subject: [GHC] #2497: Weird scoping for tyvars in rules In-Reply-To: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> References: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> Message-ID: <050.a8f357d31acddd52e23e0a72945c3a93@localhost> #2497: Weird scoping for tyvars in rules -------------------------+-------------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Comment (by rl): Forgot to mention: this is perhaps related to #2494. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 7 06:46:30 2008 From: trac at galois.com (GHC) Date: Thu Aug 7 06:46:07 2008 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@localhost> References: <044.b515c7a01d17e019028e237b73b96edc@localhost> Message-ID: <053.ff860c1d51194fab0977217608fd4c12@localhost> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------------+-------------------------------------------- Comment (by duncan): See also the thread on cabal-devel starting with: http://haskell.org/pipermail/cabal-devel/2008-May/002818.html The conclusion of the discussion was that we should either remove the tags completely, or at minimum change the Eq instance to consider only the `versionBranch`. I was going to put a proposal to removing them through the libraries submission process. I suppose I should get round to doing that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 7 07:32:25 2008 From: trac at galois.com (GHC) Date: Thu Aug 7 07:32:06 2008 Subject: [GHC] #1741: Threaded RTS must use processor affinity and processor information In-Reply-To: <044.e4defb5de192ad7951ca4bf955f5c177@localhost> References: <044.e4defb5de192ad7951ca4bf955f5c177@localhost> Message-ID: <053.73d70e8f63464e32f8f9a43b157a6385@localhost> #1741: Threaded RTS must use processor affinity and processor information ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by tibbe): * cc: johan.tibell@gmail.com (added) Comment: Replying to [comment:2 simonmar]: > One problem with setting `-N` to something other than 1 by default is that `System.Posix.forkProcess` only works with `-N1`, so if you use that function then you need to fix `-N1` somehow (probably with a hook). I'm not sure I want to contemplate making `forkProcess` work for larger values of N. I suspect `forkProcess` is rare, and we might want to deprecate it anyway. POSIX already puts pretty severe restrictions on what you can do in the child process after `fork()` in a threaded program, so it's not clear that we should be providing it at the Haskell level. I really need to be able to fork in the threaded RTS to daemonize my process. I imagine that other server programs need to do the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 7 07:54:56 2008 From: trac at galois.com (GHC) Date: Thu Aug 7 07:54:32 2008 Subject: [GHC] #2499: OPTIONS pragma silently ignored Message-ID: <046.91540bf76265b8560aaa0dae63298652@localhost> #2499: OPTIONS pragma silently ignored -------------------------+-------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- {{{ {-# OPTIONS_GHC -package blarg #-} module Foo where f x = x }}} This compiles, but it shouldn't because there is no such package. AND because `-package` is not an acceptable OPTIONS flag in a module. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 7 07:58:11 2008 From: trac at galois.com (GHC) Date: Thu Aug 7 07:57:47 2008 Subject: [GHC] #2500: Unrecognised pragma complained about twice Message-ID: <046.9e9cf92de5daf74529e4e511f971313e@localhost> #2500: Unrecognised pragma complained about twice -------------------------+-------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- {{{ module Foo where {-# FOO wibble #-} f x = x }}} We get two complaints: {{{ c:/simonpj/darcs/HEAD/ghc/stage1-inplace/ghc -c Foo.hs Foo.hs:3:0: Unrecognised pragma Foo.hs:3:0: Unrecognised pragma sh-2.04$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 7 08:37:23 2008 From: trac at galois.com (GHC) Date: Thu Aug 7 08:37:00 2008 Subject: [GHC] #2501: [Document] Is it possible to add an example to show how to use SCC in profiling? Moreover, there seems no explaination for +RTS -s -S Message-ID: <049.55daf57c282859db865e658846ee4aed@localhost> #2501: [Document] Is it possible to add an example to show how to use SCC in profiling? Moreover, there seems no explaination for +RTS -s -S ------------------------------+--------------------------------------------- Reporter: rivercheng | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.8.2 | Severity: normal Keywords: SCC profiling | Testcase: Architecture: Unknown | Os: Linux ------------------------------+--------------------------------------------- In the GHC document: 1)Could an example of how to use SCC be added? 2)It is hard to find how to use +RTS -S/-s and how to understand the output of GC statistics. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 7 11:54:43 2008 From: trac at galois.com (GHC) Date: Thu Aug 7 11:54:20 2008 Subject: [GHC] #2502: segfault with GHC.Handle.fdToHandle' Message-ID: <046.3af147e9b383729d4b3cbb7db169730e@localhost> #2502: segfault with GHC.Handle.fdToHandle' ------------------------+--------------------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Component: None Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: FreeBSD ------------------------+--------------------------------------------------- While trying to configure darcs, a FreeBSD user discovered that the following program segfaults if you compile it with "ghc -threaded -optl-L/usr/local/lib -optl-L/usr/local/lib/ -optl-pthread" {{{ import GHC.Handle ( fdToHandle' ) import IO ( IOMode(..) ) main = fdToHandle' 1 Nothing False "stdout" WriteMode True }}} For more details, please see http://bugs.darcs.net/issue979 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 7 20:20:09 2008 From: trac at galois.com (GHC) Date: Thu Aug 7 20:19:45 2008 Subject: [GHC] #2503: Panic related to MPTC's and type equality Message-ID: <044.29d0f32f56dfa872b27dea0e61cbb1c3@localhost> #2503: Panic related to MPTC's and type equality -----------------------+---------------------------------------------------- Reporter: Benja | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- The following code: {{{ {-# OPTIONS_GHC -fglasgow-exts #-} class Foo a b where foo :: a instance (a ~ ()) => Foo [a] b where foo = undefined main = print "hello" }}} gives this: {{{ ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): nameModule $dFoo{v aqY} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 7 22:07:49 2008 From: trac at galois.com (GHC) Date: Thu Aug 7 22:07:29 2008 Subject: [GHC] #2503: Panic related to MPTC's and type equality In-Reply-To: <044.29d0f32f56dfa872b27dea0e61cbb1c3@localhost> References: <044.29d0f32f56dfa872b27dea0e61cbb1c3@localhost> Message-ID: <053.76f1e6c30f02f0a13e8da9878d34cf6e@localhost> #2503: Panic related to MPTC's and type equality -------------------------+-------------------------------------------------- Reporter: Benja | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Changes (by chak): * status: new => closed * resolution: => worksforme Comment: I am pretty sure that bug has long been fixed in the HEAD. Please try with that. Equality constraints are not really a supported feature in the 6.8 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 8 09:21:43 2008 From: trac at galois.com (GHC) Date: Fri Aug 8 09:21:16 2008 Subject: [GHC] #2497: Weird scoping for tyvars in rules In-Reply-To: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> References: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> Message-ID: <050.969bcbf50f788f680f40395938988e1f@localhost> #2497: Weird scoping for tyvars in rules ----------------------+----------------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Ah, there are a bunch of issues here. Two other closely related tickets are #2498 and #2213. I'll write some notes here to cover all three. I have not executed any of the actions; I'm interested to know what others think * RULES pragmas can't be parsed if the lexer isn't recognising 'forall' as a keyword (you'd get parse errors immediately). So the lexer only recognises RULES as a pragma if the lexer's explicitForallBit is on. Currently that bit is switched on by the extensions `ScopedTypeVariables`, `PolymorphicComponents`, `ExistentialQuantification`, `Rank2Types`, and `RankNTypes`. * If one of these flags isn't on, the lexer pretends not to recongise the RULES pragma, which in turn gives an "unrecognised pragma" error in the HEAD. That seems wrong, regardless of flags: it's a perfectly good pragma. * '''ACTION 1''': We should have a language extension `-XRewriteRules` that makes the lexer recognise RULES pragmas. If `-XRewriteRules` is not on, they should be silently ignored as comments. * '''ACTION 2''': The `-XRewriteRules` extension should enable 'forall' as a keyword (the explicitForAllBit). * In a RULE, the 'forall' binds only *term*-variables. You can't say `RULES "foo" forall a (x::a). `. There's no reason in principle why not, but we'd need syntax to distinguish term from type variables, so I don't propose to change this. * So type variables are brought into scope much as they are in a pattern match, such as `(\(x::a) -> blah)`. At the moment, you have to specify *both* `-XPatternSignatures` to allow such a type signature in a pattern at all; '''and''' `-XScopedTypeVariables` to allow the type variable to have scope This is a bit confusing, but it does make sense to have `-XPatternSignatures` without `-XScopedTypeVariables`; you migh say `(\(x::Int)-> blah)` for example. '''ACTION 3''': still, I propose that `-XScopedTypeVariables` *implies* `-XPatternSignatures`. * Currently if you use `-XPatternSignatures` without `-XScopedTypeVariables` for `(\(x::a) -> blah)` you get {{{ T2497.hs:3:28: Not in scope: type variable `a' }}} And you can see why now! * RULES always allow signatures on the forall'd binders; you don't need -XPatternSignatures (and I think it'd be pedantic to require it). So now you can see why you get the scope error. Possible alternatives to the status quo * `-XRewriteRules` implies `-XScopedTypeVariables`, in the entire module * We unconditionally but locally enable `-XScopedTypeVariables` in a rewrite rule. In some ways this would be consistent with the way that RULES allow signatures without a flag '''ACTION 4''': Opinions? * The flag `-frewrite-rules` is actually an *optimisation* flag. If it's off, the Simplifier doesn't apply any rules at all. It's implied by -O. '''ACTION 5''': it looka s bit too much like a language flag. I wonder about renaming it to `-fenable-rewrite-rules` or `-fuse-rewrite-rules` Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 8 11:01:52 2008 From: trac at galois.com (GHC) Date: Fri Aug 8 11:01:26 2008 Subject: [GHC] #2504: linkBCO: >= 64k insns in BCO Message-ID: <044.eb1814cf2ce1c6f8bbe30616e31fb749@localhost> #2504: linkBCO: >= 64k insns in BCO ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- I was working on problem 22 of Project Euler, see http://projecteuler.net/index.php?section=problems&id=22. I download a file names.txt and wanted to make a haskell file of this with the following before the string: > module Problem22 where > names = [ and a closing bracket after the list of names of course. I also tried a search and replace, so it is not one big line. When loading this ghci on windows vista gives the following error: GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Problem22 ( C:/prive/Haskell/Bart/problem22.lhs, interpreted ) : panic! (the 'impossible' happened) (GHC version 6.8.3 for i386-unknown-mingw32): linkBCO: >= 64k insns in BCO Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 8 11:16:34 2008 From: trac at galois.com (GHC) Date: Fri Aug 8 11:16:08 2008 Subject: [GHC] #1218: Add sortNub and sortNubBy to Data.List In-Reply-To: <043.ff9032e500fd9c14d06a05d463884228@localhost> References: <043.ff9032e500fd9c14d06a05d463884228@localhost> Message-ID: <052.2fcae8a96dcf83068cdf77452bc52724@localhost> #1218: Add sortNub and sortNubBy to Data.List ----------------------------+----------------------------------------------- Reporter: neil | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Changes (by guest): * cc: gwern0@gmail.com (added) * version: => 6.8.2 * os: Unknown => Linux Comment: This may be abandoned, but I'm curious. Is this actually an optimization? I've been trying out some toy examples, and the 'map head . group . sort' version seems to perform absolutely terribly compared to just 'sort . nub', at least on my sample. Example: ---- gwern@craft:15969~>cat tmp2.hs [ 9:58AM] import Data.List main = print $ uniq $ take 1000000000 $ cycle [1] uniq = sort . nub% gwern@craft:15970~>time runhaskell tmp2.hs [ 9:58AM] [1] runhaskell tmp2.hs 45.90s user 0.23s system 66% cpu 1:09.24 total gwern@craft:15971~>cat tmp4.hs [ 9:59AM] import Data.Set main = print $ uniq $ take 1000000000 $ cycle [1] uniq = toList . fromList gwern@craft:15974~>time runhaskell tmp4.hs [10:00AM] [1] runhaskell tmp4.hs 38.14s user 0.14s system 96% cpu 39.743 total gwern@craft:15975~>cat tmp3.hs [10:02AM] import Data.List main = print $ uniq $ take 1000000000 $ cycle [1] uniq = map head . group . sort gwern@craft:15976~> ---- You'll understand if I don't provide timings for tmp3.hs (the map head implementation) since it takes vastly longer than 30 seconds and eats so much RAM and CPU time that it locks my system overnight. Admittedly, perhaps a list of repeated items is not the best usecase, but shouldn't optimizations - particularly optimizations in the base library be a win in all cases? (and particularly not huge pessimizations in some cases)? -- gwern -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 8 12:17:20 2008 From: trac at galois.com (GHC) Date: Fri Aug 8 12:16:52 2008 Subject: [GHC] #2494: Panic in tcSimplifyRuleLhs In-Reply-To: <041.cc78c90da661d834f8200361ebf7eb74@localhost> References: <041.cc78c90da661d834f8200361ebf7eb74@localhost> Message-ID: <050.0812f5b827bdb96c3fd071f8faf3034b@localhost> #2494: Panic in tcSimplifyRuleLhs ----------------------+----------------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Good point. I have a patch for this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 8 20:06:49 2008 From: trac at galois.com (GHC) Date: Fri Aug 8 20:06:21 2008 Subject: [GHC] #2505: windows installer should not hijack filetype associations! Message-ID: <044.a62339318202233961e8d0b3da109f64@localhost> #2505: windows installer should not hijack filetype associations! ------------------------+--------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- the 6.8.3 installer does not respect or preserve existing filetype associations: before installing, I had arranged for several things on my right-click menu for .hs files, such as edit with Vim (default), open with WinHugs, open with Ghci 6.6.1, open with Ghci 6.9. during installation, the only options I have are install and start menu location. after install, the additions I made manually are gone, including WinHugs and Ghci 6.6.1 (which installed themselves, but I had modified the entries), the edit with Vim default is replaced with open (calling ghci 6.8.3), only the separate edit with Vim (which remained they way Vim installed it) is left. this is really part of a very old issue, #916, which degenerated into a general installer discussion and ultimately disappeared into _|_. this new ticket is only about the right-click menu, on which we had reached agreement in that older discussion: installers should (a) only add right- click entries, never lose existing ones and (b) even that should be optional during installation. (now I remember why I preferred tarballs..) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 8 22:01:22 2008 From: trac at galois.com (GHC) Date: Fri Aug 8 22:00:53 2008 Subject: [GHC] #2506: infix assert panics ghc Message-ID: <044.3043ed924f65ac215b3b93b6e6566455@localhost> #2506: infix assert panics ghc -----------------------+---------------------------------------------------- Reporter: galen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- I was repeatedly getting this: {{{ ghc-6.8.3: panic! (the 'impossible' happened) (GHC version 6.8.3 for i386-unknown-linux): rename/RnExpr.lhs:(139,26)-(150,42): Non-exhaustive patterns in lambda }}} After some narrowing down, I eventually found the culprit and got a repeatable error with this minimal snippet: {{{ import Control.Exception (assert) foo = True `assert` () }}} The infixness is crucial; {{{assert True ()}}} compiles without difficulty. I use infix notation elsewhere, so it appears to be something special about {{{assert}}}. I was able to compile successfully if I used {{{-O2}}}. I see now that was likely because the asserts are simply eliminated early. I compiled ghc from sources, so it's barely possible I did something wrong there, but the nature of the symptoms make this doubtful. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 9 14:49:56 2008 From: trac at galois.com (GHC) Date: Sat Aug 9 14:49:24 2008 Subject: [GHC] #2507: quotation characters in error messages Message-ID: <051.38b1ebfeec872e08862a450e1303ba1d@localhost> #2507: quotation characters in error messages --------------------------------+------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- (wasn't there a ticket for this already?) Currently identifiers etc. are quoted like this, with the "grave accent" and symmetric single-quote characters: {{{ Ambiguous type variable `m' in the constraint: `Monad m' arising from a use of `>>=' at gw.hs:6:47-71 }}} This is not only an incorrect use of the "grave accent", but can be confusing when an identifier-name contains the prime symbol which is the same as the character used here to end the quote. What should we do? Well, I just noticed that gcc-4.2.3 uses the Unicode begin-single-quote and end-single-quote characters for the purpose (and it actually looks quite nice on my terminal). If GCC was willing to do it, perhaps we should be too! To be precise, it uses them in my default locale, "en_US.UTF-8", which must have been the Ubuntu default that I didn't even remember I had. With `env LANG=C`, GCC emits ASCII single- quotes for both the begin and the end. {{{ > cat errory.c syntax error > gcc errory.c errory.c:1: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?error? > env LANG=C gcc errory.c errory.c:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'error' }}} I propose copying GCC's behavior (which might involve first looking into exactly what its behavior is in the general case). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 9 18:47:23 2008 From: trac at galois.com (GHC) Date: Sat Aug 9 18:46:56 2008 Subject: [GHC] #2380: Adjustor.o crash compiling ghc 6.8.3 on iBook G4 10.4.11 In-Reply-To: <045.f144b092f23e8db9c081050578f2b103@localhost> References: <045.f144b092f23e8db9c081050578f2b103@localhost> Message-ID: <054.e0bad46f9e3f11db50ecb83de56511bf@localhost> #2380: Adjustor.o crash compiling ghc 6.8.3 on iBook G4 10.4.11 --------------------------+------------------------------------------------- Reporter: povman | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | --------------------------+------------------------------------------------- Comment (by steve): Building using ghc 6.8.3 installed from the binary package works. When building via MacPorts, it uses 6.8.2 to build and that causes the built stage1/ghc-inline to segfault while compiling .c files in the rts directory, not just Adjustor.c which is merely the first one. If I run with -v -ddump-stg -ddump-simpl -ddump-cmm -dppr-debug, I get the following. ../compiler/ghc-inplace -optc-O -optc-I/opt/local/include -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing- declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame- pointer -optc-I/opt/local/include -optc-I../gmp/gmpbuild -optc-fno-strict- aliasing -H16m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -package- name rts -static -I/opt/local/include -I../gmp/gmpbuild -I. -#include HCIncludes.h -dcmm-lint -c Adjustor.c -o Adjustor.o -v -ddump-stg -ddump-simpl -ddump-cmm -dppr-debug Glasgow Haskell Compiler, Version 6.8.3, for Haskell 98, stage 1 booted by GHC version 6.8.2 Using package config file: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.8.3/driver/package.conf.inplace Segmentation fault -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 9 19:36:35 2008 From: trac at galois.com (GHC) Date: Sat Aug 9 19:36:09 2008 Subject: [GHC] #2488: ByteString hGet documentation is incomplete In-Reply-To: <042.180b053b7dabbf116ac00f7d05a45f02@localhost> References: <042.180b053b7dabbf116ac00f7d05a45f02@localhost> Message-ID: <051.362749d16c4a654e13330bd3b56712c3@localhost> #2488: ByteString hGet documentation is incomplete -------------------------------+-------------------------------------------- Reporter: cjs | Owner: dons Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------------+-------------------------------------------- Changes (by dons): * owner: => dons Comment: Fixed. I've documented hGet's behaviour wrt. EOF and handles closing. The next release will contain this documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 9 19:37:26 2008 From: trac at galois.com (GHC) Date: Sat Aug 9 19:36:55 2008 Subject: [GHC] #2488: ByteString hGet documentation is incomplete In-Reply-To: <042.180b053b7dabbf116ac00f7d05a45f02@localhost> References: <042.180b053b7dabbf116ac00f7d05a45f02@localhost> Message-ID: <051.2420d91e11b78e2c5794e46535c71b69@localhost> #2488: ByteString hGet documentation is incomplete -------------------------------+-------------------------------------------- Reporter: cjs | Owner: dons Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------------+-------------------------------------------- Changes (by dons): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 10 04:06:55 2008 From: trac at galois.com (GHC) Date: Sun Aug 10 04:06:23 2008 Subject: [GHC] #888: Implement the static argument transformation In-Reply-To: <046.4f72376cf2bb17c84e2a65a1a9e8119c@localhost> References: <046.4f72376cf2bb17c84e2a65a1a9e8119c@localhost> Message-ID: <055.e971c36bcdd6cb629554694d0f9ed6ad@localhost> #888: Implement the static argument transformation ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by batterseapower): I'm currently investigating using the SAT to get stream fusion working properly, as per the ICFP07 paper. This probably just requires moving the SAT pass to a late stage in the pipeline (post-constructor specialisation) but I'm awaiting experimental results. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 10 07:28:41 2008 From: trac at galois.com (GHC) Date: Sun Aug 10 07:28:10 2008 Subject: [GHC] #2508: exception handling: exitWith ExitSuccess results in abnormal termination with Control.OldException Message-ID: <044.3565fd6a785086b82dda34be53000404@localhost> #2508: exception handling: exitWith ExitSuccess results in abnormal termination with Control.OldException -----------------------+---------------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Consider this program. {{{ import System.Exit import Control.OldException main = exitWith ExitSuccess `finally` return () }}} It should not produce any output and return 0 as its exit code. Instead we get: {{{ # runhaskell test.hs exit: ExitSuccess # echo $? 1 }}} The problem is that {{{finally}}} catches the exception and rethrows it. In the process, the {{{OldException}}} module maps exceptions to ''old'' exceptions, but never maps them back when they're thrown. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 10 10:39:13 2008 From: trac at galois.com (GHC) Date: Sun Aug 10 10:38:46 2008 Subject: [GHC] #2497: Weird scoping for tyvars in rules In-Reply-To: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> References: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> Message-ID: <050.ed5e35eab8ff7b418b2f8d9562b0ac58@localhost> #2497: Weird scoping for tyvars in rules ----------------------+----------------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by rl): My two pebbles... * '''ACTION 1''': Agreed in principle, but what about backwards compatibility? There is a lot of code with RULES and none of it uses `-XRewriteRules`. IMO, it would be better to always recognise RULES. Note also that RULES don't necessarily require `forall`; see http://www.haskell.org/ghc/docs/latest/html/users_guide/rewrite-rules.html #rule-spec for examples. * '''ACTION 2''': I think `forall` in RULES should always be recognised as a keyword. It is quite different from the other uses of `forall`, anyway, since it quantifies over terms, not types. Also, coupling `explicitForallBit` with a not obviously related language feature seems wrong. If `forall` isn't always recognised in RULES, we should have a separate `-XForallKeyword` (perhaps we should have that anyway). * '''ACTION 3''': I think the two should be kept separate but don't really care either way. * '''ACTION 4''': Enable `-XScopedTypeVariables` locally. Does `-XPatternSignatures` apply to RULES somehow? If so, enable this locally as well. * '''ACTION 5''': `-fuse-rewrite-rules` or `-fapply...` looks good to me. * I think `forall` in RULES should bind type variables as well. I'm not sure new syntax is needed here: if it is used as a type, it's a type variable, otherwise it's a term variable. Or can this lead to ambiguities? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 10 12:17:34 2008 From: trac at galois.com (GHC) Date: Sun Aug 10 12:17:02 2008 Subject: [GHC] #2485: Installed ghci wrapper refers to nonexistent file In-Reply-To: <044.2c0bcbfdb00152697f27863db8618203@localhost> References: <044.2c0bcbfdb00152697f27863db8618203@localhost> Message-ID: <053.9764bd501fdc67d3dbb444738d39a098@localhost> #2485: Installed ghci wrapper refers to nonexistent file ----------------------+----------------------------------------------------- Reporter: judah | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 10 12:25:48 2008 From: trac at galois.com (GHC) Date: Sun Aug 10 12:25:16 2008 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM In-Reply-To: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> References: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> Message-ID: <054.e9bbba63b3dcc5e98ebb7d20226cb75f@localhost> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM ---------------------+------------------------------------------------------ Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by igloo): * cc: ndmitchell@gmail.com (added) * difficulty: => Unknown * milestone: => 6.10.1 Comment: Hmm, `HKLM` looks like it contains a different hierarchy. Is `HKEY_USERS/.DEFAULT` what we want? Neil, do you know what we should be doing here? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 10 12:28:24 2008 From: trac at galois.com (GHC) Date: Sun Aug 10 12:27:51 2008 Subject: [GHC] #2485: Installed ghci wrapper refers to nonexistent file In-Reply-To: <044.2c0bcbfdb00152697f27863db8618203@localhost> References: <044.2c0bcbfdb00152697f27863db8618203@localhost> Message-ID: <053.a411ee49e66612f7b316642a90b16c19@localhost> #2485: Installed ghci wrapper refers to nonexistent file ----------------------+----------------------------------------------------- Reporter: judah | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 10 12:40:47 2008 From: trac at galois.com (GHC) Date: Sun Aug 10 12:40:13 2008 Subject: [GHC] #2500: Unrecognised pragma complained about twice In-Reply-To: <046.9e9cf92de5daf74529e4e511f971313e@localhost> References: <046.9e9cf92de5daf74529e4e511f971313e@localhost> Message-ID: <055.692a6d39c47bbc0e74287376330e8704@localhost> #2500: Unrecognised pragma complained about twice ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): However, with this module: {{{ module Foo where w = () {-# FOO wibble #-} f x = x }}} we get only one warning. I haven't checked, but I'm pretty sure that what's happening here is that the first warning is given when we are looking for OPTIONS and LANGUAGE pragmas, and the second warning is given when we are actually parsing the module for real. I don't think we should get rid of the first warning, e.g. with: {{{ {-# OOPS_TYPO_LANGAUGE CPP #-} module Foo where z = () #if FOO q = q #else w = w #endif }}} it's the only one we get: {{{ q.hs:2:0: Unrecognised pragma q.hs:8:1: lexical error at character 'i' }}} But not giving the second warning is hard. Personally I'd be tempted to leave things as they are; thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 10 12:42:58 2008 From: trac at galois.com (GHC) Date: Sun Aug 10 12:42:25 2008 Subject: [GHC] #2498: RULES pragma broken in the head In-Reply-To: <041.31ecd942feb0616590c88e5b3074c464@localhost> References: <041.31ecd942feb0616590c88e5b3074c464@localhost> Message-ID: <050.8d3d92c39291d56d8aa41d5f7ea6e945@localhost> #2498: RULES pragma broken in the head ----------------------+----------------------------------------------------- Reporter: rl | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 10 12:55:07 2008 From: trac at galois.com (GHC) Date: Sun Aug 10 12:54:34 2008 Subject: [GHC] #2508: exception handling: exitWith ExitSuccess results in abnormal termination with Control.OldException In-Reply-To: <044.3565fd6a785086b82dda34be53000404@localhost> References: <044.3565fd6a785086b82dda34be53000404@localhost> Message-ID: <053.b96edb34eb375cd80b8a107dd47297ff@localhost> #2508: exception handling: exitWith ExitSuccess results in abnormal termination with Control.OldException ----------------------------+----------------------------------------------- Reporter: int-e | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 Comment: Ah, I think we actually want `TopHandler` to also try catching the old `Exception` type. I'll look into this, although I might leave it until after the base splitting has happened. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 10 13:24:04 2008 From: trac at galois.com (GHC) Date: Sun Aug 10 13:23:33 2008 Subject: [GHC] #2509: ghc-pkg uses wrong package.conf Message-ID: <044.8363d849e74f3b77bf571200aec1b330@localhost> #2509: ghc-pkg uses wrong package.conf -----------------------+---------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- After installing HEAD ghc, running ghc-pkg lists no packages (not even base or rts): {{{ $ /Users/judah/tmp/ghc-stage/bin/ghc-pkg list /Users/judah/tmp/ghc-stage/share/ghc-6.9.20080809/ghc- pkg-6.9/package.conf: }}} The problem is that `utils/ghc-pkg/ghc-pkg.wrapper` points to the `$datadir` of ghc-pkg, which is the `ghc-stage/share/[etc]` folder listed above; whereas the package database used by ghc is instead: {{{ /Users/judah/tmp/ghc-stage/lib/ghc-6.9.20080809/package.conf }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 10 14:30:33 2008 From: trac at galois.com (GHC) Date: Sun Aug 10 14:30:01 2008 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM In-Reply-To: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> References: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> Message-ID: <054.71cee648334ceef6a65da343b44b8739@localhost> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM ---------------------+------------------------------------------------------ Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by claus): * cc: claus (added) Comment: This kind of decision (user vs system install) should be controllable during installation. Also, registry modification ought to be '''optional''', like anything the installer does (cf. #2505). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 10 15:05:28 2008 From: trac at galois.com (GHC) Date: Sun Aug 10 15:04:57 2008 Subject: [GHC] #2509: ghc-pkg uses wrong package.conf In-Reply-To: <044.8363d849e74f3b77bf571200aec1b330@localhost> References: <044.8363d849e74f3b77bf571200aec1b330@localhost> Message-ID: <053.496aabde733183f90d443cd5d14898d2@localhost> #2509: ghc-pkg uses wrong package.conf ----------------------+----------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed * milestone: => 6.10.1 Comment: Coincidentally, I was fixing this earlier today. I've just pushed the fix, so it should work now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 10 15:24:03 2008 From: trac at galois.com (GHC) Date: Sun Aug 10 15:23:29 2008 Subject: [GHC] #2510: Environment modification during installation should be optional Message-ID: <045.3e84f679ca4e95a8a9ec350bbb64b495@localhost> #2510: Environment modification during installation should be optional --------------------------------+------------------------------------------- Reporter: nimnul | Owner: Type: feature request | Status: new Priority: normal | Component: None Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Actual behaviour: GHC 6.8.3 Installer adds GHC to the PATH environment variable of the user who started the installer Expected behaviour: The installer should prompt a user whether to modify the environment at all -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 10 15:35:04 2008 From: trac at galois.com (GHC) Date: Sun Aug 10 15:34:30 2008 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM In-Reply-To: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> References: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> Message-ID: <054.c3ea5799d0408dadbcaf7cecea3df069@localhost> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM ---------------------+------------------------------------------------------ Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Comment (by nimnul): The bug is related to #2510 - the modification of system environment (namely of PATH) suffers from the same problems as registry modification. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 10 16:56:58 2008 From: trac at galois.com (GHC) Date: Sun Aug 10 16:56:23 2008 Subject: [GHC] #2511: unix package doesnt load in ghci on freebsd/amd64 Message-ID: <046.b342e2cde385158917f69c7725044f60@localhost> #2511: unix package doesnt load in ghci on freebsd/amd64 -------------------------------+-------------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Component: libraries/unix Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: FreeBSD -------------------------------+-------------------------------------------- When loading the "unix" package in ghci, the interpreter gives a link error: $ ghci -package unix GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package filepath-1.1.0.0 ... linking ... done. Loading package directory-1.0.0.0 ... linking ... done. Loading package unix-2.3.0.0 ... ghc-6.8.2: can't load .so/.DLL for: util (/usr/lib/libutil.so: Undefined symbol "__mb_sb_limit") As noted above this is ghc-6.8.2. I built from sources. My machine is: FreeBSD hpsux 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sat Mar 8 14:07:11 HST 2008 root@hpsux:/usr/obj/usr/src/sys/GENERIC amd64 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 11 00:10:44 2008 From: trac at galois.com (GHC) Date: Mon Aug 11 00:10:11 2008 Subject: [GHC] #2508: exception handling: exitWith ExitSuccess results in abnormal termination with Control.OldException In-Reply-To: <044.3565fd6a785086b82dda34be53000404@localhost> References: <044.3565fd6a785086b82dda34be53000404@localhost> Message-ID: <053.fd52983e6dada4cc1b671e7d7eb11748@localhost> #2508: exception handling: exitWith ExitSuccess results in abnormal termination with Control.OldException ----------------------------+----------------------------------------------- Reporter: int-e | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Comment (by int-e): Replying to [comment:1 igloo]: > Ah, I think we actually want `TopHandler` to also try catching the old `Exception` type. I'll look into this, although I might leave it until after the base splitting has happened. I think we've already lost the game if the old `Exception` type ever gets thrown - then any library using the new exception mechanism will not recognize the exceptions. As far as I understand the new mechanism, implementing the full `Exception` class instance should take care of that - that's what my proposed patch does. (Hmm, by that reasoning, the {{{Caster (\e -> e)}}} can be safely removed from the list of attempted casts in said patch.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 11 03:53:48 2008 From: trac at galois.com (GHC) Date: Mon Aug 11 03:53:13 2008 Subject: [GHC] #2486: Code specialization regression in 6.8.3 In-Reply-To: <044.2aa9bce2a7a3fda66c24d4bd23fa1ccd@localhost> References: <044.2aa9bce2a7a3fda66c24d4bd23fa1ccd@localhost> Message-ID: <053.91b00779020bf7eb4bfc8ea83efc73ea@localhost> #2486: Code specialization regression in 6.8.3 --------------------------------------+------------------------------------- Reporter: dolio | Owner: simonpj Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | --------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown Comment: Absolutely right, thank you! I'm working on a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 11 04:00:27 2008 From: trac at galois.com (GHC) Date: Mon Aug 11 03:59:51 2008 Subject: [GHC] #2506: infix assert panics ghc In-Reply-To: <044.3043ed924f65ac215b3b93b6e6566455@localhost> References: <044.3043ed924f65ac215b3b93b6e6566455@localhost> Message-ID: <053.1f9ab05ed8661d6991ea0610029a424a@localhost> #2506: infix assert panics ghc ----------------------+----------------------------------------------------- Reporter: galen | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown Comment: Darn -- you're right. I am fixing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 11 04:29:23 2008 From: trac at galois.com (GHC) Date: Mon Aug 11 04:28:46 2008 Subject: [GHC] #2507: quotation characters in error messages In-Reply-To: <051.38b1ebfeec872e08862a450e1303ba1d@localhost> References: <051.38b1ebfeec872e08862a450e1303ba1d@localhost> Message-ID: <060.c70ec9ea734c497b6aed9dfbd46a7c8a@localhost> #2507: quotation characters in error messages -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: I avoid discussions involving the word "unicode". I'm certainly not in principle opposed to the change suggested above, although I worry a bit that it might give us a new portability headache. The comment I wanted to add is that the bracketing single-quotes in GHC's error message are (pretty much without exception I think) added by a single function, `Outputable.quotes`. So if someone figures out the details, actually making the change should be easy. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 11 07:08:31 2008 From: trac at galois.com (GHC) Date: Mon Aug 11 07:07:55 2008 Subject: [GHC] #2512: MAP_32BIT flag might not be respected under xen? Message-ID: <044.02579c65234b2e00edf9fbae992e571c@localhost> #2512: MAP_32BIT flag might not be respected under xen? -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: None Version: 6.8.3 | Severity: critical Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Here's the error I get when I try to run ghci 6.8.3 on Fedora 9. I also got the same error on ghc 6.8.2 with Fedora 9 and Ubuntu 8.0.4, all running x86_64 under xen. /ghc-6.8.3# ghci-6.8.3 GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help ghc-6.8.3: internal error: R_X86_64_32S relocation out of range: (noname) = 0x7ffc1dbd4fb8 (GHC version 6.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort ghci-6.8.3 An strace of the bug is attached, as well here's a link to a relevant problem: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/237724 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 11 07:58:48 2008 From: trac at galois.com (GHC) Date: Mon Aug 11 07:58:13 2008 Subject: [GHC] #2494: Panic in tcSimplifyRuleLhs In-Reply-To: <041.cc78c90da661d834f8200361ebf7eb74@localhost> References: <041.cc78c90da661d834f8200361ebf7eb74@localhost> Message-ID: <050.6e130fa7b69b60a4f994c1c67f162f38@localhost> #2494: Panic in tcSimplifyRuleLhs -----------------------------------------------------+---------------------- Reporter: rl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2494, T2494-2 | Architecture: Unknown Os: Unknown | -----------------------------------------------------+---------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T2494, T2494-2 * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Mon Aug 11 03:44:38 PDT 2008 simonpj@microsoft.com * Fix Trac #2494: tcSimplifyRuleLhs }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 11 08:00:44 2008 From: trac at galois.com (GHC) Date: Mon Aug 11 08:00:09 2008 Subject: [GHC] #2486: Code specialization regression in 6.8.3 In-Reply-To: <044.2aa9bce2a7a3fda66c24d4bd23fa1ccd@localhost> References: <044.2aa9bce2a7a3fda66c24d4bd23fa1ccd@localhost> Message-ID: <053.21abd01681382ceff50e0cd5988fadba@localhost> #2486: Code specialization regression in 6.8.3 ----------------------------------------+----------------------------------- Reporter: dolio | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: simplCore/should_run/T2486 | Architecture: x86_64 (amd64) Os: Linux | ----------------------------------------+----------------------------------- Changes (by simonpj): * testcase: => simplCore/should_run/T2486 * owner: simonpj => igloo * type: run-time performance bug => merge Comment: Fixed by {{{ Sat Aug 9 09:31:23 PDT 2008 simonpj@microsoft.com * Fix Trac #2486: restore the specialiser to a working state In improving the specialiser's data reprsentaion, thus Mon Apr 28 16:57:11 GMT Daylight Time 2008 simonpj@microsoft.com * Fix Trac #1969: perfomance bug in the specialiser I got the sense of a pair of filter functions back to front. As a result, almost all specialisation opportunities were being filtered out, and no specialisations were being generated. Fortunately, dolio noticed and reported Trac #2486. The fix is simple: put the filters the right way roud. }}} This one should be merged to 6.8.3 if we release that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 11 08:02:52 2008 From: trac at galois.com (GHC) Date: Mon Aug 11 08:02:16 2008 Subject: [GHC] #2506: infix assert panics ghc In-Reply-To: <044.3043ed924f65ac215b3b93b6e6566455@localhost> References: <044.3043ed924f65ac215b3b93b6e6566455@localhost> Message-ID: <053.336a2a83cd1cc2eb58b3faa1836daf8c@localhost> #2506: infix assert panics ghc -----------------------------------------+---------------------------------- Reporter: galen | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rename/should_compile/T2506 | Architecture: x86 Os: Linux | -----------------------------------------+---------------------------------- Changes (by simonpj): * testcase: => rename/should_compile/T2506 * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Mon Aug 11 03:50:11 PDT 2008 simonpj@microsoft.com * Fix Trac #2506: infix assert }}} This should merge into 6.8.3 if we release it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 11 08:05:40 2008 From: trac at galois.com (GHC) Date: Mon Aug 11 08:05:03 2008 Subject: [GHC] #2500: Unrecognised pragma complained about twice In-Reply-To: <046.9e9cf92de5daf74529e4e511f971313e@localhost> References: <046.9e9cf92de5daf74529e4e511f971313e@localhost> Message-ID: <055.febd70fdef0fa29168623041cbfb1119@localhost> #2500: Unrecognised pragma complained about twice ----------------------+----------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): * Could we not silently ignore unrecognised pragmas when searching for OPTIONS pragmas? * Would it be possible for the "Unrecognised pragma" message to say "Unrecognised pragma `FOO'"? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 11 08:11:07 2008 From: trac at galois.com (GHC) Date: Mon Aug 11 08:10:32 2008 Subject: [GHC] #2497: Weird scoping for tyvars in rules In-Reply-To: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> References: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> Message-ID: <050.87e0bed95ad0ff2f5a7ace8843afd741@localhost> #2497: Weird scoping for tyvars in rules ----------------------+----------------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): After talking to Simon, and Ian, and taking on board Roman's comments, I now propose: * Do '''not''' add `-XRewriteRules`. A RULE is in a pragma, and so is silently ignored by other compilers anyway. Other pragmas like SPECIALISE do not have a language extension flag. They will generate errors if they are plain wrong (e.g. variables out of scope). But adding a language flag would be inconsistent. * Inside a RULE, switch on the `forall`-as-keyword in the lexer, unconditionally. Simon M will do this, and send a patch to Simon PJ for validation. * Merge the `-XScopedTypeVariables` and `-XPatternSignatures` flags. Distinguishing them isn't senseless, but it's jolly confusing. * Inside a RULE, switch on `-XScopedTypeVariables` unconditionally. * Change `-frewrite-rules` to `-fuse-rewrite-rules`; deprecate the former. Any dissenters? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 11 09:36:32 2008 From: trac at galois.com (GHC) Date: Mon Aug 11 09:35:56 2008 Subject: [GHC] #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" In-Reply-To: <053.250fd8f3285636d4b0e7d255649c2b44@localhost> References: <053.250fd8f3285636d4b0e7d255649c2b44@localhost> Message-ID: <062.a0f492fa4f43abd00e81a74f0cce8589@localhost> #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonpj): * owner: => igloo Comment: Fixed by {{{ Mon Aug 11 13:25:23 BST 2008 simonpj@microsoft.com * Fix Trac #2412: type synonyms and hs-boot recursion }}} Ian: I'm not sure how to set up a testsuite test for this. Do you think you could do so? Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 04:58:39 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 05:04:31 2008 Subject: [GHC] #2391: Network.listenOn (PortNumber n) Sometimes Picks IPv6 In-Reply-To: <042.cebcc11cc6f8e024f65fef292f8041c0@localhost> References: <042.cebcc11cc6f8e024f65fef292f8041c0@localhost> Message-ID: <051.f72d2eb326497eb882f468efaf0d72cc@localhost> #2391: Network.listenOn (PortNumber n) Sometimes Picks IPv6 -------------------------------+-------------------------------------------- Reporter: cjs | Owner: bos Type: bug | Status: assigned Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Comment (by cjs): Actually, the linux code ''incorrectly'' binds to both; this opens up a security problem, though I can't remember the exact details right now. This is exactly the reason for the default sysctl setting of "net.inet6.ip6.v6only = 1", IIRC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 05:04:18 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 05:10:02 2008 Subject: [GHC] #2391: Network.listenOn (PortNumber n) Sometimes Picks IPv6 In-Reply-To: <042.cebcc11cc6f8e024f65fef292f8041c0@localhost> References: <042.cebcc11cc6f8e024f65fef292f8041c0@localhost> Message-ID: <051.70cc488e67f426f9cbae0b8d98e85ba9@localhost> #2391: Network.listenOn (PortNumber n) Sometimes Picks IPv6 -------------------------------+-------------------------------------------- Reporter: cjs | Owner: bos Type: bug | Status: assigned Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Comment (by cjs): Here is a document discussing the security issues with IPv4-mapped addresses: ftp://ftp.itojun.org/pub/paper/draft-itojun-v6ops-v4mapped- harmful-01.txt I'd say we definitely don't want to have to force people to enable this just to use Network, which is in the end supposed to make life simpler for basic networking. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 07:00:33 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 06:59:54 2008 Subject: [GHC] #2490: GHC allows sections with out parenthesis in tuples In-Reply-To: <049.41558d2f5e8f1685b5dfab51d362bd22@localhost> References: <049.41558d2f5e8f1685b5dfab51d362bd22@localhost> Message-ID: <058.94a5671561c300fed64bc637b94f568b@localhost> #2490: GHC allows sections with out parenthesis in tuples --------------------------------------+------------------------------------- Reporter: JeremyShaw | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rename/should_fail/T2490 | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => rename/should_fail/T2490 * difficulty: => Unknown * status: new => closed * resolution: => fixed Comment: Good point. I've fixed this {{{ Tue Aug 12 09:23:32 BST 2008 simonpj@microsoft.com * Fix Trac #2490: sections should be parenthesised }}} Thanks for a fine report. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 07:08:50 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 07:08:11 2008 Subject: [GHC] #2497: Weird scoping for tyvars in rules In-Reply-To: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> References: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> Message-ID: <050.d6ffe04d0f7f107b48fee81d7e92fd2f@localhost> #2497: Weird scoping for tyvars in rules ----------------------+----------------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by josef): On the whole I think your new set of proposed changes will make things much more intuitive, especially bullets two and four. I'm stumped by the status quo every time I try to use rewrite rules. As for bullet five, I'd prefer -fenable-rewrite-rules, simply because it has a more natural reverse: -fdisable-rewrite-rules. -fdon't-use-rewrite- rules doesn't feel quite right. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 07:12:23 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 07:11:57 2008 Subject: [GHC] #1802: proposal: fix comparison operations for base:Data.Version.Version In-Reply-To: <068.1dd21a3ede57ae11143c96353900b005@localhost> References: <068.1dd21a3ede57ae11143c96353900b005@localhost> Message-ID: <077.564ac8fdddf6543fc97a8316cbcb5463@localhost> #1802: proposal: fix comparison operations for base:Data.Version.Version -------------------------------------------+-------------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------------+-------------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): I'm still keen on it, but it did not receive much support from anyone else. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 09:31:13 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 09:30:35 2008 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.aaa69cfc2ee0aece1bc7246fc9611a2f@localhost> #1338: base package breakup ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by simonmar): Yes to pulling out concurrent, st, generics, getopt, and moving the Control.Applicative stuff into containers. The rest don't seem to buy us a great deal, and I'm concerned that we're ending up with a plethora of tiny packages. I'll commit the base3-compat stuff as soon as I can get it to validate on Windows, and then it'll need to be updated to reflect these changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 09:38:03 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 09:37:24 2008 Subject: [GHC] #2504: linkBCO: >= 64k insns in BCO In-Reply-To: <044.eb1814cf2ce1c6f8bbe30616e31fb749@localhost> References: <044.eb1814cf2ce1c6f8bbe30616e31fb749@localhost> Message-ID: <053.98b7613a5401e87ca784bfd108f88c26@localhost> #2504: linkBCO: >= 64k insns in BCO ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: duplicate of #789 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 09:38:17 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 09:37:38 2008 Subject: [GHC] #789: BCOs can only have 64k instructions In-Reply-To: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> References: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> Message-ID: <055.8b6468394af7a455c67e8228bdc07d2c@localhost> #789: BCOs can only have 64k instructions ---------------------+------------------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: BCO | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------+------------------------------------------------------ Comment (by simonmar): See also #2504, with an example program -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 10:17:17 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 10:16:37 2008 Subject: [GHC] #2367: ASSERT failed! file basicTypes/MkId.lhs line 643 In-Reply-To: <053.3399b2ac3a6fdeb953db1e5f9a9f109a@localhost> References: <053.3399b2ac3a6fdeb953db1e5f9a9f109a@localhost> Message-ID: <062.bf218b6d84fc15ae08abd1b2f024e509@localhost> #2367: ASSERT failed! file basicTypes/MkId.lhs line 643 ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: gadt/records | Architecture: Unknown Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by simonpj): * owner: => igloo * type: bug => merge Comment: This one is fixed by {{{ Mon Aug 11 13:35:26 BST 2008 simonpj@microsoft.com * Fix Trac #2367: selectors for GADTs }}} I've re-enabled these tests for a fast validate (I think). Merge this to 6.8 if we release it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 10:18:59 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 10:18:20 2008 Subject: [GHC] #2507: quotation characters in error messages In-Reply-To: <051.38b1ebfeec872e08862a450e1303ba1d@localhost> References: <051.38b1ebfeec872e08862a450e1303ba1d@localhost> Message-ID: <060.8c0ed96fd02b0fb9e41d632a7b4271b1@localhost> #2507: quotation characters in error messages -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * milestone: => 6.10 branch Comment: Yes, I also noticed that gcc now uses the correct single quote characters, because the font I'm using in my xterm doesn't have those glyphs so they appear as boxes :-) It is the right thing to do, but it needs to wait until at least we have locale encoding/decoding support in Handle I/O. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 10:42:58 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 10:42:18 2008 Subject: [GHC] #2357: Implement the Haskell' proposal for polymorphic pattern bindings In-Reply-To: <047.95a1ebaf86eb581f2f41f8ae61094ccc@localhost> References: <047.95a1ebaf86eb581f2f41f8ae61094ccc@localhost> Message-ID: <056.f82c4fbdbc458e5e2eec90e9b332cc95@localhost> #2357: Implement the Haskell' proposal for polymorphic pattern bindings -------------------------------------+-------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by simonpj): See also #2187 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 11:34:14 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 11:33:37 2008 Subject: [GHC] #2513: -fparr warning should be more clear Message-ID: <048.2f3761d98808d86da386fc5cb5b36ade@localhost> #2513: -fparr warning should be more clear --------------------------+------------------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------+------------------------------------------------- When compiling program which uses parallel arrays with {{{{-# OPTIONS -fparr #-}}}}, head GHC emits warning: {{{Warning: -fparr is deprecated: Use the PArr language instead}}}. The solution is to use {{{-XPArr}}} or {{{{-# LANGUAGE PArr #-}}}} instead, which is not evident from the warning message. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 13:27:23 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 13:26:50 2008 Subject: [GHC] #2391: Network.listenOn (PortNumber n) Sometimes Picks IPv6 In-Reply-To: <042.cebcc11cc6f8e024f65fef292f8041c0@localhost> References: <042.cebcc11cc6f8e024f65fef292f8041c0@localhost> Message-ID: <051.9b1e62bf96cbcaa23eec4df7d31eeb76@localhost> #2391: Network.listenOn (PortNumber n) Sometimes Picks IPv6 -------------------------------+-------------------------------------------- Reporter: cjs | Owner: bos Type: bug | Status: assigned Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Comment (by bos): The Linux behaviour does not appear to me to be incorrect, and the document to which you refer is concerned with threats due to the use of IPv4-mapped addresses on the wire. The code in the Network module uses the Network.Socket code for its implementation. There are currently several knobs for controlling getAddrInfo that it does not use. Perhaps if you read up on a few of them and try them out, you might find a behaviour that you could then propose as more desirable. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 15:34:11 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 15:33:31 2008 Subject: [GHC] #1628: warning(s) for using stolen syntax that's not currently enabled In-Reply-To: <051.b704d0b5c5d106d49d23c23dfe91776c@localhost> References: <051.b704d0b5c5d106d49d23c23dfe91776c@localhost> Message-ID: <060.58b058077e57eca30366341c7562ce68@localhost> #1628: warning(s) for using stolen syntax that's not currently enabled -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by Isaac Dupree): * cc: id@isaac.cedarswampstudios.org (added) Comment: Not a priority for me, but I'd still like to see this sometime. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 15:47:19 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 15:46:40 2008 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> Message-ID: <060.db78ba55035690fcd5c65528e665b7f0@localhost> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by fons): * cc: alfonso.acosta@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 17:37:50 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 17:37:09 2008 Subject: [GHC] #2514: Add/Expose Binary API that allows dumping of any GHC Binary instance Message-ID: <047.57cf723e547f8e60541f4f12c39c26fa@localhost> #2514: Add/Expose Binary API that allows dumping of any GHC Binary instance --------------------------------+------------------------------------------- Reporter: nominolo | Owner: nominolo Type: feature request | Status: new Priority: normal | Component: GHC API Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Serialising Names requires that a symbol table is being provided in the BinHandle so that a string can be mapped to an index in the symbol table. API clients like Haddock need this so they can use all Binary instances of GHC data types. Whether a symbol table is provided or not is best reflected in the type (using phantom types / type labels). For example: {{{ data Put symtab a = ... data Symtab instance Monad (Put b) where ... instance Put a Foo where ... instance Put Symtab Name where ... runPut :: ... -> Put () a -> IO a putWithSymtable :: ... -> Put Symtab a -> IO a }}} Similarly for a Get monad (feature suggested by David Waern) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 17:43:08 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 17:42:26 2008 Subject: [GHC] #2514: Add/Expose Binary API that allows dumping of any GHC Binary instance In-Reply-To: <047.57cf723e547f8e60541f4f12c39c26fa@localhost> References: <047.57cf723e547f8e60541f4f12c39c26fa@localhost> Message-ID: <056.550d90dd0005fb18e96e202a198886be@localhost> #2514: Add/Expose Binary API that allows dumping of any GHC Binary instance --------------------------------+------------------------------------------- Reporter: nominolo | Owner: nominolo Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Comment (by nominolo): {{{putWithSymtable}}} would automatically {{{put}}} the symbol table after or before the output of the inner {{{Put}}} action. (I don't know exactly how it is handled in iface/BinIface.hs) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 12 18:03:24 2008 From: trac at galois.com (GHC) Date: Tue Aug 12 18:02:44 2008 Subject: [GHC] #2514: Add/Expose Binary API that allows dumping of any GHC Binary instance In-Reply-To: <047.57cf723e547f8e60541f4f12c39c26fa@localhost> References: <047.57cf723e547f8e60541f4f12c39c26fa@localhost> Message-ID: <056.ca585e8d15d1d0de074443e54c5cf6fa@localhost> #2514: Add/Expose Binary API that allows dumping of any GHC Binary instance --------------------------------+------------------------------------------- Reporter: nominolo | Owner: nominolo Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Changes (by waern): * cc: david.waern@gmail.com (added) Comment: ...you would also need the dictionary for storing FastStrings. But anyway: I think this is an important thing to get into 6.10.1, since a lot of applications will want to store GHC's data types in its own files, without having to duplicate the readBinIface / writeBinIface machinery, which is what Haddock currently does. Besides being ugly, the code I had copied from GHC doesn't work anymore with GHC 6.9, due to changes in the Binary module. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 03:30:48 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 03:30:06 2008 Subject: [GHC] #1628: warning(s) for using stolen syntax that's not currently enabled In-Reply-To: <051.b704d0b5c5d106d49d23c23dfe91776c@localhost> References: <051.b704d0b5c5d106d49d23c23dfe91776c@localhost> Message-ID: <060.05825264c69bb644c335f7dbc07e33db@localhost> #1628: warning(s) for using stolen syntax that's not currently enabled -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonpj): * priority: normal => low * milestone: 6.10 branch => _|_ Comment: It's not clear what you mean here: * Warn about things that work fine with `-XExtension`, but which mean something different (or perhaps are an outright error) in Haskell 98. * Warn about things that are stolen by `-XExtension` but somehow aren't right, but would be acceptable in Haskel 98 without `-XExtension`. Whichever of these you mean, it looks extremely difficult to implement. For that reason I'm moving it off the 6.10 branch. If I've misunderstood, by all means respond. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 04:51:07 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 04:50:25 2008 Subject: [GHC] #2513: Bad location info for flag warnings In-Reply-To: <048.2f3761d98808d86da386fc5cb5b36ade@localhost> References: <048.2f3761d98808d86da386fc5cb5b36ade@localhost> Message-ID: <057.7704f23ad2f6b1d809a91c01559c178a@localhost> #2513: Bad location info for flag warnings -----------------------+---------------------------------------------------- Reporter: Feuerbach | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------+---------------------------------------------------- Changes (by simonpj): * owner: => igloo * difficulty: => Unknown * summary: -fparr warning should be more clear => Bad location info for flag warnings Comment: Good point. I've done the easy bit, to make it say {{{ : Warning: -fparr is deprecated: Use -XPArr or pragma {-# LANGUAGE PArr#-} instead }}} But it's still wrong that it says "". Better to give the file name, or even, I suppose, "". Ian, you did the plumbing here, perhaps you can think about improving this? I'll retitle it Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 07:33:36 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 07:32:55 2008 Subject: [GHC] #2426: ghc-pkg should treat package.conf as UTF8 In-Reply-To: <044.52bda3c925309f2ed287ef35b894919b@localhost> References: <044.52bda3c925309f2ed287ef35b894919b@localhost> Message-ID: <053.929651db708d49651dce5aaf50c84896@localhost> #2426: ghc-pkg should treat package.conf as UTF8 ----------------------+----------------------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 07:34:12 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 07:33:29 2008 Subject: [GHC] #1963: Pressing ^C at the right moment can trash GHC's package list In-Reply-To: <044.fe68034f1a304106efaa8e4a323fded8@localhost> References: <044.fe68034f1a304106efaa8e4a323fded8@localhost> Message-ID: <053.12e046b10a89b248edafb5b641f5cf32@localhost> #1963: Pressing ^C at the right moment can trash GHC's package list ----------------------+----------------------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 07:35:14 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 07:34:32 2008 Subject: [GHC] #2491: ghc-pkg unregister should complain about breaking dependent packages In-Reply-To: <045.cb2eb75581a4ebbb8a9616da61bf4689@localhost> References: <045.cb2eb75581a4ebbb8a9616da61bf4689@localhost> Message-ID: <054.6b71895a7a057269aa04006349c79d96@localhost> #2491: ghc-pkg unregister should complain about breaking dependent packages -----------------------------+---------------------------------------------- Reporter: duncan | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 10:36:09 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 10:35:27 2008 Subject: [GHC] #2330: ghc-pkg should not report duplicate depends In-Reply-To: <045.a0d888b36f9d7b158756f697bfe898a1@localhost> References: <045.a0d888b36f9d7b158756f697bfe898a1@localhost> Message-ID: <054.3df4318d0689da5c6b6d3c3973fdde81@localhost> #2330: ghc-pkg should not report duplicate depends ----------------------+----------------------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 10:36:17 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 10:35:34 2008 Subject: [GHC] #2298: renameFile is not atomic on Windows In-Reply-To: <045.dd0669cd71e65d3d8109c8cabde31cb6@localhost> References: <045.dd0669cd71e65d3d8109c8cabde31cb6@localhost> Message-ID: <054.1471ca6106af73c94ade2f5da871f330@localhost> #2298: renameFile is not atomic on Windows ----------------------------+----------------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 10:39:21 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 10:38:38 2008 Subject: [GHC] #2441: Ghc-pkg cannot unregister/expose/hide packages in non-first package databases In-Reply-To: <053.1e7052fd8e6f933efbd3d50f72491d93@localhost> References: <053.1e7052fd8e6f933efbd3d50f72491d93@localhost> Message-ID: <062.c2e0a37766f9eb1d7c383d1962217f4b@localhost> #2441: Ghc-pkg cannot unregister/expose/hide packages in non-first package databases ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 10:41:42 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 10:41:12 2008 Subject: [GHC] #1802: proposal: fix comparison operations for base:Data.Version.Version In-Reply-To: <068.1dd21a3ede57ae11143c96353900b005@localhost> References: <068.1dd21a3ede57ae11143c96353900b005@localhost> Message-ID: <077.a91843e22ec4067430a62f21d9c9492e@localhost> #1802: proposal: fix comparison operations for base:Data.Version.Version -------------------------------------------+-------------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------------+-------------------------------- Comment (by igloo): If everyone else was just silent then "silence during the discussion period can be interpreted as consent". However, you need to "Add to the ticket a summary of the relevant parts of the discussion" and "If consensus was achieved, ![...] commit it". Please see http://www.haskell.org/haskellwiki/Library_submissions for more details. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 12:39:10 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 12:38:41 2008 Subject: [GHC] #1802: proposal: fix comparison operations for base:Data.Version.Version In-Reply-To: <068.1dd21a3ede57ae11143c96353900b005@localhost> References: <068.1dd21a3ede57ae11143c96353900b005@localhost> Message-ID: <077.0ca4660ffb27d75f5c962bd098cf9229@localhost> #1802: proposal: fix comparison operations for base:Data.Version.Version -------------------------------------------+-------------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------------+-------------------------------- Comment (by guest): (From Adrian Hey) I think it scarcely matters as the Eq/Ord instances are broken with or without this change (and should be deleted IMO). See ticket:2496 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 12:56:46 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 12:56:15 2008 Subject: [GHC] #1802: proposal: fix comparison operations for base:Data.Version.Version In-Reply-To: <068.1dd21a3ede57ae11143c96353900b005@localhost> References: <068.1dd21a3ede57ae11143c96353900b005@localhost> Message-ID: <077.37a38ab1d1f4fb14e503fda80ea18a9e@localhost> #1802: proposal: fix comparison operations for base:Data.Version.Version -------------------------------------------+-------------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------------+-------------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): The discussion back in October 2007 was short - it begins here: http://www.haskell.org/pipermail/libraries/2007-October/008472.html There were no strong opinions in either direction. Some people thought we should consider negative components of the version sequence, but that is totally crazy. If only Haskell had true Naturals! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 17:42:50 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 17:42:05 2008 Subject: [GHC] #2483: mapException type under extensible exceptions In-Reply-To: <051.38739bb0dd93087fbe6409fe08ce9466@localhost> References: <051.38739bb0dd93087fbe6409fe08ce9466@localhost> Message-ID: <060.9e013c23270dbd5f25eb62bf4f11c4ca@localhost> #2483: mapException type under extensible exceptions ----------------------------+----------------------------------------------- Reporter: Isaac Dupree | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Done! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 17:46:05 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 17:45:21 2008 Subject: [GHC] #2486: Code specialization regression in 6.8.3 In-Reply-To: <044.2aa9bce2a7a3fda66c24d4bd23fa1ccd@localhost> References: <044.2aa9bce2a7a3fda66c24d4bd23fa1ccd@localhost> Message-ID: <053.6aaa1a8699ca05e669cdaff75309353a@localhost> #2486: Code specialization regression in 6.8.3 ----------------------------------------+----------------------------------- Reporter: dolio | Owner: Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: simplCore/should_run/T2486 | Architecture: x86_64 (amd64) Os: Linux | ----------------------------------------+----------------------------------- Changes (by igloo): * owner: igloo => * milestone: => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 17:46:17 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 17:45:33 2008 Subject: [GHC] #2506: infix assert panics ghc In-Reply-To: <044.3043ed924f65ac215b3b93b6e6566455@localhost> References: <044.3043ed924f65ac215b3b93b6e6566455@localhost> Message-ID: <053.f693d0837c1da19cd82e3ef458b1a998@localhost> #2506: infix assert panics ghc -----------------------------------------+---------------------------------- Reporter: galen | Owner: Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rename/should_compile/T2506 | Architecture: x86 Os: Linux | -----------------------------------------+---------------------------------- Changes (by igloo): * owner: igloo => * milestone: => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 17:46:50 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 17:46:07 2008 Subject: [GHC] #2433: standalone deriving Typeable shouldn't need data constructors in scope? In-Reply-To: <044.c3db89885eba9cc62656744d598e567c@localhost> References: <044.c3db89885eba9cc62656744d598e567c@localhost> Message-ID: <053.74d70c44bedfe83cd5078932f0efb49f@localhost> #2433: standalone deriving Typeable shouldn't need data constructors in scope? --------------------------------------------+------------------------------- Reporter: claus | Owner: Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2433 | Architecture: Unknown Os: Unknown | --------------------------------------------+------------------------------- Changes (by igloo): * owner: igloo => * milestone: 6.10.1 => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 18:14:44 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 18:14:01 2008 Subject: [GHC] #2367: ASSERT failed! file basicTypes/MkId.lhs line 643 In-Reply-To: <053.3399b2ac3a6fdeb953db1e5f9a9f109a@localhost> References: <053.3399b2ac3a6fdeb953db1e5f9a9f109a@localhost> Message-ID: <062.d3c3f045d3882d8e6dc8f774bb7d2726@localhost> #2367: ASSERT failed! file basicTypes/MkId.lhs line 643 ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: gadt/records | Architecture: Unknown Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: igloo => * milestone: 6.10.1 => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 18:15:11 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 18:14:31 2008 Subject: [GHC] #2515: Flag to suppress orphan instance warnings Message-ID: <042.4664e49fbb66d0162bc19b3088fe61ba@localhost> #2515: Flag to suppress orphan instance warnings --------------------------------+------------------------------------------- Reporter: tim | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: trivial Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Since everyone is all abuzz about orphan instances: can we have a flag to disable orphan instance warnings? {{{-fno-warn-orphan-instances}}} apparently doesn't exist. It's not a big deal, but I don't care about the warnings and would rather not expend brain cycles on ignoring them. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 18:25:35 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 18:24:54 2008 Subject: [GHC] #2515: Flag to suppress orphan instance warnings In-Reply-To: <042.4664e49fbb66d0162bc19b3088fe61ba@localhost> References: <042.4664e49fbb66d0162bc19b3088fe61ba@localhost> Message-ID: <051.a3e6aa1b380ff35a24b96f7fb3f6bdc6@localhost> #2515: Flag to suppress orphan instance warnings --------------------------------+------------------------------------------- Reporter: tim | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: trivial | Resolution: worksforme Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Changes (by duncan): * status: new => closed * resolution: => worksforme Comment: You're in luck, `-fno-warn-orphans` already exists! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 19:20:38 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 19:20:02 2008 Subject: [GHC] #2515: Flag to suppress orphan instance warnings In-Reply-To: <042.4664e49fbb66d0162bc19b3088fe61ba@localhost> References: <042.4664e49fbb66d0162bc19b3088fe61ba@localhost> Message-ID: <051.833bb7db285f2fc9eb51356900d8ff96@localhost> #2515: Flag to suppress orphan instance warnings ------------------------------+--------------------------------------------- Reporter: tim | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: trivial | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------------+--------------------------------------------- Changes (by tim): * status: closed => reopened * component: Compiler => Documentation * resolution: worksforme => * type: feature request => bug Comment: Thanks -- serves me right for not reading the manual. However, there's still a documentation problem: Section 5.6.12 of the users' guide mentions the flag {{{-fwarn-orphan-modules}}}, which doesn't seem to exist. I'm not sure whether that's supposed to mean the same thing as {{{-fwarn- orphans}}}, but in any case, that should be fixed. (I would fix it myself if all of my source trees weren't currently hosed.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 19:32:33 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 19:31:54 2008 Subject: [GHC] #2515: Flag to suppress orphan instance warnings In-Reply-To: <042.4664e49fbb66d0162bc19b3088fe61ba@localhost> References: <042.4664e49fbb66d0162bc19b3088fe61ba@localhost> Message-ID: <051.0708bef35206e1378626b3498a23e65c@localhost> #2515: Flag to suppress orphan instance warnings -------------------------+-------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: trivial | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Changes (by tim): * component: Documentation => Compiler Comment: I take it back: {{{-fno-warn-orphans}}} seems to be silently ignored (if I pass it, I still see the orphan warning messages), so that should be fixed too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 20:21:02 2008 From: trac at galois.com (GHC) Date: Wed Aug 13 20:20:21 2008 Subject: [GHC] #2515: Flag to suppress orphan instance warnings In-Reply-To: <042.4664e49fbb66d0162bc19b3088fe61ba@localhost> References: <042.4664e49fbb66d0162bc19b3088fe61ba@localhost> Message-ID: <051.d3cc121fe12d910cb107b4578b94f77c@localhost> #2515: Flag to suppress orphan instance warnings -------------------------+-------------------------------------------------- Reporter: tim | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: trivial | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Comment (by duncan): Replying to [comment:3 tim]: > I take it back: {{{-fno-warn-orphans}}} seems to be silently ignored (if I pass it, I still see the orphan warning messages), so that should be fixed too. Hmm, that's interesting, it works for me in 6.8.2, both when specified on the ghc command line and in a pragma `{-# OPTIONS_GHC -fno-warn-orphans #-}`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 08:56:33 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 08:55:53 2008 Subject: [GHC] #2491: ghc-pkg unregister should complain about breaking dependent packages In-Reply-To: <045.cb2eb75581a4ebbb8a9616da61bf4689@localhost> References: <045.cb2eb75581a4ebbb8a9616da61bf4689@localhost> Message-ID: <054.412be4e8efb7c4c0c76464623bce9907@localhost> #2491: ghc-pkg unregister should complain about breaking dependent packages -----------------------------+---------------------------------------------- Reporter: duncan | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Wed Aug 13 15:25:55 BST 2008 Simon Marlow * FIX #2491 (ghc-pkg unregister should complain about breaking dependent packages) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 08:57:06 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 08:56:25 2008 Subject: [GHC] #2492: ghc-pkg insists on having HOME environment variable set In-Reply-To: <045.533f5b01d030726f747ccf757a3c72f8@localhost> References: <045.533f5b01d030726f747ccf757a3c72f8@localhost> Message-ID: <054.16b27e66a984669ad2cbbebf3375bc29@localhost> #2492: ghc-pkg insists on having HOME environment variable set ----------------------+----------------------------------------------------- Reporter: gnezdo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Fixed: {{{ Wed Aug 13 15:34:36 BST 2008 Simon Marlow * FIX #2492: ghc-pkg insists on having HOME environment variable set }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 08:57:36 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 08:56:50 2008 Subject: [GHC] #1963: Pressing ^C at the right moment can trash GHC's package list In-Reply-To: <044.fe68034f1a304106efaa8e4a323fded8@localhost> References: <044.fe68034f1a304106efaa8e4a323fded8@localhost> Message-ID: <053.b8a8f76c59cc36988d0cd669d6b7ae7b@localhost> #1963: Pressing ^C at the right moment can trash GHC's package list ----------------------+----------------------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Wed Aug 13 15:37:38 BST 2008 Simon Marlow * FIX #1963: use Cabal's writeFileAtomic to write the new package.conf This depends on #2298 also being fixed, which I'll do shortly }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 08:59:06 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 08:58:24 2008 Subject: [GHC] #2441: Ghc-pkg cannot unregister/expose/hide packages in non-first package databases In-Reply-To: <053.1e7052fd8e6f933efbd3d50f72491d93@localhost> References: <053.1e7052fd8e6f933efbd3d50f72491d93@localhost> Message-ID: <062.2a3cb40b5f8c482a51e1fd343fa13b1d@localhost> #2441: Ghc-pkg cannot unregister/expose/hide packages in non-first package databases ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed. I modified the submitted patch to do the right thing, and fixed up some other bogosity that I found along the way. Also I added a test to the testsuite. {{{ Thu Aug 14 13:53:48 BST 2008 Simon Marlow * Fix #2441 (unregister/expose/hide packages in non-first package databases) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 08:47:34 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 09:04:55 2008 Subject: [GHC] #2498: RULES pragma broken in the head In-Reply-To: <041.31ecd942feb0616590c88e5b3074c464@localhost> References: <041.31ecd942feb0616590c88e5b3074c464@localhost> Message-ID: <050.af3a2577a1b496fc19976eff7745a84e@localhost> #2498: RULES pragma broken in the head ----------------------+----------------------------------------------------- Reporter: rl | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => duplicate Comment: #2497 and #2500 now cover these points. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 08:19:25 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 09:04:59 2008 Subject: [GHC] #2426: ghc-pkg should treat package.conf as UTF8 In-Reply-To: <044.52bda3c925309f2ed287ef35b894919b@localhost> References: <044.52bda3c925309f2ed287ef35b894919b@localhost> Message-ID: <053.f19cbfc1c50ccf07d1e2cd17458d6b4e@localhost> #2426: ghc-pkg should treat package.conf as UTF8 ----------------------+----------------------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: We're not going to do this: after discussing this with Duncan it was decided that we should be using the locale encoding for the input file to 'ghc-pkg register' (also stdin), which will happen when we've implemented locale encodings in the I/O library. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 03:57:28 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 09:05:11 2008 Subject: [GHC] #2477: -package-conf flag makes runghc fail In-Reply-To: <043.3badf8aec8b2932c76550c9b14657312@localhost> References: <043.3badf8aec8b2932c76550c9b14657312@localhost> Message-ID: <052.cce4cc863fdcb33817f3434292ed0390@localhost> #2477: -package-conf flag makes runghc fail ---------------------------+------------------------------------------------ Reporter: fons | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by cjs): * status: closed => reopened * component: Compiler => Documentation * version: 6.8.2 => 6.8.3 * resolution: invalid => * severity: normal => minor Comment: This flag is not documented in section 4 of the ghc manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 13 21:50:49 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 09:05:27 2008 Subject: [GHC] #2515: Flag to suppress orphan instance warnings In-Reply-To: <042.4664e49fbb66d0162bc19b3088fe61ba@localhost> References: <042.4664e49fbb66d0162bc19b3088fe61ba@localhost> Message-ID: <051.e106f6be93c7921c66956733ada0b878@localhost> #2515: Flag to suppress orphan instance warnings ------------------------------+--------------------------------------------- Reporter: tim | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: trivial | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------------+--------------------------------------------- Changes (by tim): * component: Compiler => Documentation Comment: Replying to [comment:4 duncan]: > Replying to [comment:3 tim]: > > I take it back: {{{-fno-warn-orphans}}} seems to be silently ignored (if I pass it, I still see the orphan warning messages), so that should be fixed too. > > Hmm, that's interesting, it works for me in 6.8.2, both when specified on the ghc command line and in a pragma `{-# OPTIONS_GHC -fno-warn-orphans #-}`. I realized my problem -- I had an OPTIONS_GHC pragma in the module I was compiling, which included {{{-Wall}}}, and was giving {{{-fno-warn- orphans}}} on the command line, so {{{-Wall}}} was overriding {{{-fno- warn-orphans}}}. I find this a little confusing, but I guess it must be documented somewhere. Anyway, my "...still a documentation problem" comment still applies. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 09:06:47 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 09:06:00 2008 Subject: [GHC] #2516: Panic in typechecker when checking rules Message-ID: <044.97a677f639e2eedc3bb7f676ec672915@localhost> #2516: Panic in typechecker when checking rules -----------------------+---------------------------------------------------- Reporter: josef | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- GHC will panic when given either of the following modules. The error messages are somewhat different for the two different rules. {{{ module GHCBug1 where foo :: (forall a . a -> f a) -> f Int foo f = f undefined {-# RULES "bug1" forall (g :: a -> f a) . head (foo g) = undefined #-} }}} {{{ module GHCBug2 where foo :: (forall a . a -> f a) -> f Int foo f = f undefined {-# RULES "bug2" forall (g :: forall a . a -> f a) . head (foo g) = undefined #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 11:18:44 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 11:17:59 2008 Subject: [GHC] #1628: warning(s) for using stolen syntax that's not currently enabled In-Reply-To: <051.b704d0b5c5d106d49d23c23dfe91776c@localhost> References: <051.b704d0b5c5d106d49d23c23dfe91776c@localhost> Message-ID: <060.99254372d1c75c446b76d895c8c2120c@localhost> #1628: warning(s) for using stolen syntax that's not currently enabled -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by Isaac Dupree): I meant, when your code doesn't have `-XExtension` enabled, warn when the enabling of `-XExtension` would change/break the meaning of your code (at least on the lexical level). You're probably right that it's difficult to implement --> milestone `_|_`. I suppose could involve running the lexer twice with different flags and seeing if the results are the same. Maybe something more reasonable for a GHC API client to do?.. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 11:26:18 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 11:25:39 2008 Subject: [GHC] #2515: Flag to suppress orphan instance warnings In-Reply-To: <042.4664e49fbb66d0162bc19b3088fe61ba@localhost> References: <042.4664e49fbb66d0162bc19b3088fe61ba@localhost> Message-ID: <051.52bc422443f9cb8b7343946e6b9f0847@localhost> #2515: Flag to suppress orphan instance warnings ---------------------------+------------------------------------------------ Reporter: tim | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by simonpj): * status: reopened => closed * difficulty: => Unknown * resolution: => fixed Comment: Right, good point. I've fixed the docs; pushing shortly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 12:29:29 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 12:28:43 2008 Subject: [GHC] #2461: add Traversable generalizations of mapAccumL and mapAccumR In-Reply-To: <043.013a273f6f1f47f6080e2f3a0bdc3cdd@localhost> References: <043.013a273f6f1f47f6080e2f3a0bdc3cdd@localhost> Message-ID: <052.5c42ed4f8441348837d7b90d54b2bfc9@localhost> #2461: add Traversable generalizations of mapAccumL and mapAccumR -------------------------------+-------------------------------------------- Reporter: ross | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: Severity: normal | Resolution: fixed Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Changes (by ross): * status: new => closed * resolution: => fixed Comment: There was limited discussion (with a large sidetrack on <**>). A few in favour, no dissent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 13:21:34 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 13:20:55 2008 Subject: [GHC] #2093: getSymbolicLinkStatus (and possibly other functions) broken on systems with large file system support In-Reply-To: <049.6b21dc8703db26b4a3f8f2aed151d2af@localhost> References: <049.6b21dc8703db26b4a3f8f2aed151d2af@localhost> Message-ID: <058.e8cc99f8d5558f91bff00cbd7657e551@localhost> #2093: getSymbolicLinkStatus (and possibly other functions) broken on systems with large file system support ----------------------------+----------------------------------------------- Reporter: JeremyShaw | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: libraries/unix | Version: 6.8.2 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by guest): * cc: gwern0@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 14:41:47 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 14:41:00 2008 Subject: [GHC] #2510: Environment modification during installation should be optional In-Reply-To: <045.3e84f679ca4e95a8a9ec350bbb64b495@localhost> References: <045.3e84f679ca4e95a8a9ec350bbb64b495@localhost> Message-ID: <054.c18ab1e2e3f2a53c9dcdafd5b38b0d1d@localhost> #2510: Environment modification during installation should be optional --------------------------------+------------------------------------------- Reporter: nimnul | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Windows --------------------------------+------------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) * os: Unknown => Windows Comment: Agreed, it should be a checkbox. I'll do this, if no one else does, but not before the 6.10 timeframe. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 14:43:08 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 14:42:24 2008 Subject: [GHC] #2513: Bad location info for flag warnings In-Reply-To: <048.2f3761d98808d86da386fc5cb5b36ade@localhost> References: <048.2f3761d98808d86da386fc5cb5b36ade@localhost> Message-ID: <057.cc87409674245a01e03e5ff4b3180280@localhost> #2513: Bad location info for flag warnings -----------------------+---------------------------------------------------- Reporter: Feuerbach | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------+---------------------------------------------------- Comment (by duncan): Additionally, as I understand it, the `PArr` extension still needs renaming. I was told to hold off adding it to `Language.Haskell.Extension` because it was not ready yet and the name of the extension was going to be changed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 14:47:51 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 14:47:05 2008 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM In-Reply-To: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> References: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> Message-ID: <054.b17f55dc371823d15b8f81d536d42261@localhost> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM -----------------------------+---------------------------------------------- Reporter: nimnul | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -----------------------------+---------------------------------------------- Changes (by NeilMitchell): * os: Unknown => Windows * type: bug => feature request Comment: You can put keys in either HKLM (local to the machine) or HKCU (local to the current user). I think for some purposes they get unioned together. Often Windows app's offer to install either globally or locally, so this is something we could provide. However, in some cases, we need admin access to do HKLM which is why we picked HKCU - partly this is because me and Duncan don't have admin access on our work machines. As for Claus's comment that you should be able to stop it, this doesn't seem to offer many benefits, and isn't something that is done by any other installers. What would be the use case? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 16:19:04 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 16:18:17 2008 Subject: [GHC] #2456: Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." In-Reply-To: <046.de0b35ad5d95f2dbcea756cdc13c675e@localhost> References: <046.de0b35ad5d95f2dbcea756cdc13c675e@localhost> Message-ID: <055.85812d604aa7e57d8c6dca9b1fed5173@localhost> #2456: Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." -------------------------+-------------------------------------------------- Reporter: ronwalf | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- Changes (by ronwalf): * status: closed => reopened * resolution: fixed => Comment: I can reproduce this bug with a slightly different file with $ ghc-6.9.20080730 --version The Glorious Glasgow Haskell Compilation System, version 6.9.20080730 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 16:23:53 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 16:23:05 2008 Subject: [GHC] #2456: Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." In-Reply-To: <046.de0b35ad5d95f2dbcea756cdc13c675e@localhost> References: <046.de0b35ad5d95f2dbcea756cdc13c675e@localhost> Message-ID: <055.63081e9354f2ed5eddfeda2791aca910@localhost> #2456: Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." -------------------------+-------------------------------------------------- Reporter: ronwalf | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- Changes (by batterseapower): * version: 6.8.3 => 6.9 Comment: Replying to [comment:2 ronwalf]: > I can reproduce this bug with a slightly different file with > $ ghc-6.9.20080730 --version > The Glorious Glasgow Haskell Compilation System, version 6.9.20080730 I can also confirm WouterTest2 still exhibits this problem as of 6.9.20080813. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 16:53:53 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 16:53:07 2008 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM In-Reply-To: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> References: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> Message-ID: <054.31bcc334d8392c42f9a9402c23503555@localhost> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM -----------------------------+---------------------------------------------- Reporter: nimnul | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -----------------------------+---------------------------------------------- Comment (by nimnul): HKLM and HKCU are completely separate registry subtrees. HKCU/Software and HKLM/Software never get unioned together. HKLM is always read only for non-admins, just like /etc/ on Unix, not "in some cases". Applications not just "often" offer both per-user and per-machine installations - it's an industrial standard, a commonly agreed good practice, described in MSDN. Moreover, if a program doesn't support to choose between per-user and per-machine installation, it is assumed that the program will be installed per-machine. So if GHC installs per-user, it should notify about such unusual and unexpected behaviour using big red letters. The lack of such notification is definitely a bug, the lack of per-machine installation is a feature. What do you mean by "isn't done by any other installers?" You can hardly find a program without a possbility to install per-machine. The registry modification is never optional, but the environment modification is optional in any decent installer. Quality installers do support a choice between per-machine and per-usual installation, there is even a de facto standard for the dialog, and there are such things as administrative installation, silent installation, domain-wide GPO installation, advertisement, which is a good idea to support. I don't see the use case for optional registry modification, but I do for optional environment modification and per machine installations. Which use case did you want to see? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 18:03:25 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 18:02:38 2008 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM In-Reply-To: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> References: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> Message-ID: <054.20536aa645e953d55ccb4dbe5bc6c54a@localhost> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM ---------------------+------------------------------------------------------ Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Changes (by NeilMitchell): * type: feature request => bug Comment: I am sure some API for registry will use HKCU in preference and fall back to HKLM - although I can't remember which API, or even which language - that is all I meant by unioned. I am quite happy to believe that having options to install per user and per machine is good, and my reclassification as "feature" rather than "bug" was intended to indicate that what is there currently works, but some people want more - not that what you want is unreasonable. However, since it really actually doesn't matter, I've changed it back to bug :-) With the final comment, asking for a use case, or other installers, I was referring only to Claus's suggestion of having an optional "put nothing in the registry". In summary I think I agree with you 100% but am not sure about the extra bit of "don't touch my registry" that Claus wanted. However, if there is a use case, its easy enough to add in. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 18:39:30 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 18:38:43 2008 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM In-Reply-To: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> References: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> Message-ID: <054.02c3e04ec4b3641b825b964cdf43f6be@localhost> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM ---------------------+------------------------------------------------------ Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Comment (by claus): Replying to [comment:6 NeilMitchell]: > In summary I think I agree with you 100% but am not sure about the extra bit of "don't touch my registry" that Claus wanted. However, if there is a use case, its easy enough to add in. My "use case" is simply that installers are terribly easy to get wrong, and even if they do things right, they often regress later, or they do not cooperate with other Haskell installers, simply because making them is a job nobody wants (which is why I appreciate Sigbjorn's and your efforts in this area). I have been bitten so often by this in Haskell land, and in so many different ways (#916 has a very small selection of examples), that I switched to using binary snapshots instead of installers; and now I automatically ask for everything to be optional, so I can switch off anything I don't like!-) '''If''' we get our daily binary snapshots back, and you address the individual installer actions as options, including #2505, and the ghc installer agrees with any upcoming Haskell Platform installer (and you are probably also in a good position to coordinate with Neil on WinHugs, #916;-), then there is probably no real need for a separate "just unpack my binary" installer. But if your installer does not support this option, chances are it has built-in assumptions that will bite me later; so consider it a quality measure rather than a use case!-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 14 19:11:39 2008 From: trac at galois.com (GHC) Date: Thu Aug 14 19:10:52 2008 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM In-Reply-To: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> References: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> Message-ID: <054.1b8cb93baefdb35756448a56411084f1@localhost> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM ---------------------+------------------------------------------------------ Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Comment (by NeilMitchell): nimnul: I remembered why I was thinking of unioned bits of registries. To compute file type associations, Windows looks in both HKCU and HKLM. claus: That does sound like a sensible use case, so the option does deserve to be added. I'm not going to be even looking at the GHC installer issues for months at least, but I've listed the ones I will tackle in this bug: http://code.google.com/p/ndmitchell/issues/detail?id=55. If anyone wants to shut any of those bugs before I get to them, I'm perfectly happy! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 07:59:50 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 07:59:03 2008 Subject: [GHC] #2505: windows installer should not hijack filetype associations! In-Reply-To: <044.a62339318202233961e8d0b3da109f64@localhost> References: <044.a62339318202233961e8d0b3da109f64@localhost> Message-ID: <053.72d5cff4d094aee375b6e921c982c6c8@localhost> #2505: windows installer should not hijack filetype associations! ------------------------+--------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Windows ------------------------+--------------------------------------------------- Comment (by claus): Thanks. For future reference, when its installer time again, here are some excerpts of what various haskell installers have done to my registry in terms of file associations. For starters, there seems to be no agreement about filetype, to the extent that not all windows tools know what is going on: {{{ $ cmd /c assoc .hs .hs=hs_auto_file $ cmd /c ftype hs_auto_file File type 'hs_auto_file' not found or no open command associated with it. $ cmd /c ftype ghc_haskell ghc_haskell="C:\ghc\ghc-6.8.3\bin\ghci.exe" "%1" $ cmd /c ftype hugs_haskell hugs_haskell="C:\Program Files\WinHugs\WinHugs.exe" "%1" }}} The `ghc_haskell` looks like the one I've tried to restore after ghc 6.8.3 installation (the information I get for `Haskell Source File` when editing filetypes via explorer `Tools->Folder Options`) {{{ $ reg query HKLM\\SOFTWARE\\Classes\\ghc_haskell /s ! REG.EXE VERSION 3.0 HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ghc_haskell REG_SZ Haskell Source File EditFlags REG_DWORD 0x0 BrowserFlags REG_DWORD 0x8 HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ghc_haskell\DefaultIcon REG_SZ C:\ghc\ghc-6.8.3\icons\hsicon.ico HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ghc_haskell\shell REG_SZ edit HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ghc_haskell\shell\edit HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ghc_haskell\shell\edit\command REG_SZ C:\vim\vim70\gvim.exe "%1" HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ghc_haskell\shell\open REG_SZ open with ghci 6.8.3 HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ghc_haskell\shell\open\command REG_SZ "C:\ghc\ghc-6.8.3\bin\ghci.exe" "%1" HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ghc_haskell\shell\open\ddeexec HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ghc_haskell\shell\open\ddeexec\Application REG_SZ ghci HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ghc_haskell\shell\open\ddeexec\Topic REG_SZ System HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ghc_haskell\shell\open_with_ghci_6.9 REG_SZ open with ghci 6.9 HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ghc_haskell\shell\open_with_ghci_6.9\command REG_SZ C:\ghc\ghc-6.9.20080514\bin\ghci.exe "%1" HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ghc_haskell\shell\open_with_WinHugs REG_SZ open with WinHugs HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ghc_haskell\shell\open_with_WinHugs\command REG_SZ "C:\Program Files\WinHugs\winhugs.exe" %1 }}} Note that the `shell` default is `edit` which directly calls my editor, and that I like to have several GHC versions and WinHugs available there (the only reason that the "Edit With Vim" entry survived the GHC installer is that it is available for all fails, so stored elsewhere). The `hugs_haskell` entry seems to be one that I partially restored after a WinHugs installer had taken over (also removing my previous preferences): {{{ $ reg query HKLM\\SOFTWARE\\Classes\\hugs_haskell /s ! REG.EXE VERSION 3.0 HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hugs_haskell REG_SZ Haskell Script EditFlags REG_DWORD 0x0 BrowserFlags REG_DWORD 0x8 HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hugs_haskell\DefaultIcon REG_SZ "C:\Program Files\WinHugs\WinHugs.exe",1 HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hugs_haskell\shell REG_SZ Edit HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hugs_haskell\shell\Edit REG_SZ HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hugs_haskell\shell\Edit\command REG_SZ "C:\Program Files\WinHugs\WinHugs.exe" /edit "%1" HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hugs_haskell\shell\Open REG_SZ HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hugs_haskell\shell\Open\command REG_SZ "C:\Program Files\WinHugs\WinHugs.exe" "%1" HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hugs_haskell\shell\open_with_ghci_6.6.1 REG_SZ open with ghci 6.6.1 HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hugs_haskell\shell\open_with_ghci_6.6.1\command REG_SZ C:\ghc\ghc-6.6.1\bin\ghci.exe "%1" HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hugs_haskell\shell\open_with_ghci_6.9 REG_SZ open with ghci 6.9 HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hugs_haskell\shell\open_with_ghci_6.9\command REG_SZ C:\ghc\ghc-6.9.20080514\bin\ghci.exe "%1" HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hugs_haskell\shell\open_with_ghci_6.9\ddeexec HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hugs_haskell\shell\open_with_ghci_6.9\ddeexec\Application REG_SZ ghci HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hugs_haskell\shell\open_with_ghci_6.9\ddeexec\Topic REG_SZ System }}} Note that WinHugs believed at the time it should handle all editing of Haskell files.. The behaviour I'd like to see is that each installer '''adds''' its functions to the existing menu, for the existing filetype, with descriptive names like "`Open with GHCi x.x`", "`Edit via WinHugs y.y`", etc. Then I can choose which of these, if any, to call from the default `open` and `edit` functions, and changing defaults never looses any options. Unless there is no existing default action or filetype, overriding what is there should be optional (default: no override). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 08:43:06 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 08:42:16 2008 Subject: [GHC] #2517: remove 'pure' method from Arrow class Message-ID: <043.bffe8bdb0940ee07d4e323e480390725@localhost> #2517: remove 'pure' method from Arrow class -------------------------+-------------------------------------------------- Reporter: ross | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- The Arrow class as originally defined by John Hughes had methods {{{arr}}}, {{{>>>}}} and {{{first}}}. ({{{>>>}}} has since been moved by #1773 to the {{{Category}}} class.) When writing the ''Fun of Programming'' paper, I added {{{pure}}} as a synonym for {{{arr}}}, because Richard Bird preferred it. However this name hasn't caught on, and now it clashes with a method in the {{{Applicative}}} class, so I propose to remove it. The usual practice would be to deprecate the name in one release and remove it in the following one, but I propose to remove it in one step because * no-one seems to be using this name, and * backward compatibility has been broken anyway by the Category split (#1773). The only people who will be bitten by the change are those who import {{{Control.Arrow}}} hiding {{{pure}}}, and they wouldn't be warned by deprecation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 08:55:22 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 08:54:34 2008 Subject: [GHC] #2442: Heuristics to improve error messages for badly referenced things In-Reply-To: <053.d96b74737451be892238b37815ca44b6@localhost> References: <053.d96b74737451be892238b37815ca44b6@localhost> Message-ID: <062.5ccbdaa03a4f9dcf8b059f30c9444267@localhost> #2442: Heuristics to improve error messages for badly referenced things -----------------------------+---------------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by ross): * type: proposal => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 09:28:18 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 09:27:29 2008 Subject: [GHC] #2518: hard-to-find .hs-boot docs Message-ID: <051.671b51060fac7715fa950c1267fa75b4@localhost> #2518: hard-to-find .hs-boot docs -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- I can never find the User's Guide's documentation on .hs-boot files... and this documentation section is wrong: http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs-and- infelicities.html#infelicities-Modules The lack of implementing mutually recursive modules directly as specified by Haskell98 is at least an infelicity I think :-) ... that section should summarize and link to http://www.haskell.org/ghc/docs/latest/html/users_guide/separate- compilation.html#mutual-recursion -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 11:49:01 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 11:48:13 2008 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM In-Reply-To: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> References: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> Message-ID: <054.f40c81ae9cd11c28e06f0e7a9f1bd2dc@localhost> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM ---------------------+------------------------------------------------------ Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Changes (by guest): * cc: kfrdbs@gmail.com (added) Comment: Perhaps what Claus is thinking of is a Portable GHC package, one that doesn't modify the registry. An increasing number of software packages have a so-called Portable version that allows installation to a USB flash disk. Something along those lines for GHC might be useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 12:02:51 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 12:02:18 2008 Subject: [GHC] #2356: GHC accepts multiple instances for the same type in different modules In-Reply-To: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> References: <044.2ec6e38cc1bfc912f22d361e9492d9f9@localhost> Message-ID: <053.89ee2817178600ae8ff81b2e582c5370@localhost> #2356: GHC accepts multiple instances for the same type in different modules ----------------------+----------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by spl): * cc: leather@cs.uu.nl (added) * version: 6.8.2 => 6.8.3 Comment: I prefer having GHC work as it does now. It makes sense to me that instances only overlap when used and not just when imported. If GHC changes, I would like the option to get back to the current approach, but without requiring {{{-fallow-overlapping-instances}}}. Perhaps some language extension. Also, has this been mentioned in haskell-prime? I just recently learned about this issue first-hand. See the glasgow- haskell-users thread starting [http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/14970/focus=14992 here] with my own [http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/14970/focus=14999 simple example] that highlights the usefulness of instances working the way they do now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 12:15:13 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 12:14:23 2008 Subject: [GHC] #2508: exception handling: exitWith ExitSuccess results in abnormal termination with Control.OldException In-Reply-To: <044.3565fd6a785086b82dda34be53000404@localhost> References: <044.3565fd6a785086b82dda34be53000404@localhost> Message-ID: <053.8efb3fd1a60b6a35ff46a18684c5dc1b@localhost> #2508: exception handling: exitWith ExitSuccess results in abnormal termination with Control.OldException ----------------------------+----------------------------------------------- Reporter: int-e | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Ah, I see, so we just never actually throw the old Exception type. Makes sense, patch applied; thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 12:16:20 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 12:15:30 2008 Subject: [GHC] #2449: panic with GeneralizedNewtypeDeriving and a .hs-boot file In-Reply-To: <044.e61299c07a3173d5bd1857190eae6cdf@localhost> References: <044.e61299c07a3173d5bd1857190eae6cdf@localhost> Message-ID: <053.bd203b08cc45260b9b1f7f272dbf9c45@localhost> #2449: panic with GeneralizedNewtypeDeriving and a .hs-boot file ------------------------+--------------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: drvfail016 | Architecture: Unknown Os: Unknown | ------------------------+--------------------------------------------------- Changes (by igloo): * testcase: => drvfail016 * status: new => closed * resolution: => fixed Comment: Test drvfail016 added -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 12:16:57 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 12:16:07 2008 Subject: [GHC] #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" In-Reply-To: <053.250fd8f3285636d4b0e7d255649c2b44@localhost> References: <053.250fd8f3285636d4b0e7d255649c2b44@localhost> Message-ID: <062.c6ecf9ac858ff31ede0c53f67332f5d4@localhost> #2412: Interaction between type synonyms and .hs-boot causes panic "tcIfaceGlobal (local): not found" ----------------------------+----------------------------------------------- Reporter: batterseapower | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2412 | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * testcase: => T2412 * status: new => closed * resolution: => fixed Comment: Test T2412 added -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 13:22:27 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 13:21:39 2008 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM In-Reply-To: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> References: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> Message-ID: <054.89b617176536b2b94045bc5fb1af312f@localhost> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM ---------------------+------------------------------------------------------ Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Comment (by nimnul): There is no such thing as "installer that doesn't modify the registry". Any installer at least creates that "uninstall me" entry, and MSI installers modify much more. Installers are a poor choice for portable packages - a classic "binary tarball" package is much better for that purpose. For example, if you install something to a removable disk, and move the disk to another box, the registry won't go with you, and you'll be in trouble. More reasons to have tarballs (or 7z/tbz/whatever) are to allow installations to a company-wide network drive, and to allow GHC to survive OS re-installation. It's a pity that GHC installer is not an MSI installer - MSI is more robust than other installers, and is better fit for corporate use (see the list of MSI features in my earlier post - I mistakenly thought that "Windows Installer" label at http://haskell.org/ghc/download_ghc_683.html meant "Microsoft Installer") MSI has an API to query installation location for a package, without a need to know whether it is system-wide or per-user: Here is .js code, but of course Microsoft has plain C api for that too. {{{ var i = WScript.CreateObject("WindowsInstaller.Installer") var p = i.products for (var j = 0; j < p.Count ; j++) { WScript.Echo(i.ProductInfo(p.Item(j), 'ProductName')); WScript.Echo(i.ProductInfo(p.Item(j), 'VersionString')); WScript.Echo(i.ProductInfo(p.Item(j), 'InstallLocation')); } }}} Of course I understand that migrating to WiX/MSI is not an option in observable future, but that would save us from lots of problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 13:50:32 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 13:49:55 2008 Subject: [GHC] #2518: hard-to-find .hs-boot docs In-Reply-To: <051.671b51060fac7715fa950c1267fa75b4@localhost> References: <051.671b51060fac7715fa950c1267fa75b4@localhost> Message-ID: <060.a3467d355d77da650172526a17496d56@localhost> #2518: hard-to-find .hs-boot docs ------------------------------+--------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------------+--------------------------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): The Haskell'98 Report specifies in Section 5.7: "Depending on the Haskell implementation used, separate compilation of mutually recursive modules may require that imported modules contain additional information so that they may be referenced before they are compiled. The precise details of separate compilation are not defined by this report." -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 14:07:51 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 14:07:13 2008 Subject: [GHC] #2518: hard-to-find .hs-boot docs In-Reply-To: <051.671b51060fac7715fa950c1267fa75b4@localhost> References: <051.671b51060fac7715fa950c1267fa75b4@localhost> Message-ID: <060.522e66cbf7d14a86c0ac425ff32f8cc0@localhost> #2518: hard-to-find .hs-boot docs ------------------------------+--------------------------------------------- Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------------+--------------------------------------------- Comment (by Isaac Dupree): Well, I don't think that .hs-boot files are information that "imported modules contain", because it's in a separate file, which is a nuisance to me in practice. And there's no inherent reason that `ghc --make` has to use separate compilation, so it's not completely obvious that that paragraph -as written- should apply. But I don't think the details matter so much as that the documentation should point out in that location what's going on, because users regularly get confused about it. If it really doesn't even count as an infelicity, then it should go in the "undefined behavior in Haskell 98" section of that page, , a section that unfortunately is harder to read due to the lack of sub-headings in the table of contents. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 14:47:37 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 14:46:48 2008 Subject: [GHC] #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM In-Reply-To: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> References: <045.8268642d688f1830bf5e7f9b3d0846d3@localhost> Message-ID: <054.ff611e55ac961b6e6c1822e99da988fe@localhost> #2489: Registry keys are created in per-user HKCU instead of system-wide HKLM ---------------------+------------------------------------------------------ Reporter: nimnul | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Comment (by NeilMitchell): nimnul: An MSI would be the best option, but it requires someone who knows all about MSI's. I did look into WiX but didn't have the time to get anything to a useable level. If someone with the necessary expertise to do the .msi solution, and the time to keep it working, then that would be great! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 15:58:23 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 15:57:48 2008 Subject: [GHC] #2431: allow empty case analysis In-Reply-To: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@localhost> References: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@localhost> Message-ID: <057.76ff9567b85cbdf1753f997db359123f@localhost> #2431: allow empty case analysis ---------------------------------+------------------------------------------ Reporter: RalfHinze | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: Keywords: empty case analysis | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------+------------------------------------------ Comment (by malcolm.wallace@cs.york.ac.uk): I tried to think of how parsing might go wrong. Consider the following (contrived) example: {{{ case foo of [] -> case bar of (x:xs) -> baz }}} Did you spot that the second alternative is indented with a tab rather than spaces, (with editor tab width set to 2 instead of 8)? So although I _intended_ to have the two alternatives for the outer case, and the inner case empty, in fact the second pattern is indented further than the first, and so there is a single alternative for each of the inner and outer cases? Well, I did say it was contrived. -fwarn-incomplete-patterns would catch it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 16:40:15 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 16:39:28 2008 Subject: [GHC] #2340: Improve Template Haskell error recovery In-Reply-To: <046.869c20c62dd7ab567cd622b9021b6c1e@localhost> References: <046.869c20c62dd7ab567cd622b9021b6c1e@localhost> Message-ID: <055.6866844dd77ad39fbce558a609bfd754@localhost> #2340: Improve Template Haskell error recovery ------------------------------+--------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * milestone: 6.10.1 => 6.12 branch Comment: No replies to http://www.haskell.org/pipermail/template- haskell/2008-July/000695.html so punting. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 15 19:52:57 2008 From: trac at galois.com (GHC) Date: Fri Aug 15 19:52:06 2008 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.db724c877cef91bf2f57ef11654c9bb4@localhost> #1338: base package breakup ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by igloo): Thread starts here: http://www.haskell.org/pipermail/libraries/2008-August/010379.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 08:39:01 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 08:38:15 2008 Subject: [GHC] #2481: ghci: :f fmap -> can't unify In-Reply-To: <044.bb22267ef7664b8c3af7a80d0a7ef05d@localhost> References: <044.bb22267ef7664b8c3af7a80d0a7ef05d@localhost> Message-ID: <053.df85a8c1058862faec1c56d9e8bbaf02@localhost> #2481: ghci: :f fmap -> can't unify --------------------+------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. Happily, this already works in the HEAD: {{{ Prelude> :f fmap fmap = _ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 08:40:55 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 08:40:10 2008 Subject: [GHC] #2481: ghci: :f fmap -> can't unify In-Reply-To: <044.bb22267ef7664b8c3af7a80d0a7ef05d@localhost> References: <044.bb22267ef7664b8c3af7a80d0a7ef05d@localhost> Message-ID: <053.a85bd4206d95c0fc909aebce98da83be@localhost> #2481: ghci: :f fmap -> can't unify --------------------+------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | --------------------+------------------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 09:03:34 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 09:02:42 2008 Subject: [GHC] #2482: Documentation of STUArray: type argument name mismatch In-Reply-To: <044.473dec5fe610a9994dfae768714f70b4@localhost> References: <044.473dec5fe610a9994dfae768714f70b4@localhost> Message-ID: <053.c0fa75042698aa1fa369a7f36fb6b179@localhost> #2482: Documentation of STUArray: type argument name mismatch ---------------------------+------------------------------------------------ Reporter: wozer | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 09:07:08 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 09:06:21 2008 Subject: [GHC] #2446: Network.Socket.PortNum should not be exported In-Reply-To: <042.b2277c9aa83a0038145519302cc81ee4@localhost> References: <042.b2277c9aa83a0038145519302cc81ee4@localhost> Message-ID: <051.5e5a788780967a74937c3260af82a6c0@localhost> #2446: Network.Socket.PortNum should not be exported ----------------------+----------------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Please file a library submission if you want to propose this: http://www.haskell.org/haskellwiki/Library_submissions -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 09:09:27 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 09:08:36 2008 Subject: [GHC] #2468: Wrong names in Mangler script In-Reply-To: <043.ceb2592b5f923064428cfcba80ddc7f3@localhost> References: <043.ceb2592b5f923064428cfcba80ddc7f3@localhost> Message-ID: <052.f842f3b6abeba187d202170033e7475b@localhost> #2468: Wrong names in Mangler script ----------------------+----------------------------------------------------- Reporter: jsnx | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 09:23:55 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 09:23:02 2008 Subject: [GHC] #2474: II belive that in ISO8601 the date and time should be separated by a 'T', not a space In-Reply-To: <053.c50e53ab3abbd63ccd001b113f15157f@localhost> References: <053.c50e53ab3abbd63ccd001b113f15157f@localhost> Message-ID: <062.4a77a9faf94e2ac1ec68fb4b5ecccd73@localhost> #2474: II belive that in ISO8601 the date and time should be separated by a 'T', not a space -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: I'm not sure; that wikipedia page lists `2008-08-16 07:51Z` as `Example separate date and time in UTC`. Can you propose this with the library submission procedure (http://www.haskell.org/haskellwiki/Library_submissions) so that people more knowledgeable than I can have a say? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 09:25:28 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 09:24:36 2008 Subject: [GHC] #2512: MAP_32BIT flag might not be respected under xen? In-Reply-To: <044.02579c65234b2e00edf9fbae992e571c@localhost> References: <044.02579c65234b2e00edf9fbae992e571c@localhost> Message-ID: <053.a51d1c7a42eaf7dbea3eeab78298005f@localhost> #2512: MAP_32BIT flag might not be respected under xen? ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 6.8.3 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > Here's the error I get when I try to run ghci 6.8.3 on Fedora 9. I also > got the same error on ghc 6.8.2 with Fedora 9 and Ubuntu 8.0.4, all > running x86_64 under xen. > > /ghc-6.8.3# ghci-6.8.3 > GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help > ghc-6.8.3: internal error: R_X86_64_32S relocation out of range: (noname) > = 0x7ffc1dbd4fb8 > > (GHC version 6.8.3 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort ghci-6.8.3 > > An strace of the bug is attached, as well here's a link to a relevant > problem: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/237724 New description: Here's the error I get when I try to run ghci 6.8.3 on Fedora 9. I also got the same error on ghc 6.8.2 with Fedora 9 and Ubuntu 8.0.4, all running x86_64 under xen. {{{ /ghc-6.8.3# ghci-6.8.3 GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help ghc-6.8.3: internal error: R_X86_64_32S relocation out of range: (noname) = 0x7ffc1dbd4fb8 (GHC version 6.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort ghci-6.8.3 }}} An strace of the bug is attached, as well here's a link to a relevant problem: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/237724 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 09:52:24 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 09:51:31 2008 Subject: [GHC] #2482: Documentation of STUArray: type argument name mismatch In-Reply-To: <044.473dec5fe610a9994dfae768714f70b4@localhost> References: <044.473dec5fe610a9994dfae768714f70b4@localhost> Message-ID: <053.1e4578cb3a77e63e82ea078361e2e046@localhost> #2482: Documentation of STUArray: type argument name mismatch ---------------------------+------------------------------------------------ Reporter: wozer | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by ross): * status: new => closed * resolution: => fixed Comment: fixed by this patch to the array package: {{{ Sat Aug 16 14:50:28 BST 2008 Ross Paterson * use "e" for element type for consistency (fixes #2482) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 10:35:37 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 10:34:44 2008 Subject: [GHC] #2473: Data.Array.IO.Internals hidden in GHC6.8 for no good reason In-Reply-To: <044.3c74e42a68ae62a3562b4a333f1234f6@localhost> References: <044.3c74e42a68ae62a3562b4a333f1234f6@localhost> Message-ID: <053.74af45667028f80e018df54ce15795f8@localhost> #2473: Data.Array.IO.Internals hidden in GHC6.8 for no good reason -------------------------------+-------------------------------------------- Reporter: ryani | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown Comment: It was hidden by: {{{ Sat Nov 11 11:32:48 GMT 2006 Ross Paterson * hide Data.Array.IO.Internals It's hidden from haddock, and everything it exports is re-exported by Data.Array.IO. }}} which isn't quite accurate, as `Data.Array.IO` re-exports `IOArray` and `IOUArray` abstractly. I think that `.Internal` modules aren't really part of the API, so I'll just re-expose it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 11:35:13 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 11:34:20 2008 Subject: [GHC] #2476: internal error: awaitEvent: descriptor out of range In-Reply-To: <046.98b2024ece2c4d6cefc902a4a054a14b@localhost> References: <046.98b2024ece2c4d6cefc902a4a054a14b@localhost> Message-ID: <055.d51587c6e9b012eda5aefc00360de2de@localhost> #2476: internal error: awaitEvent: descriptor out of range ----------------------------+----------------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: ia64 Os: FreeBSD | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > My program reports: > Server3s.exe: internal error: awaitEvent: descriptor out of range > (GHC version 6.8.2 for x86_64_unknown_freebsd) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Abort trap: 6 (core dumped) > > The core dump shows: > (gdb) where > #0 0x0000000800956dec in kill () from /lib/libc.so.7 > #1 0x0000000800955c5b in abort () from /lib/libc.so.7 > #2 0x00000000004e5bcd in rtsFatalInternalErrorFn () > #3 0x00000000004e58bc in barf () > #4 0x00000000004ea57d in awaitEvent () > #5 0x00000000004e6d85 in scheduleWaitThread () > #6 0x00000000004e42a9 in real_main () > #7 0x00000000004e4398 in main () > > My host is: > FreeBSD hpsux 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sat Mar 8 14:07:11 HST > 2008 root@hpsux:/usr/obj/usr/src/sys/GENERIC amd64 > > The full sources that are causing this issue are attached. To reproduce: > run "make" then in one window run "./Server3s.exe" and in another window > run "./DummyClient3s.exe". I get the crash in the Server3s program after > it runs for a while. > > I can provide built binaries and a core dump if it is helpful. I didn't > include them yet because they are large. New description: My program reports: {{{ Server3s.exe: internal error: awaitEvent: descriptor out of range (GHC version 6.8.2 for x86_64_unknown_freebsd) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 (core dumped) }}} The core dump shows: {{{ (gdb) where #0 0x0000000800956dec in kill () from /lib/libc.so.7 #1 0x0000000800955c5b in abort () from /lib/libc.so.7 #2 0x00000000004e5bcd in rtsFatalInternalErrorFn () #3 0x00000000004e58bc in barf () #4 0x00000000004ea57d in awaitEvent () #5 0x00000000004e6d85 in scheduleWaitThread () #6 0x00000000004e42a9 in real_main () #7 0x00000000004e4398 in main () }}} My host is: {{{ FreeBSD hpsux 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sat Mar 8 14:07:11 HST 2008 root@hpsux:/usr/obj/usr/src/sys/GENERIC amd64 }}} The full sources that are causing this issue are attached. To reproduce: run "make" then in one window run "./Server3s.exe" and in another window run "./DummyClient3s.exe". I get the crash in the Server3s program after it runs for a while. I can provide built binaries and a core dump if it is helpful. I didn't include them yet because they are large. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 11:55:19 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 11:54:24 2008 Subject: [GHC] #1063: hReady should probably return False at the end of a file In-Reply-To: <044.0663959ba05fc1f12d7857cb5910edf0@localhost> References: <044.0663959ba05fc1f12d7857cb5910edf0@localhost> Message-ID: <053.4ba6a017d92ff71c9e9e974292e08954@localhost> #1063: hReady should probably return False at the end of a file ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: hReady001 | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by ross): According to the [file://localhost/usr/share/doc/haskell98-report/html/haskell98-report- html/io.html#sect21.9.1 H98 Report, S21.9.1], hReady and hWaitForInput should fail with isEOFError in this situation. False seems wrong: some programs will keep waiting forever. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 12:00:56 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 12:00:03 2008 Subject: [GHC] #2476: internal error: awaitEvent: descriptor out of range In-Reply-To: <046.98b2024ece2c4d6cefc902a4a054a14b@localhost> References: <046.98b2024ece2c4d6cefc902a4a054a14b@localhost> Message-ID: <055.16ae66e4edf5ce93b239ea88ac9bceff@localhost> #2476: internal error: awaitEvent: descriptor out of range ----------------------------+----------------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: ia64 Os: FreeBSD | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 Comment: I can't reproduce this on amd64/Linux; after a while it dies with: {{{ DummyClient3s.exe: connect: unsupported operation (Cannot assign requested address) }}} strace shows that this is caused by: {{{ connect(3, {sa_family=AF_INET, sin_port=htons(8001), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRNOTAVAIL (Cannot assign requested address) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 12:53:57 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 12:53:04 2008 Subject: [GHC] #2468: Wrong names in Mangler script In-Reply-To: <043.ceb2592b5f923064428cfcba80ddc7f3@localhost> References: <043.ceb2592b5f923064428cfcba80ddc7f3@localhost> Message-ID: <052.582b569ac2cc374ffcd205d98a2a8761@localhost> #2468: Wrong names in Mangler script ----------------------+----------------------------------------------------- Reporter: jsnx | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed * milestone: => 6.10.1 Comment: Fixed, thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 14:03:40 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 14:02:47 2008 Subject: [GHC] #1063: hReady should probably return False at the end of a file In-Reply-To: <044.0663959ba05fc1f12d7857cb5910edf0@localhost> References: <044.0663959ba05fc1f12d7857cb5910edf0@localhost> Message-ID: <053.9a380492c1fa3e94a26992c6d87c1d47@localhost> #1063: hReady should probably return False at the end of a file ----------------------------+----------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: hReady001 | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: => igloo Comment: Good point, thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 14:48:55 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 14:48:01 2008 Subject: [GHC] #2502: segfault with GHC.Handle.fdToHandle' In-Reply-To: <046.3af147e9b383729d4b3cbb7db169730e@localhost> References: <046.3af147e9b383729d4b3cbb7db169730e@localhost> Message-ID: <055.e948fb6de96f104e272afa8aa386da25@localhost> #2502: segfault with GHC.Handle.fdToHandle' ---------------------+------------------------------------------------------ Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: FreeBSD | ---------------------+------------------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: I can't reproduce this on Linux/amd64. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 14:50:57 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 14:50:05 2008 Subject: [GHC] #916: windows installer should play nice with other Haskell tools In-Reply-To: <062.82a61997b82e196e33cc4bb01ea09d25@localhost> References: <062.82a61997b82e196e33cc4bb01ea09d25@localhost> Message-ID: <071.8f1963913d0f10f2dcae25b926529f40@localhost> #916: windows installer should play nice with other Haskell tools -------------------------------------+-------------------------------------- Reporter: claus.reinke@talk21.com | Owner: neil Type: bug | Status: new Priority: low | Milestone: _|_ Component: Build System | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Architecture: Unknown Os: Windows | -------------------------------------+-------------------------------------- Comment (by igloo): See also #2505. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 14:53:48 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 14:52:56 2008 Subject: [GHC] #2505: windows installer should not hijack filetype associations! In-Reply-To: <044.a62339318202233961e8d0b3da109f64@localhost> References: <044.a62339318202233961e8d0b3da109f64@localhost> Message-ID: <053.b18bae4ed733ea12222f9ba4389206ba@localhost> #2505: windows installer should not hijack filetype associations! ---------------------+------------------------------------------------------ Reporter: claus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: I'm closing this as a duplicate of #916. If someone has the knowledge and some time to spend, then what would be really nice is: * Something that generates an MSI installer * Something that generates an installer that can act as a slave to a HP installer, i.e. the HP installer asks the user where to install to etc and passes that info on to the GHC installer * Something that generates an installer that behaves as Claus, Neil et al have agreed a Windows installer should behave -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 15:35:12 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 15:34:18 2008 Subject: [GHC] #2467: orphan instance warnings are badly behaved In-Reply-To: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> References: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> Message-ID: <054.296f9b18a604145d452cda206e452580@localhost> #2467: orphan instance warnings are badly behaved ----------------------+----------------------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): array done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 17:05:07 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 17:04:13 2008 Subject: [GHC] #1063: hReady should probably return False at the end of a file In-Reply-To: <044.0663959ba05fc1f12d7857cb5910edf0@localhost> References: <044.0663959ba05fc1f12d7857cb5910edf0@localhost> Message-ID: <053.2e991c72003497d6d1a54dd9882416a6@localhost> #1063: hReady should probably return False at the end of a file ----------------------------+----------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: hReady001 | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 17:43:13 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 17:42:19 2008 Subject: [GHC] #2484: ghc 6.8.2 broken after Security Update 2008-005 (PPC) on Mac OS 10.4.11 In-Reply-To: <044.a2618a27f261a948044540a6bc0d6d47@localhost> References: <044.a2618a27f261a948044540a6bc0d6d47@localhost> Message-ID: <053.0f214f351f0326f01e68166fe7cc56f2@localhost> #2484: ghc 6.8.2 broken after Security Update 2008-005 (PPC) on Mac OS 10.4.11 ----------------------+----------------------------------------------------- Reporter: knarF | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: When you say `when compiling the simple file`, do you really mean compiling, as opposed to running it in ghci? I can't see why that would fail if compiling hello world worked. Has anyone else seen this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 17:43:56 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 17:43:03 2008 Subject: [GHC] #2473: Data.Array.IO.Internals hidden in GHC6.8 for no good reason In-Reply-To: <044.3c74e42a68ae62a3562b4a333f1234f6@localhost> References: <044.3c74e42a68ae62a3562b4a333f1234f6@localhost> Message-ID: <053.3614695a5f598300d072e5fc955c956c@localhost> #2473: Data.Array.IO.Internals hidden in GHC6.8 for no good reason -------------------------------+-------------------------------------------- Reporter: ryani | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by ryani): Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 16 20:31:22 2008 From: trac at galois.com (GHC) Date: Sat Aug 16 20:30:28 2008 Subject: [GHC] #2176: H98 module Array exports non-H98 instance Functor ((->) a) In-Reply-To: <045.a9dd1faca636f175591a794f8e7a99a8@localhost> References: <045.a9dd1faca636f175591a794f8e7a99a8@localhost> Message-ID: <054.5afc50c5f1c274e2fe61bd086e69f1d6@localhost> #2176: H98 module Array exports non-H98 instance Functor ((->) a) ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/haskell98 | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------+------------------------------------------ Changes (by ross): * status: new => closed * resolution: => fixed Comment: Fixed by elimination of orphan instances in Data.Array and then the patch {{{ Sun Aug 17 01:23:48 BST 2008 Ross Paterson * delete imports of Data.Foldable and Data.Traversable (fixes #2176) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 17 09:30:46 2008 From: trac at galois.com (GHC) Date: Sun Aug 17 09:30:38 2008 Subject: [GHC] #1999: panic with GADT etc. In-Reply-To: <046.74c6dc616261a913ffd4180fb00731f0@localhost> References: <046.74c6dc616261a913ffd4180fb00731f0@localhost> Message-ID: <055.4d01a1c26ae08abc1910a34c7eb100c1@localhost> #1999: panic with GADT etc. ----------------------+----------------------------------------------------- Reporter: jeltsch | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T1999 | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by ganesh): * cc: ganesh@earth.li (added) Comment: I'm also getting this error (without -dcore-lint, or at least without explicitly specifying it); if it's useful I can cut down a test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 17 15:13:52 2008 From: trac at galois.com (GHC) Date: Sun Aug 17 15:12:57 2008 Subject: [GHC] #2519: Time.toClockTime: picoseconds out of range, after diffClockTimes Message-ID: <046.99e01b8d2f29c1267b52b4fd1e83a300@localhost> #2519: Time.toClockTime: picoseconds out of range, after diffClockTimes -------------------------+-------------------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: TimeDiff | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- I've found a consistent problem where the picoseconds field of TimeDiff is less than zero. I'm attaching a program that is able to reproduce this problem under 6.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 17 15:15:31 2008 From: trac at galois.com (GHC) Date: Sun Aug 17 15:14:35 2008 Subject: [GHC] #2519: Time.toClockTime: picoseconds out of range, after diffClockTimes In-Reply-To: <046.99e01b8d2f29c1267b52b4fd1e83a300@localhost> References: <046.99e01b8d2f29c1267b52b4fd1e83a300@localhost> Message-ID: <055.02fac0553128ccb4c25ea050eedc8bb4@localhost> #2519: Time.toClockTime: picoseconds out of range, after diffClockTimes -------------------------+-------------------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: TimeDiff | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Comment (by Ansible): Output from PicoTest.hs: *Main> main Welcome to the picotest. Enter 'q' to quit. Hit enter for test: Clocktime1 1218999538 seconds; 896297000000 picoseconds. Clocktime2 1218999539 seconds; 943780000000 picoseconds. TimeDiff TimeDiff {tdYear = 0, tdMonth = 0, tdDay = 0, tdHour = 0, tdMin = 0, tdSec = 1, tdPicosec = 47483000000} converted to seconds: 1.047483 Hit enter for test: Clocktime1 1218999539 seconds; 946978000000 picoseconds. Clocktime2 1218999540 seconds; 931424000000 picoseconds. TimeDiff TimeDiff {tdYear = 0, tdMonth = 0, tdDay = 0, tdHour = 0, tdMin = 0, tdSec = 1, tdPicosec = -15554000000} converted to seconds: *** Exception: Time.toClockTime: picoseconds out of range -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 17 15:16:49 2008 From: trac at galois.com (GHC) Date: Sun Aug 17 15:15:52 2008 Subject: [GHC] #2519: Time.toClockTime: picoseconds out of range, after diffClockTimes In-Reply-To: <046.99e01b8d2f29c1267b52b4fd1e83a300@localhost> References: <046.99e01b8d2f29c1267b52b4fd1e83a300@localhost> Message-ID: <055.260eefaa4e6caa1b109f505e519bab91@localhost> #2519: Time.toClockTime: picoseconds out of range, after diffClockTimes -------------------------+-------------------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: TimeDiff | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Comment (by Ansible): Output from PicoTest2.hs. Does not produce the bug, although the same ClockTime values are used. [1 of 1] Compiling Main ( PicoTest2.hs, interpreted ) Ok, modules loaded: Main. *Main> main TimeDiff {tdYear = 0, tdMonth = 0, tdDay = 0, tdHour = 0, tdMin = 0, tdSec = -1, tdPicosec = 15554000000} -0.984446 *Main> -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 17 17:23:35 2008 From: trac at galois.com (GHC) Date: Sun Aug 17 17:22:39 2008 Subject: [GHC] #2520: SPECIALIZE causing duplicate assembler symbols Message-ID: <045.4cbde2e14ab09ef4660570998e97cec8@localhost> #2520: SPECIALIZE causing duplicate assembler symbols -----------------------+---------------------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- The program below causes duplicate assembler symbols when compiled -O with ghc 6.9.20080816 (but not with ghc 6.8.2) There's no profiling involved otherwise I'd have assumed this was a duplicate of #2410. {{{ {-# LANGUAGE GADTs #-} module Types where data Prod a b = Prod a b data Nil = Nil class ProdSel f where nil :: f Nil prod :: f x -> f y -> f (Prod x y) instance ProdSel SqlFields where nil = SFNil prod = SFProd {-# SPECIALIZE reproject :: SqlFields a -> SqlFields a #-} reproject :: ProdSel f => SqlFields a -> f a reproject SFNil = nil reproject (SFProd a b) = prod (reproject a) (reproject b) data SqlFields a where SFNil :: SqlFields Nil SFProd :: SqlFields a -> SqlFields b -> SqlFields (Prod a b) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 17 18:30:08 2008 From: trac at galois.com (GHC) Date: Sun Aug 17 18:29:11 2008 Subject: [GHC] #2474: II belive that in ISO8601 the date and time should be separated by a 'T', not a space In-Reply-To: <053.c50e53ab3abbd63ccd001b113f15157f@localhost> References: <053.c50e53ab3abbd63ccd001b113f15157f@localhost> Message-ID: <062.d689472f591d142355fb090af6137c68@localhost> #2474: II belive that in ISO8601 the date and time should be separated by a 'T', not a space -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by josef): I'm with Magnus on this one. A correct date has 'T' as a separator. Igloo, if you read further on the Wikipedia page you will find the following passage: The date and time representations may appear in proximity to each other, often separated by a space or sometimes by other characters. In these cases they occupy two separate fields in a data system, rather than a single combined representation. This is usually done for human readability. Unlike the previous examples, "2007-04-05 14:30" is considered two separate, but acceptable, representations?one for date and the other for time. It is then left to the reader to interpret the two separate representations as meaning a single time point based on the context. This should make it clear that it is somewhat dubious to use space as a separator. There are many implementations of dates that are sloppy when it comes to delimiters because most date parsers are rather forgiving. I think we should hold ourselves to a higher standard than that. It's a simple fix and there no reason not to do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 17 22:20:33 2008 From: trac at galois.com (GHC) Date: Sun Aug 17 22:19:40 2008 Subject: [GHC] #2521: Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg. Message-ID: <042.a15d898f52a182feca97f0f12eb7b2a0@localhost> #2521: Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg. ------------------------+--------------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Multiple ------------------------+--------------------------------------------------- According to section 5.8.4.1 of the ''Users' Guide'', appending a colon to GHC_PACKAGE_PATH should include the system libraries, and this can be verified with ghc-pkg. While the colon does appear to work for ghci (as verified with -v), it does not appear to work for ghc-pkg. {{{ $ echo '[]' > temp.conf $ export GHC_PACKAGE_PATH=`pwd`/temp.conf: ghc-pkg list /home/cjs/temp.conf: $ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 17 22:34:01 2008 From: trac at galois.com (GHC) Date: Sun Aug 17 22:33:47 2008 Subject: [GHC] #1999: panic with GADT etc. In-Reply-To: <046.74c6dc616261a913ffd4180fb00731f0@localhost> References: <046.74c6dc616261a913ffd4180fb00731f0@localhost> Message-ID: <055.d0c47bf7421ba5784bbfcdafe73cdaa2@localhost> #1999: panic with GADT etc. ----------------------+----------------------------------------------------- Reporter: jeltsch | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T1999 | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Comment (by chak): Replying to [comment:6 ganesh]: > I'm also getting this error (without -dcore-lint, or at least without explicitly specifying it); if it's useful I can cut down a test case. That might be useful, so that if it has a different cause, we can make sure to fix your problem, too. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 18 06:32:43 2008 From: trac at galois.com (GHC) Date: Mon Aug 18 06:32:01 2008 Subject: [GHC] #2431: allow empty case analysis In-Reply-To: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@localhost> References: <048.d68852a6d9d47b4ac7cd50dcdf56aabf@localhost> Message-ID: <057.cd6d828b29b293a04f97cb274336a499@localhost> #2431: allow empty case analysis ---------------------------------+------------------------------------------ Reporter: RalfHinze | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: Keywords: empty case analysis | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:6 malcolm.wallace@cs.york.ac.uk]: > I tried to think of how parsing might go wrong. Consider the following (contrived) example: > > {{{ > case foo of > [] -> > case bar of > (x:xs) -> > baz > }}} > > Did you spot that the second alternative is indented with a tab rather than spaces, (with editor tab width set to 2 instead of 8)? I realise the example is contrived, but I don't think we need to consider it. The Haskell report defines tab stops to be 8 characters apart, so you should always have your editor set to use 8-character tab stops when editing Haskell code, because that's how the compiler sees it. Anything else will cause confusion, in many more ways than just the example above. If you don't like 8-char tabs then fine: use spaces instead, and `-fwarn- tabs`, but you should still set your editor to use 8-char tabs so that you can read other people's code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 18 06:36:24 2008 From: trac at galois.com (GHC) Date: Mon Aug 18 06:35:37 2008 Subject: [GHC] #2521: Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg. In-Reply-To: <042.a15d898f52a182feca97f0f12eb7b2a0@localhost> References: <042.a15d898f52a182feca97f0f12eb7b2a0@localhost> Message-ID: <051.eeb6f1a22ebd022806a640a3cc3922d0@localhost> #2521: Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg. ----------------------+----------------------------------------------------- Reporter: cjs | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown Comment: I'm in ghc-pkg at the moment... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 18 08:34:50 2008 From: trac at galois.com (GHC) Date: Mon Aug 18 08:33:53 2008 Subject: [GHC] #2330: ghc-pkg should not report duplicate depends In-Reply-To: <045.a0d888b36f9d7b158756f697bfe898a1@localhost> References: <045.a0d888b36f9d7b158756f697bfe898a1@localhost> Message-ID: <054.ca14fe651bd3b440229c33dadc5d4d9c@localhost> #2330: ghc-pkg should not report duplicate depends ----------------------+----------------------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Mon Aug 18 12:24:34 BST 2008 Simon Marlow * Test for and reject duplicate dependencies (#2330) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 18 08:35:15 2008 From: trac at galois.com (GHC) Date: Mon Aug 18 08:34:20 2008 Subject: [GHC] #2521: Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg. In-Reply-To: <042.a15d898f52a182feca97f0f12eb7b2a0@localhost> References: <042.a15d898f52a182feca97f0f12eb7b2a0@localhost> Message-ID: <051.f618b4ff270a18c53372b73a788ca5ec@localhost> #2521: Trailing colon on GHC_PACKAGE_PATH doesn't work with ghc-pkg. ----------------------+----------------------------------------------------- Reporter: cjs | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Mon Aug 18 12:33:45 BST 2008 Simon Marlow * FIX #2521: trailing colon in GHC_PACKAGE_PATH This was broken in the System.FilePath switchover, since filepath's splitSearchPath doesn't do what we want (it ignores empty components on Windows, and treats them as "." on Unix). So we use our own hand-rolled version, just like GHC. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 18 15:49:02 2008 From: trac at galois.com (GHC) Date: Mon Aug 18 15:48:48 2008 Subject: [GHC] #1999: panic with GADT etc. In-Reply-To: <046.74c6dc616261a913ffd4180fb00731f0@localhost> References: <046.74c6dc616261a913ffd4180fb00731f0@localhost> Message-ID: <055.bb83bb1ad6aa1ca972034c4d32ed63b1@localhost> #1999: panic with GADT etc. ----------------------+----------------------------------------------------- Reporter: jeltsch | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T1999 | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Comment (by ganesh): {{{ {-# LANGUAGE GADTs #-} module Types where data EqTypes a b where EqConstr :: EqTypes a b -> EqTypes (s a) (s b) eqUnConstr :: EqTypes (s a) (s b) -> EqTypes a b eqUnConstr (EqConstr eq) = eq }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 19 00:01:59 2008 From: trac at galois.com (GHC) Date: Tue Aug 19 00:01:04 2008 Subject: [GHC] #2522: Warning for missing export lists Message-ID: <042.bc97894bc85aa965fac36f83804d8ebb@localhost> #2522: Warning for missing export lists --------------------------------+------------------------------------------- Reporter: tim | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- It occurred to me that it would be nice to have a warning for modules that lack an export list. Obviously not everybody prefers to write export lists for all their modules, but that's why it would be an optional warning. (It would also be handy to use in conjunction with {{{-fwarn-unused-binds}}}.) If there is already such a flag, then the task is to add it to the users' guide, since I don't see it there :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 19 08:13:02 2008 From: trac at galois.com (GHC) Date: Tue Aug 19 08:12:01 2008 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.7c8357f9a2dd091c1dd4a5844562db9f@localhost> #1338: base package breakup ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by simonpj): I'm also a bit concerned about creating lots of tiny packages. Maybe we can do this a step at a time? If, indeed, we need do anything at all. What is the Main Goal here? Who is pushing for further decomposition of 'base', and what gains does it bring? Are these gains the most important thing to spend our limited effort budget on? There are plenty of other pressing issues! (Untying the mutual recursion is good regardless of further break-up.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 19 08:27:54 2008 From: trac at galois.com (GHC) Date: Tue Aug 19 08:27:06 2008 Subject: [GHC] #2518: hard-to-find .hs-boot docs In-Reply-To: <051.671b51060fac7715fa950c1267fa75b4@localhost> References: <051.671b51060fac7715fa950c1267fa75b4@localhost> Message-ID: <060.f2355c487f7c9b004930b118eebb6fa7@localhost> #2518: hard-to-find .hs-boot docs ---------------------------+------------------------------------------------ Reporter: Isaac Dupree | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: OK I'll add it as an infelicity. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 19 08:30:24 2008 From: trac at galois.com (GHC) Date: Tue Aug 19 08:29:22 2008 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.e400bc75eaa24cd36430932352748408@localhost> #1338: base package breakup ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by igloo): One advantage of making base small is that if you are, for example, debugging GHC.Handle then you don't have to recompile >100 other modules every time you make a change in it. Being able to separately upgrade the different parts is another advantage. Also, it means that we can have a separate maintainer for, e.g., SYB (well, this doesn't technically need it to be a separate package, but it's conceptually simpler if it is). Breaking base up into packages also makes it much easier to see what the hierarchy is, and makes it easier to restructure the hierarchy. Plus it means that people can't re-tangle the logically separate components, which is all too easy to do when you just have one huge package. It also means that packages are clearer about what they depend on. One possibility, which I think would be really cool, is to separate all the IO modules from the non-IO modules; between that and looking at the extensions used (e.g. TH and FFI) it would then be clear whether or not a library could do any IO. Of course, the Prelude is a hurdle for this goal. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 19 08:32:48 2008 From: trac at galois.com (GHC) Date: Tue Aug 19 08:31:59 2008 Subject: [GHC] #2518: hard-to-find .hs-boot docs In-Reply-To: <051.671b51060fac7715fa950c1267fa75b4@localhost> References: <051.671b51060fac7715fa950c1267fa75b4@localhost> Message-ID: <060.a9d7bd6f8a3afc099d10c629fa460d33@localhost> #2518: hard-to-find .hs-boot docs ---------------------------+------------------------------------------------ Reporter: Isaac Dupree | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Tue Aug 19 13:30:16 BST 2008 simonpj@microsoft.com * Fix Trac #2518: add hs-boot files as an infelicty }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 19 08:33:03 2008 From: trac at galois.com (GHC) Date: Tue Aug 19 08:32:02 2008 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.8a86a4012c7fae140d65adc897ecac20@localhost> #1338: base package breakup ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by spl): I can't speak for most packages, but I would like to see that the Data.Generics modules are broken out into a separate package for easier maintainability and upgradeability. Also, as was discussed in the thread linked by igloo, I would like to call it "syb" instead of "generics." -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 19 08:33:47 2008 From: trac at galois.com (GHC) Date: Tue Aug 19 08:32:57 2008 Subject: [GHC] #2474: II belive that in ISO8601 the date and time should be separated by a 'T', not a space In-Reply-To: <053.c50e53ab3abbd63ccd001b113f15157f@localhost> References: <053.c50e53ab3abbd63ccd001b113f15157f@localhost> Message-ID: <062.700c18ef36c8a2a08f4ee78988d64368@localhost> #2474: II belive that in ISO8601 the date and time should be separated by a 'T', not a space -------------------------------+-------------------------------------------- Reporter: MagnusTherning | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): The general rule in these situations is to be strictly conformant when generating text, but lenient when parsing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 19 08:35:14 2008 From: trac at galois.com (GHC) Date: Tue Aug 19 08:34:13 2008 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.dfb68361ae6ed3bc48ee91801fd8ec04@localhost> #1338: base package breakup ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by simonpj): Igloo: these are all good goals. The question is really how high up our priority list they are. spl: yes, I agree there's a specific reason for the generics stuff. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 19 08:51:17 2008 From: trac at galois.com (GHC) Date: Tue Aug 19 08:50:14 2008 Subject: [GHC] #2516: Panic in typechecker when checking rules In-Reply-To: <044.97a677f639e2eedc3bb7f676ec672915@localhost> References: <044.97a677f639e2eedc3bb7f676ec672915@localhost> Message-ID: <053.65bbc964ab8780c4d98c97c95fdae1f2@localhost> #2516: Panic in typechecker when checking rules -------------------------------------+-------------------------------------- Reporter: josef | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------------+-------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Several things going on here. First, I've already fixed a bug in typechecking for rules, so it doesn't crash any more. Second, see #2497; you need `-XScopedTypeVariables -XRankNTypes -XPatternSignatures`; that will improve shortly. At that point, with the HEAD and those flags we get: {{{ T2516.hs:9:15: Couldn't match expected type `[]' against inferred type `f' `f' is a rigid type variable bound by the type signature for `g' at T2516.hs:8:23 In the first argument of `foo', namely `g' In the first argument of `head', namely `(foo g)' When checking the transformation rule "bug1" T2516.hs:9:15: Couldn't match expected type `a1' against inferred type `a' `a1' is a rigid type variable bound by the polymorphic type `forall a1. a1 -> [a1]' at T2516.hs:9:11 `a' is a rigid type variable bound by the type signature for `g' at T2516.hs:8:18 In the first argument of `foo', namely `g' In the first argument of `head', namely `(foo g)' When checking the transformation rule "bug1" }}} And indeed that's right. What you wanted in `GHCBug1` is this: {{{ {-# RULES "bug1" forall (g :: forall a. a -> [a]) . head (foo g) = undefined #-} }}} Note the `forall` in the type of `g`, and the `[a]` instead of `f a`. Then all is cool. So I'll close this as a dup of #2497. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 19 09:05:29 2008 From: trac at galois.com (GHC) Date: Tue Aug 19 09:04:29 2008 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.9d0c0abe6c876bbd510672823c1bc919@localhost> #1338: base package breakup ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by simonmar): Replying to [comment:18 igloo]: > One advantage of making base small is that if you are, for example, debugging GHC.Handle then you don't have to recompile >100 other modules every time you make a change in it. All the other advantages are good, but this one is false I think. If you modify `GHC.Handle` you do have to recompile all the modules above it in the hierarchy, regardless of whether they're in another package or not. GHC may be able to avoid actual recompilation, but you at least need to invoke GHC on every module. (currently the build system doesn't do this except within a package, which is bad, and something we hope to fix). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 19 09:09:32 2008 From: trac at galois.com (GHC) Date: Tue Aug 19 09:08:30 2008 Subject: [GHC] #2456: Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." In-Reply-To: <046.de0b35ad5d95f2dbcea756cdc13c675e@localhost> References: <046.de0b35ad5d95f2dbcea756cdc13c675e@localhost> Message-ID: <055.a75d570ad36738535f8f23b1be9390a1@localhost> #2456: Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." ----------------------+----------------------------------------------------- Reporter: ronwalf | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Excellent point. That is bad. I'll fix. Meanwhile, in both cases you have {{{ deriving instance Data (Expr Const) deriving instance Data (Expr Var) }}} Question: do you really want this? You're generating more or less the same code twice. Why not write this? {{{ deriving instance Data a => Data (Expr a) }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 19 09:12:57 2008 From: trac at galois.com (GHC) Date: Tue Aug 19 09:11:55 2008 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.f826842b519e5297279e492e6652d4b1@localhost> #1338: base package breakup ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by igloo): Replying to [comment:21 simonmar]: > Replying to [comment:18 igloo]: > > One advantage of making base small is that if you are, for example, debugging GHC.Handle then you don't have to recompile >100 other modules every time you make a change in it. > > All the other advantages are good, but this one is false I think. If you modify `GHC.Handle` you do have to recompile all the modules above it in the hierarchy, regardless of whether they're in another package or not. Let me try to clarify: If you're debugging `GHC.Handle` then you don't need to recompile, for example, `GetOpt` after adding a debugging print or when you want to test a fix. Once you've actually fixed the bug you'll need to recompile everything so that the other libraries all work again, agreed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 19 09:19:17 2008 From: trac at galois.com (GHC) Date: Tue Aug 19 09:18:14 2008 Subject: [GHC] #2456: Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." In-Reply-To: <046.de0b35ad5d95f2dbcea756cdc13c675e@localhost> References: <046.de0b35ad5d95f2dbcea756cdc13c675e@localhost> Message-ID: <055.5c4b93473c1eb2461688d71e55912459@localhost> #2456: Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." ----------------------+----------------------------------------------------- Reporter: ronwalf | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by ronwalf): In this case, (a) has the wrong kind (*->*), so trying that line gives: #WouterTest2.hs:396:39: Kind mis-match Expected kind `* -> *', but `a' has kind `*' In the type `Expr a' In the type `(Data a) => Data (Expr a)' In the stand-alone deriving instance for `(Data a) => Data (Expr a)' -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 19 11:33:19 2008 From: trac at galois.com (GHC) Date: Tue Aug 19 11:32:45 2008 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.84bc118f6b5f0658fb4d8bc92351af2c@localhost> #1876: Complete shared library support ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by mafo): * cc: mafo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 19 14:59:43 2008 From: trac at galois.com (GHC) Date: Tue Aug 19 14:58:41 2008 Subject: [GHC] #2523: Improve warnings for use of "forall" without -XExistentialQuantification Message-ID: <046.291e52922a77a998047387786dd32e52@localhost> #2523: Improve warnings for use of "forall" without -XExistentialQuantification ------------------------+--------------------------------------------------- Reporter: dmhouse | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Here's a GHCi session: {{{ Prelude> let foo :: forall a. a; foo = undefined :1:19: Illegal operator `.' in type `forall a . a' (Use -XTypeOperators to allow operators in types) Prelude> let foo :: forall a. Show a => a; foo = undefined :1:28: parse error on input `=>' }}} Both of these errors could be improved, I think, by detecting the use of 'forall' as a type variable name, and suggesting -XExistentialQuantification if it's being used. -- Ticket URL: GHC The Glasgow Haskell Compiler From simonpj at microsoft.com Wed Aug 20 05:57:17 2008 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Aug 20 05:56:13 2008 Subject: [Haskell] Is this a feature or bug in the GADTs & ExistentialQuantification? (Was: [Haskell-cafe] Unboxing VT_VARIANT in hscom) In-Reply-To: References: Message-ID: <638ABD0A29C8884A91BC5FB5C349B1C32AE853DA68@EA-EXMSG-C334.europe.corp.microsoft.com> (Redirecting to ghc-bugs.) Krasimir, Praki | The issue reported by Praki looks like a GHC bug to me. I have compiled the two modules below with 6.8.3 and with the HEAD; both are fine. If you have a reproducible case that fails, do please submit a Trac report. With HEAD you do need to add a type signature to useVariant :: Variant -> IO (), but then it's fine. The code I used is below. Simon | The smallest test case is at the end. (VarType a) is a GADT and | Variant wraps the VarType with a value of type a. The definitions of | Variant and VarType require ExistentialQuantification and GADTs | extensions and I have declared them. The problem is when someone try | to use them. | | If the client code is compiled without any extensions turned on the | error message is: | | >> test.hs:35:47: | >> Couldn't match expected type `IDispatch a' | >> against inferred type `a1' | >> `a1' is a rigid type variable bound by | >> the constructor `Variant' at test.hs:34:22 | >> In the second argument of `getMethodID', namely `idisp' | >> In a 'do' expression: dispId <- getMethodID "ExecQuery" idisp | >> In the expression: | >> do dispId <- getMethodID "ExecQuery" idisp | >> return () | | This suggests that the compiler understands that Variant is an | existential type but doesn't understand that VarType is a GADT. If the | code is compiled with -fglasgow-exts then everything works fine. Why | the compiler always understands existential types and not GADT. For me | this is unfair against GADT. Shouldn't the compiler always understand | GADT as well provided that they are already defined somewhere? | | Best Regards, | Krasimir | | ------------------------------------------------------------------------------ | -- Implementation of Variant | ------------------------------------------------------------------------------ | | {-# LANGUAGE ExistentialQuantification, GADTs #-} | module Variant where | | data VarType a where | VT_DISPATCH :: VarType IDispatch | | data IDispatch = IDispatch | | data Variant = forall a . Variant (VarType a) a | | | ------------------------------------------------------------------------------ | -- Use of Variant | ------------------------------------------------------------------------------ | | import Variant | | useIDispatch :: IDispatch -> IO () | useIDispatch _ = putStrLn "useIDispatch" | | useVariant :: Variant -> IO () | useVariant (Variant VT_DISPATCH idisp) = useIDispatch idisp From trac at galois.com Wed Aug 20 07:10:38 2008 From: trac at galois.com (GHC) Date: Wed Aug 20 07:09:34 2008 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.f9458ed31facc5d4664ed7509c93c446@localhost> #1338: base package breakup ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by simonmar): Replying to [comment:22 igloo]: > Let me try to clarify: If you're debugging `GHC.Handle` then you don't need to recompile, for example, `GetOpt` after adding a debugging print or when you want to test a fix. > > Once you've actually fixed the bug you'll need to recompile everything so that the other libraries all work again, agreed. Ok, I see what you meant. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 20 07:39:01 2008 From: trac at galois.com (GHC) Date: Wed Aug 20 07:37:58 2008 Subject: [GHC] #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@localhost> References: <044.c09df8f4b72158c8c14035187a5540c9@localhost> Message-ID: <053.ea6b7232154463e2ac04830fb7c7aaba@localhost> #2182: ghc sessions (--make, --interactive, ghc api) erroneously retain instances ---------------------+------------------------------------------------------ Reporter: claus | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by claus): * summary: ghci session retains instances after :m -Module => ghc sessions (--make, --interactive, ghc api) erroneously retain instances Comment: (changed ticket title to reflect broader scope) This bug affects all ghc sessions, not just ghci. In particular: - Cabal uses `ghc --make`, which can fail because of this bug - Haddock 2 uses the ghc api, which can fail because of this bug In both cases, the workaround is to repeat the command, so that it continues with a fresh ghc session, but that will not at all be obvious to users. Example: {{{ $ darcs get http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/syb-utils Finished getting. $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.3 $ cd syb-utils/ $ runhaskell.exe Setup.hs configure Configuring syb-utils-0.0.2008.8.19... Warning: No license-file field. $ runhaskell.exe Setup.hs build Preprocessing library syb-utils-0.0.2008.8.19... Building syb-utils-0.0.2008.8.19... [1 of 6] Compiling Data.Generics.Instances.Dubious ( Data/Generics/Instances/Dubious.hs, dist\build/ Data/Generics/Instances/Dubious.o ) [2 of 6] Compiling Data.Generics.Utils ( Data/Generics/Utils.hs, dist\build/Data/Generics/Utils.o ) [3 of 6] Compiling Data.Generics.NoInstances ( Data/Generics/NoInstances.hs, dist\build/Data/Generic s/NoInstances.o ) [4 of 6] Compiling Data.Generics.GPS ( Data/Generics/GPS.hs, dist\build/Data/Generics/GPS.o ) [5 of 6] Compiling Data.Generics.Instances.Standard ( Data/Generics/Instances/Standard.hs, dist\buil d/Data/Generics/Instances/Standard.o ) Data/Generics/Instances/Standard.hs:61:0: Duplicate instance declarations: instance Data Bool -- Defined at Data/Generics/Instances/Standard.hs:(61,0)-(68,28) instance Data Bool -- Defined in Data.Generics.Instances .. $ runhaskell.exe Setup.hs build Preprocessing library syb-utils-0.0.2008.8.19... Building syb-utils-0.0.2008.8.19... [5 of 6] Compiling Data.Generics.Instances.Standard ( Data/Generics/Instances/Standard.hs, dist\buil d/Data/Generics/Instances/Standard.o ) [6 of 6] Compiling Data.Generics.Alt ( Data/Generics/Alt.hs, dist\build/Data/Generics/Alt.o ) c:\ghc\ghc-6.8.3\bin\ar.exe: creating dist\build\libHSsyb- utils-0.0.2008.8.19.a }}} Confusingly, the behaviour is compiler-version and tool dependent: {{{ $ runhaskell.exe Setup.hs clean cleaning... $ /cygdrive/c//fptools/ghc/ghc/stage2-inplace/ghc.exe --version The Glorious Glasgow Haskell Compilation System, version 6.9.20080816 $ runhaskell Setup configure --with- compiler=c:/fptools/ghc/ghc/stage2-inplace/ghc.exe --with-hc-pk g=c:/fptools/ghc/utils/ghc-pkg/install-inplace/bin/ghc-pkg.exe --with- haddock=c:/Program\ Files/Has kell/bin/haddock.exe -fGhcApi Configuring syb-utils-0.0.2008.8.19... Warning: No license-file field. cr3@cr3-lt ~/tst/ghc-session-bug/syb-utils $ runhaskell.exe Setup.hs build Preprocessing library syb-utils-0.0.2008.8.19... Building syb-utils-0.0.2008.8.19... [1 of 9] Compiling Data.Generics.Instances.Dubious ( Data\Generics\Instances\Dubious.hs, dist\build\ Data\Generics\Instances\Dubious.o ) [2 of 9] Compiling Data.Generics.Instances.Standard ( Data\Generics\Instances\Standard.hs, dist\buil d\Data\Generics\Instances\Standard.o ) [3 of 9] Compiling Data.Generics.Utils ( Data\Generics\Utils.hs, dist\build\Data\Generics\Utils.o ) [4 of 9] Compiling Data.Generics.NoInstances ( Data\Generics\NoInstances.hs, dist\build\Data\Generic s\NoInstances.o ) [5 of 9] Compiling Data.Generics.GPS ( Data\Generics\GPS.hs, dist\build\Data\Generics\GPS.o ) [6 of 9] Compiling Data.Generics.Alt ( Data\Generics\Alt.hs, dist\build\Data\Generics\Alt.o ) [7 of 9] Compiling GHC.Syb.Instances0 ( GHC\Syb\Instances0.hs, dist\build\GHC\Syb\Instances0.o ) [8 of 9] Compiling GHC.Syb.Instances ( GHC\Syb\Instances.hs, dist\build\GHC\Syb\Instances.o ) [9 of 9] Compiling GHC.Syb.Utils ( GHC\Syb\Utils.hs, dist\build\GHC\Syb\Utils.o ) c:\ghc\ghc-6.8.3\bin\ar.exe: creating dist\build\libHSsyb- utils-0.0.2008.8.19.a }}} Note that ghc head and ghc 6.8.3 process the dependencies in a different order, which probably explains why the bug isn't triggered in head: `Data.Generics.Instances.Dubious` and `Data.Generics.Instances.Standard` represent two halves of `base`'s `Data.Generics.Instances`; the latter isn't explicitly imported here, but `Data.Generics.GPS` uses `Data.IntMap`, which inadvertedly re-exports the instances from `Data.Generics.Instances`. If `Data.Generics.Instances.*` are compiled first, ghc doesn't complain about alternative instances being present, but if either of `Data.Generics.Instances.*` is compiled after `Data.Generics.GPS`, the erroneously retained instances conflict with the newly defined ones. We can confirm the bug is still there by trying to haddock2 the package with a fresh darcs haddock, freshly compiled with the same ghc head: {{{ $ runhaskell.exe Setup.hs clean cleaning... $ /cygdrive/c/Program\ Files/Haskell/bin/haddock.exe --version Haddock version 2.2.2, (c) Simon Marlow 2006 Ported to use the GHC API by David Waern 2006-2008 $ /cygdrive/c/Program\ Files/Haskell/bin/haddock.exe +RTS --info [("GHC RTS", "Yes") ,("GHC version", "6.9.20080816") ,("RTS way", "rts") ,("Host platform", "i386-unknown-mingw32") ,("Build platform", "i386-unknown-mingw32") ,("Target platform", "i386-unknown-mingw32") ,("Compiler unregisterised", "NO") ,("Tables next to code", "YES") ] $ runhaskell Setup configure --with- compiler=c:/fptools/ghc/ghc/stage2-inplace/ghc.exe --with-hc-pk g=c:/fptools/ghc/utils/ghc-pkg/install-inplace/bin/ghc-pkg.exe --with- haddock=c:/Program\ Files/Haskell/bin/haddock.exe -fGhcApi Configuring syb-utils-0.0.2008.8.19... Warning: No license-file field. cr3@cr3-lt ~/tst/ghc-session-bug/syb-utils $ runhaskell.exe Setup.hs haddock Preprocessing library syb-utils-0.0.2008.8.19... Running Haddock for syb-utils-0.0.2008.8.19... Preprocessing library syb-utils-0.0.2008.8.19... Warning: Cannot read c:\fptools\ghc\compiler\dist- stage2\doc\html\ghc\ghc.haddock: "Magic number mismatch: couldn't load interface file: c:\\fptools\\ghc\\compiler\\dist-stage2\\doc\\html\\ghc\\ghc.haddock" Skipping this interface. Warning: Cannot read c:\fptools\ghc\libraries\base\dist\doc\html\base\base.haddock: "Magic number mismatch: couldn't load interface file: c:\\fptools\\ghc\\libraries\\base\\dist\\doc\\html\\base\\base.haddock" Skipping this interface. Warning: Cannot read c:\fptools\ghc\libraries\containers\dist\doc\html\containers\containers.haddock : "Magic number mismatch: couldn't load interface file: c:\\fptools\\ghc\\libraries\\containers\\dist\\doc\\html\\containers\\containers.haddock" Skipping this interface. Data\Generics\Instances\Dubious.hs:59:9: Duplicate instance declarations: instance (Data a, Integral a) => Data (Ratio a) -- Defined at Data\Generics\Instances\Dubious.hs:59:9-46 instance (Data a, Integral a) => Data (Ratio a) -- Defined in Data.Generics.Instances .. $ runhaskell.exe Setup.hs haddock Preprocessing library syb-utils-0.0.2008.8.19... Running Haddock for syb-utils-0.0.2008.8.19... Preprocessing library syb-utils-0.0.2008.8.19... Warning: Cannot read c:\fptools\ghc\compiler\dist- stage2\doc\html\ghc\ghc.haddock: "Magic number mismatch: couldn't load interface file: c:\\fptools\\ghc\\compiler\\dist-stage2\\doc\\html\\ghc\\ghc.haddock" Skipping this interface. Warning: Cannot read c:\fptools\ghc\libraries\base\dist\doc\html\base\base.haddock: "Magic number mismatch: couldn't load interface file: c:\\fptools\\ghc\\libraries\\base\\dist\\doc\\html\\base\\base.haddock" Skipping this interface. Warning: Cannot read c:\fptools\ghc\libraries\containers\dist\doc\html\containers\containers.haddock : "Magic number mismatch: couldn't load interface file: c:\\fptools\\ghc\\libraries\\containers\\dist\\doc\\html\\containers\\containers.haddock" Skipping this interface. Warning: in export list of "Data.Generics.NoInstances": module not found: "Data.Generics.Basics" Warning: in export list of "Data.Generics.NoInstances": module not found: "Data.Generics.Aliases" Warning: in export list of "Data.Generics.NoInstances": module not found: "Data.Generics.Schemes" Warning: in export list of "Data.Generics.NoInstances": module not found: "Data.Generics.Text" Warning: in export list of "Data.Generics.NoInstances": module not found: "Data.Generics.Twins" Warning: in export list of "Data.Generics.Alt": module not found: "Data.Generics.Basics" Warning: in export list of "Data.Generics.Alt": module not found: "Data.Generics.Aliases" Warning: in export list of "Data.Generics.Alt": module not found: "Data.Generics.Schemes" Warning: in export list of "Data.Generics.Alt": module not found: "Data.Generics.Text" Warning: in export list of "Data.Generics.Alt": module not found: "Data.Generics.Twins" Warning: syb-utils-0.0.2008.8.19:GHC.Syb.Instances: could not find link destinations for: Data.Typeable.TyCon Warning: syb-utils-0.0.2008.8.19:GHC.Syb.Instances0: could not find link destinations for: Data.Typeable.TyCon Warning: syb-utils-0.0.2008.8.19:GHC.Syb.Utils: could not find link destinations for: GHC.Classes.Eq GHC.Classes.Ord GHC.Show.Show Data.Generics.Basics.Data GHC.Types.Int GHC.Base.St ring Data.Generics.Aliases.GenericQ GHC.Bool.Bool Warning: syb-utils-0.0.2008.8.19:Data.Generics.GPS: could not find link destinations for: Data.Generics.Basics.Data Data.Generics.Aliases.GenericQ Data.Typeable.Typeable Data.Typeable.Typeable1 Data.Maybe.Maybe Data.IntMap.IntMap Data.IntSet.IntSet GHC.Types.Int Data.Generics.Aliases.GenericT Warning: syb-utils-0.0.2008.8.19:Data.Generics.Utils: could not find link destinations for: Control.Applicative.Applicative Data.Typeable.Typeable1 Data.Typeable.Typeable Data.Generics.Basics.Data Data.Generics.Utils.X Warning: syb-utils-0.0.2008.8.19:Data.Generics.Instances.Standard: could not find link destinations for: Data.Typeable.TyCon Documentation created: dist\doc\html\syb-utils\index.html }}} What are the chances of getting this fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 20 08:09:22 2008 From: trac at galois.com (GHC) Date: Wed Aug 20 08:08:22 2008 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.7a5b33c7ad767d981374c5becac028ca@localhost> #1338: base package breakup ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by dreixel): * cc: jpm@cs.uu.nl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 20 13:45:27 2008 From: trac at galois.com (GHC) Date: Wed Aug 20 13:44:21 2008 Subject: [GHC] #2524: GHCi linking error with Gtk2Hs. Message-ID: <044.59cb7e8fce12e9938c333af90a352411@localhost> #2524: GHCi linking error with Gtk2Hs. -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Windows -----------------------+---------------------------------------------------- Starting ghci interpreter with '-package gtk' option results in this linking error: {{{ GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading package mtl-1.1.0.1 ... linking ... done. : Unknown PEi386 section name '.reloc' (while processing: F:/Gtk2Hs/HSglib.o) Loading package glib-0.9.13 ... : panic! (the 'impossible' happened) (GHC version 6.8.3 for i386-unknown-mingw32): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I use Windows XP Home SP2 with last updates, and GHC / Gtk2Hs installers from this site. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 20 14:49:50 2008 From: trac at galois.com (GHC) Date: Wed Aug 20 14:48:44 2008 Subject: [GHC] #2525: maps created by Data.Map.fromAscList fail lookup on some keys present Message-ID: <044.b97aac9fa56a03f5fa0cd64033c2481b@localhost> #2525: maps created by Data.Map.fromAscList fail lookup on some keys present -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- {{{ import Data.Map member "foo" $ fromAscList [("foo", True), ("bar", False)] }}} The above expression evaluates to False, when it should clearly be True. This works fine when fromList is used instead. Tested on 6.8.2, but I don't see anything in the release notes vaguely related for 6.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 20 15:13:01 2008 From: trac at galois.com (GHC) Date: Wed Aug 20 15:11:56 2008 Subject: [GHC] #2525: maps created by Data.Map.fromAscList fail lookup on some keys present In-Reply-To: <044.b97aac9fa56a03f5fa0cd64033c2481b@localhost> References: <044.b97aac9fa56a03f5fa0cd64033c2481b@localhost> Message-ID: <053.d6ce839a6d14c43a1ab8a5e172c961d1@localhost> #2525: maps created by Data.Map.fromAscList fail lookup on some keys present -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------------+-------------------------------------------- Comment (by tibbe): The documentation for `fromAscList` states: "O(n). Build a map from an ascending list in linear time. The precondition (input list is ascending) is not checked." Your list is descending. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 20 16:14:21 2008 From: trac at galois.com (GHC) Date: Wed Aug 20 16:13:15 2008 Subject: [GHC] #2526: warn about missing signatures only for exported functions Message-ID: <054.8d84f54fed1e47316e9d59e9281759fd@localhost> #2526: warn about missing signatures only for exported functions --------------------------------+------------------------------------------- Reporter: fergushenderson | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple --------------------------------+------------------------------------------- The -fno-warn-missing-signatures option results in warnings if signatures are not declared for any top-level functions. Many Haskell users prefer to declare type signatures only for exported functions, which are part of the module's interface, not for all functions. It would be nice to have an option that issued warnings iff any exported functions lacked explicit signatures. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 20 16:19:09 2008 From: trac at galois.com (GHC) Date: Wed Aug 20 16:18:03 2008 Subject: [GHC] #2527: all ghc language extensions should have their own flags Message-ID: <054.6833207c55960235d69c7f56ccbd1232@localhost> #2527: all ghc language extensions should have their own flags --------------------------------+------------------------------------------- Reporter: fergushenderson | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple --------------------------------+------------------------------------------- Right now, to enable some ghc features such as unboxed types, there is no way of doing so except with "-fglasgow-exts", which also enables every other ghc feature. It would be nice to have individual options for every ghc language extension, so that we can only enable the specific extensions that we want. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 20 18:57:50 2008 From: trac at galois.com (GHC) Date: Wed Aug 20 18:56:46 2008 Subject: [GHC] #2527: all ghc language extensions should have their own flags In-Reply-To: <054.6833207c55960235d69c7f56ccbd1232@localhost> References: <054.6833207c55960235d69c7f56ccbd1232@localhost> Message-ID: <063.bc418865330bd1f400469844332453e6@localhost> #2527: all ghc language extensions should have their own flags --------------------------------+------------------------------------------- Reporter: fergushenderson | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple --------------------------------+------------------------------------------- Comment (by duncan): Isn't this exactly what the language extensions given with the -X flags do? I was under the impression that as of ghc-6.8 there are no ghc extensions that are enabled just by -fglasgow-exts and don't have a specific language extension and corresponding -X flag. Were you thinking of any extensions in particular? Unboxed tuples uses the `UnboxedTuples` language extension, ie the `-XUnboxedTuples` ghc flag or a pragma `{#- LANGUAGE UnboxedTuples -#}` at the top of the module source file. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 20 22:48:22 2008 From: trac at galois.com (GHC) Date: Wed Aug 20 22:47:16 2008 Subject: [GHC] #2528: nub not as reliable as nubBy Message-ID: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> #2528: nub not as reliable as nubBy -------------------------+-------------------------------------------------- Reporter: jdressel | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Linux -------------------------+-------------------------------------------------- While working on a fun math/programming exercise I discovered a peculiar behavior in "nub". While it worked the vast majority of the time, there were a few cases where it failed to purge all duplicates as defined by (==). Replacing the use of "nub" with "nubBy (==)" correctly purged all cases. I have linked a codepad evaluation that outputs the strange behavior: http://codepad.org/VNauTAam I would have isolated the bug better for you, but like I say nub works by far the majority of the time. This must be a peculiar clash with my custom data structures and strange definition of (==). Cheers. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 20 23:32:20 2008 From: trac at galois.com (GHC) Date: Wed Aug 20 23:31:14 2008 Subject: [GHC] #2528: nub not as reliable as nubBy In-Reply-To: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> References: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> Message-ID: <056.cffbfe17674baf82d4f57ad189be5357@localhost> #2528: nub not as reliable as nubBy -------------------------+-------------------------------------------------- Reporter: jdressel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: invalid Keywords: | Testcase: Architecture: Unknown | Os: Linux -------------------------+-------------------------------------------------- Changes (by JeremyShaw): * status: new => closed * resolution: => invalid Comment: Your (==) instance is broken. Specifically, for: -- ((9+9)+2) a = Branch (Branch (Leaf (Just 9)) Add (Leaf (Just 9))) Add (Leaf (Just 2)) -- (9+(2+9)) b = Branch (Leaf (Just 9)) Add (Branch (Leaf (Just 2)) Add (Leaf (Just 9))) we see that: *Main> a == b True *Main> b == a False *Main> There may be other bugs as well, that is just the first instance I found. nubBy (==) will break as well, you just have not seen it yet. All instances of Eq must be transitive, reflexive, symmetric, and antisymmetric. Haskell can't automatically check this for you -- so it is left up the developer to do, either by formal proof, or by unit testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 03:30:42 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 03:29:35 2008 Subject: [GHC] #2527: all ghc language extensions should have their own flags In-Reply-To: <054.6833207c55960235d69c7f56ccbd1232@localhost> References: <054.6833207c55960235d69c7f56ccbd1232@localhost> Message-ID: <063.83a91a951be5466b27c438fa1785597a@localhost> #2527: all ghc language extensions should have their own flags -----------------------------+---------------------------------------------- Reporter: fergushenderson | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Indeed Duncan is right. Specifically, `-fglasgow-exts` sets the following flags, and that is its only effect {{{ Opt_PrintExplicitForalls , Opt_ForeignFunctionInterface , Opt_UnliftedFFITypes , Opt_GADTs , Opt_ImplicitParams , Opt_ScopedTypeVariables , Opt_UnboxedTuples , Opt_TypeSynonymInstances , Opt_StandaloneDeriving , Opt_DeriveDataTypeable , Opt_FlexibleContexts , Opt_FlexibleInstances , Opt_ConstrainedClassMethods , Opt_MultiParamTypeClasses , Opt_FunctionalDependencies , Opt_MagicHash , Opt_PolymorphicComponents , Opt_ExistentialQuantification , Opt_UnicodeSyntax , Opt_PostfixOperators , Opt_PatternGuards , Opt_LiberalTypeSynonyms , Opt_RankNTypes , Opt_ImpredicativeTypes , Opt_TypeOperators , Opt_RecursiveDo , Opt_ParallelListComp , Opt_EmptyDataDecls , Opt_KindSignatures , Opt_PatternSignatures , Opt_GeneralizedNewtypeDeriving , Opt_TypeFamilies ] }}} So I'll close this ticket. Fergus if some of these flags are too coarse- grained, open another ticket. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 05:04:29 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 05:03:22 2008 Subject: [GHC] #2528: nub not as reliable as nubBy In-Reply-To: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> References: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> Message-ID: <056.2f81e9afbd61405282ad1e262d45d586@localhost> #2528: nub not as reliable as nubBy -------------------------------+-------------------------------------------- Reporter: jdressel | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Linux -------------------------------+-------------------------------------------- Changes (by guest): * status: closed => reopened * component: Compiler => libraries/base * resolution: invalid => Comment: (From Adrian Hey) Well there still seems to be a problem, considering the what the library docs say about nubBy.. "The 'nubBy' function behaves just like 'nub', except it uses a user- supplied equality predicate instead of the overloaded '==' function." ..and nub was indeed originally defined as,.. {{{ nub=nubBy compare }}} ..as is the local nub in the example. So right or wrong, shouldn't we see the same result in each case? Here's the source of the problem I think: {{{ elem_by :: (a -> a -> Bool) -> a -> [a] -> Bool elem_by _ _ [] = False elem_by eq y (x:xs) = x `eq` y || elem_by eq y xs }}} vs. {{{ elem _ [] = False elem x (y:ys) = x==y || elem x ys }}} Also, where does the H98 report say all instances of Eq must be transitive, reflexive, symmetric, and antisymmetric? It just says "The Eq class provides equality (==)..", whatever that might mean :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 05:23:32 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 05:22:24 2008 Subject: [GHC] #2484: ghc 6.8.2 broken after Security Update 2008-005 (PPC) on Mac OS 10.4.11 In-Reply-To: <044.a2618a27f261a948044540a6bc0d6d47@localhost> References: <044.a2618a27f261a948044540a6bc0d6d47@localhost> Message-ID: <053.2cbc4690dba3eb4f80e4451dbe469ea0@localhost> #2484: ghc 6.8.2 broken after Security Update 2008-005 (PPC) on Mac OS 10.4.11 ----------------------+----------------------------------------------------- Reporter: knarF | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by thorkilnaur): With {{{System Version: Mac OS X 10.4.11 (8S165)}}} and {{{2008-08-10 17:14:36 +0200: Installed "Security Update 2008-005 (PowerPC)" (1.0)}}} I am not able to reproduce this: {{{ $ uname -a Darwin Thorkil-Naurs-Computer.local 8.11.0 Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007; root:xnu-792.24.17~1/RELEASE_PPC Power Macintosh powerpc $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 $ ghci randil.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( randil.hs, interpreted ) Ok, modules loaded: Main. *Main> main Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package random-1.0.0.0 ... linking ... done. open http://www.dilbert.com/fast/1997-03-08 *Main> :q Leaving GHCi. $ ghc --make randil.hs [1 of 1] Compiling Main ( randil.hs, randil.o ) Linking randil ... $ ./randil open http://www.dilbert.com/fast/2002-12-13 $ which runhaskell /Users/thorkilnaur/tn/install/ghc-6.8.2/bin/runhaskell $ runhaskell randil.hs open http://www.dilbert.com/fast/1997-04-03 $ chmod a+x randil.hs $ diff ../original/hackage.haskell.org/trac/ghc/attachment/ticket/2484/randil.hs\?format\=raw randil.hs 1c1 < #!/usr/local/bin/runhaskell --- > #!/Users/thorkilnaur/tn/install/ghc-6.8.2/bin/runhaskell $ ./randil.hs open http://www.dilbert.com/fast/2006-08-19 $ }}} Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 05:43:29 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 05:42:23 2008 Subject: [GHC] #2528: nub not as reliable as nubBy In-Reply-To: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> References: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> Message-ID: <056.f8b0b77d7bb3218096484ba4c8b264e7@localhost> #2528: nub not as reliable as nubBy -------------------------------+-------------------------------------------- Reporter: jdressel | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Linux -------------------------------+-------------------------------------------- Comment (by guest): (from Adrian Hey) Erm..that should be.. {{{ nub=nubBy (==) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 07:41:52 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 07:40:45 2008 Subject: [GHC] #2298: renameFile is not atomic on Windows In-Reply-To: <045.dd0669cd71e65d3d8109c8cabde31cb6@localhost> References: <045.dd0669cd71e65d3d8109c8cabde31cb6@localhost> Message-ID: <054.1fabb0697065e44a006cc588fcdb1cad@localhost> #2298: renameFile is not atomic on Windows ----------------------------+----------------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed. libraries/base: {{{ Mon Aug 18 08:59:50 PDT 2008 Simon Marlow * remove __hscore_renameFile, it is no longer uesd }}} libraries/directory: {{{ Wed Aug 20 07:01:24 PDT 2008 Simon Marlow * fix #2298: use MoveFileEx() on Windows }}} GHC itself: {{{ Thu Aug 21 03:04:36 PDT 2008 Simon Marlow * move directory after Win32/unix }}} libraries/Win32: {{{ Wed Aug 20 15:00:27 GMT Daylight Time 2008 Simon Marlow * Move -DUNICODE from cc-options into HsWin32.h, where it can do less damange }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 10:02:57 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 10:02:06 2008 Subject: [GHC] #2528: nub not as reliable as nubBy In-Reply-To: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> References: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> Message-ID: <056.7d1cae20b2b60ec53b51f675a6d92a60@localhost> #2528: nub not as reliable as nubBy -------------------------------+-------------------------------------------- Reporter: jdressel | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Linux -------------------------------+-------------------------------------------- Comment (by jdressel): Jeremy is correct: I forgot a case in my definition of (==) that makes it not completely symmetric for second layer commutative equivalence (oops). The relevant demonstration for the example case that failed in the linked codepaste is: {{{ *Main> let a = Branch (Branch (Leaf (Just 9)) Add (Leaf (Just 9))) Add (Leaf (Just 2)) *Main> let b = Branch (Leaf (Just 9)) Add (Branch (Leaf (Just 9)) Add (Leaf (Just 2))) *Main> a == b True *Main> b == a False *Main> List.nubBy (==) [a,b] [((9+9)+2)] *Main> List.nub [a,b] [((9+9)+2),(9+(9+2))] }}} I guess the lack of symmetry in (==) causes the difference in behavior, which makes more sense to me now. However, Adrian is also correct, the difference in behavior between "nub" and "nubBy (==)" is what startled me. I would have found the bug in my code eventually (especially after unit testing). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 10:04:24 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 10:03:16 2008 Subject: [GHC] #2529: deriving Read fails on infix data constructors with record syntax Message-ID: <042.9534959a7ba451df3c949a110c475056@localhost> #2529: deriving Read fails on infix data constructors with record syntax -----------------------+---------------------------------------------------- Reporter: spl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- The example below successfully performs the {{{show}}}, but {{{reads}}} returns an empty list. It fails in both GHCi and GHC. It succeeds if you replaces the infix symbol with a name. {{{ module Main where data A = (:<>:) { x :: Int, y :: Int } deriving (Read, Show) t :: A t = 1 :<>: 2 s :: String s = show t r :: [(A,String)] r = reads s main :: IO () main = do putStrLn s putStrLn (show r) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 10:05:38 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 10:04:35 2008 Subject: [GHC] #2529: deriving Read fails on infix data constructors with record syntax In-Reply-To: <042.9534959a7ba451df3c949a110c475056@localhost> References: <042.9534959a7ba451df3c949a110c475056@localhost> Message-ID: <051.486a773af2164be7de8e33867c1607c0@localhost> #2529: deriving Read fails on infix data constructors with record syntax -------------------------+-------------------------------------------------- Reporter: spl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- Changes (by spl): * cc: leather@cs.uu.nl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 10:29:22 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 10:28:16 2008 Subject: [GHC] #2529: deriving Read fails on infix data constructors with record syntax In-Reply-To: <042.9534959a7ba451df3c949a110c475056@localhost> References: <042.9534959a7ba451df3c949a110c475056@localhost> Message-ID: <051.9f3d61a8017fb6b4d75af13bd7bc3087@localhost> #2529: deriving Read fails on infix data constructors with record syntax -------------------------+-------------------------------------------------- Reporter: spl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- Comment (by spl): I suppose it would've been helpful to include GHCi output, though it is trivial: {{{ Prelude Main> main (:<>:) {x = 1, y = 2} [] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 10:40:23 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 10:39:44 2008 Subject: [GHC] #2523: Improve warnings for use of "forall" without -XExistentialQuantification In-Reply-To: <046.291e52922a77a998047387786dd32e52@localhost> References: <046.291e52922a77a998047387786dd32e52@localhost> Message-ID: <055.762988cf91a157847d0b853404104ad7@localhost> #2523: Improve warnings for use of "forall" without -XExistentialQuantification ----------------------+----------------------------------------------------- Reporter: dmhouse | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Good idea. {{{ Prelude> let foo :: forall a. a; foo = undefined :1:19: Illegal operator `.' in type `forall a . a' Perhaps you intended to use -XRankNTypes or similar flag to enable explicit-forall syntax: forall . Prelude> }}} Patch is this {{{ Thu Aug 21 13:35:02 GMT Daylight Time 2008 simonpj@microsoft.com * Improve error message when 'forall' is not a keyword }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 10:48:49 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 10:47:41 2008 Subject: [GHC] #2456: Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." In-Reply-To: <046.de0b35ad5d95f2dbcea756cdc13c675e@localhost> References: <046.de0b35ad5d95f2dbcea756cdc13c675e@localhost> Message-ID: <055.e9e3b94c74f95b1dbf2d84efc1ed84b4@localhost> #2456: Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." ----------------------+----------------------------------------------------- Reporter: ronwalf | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by simonpj): I've fixed the original bug of duplicate symbols {{{ Wed Aug 20 13:07:51 GMT Daylight Time 2008 simonpj@microsoft.com * Fix Trac #2456: eliminate duplicate bindings when deriving }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 10:51:52 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 10:50:43 2008 Subject: [GHC] #2524: GHCi linking error with Gtk2Hs. In-Reply-To: <044.59cb7e8fce12e9938c333af90a352411@localhost> References: <044.59cb7e8fce12e9938c333af90a352411@localhost> Message-ID: <053.73658ebc36d60cfa40208e8bf759be0c@localhost> #2524: GHCi linking error with Gtk2Hs. ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ---------------------+------------------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks, we already fixed this one: #2405 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 11:04:53 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 11:03:44 2008 Subject: [GHC] #2528: nub not as reliable as nubBy In-Reply-To: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> References: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> Message-ID: <056.026c49caaa9cd06f0f867ff0c18443fb@localhost> #2528: nub not as reliable as nubBy ----------------------------+----------------------------------------------- Reporter: jdressel | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * status: reopened => new * difficulty: => Unknown * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 12:49:36 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 12:48:28 2008 Subject: [GHC] #2456: For higher kinds, instance declarations need quantification in the context In-Reply-To: <046.de0b35ad5d95f2dbcea756cdc13c675e@localhost> References: <046.de0b35ad5d95f2dbcea756cdc13c675e@localhost> Message-ID: <055.e6f628c41d1c1f64dcf3eb6bbf9679d8@localhost> #2456: For higher kinds, instance declarations need quantification in the context -----------------------------+---------------------------------------------- Reporter: ronwalf | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | -----------------------------+---------------------------------------------- Changes (by simonpj): * summary: Generics compilation problem: "FATAL:Symbol _XJv_srt already defined." => For higher kinds, instance declarations need quantification in the context * type: bug => feature request * milestone: => _|_ Comment: However, concerning your comment above, I had missed the fact that `Expr` has kind `(*->*) -> *`. What you ''really'' want to say is: {{{ deriving instance (forall a. Data a => Data (f a)) => Data (Expr f) }}} Notice that the context of the instance has a nested `forall`. This has been a long-standing want; see [http://research.microsoft.com/%7Esimonpj/Papers/derive.htm Derivable type classes], Section 7. So I'll retitle this ticket as a feature request for such a feature. But don't hold your breath. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 12:49:59 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 12:48:56 2008 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax Message-ID: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> #2530: deriving Show adds extra parens for constructor with record syntax -----------------------+---------------------------------------------------- Reporter: spl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- Since record construction binds more tightly than function application, no parentheses are needed when passing a constructor with record syntax to a function constructor. As a result, we can pass {{{Just A {x = 5}}}} as shown below. {{{ module Main where data A = A {x :: Int} deriving (Show) main :: IO () main = print $ Just A {x = 5} }}} But we get the result in the GHCi session below: {{{ *Main> main Just (A {x = 5}) }}} I tried looking through {{{TcGenDeriv}}}, but didn't figure out quite where the parenifying was done. {{{nested_compose_Expr}}}? {{{show_thingies}}}? I just wanted to make a ticket for general knowledge. Of course, this is not a real bug. Perhaps you could reclassify it as a feature. Either way, it would be nice to have. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 12:59:05 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 12:57:59 2008 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> References: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> Message-ID: <051.04036dcdc9b19de67d1233eb00215f2d@localhost> #2530: deriving Show adds extra parens for constructor with record syntax ----------------------+----------------------------------------------------- Reporter: spl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: True. But I '''hate''' the fact that record construction binds more tightly than application. There's no harm in the extra parens, and I think they make it easier to read. So can we close this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 13:10:26 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 13:09:23 2008 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> References: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> Message-ID: <051.1ba7f20f47da1d0383c0805eac6896c4@localhost> #2530: deriving Show adds extra parens for constructor with record syntax ----------------------+----------------------------------------------------- Reporter: spl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by NeilMitchell): Hugs does the opposite, which is a bit of a shame, as it means Hugs and GHC versions of a program do not produce the same output. Perhaps the Haskell' report should legislate on the "suggested" printing of a record. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 13:18:55 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 13:17:49 2008 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> References: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> Message-ID: <051.762a5c5680ef4b3aacaf028373274c68@localhost> #2530: deriving Show adds extra parens for constructor with record syntax ----------------------+----------------------------------------------------- Reporter: spl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by spl): I agree with Neil in that it is a shame it isn't standardized. I found it, because I'm writing a generic version of Show, and I'd like my output to be equivalent to GHC's for an added comfort level of testing. I'm fine with being overruled. As I said, it is simply a "nice-to-have." -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 16:46:09 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 16:45:45 2008 Subject: [GHC] #2528: nub not as reliable as nubBy In-Reply-To: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> References: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> Message-ID: <056.dd3644222cf71f8a29fe0986e64a4d51@localhost> #2528: nub not as reliable as nubBy ----------------------------+----------------------------------------------- Reporter: jdressel | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Comment (by JeremyShaw): Replying to [comment:2 guest]: > (From Adrian Hey) > > Well there still seems to be a problem, considering the what the library docs say about nubBy.. hrm, interesting. I am guessing that even with 'valid' Eq instances that could be important due to laziness and bottom? > Also, where does the H98 report say all instances of Eq must be transitive, reflexive, symmetric, and antisymmetric? It just says "The Eq class provides equality (==)..", whatever that might mean :-) Well, it does not say it explicitly, but I suspect H98's usage of Eq implicitly demands those laws be followed. Hopefully in Haskell' the laws will not only be stated, but there will be some QuickCheck-style properties you can use to test your own instances ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 17:10:22 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 17:09:13 2008 Subject: [GHC] #2475: debugger gives "Can't unify" when stopped at an exception In-Reply-To: <044.67056a89ea8901dff63b307a4127f5ba@localhost> References: <044.67056a89ea8901dff63b307a4127f5ba@localhost> Message-ID: <053.438a5692bbaf1b95a638e051c053c2cc@localhost> #2475: debugger gives "Can't unify" when stopped at an exception ------------------------------------------+--------------------------------- Reporter: igloo | Owner: mnislaih Type: bug | Status: assigned Priority: normal | Milestone: 6.10.1 Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: break011, break017, break024 | Architecture: Unknown Os: Unknown | ------------------------------------------+--------------------------------- Changes (by guest): * testcase: break011, break024 => break011, break017, break024 Comment: Also break017 Igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 17:57:24 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 17:56:15 2008 Subject: [GHC] #2531: Prune duplicates in ghci history Message-ID: <045.a0871c51adeff1456b5bd9c24f43a05b@localhost> #2531: Prune duplicates in ghci history --------------------------------+------------------------------------------- Reporter: venkat | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- When we enter the same expressions in ghci, all of them go in to history. It'd be useful to have an option to eliminate duplicate expressions before storing them in ghci history. We can also consider doing this for storing ghci history as a file. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 20:48:22 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 20:47:18 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.44ec11a820181101ee9d13606520fc58@localhost> #2337: Data.Array documentation utterly broken ---------------------------+------------------------------------------------ Reporter: japple | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by japple): * status: closed => reopened * version: 6.8.2 => 6.8.3 * resolution: invalid => Comment: We should not wait for Haddock to be fixed to get this fixed. If Haddock can't generate the proper documentation for symbols exported from another package, the GHC documentation should be generated from the appropriate package. If the main repository for documentation of the standard library does not document how arrays are used, I would venture to say that your language does not really support arrays. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 20:59:01 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 20:57:51 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.dfb952c33a3b0122046827d1fc9ecbfd@localhost> #2337: Data.Array documentation utterly broken ---------------------------+------------------------------------------------ Reporter: japple | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Comment (by japple): I mean "one's language", not "your language". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 21:23:56 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 21:22:44 2008 Subject: [GHC] #2532: Add Typeable instance to Data.Unique Message-ID: <045.cab33c7b39a6b1cefa6bbdc4f3dc0833@localhost> #2532: Add Typeable instance to Data.Unique -------------------------+-------------------------------------------------- Reporter: japple | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Data.Unique should be able to be used with Data.Dynamic. Timescale for consideration: Until September 7, 2008. The [http://www.haskell.org/haskellwiki/Library_submissions library submission procedures] say If the changes update Haddoc [sic] documentation, also attach the resulting Haddock-generated pages. Haddock fails on the file because of existing CPP commands. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 22:40:07 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 22:38:56 2008 Subject: [GHC] #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts Message-ID: <045.1b6e550f0033cafaf14d077da3af73bb@localhost> #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts -------------------------+-------------------------------------------------- Reporter: japple | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- The Prelude functions drop, take, and splitAt are unfailing (never call error). This patch changes the Data.List generic versions to behave the same way. At present, they call error on negative arguments. quickCheck (\x n -> take n x == genericTake n x) quickCheck (\x n -> drop n x == genericDrop n x) quickCheck (\x n -> splitAt n x == genericSplitAt n x) The library submission procedures say If the changes update Haddoc [sic] documentation, also attach the resulting Haddock-generated pages. Haddock fails on the file because of existing CPP commands. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 22:46:13 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 22:45:09 2008 Subject: [GHC] #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts In-Reply-To: <045.1b6e550f0033cafaf14d077da3af73bb@localhost> References: <045.1b6e550f0033cafaf14d077da3af73bb@localhost> Message-ID: <054.e8668a9ac936d7aef0fa5db19f8a89e8@localhost> #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts -------------------------------+-------------------------------------------- Reporter: japple | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Comment (by japple): Deadline: Sept 7 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 22:55:58 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 22:54:48 2008 Subject: [GHC] #2177: Can Data.Unique safely derive Typeable? In-Reply-To: <045.8724b926d6549afcfc85d1a3ada0af59@localhost> References: <045.8724b926d6549afcfc85d1a3ada0af59@localhost> Message-ID: <054.d9590da6cd19c13f3ffb8bb7c06a9037@localhost> #2177: Can Data.Unique safely derive Typeable? -----------------------------+---------------------------------------------- Reporter: japple | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by japple): See #2532. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 21 23:54:40 2008 From: trac at galois.com (GHC) Date: Thu Aug 21 23:53:31 2008 Subject: [GHC] #2534: Odd probable cause given by type checker Message-ID: <047.ed1af1376e750ad1e5dab7d0ee130215@localhost> #2534: Odd probable cause given by type checker -------------------------+-------------------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- In the following code, a function has been applied to zero arguments, which the type checker suggests is too many. {{{ Prelude> foldr (>>=) [] [] :1:6: Occurs check: cannot construct the infinite type: b = a -> b Probable cause: `>>=' is applied to too many arguments In the first argument of `foldr', namely `(>>=)' In the expression: foldr (>>=) [] [] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 22 00:18:13 2008 From: trac at galois.com (GHC) Date: Fri Aug 22 00:17:03 2008 Subject: [GHC] #2535: Bug fix for QuickCheck 1.1.0.0 Message-ID: <047.a94a8053354ba7fb4be42a9b053bccf3@localhost> #2535: Bug fix for QuickCheck 1.1.0.0 -------------------------+-------------------------------------------------- Reporter: patperry | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- There is currently a bug in "variant" that manifests itself in the coarbitrary function for Double and Float. It has been previously reported here: http://hackage.haskell.org/trac/ghc/ticket/2065 The attached patch fixes the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 22 09:56:10 2008 From: trac at galois.com (GHC) Date: Fri Aug 22 09:54:59 2008 Subject: [GHC] #2536: Flag for Making Type Signatures Mandatory Message-ID: <044.101fd6384c08a2fdff0997682079b641@localhost> #2536: Flag for Making Type Signatures Mandatory --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.8.3 | Severity: trivial Keywords: type signatures | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- I propose to add a flag to GHC to only compile programs that have type signatures for the defining equations. The purpose of this is to satisfy the belt and braces notion of programming and to also aid in teaching Haskell as a programming language. Calling GHC with the following ghc -ftypesignatures a.hs will reject a.hs if any of its definitions do not have type signatures. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 22 10:07:31 2008 From: trac at galois.com (GHC) Date: Fri Aug 22 10:06:20 2008 Subject: [GHC] #2536: Flag for Making Type Signatures Mandatory In-Reply-To: <044.101fd6384c08a2fdff0997682079b641@localhost> References: <044.101fd6384c08a2fdff0997682079b641@localhost> Message-ID: <053.e1411b3429712b00643eefbaa3606006@localhost> #2536: Flag for Making Type Signatures Mandatory ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.3 Severity: trivial | Resolution: Keywords: type signatures | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- Comment (by NeilMitchell): {{{-fwarn-missing-signatures -Werror}}} already does this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 22 20:17:21 2008 From: trac at galois.com (GHC) Date: Fri Aug 22 20:16:14 2008 Subject: [GHC] #2537: base3-compat: not installable Message-ID: <047.5108d27045064c237bdd5984a83223b5@localhost> #2537: base3-compat: not installable -------------------------+-------------------------------------------------- Reporter: clanehin | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- Due to missing LICENSE file. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 22 22:21:02 2008 From: trac at galois.com (GHC) Date: Fri Aug 22 22:19:53 2008 Subject: [GHC] #2538: Better error message for missing Rank2Types (or RankNTypes) flag Message-ID: <042.1a667f48d50ac64babcfbb21bf4e41d3@localhost> #2538: Better error message for missing Rank2Types (or RankNTypes) flag --------------------------------+------------------------------------------- Reporter: tim | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- For a rank-2 type signature when the {{{Rank2Types}}} language option isn't enabled, GHC gives: {{{ Illegal polymorphic or qualified type: (Data a) => a -> RnM a In the type signature for `rnVarsIn': rnVarsIn :: ((Data a) => a -> RnM a) -> [Vdef] -> Exp -> S.Set Var -> RnM ([Vdef], Exp) }}} It would be good to suggest using {{{-XRank2Types}}} or {{{-XRankNTypes}}}. (Sorry if this is already fixed; I don't have a working HEAD to test it with.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 23 19:26:25 2008 From: trac at galois.com (GHC) Date: Sat Aug 23 19:25:10 2008 Subject: [GHC] #2539: panic when using .o files from the wrong platform Message-ID: <042.341988b91b98ef1befd98d4359420bff@localhost> #2539: panic when using .o files from the wrong platform ------------------------+--------------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- When I moved a tarball of a haskell project from my linux box to a windows box, I forgot to delete the linux object files. GHC subsequently panicked when I tried to compile the project with the message "loadObj: failed". Obviously, this is a dumb thing for the user to do, but if practicable, it would be nice if GHC could handle it more gracefully. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 23 19:45:53 2008 From: trac at galois.com (GHC) Date: Sat Aug 23 19:44:43 2008 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> References: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> Message-ID: <051.fdf9699e5684f66348d244d597d4f835@localhost> #2530: deriving Show adds extra parens for constructor with record syntax ----------------------+----------------------------------------------------- Reporter: spl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by igloo): I agree with Simon (and I think it's a bug in the language that you don't need parens there). I also agree with Neil, that we should have consistency between implementations, and that the report should say what the output should be. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 24 08:31:19 2008 From: trac at galois.com (GHC) Date: Sun Aug 24 08:30:04 2008 Subject: [GHC] #2473: Data.Array.IO.Internals hidden in GHC6.8 for no good reason In-Reply-To: <044.3c74e42a68ae62a3562b4a333f1234f6@localhost> References: <044.3c74e42a68ae62a3562b4a333f1234f6@localhost> Message-ID: <053.40e9176c4e61130ff883389d250c605c@localhost> #2473: Data.Array.IO.Internals hidden in GHC6.8 for no good reason -------------------------------+-------------------------------------------- Reporter: ryani | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Done! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 24 15:06:58 2008 From: trac at galois.com (GHC) Date: Sun Aug 24 15:05:38 2008 Subject: [GHC] #2525: maps created by Data.Map.fromAscList fail lookup on some keys present In-Reply-To: <044.b97aac9fa56a03f5fa0cd64033c2481b@localhost> References: <044.b97aac9fa56a03f5fa0cd64033c2481b@localhost> Message-ID: <053.76d7e5e0b3c6b78548bbecd2b945d3d3@localhost> #2525: maps created by Data.Map.fromAscList fail lookup on some keys present ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: tibbe is right, so I'm closing the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 24 15:08:10 2008 From: trac at galois.com (GHC) Date: Sun Aug 24 15:06:51 2008 Subject: [GHC] #2536: Flag for Making Type Signatures Mandatory In-Reply-To: <044.101fd6384c08a2fdff0997682079b641@localhost> References: <044.101fd6384c08a2fdff0997682079b641@localhost> Message-ID: <053.571ec16f5eb2334d78d50a9d8d21efb8@localhost> #2536: Flag for Making Type Signatures Mandatory -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.3 Severity: trivial | Resolution: invalid Keywords: type signatures | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: As Neil says, you can already do this, so I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 24 15:09:00 2008 From: trac at galois.com (GHC) Date: Sun Aug 24 15:07:48 2008 Subject: [GHC] #2537: base3-compat: not installable In-Reply-To: <047.5108d27045064c237bdd5984a83223b5@localhost> References: <047.5108d27045064c237bdd5984a83223b5@localhost> Message-ID: <056.849b21228cf891041f004941b3210f99@localhost> #2537: base3-compat: not installable -------------------------------+-------------------------------------------- Reporter: clanehin | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Fixed, thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 24 16:54:15 2008 From: trac at galois.com (GHC) Date: Sun Aug 24 16:53:06 2008 Subject: [GHC] #2540: [Text.Regex] incorrect word boundary ("\\b") substitutions Message-ID: <045.dc1ce4d07a034cafda39a835d9bd9181@localhost> #2540: [Text.Regex] incorrect word boundary ("\\b") substitutions -------------------------------+-------------------------------------------- Reporter: Eelis- | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.8.3 | Severity: normal Keywords: regex | Testcase: Architecture: x86_64 (amd64) | Os: Unknown -------------------------------+-------------------------------------------- Consider: {{{ import Text.Regex main = putStrLn $ subRegex (mkRegex "\\b(.)") "abcdef" "|\\1" }}} This outputs "|a|b|c|d|e|f", while it really should output "|abcdef" (at least according to Perl and Ruby). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 24 16:59:27 2008 From: trac at galois.com (GHC) Date: Sun Aug 24 16:58:18 2008 Subject: [GHC] #2540: [Text.Regex] incorrect word boundary ("\\b") substitutions In-Reply-To: <045.dc1ce4d07a034cafda39a835d9bd9181@localhost> References: <045.dc1ce4d07a034cafda39a835d9bd9181@localhost> Message-ID: <054.843d8adf26ca124da9e742ca996663b0@localhost> #2540: [Text.Regex] incorrect word boundary ("\\b") substitutions ----------------------------------+----------------------------------------- Reporter: Eelis- | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: regex | Testcase: Architecture: x86_64 (amd64) | Os: Unknown ----------------------------------+----------------------------------------- Comment (by dons): Inconsitency between the regex.h C library, and PCRE? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 24 18:53:54 2008 From: trac at galois.com (GHC) Date: Sun Aug 24 18:52:36 2008 Subject: [GHC] #2541: ghc does call unlit from the right location Message-ID: <044.2a094f4ddd613be9112d0fc74a76efef@localhost> #2541: ghc does call unlit from the right location -----------------------+---------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Component: Driver Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- An installed version of ghc-6.9.20080824 does not call `unlit` correctly when compiling a literate Haskell file: {{{ $ ~/tmp/ghc-stage/bin/ghc Setup.lhs ghc: could not execute: /Users/judah/tmp/ghc- stage/share/ghc-6.9.20080824/./unlit $ find ~/tmp/ghc-stage/ -name unlit /Users/judah/tmp/ghc-stage//lib/ghc-6.9.20080824/unlit }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 24 18:54:49 2008 From: trac at galois.com (GHC) Date: Sun Aug 24 18:53:30 2008 Subject: [GHC] #2541: ghc does call unlit from the right location In-Reply-To: <044.2a094f4ddd613be9112d0fc74a76efef@localhost> References: <044.2a094f4ddd613be9112d0fc74a76efef@localhost> Message-ID: <053.0115b103fca0d051d665bc1c83f4db20@localhost> #2541: ghc does call unlit from the right location -----------------------+---------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- Comment (by judah): Sorry, the title should say "ghc does NOT call unlit from the right location". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 24 19:06:38 2008 From: trac at galois.com (GHC) Date: Sun Aug 24 19:05:18 2008 Subject: [GHC] #2542: runghc does not infer module file extensions Message-ID: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> #2542: runghc does not infer module file extensions ------------------------+--------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- In ghc-6.8 (and possibly earlier), `runghc` will infer the extension of a module filename if it is not specified at the command line. This feature lets us type, for example, {{{runghc Setup configure}}} without worrying whether there's a `Setup.lhs` or `Setup.hs` file present. For example: {{{ $ cat Useful.hs main = putStrLn "Hello, world" $ runghc Useful Hello, world }}} However, this does not work for ghc-6.9.20080824: {{{ $ ~/tmp/ghc-stage/bin/runghc Useful : can't find file: Useful $ ~/tmp/ghc-stage/bin/runghc Useful.hs Hello, world }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 24 19:13:11 2008 From: trac at galois.com (GHC) Date: Sun Aug 24 19:11:53 2008 Subject: [GHC] #2541: ghc does call unlit from the right location In-Reply-To: <044.2a094f4ddd613be9112d0fc74a76efef@localhost> References: <044.2a094f4ddd613be9112d0fc74a76efef@localhost> Message-ID: <053.0fb37b0c447dc267b7626dc9e2c3478e@localhost> #2541: ghc does call unlit from the right location ---------------------+------------------------------------------------------ Reporter: judah | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ---------------------+------------------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 24 19:14:59 2008 From: trac at galois.com (GHC) Date: Sun Aug 24 19:13:40 2008 Subject: [GHC] #2542: runghc does not infer module file extensions In-Reply-To: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> References: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> Message-ID: <053.b1d6fcd550711c486ee26c8ca12549de@localhost> #2542: runghc does not infer module file extensions ----------------------+----------------------------------------------------- Reporter: judah | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 24 19:32:51 2008 From: trac at galois.com (GHC) Date: Sun Aug 24 19:31:44 2008 Subject: [GHC] #2540: [Text.Regex] incorrect word boundary ("\\b") substitutions In-Reply-To: <045.dc1ce4d07a034cafda39a835d9bd9181@localhost> References: <045.dc1ce4d07a034cafda39a835d9bd9181@localhost> Message-ID: <054.98e02ff3a04a2743f64f1ca7d7c34f01@localhost> #2540: [Text.Regex] incorrect word boundary ("\\b") substitutions -------------------------------+-------------------------------------------- Reporter: Eelis- | Owner: TextRegexLazy@personal.mightyreason.com Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: regex | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * owner: => TextRegexLazy@personal.mightyreason.com * difficulty: => Unknown * milestone: => Not GHC Comment: I'd expect it to do the same things as sed: {{{ $ echo "abcdef" | sed -r 's/\b(.)/|\1/g' |abcdef }}} i.e. it looks like a bug to me. Looks like the problem is how `subRegex` recurses on what comes after the match (`trail`): {{{ case matchRegexAll regexp inp of Nothing -> inp Just (lead, match, trail, groups) -> lead ++ lookup match repl groups ++ (subRegex regexp trail repl) }}} Christopher, I've assigned it to you as the regex libraries maintainer. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 24 20:24:36 2008 From: trac at galois.com (GHC) Date: Sun Aug 24 20:23:19 2008 Subject: [GHC] #2542: runghc does not infer module file extensions In-Reply-To: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> References: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> Message-ID: <053.fd08ffe463335ffc9228ecd7385dca75@localhost> #2542: runghc does not infer module file extensions ----------------------+----------------------------------------------------- Reporter: judah | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by duncan): It's pretty important that this works. We document all over the place that people should use `runghc Setup blah`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 25 06:29:06 2008 From: trac at galois.com (GHC) Date: Mon Aug 25 06:27:57 2008 Subject: [GHC] #2540: [Text.Regex] incorrect word boundary ("\\b") substitutions. Bug in regex-compat's subRegex handling of BOL flags. In-Reply-To: <045.dc1ce4d07a034cafda39a835d9bd9181@localhost> References: <045.dc1ce4d07a034cafda39a835d9bd9181@localhost> Message-ID: <054.d2287114b163e181df82a00b8b572df2@localhost> #2540: [Text.Regex] incorrect word boundary ("\\b") substitutions. Bug in regex- compat's subRegex handling of BOL flags. --------------------------------+------------------------------------------- Reporter: Eelis- | Owner: ChrisKuklewicz Type: bug | Status: assigned Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: regex regex-compat | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------+------------------------------------------- Changes (by ChrisKuklewicz): * status: new => assigned * summary: [Text.Regex] incorrect word boundary ("\\b") substitutions => [Text.Regex] incorrect word boundary ("\\b") substitutions. Bug in regex-compat's subRegex handling of BOL flags. * owner: TextRegexLazy@personal.mightyreason.com => ChrisKuklewicz * architecture: x86_64 (amd64) => Multiple * keywords: regex => regex regex-compat * os: Unknown => Multiple Comment: Ah bollocks, there is a bug here but it is subtle. The above complaint is actually to do with the lack of support for GNU extensions to regex/sed. The regex-posix library expects to implement just the POSIX regular expressions and none of the different extensions. This is also consistent with the BSD sed. The actual c-library calls in regex-posix are regcomp and regexec (and regfree, regerror). In GNU regex/sed (I tested version 4.1.5 on linux) the \b means a word boundary. I assume that this is also the case in Perl and Ruby. Thus \b matches only at the front of the abcdef word for these systems. In POSIX sed the \b is not recognized as a known escape, but is accepted as a literal b. So it matches the bc in abcdef and is replaced by |c. On Mac OS 10.5.4 the equivalent to -r is -E and then: {{{ $ echo "abcdef" | sed -E 's/\b(.)/|\1/g' a|cdef }}} With ghc version 6.8.3 on OS X I get the same answer as POSIX sed {{{ Prelude> :m +Text.Regex Prelude Text.Regex> subRegex (mkRegex "\\b(.)") "abcdef" "|\\1" "a|cdef" }}} On linux I can reproduce the bug report: {{{ Prelude Text.Regex> subRegex (mkRegex "\\b(.)") "abcdef" "|\\1" "|a|b|c|d|e|f" }}} Note that man 3 regexec and man 7 regex on linux are not describing the \b behavior. It is mis-documented. But there is a further problem: Change \b to `^` and it is clear that Text.Regex is getting the wrong answer on all systems. On OS X: {{{ $ echo "abcdef" | sed -E 's/^(.)/|\1/' |abcdef Prelude Text.Regex> subRegex (mkRegex "^(.)") "abcdef" "|\\1" "|a|b|c|d|e|f" }}} So there is a bug to fix with respect to `^`. Fixing this may also accidentally fix the \b handling on GNU systems. I thought I had added enough 'execNotBOL' (REG_NOTBOL) flags to cover all these cases, but regex-compat's subRegex is not clearly not clever enough. I will update this bug report when there is a fixed version to announce. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 25 14:02:02 2008 From: trac at galois.com (GHC) Date: Mon Aug 25 14:01:10 2008 Subject: [GHC] #2541: ghc does call unlit from the right location In-Reply-To: <044.2a094f4ddd613be9112d0fc74a76efef@localhost> References: <044.2a094f4ddd613be9112d0fc74a76efef@localhost> Message-ID: <053.92223968edd3ba11982ba323f08d4941@localhost> #2541: ghc does call unlit from the right location ---------------------+------------------------------------------------------ Reporter: judah | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Driver | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ---------------------+------------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed * milestone: => 6.10.1 Comment: Thanks for the report; now fixed in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 25 14:03:48 2008 From: trac at galois.com (GHC) Date: Mon Aug 25 14:02:26 2008 Subject: [GHC] #2543: Nested SPECIALIZEd functions cause error: "Symbol _BadUTF8_zdf1_closure already defined." Message-ID: <044.e713affc75f221ae3449046e647f449d@localhost> #2543: Nested SPECIALIZEd functions cause error: "Symbol _BadUTF8_zdf1_closure already defined." -----------------------+---------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- The `utf8-string` package (in particular, the module `Code.Binary.UTF8.Generic`) does not compile under ghc-6.9.20080825. I tried stripping down that module and believe the problem occurs when a SPECIALIZEd function calls another SPECIALIZEd function: {{{ {-# LANGUAGE FlexibleInstances #-} module BadUTF8 where import Data.Word class UTF8Bytes b where instance UTF8Bytes [Word8] where {-# SPECIALIZE myfoldr :: (Char -> a -> a) -> a -> [Word8] -> a #-} myfoldr :: UTF8Bytes b => (Char -> a -> a) -> a -> b -> a myfoldr _ x _ = x {-# SPECIALIZE toString :: [Word8] -> String #-} toString :: UTF8Bytes b => b -> String toString bs = myfoldr (:) [] bs }}} Compiling using ghc-6.9.20080825 without -O, or ghc-6.8.3 with or without -O, does not produce an error. However, ghc-6.9.20080825 with optimization produces: {{{ judah-jacobsons-computer:tmp judah$ ~/tmp/ghc-stage/bin/ghc --make -O BadUTF8.hs [1 of 1] Compiling BadUTF8 ( BadUTF8.hs, BadUTF8.o ) /var/folders/Pm/Pm4yd68oG4qqe- gsgn56W++++TI/-Tmp-/ghc88501_0/ghc88501_0.s:81:0: FATAL:Symbol _BadUTF8_zdf1_closure already defined. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 25 15:57:46 2008 From: trac at galois.com (GHC) Date: Mon Aug 25 15:56:25 2008 Subject: [GHC] #2542: runghc does not infer module file extensions In-Reply-To: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> References: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> Message-ID: <053.d1d2c051893530ce210d0c598c3e2174@localhost> #2542: runghc does not infer module file extensions ----------------------+----------------------------------------------------- Reporter: judah | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * priority: normal => high * milestone: => 6.10.1 Comment: OK, I've (locally) fixed this for filenames like "foo.hs", but for "Setup.hs" (where "Setup" looks like a module name) we get: {{{ $ runghc Setup Setup.hs:2:7: File name does not match module name: Saw: `Main' Expected: `Setup' }}} which mirrors {{{ $ ghc --make Setup Setup.hs:2:7: File name does not match module name: Saw: `Main' Expected: `Setup' }}} This was a deliberate behaviour change, but I think that it was a mistake. If we really do want this to fail with the above message, then I think `ghc --make foo` should fail with "Bad module name". I would prefer that all of these succeed, though, despite the module name not matching the filename. The "ghc --make Setup" and "runhaskell Setup" cases are particularly motivating. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 25 17:58:36 2008 From: trac at galois.com (GHC) Date: Mon Aug 25 17:57:25 2008 Subject: [GHC] #2540: [Text.Regex] incorrect word boundary ("\\b") substitutions. Bug in regex-compat's subRegex handling of BOL flags. In-Reply-To: <045.dc1ce4d07a034cafda39a835d9bd9181@localhost> References: <045.dc1ce4d07a034cafda39a835d9bd9181@localhost> Message-ID: <054.e05f8b5e5e3bee55b22100c43d3b3318@localhost> #2540: [Text.Regex] incorrect word boundary ("\\b") substitutions. Bug in regex- compat's subRegex handling of BOL flags. --------------------------------+------------------------------------------- Reporter: Eelis- | Owner: ChrisKuklewicz Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: regex regex-compat | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | --------------------------------+------------------------------------------- Changes (by ChrisKuklewicz): * status: assigned => closed * resolution: => fixed Comment: I have uploaded regex-compat 0.92 and regex-posix 0.93.2 to hackage (they are also in darcs). These contain two changes: regex-posix's Wrap.hsc defines _POSIX_C_SOURCE to (untested) cause the gnu systems to stop trying to handle non-posix escapes like \b. regex-compat's splitRegex and subRegex are changed to use matchAllText and not to use recursion. This may (untested) create differences in behavior compared to the old version, including laziness. Both require the newer regex-base to compile and run, the current version of which is 0.93.1 at this time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 25 19:19:40 2008 From: trac at galois.com (GHC) Date: Mon Aug 25 19:18:22 2008 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.ed31ada17a31b33f56ecae3c64d6ec91@localhost> #1338: base package breakup ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: igloo => * milestone: 6.10 branch => 6.12 branch Comment: I've done the parts of this that nobody objected to namely: {{{ concurrent, unique, timeout st syb (was: generics) getopt }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 04:07:33 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 04:06:11 2008 Subject: [GHC] #2542: runghc does not infer module file extensions In-Reply-To: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> References: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> Message-ID: <053.8e6ed98bf98a4225fe3ff4f5f4265f5d@localhost> #2542: runghc does not infer module file extensions ----------------------+----------------------------------------------------- Reporter: judah | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonmar): Yes, the change was deliberate, but I agree it's not ideal and we should try to fix it. I just don't know what to do about it. The problem is that people wanted a way to say "load this file with the interpreter only, ignore any compiled code for it". And the solution we adopted for this was to say that any target named by ''filename'' (rather than ''module'') would be loaded with the interpreter. But the problem is that previously `:load Setup` would look for a filename `Setup.hs` and load that, but that's wrong: we don't want `:load Setup` to always use the interpreter. So I made `:load Setup` treat `Setup` as a module name, which seems more correct. The problem is that now `:load Setup` will expect to find a module called `Setup` when it reads `Setup.hs`, which it often won't. So I could probably add an exception for this case and make it work again, but it would be ugly, and hard to document without being thoroughly confusing. Can anyone think of a plan that is simple, easy to explain and implement, and doesn't break existing practice too much? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 05:04:43 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 05:03:21 2008 Subject: [GHC] #2542: runghc does not infer module file extensions In-Reply-To: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> References: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> Message-ID: <053.116dd2bd97b5b48696a6b20c93eaa252@localhost> #2542: runghc does not infer module file extensions ----------------------+----------------------------------------------------- Reporter: judah | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): Can `Foo` not search for `Foo.o&hi`, then `Foo.hs`, then `Foo.lhs`, and not require that the module name matches? `foo` would do the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 05:14:39 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 05:13:15 2008 Subject: [GHC] #2520: SPECIALIZE causing duplicate assembler symbols In-Reply-To: <045.4cbde2e14ab09ef4660570998e97cec8@localhost> References: <045.4cbde2e14ab09ef4660570998e97cec8@localhost> Message-ID: <054.c79fcc4ecdd2b7daf29d3ee275aa9096@localhost> #2520: SPECIALIZE causing duplicate assembler symbols ----------------------+----------------------------------------------------- Reporter: ganesh | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown Comment: I'll look at this. See also #2543 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 05:15:00 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 05:13:36 2008 Subject: [GHC] #2543: Nested SPECIALIZEd functions cause error: "Symbol _BadUTF8_zdf1_closure already defined." In-Reply-To: <044.e713affc75f221ae3449046e647f449d@localhost> References: <044.e713affc75f221ae3449046e647f449d@localhost> Message-ID: <053.c5263585c81bc387e29fd83fc699e8a2@localhost> #2543: Nested SPECIALIZEd functions cause error: "Symbol _BadUTF8_zdf1_closure already defined." ----------------------+----------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Dup of #2520. Thanks for another test case. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 05:45:26 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 05:44:04 2008 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.8a332b77e5ee4d7d97c7f7140e991ed8@localhost> #2337: Data.Array documentation utterly broken ---------------------------+------------------------------------------------ Reporter: japple | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Comment (by simonmar): A quick fix for 6.10.1 would be to un-hide `GHC.Arr`, then at least we'd get hyperlinks in the `Data.Array` docs that would take you to the actual documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 06:14:00 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 06:12:37 2008 Subject: [GHC] #2542: runghc does not infer module file extensions In-Reply-To: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> References: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> Message-ID: <053.e29486e86ad601b88a638bc3b9359a97@localhost> #2542: runghc does not infer module file extensions ----------------------+----------------------------------------------------- Reporter: judah | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonmar): Yes, but that would be an exception. There are currently two cases: * a module name: search for the source file using the normal search semantics (`-i` search path, hierarchical module names etc.), load compiled code if available, require the module name in the file to be correct. * a filename ending in `.hs` or `.lhs`, or missing the extension: load exactly that file, which can contain any module, and in GHCi ignore any compiled version. there would be an extra case, to come first: * for target `X`, if `X.hs` or `X.lhs` exists, load that file, which can contain any module, and in GHCi load compiled code if available. this would change the behaviour of `:load foo` (it would load compiled code, whereas `:load foo.hs` wouldn't). My main objection to this is that three cases feels like one too many to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 06:19:59 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 06:18:36 2008 Subject: [GHC] #2542: runghc does not infer module file extensions In-Reply-To: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> References: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> Message-ID: <053.f75e99a23740bed1904f0e6361939833@localhost> #2542: runghc does not infer module file extensions ----------------------+----------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 06:30:11 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 06:28:48 2008 Subject: [GHC] #2485: Installed ghci wrapper refers to nonexistent file In-Reply-To: <044.2c0bcbfdb00152697f27863db8618203@localhost> References: <044.2c0bcbfdb00152697f27863db8618203@localhost> Message-ID: <053.3452327c7e50bf4972da6af389cfade0@localhost> #2485: Installed ghci wrapper refers to nonexistent file ----------------------+----------------------------------------------------- Reporter: judah | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the report; now fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 06:51:19 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 06:49:57 2008 Subject: [GHC] #2513: Bad location info for flag warnings In-Reply-To: <048.2f3761d98808d86da386fc5cb5b36ade@localhost> References: <048.2f3761d98808d86da386fc5cb5b36ade@localhost> Message-ID: <057.f2c5bb0d8adca797660bc440e742c860@localhost> #2513: Bad location info for flag warnings -----------------------+---------------------------------------------------- Reporter: Feuerbach | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------+---------------------------------------------------- Comment (by simonpj): I've realised that good location info for flag warnings is more important than I thought when you are using `--make` or compiling multiple modules. Below is a dump from building GHC itself. Saying `` does not tell me which module has the offending pragma; or whether it's the command line. (In this case it's the latter.) {{{ /64playpen/simonpj/builds/HEAD-1/ghc/stage1-inplace/ghc -M -dep-makefile dist-stage2/build/.depend -package-name ghc-6.9 -hide-all-packages -no- user-package-conf -i -idist-stage2/build -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise -idist-stage2/build/autogen -Idist-stage2/build/autogen -Idist- stage2/build -I../libffi/build/include -Istage2plus -I../libraries/base/cbits -I../libraries/base/include -I. -Iparser -Iutils -optP-DUSE_EDITLINE -optP-DGHCI -optP-include -optPdist- stage2/build/autogen/cabal_macros.h -odir dist-stage2/build -hidir dist- stage2/build -stubdir dist-stage2/build -package Cabal-1.5.3 -package array-0.1 -package base-4.0 -package bytestring-0.9 -package concurrent-0.1 -package containers-0.1 -package directory-1.0 -package editline-0.2 -package filepath-1.1 -package haskell98-1.0.1 -package hpc-0.5 -package old-time-1.0 -package process-1.0.1 -package st-0.1 -package template-haskell-2.2 -package unix-2.2 -O -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Wall -fno-warn-name-shadowing -fno- warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XPatternSignatures -idist-stage2/build -Werror -H64m -O0 -fasm -Rghc- timing -O0 -fasm AsmCodeGen MachCodeGen MachInstrs MachRegs NCGMonad PositionIndependentCode PprMach RegAllocColor RegAllocInfo RegAllocLinear RegAllocStats RegArchBase RegArchX86 RegCoalesce RegLiveness RegSpill RegSpillClean RegSpillCost DsMeta TcSplice Convert ByteCodeAsm ByteCodeFFI ByteCodeGen ByteCodeInstr ByteCodeItbls ByteCodeLink Debugger GhciMonad GhciTags InteractiveUI LibFFI Linker ObjLink RtClosureInspect BasicTypes DataCon Demand Exception Id IdInfo Literal MkId Module Name NameEnv NameSet NewDemand OccName RdrName SrcLoc UniqSupply Unique Var VarEnv VarSet BlockId CLabel Cmm CmmBrokenBlock CmmCPS CmmCPSGen CmmCPSZ CmmCallConv CmmCommonBlockElimZ CmmContFlowOpt CmmCvt CmmExpr CmmInfo CmmLex CmmLint CmmLive CmmLiveZ CmmOpt CmmParse CmmProcPoint CmmProcPointZ CmmSpillReload CmmTx CmmUtils CmmZipUtil DFMonad Dataflow MachOp MkZipCfg MkZipCfgCmm OptimizationFuel PprC PprCmm PprCmmZ StackColor StackPlacements ZipCfg ZipCfgCmmRep ZipCfgExtras ZipDataflow Bitmap CgBindery CgCallConv CgCase CgClosure CgCon CgExpr CgForeignCall CgHeapery CgHpc CgInfoTbls CgLetNoEscape CgMonad CgParallel CgPrimOp CgProf CgStackery CgTailCall CgTicky CgUtils ClosureInfo CodeGen SMRep CoreFVs CoreLint CorePrep CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils ExternalCore MkCore MkExternalCore PprCore PprExternalCore CprAnalyse Check Coverage Desugar DsArrows DsBinds DsCCall DsExpr DsForeign DsGRHSs DsListComp DsMonad DsUtils Match MatchCon MatchLit HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils BinIface BuildTyCl IfaceEnv IfaceSyn IfaceType LoadIface MkIface TcIface BreakArray CmdLineParser CodeOutput Config Constants DriverMkDepend DriverPhases DriverPipeline DynFlags ErrUtils Finder GHC HeaderInfo HscMain HscStats HscTypes InteractiveEval PackageConfig Packages ParsePkgConf PprTyThing StaticFlags SysTools TidyPgm Ctype HaddockLex HaddockParse HaddockUtils LexCore Lexer Parser ParserCore ParserCoreUtils RdrHsSyn ForeignCall PrelInfo PrelNames PrelRules PrimOp TysPrim TysWiredIn CostCentre SCCfinal RnBinds RnEnv RnExpr RnHsDoc RnHsSyn RnNames RnPat RnSource RnTypes CSE FloatIn FloatOut LiberateCase OccurAnal SAT SetLevels SimplCore SimplEnv SimplMonad SimplUtils Simplify SRT SimplStg StgStats Rules SpecConstr Specialise CoreToStg StgLint StgSyn DmdAnal SaAbsInt SaLib StrictAnal WorkWrap WwLib FamInst Inst TcArrows TcBinds TcClassDcl TcDefaults TcDeriv TcEnv TcExpr TcForeign TcGenDeriv TcHsSyn TcHsType TcInstDcls TcMType TcMatches TcPat TcRnDriver TcRnMonad TcRnTypes TcRules TcSimplify TcTyClsDecls TcTyDecls TcTyFuns TcType TcUnify Class Coercion FamInstEnv FunDeps Generics InstEnv TyCon Type TypeRep Unify Bag Binary BufWrite Digraph Encoding FastBool FastFunctions FastMutInt FastString FastTypes Fingerprint FiniteMap GraphBase GraphColor GraphOps GraphPpr IOEnv Interval LazyUniqFM ListSetOps Maybes MonadUtils OrdList Outputable Panic Pretty State StringBuffer Unicode UniqFM UniqSet Util VectBuiltIn VectCore VectMonad VectType VectUtils Vectorise : Warning: -XPatternSignatures is deprecated: use -XScopedTypeVariables or pragma {-# LANGUAGE ScopedTypeVariables#-} instead : Failing due to -Werror. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 07:37:03 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 07:35:40 2008 Subject: [GHC] #2542: runghc does not infer module file extensions In-Reply-To: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> References: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> Message-ID: <053.91596b1c1abc3af8461c7c928cbe4b97@localhost> #2542: runghc does not infer module file extensions ----------------------+----------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonpj): I thought that we allowed the module name not to match the file name precisely (and only) when the module was called `Main`. That would collapse your first and third bullets which is what you wanted. Also I suggest that plain `M` (no suffix) on the command line should fail altogether if you can't find `M.hs` or `M.lhs`, regardless of whether you are linking or not. And plain `m` (lower case) should fail too, since `m` can't be a module name. Stuff you want to link should have suffix `.o` or `.a`, shouldn't it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 07:42:23 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 07:40:59 2008 Subject: [GHC] #2542: runghc does not infer module file extensions In-Reply-To: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> References: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> Message-ID: <053.52fc5bb03bb8e323f3cc09ab812c73e3@localhost> #2542: runghc does not infer module file extensions ----------------------+----------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by claus): (aside: would either `runhaskell Main` or adding `module Setup where` work?) The first two cases sound right overall, but note that they already differ in strictness of checking: - via module name, the file name has to match - via file name, the module name doesn't need to match. It would make more sense to have matching behaviour determined independently of the route, but the module-name route depends on strict matches to find the file (or ghc would have to check all sources for matching module names). We could still have a flag `ModuleFileNameMatch`, but it wouldn't buy much. The problem arises from `Setup.[l]hs` '''not''' having a module name, combined with the default being `Main`, which was meant to make finding and running `Main.main` in non-module code possible, while Cabal wants to find and run `Setup.main` in non-module code. Could we simply change the default module name? - if the filename is a module name, `File.[l]hs` introduces module `File` (and module `Main`, if we still need that?) - if there is an explicit module name, it has to match the file name or be `Main` -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 07:51:09 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 07:49:44 2008 Subject: [GHC] #2544: Improve "Can't unify" error messages from type functions Message-ID: <046.d4540170a8e4dbef24cd1ffc9375378f@localhost> #2544: Improve "Can't unify" error messages from type functions ----------------------------------------+----------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- Consider this example from a Haskell Cafe thread: {{{ data (:|:) a b = Inl a | Inr b class Ix i where type IxMap i :: * -> * empty :: IxMap i [Int] data BiApp a b c = BiApp (a c) (b c) instance (Ix l, Ix r) => Ix (l :|: r) where type IxMap (l :|: r) = BiApp (IxMap l) (IxMap r) empty = BiApp empty empty }}} This elicits the following confusing error message: {{{ Couldn't match expected type `IxMap l' against inferred type `IxMap i' Expected type: IxMap (l :|: r) [Int] Inferred type: BiApp (IxMap i) (IxMap i1) [Int] In the expression: BiApp empty empty In the definition of `empty': empty = BiApp empty empty }}} As Alexander Dunlap responds, the error message is correct, but I can't help feeling that we should try harder to give a better error message. Something like "Since `IxMap` is a type function, knowing that `IxMap l` = `IxMap i` does not require that `l` = `i`". Or something. This ticket is just to make sure we don't forget. The thread is here http://www.haskell.org/pipermail/haskell-cafe/2008-August/046371.html Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 08:26:38 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 08:25:15 2008 Subject: [GHC] #2213: Confusing flags for rewrite rules In-Reply-To: <043.a16de73b756c546cfe361c8db1abcd3b@localhost> References: <043.a16de73b756c546cfe361c8db1abcd3b@localhost> Message-ID: <052.a8b40073ee6ac6f9cf1bcc3b24840118@localhost> #2213: Confusing flags for rewrite rules -----------------------------+---------------------------------------------- Reporter: dons | Owner: dons Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: rules, warnings | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonpj): * status: assigned => closed * resolution: => fixed Comment: See the discussion and fix in #2497. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 08:27:37 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 08:26:14 2008 Subject: [GHC] #2497: Weird scoping for tyvars in rules In-Reply-To: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> References: <041.a9ef83c2e656abc59c0b9db2edf923b5@localhost> Message-ID: <050.f27ff007fdb947b6a8e538091c3a45c1@localhost> #2497: Weird scoping for tyvars in rules --------------------------------------------+------------------------------- Reporter: rl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T2497 | Architecture: Unknown Os: Unknown | --------------------------------------------+------------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T2497 * status: new => closed * resolution: => fixed Comment: Fixed by a combination of {{{ Wed Aug 20 14:29:11 BST 2008 Simon Marlow * always treat 'forall' and '.' as reserved keywords inside RULES pragmas }}} and {{{ Tue Aug 26 13:21:21 BST 2008 simonpj@microsoft.com * Fix flaggery for RULES (cf Trac #2497) }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 09:12:41 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 09:11:22 2008 Subject: [GHC] #2538: Better error message for missing Rank2Types (or RankNTypes) flag In-Reply-To: <042.1a667f48d50ac64babcfbb21bf4e41d3@localhost> References: <042.1a667f48d50ac64babcfbb21bf4e41d3@localhost> Message-ID: <051.54a4f92f2599f7656fc386da8b6b4299@localhost> #2538: Better error message for missing Rank2Types (or RankNTypes) flag -------------------------------------+-------------------------------------- Reporter: tim | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown Comment: Good idea. I'm fixing this. S -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 09:57:43 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 09:56:19 2008 Subject: [GHC] #2545: Data Parallel Haskell on Kubuntu 8.04 uses too much memory Message-ID: <047.a1caf49d69e3b7edd366bd96e3b1141c@localhost> #2545: Data Parallel Haskell on Kubuntu 8.04 uses too much memory ----------------------------+----------------------------------------------- Reporter: jjanssen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: Memory Leak | Testcase: Architecture: x86 | Os: Linux ----------------------------+----------------------------------------------- Hey. I tried to perform some tests on the performance of data parallel haskell today using the program from the DPH-wiki: {{{ {-# OPTIONS -fparr -fglasgow-exts #-} module Main where import GHC.PArr dotp :: Num a => [:a:] -> [:a:] -> a dotp xs ys = sumP [:x*y | x <- xs | y <- ys:] main = putStrLn $ show $ dotp [:1..500000:] [:5..4999995:] }}} After compiling this with -threaded and running it, the memory usage starts to increase up until the point that the machine starts swapping. On a machine with 2GiB of memory, this hardly seems to be normal behaviour, especially since a program like this should presumably take up maximally 3*the size of the vectors used, which would translate to 3*500.000*32 bit = 6MiB. So this seems like a bug. I tried it with the GHC 6.8.2 that is in the kubuntu repositories and with the GHC 6.8.3 binaries distributed on the GHC website. Both showed the same behaviour. Also, the behaviour does not seem to depend on the usage of +RTS -N2, as both with and without these flags the memory gets filled. Additionally, I remember having similar problems when trying out parMap_ on an example, but I can't seem to find the example right now. Hopefully this gets fixed (or maybe already is), so I can start using the power of DPH to optimise some of my programs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 11:14:52 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 11:14:06 2008 Subject: [GHC] #1346: bootstrap from HC files In-Reply-To: <047.353746f1d61af31dcc9643e79add3cec@localhost> References: <047.353746f1d61af31dcc9643e79add3cec@localhost> Message-ID: <056.dff083d1cd3c5e33146b978be129cda2@localhost> #1346: bootstrap from HC files --------------------------+------------------------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by simonpj): * milestone: 6.10.1 => 6.12 branch Comment: Let's postpone this past the 6.10 release, because the build system is in upheaval. Simon & Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 11:20:06 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 11:18:41 2008 Subject: [GHC] #2462: Data.List.sum is slower than 6.8.3 In-Reply-To: <047.a070686fa958e3b92e101be0217ff9b1@localhost> References: <047.a070686fa958e3b92e101be0217ff9b1@localhost> Message-ID: <056.f771c57b93b33dd4a9bc314b57ae3209@localhost> #2462: Data.List.sum is slower than 6.8.3 --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: run-time performance bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 13:30:33 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 13:29:43 2008 Subject: [GHC] #1346: bootstrap from HC files In-Reply-To: <047.353746f1d61af31dcc9643e79add3cec@localhost> References: <047.353746f1d61af31dcc9643e79add3cec@localhost> Message-ID: <056.b22e36bfbd5ddb3925b94b9ccbba684b@localhost> #1346: bootstrap from HC files --------------------------+------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 13:33:26 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 13:32:03 2008 Subject: [GHC] #2546: Reliable crash in scheduleCheckBlackHoles Message-ID: <044.f1d71ea4c4ced0ffd1ef244c500b6860@localhost> #2546: Reliable crash in scheduleCheckBlackHoles -----------------------+---------------------------------------------------- Reporter: nogin | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: critical Keywords: crash | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- I hit a fully reproducible bug in {{{scheduleCheckBlackHoles}}} using GHC 6.8.2 under CentOS 5.2. The program has no FFI and no unsafe calls. Before reporting the bug, I've deleted all the binaries and recompiled using {{{ghc -Wall -Werror -fwarn-simple-patterns -fwarn-tabs -fwarn-incomplete- record-updates -fwarn-monomorphism-restriction -fno-warn-name-shadowing -threaded -O2 -dcore-lint -o XXX YYY/*.hs}}}. I run with {{{+RTS -N3 -A10m -sstderr}}}. The {{{gdb}}} output is given below. ---- P.S. The code in question is unfortunately proprietary and I doubt that I'd be able to share a test case. The code is very heavy on IORefs (including lots and lost of atomicModifyIORef) and uses a number of MVars (the model is - use atomicModifyIORef if possible; then use an MVar if atomicModifyIORef's output suggests we may need to block), but no STM. P.P.S. I'd be more than happy to help in debugging, if somebody is willing to provide guidance (I am fairly new to Haskell, but have 10+ years of in- depth OCaml experience). {{{ (gdb) run 4000 +RTS -N3 -A10m -sstderr Starting program: XXX 4000 +RTS -N3 -A10m -sstderr (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] XXX 4000 +RTS -N3 -A10m -sstderr [New Thread 1118336 (LWP 20985)] [New Thread 24583056 (LWP 21019)] [New Thread 86469520 (LWP 21020)] [New Thread 59771792 (LWP 21021)] [New Thread 117144464 (LWP 21022)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 59771792 (LWP 21021)] 0x080884b3 in scheduleCheckBlackHoles () (gdb) run 4000 +RTS -N3 -A10m -sstderr The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: XXX 4000 +RTS -N3 -A10m -sstderr (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] XXX 4000 +RTS -N3 -A10m -sstderr [New Thread 1118336 (LWP 21029)] [New Thread 24963984 (LWP 21061)] [New Thread 68045712 (LWP 21062)] [New Thread 78535568 (LWP 21063)] [New Thread 89025424 (LWP 21064)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 78535568 (LWP 21063)] 0x080884b3 in scheduleCheckBlackHoles () (gdb) bt #0 0x080884b3 in scheduleCheckBlackHoles () #1 0x0a0d1f34 in ?? () #2 0x00000004 in ?? () #3 0x00000001 in ?? () #4 0x0a0bf0d8 in ?? () #5 0x00000001 in ?? () #6 0x08089497 in schedule () #7 0x0a0d1ee8 in ?? () #8 0x0001ff78 in ?? () #9 0x00000000 in ?? () (gdb) run 4000 +RTS -N3 -A10m -sstderr The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: XXX 4000 +RTS -N3 -A10m -sstderr (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] XXX 4000 +RTS -N3 -A10m -sstderr [New Thread 1118336 (LWP 21065)] [New Thread 26430352 (LWP 21097)] [New Thread 36920208 (LWP 21098)] [New Thread 130771856 (LWP 21099)] [New Thread 47410064 (LWP 21100)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 26430352 (LWP 21097)] 0x080884b3 in scheduleCheckBlackHoles () (gdb) bt #0 0x080884b3 in scheduleCheckBlackHoles () #1 0x0977a4d4 in ?? () #2 0x00000004 in ?? () #3 0x00000001 in ?? () #4 0x0976e1f8 in ?? () #5 0x00000001 in ?? () #6 0x08089497 in schedule () #7 0x0977a488 in ?? () #8 0x00001f78 in ?? () #9 0x00000005 in ?? () #10 0x080bca50 in stg_NO_TREC_closure () #11 0x0977a4d4 in ?? () #12 0x0976e1f8 in ?? () #13 0x07126000 in ?? () #14 0x00001000 in ?? () #15 0x01934b5c in ?? () #16 0x07126000 in ?? () #17 0x0977a4d4 in ?? () #18 0x0977a488 in ?? () #19 0x0976e1f8 in ?? () #20 0x0976e1f8 in ?? () #21 0x0977a4d4 in ?? () #22 0x0977a488 in ?? () #23 0x0976e1f8 in ?? () #24 0x019344b8 in ?? () #25 0x08089b24 in workerStart () #26 0x080bdbdc in dummy_tso () #27 0x0977a488 in ?? () #28 0x00000000 in ?? () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 13:50:24 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 13:48:58 2008 Subject: [GHC] #2546: Reliable crash in scheduleCheckBlackHoles In-Reply-To: <044.f1d71ea4c4ced0ffd1ef244c500b6860@localhost> References: <044.f1d71ea4c4ced0ffd1ef244c500b6860@localhost> Message-ID: <053.f0eec06a1144efff577e7f7d9efeb655@localhost> #2546: Reliable crash in scheduleCheckBlackHoles -------------------------+-------------------------------------------------- Reporter: nogin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: Keywords: crash | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Comment (by nogin): By adding the {{{-debug -dppr-debug}}} flags to the compilation command line, I was able to get a much better {{{gdb}}} backtrace: {{{ (gdb) run 4000 +RTS -N3 -A10m -sstderr Starting program: XXX 4000 +RTS -N3 -A10m -sstderr [Thread debugging using libthread_db enabled] XXX 4000 +RTS -N3 -A10m -sstderr [New Thread 1118336 (LWP 21542)] [New Thread 25070480 (LWP 21576)] [New Thread 113068944 (LWP 21577)] [New Thread 85584784 (LWP 21578)] [New Thread 131009424 (LWP 21579)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 131009424 (LWP 21579)] 0x0808c25c in checkBlackHoles (cap=0x8daf278) at Schedule.c:2952 2952 Schedule.c: ??? ?????? ????? ??? ????????. in Schedule.c (gdb) bt #0 0x0808c25c in checkBlackHoles (cap=0x8daf278) at Schedule.c:2952 #1 0x0808a5b5 in scheduleCheckBlackHoles (cap=0x8daf278) at Schedule.c:941 #2 0x0808983a in schedule (initialCapability=0x8daf278, task=0x8dc4268) at Schedule.c:458 #3 0x0808b957 in workerStart (task=0x8dc4268) at Schedule.c:2528 #4 0x00d5f46b in start_thread () from /lib/libpthread.so.0 #5 0x00cb6dbe in clone () from /lib/libc.so.6 (gdb) run 4000 +RTS -N3 -A10m -sstderr The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: XXX 4000 +RTS -N3 -A10m -sstderr [Thread debugging using libthread_db enabled] XXX 4000 +RTS -N3 -A10m -sstderr [New Thread 1118336 (LWP 21588)] [New Thread 25312144 (LWP 21620)] [New Thread 62921616 (LWP 21621)] [New Thread 103971728 (LWP 21622)] [New Thread 73411472 (LWP 21623)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 25312144 (LWP 21620)] 0x0808c25c in checkBlackHoles (cap=0x8787278) at Schedule.c:2952 2952 in Schedule.c (gdb) bt #0 0x0808c25c in checkBlackHoles (cap=0x8787278) at Schedule.c:2952 #1 0x0808a5b5 in scheduleCheckBlackHoles (cap=0x8787278) at Schedule.c:941 #2 0x0808983a in schedule (initialCapability=0x8787278, task=0x8793578) at Schedule.c:458 #3 0x0808b957 in workerStart (task=0x8793578) at Schedule.c:2528 #4 0x00d5f46b in start_thread () from /lib/libpthread.so.0 #5 0x00cb6dbe in clone () from /lib/libc.so.6 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 13:58:05 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 13:56:42 2008 Subject: [GHC] #2546: Reliable crash in checkBlackHoles In-Reply-To: <044.f1d71ea4c4ced0ffd1ef244c500b6860@localhost> References: <044.f1d71ea4c4ced0ffd1ef244c500b6860@localhost> Message-ID: <053.1464228bbec79403d468e17ddab8dbc2@localhost> #2546: Reliable crash in checkBlackHoles -------------------------+-------------------------------------------------- Reporter: nogin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: Keywords: crash | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Changes (by nogin): * summary: Reliable crash in scheduleCheckBlackHoles => Reliable crash in checkBlackHoles -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 14:02:43 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 14:01:18 2008 Subject: [GHC] #2546: Reliable crash in checkBlackHoles In-Reply-To: <044.f1d71ea4c4ced0ffd1ef244c500b6860@localhost> References: <044.f1d71ea4c4ced0ffd1ef244c500b6860@localhost> Message-ID: <053.489776d217b44e37621bc62312c01f63@localhost> #2546: Reliable crash in checkBlackHoles -------------------------+-------------------------------------------------- Reporter: nogin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: Keywords: crash | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Comment (by nogin): This might be a dup of #1898 - will try upgrading to 6.8.3 to check if it's still there. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 17:17:37 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 17:16:14 2008 Subject: [GHC] #1895: Allow aliases in GHCi module imports In-Reply-To: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> References: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> Message-ID: <053.86845a880122d902c47e5a7e7d1b2876@localhost> #1895: Allow aliases in GHCi module imports -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by jcpetruzza): * cc: jcpetruzza@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 18:36:35 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 18:35:14 2008 Subject: [GHC] #2547: No -X flag for unboxed types Message-ID: <042.f34359a92228af4d282ff6ab0a45d34f@localhost> #2547: No -X flag for unboxed types --------------------------------+------------------------------------------- Reporter: tim | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- There doesn't seem to be a separate -X flag for unboxed types; there is one for unboxed tuples, but it seems like {{{Int#}}}, {{{Char#}}} and the rest can only be gotten at with {{{-fglasgow-exts}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 18:40:35 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 18:39:13 2008 Subject: [GHC] #2547: No -X flag for unboxed types In-Reply-To: <042.f34359a92228af4d282ff6ab0a45d34f@localhost> References: <042.f34359a92228af4d282ff6ab0a45d34f@localhost> Message-ID: <051.67242015de51b1a0b28aa4b859fdb918@localhost> #2547: No -X flag for unboxed types --------------------------------+------------------------------------------- Reporter: tim | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Comment (by NeilMitchell): -XMagicHash is the answer. I have no idea where the documentation is, and neither does Google... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 19:12:34 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 19:11:10 2008 Subject: [GHC] #1895: Allow aliases in GHCi module imports In-Reply-To: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> References: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> Message-ID: <053.f7c2b92b3a14debf8d4ff5e6fab4e606@localhost> #1895: Allow aliases in GHCi module imports -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by guest): * cc: gwern0@gmail.com (added) Comment: Speaking for myself, I really hope that when this is fixed, it'll be easy to load modules qualified via the GHC API. This would let me fix mueval so things like 'mueval -e "Map.map (+1) $ Map.fromList [(1,2)]' could work. (Which is valuable since I use mueval in Lambdabot, and Lambdabot users expect to be able to use qualified imports.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 19:13:48 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 19:12:24 2008 Subject: [GHC] #1895: Allow aliases in GHCi module imports In-Reply-To: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> References: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> Message-ID: <053.e1465665d6a10d55ccc1349cc69a9721@localhost> #1895: Allow aliases in GHCi module imports -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by guest): * cc: cgibbard@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 19:47:44 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 19:46:22 2008 Subject: [GHC] #2547: No -X flag for unboxed types In-Reply-To: <042.f34359a92228af4d282ff6ab0a45d34f@localhost> References: <042.f34359a92228af4d282ff6ab0a45d34f@localhost> Message-ID: <051.456c497d02f77f45ab6d3ea43f40dac0@localhost> #2547: No -X flag for unboxed types --------------------------------+------------------------------------------- Reporter: tim | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Comment (by duncan): Replying to [comment:1 NeilMitchell]: > -XMagicHash is the answer. > > I have no idea where the documentation is, and neither does Google... I should like to note that I am now enforcing that all new language extensions registered in Language.Haskell.Extension require haddock documentation including an explanation and examples. Ian was the first victim of my enforcement earlier today when he registered the `PackageImports` extension. :-) Hopefully this will help google and hoogle and become a useful reference. Obviously this will require copying out documentation from various places for all the existing extensions. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 26 20:29:29 2008 From: trac at galois.com (GHC) Date: Tue Aug 26 20:28:08 2008 Subject: [GHC] #2545: Data Parallel Haskell on Kubuntu 8.04 uses too much memory In-Reply-To: <047.a1caf49d69e3b7edd366bd96e3b1141c@localhost> References: <047.a1caf49d69e3b7edd366bd96e3b1141c@localhost> Message-ID: <056.3a01b99473641096db6f9446dacf08d8@localhost> #2545: Data Parallel Haskell on Kubuntu 8.04 uses too much memory ----------------------------+----------------------------------------------- Reporter: jjanssen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: Memory Leak | Testcase: Architecture: x86 | Os: Linux ----------------------------+----------------------------------------------- Changes (by chak): * status: new => closed * resolution: => invalid Comment: Data Parallel Haskell is not supported at all in the 6.8.x branch and the version that you have been testing is just a very, very rough prototype to play around with the surface syntax. It does not run in parallel at all and there is no optimisation whatsoever. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 03:36:02 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 03:34:39 2008 Subject: [GHC] #2545: Data Parallel Haskell on Kubuntu 8.04 uses too much memory In-Reply-To: <047.a1caf49d69e3b7edd366bd96e3b1141c@localhost> References: <047.a1caf49d69e3b7edd366bd96e3b1141c@localhost> Message-ID: <056.29ea6d93decf8a48b112f4186a1576ea@localhost> #2545: Data Parallel Haskell on Kubuntu 8.04 uses too much memory -------------------------+-------------------------------------------------- Reporter: jjanssen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: Memory Leak | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------+-------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: However, just to add, DPH is ''very much'' in our sights as an active project. We are working hard on getting something usable into GHC 6.10 (although it may still not be very performant). And we won't stop there... we have invested lots of effort to getting where we are, and we won't be satisfied until we have DPH running on multicores with serious speedups. It's just taking longer than we thought! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 04:04:59 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 04:03:35 2008 Subject: [GHC] #2545: Data Parallel Haskell on Kubuntu 8.04 uses too much memory In-Reply-To: <047.a1caf49d69e3b7edd366bd96e3b1141c@localhost> References: <047.a1caf49d69e3b7edd366bd96e3b1141c@localhost> Message-ID: <056.a6a94152e7461c2612df1096d1d9eece@localhost> #2545: Data Parallel Haskell on Kubuntu 8.04 uses too much memory -------------------------+-------------------------------------------------- Reporter: jjanssen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: Memory Leak | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------+-------------------------------------------------- Comment (by jjanssen): Ok, thanks for clearing that up! It might be useful to add an additional disclaimer to http://www.haskell.org/haskellwiki/Data_Parallel_Haskell/GHC.PArr about it being unstable and unsupported in GHC 6.8.3 as this page suggested (to me at least) that the example would run without any problems on GHC >=6.6.1 I'll be waiting eagerly for 6.10 then ;). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 04:28:43 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 04:27:21 2008 Subject: [GHC] #2547: No -X flag for unboxed types In-Reply-To: <042.f34359a92228af4d282ff6ab0a45d34f@localhost> References: <042.f34359a92228af4d282ff6ab0a45d34f@localhost> Message-ID: <051.57906897cfd0d1b71467fe0978fe1a6f@localhost> #2547: No -X flag for unboxed types -----------------------------+---------------------------------------------- Reporter: tim | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown Comment: OK I'll improve the docs. S -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 04:30:40 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 04:29:14 2008 Subject: [GHC] #2542: runghc does not infer module file extensions In-Reply-To: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> References: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> Message-ID: <053.8cdfe0117f15000780453914970994f5@localhost> #2542: runghc does not infer module file extensions ----------------------+----------------------------------------------------- Reporter: judah | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 04:39:45 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 04:38:18 2008 Subject: [GHC] #2542: runghc does not infer module file extensions In-Reply-To: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> References: <044.a43cdf8e37f7b44e707cb497643d7a68@localhost> Message-ID: <053.aeb61eaadfadc7c6daf3b35f42aff631@localhost> #2542: runghc does not infer module file extensions ----------------------+----------------------------------------------------- Reporter: judah | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonmar): Here is the latest plan. We came to the conclusion that mixing up the notion of whether a module is compiled to byte code or object code with whether it is specified as a filename or module name is too confusing. So we propose to restore the previous behaviour for specifying modules/filenames, and add a new way to say that a module is to be loaded as byte-code: {{{ Prelude> :load *A Compiling A ( A.hs, interpreted ) *A> }}} The `*`-prefix forces the module to be loaded as byte-code. You can use any combination of * and non-* modules, and you can convert a non-* module to a * module later by saying `:add *A`. The * syntax mirrors the same syntax used in the `:module` command and the prompt, so I think it's a consistent choice. I'm validating the change now, please speak up if you dislike this idea or have a better one. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 05:08:19 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 05:06:58 2008 Subject: [GHC] #2547: No -X flag for unboxed types In-Reply-To: <042.f34359a92228af4d282ff6ab0a45d34f@localhost> References: <042.f34359a92228af4d282ff6ab0a45d34f@localhost> Message-ID: <051.cbb92cdeaecf0eb2f39e94e83e937187@localhost> #2547: No -X flag for unboxed types -----------------------------+---------------------------------------------- Reporter: tim | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: OK, done {{{ Wed Aug 27 10:05:44 BST 2008 simonpj@microsoft.com * Improve documentation of MagicHash and primitive types generally (Trac #2547) }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 05:10:49 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 05:09:21 2008 Subject: [GHC] #1205: ghci reports functions not in scope after loading a .hs, if there is a .o present In-Reply-To: <044.bd60efe42aee3f1abdd3292b0526501b@localhost> References: <044.bd60efe42aee3f1abdd3292b0526501b@localhost> Message-ID: <053.a6ee55e503ee95a9a3f6250087717a10@localhost> #1205: ghci reports functions not in scope after loading a .hs, if there is a .o present -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: closed Priority: high | Milestone: 6.10 branch Component: GHCi | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by simonmar): We plan to change the way this works again: see #2542. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 08:17:55 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 08:16:30 2008 Subject: [GHC] #2513: Bad location info for flag warnings In-Reply-To: <048.2f3761d98808d86da386fc5cb5b36ade@localhost> References: <048.2f3761d98808d86da386fc5cb5b36ade@localhost> Message-ID: <057.df6f8f96a1b0ba05f7bfadaff94490d0@localhost> #2513: Bad location info for flag warnings -----------------------+---------------------------------------------------- Reporter: Feuerbach | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------+---------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed * milestone: => 6.10.1 Comment: Fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 08:21:27 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 08:20:01 2008 Subject: [GHC] #2262: Build failure of HEAD from 2008-05-04 on OS X 10.4.11 In-Reply-To: <047.3f0e3b88d9818643a9caa58f0fc62bf1@localhost> References: <047.3f0e3b88d9818643a9caa58f0fc62bf1@localhost> Message-ID: <056.5f32ba01b8f4660eecf4bf283ce7175d@localhost> #2262: Build failure of HEAD from 2008-05-04 on OS X 10.4.11 ----------------------+----------------------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Building on OS X works for me, and there is no longer a `SRC_HC_OPTS += -fvia-C` in `rts/Makefile` on OS X, so we believe that this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 08:47:17 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 08:45:49 2008 Subject: [GHC] #2548: validate should continue if it sees warnings or haddock failures Message-ID: <044.acb88219f5f1e55a8e3bc288488095a4@localhost> #2548: validate should continue if it sees warnings or haddock failures --------------------------------+------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.8.3 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- From this thread: http://www.haskell.org/pipermail/cvs-ghc/2008-August/044517.html Rather than falling over on warnings and haddock failures, validate should just report them at the end, e.g.: {{{ Unexpected warnings in modules: simplCore/Simplify.lhs codeGen/CgMonad.lhs Unexpected Haddock failure in: codeGen/CgExpr.lhs Unexpected testsuite failures in: tc125 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 11:17:52 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 11:16:24 2008 Subject: [GHC] #2462: Data.List.sum is slower than 6.8.3 In-Reply-To: <047.a070686fa958e3b92e101be0217ff9b1@localhost> References: <047.a070686fa958e3b92e101be0217ff9b1@localhost> Message-ID: <056.63434432a1c3c9073519871e14eb7c4d@localhost> #2462: Data.List.sum is slower than 6.8.3 --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: run-time performance bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: I can't reproduce this. I compiled {{{ module Main( main ) where main = print (sum [1..100000000::Int]) }}} with -O and -O2 with the HEAD and 6.8.3. Results are essentially identical. I'll close this, but if anyone else can reproduce it, please re-open. {{{ Allocs Runtime(user) ghc-HEAD -O 8.031M 1.82s ghc-HEAD -O2 8.031M 1.82s ghc-6.8.3 -O 8.031M 1.82s ghc-6.8.3 -O2 8.031M 1.82 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 11:36:42 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 11:35:16 2008 Subject: [GHC] #745: GHC should recover better from bad type signatures In-Reply-To: <046.cbb264e9d67bbb505fa434af9a5d4e38@localhost> References: <046.cbb264e9d67bbb505fa434af9a5d4e38@localhost> Message-ID: <055.a9a9de9c3196c24c1c76a25e3bf48c95@localhost> #745: GHC should recover better from bad type signatures ---------------------------------------------+------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: _|_ Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_fail/tcfail113 | Architecture: Unknown Os: Unknown | ---------------------------------------------+------------------------------ Changes (by simonpj): * testcase: => typecheck/should_fail/tcfail113 * status: new => closed * resolution: => fixed Comment: Fixed at last {{{ Wed Aug 27 16:33:22 BST 2008 simonpj@microsoft.com * Fix Trac #745: improve error recoevery for type signatures }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 11:37:00 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 11:35:39 2008 Subject: [GHC] #2538: Better error message for missing Rank2Types (or RankNTypes) flag In-Reply-To: <042.1a667f48d50ac64babcfbb21bf4e41d3@localhost> References: <042.1a667f48d50ac64babcfbb21bf4e41d3@localhost> Message-ID: <051.e97c41cb9c0199dac9b8927ab19b07a1@localhost> #2538: Better error message for missing Rank2Types (or RankNTypes) flag --------------------------------------------------------+------------------- Reporter: tim | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: tcfail127, tcfail184, tcfail195, tcfail197 | Architecture: Unknown Os: Unknown | --------------------------------------------------------+------------------- Changes (by simonpj): * testcase: => tcfail127, tcfail184, tcfail195, tcfail197 * status: new => closed * resolution: => fixed Comment: Done {{{ Wed Aug 27 16:30:51 BST 2008 simonpj@microsoft.com * Fix Trac #2538: better error messages when validating types }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 11:39:35 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 11:38:07 2008 Subject: [GHC] #2520: SPECIALIZE causing duplicate assembler symbols In-Reply-To: <045.4cbde2e14ab09ef4660570998e97cec8@localhost> References: <045.4cbde2e14ab09ef4660570998e97cec8@localhost> Message-ID: <054.559ff0ac3aa2dfde11ff0fab9b80cdf4@localhost> #2520: SPECIALIZE causing duplicate assembler symbols --------------------------------------------+------------------------------- Reporter: ganesh | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: simplCore/should_compile/T2520 | Architecture: x86 Os: Linux | --------------------------------------------+------------------------------- Changes (by simonpj): * testcase: => simplCore/should_compile/T2520 * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Wed Aug 27 16:27:28 BST 2008 simonpj@microsoft.com * Fix Trac #2520: duplicate symbols }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 12:16:02 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 12:14:41 2008 Subject: [GHC] #2529: deriving Read fails on infix data constructors with record syntax In-Reply-To: <042.9534959a7ba451df3c949a110c475056@localhost> References: <042.9534959a7ba451df3c949a110c475056@localhost> Message-ID: <051.77a3b1d335db5cfbbc68e312c57f9e1d@localhost> #2529: deriving Read fails on infix data constructors with record syntax ----------------------+----------------------------------------------------- Reporter: spl | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown Comment: Excellent point thank you. Am fixing. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 15:37:02 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 15:35:35 2008 Subject: [GHC] #2549: Non null-terminated C strings sended to OpenGL functions. Message-ID: <048.590549b48ce208041e89fe161483ad2a@localhost> #2549: Non null-terminated C strings sended to OpenGL functions. --------------------------+------------------------------------------------- Reporter: Vincent.B | Owner: Type: bug | Status: new Priority: normal | Component: libraries/HGL Version: 6.8.3 | Severity: major Keywords: | Testcase: Architecture: x86 | Os: Windows --------------------------+------------------------------------------------- * Program started with GHC started like runhaskell does * debuggued with gDEBugger (OpenGL debug) Consider the following code : {{{ borderBind <- get $ programVars "borderColor" shadowBind <- get $ programVars "shadowColor" mathBind <- get $ uniformLocation txtProg "mathAlpha" alphaBind <- get $ uniformLocation txtProg "genAlpha" }}} I'm using it to retrieve the location of some variables in some shaders, the problem is the real value sended to OpenGL : < see image 1 > They are not null-terminated, and this way, sending some garbage appended at the end of the string. I've tested a little work-around : {{{ borderBind <- get $ programVars "borderColor\0" shadowBind <- get $ programVars "shadowColor\0" mathBind <- get $ uniformLocation txtProg "mathAlpha\0" alphaBind <- get $ uniformLocation txtProg "genAlpha\0" }}} And this way I'm able to recover the location normally. ---- After digging, the problem seem to be in Graphics.Rendering.OpenGL.GL.Shaders, with the function ''withGLStringLen''. This function is using withCAStringLen which acording to documentation ( [http://haskell.org/ghc/docs/latest/html/libraries/base/Foreign-C-String.html#v%3AwithCAStringLen] ) doesn't provide any assurance about the null termination. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 15:47:31 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 15:46:02 2008 Subject: [GHC] #2550: Add an option to use manifest files instead of filesystem hierarchy to find modules Message-ID: <047.3665f1a48a327f8421f4cc9de980373f@localhost> #2550: Add an option to use manifest files instead of filesystem hierarchy to find modules --------------------------------+------------------------------------------- Reporter: YitzGale | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- As discussed in the following thread: http://www.haskell.org/pipermail/haskell-cafe/2008-August/046494.html Add an option to look for modules using manifest files, rather than assuming that the filesystem contains a hierarchy of directories that exactly matches the module hierarchy. This is desirable for the following reasons: * It avoids an ugly and ad hoc dependency between two unrelated domains. * In large and complex projects, it allows the project manager more flexibility in using directory structure to organize teams and manage complex version control setups. * It avoids problems caused by mismatch between the filesystem and the module hierarchy, such as a non-hierarchical file system or incompatibilities in the way files are named. * It allows for more than one module per file. This is helpful because the module system is the only way to achieve encapsulation in Haskell, so the system needs to be as lightweight and flexible as possible. It also makes it easier to share and distribute Haskell programs when it is most convenient to do so as a single file, such as literate Haskell via email. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 17:10:30 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 17:09:02 2008 Subject: [GHC] #2546: Reliable crash in checkBlackHoles In-Reply-To: <044.f1d71ea4c4ced0ffd1ef244c500b6860@localhost> References: <044.f1d71ea4c4ced0ffd1ef244c500b6860@localhost> Message-ID: <053.74ea5f45dcfc2cd64ca002042200018c@localhost> #2546: Reliable crash in checkBlackHoles -------------------------+-------------------------------------------------- Reporter: nogin | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: duplicate Keywords: crash | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Changes (by nogin): * status: new => closed * resolution: => duplicate Comment: Indeed, this does not seem to be present in 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 27 21:11:20 2008 From: trac at galois.com (GHC) Date: Wed Aug 27 21:09:58 2008 Subject: [GHC] #2545: Data Parallel Haskell on Kubuntu 8.04 uses too much memory In-Reply-To: <047.a1caf49d69e3b7edd366bd96e3b1141c@localhost> References: <047.a1caf49d69e3b7edd366bd96e3b1141c@localhost> Message-ID: <056.5e4cfbf78cd103dffb49abafb92df319@localhost> #2545: Data Parallel Haskell on Kubuntu 8.04 uses too much memory -------------------------+-------------------------------------------------- Reporter: jjanssen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: Memory Leak | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------+-------------------------------------------------- Comment (by chak): I put a warning on the wiki page. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 28 07:38:05 2008 From: trac at galois.com (GHC) Date: Thu Aug 28 07:36:38 2008 Subject: [GHC] #2462: Data.List.sum is slower than 6.8.3 In-Reply-To: <047.a070686fa958e3b92e101be0217ff9b1@localhost> References: <047.a070686fa958e3b92e101be0217ff9b1@localhost> Message-ID: <056.90a630542c44a462f8ae74138321d888@localhost> #2462: Data.List.sum is slower than 6.8.3 --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: run-time performance bug | Status: reopened Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonmar): * status: closed => reopened * resolution: invalid => Comment: We think it's necessary to compile the definition of sum itself with -O2 in order to reproduce this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 28 07:46:45 2008 From: trac at galois.com (GHC) Date: Thu Aug 28 07:45:14 2008 Subject: [GHC] #2550: Add an option to use manifest files instead of filesystem hierarchy to find modules In-Reply-To: <047.3665f1a48a327f8421f4cc9de980373f@localhost> References: <047.3665f1a48a327f8421f4cc9de980373f@localhost> Message-ID: <056.b05329867119a813bac6ab0904802eaf@localhost> #2550: Add an option to use manifest files instead of filesystem hierarchy to find modules -----------------------------+---------------------------------------------- Reporter: YitzGale | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: You can choose your own mapping between filenames and module names as long as you tell GHC about all the filenames in your project. For example: {{{ $ cat >Foo.Burble.hs module Foo.Burble where $ cat >Bar.Mumble.hs module Bar.Mumble where import Foo.Burble $ cat >MyProg.hs module Main where import Foo.Burble import Bar.Mumble main = print "hello" $ ghc --make MyProg.hs Foo.Burble.hs Bar.Mumble.hs [1 of 3] Compiling Foo.Burble ( Foo.Burble.hs, Foo.Burble.o ) [2 of 3] Compiling Bar.Mumble ( Bar.Mumble.hs, Bar.Mumble.o ) [3 of 3] Compiling Main ( MyProg.hs, MyProg.o ) Linking MyProg ... }}} So your "manifest" might just be a list of filenames that you pass to ghc using {{{ghc --make `cat manifest`}}}. This doesn't let you put multiple modules in one file, of course. Also, I don't think you can do this with Cabal (or maybe you can?). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 28 08:14:39 2008 From: trac at galois.com (GHC) Date: Thu Aug 28 08:13:16 2008 Subject: [GHC] #2529: deriving Read fails on infix data constructors with record syntax In-Reply-To: <042.9534959a7ba451df3c949a110c475056@localhost> References: <042.9534959a7ba451df3c949a110c475056@localhost> Message-ID: <051.3e4b4d8059a7bf2861ce014fba273bee@localhost> #2529: deriving Read fails on infix data constructors with record syntax ---------------------------------------+------------------------------------ Reporter: spl | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: deriving/should_run/T2529 | Architecture: x86 Os: MacOS X | ---------------------------------------+------------------------------------ Changes (by simonpj): * testcase: => deriving/should_run/T2529 * status: new => closed * resolution: => fixed Comment: Fixed {{{ Thu Aug 28 13:10:06 BST 2008 simonpj@microsoft.com * Fix Trac #2529: derived read for prefix constructor operators }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 28 08:53:55 2008 From: trac at galois.com (GHC) Date: Thu Aug 28 08:52:42 2008 Subject: [GHC] #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts In-Reply-To: <045.1b6e550f0033cafaf14d077da3af73bb@localhost> References: <045.1b6e550f0033cafaf14d077da3af73bb@localhost> Message-ID: <054.a91ebae5bec0c5286481ae1c0f874075@localhost> #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts -------------------------------+-------------------------------------------- Reporter: japple | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): I agree that the generic versions should match the behaviour of the Int- specific versions. As I recall, the Int-specific Prelude functions originally called error, but this was changed around the time of Haskell 1.4/H'98. The failure to change the generic versions at the same time was just an oversight. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 28 10:12:29 2008 From: trac at galois.com (GHC) Date: Thu Aug 28 10:11:01 2008 Subject: [GHC] #2462: Data.List.sum is slower than 6.8.3 In-Reply-To: <047.a070686fa958e3b92e101be0217ff9b1@localhost> References: <047.a070686fa958e3b92e101be0217ff9b1@localhost> Message-ID: <056.01863e34d413fb4f45266e5ad5211402@localhost> #2462: Data.List.sum is slower than 6.8.3 --------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: run-time performance bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonpj): * status: reopened => closed * resolution: => invalid Comment: I did that and it's still fine. Re-open if you think otherwise! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 28 10:16:44 2008 From: trac at galois.com (GHC) Date: Thu Aug 28 10:15:12 2008 Subject: [GHC] #2550: Add an option to read file names from a file instead of the command line In-Reply-To: <047.3665f1a48a327f8421f4cc9de980373f@localhost> References: <047.3665f1a48a327f8421f4cc9de980373f@localhost> Message-ID: <056.d89e8e7d342d5d62cece0cef8c7d3d75@localhost> #2550: Add an option to read file names from a file instead of the command line -----------------------------+---------------------------------------------- Reporter: YitzGale | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by YitzGale): * summary: Add an option to use manifest files instead of filesystem hierarchy to find modules => Add an option to read file names from a file instead of the command line Comment: Nice. Could this be documented in sections 5.6.1 and 5.6.3 of the manual please? There could be too many file names to be able to specify them on the command line. So it still would be useful to have an option to specify the file names in a file. Multiple modules per file now sounds like an orthogonal issuse, I'll open a separate request for that. And yes, Cabal support is another orthogonal issue. So it now sounds like this feature should be easy to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 28 10:28:38 2008 From: trac at galois.com (GHC) Date: Thu Aug 28 10:27:08 2008 Subject: [GHC] #2551: Allow multiple modules per source file Message-ID: <047.3a5018e62377d0e216dd18feced12298@localhost> #2551: Allow multiple modules per source file --------------------------------+------------------------------------------- Reporter: YitzGale | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- This is helpful because the module system is the only way to achieve encapsulation in Haskell, so the system needs to be as lightweight and flexible as possible. It also makes it easier to share and distribute Haskell programs when it is most convenient to do so as a single file, such as literate Haskell via email. To use this feature, one would specify files to be compiled explicitly. When GHC searches on its own for modules, it needs the path of the file to indicate the name of the module it contains, so multiple modules are not possible in that case. See #2550, and the thread in: http://www.haskell.org/pipermail/haskell-cafe/2008-August/046494.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 28 10:54:12 2008 From: trac at galois.com (GHC) Date: Thu Aug 28 10:52:42 2008 Subject: [GHC] #2552: SCC annotation behavior differs between toplevel and non-toplevel Message-ID: <044.15a1341c91a98c8a8d7587f72c101e1e@localhost> #2552: SCC annotation behavior differs between toplevel and non-toplevel ------------------------------+--------------------------------------------- Reporter: Rauli | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: scc profiling | Testcase: Architecture: x86 | Os: Linux ------------------------------+--------------------------------------------- I'm not sure if this is a bug, but using ghc -prof -auto-all and manual SCC annotations for non-toplevel functions produces very different results from moving the same function to toplevel: {{{ fib n = nfib' n where nfib' n = {-# SCC "nfib'" #-} nfib n -- %time: 0 (both individual and inherited) where nfib n = if n < 2 then 1 else nfib (n-1) + nfib (n-2) fib n = nfib' n nfib' n = nfib n -- %time: 100 (both individual and inherited) where nfib n = if n < 2 then 1 else nfib (n-1) + nfib (n-2) }}} This happens with both -O0 and -O2, even when these functions are not exported. Adding a NOINLINE for nfib' doesn't change anything. Computing the correct inherited time for the SCC would be useful to pinpoint the cost centres inside a more complex function. Currently one needs to move them to toplevel to get the same effect. Given that the toplevel route works, it's also counterintuitive that manual SCC annotations don't. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 28 11:56:58 2008 From: trac at galois.com (GHC) Date: Thu Aug 28 11:55:27 2008 Subject: [GHC] #2550: Add an option to read file names from a file instead of the command line In-Reply-To: <047.3665f1a48a327f8421f4cc9de980373f@localhost> References: <047.3665f1a48a327f8421f4cc9de980373f@localhost> Message-ID: <056.b13acdb33c4c3564c7cbf2ed06927f9f@localhost> #2550: Add an option to read file names from a file instead of the command line -----------------------------+---------------------------------------------- Reporter: YitzGale | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by YitzGale): Having an option to read file names from a file is also less platform dependent - the backticks trick is specific to Unix-like shells. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 28 13:48:09 2008 From: trac at galois.com (GHC) Date: Thu Aug 28 13:46:45 2008 Subject: [GHC] #2253: Native code generator could do better In-Reply-To: <043.862f2d1bf55b0e0d2dddbf6af3659352@localhost> References: <043.862f2d1bf55b0e0d2dddbf6af3659352@localhost> Message-ID: <052.263199bfa01bd76cd9c332a199c9fb05@localhost> #2253: Native code generator could do better --------------------------------------+------------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (NCG) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Unknown | --------------------------------------+------------------------------------- Changes (by guest): * cc: kfrdbs@gmail.com (added) Comment: New code generator may help: [http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/NewCodeGen] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 28 13:49:20 2008 From: trac at galois.com (GHC) Date: Thu Aug 28 13:47:50 2008 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@localhost> Message-ID: <052.07833b1a1984961d492333dc537fc19c@localhost> #2289: Needless reboxing of values when returning from a tight loop ----------------------------------------+----------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: boxing, loops, performance | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------------+----------------------------------- Changes (by guest): * cc: kfrdbs@gmail.com (added) Comment: New code generator may help: [http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/NewCodeGen] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 28 15:39:30 2008 From: trac at galois.com (GHC) Date: Thu Aug 28 15:38:00 2008 Subject: [GHC] #2553: panic: RegAllocLinear.getStackSlotFor: out of stack slots Message-ID: <056.cbc47ed313e48fa03058c7472b71f14a@localhost> #2553: panic: RegAllocLinear.getStackSlotFor: out of stack slots ----------------------------------+----------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux ----------------------------------+----------------------------------------- Trying to cabal install the crypto library, I got the error: {{{ [1 of 4] Compiling Codec.Utils ( Codec/Utils.hs, dist/build/SHA1Test /SHA1Test-tmp/Codec/Utils.o ) [2 of 4] Compiling Data.Digest.SHA1 ( Data/Digest/SHA1.hs, dist/build/SHA1Test/SHA1Test-tmp/Data/Digest/SHA1.o ) [3 of 4] Compiling Codec.Text.Raw ( Codec/Text/Raw.hs, dist/build/SHA1Test/SHA1Test-tmp/Codec/Text/Raw.o ) [4 of 4] Compiling Main ( ./SHA1Test.hs, dist/build/SHA1Test /SHA1Test-tmp/Main.o ) ghc-6.8.3: panic! (the 'impossible' happened) (GHC version 6.8.3 for i386-unknown-linux): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: Crypto-4.1.0 failed during the building phase. The exception was: exit: ExitFailure 1 }}} twice, so it seems to be reproducible. However, passing the flag -fregs-graph, it built without error (though compiling the SHA1Test Main took a long time, approximately two minutes). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 29 03:37:05 2008 From: trac at galois.com (GHC) Date: Fri Aug 29 03:35:35 2008 Subject: [GHC] #2554: internal error: stg_ap_pp_ret (with terminfo) Message-ID: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> #2554: internal error: stg_ap_pp_ret (with terminfo) -----------------------+---------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- When trying to run the haskeline package against HEAD, I sometimes get bus errors, segfaults or the following error: {{{ Test: internal error: stg_ap_pp_ret (GHC version 6.9.20080827 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap }}} I've tried to strip down the relevant parts of the code. Attached is my best attempt to isolate the error. The code runs fine on 6.8.3, but crashes with a segfault or bus error if it was compiled with ghc-6.9.20080827: {{{ $ ~/tmp/ghc-stage/bin/ghc --make -threaded Test.hs -fforce-recomp -lncurses [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ ./Test foobar1 Starting loop... About to do the bad thing. Segmentation fault }}} This is with OS X 10.5.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 29 12:35:49 2008 From: trac at galois.com (GHC) Date: Fri Aug 29 12:34:16 2008 Subject: [GHC] #2554: internal error: stg_ap_pp_ret (with terminfo) In-Reply-To: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> References: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> Message-ID: <053.84c841491e8720149e3bda7f230428f5@localhost> #2554: internal error: stg_ap_pp_ret (with terminfo) -------------------------+-------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- Comment (by judah): I managed to strip down the test case to eliminate the dependency on the curses library. Hopefully this isolates the problem a little better. See the attached `Test.hs` and `c_test.c`. {{{ $ ~/tmp/ghc-stage/bin/ghc --make -fforce-recomp -threaded Test.hs c_test.c [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ ./Test Calling function. Called function. Calling function. Test: internal error: stg_ap_pp_ret (GHC version 6.9.20080827 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 29 18:03:40 2008 From: trac at galois.com (GHC) Date: Fri Aug 29 18:02:07 2008 Subject: [GHC] #2420: Multi-method classes are inlined/specialized better than single-method classes for strict types In-Reply-To: <048.3992ed493cb4d18feeaa36522408a406@localhost> References: <048.3992ed493cb4d18feeaa36522408a406@localhost> Message-ID: <057.0b40cb4edae30707fbe1be63ec0a5da3@localhost> #2420: Multi-method classes are inlined/specialized better than single-method classes for strict types -----------------------+---------------------------------------------------- Reporter: sedillard | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | -----------------------+---------------------------------------------------- Comment (by simonpj): I know something about what is going on here. First, there's nothing very bad happening. The code ''looks'' worse, but at any call to `squarepd`, the whole definition will be inlined, and then `$WPair` will be inlined, and it'll all turn out like the previous case. So efficiency should be similar either way. Why the difference between the two cases? Because the details of inlining are regrettably delicate. The `__inline_me__` note makes the enclosed expression look small, so that it'll be keen to inline. When it ''is'' inlined at an application, the `__inline_me__` wrapper is removed. But in your example you have {{{ squarepd = square }}} where `square` in this case is the `Pair` instance function, which is marked `INLINE`. This isn't an application of `square`; rather it's more like a renaming, so we end up with an `__inline_me__` around the `squarepd` RHS. Inside `__inline_me__` GHC is very reluctant to do any inlining at all; it just blows up the thing to be inlined. Leave it until it ''is'' inlined. If you instead wrote {{{ squarepd x = square x }}} now it looks like a ''call'' of `square`, so the thing it inlined and the `__inline_me__` is stripped off, and then `$WPair` can get inlined. That's the general idea. For 6.10 I have two changes in the works that will affect this: (a) a new way of treating INLINE pragmas, and (b) a new way of treating instance declarations. So I'm not going to pursue this further until I've done that. I'll leave it open to remind me to take another look then. Meanwhile: do you think the difference has a performance impact (contrary to my claim)? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 08:41:09 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 08:39:32 2008 Subject: [GHC] #2555: Template Haskell does not respect -package and -hide constraints Message-ID: <044.7c1849c0092957cb6d9dc4fd3b20e42f@localhost> #2555: Template Haskell does not respect -package and -hide constraints ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Linux ------------------------+--------------------------------------------------- (I am using 6.8.2-2ubuntu1, packaged for Ubuntu Hardy Heron, on amd64.) Recently sjanssen added some patches to the Lambdabot darcs repository which replace a preprocessor, BotPP, with some Template Haskell. This seems to work well, however I ran into a problem with it - everytime TH was called, it would error out with a message about Bytestring 0.9.1.0. This is far from the first time I've run into this problem, but it was not fixed by forcibly removing 0.9.1.0 & recompiling affected packages against bytestring 09.0.1! After even more debugging, I finally figured it out: The module TH was erroring out on has an 'import Text.Regex'. Text.Regex is installed by the regex-compat package. I had two regex-compats installed. regex-compat-0.91 was linked against bytestring0.9.0.1. regex- compat-0.92 was linked against (the removed) bytestring-0.9.1.0. Now, normally Cabal detects that using 0.92 would lead to errors, and it selects 0.91, and it adds to the GHC options '-hide-all-package -package regex-compat-0.91', and everything compiles fine and the user is happy. But! in this case, Template Haskell ignores the flags, and it uses the most recent regex-compat. And it is this that breaks the build. I ultimately resolved this issue by removing regex-compat-0.92 and reinstalling and linking it against 0.9.0.1, although I fear this may yet lead to bugs in the future. Short summary: Cabal is smarter than TH and picks better package versions to compile against, and yet TH ignores Cabal's picks. This leads to unnecessary & difficult to figure out compile failures. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 08:41:37 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 08:40:00 2008 Subject: [GHC] #2555: Template Haskell does not respect -package and -hide constraints In-Reply-To: <044.7c1849c0092957cb6d9dc4fd3b20e42f@localhost> References: <044.7c1849c0092957cb6d9dc4fd3b20e42f@localhost> Message-ID: <053.f085ff88a3147224a8b213c41dbced55@localhost> #2555: Template Haskell does not respect -package and -hide constraints -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Linux -------------------------+-------------------------------------------------- Changes (by guest): * cc: gwern0@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 09:23:14 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 09:21:37 2008 Subject: [GHC] #2335: Haddock's internal GHC version must match the configured GHC version In-Reply-To: <042.dd7881e9cf460e19411390b51f02530e@localhost> References: <042.dd7881e9cf460e19411390b51f02530e@localhost> Message-ID: <051.fbd80277cb8787189de0fb59631b7e93@localhost> #2335: Haddock's internal GHC version must match the configured GHC version --------------------------+------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.10.1 Component: Build System | Version: 6.8.2 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: haddock 2 is now built while building ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 12:06:07 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 12:04:36 2008 Subject: [GHC] #1389: readline checks in configure.ac can probably be removed In-Reply-To: <047.d6f3a7067b92adffac648351296fa875@localhost> References: <047.d6f3a7067b92adffac648351296fa875@localhost> Message-ID: <056.78ce24feb53ee790c32eed3017630ad5@localhost> #1389: readline checks in configure.ac can probably be removed --------------------------+------------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: closed Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: The only readline references now are in mk/bootstrap.mk as far as I can see, and fixing bootstrapping is a separate issue, so I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 16:15:25 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 16:13:48 2008 Subject: [GHC] #2427: Allow compilation of source from stdin In-Reply-To: <044.abbe9ae8909931700fcc95de3eb51afe@localhost> References: <044.abbe9ae8909931700fcc95de3eb51afe@localhost> Message-ID: <053.0f6fe1579d6ed17f5baf148fe3013fae@localhost> #2427: Allow compilation of source from stdin -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: low | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * priority: normal => low * milestone: => 6.12 branch Comment: This is probably quite low priority for us currently, so do add yourself to this ticket if it's important for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 16:24:53 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 16:23:14 2008 Subject: [GHC] #2556: Deprecated perl stuff in ghc-split Message-ID: <044.ceb58b94b19e4b109063f24afc9124ec@localhost> #2556: Deprecated perl stuff in ghc-split ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Linux ------------------------+--------------------------------------------------- On Ubuntu Intrepid Ibex (adm64): gwern@craft:19282~>perl --version [ 4:22PM] This is perl, v5.10.0 built for x86_64-linux-gnu-thread-multi Every single compiled module generates a warning: "$* is no longer supported at /usr/lib/ghc-6.8.2/ghc-split line 39." The line mentioned is: $* = 1; # multi-line matches are OK ---- This deprecation warning is very annoying and obscures output, especially on packages with hundreds of modules such as XMonad or Darcs. A fix would be nice; presumably Perl would not have deprecated something without a easy fix being available. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 16:29:01 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 16:27:22 2008 Subject: [GHC] #2439: Missed optimisation with dictionaries and loops In-Reply-To: <041.4a9e022e22f0d06a0023c060ae99c7bb@localhost> References: <041.4a9e022e22f0d06a0023c060ae99c7bb@localhost> Message-ID: <050.04708016d76866c6cb74b57fd35d5cd8@localhost> #2439: Missed optimisation with dictionaries and loops --------------------------------------+------------------------------------- Reporter: rl | Owner: simonpj Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * owner: => simonpj * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 16:34:37 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 16:32:59 2008 Subject: [GHC] #2440: Bad code with type families In-Reply-To: <041.36cfaf77666d90945b8031e68cebdd8a@localhost> References: <041.36cfaf77666d90945b8031e68cebdd8a@localhost> Message-ID: <050.7f871f4fba3e90193314811528458e0e@localhost> #2440: Bad code with type families --------------------------------------+------------------------------------- Reporter: rl | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 16:36:47 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 16:35:09 2008 Subject: [GHC] #2442: Heuristics to improve error messages for badly referenced things In-Reply-To: <053.d96b74737451be892238b37815ca44b6@localhost> References: <053.d96b74737451be892238b37815ca44b6@localhost> Message-ID: <062.98b272b2386cf65a73e78c1ddb560303@localhost> #2442: Heuristics to improve error messages for badly referenced things -----------------------------+---------------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.12 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * priority: normal => high * milestone: => 6.12 branch Comment: I don't think we'll look at this in time for 6.10, but we should make a decision early in 6.12 to avoid collecting any more conflicts than necessary (although I guess it'll be in the wrong VCS by then; ug). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 17:13:10 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 17:11:32 2008 Subject: [GHC] #2557: building HEAD fails when editline is installed as a user package Message-ID: <045.4540196d5276eabdacdaa367ea1601d5@localhost> #2557: building HEAD fails when editline is installed as a user package -----------------------+---------------------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: minor Keywords: | Testcase: Architecture: x86 | Os: MacOS X -----------------------+---------------------------------------------------- Building stage1 of HEAD fails when editline is installed as a user-level package, but not as a global package, in the bootstrapping compiler. I am using ghc-6.8.3 to build ghc-6.9.20080830. {{{ /Users/judah/Programming/dontbackup/ghc-unvalidated/libraries/cabal-bin /usr/local/bin/ghc /Users/judah/Programming/dontbackup/ghc- unvalidated/libraries/bootstrapping.conf configure --distpref dist-stage1 \ --flags=stage1 --flags=-ghci --flags=ncg --flags=editline --ghc-options='-#include "cutils.h"' --with- compiler=/usr/local/bin/ghc --with-hc-pkg=/usr/local/bin/ghc-pkg --package-db /Users/judah/Programming/dontbackup/ghc- unvalidated/libraries/bootstrapping.conf \ --prefix=/NONEXISTENT --bindir=/NONEXISTENT --libdir=/NONEXISTENT --libexecdir=/NONEXISTENT --datadir=/NONEXISTENT --docdir=/NONEXISTENT --haddockdir=/NONEXISTENT --htmldir=/NONEXISTENT \ --libsubdir='$pkgid' --with-gcc=gcc --with- ld=/usr/bin/ld --with-hscolour=/Users/judah/.cabal/bin/HsColour --with- alex=/usr/local/bin/alex --with-happy=/Users/judah/.cabal/bin/happy --configure-option='--prefix=/Users/judah/tmp/ghc-stage' --configure- option=--with-cc=gcc --with-hsc2hs=/Users/judah/Programming/dontbackup /ghc-unvalidated/utils/hsc2hs/install-inplace/bin/hsc2hs \ --ghc-option=-DSTAGE=1 Configuring ghc-6.9... cabal-bin: At least the following dependencies are missing: editline -any make[1]: *** [boot.stage.1] Error 1 make: *** [stage1] Error 1 }}} Ghc decides whether to use editline in stage1 based on the flag `GhcHasEditline`, which the configure script sets to True in this case. Since the above cabal-bin command doesn't look at the user-level package DB, Cabal doesn't see the editline package and complains. When the build system changes (post-6.10) to rely less on Cabal, this issue may go away. But for 6.10, I think that the easiest solution is to just never build stage1 with editline. Note that we already never build ghci in stage1 (see `compiler/Makefile`), so this seems reasonable to me. Patch is attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 17:16:32 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 17:14:53 2008 Subject: [GHC] #2557: building HEAD fails when editline is installed as a user package In-Reply-To: <045.4540196d5276eabdacdaa367ea1601d5@localhost> References: <045.4540196d5276eabdacdaa367ea1601d5@localhost> Message-ID: <054.8c63f0f396d786234512aed5ab653326@localhost> #2557: building HEAD fails when editline is installed as a user package -------------------------+-------------------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Testcase: Architecture: x86 | Os: MacOS X -------------------------+-------------------------------------------------- Changes (by judahj): * version: 6.8.3 => 6.9 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 20:40:51 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 20:39:15 2008 Subject: [GHC] #2443: @EnableWin32DLLs@ in mk/config.mk In-Reply-To: <045.5cbd6ee8b0d9740b3306b11c8e19da4a@localhost> References: <045.5cbd6ee8b0d9740b3306b11c8e19da4a@localhost> Message-ID: <054.c4a3e4d792f973a454fcc34ff623c120@localhost> #2443: @EnableWin32DLLs@ in mk/config.mk --------------------------+------------------------------------------------- Reporter: rurban | Owner: rurban Type: bug | Status: assigned Priority: normal | Milestone: Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Multiple | --------------------------+------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > @EnableWin32DLLs@ should be temp. disabled also. > > [EnableWin32DLLs.patch > rurban@x-ray.at**20080713112530] hunk ./mk/config.mk.in 410 > -DLLized=@EnableWin32DLLs@ > +#temp. disabled. was @EnableWin32DLLs@ > +DLLized=NO New description: {{{ @EnableWin32DLLs@ should be temp. disabled also. [EnableWin32DLLs.patch rurban@x-ray.at**20080713112530] hunk ./mk/config.mk.in 410 -DLLized=@EnableWin32DLLs@ +#temp. disabled. was @EnableWin32DLLs@ +DLLized=NO }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 20:42:01 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 20:40:22 2008 Subject: [GHC] #2443: @EnableWin32DLLs@ in mk/config.mk In-Reply-To: <045.5cbd6ee8b0d9740b3306b11c8e19da4a@localhost> References: <045.5cbd6ee8b0d9740b3306b11c8e19da4a@localhost> Message-ID: <054.60a070de3417508f740dec3da55d7b91@localhost> #2443: @EnableWin32DLLs@ in mk/config.mk --------------------------+------------------------------------------------- Reporter: rurban | Owner: rurban Type: bug | Status: assigned Priority: normal | Milestone: 6.10.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Multiple | --------------------------+------------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 Comment: Does anyone know what the status of this is? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 20:44:54 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 20:43:16 2008 Subject: [GHC] #2444: gtk2hs 0.9.13 fails to build on ppc due to bad code generated with -fvia-C In-Reply-To: <042.86c4267360832e863379a2145bf9d85a@localhost> References: <042.86c4267360832e863379a2145bf9d85a@localhost> Message-ID: <051.3c63f6864b1d097ef133c1b7c58ba28a@localhost> #2444: gtk2hs 0.9.13 fails to build on ppc due to bad code generated with -fvia-C ----------------------+----------------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: I'm afraid that I don't think that we'll fix this before `-fvia-C` and the mangler is removed in 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 20:46:11 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 20:44:41 2008 Subject: [GHC] #2448: Type equality constraint not propagated to superclass In-Reply-To: <044.69c727e94da0f0e8a02cdc7148428338@localhost> References: <044.69c727e94da0f0e8a02cdc7148428338@localhost> Message-ID: <053.82e3fcc400a86178f838c65ccf6c8b53@localhost> #2448: Type equality constraint not propagated to superclass ------------------------------------------------------+--------------------- Reporter: conal | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: type families, type equality constraints | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------------------------------+--------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 20:47:00 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 20:45:21 2008 Subject: [GHC] #2453: users_guide/syntax-extns.html # 8.3.3, control.monad doc, etc, have obsolete refs to www.cse.ogi.edu In-Reply-To: <044.c1e45508467fb83fb9ed0eb2a4a7e130@localhost> References: <044.c1e45508467fb83fb9ed0eb2a4a7e130@localhost> Message-ID: <053.7562d63c4d3686b3a4627a46a3af99c2@localhost> #2453: users_guide/syntax-extns.html # 8.3.3, control.monad doc, etc, have obsolete refs to www.cse.ogi.edu ---------------------------+------------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: trivial | Resolution: Keywords: OGI | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 30 20:50:13 2008 From: trac at galois.com (GHC) Date: Sat Aug 30 20:48:42 2008 Subject: [GHC] #2458: GHC MacOS X Leopard build succeeds, but ghci complains about: unknown symbol `_environ' In-Reply-To: <048.8d22aecac33c2afb7c79a5628eb01872@localhost> References: <048.8d22aecac33c2afb7c79a5628eb01872@localhost> Message-ID: <057.4708817355b460be35072cdf9630e041@localhost> #2458: GHC MacOS X Leopard build succeeds, but ghci complains about: unknown symbol `_environ' ----------------------------+----------------------------------------------- Reporter: IgorBoehm | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.9 Severity: major | Resolution: Keywords: environ | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 07:35:38 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 07:34:05 2008 Subject: [GHC] #2458: GHC MacOS X Leopard build succeeds, but ghci complains about: unknown symbol `_environ' In-Reply-To: <048.8d22aecac33c2afb7c79a5628eb01872@localhost> References: <048.8d22aecac33c2afb7c79a5628eb01872@localhost> Message-ID: <057.1769e40c99fdf1b33ff0f28078fb3a14@localhost> #2458: GHC MacOS X Leopard build succeeds, but ghci complains about: unknown symbol `_environ' ----------------------------+----------------------------------------------- Reporter: IgorBoehm | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.9 Severity: major | Resolution: fixed Keywords: environ | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Hmm, this works for me; presumably fixed by Cabal's `Distribution.Simple.GHC.stripExe` doing: {{{ args = path : case buildOS of OSX -> ["-x"] -- By default, stripping the ghc binary on at least -- some OS X installations causes: -- HSbase-3.0.o: unknown symbol `_environ'" -- The -x flag fixes that. _ -> [] }}} so I'm closing this ticket. Please reopen it if you still think there's a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 07:40:54 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 07:39:14 2008 Subject: [GHC] #2464: Allow #ifdef'd pragmas In-Reply-To: <042.da2d7162b5833ab052aba0dee11396e7@localhost> References: <042.da2d7162b5833ab052aba0dee11396e7@localhost> Message-ID: <051.cd74093a435753ad2834d18f38d0c516@localhost> #2464: Allow #ifdef'd pragmas -------------------------------+-------------------------------------------- Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Parser) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 07:51:26 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 07:49:47 2008 Subject: [GHC] #2466: Execution time mis-accounting In-Reply-To: <047.14a5fe48bc275ad5be0eac4353281985@localhost> References: <047.14a5fe48bc275ad5be0eac4353281985@localhost> Message-ID: <056.f9f7b80f6df3a714a8ddf07b9239d40e@localhost> #2466: Execution time mis-accounting -----------------------+---------------------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -----------------------+---------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 07:52:04 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 07:50:24 2008 Subject: [GHC] #2467: orphan instance warnings are badly behaved In-Reply-To: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> References: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> Message-ID: <054.f648d51b959953e6e1306513c3701da6@localhost> #2467: orphan instance warnings are badly behaved ----------------------+----------------------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 07:59:47 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 07:58:07 2008 Subject: [GHC] #2469: Linking fails with "multiple definition of `deRefStablePtr'" In-Reply-To: <048.9eb18d1762f2087efabea300fec1f63f@localhost> References: <048.9eb18d1762f2087efabea300fec1f63f@localhost> Message-ID: <057.8d662bb7f3774e3fe3cb9ad04051b209@localhost> #2469: Linking fails with "multiple definition of `deRefStablePtr'" ----------------------------------+----------------------------------------- Reporter: meteficha | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler (FFI) | Version: 6.8.2 Severity: normal | Resolution: Keywords: linker ffi stableptr | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks, we'll take a look. Looks like this example depends on GLFW and OpenGL. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 08:10:10 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 08:08:30 2008 Subject: [GHC] #2472: GHC: Hard-coded and wrong path to perl interpreter for ghc-asm In-Reply-To: <046.0c29c740873e6968d58d3860791897c0@localhost> References: <046.0c29c740873e6968d58d3860791897c0@localhost> Message-ID: <055.c4e8141f3a626a372eb73512e9e9054d@localhost> #2472: GHC: Hard-coded and wrong path to perl interpreter for ghc-asm ----------------------------+----------------------------------------------- Reporter: sanketr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: major | Resolution: invalid Keywords: ghc, asm, perl | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: This looks like just a bug in the Mac installer. GHC detects the location of perl when building, and it looks like it was in a non-standard place on the machine the installer was built. It detects /usr/bin/perl on my Mac. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 08:17:25 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 08:15:49 2008 Subject: [GHC] #2477: -package-conf flag makes runghc fail In-Reply-To: <043.3badf8aec8b2932c76550c9b14657312@localhost> References: <043.3badf8aec8b2932c76550c9b14657312@localhost> Message-ID: <052.068ac4ec72599ee06e85641988ab3016@localhost> #2477: -package-conf flag makes runghc fail ---------------------------+------------------------------------------------ Reporter: fons | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Changes (by igloo): * status: reopened => new * owner: => igloo * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 08:20:49 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 08:19:12 2008 Subject: [GHC] #2480: error function is not lazy In-Reply-To: <051.ecb98bd3181d9ab4e7aa4d8a7990d204@localhost> References: <051.ecb98bd3181d9ab4e7aa4d8a7990d204@localhost> Message-ID: <060.f9d7c785719c7f2976c58855ac2e855f@localhost> #2480: error function is not lazy --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: cg016 | Architecture: Unknown Os: Windows | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: You can use a top-level error handler if you want to do something like this, so I think the current behaviour is a reasonable default. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 08:24:51 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 08:23:10 2008 Subject: [GHC] #2493: implement proposed Qualified Operator syntax In-Reply-To: <051.85a6e8a5d506f432836c995c200eacbf@localhost> References: <051.85a6e8a5d506f432836c995c200eacbf@localhost> Message-ID: <060.36ad753167f46567892a9c0d4ec005ff@localhost> #2493: implement proposed Qualified Operator syntax -----------------------------+---------------------------------------------- Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: I think the flag ought to turn off support for H98 qualified operators, too. I don't really like "Saner", but I don't like anything else I can think of (New, Prime, Parenthesised) either. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 08:26:26 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 08:24:47 2008 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@localhost> References: <044.b515c7a01d17e019028e237b73b96edc@localhost> Message-ID: <053.d0fd68c1fd7c3ae2f4d850eb2c0ea06e@localhost> #2496: Invalid Eq/Ord instances in Data.Version ----------------------------+----------------------------------------------- Reporter: guest | Owner: duncan.coutts@worc.ox.ac.uk Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: => duncan.coutts@worc.ox.ac.uk * difficulty: => Unknown * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 08:31:04 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 08:29:24 2008 Subject: [GHC] #2501: [Document] Is it possible to add an example to show how to use SCC in profiling? Moreover, there seems no explaination for +RTS -s -S In-Reply-To: <049.55daf57c282859db865e658846ee4aed@localhost> References: <049.55daf57c282859db865e658846ee4aed@localhost> Message-ID: <058.b32a00ef006fe945e59d3c5ddbd35f99@localhost> #2501: [Document] Is it possible to add an example to show how to use SCC in profiling? Moreover, there seems no explaination for +RTS -s -S ---------------------------+------------------------------------------------ Reporter: rivercheng | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.2 Severity: normal | Resolution: Keywords: SCC profiling | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ---------------------------+------------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 08:32:18 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 08:30:37 2008 Subject: [GHC] #2510: Environment modification during installation should be optional In-Reply-To: <045.3e84f679ca4e95a8a9ec350bbb64b495@localhost> References: <045.3e84f679ca4e95a8a9ec350bbb64b495@localhost> Message-ID: <054.ced912bd2067a311d0573099b7857c98@localhost> #2510: Environment modification during installation should be optional -----------------------------+---------------------------------------------- Reporter: nimnul | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 08:32:36 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 08:30:56 2008 Subject: [GHC] #2511: unix package doesnt load in ghci on freebsd/amd64 In-Reply-To: <046.b342e2cde385158917f69c7725044f60@localhost> References: <046.b342e2cde385158917f69c7725044f60@localhost> Message-ID: <055.33db5969e66272bcb016e1f14389bf27@localhost> #2511: unix package doesnt load in ghci on freebsd/amd64 ----------------------------+----------------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > When loading the "unix" package in ghci, the interpreter gives a link > error: > > $ ghci -package unix > GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > Loading package old-locale-1.0.0.0 ... linking ... done. > Loading package old-time-1.0.0.0 ... linking ... done. > Loading package filepath-1.1.0.0 ... linking ... done. > Loading package directory-1.0.0.0 ... linking ... done. > Loading package unix-2.3.0.0 ... ghc-6.8.2: can't load .so/.DLL for: util > (/usr/lib/libutil.so: Undefined symbol "__mb_sb_limit") > > As noted above this is ghc-6.8.2. I built from sources. My machine is: > FreeBSD hpsux 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sat Mar 8 14:07:11 HST > 2008 root@hpsux:/usr/obj/usr/src/sys/GENERIC amd64 New description: When loading the "unix" package in ghci, the interpreter gives a link error: {{{ $ ghci -package unix GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package filepath-1.1.0.0 ... linking ... done. Loading package directory-1.0.0.0 ... linking ... done. Loading package unix-2.3.0.0 ... ghc-6.8.2: can't load .so/.DLL for: util (/usr/lib/libutil.so: Undefined symbol "__mb_sb_limit") }}} As noted above this is ghc-6.8.2. I built from sources. My machine is: {{{ FreeBSD hpsux 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sat Mar 8 14:07:11 HST 2008 root@hpsux:/usr/obj/usr/src/sys/GENERIC amd64 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 08:37:57 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 08:36:18 2008 Subject: [GHC] #2511: unix package doesnt load in ghci on freebsd/amd64 In-Reply-To: <046.b342e2cde385158917f69c7725044f60@localhost> References: <046.b342e2cde385158917f69c7725044f60@localhost> Message-ID: <055.9040f4b2aa9b8c2797c0cd4e19727107@localhost> #2511: unix package doesnt load in ghci on freebsd/amd64 ----------------------------+----------------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/unix | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: FreeBSD | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 Comment: Based on a quick google, it looks like this is a FreeBSD libc thing. Did you build against the same libc you are running? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 08:42:48 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 08:41:08 2008 Subject: [GHC] #2512: MAP_32BIT flag might not be respected under xen? In-Reply-To: <044.02579c65234b2e00edf9fbae992e571c@localhost> References: <044.02579c65234b2e00edf9fbae992e571c@localhost> Message-ID: <053.858da3c409f682fe748b532886f2c532@localhost> #2512: MAP_32BIT flag might not be respected under xen? ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: None | Version: 6.8.3 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 08:46:09 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 08:44:29 2008 Subject: [GHC] #2514: Add/Expose Binary API that allows dumping of any GHC Binary instance In-Reply-To: <047.57cf723e547f8e60541f4f12c39c26fa@localhost> References: <047.57cf723e547f8e60541f4f12c39c26fa@localhost> Message-ID: <056.369842ce4668ad99a6ab38bc975dbe29@localhost> #2514: Add/Expose Binary API that allows dumping of any GHC Binary instance -----------------------------+---------------------------------------------- Reporter: nominolo | Owner: nominolo Type: feature request | Status: new Priority: normal | Milestone: 6.10.1 Component: GHC API | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: Do either of you know what the status of this is? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 08:46:41 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 08:45:01 2008 Subject: [GHC] #2517: remove 'pure' method from Arrow class In-Reply-To: <043.bffe8bdb0940ee07d4e323e480390725@localhost> References: <043.bffe8bdb0940ee07d4e323e480390725@localhost> Message-ID: <052.f07ef9dfba7fb118e05af676ecb4fdfe@localhost> #2517: remove 'pure' method from Arrow class ----------------------------+----------------------------------------------- Reporter: ross | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 08:56:32 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 08:54:51 2008 Subject: [GHC] #2519: Time.toClockTime: picoseconds out of range, after diffClockTimes In-Reply-To: <046.99e01b8d2f29c1267b52b4fd1e83a300@localhost> References: <046.99e01b8d2f29c1267b52b4fd1e83a300@localhost> Message-ID: <055.0c78addffa3516bb8d75e8403d785e3b@localhost> #2519: Time.toClockTime: picoseconds out of range, after diffClockTimes ----------------------+----------------------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: TimeDiff | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => _|_ Comment: I recommend you use the new `time` package instead of `old-time`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 08:57:59 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 08:56:25 2008 Subject: [GHC] #2522: Warning for missing export lists In-Reply-To: <042.bc97894bc85aa965fac36f83804d8ebb@localhost> References: <042.bc97894bc85aa965fac36f83804d8ebb@localhost> Message-ID: <051.18a0987e8a5e3cf0253c0f49803e8ee0@localhost> #2522: Warning for missing export lists -----------------------------+---------------------------------------------- Reporter: tim | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: I guess we wouldn't warn about {{{ module Foo (module Foo) where ... }}} ? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 08:58:21 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 08:56:40 2008 Subject: [GHC] #2526: warn about missing signatures only for exported functions In-Reply-To: <054.8d84f54fed1e47316e9d59e9281759fd@localhost> References: <054.8d84f54fed1e47316e9d59e9281759fd@localhost> Message-ID: <063.160e97c9115542ea10440558e4e86751@localhost> #2526: warn about missing signatures only for exported functions -----------------------------+---------------------------------------------- Reporter: fergushenderson | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:03:28 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:01:48 2008 Subject: [GHC] #2528: nub not as reliable as nubBy In-Reply-To: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> References: <047.2632c5cc755f3bbba48c2dd84ec254eb@localhost> Message-ID: <056.069c8698f81b12de12cb20d5e79fcaa7@localhost> #2528: nub not as reliable as nubBy ----------------------------+----------------------------------------------- Reporter: jdressel | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: libraries/base | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:05:45 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:04:09 2008 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> References: <042.b19622be9d3706ab4b282d1c64e9acb0@localhost> Message-ID: <051.467342dd993481d90416bd3c73c7109b@localhost> #2530: deriving Show adds extra parens for constructor with record syntax ----------------------+----------------------------------------------------- Reporter: spl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:06:05 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:04:26 2008 Subject: [GHC] #2531: Prune duplicates in ghci history In-Reply-To: <045.a0871c51adeff1456b5bd9c24f43a05b@localhost> References: <045.a0871c51adeff1456b5bd9c24f43a05b@localhost> Message-ID: <054.595e6680b15fbef461a30232d4c27447@localhost> #2531: Prune duplicates in ghci history -----------------------------+---------------------------------------------- Reporter: venkat | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:09:01 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:07:20 2008 Subject: [GHC] #2532: Add Typeable instance to Data.Unique In-Reply-To: <045.cab33c7b39a6b1cefa6bbdc4f3dc0833@localhost> References: <045.cab33c7b39a6b1cefa6bbdc4f3dc0833@localhost> Message-ID: <054.6e8bda734e28f5b30a370764aab5199e@localhost> #2532: Add Typeable instance to Data.Unique ----------------------------+----------------------------------------------- Reporter: japple | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:09:37 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:08:10 2008 Subject: [GHC] #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts In-Reply-To: <045.1b6e550f0033cafaf14d077da3af73bb@localhost> References: <045.1b6e550f0033cafaf14d077da3af73bb@localhost> Message-ID: <054.fb89f2cbedc4a4e77fcdceb9f1a29964@localhost> #2533: Generic functions that take integral arguments should work the same way as their prelude counterparts ----------------------------+----------------------------------------------- Reporter: japple | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:10:35 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:08:55 2008 Subject: [GHC] #2534: Odd probable cause given by type checker In-Reply-To: <047.ed1af1376e750ad1e5dab7d0ee130215@localhost> References: <047.ed1af1376e750ad1e5dab7d0ee130215@localhost> Message-ID: <056.e1735c187967c680b45254da296ed867@localhost> #2534: Odd probable cause given by type checker -------------------------------------+-------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the example -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:12:29 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:10:48 2008 Subject: [GHC] #2535: Bug fix for QuickCheck 1.1.0.0 In-Reply-To: <047.a94a8053354ba7fb4be42a9b053bccf3@localhost> References: <047.a94a8053354ba7fb4be42a9b053bccf3@localhost> Message-ID: <056.33a37f21f3f4c3e3950116c4e553b602@localhost> #2535: Bug fix for QuickCheck 1.1.0.0 -------------------------------+-------------------------------------------- Reporter: patperry | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:14:03 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:12:22 2008 Subject: [GHC] #2539: panic when using .o files from the wrong platform In-Reply-To: <042.341988b91b98ef1befd98d4359420bff@localhost> References: <042.341988b91b98ef1befd98d4359420bff@localhost> Message-ID: <051.5ee0ebb93f7192865b9bad110844bbaf@localhost> #2539: panic when using .o files from the wrong platform ----------------------+----------------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:19:26 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:17:46 2008 Subject: [GHC] #2549: Non null-terminated C strings sended to OpenGL functions. In-Reply-To: <048.590549b48ce208041e89fe161483ad2a@localhost> References: <048.590549b48ce208041e89fe161483ad2a@localhost> Message-ID: <057.e0f764fc61b6efe07e6a20455bcb897a@localhost> #2549: Non null-terminated C strings sended to OpenGL functions. ---------------------------+------------------------------------------------ Reporter: Vincent.B | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/HGL | Version: 6.8.3 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: HGL no longer comes with GHC. Please report this directly to the library maintainer. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:23:33 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:21:53 2008 Subject: [GHC] #2550: Add an option to read file names from a file instead of the command line In-Reply-To: <047.3665f1a48a327f8421f4cc9de980373f@localhost> References: <047.3665f1a48a327f8421f4cc9de980373f@localhost> Message-ID: <056.cefb42be07c1dd4ebc93dc179c380dfd@localhost> #2550: Add an option to read file names from a file instead of the command line -----------------------------+---------------------------------------------- Reporter: YitzGale | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:26:13 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:24:33 2008 Subject: [GHC] #2551: Allow multiple modules per source file In-Reply-To: <047.3a5018e62377d0e216dd18feced12298@localhost> References: <047.3a5018e62377d0e216dd18feced12298@localhost> Message-ID: <056.b30b51b06fa7cac05a3e183a238f2518@localhost> #2551: Allow multiple modules per source file -----------------------------+---------------------------------------------- Reporter: YitzGale | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => _|_ Comment: I don't think we're likely to implement this any time soon, I'm afraid, unless there is more demand for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:26:56 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:25:16 2008 Subject: [GHC] #2552: SCC annotation behavior differs between toplevel and non-toplevel In-Reply-To: <044.15a1341c91a98c8a8d7587f72c101e1e@localhost> References: <044.15a1341c91a98c8a8d7587f72c101e1e@localhost> Message-ID: <053.d7d62d67100baefd4d63faeae3c417cb@localhost> #2552: SCC annotation behavior differs between toplevel and non-toplevel ---------------------------+------------------------------------------------ Reporter: Rauli | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: scc profiling | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------------+------------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:33:17 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:31:36 2008 Subject: [GHC] #2553: panic: RegAllocLinear.getStackSlotFor: out of stack slots In-Reply-To: <056.cbc47ed313e48fa03058c7472b71f14a@localhost> References: <056.cbc47ed313e48fa03058c7472b71f14a@localhost> Message-ID: <065.8fb6323b5686f5cd7b403b1a906d6beb@localhost> #2553: panic: RegAllocLinear.getStackSlotFor: out of stack slots -------------------------------+-------------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report. Happily, this is a duplicate of #2424, and already fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:39:15 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:37:35 2008 Subject: [GHC] #2554: internal error: stg_ap_pp_ret (with terminfo) In-Reply-To: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> References: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> Message-ID: <053.18319012bdc59e01c10b30aa2688f1ea@localhost> #2554: internal error: stg_ap_pp_ret (with terminfo) ----------------------+----------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.1 Comment: Thanks for the testcase. However, I'm unable to reproduce the problem with 6.9.20080828. I've run Test 20 or 30 times, and I just get {{{ $ ./Test Calling function. Called function. Calling function. Called function. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:45:57 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:44:16 2008 Subject: [GHC] #2556: Deprecated perl stuff in ghc-split In-Reply-To: <044.ceb58b94b19e4b109063f24afc9124ec@localhost> References: <044.ceb58b94b19e4b109063f24afc9124ec@localhost> Message-ID: <053.8c14c3bc1c4829bb0c33c220f8170c5a@localhost> #2556: Deprecated perl stuff in ghc-split ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed * milestone: => 6.10.1 Comment: Thanks for the report; this has already been fixed in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:49:46 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:48:04 2008 Subject: [GHC] #2445: better error message needed for missing package files In-Reply-To: <045.9cb2bae0df0646f2155e8c136223a84e@localhost> References: <045.9cb2bae0df0646f2155e8c136223a84e@localhost> Message-ID: <054.1f2acdf4b7a737df72b1b83e2ef65692@localhost> #2445: better error message needed for missing package files ----------------------+----------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:54:30 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:52:49 2008 Subject: [GHC] #2459: can't link haskell without "main" function, or -no-hs-main broken on windows? In-Reply-To: <042.a892bb62d9bf138a3680ca1e496e0413@localhost> References: <042.a892bb62d9bf138a3680ca1e496e0413@localhost> Message-ID: <051.b0c3c75486143284c7b4e7f3cbceb127@localhost> #2459: can't link haskell without "main" function, or -no-hs-main broken on windows? ---------------------+------------------------------------------------------ Reporter: jvl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Driver | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:56:52 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:55:11 2008 Subject: [GHC] #2460: provide -mwindows option like gcc In-Reply-To: <042.8396d2df2e0ff931276aa5a0abcdaca6@localhost> References: <042.8396d2df2e0ff931276aa5a0abcdaca6@localhost> Message-ID: <051.96d2c772da6b6f34975ac5500f63bdd9@localhost> #2460: provide -mwindows option like gcc -----------------------------+---------------------------------------------- Reporter: jvl | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 09:57:39 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 09:55:58 2008 Subject: [GHC] #2555: Template Haskell does not respect -package and -hide constraints In-Reply-To: <044.7c1849c0092957cb6d9dc4fd3b20e42f@localhost> References: <044.7c1849c0092957cb6d9dc4fd3b20e42f@localhost> Message-ID: <053.f749c29ada42fcedceb82061ec5fa0d1@localhost> #2555: Template Haskell does not respect -package and -hide constraints ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 10:01:50 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 10:00:09 2008 Subject: [GHC] #2557: building HEAD fails when editline is installed as a user package In-Reply-To: <045.4540196d5276eabdacdaa367ea1601d5@localhost> References: <045.4540196d5276eabdacdaa367ea1601d5@localhost> Message-ID: <054.a6bb77f0d6569486bfe0bb4f58a5df3e@localhost> #2557: building HEAD fails when editline is installed as a user package ----------------------+----------------------------------------------------- Reporter: judahj | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 10:21:38 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 10:19:57 2008 Subject: [GHC] #2453: users_guide/syntax-extns.html # 8.3.3, control.monad doc, etc, have obsolete refs to www.cse.ogi.edu In-Reply-To: <044.c1e45508467fb83fb9ed0eb2a4a7e130@localhost> References: <044.c1e45508467fb83fb9ed0eb2a4a7e130@localhost> Message-ID: <053.5e0613c3b399530d84efdffc9fc327be@localhost> #2453: users_guide/syntax-extns.html # 8.3.3, control.monad doc, etc, have obsolete refs to www.cse.ogi.edu ---------------------------+------------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Documentation | Version: 6.8.3 Severity: trivial | Resolution: Keywords: OGI | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------+------------------------------------------------ Comment (by igloo): Also http://www.haskell.org/pipermail/libraries/2007-December/008735.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 12:11:53 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 12:10:14 2008 Subject: [GHC] #2554: internal error: stg_ap_pp_ret (with terminfo) In-Reply-To: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> References: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> Message-ID: <053.1a2913e9d1261b83e854f9585d1f258c@localhost> #2554: internal error: stg_ap_pp_ret (with terminfo) ----------------------+----------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by judah): It might be easier to reproduce the error with Test2.hs (attached) instead of Test.hs. Pressing ctrl-c when it prompts the user to enter a character causes a crash on my machine: {{{ $ ./Test2 Calling function. Called function. Enter a character, or press ctrl-c. ^CResult:Nothing Calling function. Bus error }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 12:48:03 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 12:46:23 2008 Subject: [GHC] #2554: internal error: stg_ap_pp_ret (with terminfo) In-Reply-To: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> References: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> Message-ID: <053.c745eee2290673e9258bcf04118cf138@localhost> #2554: internal error: stg_ap_pp_ret (with terminfo) ----------------------+----------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by igloo): After speaking to judah online, I tried with a `quickest` build, and my fourth attempt (with the original `Test.hs`) gave me: {{{ $ ./Test Calling function. Called function. Calling function. Test: internal error: stg_ap_pp_ret (GHC version 6.9.20080830 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 13:00:30 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 12:58:50 2008 Subject: [GHC] #2554: internal error: stg_ap_pp_ret (with terminfo) In-Reply-To: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> References: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> Message-ID: <053.c9e1753d9cfc6d28f5c92219ea932ce4@localhost> #2554: internal error: stg_ap_pp_ret (with terminfo) ----------------------+----------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by igloo): And Test2 consistently gives me: {{{ $ ./Test2 Calling function. Called function. Enter a character, or press ctrl-c. ^CResult:Nothing Calling function. Test2: internal error: stg_ap_pp_ret (GHC version 6.9.20080830 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 17:28:37 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 17:26:56 2008 Subject: [GHC] #2554: internal error: stg_ap_pp_ret (with terminfo) In-Reply-To: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> References: <044.33425e4fe753fc449a0d0bee6dcb7ad9@localhost> Message-ID: <053.e1b4a355481f6545f50cf77e0e4b22bc@localhost> #2554: internal error: stg_ap_pp_ret (with terminfo) ----------------------+----------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by judah): FWIW, building HEAD with `BuildFlavor=perf` made the error unreproducible for me too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 17:43:12 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 17:41:30 2008 Subject: [GHC] #2557: building HEAD fails when editline is installed as a user package In-Reply-To: <045.4540196d5276eabdacdaa367ea1601d5@localhost> References: <045.4540196d5276eabdacdaa367ea1601d5@localhost> Message-ID: <054.dc8918cf68201d5498ebd315cb8533a4@localhost> #2557: building HEAD fails when editline is installed as a user package ----------------------+----------------------------------------------------- Reporter: judahj | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: Compiler | Version: 6.9 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 31 19:26:44 2008 From: trac at galois.com (GHC) Date: Sun Aug 31 19:25:05 2008 Subject: [GHC] #1895: Allow aliases in GHCi module imports In-Reply-To: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> References: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> Message-ID: <053.b77d922f1d0f5be4db47657924b1681b@localhost> #1895: Allow aliases in GHCi module imports -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by ertai): * cc: nicolas.pouillard@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler