From trac at galois.com Wed Jul 1 00:53:08 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 00:35:41 2009 Subject: [GHC] #3339: Data.Monoid: Add (+>) as a synonym for mappend In-Reply-To: <042.626638ce45ff16ad4ce623d16cab0138@localhost> References: <042.626638ce45ff16ad4ce623d16cab0138@localhost> Message-ID: <051.25bf23f7f53bf115b785e340b549917e@localhost> #3339: Data.Monoid: Add (+>) as a synonym for mappend ------------------------------+--------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by ajd): What is wrong with generalizing the type of (++)? If it would not break too much code (on first glance, I'm not sure how it would), I think that that would be the best solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 04:47:19 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 04:29:58 2009 Subject: [GHC] #3339: Data.Monoid: Add (+>) as a synonym for mappend In-Reply-To: <042.626638ce45ff16ad4ce623d16cab0138@localhost> References: <042.626638ce45ff16ad4ce623d16cab0138@localhost> Message-ID: <051.6c0e60433d5185a393e2f054ac2831b4@localhost> #3339: Data.Monoid: Add (+>) as a synonym for mappend ------------------------------+--------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by jochemb): Generalizing (++) may be confusing for newbies, but I think this is the best way to go. (+>) and (<+) are totally asymmetric, like (>>=) and (*>), whereas the type of (+>) is Monoid a => a -> a -> a (++) is (pretty obviously) not commutative, like (>>) and (&&), where there can be no confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 04:58:46 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 04:41:24 2009 Subject: [GHC] #3339: Data.Monoid: Add (+>) as a synonym for mappend In-Reply-To: <042.626638ce45ff16ad4ce623d16cab0138@localhost> References: <042.626638ce45ff16ad4ce623d16cab0138@localhost> Message-ID: <051.4ba8f6c673e101338902da7c2b5af635@localhost> #3339: Data.Monoid: Add (+>) as a synonym for mappend ------------------------------+--------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by david48): In my opinion as a newbie, there are far more confusing things for newbies than (++) being the mappend of monoids. And anyways, monoids is far from being the hardest thing to understand in haskell, once you read a few well written blog posts. You can still learn to use ++ as the concatenation operator for strings, and discover later that there is more to it than it looks. I support generalizing the type of (++) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 06:37:14 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 06:19:49 2009 Subject: [GHC] #454: hPutBuf doesn't respect LineBuffering In-Reply-To: <047.0ae23113bdabf18ce84f68bc410637a0@localhost> References: <047.0ae23113bdabf18ce84f68bc410637a0@localhost> Message-ID: <056.c314332a3ca79b23d11825f5621404b6@localhost> #454: hPutBuf doesn't respect LineBuffering ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.12.1 Component: libraries/base | Version: 6.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: None => fixed * milestone: _|_ => 6.12.1 Comment: The new IO library now treats `LineBuffering` like `NoBuffering` in `hPutBuf`. Arguably `LineBuffering` makes little sense for a byte- oriented API, since the newline character might be encoded arbitrarily. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 06:55:50 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 06:38:29 2009 Subject: [GHC] #3339: Data.Monoid: Add (+>) as a synonym for mappend In-Reply-To: <042.626638ce45ff16ad4ce623d16cab0138@localhost> References: <042.626638ce45ff16ad4ce623d16cab0138@localhost> Message-ID: <051.7dd8a5f63ef9997c98948068da72be22@localhost> #3339: Data.Monoid: Add (+>) as a synonym for mappend ------------------------------+--------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by JulesBean): There is no universal convention that symmetric-looking operators should be commutative. However, it is certainly a handy visual guide. To address specific points: (&&) looks commutative to me, and it *is* commutative, in the _|_ free fragment of haskell. That's the fragment I most commonly reason about. You don't get many algebraic laws without that. Similarly (||). (>>) looks uncommutative - it's not about repeated symbols, it's about the way the > symbols obviously 'point' in one direction. And, (>>) *is* noncommutative, of course. Concrete advantages for (+>): * It has a symbol which visually indicates direction, and mappend is often a directional operation in some sense; * It can be 'naturally' flipped to yield <+; it's useful to have a short name for flip mappend. The latter is the key point. The reason to use +> is so we can use <+. I rejected using (++) not just because it looks too symmetric (that's not a big problem, it doesn't confuse people too much) but simply because the backwards-compatibility damage of changing the type of a very very widely used operator is very significant. By contrast, (+>) is not used in any widely used libraries, certainly not in base, and the backwards-compatibility damage of adding a new symbol to Data.Monoid is relatively low. No worse than adding any other new function to an API. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 08:01:19 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 07:43:59 2009 Subject: [GHC] #3339: Data.Monoid: Add (+>) as a synonym for mappend In-Reply-To: <042.626638ce45ff16ad4ce623d16cab0138@localhost> References: <042.626638ce45ff16ad4ce623d16cab0138@localhost> Message-ID: <051.b3896e8fe2447a175b499c1ad4800b28@localhost> #3339: Data.Monoid: Add (+>) as a synonym for mappend ------------------------------+--------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by duncan): Is there any evidence for why a flipped mappend is useful? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 08:09:30 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 07:52:12 2009 Subject: [GHC] #3339: Data.Monoid: Add (+>) as a synonym for mappend In-Reply-To: <042.626638ce45ff16ad4ce623d16cab0138@localhost> References: <042.626638ce45ff16ad4ce623d16cab0138@localhost> Message-ID: <051.6994d2f65f98996ec715b43a4ad656f3@localhost> #3339: Data.Monoid: Add (+>) as a synonym for mappend ------------------------------+--------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by JulesBean): I think it's useful for Endo a, where you sometimes want to postcompose and sometimes precompose functions. I think it's useful for any monoid which represents something like the composition of a graphical image, where precomposition is putting something 'underneath' and postcomposition is putting something 'on top'. I suspect you quite often get Monoids along those general lines in DSLs; I've certainly seen a view. Of course the case for a special flipped operator can never be that strong; you can always just write an expression the other way around. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 08:16:07 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 07:58:40 2009 Subject: [GHC] #3340: Better defaults for parallel GC settings Message-ID: <047.fcbb118c30a8f079699c4527915832cf@localhost> #3340: Better defaults for parallel GC settings -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.2 Severity: normal | Keywords: Difficulty: Moderate (1 day) | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- The parallel GC settings should default to something sensible in 6.12.1. Check that we don't introduce any performance regressions with the default settings compared to 6.10.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 08:47:20 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 08:30:00 2009 Subject: [GHC] #3339: Data.Monoid: Add (+>) as a synonym for mappend In-Reply-To: <042.626638ce45ff16ad4ce623d16cab0138@localhost> References: <042.626638ce45ff16ad4ce623d16cab0138@localhost> Message-ID: <051.4ee0e6cd838727c3f3b842e789e66917@localhost> #3339: Data.Monoid: Add (+>) as a synonym for mappend ------------------------------+--------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by bkomuves): +1 vote for generalizing (++). I think flipped mappend is so rare that writing "flip (++)" is actually easier to read. And you can still define your own <+ and +> if you use them a lot. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 11:24:23 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 11:07:03 2009 Subject: [GHC] #3339: Data.Monoid: Add (+>) as a synonym for mappend In-Reply-To: <042.626638ce45ff16ad4ce623d16cab0138@localhost> References: <042.626638ce45ff16ad4ce623d16cab0138@localhost> Message-ID: <051.f3270d0983a248f714d6df2bfce47b70@localhost> #3339: Data.Monoid: Add (+>) as a synonym for mappend ------------------------------+--------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by tibbe): I agree with generalizing (++). Are there any programs that will break because of that generalization? My argument for reusing (++) is that I'd like to keep the number of different operators I have to memorize (in particular when reading other people's code) to a minimum. I only think very fundamental type classes deserve operators (e.g. Monad, Functor, Monoid, Num). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 14:15:34 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 13:58:07 2009 Subject: [GHC] #3331: control-monad-queue performance regression In-Reply-To: <046.199bea4da34b828d923df9304139778a@localhost> References: <046.199bea4da34b828d923df9304139778a@localhost> Message-ID: <055.bc0abb5b2157290607227809e7c9a768@localhost> #3331: control-monad-queue performance regression -----------------------------------------+---------------------------------- Reporter: lpsmith | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: Here are some numbers when compiling with `-O` and `-O2`, and with 6.8.2 and 6.10.3. In particular, note the bytes allocated in the heap (the first number after `<> ./Time allison 34 20 +RTS -tstderr 13.86s user 0.07s system 99% cpu 13.939 total }}} {{{ $ ghc-6.8.2 --make Time -O -Wall $ time ./Time allison 34 20 +RTS -tstderr ./Time allison 34 20 +RTS -tstderr allison Timings: [88,82,82,82,82,82,82,82,83,82,82,81,83,82,83,82,82,82,82,83] Sum: 1649 Minimum: 81 Maximum: 88 Mean: 82.45 Stddev: 1.3592277219068187 <> ./Time allison 34 20 +RTS -tstderr 16.48s user 0.09s system 100% cpu 16.568 total }}} {{{ $ ghc-6.10.3 --make Time -O2 -Wall $ time ./Time allison 34 20 +RTS -t ./Time allison 34 20 +RTS -t allison Timings: [92,86,86,86,86,86,87,86,86,86,85,85,85,85,85,85,85,86,85,85] Sum: 1718 Minimum: 85 Maximum: 92 Mean: 85.9 Stddev: 1.5132745950421556 <> ./Time allison 34 20 +RTS -t 17.20s user 0.07s system 100% cpu 17.261 total }}} {{{ $ ghc-6.10.3 --make Time -O -Wall $ time ./Time allison 34 20 +RTS -t ./Time allison 34 20 +RTS -t allison Timings: [102,96,95,96,94,95,96,95,98,96,96,96,95,94,95,96,95,96,94,96] Sum: 1916 Minimum: 94 Maximum: 102 Mean: 95.8 Stddev: 1.6911534525287764 <> ./Time allison 34 20 +RTS -t 19.13s user 0.12s system 100% cpu 19.252 total }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 14:17:03 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 13:59:35 2009 Subject: [GHC] #3331: control-monad-queue performance regression In-Reply-To: <046.199bea4da34b828d923df9304139778a@localhost> References: <046.199bea4da34b828d923df9304139778a@localhost> Message-ID: <055.4dfab05373fa7c2eb9c22bf058847ad6@localhost> #3331: control-monad-queue performance regression -----------------------------------------+---------------------------------- Reporter: lpsmith | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by igloo): The above numbers are for the attached Time.hs and A.hs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 14:39:44 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 14:22:15 2009 Subject: [GHC] #3341: encoding errors could be handled better Message-ID: <045.aacea9ec15561126d540765d32ffcd87@localhost> #3341: encoding errors could be handled better --------------------+------------------------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.11 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- With the new Unicode I/O library, using the following program (`badchar.hs`): {{{ import System.IO main = do hSetBuffering stdin NoBuffering getChar >> print }}} If the terminal's LANG is utf-8 but a latin-1 non-ASCII character is typed, then the terminal hangs and doesn't throw an error until three more bytes are entered. Since `NoBuffering` is set, I'd expect the program to immediately perform error handling rather than waiting for more input. Furthermore, if the end of input is reached then the invalid byte is accepted without error. For example, in a utf-8 terminal: {{{ dhcp-19-155:tmp judah$ ghc -e "putStrLn \"\\249\"" | ./badchar '\249' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 16:14:00 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 15:56:37 2009 Subject: [GHC] #3292: Add an 'ignore' function to Control.Monad In-Reply-To: <044.27c764de47060e5a6666b1886ee80198@localhost> References: <044.27c764de47060e5a6666b1886ee80198@localhost> Message-ID: <053.2634674dd3d146fd5857f8a823a51897@localhost> #3292: Add an 'ignore' function to Control.Monad ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.2 Severity: minor | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by dons): This is a generalization of the well-known FFI 'void' function: {{{ module Foreign.Marshal.Error -- |Discard the return value of an 'IO' action -- void :: IO a -> IO () void act = act >> return () }}} in base for the last decade. Generalising 'void' (with that name), seems more intuitive to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 16:14:45 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 15:57:41 2009 Subject: [GHC] #3301: Update Haskeline In-Reply-To: <042.39eb2fb65f452fed35078da0d81f6675@localhost> References: <042.39eb2fb65f452fed35078da0d81f6675@localhost> Message-ID: <051.a18d79290677bbcc4f342c0c2154a483@localhost> #3301: Update Haskeline ------------------------------+--------------------------------------------- Reporter: cjs | Owner: Type: merge | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: major | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by phunge0): * cc: phunge0 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 17:50:04 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 17:32:39 2009 Subject: [GHC] #3263: Warnings for monadic values not used In-Reply-To: <051.2ba77802c306560898b377ae21be4ade@localhost> References: <051.2ba77802c306560898b377ae21be4ade@localhost> Message-ID: <060.edc1bc9537d11678c8b5a2b3b3195120@localhost> #3263: Warnings for monadic values not used ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by batterseapower): * cc: batterseapower@hotmail.com (added) Comment: I've attached above an implementation of these two flags. The patch contains: * Code adding -fwarn-wrong-do-bind and -fwarn-unused-do-bind warning generation to the compiler * Documentation for the two new flags * Changes to all the core libraries and GHC itself to prevent the build breaking with -Werror * Tests for the new warnings I found one particularly suspicious instance of code that the warnings picked up in GHC: {{{ ; _ <- set_head_fact h a fuel ; return fuel } }}} (compiler/cmm/ZipDataflow.hs:784:22:). set_head_fact returns a Fuel, but it is ignored by the single use site. Can this really be what was intended? When modifying all the libraries, I found a number of functions that often required me to write tedious {{{_ <-}}} bindings to suppress the warnings. Maybe we should consider providing _ variants of the following: {{{ forkIO -- Returns a ThreadId, which is hardly ever used char -- Returns the character input verbatim, noone cares about it string -- Returns the string input verbatim evaluate -- Returns the thing on the input. Perhaps we should provide force :: a -> IO () as an alternative try -- I saw a use of try discarding the result (i.e. ignoring all exceptions) in both Cabal and ghc (InteractiveUI.hs) throwErrnoIfNull -- One occurence }}} Internal stuff: {{{ writeBuffer -- Seen in the encoding code. Return value rarely used. installHandler -- Used a lot in GHC code, return value rarely (never?) used }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 17:56:07 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 17:38:41 2009 Subject: [GHC] #3263: Warnings for monadic values not used In-Reply-To: <051.2ba77802c306560898b377ae21be4ade@localhost> References: <051.2ba77802c306560898b377ae21be4ade@localhost> Message-ID: <060.57936e241e7cf6b3b3d22264999dd189@localhost> #3263: Warnings for monadic values not used ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by batterseapower): A little more commentary: * My patch does not warn on uses of {{{>>}}}, only in do-notation, where the situation is more clear cut * My general impression of the changes I made to GHC as a result of having this warning are fairly positive: * I managed to find several instances of foldM, mapM and zipWithM being used where the _ variants were more appropriate * A few functions had their results discarded at all use sites and could have their return values removed outright, which is nice * A fair number of the new _ <- bindings occured in places where people had written a comment saying something like 'throwing this away' or 'HACK', which is a nice confirmation that the warning is providing valuable information -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 19:15:13 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 18:57:45 2009 Subject: [GHC] #3342: splitTyConApp panic when using view patterns Message-ID: <044.11e2951faa3ccd3c80f19d138272cf2e@localhost> #3342: splitTyConApp panic when using view patterns -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Here is a sample program that makes ghci panic with the following message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-unknown-linux): splitTyConApp t_ag8{tv} [tau] }}} The code uses view patterns. {{{ module Bug where data F = FT String [F] data G = GX F F | GY spec :: F -> G spec (FT "X" [t1, t2]) = GX t1 t2 spec _ = GY walk (spec -> GX _ t2) = walk t2 walk t@(FT _ _) = t }}} You can reach me at cklin@cs.pdx.edu -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 1 19:28:49 2009 From: trac at galois.com (GHC) Date: Wed Jul 1 19:11:34 2009 Subject: [GHC] #3342: splitTyConApp panic when using view patterns In-Reply-To: <044.11e2951faa3ccd3c80f19d138272cf2e@localhost> References: <044.11e2951faa3ccd3c80f19d138272cf2e@localhost> Message-ID: <053.641c5713b103efb8b718a9d6bedffd54@localhost> #3342: splitTyConApp panic when using view patterns ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by guest): * cc: cklin@cs.pdx.edu (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 2 01:57:29 2009 From: trac at galois.com (GHC) Date: Thu Jul 2 01:40:04 2009 Subject: [GHC] #3343: make 2 doesn't seem to work as documented Message-ID: <043.8b27f399b7b0d79cfe1e1d26e534b327@localhost> #3343: make 2 doesn't seem to work as documented -----------------------------+---------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- [wiki:Building/Using The guide to the new build system] claims, under the heading "Rebuilding the GHC binary after making changes", that `make 2` "is like make stage=2, except that it omits the dependency-building phase." However, it seems to include the dependency-building and also fails with an error: {{{ echo "utils/haddock_dist_depfile_EXISTS = YES" >> utils/haddock/dist/build/.depend for dir in utils/haddock/dist/build/./ utils/haddock/dist/build/Haddock/ utils/haddock/dist/build/Haddock/Backends/ utils/haddock/dist/build/Haddock/GHC/ utils/haddock/dist/build/Haddock/Interface/ utils/haddock/dist/build/Haddock/Utils/; do if test ! -d $dir; then mkdir -p $dir; fi done make[1]: *** No rule to make target `2'. Stop. make: *** [2] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 2 04:03:06 2009 From: trac at galois.com (GHC) Date: Thu Jul 2 03:45:37 2009 Subject: [GHC] #3341: encoding errors could be handled better In-Reply-To: <045.aacea9ec15561126d540765d32ffcd87@localhost> References: <045.aacea9ec15561126d540765d32ffcd87@localhost> Message-ID: <054.32b4be440b52a79b62a305e67899146d@localhost> #3341: encoding errors could be handled better -------------------------------+-------------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 Comment: What do you mean by a "Latin-1 non-ASCII character"? e.g. a byte between 0x80 and 0xBF should elicit an error immediately, whereas a byte between 0xC0 and 0xDF will require one extra byte to determine whether there is a decoding error or not. I do think there's a bug here though: if the bytes 0xE0 0x00 are received, then GHC will wait for one more byte before raising an error, even though the sequence is already erroneous. In this example: {{{ ghc -e "putStrLn \"\\249\"" | ./badchar }}} bear in mind that ghc is using the locale encoding to output '\249', and then decoding it again on input. I think you're seeing the correct result here. If you feed a real incorrect sequence at the end of the input, GHC behaves correctly: {{{ $ cat 3341.hs import System.IO import GHC.IO.Handle import GHC.IO.Encoding main = do hSetBuffering stdin NoBuffering -- hSetEncoding stdin utf8 getChar >>= print $ hexdump -C char2 00000000 c0 03 |..| 00000002 $ echo $LANG en_US.utf8 $ ./3341 : hGetChar: invalid argument (Invalid or incomplete multibyte or wide character) [2] 27598 exit 1 ./3341 < char2 }}} and you get the same result using the built-in UTF-8 decoder (uncomment the hSetEncoding line). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 2 04:27:56 2009 From: trac at galois.com (GHC) Date: Thu Jul 2 04:10:29 2009 Subject: [GHC] #3341: encoding errors could be handled better In-Reply-To: <045.aacea9ec15561126d540765d32ffcd87@localhost> References: <045.aacea9ec15561126d540765d32ffcd87@localhost> Message-ID: <054.9439395abccef75f09b08b5cb3190e2a@localhost> #3341: encoding errors could be handled better -------------------------------+-------------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by simonmar): An update: the built-in UTF-8 decoder has a bug, in that when the byte 0x80 is received it will wait for 3 more bytes before emitting an error (the iconv UTF-8 decoder doesn't have this bug). I've fixed that. I managed to crash xterm by pasting the bytes 0xE0 0x00 into it :-) And it wasn't even in UTF-8 mode. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 2 04:29:14 2009 From: trac at galois.com (GHC) Date: Thu Jul 2 04:12:08 2009 Subject: [GHC] #3343: make 2 doesn't seem to work as documented In-Reply-To: <043.8b27f399b7b0d79cfe1e1d26e534b327@localhost> References: <043.8b27f399b7b0d79cfe1e1d26e534b327@localhost> Message-ID: <052.b669e38f90afb51a6fb58bd83b751663@localhost> #3343: make 2 doesn't seem to work as documented ---------------------------------+------------------------------------------ Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: did you perhaps omit the `cd ghc` step? `make 2` only works in the `compiler` and `ghc` subdirectories. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 2 05:53:13 2009 From: trac at galois.com (GHC) Date: Thu Jul 2 05:35:47 2009 Subject: [GHC] #3197: disambiguating type family instances with qualified names not possible In-Reply-To: <044.4e0198f3effcd8f1d87eec80ef8d0a9e@localhost> References: <044.4e0198f3effcd8f1d87eec80ef8d0a9e@localhost> Message-ID: <053.1ad2f712608e9c0b854c1285d5fdc307@localhost> #3197: disambiguating type family instances with qualified names not possible ----------------------------------------+----------------------------------- Reporter: claus | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: I fixed the bug, and I also permitted type families with no indices. I already wondered whether we should have them, but didn't see much use. You are saying there are useful and I don't think they create any problems (in the implementation, it was just a matter of removing the check). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 2 08:46:22 2009 From: trac at galois.com (GHC) Date: Thu Jul 2 08:29:07 2009 Subject: [GHC] #3342: splitTyConApp panic when using view patterns In-Reply-To: <044.11e2951faa3ccd3c80f19d138272cf2e@localhost> References: <044.11e2951faa3ccd3c80f19d138272cf2e@localhost> Message-ID: <053.45b56a5b3f5cec4adc1c3814f4e55b31@localhost> #3342: splitTyConApp panic when using view patterns ------------------------------------------------+--------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: typecheck/should_compiler/T3342 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Changes (by simonpj): * testcase: => typecheck/should_compiler/T3342 * difficulty: => Unknown * type: bug => merge * owner: => igloo Comment: Oops. Thank you. A bad oversight, fortunately easily fixed {{{ Thu Jul 2 05:43:31 PDT 2009 simonpj@microsoft.com * Fix Trac #3342: missed zonking in TcHsSyn The type in a ViewPat wasn't being zonked. Easily fixed. M ./compiler/typecheck/TcHsSyn.lhs -1 +2 }}} Ian: this one should go into 6.10.4. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 2 09:10:57 2009 From: trac at galois.com (GHC) Date: Thu Jul 2 08:53:28 2009 Subject: [GHC] #3263: Warnings for monadic values not used In-Reply-To: <051.2ba77802c306560898b377ae21be4ade@localhost> References: <051.2ba77802c306560898b377ae21be4ade@localhost> Message-ID: <060.27481f67fdf0c8866ff2ac43925b5594@localhost> #3263: Warnings for monadic values not used ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Thank you Max. I've had a look. Generally fine. Most of the lines of code changed are to make the compiler and libraries warning-free. Only a few (in `DsExpr` actually implement the feature). IAN: could you commit the patches please? Once that's done, I have two thoughts * I found `-fwarn-wrong-do-bind` quite confusing. I believe that (a) it is on by default, but (b) any program that warns because of `-fwarn-wrong- do-bind` will '''also''' warn because of `-fwarn-unused-do-bind`, if the latter flag is on. So we really only want one or the other, never both. Is that right? * The formatting of the error messages is very very wide, much more so than any other GHC error. Better reformat please. * I found the error message for `-fwarn-wrong-do-bind` pretty confusing. Since they are so closely related can we give them closely related messages, like: {{{ A do-notation statement discarded a result of type Suppress this warning by saying "_ <- blah", or flag }}} where and are appropriately substituted. That seems much more direct to me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 2 09:13:02 2009 From: trac at galois.com (GHC) Date: Thu Jul 2 08:55:38 2009 Subject: [GHC] #3330: Type checker hangs In-Reply-To: <060.111b0979bdfa1b272261462ee3c542d4@localhost> References: <060.111b0979bdfa1b272261462ee3c542d4@localhost> Message-ID: <069.346726630b6eb408908aabe49bdacae2@localhost> #3330: Type checker hangs ----------------------------------------+----------------------------------- Reporter: MartijnVanSteenbergen | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * owner: => chak * difficulty: => Unknown Comment: That's much easier, thank you v much. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 2 11:12:07 2009 From: trac at galois.com (GHC) Date: Thu Jul 2 10:54:37 2009 Subject: [GHC] #3263: Warnings for monadic values not used In-Reply-To: <051.2ba77802c306560898b377ae21be4ade@localhost> References: <051.2ba77802c306560898b377ae21be4ade@localhost> Message-ID: <060.5d23f31a8afd17ca4585f8f6d941a021@localhost> #3263: Warnings for monadic values not used ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by batterseapower): Thanks for the feedback Simon. I'm about to attach the additional patches that address all of your (spot-on) comments above. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 2 11:30:35 2009 From: trac at galois.com (GHC) Date: Thu Jul 2 11:13:05 2009 Subject: [GHC] #1792: -ddump-minimal-imports breaks qualified imports (import...as) In-Reply-To: <044.ae2e6ac08c5448ff46a1de0b12b1fa4a@localhost> References: <044.ae2e6ac08c5448ff46a1de0b12b1fa4a@localhost> Message-ID: <053.64a3e1a26a0b990b9ab758f7470848b0@localhost> #1792: -ddump-minimal-imports breaks qualified imports (import...as) ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Compiler | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by fasta): * cc: fasta (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 2 17:26:48 2009 From: trac at galois.com (GHC) Date: Thu Jul 2 17:09:18 2009 Subject: [GHC] #3341: encoding errors could be handled better In-Reply-To: <045.aacea9ec15561126d540765d32ffcd87@localhost> References: <045.aacea9ec15561126d540765d32ffcd87@localhost> Message-ID: <054.9bf2070d4d53d4933a53d461058b094a@localhost> #3341: encoding errors could be handled better -------------------------------+-------------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by judahj): Replying to [comment:1 simonmar]: > What do you mean by a "Latin-1 non-ASCII character"? e.g. a byte between 0x80 and 0xBF should elicit an error immediately, whereas a byte between 0xC0 and 0xDF will require one extra byte to determine whether there is a decoding error or not. I do think there's a bug here though: if the bytes 0xE0 0x00 are received, then GHC will wait for one more byte before raising an error, even though the sequence is already erroneous. > OK, that's a better explanation of what I was seeing. As a further example, if I enter into a utf-8 terminal the invalid byte sequence [0xf7, 0x97] (which corresponds to a latin-1 '?' followed by an 'a'), then GHC incorrectly waits for two more bytes before raising an error. However, from a UI perspective it seems to me that when `NoBuffering` is set we should not be pausing to wait for more input. Instead, when a partial byte sequence is read but `hReady` is false we should raise an error. (This is the current behavior of Haskeline.) Thus, when a user has the wrong LANG set and types a character they will immediately get feedback that something's off. > In this example: > > {{{ > ghc -e "putStrLn \"\\249\"" | ./badchar > }}} > > bear in mind that ghc is using the locale encoding to output '\249', and then decoding it again on input. I think you're seeing the correct result here. Yes, you're correct, sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 2 18:56:35 2009 From: trac at galois.com (GHC) Date: Thu Jul 2 18:39:06 2009 Subject: [GHC] #3344: request earlier and more perspicuous detection of tab characters in compiler/ghc.cabal.in Message-ID: <041.a1b1d435c26ca8460ae95266297368fa@localhost> #3344: request earlier and more perspicuous detection of tab characters in compiler/ghc.cabal.in -----------------------------+---------------------------------------------- Reporter: nr | Owner: Type: feature request | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- It turns out that if there is a tab character in {{{compiler/ghc.cabal.in}}} then the build fails in a way that I at least found hard to diagnose. Since the configure script builds {{{compiler/ghc.cabal}}} from {{{compiler/ghc.cabal.in}}}, life would be a lot simpler if the build fell over at that point with an error saying that tab characters are forbidden in that file. Since I believe the tab character is a tool of Satan, I would not dream of suggesting that the configure script run expand(1) over the offending file. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 2 22:07:05 2009 From: trac at galois.com (GHC) Date: Thu Jul 2 21:49:35 2009 Subject: [GHC] #3263: Warnings for monadic values not used In-Reply-To: <051.2ba77802c306560898b377ae21be4ade@localhost> References: <051.2ba77802c306560898b377ae21be4ade@localhost> Message-ID: <060.9423ad005872983132bcea07cb3ca55e@localhost> #3263: Warnings for monadic values not used ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by isaacdupree): Stylistically: Do we want to be suggesting `_ <- ...`? What about the (if-we-approve-it) `Control.Monad.ignore ...`? Maybe not a big deal (I don't even know which style we'd prefer), but when there are suggestions that the community disapproves of (e.g., the `-XSomeExtension` ones come to mind that didn't mention LANGUAGE) it's generally a bit unfortunate :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 3 05:51:34 2009 From: trac at galois.com (GHC) Date: Fri Jul 3 05:34:27 2009 Subject: [GHC] #3301: Update Haskeline In-Reply-To: <042.39eb2fb65f452fed35078da0d81f6675@localhost> References: <042.39eb2fb65f452fed35078da0d81f6675@localhost> Message-ID: <051.c813df5adb7c63980262b357ad72c210@localhost> #3301: Update Haskeline ---------------------------------+------------------------------------------ Reporter: cjs | Owner: Type: merge | Status: new Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.10.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 3 05:59:28 2009 From: trac at galois.com (GHC) Date: Fri Jul 3 05:41:57 2009 Subject: [GHC] #3341: encoding errors could be handled better In-Reply-To: <045.aacea9ec15561126d540765d32ffcd87@localhost> References: <045.aacea9ec15561126d540765d32ffcd87@localhost> Message-ID: <054.04c5aec6f3f2f6fd953f3b6fe5673a0b@localhost> #3341: encoding errors could be handled better -------------------------------+-------------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by simonmar): Replying to [comment:3 judahj]: > However, from a UI perspective it seems to me that when `NoBuffering` is set we should not be pausing to wait for more input. Instead, when a partial byte sequence is read but `hReady` is false we should raise an error. (This is the current behavior of Haskeline.) Thus, when a user has the wrong LANG set and types a character they will immediately get feedback that something's off. That's an interesting idea. Is there a precedent for it? Are you sure that it isn't possible to get buffering issues, for instance if you're typing over an SSH connection, might a byte sequence happen to be broken into separate network packets? FYI, the buffering mode make no difference for input handles in GHC. We always use a buffer, but it is invisible to the client. This is because we always allow the client to read whatever data is available; the input functions never block if there are any characters to return, except in the case of `hGetLine` which waits for a newline. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 3 07:55:44 2009 From: trac at galois.com (GHC) Date: Fri Jul 3 07:38:13 2009 Subject: [GHC] #2283: WIndows: loading objects that refer to DLL symbols In-Reply-To: <047.9dd077e0a526e115792cbcdfa56aeafb@localhost> References: <047.9dd077e0a526e115792cbcdfa56aeafb@localhost> Message-ID: <056.62988383ceb1c489d2f36d88b6c72d7d@localhost> #2283: WIndows: loading objects that refer to DLL symbols -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by batterseapower): Surely ghci can't be expected to handle this? On Windows, the user must also link against the DLL import lib (test3b.dll.a) if they want test_proxy_5a to work properly, whether they are building an EXE or running GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 3 08:01:50 2009 From: trac at galois.com (GHC) Date: Fri Jul 3 07:44:17 2009 Subject: [GHC] #3345: Support reading .a files in GHCi to reclaim some disk space Message-ID: <053.59839787a1c48a2f42a78e2afa335a69@localhost> #3345: Support reading .a files in GHCi to reclaim some disk space -----------------------------+---------------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Currently, Cabal builds two code files for every libary it installs: {{{ mbolingbroke@mb566 ~/.cabal/lib/vector-space-0.5.6/ghc-6.10.1 $ ls . .. Data HSvector-space-0.5.6.o libHSvector-space-0.5.6.a }}} The .a is a straight concatenation of the .o files that got built. The .o is the result of lding together all the .o files (and so has inter-object references already resolved) but is actually only used by GHCi. If GHCi could support loading .a files then Cabal wouldn't have to build this extra .o file and we could cut the size of installed libraries almost in half. (Or perhaps GHC could link against the .o rather than the .a, and then Cabal could stop building the .a, instead?) {{{ [12:32] BSP_: does cabal build both .o and .a's for a library purely because ghci isn't capable of reading the .a format and loading each .o individually? [12:33] BSP_: it seems a bit wasteful to have two copies of the code installed for each library... [12:35] dcoutts: BSP_: that's correct [12:35] dcoutts: in theory it's not that hard [12:35] dcoutts: there's no real need for ghci to read the .a index, just link in everything [12:36] arjanb left the chat room. ("bbl") [12:36] dcoutts: the .a format is trivial [12:36] ? dcoutts has a parser [12:36] dcoutts: and generator for that matter }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 3 08:36:33 2009 From: trac at galois.com (GHC) Date: Fri Jul 3 08:19:03 2009 Subject: [GHC] #3346: Strange and incorrect type error when using rewrite rules with type families Message-ID: <046.8516030065369a83577dc50b430a1824@localhost> #3346: Strange and incorrect type error when using rewrite rules with type families -----------------------------+---------------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The following code {{{ {-# OPTIONS_GHC -fglasgow-exts -O1 #-} module Main where {-# RULES "rule1" forall x. to (from x) = x #-} {-# RULES "rule2" forall x. from (to x) = x #-} class EP a where type Result a from :: a -> Result a to :: Result a -> a }}} gives the compilation error with GHC 6.11.20090703: {{{ Couldn't match expected type `Result a' against inferred type `Result a' NB: `Result' is a type function, and may not be injective In the first argument of `to', namely `(from x)' In the expression: to (from x) When checking the transformation rule "rule1" }}} I don't understand this error. rule2 seems unproblematic, though. The similar code with functional dependencies {{{ {-# RULES "rule3" forall x. to' (from' x) = x #-} {-# RULES "rule4" forall x. from' (to' x) = x #-} class EP' a b | a -> b where from' :: a -> b to' :: b -> a }}} raises no errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 3 09:15:11 2009 From: trac at galois.com (GHC) Date: Fri Jul 3 08:57:40 2009 Subject: [GHC] #3263: Warnings for monadic values not used In-Reply-To: <051.2ba77802c306560898b377ae21be4ade@localhost> References: <051.2ba77802c306560898b377ae21be4ade@localhost> Message-ID: <060.ca7f317928aa3126c2e27db1a0146976@localhost> #3263: Warnings for monadic values not used ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo Comment: Re: {{{ evaluate -- Returns the thing on the input. Perhaps we should provide force :: a -> IO () as an alternative }}} I think that actually you are meant to use the returned value rather than the input value, as otherwise inlining can defeat the purpose of the forcing. See #2273 for more. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 3 15:32:27 2009 From: trac at galois.com (GHC) Date: Fri Jul 3 15:14:54 2009 Subject: [GHC] #3347: Add flag to prevent generation of import libraries on Windows Message-ID: <053.8a747ba46b77fc35e5fe19946b0f7d84@localhost> #3347: Add flag to prevent generation of import libraries on Windows -----------------------------+---------------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The import libraries generated when you use the -shared option to generate a library can be very big. For example, when using it to build the edit- distance library from Hackage (v0.1.2) I observed a DLL size of 2.7Mb and an import library size of 2.2Mb. (See also http://www.nabble.com/--out- implib-when-linking-shared-libraries-tt23561017.html) Due to these size concerns, it may be desirable to disable the generation of the import library altogether in cases where the user only wants to use dynamic linking. The attached patch adds a new flag, -fno-shared-implib, that does just that. NB: after experimentation I have found that there are at least two ways to reduce the size of the generated import library: * Use pexports from mingw-utils to generate a .def file from the generated .dll, and then use lib /def: to generate an import library from that. (NB: may be an issue with underscores added/removed in exported names - I haven't checked this). This generated a 825kb import library in my experiment above. * Unpack the .dll.a generated by the binutils ld and link the contents together. This should be equally functional as an import library, but it reduces the disk space requirements to a similar level as the other option (815kb in my test). The basic root of the problem is that the import libraries generated by GNU dlltool / ld are pretty bloated compared to those from the Microsoft toolchain. However, even the MS toolchain can't do much better than 30% of the size of the code, because Haskell code just exports tons of symbols (~3200 in my test, which of course includes not only the library but the RTS, base library etc). This should be ameliorated by the implementation of shared libraries on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 3 17:34:50 2009 From: trac at galois.com (GHC) Date: Fri Jul 3 17:18:13 2009 Subject: [GHC] #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) In-Reply-To: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> References: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> Message-ID: <056.8a51dfee4efb019adfb47a91b12d7f7b@localhost> #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by Baughn): * cc: sveina@gmail.com (added) Comment: This bug makes view patterns absolutely impossible to use. I accept that fixing it could take some work, but can we at least suppress the warning in 6.10.4? Add an option for that, perhaps? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 08:20:17 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 08:02:54 2009 Subject: [GHC] #3342: splitTyConApp panic when using view patterns In-Reply-To: <044.11e2951faa3ccd3c80f19d138272cf2e@localhost> References: <044.11e2951faa3ccd3c80f19d138272cf2e@localhost> Message-ID: <053.6bd1fa4806c7cad5917d8aa28cc1ef33@localhost> #3342: splitTyConApp panic when using view patterns ------------------------------------------------+--------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_compiler/T3342 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 08:31:46 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 08:14:35 2009 Subject: [GHC] #3301: Update Haskeline In-Reply-To: <042.39eb2fb65f452fed35078da0d81f6675@localhost> References: <042.39eb2fb65f452fed35078da0d81f6675@localhost> Message-ID: <051.64f1f1fcc1a315a2c1de946965b81581@localhost> #3301: Update Haskeline ---------------------------------+------------------------------------------ Reporter: cjs | Owner: Type: merge | Status: closed Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.10.3 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I've merged all the changes from the upstream haskeline repo into our repo. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 08:34:22 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 08:16:47 2009 Subject: [GHC] #3299: Error building HEAD on OS X: missing gmp.h In-Reply-To: <044.32b6ebaa96b6830af3d57ca8d51e4a7b@localhost> References: <044.32b6ebaa96b6830af3d57ca8d51e4a7b@localhost> Message-ID: <053.75d1b6af769a761a9e278e083249d006@localhost> #3299: Error building HEAD on OS X: missing gmp.h -------------------------+-------------------------------------------------- Reporter: judah | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by igloo): judah, can you check whether this is now working properly for you please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 10:16:50 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 09:59:13 2009 Subject: [GHC] #3348: crash in gc with > 2 generations Message-ID: <051.280ba552da1632e68cecc9754593cebf@localhost> #3348: crash in gc with > 2 generations -------------------------+-------------------------------------------------- Reporter: dynamic-wind | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 -------------------------+-------------------------------------------------- using ghci from binary distribution built w/mingw command line arguments +RTS -G3 enter: > let n=[1..10000000] > last n sometimes hereafter ghc crashes in various fashions, e.g. "evacuate: unknown closure type: 0" reproducing the crash may require several attempts seems like only 2 spaced gc works ok? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 10:31:26 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 10:13:49 2009 Subject: [GHC] #3349: poor responsiveness of ghci Message-ID: <051.8d710dd8a00a93e9e65fe6cedca146fa@localhost> #3349: poor responsiveness of ghci -------------------------------------+-------------------------------------- Reporter: dynamic-wind | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: GHCi Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 -------------------------------------+-------------------------------------- With lots of garbage created during an interactive session, pauses for gc become very noticeable and processor usage of GHC is very high. Line- editor of GHCi (thanks to Haskelline I think) loses keypresses when several keys are hit quickly after a pause. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 11:44:04 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 11:26:30 2009 Subject: [GHC] #3349: poor responsiveness of ghci In-Reply-To: <051.8d710dd8a00a93e9e65fe6cedca146fa@localhost> References: <051.8d710dd8a00a93e9e65fe6cedca146fa@localhost> Message-ID: <060.fa1a0770734710359c7a49e2ae3a5ecf@localhost> #3349: poor responsiveness of ghci --------------------------------------+------------------------------------- Reporter: dynamic-wind | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------------------------+------------------------------------- Comment (by judah): Thanks for the report. The behavior of losing keypresses sounds like a bug which has been fixed in the latest release of Haskeline, and will be used by ghc-6.10.4. Can you please run: {{{ cabal update cabal install ghci-haskeline }}} (You may want to run `cabal install --user ghci-haskeline` instead if you get permission errors.) Those commands should give you a `ghci-haskeline` program; please let us know whether it still presents those problems or whether they have been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 12:04:09 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 11:46:32 2009 Subject: [GHC] #3348: crash in gc with > 2 generations In-Reply-To: <051.280ba552da1632e68cecc9754593cebf@localhost> References: <051.280ba552da1632e68cecc9754593cebf@localhost> Message-ID: <060.1336f8ae3695360c88b56c34b0dc29ed@localhost> #3348: crash in gc with > 2 generations -------------------------------+-------------------------------------------- Reporter: dynamic-wind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: Thanks for the report. The stable branch crashes even earlier than that for me, on amd64/Linux: {{{ ghc/stage2-inplace/ghc --interactive +RTS -G3 GHCi, version 6.10.3.20090702: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. zsh: segmentation fault ghc/6.10-branch/ghc/ghc/stage2-inplace/ghc --interactive +RTS -G3 }}} I can't reproduce the problem with the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 12:07:04 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 11:49:33 2009 Subject: [GHC] #2715: Equality constraint in superclass not supported In-Reply-To: <047.797aaec011bad118fea0580e1c0ce283@localhost> References: <047.797aaec011bad118fea0580e1c0ce283@localhost> Message-ID: <056.66e70dfc089bd5f4eabe3c7f7e9d7a64@localhost> #2715: Equality constraint in superclass not supported ----------------------------------------+----------------------------------- Reporter: rodprice | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Changes (by ganesh): * cc: ganesh (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 12:38:27 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 12:20:50 2009 Subject: [GHC] #3299: Error building HEAD on OS X: missing gmp.h In-Reply-To: <044.32b6ebaa96b6830af3d57ca8d51e4a7b@localhost> References: <044.32b6ebaa96b6830af3d57ca8d51e4a7b@localhost> Message-ID: <053.2d64f1cb68aa97a9ecee3e96404a20a4@localhost> #3299: Error building HEAD on OS X: missing gmp.h -------------------------+-------------------------------------------------- Reporter: judah | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by judah): Yes, it works fine now; thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 13:11:44 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 12:54:07 2009 Subject: [GHC] #3299: Error building HEAD on OS X: missing gmp.h In-Reply-To: <044.32b6ebaa96b6830af3d57ca8d51e4a7b@localhost> References: <044.32b6ebaa96b6830af3d57ca8d51e4a7b@localhost> Message-ID: <053.1209a9be817ad9afee45411def28daca@localhost> #3299: Error building HEAD on OS X: missing gmp.h -------------------------+-------------------------------------------------- Reporter: judah | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Great, thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 13:53:34 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 13:36:05 2009 Subject: [GHC] #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) In-Reply-To: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> References: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> Message-ID: <056.dda8b63de075d2d2e09c300f2e4ec1b1@localhost> #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): You can turn the warning off with `-fno-warn-overlapping-patterns`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 14:46:06 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 14:28:37 2009 Subject: [GHC] #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) In-Reply-To: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> References: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> Message-ID: <056.80525ffe5303efb6feba98263086f951@localhost> #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by Baughn): I could, but then I lose ''all'' the overlap warnings, and I'd really like to keep them around. I don't always use view patterns. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 18:19:40 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 18:02:03 2009 Subject: [GHC] #3263: Warnings for monadic values not used In-Reply-To: <051.2ba77802c306560898b377ae21be4ade@localhost> References: <051.2ba77802c306560898b377ae21be4ade@localhost> Message-ID: <060.0b910391a80e01d6141cc3c890309686@localhost> #3263: Warnings for monadic values not used ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12.1 Comment: I've looked at some of the changes needed to fix base once the new warnings are on. There are some suspicious looking things going on in the `GHC.IO.Encoding.*` modules: `writeCharBuf` returns a new index, which may be either 1 or 2 beyond the index we're writing to if `CHARBUF_UTF16`, but we ignore it and just assume 1. Also, the `ow >= os` test looks like it'll be wrong when we need to write 2 characters. Simon M, am I missing something? The `updatingBucket` code also doesn't make sense to me: {{{ bkts' <- thawArray bkts writeMutArray bkts' indx bckt' freezeArray bkts' }}} Note that the frozen array is ignored - although currently {{{ freezeArray = return -- unsafeFreeze thawArray = return -- unsafeThaw }}} so nothing's happening anyway. There are also a number of C calls that look like they need to be wrapped in `throwErrnoIfMinus1_` or `throwErrnoIfMinus1Retry_`, e.g. {{{ hunk ./System/Posix/Internals.hs 243 - c_sigemptyset p_sigset - c_sigaddset p_sigset const_sigttou - c_sigprocmask const_sig_block p_sigset p_old_sigset + throwErrnoIfMinus1_ "sigemptyset" $ c_sigemptyset p_sigset + throwErrnoIfMinus1_ "sigaddset" $ c_sigaddset p_sigset const_sigttou + throwErrnoIfMinus1_ "sigprocmask" $ c_sigprocmask const_sig_block p_sigset p_old_sigset hunk ./System/Posix/Internals.hs 249 - c_sigprocmask const_sig_setmask p_old_sigset nullPtr + throwErrnoIfMinus1_ "sigprocmask" $ c_sigprocmask const_sig_setmask p_old_sigset nullPtr hunk ./System/Posix/Internals.hs 326 - c_fcntl_write fd const_f_setfl (fromIntegral flags') + throwErrnoIfMinus1Retry_ "fcntl_write" $ c_fcntl_write fd const_f_setfl (fromIntegral flags') hunk ./GHC/Conc.lhs 1085 - c_write (fromIntegral fd) pbuf 1; return () + throwErrnoIfMinus1Retry_ "write" $ c_write (fromIntegral fd) pbuf 1 }}} For now I've applied the patches that add the warning, but not the library patches, and I've set {{{ GhcLibHcOpts += -fno-warn-unused-do-bind }}} when validating so the warnings don't make the build fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 19:56:05 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 19:38:28 2009 Subject: [GHC] #3350: GHC doesn't compile on Mac OS X 10.4 (Tiger) via MacPorts Message-ID: <044.ceb05e62d959d517126b90f70525a764@localhost> #3350: GHC doesn't compile on Mac OS X 10.4 (Tiger) via MacPorts ----------------------------------------+----------------------------------- Reporter: indil | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.3 | Severity: blocker Keywords: install, error, gmp, linker | Testcase: Os: MacOS X | Architecture: x86 ----------------------------------------+----------------------------------- Executed "sudo port install ghc". Began installing version 6.10.3. Got this error: /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: can't locate file for: -lgmp collect2: ld returned 1 exit status linking dist-stage1/build/Fingerprint_hsc_make.o failed command was: /usr/bin/gcc -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/lib/ghc-6.6 -lHSunix_cbits -ldl -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries/hpc /dist-bootstrapping/build -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/lib/ghc-6.6 -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries /extensible-exceptions/dist-bootstrapping/build -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries/Cabal /dist-bootstrapping/build -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries/filepath /dist-bootstrapping/build -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/lib/ghc-6.6 -lHSbase_cbits -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/lib/ghc-6.6 -lm -lgmp -ldl dist- stage1/build/Fingerprint_hsc_make.o -o dist- stage1/build/Fingerprint_hsc_make make[1]: *** [boot.stage.1] Error 1 make: *** [stage1] Error 1 I checked, and gmp is installed. I tried uninstalling it, cleaning it, and reinstalling it, and I also tried cleaning ghc, but I get the same error when trying to install ghc again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 20:26:40 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 20:09:03 2009 Subject: [GHC] #1817: Should be possible to specify pragmas with mixed case In-Reply-To: <044.c4095d9e6406b41062c64e87c778bda3@localhost> References: <044.c4095d9e6406b41062c64e87c778bda3@localhost> Message-ID: <053.9720c17f902749d4a13adb88b8d76f76@localhost> #1817: Should be possible to specify pragmas with mixed case ----------------------------------+----------------------------------------- Reporter: igloo | Owner: squadette Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Parser) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by squadette): * owner: => squadette -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 4 21:37:23 2009 From: trac at galois.com (GHC) Date: Sat Jul 4 21:19:47 2009 Subject: [GHC] #1817: Should be possible to specify pragmas with mixed case In-Reply-To: <044.c4095d9e6406b41062c64e87c778bda3@localhost> References: <044.c4095d9e6406b41062c64e87c778bda3@localhost> Message-ID: <053.0b26e7de745a874881ae718be289d459@localhost> #1817: Should be possible to specify pragmas with mixed case ----------------------------------+----------------------------------------- Reporter: igloo | Owner: squadette Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Parser) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by squadette): Please provide feedback for the patch at: http://github.com/squadette/ghc/commit/8d416b7dcc96bd44a06dbcec4fa33a0edf2b4883 (could be downloaded at: http://github.com/squadette/ghc/commit/8d416b7dcc96bd44a06dbcec4fa33a0edf2b4883.patch) It passes all my tests, but they are not yet comprehensive. Patch to testsuite will follow. Also, LINE pragma is not handled yet, that'll be in the updated version of the patch. This is my first cut at hacking GHC. Thank you, -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 5 08:22:29 2009 From: trac at galois.com (GHC) Date: Sun Jul 5 08:04:51 2009 Subject: [GHC] #3351: Generated ghc man page missing xrefs Message-ID: <043.e70675efe6c1e6fb67be6a4568f6dd0d@localhost> #3351: Generated ghc man page missing xrefs -----------------------------+---------------------------------------------- Reporter: kaol | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.3 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The man page for ghc is generated from xml files. Currently, this ignores xrefs, turning, for example {{{ enable almost all warnings (details in ) }}} to enable almost all warnings (details in ) This leads to stunted sentences as well as missing information. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 5 10:14:41 2009 From: trac at galois.com (GHC) Date: Sun Jul 5 09:57:03 2009 Subject: [GHC] #3352: Data.Word should define instances of Random for each type Message-ID: <043.251be63510fd30b1463f4fc2dcc0c60a@localhost> #3352: Data.Word should define instances of Random for each type -----------------------------+---------------------------------------------- Reporter: kaol | Owner: Type: feature request | Status: new Priority: normal | Component: libraries/base Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I'm forwarding Debian bug http://bugs.debian.org/533022 for your consideration. ---- Data.Word defines signed and unsigned integer types for various bit sizes. It would help if Data.Word made each type an instance of Random. Per http://www.haskell.org/haskellwiki/Orphan_instance , such an instance should appear either in System.Random or Data.Word, and it makes more sense to do the latter. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 5 10:36:07 2009 From: trac at galois.com (GHC) Date: Sun Jul 5 10:18:29 2009 Subject: [GHC] #2608: Direct support for unit tests in Cabal In-Reply-To: <043.0f910c87967bdcd72df76a06d6dc0fa6@localhost> References: <043.0f910c87967bdcd72df76a06d6dc0fa6@localhost> Message-ID: <052.f8809d92a2249e074ed219618005cf30@localhost> #2608: Direct support for unit tests in Cabal ----------------------------------+----------------------------------------- Reporter: kaol | Owner: Type: proposal | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.6.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by kaol): I looked at reporting this to the Cabal bug tracker but looks like it's being discussed already at http://hackage.haskell.org/trac/hackage/ticket/215 http://hackage.haskell.org/trac/hackage/ticket/212 also. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 5 11:24:38 2009 From: trac at galois.com (GHC) Date: Sun Jul 5 11:07:00 2009 Subject: [GHC] #3352: Data.Word should define instances of Random for each type In-Reply-To: <043.251be63510fd30b1463f4fc2dcc0c60a@localhost> References: <043.251be63510fd30b1463f4fc2dcc0c60a@localhost> Message-ID: <052.9cf865dffaaa0669b22b90fc84f821d3@localhost> #3352: Data.Word should define instances of Random for each type ------------------------------+--------------------------------------------- Reporter: kaol | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by ross): Data.Word is in the base package and System.Random is in the random package, which depends on base, so the instances would have to go in System.Random. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 5 12:02:23 2009 From: trac at galois.com (GHC) Date: Sun Jul 5 11:44:42 2009 Subject: [GHC] #3353: Add CLDouble support Message-ID: <044.199bb36c514cf1226e0efa905a8fa4ca@localhost> #3353: Add CLDouble support -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- The FFI spec says that we should support `CLDouble`, but we don't (#2793). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 5 12:03:24 2009 From: trac at galois.com (GHC) Date: Sun Jul 5 11:45:46 2009 Subject: [GHC] #2793: CLDouble is nothing like a long double In-Reply-To: <047.5dadea2fc38a170289501238d399f214@localhost> References: <047.5dadea2fc38a170289501238d399f214@localhost> Message-ID: <056.197370d32e85e9173d1382333df3e344@localhost> #2793: CLDouble is nothing like a long double ---------------------------------+------------------------------------------ Reporter: jedbrown | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I've removed GHC's CLDouble pretense, and opened #3353 "Add CLDouble support" to add proper support. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 5 12:51:55 2009 From: trac at galois.com (GHC) Date: Sun Jul 5 12:34:21 2009 Subject: [GHC] #2253: Native code generator could do better In-Reply-To: <043.862f2d1bf55b0e0d2dddbf6af3659352@localhost> References: <043.862f2d1bf55b0e0d2dddbf6af3659352@localhost> Message-ID: <052.729ad55d9315fd085b01ec8e49a20d19@localhost> #2253: Native code generator could do better -----------------------------------------+---------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (NCG) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by Lemmih): * cc: lemmih@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 5 15:10:06 2009 From: trac at galois.com (GHC) Date: Sun Jul 5 14:52:28 2009 Subject: [GHC] #3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger) Message-ID: <047.37055053b1160c638a5374c844089d6a@localhost> #3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger) ---------------------+------------------------------------------------------ Reporter: bkomuves | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.1 | Severity: major Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple ---------------------+------------------------------------------------------ It seems that binaries (at least those linked with the threaded runtime) built with GHC on Mac OS X 10.5 do not work on Mac OS X 10.4. The error message in my case is {{{ dyld: lazy symbol binding failed: Symbol not found: _pthread_cond_init$UNIX2003 Referenced from: Expected in: /usr/lib/libSystem.B.dylib }}} I believe that the primary reasons for this is that the runtime system is linked against the 10.5 system libraries, which are not ABI compatible with the 10.4 system libraries. Apple provides both 10.4 and 10.5 SDKs with 10.5, along with compiler and linker options for those who want to build backward-compatible binaries. I tried to pass these options to the linker, which results in the error message {{{ Undefined symbols: "_strerror$UNIX2003", referenced from: _newThreadLocalKey in libHSrts_thr.a(OSThreads.thr_o) _setThreadLocalVar in libHSrts_thr.a(OSThreads.thr_o) _freeThreadLocalKey in libHSrts_thr.a(OSThreads.thr_o) _my_mmap in libHSrts_thr.a(OSMem.thr_o) _rtsSysErrorMsgFn in libHSrts_thr.a(RtsMessages.thr_o) "_fputs$UNIX2003", referenced from: _heapCensus in libHSrts_thr.a(ProfHeap.thr_o) "_read$UNIX2003", referenced from: ___hscore_PrelHandle_read in libHSbase-4.0.0.0.a(PrelIOUtils.o) "_fcntl$UNIX2003", referenced from: _resetNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o) _resetNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o) _setNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o) _setNonBlockingFd in libHSrts_thr.a(RtsUtils.thr_o) "_pthread_cond_init$UNIX2003", referenced from: _initCondition in libHSrts_thr.a(OSThreads.thr_o) "_open$UNIX2003", referenced from: ___hscore_open in libHSbase-4.0.0.0.a(PrelIOUtils.o) "_kill$UNIX2003", referenced from: _shutdownHaskellAndSignal in libHSrts_thr.a(RtsStartup.thr_o) "_select$UNIX2003", referenced from: _fdReady in libHSbase-4.0.0.0.a(inputReady.o) "_write$UNIX2003", referenced from: _ioManagerWakeup in libHSrts_thr.a(Signals.thr_o) _ioManagerDie in libHSrts_thr.a(Signals.thr_o) _generic_handler in libHSrts_thr.a(Signals.thr_o) ___hscore_PrelHandle_write in libHSbase-4.0.0.0.a(PrelIOUtils.o) ld: symbol(s) not found }}} It would be nice if GHC on OS X shipped with two version of the runtime (and the base library?), and had compiler flags to build compatible binaries. This could be also a problem in the future, with the next OS X versions. See also this thread: http://lists.apple.com/archives/Darwin- dev/2007/Nov/msg00109.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 5 19:45:14 2009 From: trac at galois.com (GHC) Date: Sun Jul 5 19:27:34 2009 Subject: [GHC] #3348: crash in gc with > 2 generations In-Reply-To: <051.280ba552da1632e68cecc9754593cebf@localhost> References: <051.280ba552da1632e68cecc9754593cebf@localhost> Message-ID: <060.7231f9feb5e29109cbb1c2d8e9574b02@localhost> #3348: crash in gc with > 2 generations -------------------------------+-------------------------------------------- Reporter: dynamic-wind | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Runtime System | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: => 6.10.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 6 04:55:38 2009 From: trac at galois.com (GHC) Date: Mon Jul 6 04:37:58 2009 Subject: [GHC] #3355: Refactor Template Haskell syntax conversions Message-ID: <047.1f46b8c5776cfa915775f27bfb2f30b5@localhost> #3355: Refactor Template Haskell syntax conversions -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.3 Severity: normal | Keywords: Difficulty: Moderate (1 day) | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- On [wiki:Commentary/Compiler/TemplateHaskell] there is a proposed refactoring of the Tempate Haskell-related syntax conversions. This task is to do that refactoring. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 6 07:22:50 2009 From: trac at galois.com (GHC) Date: Mon Jul 6 07:05:09 2009 Subject: [GHC] #3348: crash in gc with > 2 generations In-Reply-To: <051.280ba552da1632e68cecc9754593cebf@localhost> References: <051.280ba552da1632e68cecc9754593cebf@localhost> Message-ID: <060.653304e29db363489645104cecf44c56@localhost> #3348: crash in gc with > 2 generations -------------------------------+-------------------------------------------- Reporter: dynamic-wind | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Runtime System | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'm validating the fix for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 6 08:01:41 2009 From: trac at galois.com (GHC) Date: Mon Jul 6 07:43:59 2009 Subject: [GHC] #3348: crash in gc with > 2 generations In-Reply-To: <051.280ba552da1632e68cecc9754593cebf@localhost> References: <051.280ba552da1632e68cecc9754593cebf@localhost> Message-ID: <060.7523dcefa465293e2414f446ae59013b@localhost> #3348: crash in gc with > 2 generations -------------------------------+-------------------------------------------- Reporter: dynamic-wind | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.4 Component: Runtime System | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Mon Jul 6 04:22:27 PDT 2009 Simon Marlow * Fix generational GC bug (#3348) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 6 10:48:50 2009 From: trac at galois.com (GHC) Date: Mon Jul 6 10:31:11 2009 Subject: [GHC] #2197: GHCi doesn't work when built with way=p In-Reply-To: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> References: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> Message-ID: <052.cfa13d165f327ad71d1c4e5a9cbcb088@localhost> #2197: GHCi doesn't work when built with way=p ---------------------------------+------------------------------------------ Reporter: SamB | Owner: simonmar Type: bug | Status: closed Priority: low | Milestone: 6.12 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed (as in, we get a good error message. GHCi still does not work when built profiled) {{{ Wed Jul 1 05:23:54 PDT 2009 Simon Marlow * Fix #2197 (properly this time) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 6 13:51:46 2009 From: trac at galois.com (GHC) Date: Mon Jul 6 13:34:05 2009 Subject: [GHC] #2197: GHCi doesn't work when built with way=p In-Reply-To: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> References: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> Message-ID: <052.9f9d711ac3f6a3dab34eae25f2c696f0@localhost> #2197: GHCi doesn't work when built with way=p ---------------------------------+------------------------------------------ Reporter: SamB | Owner: simonmar Type: bug | Status: closed Priority: low | Milestone: 6.12 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by SamB): Does this also work for Template Haskell? Even from Haddock? What if I *want* GHCi to support profiling? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 6 14:10:04 2009 From: trac at galois.com (GHC) Date: Mon Jul 6 13:52:22 2009 Subject: [GHC] #3306: Improve syntax for GADT + records In-Reply-To: <046.d67bbf39466d205ecf2349957e851ca2@localhost> References: <046.d67bbf39466d205ecf2349957e851ca2@localhost> Message-ID: <055.f58486ae7389ab5c73744845d1276246@localhost> #3306: Improve syntax for GADT + records ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by SamB): I really don't like the way (B) implies the existance of record types -- unless you would like to add those too? I am one of those who wants to see the current data type declaration syntax die as soon as reasonably possible, i.e., in H'', and do not approve of it's being used as a precedent for anything. In that light, I don't think that (A) looks much like a repeat of C's mistake -- the part to the left of the {{{::}}} is obviously supposed to be a term. The one issue I have with (A) is the location of the context, and that doesn't seem like a good enough reason to use (B) instead, unless we want to make this possible too: {{{ { x::ty, y::ty } -> ty }}} I'll grant that even (B) isn't nearly as bad as what a context on an old- style "data" declaration does, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 6 16:16:27 2009 From: trac at galois.com (GHC) Date: Mon Jul 6 15:58:45 2009 Subject: [GHC] #3356: {-# LANGUAGE NoTraditionalRecordSyntax #-} to disable the current record syntax Message-ID: <043.6778edbbee7a5013ba33c2b55c12358e@localhost> #3356: {-# LANGUAGE NoTraditionalRecordSyntax #-} to disable the current record syntax -----------------------------+---------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I want to get the current record syntax demoted to an extension in Haskell'. This would be more likely to happen if disallowing it was supported by GHC, so I want to see GHC support this with: {{{ {-# LANGUAGE NoTraditionalRecordSyntax #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 6 23:21:13 2009 From: trac at galois.com (GHC) Date: Mon Jul 6 23:03:29 2009 Subject: [GHC] #3357: ghc panic Message-ID: <050.7b7e81294b3928dd895b8511a4ac3a2f@localhost> #3357: ghc panic ------------------------+--------------------------------------------------- Reporter: kimwallmark | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple ------------------------+--------------------------------------------------- I ran "ghci 67.hs" from the command line, and got the following crash. 67.hs is a 21K file that references no other modules. {{{ GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( 67.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-apple-darwin): 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 Mon Jul 6 23:25:03 2009 From: trac at galois.com (GHC) Date: Mon Jul 6 23:07:20 2009 Subject: [GHC] #3358: ghc panic Message-ID: <050.e5f262228fcd36d77c24062371cc5665@localhost> #3358: ghc panic ------------------------+--------------------------------------------------- Reporter: kimwallmark | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple ------------------------+--------------------------------------------------- Running "ghci 67.hs" from the command line caused the following crash. 67.hs is a ~21K file that doesn't reference any other modules. {{{ GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( 67.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-apple-darwin): 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 Mon Jul 6 23:25:36 2009 From: trac at galois.com (GHC) Date: Mon Jul 6 23:07:51 2009 Subject: [GHC] #3358: ghc panic In-Reply-To: <050.e5f262228fcd36d77c24062371cc5665@localhost> References: <050.e5f262228fcd36d77c24062371cc5665@localhost> Message-ID: <059.fa2f540570ed92208b515d4ef853b212@localhost> #3358: ghc panic -------------------------+-------------------------------------------------- Reporter: kimwallmark | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: duplicate Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple -------------------------+-------------------------------------------------- Changes (by kimwallmark): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 01:56:43 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 01:39:04 2009 Subject: [GHC] #2677: Detection of TF instance conflict depends on instance order In-Reply-To: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> References: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> Message-ID: <055.f06f43438e42cd6fddacbfd9b73e784a@localhost> #2677: Detection of TF instance conflict depends on instance order ----------------------------------------+----------------------------------- Reporter: reinerp | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: TF instance conflict | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 01:57:00 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 01:39:19 2009 Subject: [GHC] #2677: Detection of TF instance conflict depends on instance order In-Reply-To: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> References: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> Message-ID: <055.3ba1999f3d4e7fbfe64e062b8d0a1dab@localhost> #2677: Detection of TF instance conflict depends on instance order ----------------------------------------+----------------------------------- Reporter: reinerp | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: TF instance conflict | Difficulty: Unknown Testcase: T2677 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by chak): * testcase: => T2677 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 02:28:43 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 02:10:59 2009 Subject: [GHC] #3359: Build failed: "Could not find module `MachOp'" on 64bit Linux w/ GHC 6.10.3 Message-ID: <053.73eaad444842b7192c2c7e2a94f9bfa5@localhost> #3359: Build failed: "Could not find module `MachOp'" on 64bit Linux w/ GHC 6.10.3 ---------------------------+------------------------------------------------ Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ---------------------------+------------------------------------------------ {{{ [glastonbury:~/Projects/GHC/ghc]$ make ===--- updating makefiles phase 0 make -r --no-print-directory -f ghc.mk phase=0 just-makefiles ===--- updating makefiles phase 1 make -r --no-print-directory -f ghc.mk phase=1 just-makefiles ===--- updating makefiles phase 2 make -r --no-print-directory -f ghc.mk phase=2 just-makefiles compiler/ghc.mk:432: compiler/stage1/build/.depend-v: No such file or directory "inplace/bin/mkdirhier" compiler/stage1/build "rm" -f compiler/stage1/build/.depend-v.tmp touch compiler/stage1/build/.depend-v.tmp "inplace/bin/mkdependC" -f compiler/stage1/build/.depend-v.tmp -- -O -g -O2 -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -isystem/usr/local/lib/ghc-6.10.3/bytestring-0.9.1.4/include -isystem/usr/local/lib/ghc-6.10.3/process-1.0.1.1/include -isystem/usr/local/lib/ghc-6.10.3/directory-1.0.0.3/include -isystem/usr/local/lib/ghc-6.10.3/unix-2.3.2.0/include -isystem/usr/local/lib/ghc-6.10.3/old-time-1.0.0.2/include -isystem/usr/local/lib/ghc-6.10.3/base-4.1.0.0/include -isystem/usr/local/lib/ghc-6.10.3/include -isystemPAPI_INCLUDE_DIR -- compiler/parser/cutils.c compiler/utils/md5.c sed -e "s|compiler/\([^ :]*o[ :]\)|compiler/stage1/build/\1|g" -e "s|/home/ashley/Projects/GHC/ghc/||" compiler/stage1/build/.depend-v "/usr/local/bin/ghc" -M -include-pkg-deps -dep-makefile compiler/stage1/build/.depend-v -H32m -O -package-conf libraries/bootstrapping.conf -package-name ghc-6.11 -hide-all-packages -i -icompiler/nativeGen -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/main -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.7.2 -package array-0.2.0.0 -package base-4.1.0.0 -package bytestring-0.9.1.4 -package containers-0.2.0.1 -package directory-1.0.0.3 -package filepath-1.1.0.2 -package haskell98-1.0.1.0 -package hpc-0.5.0.3 -package old-time-1.0.0.2 -package process-1.0.1.1 -package unix-2.3.2.0 -#include cutils.h -DSTAGE=1 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -hisuf hi -osuf o -hcsuf hc compiler/nativeGen/AsmCodeGen.lhs compiler/nativeGen/TargetReg.hs compiler/nativeGen/NCGMonad.hs compiler/nativeGen/Instruction.hs compiler/nativeGen/Size.hs compiler/nativeGen/Reg.hs compiler/nativeGen/RegClass.hs compiler/nativeGen/PprBase.hs compiler/nativeGen/PIC.hs compiler/nativeGen/Platform.hs compiler/nativeGen/Alpha/Regs.hs compiler/nativeGen/Alpha/RegInfo.hs compiler/nativeGen/Alpha/Instr.hs compiler/nativeGen/Alpha/CodeGen.hs compiler/nativeGen/X86/Regs.hs compiler/nativeGen/X86/RegInfo.hs compiler/nativeGen/X86/Instr.hs compiler/nativeGen/X86/Cond.hs compiler/nativeGen/X86/Ppr.hs compiler/nativeGen/X86/CodeGen.hs compiler/nativeGen/PPC/Regs.hs compiler/nativeGen/PPC/RegInfo.hs compiler/nativeGen/PPC/Instr.hs compiler/nativeGen/PPC/Cond.hs compiler/nativeGen/PPC/Ppr.hs compiler/nativeGen/PPC/CodeGen.hs compiler/nativeGen/SPARC/Base.hs compiler/nativeGen/SPARC/Regs.hs compiler/nativeGen/SPARC/RegPlate.hs compiler/nativeGen/SPARC/Imm.hs compiler/nativeGen/SPARC/AddrMode.hs compiler/nativeGen/SPARC/Cond.hs compiler/nativeGen/SPARC/Instr.hs compiler/nativeGen/SPARC/Stack.hs compiler/nativeGen/SPARC/ShortcutJump.hs compiler/nativeGen/SPARC/Ppr.hs compiler/nativeGen/SPARC/CodeGen.hs compiler/nativeGen/SPARC/CodeGen/Amode.hs compiler/nativeGen/SPARC/CodeGen/Base.hs compiler/nativeGen/SPARC/CodeGen/CCall.hs compiler/nativeGen/SPARC/CodeGen/CondCode.hs compiler/nativeGen/SPARC/CodeGen/Gen32.hs compiler/nativeGen/SPARC/CodeGen/Gen64.hs compiler/nativeGen/SPARC/CodeGen/Sanity.hs compiler/nativeGen/SPARC/CodeGen/Expand.hs compiler/nativeGen/RegAlloc/Liveness.hs compiler/nativeGen/RegAlloc/Graph/Main.hs compiler/nativeGen/RegAlloc/Graph/Stats.hs compiler/nativeGen/RegAlloc/Graph/ArchBase.hs compiler/nativeGen/RegAlloc/Graph/ArchX86.hs compiler/nativeGen/RegAlloc/Graph/Coalesce.hs compiler/nativeGen/RegAlloc/Graph/Spill.hs compiler/nativeGen/RegAlloc/Graph/SpillClean.hs compiler/nativeGen/RegAlloc/Graph/SpillCost.hs compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs compiler/nativeGen/RegAlloc/Linear/Main.hs compiler/nativeGen/RegAlloc/Linear/JoinToTargets.hs compiler/nativeGen/RegAlloc/Linear/State.hs compiler/nativeGen/RegAlloc/Linear/Stats.hs compiler/nativeGen/RegAlloc/Linear/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/StackMap.hs compiler/nativeGen/RegAlloc/Linear/Base.hs compiler/nativeGen/RegAlloc/Linear/X86/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/PPC/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/SPARC/FreeRegs.hs compiler/basicTypes/BasicTypes.lhs compiler/basicTypes/DataCon.lhs compiler/basicTypes/Demand.lhs compiler/utils/Exception.hs compiler/basicTypes/Id.lhs compiler/basicTypes/IdInfo.lhs compiler/basicTypes/Literal.lhs compiler/basicTypes/MkId.lhs compiler/basicTypes/Module.lhs compiler/basicTypes/Name.lhs compiler/basicTypes/NameEnv.lhs compiler/basicTypes/NameSet.lhs compiler/basicTypes/NewDemand.lhs compiler/basicTypes/OccName.lhs compiler/basicTypes/RdrName.lhs compiler/basicTypes/SrcLoc.lhs compiler/basicTypes/UniqSupply.lhs compiler/basicTypes/Unique.lhs compiler/basicTypes/Var.lhs compiler/basicTypes/VarEnv.lhs compiler/basicTypes/VarSet.lhs compiler/cmm/BlockId.hs compiler/cmm/CLabel.hs compiler/cmm/Cmm.hs compiler/cmm/CmmBrokenBlock.hs compiler/cmm/CmmBuildInfoTables.hs compiler/cmm/CmmCPS.hs compiler/cmm/CmmCPSGen.hs compiler/cmm/CmmCPSZ.hs compiler/cmm/CmmCallConv.hs compiler/cmm/CmmCommonBlockElimZ.hs compiler/cmm/CmmContFlowOpt.hs compiler/cmm/CmmCvt.hs compiler/cmm/CmmExpr.hs compiler/cmm/CmmInfo.hs compiler/cmm/CmmLex.hs compiler/cmm/CmmLint.hs compiler/cmm/CmmLive.hs compiler/cmm/CmmLiveZ.hs compiler/cmm/CmmOpt.hs compiler/cmm/CmmParse.hs compiler/cmm/CmmProcPoint.hs compiler/cmm/CmmProcPointZ.hs compiler/cmm/CmmSpillReload.hs compiler/cmm/CmmStackLayout.hs compiler/cmm/CmmTx.hs compiler/cmm/CmmUtils.hs compiler/cmm/CmmZipUtil.hs compiler/cmm/DFMonad.hs compiler/cmm/Dataflow.hs compiler/cmm/MkZipCfg.hs compiler/cmm/MkZipCfgCmm.hs compiler/cmm/OptimizationFuel.hs compiler/cmm/PprC.hs compiler/cmm/PprCmm.hs compiler/cmm/PprCmmZ.hs compiler/cmm/StackColor.hs compiler/cmm/StackPlacements.hs compiler/cmm/ZipCfg.hs compiler/cmm/ZipCfgCmmRep.hs compiler/cmm/ZipCfgExtras.hs compiler/cmm/ZipDataflow.hs compiler/codeGen/Bitmap.hs compiler/codeGen/CgBindery.lhs compiler/codeGen/CgCallConv.hs compiler/codeGen/CgCase.lhs compiler/codeGen/CgClosure.lhs compiler/codeGen/CgCon.lhs compiler/codeGen/CgExpr.lhs compiler/codeGen/CgForeignCall.hs compiler/codeGen/CgHeapery.lhs compiler/codeGen/CgHpc.hs compiler/codeGen/CgInfoTbls.hs compiler/codeGen/CgLetNoEscape.lhs compiler/codeGen/CgMonad.lhs compiler/codeGen/CgParallel.hs compiler/codeGen/CgPrimOp.hs compiler/codeGen/CgProf.hs compiler/codeGen/CgStackery.lhs compiler/codeGen/CgTailCall.lhs compiler/codeGen/CgTicky.hs compiler/codeGen/CgUtils.hs compiler/codeGen/StgCmm.hs compiler/codeGen/StgCmmBind.hs compiler/codeGen/StgCmmClosure.hs compiler/codeGen/StgCmmCon.hs compiler/codeGen/StgCmmEnv.hs compiler/codeGen/StgCmmExpr.hs compiler/codeGen/StgCmmForeign.hs compiler/codeGen/StgCmmGran.hs compiler/codeGen/StgCmmHeap.hs compiler/codeGen/StgCmmHpc.hs compiler/codeGen/StgCmmLayout.hs compiler/codeGen/StgCmmMonad.hs compiler/codeGen/StgCmmPrim.hs compiler/codeGen/StgCmmProf.hs compiler/codeGen/StgCmmTicky.hs compiler/codeGen/StgCmmUtils.hs compiler/codeGen/ClosureInfo.lhs compiler/codeGen/CodeGen.lhs compiler/codeGen/SMRep.lhs compiler/coreSyn/CoreArity.lhs compiler/coreSyn/CoreFVs.lhs compiler/coreSyn/CoreLint.lhs compiler/coreSyn/CorePrep.lhs compiler/coreSyn/CoreSubst.lhs compiler/coreSyn/CoreSyn.lhs compiler/coreSyn/CoreTidy.lhs compiler/coreSyn/CoreUnfold.lhs compiler/coreSyn/CoreUtils.lhs compiler/coreSyn/ExternalCore.lhs compiler/coreSyn/MkCore.lhs compiler/coreSyn/MkExternalCore.lhs compiler/coreSyn/PprCore.lhs compiler/coreSyn/PprExternalCore.lhs compiler/cprAnalysis/CprAnalyse.lhs compiler/deSugar/Check.lhs compiler/deSugar/Coverage.lhs compiler/deSugar/Desugar.lhs compiler/deSugar/DsArrows.lhs compiler/deSugar/DsBinds.lhs compiler/deSugar/DsCCall.lhs compiler/deSugar/DsExpr.lhs compiler/deSugar/DsForeign.lhs compiler/deSugar/DsGRHSs.lhs compiler/deSugar/DsListComp.lhs compiler/deSugar/DsMonad.lhs compiler/deSugar/DsUtils.lhs compiler/deSugar/Match.lhs compiler/deSugar/MatchCon.lhs compiler/deSugar/MatchLit.lhs compiler/hsSyn/HsBinds.lhs compiler/hsSyn/HsDecls.lhs compiler/hsSyn/HsDoc.hs compiler/hsSyn/HsExpr.lhs compiler/hsSyn/HsImpExp.lhs compiler/hsSyn/HsLit.lhs compiler/hsSyn/HsPat.lhs compiler/hsSyn/HsSyn.lhs compiler/hsSyn/HsTypes.lhs compiler/hsSyn/HsUtils.lhs compiler/iface/BinIface.hs compiler/iface/BuildTyCl.lhs compiler/iface/IfaceEnv.lhs compiler/iface/IfaceSyn.lhs compiler/iface/IfaceType.lhs compiler/iface/LoadIface.lhs compiler/iface/MkIface.lhs compiler/iface/TcIface.lhs compiler/main/Annotations.lhs compiler/main/BreakArray.hs compiler/main/CmdLineParser.hs compiler/main/CodeOutput.lhs compiler/main/Config.hs compiler/main/Constants.lhs compiler/main/DriverMkDepend.hs compiler/main/DriverPhases.hs compiler/main/DriverPipeline.hs compiler/main/DynFlags.hs compiler/main/ErrUtils.lhs compiler/main/Finder.lhs compiler/main/GHC.hs compiler/main/HeaderInfo.hs compiler/main/HscMain.lhs compiler/main/HscStats.lhs compiler/main/HscTypes.lhs compiler/main/InteractiveEval.hs compiler/main/PackageConfig.hs compiler/main/Packages.lhs compiler/main/ParsePkgConf.hs compiler/main/PprTyThing.hs compiler/main/StaticFlags.hs compiler/main/StaticFlagParser.hs compiler/main/SysTools.lhs compiler/main/TidyPgm.lhs compiler/parser/Ctype.lhs compiler/parser/HaddockLex.hs compiler/parser/HaddockParse.hs compiler/parser/HaddockUtils.hs compiler/parser/LexCore.hs compiler/parser/Lexer.hs compiler/parser/Parser.hs compiler/parser/ParserCore.hs compiler/parser/ParserCoreUtils.hs compiler/parser/RdrHsSyn.lhs compiler/prelude/ForeignCall.lhs compiler/prelude/PrelInfo.lhs compiler/prelude/PrelNames.lhs compiler/prelude/PrelRules.lhs compiler/prelude/PrimOp.lhs compiler/prelude/TysPrim.lhs compiler/prelude/TysWiredIn.lhs compiler/profiling/CostCentre.lhs compiler/profiling/SCCfinal.lhs compiler/rename/RnBinds.lhs compiler/rename/RnEnv.lhs compiler/rename/RnExpr.lhs compiler/rename/RnHsDoc.hs compiler/rename/RnHsSyn.lhs compiler/rename/RnNames.lhs compiler/rename/RnPat.lhs compiler/rename/RnSource.lhs compiler/rename/RnTypes.lhs compiler/simplCore/CoreMonad.lhs compiler/simplCore/CSE.lhs compiler/simplCore/FloatIn.lhs compiler/simplCore/FloatOut.lhs compiler/simplCore/LiberateCase.lhs compiler/simplCore/OccurAnal.lhs compiler/simplCore/SAT.lhs compiler/simplCore/SetLevels.lhs compiler/simplCore/SimplCore.lhs compiler/simplCore/SimplEnv.lhs compiler/simplCore/SimplMonad.lhs compiler/simplCore/SimplUtils.lhs compiler/simplCore/Simplify.lhs compiler/simplStg/SRT.lhs compiler/simplStg/SimplStg.lhs compiler/simplStg/StgStats.lhs compiler/specialise/Rules.lhs compiler/specialise/SpecConstr.lhs compiler/specialise/Specialise.lhs compiler/stgSyn/CoreToStg.lhs compiler/stgSyn/StgLint.lhs compiler/stgSyn/StgSyn.lhs compiler/stranal/DmdAnal.lhs compiler/stranal/SaAbsInt.lhs compiler/stranal/SaLib.lhs compiler/stranal/StrictAnal.lhs compiler/stranal/WorkWrap.lhs compiler/stranal/WwLib.lhs compiler/typecheck/FamInst.lhs compiler/typecheck/Inst.lhs compiler/typecheck/TcAnnotations.lhs compiler/typecheck/TcArrows.lhs compiler/typecheck/TcBinds.lhs compiler/typecheck/TcClassDcl.lhs compiler/typecheck/TcDefaults.lhs compiler/typecheck/TcDeriv.lhs compiler/typecheck/TcEnv.lhs compiler/typecheck/TcExpr.lhs compiler/typecheck/TcForeign.lhs compiler/typecheck/TcGenDeriv.lhs compiler/typecheck/TcHsSyn.lhs compiler/typecheck/TcHsType.lhs compiler/typecheck/TcInstDcls.lhs compiler/typecheck/TcMType.lhs compiler/typecheck/TcMatches.lhs compiler/typecheck/TcPat.lhs compiler/typecheck/TcRnDriver.lhs compiler/typecheck/TcRnMonad.lhs compiler/typecheck/TcRnTypes.lhs compiler/typecheck/TcRules.lhs compiler/typecheck/TcSimplify.lhs compiler/typecheck/TcTyClsDecls.lhs compiler/typecheck/TcTyDecls.lhs compiler/typecheck/TcTyFuns.lhs compiler/typecheck/TcType.lhs compiler/typecheck/TcUnify.lhs compiler/types/Class.lhs compiler/types/Coercion.lhs compiler/types/FamInstEnv.lhs compiler/types/FunDeps.lhs compiler/types/Generics.lhs compiler/types/InstEnv.lhs compiler/types/TyCon.lhs compiler/types/Type.lhs compiler/types/TypeRep.lhs compiler/types/Unify.lhs compiler/utils/Bag.lhs compiler/utils/Binary.hs compiler/utils/BufWrite.hs compiler/utils/Digraph.lhs compiler/utils/Encoding.hs compiler/utils/FastBool.lhs compiler/utils/FastFunctions.lhs compiler/utils/FastMutInt.lhs compiler/utils/FastString.lhs compiler/utils/FastTypes.lhs compiler/stage1/build/Fingerprint.hs compiler/utils/FiniteMap.lhs compiler/utils/GraphBase.hs compiler/utils/GraphColor.hs compiler/utils/GraphOps.hs compiler/utils/GraphPpr.hs compiler/utils/IOEnv.hs compiler/utils/Interval.hs compiler/utils/LazyUniqFM.lhs compiler/utils/ListSetOps.lhs compiler/utils/Maybes.lhs compiler/utils/MonadUtils.hs compiler/utils/OrdList.lhs compiler/utils/Outputable.lhs compiler/utils/Panic.lhs compiler/utils/Pretty.lhs compiler/utils/Serialized.hs compiler/utils/State.hs compiler/utils/StringBuffer.lhs compiler/utils/UniqFM.lhs compiler/utils/UniqSet.lhs compiler/utils/Util.lhs compiler/vectorise/VectBuiltIn.hs compiler/vectorise/VectCore.hs compiler/vectorise/VectMonad.hs compiler/vectorise/VectType.hs compiler/vectorise/VectUtils.hs compiler/vectorise/Vectorise.hs compiler/cmm/CmmParse.hs:30:7: Could not find module `MachOp': it is a member of the hidden package `ghc-6.10.3' Use -v to see a list of the files searched for. make[1]: *** [compiler/stage1/build/.depend-v] Error 1 make[1]: *** Deleting file `compiler/stage1/build/.depend-v' make: *** [all] Error 2 }}} {{{ [glastonbury:~/Projects/GHC/ghc]$ uname -a Linux glastonbury 2.6.28-13-generic #44-Ubuntu SMP Tue Jun 2 07:55:09 UTC 2009 x86_64 GNU/Linux [glastonbury:~/Projects/GHC/ghc]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.3 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 04:04:47 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 03:47:03 2009 Subject: [GHC] #2197: GHCi doesn't work when built with way=p In-Reply-To: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> References: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> Message-ID: <052.a272443f031710e4644d0664faa494f6@localhost> #2197: GHCi doesn't work when built with way=p ---------------------------------+------------------------------------------ Reporter: SamB | Owner: simonmar Type: bug | Status: closed Priority: low | Milestone: 6.12 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:12 SamB]: > Does this also work for Template Haskell? Even from Haddock? No, TH also doesn't work when GHC is built with -prof. I'll check what happens and make it emit an error message. > What if I *want* GHCi to support profiling? There's a fair bit of work to do, and it's not clear it's worth the effort. The byte code compiler and interpreter have to be modified to support the different closure representations and other conventions of the profiling build. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 04:21:16 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 04:03:36 2009 Subject: [GHC] #3344: request earlier and more perspicuous detection of tab characters in compiler/ghc.cabal.in In-Reply-To: <041.a1b1d435c26ca8460ae95266297368fa@localhost> References: <041.a1b1d435c26ca8460ae95266297368fa@localhost> Message-ID: <050.4cdc1952dc5d0c794429b48424e8d284@localhost> #3344: request earlier and more perspicuous detection of tab characters in compiler/ghc.cabal.in ---------------------------------+------------------------------------------ Reporter: nr | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 04:23:26 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 04:12:04 2009 Subject: [GHC] #926: infinite loop in ShutdownIOManager() In-Reply-To: <044.c76e7ce68daae6830ea4c0eae2d0eb8f@localhost> References: <044.c76e7ce68daae6830ea4c0eae2d0eb8f@localhost> Message-ID: <053.e6e7ebbc6691e2d16b6090058366ef95@localhost> #926: infinite loop in ShutdownIOManager() -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Runtime System | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: simonmar => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 04:50:20 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 04:32:38 2009 Subject: [GHC] #3344: request earlier and more perspicuous detection of tab characters in compiler/ghc.cabal.in In-Reply-To: <041.a1b1d435c26ca8460ae95266297368fa@localhost> References: <041.a1b1d435c26ca8460ae95266297368fa@localhost> Message-ID: <050.12e650b2c214eebd2d38391ba469e8bb@localhost> #3344: request earlier and more perspicuous detection of tab characters in compiler/ghc.cabal.in ---------------------------------+------------------------------------------ Reporter: nr | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Done {{{ Tue Jul 7 09:18:45 BST 2009 Simon Marlow * check for tabs in compiler/ghc.cabal.in (#3344) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 04:53:35 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 04:35:51 2009 Subject: [GHC] #3263: Warnings for monadic values not used In-Reply-To: <051.2ba77802c306560898b377ae21be4ade@localhost> References: <051.2ba77802c306560898b377ae21be4ade@localhost> Message-ID: <060.b2b747fcf50b0551d4bb1bc158f9e861@localhost> #3263: Warnings for monadic values not used ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): I've fixed the GHC.IO.Encoding modules. {{{ Mon Jul 6 14:33:03 BST 2009 Simon Marlow * Use the result of writeCharBuf }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 05:08:52 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 04:51:15 2009 Subject: [GHC] #2253: Native code generator could do better In-Reply-To: <043.862f2d1bf55b0e0d2dddbf6af3659352@localhost> References: <043.862f2d1bf55b0e0d2dddbf6af3659352@localhost> Message-ID: <052.8646ac927fdb01372aba436edd7278fa@localhost> #2253: Native code generator could do better -----------------------------------------+---------------------------------- Reporter: dons | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (NCG) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by simonmar): The main problem here is those extra reg->reg moves between argument registers (e.g. %rsi) and temporary registers (e.g. %rax). One way to fix it is to make cmmMiniInline a little smarter, by substituting for assignments of temporaries from global regs. The new register allocator might also do better. However, the new backend will solve this in a much better way, by having liveness information about global registers. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 05:21:12 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 05:03:30 2009 Subject: [GHC] #3357: ghc panic In-Reply-To: <050.7b7e81294b3928dd895b8511a4ac3a2f@localhost> References: <050.7b7e81294b3928dd895b8511a4ac3a2f@localhost> Message-ID: <059.51cb1f0a156b9d293d66ecb9a29037b9@localhost> #3357: ghc panic ---------------------------------+------------------------------------------ Reporter: kimwallmark | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report. This is a duplicate of #789 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 05:21:29 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 05:03:45 2009 Subject: [GHC] #789: BCOs can only have 64k instructions: linkBCO: >= 64k insns in BCO In-Reply-To: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> References: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> Message-ID: <055.901e114cce9acfcb6a781e1a2c311a22@localhost> #789: BCOs can only have 64k instructions: linkBCO: >= 64k insns in BCO ------------------------+--------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: BCO | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------+--------------------------------------------------- Comment (by simonmar): See also #3357 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 05:22:02 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 05:04:17 2009 Subject: [GHC] #789: BCOs can only have 64k instructions: linkBCO: >= 64k insns in BCO In-Reply-To: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> References: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> Message-ID: <055.137a41f052ae77cca01ee5a8444b8f38@localhost> #789: BCOs can only have 64k instructions: linkBCO: >= 64k insns in BCO ------------------------+--------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: BCO | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------+--------------------------------------------------- Changes (by simonmar): * priority: normal => high Comment: people bump into this quite often, let's up the priority -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 05:56:58 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 05:39:16 2009 Subject: [GHC] #3228: please make it easier to remove a file from the GHC sources In-Reply-To: <041.5dbccaa2009317c73dad3a60d2601df8@localhost> References: <041.5dbccaa2009317c73dad3a60d2601df8@localhost> Message-ID: <050.51088edc0bba05a91e0fb1bce702cc8c@localhost> #3228: please make it easier to remove a file from the GHC sources --------------------------------+------------------------------------------- Reporter: nr | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | --------------------------------+------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: I'm claiming I've now fulfilled this request. {{{ Tue Jul 7 09:50:40 BST 2009 Simon Marlow * Avoid unnecessary recompilation after ./configure (helps #3228) }}} So to remove a file from GHC, you * edit `compiler/ghc.cabal.in` * `sh config.status` * `cd compiler; make 1` and it might re-configure GHC, but it shouldn't do too much extraneous stuff. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 11:57:37 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 11:39:53 2009 Subject: [GHC] #3360: Add profiling support to GHCi Message-ID: <043.11a45369957037aa40d80793cfeb6f91@localhost> #3360: Add profiling support to GHCi -----------------------------+---------------------------------------------- Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- It would be nice if GHCi could be run with profiling on. In [comment:#2197:13 comment 13] of ticket #2197, simonmar said: > There's a fair bit of work to do, and it's not clear it's worth the effort. The byte code compiler and interpreter have to be modified to support the different closure representations and other conventions of the profiling build. This would, of course, also allow profiling of GHC or Haddock dealing with Template Haskell code, as well as any ghc-api clients that somehow end up invoking the bytecode interpreter. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 11:59:46 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 11:42:05 2009 Subject: [GHC] #2197: GHCi doesn't work when built with way=p In-Reply-To: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> References: <043.8ca8ccba553cfe5b0f79906ba5d25b8c@localhost> Message-ID: <052.5137348fd850acd1894a6a9aa87ae203@localhost> #2197: GHCi doesn't work when built with way=p ---------------------------------+------------------------------------------ Reporter: SamB | Owner: simonmar Type: bug | Status: closed Priority: low | Milestone: 6.12 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by SamB): Replying to [comment:13 simonmar]: > Replying to [comment:12 SamB]: > > Does this also work for Template Haskell? Even from Haddock? > > No, TH also doesn't work when GHC is built with -prof. I'll check what happens and make it emit an error message. Yeah, that's what I meant. Hmm. And aren't there probably some other way to invoke the bytecode interpreter from the GHC API? It might be nice if all such ways would give the same exception... > > What if I *want* GHCi to support profiling? > > There's a fair bit of work to do, and it's not clear it's worth the effort. The byte code compiler and interpreter have to be modified to support the different closure representations and other conventions of the profiling build. Hmm. I was expecting something more along the lines of "so make another ticket", which I've now done: see ticket #3360. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 16:43:42 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 16:25:55 2009 Subject: [GHC] #3361: impossible happened Message-ID: <045.ebe099cd458dcabbf899a0b1bc958642@localhost> #3361: impossible happened -------------------+-------------------------------------------------------- Reporter: temoto | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- Reloading xmonad configuration i get ugly X window with this text: Error detected while loading xmonad configuration file: /home/temoto/.xmonad/xmonad.hs on the commandline: Warning: -no-recomp is deprecated: Use -fforce-recomp instead Binary: Int64 truncated to fit in 32 bit Int ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-unknown-linux): Prelude.chr: bad argument Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Please check the file for errors. Running 32bit Ubuntu Karmic on custom 64bit capable kernel. The error is 100% reproducable, in fact i get it on every xmonad config reload. I can send any additional information, if that helps. The error started to appear after i upgraded Ubuntu jaunty to unstable karmic (so really lots of packages changed, i can't trace point of failure more precisely). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 7 23:29:49 2009 From: trac at galois.com (GHC) Date: Tue Jul 7 23:12:02 2009 Subject: [GHC] #3362: Adding a newtype EndoCategory to Control.Category Message-ID: <041.a309c46198949df45199b585afafe754@localhost> #3362: Adding a newtype EndoCategory to Control.Category -----------------------------+---------------------------------------------- Reporter: r6 | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I suggest adding a wrapper to make {{{(a x x)}}} a {{{Monoid}}} for any {{{Category}}} {{{a}}} and type {{{x}}}. This would be added to {{{Control.Category}}}. {{{ newtype EndoCategory a x = EndoCategory { runEndoCategory :: a x x } instance (Category a) => Monoid (EndoCategory a x) where mempty = EndoCategory id mappend (EndoCategory f) (EndoCategory g) = EndoCategory (f . g) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 8 06:07:38 2009 From: trac at galois.com (GHC) Date: Wed Jul 8 05:49:49 2009 Subject: [GHC] #3304: define gcd 0 0 = 0 In-Reply-To: <045.185c8414dc74a05b9b8c81a6506a335e@localhost> References: <045.185c8414dc74a05b9b8c81a6506a335e@localhost> Message-ID: <054.7aaf10a9a4e1f706dbccc8f1c4c8fb4e@localhost> #3304: define gcd 0 0 = 0 ------------------------------+--------------------------------------------- Reporter: stevec | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by guest): There was a discussion about that issue years ago: http://www.haskell.org/pipermail/haskell/2001-December/008609.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 8 11:00:04 2009 From: trac at galois.com (GHC) Date: Wed Jul 8 10:42:22 2009 Subject: [GHC] #2677: Detection of TF instance conflict depends on instance order In-Reply-To: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> References: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> Message-ID: <055.02ad6480a02acae44e9c117d4c6b0c6a@localhost> #2677: Detection of TF instance conflict depends on instance order ----------------------------------------+----------------------------------- Reporter: reinerp | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.10.3 Severity: critical | Resolution: fixed Keywords: TF instance conflict | Difficulty: Unknown Testcase: T2677 | Os: Linux Architecture: x86_64 (amd64) | ----------------------------------------+----------------------------------- Changes (by dorchard): * version: 6.9 => 6.10.3 * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86_64 (amd64) * severity: normal => critical Comment: Just discovered this bug today but glad to see it has already been picked up. The bug applies to data families too. You can do some pretty whacked out stuff with this bug, like launching missiles ;) {{{ {-# LANGUAGE TypeFamilies #-} -- MkFoo is a constructor on pure functions thereore "safe" :) data family Foo a data instance Foo a = MkFoo (Int -> Int) unBox :: Foo a -> (Int -> Int) unBox (MkFoo x) = x -- Nasty person adds this code in a module launchMissiles :: IO () launchMissiles = print ("Launching missiles...") data instance Foo Int = MakeLauncher (IO()) launch = (unBox (MakeLauncher launchMissiles)) 42 }}} launch segfaults, but about 1 in 3 times (depending on the memory layout) the missiles are launched! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 8 11:00:42 2009 From: trac at galois.com (GHC) Date: Wed Jul 8 10:42:57 2009 Subject: [GHC] #2677: Detection of TF instance conflict depends on instance order In-Reply-To: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> References: <046.85ed4c204d40e74117cf277dea4c07f0@localhost> Message-ID: <055.a537a7ecef171af41052ec400bb48a90@localhost> #2677: Detection of TF instance conflict depends on instance order ----------------------------------------+----------------------------------- Reporter: reinerp | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: TF instance conflict | Difficulty: Unknown Testcase: T2677 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by dorchard): * version: 6.10.3 => 6.9 * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple * severity: critical => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 8 14:01:05 2009 From: trac at galois.com (GHC) Date: Wed Jul 8 13:43:17 2009 Subject: [GHC] #3362: Adding a newtype EndoCategory to Control.Category In-Reply-To: <041.a309c46198949df45199b585afafe754@localhost> References: <041.a309c46198949df45199b585afafe754@localhost> Message-ID: <050.576d1632757e7a6f16554f1240df64f7@localhost> #3362: Adding a newtype EndoCategory to Control.Category ------------------------------+--------------------------------------------- Reporter: r6 | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by r6): class Monad m where[[BR]]return and Kleisli compose[[BR]]must form a monoid by lilac -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 8 14:46:00 2009 From: trac at galois.com (GHC) Date: Wed Jul 8 14:28:36 2009 Subject: [GHC] #3301: Update Haskeline In-Reply-To: <042.39eb2fb65f452fed35078da0d81f6675@localhost> References: <042.39eb2fb65f452fed35078da0d81f6675@localhost> Message-ID: <051.e938b5acbe9ad1e99b45b4f7c9af2f49@localhost> #3301: Update Haskeline ---------------------------------+------------------------------------------ Reporter: cjs | Owner: Type: merge | Status: reopened Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.10.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by JSchmitt): * status: closed => reopened * resolution: fixed => Comment: I'm the maintainer of kaya and have to complaint, that the build of this package failes, after you have removed System.Console.Editline.Readline in ghc-6.10.3. This is very bad, because the fedora maintainer has push 6.10.3 as an minor update to F-11 and F-10. In the Fedora project i have opened the following bug for this issue: https://bugzilla.redhat.com/show_bug.cgi?id=508729 So I want to request, that you may reintegrate System.Console.Editline.Readline on ghc. Best Regards: Jochen Schmitt -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 9 11:41:30 2009 From: trac at galois.com (GHC) Date: Thu Jul 9 11:24:13 2009 Subject: [GHC] #1817: Should be possible to specify pragmas with mixed case In-Reply-To: <044.c4095d9e6406b41062c64e87c778bda3@localhost> References: <044.c4095d9e6406b41062c64e87c778bda3@localhost> Message-ID: <053.f65febadc62237ce0b986bcddae7fea7@localhost> #1817: Should be possible to specify pragmas with mixed case ----------------------------------+----------------------------------------- Reporter: igloo | Owner: squadette Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Parser) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * milestone: 6.12 branch => 6.12.1 Comment: Thanks for the patch! I've applied it. Leaving the ticket open as LINE isn't done yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 9 13:06:11 2009 From: trac at galois.com (GHC) Date: Thu Jul 9 12:48:20 2009 Subject: [GHC] #3361: GHC panic with 64 bit kernel: Int64 truncated to fit in 32 bit Int In-Reply-To: <045.ebe099cd458dcabbf899a0b1bc958642@localhost> References: <045.ebe099cd458dcabbf899a0b1bc958642@localhost> Message-ID: <054.12028c45082f5bc6fb69e42c875afdcb@localhost> #3361: GHC panic with 64 bit kernel: Int64 truncated to fit in 32 bit Int ----------------------+----------------------------------------------------- Reporter: temoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 ----------------------+----------------------------------------------------- Changes (by dons): * summary: impossible happened => GHC panic with 64 bit kernel: Int64 truncated to fit in 32 bit Int Comment: Can you please rebuild xmonad and xmonad-contrib from scratch, from source? The most likely cause is some API incompatibility due to partial rebuilds (or separate builds). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 9 15:53:56 2009 From: trac at galois.com (GHC) Date: Thu Jul 9 15:36:05 2009 Subject: [GHC] #1817: Should be possible to specify pragmas with mixed case In-Reply-To: <044.c4095d9e6406b41062c64e87c778bda3@localhost> References: <044.c4095d9e6406b41062c64e87c778bda3@localhost> Message-ID: <053.4bd5f222148ada828edc1087ea2c4b1b@localhost> #1817: Should be possible to specify pragmas with mixed case ----------------------------------+----------------------------------------- Reporter: igloo | Owner: squadette Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Parser) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by squadette): roll back the previous patch, and apply the following: http://github.com/squadette/ghc/commit/5d88b71ccd31fc7f4d2f2e750fa1192dd850babf.patch It passes ghc stage1/2 build and testsuite w/o any regression. Thank you, -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 9 17:14:18 2009 From: trac at galois.com (GHC) Date: Thu Jul 9 16:56:27 2009 Subject: [GHC] #3361: GHC panic with 64 bit kernel: Int64 truncated to fit in 32 bit Int In-Reply-To: <045.ebe099cd458dcabbf899a0b1bc958642@localhost> References: <045.ebe099cd458dcabbf899a0b1bc958642@localhost> Message-ID: <054.390ff6574417a24bc8923283a116f310@localhost> #3361: GHC panic with 64 bit kernel: Int64 truncated to fit in 32 bit Int ----------------------+----------------------------------------------------- Reporter: temoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by temoto): Thank you. I reinstalled xmonad-contrib from ubuntu packages with purge and it works now. I don't know how to better close the ticket, is it invalid or wontfix or something else, so please, close it as you think better. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 9 23:30:41 2009 From: trac at galois.com (GHC) Date: Thu Jul 9 23:12:48 2009 Subject: [GHC] #3363: ghc: panic installing darcs-beta Message-ID: <045.de12ed84c007a250d14e3f99a59f31ef@localhost> #3363: ghc: panic installing darcs-beta --------------------+------------------------------------------------------- Reporter: dimavs | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- I've just tried to install darcs using ''cabal install darcs-beta'', and somewhere in the middle I've got {{{ [ 57 of 136] Compiling Darcs.Repository.Prefs ( src/Darcs/Repository/Prefs.lhs, dist/build/Darcs/Repository/Prefs.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-apple-darwin): cat_evals base:GHC.Arr.Array{d ras} [ww{v a305N} [lid], ww1{v a305O} [lid], ww2{v a305P} [lid]] [!, !, _, _] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: darcs-beta-2.2.98.2 failed during the building phase. The exception was: exit: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 10 03:03:55 2009 From: trac at galois.com (GHC) Date: Fri Jul 10 02:46:12 2009 Subject: [GHC] #2203: TFs in class instances heads In-Reply-To: <043.d54d86ddec760e3a2475c6e848a97d7e@localhost> References: <043.d54d86ddec760e3a2475c6e848a97d7e@localhost> Message-ID: <052.d89f3f43991cf7c659bf994f35ab27ed@localhost> #2203: TFs in class instances heads ----------------------------------------+----------------------------------- Reporter: chak | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2203a & T2203b | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by chak): * testcase: T2203a => T2203a & T2203b * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 10 04:17:18 2009 From: trac at galois.com (GHC) Date: Fri Jul 10 04:00:05 2009 Subject: [GHC] #3339: Data.Monoid: Add (+>) as a synonym for mappend In-Reply-To: <042.626638ce45ff16ad4ce623d16cab0138@localhost> References: <042.626638ce45ff16ad4ce623d16cab0138@localhost> Message-ID: <051.873e962e89c736e439c6191ec48e09f2@localhost> #3339: Data.Monoid: Add (+>) as a synonym for mappend ------------------------------+--------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by jeltsch): I agree. Since {{{(++)}}} is {{{mappend}}} for a specific type, it makes much sense to just generalize {{{(++)}}} to work with arbitrary {{{Monoid}}} instances. There is also a poll about this topic which has a strong bias to making {{{(++)}}} the new {{{mappend}}}: http://doodle.com/4yrfd7qaw5man3rm. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 10 05:06:55 2009 From: trac at galois.com (GHC) Date: Fri Jul 10 04:49:39 2009 Subject: [GHC] #3339: Data.Monoid: Add (+>) as a synonym for mappend In-Reply-To: <042.626638ce45ff16ad4ce623d16cab0138@localhost> References: <042.626638ce45ff16ad4ce623d16cab0138@localhost> Message-ID: <051.4dbaa66b1f4d31442d0aabd4caba03ac@localhost> #3339: Data.Monoid: Add (+>) as a synonym for mappend ------------------------------+--------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by JulesBean): Technical decisions are not best made by democracy. A poll is not interesting. What is interesting is arguments of substance. (++) is a sensible choice but has backward-compatibility problems, and "confusing newbies with weird error messages" problems. It is only for those reasons that I didn't choose it. If we're choosing something new, then +> has the advantage of being visually flippable, but <> has the advantage of being already used in (at least) two other monoids. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 10 08:39:31 2009 From: trac at galois.com (GHC) Date: Fri Jul 10 08:21:40 2009 Subject: [GHC] #3361: GHC panic with 64 bit kernel: Int64 truncated to fit in 32 bit Int In-Reply-To: <045.ebe099cd458dcabbf899a0b1bc958642@localhost> References: <045.ebe099cd458dcabbf899a0b1bc958642@localhost> Message-ID: <054.06069a1b4f879bdc7c175d429930b899@localhost> #3361: GHC panic with 64 bit kernel: Int64 truncated to fit in 32 bit Int -------------------------+-------------------------------------------------- Reporter: temoto | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: closing as requested. If you think this is something we could have / should have detected in GHC, then please re-open. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 10 08:41:56 2009 From: trac at galois.com (GHC) Date: Fri Jul 10 08:24:02 2009 Subject: [GHC] #3363: ghc: panic installing darcs-beta In-Reply-To: <045.de12ed84c007a250d14e3f99a59f31ef@localhost> References: <045.de12ed84c007a250d14e3f99a59f31ef@localhost> Message-ID: <054.3cb674ebb6e8be0be0076347c78d9b89@localhost> #3363: ghc: panic installing darcs-beta -------------------------+-------------------------------------------------- Reporter: dimavs | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Thanks for the report. This is a bug in the Haskell Platform package for OS X, see [http://trac.haskell.org/haskell-platform/ticket/71]. Also reported (and closed) in GHC as #3275. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 10 09:19:15 2009 From: trac at galois.com (GHC) Date: Fri Jul 10 09:01:24 2009 Subject: [GHC] #3364: calling "ghc -H" panics Message-ID: <044.8f3c1ce38e708cbdf5f93b63ad116141@localhost> #3364: calling "ghc -H" panics -------------------+-------------------------------------------------------- Reporter: baldo | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- Calling with only the argument "`-H`" GHC panics: {{{ # ghci -H ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-unknown-linux): ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-unknown-linux): Static flags have not been initialised! Please call GHC.newSession or GHC.parseStaticFlags early enough. Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Same for `ghci -H`. The version I'm using is GHC 6.10.3-1 from Arch Linux's repository. Details about how ghc has been build can be found on http://repos.archlinux.org/viewvc.cgi/ghc/repos/extra-i686/?pathrev=38707 Hope this helps. ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 03:55:06 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 03:37:09 2009 Subject: [GHC] #3365: Bug in GHCi, 'impossible' happened Message-ID: <044.7aa62f471000d52a3544653877a3da16@localhost> #3365: Bug in GHCi, 'impossible' happened -------------------+-------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- I have just created file with following contents: {{{ import List; l = sort ["MARY","PATRICIA", ...] }}} I have got this list from http://projecteuler.net/project/names.txt. Then i saved this code into the file "22.hs" and started it with "ghci 22.hs" command. Then i got the following output: {{{ GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( 22.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for x86_64-unknown-linux): linkBCO: >= 64k insns in BCO Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > Leaving GHCi. }}} I am running Arch Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 03:55:12 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 03:37:16 2009 Subject: [GHC] #3366: Bug in GHCi, 'impossible' happened Message-ID: <044.56bbdffb14e50b5ed2aa9bcdc3a50d22@localhost> #3366: Bug in GHCi, 'impossible' happened -------------------+-------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- I have just created file with following contents: {{{ import List; l = sort ["MARY","PATRICIA", ...] }}} I have got this list from http://projecteuler.net/project/names.txt. Then i saved this code into the file "22.hs" and started it with "ghci 22.hs" command. Then i got the following output: {{{ GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( 22.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for x86_64-unknown-linux): linkBCO: >= 64k insns in BCO Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > Leaving GHCi. }}} I am running Arch Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 07:14:19 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 06:56:34 2009 Subject: [GHC] #3367: syntax error in LANGUAGE pragma -- getOptions'.parseLanguage(1) went past eof token Message-ID: <051.0cdd30836d17edc62782e22533c0498b@localhost> #3367: syntax error in LANGUAGE pragma -- getOptions'.parseLanguage(1) went past eof token -------------------------+-------------------------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------------+-------------------------------------------------- the following program is sufficient to produce this error: {-# LANGUAGE MultiParamTypeClasses -} module GZsvn.WDIRops (WDIR (..)) where the culprit is the missing # at the end of the prama. message: ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-unknown-linux): getOptions'.parseLanguage(1) went past eof token i could not find the same error already reported, but other problems with LANGUAGE pragma syntax. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 08:27:04 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 08:09:08 2009 Subject: [GHC] #3348: crash in gc with > 2 generations In-Reply-To: <051.280ba552da1632e68cecc9754593cebf@localhost> References: <051.280ba552da1632e68cecc9754593cebf@localhost> Message-ID: <060.9bfd4703e56a98802178e733950cfc69@localhost> #3348: crash in gc with > 2 generations -------------------------------+-------------------------------------------- Reporter: dynamic-wind | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.4 Component: Runtime System | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 09:14:04 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 08:56:06 2009 Subject: [GHC] #3368: Deriving Foldable doesn't work Message-ID: <043.07fd00804268a4211b859ee0eb6e08cb@localhost> #3368: Deriving Foldable doesn't work -----------------------------+---------------------------------------------- Reporter: cmcq | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I was trying out the Foldable deriving in GHC HEAD (see ticket #2953). fold gave a stack space overflow. -ddump-deriv shows that the wrong foldr is being used: {{{ { GHC.Base.foldr f_aat z_aav (Main.Nil) = z_aav, }}} This is easy to fix but isn't it strange that there's no compile error? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 12:04:44 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 11:46:48 2009 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@localhost> References: <045.426dc6319f98492c5b511466045bc0b5@localhost> Message-ID: <054.29984617ff71fca96143343749b5ff72@localhost> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) -----------------------+---------------------------------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: GHCi | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by meteficha): * status: closed => reopened * resolution: invalid => Comment: Hello, igloo! I'm Hipmunk's maintainer and it has been almost two months since you've closed this bug saying that this is a bug in Hipmunk but not saying what should be done on Hipmunk's side. I'm reopening it because I too believe that this is a bug on GHCi's side. I'll be happy to "fix" Hipmunk if you say how to do so, though. Thanks, Felipe. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 12:07:30 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 11:49:32 2009 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@localhost> References: <045.426dc6319f98492c5b511466045bc0b5@localhost> Message-ID: <054.61bdefcc5589e4935a4d007750233829@localhost> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) -----------------------+---------------------------------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: GHCi | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by meteficha): * cc: felipe.lessa@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 12:22:07 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 12:04:22 2009 Subject: [GHC] #3367: syntax error in LANGUAGE pragma -- getOptions'.parseLanguage(1) went past eof token In-Reply-To: <051.0cdd30836d17edc62782e22533c0498b@localhost> References: <051.0cdd30836d17edc62782e22533c0498b@localhost> Message-ID: <060.9128eb418668ad70767ea4f0eaaa9fc8@localhost> #3367: syntax error in LANGUAGE pragma -- getOptions'.parseLanguage(1) went past eof token ---------------------------------+------------------------------------------ Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Old description: > the following program is sufficient to produce this error: > > {-# LANGUAGE MultiParamTypeClasses -} > > module GZsvn.WDIRops (WDIR (..)) > where > > the culprit is the missing # at the end of the prama. > > message: > > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.3 for i386-unknown-linux): > getOptions'.parseLanguage(1) went past eof token > > i could not find the same error already reported, but other problems with > LANGUAGE pragma syntax. New description: the following program is sufficient to produce this error: {{{ {-# LANGUAGE MultiParamTypeClasses -} module GZsvn.WDIRops (WDIR (..)) where }}} the culprit is the missing # at the end of the prama. message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-unknown-linux): getOptions'.parseLanguage(1) went past eof token }}} i could not find the same error already reported, but other problems with LANGUAGE pragma syntax. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 12:23:17 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 12:05:27 2009 Subject: [GHC] #3367: syntax error in LANGUAGE pragma -- getOptions'.parseLanguage(1) went past eof token In-Reply-To: <051.0cdd30836d17edc62782e22533c0498b@localhost> References: <051.0cdd30836d17edc62782e22533c0498b@localhost> Message-ID: <060.b126bf930442bc29aa3b1414126fa5f0@localhost> #3367: syntax error in LANGUAGE pragma -- getOptions'.parseLanguage(1) went past eof token ---------------------------------+------------------------------------------ Reporter: andrewufrank | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for the report. Happily, the fix for the other recently-reported bugs in the HEAD (which will be 6.12) has also fixed this case: {{{ q.hs:1:14: cannot parse LANGUAGE pragma: comma-separated list expected }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 12:24:12 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 12:06:13 2009 Subject: [GHC] #3366: Bug in GHCi, 'impossible' happened In-Reply-To: <044.56bbdffb14e50b5ed2aa9bcdc3a50d22@localhost> References: <044.56bbdffb14e50b5ed2aa9bcdc3a50d22@localhost> Message-ID: <053.2b9087d03aa3bf9830e7d574b4771dc4@localhost> #3366: Bug in GHCi, 'impossible' happened -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Duplicate of #3365. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 12:25:18 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 12:07:20 2009 Subject: [GHC] #789: BCOs can only have 64k instructions: linkBCO: >= 64k insns in BCO In-Reply-To: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> References: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> Message-ID: <055.effbfcee325a2eca5d9cb25b9c0493e3@localhost> #789: BCOs can only have 64k instructions: linkBCO: >= 64k insns in BCO ------------------------+--------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: BCO | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------+--------------------------------------------------- Comment (by igloo): See also #3365. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 12:25:44 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 12:07:47 2009 Subject: [GHC] #3365: Bug in GHCi, 'impossible' happened In-Reply-To: <044.7aa62f471000d52a3544653877a3da16@localhost> References: <044.7aa62f471000d52a3544653877a3da16@localhost> Message-ID: <053.4528e5ce3ff5c973875c27bf5efc5d6d@localhost> #3365: Bug in GHCi, 'impossible' happened -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report. This is a duplicate of #789. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 14:04:27 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 13:46:57 2009 Subject: [GHC] #3301: Update Haskeline In-Reply-To: <042.39eb2fb65f452fed35078da0d81f6675@localhost> References: <042.39eb2fb65f452fed35078da0d81f6675@localhost> Message-ID: <051.1781e9c0dba8450b146c5647301140f0@localhost> #3301: Update Haskeline ---------------------------------+------------------------------------------ Reporter: cjs | Owner: Type: merge | Status: closed Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.10.3 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: reopened => closed * resolution: => fixed Comment: The Fedora kaya package will need to depend on a Fedora Haskell editline or readline package. I don't know if either of those are packaged for Fedora yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 14:14:16 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 13:56:17 2009 Subject: [GHC] #3312: no darcs and no VERSION file In-Reply-To: <044.8bacdee4fc43cf8a128dd2de27730115@localhost> References: <044.8bacdee4fc43cf8a128dd2de27730115@localhost> Message-ID: <053.a67c7380cdbedcb7acfe4f8c909774ed@localhost> #3312: no darcs and no VERSION file ---------------------------------+------------------------------------------ Reporter: zooko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: I believe that zooko is unstuck now that source dists are working again. I think it's reasonable that darcs checkouts can assume that darcs exists, so I'll close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 14:28:24 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 14:10:33 2009 Subject: [GHC] #1074: -fwarn-unused-imports complains about wrong import In-Reply-To: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> References: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> Message-ID: <053.de5fe80138dabfbde97c53d61a37eed4@localhost> #1074: -fwarn-unused-imports complains about wrong import ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.6 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Mon Jul 6 12:25:03 BST 2009 simonpj@microsoft.com * Major patch to fix reporting of unused imports }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 14:32:11 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 14:14:17 2009 Subject: [GHC] #1148: Bad warnings about unused imports that are in fact needed In-Reply-To: <045.bee1b922a3147d2353135cd2446dcba2@localhost> References: <045.bee1b922a3147d2353135cd2446dcba2@localhost> Message-ID: <054.904682af716c25ff2e2abbb514a46c39@localhost> #1148: Bad warnings about unused imports that are in fact needed --------------------------------------+------------------------------------- Reporter: brianh | Owner: Type: bug | Status: closed Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: fixed Keywords: warning unused import | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | --------------------------------------+------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by: {{{ Mon Jul 6 12:25:03 BST 2009 simonpj@microsoft.com * Major patch to fix reporting of unused imports }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 14:35:46 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 14:17:49 2009 Subject: [GHC] #2267: Bogus "unused import" warning In-Reply-To: <046.30ab0572d75eae6eab884580b0a1c4cf@localhost> References: <046.30ab0572d75eae6eab884580b0a1c4cf@localhost> Message-ID: <055.eeab25212d6783494453c24a443adc30@localhost> #2267: Bogus "unused import" warning ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by: {{{ Mon Jul 6 12:25:03 BST 2009 simonpj@microsoft.com * Major patch to fix reporting of unused imports }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 15:03:02 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 14:45:04 2009 Subject: [GHC] #1792: -ddump-minimal-imports breaks qualified imports (import...as) In-Reply-To: <044.ae2e6ac08c5448ff46a1de0b12b1fa4a@localhost> References: <044.ae2e6ac08c5448ff46a1de0b12b1fa4a@localhost> Message-ID: <053.613a21129c83c499001c7b13f8304960@localhost> #1792: -ddump-minimal-imports breaks qualified imports (import...as) ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.12 branch Component: Compiler | Version: 6.6.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T1792_imports | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * testcase: => T1792_imports * status: new => closed * resolution: => fixed Comment: Fixed by: {{{ Mon Jul 6 12:25:03 BST 2009 simonpj@microsoft.com * Major patch to fix reporting of unused imports }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 16:20:58 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 16:03:00 2009 Subject: [GHC] #3359: Build failed: "Could not find module `MachOp'" on 64bit Linux w/ GHC 6.10.3 In-Reply-To: <053.73eaad444842b7192c2c7e2a94f9bfa5@localhost> References: <053.73eaad444842b7192c2c7e2a94f9bfa5@localhost> Message-ID: <062.53df70dba84790fcbf50803d5e827d72@localhost> #3359: Build failed: "Could not find module `MachOp'" on 64bit Linux w/ GHC 6.10.3 ----------------------------+----------------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------------+----------------------------------------------- Comment (by Ashley Yakeley): It looks like CmmParse.hs is not being cleaned, and not being rebuilt from CmmParse.y. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 17:04:56 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 16:46:57 2009 Subject: [GHC] #3359: Build failed: "Could not find module `MachOp'" on 64bit Linux w/ GHC 6.10.3 In-Reply-To: <053.73eaad444842b7192c2c7e2a94f9bfa5@localhost> References: <053.73eaad444842b7192c2c7e2a94f9bfa5@localhost> Message-ID: <062.fdb93e13c840b4c5b0b65a60c12a9de5@localhost> #3359: Build failed: "Could not find module `MachOp'" on 64bit Linux w/ GHC 6.10.3 ----------------------------+----------------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------------+----------------------------------------------- Comment (by Ashley Yakeley): Actually, it looks like leftover files. This could be helped by cleaning up .darcs-boring. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 17:08:40 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 16:50:42 2009 Subject: [GHC] #3369: Deadlock sending stdin to a process which does not read it Message-ID: <047.ae0eafc4c75d0c813ff01c481cb76a53@localhost> #3369: Deadlock sending stdin to a process which does not read it ---------------------+------------------------------------------------------ Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Component: libraries/process Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple ---------------------+------------------------------------------------------ This code writes some standard input to a command and collects the output: (ih,oh,eh,ph) ? runInteractiveCommand cmd forkIO $ hPutStr ih i' -- separate thread in case cmd does not read stdin out ? hGetContents oh err ? hGetContents eh exit ? waitForProcess ph But if cmd does not read from stdin, using ghc 6.10.3 or 6.8.2 on a mac (with or without -threaded), it seems to hang at waitForProcess. (I tried to work around this by adding forkIO at Heffalump's suggestion, but no difference. With ghc 6.10.3 on a gnu/linux machine, it works as intended. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 17:24:34 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 17:06:36 2009 Subject: [GHC] #3369: Deadlock sending stdin to a process which does not read it In-Reply-To: <047.ae0eafc4c75d0c813ff01c481cb76a53@localhost> References: <047.ae0eafc4c75d0c813ff01c481cb76a53@localhost> Message-ID: <056.6e5ab07ba2a5b3647d5d935b7aef579b@localhost> #3369: Deadlock sending stdin to a process which does not read it -------------------------------+-------------------------------------------- Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by simonmic): {{{ (ih,oh,eh,ph) ? runInteractiveCommand cmd forkIO $ hPutStr ih i' -- separate thread in case cmd does not read stdin out ? hGetContents oh err ? hGetContents eh exit ? waitForProcess ph }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 17:49:02 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 17:31:03 2009 Subject: [GHC] #3370: Put DiffArray in its own diffarray package Message-ID: <044.358443d8c33e79bf89bf7ebfe52581be@localhost> #3370: Put DiffArray in its own diffarray package --------------------------------+------------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: new Priority: normal | Milestone: _|_ Component: libraries (other) | Version: 6.10.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------+------------------------------------------- !DiffArray currently has serious performance problems (see #2727), and is not currently being actively maintained. However, as part of the corelib `array` it gives the impression that it is a "blessed" library. I propose that we split !DiffArray off into its own `diffarray` package. This also has the advantage that it can then be maintained by a separate maintainer, if someone is interested, and it will be decoupled from GHC's major release schedule. Deadline: 26 July (2 weeks). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 17:51:31 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 17:33:31 2009 Subject: [GHC] #3370: Put DiffArray in its own diffarray package In-Reply-To: <044.358443d8c33e79bf89bf7ebfe52581be@localhost> References: <044.358443d8c33e79bf89bf7ebfe52581be@localhost> Message-ID: <053.c3f5f6716d68625d23ea7afca37594a5@localhost> #3370: Put DiffArray in its own diffarray package ----------------------------------+----------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: new Priority: normal | Milestone: _|_ Component: libraries (other) | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by igloo): Mailing list thread starts here: http://www.haskell.org/pipermail/libraries/2009-July/012131.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 17:51:59 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 17:34:00 2009 Subject: [GHC] #2727: DiffArray performance unusable for advertized purpose In-Reply-To: <044.19ebac4c441c1f8e8ea00498a3c1e235@localhost> References: <044.19ebac4c441c1f8e8ea00498a3c1e235@localhost> Message-ID: <053.c4d3c96096d248d06e4901599927d7fe@localhost> #2727: DiffArray performance unusable for advertized purpose -----------------------------------------+---------------------------------- Reporter: claus | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by igloo): Proposal is #3370. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 18:04:14 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 17:46:17 2009 Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled? In-Reply-To: <047.c01de827ffb9a59aafb72de68ac54369@localhost> References: <047.c01de827ffb9a59aafb72de68ac54369@localhost> Message-ID: <056.d80e2823e7cf910bf003f253d347bea4@localhost> #2798: Enable "rec" keyword when RecursiveDo is enabled? ---------------------------------+------------------------------------------ Reporter: nominolo | Owner: Type: task | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Extensions can be marked deprecated in `xFlags` in `compiler/main/DynFlags.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 18:31:13 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 18:13:14 2009 Subject: [GHC] #3277: ghc-6.8.2: panic! (the 'impossible' happened) RnEnv.lookupImportedName In-Reply-To: <047.0eb0687378e057ea5b71774bbee9b502@localhost> References: <047.0eb0687378e057ea5b71774bbee9b502@localhost> Message-ID: <056.41c23bf94a30a8b76d3f41b1fda7df0c@localhost> #3277: ghc-6.8.2: panic! (the 'impossible' happened) RnEnv.lookupImportedName -------------------------+-------------------------------------------------- Reporter: newhoggy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Old description: > joky@joky-vm-ubuntu:~/svn-work/test-tools/haskell$ ./quick.lhs ghc-6.8.2: > panic! (the 'impossible' happened) > (GHC version 6.8.2 for i386-unknown-linux): > RnEnv.lookupImportedName AMP.secBoardId{v} > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: {{{ joky@joky-vm-ubuntu:~/svn-work/test-tools/haskell$ ./quick.lhs ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): RnEnv.lookupImportedName AMP.secBoardId{v} 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 Sat Jul 11 18:38:24 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 18:20:26 2009 Subject: [GHC] #3277: ghc-6.8.2: panic! (the 'impossible' happened) RnEnv.lookupImportedName In-Reply-To: <047.0eb0687378e057ea5b71774bbee9b502@localhost> References: <047.0eb0687378e057ea5b71774bbee9b502@localhost> Message-ID: <056.20a05a8b200f7f0add283b152be1978e@localhost> #3277: ghc-6.8.2: panic! (the 'impossible' happened) RnEnv.lookupImportedName -------------------------+-------------------------------------------------- Reporter: newhoggy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I'm afraid we are no longer porting fixes back to the 6.8 branch, no. Thanks for confirming that the bug is fixed in 6.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 19:06:41 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 18:48:45 2009 Subject: [GHC] #3260: Linking stage2 on PPC gives "scattered reloc r_address too large" In-Reply-To: <043.9087f80d620051a542dc03d51ff19b43@localhost> References: <043.9087f80d620051a542dc03d51ff19b43@localhost> Message-ID: <052.8c2cd6f9be403f9ed015ab01c7b033fd@localhost> #3260: Linking stage2 on PPC gives "scattered reloc r_address too large" -------------------------+-------------------------------------------------- Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | -------------------------+-------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 Comment: Thanks for narrowing down the patch that cause the problem, Thorkil. It looks like it is not directly responsible, though, but it just happens to make the final object too large. We hopefully just need to do something like pass a flag to the linker to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 19:20:21 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 19:02:24 2009 Subject: [GHC] #3284: ghc: panic! (the 'impossible' happened). RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph In-Reply-To: <049.4914c49b41cf056fab45d2733464764f@localhost> References: <049.4914c49b41cf056fab45d2733464764f@localhost> Message-ID: <058.e6c71541ad98cb848cb50dc488dc0493@localhost> #3284: ghc: panic! (the 'impossible' happened). RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph ---------------------------+------------------------------------------------ Reporter: mpiechotka | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | ---------------------------+------------------------------------------------ Changes (by igloo): * difficulty: => Unknown Old description: > Linking dist/build/SymmetricTest/SymmetricTest ... > [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: panic! (the 'impossible' happened) > (GHC version 6.10.2 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 > > (Crypto 4.1.0) New description: {{{ Linking dist/build/SymmetricTest/SymmetricTest ... [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: panic! (the 'impossible' happened) (GHC version 6.10.2 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 }}} (Crypto 4.1.0) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 19:28:27 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 19:10:29 2009 Subject: [GHC] #3284: ghc: panic! (the 'impossible' happened). RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph In-Reply-To: <049.4914c49b41cf056fab45d2733464764f@localhost> References: <049.4914c49b41cf056fab45d2733464764f@localhost> Message-ID: <058.183771264933d0131fc674a1708166f5@localhost> #3284: ghc: panic! (the 'impossible' happened). RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph ---------------------------+------------------------------------------------ Reporter: mpiechotka | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. This is a duplicate of #2790. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 11 19:55:49 2009 From: trac at galois.com (GHC) Date: Sat Jul 11 19:37:51 2009 Subject: [GHC] #3289: make -j3 (or make -j30) occasionally fails on 6.11 In-Reply-To: <047.70666110621d92af3cf2b3e0ea735059@localhost> References: <047.70666110621d92af3cf2b3e0ea735059@localhost> Message-ID: <056.584b52c5cd2179b27acd2f80876c5c64@localhost> #3289: make -j3 (or make -j30) occasionally fails on 6.11 ------------------------------------------+--------------------------------- Reporter: gbeshers | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: makefile dependency split | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ------------------------------------------+--------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > I've seen this a handful of times since the new build system was pushed. > I'm using exclusively x86_64 systems. The error message is > > /usr/bin/ld: cannot find libraries/base/dist- > install/build/GHC/Enum_split/Enum__1.p_o > > Turning on make's debug information makes it clear that some process, I > presume split, > is not completing before linking occurs. > > Simply restarting the make completes the build most times (I think only > once has > a second error occurred and I'm not 100% that I had made no > modifications). > > This happens on a dual-core debian system and an 8-core RHEL5.3 or > Fedora-11 system. > > If you need make's debug output send email to gbeshers at gmail dot com, > but I am > hoping just adding a dependency will work. New description: I've seen this a handful of times since the new build system was pushed. I'm using exclusively x86_64 systems. The error message is {{{ /usr/bin/ld: cannot find libraries/base/dist- install/build/GHC/Enum_split/Enum__1.p_o }}} Turning on make's debug information makes it clear that some process, I presume split, is not completing before linking occurs. Simply restarting the make completes the build most times (I think only once has a second error occurred and I'm not 100% that I had made no modifications). This happens on a dual-core debian system and an 8-core RHEL5.3 or Fedora-11 system. If you need make's debug output send email to gbeshers at gmail dot com, but I am hoping just adding a dependency will work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 04:11:58 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 03:53:59 2009 Subject: [GHC] #3359: Build failed: "Could not find module `MachOp'" on 64bit Linux w/ GHC 6.10.3 In-Reply-To: <053.73eaad444842b7192c2c7e2a94f9bfa5@localhost> References: <053.73eaad444842b7192c2c7e2a94f9bfa5@localhost> Message-ID: <062.39c59b5c0606b3512fcf12eaee8764b8@localhost> #3359: Build failed: "Could not find module `MachOp'" on 64bit Linux w/ GHC 6.10.3 ----------------------------+----------------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: worksforme Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------------+----------------------------------------------- Changes (by Ashley Yakeley): * status: new => closed * resolution: => worksforme Comment: Deleting leftover files fixed this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 07:38:29 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 07:20:31 2009 Subject: [GHC] #3350: GHC doesn't compile on Mac OS X 10.4 (Tiger) via MacPorts In-Reply-To: <044.ceb05e62d959d517126b90f70525a764@localhost> References: <044.ceb05e62d959d517126b90f70525a764@localhost> Message-ID: <053.0c6a66e1d70778d142f3ead4e299177e@localhost> #3350: GHC doesn't compile on Mac OS X 10.4 (Tiger) via MacPorts --------------------------------------------+------------------------------- Reporter: indil | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.3 Severity: blocker | Resolution: Keywords: install, error, gmp, linker | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | --------------------------------------------+------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > Executed "sudo port install ghc". Began installing version 6.10.3. Got > this error: > > /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: can't locate file for: > -lgmp > collect2: ld returned 1 exit status > linking dist-stage1/build/Fingerprint_hsc_make.o failed > command was: /usr/bin/gcc > -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work > /ghc-bootstrap/lib/ghc-6.6 -lHSunix_cbits -ldl > -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries/hpc > /dist-bootstrapping/build > -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work > /ghc-bootstrap/lib/ghc-6.6 > -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries > /extensible-exceptions/dist-bootstrapping/build > -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries/Cabal > /dist-bootstrapping/build > -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries/filepath > /dist-bootstrapping/build > -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work > /ghc-bootstrap/lib/ghc-6.6 -lHSbase_cbits > -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work > /ghc-bootstrap/lib/ghc-6.6 -lm -lgmp -ldl dist- > stage1/build/Fingerprint_hsc_make.o -o dist- > stage1/build/Fingerprint_hsc_make > make[1]: *** [boot.stage.1] Error 1 > make: *** [stage1] Error 1 > > I checked, and gmp is installed. I tried uninstalling it, cleaning it, > and reinstalling it, and I also tried cleaning ghc, but I get the same > error when trying to install ghc again. New description: Executed "sudo port install ghc". Began installing version 6.10.3. Got this error: {{{ /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: can't locate file for: -lgmp collect2: ld returned 1 exit status linking dist-stage1/build/Fingerprint_hsc_make.o failed command was: /usr/bin/gcc -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/lib/ghc-6.6 -lHSunix_cbits -ldl -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries/hpc /dist-bootstrapping/build -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/lib/ghc-6.6 -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries /extensible-exceptions/dist-bootstrapping/build -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries/Cabal /dist-bootstrapping/build -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.3/libraries/filepath /dist-bootstrapping/build -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/lib/ghc-6.6 -lHSbase_cbits -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work /ghc-bootstrap/lib/ghc-6.6 -lm -lgmp -ldl dist- stage1/build/Fingerprint_hsc_make.o -o dist- stage1/build/Fingerprint_hsc_make make[1]: *** [boot.stage.1] Error 1 make: *** [stage1] Error 1 }}} I checked, and gmp is installed. I tried uninstalling it, cleaning it, and reinstalling it, and I also tried cleaning ghc, but I get the same error when trying to install ghc again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 07:59:20 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 07:41:22 2009 Subject: [GHC] #3351: Generated ghc man page missing xrefs In-Reply-To: <043.e70675efe6c1e6fb67be6a4568f6dd0d@localhost> References: <043.e70675efe6c1e6fb67be6a4568f6dd0d@localhost> Message-ID: <052.d87ec8197033b518e3943d1cc641444a@localhost> #3351: Generated ghc man page missing xrefs ---------------------------------+------------------------------------------ Reporter: kaol | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Documentation | Version: 6.10.3 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: There have been discussions about rewriting the docs in something like markdown. That might be the best way to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 08:38:50 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 08:20:51 2009 Subject: [GHC] #3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger) In-Reply-To: <047.37055053b1160c638a5374c844089d6a@localhost> References: <047.37055053b1160c638a5374c844089d6a@localhost> Message-ID: <056.2ff7fca901e2a2f1c8a1addb7318b097@localhost> #3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger) ---------------------------------+------------------------------------------ Reporter: bkomuves | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Build System | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => _|_ Comment: A build on OS X 10.4 presumably does work though, so I don't think that this is a high priority for us. We would happily apply patches to make it work, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 11:44:37 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 11:26:37 2009 Subject: [GHC] #3245: Quadratic slowdown in Data.Typeable In-Reply-To: <044.8f6ad688a6e54aadf1867244399f152a@localhost> References: <044.8f6ad688a6e54aadf1867244399f152a@localhost> Message-ID: <053.9f0766a1347ae439dfac744f27831194@localhost> #3245: Quadratic slowdown in Data.Typeable -----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 11:44:57 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 11:26:56 2009 Subject: [GHC] #3251: split rts headers into public and private In-Reply-To: <045.c36f62f5a06285c15ad56ab2ce446706@localhost> References: <045.c36f62f5a06285c15ad56ab2ce446706@localhost> Message-ID: <054.b4c71a36d2e319292ce6df16065c1c4b@localhost> #3251: split rts headers into public and private ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 11:47:14 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 11:29:15 2009 Subject: [GHC] #3347: Add flag to prevent generation of import libraries on Windows In-Reply-To: <053.8a747ba46b77fc35e5fe19946b0f7d84@localhost> References: <053.8a747ba46b77fc35e5fe19946b0f7d84@localhost> Message-ID: <062.e152be040cbbdc41a70ad3418618d0cd@localhost> #3347: Add flag to prevent generation of import libraries on Windows ------------------------------+--------------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by NeilMitchell): Max mentions .lib's of ~2.5Mb, but .lib's can be as big as 60Mb. An alternative to this patch would be to disable the creation of .lib's by default, and add a flag -shared-implib to enable it. The email thread suggests that GNU can link against the .dll's directly, and MSVC can't link against the .lib's at all - if so then they are a bit useless. Is there a flag to indicate bugs which contain patches? I think projects like Mozilla do, and it helps them review and apply patches before they go stale. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 11:57:35 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 11:39:35 2009 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@localhost> References: <045.426dc6319f98492c5b511466045bc0b5@localhost> Message-ID: <054.f770c7ab7639fa8e3c54a5d1e7b5f7ab@localhost> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) -----------------------+---------------------------------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: GHCi | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Old description: > On Windows, when attempting to use Hipmunk from ghci, it produces the > error: > > ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) > > To reproduce: > cabal install Hipmunk > ghci > :m + Physics.Hipmunk > initChipmunk > > Presumably this has something to do with there being no libm on Windows. New description: On Windows, when attempting to use Hipmunk from ghci, it produces the error: {{{ ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) }}} To reproduce: {{{ cabal install Hipmunk ghci :m + Physics.Hipmunk initChipmunk }}} Presumably this has something to do with there being no libm on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 12:00:36 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 11:42:37 2009 Subject: [GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) In-Reply-To: <045.426dc6319f98492c5b511466045bc0b5@localhost> References: <045.426dc6319f98492c5b511466045bc0b5@localhost> Message-ID: <054.4ad7a2d11dd3276fa135b92883bd9cde@localhost> #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL) -----------------------+---------------------------------------------------- Reporter: jeffz1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * status: reopened => closed * resolution: => invalid Comment: I'm afraid I don't know how to do this on Windows, but I still don't see a GHC bug here: If you tell GHC that you need a library that doesn't exist then you will get the above error message. Please reopen this ticket and give more details if you believe that there is a GHC bug causing this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 12:01:00 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 11:42:59 2009 Subject: [GHC] #3266: Segment fault with WxHaskell and GHC 6.10.2 In-Reply-To: <051.cf64c613e81199a56945f37be31832f5@localhost> References: <051.cf64c613e81199a56945f37be31832f5@localhost> Message-ID: <060.aedc0dfa36943d3838cfb4787ee775dc@localhost> #3266: Segment fault with WxHaskell and GHC 6.10.2 -----------------------------+---------------------------------------------- Reporter: mcastellazzi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: wxhaskell | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > When i compile this very simple program : > module Main where > > import Graphics.UI.WX > > main :: IO () > main = start gui > > gui :: IO () > gui = do > frame [text := "Hello World!"] > return () > > and that I run it with DOS, I get the error : "Segment fault/access > violation in generated code" as soon as the mouse passes over the > displayed window. > > When I compile it and run it with GHCI, under Windows, I get the extra > informations : > Signature du probl?me?: > Nom d??v?nement de probl?me: APPCRASH > Nom de l?application: ghc.exe > Version de l?application: 0.0.0.0 > Horodatage de l'application: 49d14878 > Nom du module par d?faut: comctl32.dll_unloaded > Version du module par d?faut: 0.0.0.0 > Horodateur du module par d?faut: 4549bcb0 > Code de l?exception: c0000005 > D?calage de l?exception: 73828219 > Version du syst?me: 6.0.6000.2.0.0.768.3 > Identificateur de param?tres r?gionaux: 1036 > Information suppl?mentaire n??1: 916f > Information suppl?mentaire n??2: 5a80fd0e43273a8de02792153de3009a > Information suppl?mentaire n??3: 3cbc > Information suppl?mentaire n??4: a7ba763d72dae8d739732c4202cd60ca > > I get the same error with almost all the demo programs delivered with > WxHaskell. > > I have Windows Vista, GHC 6.10.2, wxHaskell 0.11.1.2 et WxWidgets 2.8.9. New description: When i compile this very simple program : {{{ module Main where import Graphics.UI.WX main :: IO () main = start gui gui :: IO () gui = do frame [text := "Hello World!"] return () }}} and that I run it with DOS, I get the error : "Segment fault/access violation in generated code" as soon as the mouse passes over the displayed window. When I compile it and run it with GHCI, under Windows, I get the extra informations : {{{ Signature du probl?me?: Nom d??v?nement de probl?me: APPCRASH Nom de l?application: ghc.exe Version de l?application: 0.0.0.0 Horodatage de l'application: 49d14878 Nom du module par d?faut: comctl32.dll_unloaded Version du module par d?faut: 0.0.0.0 Horodateur du module par d?faut: 4549bcb0 Code de l?exception: c0000005 D?calage de l?exception: 73828219 Version du syst?me: 6.0.6000.2.0.0.768.3 Identificateur de param?tres r?gionaux: 1036 Information suppl?mentaire n??1: 916f Information suppl?mentaire n??2: 5a80fd0e43273a8de02792153de3009a Information suppl?mentaire n??3: 3cbc Information suppl?mentaire n??4: a7ba763d72dae8d739732c4202cd60ca }}} I get the same error with almost all the demo programs delivered with WxHaskell. I have Windows Vista, GHC 6.10.2, wxHaskell 0.11.1.2 et WxWidgets 2.8.9. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 12:23:51 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 12:05:49 2009 Subject: [GHC] #3266: Segment fault with WxHaskell and GHC 6.10.2 In-Reply-To: <051.cf64c613e81199a56945f37be31832f5@localhost> References: <051.cf64c613e81199a56945f37be31832f5@localhost> Message-ID: <060.f84e5060ff597d701e1ece66e4ba9d11@localhost> #3266: Segment fault with WxHaskell and GHC 6.10.2 -----------------------------+---------------------------------------------- Reporter: mcastellazzi | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: wxhaskell | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => _|_ Comment: My hunch is that, as Eric suggests, it is a wxHaskell bug, probably due to different threads calling wxHaskell functions. GHCi is compiled with `-threaded`, which might explain why you see the problem in ghci but not when running compiled code. If you think that it is a GHC bug then it would be very helpful if you could make this example self-contained, just inlining the few wxHaskell functions and FFI imports that are used. I'll leave the ticket open while its cause is unconfirmed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 12:49:09 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 12:31:09 2009 Subject: [GHC] #3267: hasktags ctags output enhancement In-Reply-To: <055.117b0d5ee2131e5ce270f52b6af3f005@localhost> References: <055.117b0d5ee2131e5ce270f52b6af3f005@localhost> Message-ID: <064.6da592a9422614653f09462fab234fee@localhost> #3267: hasktags ctags output enhancement ---------------------------------+------------------------------------------ Reporter: vincent.berthoux | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.10.2 Severity: normal | Resolution: invalid Keywords: hasktags | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: hasktags is no longer part of the GHC distribution. It now has its own darcs repo here: http://darcs.haskell.org/hasktags/ As far as I know it doesn't have a maintainer. Perhaps you would be interested in taking it over? You could make a project for it on http://community.haskell.org/. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 12:52:16 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 12:34:16 2009 Subject: [GHC] #3268: implement the Cabal ${pkgroot} spec extension In-Reply-To: <045.8be95892c9d19347370cbf9a54614c20@localhost> References: <045.8be95892c9d19347370cbf9a54614c20@localhost> Message-ID: <054.96fae4555d8bb3470f1e13a0880f1d5b@localhost> #3268: implement the Cabal ${pkgroot} spec extension ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Package system | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 13:21:04 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 13:03:03 2009 Subject: [GHC] #3271: New methods for Data.Sequence In-Reply-To: <053.cc9895e43857ea386bfb254a48e9e83f@localhost> References: <053.cc9895e43857ea386bfb254a48e9e83f@localhost> Message-ID: <062.6e078c46afc9b8aff47014351c0f19f5@localhost> #3271: New methods for Data.Sequence ----------------------------------+----------------------------------------- Reporter: LouisWasserman | Owner: LouisWasserman Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 13:23:06 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 13:05:06 2009 Subject: [GHC] #3272: GHC panics when contexts are put late in function types In-Reply-To: <044.48a8ed9c7f42f20ab8f57bc784f391e5@localhost> References: <044.48a8ed9c7f42f20ab8f57bc784f391e5@localhost> Message-ID: <053.960ec43b6f795cf8ef3ab6250e94e251@localhost> #3272: GHC panics when contexts are put late in function types ----------------------------------------+----------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by igloo): * milestone: => 6.12.1 Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 13:23:20 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 13:05:19 2009 Subject: [GHC] #3274: Add System.FilePath.Cygwin In-Reply-To: <051.26cec4bbfc888314c03b702b9312954c@localhost> References: <051.26cec4bbfc888314c03b702b9312954c@localhost> Message-ID: <060.ef4ab657037f911366412283db9ae86d@localhost> #3274: Add System.FilePath.Cygwin ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * type: bug => proposal * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 13:32:47 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 13:14:49 2009 Subject: [GHC] #3276: FilePath.addTrailingPathSeparator "" = "/" In-Reply-To: <045.c94373ccfee4669a603a10ee0b36cb4d@localhost> References: <045.c94373ccfee4669a603a10ee0b36cb4d@localhost> Message-ID: <054.fe13f104517fc11b32d5cd38ffcee7a7@localhost> #3276: FilePath.addTrailingPathSeparator "" = "/" ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * milestone: => 6.12.1 Comment: Here's a property I'd expect System.FilePath to satisfy: {{{ (addTrailingPathSeparator x y) == (x y) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 13:35:19 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 13:17:18 2009 Subject: [GHC] #3280: The order of arguments to the function passed to nubBy got swapped somehow In-Reply-To: <044.3c8fa074464e1da7a1a920048af3ac0f@localhost> References: <044.3c8fa074464e1da7a1a920048af3ac0f@localhost> Message-ID: <053.3d709070c8444eb5d0bd4be64e514773@localhost> #3280: The order of arguments to the function passed to nubBy got swapped somehow ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12.1 Comment: Does someone want to make a proposal for this please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 13:49:23 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 13:31:22 2009 Subject: [GHC] #3282: How to start an emacs editor within ghci asynchronously with :edit filename.hs :set editor emacs & don't go In-Reply-To: <048.be8dd9462b3573e642dcec0dfb5c7624@localhost> References: <048.be8dd9462b3573e642dcec0dfb5c7624@localhost> Message-ID: <057.4ab35245f8e2eb619cb30d05d45b5809@localhost> #3282: How to start an emacs editor within ghci asynchronously with :edit filename.hs :set editor emacs & don't go ---------------------------------+------------------------------------------ Reporter: petersonx | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: So if you could run an editor asynchronously, you would expect ghci to watch the file and reload if it is saved, presumably? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 14:16:56 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 13:58:54 2009 Subject: [GHC] #3283: Selective disabling of unused bind warnings In-Reply-To: <042.99c53619193c24de1883dd2c0ccb355d@localhost> References: <042.99c53619193c24de1883dd2c0ccb355d@localhost> Message-ID: <051.e31baf3ca7ac15d70374f2b96fd84ab2@localhost> #3283: Selective disabling of unused bind warnings ---------------------------------+------------------------------------------ Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 14:22:57 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 14:04:57 2009 Subject: [GHC] #3289: make -j3 (or make -j30) occasionally fails on 6.11 In-Reply-To: <047.70666110621d92af3cf2b3e0ea735059@localhost> References: <047.70666110621d92af3cf2b3e0ea735059@localhost> Message-ID: <056.5b31eeab9e1f37745df6ffa66b02768c@localhost> #3289: make -j3 (or make -j30) occasionally fails on 6.11 ------------------------------------------+--------------------------------- Reporter: gbeshers | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: makefile dependency split | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ------------------------------------------+--------------------------------- Changes (by igloo): * milestone: => 6.12.1 Comment: I can neither reproduce this, nor see why it would happen. I've sent an e-mail to gbeshers. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 14:26:43 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 14:08:42 2009 Subject: [GHC] #3292: Add an 'ignore' function to Control.Monad In-Reply-To: <044.27c764de47060e5a6666b1886ee80198@localhost> References: <044.27c764de47060e5a6666b1886ee80198@localhost> Message-ID: <053.27d70a77cc4edf0643bf56fb77b1ba6f@localhost> #3292: Add an 'ignore' function to Control.Monad ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 14:27:58 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 14:09:57 2009 Subject: [GHC] #3294: Large compilation time/memory consumption In-Reply-To: <046.0a15417e538aeef3254b5152fea74b37@localhost> References: <046.0a15417e538aeef3254b5152fea74b37@localhost> Message-ID: <055.f94284eb3fc05008858bf58716aee00f@localhost> #3294: Large compilation time/memory consumption ---------------------------------------------+------------------------------ Reporter: pumpkin | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ---------------------------------------------+------------------------------ Changes (by igloo): * difficulty: => Unknown Old description: > When compiling the attached test case in the following way: > > airpumpkin:integer-benchmark pumpkin$ time ghc -O2 --make -o big Big.hs > [1 of 1] Compiling Main ( Big.hs, Big.o ) > Linking big ... > > real 1m29.336s > user 1m18.300s > sys 0m6.816s > > You can see it takes a while to compile, and uses 640 MB of RAM during > compilation. New description: When compiling the attached test case in the following way: {{{ airpumpkin:integer-benchmark pumpkin$ time ghc -O2 --make -o big Big.hs [1 of 1] Compiling Main ( Big.hs, Big.o ) Linking big ... real 1m29.336s user 1m18.300s sys 0m6.816s }}} You can see it takes a while to compile, and uses 640 MB of RAM during compilation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 14:34:47 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 14:16:50 2009 Subject: [GHC] #3296: mention also -RTS after stack overflow In-Reply-To: <045.b258499c759b06282a80550677967359@localhost> References: <045.b258499c759b06282a80550677967359@localhost> Message-ID: <054.4313a4a8b84bce5a6cf55484628f64d6@localhost> #3296: mention also -RTS after stack overflow ---------------------------------+------------------------------------------ Reporter: maeder | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 Comment: It's a clarity/verbosity tradeoff. Let's make a decision for 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 15:38:59 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 15:21:21 2009 Subject: [GHC] #3297: Compiler panic on incorrect code (TcTyFuns.flattenType: synonym family in a rank-n type) In-Reply-To: <048.6b2e6afb6975be0e0c389f8b6c47df0c@localhost> References: <048.6b2e6afb6975be0e0c389f8b6c47df0c@localhost> Message-ID: <057.0b7945c527bd535c3d4845ea9d45f82d@localhost> #3297: Compiler panic on incorrect code (TcTyFuns.flattenType: synonym family in a rank-n type) ----------------------------------------+----------------------------------- Reporter: hesselink | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 15:40:44 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 15:22:52 2009 Subject: [GHC] #3298: Add swap to Data.Tuple In-Reply-To: <041.b0c2cdf17e67a092210f2327e17cca5e@localhost> References: <041.b0c2cdf17e67a092210f2327e17cca5e@localhost> Message-ID: <050.fa2954d2ec65a4a5fd11f94f404246ac@localhost> #3298: Add swap to Data.Tuple ---------------------------------+------------------------------------------ Reporter: r6 | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 15:44:02 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 15:26:25 2009 Subject: [GHC] #3302: Where-clause environments for GHCi In-Reply-To: <042.5c0ec265d0b74126ec10ff4afe70b130@localhost> References: <042.5c0ec265d0b74126ec10ff4afe70b130@localhost> Message-ID: <051.3ba574e9b23f46a38964f3a96720cf38@localhost> #3302: Where-clause environments for GHCi ---------------------------------+------------------------------------------ Reporter: cjs | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks dherington. Closing the ticket as this is already possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 16:03:44 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 15:45:43 2009 Subject: [GHC] #3294: Large compilation time/memory consumption In-Reply-To: <046.0a15417e538aeef3254b5152fea74b37@localhost> References: <046.0a15417e538aeef3254b5152fea74b37@localhost> Message-ID: <055.2a7ed09b900b3877e97983e3ab4fb1c0@localhost> #3294: Large compilation time/memory consumption ---------------------------------------------+------------------------------ Reporter: pumpkin | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ---------------------------------------------+------------------------------ Changes (by igloo): * milestone: => 6.12.1 Comment: Thanks for the report. I've attached some space profiles with and without `-O`. It looks like it is the codegen taking all the time and space. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 16:09:31 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 15:51:28 2009 Subject: [GHC] #3303: Allow multi-line deprecation messages. In-Reply-To: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> References: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> Message-ID: <054.2f31ce7caa4d8b6818b2f1b6232596d9@localhost> #3303: Allow multi-line deprecation messages. ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 16:09:58 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 15:51:56 2009 Subject: [GHC] #3304: define gcd 0 0 = 0 In-Reply-To: <045.185c8414dc74a05b9b8c81a6506a335e@localhost> References: <045.185c8414dc74a05b9b8c81a6506a335e@localhost> Message-ID: <054.97cd9a0286a95b6795563a0014a4cea0@localhost> #3304: define gcd 0 0 = 0 ---------------------------------+------------------------------------------ Reporter: stevec | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 16:12:58 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 15:54:57 2009 Subject: [GHC] #3305: panic message "impossible happened" loadobj: failed loading SOE packages and trying to run main1 in Animation.lhs In-Reply-To: <051.558ce25b2ee78a9e988e8e8d099ba07d@localhost> References: <051.558ce25b2ee78a9e988e8e8d099ba07d@localhost> Message-ID: <060.98478d5101640445e7b6b6a1be1bce69@localhost> #3305: panic message "impossible happened" loadobj: failed loading SOE packages and trying to run main1 in Animation.lhs -----------------------------+---------------------------------------------- Reporter: don vinnedge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: Can you paste the exact command you are running and error that you are seeing please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 16:15:05 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 15:57:04 2009 Subject: [GHC] #3306: Improve syntax for GADT + records In-Reply-To: <046.d67bbf39466d205ecf2349957e851ca2@localhost> References: <046.d67bbf39466d205ecf2349957e851ca2@localhost> Message-ID: <055.45b2c2ab0bcf0d3995cab2008d7b3c76@localhost> #3306: Improve syntax for GADT + records ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 16:15:43 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 15:57:41 2009 Subject: [GHC] #3307: System.IO and System.Directory functions not Unicode-aware under Unix In-Reply-To: <047.ddb3891fe2d3c253095b502cf5958591@localhost> References: <047.ddb3891fe2d3c253095b502cf5958591@localhost> Message-ID: <056.1d471da99bc04c386c6159f768757b54@localhost> #3307: System.IO and System.Directory functions not Unicode-aware under Unix ----------------------------------+----------------------------------------- Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: directory unicode | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 16:16:02 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 15:58:01 2009 Subject: [GHC] #3308: getArgs should return Unicode on Windows In-Reply-To: <047.349ab7e0a032ccecf479f1bc43886f9b@localhost> References: <047.349ab7e0a032ccecf479f1bc43886f9b@localhost> Message-ID: <056.92de256a102ac97c09dca087604a561c@localhost> #3308: getArgs should return Unicode on Windows ---------------------------------+------------------------------------------ Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: unicode | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 16:16:20 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 15:58:18 2009 Subject: [GHC] #3309: getArgs should return Unicode on Unix In-Reply-To: <047.aeeed4251d6d88157f87d6d7a9cbe6b7@localhost> References: <047.aeeed4251d6d88157f87d6d7a9cbe6b7@localhost> Message-ID: <056.2a0b0fda3f16fc0a65cdecd7edce306b@localhost> #3309: getArgs should return Unicode on Unix ---------------------------------+------------------------------------------ Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: unicode | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 16:48:26 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 16:30:26 2009 Subject: [GHC] #3313: Uncertain bug report (panic!) In-Reply-To: <056.afdd6dd2b6671bd71703bba915e82288@localhost> References: <056.afdd6dd2b6671bd71703bba915e82288@localhost> Message-ID: <065.91cd48fb59cce05d1a030b2eecb75ef6@localhost> #3313: Uncertain bug report (panic!) ----------------------------------+----------------------------------------- Reporter: semanticprecision | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 Comment: Thanks for the report. It breaks the HEAD too. Here's a minimal testcase: {{{ module Foo where import Data.Word bytesToGrayscaleImage :: Word -> Maybe () bytesToGrayscaleImage 5 = Just () bytesToGrayscaleImage 6 = Just () bytesToGrayscaleImage _ = Nothing }}} {{{ $ ghci Foo.hs GHCi, version 6.11.20090710: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp-0.1.0.0 ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. [1 of 1] Compiling Foo ( Foo.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 6.11.20090710 for x86_64-unknown-linux): schemeE(AnnCase).my_discr __word 5 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 Sun Jul 12 16:56:41 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 16:38:40 2009 Subject: [GHC] #3314: Add compilation date to +RTS --info In-Reply-To: <044.ba2b5095895a2d1777a79a9b191f08e5@localhost> References: <044.ba2b5095895a2d1777a79a9b191f08e5@localhost> Message-ID: <053.42b6dc0302061c237c015e3386a0dd44@localhost> #3314: Add compilation date to +RTS --info ---------------------------------+------------------------------------------ Reporter: Orphi | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: It would be a little fiddly, but I think worth it. Thanks for the idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 17:16:02 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 16:58:02 2009 Subject: [GHC] #3315: Add generalised "lookup" function In-Reply-To: <046.c82ce153a867ca40d2078a55a59c2144@localhost> References: <046.c82ce153a867ca40d2078a55a59c2144@localhost> Message-ID: <055.592ec7a21162cf40a75095a31b426cec@localhost> #3315: Add generalised "lookup" function ---------------------------------+------------------------------------------ Reporter: skorpan | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 6.11 Severity: minor | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Please see http://www.haskell.org/haskellwiki/Library_submissions for how to propose changes to the core libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 17:18:05 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 17:00:03 2009 Subject: [GHC] #3321: -fhpc assumes original sources relative to the current directory In-Reply-To: <045.e36e70091ef09c2231ae7feacc97785c@localhost> References: <045.e36e70091ef09c2231ae7feacc97785c@localhost> Message-ID: <054.bfbabe47250c7d98eeb54bb513e62346@localhost> #3321: -fhpc assumes original sources relative to the current directory ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 17:22:34 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 17:04:32 2009 Subject: [GHC] #3324: Add Foldable and Traversable instances for ((, ) a) In-Reply-To: <047.8947bef7cc0f665b60675f311754fd4d@localhost> References: <047.8947bef7cc0f665b60675f311754fd4d@localhost> Message-ID: <056.3806c7def33fa1a606a3dc3f1ce0cf50@localhost> #3324: Add Foldable and Traversable instances for ((,) a) ---------------------------------+------------------------------------------ Reporter: YitzGale | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 12 22:20:58 2009 From: trac at galois.com (GHC) Date: Sun Jul 12 22:03:01 2009 Subject: [GHC] #3306: Improve syntax for GADT + records In-Reply-To: <046.d67bbf39466d205ecf2349957e851ca2@localhost> References: <046.d67bbf39466d205ecf2349957e851ca2@localhost> Message-ID: <055.f88c59da8faa0292c490ce17dafce5f9@localhost> #3306: Improve syntax for GADT + records ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by chak): I recently needed class constraints in a GADT with record syntax and used (B) with the HEAD. So, there is definitely a need for this. I definitely prefer (B) out of the two choices listed above. I think it is ok to make a breaking change here. After all, this is very experimental territory still. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 04:05:38 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 03:48:20 2009 Subject: [GHC] #3339: Data.Monoid: Add (+>) as a synonym for mappend In-Reply-To: <042.626638ce45ff16ad4ce623d16cab0138@localhost> References: <042.626638ce45ff16ad4ce623d16cab0138@localhost> Message-ID: <051.3f2c8769b15fd99c085d87d3a051e4a8@localhost> #3339: Data.Monoid: Add (+>) as a synonym for mappend ------------------------------+--------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by jeltsch): What are the exact backward-compatibility problems? I can only think of cases like {{{ cat = (++) }}} which only matter because the monomorphism restriction is still in use. The ?confusing newbiews with weird error messages? problem is already present in several places. For example, the expression {{{1 + 'A'}}} will make GHC complain that there is no instance for {{{(Num Char)}}}. I think, it would be better to try to generate better error messages instead of increasing the number of operators. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 05:45:42 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 05:27:43 2009 Subject: [GHC] #3306: Improve syntax for GADT + records In-Reply-To: <046.d67bbf39466d205ecf2349957e851ca2@localhost> References: <046.d67bbf39466d205ecf2349957e851ca2@localhost> Message-ID: <055.2dd4d2d45a72abadcba81d527b9f7937@localhost> #3306: Improve syntax for GADT + records ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => simonpj Comment: I've mostly implemented this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 05:57:07 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 05:39:12 2009 Subject: [GHC] #3296: mention also -RTS after stack overflow In-Reply-To: <045.b258499c759b06282a80550677967359@localhost> References: <045.b258499c759b06282a80550677967359@localhost> Message-ID: <054.1a5a3d8b74bfcdba551ba5f071abeed3@localhost> #3296: mention also -RTS after stack overflow ---------------------------------+------------------------------------------ Reporter: maeder | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): The suggestion is to change the message to this: {{{ Stack space overflow: current size 8388608 bytes. Use `+RTS -K -RTS' to increase it. }}} correct? (that's fine by me) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 06:03:06 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 05:45:03 2009 Subject: [GHC] #3294: Large compilation time/memory consumption In-Reply-To: <046.0a15417e538aeef3254b5152fea74b37@localhost> References: <046.0a15417e538aeef3254b5152fea74b37@localhost> Message-ID: <055.122a95c0fceb201bbbbac04373e2e556@localhost> #3294: Large compilation time/memory consumption ---------------------------------------------+------------------------------ Reporter: pumpkin | Owner: simonmar Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ---------------------------------------------+------------------------------ Changes (by simonmar): * owner: => simonmar Comment: Yes, the register allocator looks like a culprit. Try `-fregs-graph`? I'm fairly familiar with the linear register allocator anyway, so I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 06:05:10 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 05:47:07 2009 Subject: [GHC] #3313: Uncertain bug report (panic!) In-Reply-To: <056.afdd6dd2b6671bd71703bba915e82288@localhost> References: <056.afdd6dd2b6671bd71703bba915e82288@localhost> Message-ID: <065.c3144a390487d867b7489fb30d7f271c@localhost> #3313: Uncertain bug report (panic!) ----------------------------------+----------------------------------------- Reporter: semanticprecision | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: duplicate of #2881 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 06:09:47 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 05:51:46 2009 Subject: [GHC] #3326: the recompilation checker should take CPP flags into account In-Reply-To: <047.f460b2673a1733e129e3e26d96037ca8@localhost> References: <047.f460b2673a1733e129e3e26d96037ca8@localhost> Message-ID: <056.0fea64d11ae9a8e231140834134efb4c@localhost> #3326: the recompilation checker should take CPP flags into account ---------------------------------+------------------------------------------ Reporter: bkomuves | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 06:31:39 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 06:13:36 2009 Subject: [GHC] #3369: Deadlock sending stdin to a process which does not read it In-Reply-To: <047.ae0eafc4c75d0c813ff01c481cb76a53@localhost> References: <047.ae0eafc4c75d0c813ff01c481cb76a53@localhost> Message-ID: <056.1cf88efea1581a219d3aa05bf6f72201@localhost> #3369: Deadlock sending stdin to a process which does not read it -------------------------------+-------------------------------------------- Reporter: simonmic | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/process | Version: 6.10.3 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Changes (by simonmic): * status: new => closed * resolution: => invalid Comment: This was hard to reproduce today, and I'm no longer sure its mac-specific. I learned some more about lazy I/O and added the writeFile line, trying to force full evaluation: {{{ (ih,oh,eh,ph) ? runInteractiveCommand cmd forkIO $ hPutStr ih i' out ? hGetContents oh err ? hGetContents eh writeFile "/dev/null" $ printf "%d%d " (length o_actual) (length e_actual) exit ? waitForProcess ph }}} This prevented the hang. I guess there's no ghc issue here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 06:40:43 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 06:22:39 2009 Subject: [GHC] #3331: control-monad-queue performance regression In-Reply-To: <046.199bea4da34b828d923df9304139778a@localhost> References: <046.199bea4da34b828d923df9304139778a@localhost> Message-ID: <055.50180c47fa94e9029a268e6477188d46@localhost> #3331: control-monad-queue performance regression -----------------------------------------+---------------------------------- Reporter: lpsmith | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 06:44:16 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 06:26:16 2009 Subject: [GHC] #3296: mention also -RTS after stack overflow In-Reply-To: <045.b258499c759b06282a80550677967359@localhost> References: <045.b258499c759b06282a80550677967359@localhost> Message-ID: <054.f437c55abb17024c3480bc045aebad44@localhost> #3296: mention also -RTS after stack overflow ---------------------------------+------------------------------------------ Reporter: maeder | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by maeder): Yes, thanks, fine with me, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 06:48:13 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 06:30:13 2009 Subject: [GHC] #3330: Type checker hangs In-Reply-To: <060.111b0979bdfa1b272261462ee3c542d4@localhost> References: <060.111b0979bdfa1b272261462ee3c542d4@localhost> Message-ID: <069.85e4cc6fc3669103e7646fc4e511cd2d@localhost> #3330: Type checker hangs ----------------------------------------+----------------------------------- Reporter: MartijnVanSteenbergen | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 06:57:36 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 06:39:44 2009 Subject: [GHC] #3333: GHCi doesn't load weak symbols In-Reply-To: <047.f7df20b3080234226b9f5744151738a8@localhost> References: <047.f7df20b3080234226b9f5744151738a8@localhost> Message-ID: <056.1cf0e8ccde5f2bf4e583cac20e921758@localhost> #3333: GHCi doesn't load weak symbols --------------------------------------+------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: Keywords: weak, dynamic loading | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | --------------------------------------+------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 06:57:48 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 06:39:44 2009 Subject: [GHC] #3335: make some Applicative functions into methods, and split off Data.Functor In-Reply-To: <043.088ab986c5172cef4daab943f384779a@localhost> References: <043.088ab986c5172cef4daab943f384779a@localhost> Message-ID: <052.9afa6fa3f48228570285f31c57e5a210@localhost> #3335: make some Applicative functions into methods, and split off Data.Functor ---------------------------------+------------------------------------------ Reporter: ross | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 06:58:05 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 06:40:03 2009 Subject: [GHC] #3336: Following gcc behaviour with regards to calling conventions on x86_64 In-Reply-To: <053.2867833c6ad9a83e8721822ccc5e3e0d@localhost> References: <053.2867833c6ad9a83e8721822ccc5e3e0d@localhost> Message-ID: <062.51fecf81ddb734ef8393d1088a75b23c@localhost> #3336: Following gcc behaviour with regards to calling conventions on x86_64 --------------------------------------------+------------------------------- Reporter: JeffersonHeard | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: calling convention, stdcall | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | --------------------------------------------+------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > http://blogs.msdn.com/freik/archive/2005/03/17/398200.aspx > > Right now, if anything other than ccall is given to ghc on x86_64 > architectures, ghc errors out with the complaint that the calling > convention is not supported on this architecture. gcc on the other hand, > handles this situation gracefully, ignoring the calling convention > attribute. My thought is that ghc should do this as well. > > Currently, I get this: > > TerraHS/TerraLib/TePoint.hs:121:0: > calling convention not supported on this architecture: stdcall > When checking declaration: > foreign import stdcall unsafe "static &c_tepoint_setobjectid" > tepoint_setobjectid > :: TePointPtr -> CString -> IO () > > I think I should instead get a warning saying that the calling convention > is being ignored. New description: http://blogs.msdn.com/freik/archive/2005/03/17/398200.aspx Right now, if anything other than ccall is given to ghc on x86_64 architectures, ghc errors out with the complaint that the calling convention is not supported on this architecture. gcc on the other hand, handles this situation gracefully, ignoring the calling convention attribute. My thought is that ghc should do this as well. Currently, I get this: {{{ TerraHS/TerraLib/TePoint.hs:121:0: calling convention not supported on this architecture: stdcall When checking declaration: foreign import stdcall unsafe "static &c_tepoint_setobjectid" tepoint_setobjectid :: TePointPtr -> CString -> IO () }}} I think I should instead get a warning saying that the calling convention is being ignored. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 06:58:32 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 06:40:29 2009 Subject: [GHC] #3336: Following gcc behaviour with regards to calling conventions on x86_64 In-Reply-To: <053.2867833c6ad9a83e8721822ccc5e3e0d@localhost> References: <053.2867833c6ad9a83e8721822ccc5e3e0d@localhost> Message-ID: <062.940390b67616881ba52147a162c6ad00@localhost> #3336: Following gcc behaviour with regards to calling conventions on x86_64 --------------------------------------------+------------------------------- Reporter: JeffersonHeard | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: calling convention, stdcall | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | --------------------------------------------+------------------------------- Changes (by igloo): * milestone: => 6.14.1 Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 06:58:47 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 06:41:22 2009 Subject: [GHC] #3339: Data.Monoid: Add (+>) as a synonym for mappend In-Reply-To: <042.626638ce45ff16ad4ce623d16cab0138@localhost> References: <042.626638ce45ff16ad4ce623d16cab0138@localhost> Message-ID: <051.f59a0512500e937ff3a9917b0897931b@localhost> #3339: Data.Monoid: Add (+>) as a synonym for mappend ---------------------------------+------------------------------------------ Reporter: bos | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * type: bug => proposal * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 07:00:09 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 06:42:08 2009 Subject: [GHC] #3343: make 2 doesn't seem to work as documented In-Reply-To: <043.8b27f399b7b0d79cfe1e1d26e534b327@localhost> References: <043.8b27f399b7b0d79cfe1e1d26e534b327@localhost> Message-ID: <052.dbfdb6b72d9c738d1565dc8f550dd724@localhost> #3343: make 2 doesn't seem to work as documented ---------------------------------+------------------------------------------ Reporter: chak | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: Please re-open if the problem is something other than running "make 2" from the wrong directory. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 07:02:47 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 06:44:43 2009 Subject: [GHC] #3345: Support reading .a files in GHCi to reclaim some disk space In-Reply-To: <053.59839787a1c48a2f42a78e2afa335a69@localhost> References: <053.59839787a1c48a2f42a78e2afa335a69@localhost> Message-ID: <062.f353286f29a8632ec43ac19de2a37bdf@localhost> #3345: Support reading .a files in GHCi to reclaim some disk space ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 Comment: The alternative will be for GHCi to use dynamic libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 07:05:02 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 06:47:02 2009 Subject: [GHC] #3346: Strange and incorrect type error when using rewrite rules with type families In-Reply-To: <046.8516030065369a83577dc50b430a1824@localhost> References: <046.8516030065369a83577dc50b430a1824@localhost> Message-ID: <055.b3c795d167ad026ebc13f1028afd1033@localhost> #3346: Strange and incorrect type error when using rewrite rules with type families ---------------------------------+------------------------------------------ Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 07:09:11 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 06:51:09 2009 Subject: [GHC] #3347: Add flag to prevent generation of import libraries on Windows In-Reply-To: <053.8a747ba46b77fc35e5fe19946b0f7d84@localhost> References: <053.8a747ba46b77fc35e5fe19946b0f7d84@localhost> Message-ID: <062.3d882216b89c91d0db65751804a353cd@localhost> #3347: Add flag to prevent generation of import libraries on Windows ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.12.1 Comment: Thanks for the report and patch; I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 07:13:50 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 06:55:46 2009 Subject: [GHC] #3352: Data.Word should define instances of Random for each type In-Reply-To: <043.251be63510fd30b1463f4fc2dcc0c60a@localhost> References: <043.251be63510fd30b1463f4fc2dcc0c60a@localhost> Message-ID: <052.c9cf0f4fe8c0d5e7e307015b660a94f3@localhost> #3352: Data.Word should define instances of Random for each type ---------------------------------+------------------------------------------ Reporter: kaol | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => _|_ Comment: Can someone make a library submission (http://www.haskell.org/haskellwiki/Library_submissions) for this please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 07:25:26 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 07:07:26 2009 Subject: [GHC] #3356: {-# LANGUAGE NoTraditionalRecordSyntax #-} to disable the current record syntax In-Reply-To: <043.6778edbbee7a5013ba33c2b55c12358e@localhost> References: <043.6778edbbee7a5013ba33c2b55c12358e@localhost> Message-ID: <052.bacd71c0f790935cdc6fe388b2836cc7@localhost> #3356: {-# LANGUAGE NoTraditionalRecordSyntax #-} to disable the current record syntax ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 07:25:51 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 07:07:48 2009 Subject: [GHC] #3360: Add profiling support to GHCi In-Reply-To: <043.11a45369957037aa40d80793cfeb6f91@localhost> References: <043.11a45369957037aa40d80793cfeb6f91@localhost> Message-ID: <052.e6cf076d2682aa012e1613cbf7dace8e@localhost> #3360: Add profiling support to GHCi ---------------------------------+------------------------------------------ Reporter: SamB | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14 branch Component: GHCi | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 07:25:59 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 07:07:55 2009 Subject: [GHC] #3362: Adding a newtype EndoCategory to Control.Category In-Reply-To: <041.a309c46198949df45199b585afafe754@localhost> References: <041.a309c46198949df45199b585afafe754@localhost> Message-ID: <050.7c80b68f2b8466dccec75d30e21c313e@localhost> #3362: Adding a newtype EndoCategory to Control.Category ---------------------------------+------------------------------------------ Reporter: r6 | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 07:26:23 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 07:08:22 2009 Subject: [GHC] #3364: calling "ghc -H" panics In-Reply-To: <044.8f3c1ce38e708cbdf5f93b63ad116141@localhost> References: <044.8f3c1ce38e708cbdf5f93b63ad116141@localhost> Message-ID: <053.f0b499294243e8b715778ef600a48d7d@localhost> #3364: calling "ghc -H" panics -------------------------+-------------------------------------------------- Reporter: baldo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 07:46:14 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 07:28:11 2009 Subject: [GHC] #3368: Deriving Foldable doesn't work In-Reply-To: <043.07fd00804268a4211b859ee0eb6e08cb@localhost> References: <043.07fd00804268a4211b859ee0eb6e08cb@localhost> Message-ID: <052.47163e916900a4563746888faf3af212@localhost> #3368: Deriving Foldable doesn't work ---------------------------------+------------------------------------------ Reporter: cmcq | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.12.1 Comment: Thanks for the report and patches. I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 11:38:58 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 11:20:57 2009 Subject: [GHC] #3274: Add System.FilePath.Cygwin In-Reply-To: <051.26cec4bbfc888314c03b702b9312954c@localhost> References: <051.26cec4bbfc888314c03b702b9312954c@localhost> Message-ID: <060.d5b8bf988190e5c5aa97949fc10f6d9d@localhost> #3274: Add System.FilePath.Cygwin ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by NeilMitchell): * status: new => closed * resolution: => wontfix Comment: Some people thought it was a good idea. There was discussion of how to deal with drives, in particular support for /cygdrive/c/ etc. Simon Marlow suggested that perhaps System.FilePath.POSIX might be more appropriate in most cases. Neil realised that while originally his FilePath.Cygwin module had done before than POSIX, increasingly it was becoming more like POSIX. Concensus was to reject this proposal, but if anyone comes up with a particular application thatn requires a distinction between Cygwin and POSIX style filepaths, then perhaps it could be reopenned. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 12:10:59 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 11:52:55 2009 Subject: [GHC] #3371: Spurious "Defined but not used" when using record wildcards Message-ID: <045.27d6fa5bd2fb93020be76adb054ad300@localhost> #3371: Spurious "Defined but not used" when using record wildcards -----------------------------+---------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Code such as {{{ {-# LANGUAGE RecordWildCards #-} module Test(bar) where data Foo = Foo { a, b :: Int } deriving(Eq) bar Foo{..} = print a }}} produces "defined but not used" warnings for both a and b, when compiled with -Wall. The expected output is that either only a warning for b is given, or none is given. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 13:32:23 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 13:14:25 2009 Subject: [GHC] #367: Infinite loops can hang Concurrent Haskell In-Reply-To: <046.5a2b87104f229d7899f0f85ea5bfdf9e@localhost> References: <046.5a2b87104f229d7899f0f85ea5bfdf9e@localhost> Message-ID: <055.e328caa330b537ecc8ab0915a6eaedfb@localhost> #367: Infinite loops can hang Concurrent Haskell -------------------------------------+-------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.4.1 Severity: normal | Resolution: None Keywords: scheduler allocation | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by SamB): * status: assigned => new * owner: nobody => * cc: SamB (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 13 21:25:57 2009 From: trac at galois.com (GHC) Date: Mon Jul 13 21:08:03 2009 Subject: [GHC] #3282: How to start an emacs editor within ghci asynchronously with :edit filename.hs :set editor emacs & don't go In-Reply-To: <048.be8dd9462b3573e642dcec0dfb5c7624@localhost> References: <048.be8dd9462b3573e642dcec0dfb5c7624@localhost> Message-ID: <057.2e8eba798986e3a80616ffbfc88ea4f2@localhost> #3282: How to start an emacs editor within ghci asynchronously with :edit filename.hs :set editor emacs & don't go ---------------------------------+------------------------------------------ Reporter: petersonx | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by petersonx): reloading the file could be done manually. the wished feature in my eyes is opening an editor asynchronously (and not blocking ghci) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 14 01:34:59 2009 From: trac at galois.com (GHC) Date: Tue Jul 14 01:16:58 2009 Subject: [GHC] #3272: GHC panics when contexts are put late in function types In-Reply-To: <044.48a8ed9c7f42f20ab8f57bc784f391e5@localhost> References: <044.48a8ed9c7f42f20ab8f57bc784f391e5@localhost> Message-ID: <053.5502104aaa53e59df345063c1a70a80f@localhost> #3272: GHC panics when contexts are put late in function types ----------------------------------------+----------------------------------- Reporter: dmwit | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 14 04:18:12 2009 From: trac at galois.com (GHC) Date: Tue Jul 14 04:00:10 2009 Subject: [GHC] #1434: Slow conversion from Double to Int In-Reply-To: <064.721fd4548a9d950dbdd8525731a58ee4@localhost> References: <064.721fd4548a9d950dbdd8525731a58ee4@localhost> Message-ID: <073.b7e7c545e8cfe58f4009a189cb46f373@localhost> #1434: Slow conversion from Double to Int ------------------------------------------+--------------------------------- Reporter: ghc@henning-thielemann.de | Owner: dons Type: task | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: Keywords: rules | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ------------------------------------------+--------------------------------- Changes (by Khudyakov): * cc: alexey.skladnoy@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 14 04:18:46 2009 From: trac at galois.com (GHC) Date: Tue Jul 14 04:00:44 2009 Subject: [GHC] #2271: floor, ceiling, round :: Double -> Int are awesomely slow In-Reply-To: <043.845265305898c52232b3689d70d3b99c@localhost> References: <043.845265305898c52232b3689d70d3b99c@localhost> Message-ID: <052.51877969bd346b8bd4009e720782433b@localhost> #2271: floor, ceiling, round :: Double -> Int are awesomely slow ------------------------------------------+--------------------------------- Reporter: dons | Owner: dons@galois.com Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: performance, math, double | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------------+--------------------------------- Changes (by Khudyakov): * cc: alexey.skladnoy@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 14 13:40:35 2009 From: trac at galois.com (GHC) Date: Tue Jul 14 13:22:33 2009 Subject: [GHC] #3368: Deriving Foldable doesn't work In-Reply-To: <043.07fd00804268a4211b859ee0eb6e08cb@localhost> References: <043.07fd00804268a4211b859ee0eb6e08cb@localhost> Message-ID: <052.c592d2698d520040c3eefe92b598636b@localhost> #3368: Deriving Foldable doesn't work ---------------------------------+------------------------------------------ Reporter: cmcq | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Patches applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 14 13:40:51 2009 From: trac at galois.com (GHC) Date: Tue Jul 14 13:22:49 2009 Subject: [GHC] #3347: Add flag to prevent generation of import libraries on Windows In-Reply-To: <053.8a747ba46b77fc35e5fe19946b0f7d84@localhost> References: <053.8a747ba46b77fc35e5fe19946b0f7d84@localhost> Message-ID: <062.581e1c77f7b9ca3d6ab78c393587e9bd@localhost> #3347: Add flag to prevent generation of import libraries on Windows ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: igloo Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Patch applied (rerecorded to avoid conflict); thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 14 13:42:13 2009 From: trac at galois.com (GHC) Date: Tue Jul 14 13:24:09 2009 Subject: [GHC] #3263: Warnings for monadic values not used In-Reply-To: <051.2ba77802c306560898b377ae21be4ade@localhost> References: <051.2ba77802c306560898b377ae21be4ade@localhost> Message-ID: <060.e4b4ccee2601c46cfd1f343e8208f267@localhost> #3263: Warnings for monadic values not used ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: igloo Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Warnings in the GHC build now all fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 14 13:48:57 2009 From: trac at galois.com (GHC) Date: Tue Jul 14 13:30:51 2009 Subject: [GHC] #2998: Expose the internals of the network library to make it more extensible In-Reply-To: <044.38e242663cf791489f4226de94cd9e56@localhost> References: <044.38e242663cf791489f4226de94cd9e56@localhost> Message-ID: <053.dc2017368c1297220f95f51aeccfa1b8@localhost> #2998: Expose the internals of the network library to make it more extensible ----------------------------------+----------------------------------------- Reporter: tibbe | Owner: igloo Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: tibbe says that this has been done now, with `.Internal`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 14 13:58:56 2009 From: trac at galois.com (GHC) Date: Tue Jul 14 13:40:49 2009 Subject: [GHC] #3121: readline package does not respect Cabal --extra-{include, lib}-dirs flags In-Reply-To: <045.65efa1beaca7b94b94b7ae3c87f65f90@localhost> References: <045.65efa1beaca7b94b94b7ae3c87f65f90@localhost> Message-ID: <054.250982a850ceb79c45cdfad490a3414d@localhost> #3121: readline package does not respect Cabal --extra-{include,lib}-dirs flags ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by igloo): * owner: igloo => Comment: If it doesn't work with cabal-install then we should probably look for a solution that does. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 14 16:08:49 2009 From: trac at galois.com (GHC) Date: Tue Jul 14 15:50:46 2009 Subject: [GHC] #2281: properFraction implemented with modf primitive? In-Reply-To: <044.76024905950f1c976abf1516a4afff90@localhost> References: <044.76024905950f1c976abf1516a4afff90@localhost> Message-ID: <053.e45032d94a726fd9927daacff17ffa71@localhost> #2281: properFraction implemented with modf primitive? ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * type: proposal => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 14 18:25:02 2009 From: trac at galois.com (GHC) Date: Tue Jul 14 18:06:56 2009 Subject: [GHC] #3372: Allow for multiple linker instances Message-ID: <049.b54da97038a1da97405ea7b63a99f067@localhost> #3372: Allow for multiple linker instances -----------------------------+---------------------------------------------- Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Right now there is only one RTS linker with a single symbol table.This means, for example, that one cannot have multiple instances of the GHC interpreter in the same process running simultaneously. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 14 18:31:26 2009 From: trac at galois.com (GHC) Date: Tue Jul 14 18:13:23 2009 Subject: [GHC] #3373: GHC API is not thread safe Message-ID: <049.05da201065b7c5ade7dcf13301c3e81b@localhost> #3373: GHC API is not thread safe -----------------------------+---------------------------------------------- Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: normal | Component: GHC API Version: | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- There are some items of global state (the {{{NameCache}}} and the {{{PackageInterfaceTable}}}) that should be protected. One can workaround this by using a mutex and only invoking GHC API operations in one thread at a time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 14 21:48:44 2009 From: trac at galois.com (GHC) Date: Tue Jul 14 21:30:36 2009 Subject: [GHC] #3374: Profiling libraries are not installed Message-ID: <046.8d56386f212a852d9f6e4247f2bbcfa0@localhost> #3374: Profiling libraries are not installed --------------------+------------------------------------------------------- Reporter: scsibug | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86_64 (amd64) --------------------+------------------------------------------------------- When building GHC from source, profiling libraries are created as requested, but are not installed. I followed the README's instructions, doing "sh boot; ./configure; make; make install". No custom build.mk was used. Attempting to compile programs with the "-prof" option fails, with a message like: Could not find module `System.Random': Perhaps you haven't installed the profiling libraries for package `random-1.0.0.1'? Use -v to see a list of the files searched for. When using the inplace/bin/ghc-stage2 compiler, instead of the installed version, profiled applications can be built without error. Running "make show VALUE=GhcLibWays" in the build directory confirms that it is set to "v p". Inspection of the library directory confirms that "_p.a" library files exist. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 15 09:32:57 2009 From: trac at galois.com (GHC) Date: Wed Jul 15 09:14:48 2009 Subject: [GHC] #3337: Proposal: expose Unicode and newline translation from System.IO In-Reply-To: <047.51c010c54df2cc5daad1df04dbf9cffa@localhost> References: <047.51c010c54df2cc5daad1df04dbf9cffa@localhost> Message-ID: <056.b96b606eaf9d7d7814de865808177346@localhost> #3337: Proposal: expose Unicode and newline translation from System.IO ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Done. {{{ Mon Jul 13 12:31:04 BST 2009 Simon Marlow * Export Unicode and newline functionality from System.IO; update Haddock docs Wed Jul 15 13:22:57 BST 2009 Simon Marlow * Add the utf8_bom codec as suggested during the discussion on the libraries list. Wed Jul 15 13:24:14 BST 2009 Simon Marlow * Add more documentation to mkTextEncoding noting that "//IGNORE" and "//TRANSLIT" suffixes can be used with GNU iconv. Wed Jul 15 13:25:19 BST 2009 Simon Marlow * Add hGetEncoding :: Handle -> IO (Maybe TextEncoding) as suggested during the discussion on the libraries list }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 15 10:34:34 2009 From: trac at galois.com (GHC) Date: Wed Jul 15 10:16:25 2009 Subject: [GHC] #1817: Should be possible to specify pragmas with mixed case In-Reply-To: <044.c4095d9e6406b41062c64e87c778bda3@localhost> References: <044.c4095d9e6406b41062c64e87c778bda3@localhost> Message-ID: <053.f3a5ddb0e362479618ebc3f72873e422@localhost> #1817: Should be possible to specify pragmas with mixed case ----------------------------------+----------------------------------------- Reporter: igloo | Owner: squadette Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Parser) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by squadette): ok, ignore my previous comment and just apply this: http://github.com/squadette/ghc/commit/5a6521cc82e47c1757c498651eb6d77704a3cc48 (http://github.com/squadette/ghc/commit/5a6521cc82e47c1757c498651eb6d77704a3cc48.patch) It contains only LINE-related changes, rebased against your stripPrefix changes. Thank you, -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 15 12:56:29 2009 From: trac at galois.com (GHC) Date: Wed Jul 15 12:38:29 2009 Subject: [GHC] #1548: printf bugs In-Reply-To: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> References: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> Message-ID: <060.d21e14e625c205477f67a7913b070229@localhost> #1548: printf bugs ---------------------------------+------------------------------------------ Reporter: l.mai@web.de | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by squadette): * cc: squadette@gmail.com (added) Comment: I believe this patch fixes the third problem (precision matters for integral arguments too!) http://mynd.rinet.ru/~alexm/ghc-1548.patch Also, I've added the "Language CPP" pragma: Text/Printf.hs has #ifdef inside! Consider applying, Thank you, -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 15 15:49:59 2009 From: trac at galois.com (GHC) Date: Wed Jul 15 15:31:49 2009 Subject: [GHC] #3070: floor(0/0) should not be defined In-Reply-To: <046.e7310ec88130e4aef68644b0cf077a3b@localhost> References: <046.e7310ec88130e4aef68644b0cf077a3b@localhost> Message-ID: <055.e4eece4d272a045fc3f8eec0f5ac1f29@localhost> #3070: floor(0/0) should not be defined ---------------------------------+------------------------------------------ Reporter: carette | Owner: squadette Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Prelude | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by squadette): * owner: => squadette * cc: squadette@gmail.com (added) Comment: Same thing happens with exponent, significand, scaleFloat, truncate, round, and ceiling. I believe this patch should fix the problem: http://mynd.rinet.ru/~alexm/floor-3070.patch 1. Of course, we get some performance hit, with two ifs for every call to those functions, and the appearance of `undefined' (may it confuse the optimizer somehow?) However, most of them seem to be not very performance oriented (except maybe for scaleFloat). 2. However, I believe that getting significand (0/0) = -0.75 is not right, however fast it is. 3. withValidDouble could probably be made a monad of some sort? 4. properFraction should be reindented if this patch is applied. I did not make it to minimize changes. 5. maybe we need a special compiler flag which means "do not bother checking floats for validity, let the user handle details. Thank you, -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 15 16:30:31 2009 From: trac at galois.com (GHC) Date: Wed Jul 15 16:12:21 2009 Subject: [GHC] #3070: floor(0/0) should not be defined In-Reply-To: <046.e7310ec88130e4aef68644b0cf077a3b@localhost> References: <046.e7310ec88130e4aef68644b0cf077a3b@localhost> Message-ID: <055.6d4d73ebe6214fdb83a3cb0e79a43b66@localhost> #3070: floor(0/0) should not be defined ---------------------------------+------------------------------------------ Reporter: carette | Owner: squadette Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Prelude | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by squadette): Well, it seems like this whole idea of correctness really contradicts some folks' expectations about speed: http://hackage.haskell.org/trac/ghc/ticket/2271 http://hackage.haskell.org/trac/ghc/ticket/1434 ("This is really a problem for me when doing signal processing, since for writing to a common audio file format or listening to a signal data has to be converted from Double to Int16.") http://hackage.haskell.org/trac/ghc/ticket/2281 If we add even more specializations for primitive types, what will happen to correctness? Haskell 98 seems to ignore the question of invalid floating point arguments, however recognizing the existence of NaNs :) Maybe we should just explicitly state somewhere that we sacrifice correctness to speed wrt Float <-> Int domain discrepancies. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 15 22:38:20 2009 From: trac at galois.com (GHC) Date: Wed Jul 15 22:20:11 2009 Subject: [GHC] #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use Message-ID: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use -----------------------------+---------------------------------------------- Reporter: seliopou | Owner: seliopou Type: feature request | Status: new Priority: normal | Component: Build System Version: 6.10.3 | Severity: trivial Keywords: darcs git | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The {{{darcs-all}}} script currently assumes that it is being run from the top level of a darcs repository. It uses the repository location stored in {{{_darcs/prefs/defaultrepo}}} to determine from where to get the other repositories that GHC depends on. The assumption that the script is being run from a darcs repository is unnecessary and is a hindrance to people who wish to use the git mirror of the GHC repository. To make this script more flexible, and to allow git users to use the repository without having to hack this script, I propose adding to the script a {{{-r}}} option, which itself takes as an argument the location of a darcs repository from which to get GHC's dependencies. This option would be useful for darcs users as it would allow them to get, pull, or push from any darcs repository they wish. It would also be useful to git users, as it would allow them to quickly get started working on GHC by using the command {{{./darcs-all -r http://darcs.haskell.org/ghc get}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 16 04:55:01 2009 From: trac at galois.com (GHC) Date: Thu Jul 16 04:36:50 2009 Subject: [GHC] #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use In-Reply-To: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> References: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> Message-ID: <056.bd97f948065727a7fbfebb77a179d8da@localhost> #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use ---------------------------------+------------------------------------------ Reporter: seliopou | Owner: seliopou Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: darcs git | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: There is some overlap with `push-all` here. `push-all` can push, pull, and send, but not get. I use it a lot for pushing and pulling to/from different repository trees. Perhaps push-all should be merged with darcs-all? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 16 05:01:38 2009 From: trac at galois.com (GHC) Date: Thu Jul 16 04:43:27 2009 Subject: [GHC] #3070: floor(0/0) should not be defined In-Reply-To: <046.e7310ec88130e4aef68644b0cf077a3b@localhost> References: <046.e7310ec88130e4aef68644b0cf077a3b@localhost> Message-ID: <055.057928a23892c239a37526939c5af51e@localhost> #3070: floor(0/0) should not be defined ---------------------------------+------------------------------------------ Reporter: carette | Owner: squadette Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Prelude | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by squadette): or, the problem is purely of expectations. People are used to the fact that evaluating 0/0 gives Division by zero runtime error. Haskell however is so lazy that it does not bother exiting. Maybe a special command line argument is needed -- terminate on invalid FP operations. This could be useful for beginners, gentle introductions and such. As for the day-to-day programming we just declare that Double cannot be converted to integral types anyway, so a) invalid operations give NaN, and b) all the functions will give you literal garbage when out of the target range (incl. NaN and Infinity). AFAIU floating point developers are used to manage evaluation details carefully anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 16 05:03:44 2009 From: trac at galois.com (GHC) Date: Thu Jul 16 04:45:34 2009 Subject: [GHC] #3376: test Message-ID: <047.cee9a71c821c0437651ff890d4924297@localhost> #3376: test -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- test -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 16 10:54:19 2009 From: trac at galois.com (GHC) Date: Thu Jul 16 10:36:05 2009 Subject: [GHC] #3122: Enhance --info In-Reply-To: <044.9e71a36a06ffc4f0a9385ad48ed342a2@localhost> References: <044.9e71a36a06ffc4f0a9385ad48ed342a2@localhost> Message-ID: <053.56e27dc78989a5c27ebd639e77c62d03@localhost> #3122: Enhance --info ---------------------------------+------------------------------------------ Reporter: igloo | Owner: duncan Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: igloo => duncan Comment: I've done the `--print-foo` part of this ticket. The gcc situation is rather complex. We have {{{ pgm_c :: (String,[Option]) opt_c :: [String] }}} and we also do this when running gcc: {{{ -- If the -B option is set, add to PATH. This works around -- a bug in gcc on Windows Vista where it can't find its auxiliary -- binaries (see bug #1110). getGccEnv :: [Option] -> IO (Maybe [(String,String)]) getGccEnv opts = if null b_dirs then return Nothing else do env <- getEnvironment return (Just (map mangle_path env)) where (b_dirs, _) = partitionWith get_b_opt opts get_b_opt (Option ('-':'B':dir)) = Left dir get_b_opt other = Right other mangle_path (path,paths) | map toUpper path == "PATH" = (path, '\"' : head b_dirs ++ "\";" ++ paths) mangle_path other = other }}} Likewise for cpp, as and ld. What exactly does Cabal want to know? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 16 12:21:57 2009 From: trac at galois.com (GHC) Date: Thu Jul 16 12:03:46 2009 Subject: [GHC] #3376: hpc and CPP don't mix on Windows Message-ID: <044.6ac0df9e14fafd4394d0f7a94cb2ccc6@localhost> #3376: hpc and CPP don't mix on Windows ----------------------------+----------------------------------------------- Reporter: igloo | Owner: andy@galois.com Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Code Coverage | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Windows | Architecture: Unknown/Multiple ----------------------------+----------------------------------------------- Originaly reported by Dominic Steinitz here: http://www.haskell.org/pipermail/glasgow-haskell- users/2009-July/017511.html On Windows, with these files: CommonHPC.hs: {{{ module Main (main) where import Common main = do test test test = do putStrLn $ show $ fact 4 putStrLn $ show $ fact 5 }}} Common.hs: {{{ module Common (fact) where fact 0 = 1 fact n = n * fact (n-1) }}} This works: {{{ $ ghc -fhpc --make CommonHPC $ ./CommonHPC $ cat CommonHPC.exe.tix Tix [ TixModule "Main" 693125724 18 [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1], TixModule "Common" 4136915291 8 [2,9,9,9,9,9,9,11]] }}} but with `-cpp` we get no ticks for Common: {{{ $ ghc -fhpc --make CommonHPC -cpp $ ./CommonHPC $ cat CommonHPC.exe.tix Tix [ TixModule "Main" 693125724 18 [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1], TixModule "Common" 3370079577 0 []] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 16 19:21:25 2009 From: trac at galois.com (GHC) Date: Thu Jul 16 19:03:12 2009 Subject: [GHC] #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use In-Reply-To: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> References: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> Message-ID: <056.b95c244405aa527e31fef206580cc268@localhost> #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use ---------------------------------+------------------------------------------ Reporter: seliopou | Owner: seliopou Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: darcs git | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by seliopou): I believe {{{darcs-all}}} can do everything that {{{push-all}}} can do as long as {{{darcs-all}}} can take a repository location as an argument. If my patch is accepted, {{{push-all}}} can simply be deleted. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 16 19:54:08 2009 From: trac at galois.com (GHC) Date: Thu Jul 16 19:35:54 2009 Subject: [GHC] #3271: New methods for Data.Sequence In-Reply-To: <053.cc9895e43857ea386bfb254a48e9e83f@localhost> References: <053.cc9895e43857ea386bfb254a48e9e83f@localhost> Message-ID: <062.bf69a30b8cb8d8af353446f045ab5ef6@localhost> #3271: New methods for Data.Sequence ----------------------------------+----------------------------------------- Reporter: LouisWasserman | Owner: LouisWasserman Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by LouisWasserman): In response to Ross's useful suggestions (which I had not actually noticed until recently), I have made considerable changes to my Data.Sequence patch here. Here are the relevant points: * I completely rewrote the sorting method. The sort is unstable, but it is 40 lines (much more maintainable than the several-hundred line implementation from earlier) and runs *twice as fast as* (fromList . Data.List.sort . toList) for n=50000. (For sorted lists, it clocks in at about 4x faster.) o This is with no RTS options. With -H128m, the advantage is considerably thinner -- 39ms vs. 43ms (about one standard deviation) -- but the implementation is sufficiently compact that the moderate benefit is satisfactory. * tails and inits are considerably more sophisticated, running to about 50 lines apiece (although some of that code is shared between them), but o This implementation is genuinely asymptotically faster than the previous implementation: evaluating any tail from the sequence returned by tails takes O(log (min (i, n-i))), as opposed to O(n) in scanr (<|) empty xs, but evaluating every tail from the sequence takes O(n) overall, as opposed to O(n log n) in fromList [drop n xs | n <- [0..length xs]]. o Without direct access to the internals of the sequence it is impossible to match the asymptotic performance of this implementation. o This implementation is also a hair faster in practice. * partition is now in fact implemented via a simple foldl', which is actually faster than my old, several-dozen-line implementation as well as obviously simpler. * filter has been added to the list of methods available in Data.Sequence. * iterate has been renamed to iterateN to reinforce the different type, which requires a finite bound on the sequence length. * On the back end, replicate, iterateN, and sortBy do not use fromList, but instead use a common framework that wraps construction of a sequence in an Applicative functor. This automatically induces the node sharing that gives replicate performance O(log n), but behaves exactly correctly for all its other requirements. * As a result, there is a faster alternative to fromList if the length of the list is known. The name and type of this method seems like it might become genuinely contentious, so I'm not inclined to expose that faster method at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 00:09:56 2009 From: trac at galois.com (GHC) Date: Thu Jul 16 23:51:43 2009 Subject: [GHC] #964: Cross Compile and Universal Binary In-Reply-To: <070.aac5ee31b362526bf71e8f397562d506@localhost> References: <070.aac5ee31b362526bf71e8f397562d506@localhost> Message-ID: <079.e4ca4d3addf27d1d37d042ee1e7d47f6@localhost> #964: Cross Compile and Universal Binary ------------------------------------------------+--------------------------- Reporter: shelarcy@capella.freemail.ne.jp | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: critical | Resolution: Keywords: | Difficulty: Project (> 1 week) Testcase: N/A | Os: MacOS X Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Comment (by jsnow): Let me just say "me too". I'd like to at least be able to cross-compile from x86 to x86-64 and vice versa. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 04:24:09 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 04:06:06 2009 Subject: [GHC] #1548: printf bugs In-Reply-To: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> References: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> Message-ID: <060.c7ae0656208dbaa38522913e7cb4a733@localhost> #1548: printf bugs ---------------------------------+------------------------------------------ Reporter: l.mai@web.de | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Lennart, any comments? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 04:31:24 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 04:13:10 2009 Subject: [GHC] #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use In-Reply-To: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> References: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> Message-ID: <056.c08b6d9c9e0fcc2303c457b858ca8965@localhost> #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use ---------------------------------+------------------------------------------ Reporter: seliopou | Owner: seliopou Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: darcs git | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): It's not quite there, I think: $repo_base is not used inside darcsall(), so if you do {{{ ./darcs-all -r some-other-repo push }}} the -r option has no effect. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 08:07:17 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 07:49:09 2009 Subject: [GHC] #3306: Improve syntax for GADT + records In-Reply-To: <046.d67bbf39466d205ecf2349957e851ca2@localhost> References: <046.d67bbf39466d205ecf2349957e851ca2@localhost> Message-ID: <055.30b76b6aadff7977aa4e10361cc1b40e@localhost> #3306: Improve syntax for GADT + records ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: simonpj Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: In fact I'd even committed that patch, so I declare this done: {{{ Thu Jul 2 10:46:57 BST 2009 simonpj@microsoft.com * New syntax for GADT-style record declarations, and associated refactoring The main purpose of this patch is to fix Trac #3306, by fleshing out the syntax for GADT-style record declraations so that you have a context in the type. The new form is data T a where MkT :: forall a. Eq a => { x,y :: !a } -> T a See discussion on the Trac ticket. The old form is still allowed, but give a deprecation warning. When we remove the old form we'll also get rid of the one reduce/reduce error in the grammar. Hurrah! While I was at it, I failed as usual to resist the temptation to do lots of refactoring. The parsing of data/type declarations is now much simpler and more uniform. Less code, less chance of errors, and more functionality. Took longer than I planned, though. ConDecl has record syntax, but it was not being used consistently, so I pushed that through the compiler. M ./compiler/deSugar/DsMeta.hs -4 +4 M ./compiler/hsSyn/Convert.lhs -20 +29 M ./compiler/hsSyn/HsDecls.lhs -23 +26 M ./compiler/hsSyn/HsTypes.lhs -2 +21 M ./compiler/parser/HaddockUtils.hs -6 +5 M ./compiler/parser/Parser.y.pp -143 +64 M ./compiler/parser/ParserCore.y -21 +14 M ./compiler/parser/RdrHsSyn.lhs -188 +205 M ./compiler/rename/RnHsSyn.lhs +1 M ./compiler/rename/RnSource.lhs -65 +56 M ./compiler/rename/RnTypes.lhs -5 +19 M ./compiler/typecheck/TcHsType.lhs -4 +12 M ./compiler/typecheck/TcTyClsDecls.lhs -3 +6 M ./docs/users_guide/glasgow_exts.xml -19 +60 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 10:12:54 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 09:54:39 2009 Subject: [GHC] #1817: Should be possible to specify pragmas with mixed case In-Reply-To: <044.c4095d9e6406b41062c64e87c778bda3@localhost> References: <044.c4095d9e6406b41062c64e87c778bda3@localhost> Message-ID: <053.3312eeeee30ab590fd85c49d544a917a@localhost> #1817: Should be possible to specify pragmas with mixed case ----------------------------------+----------------------------------------- Reporter: igloo | Owner: squadette Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler (Parser) | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 12:06:37 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 11:48:26 2009 Subject: [GHC] #3346: Strange and incorrect type error when using rewrite rules with type families In-Reply-To: <046.8516030065369a83577dc50b430a1824@localhost> References: <046.8516030065369a83577dc50b430a1824@localhost> Message-ID: <055.134ccdd631578ab1389f0b009c0fae08@localhost> #3346: Strange and incorrect type error when using rewrite rules with type families -----------------------------------------------+---------------------------- Reporter: dreixel | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T3346 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------------+---------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T3346 * status: new => closed * resolution: => fixed Comment: You are right, that is bogus. Fixed by {{{ Fri Jul 17 16:57:22 BST 2009 simonpj@microsoft.com * Fix Trac #3346: tcSimplify for LHS of RULES with type equalities M ./compiler/typecheck/TcSimplify.lhs -2 +12 }}} There was special handling for constraints on the LHS of a RULE, which hadn't been updated to account for type families. Thanks for the report. I've added a regression test Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 16:53:23 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 16:35:08 2009 Subject: [GHC] #2954: System.Process.terminateProcess sends SIGTERM rather than SIGKILL on unix In-Reply-To: <044.33b296bee16ac04eb53e73148864ea5b@localhost> References: <044.33b296bee16ac04eb53e73148864ea5b@localhost> Message-ID: <053.4e5fd4ee056aa9b7e02fee669a7943ce@localhost> #2954: System.Process.terminateProcess sends SIGTERM rather than SIGKILL on unix ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/process | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 18:21:41 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 18:03:26 2009 Subject: [GHC] #3055: Int / Word / IntN / WordN are unequally optimized In-Reply-To: <044.1c39597802e7cddf9bd2ebc2460d51ee@localhost> References: <044.1c39597802e7cddf9bd2ebc2460d51ee@localhost> Message-ID: <053.9c327380dd6ad3c94f3ff97af557f1c0@localhost> #3055: Int / Word / IntN / WordN are unequally optimized -----------------------------------------+---------------------------------- Reporter: claus | Owner: igloo Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 18:37:16 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 18:18:59 2009 Subject: [GHC] #3377: [Patch] Support Python-style tuple sections Message-ID: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> #3377: [Patch] Support Python-style tuple sections -----------------------------+---------------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Support Python-style tuple sections: {{{ >>> (, True, "Hello", ) 1 "World" (1, True, "Hello", "World") }}} The attached patches implement this syntax for both boxed and unboxed tuples, and include tests and documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 18:45:15 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 18:26:58 2009 Subject: [GHC] #3051: Add product/sum/maximum/minimum specialisations for more atomic types In-Reply-To: <050.4cbbe590f771bebce8bcbc747d03bc73@localhost> References: <050.4cbbe590f771bebce8bcbc747d03bc73@localhost> Message-ID: <059.bd42f7ad2afd0da4a0fbd9e0eec3eb76@localhost> #3051: Add product/sum/maximum/minimum specialisations for more atomic types ---------------------------------+------------------------------------------ Reporter: thorkilnaur | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => duplicate Comment: Closing, as this ticket is subsumed by #3055. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 18:45:57 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 18:27:42 2009 Subject: [GHC] #2270: gcd is specialised only for Int In-Reply-To: <043.b1b4c47bccdeb536ea28564b64a56127@localhost> References: <043.b1b4c47bccdeb536ea28564b64a56127@localhost> Message-ID: <052.0b08d83b7a7ed7803d7973bc4e8a24f4@localhost> #2270: gcd is specialised only for Int ------------------------------------------------+--------------------------- Reporter: dons | Owner: dons@galois.com Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: rules, performance, double, gcd | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Changes (by igloo): * status: new => closed * resolution: => duplicate Comment: Closing, as this ticket is subsumed by #3055. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 18:51:08 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 18:32:55 2009 Subject: [GHC] #3378: [Patch] Make 'group' into a special ID when TransformListComp is on Message-ID: <053.bb0c2863cc6b81c9d59a0b979dc0de10@localhost> #3378: [Patch] Make 'group' into a special ID when TransformListComp is on -----------------------------+---------------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- {{{ -- >>> | 'then' exp 'by' exp { LL $ \leftStmts -> (mkTransformByStmt (reverse leftStmts) $2 $4) } | 'then' 'group' 'by' exp { LL $ \leftStmts -> (mkGroupByStmt (reverse leftStmts) $4) } -- <<< -- These two productions deliberately have a shift-reduce conflict. I have made 'group' into a special_id, -- which means you can enable TransformListComp while still using Data.List.group. However, this makes the two -- productions ambiguous. I've set things up so that Happy chooses to resolve the conflict in that case by -- choosing the "group by" variant, which is what we want. -- -- This is rather dubious: the user might be confused as to how to parse this statement. However, it is a good -- practical choice. NB: Data.List.group :: [a] -> [[a]], so using the first production would not even type check -- if /that/ is the group function we conflict with. }}} Take it or leave it :). Probably a win in practice. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 19:11:12 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 18:52:55 2009 Subject: [GHC] #3379: GHC should use the standard binary package Message-ID: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@localhost> #3379: GHC should use the standard binary package -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- GHC should use the standard binary package, rather than reimplementing its functionality itself. If the current binary package is slower than GHC's Binary, then we should fix that. There's some discussion about this in #3041. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 19:11:44 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 18:53:29 2009 Subject: [GHC] #3041: Arch independent binary representations In-Reply-To: <046.ec9add4015adc692796a9426b46aeec0@localhost> References: <046.ec9add4015adc692796a9426b46aeec0@localhost> Message-ID: <055.d93004ac34f12093b77ef85fa2a16353@localhost> #3041: Arch independent binary representations ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I've made Int's get serialized as Int64, and opened #3379 for making GHC use the standard binary package. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 19:16:54 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 18:58:39 2009 Subject: [GHC] #3088: have ghc-pkg print less useless info when registering In-Reply-To: <045.a08b0a44980955bc3fea79b4658f5193@localhost> References: <045.a08b0a44980955bc3fea79b4658f5193@localhost> Message-ID: <054.d99d9990b477c4dc67d92aa4a4ad600b@localhost> #3088: have ghc-pkg print less useless info when registering ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Package system | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: ghc-pkg now has a verbosity flag, and at verbosity level 0 it won't print those messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:21:47 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:03:31 2009 Subject: [GHC] #3206: Redhat EL 5 ghc-6.8.3: internal error: getMBlock: mmap: Permission denied In-Reply-To: <048.13ce0c84cab41116f3aa554bc7977596@localhost> References: <048.13ce0c84cab41116f3aa554bc7977596@localhost> Message-ID: <057.024c7b0e494fadf83e26286bc4ca85db@localhost> #3206: Redhat EL 5 ghc-6.8.3: internal error: getMBlock: mmap: Permission denied --------------------------------------+------------------------------------- Reporter: Dmitry123 | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.12.1 Component: Runtime System | Version: 6.8.3 Severity: normal | Resolution: worksforme Keywords: getMBlock mmap denied | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | --------------------------------------+------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: No response, so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:23:52 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:06:00 2009 Subject: [GHC] #3178: Fix linking -lpthread for semaphores In-Reply-To: <047.4c07ab6c1ca5f755c6e1425bd544758d@localhost> References: <047.4c07ab6c1ca5f755c6e1425bd544758d@localhost> Message-ID: <056.ec41a80a14962bd154985834fe97953a@localhost> #3178: Fix linking -lpthread for semaphores ---------------------------------+------------------------------------------ Reporter: sthibaul | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/unix | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Other Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: low => normal * milestone: 6.12.1 => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:26:10 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:08:01 2009 Subject: [GHC] #2031: relocation overflow In-Reply-To: <045.02b5c8981d759aa3391df46bf05998bf@localhost> References: <045.02b5c8981d759aa3391df46bf05998bf@localhost> Message-ID: <054.5efba6215244ae7fc0d714ed9f352e0c@localhost> #2031: relocation overflow -------------------------+-------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | -------------------------+-------------------------------------------------- Changes (by igloo): * priority: low => normal * milestone: 6.12.1 => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:32:31 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:14:22 2009 Subject: [GHC] #3132: x86 code generator generates bad FPU register names In-Reply-To: <044.486f0fa3ddd7b77dad74344aee019e46@localhost> References: <044.486f0fa3ddd7b77dad74344aee019e46@localhost> Message-ID: <053.b6a8c5f1ebae0992301b3a44922f70ca@localhost> #3132: x86 code generator generates bad FPU register names -------------------------------+-------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * status: reopened => new * owner: nobody => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:33:20 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:15:05 2009 Subject: [GHC] #68: Warnings for unitialized fields In-Reply-To: <045.557e7250f2a1db18e5acbe51a391714e@localhost> References: <045.557e7250f2a1db18e5acbe51a391714e@localhost> Message-ID: <054.10adcf17bd5aac9fd73dea50f4eb31c3@localhost> #68: Warnings for unitialized fields ---------------------------------+------------------------------------------ Reporter: nobody | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: minor | Resolution: None Keywords: warnings | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * testcase: => * status: assigned => new * owner: nobody => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:33:25 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:15:08 2009 Subject: [GHC] #110: Cygwin binaries In-Reply-To: <046.e27078d66dc3ce56ae08f6163d6a3403@localhost> References: <046.e27078d66dc3ce56ae08f6163d6a3403@localhost> Message-ID: <055.76e768877b6332630157e9cc0ce20e86@localhost> #110: Cygwin binaries ---------------------------------+------------------------------------------ Reporter: fizzgig | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: None | Version: None Severity: minor | Resolution: None Keywords: | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: assigned => new * owner: nobody => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:33:31 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:15:14 2009 Subject: [GHC] #285: hp-ux 11.11 binaries In-Reply-To: <044.973042cd7618270d83934312097da719@localhost> References: <044.973042cd7618270d83934312097da719@localhost> Message-ID: <053.a1ea735f06eca648d151d8fa5414d171@localhost> #285: hp-ux 11.11 binaries --------------------------------+------------------------------------------- Reporter: amyhr | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: None | Version: None Severity: minor | Resolution: None Keywords: | Difficulty: Unknown Testcase: N/A | Os: HPUX Architecture: hppa | --------------------------------+------------------------------------------- Changes (by igloo): * status: assigned => new * owner: nobody => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:33:35 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:15:22 2009 Subject: [GHC] #288: amd64-FreeBSD-5.3 port? In-Reply-To: <045.aaebc23b15b0d0e8b18e01239168049e@localhost> References: <045.aaebc23b15b0d0e8b18e01239168049e@localhost> Message-ID: <054.b4a0af0e5d477491c93f7bdaf031a18d@localhost> #288: amd64-FreeBSD-5.3 port? --------------------------------+------------------------------------------- Reporter: nobody | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: None | Version: None Severity: minor | Resolution: None Keywords: | Difficulty: Unknown Testcase: N/A | Os: FreeBSD Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by igloo): * status: assigned => new * owner: nobody => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:33:54 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:15:38 2009 Subject: [GHC] #288: amd64-FreeBSD-5.3 port? In-Reply-To: <045.aaebc23b15b0d0e8b18e01239168049e@localhost> References: <045.aaebc23b15b0d0e8b18e01239168049e@localhost> Message-ID: <054.292b293d6e74b8052e11fcaafca80dea@localhost> #288: amd64-FreeBSD-5.3 port? --------------------------------+------------------------------------------- Reporter: nobody | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: None | Version: None Severity: minor | Resolution: None Keywords: | Difficulty: Unknown Testcase: N/A | Os: FreeBSD Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:34:45 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:16:31 2009 Subject: [GHC] #420: O'Haskell In-Reply-To: <043.85eea6d2fdc5ea4d79df32edc41b4340@localhost> References: <043.85eea6d2fdc5ea4d79df32edc41b4340@localhost> Message-ID: <052.6b68fedaab491ae35d2c8f9515e5633b@localhost> #420: O'Haskell ---------------------------------+------------------------------------------ Reporter: mlbm | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: None | Version: None Severity: minor | Resolution: None Keywords: | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: assigned => new * owner: nobody => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:34:39 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:16:32 2009 Subject: [GHC] #366: incomplete patterns and GADT In-Reply-To: <045.78fabe56a37c24d921b345c081d108ef@localhost> References: <045.78fabe56a37c24d921b345c081d108ef@localhost> Message-ID: <054.a51038f13b3eb9fedf8a390f0bfc3bc3@localhost> #366: incomplete patterns and GADT ---------------------------------+------------------------------------------ Reporter: nobody | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: minor | Resolution: None Keywords: | Difficulty: Unknown Testcase: tc215 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: assigned => new * owner: nobody => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:34:42 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:16:33 2009 Subject: [GHC] #368: Provide a Java Backend In-Reply-To: <049.9a5162d2cca544679bf8d2366946a80b@localhost> References: <049.9a5162d2cca544679bf8d2366946a80b@localhost> Message-ID: <058.ae6e8c06be3bce79ebf270be88753cd0@localhost> #368: Provide a Java Backend ---------------------------------+------------------------------------------ Reporter: rainbowang | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: minor | Resolution: None Keywords: | Difficulty: Project (> 1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: assigned => new * owner: nobody => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:34:50 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:16:37 2009 Subject: [GHC] #472: Supertyping of classes In-Reply-To: <045.6b3e08abba3cef5f928c39765d3026d0@localhost> References: <045.6b3e08abba3cef5f928c39765d3026d0@localhost> Message-ID: <054.4989257a69a2ef5e3b45ef1b04514214@localhost> #472: Supertyping of classes ----------------------------------------+----------------------------------- Reporter: nobody | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: None Severity: minor | Resolution: None Keywords: | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by igloo): * status: assigned => new * owner: nobody => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:34:55 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:16:40 2009 Subject: [GHC] #487: powerpc/linux segfaulting binaries In-Reply-To: <043.e4c96af6f7160fcdea6756f17c3ec89f@localhost> References: <043.e4c96af6f7160fcdea6756f17c3ec89f@localhost> Message-ID: <052.2eba9dd0110993271f4696e6310beaf0@localhost> #487: powerpc/linux segfaulting binaries -------------------------+-------------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: N/A | Os: Linux Architecture: powerpc | -------------------------+-------------------------------------------------- Changes (by igloo): * status: assigned => new * owner: nobody => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:34:59 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:16:44 2009 Subject: [GHC] #307: Implicit Parameters and monomorphism In-Reply-To: <045.f699d0b39fe45c4e63292f1f2f68cc42@localhost> References: <045.f699d0b39fe45c4e63292f1f2f68cc42@localhost> Message-ID: <054.d65ee1c5a3089659924157c958784aa5@localhost> #307: Implicit Parameters and monomorphism ---------------------------------+------------------------------------------ Reporter: nobody | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: None | Version: None Severity: minor | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: assigned => new * owner: nobody => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:35:05 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:16:50 2009 Subject: [GHC] #565: overlapping instances & fundeps broken In-Reply-To: <047.be51df89a55fc16684527ec6b862b817@localhost> References: <047.be51df89a55fc16684527ec6b862b817@localhost> Message-ID: <056.ff5d90c23f235e29bc839c1ff8a22d9d@localhost> #565: overlapping instances & fundeps broken ----------------------------------------+----------------------------------- Reporter: ashley-y | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler (Type checker) | Version: 5.00 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by igloo): * status: assigned => new * owner: nobody => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:35:03 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:16:53 2009 Subject: [GHC] #485: AdjustorAsm.S doesn't build on AIX In-Reply-To: <047.348c1b9e6ebc7759d7861925cfd6ccd1@localhost> References: <047.348c1b9e6ebc7759d7861925cfd6ccd1@localhost> Message-ID: <056.c4bcc88006605315577df63fc8b7ec24@localhost> #485: AdjustorAsm.S doesn't build on AIX ---------------------------------+------------------------------------------ Reporter: jgoerzen | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.4.1 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: N/A | Os: AIX Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: assigned => new * owner: nobody => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:35:25 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:17:08 2009 Subject: [GHC] #17: RFE:Separate unused-binds local/top-level In-Reply-To: <047.fe4cdb312b5d86f34d27df1115f2c91a@localhost> References: <047.fe4cdb312b5d86f34d27df1115f2c91a@localhost> Message-ID: <056.05c14c81e1ad425eafc3232092168376@localhost> #17: RFE:Separate unused-binds local/top-level ------------------------------------+--------------------------------------- Reporter: magunter | Owner: igloo Type: feature request | Status: new Priority: lowest | Milestone: _|_ Component: None | Version: None Severity: minor | Resolution: None Keywords: -fwarn-unused-binds | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * testcase: => * status: assigned => new * owner: nobody => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:35:32 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:17:15 2009 Subject: [GHC] #29: Check for exhaustive patterns is broken In-Reply-To: <045.9dc542783fd9cde38eba0be02a5527cd@localhost> References: <045.9dc542783fd9cde38eba0be02a5527cd@localhost> Message-ID: <054.6bebdfd095ec6224675980dba3a9eabc@localhost> #29: Check for exhaustive patterns is broken ---------------------------------+------------------------------------------ Reporter: nobody | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: 5.02 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: assigned => new * owner: nobody => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:35:37 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:17:20 2009 Subject: [GHC] #552: GHCi :m doesn't restore default decl In-Reply-To: <046.8fe84617c76248de33d1df0f58763c7d@localhost> References: <046.8fe84617c76248de33d1df0f58763c7d@localhost> Message-ID: <055.f4b018c3080d56643c3917087d9011e2@localhost> #552: GHCi :m doesn't restore default decl ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: GHCi | Version: 5.00 Severity: normal | Resolution: None Keywords: | Difficulty: Unknown Testcase: ghci016 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: assigned => new * owner: nobody => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:35:43 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:17:26 2009 Subject: [GHC] #17: RFE:Separate unused-binds local/top-level In-Reply-To: <047.fe4cdb312b5d86f34d27df1115f2c91a@localhost> References: <047.fe4cdb312b5d86f34d27df1115f2c91a@localhost> Message-ID: <056.fbb50f181d3ffe933dc8408eb6ab010c@localhost> #17: RFE:Separate unused-binds local/top-level ------------------------------------+--------------------------------------- Reporter: magunter | Owner: Type: feature request | Status: new Priority: lowest | Milestone: _|_ Component: None | Version: None Severity: minor | Resolution: None Keywords: -fwarn-unused-binds | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * owner: igloo => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:40:35 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:22:23 2009 Subject: [GHC] #3380: [Patch] Support implicit concatenation in list comprehensions Message-ID: <053.31375e41dd51007462e20df85979f732@localhost> #3380: [Patch] Support implicit concatenation in list comprehensions -----------------------------+---------------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Using the -XImplicitConcatListComp option turns on implicit concatenation in list comprehensions. What this means is that you can write several things separated by commas in the "body" of a list comprehension, like so {{{ [x, x | x <- [1..10], x `mod` 2 == 0] }}} This program produces the following output {{{ [2, 2, 4, 4, 6, 6, 8, 8] }}} The effect is the same as if you had written {{{ concat [[x, x] | x <- [1..10], x `mod` 2 == 0] }}} but more concise, and more likely to be optimised well by the compiler. NB: this was originally proposed in the SQL-like list comprehensions paper. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:42:19 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:24:02 2009 Subject: [GHC] #3379: GHC should use the standard binary package In-Reply-To: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@localhost> References: <044.fa4dfe8be6394c3f94f6b68d8a40f5e7@localhost> Message-ID: <053.2d2e7731087d59759117bdbbca506964@localhost> #3379: GHC should use the standard binary package ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by batterseapower): Annotations should also use the standard binary package for serialisation if it becomes a boot library. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 17 20:42:43 2009 From: trac at galois.com (GHC) Date: Fri Jul 17 20:24:27 2009 Subject: [GHC] #3380: [Patch] Support implicit concatenation in list comprehensions In-Reply-To: <053.31375e41dd51007462e20df85979f732@localhost> References: <053.31375e41dd51007462e20df85979f732@localhost> Message-ID: <062.311700874c1ba374369a897d27a67dcf@localhost> #3380: [Patch] Support implicit concatenation in list comprehensions ------------------------------+--------------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by batterseapower): * cc: ndmitchell@gmail.com, batterseapower@hotmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 18 06:22:02 2009 From: trac at galois.com (GHC) Date: Sat Jul 18 06:03:45 2009 Subject: [GHC] #3380: [Patch] Support implicit concatenation in list comprehensions In-Reply-To: <053.31375e41dd51007462e20df85979f732@localhost> References: <053.31375e41dd51007462e20df85979f732@localhost> Message-ID: <062.f6a0bd58e58c062b4eeee6320a72cf61@localhost> #3380: [Patch] Support implicit concatenation in list comprehensions ------------------------------+--------------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by batterseapower): NB: this generalises to instances of MonadPlus, but I can't think of a nice-looking syntax. {{{ [e1, e2 | qs] = concat [[e1, e2] | qs] = join [return e1 `mplus` return e2 | qs] }}} This is pretty easy to implement as long as you can come up with the syntax. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 18 08:49:47 2009 From: trac at galois.com (GHC) Date: Sat Jul 18 08:31:29 2009 Subject: [GHC] #3381: PROPOSAL: Remove Control.OldException Message-ID: <044.bea515c2e882a187756034c0cc466b95@localhost> #3381: PROPOSAL: Remove Control.OldException -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- We included `Control.OldException` in base to help people trying to remain compatible with both GHC 6.8 and GHC 6.10. However, my impression is that most (all?) people who wanted compatibility used the `extensible- exceptions` package instead. I propose that we remove `Control.OldException` for GHC 6.12. If anyone does want `Control.OldException`, then it could be provided by a separate package. Deadline: 2nd August (2 weeks). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 18 09:11:37 2009 From: trac at galois.com (GHC) Date: Sat Jul 18 08:53:20 2009 Subject: [GHC] #3380: [Patch] Support implicit concatenation in list comprehensions In-Reply-To: <053.31375e41dd51007462e20df85979f732@localhost> References: <053.31375e41dd51007462e20df85979f732@localhost> Message-ID: <062.9b5fc8afe27873311bee9e484e958353@localhost> #3380: [Patch] Support implicit concatenation in list comprehensions ------------------------------+--------------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by ross): So this is a slightly shorter way of writing {{{ [x' | x <- [1..10], x `mod` 2 == 0, x' <- [x, x]] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 18 10:26:18 2009 From: trac at galois.com (GHC) Date: Sat Jul 18 10:07:59 2009 Subject: [GHC] #3380: [Patch] Support implicit concatenation in list comprehensions In-Reply-To: <053.31375e41dd51007462e20df85979f732@localhost> References: <053.31375e41dd51007462e20df85979f732@localhost> Message-ID: <062.53cac8be6901d07a03ab4a70d70c1d56@localhost> #3380: [Patch] Support implicit concatenation in list comprehensions ------------------------------+--------------------------------------------- Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by batterseapower): Yes, though the code generated by this patch may be /slightly/ better than for your version if you have RULES or foldr/buildable list literals turned off. The "killer app" that made me implement this was to support the following idiom: {{{ system "foo" $ ["foo" | fooing_enabled] ++ ["bar" | baring_enabled] }}} If you want to turn on two options when baring_enabled is on then you can now write: {{{ system "foo" $ ["foo" | fooing_enabled] ++ ["bar1", "bar2" | baring_enabled] }}} Which seems quite slick. It's a rather nice interpretation of some otherwise unused syntax IMHO. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 18 15:18:47 2009 From: trac at galois.com (GHC) Date: Sat Jul 18 15:00:27 2009 Subject: [GHC] #3289: make -j3 (or make -j30) occasionally fails on 6.11 In-Reply-To: <047.70666110621d92af3cf2b3e0ea735059@localhost> References: <047.70666110621d92af3cf2b3e0ea735059@localhost> Message-ID: <056.bb4fc51ba94d9c1bf4a65955c6df079c@localhost> #3289: make -j3 (or make -j30) occasionally fails on 6.11 ------------------------------------------+--------------------------------- Reporter: gbeshers | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: makefile dependency split | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ------------------------------------------+--------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: The problem is that both {{{ libraries/base/dist-install/build/GHC/Float.o libraries/base/dist-install/build/GHC/Float.p_o }}} used (and cleaned) the same {{{ libraries/base/dist-install/build/GHC/Float_split }}} directory, so there is a race condition if both are built in parallel. Fixed by: {{{ Sat Jul 18 07:55:22 PDT 2009 Ian Lynagh * Add osuf to the name we use for the split dir This avoids a collision between the directories we use when compiling multiple ways, which in turn leads to a race condition in parallel builds. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 18 18:40:44 2009 From: trac at galois.com (GHC) Date: Sat Jul 18 18:22:24 2009 Subject: [GHC] #3382: Panic in tidyNPat when using N+k patterns with overloaded strings Message-ID: <053.a9f0b9ded78d6372543c08e558ec6572@localhost> #3382: Panic in tidyNPat when using N+k patterns with overloaded strings -----------------------------+---------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Spotted this while reading the source code to tidyNPat. It looked dubious to me, and indeed it is: {{{ {-# OPTIONS_GHC -XOverloadedStrings #-} module Main where import Data.String instance IsString Int where fromString x = 1337 f :: Int -> String f "hello" = "correct" f _ = "false" main = do print $ f 1337 print $ f 1338 }}} Result: {{{ mbolingbroke@mb566 ~/Programming/Checkouts $ ghc --make Boog.hs [1 of 1] Compiling Main ( Boog.hs, Boog.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-apple-darwin): tidyNPat }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 18 19:14:43 2009 From: trac at galois.com (GHC) Date: Sat Jul 18 18:56:23 2009 Subject: [GHC] #3383: Confluent type instances confuse the solver Message-ID: <043.f4ac9598d659216aef29ac1a96176133@localhost> #3383: Confluent type instances confuse the solver ----------------------------------------------------+----------------------- Reporter: desp | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.3 | Severity: normal Keywords: type family families instance instances | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ----------------------------------------------------+----------------------- While attempting to define integer arithmetic using type families, I encountered a problem with the type checker failing to recognize equivalent types: {{{ {-# LANGUAGE EmptyDataDecls, TypeFamilies #-} module WithBug where data Z data S a data P a b type family N a type instance N (P Z a) = P Z a type instance N (P a Z) = P a Z -- with bug type instance N (P (S a) (S b)) = N (P a b) }}} {{{ $ ghci WithBug *WithBug> :t (undefined :: N (P Z Z)) :: P Z Z :1:1: Couldn't match expected type `P Z Z' against inferred type `N (P Z Z)' In the expression: (undefined :: N (P Z Z)) :: P Z Z }}} Rewriting the problematic instance fixed the problem: {{{ {-# LANGUAGE EmptyDataDecls, TypeFamilies #-} module WithoutBug where data Z data S a data P a b type family N a type instance N (P Z a) = P Z a type instance N (P (S a) Z) = P (S a) Z -- without bug type instance N (P (S a) (S b)) = N (P a b) }}} {{{ $ ghci WithoutBug *WithoutBug> :t (undefined :: N (P Z Z)) :: P Z Z (undefined :: N (P Z Z)) :: P Z Z :: P Z Z }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 18 19:15:47 2009 From: trac at galois.com (GHC) Date: Sat Jul 18 18:57:28 2009 Subject: [GHC] #3383: Confluent type family instances confuse the solver In-Reply-To: <043.f4ac9598d659216aef29ac1a96176133@localhost> References: <043.f4ac9598d659216aef29ac1a96176133@localhost> Message-ID: <052.359879c6ee2636e4f37c6fc0e14c0ff8@localhost> #3383: Confluent type family instances confuse the solver -----------------------------------------------------+---------------------- Reporter: desp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.3 Severity: normal | Resolution: Keywords: type family families instance instances | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------------------------------+---------------------- Changes (by desp): * summary: Confluent type instances confuse the solver => Confluent type family instances confuse the solver -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 04:37:11 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 04:18:55 2009 Subject: [GHC] #3383: Confluent type family instances confuse the solver In-Reply-To: <043.f4ac9598d659216aef29ac1a96176133@localhost> References: <043.f4ac9598d659216aef29ac1a96176133@localhost> Message-ID: <052.b970a7ef4ac040f9be8f75506c30b043@localhost> #3383: Confluent type family instances confuse the solver -----------------------------------------------------+---------------------- Reporter: desp | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.3 Severity: normal | Resolution: worksforme Keywords: type family families instance instances | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------------------------------+---------------------- Changes (by chak): * status: new => closed * resolution: => worksforme Comment: This bug has already been fixed in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 06:30:24 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 06:12:23 2009 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.1311a9cb2c697e14c277999e60c4d488@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.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by guest): If some ghc hacker have time, please fix this problem. I waste too much time to fix import cycle problem, it's not `little` problem, special to big projects. Example in my projects have 30 files, i got below information by ghc: ------------------> output start <-------------- Module imports form a cycle for modules: main:Manatee.File[boot] imports: Manatee.Commander[boot] Manatee.View[boot] Graphics.UI.Gtk.Gdk.Events Data.ByteString.Lazy.UTF8 Data.ByteString.Lazy Manatee.IORefObject Data.IORef main:Manatee.View[boot] imports: Manatee.Page Graphics.UI.Gtk.Abstract.Paned main:Manatee.Page imports: Manatee.TabGroup[boot] Manatee.File[boot] Manatee.ViewList[boot] Manatee.StringBuffer[boot] Manatee.PageList[boot] Manatee.IORefObject Manatee.PageBuffer Manatee.Utils Manatee.View Graphics.UI.Gtk Control.Monad Data.List System.FilePath Control.Applicative Data.Function Data.IORef Text.Printf main:Manatee.TabGroup[boot] imports: Manatee.PageList[boot] Manatee.Page[boot] Data.IORef main:Manatee.PageList[boot] imports: Manatee.Page[boot] Data.Set Data.IORef main:Manatee.Page[boot] imports: Manatee.View[boot] Manatee.IORefObject[boot] Manatee.PageBuffer Graphics.UI.Gtk main:Manatee.PageBuffer imports: Manatee.ViewList[boot] Manatee.View[boot] Graphics.UI.Gtk Data.IORef main:Manatee.ViewList[boot] imports: Manatee.Page[boot] Manatee.IORefObject[boot] Manatee.ViewNode[boot] Manatee.View[boot] Data.Set Data.IORef main:Manatee.StringBuffer[boot] imports: Manatee.PageBuffer Graphics.UI.Gtk.SourceView.SourceBuffer main:Manatee.IORefObject imports: Manatee.Commander[boot] Manatee.PageList[boot] Manatee.ViewNodeList[boot] Manatee.ViewList[boot] Manatee.Utils Graphics.UI.Gtk.Windows.WindowGroup Graphics.UI.Gtk.Abstract.Container Graphics.UI.Gtk Data.IORef main:Manatee.View imports: Manatee.PageList[boot] Manatee.Page[boot] Manatee.ListZipper Data.Foldable Manatee.ViewNode Manatee.IORefObject Manatee.PageBuffer Manatee.TabGroup Manatee.ViewList Graphics.UI.Gtk.Layout.VPaned Graphics.UI.Gtk.Layout.HPaned Graphics.UI.Gtk.Abstract.Paned Graphics.UI.Gtk.Abstract.Container Graphics.UI.Gtk Data.List Data.IORef Control.Monad.Reader Text.Printf Data.Function Data.Maybe Control.Applicative Control.Monad.State main:Manatee.ViewNode imports: Manatee.ViewNodeList[boot] Manatee.ViewList[boot] Manatee.View[boot] Manatee.Utils Manatee.IORefObject Graphics.UI.Gtk.Layout.VPaned Graphics.UI.Gtk.Layout.HPaned Graphics.UI.Gtk.Abstract.Paned Graphics.UI.Gtk Data.Function Control.Monad Text.Printf Data.Maybe Data.IORef Control.Applicative main:Manatee.TabGroup imports: Manatee.PageList[boot] Manatee.Page[boot] Data.Foldable Data.Sequence Manatee.Utils Graphics.UI.Gtk.SourceView.SourceBuffer Graphics.UI.Gtk Data.List Data.Sequence Control.Monad Text.Printf Control.Applicative Data.IORef main:Manatee.ViewList imports: Manatee.Page[boot] Manatee.View[boot] Manatee.ListZipper Manatee.IORefObject Manatee.ListZipper Manatee.Utils Manatee.ViewNode Graphics.UI.Gtk.Abstract.Container Graphics.UI.Gtk.Abstract.Paned Graphics.UI.Gtk Text.Printf Data.IORef Control.Applicative ---------------> output end <------------- Above information is really less help, if i change one file, i will got another different output. I have spend more time to fix this problem along with my project increase everyday. I'm really tired.... So please ghc expert fix this problem, then I'm free. Thanks! -- Andy -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 08:52:53 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 08:34:32 2009 Subject: [GHC] #2051: -hide-package doesn't allow hiding uninstalled package In-Reply-To: <053.fd935e025acfb737c5e2348105b5b118@localhost> References: <053.fd935e025acfb737c5e2348105b5b118@localhost> Message-ID: <062.b041200190b102b136fc781ca0bfdf13@localhost> #2051: -hide-package doesn't allow hiding uninstalled package --------------------------------+------------------------------------------- Reporter: MagnusTherning | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: It looks like `-ignore-package dataenc` already does what you want, so I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 10:20:46 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 10:02:40 2009 Subject: [GHC] #3380: [Patch] Support implicit concatenation in list comprehensions In-Reply-To: <053.31375e41dd51007462e20df85979f732@localhost> References: <053.31375e41dd51007462e20df85979f732@localhost> Message-ID: <062.551214237a6b6c04205f8bf0dbcb8cdf@localhost> #3380: [Patch] Support implicit concatenation in list comprehensions ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * cc: koen@chalmers.se (added) * difficulty: => Unknown Comment: Thanks for trying this out. I'm adding Koen to the cc list since he suggested the idea originally. Frankly, I'm unsure whether it's a feature that pays its way. It uses syntactic space, which is good, but it's one more thing to maintain and explain. It's not a big deal, but I'd like to hear some more people saying "oh yes I want this" before committing to it forever. Max: one way to get such expressions of support would be to describe the feature (linking to this ticket) in a message to Haskell Cafe, and encourage people to add use cases. Does anyone else have an opinion, especially Koen? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 10:22:04 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 10:03:43 2009 Subject: [GHC] #3377: [Patch] Support Python-style tuple sections In-Reply-To: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> References: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> Message-ID: <062.917c0fbac75720431d74bde5bdc8732e@localhost> #3377: [Patch] Support Python-style tuple sections ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Thanks for this. It seems to me to be a simple and consistent generalisation of Haskell's existing notion of "sections" and I can see that it'd be useful sometimes. Does anyone else have an opinion? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 10:29:49 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 10:11:28 2009 Subject: [GHC] #3377: [Patch] Support Python-style tuple sections In-Reply-To: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> References: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> Message-ID: <062.4420064158ba8d7541be0a92da3df68f@localhost> #3377: [Patch] Support Python-style tuple sections ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by isaacdupree): yeah, I remember trying to do this a few years ago and being disappointed that it didn't work. So I think it's a good idea. (except that adding syntax always has hazards. Will somebody want list-literals with sections like this? Er admittedly I've never actually wanted that, so maybe not.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 10:45:30 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 10:27:09 2009 Subject: [GHC] #3377: [Patch] Support Python-style tuple sections In-Reply-To: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> References: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> Message-ID: <062.bc17faa2ad082e9d5f7f292ad2a530f3@localhost> #3377: [Patch] Support Python-style tuple sections ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by batterseapower): I proposed list sections to Neil in an email, and I reproduce his reply here: {{{ I tried to think of why the list section wouldn't be useful. The reason I decided is that for lists we have the singleton list (we lack the singleton tuple) and list concatenation (there is no tuple concat, but it could be added). Using these you can often encode list sections: map (:1) So I think thats the reason no one needs list sections. Thanks Neil }}} Seems reasonable to me! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 10:55:58 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 10:37:47 2009 Subject: [GHC] #3380: [Patch] Support implicit concatenation in list comprehensions In-Reply-To: <053.31375e41dd51007462e20df85979f732@localhost> References: <053.31375e41dd51007462e20df85979f732@localhost> Message-ID: <062.224a0265ae33bb1b004eedaa86f4c058@localhost> #3380: [Patch] Support implicit concatenation in list comprehensions ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): I have no net opinion either way. On the one hand, it would be nice to be able to do it, but on the flipside, I can imagine people getting confused if they don't notice that there isn't an extra pair of square brackets. A quick grep finds some cases where this could be used in the GHC sources: {{{ ./main/DriverPipeline.hs: let pkg_framework_opts = concat [ ["-framework", fw] | fw <- pkg_frameworks ] ./main/DriverPipeline.hs: framework_opts = concat [ ["-framework", fw] | fw <- reverse frameworks ] ./main/GHC.hs: concat [ [(m,True), (m,False)] | m <- ms_home_srcimps s ] ./rename/RnNames.lhs: ; addUsedRdrNames (concat [ [mkRdrQual mod occ, mkRdrUnqual occ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 11:03:48 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 10:45:26 2009 Subject: [GHC] #3377: [Patch] Support Python-style tuple sections In-Reply-To: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> References: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> Message-ID: <062.13d41dcb40df8be040cfdb6a01d74fde@localhost> #3377: [Patch] Support Python-style tuple sections ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by NeilMitchell): It should be noted that Python style tuple sections are slightly different, in Python (1,) is the 1-element tuple. This patch doesn't implement that, but instead the reasonably sensible generalisation: {{{(a,,c,) ==> \b d -> (a,b,c,d)}}} I really like this feature, I often do {{{map ((,) 1) xs}}} or {{{map (\x -> (1,x)) xs}}}, both of which are a bit too clunky. This feature would fix both of them. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 11:11:14 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 10:52:58 2009 Subject: [GHC] #3380: [Patch] Support implicit concatenation in list comprehensions In-Reply-To: <053.31375e41dd51007462e20df85979f732@localhost> References: <053.31375e41dd51007462e20df85979f732@localhost> Message-ID: <062.288b734dc84f41852897225d2a75fc18@localhost> #3380: [Patch] Support implicit concatenation in list comprehensions ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by batterseapower): OK, I've started a thread on the cafe: http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61514 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 12:10:38 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 11:52:18 2009 Subject: [GHC] #2120: Arrays allow out-of-bounds indexes In-Reply-To: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> References: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> Message-ID: <055.d6e423260e27752d5e33af6ffc8676d6@localhost> #2120: Arrays allow out-of-bounds indexes ----------------------------------+----------------------------------------- Reporter: amthrax | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by these patches in array and base: {{{ Sun Jul 19 16:29:31 BST 2009 Ian Lynagh * Improve the index checking for array accesses; fixes #2120 #2669 As well as checking that offset we are reading is actually inside the array, we now also check that it is "in range" as defined by the Ix instance. This fixes confusing behaviour (#2120) and improves some error messages (#2669). Sun Jul 19 16:32:28 BST 2009 Ian Lynagh * Improve the index checking for array accesses; fixes #2120 #2669 As well as checking that offset we are reading is actually inside the array, we now also check that it is "in range" as defined by the Ix instance. This fixes confusing behaviour (#2120) and improves some error messages (#2669). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 12:11:15 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 11:52:54 2009 Subject: [GHC] #2669: "index out of range" error message regression In-Reply-To: <044.80e0e61ca034157992559b1b44b66761@localhost> References: <044.80e0e61ca034157992559b1b44b66761@localhost> Message-ID: <053.6b09688bdad0e7f1ff6ebe9680e9f3e8@localhost> #2669: "index out of range" error message regression ---------------------------------+------------------------------------------ Reporter: claus | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: None | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by these patches in array and base: {{{ Sun Jul 19 16:29:31 BST 2009 Ian Lynagh * Improve the index checking for array accesses; fixes #2120 #2669 As well as checking that offset we are reading is actually inside the array, we now also check that it is "in range" as defined by the Ix instance. This fixes confusing behaviour (#2120) and improves some error messages (#2669). Sun Jul 19 16:32:28 BST 2009 Ian Lynagh * Improve the index checking for array accesses; fixes #2120 #2669 As well as checking that offset we are reading is actually inside the array, we now also check that it is "in range" as defined by the Ix instance. This fixes confusing behaviour (#2120) and improves some error messages (#2669). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 12:55:40 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 12:37:19 2009 Subject: [GHC] #3377: [Patch] Support Python-style tuple sections In-Reply-To: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> References: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> Message-ID: <062.4472663a4005269c4a7d6cc50d0f8f6c@localhost> #3377: [Patch] Support Python-style tuple sections ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by nominolo): I like the idea as well, but I wonder if proposing a new {{{LANGUAGE}}} to a wider audience ({{{libraries@}}} or {{{haskell-cafe@}}}) might give better feedback. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 13:56:30 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 13:38:10 2009 Subject: [GHC] #1324: threadDelay can't handle long times In-Reply-To: <044.993173f32a7ede9ee4461b0bd4ee79f1@localhost> References: <044.993173f32a7ede9ee4461b0bd4ee79f1@localhost> Message-ID: <053.82637f99baa8692e6d761336d70508d6@localhost> #1324: threadDelay can't handle long times ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: If you would like to propose changing the interface, please use the [http://www.haskell.org/haskellwiki/Library_submissions library submissions] procedure. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 14:03:12 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 13:44:58 2009 Subject: [GHC] #1647: Using -fdicts-strict flag causes Core Lint error In-Reply-To: <067.8af6cf06fabf5acdf49f68ce59933274@localhost> References: <067.8af6cf06fabf5acdf49f68ce59933274@localhost> Message-ID: <076.672ad3e84aded7e5f54d9a12bef234d3@localhost> #1647: Using -fdicts-strict flag causes Core Lint error ---------------------------------------------+------------------------------ Reporter: chevalier@alum.wellesley.edu | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.7 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I can no longer reproduce this with the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 15:17:35 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 14:59:21 2009 Subject: [GHC] #1647: Using -fdicts-strict flag causes Core Lint error In-Reply-To: <067.8af6cf06fabf5acdf49f68ce59933274@localhost> References: <067.8af6cf06fabf5acdf49f68ce59933274@localhost> Message-ID: <076.ce94cc9544480d7fbc3e94b5eea70b9d@localhost> #1647: Using -fdicts-strict flag causes Core Lint error ---------------------------------------------+------------------------------ Reporter: chevalier@alum.wellesley.edu | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.7 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T1647 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by igloo): * testcase: => T1647 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 16:00:48 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 15:42:25 2009 Subject: [GHC] #3384: Add HsSyn prettyprinter tests Message-ID: <044.d11e412e7968bb1bf100410e6ff17081@localhost> #3384: Add HsSyn prettyprinter tests -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Test Suite | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Add HsSyn prettyprinter tests. See #1966 for some discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 16:01:08 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 15:42:49 2009 Subject: [GHC] #1966: Incorrect Outputable instance for InstDecl In-Reply-To: <044.a38c58added2b3ae3cac99b98cdbc78f@localhost> References: <044.a38c58added2b3ae3cac99b98cdbc78f@localhost> Message-ID: <053.30fa217eab937582b3b8ea66ad2cf769@localhost> #1966: Incorrect Outputable instance for InstDecl ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: task | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: ppr001 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I've opened #3384 for the regression tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 16:08:26 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 15:50:04 2009 Subject: [GHC] #1911: -w doesn't turn off nullModuleExport In-Reply-To: <052.f8888bb7a75c82cffc374ff0c38b4c43@localhost> References: <052.f8888bb7a75c82cffc374ff0c38b4c43@localhost> Message-ID: <061.f5851a14032c55910b61f2a340e66910@localhost> #1911: -w doesn't turn off nullModuleExport ---------------------------------+------------------------------------------ Reporter: AndreaRossato | Owner: AndreaRossato Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.8.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: assigned => closed * resolution: => fixed Comment: Andrea, sorry for overlooking your patch for so long; I tend not to look at bugs that are assigned to someone else. I've applied a similar patch, only using `warn-dodgy-exports` rather than `warn-misc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 19 16:40:27 2009 From: trac at galois.com (GHC) Date: Sun Jul 19 16:22:06 2009 Subject: [GHC] #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic Message-ID: <046.5cfaefd5bf9586a45cb1735e8d8f0098@localhost> #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic -------------------------------------+-------------------------------------- Reporter: gparent | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: readline panic truncated | Testcase: Os: Linux | Architecture: x86 -------------------------------------+-------------------------------------- Compiling readline 1.0.1.0 from source using GHC 6.10.3 causes the following output: geordi@debianserv:~/haskell/readline-1.0.1.0$ runhaskell Setup.hs configure Setup.hs:3:0: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks" Warning: defaultUserHooks in Setup script is deprecated. Configuring readline-1.0.1.0... checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for GNUreadline.framework... checking for readline... no checking for tputs in -lncurses... yes checking for readline in -lreadline... yes checking for rl_readline_version... yes checking for rl_begin_undo_group... yes checking for rl_erase_empty_line... yes checking for rl_free_undo_list... yes checking for rl_completion_word_break_hook in -lreadline... yes configure: creating ./config.status config.status: creating config.mk config.status: creating readline.buildinfo config.status: creating include/HsReadlineConfig.h config.status: include/HsReadlineConfig.h is unchanged geordi@debianserv:~/haskell/readline-1.0.1.0$ runhaskell Setup.hs build Setup.hs:3:0: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: "Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks" Preprocessing library readline-1.0.1.0... Building readline-1.0.1.0... Binary: Int64 truncated to fit in 32 bit Int ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-unknown-linux): Prelude.chr: bad argument Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug geordi@debianserv:~/haskell/readline-1.0.1.0$ Package was downloaded from: http://hackage.haskell.org/cgi-bin/hackage- scripts/package/readline GHC is the latest version from Debian/Unstable. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 20 06:50:45 2009 From: trac at galois.com (GHC) Date: Mon Jul 20 06:32:23 2009 Subject: [GHC] #288: amd64-FreeBSD-5.3 port? In-Reply-To: <045.aaebc23b15b0d0e8b18e01239168049e@localhost> References: <045.aaebc23b15b0d0e8b18e01239168049e@localhost> Message-ID: <054.f91de252aea070f58dbff80db5da8610@localhost> #288: amd64-FreeBSD-5.3 port? --------------------------------+------------------------------------------- Reporter: nobody | Owner: Type: feature request | Status: closed Priority: normal | Milestone: _|_ Component: None | Version: None Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: N/A | Os: FreeBSD Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: None => fixed Comment: GHC works on x86_64-*-freebsd (see [wiki:Platforms]) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 20 14:28:10 2009 From: trac at galois.com (GHC) Date: Mon Jul 20 14:09:45 2009 Subject: [GHC] #3386: RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph Message-ID: <049.5b3494ecafeb0e231ba14cf4473a8bc4@localhost> #3386: RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph -----------------------------+---------------------------------------------- Reporter: StefanWehr | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: stack slots | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Using ghc 6.10.4, I tried to install the crypto lib (version 4.1.0) via "cabal install crypto". However, ghc fails: [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test /SHA1Test-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph OS: Ubuntu Linux (Hardy), 32 bit -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 20 14:49:16 2009 From: trac at galois.com (GHC) Date: Mon Jul 20 14:30:56 2009 Subject: [GHC] #3377: [Patch] Support Python-style tuple sections In-Reply-To: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> References: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> Message-ID: <062.73cd8621298eacbdccc7abd7e0caae87@localhost> #3377: [Patch] Support Python-style tuple sections ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by BenMoseley): * cc: ben@moseley.name (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 20 15:44:41 2009 From: trac at galois.com (GHC) Date: Mon Jul 20 15:26:43 2009 Subject: [GHC] #3380: [Patch] Support implicit concatenation in list comprehensions In-Reply-To: <053.31375e41dd51007462e20df85979f732@localhost> References: <053.31375e41dd51007462e20df85979f732@localhost> Message-ID: <062.698110f41b8577aa0765bfc416d99011@localhost> #3380: [Patch] Support implicit concatenation in list comprehensions ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): I support this extension. It's exactly the syntax I have often wished we had. The case where I have wished we had this is the same as cited above, namely building lists of command line flags (there's a lot of that in Cabal). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 20 16:32:34 2009 From: trac at galois.com (GHC) Date: Mon Jul 20 16:14:07 2009 Subject: [GHC] #3387: Provide a CInt instance for unboxed arrays Message-ID: <044.dd8f14bf96a26cc0f1cd7713bc326856@localhost> #3387: Provide a CInt instance for unboxed arrays -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Would it make sense to provide a `CInt` (and perhaps `CLong`, etc.) instance for unboxed arrays? I missed that a couple of times when storing e.g. file descriptors in an array. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 21 00:15:48 2009 From: trac at galois.com (GHC) Date: Mon Jul 20 23:57:22 2009 Subject: [GHC] #3377: [Patch] Support Python-style tuple sections In-Reply-To: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> References: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> Message-ID: <062.c1a4840a6e0c1dd008bfc23d635f1d30@localhost> #3377: [Patch] Support Python-style tuple sections ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by pumpkin): * cc: pumpkingod@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 21 04:30:47 2009 From: trac at galois.com (GHC) Date: Tue Jul 21 04:12:30 2009 Subject: [GHC] #2362: allow full import syntax in GHCi In-Reply-To: <051.a17c861cfc196911194c3abd0e428c4d@localhost> References: <051.a17c861cfc196911194c3abd0e428c4d@localhost> Message-ID: <060.0889f217d8f7f078cfd832b5687a03e8@localhost> #2362: allow full import syntax in GHCi ---------------------------------+------------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: ghci, import | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * cc: rturk@science.uva.nl, jcpetruzza@gmail.com, gwern0@gmail.com, cgibbard@gmail.com, nicolas.pouillard@gmail.com, rendel@daimi.au.dk, mjm2002@gmail.com (added) Comment: merging with #1895, as this ticket will subsume it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 21 04:39:28 2009 From: trac at galois.com (GHC) Date: Tue Jul 21 04:21:40 2009 Subject: [GHC] #1895: Allow aliases in GHCi module imports In-Reply-To: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> References: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> Message-ID: <053.61c83b6574545c2d55fd12f3d5953f97@localhost> #1895: Allow aliases in GHCi module imports ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: closed Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: closing to merge with #2362 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 21 04:57:53 2009 From: trac at galois.com (GHC) Date: Tue Jul 21 04:39:38 2009 Subject: [GHC] #2362: allow full import syntax in GHCi In-Reply-To: <051.a17c861cfc196911194c3abd0e428c4d@localhost> References: <051.a17c861cfc196911194c3abd0e428c4d@localhost> Message-ID: <060.0cbafe42f285e527672fc4c5834223c1@localhost> #2362: allow full import syntax in GHCi ---------------------------------+------------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: ghci, import | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by tibbe): * cc: johan.tibell@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 21 06:03:17 2009 From: trac at galois.com (GHC) Date: Tue Jul 21 05:44:50 2009 Subject: [GHC] #3387: Provide a CInt instance for unboxed arrays In-Reply-To: <044.dd8f14bf96a26cc0f1cd7713bc326856@localhost> References: <044.dd8f14bf96a26cc0f1cd7713bc326856@localhost> Message-ID: <053.7fca2edad9d84200c94cb5215c5924ff@localhost> #3387: Provide a CInt instance for unboxed arrays ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: Is StorableArray not suitable? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 21 07:17:24 2009 From: trac at galois.com (GHC) Date: Tue Jul 21 06:59:00 2009 Subject: [GHC] #3387: Provide a CInt instance for unboxed arrays In-Reply-To: <044.dd8f14bf96a26cc0f1cd7713bc326856@localhost> References: <044.dd8f14bf96a26cc0f1cd7713bc326856@localhost> Message-ID: <053.9a1c1a5088c8f538fa54ca2fd41ccebf@localhost> #3387: Provide a CInt instance for unboxed arrays ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by tibbe): The `StorableArray` documentation reads: "It is similar to Data.Array.IO.IOUArray but slower. Its advantage is that it's compatible with C." Is this still true? Also, are `StorableArray`s always allocated on the C heap and if so isn't that potentially bad for the GC as it knows nothing about their size? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 21 15:14:35 2009 From: trac at galois.com (GHC) Date: Tue Jul 21 14:56:25 2009 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@localhost> References: <046.37416aee19ee095c9a6e98285b215b72@localhost> Message-ID: <055.1209cd45535d0b822a18e4e699ea9131@localhost> #915: Implement list fusion using streams instead of foldr/build ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.8 Severity: normal | Resolution: Keywords: fusion | Difficulty: Project (> 1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by pumpkin): * cc: pumpkingod@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 21 15:20:30 2009 From: trac at galois.com (GHC) Date: Tue Jul 21 15:02:11 2009 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@localhost> References: <046.37416aee19ee095c9a6e98285b215b72@localhost> Message-ID: <055.2e74252c909852bcf2fcc95d03afa45e@localhost> #915: Implement list fusion using streams instead of foldr/build ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.8 Severity: normal | Resolution: Keywords: fusion | Difficulty: Project (> 1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by mux): * cc: mhenrion@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 21 15:21:08 2009 From: trac at galois.com (GHC) Date: Tue Jul 21 15:02:39 2009 Subject: [GHC] #3293: Implement shiftLInteger and shiftRInteger In-Reply-To: <044.df0bc2082d2b67a740bace217a62079f@localhost> References: <044.df0bc2082d2b67a740bace217a62079f@localhost> Message-ID: <053.63c3c12d4d5bebe4cfc128aab8da8de8@localhost> #3293: Implement shiftLInteger and shiftRInteger ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 21 16:48:37 2009 From: trac at galois.com (GHC) Date: Tue Jul 21 16:30:38 2009 Subject: [GHC] #3330: Type checker hangs In-Reply-To: <060.111b0979bdfa1b272261462ee3c542d4@localhost> References: <060.111b0979bdfa1b272261462ee3c542d4@localhost> Message-ID: <069.b72735db0545e592d9fb86b3a2344d6b@localhost> #3330: Type checker hangs ----------------------------------------+----------------------------------- Reporter: MartijnVanSteenbergen | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | ----------------------------------------+----------------------------------- Changes (by EduardSergeev): * os: Unknown/Multiple => MacOS X * architecture: Unknown/Multiple => x86_64 (amd64) Comment: I think I am now facing a similar behavior (hangs while compiling, continiously consuming memory until the whole system hangs) from GHC 6.10.3 on Mac OS X 10.5.7 (and on Windows XP as well) on the following simple type family example: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} class RFunctor c a b where type Res c a b :: * rmap :: (a -> b) -> c -> Res c a b instance (a ~ c) => RFunctor c a b where type Res c a b = b rmap f = f instance (RFunctor c a b, a ~ c) => RFunctor [c] a b where type Res [c] a b = [b] rmap f = map (map f) }}} But if these two instances declarations are interchanged it reports: Conflicting family instance declarations: type instance Res [c] a b -- Defined at TFTest.hs:14:9-11 type instance Res c a b -- Defined at TFTest.hs:18:9-11 I've also attached the fragment of the output from GHC with -ddump-tc- trace -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 21 17:55:11 2009 From: trac at galois.com (GHC) Date: Tue Jul 21 17:36:43 2009 Subject: [GHC] #3046: Generalized newtype deriving with associated types In-Reply-To: <053.5760498fe5df42ff01ed60b4c8b401f4@localhost> References: <053.5760498fe5df42ff01ed60b4c8b401f4@localhost> Message-ID: <062.dc8ef19dac11f10c57eca70dbc8ca4f6@localhost> #3046: Generalized newtype deriving with associated types ------------------------------+--------------------------------------------- Reporter: LouisWasserman | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by pumpkin): (duplicate of #2850 in case you find this one first) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 21 18:25:37 2009 From: trac at galois.com (GHC) Date: Tue Jul 21 18:07:09 2009 Subject: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work In-Reply-To: <042.bfabde61c4aa31a17887ff9436d679ab@localhost> References: <042.bfabde61c4aa31a17887ff9436d679ab@localhost> Message-ID: <051.1bfeebd0e3c03c94ebd78005632e5415@localhost> #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work ---------------------------------+------------------------------------------ Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by pumpkin): * cc: pumpkingod@gmail.com, dons@galois.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 21 18:31:38 2009 From: trac at galois.com (GHC) Date: Tue Jul 21 18:13:09 2009 Subject: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work In-Reply-To: <042.bfabde61c4aa31a17887ff9436d679ab@localhost> References: <042.bfabde61c4aa31a17887ff9436d679ab@localhost> Message-ID: <051.73b3e3dd108608819b9f894f0cdbb6da@localhost> #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work ---------------------------------+------------------------------------------ Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by pumpkin): I find this error puzzling because this used to work in 6.8.3 and even (I believe) 6.10.1. But now I'm on 6.10.3 and am trying to compile some code that I hadn't touched since 6.10.1, and I get this error. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 22 02:04:15 2009 From: trac at galois.com (GHC) Date: Wed Jul 22 01:45:46 2009 Subject: [GHC] #3382: Panic in tidyNPat when using N+k patterns with overloaded strings In-Reply-To: <053.a9f0b9ded78d6372543c08e558ec6572@localhost> References: <053.a9f0b9ded78d6372543c08e558ec6572@localhost> Message-ID: <062.282fe3795116c9c0e553dbf40232f42d@localhost> #3382: Panic in tidyNPat when using N+k patterns with overloaded strings -----------------------------------------+---------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: deSugar/should_run/T3382 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonpj): * testcase: => deSugar/should_run/T3382 * difficulty: => Unknown * status: new => closed * resolution: => fixed Comment: Ah yes, excellent point. Fixed by {{{ Mon Jul 20 07:12:26 GMT Daylight Time 2009 simonpj@microsoft.com * Fix Trac #3382: desugaring of NPats Max spotted that the short-cut rules for desugaring NPats (where we compare against a literal) were wrong now that we have overloaded strings. }}} thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 22 04:19:49 2009 From: trac at galois.com (GHC) Date: Wed Jul 22 04:01:19 2009 Subject: [GHC] #3387: Provide a CInt instance for unboxed arrays In-Reply-To: <044.dd8f14bf96a26cc0f1cd7713bc326856@localhost> References: <044.dd8f14bf96a26cc0f1cd7713bc326856@localhost> Message-ID: <053.041cab171204f7a38f0a25ba78d8bee8@localhost> #3387: Provide a CInt instance for unboxed arrays ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): As we discussed on IRC, I'm not sure the comment about the speed of StorableArray is still true. It probably dates from before we optimised the representation of `ForeignPtr`. A `StorableArray` allocated using `newArray` is on the Haskell heap, and GC'd as usual. However, you can also make a `StorableArray` using `unsafeForeignPtrToStorableArray`, in which case the memory can reside anywhere you like (but presumably the `ForeignPtr` has a finalizer to deallocate it). Can I close this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 22 04:40:06 2009 From: trac at galois.com (GHC) Date: Wed Jul 22 04:21:38 2009 Subject: [GHC] #3377: [Patch] Support Python-style tuple sections In-Reply-To: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> References: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> Message-ID: <062.73929693c29651f840018275f0c97236@localhost> #3377: [Patch] Support Python-style tuple sections ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): This was controversial when it was brought up for Haskell'. I can't find any discussion online, but the committee [http://hackage.haskell.org/trac /haskell-prime/wiki/StrawPoll-2 straw poll] shows that the majority were against it. This doesn't necessarily mean that people disliked the extension: it's more likely because in Haskell prime we were/are more concerned with standardising existing extensions than inventing new ones. Personally, I'd like to see this go into GHC. I don't think it does any harm, it's easy to explain, and it's often very useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 22 04:53:45 2009 From: trac at galois.com (GHC) Date: Wed Jul 22 04:35:15 2009 Subject: [GHC] #3387: Provide a CInt instance for unboxed arrays In-Reply-To: <044.dd8f14bf96a26cc0f1cd7713bc326856@localhost> References: <044.dd8f14bf96a26cc0f1cd7713bc326856@localhost> Message-ID: <053.4819d0db2c85a1963cd5e52da4a3ef89@localhost> #3387: Provide a CInt instance for unboxed arrays ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by tibbe): * status: new => closed * resolution: => invalid Comment: Thanks for the explanation. Closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 22 06:24:14 2009 From: trac at galois.com (GHC) Date: Wed Jul 22 06:05:45 2009 Subject: [GHC] #3377: [Patch] Support Python-style tuple sections In-Reply-To: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> References: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> Message-ID: <062.e5e6bb7befd732fd589dc79269ac5685@localhost> #3377: [Patch] Support Python-style tuple sections ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by MartijnVanSteenbergen): * cc: MartijnVanSteenbergen (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 22 06:56:48 2009 From: trac at galois.com (GHC) Date: Wed Jul 22 06:38:22 2009 Subject: [GHC] #366: incomplete patterns and GADT In-Reply-To: <045.78fabe56a37c24d921b345c081d108ef@localhost> References: <045.78fabe56a37c24d921b345c081d108ef@localhost> Message-ID: <054.f33522eefdcb7ef76a80a3210b26e7cc@localhost> #366: incomplete patterns and GADT ----------------------------------------------------------+----------------- Reporter: nobody | Owner: Type: feature request | Status: closed Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: tc215, deSugar/should_compile/GadtOverlap | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------------------------+----------------- Changes (by simonpj): * testcase: tc215 => tc215, deSugar/should_compile/GadtOverlap * status: new => closed * resolution: None => fixed Comment: I have not done the full overhaul envisaged by #595, but it turned out to be rather easy to make GADTs play nicely with overlapping-pattern warnings. {{{ * Take account of GADTs when reporting patterm-match overlap Ignore-this: 7dcbdcb91021e83e6e6208a2e68c50c9 When matching against a GADT, some of the constructors may be impossible. For example data T a where T1 :: T Int T2 :: T Bool T3 :: T a f :: T Int -> Int f T1 = 3 f T3 = 4 Here, does not have any missing cases, despite omittting T2, because T2 :: T Bool. This patch teaches the overlap checker about GADTs, which happily turned out to be rather easy even though the overlap checker needs a serious rewrite. }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 22 06:58:55 2009 From: trac at galois.com (GHC) Date: Wed Jul 22 06:40:26 2009 Subject: [GHC] #3377: [Patch] Support Python-style tuple sections In-Reply-To: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> References: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> Message-ID: <062.2fda447bb4883fe8e8ca84ff84158949@localhost> #3377: [Patch] Support Python-style tuple sections ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): I agree. I'm going to put this in. Just working on the patch now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 22 12:03:10 2009 From: trac at galois.com (GHC) Date: Wed Jul 22 11:44:38 2009 Subject: [GHC] #3325: ghci debugger sometime doesn't notice that Integers are Integers In-Reply-To: <044.8521015b6f803e8f2ebf61aa1e1f946a@localhost> References: <044.8521015b6f803e8f2ebf61aa1e1f946a@localhost> Message-ID: <053.0f09bd83803460677a2a1bc2d9a7c4b1@localhost> #3325: ghci debugger sometime doesn't notice that Integers are Integers ------------------------------------------------------------------------------------------------------------------------+ Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: 2740, break001, break006, break026, hist001, print003, print005, print006, print010, print012, print014 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------------------------------------------------------------------------------------------+ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This got fixed during the latest Integer reshuffle -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 22 12:04:58 2009 From: trac at galois.com (GHC) Date: Wed Jul 22 11:46:28 2009 Subject: [GHC] #3388: mkIntegerExpr could use bit operations rather than plus/times for making large Integers. Message-ID: <044.ab35d5f8bcb300fe9e050deffadd03f1@localhost> #3388: mkIntegerExpr could use bit operations rather than plus/times for making large Integers. -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- `mkIntegerExpr` in `coreSyn/MkCore.lhs` could use bit operations rather than plus/times for making large Integers. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 22 12:05:57 2009 From: trac at galois.com (GHC) Date: Wed Jul 22 11:47:26 2009 Subject: [GHC] #3293: Implement shiftLInteger and shiftRInteger In-Reply-To: <044.df0bc2082d2b67a740bace217a62079f@localhost> References: <044.df0bc2082d2b67a740bace217a62079f@localhost> Message-ID: <053.bcdc5377a1e751e504dc078d7d9b7b1e@localhost> #3293: Implement shiftLInteger and shiftRInteger ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: task | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: `shiftLInteger` and `shiftRInteger` are now implemented. I've opened #3388 for `mkInteger`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 22 13:57:00 2009 From: trac at galois.com (GHC) Date: Wed Jul 22 13:38:29 2009 Subject: [GHC] #3389: CPP strips out C-style comments Message-ID: <047.ed7a4a8a5db27a5742ce2338e8823121@localhost> #3389: CPP strips out C-style comments -----------------------------+---------------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: new Priority: normal | Component: Driver Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The following code fails to compiler with {{{`y` not in scope}}}: {{{ {-# LANGUAGE CPP #-} module Foo (x) where x = ([y], z) -- Oh, noes! Here comes a C-style comment: /usr/local/* y = 42 -- And now let's close it */Setup.hs accidentally z = 23 }}} Apparently, the part between the {{{/*}}} and the {{{*/}}} got stripped out by the preprocessor. If we use a {{{gcc}}}'s CPP mode, we should at least pass it some options to prevent this from happening. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 22 15:13:13 2009 From: trac at galois.com (GHC) Date: Wed Jul 22 14:54:50 2009 Subject: [GHC] #3389: CPP strips out C-style comments In-Reply-To: <047.ed7a4a8a5db27a5742ce2338e8823121@localhost> References: <047.ed7a4a8a5db27a5742ce2338e8823121@localhost> Message-ID: <056.ad748857afdf1c6ad08a68d431053019@localhost> #3389: CPP strips out C-style comments ------------------------------+--------------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by malcolm.wallace@cs.york.ac.uk): Stripping C comments is part of the normal tokenisation behaviour of CPP. There are no options to gcc to turn it off. See for instance http://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html#SEC2 If you want to avoid C-tokenisation but still use CPP with Haskell, try cpphs instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 06:40:32 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 06:21:59 2009 Subject: [GHC] #3390: Make the Windows build work with mingw gcc 4.4.0 Message-ID: <047.29bca0c885caf29d0340fe02876b5659@localhost> #3390: Make the Windows build work with mingw gcc 4.4.0 ---------------------------+------------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Windows | Architecture: x86 ---------------------------+------------------------------------------------ Apparently there is breakage when using gcc 4.4.0 to build on Windows (not surprisingly). * [http://www.haskell.org/pipermail/glasgow-haskell- users/2009-July/017547.html] We should * make the build work * update the wiki instructions to point to the new gcc -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 08:22:39 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 08:04:06 2009 Subject: [GHC] #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic In-Reply-To: <046.5cfaefd5bf9586a45cb1735e8d8f0098@localhost> References: <046.5cfaefd5bf9586a45cb1735e8d8f0098@localhost> Message-ID: <055.cbbc0565480df95b9f372bf4e57b157b@localhost> #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic --------------------------------------+------------------------------------- Reporter: gparent | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: readline panic truncated | Testcase: Os: Linux | Architecture: x86 --------------------------------------+------------------------------------- Comment (by pejo): GHC can give the chr: bad arugment-panic if you have .hi-files that were built with a different compiler laying around. Try removing any old .hi- files and rebuild. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 08:41:20 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 08:22:46 2009 Subject: [GHC] #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic In-Reply-To: <046.5cfaefd5bf9586a45cb1735e8d8f0098@localhost> References: <046.5cfaefd5bf9586a45cb1735e8d8f0098@localhost> Message-ID: <055.c3ee537e59c62c71f5908aa7534ed5eb@localhost> #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic -----------------------------------------+---------------------------------- Reporter: gparent | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: readline panic truncated | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: I've added this to the building FAQ: http://hackage.haskell.org/trac/ghc/wiki/Building/Troubleshooting Please close the bug if that fixes the problem. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 08:42:18 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 08:23:45 2009 Subject: [GHC] #3193: line number for GADT type error is very inaccurate In-Reply-To: <041.70394cb40bad7490a7814d559b0c8397@localhost> References: <041.70394cb40bad7490a7814d559b0c8397@localhost> Message-ID: <050.cd2613eec8664f495f71a0f7163e276c@localhost> #3193: line number for GADT type error is very inaccurate -------------------------+-------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: GADTs | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I'm nearly certain I have fixed this bug: {{{ Wed Jul 22 23:55:04 PDT 2009 simonpj@microsoft.com * Fix Trac #3193: improve line number reporting for equality constraints Ignore-this: b45a68071bcaca48cad7855dccb9c9eb When reporting an error from a failed equality constraint, we were setting the *context* but not the *line number* in TcTyFuns.eqInstMisMatch As a result, the line number didn't match the context at all. It's trivial to fix. I'm 99% certain this fixes #3193, but it's too complicated to reproduce, so I have not actually tested it. M ./compiler/typecheck/TcRnMonad.lhs -3 +3 M ./compiler/typecheck/TcSimplify.lhs -2 +2 M ./compiler/typecheck/TcTyFuns.lhs -2 +1 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 08:43:30 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 08:24:57 2009 Subject: [GHC] #3377: [Patch] Support Python-style tuple sections In-Reply-To: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> References: <053.8b8deeb6206d08f7bc8dcf9f54564a9d@localhost> Message-ID: <062.2f5b0ab6191c1195e03a7734a6b28c31@localhost> #3377: [Patch] Support Python-style tuple sections ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: OK, it's done. Thanks to Max for doing the first version. {{{ Wed Jul 22 23:38:59 PDT 2009 simonpj@microsoft.com * Add tuple sections as a new feature Ignore-this: d42a26fc1efff112b852b5c1135c1746 This patch adds tuple sections, so that (x,,z) means \y -> (x,y,z) Thanks for Max Bolingbroke for doing the hard work. In the end, instead of using two constructors in HsSyn, I used just one (still called ExplicitTuple) whose arguments can be Present (LHsExpr id) or Missing PostTcType While I was at it, I did a bit of refactoring too. M ./compiler/deSugar/Coverage.lhs -6 +10 M ./compiler/deSugar/DsArrows.lhs -10 +5 M ./compiler/deSugar/DsExpr.lhs -10 +20 M ./compiler/deSugar/DsListComp.lhs -2 +2 M ./compiler/deSugar/DsMeta.hs -2 +4 M ./compiler/deSugar/DsUtils.lhs -19 +13 M ./compiler/deSugar/Match.lhs -15 +18 M ./compiler/hsSyn/Convert.lhs -1 +1 M ./compiler/hsSyn/HsExpr.lhs -23 +38 M ./compiler/hsSyn/HsUtils.lhs -5 +17 M ./compiler/main/DynFlags.hs +2 M ./compiler/parser/Parser.y.pp -10 +27 M ./compiler/parser/RdrHsSyn.lhs -3 +4 M ./compiler/rename/RnExpr.lhs -5 +17 M ./compiler/rename/RnSource.lhs -1 M ./compiler/typecheck/TcExpr.lhs -17 +27 M ./compiler/typecheck/TcGenDeriv.lhs -8 +6 M ./compiler/typecheck/TcHsSyn.lhs -10 +8 M ./compiler/typecheck/TcTyClsDecls.lhs -1 +1 M ./compiler/types/Generics.lhs -4 +4 M ./compiler/types/TypeRep.lhs +1 M ./docs/users_guide/glasgow_exts.xml +38 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 09:17:18 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 08:59:03 2009 Subject: [GHC] #3012: A little deriving for GADTs In-Reply-To: <044.94324394f531ef37390c0c5f7ffabb55@localhost> References: <044.94324394f531ef37390c0c5f7ffabb55@localhost> Message-ID: <053.d0fd983e3dc904cd2c90228e42e2d71b@localhost> #3012: A little deriving for GADTs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: OK it's done {{{ Thu Jul 23 06:01:45 PDT 2009 simonpj@microsoft.com * Fix Trac #3012: allow more free-wheeling in standalone deriving Ignore-this: 357580b9388ccbe1da3c1da3ba90e456 In standalone deriving, we now do *not* check side conditions. We simply generate the code and typecheck it. If there's a type error, it's the programmer's problem. This means that you can do 'deriving instance Show (T a)', where T is a GADT, for example, provided of course that the boilerplate code does in fact typecheck. I put some work into getting a decent error message. In particular if there's a type error in a method, GHC will show the entire code for that method (since, after all, the user did not write it). Most of the changes are to achieve that goal. Still to come: changes in the documentation. M ./compiler/typecheck/TcClassDcl.lhs -1 +1 M ./compiler/typecheck/TcDeriv.lhs -25 +27 M ./compiler/typecheck/TcEnv.lhs -2 +3 M ./compiler/typecheck/TcInstDcls.lhs -8 +22 M ./compiler/typecheck/TcMatches.lhs -1 +2 M ./compiler/typecheck/TcRnMonad.lhs -21 +31 M ./compiler/typecheck/TcRnTypes.lhs -6 +9 M ./compiler/utils/Outputable.lhs -3 +3 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 09:22:10 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 09:03:36 2009 Subject: [GHC] #3131: GHC stops after a single 'defined but not used' warning In-Reply-To: <041.cbb217fb4ffa21824da5fcede2622adb@localhost> References: <041.cbb217fb4ffa21824da5fcede2622adb@localhost> Message-ID: <050.74828999a336144aa65f829c5826af91@localhost> #3131: GHC stops after a single 'defined but not used' warning -------------------------+-------------------------------------------------- Reporter: nr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: No response from submitter, and I can't reproduce this with either 6.10.1 or the HEAD, so closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 09:29:09 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 09:10:47 2009 Subject: [GHC] #3389: CPP strips out C-style comments In-Reply-To: <047.ed7a4a8a5db27a5742ce2338e8823121@localhost> References: <047.ed7a4a8a5db27a5742ce2338e8823121@localhost> Message-ID: <056.1fb74a5343f85e12b5c2f940e2275fa1@localhost> #3389: CPP strips out C-style comments ---------------------------------+------------------------------------------ Reporter: nominolo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 6.10.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: As I understand it, there's no way we can stop cpp doing this, so I'm closing this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 09:35:23 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 09:17:54 2009 Subject: [GHC] #3111: Can't find DPH In-Reply-To: <050.65f6a7da171a14d95bacead6558ace4f@localhost> References: <050.65f6a7da171a14d95bacead6558ace4f@localhost> Message-ID: <059.c36cff437eea4f8a2d1fa691ab0da19b@localhost> #3111: Can't find DPH -------------------------------+-------------------------------------------- Reporter: colin-adams | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: As dph is now always built with GHC, there will not be an error due to it being absent. No response from submitter as to what the problem with installing dph was, and it presumably no longer applies anyway, so closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 10:00:15 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 09:42:00 2009 Subject: [GHC] #3137: ghc 6.10.2 fails to compile on Mac OS X Leopard In-Reply-To: <046.6f633fd5a4e98213439c39f0a29d0f1a@localhost> References: <046.6f633fd5a4e98213439c39f0a29d0f1a@localhost> Message-ID: <055.70fd9568e87c930cdc1ed18f831de75e@localhost> #3137: ghc 6.10.2 fails to compile on Mac OS X Leopard ---------------------------------+------------------------------------------ Reporter: mvanier | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks for testing; sounds like the problem is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 10:51:16 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 10:32:45 2009 Subject: [GHC] #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic In-Reply-To: <046.5cfaefd5bf9586a45cb1735e8d8f0098@localhost> References: <046.5cfaefd5bf9586a45cb1735e8d8f0098@localhost> Message-ID: <055.bf06c50364b06b4a00fed33fb83f7ad2@localhost> #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic -----------------------------------------+---------------------------------- Reporter: gparent | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: readline panic truncated | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------+---------------------------------- Comment (by simonmar): Remember the hi-file problem only affects people building GHC HEAD from source. The reporter said he was using GHC 6.10.3. I wonder if perhaps he switched from 64-bit to 32-bit, or vice versa? I don't think we record the platform in the hi file, only the GHC version. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 11:05:05 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 10:46:32 2009 Subject: [GHC] #3391: Generics compilation failure in combination with Data.Accessor deriving Message-ID: <046.34af5f63742143bd4bf7813e86933421@localhost> #3391: Generics compilation failure in combination with Data.Accessor deriving -----------------------------+---------------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: Generics | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- When trying to compile (using my latest build: 6.11.20090722) a file with -XGenerics I get the following error: {{{ "inplace/bin/ghc-stage2" -O -H64m -package-name clash-0.1 -hide-all- packages -i -ilibraries/clash-lib/c?ash/. -ilibraries/clash-lib/c?ash/dist- install/build -ilibraries/clash-lib/c?ash/dist-install/build/autogen -Ilibraries/clash- lib/c?ash/dist-install/build -Ilibraries/clash-lib/c?ash/dist-install/build/autogen -Ilibraries/clash- lib/c?ash/. -optP-include -optPlibraries/clash-lib/c?ash/dist- install/build/autogen/cabal_macros.h -package base-4.1.0.0 -package containers-0.2.0.1 -package data- accessor-0.2.1 -package data-accessor-template-0.2.1.1 -package filepath-1.1.0.1 -package ghc-6.11.20090722 -package haskell98-1.0.1.0 -package pretty-1.0.1.0 -package prettyclass-1.0.0.0 -package syb-0.1.0.0 -package template-haskell-2.4.0.0 -package transformers-0.1.4.0 -package vhdl-0.1 -O2 -XGenerics -fno-warn-deprecated-flags -Wwarn -odir libraries/clash-lib/c?ash /dist-install/build -hidir libraries/clash-lib/c?ash/dist-install/build -stubdir libraries /clash-lib/c?ash/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/clash- lib/c?ash/./CLasH/VHDL/VHDLTypes.hs -o libraries/clash-lib/c?ash/dist-install/build/CLasH/VHDL/VHDLTypes.o ... Loading some packages etc etc. ... /var/folders/wh/whtzeDfoGBCCu- 65jmvmZU+++TI/-Tmp-/ghc58528_0/ghc58528_0.s:4565:0: FATAL:Symbol _clashzm0zi1_CLasHziVHDLziVHDLTypes_zdgfromVHDLState_closure already defined. gmake[1]: *** [libraries/clash-lib/c?ash/dist- install/build/CLasH/VHDL/VHDLTypes.o] Error 1 gmake: *** [all] Error 2 }}} Indeed, when I compile with -dcore-lint I get to see this: {{{ *** Core Lint Errors: in result of Desugar *** : Duplicate variables brought into scope [[CLasH.VHDL.VHDLTypes.$gfromTypeState, CLasH.VHDL.VHDLTypes.$gfromTypeState, CLasH.VHDL.VHDLTypes.$gfromTypeState], [CLasH.VHDL.VHDLTypes.$gtoTypeState, CLasH.VHDL.VHDLTypes.$gtoTypeState, CLasH.VHDL.VHDLTypes.$gtoTypeState], [CLasH.VHDL.VHDLTypes.$gfromEntity, CLasH.VHDL.VHDLTypes.$gfromEntity, CLasH.VHDL.VHDLTypes.$gfromEntity], [CLasH.VHDL.VHDLTypes.$gtoEntity, CLasH.VHDL.VHDLTypes.$gtoEntity, CLasH.VHDL.VHDLTypes.$gtoEntity], [CLasH.VHDL.VHDLTypes.$gfromOrdType, CLasH.VHDL.VHDLTypes.$gfromOrdType, CLasH.VHDL.VHDLTypes.$gfromOrdType], [CLasH.VHDL.VHDLTypes.$gtoOrdType, CLasH.VHDL.VHDLTypes.$gtoOrdType, CLasH.VHDL.VHDLTypes.$gtoOrdType], [CLasH.VHDL.VHDLTypes.$gfromHType, CLasH.VHDL.VHDLTypes.$gfromHType, CLasH.VHDL.VHDLTypes.$gfromHType], [CLasH.VHDL.VHDLTypes.$gtoHType, CLasH.VHDL.VHDLTypes.$gtoHType, CLasH.VHDL.VHDLTypes.$gtoHType], [CLasH.VHDL.VHDLTypes.$gfromVHDLState, CLasH.VHDL.VHDLTypes.$gfromVHDLState], [CLasH.VHDL.VHDLTypes.$gtoVHDLState, CLasH.VHDL.VHDLTypes.$gtoVHDLState]] *** Offending Program *** .. Many, Many lines of Core output .. }}} Note that when I compile without -XGenerics (but with -dcore-lint) I do not get any error. I assume it has something to do with the following two lines in my sourcecode: {{{ $( Data.Accessor.Template.deriveAccessors ''TypeState ) $( Data.Accessor.Template.deriveAccessors ''VHDLState ) }}} As there are no errors when I remove those two TH splices (Sadly so, I need those accessors) The implementation of Data.Accessor.Template.deriveAccessors can be found here (it's patched to work with version 2.4 of the template-haskell library): [http://github.com/christiaanb/data- accessor/blob/988137e3cb152ff0c66ec97919069d765b3669c6/template/src/Data/Accessor/Template.hs] Maybe it's related to: #2456 For me it's not such a big problem as I will just compile that file with the NoGenerics Language pragma. But I would still like to know what might be causing this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 11:37:11 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 11:18:37 2009 Subject: [GHC] #3391: Generics compilation failure in combination with Data.Accessor deriving In-Reply-To: <046.34af5f63742143bd4bf7813e86933421@localhost> References: <046.34af5f63742143bd4bf7813e86933421@localhost> Message-ID: <055.3f0b5ffd61f01d174a6f0acb8c410830@localhost> #3391: Generics compilation failure in combination with Data.Accessor deriving ---------------------------------+------------------------------------------ Reporter: darchon | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: Generics | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown Comment: Ah I see what is going on. Fixing. S -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 12:04:07 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 11:45:35 2009 Subject: [GHC] #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic In-Reply-To: <046.5cfaefd5bf9586a45cb1735e8d8f0098@localhost> References: <046.5cfaefd5bf9586a45cb1735e8d8f0098@localhost> Message-ID: <055.1aef079beba3bf33e29ef1a116fece03@localhost> #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic -----------------------------------------+---------------------------------- Reporter: gparent | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: invalid Keywords: readline panic truncated | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by gparent): * status: new => closed * resolution: => invalid Comment: Replying to [comment:3 simonmar]: > Remember the hi-file problem only affects people building GHC HEAD from source. The reporter said he was using GHC 6.10.3. > > I wonder if perhaps he switched from 64-bit to 32-bit, or vice versa? I don't think we record the platform in the hi file, only the GHC version. No, I did not. The problem was indeed existing .hi files in the dist directory of the readline package I downloaded. Thanks everyone! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 12:08:01 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 11:49:27 2009 Subject: [GHC] #3391: Generics compilation failure in combination with Data.Accessor deriving In-Reply-To: <046.34af5f63742143bd4bf7813e86933421@localhost> References: <046.34af5f63742143bd4bf7813e86933421@localhost> Message-ID: <055.ffaa596e3cb1b3af55eebdc5d1029929@localhost> #3391: Generics compilation failure in combination with Data.Accessor deriving -----------------------------------------------+---------------------------- Reporter: darchon | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: Generics | Difficulty: Unknown Testcase: typecheck/should_compile/T3391 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------------+---------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T3391 * status: new => closed * resolution: => fixed Comment: Good stuff. Fixed by {{{ Thu Jul 23 16:58:03 BST 2009 simonpj@microsoft.com * Fix Trac #3391: make generic to/from bindings only for newly-declared types Before this patch we were bogusly making to/from bindings for all data types in the TcGblEnv. But that is wrong when we have multiple "chunks" of bindings in Template Haskell. We should start from the declarations themselves. Easy. M ./compiler/typecheck/TcDeriv.lhs -7 +7 }}} Thanks for the report Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 23 12:44:24 2009 From: trac at galois.com (GHC) Date: Thu Jul 23 12:26:54 2009 Subject: [GHC] #1496: Newtypes and type families combine to produce inconsistent FC(X) axiom sets In-Reply-To: <045.d93d26e0bae3aef3676683e1847e945d@localhost> References: <045.d93d26e0bae3aef3676683e1847e945d@localhost> Message-ID: <054.bcdfc987cc00985b2476f055ece3f6c2@localhost> #1496: Newtypes and type families combine to produce inconsistent FC(X) axiom sets ----------------------------------------+----------------------------------- Reporter: sorear | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.7 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by pumpkin): * cc: pumpkingod@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 03:40:55 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 03:22:20 2009 Subject: [GHC] #3273: memory leak due to optimisation In-Reply-To: <043.8d7f62a0a1af41f2de804ebbbba872f7@localhost> References: <043.8d7f62a0a1af41f2de804ebbbba872f7@localhost> Message-ID: <052.86cd878af64f850136113f4829adbe44@localhost> #3273: memory leak due to optimisation -----------------------------------------+---------------------------------- Reporter: sebf | Owner: Type: run-time performance bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: OK, so the conclusion seems to be that, while this case is more interesting than #917, it is simply a manifestation of the full laziness space leak. And alas we don't know a good way to get the benefits of full laziness (sharing computation) without occasionally paying its costs (in terms of space). I'm going to close this one as a duplicate, and cross-link from #917. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 03:41:35 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 03:22:59 2009 Subject: [GHC] #917: -O introduces space leak In-Reply-To: <062.4116b6ef44458082738cb509a6e4cb7c@localhost> References: <062.4116b6ef44458082738cb509a6e4cb7c@localhost> Message-ID: <071.d950b6f18a8c1001439de4d7ca3a2a29@localhost> #917: -O introduces space leak ----------------------------------------+----------------------------------- Reporter: claus.reinke@talk21.com | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.5 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * testcase: => Comment: See also #3273 for another example of a space leak caused by the full laziness transformation. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 04:31:53 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 04:13:18 2009 Subject: [GHC] #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic In-Reply-To: <046.5cfaefd5bf9586a45cb1735e8d8f0098@localhost> References: <046.5cfaefd5bf9586a45cb1735e8d8f0098@localhost> Message-ID: <055.72226065e141b4812f5b768b5345c235@localhost> #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic -----------------------------------------+---------------------------------- Reporter: gparent | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: readline panic truncated | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by simonmar): * status: closed => reopened * resolution: invalid => Comment: I downloaded the readline package from that URL, and it doesn't seem to have any `.hi` files. Could you let me have a copy of the one you downloaded? (attaching it here is fine). I'm interested in exactly what happened. I suspect the `.hi` files are from a different platform (Linux 64-bit probably), but the same GHC version. We ought to be putting the platform name in the `.hi` files too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 11:30:29 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 11:11:51 2009 Subject: [GHC] #3392: export copyPermissions from System.Directory Message-ID: <044.f43f9c0d4bae4a938d0ec3b5319129f9@localhost> #3392: export copyPermissions from System.Directory ----------------------------------+----------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ----------------------------------+----------------------------------------- {{{ copyPermissions :: FilePath -> FilePath -> IO () }}} (currently an internal function) should be exported from `System.Directory`. It is not the same as {{{ getPermissions s >>= setPermissions d }}} as the `Permissions` type this uses is lossy. Deadline: 8th August (2 weeks). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 11:43:43 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 11:25:05 2009 Subject: [GHC] #3381: PROPOSAL: Remove Control.OldException In-Reply-To: <044.bea515c2e882a187756034c0cc466b95@localhost> References: <044.bea515c2e882a187756034c0cc466b95@localhost> Message-ID: <053.38b5fa92b266ba7e3e5f0d3e6c82bf16@localhost> #3381: PROPOSAL: Remove Control.OldException ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Thread starts here: http://www.haskell.org/pipermail/libraries/2009-July/012195.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 12:43:00 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 12:24:22 2009 Subject: [GHC] #3393: Add openFileTemplate, openBinaryFileTemplate to System.IO Message-ID: <044.9de646c5d20af2930ed2bccac502e1ac@localhost> #3393: Add openFileTemplate, openBinaryFileTemplate to System.IO -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- In `System.IO`, `openTempFile` and `openBinaryTempFile` mask the file permissions of the file they create with 0o600. However, we would like to use it for implementing things like `writeFileAtomic`, in which case we want the default file permissions to be used. I propose that we add `openFileTemplate` and `openBinaryFileTemplate` functions, which use the default permissions. Deadline: 8th August (2 weeks). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 12:45:08 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 12:26:30 2009 Subject: [GHC] #3393: Add openFileTemplate, openBinaryFileTemplate to System.IO In-Reply-To: <044.9de646c5d20af2930ed2bccac502e1ac@localhost> References: <044.9de646c5d20af2930ed2bccac502e1ac@localhost> Message-ID: <053.7408b5226dd7879c1a4cb33175efac52@localhost> #3393: Add openFileTemplate, openBinaryFileTemplate to System.IO ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Discussion starts here: http://www.haskell.org/pipermail/libraries/2009-July/012196.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 12:47:28 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 12:28:50 2009 Subject: [GHC] #3394: Make Permissions type abstract Message-ID: <044.198f856251ea3382d49901fb60012390@localhost> #3394: Make Permissions type abstract ----------------------------------+----------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/directory | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ----------------------------------+----------------------------------------- This task is to make a proposal to make the portable Permissions type abstract. We could then implement `copyPermissions` using `getPermissions` and `setPermissions`, for example, and functions in the unix and Win32 packages would be able to do more with this type than the portable interface. Originally part of #2610. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 12:47:54 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 12:29:17 2009 Subject: [GHC] #2610: File permission-related proposals In-Reply-To: <044.2484ad9dcf80cd653040fb3392e0b3ab@localhost> References: <044.2484ad9dcf80cd653040fb3392e0b3ab@localhost> Message-ID: <053.8f3e31f123b8e4ceb051fff545a1815e@localhost> #2610: File permission-related proposals ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: These are now #3393, #3392 and #3394 respectively. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 13:19:32 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 13:00:57 2009 Subject: [GHC] #1653: GHCi ':set' completion does not list all options In-Reply-To: <045.831bf1fe23d07db587092523d41ab0a3@localhost> References: <045.831bf1fe23d07db587092523d41ab0a3@localhost> Message-ID: <054.e93507b60872d64a590fc7b10b21a3a3@localhost> #1653: GHCi ':set' completion does not list all options -----------------------+---------------------------------------------------- Reporter: sorear | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This is now done in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 13:33:32 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 13:14:56 2009 Subject: [GHC] #1868: Exception fails all exception predicates In-Reply-To: <044.29f71b3210470c5eb60c417733ff995c@localhost> References: <044.29f71b3210470c5eb60c417733ff995c@localhost> Message-ID: <053.5a2ca6f69d4872718430f1e9263d0909@localhost> #1868: Exception fails all exception predicates -------------------------------+-------------------------------------------- Reporter: Orphi | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.8.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: I'm going to close this ticket. To fix it properly we would need a library proposal, either to add more predicates, or preferably to move to a proper exception hierarchy. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 13:44:02 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 13:25:55 2009 Subject: [GHC] #2180: Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock In-Reply-To: <045.aae0aee80d987ae754764eec42f593a9@localhost> References: <045.aae0aee80d987ae754764eec42f593a9@localhost> Message-ID: <054.c713b339fba600a4d0458e9c5e3cfd02@localhost> #2180: Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock ---------------------------------+------------------------------------------ Reporter: Baughn | Owner: Baughn Type: feature request | Status: assigned Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: 6.12 branch => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 13:47:01 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 13:28:33 2009 Subject: [GHC] #2211: Installing latest GHC-6.8.2 stable: pwd with floating point exception In-Reply-To: <044.6fa473611ed5d150325a47086f85da68@localhost> References: <044.6fa473611ed5d150325a47086f85da68@localhost> Message-ID: <053.8270e7259da491182faba2ba54a0c815@localhost> #2211: Installing latest GHC-6.8.2 stable: pwd with floating point exception -----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: critical | Resolution: invalid Keywords: Floating point exception | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by igloo): * status: reopened => closed * resolution: => invalid Comment: We don't have a way to keep this info up-to-date, and I think incorrect info would be worse than no info, so I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 13:55:52 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 13:37:16 2009 Subject: [GHC] #2006: unreachable GADT pattern clauses show up as warnings with -Wall In-Reply-To: <044.a004885c928a62e2a73bf12df457c462@localhost> References: <044.a004885c928a62e2a73bf12df457c462@localhost> Message-ID: <053.165ecbcc70bc096427b778007556dce6@localhost> #2006: unreachable GADT pattern clauses show up as warnings with -Wall ---------------------------------+------------------------------------------ Reporter: ryani | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by: {{{ Wed Jul 22 06:09:33 BST 2009 simonpj@microsoft.com * Take account of GADTs when reporting patterm-match overlap }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 13:58:11 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 13:39:36 2009 Subject: [GHC] #2210: ghci gets into weird state if loading a module with a bad LANGUAGE pragma In-Reply-To: <042.5443ce857d991a3638a2d4dd2d291753@localhost> References: <042.5443ce857d991a3638a2d4dd2d291753@localhost> Message-ID: <051.2fd03aad1aa31ef046083074ac938693@localhost> #2210: ghci gets into weird state if loading a module with a bad LANGUAGE pragma ---------------------------------+------------------------------------------ Reporter: bos | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This is fixed in the HEAD: {{{ b.hs:1:13: unsupported extension: BreakMe Failed, modules loaded: none. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 18:32:49 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 18:14:12 2009 Subject: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS In-Reply-To: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> References: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> Message-ID: <053.28b5ee4963f12a4362b0420a598d213a@localhost> #698: GHC's internal memory allocator never releases memory back to the OS ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by JeremyShaw): I believe that virtual memory counts against your quota on most VPSes. On my VPS with a 64MB quota, I have a Haskell-based server which only requires 7MB RSS (and 5MB of that is SHR), but requires 40MB virtual. In general, the threaded RTS seems to use a lot of virtual memory. On my system, the one-liner: {{{ main = getLine >> return () }}} compiled with, {{{ghc --make -O2 -threaded -o main}}} requires less than 1MB of RSS but 20MB of virtual. If (unused) virtual memory really does count against my quota, then there could be an actual costs savings involved... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 24 23:46:07 2009 From: trac at galois.com (GHC) Date: Fri Jul 24 23:27:30 2009 Subject: [GHC] #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic In-Reply-To: <046.5cfaefd5bf9586a45cb1735e8d8f0098@localhost> References: <046.5cfaefd5bf9586a45cb1735e8d8f0098@localhost> Message-ID: <055.94059f7061d18dfa6fe7dce98d68a456@localhost> #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic -----------------------------------------+---------------------------------- Reporter: gparent | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: readline panic truncated | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------+---------------------------------- Comment (by gparent): I'm sorry, I didn't phrase this correctly. The .hi files weren't in the package I downloaded, they were remnants from an earlier compile of the package that I did myself. So what happened is, I compiled readline-1.0.1.0 for version god-knows- what, and then I tried rebuilding it with a newer GHC version, without cleaning, and I ran into those .hi related errors. No 64-bit involved in the entire process. Just different GHC versions after a package upgrade. runhaskell Setup.hs clean (or if that doesn't work, rm -rf dist), then rebuilding, fixed the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 25 13:22:23 2009 From: trac at galois.com (GHC) Date: Sat Jul 25 13:03:44 2009 Subject: [GHC] #3395: Template Haskell crashes Message-ID: <051.8ddfdbe5023ec6ecffaddcf454ad0905@localhost> #3395: Template Haskell crashes -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The following fragment: {{{ {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH foo = $(return $ CompE [NoBindS (VarE $ mkName "undefined") ,BindS (VarP $ mkName "r1") (VarE $ mkName "undefined") ]) }}} when loaded gives: {{{ *** Exception: hsSyn\Convert.lhs:(427,14)-(428,33): Non-exhaustive patterns in case }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 25 13:28:31 2009 From: trac at galois.com (GHC) Date: Sat Jul 25 13:09:51 2009 Subject: [GHC] #3395: Template Haskell crashes In-Reply-To: <051.8ddfdbe5023ec6ecffaddcf454ad0905@localhost> References: <051.8ddfdbe5023ec6ecffaddcf454ad0905@localhost> Message-ID: <060.dcc9f095baf3d02726edbae657f31d5e@localhost> #3395: Template Haskell crashes ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by NeilMitchell): As a hint for anyone wanting to work around this bug, converting the list comp to a {{{do}}} block does work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 25 14:40:33 2009 From: trac at galois.com (GHC) Date: Sat Jul 25 14:21:53 2009 Subject: [GHC] #3395: Template Haskell crashes In-Reply-To: <051.8ddfdbe5023ec6ecffaddcf454ad0905@localhost> References: <051.8ddfdbe5023ec6ecffaddcf454ad0905@localhost> Message-ID: <060.619fe938d6df8a924aee9acb195e3dff@localhost> #3395: Template Haskell crashes ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. This represents {{{ [r1 <- undefined | undefined] }}} i.e. it generates incorrect Haskell. The HEAD gives a {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 6.11.20090722 for x86_64-unknown-linux): Malformed body }}} error. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 25 14:50:20 2009 From: trac at galois.com (GHC) Date: Sat Jul 25 14:31:40 2009 Subject: [GHC] #311: gmp's memory management In-Reply-To: <043.f6cbfda45c43862fefdcb63df98df61f@localhost> References: <043.f6cbfda45c43862fefdcb63df98df61f@localhost> Message-ID: <052.f1b84b84aea25dba51f71656874ccada@localhost> #311: gmp's memory management ---------------------------------+------------------------------------------ Reporter: as49 | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.12 branch Component: Compiler (FFI) | Version: 6.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: None => fixed Comment: It is now possible to build GHC with a pure Haskell Integer library, so I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 25 15:19:01 2009 From: trac at galois.com (GHC) Date: Sat Jul 25 15:00:19 2009 Subject: [GHC] #2995: ghc -Wall does not complain about unnecessary data constructor imports In-Reply-To: <048.f0e44db11fec5519d682367c28fd6c91@localhost> References: <048.f0e44db11fec5519d682367c28fd6c91@localhost> Message-ID: <057.0c535c927ed4c3006a8cb47c90a1de59@localhost> #2995: ghc -Wall does not complain about unnecessary data constructor imports ---------------------------------+------------------------------------------ Reporter: EyalLotem | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This module: {{{ import Prelude (id) import Data.Maybe (Maybe(Just)) f :: Maybe a -> Maybe a f = id }}} now gives: {{{ b.hs:3:0: Warning: The import of `Just' from module `Data.Maybe' is redundant }}} in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 25 15:29:15 2009 From: trac at galois.com (GHC) Date: Sat Jul 25 15:17:05 2009 Subject: [GHC] #2951: Add support for amd64-solaris2 platform In-Reply-To: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> References: <046.a9fb03ce427f6c0dddff7a23f09ab9c7@localhost> Message-ID: <055.2b1363a87892fe5802b0307c083ae619@localhost> #2951: Add support for amd64-solaris2 platform --------------------------------+------------------------------------------- Reporter: kgardas | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: GHC now builds for the platform of the bootstrapping compiler, so this bug is now fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 25 15:59:14 2009 From: trac at galois.com (GHC) Date: Sat Jul 25 15:40:34 2009 Subject: [GHC] #2608: Direct support for unit tests in Cabal In-Reply-To: <043.0f910c87967bdcd72df76a06d6dc0fa6@localhost> References: <043.0f910c87967bdcd72df76a06d6dc0fa6@localhost> Message-ID: <052.cfde5897c3052e4bffb5f1ff35f03569@localhost> #2608: Direct support for unit tests in Cabal ----------------------------------+----------------------------------------- Reporter: kaol | Owner: Type: proposal | Status: closed Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.6.1 Severity: minor | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Closing in favour of the Cabal tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 25 16:19:33 2009 From: trac at galois.com (GHC) Date: Sat Jul 25 16:00:52 2009 Subject: [GHC] #2995: ghc -Wall does not complain about unnecessary data constructor imports In-Reply-To: <048.f0e44db11fec5519d682367c28fd6c91@localhost> References: <048.f0e44db11fec5519d682367c28fd6c91@localhost> Message-ID: <057.dd91235a4595ceff88a5259f83bb5049@localhost> #2995: ghc -Wall does not complain about unnecessary data constructor imports ---------------------------------+------------------------------------------ Reporter: EyalLotem | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by tibbe): A tiny nit-pick. Is redundant the right word here? Shouldn't it be "unused"? When I hear the word redundant I think of something like this: {{{ import Data.Maybe (Maybe(Just)) import Data.Maybe a = Just "b" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 25 16:58:36 2009 From: trac at galois.com (GHC) Date: Sat Jul 25 16:39:55 2009 Subject: [GHC] #2995: ghc -Wall does not complain about unnecessary data constructor imports In-Reply-To: <048.f0e44db11fec5519d682367c28fd6c91@localhost> References: <048.f0e44db11fec5519d682367c28fd6c91@localhost> Message-ID: <057.8d6276911a0116878afc093edef0b3a0@localhost> #2995: ghc -Wall does not complain about unnecessary data constructor imports ---------------------------------+------------------------------------------ Reporter: EyalLotem | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): You get the same warning for redundant and completely unused imports. I don't think it's worth the extra code to distinguish the too. And redundant isn't exactly incorrect, it's just not as precise as it could be. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 25 17:06:40 2009 From: trac at galois.com (GHC) Date: Sat Jul 25 16:48:00 2009 Subject: [GHC] #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use In-Reply-To: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> References: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> Message-ID: <056.fc27b8708d30fcb7ced5d4ac18bc4f8d@localhost> #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use ---------------------------------+------------------------------------------ Reporter: seliopou | Owner: seliopou Type: feature request | Status: assigned Priority: normal | Milestone: Component: Build System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: darcs git | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by seliopou): * status: new => assigned Comment: The latest patch should work as expected. I changed the -r option to accept repo locations without the trailing "/ghc". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 25 17:15:54 2009 From: trac at galois.com (GHC) Date: Sat Jul 25 16:57:13 2009 Subject: [GHC] #311: gmp's memory management In-Reply-To: <043.f6cbfda45c43862fefdcb63df98df61f@localhost> References: <043.f6cbfda45c43862fefdcb63df98df61f@localhost> Message-ID: <052.ce487183d2502e19ad16d52c4ef4f4a8@localhost> #311: gmp's memory management ---------------------------------+------------------------------------------ Reporter: as49 | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.12 branch Component: Compiler (FFI) | Version: 6.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by isaacdupree): It's still a bug/issue for when GHC is built with GMP. Were we planning on switching to non-GMP as default or mandatory? (I think such a change would need more discussion, because some code might use the speed of GMP's algorithms on large numbers.) I guess just having non-gmp as a configure choice is a workaround for these users, although not a perfect or easy workaround -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jul 25 17:38:04 2009 From: trac at galois.com (GHC) Date: Sat Jul 25 17:19:24 2009 Subject: [GHC] #311: gmp's memory management In-Reply-To: <043.f6cbfda45c43862fefdcb63df98df61f@localhost> References: <043.f6cbfda45c43862fefdcb63df98df61f@localhost> Message-ID: <052.cbe3adc51c2659e4c141f663ad294c47@localhost> #311: gmp's memory management ---------------------------------+------------------------------------------ Reporter: as49 | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.12 branch Component: Compiler (FFI) | Version: 6.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): It's also now easy to create alternative integer backends, e.g. using a renamed gmp, or another C integer library. I don't think we intend to do anything else on this front, though. GMP will remain the default. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 26 03:06:01 2009 From: trac at galois.com (GHC) Date: Sun Jul 26 02:47:19 2009 Subject: [GHC] #3395: Template Haskell crashes In-Reply-To: <051.8ddfdbe5023ec6ecffaddcf454ad0905@localhost> References: <051.8ddfdbe5023ec6ecffaddcf454ad0905@localhost> Message-ID: <060.b7459a1610a7c581189902f68888e8fa@localhost> #3395: Template Haskell crashes ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by NeilMitchell): The order for CompE is non-intuitive, most other Template Haskell expressions follow their syntactic representation for order, but this doesn't. Could a note be added to the documentation? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 26 06:41:47 2009 From: trac at galois.com (GHC) Date: Sun Jul 26 06:23:25 2009 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@localhost> References: <046.37416aee19ee095c9a6e98285b215b72@localhost> Message-ID: <055.0713cc8e3e3c63ec4d0f55710e15a998@localhost> #915: Implement list fusion using streams instead of foldr/build ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.8 Severity: normal | Resolution: Keywords: fusion | Difficulty: Project (> 1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@cielonegro.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 26 07:30:53 2009 From: trac at galois.com (GHC) Date: Sun Jul 26 07:12:12 2009 Subject: [GHC] #3396: Parsing LANGUAGE pragma causes GHC panic Message-ID: <045.db1f57ea6e233812af6dd3af15c9fd6d@localhost> #3396: Parsing LANGUAGE pragma causes GHC panic -------------------+-------------------------------------------------------- Reporter: radekm | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------+-------------------------------------------------------- Parsing LANGUAGE pragma like this (notice the '*'): {{{ {-# LANGUAGE * #-} }}} causes: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): getOptions'.parseLanguage(2) went past eof token }}} Instead of the '*' you can write another character like '+', '-' etc. I'm using GHC from Arch Linux's repository (package: ghc 6.10.4-1). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 26 07:32:59 2009 From: trac at galois.com (GHC) Date: Sun Jul 26 07:14:17 2009 Subject: [GHC] #3396: Parsing LANGUAGE pragma causes GHC panic In-Reply-To: <045.db1f57ea6e233812af6dd3af15c9fd6d@localhost> References: <045.db1f57ea6e233812af6dd3af15c9fd6d@localhost> Message-ID: <054.45b3843c7c5f4c2aa1f772537c0cda1f@localhost> #3396: Parsing LANGUAGE pragma causes GHC panic -------------------------------+-------------------------------------------- Reporter: radekm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------------------+-------------------------------------------- Changes (by radekm): * architecture: Unknown/Multiple => x86 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 26 08:09:33 2009 From: trac at galois.com (GHC) Date: Sun Jul 26 07:50:51 2009 Subject: [GHC] #3396: Parsing LANGUAGE pragma causes GHC panic In-Reply-To: <045.db1f57ea6e233812af6dd3af15c9fd6d@localhost> References: <045.db1f57ea6e233812af6dd3af15c9fd6d@localhost> Message-ID: <054.999f5cfa11c4fce44745e9291e1f27cb@localhost> #3396: Parsing LANGUAGE pragma causes GHC panic ----------------------------------+----------------------------------------- Reporter: radekm | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. Happily, this is already fixed in the HEAD: {{{ j.hs:2:0: cannot parse LANGUAGE pragma: comma-separated list expected }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 26 11:12:07 2009 From: trac at galois.com (GHC) Date: Sun Jul 26 10:53:25 2009 Subject: [GHC] #2561: Using "ITstring !FastString" in Lexer.x goes wrong (internal error: stg_ap_v_ret) In-Reply-To: <044.9ac0e4e49ee8e155dd0628d5c362af04@localhost> References: <044.9ac0e4e49ee8e155dd0628d5c362af04@localhost> Message-ID: <053.365852e2017706e039d7b7f6546e2b53@localhost> #2561: Using "ITstring !FastString" in Lexer.x goes wrong (internal error: stg_ap_v_ret) ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I can't reproduce this in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 26 11:45:59 2009 From: trac at galois.com (GHC) Date: Sun Jul 26 11:27:17 2009 Subject: [GHC] #2800: deprecated OPTIONS flag warnings generated during dep chasing? In-Reply-To: <045.0e85c856f9a219b317597d25eed9584a@localhost> References: <045.0e85c856f9a219b317597d25eed9584a@localhost> Message-ID: <054.d1e0ac699435884d921f4b3ca374ff23@localhost> #2800: deprecated OPTIONS flag warnings generated during dep chasing? ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: The only reason putting `-fno-warn-deprecated-flags` in the Cabal file doesn't work is because Cabal is a special case, and wants to be bootstrappable with just `ghc --make`. I think we should just live with a couple of warnings in this case, rather than going to lots of effort to work around the problem. Also, the current warnings at least will stop being a problem as support for building with older GHC versions is dropped. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 26 12:21:04 2009 From: trac at galois.com (GHC) Date: Sun Jul 26 12:02:20 2009 Subject: [GHC] #3094: Some GHC.* module should export word size and heap object header size In-Reply-To: <045.907bdf02870cf9d7a457cb5fba873bca@localhost> References: <045.907bdf02870cf9d7a457cb5fba873bca@localhost> Message-ID: <054.0caadfb2b6c758699abe35a890b2a610@localhost> #3094: Some GHC.* module should export word size and heap object header size ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by igloo): Would you be happy with `GHC.Constants` exporting the same things as `Constants` in the `ghc` package? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 26 13:23:20 2009 From: trac at galois.com (GHC) Date: Sun Jul 26 13:04:42 2009 Subject: [GHC] #3397: :step hangs when -fbreak-on-exception is set Message-ID: <045.0c0cb085f9bbd1ffc018c8ff9c9523d7@localhost> #3397: :step hangs when -fbreak-on-exception is set -----------------------------+---------------------------------------------- Reporter: hamish | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 -----------------------------+---------------------------------------------- Stepping through code (that I can step through fine when -fbreak-on- exception is no set) hangs at the same place each time. The function I started stepping was in one module and the hang was in another (not sure if this is significant). Ctrl+C returns to the prompt (no other output) and a further :step at that point causes a "not at breakpoint". I wonder if the flag is causing something to be evaluated a second time (I understand that can cause :step to hang). Erik first noticed the problem in Leksah, but I can reproduce it in GHCi without using Leksah to control it. I'll try to get a minimal test case together. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 26 15:10:42 2009 From: trac at galois.com (GHC) Date: Sun Jul 26 14:52:07 2009 Subject: [GHC] #3389: CPP strips out C-style comments In-Reply-To: <047.ed7a4a8a5db27a5742ce2338e8823121@localhost> References: <047.ed7a4a8a5db27a5742ce2338e8823121@localhost> Message-ID: <056.571526b4a2f7b7df7b9814be358ae6d3@localhost> #3389: CPP strips out C-style comments ---------------------------------+------------------------------------------ Reporter: nominolo | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Driver | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by nominolo): * status: closed => reopened * type: bug => feature request * resolution: invalid => Comment: At least my version of {{{cpp}}} (GNU cpp on Mac OS X 10.5) claims to have this option: {{{ -C Do not discard comments. All comments are passed through to the output file, except for comments in processed directives, which are deleted along with the directive. You should be prepared for side effects when using -C; it causes the preprocessor to treat comments as tokens in their own right. For example, comments appearing at the start of what would be a directive line have the effect of turning that line into an ordinary source line, since the first token on the line is no longer a #. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jul 26 16:34:32 2009 From: trac at galois.com (GHC) Date: Sun Jul 26 16:15:47 2009 Subject: [GHC] #3168: Unhelpful error message about "hidden" packages In-Reply-To: <046.ff62d5eacb5bc3400e424ed1c5c251e4@localhost> References: <046.ff62d5eacb5bc3400e424ed1c5c251e4@localhost> Message-ID: <055.03c8b2d1cf4d88a01f8942edfe2f82e7@localhost> #3168: Unhelpful error message about "hidden" packages ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Now fixed: {{{ $ ./Setup build Preprocessing library pretty-1.0.1.0... Building pretty-1.0.1.0... Text/PrettyPrint/HughesPJ.hs:217:7: Could not find module `System.Directory': It is a member of the hidden package `directory-1.0.0.2'. Perhaps you need to add `directory' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. }}} You only get this extra cabal hint if `-fbuilding-cabal-package` is passed, and Cabal HEAD now passes this to GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 27 07:52:51 2009 From: trac at galois.com (GHC) Date: Mon Jul 27 07:34:07 2009 Subject: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS In-Reply-To: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> References: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> Message-ID: <053.bb408255c0371a9beb34dff6228191b9@localhost> #698: GHC's internal memory allocator never releases memory back to the OS ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Jeremy - I think what you're describing here is not related to freeing of memory in the RTS. The virtual memory used by the trivial program is mostly shared libraries. Try `cat /proc//maps` - on my x86_64/Linux system here, the trivial program without `-threaded` needs 16MB of VM, and with `-threaded` needs 20MB. The shared library mappings account for most of the 16MB, and the extra 4MB with `-threaded` is due to the OS threads which seem to reserve 2MB each. GHC's RTS has only allocated 1MB in each case, and there is no memory to free back to the OS. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 27 07:55:47 2009 From: trac at galois.com (GHC) Date: Mon Jul 27 07:37:02 2009 Subject: [GHC] #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic In-Reply-To: <046.5cfaefd5bf9586a45cb1735e8d8f0098@localhost> References: <046.5cfaefd5bf9586a45cb1735e8d8f0098@localhost> Message-ID: <055.e487af1658eb72dac57f71000d78c974@localhost> #3385: Compiling readline 1.0.1.0 on GHC 6.10.3 causes panic -----------------------------------------+---------------------------------- Reporter: gparent | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: invalid Keywords: readline panic truncated | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by simonmar): * status: reopened => closed * resolution: => invalid Comment: Replying to [comment:6 gparent]: > I'm sorry, I didn't phrase this correctly. The .hi files weren't in the package I downloaded, they were remnants from an earlier compile of the package that I did myself. > > So what happened is, I compiled readline-1.0.1.0 for version god-knows- what, and then I tried rebuilding it with a newer GHC version, without cleaning, and I ran into those .hi related errors. No 64-bit involved in the entire process. Just different GHC versions after a package upgrade. runhaskell Setup.hs clean (or if that doesn't work, rm -rf dist), then rebuilding, fixed the problem. Ok, then I'm still slightly mystified, as GHC should have detected that the old `.hi` files were from a different GHC version and emitted a suitable error message. Well, in the absence of any evidence we'll have to leave this one closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 27 08:05:46 2009 From: trac at galois.com (GHC) Date: Mon Jul 27 07:47:01 2009 Subject: [GHC] #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use In-Reply-To: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> References: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> Message-ID: <056.2b699cab53fd9179b80d44fb6bb5ad7c@localhost> #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use ---------------------------------+------------------------------------------ Reporter: seliopou | Owner: seliopou Type: feature request | Status: assigned Priority: normal | Milestone: Component: Build System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: darcs git | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Sorry, doesn't work for me: {{{ ~/darcs/ghc-testing > ./darcs-all pull == running darcs pull --repodir . /home/simonmar/ghc-HEAD/ghc darcs failed: Not a repository: /home/simonmar/ghc-HEAD/ghc (/home/simonmar/ghc-HEAD/ghc/_darcs/inventory: openBinaryFile: does not exist (No such file or directory)) darcs failed: 512 at ./darcs-all line 87. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 27 10:18:09 2009 From: trac at galois.com (GHC) Date: Mon Jul 27 09:59:25 2009 Subject: [GHC] #3398: Unicode output in GHC Message-ID: <047.de64825b187e674ad618957169425649@localhost> #3398: Unicode output in GHC -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: 2816 Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Unicode output is somewhat broken in GHC as a whole. We should fix it properly. Most output is generated by the Pretty module. Pretty has two ways to output: * `printLeftRender`, which is used when the rendering mode is `LeftMode`. This method uses the `BufWrite` module to speed up output. For `FastStrings`, the output will be in UTF-8, for strings and other characters the output takes the low 8 bits of each character. * `printDoc`, when used in modes other than `LeftMode` (e.g. for things like error messages and `-ddump`), calls `hPutStr` for strings which uses the prevailing encoding on stdout. However, it calls `hPutFS` for `FastStrings`, which always emits UTF-8. * In GHCi, there is an additional layer due to Haskeline, which pipes all the output through its own decoder (or tries to, I think there are cases not covered). This is all a bit of a mess. We should be using the Unicode layer in the IO library for all encoding/decoding now. I suggest that: * we leave `printLeftRender` alone. It is used for printing things like the `.s` file, and never outputs any Unicode characters because everything is Z-encoded. * `printDoc`, instead of `hPutFS`, should use `hPutStr . decodeFS` * We get rid of the Haskeline decoding layer. However, this will introduce a regression on Windows, because the Haskeline encoding layer currently does code-page encoding. Judah has mentioned looking at doing code-page encoding in the GHC IO library, so let's see what happens there. Once this is done, we can do #2507 (quotation characters in error messages). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 27 10:38:52 2009 From: trac at galois.com (GHC) Date: Mon Jul 27 10:20:18 2009 Subject: [GHC] #3114: "ghc -shared --make" gives panic In-Reply-To: <052.079c60d812f2d30299cbb39a250d1778@localhost> References: <052.079c60d812f2d30299cbb39a250d1778@localhost> Message-ID: <061.9ecc5623217e3ccc5f15693552529c78@localhost> #3114: "ghc -shared --make" gives panic ------------------------------------+--------------------------------------- Reporter: Mark_Spezzano | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: command line option | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by phyx): * cc: phyx (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 27 13:19:08 2009 From: trac at galois.com (GHC) Date: Mon Jul 27 13:00:22 2009 Subject: [GHC] #3094: Some GHC.* module should export word size and heap object header size In-Reply-To: <045.907bdf02870cf9d7a457cb5fba873bca@localhost> References: <045.907bdf02870cf9d7a457cb5fba873bca@localhost> Message-ID: <054.8b952c550ccae2d1f59ca2b6f8692007@localhost> #3094: Some GHC.* module should export word size and heap object header size ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by duncan): Replying to [comment:2 igloo]: > Would you be happy with `GHC.Constants` exporting the same things as `Constants` in the `ghc` package? Yep. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 27 13:19:06 2009 From: trac at galois.com (GHC) Date: Mon Jul 27 13:00:25 2009 Subject: [GHC] #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} Message-ID: <043.61bcbfbf5cb528673d0b1d82854dcbb9@localhost> #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} -----------------------------+---------------------------------------------- Reporter: iago | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Better (more general) type signatures would be {{{ deleteBy :: (b -> a -> Bool) -> b -> [a] -> [a] deleteFirstsBy :: (b -> a -> Bool) -> [b] -> [a] -> [a] }}} ''Example of why it is useful'': {{{ deleteBy ((==) . fst) 1 [(1,'a'), (2, 'b')] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 27 13:36:45 2009 From: trac at galois.com (GHC) Date: Mon Jul 27 13:17:58 2009 Subject: [GHC] #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} In-Reply-To: <043.61bcbfbf5cb528673d0b1d82854dcbb9@localhost> References: <043.61bcbfbf5cb528673d0b1d82854dcbb9@localhost> Message-ID: <052.dec93655f7258c780f58319320ea5815@localhost> #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} ------------------------------+--------------------------------------------- Reporter: iago | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by iago): Sorry, the example was wrong, it should be {{{ deleteBy (\x -> (x ==) . fst) 1 [(1,'a'), (2, 'b')] }}} or {{{ deleteBy ((==) . fst) (1,'a') [1,2] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 27 14:09:26 2009 From: trac at galois.com (GHC) Date: Mon Jul 27 13:50:41 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard Message-ID: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> #3400: OS X: ghc broken on Snow Leopard --------------------+------------------------------------------------------- Reporter: bbb | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: critical Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- I downloaded GHC-6.10.4-i386.pkg and installed it on a OS X 10.6 Snow Leopard seed. gcc in Snow Leopard defaults to x86_64. This breaks even trivial builds with GHC since it passes either no or incompatible flags. GHC should either produce proper x86_64 assembly or pass "-arch i386" to force a 32-bit build. An example follows. == Trivial source: == {{{ $ cat Foo.hs main = do putStrLn "Foo!" }}} == Direct build broken: == {{{ $ ghc --make Foo.hs -v3 Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 booted by GHC version 6.10.3.20090628 Using package config file: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/./package.conf hiding package base-3.0.3.1 to avoid conflict with later version base-4.1.0.0 wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 wired-in package integer mapped to integer-0.1.0.1 wired-in package base mapped to base-4.1.0.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package syb mapped to syb-0.1.0.1 wired-in package template-haskell mapped to template-haskell-2.3.0.1 wired-in package dph-seq mapped to dph-seq-0.3 wired-in package dph-par mapped to dph-par-0.3 Hsc static flags: -static *** Chasing dependencies: Chasing modules from: *Foo.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = Fri Jul 24 11:35:52 PDT 2009 ms_mod = main:Main, ms_imps = [] ms_srcimps = [] }] compile: input file Foo.hs Created temporary directory: /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24470_0 *** Checking old interface for main:Main: [1 of 1] Compiling Main ( Foo.hs, Foo.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 10 *** Simplify: Result size = 8 *** Tidy Core: Result size = 8 *** CorePrep: Result size = 10 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler: gcc -I. -c /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24470_0/ghc24470_0.s -o Foo.o /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:36:0: suffix or operands invalid for `push' /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:83:0: suffix or operands invalid for `push' /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:130:0: suffix or operands invalid for `push' /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:156:0: 32-bit absolute addressing is not supported for x86-64 /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:156:0: cannot do signed 4 byte relocation /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:159:0: 32-bit absolute addressing is not supported for x86-64 /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24470_0/ghc24470_0.s:159:0: cannot do signed 4 byte relocation *** Deleting temp files: Deleting: /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24470_0/ghc24470_0.s *** Deleting temp dirs: Deleting: /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24470_0 }}} == Via-C build broken: == {{{ $ ghc --make Foo.hs -v3 -fvia-c Glasgow Haskell Compiler, Version 6.10.4, for Haskell 98, stage 2 booted by GHC version 6.10.3.20090628 Using package config file: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/./package.conf hiding package base-3.0.3.1 to avoid conflict with later version base-4.1.0.0 wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 wired-in package integer mapped to integer-0.1.0.1 wired-in package base mapped to base-4.1.0.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package syb mapped to syb-0.1.0.1 wired-in package template-haskell mapped to template-haskell-2.3.0.1 wired-in package dph-seq mapped to dph-seq-0.3 wired-in package dph-par mapped to dph-par-0.3 Hsc static flags: -static *** Chasing dependencies: Chasing modules from: *Foo.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = Fri Jul 24 11:35:52 PDT 2009 ms_mod = main:Main, ms_imps = [] ms_srcimps = [] }] compile: input file Foo.hs Created temporary directory: /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0 *** Checking old interface for main:Main: [1 of 1] Compiling Main ( Foo.hs, Foo.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 10 *** Simplify: Result size = 8 *** Tidy Core: Result size = 8 *** CorePrep: Result size = 10 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** C Compiler: gcc -x c /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.hc -o /var/folders/p5 /p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.raw_s -DDONT_WANT_WIN32_DLL_SUPPORT -mdynamic-no-pic -march=i686 -fno-defer-pop -fomit-frame-pointer -fno-builtin -DSTOLEN_X86_REGS=4 -fwrapv -mno-omit- leaf-frame-pointer -fno-unit-at-a-time -ffloat-store -fno-strict-aliasing -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=610 -DTABLES_NEXT_TO_CODE -I . -I /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/base-4.1.0.0/include -I /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/include Using built-in specs. Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5646~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable- languages=c,objc,c++,obj-c++ --program-transform- name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple- darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686 -apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5646) /usr/libexec/gcc/i686-apple-darwin10/4.2.1/cc1 -quiet -v -I . -I /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/base-4.1.0.0/include -I /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/include -imultilib x86_64 -D__DYNAMIC__ -DDONT_WANT_WIN32_DLL_SUPPORT -DSTOLEN_X86_REGS=4 -D__GLASGOW_HASKELL__=610 -DTABLES_NEXT_TO_CODE /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.hc -quiet -dumpbase ghc24479_0.hc -mmacosx-version-min=10.6.0 -mdynamic-no-pic -march=i686 -mno-omit-leaf-frame-pointer -m64 -auxbase-strip /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.raw_s -O -Wimplicit -version -fno-defer-pop -fomit-frame-pointer -fno-builtin -fwrapv -fno- unit-at-a-time -ffloat-store -fno-strict-aliasing -o /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.raw_s ignoring nonexistent directory "/usr/lib/gcc/i686-apple- darwin10/4.2.1/../../../../i686-apple-darwin10/include" #include "..." search starts here: #include <...> search starts here: . /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/base-4.1.0.0/include /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/include /usr/local/include /usr/lib/gcc/i686-apple-darwin10/4.2.1/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-/ghc24479_0/ghc24479_0.hc:1:0: error: CPU you selected does not support x86-64 instruction set GNU C version 4.2.1 (Apple Inc. build 5646) (i686-apple-darwin10) compiled by GNU C version 4.2.1 (Apple Inc. build 5646). GGC heuristics: --param ggc-min-expand=150 --param ggc-min-heapsize=131072 *** Deleting temp files: Deleting: /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.raw_s /var/folders/p5 /p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.hc Warning: deleting non-existent /var/folders/p5/p5hZ- IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0/ghc24479_0.raw_s *** Deleting temp dirs: Deleting: /var/folders/p5/p5hZ-IyTHEamZkUAcT8VfU+++TM/-Tmp-//ghc24479_0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 27 23:14:16 2009 From: trac at galois.com (GHC) Date: Mon Jul 27 22:55:27 2009 Subject: [GHC] #3401: unintuitive error message about unbalanced parentheses Message-ID: <045.20c6ca59181c0a850cc49f638c2df213@localhost> #3401: unintuitive error message about unbalanced parentheses --------------------+------------------------------------------------------- Reporter: tinlyx | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- A minimal test case is as follows: testFunc file = do let file1 = file) return file1 If you try to load it, you will get: ...\test.hs:111:2: The last statement in a 'do' construct must be an expression This error message is kind of unfriendly, and probably only GHC authors know how a mismatched parenthesis can lead to such an error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jul 27 23:34:11 2009 From: trac at galois.com (GHC) Date: Mon Jul 27 23:15:23 2009 Subject: [GHC] #3401: unintuitive error message about unbalanced parentheses In-Reply-To: <045.20c6ca59181c0a850cc49f638c2df213@localhost> References: <045.20c6ca59181c0a850cc49f638c2df213@localhost> Message-ID: <054.b7ecdc816467c611d5a292c0b36c6827@localhost> #3401: unintuitive error message about unbalanced parentheses ----------------------+----------------------------------------------------- Reporter: tinlyx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple ----------------------+----------------------------------------------------- Comment (by isaacdupree): I'm not such a GHC author, but it's because the closing-parenthesis terminates the "do" layout (which is a non-error in some cases if there had been an open-parenthesis before the "do" for example). I guess it reports the error in "do"-syntax before getting to the mismatched parenthesis error. That said, I'd think that GHC ought to be able to look ahead more. Also for the "mismatched parentheses (maybe incorrect indentation?)" error. If parentheses, *regardless* of layout, are still mismatched, then that's definitely an error that could be reported as such :-) (implementing that might be more adifficult though.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 28 04:03:36 2009 From: trac at galois.com (GHC) Date: Tue Jul 28 03:44:49 2009 Subject: [GHC] #999: Misattributed parse error in do block In-Reply-To: <057.38b4e5ace3d6beb45133f8b4750f80d2@localhost> References: <057.38b4e5ace3d6beb45133f8b4750f80d2@localhost> Message-ID: <066.d7504196ba89b0a824102181ffd4e5a6@localhost> #999: Misattributed parse error in do block -----------------------------------+---------------------------------------- Reporter: red5_2@hotmail.com | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler (Parser) | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------+---------------------------------------- Comment (by simonmar): see also #3401 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 28 04:03:43 2009 From: trac at galois.com (GHC) Date: Tue Jul 28 03:44:54 2009 Subject: [GHC] #3401: unintuitive error message about unbalanced parentheses In-Reply-To: <045.20c6ca59181c0a850cc49f638c2df213@localhost> References: <045.20c6ca59181c0a850cc49f638c2df213@localhost> Message-ID: <054.5ecff626f488a2d4ae7f2ba69bd500a6@localhost> #3401: unintuitive error message about unbalanced parentheses ---------------------------------+------------------------------------------ Reporter: tinlyx | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: See #999 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 28 05:04:50 2009 From: trac at galois.com (GHC) Date: Tue Jul 28 04:46:00 2009 Subject: [GHC] #3402: internal error: ARR_WORDS object entered! Message-ID: <044.eda0f81b8249dde6fbc220a86607b25d@localhost> #3402: internal error: ARR_WORDS object entered! -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I got this while playing around with `vacuum-cairo`: {{{ $ ghci ghci> :m +System.Vacuum.Cairo ghci> :m +Data.Text ghci> :m +Data.IntMap ghci> view $ fromList [(1, "hi" :: Text)] : internal error: ARR_WORDS object entered! (GHC version 6.10.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jul 28 17:01:58 2009 From: trac at galois.com (GHC) Date: Tue Jul 28 16:43:12 2009 Subject: [GHC] #3403: linear stack usage where constant stack usage expected Message-ID: <044.c42570fd5e569e69e860d17ee2825cf7@localhost> #3403: linear stack usage where constant stack usage expected -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- I would expect this program: {{{ {-# LANGUAGE BangPatterns #-} module Main (main) where import qualified Data.Set as Set import Data.Set (Set) data Result = Result !S1 !S2 type S1 = Set () type S2 = Set () input :: [[(Int, ())]] input = replicate 1000 (replicate 400 (100, ())) main :: IO () main = do let Result s1 s2 = doAll Set.empty Set.empty () input print $ Set.size s1 print $ Set.size s2 doAll :: S1 -> S2 -> () -> [[(Int, ())]] -> Result doAll !s1 !s2 !_ [] = Result s1 s2 doAll !s1 !s2 !unit ([] : xs) = doAll s1 s2 unit xs doAll !s1 !s2 !unit (((t, _) : x1) : x2 : xs) | t >= 99999 = doAll s1 s2 unit (x1 : x2 : xs) doAll !s1 !s2 !unit (((_, ()) : x) : xs) = doAll s1 s2 unit (x : xs) }}} to run through the input list in constant stack space, and finish successfully. However, with the HEAD (and 6.8.2 and 6.10.3): {{{ $ ghc -O --make foo -ddump-simpl > out $ ./foo Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. }}} The `doAll` function ends up like this: {{{ Rec { Main.main_$wdoAll :: Main.S1 -> Main.S2 -> [[(GHC.Types.Int, ())]] -> (# Main.S1, Main.S2 #) GblId [Arity 3 NoCafRefs Str: DmdType SSS] Main.main_$wdoAll = \ (w_sXJ :: Main.S1) (w1_sXK :: Main.S2) (w2_sXO :: [[(GHC.Types.Int, ())]]) -> case w_sXJ of s1_Xgz { __DEFAULT -> case w1_sXK of s2_XgE { __DEFAULT -> case w2_sXO of _ { [] -> (# s1_Xgz, s2_XgE #); : ds_dqj xs_ags -> case ds_dqj of _ { [] -> Main.main_$wdoAll s1_Xgz s2_XgE xs_ags; : ds1_dqk x1_agJ -> case ds1_dqk of _ { (t_agH, ds2_dql) -> let { fail_sY1 :: Main.Result LclId [Str: DmdType m] fail_sY1 = case ds2_dql of _ { () -> case Main.main_$wdoAll s1_Xgz s2_XgE (GHC.Types.: @ [(GHC.Types.Int, ())] x1_agJ xs_ags) of _ { (# ww1_sXU, ww2_sXV #) -> Main.Result ww1_sXU ww2_sXV } } } in case xs_ags of wild3_XF { [] -> case fail_sY1 of _ { Main.Result ww1_sXU ww2_sXV -> (# ww1_sXU, ww2_sXV #) }; : x2_agL xs1_agN -> case t_agH of _ { GHC.Types.I# x_axj -> case GHC.Prim.>=# x_axj 99999 of _ { GHC.Bool.False -> case fail_sY1 of _ { Main.Result ww1_sXU ww2_sXV -> (# ww1_sXU, ww2_sXV #) }; GHC.Bool.True -> Main.main_$wdoAll s1_Xgz s2_XgE (GHC.Types.: @ [(GHC.Types.Int, ())] x1_agJ wild3_XF) } } } } } } } } end Rec } }}} It looks like the problem is that rather than just recursively tail- calling itself, it calls itself in `fail_sY1`, builds a `Result`, and then takes the result apart again to return an unboxed tuple. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 29 04:55:24 2009 From: trac at galois.com (GHC) Date: Wed Jul 29 04:36:45 2009 Subject: [GHC] #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} In-Reply-To: <043.61bcbfbf5cb528673d0b1d82854dcbb9@localhost> References: <043.61bcbfbf5cb528673d0b1d82854dcbb9@localhost> Message-ID: <052.3c3fd4e2aa411b570faa470cb9114ae9@localhost> #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} ------------------------------+--------------------------------------------- Reporter: iago | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by maeder): Your proposal shows to me that there is another generalization of `delete` (I think a better one than `deleteBy`), let's call it `deleteFirst` which is a variant of `filter` with a negated predicate, that stops immediately after one element has been removed. {{{ deleteFirst :: (a -> Bool) -> [a] -> [a] deleteFirst p l = let (ft, rt) = break p l in ft ++ drop 1 rt delete :: Eq a => a -> [a] -> [a] delete a = deleteFirst (== a) }}} (In the type signature of your above function `deleteFirstsBy` the argument lists '[a]' and '[b]' should be swapped, because the second argument is taken away from the first one.) Maybe a better alternative for `deleteFirstsBy` would be `deleteFirsts`: {{{ deleteFirsts :: [a -> Bool] -> [a] -> [a] deleteFirsts fs l = foldr deleteFirst l fs deleteFirstsBy :: (b -> a -> Bool) -> [a] -> [b] -> [a] deleteFirstsBy eq l r = deleteFirsts (map eq r) l }}} But, since hardly anybody wants to touch Data.List, I would vote for closing this ticket -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 29 05:06:28 2009 From: trac at galois.com (GHC) Date: Wed Jul 29 04:47:40 2009 Subject: [GHC] #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} In-Reply-To: <043.61bcbfbf5cb528673d0b1d82854dcbb9@localhost> References: <043.61bcbfbf5cb528673d0b1d82854dcbb9@localhost> Message-ID: <052.dce785bd8abda18a78515df4707e4926@localhost> #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} ------------------------------+--------------------------------------------- Reporter: iago | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by iago): The proposal doesn't require change code itself, it is just use the more general type signature instead of restrict it unnecessary. The change wouldn't break any code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 29 05:23:42 2009 From: trac at galois.com (GHC) Date: Wed Jul 29 05:05:01 2009 Subject: [GHC] #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} In-Reply-To: <043.61bcbfbf5cb528673d0b1d82854dcbb9@localhost> References: <043.61bcbfbf5cb528673d0b1d82854dcbb9@localhost> Message-ID: <052.e0a0c9f30cd09e5dd7b49e13c22393ce@localhost> #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} ------------------------------+--------------------------------------------- Reporter: iago | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by maeder): Another argument against this proposal is, that an "equality" function taking different argument types is rather unintuitive. Who actually needs this generalization and is able to understand this from the documentation? Orthogonality would also require to check if the other "By"-functions can be generalized to swallow an "(b -> a -> Bool)" argument. (Indeed `intersectBy` could be generalized, too.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 29 13:06:16 2009 From: trac at galois.com (GHC) Date: Wed Jul 29 12:47:24 2009 Subject: [GHC] #3271: New methods for Data.Sequence In-Reply-To: <053.cc9895e43857ea386bfb254a48e9e83f@localhost> References: <053.cc9895e43857ea386bfb254a48e9e83f@localhost> Message-ID: <062.26150194819d2f93f0080ddfd4f47658@localhost> #3271: New methods for Data.Sequence ----------------------------------+----------------------------------------- Reporter: LouisWasserman | Owner: LouisWasserman Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by LouisWasserman): * version: 6.10.2 => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 29 16:58:47 2009 From: trac at galois.com (GHC) Date: Wed Jul 29 16:39:56 2009 Subject: [GHC] #3404: Strictness analysis bug with Double Message-ID: <046.d8394ff39f5a8fb2e1c2ff08cf3f0634@localhost> #3404: Strictness analysis bug with Double -----------------------------+---------------------------------------------- Reporter: lpsmith | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This program will overflow the stack, even when compiled -O to turn on strictness analysis: {{{ main = print (sum [1..1e7] :: Double) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 29 17:17:58 2009 From: trac at galois.com (GHC) Date: Wed Jul 29 16:59:06 2009 Subject: [GHC] #3404: Strictness analysis bug with Double In-Reply-To: <046.d8394ff39f5a8fb2e1c2ff08cf3f0634@localhost> References: <046.d8394ff39f5a8fb2e1c2ff08cf3f0634@localhost> Message-ID: <055.60527ab8e78b67159bd79665668e7d50@localhost> #3404: Strictness analysis bug with Double ------------------------------+--------------------------------------------- Reporter: lpsmith | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by dons): sum is defined as foldl (+). For some atomic types (Int, Integer) we generate specialized versions, but not for Double currently. This is an example of the broader syndrome of irregular specializations in the base library. Other tickets: #2251 #2270 #2271 Notably it is solved by #915 or by doing regular RULES/SPECIALIZE for all atomic numeric types, for base functions on Num a => a ... Another solution is to use uvector (stream fusion again). {{{ import Data.Array.Vector main = print (sumU (enumFromToFracU 1 1e7) :: Double) $wfold :: Double# -> Double# -> Double# $wfold = \ (ww_s15b :: Double#) (ww1_s15f :: Double#) -> case >## ww1_s15f 1.00000005e7 of wild_aWD { False -> $wfold (+## ww_s15b ww1_s15f) (+## ww1_s15f 1.0); True -> ww_s15b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jul 29 21:58:51 2009 From: trac at galois.com (GHC) Date: Wed Jul 29 21:39:59 2009 Subject: [GHC] #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use In-Reply-To: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> References: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> Message-ID: <056.c776bfdd5c6ddf6f1d620b410eda663d@localhost> #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use ---------------------------------+------------------------------------------ Reporter: seliopou | Owner: seliopou Type: feature request | Status: assigned Priority: normal | Milestone: Component: Build System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: darcs git | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by seliopou): The latest patch (v4) has been tested on a checkout of {{{http://darcs.haskell.org}}}, a local checkout, and the git mirror. I also added a more descriptive commit message, reproduced below: {{{ Replace push-all with darcs-all This patch modifies darcs-all to have feature parity with push-all by recognizing two new options. * -i, equivalent to --ignore-failure in push-all * -r , specifies the remote repository darcs commands will use Some example commands: Get the libraries from a repository of your choosing. This is useful when working with a git mirror: $ ./darcs-all -r http://darcs.haskell.org get Pull changes. Used to be: $ ./push-all --pull http://darcs.haskell.org Is now: $ ./darcs-all -r http://darcs.haskell.org pull Or to use the default remote of the ghc repository: $ ./darcs-all pull }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 30 10:31:02 2009 From: trac at galois.com (GHC) Date: Thu Jul 30 10:12:07 2009 Subject: [GHC] #3405: ghc: panic! FamInstEnv.pprFamInstHdr Message-ID: <042.dded98492224a2f28c862d5e30a05f7e@localhost> #3405: ghc: panic! FamInstEnv.pprFamInstHdr -----------------------------+---------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I got this message during a compile: Appraisal/Account/XML.hs:1:0:ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): FamInstEnv.pprFamInstHdr Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Unfortunately, I am unable to provide a simplified source file that reproduces the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 30 11:34:46 2009 From: trac at galois.com (GHC) Date: Thu Jul 30 11:15:51 2009 Subject: [GHC] #3406: 'impossible' happened while messing around with ScopedTypeVariables Message-ID: <044.9724012c5b1b2098374ba8fb8be5fa12@localhost> #3406: 'impossible' happened while messing around with ScopedTypeVariables -------------------------------+-------------------------------------------- Reporter: RyanN | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: ScopedTypeVariabes | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------------------+-------------------------------------------- The attached bug.hs was an (incorrect) intermediate step on my way to figuring out how to make a form of heterogeneous collections using existential types. I had just switched on ScopedTypeVariables when I ran into this problem: ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for x86_64-unknown-linux): readFilledBox a{tv ary} [box] I tested it on 6.10.1 and 6.10.3 (both got the same error). I ran it on various flavors of Redhat Enterprise/CentOs. I also ran into the same crash using 6.8.2 on an 32 bit ubuntu machine, as well as 6.8.2 on a 64 bit ubuntu machine. -Ryan -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 30 11:40:17 2009 From: trac at galois.com (GHC) Date: Thu Jul 30 11:21:20 2009 Subject: [GHC] #3407: GHC.Prim documentation should mention GHC.Exts! Message-ID: <044.b2bcc86bcf34543dca950728f9a46ba1@localhost> #3407: GHC.Prim documentation should mention GHC.Exts! -----------------------------+---------------------------------------------- Reporter: RyanN | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I had a real headache while learning to use unboxed types yesterday because I couldn't find mention anywhere of how to *convert* between boxed and unboxed representations. (I.e. you unbox a single function and then need to call it from the larger program.) I read the original paper that mentions the "Int#" data constructor, and eventually found some code on the web with the I# constructor that's actually in use. But I still had to dig before I could find what module it was defined in! Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 30 12:53:49 2009 From: trac at galois.com (GHC) Date: Thu Jul 30 12:34:54 2009 Subject: [GHC] #3405: ghc: panic! FamInstEnv.pprFamInstHdr In-Reply-To: <042.dded98492224a2f28c862d5e30a05f7e@localhost> References: <042.dded98492224a2f28c862d5e30a05f7e@localhost> Message-ID: <051.b3082b653320daddf5972140cab9bac8@localhost> #3405: ghc: panic! FamInstEnv.pprFamInstHdr ------------------------------+--------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by dsf): We believe this was probably caused by mixing compiled and loaded versions of the same packages. Whether it is "correct" for this to provoke to an impossible error I can not say. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 30 13:39:38 2009 From: trac at galois.com (GHC) Date: Thu Jul 30 13:20:41 2009 Subject: [GHC] #3408: idle GC causes large CPU usage if run more frequently than 1 second Message-ID: <049.48be2d13214f4104fb7093c0a3d0accb@localhost> #3408: idle GC causes large CPU usage if run more frequently than 1 second -----------------------+---------------------------------------------------- Reporter: JeremyShaw | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.4 | Severity: normal Keywords: idle GC | Testcase: Os: Linux | Architecture: Unknown/Multiple -----------------------+---------------------------------------------------- I have a web server which exhibits unusual CPU usage. When it first starts it loads a bunch of state from disk -- around 800MB. It then sits idle consuming no CPU. If I make any request to the server, it starts using 30-60% of the CPU and never goes back down -- even if the request does not interact with the state system at all. If I disable idle GC, then the problem goes away. If I set idle GC time using, {{{+RTS -I1}}}, the problem goes away. If I set it to, {{{+RTS -I0.9999999}}}, then I see the CPU usage issue. Setting the {{{+RTS -I1}}} option is sufficient for now, but the documentation says I should report any weirdness. I do not have a simple test case for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jul 30 20:08:54 2009 From: trac at galois.com (GHC) Date: Thu Jul 30 19:49:58 2009 Subject: [GHC] #3406: 'impossible' happened while messing around with ScopedTypeVariables In-Reply-To: <044.9724012c5b1b2098374ba8fb8be5fa12@localhost> References: <044.9724012c5b1b2098374ba8fb8be5fa12@localhost> Message-ID: <053.1b23399130ed5a8a45a4243590cdd5bf@localhost> #3406: 'impossible' happened while messing around with ScopedTypeVariables --------------------------------+------------------------------------------- Reporter: RyanN | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: ScopedTypeVariabes | Testcase: Os: Linux | Architecture: x86_64 (amd64) --------------------------------+------------------------------------------- Comment (by RyanN): P.S. I run into the same problem using 6.8.3 on Mac Os. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 31 03:13:45 2009 From: trac at galois.com (GHC) Date: Fri Jul 31 02:55:22 2009 Subject: [GHC] #3405: ghc: panic! FamInstEnv.pprFamInstHdr In-Reply-To: <042.dded98492224a2f28c862d5e30a05f7e@localhost> References: <042.dded98492224a2f28c862d5e30a05f7e@localhost> Message-ID: <051.e6618db4f6d20c78f586e57380a107c9@localhost> #3405: ghc: panic! FamInstEnv.pprFamInstHdr ------------------------------+--------------------------------------------- Reporter: dsf | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by chak): * owner: => chak Comment: Thanks for the report. I think I know what the problem is. (Note to self: Cover `AbstractTyCon` in that function by just printing `data instance`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 31 10:30:52 2009 From: trac at galois.com (GHC) Date: Fri Jul 31 10:11:55 2009 Subject: [GHC] #3408: idle GC causes large CPU usage if run more frequently than 1 second In-Reply-To: <049.48be2d13214f4104fb7093c0a3d0accb@localhost> References: <049.48be2d13214f4104fb7093c0a3d0accb@localhost> Message-ID: <058.d5f77c66db0f30cf67c4cbb4585975d2@localhost> #3408: idle GC causes large CPU usage if run more frequently than 1 second ---------------------------------+------------------------------------------ Reporter: JeremyShaw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: idle GC | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.12 branch Comment: It's very odd that something is happening at the 1-second interval. Basically we need to figure out whether this is something GHC can fix, or whether it is something special to your app. The point of the idle GC is not performance primarily, it for the detection of deadlocked threads and for running finalizers. Without the idle GC, we don't detect deadlocks until the next GC, and if the system really is deadlocked it will never GC. The problem is that in the threaded RTS we don't know whether a thread in a foreign call is about to return or whether it is blocked for ever, so we have to make a guess about when the system is idle and try to figure out whether it is deadlocked. If you don't care about detecting deadlocks or running finalizers, then by all means disable the idle GC. Now, the problem you're describing sounds like this: when the idle GC runs, it starts some finalizers. The finalizers then run, and create some more finalizers. A bit later, the idle GC runs again, and so on - never reaching a fixed point. If that's your problem then you either need to turn off the idle GC or restructure the app so that finalizers don't create more finalizers. I don't understand how the 1-second parameter comes into it. Perhaps your app has a 1-second timer for something? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 31 16:10:57 2009 From: trac at galois.com (GHC) Date: Fri Jul 31 15:52:01 2009 Subject: [GHC] #3408: idle GC causes large CPU usage if run more frequently than 1 second In-Reply-To: <049.48be2d13214f4104fb7093c0a3d0accb@localhost> References: <049.48be2d13214f4104fb7093c0a3d0accb@localhost> Message-ID: <058.d59d0e614905592e7cff14acbc49f206@localhost> #3408: idle GC causes large CPU usage if run more frequently than 1 second ---------------------------------+------------------------------------------ Reporter: JeremyShaw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: idle GC | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by JeremyShaw): I am not knowingly using finalizers. But my application depends on dozens of libraries from hackage, so who knows what is in there :) I'll work on coming up with a sensible test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jul 31 20:25:28 2009 From: trac at galois.com (GHC) Date: Fri Jul 31 20:06:29 2009 Subject: [GHC] #3409: type variable out of scope in worker/wrapper transformation Message-ID: <045.9adc3defe572c3fa16e2251d91a15c7c@localhost> #3409: type variable out of scope in worker/wrapper transformation -----------------------------+---------------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I ran into a bug while using type families in an array library that I'm writing. The original error looked something like: {{{ Declaration for $wslice: Iface type variable out of scope: s }}} I've tried to strip down the code as much as possible into the attached cabal package with two modules. The package builds itself with -dcore- lint and -O2; so just running `cabal install` inside of the package should cause a Core Lint error. Let me know if there's any more information I can provide to help diagnose this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler