From trac at galois.com Mon Jun 1 05:14:43 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 04:58:49 2009 Subject: [GHC] #2362: allow full import syntax in GHCi In-Reply-To: <051.a17c861cfc196911194c3abd0e428c4d@localhost> References: <051.a17c861cfc196911194c3abd0e428c4d@localhost> Message-ID: <060.7109065687754dab415067b120002d97@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 | ---------------------------------+------------------------------------------ Comment (by simonmar): related: #3217 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 05:19:39 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 05:03:43 2009 Subject: [GHC] #2442: Heuristics to improve error messages for badly referenced things In-Reply-To: <053.d96b74737451be892238b37815ca44b6@localhost> References: <053.d96b74737451be892238b37815ca44b6@localhost> Message-ID: <062.39ea1c83802fdd340485e857971a6239@localhost> #2442: Heuristics to improve error messages for badly referenced things ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: simonpj Type: feature request | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 05:32:52 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 05:16:56 2009 Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled? In-Reply-To: <047.c01de827ffb9a59aafb72de68ac54369@localhost> References: <047.c01de827ffb9a59aafb72de68ac54369@localhost> Message-ID: <056.82080e7807a7600f7d783184795f8bab@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 simonmar): We (Simon & Simon) think the ideal state of affairs would be: * Allow `rec` in `do` (as Ross intended) * Deprecate `mdo` as far as flags go, there are two options: * have the existing `RecursiveDo` flag enable the new `rec` syntax, and deprecate the use of `mdo`. Eventually `mdo` would be removed as a keyword. * Define a new extension, e.g. `DoRec` for the new `rec` keyword, and deprecate the old `RecursiveDo` extension. The second approach has the benefit that we can identify obsolete code on Hackage without trying to compile it, but it means having two similarly- named extensions which could lead to confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 05:35:14 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 05:19:27 2009 Subject: [GHC] #1924: Rewrite the handling of values we get from ./configure In-Reply-To: <044.9ce32a75cdc46063892169755ff2cb07@localhost> References: <044.9ce32a75cdc46063892169755ff2cb07@localhost> Message-ID: <053.938244eae24c8c07229efc14a5b11399@localhost> #1924: Rewrite the handling of values we get from ./configure ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 05:34:38 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 05:19:27 2009 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.fd799cfa7c8cb33dcd0268ceb2e35260@localhost> #1876: Complete shared library support ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: duncan Type: task | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => duncan -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 05:35:31 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 05:19:43 2009 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.7c5229d292b6c20eabdece32fe301fb1@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT -------------------------------+-------------------------------------------- Reporter: dons | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: OpenBSD, Xen | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 05:36:35 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 05:20:41 2009 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.c6cdb99ec07a4d11def8b15e97c2ca14@localhost> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -----------------------------------------------+---------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------------+---------------------------- Changes (by simonmar): * priority: high => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 05:37:15 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 05:21:19 2009 Subject: [GHC] #2451: New signal-handling API In-Reply-To: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> References: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> Message-ID: <056.d9899bc94201ff0b1f22c4349ea722fd@localhost> #2451: New signal-handling API ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: proposal | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/unix | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 05:37:38 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 05:21:49 2009 Subject: [GHC] #2578: "ld: atom sorting error for ..." on OS X In-Reply-To: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> References: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> Message-ID: <053.730ec4b1e8ccef8aefc848947ebe938f@localhost> #2578: "ld: atom sorting error for ..." on OS X ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 05:38:43 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 05:22:54 2009 Subject: [GHC] #2793: CLDouble is nothing like a long double In-Reply-To: <047.5dadea2fc38a170289501238d399f214@localhost> References: <047.5dadea2fc38a170289501238d399f214@localhost> Message-ID: <056.50da1412537d1b39c4d2d7d819a41565@localhost> #2793: CLDouble is nothing like a long double ---------------------------------+------------------------------------------ Reporter: jedbrown | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => igloo Comment: Let's just remove it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 05:39:37 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 05:23:41 2009 Subject: [GHC] #2925: Linker mmap failure on FreeBSD/x86_64 In-Reply-To: <047.eaff3ca4aa8bcea6096eb0e3b35eda7f@localhost> References: <047.eaff3ca4aa8bcea6096eb0e3b35eda7f@localhost> Message-ID: <056.12b7f6d5575927e8483efdd7be35d4e3@localhost> #2925: Linker mmap failure on FreeBSD/x86_64 -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: FreeBSD Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 05:39:59 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 05:24:03 2009 Subject: [GHC] #2978: Add support for more characters to UnicodeSyntax In-Reply-To: <045.01e065f460d6968a8d3a0a8de34723f0@localhost> References: <045.01e065f460d6968a8d3a0a8de34723f0@localhost> Message-ID: <054.64c587a0ef898ab50768cdd70cc680ab@localhost> #2978: Add support for more characters to UnicodeSyntax ---------------------------------+------------------------------------------ Reporter: porges | Owner: simonmar Type: feature request | Status: new Priority: high | 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 simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 05:33:55 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 05:25:11 2009 Subject: [GHC] #1346: bootstrap from HC files In-Reply-To: <047.353746f1d61af31dcc9643e79add3cec@localhost> References: <047.353746f1d61af31dcc9643e79add3cec@localhost> Message-ID: <056.b696b33a1782bd4ce0a1dfd5515b61e1@localhost> #1346: bootstrap from HC files ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 05:41:08 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 05:25:16 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.354b7983f7e13bf2002fa28b98a2243f@localhost> #3132: x86 code generator generates bad FPU register names -------------------------------+-------------------------------------------- Reporter: int-e | Owner: benl 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 simonmar): * owner: => benl * cc: benl (added) Comment: Ben, would you care to look at this one? (if not, please just unassign yourself) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 06:09:41 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 06:00:44 2009 Subject: [GHC] #1346: bootstrap from HC files In-Reply-To: <047.353746f1d61af31dcc9643e79add3cec@localhost> References: <047.353746f1d61af31dcc9643e79add3cec@localhost> Message-ID: <056.8c291a8cfea15288bb43043d33a26bcf@localhost> #1346: bootstrap from HC files ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Porting to a new platform is now working again: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting Doing a non-bootstrapping build from HC files isn't something that we plan to support, especially given that the registerised via-C way will be disappearing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 06:34:00 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 06:18:06 2009 Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled? In-Reply-To: <047.c01de827ffb9a59aafb72de68ac54369@localhost> References: <047.c01de827ffb9a59aafb72de68ac54369@localhost> Message-ID: <056.6474de94293af1f30fe699e7a69979c3@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 duncan): I don't think I'd bother with changing the extension name. We can discover deprecated stuff on hackage automatically by other (more general) means. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 07:04:05 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 06:48:14 2009 Subject: [GHC] #3253: validate failure (GCC warning) In-Reply-To: <050.ebb2294c3e42762e8bd80739a4e081c3@localhost> References: <050.ebb2294c3e42762e8bd80739a4e081c3@localhost> Message-ID: <059.aa2f2c5a61d7c701c704ca783ee0e38e@localhost> #3253: validate failure (GCC warning) ----------------------------------+----------------------------------------- Reporter: isaacdupree | Owner: simonmar Type: bug | Status: reopened Priority: high | Milestone: 6.12.1 Component: libraries/process | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 07:13:14 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 06:58:28 2009 Subject: [GHC] #3265: Type operators can be defined without the TypeOperators extension flag In-Reply-To: <044.bd55a0547092a6d4c7f6613593a50b08@localhost> References: <044.bd55a0547092a6d4c7f6613593a50b08@localhost> Message-ID: <053.8b011b9fc9c517b7a3ef95c91591dd22@localhost> #3265: Type operators can be defined without the TypeOperators extension flag ---------------------------------+------------------------------------------ Reporter: nibro | Owner: simonpj Type: bug | 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): * owner: => simonpj * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 07:19:22 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 07:03:34 2009 Subject: [GHC] #3138: Returning a known constructor: GHC generates terrible code for cmonad In-Reply-To: <046.ecd79a44a24e66ebe8454442595b165e@localhost> References: <046.ecd79a44a24e66ebe8454442595b165e@localhost> Message-ID: <055.7e370841b8ee8187d1c6f4b8e05b4937@localhost> #3138: Returning a known constructor: GHC generates terrible code for cmonad -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | 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 augustss): I expect the code to be the same as the code for {{{ main = do rs <- newIORef 0 ri <- newIORef 0 writeIORef ri 1 let loop = do i <- readIORef ri if i < 1e3 then do s <- readIORef s writeIORef rs (s + 1/i) writeIORef ri (i+1) loop else return () loop s <- readIORef rs putStrLn $ "Almost infinity is " ++ show s }}} Because that's what the code does. Getting that far would require specializing the recursive while function (why doesn't ghc specialize recursive functions?). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 07:28:08 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 07:12:21 2009 Subject: [GHC] #3138: Returning a known constructor: GHC generates terrible code for cmonad In-Reply-To: <046.ecd79a44a24e66ebe8454442595b165e@localhost> References: <046.ecd79a44a24e66ebe8454442595b165e@localhost> Message-ID: <055.7b5f7280dcc42baab2a2ba6a5d3dcbbd@localhost> #3138: Returning a known constructor: GHC generates terrible code for cmonad -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | 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 augustss): A first thing to look at is the fact that there's still dictionaries in the code. There's no unresolved overloading in Inf.hs, so all dictionaries should be gone. To avoid the disturbing recursive while function, try this code instead: {{{ inf = runE $ do s <- auto 0 i <- auto 0 i =: 1 if1 ((i :: E m Double) <= 1e3) $ do s += 1/i i += 1 retrn s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 08:19:17 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 08:03:27 2009 Subject: [GHC] #3256: Extra EOT from NoBuffering mode in emacs In-Reply-To: <044.f071539e68c72dff76745c9af1d974f7@localhost> References: <044.f071539e68c72dff76745c9af1d974f7@localhost> Message-ID: <053.349c4e474c8b7f5af44904cd6e842b88@localhost> #3256: Extra EOT from NoBuffering mode in emacs ---------------------------------+------------------------------------------ Reporter: judah | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.4 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: As far as I can tell, this is not a bug in GHC. The same behaviour can be replicated with a C program: {{{ #include #include #include main() { char buf[1024]; struct termios termios; int r; tcgetattr(0,&termios); termios.c_lflag &= ~ECHO; termios.c_lflag &= ~ICANON; termios.c_cc[VMIN] = 1; termios.c_cc[VTIME] = 0; tcsetattr(0,TCSANOW,&termios); do { r = read(0, &buf, 1024); write(1, buf, r); } while (r != 0); exit(0); } }}} If you paste a line of 255 x's to the C program in emacs, you'll see a `^D` character inserted in the output, in exactly the same way as with the Haskell program. This appears to be something that emacs is doing when stdin has ICANON unset. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 08:35:55 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 08:20:03 2009 Subject: [GHC] #2793: CLDouble is nothing like a long double In-Reply-To: <047.5dadea2fc38a170289501238d399f214@localhost> References: <047.5dadea2fc38a170289501238d399f214@localhost> Message-ID: <056.eeb7c4a3fb91ce25ce6ded5c27ccb0d9@localhost> #2793: CLDouble is nothing like a long double ---------------------------------+------------------------------------------ Reporter: jedbrown | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by jedbrown): I personally don't have a problem with that, but some people care a lot about quad precision, mostly for very ill-conditioned problems or in order to get away with a numerically unstable method. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 09:25:17 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 09:09:21 2009 Subject: [GHC] #3247: GHCI segfaults when per-thread stack size is larger than max stack size In-Reply-To: <045.8f92b0bc876144cec71a99de4ec5ff73@localhost> References: <045.8f92b0bc876144cec71a99de4ec5ff73@localhost> Message-ID: <054.a5660d6a2680a47d995f59eb99057910@localhost> #3247: GHCI segfaults when per-thread stack size is larger than max stack size -------------------------------+-------------------------------------------- Reporter: earthy | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by simonmar): dup of #3156 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 09:25:26 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 09:09:29 2009 Subject: [GHC] #3247: GHCI segfaults when per-thread stack size is larger than max stack size In-Reply-To: <045.8f92b0bc876144cec71a99de4ec5ff73@localhost> References: <045.8f92b0bc876144cec71a99de4ec5ff73@localhost> Message-ID: <054.019394340704d121d618c1757c1ea099@localhost> #3247: GHCI segfaults when per-thread stack size is larger than max stack size -------------------------------+-------------------------------------------- Reporter: earthy | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 10:37:58 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 10:22:00 2009 Subject: [GHC] #3268: implement the Cabal ${pkgroot} spec extension Message-ID: <045.8be95892c9d19347370cbf9a54614c20@localhost> #3268: implement the Cabal ${pkgroot} spec extension -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Component: Package system Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- See the proposal for relative paths in installed package descriptions: http://www.haskell.org/pipermail/libraries/2009-May/011772.html Basically it amounts to replacing ghc's current `$topdir` and `$httptopdir` with variables that are interpreted relative to the package db file itself rather than relative to where ghc is installed (though for the global package db these coincide). The open question is how tools discover the location of the package dbs. The proposed spec extension does not specify this, but perhaps it should specify an extension to (the hypothetical) `hc-pkg` system to discover the default set of package dbs and their paths. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 11:43:18 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 11:27:23 2009 Subject: [GHC] #3269: Stop using PackedString in template-haskell; drop packedstring as a bootlib Message-ID: <047.abd640ec5c07016c46e6eb6bec9a7ca8@localhost> #3269: Stop using PackedString in template-haskell; drop packedstring as a bootlib -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: None | Version: 6.10.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- The `packedstring` library has been superseded by the `bytestring` and `text` libraries, yet we are still shipping it with GHC for only one reason: it is used in the representations of three types in `template- haskell`. The proposal is that we * make the types `ModName`, `PkgName`, and `OccName` from `Language.Haskell.TH.Syntax` into abstract newtypes (an API change) * change their representation from `PackedString` to `String` * drop the `packedstring` library from the bootlibs that GHC ships with Relevant discussions: * [http://www.haskell.org/pipermail/libraries/2008-November/010960.html] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 11:46:58 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 11:31:03 2009 Subject: [GHC] #3270: Stop using PackedString in template-haskell; drop packedstring as a bootlib Message-ID: <047.ae96a250e59fa9f3dea9027a4dd53845@localhost> #3270: Stop using PackedString in template-haskell; drop packedstring as a bootlib -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: None | Version: 6.10.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- The `packedstring` library has been superseded by the `bytestring` and `text` libraries, yet we are still shipping it with GHC for only one reason: it is used in the representations of three types in `template- haskell`. The proposal is that we * make the types `ModName`, `PkgName`, and `OccName` from `Language.Haskell.TH.Syntax` into abstract newtypes (an API change) * change their representation from `PackedString` to `String` * drop the `packedstring` library from the bootlibs that GHC ships with Relevant discussions: * [http://www.haskell.org/pipermail/libraries/2008-November/010960.html] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 11:47:31 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 11:31:35 2009 Subject: [GHC] #3269: Stop using PackedString in template-haskell; drop packedstring as a bootlib In-Reply-To: <047.abd640ec5c07016c46e6eb6bec9a7ca8@localhost> References: <047.abd640ec5c07016c46e6eb6bec9a7ca8@localhost> Message-ID: <056.305750369d83811f2a13c73f86fe0f13@localhost> #3269: Stop using PackedString in template-haskell; drop packedstring as a bootlib ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: None | Version: 6.10.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 12:06:58 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 11:51:01 2009 Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled? In-Reply-To: <047.c01de827ffb9a59aafb72de68ac54369@localhost> References: <047.c01de827ffb9a59aafb72de68ac54369@localhost> Message-ID: <056.26b1898190f6b004c161135f3e6ed9d2@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 isaacdupree): my feeling is to prefer `DoRec` -- it sounds more mnemonic to me; and it seems unpleasant for an extension to have two substantially different parsings that might conflict with existing code (if 'rec' is a variable name somewhere). e.g. how will haskell-src[-exts] deal with it after the Summer-of-Code effort? But I don't really mind either way. (P.S. do we have a way to mark extension-flags deprecated?) -Isaac -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 12:14:16 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 11:58:20 2009 Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled? In-Reply-To: <047.c01de827ffb9a59aafb72de68ac54369@localhost> References: <047.c01de827ffb9a59aafb72de68ac54369@localhost> Message-ID: <056.912eb9965ff721080f20527bd106c34a@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 isaacdupree): so if you want your code to compile on pre-6.12 you can: - just use `mdo` - use `rec` and enable `Arrows` also (I guess this hack could be, but shouldn't be, sanctioned by Cabal.. among other things, Arrows also introduces `proc` as a keyword, so it's not harmless) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 1 12:22:03 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 12:06:06 2009 Subject: [GHC] #3270: Stop using PackedString in template-haskell; drop packedstring as a bootlib In-Reply-To: <047.ae96a250e59fa9f3dea9027a4dd53845@localhost> References: <047.ae96a250e59fa9f3dea9027a4dd53845@localhost> Message-ID: <056.11c1f6f747d68849c080682ec3bc858d@localhost> #3270: Stop using PackedString in template-haskell; drop packedstring as a bootlib ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: None | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by guest): * cc: gwern0@gmail.com (added) Comment: This change has my support. -- Ticket URL: GHC The Glasgow Haskell Compiler From Sven.Panne at aedion.de Mon Jun 1 14:05:14 2009 From: Sven.Panne at aedion.de (Sven Panne) Date: Mon Jun 1 13:49:19 2009 Subject: [HOpenGL] renderString not working in ghci In-Reply-To: <20090520072414.GM12034@katherina.student.utwente.nl> References: <20090520072414.GM12034@katherina.student.utwente.nl> Message-ID: <200906012005.15088.Sven.Panne@aedion.de> [ Reprise of an old GHCi problem, GHC HQ read on please... ] Am Mittwoch, 20. Mai 2009 09:24:14 schrieb Matthijs Kooijman: > I've been playing around with GLUT (latest version from hackage, on Debian) > a bit yesterday and am having some troubles with renderString. It works > fine when I compile a binary using ghc, but when running from ghci I get an > error similar to the following (I don't have the actual error at hand atm). > > freeglut(): font 0xsomething not found > > From looking at the freeglut code, it seems this means that the font > pointer passed in does not match the address of any of the font variables > in the library. I'm not completely sure how the linking works in ghci, but > it appears that something goes wrong with dynamic linking? > > Is this a known problem, or does anyone have any pointers where to debug > this? After thinking about this for a while, I got a d?j? vu feeling and browsed through old mails, and there it was, the thread about the arcane, dark corners of dynamic linking and position independent code, where (almost) no man has gone before: ;-) http://www.haskell.org/pipermail/cvs-ghc/2007-September/038458.html I think that we finally came to the conclusion that we *have* to compile code with -fPIC on some platforms, including x86_64, but looking at the verbose output of the build step of the GLUT package on x86_64, one can see that there is nothing PIC-related at all. Adding "--ghc-option=-fPIC" to Cabal's build step for the GLUT package makes ARBOcclude.hs (and renderString in general) work again. So my questing is: Is this a bug in GHC, i.e. should it always use -fPIC implicitly? Or is this a bug in my GLUT package's .cabal file? I have a tendency to believe the former possibility... Or asked the other way round: Is there a reason why -fPIC is not the default for GHC? Cheers, S. From duncan.coutts at worc.ox.ac.uk Mon Jun 1 16:48:56 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Jun 1 16:33:14 2009 Subject: [HOpenGL] renderString not working in ghci In-Reply-To: <200906012005.15088.Sven.Panne@aedion.de> References: <20090520072414.GM12034@katherina.student.utwente.nl> <200906012005.15088.Sven.Panne@aedion.de> Message-ID: <1243889336.29805.81.camel@localhost> On Mon, 2009-06-01 at 20:05 +0200, Sven Panne wrote: > [ Reprise of an old GHCi problem, GHC HQ read on please... ] > > Am Mittwoch, 20. Mai 2009 09:24:14 schrieb Matthijs Kooijman: > > I've been playing around with GLUT (latest version from hackage, on Debian) > > a bit yesterday and am having some troubles with renderString. It works > > fine when I compile a binary using ghc, but when running from ghci I get an > > error similar to the following (I don't have the actual error at hand atm). > > > > freeglut(): font 0xsomething not found > > > > From looking at the freeglut code, it seems this means that the font > > pointer passed in does not match the address of any of the font variables > > in the library. I'm not completely sure how the linking works in ghci, but > > it appears that something goes wrong with dynamic linking? > > > > Is this a known problem, or does anyone have any pointers where to debug > > this? > > After thinking about this for a while, I got a d?j? vu feeling and browsed > through old mails, and there it was, the thread about the arcane, dark corners > of dynamic linking and position independent code, where (almost) no man has > gone before: ;-) > > http://www.haskell.org/pipermail/cvs-ghc/2007-September/038458.html I don't know how the problem reported in that message is related to the renderString problem (which I do not understand), but the behaviour you see there is not terribly surprising. It's an artefact of the way dynamic linking works and should not generally cause any problems. The only case where it should make a difference is if code is assigning any meaning to the address of functions, eg to compare them for identity. In that case going via a thunk will make a difference. Is that what freeglut is doing do you think? > I think that we finally came to the conclusion that we *have* to compile code > with -fPIC on some platforms, including x86_64, but looking at the verbose > output of the build step of the GLUT package on x86_64, one can see that there > is nothing PIC-related at all. Adding "--ghc-option=-fPIC" to Cabal's build > step for the GLUT package makes ARBOcclude.hs (and renderString in general) > work again. > > So my questing is: Is this a bug in GHC, i.e. should it always use -fPIC > implicitly? I rather suspect it's freeglut doing something dubious with comparing function pointers. > Or is this a bug in my GLUT package's .cabal file? I have a > tendency to believe the former possibility... Or asked the other way round: Is > there a reason why -fPIC is not the default for GHC? On most platforms -fPIC imposes some overhead and so it is only used when it's advantageous or necessary. On most platforms code that will live in a shared library should or must be compiled with -fPIC. x86-64 is one of the few architectures where the overhead is relatively low. Duncan From trac at galois.com Mon Jun 1 17:56:01 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 17:40:05 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.1955fafc9b0300c6d631d1f8f1138b17@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 | ---------------------------------+------------------------------------------ Changes (by asklinge): * cc: asklingenberg@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From Sven.Panne at aedion.de Mon Jun 1 18:39:07 2009 From: Sven.Panne at aedion.de (Sven Panne) Date: Mon Jun 1 18:23:10 2009 Subject: [HOpenGL] renderString not working in ghci In-Reply-To: <1243889336.29805.81.camel@localhost> References: <20090520072414.GM12034@katherina.student.utwente.nl> <200906012005.15088.Sven.Panne@aedion.de> <1243889336.29805.81.camel@localhost> Message-ID: <200906020039.07410.Sven.Panne@aedion.de> Am Montag, 1. Juni 2009 22:48:56 schrieb Duncan Coutts: > I don't know how the problem reported in that message is related to the > renderString problem (which I do not understand), but the behaviour you > see there is not terribly surprising. It's an artefact of the way > dynamic linking works and should not generally cause any problems. The word "generally" is a problem in itself. ;-) The main point is that GHCi'l dynamic linker behaves differently from the system's dynamic linker, so this is a very good reason to consider this a bug. It might not surface very often, but it is nevertheless a different behaviour a.k.a. bug. > The only case where it should make a difference is if code is assigning > any meaning to the address of functions, eg to compare them for > identity. In that case going via a thunk will make a difference. Is that > what freeglut is doing do you think? It is not about the address of functions, it is about data addresses. Here is the relevant snippet from GLUT's/freeglut's header file for non-Windows platforms: ---------------------------------------------------------------------- /* * I don't really know if it's a good idea... But here it goes: */ extern void* glutStrokeRoman; extern void* glutStrokeMonoRoman; extern void* glutBitmap9By15; ... /* * Those pointers will be used by following definitions: */ # define GLUT_STROKE_ROMAN ((void *) &glutStrokeRoman) # define GLUT_STROKE_MONO_ROMAN ((void *) &glutStrokeMonoRoman) # define GLUT_BITMAP_9_BY_15 ((void *) &glutBitmap9By15) ... ---------------------------------------------------------------------- As you can see, GLUT's fonts are represented by the addresses of global variables. This might not be the nicest way to do this, but it has to be done for binary compatibility reasons and there is *nothing* dubious about this. Note that e.g. we are very lucky that "errno" is a macro for a function call on all platforms for which -fPIC is relevant, otherwise we would have the same problem with it, too. The GLUT Haskell package uses a simple C wrapper around these macros: ---------------------------------------------------------------------- void* hs_GLUT_marshalBitmapFont(int fontID) { switch (fontID) { case 0 : return GLUT_BITMAP_8_BY_13; case 1 : return GLUT_BITMAP_9_BY_15; case 2 : return GLUT_BITMAP_TIMES_ROMAN_10; case 3 : return GLUT_BITMAP_TIMES_ROMAN_24; case 4 : return GLUT_BITMAP_HELVETICA_10; case 5 : return GLUT_BITMAP_HELVETICA_12; case 6 : return GLUT_BITMAP_HELVETICA_18; } return (void*)0; } ---------------------------------------------------------------------- For reasons explained in great length in the mail thread quoted, GHCi's linker doesn't link the wrapper correctly on some platforms when -fPIC is not used for its compilation. > I rather suspect it's freeglut doing something dubious with comparing > function pointers. The only one doing dubious things is GHCi's dynamic linker... ;-) > On most platforms -fPIC imposes some overhead and so it is only used > when it's advantageous or necessary. On most platforms code that will > live in a shared library should or must be compiled with -fPIC. x86-64 > is one of the few architectures where the overhead is relatively low. So my question is again: Why is -fPIC not the default for GHC on x86_64? If we don't want the overhead, that's OK (any benchmark numbers?), but then GHC's documentation should really contain a big, fat warning that GHCi's dynamic linker gets cases like the one above wrong. Cheers, S. From trac at galois.com Tue Jun 2 00:04:30 2009 From: trac at galois.com (GHC) Date: Mon Jun 1 23:48:37 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.a94ac837aabbc82f0d4c8f3c520b33b3@localhost> #3132: x86 code generator generates bad FPU register names -------------------------------+-------------------------------------------- Reporter: int-e | Owner: nobody 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 benl): * owner: benl => nobody Comment: The cmm code for the failing program contains the following: {{{ if (_c1Wu::I32 >= 1) goto c1Wx; _s1Ba::F64 = r1tw_closure; _s1Nk::F64 = %MO_F_Sub_W64(D1, _s1Ba::F64); _s1Nl::F64 = %MO_F_Mul_W64(F64[Sp + 12], _s1Nk::F64); }}} Note that r1tw_closure is not a F64. Here is a test-case that fails -dcmm-lint as well as -dstg-lint when compiled with -O2. {{{ module Spring where import Data.Array.Unboxed type Arr = UArray Int Double step :: Double -> Int -> Arr -> Arr step h sz y = listArray (0, 0) [] }}} {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 6.11.20090514 for i386-unknown-linux): *** Stg Lint ErrMsgs: in Stg2Stg *** : [in body of lambda with binders s{v sGe} [lid] :: ghc-prim:GHC.Prim.State#{(w) tc 32q} s{tv awN} [tv]] In a function application, function type doesn't match arg types: Function type: forall s{tv axt} [tv] i{tv axu} [tv]. (base:GHC.Arr.Ix{tc 2i} i{tv axu} [tv]) => (i{tv axu} [tv], i{tv axu} [tv]) -> base:GHC.ST.ST{tc r65} s{tv axt} [tv] (array-0.2.0.1:Data.Array.Base.STUArray{tc r6} s{tv axt} [tv] i{tv axu} [tv] ghc-prim:GHC.Types.Double{(w) tc 3u}) Arg types: base:GHC.Arr.Ix{tc 2i} ghc-prim:GHC.Types.Int{(w) tc 3J} (ghc-prim:GHC.Types.Int{(w) tc 3J}, ghc-prim:GHC.Types.Int{(w) tc 3J}) ghc-prim:GHC.Prim.State#{(w) tc 32q} s{tv awN} [tv] Expression: array-0.2.0.1:Data.Array.Base.newArray_8{v ra} [gid] base:GHC.Arr.$f14{v r9} [gid] main:Spring.lvl1{v r8} [gid] s{v sGe} [lid] }}} I'm not sure how to read the STG code, but it looks like something in the libs has been messed up, which has then been inlined. Perhaps validate should be compiling with all the lint options turned on? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 2 03:50:20 2009 From: trac at galois.com (GHC) Date: Tue Jun 2 03:34:29 2009 Subject: [GHC] #3138: Returning a known constructor: GHC generates terrible code for cmonad In-Reply-To: <046.ecd79a44a24e66ebe8454442595b165e@localhost> References: <046.ecd79a44a24e66ebe8454442595b165e@localhost> Message-ID: <055.fb87058a49bf2c4f7aa08519b6ada2a9@localhost> #3138: Returning a known constructor: GHC generates terrible code for cmonad -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | 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 simonpj): Indeed GHC isn't a supercompiler and doesn't specialise recursive functions for their call sites. As it happens, Peter Jonsson started yesterday as an intern to try just that! But as of today, no. (Except that, perhaps inconsistently, within a single module, we specialise overloaded functions (including recursive ones) at the types where they are called locally. You can use a SPECIALISE pragma to make that happen for types where there is no local call.) Even non-recursive functions are inlined only if they look small enough. That can indeed lead to dictionaries being passed instead of code being duplicated. Meanwhile I'll look at the simpler example -- thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 2 03:59:55 2009 From: trac at galois.com (GHC) Date: Tue Jun 2 03:43:57 2009 Subject: [GHC] #781: GHCi on x86_64, cannot link to static data in shared libs In-Reply-To: <044.a73c522b97030f99c5fa39d521657f06@localhost> References: <044.a73c522b97030f99c5fa39d521657f06@localhost> Message-ID: <053.8cd7d9a6f431e7d680fec1347dd8bfb5@localhost> #781: GHCi on x86_64, cannot link to static data in shared libs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.5 Severity: normal | Resolution: Keywords: getEnvironment | Difficulty: Unknown Testcase: getEnvironment01 | Os: Linux Architecture: x86_64 (amd64) | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * milestone: _|_ => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From marlowsd at gmail.com Tue Jun 2 04:01:10 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Tue Jun 2 03:45:13 2009 Subject: [HOpenGL] renderString not working in ghci In-Reply-To: <200906020039.07410.Sven.Panne@aedion.de> References: <20090520072414.GM12034@katherina.student.utwente.nl> <200906012005.15088.Sven.Panne@aedion.de> <1243889336.29805.81.camel@localhost> <200906020039.07410.Sven.Panne@aedion.de> Message-ID: <4A24DC46.9050803@gmail.com> On 01/06/2009 23:39, Sven Panne wrote: > So my question is again: Why is -fPIC not the default for GHC on x86_64? If we > don't want the overhead, that's OK (any benchmark numbers?), but then GHC's > documentation should really contain a big, fat warning that GHCi's dynamic > linker gets cases like the one above wrong. There is a ticket, BTW: http://hackage.haskell.org/trac/ghc/ticket/781 I've milestoned it for 6.12.1 and made it high priority. I think the only reason that -fPIC is not the default right now on x86_64 is that (a) it's (still) experimental, and (b) we don't know what performance implications it has. Duncan will hopefully be able to resolve both in due course. Duncan: just to clarify, the problem here is that in the x86_64 small memory model (the default), external references from non-PIC code are assigned 32-bit addresses. ld.so makes this work in two ways: * if the symbol points to code, then a jump trampoline is installed in the PLT, and the 32-bit address points to it * if the symbol points to data, then the data object is moved with the dreaded R_COPY relocation, so that it ends up within the low 2Gb and the 32-bit relocation is large enough. the problem is that in GHCi's linker we don't know which symbols point to data and which point to code. So we assume they point to code (data is quite rare), and install trampolines. If we use -fPIC, then external references are made via the PLT or GOT, and the problem doesn't occur. I mentioned this in a comment on #1876: http://hackage.haskell.org/trac/ghc/ticket/1876#comment:11 One thing we could do to help would be to spot foreign import ccall "&foo" foo :: Ptr T where T is not a function type, and emit a warning suggesting the use of -fPIC. Cheers, Simon From trac at galois.com Tue Jun 2 08:47:32 2009 From: trac at galois.com (GHC) Date: Tue Jun 2 08:31:33 2009 Subject: [GHC] #3253: validate failure (GCC warning) In-Reply-To: <050.ebb2294c3e42762e8bd80739a4e081c3@localhost> References: <050.ebb2294c3e42762e8bd80739a4e081c3@localhost> Message-ID: <059.e13993bd2eb0bda87785cddcc45ef605@localhost> #3253: validate failure (GCC warning) ----------------------------------+----------------------------------------- Reporter: isaacdupree | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: libraries/process | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by igloo): * status: reopened => closed * resolution: => fixed Comment: Fixed: {{{ Tue Jun 2 12:34:08 BST 2009 Ian Lynagh * Use -w when compiling libffi, to stop -Werror failures }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 2 09:40:49 2009 From: trac at galois.com (GHC) Date: Tue Jun 2 09:25:01 2009 Subject: [GHC] #3265: Type operators can be defined without the TypeOperators extension flag In-Reply-To: <044.bd55a0547092a6d4c7f6613593a50b08@localhost> References: <044.bd55a0547092a6d4c7f6613593a50b08@localhost> Message-ID: <053.3ff8f56d3a53d3dcde6577a50c9fcb8f@localhost> #3265: Type operators can be defined without the TypeOperators extension flag -----------------------------------------+---------------------------------- Reporter: nibro | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rename/should_fail/T3265 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonpj): * testcase: => rename/should_fail/T3265 * status: new => closed * resolution: => fixed Comment: Quite right thanks. Fixed by {{{ Tue Jun 2 14:37:06 BST 2009 simonpj@microsoft.com * Fix Trac #3265: type operators in type/class declarations We should accept these: data a :*: b = .... or data (:*:) a b = ... only if -XTypeOperators is in force. And similarly class decls. }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 2 10:21:29 2009 From: trac at galois.com (GHC) Date: Tue Jun 2 10:05:31 2009 Subject: [GHC] #3268: implement the Cabal ${pkgroot} spec extension In-Reply-To: <045.8be95892c9d19347370cbf9a54614c20@localhost> References: <045.8be95892c9d19347370cbf9a54614c20@localhost> Message-ID: <054.0df91c26f5d292806a52f9b7393d8595@localhost> #3268: implement the Cabal ${pkgroot} spec extension ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: After discussion with Duncan, we decided to * implement `ghc-pkg pkgroot `, which returns the value of `${pkgroot}` for the given package * for `ghc-pkg dump`, we prefix each batch of packages with the `pkgroot` value (choosing some suitable syntax) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 2 11:28:20 2009 From: trac at galois.com (GHC) Date: Tue Jun 2 11:12:21 2009 Subject: [GHC] #3241: System.Win32.Registry - incorrect length calculation in regSetStringValue In-Reply-To: <046.5e05961aa036dbf948d62b849e5dd19f@localhost> References: <046.5e05961aa036dbf948d62b849e5dd19f@localhost> Message-ID: <055.0318315cf7ffedbe720241ef8731a094@localhost> #3241: System.Win32.Registry - incorrect length calculation in regSetStringValue ----------------------------------+----------------------------------------- Reporter: binarin | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Mon Jun 1 13:52:21 BST 2009 Simon Marlow * Fix #3241: regSetStringValue passed the wrong value for the length Mon Jun 1 13:52:09 BST 2009 Simon Marlow * add a test for #3241 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 2 11:32:04 2009 From: trac at galois.com (GHC) Date: Tue Jun 2 11:16:06 2009 Subject: [GHC] #2650: Child processes always unwantedly inherit Handles on Windows In-Reply-To: <047.1449ef20e3242d7624bded23f58b28e1@localhost> References: <047.1449ef20e3242d7624bded23f58b28e1@localhost> Message-ID: <056.553e9db50f85c83b980de007e06ba5ca@localhost> #2650: Child processes always unwantedly inherit Handles on Windows ----------------------------------+----------------------------------------- Reporter: Deewiant | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: libraries/process | Version: 6.9 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * component: libraries (other) => libraries/process * resolution: => fixed Comment: Fixed: {{{ Tue Jun 2 12:58:07 BST 2009 Simon Marlow * Fix #2650: avoid a race condition on Windows when creating sub- processes }}} I think this part of the bug is much more unlikely to cause problems than #3231, as it should only affect you if you're creating processes from multiple threads, and even then it might not cause a problem, because the only effect is to unnecessarily inherit a pipe Handle or two. There's also a workaround: do your own mutual exclusion. So I'm not suggesting we merge this into 6.10.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 2 11:36:32 2009 From: trac at galois.com (GHC) Date: Tue Jun 2 11:20:33 2009 Subject: [GHC] #3186: findExeutable does not respect order of search path on Windows In-Reply-To: <045.8d432c25f775875a5ebadcd8663d4571@localhost> References: <045.8d432c25f775875a5ebadcd8663d4571@localhost> Message-ID: <054.a4307b903d5dff254ae8446cc7b7065d@localhost> #3186: findExeutable does not respect order of search path on Windows ------------------------------------+--------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/directory | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Fri May 29 13:34:49 BST 2009 Simon Marlow * Fix #3189: add docs to findExecutable }}} d'oh, I got the bug number wrong in the patch. Oh well. The docs for `findExceutable` now say: {{{ -- | Given an executable file name, searches for such file in the -- directories listed in system PATH. The returned value is the path -- to the found executable or Nothing if an executable with the given -- name was not found. For example (findExecutable \"ghc\") gives you -- the path to GHC. -- -- The path returned by 'findExecutable' corresponds to the -- program that would be executed by 'System.Process.createProcess' -- when passed the same string (as a RawCommand, not a ShellCommand). -- -- On Windows, 'findExecutable' calls the Win32 function 'SearchPath', -- which may search other places before checking the directories in -- @PATH@. Where it actually searches depends on registry settings, -- but notably includes the directory containing the current -- executable. See -- for more -- details. -- }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 2 15:13:48 2009 From: trac at galois.com (GHC) Date: Tue Jun 2 14:58:01 2009 Subject: [GHC] #2793: CLDouble is nothing like a long double In-Reply-To: <047.5dadea2fc38a170289501238d399f214@localhost> References: <047.5dadea2fc38a170289501238d399f214@localhost> Message-ID: <056.7ca8d4a749a3534be8da1af7141928f4@localhost> #2793: CLDouble is nothing like a long double ---------------------------------+------------------------------------------ Reporter: jedbrown | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Well, currently it doesn't provide quad precision anyway, so nothing is lost by removing it. However, there are a couple of issues with removing it: * The FFI addendum says that we should provide it * The code is a CPP tangle with the GHC, hugs and nhc implementations of it. I don't know if anything ''really'' implements it. There's also more work involved in implementing it than I'd previously realised. I'll revisit it after removing decodeDoubleInteger. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 2 17:36:34 2009 From: trac at galois.com (GHC) Date: Tue Jun 2 17:20:35 2009 Subject: [GHC] #3271: New methods for Data.Sequence Message-ID: <053.cc9895e43857ea386bfb254a48e9e83f@localhost> #3271: New methods for Data.Sequence -----------------------------+---------------------------------------------- Reporter: LouisWasserman | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- `Data.Sequence` is meant as a general-purpose implementation of finite sequences. The range of methods it offers, however, is considerably more constrained than `Data.List`, even allowing for the constraint that sequences are finite. The following methods cannot be efficiently implemented based on currently exported methods from `Data.Sequence`. * `zipWith` and its variants. Note: it suffices to define `zipWith` alone. * `replicate`. (This can be implemented in `O(log n)` time with node sharing.) The following methods are relatively simple extensions of already-exported methods. It may be more appropriate to allow library users to reimplement them themselves. * `scanl`, `scanr`, and variants. This is relatively straightforward using methods borrowed from the `Traversable` instance. * `tails` and `inits`. `tails` is equivalent to `scanr (<|) empty`; `inits` is similar. * `takeWhile`, `dropWhile`, `span`, `break` (and perhaps from-the-end variations). Finding a breakpoint index can be done as efficiently on lists as on sequences; find the appropriate breakpoint index after converting to a list and use `splitAt`. * `unfoldr` and `iterate`, though the latter would require a finite number of iterations to perform. * `partition`. I can conceive of a slightly more efficient implementation than the trivial one, but the gains may be minimal. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 2 17:48:56 2009 From: trac at galois.com (GHC) Date: Tue Jun 2 17:32:58 2009 Subject: [GHC] #3271: New methods for Data.Sequence In-Reply-To: <053.cc9895e43857ea386bfb254a48e9e83f@localhost> References: <053.cc9895e43857ea386bfb254a48e9e83f@localhost> Message-ID: <062.761c524fb994e0b7c5ae1c7bfaed420a@localhost> #3271: New methods for Data.Sequence -------------------------------+-------------------------------------------- Reporter: LouisWasserman | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by LouisWasserman): Discussion deadline: 2 weeks after ticket submission. (June 16) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 3 00:34:44 2009 From: trac at galois.com (GHC) Date: Wed Jun 3 00:18:48 2009 Subject: [GHC] #3272: GHC panics when contexts are put late in function types Message-ID: <044.48a8ed9c7f42f20ab8f57bc784f391e5@localhost> #3272: GHC panics when contexts are put late in function types -----------------------------+---------------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Here's a simple transcript from ghci: {{{ Prelude> :m + Data.List Prelude Data.List> :t genericLength :: [a] -> Num b => b ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for x86_64-unknown-linux): TcTyFuns.flattenType: unexpected PredType 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 Wed Jun 3 05:20:31 2009 From: trac at galois.com (GHC) Date: Wed Jun 3 05:04:34 2009 Subject: [GHC] #2793: CLDouble is nothing like a long double In-Reply-To: <047.5dadea2fc38a170289501238d399f214@localhost> References: <047.5dadea2fc38a170289501238d399f214@localhost> Message-ID: <056.712c8323bbf43bf9927c084836e1acc7@localhost> #2793: CLDouble is nothing like a long double ---------------------------------+------------------------------------------ Reporter: jedbrown | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Wouldn't we have to implement long double as a new primitive type in GHC, provide support in all the code generators, including support for passing long double to C functions in all the native backends? It's a lot of work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 3 05:38:38 2009 From: trac at galois.com (GHC) Date: Wed Jun 3 05:22:41 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.9e1d4407d87208de4c3b591ec6af234a@localhost> #3272: GHC panics when contexts are put late in function types ----------------------------------------+----------------------------------- Reporter: dmwit | Owner: 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): * difficulty: => Unknown Comment: Fails in HEAD too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 3 07:16:41 2009 From: trac at galois.com (GHC) Date: Wed Jun 3 07:00:41 2009 Subject: [GHC] #3268: implement the Cabal ${pkgroot} spec extension In-Reply-To: <045.8be95892c9d19347370cbf9a54614c20@localhost> References: <045.8be95892c9d19347370cbf9a54614c20@localhost> Message-ID: <054.b06dff740588c3faadcfe4762c97feb7@localhost> #3268: implement the Cabal ${pkgroot} spec extension ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Package system | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [comment:1 simonmar]: > After discussion with Duncan, we decided to > > * implement `ghc-pkg pkgroot `, which returns the value of `${pkgroot}` > for the given package Oh, sorry, I wasn't clear. I don't think this is necessary. But if you want to do it anyway I'm not going to say no. > * for `ghc-pkg dump`, we prefix each batch of packages with the `pkgroot` value > (choosing some suitable syntax) Yes. Some suitable syntax we've not yet chosen :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 4 08:24:49 2009 From: trac at galois.com (GHC) Date: Thu Jun 4 08:08:45 2009 Subject: [GHC] #3273: memory leak due to optimisation Message-ID: <043.8d7f62a0a1af41f2de804ebbbba872f7@localhost> #3273: memory leak due to optimisation -----------------------------+---------------------------------------------- Reporter: sebf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Short summary: The attached programs use lots of space when compiled with -O and run in constant space without -O. condensed.hs runs in constant space with -O too, if you remove any occurrence of 'id'. original.hs uses a lot of space without -O too, if an alternative definition of 'iterDepth' is used (see comment there). I could reproduce this behaviour with ghc-6.8.2 under Linux as well as ghc-6.10.1 and ghc-6.11.20090331 under Mac OS X 10.5.7. Full description: This ticket has an attached tar file with two source files -- original.hs and condensed.hs -- that can be compiled with and without -O to reproduce the bug: {{{ $ ghc -fforce-recomp --make original [1 of 1] Compiling Main ( original.hs, original.o ) Linking original ... $ ./original ^C $ ghc -v -dcore-lint -O -fforce-recomp --make original Glasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC version 6.8.3 Using package config file: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/./package.conf Using package config file: /Users/sebf/.ghc/i386-darwin-6.10.1/package.conf hiding package HTTP-3001.1.3 to avoid conflict with later version HTTP-3001.1.4 hiding package haddock-2.3.0 to avoid conflict with later version haddock-2.4.1 hiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0 hiding package old-time-1.0.0.1 to avoid conflict with later version old- time-1.0.0.2 hiding package filepath-1.1.0.1 to avoid conflict with later version filepath-1.1.0.2 hiding package process-1.0.1.0 to avoid conflict with later version process-1.0.1.1 hiding package Cabal-1.6.0.1 to avoid conflict with later version Cabal-1.6.0.2 hiding package regex-base-0.72.0.2 to avoid conflict with later version regex-base-0.93.1 hiding package regex-posix-0.72.0.3 to avoid conflict with later version regex-posix-0.93.2 hiding package regex-compat-0.71.0.1 to avoid conflict with later version regex-compat-0.92 hiding package network-2.2.0.1 to avoid conflict with later version network-2.2.1.2 hiding package QuickCheck-1.2.0.0 to avoid conflict with later version QuickCheck-2.1.0.1 hiding package time-1.1.2.2 to avoid conflict with later version time-1.1.2.3 hiding package zlib-0.4.0.4 to avoid conflict with later version zlib-0.5.0.0 hiding package HTTP-3001.1.4 to avoid conflict with later version HTTP-3001.1.5 hiding package regex-posix-0.93.2 to avoid conflict with later version regex-posix-0.94.1 hiding package utf8-string-0.3.3 to avoid conflict with later version utf8-string-0.3.4 hiding package binary-0.4.3.1 to avoid conflict with later version binary-0.4.4 hiding package zip-archive-0.1.1.1 to avoid conflict with later version zip-archive-0.1.1.3 hiding package binary-0.4.4 to avoid conflict with later version binary-0.5 hiding package haddock-2.4.1 to avoid conflict with later version haddock-2.4.2 hiding package HTTP-3001.1.5 to avoid conflict with later version HTTP-4000.0.0 hiding package hscolour-1.10.1 to avoid conflict with later version hscolour-1.11 hiding package HTTP-4000.0.0 to avoid conflict with later version HTTP-4000.0.1 hiding package haskell-src-exts-0.4.6 to avoid conflict with later version haskell-src-exts-0.4.8 hiding package HTTP-4000.0.1 to avoid conflict with later version HTTP-4000.0.4 hiding package digest-0.0.0.1 to avoid conflict with later version digest-0.0.0.2 hiding package level-monad-0.2.1 to avoid conflict with later version level-monad-0.3 hiding package HTTP-4000.0.4 to avoid conflict with later version HTTP-4000.0.7 hiding package digest-0.0.0.2 to avoid conflict with later version digest-0.0.0.4 hiding package terminfo-0.2.2.1 to avoid conflict with later version terminfo-0.3.0.2 hiding package stream-monad-0.1 to avoid conflict with later version stream-monad-0.1.1.0 hiding package tree-monad-0.1 to avoid conflict with later version tree- monad-0.1.1 hiding package parallel-tree-search-0.2.1 to avoid conflict with later version parallel-tree-search-0.4 hiding package explicit-sharing-0.2 to avoid conflict with later version explicit-sharing-0.3.1.1 hiding package tree-monad-0.1.1 to avoid conflict with later version tree- monad-0.2 hiding package tree-monad-0.2 to avoid conflict with later version tree- monad-0.2.1 hiding package parallel-tree-search-0.4 to avoid conflict with later version parallel-tree-search-0.4.1 hiding package level-monad-0.3 to avoid conflict with later version level- monad-0.3.1 hiding package explicit-sharing-0.3.1.1 to avoid conflict with later version explicit-sharing-0.3.1.2 hiding package explicit-sharing-0.3.1.2 to avoid conflict with later version explicit-sharing-0.3.1.3 hiding package explicit-sharing-0.3.1.3 to avoid conflict with later version explicit-sharing-0.4.0 hiding package explicit-sharing-0.4.0 to avoid conflict with later version explicit-sharing-0.5.0 wired-in package ghc-prim mapped to ghc-prim-0.1.0.0 wired-in package integer mapped to integer-0.1.0.0 wired-in package base mapped to base-4.0.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.0 wired-in package template-haskell mapped to template-haskell-2.3.0.0 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: *original.hs Stable obj: [Main] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = Thu Jun 4 13:23:20 CEST 2009 ms_mod = main:Main, ms_imps = [Control.Monad.Cont] ms_srcimps = [] }] compile: input file original.hs Created temporary directory: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0 *** Checking old interface for main:Main: [1 of 1] Compiling Main ( original.hs, original.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 753 *** Core Linted result of Desugar: *** Simplify: Result size = 290 *** Core Linted result of Simplifier phase gentle, iteration 1 out of 4: Result size = 280 *** Core Linted result of Simplifier phase gentle, iteration 2 out of 4: Result size = 280 *** Core Linted result of Simplify phase gentle done: *** Specialise: Result size = 331 *** Core Linted result of Specialise: *** Float out (not lambdas, not constants): Result size = 351 *** Core Linted result of Float out (not lambdas, not constants): *** Float inwards: Result size = 351 *** Core Linted result of Float inwards: *** Simplify: Result size = 587 *** Core Linted result of Simplifier phase 2 [main], iteration 1 out of 4: Result size = 390 *** Core Linted result of Simplifier phase 2 [main], iteration 2 out of 4: Result size = 304 *** Core Linted result of Simplify phase 2 [main] done: *** Simplify: Result size = 287 *** Core Linted result of Simplifier phase 1 [main], iteration 1 out of 4: Result size = 287 *** Core Linted result of Simplify phase 1 [main] done: *** Simplify: Result size = 330 *** Core Linted result of Simplifier phase 0 [main], iteration 1 out of 4: Result size = 310 *** Core Linted result of Simplifier phase 0 [main], iteration 2 out of 4: Result size = 304 *** Core Linted result of Simplifier phase 0 [main], iteration 3 out of 4: Result size = 304 *** Core Linted result of Simplify phase 0 [main] done: *** Demand analysis: Result size = 304 *** Core Linted result of Demand analysis: *** Worker Wrapper binds: Result size = 330 *** Core Linted result of Worker Wrapper binds: *** GlomBinds: *** Simplify: Result size = 345 *** Core Linted result of Simplifier phase 0 [post-worker-wrapper], iteration 1 out of 4: Result size = 345 *** Core Linted result of Simplify phase 0 [post-worker-wrapper] done: *** Float out (not lambdas, constants): Result size = 353 *** Core Linted result of Float out (not lambdas, constants): *** Common sub-expression: Result size = 352 *** Core Linted result of Common sub-expression: *** Float inwards: Result size = 352 *** Core Linted result of Float inwards: *** Simplify: Result size = 353 *** Core Linted result of Simplifier phase 0 [final], iteration 1 out of 4: Result size = 353 *** Core Linted result of Simplify phase 0 [final] done: *** Tidy Core: Result size = 353 *** Core Linted result of Tidy Core: writeBinIface: 49 Names writeBinIface: 98 dict entries *** CorePrep: Result size = 430 *** Core Linted result of CorePrep: *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler: gcc -I. -c /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0/ghc13029_0.s -o original.o *** Deleting temp files: Deleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0/ghc13029_0.s Upsweep completely successful. *** Deleting temp files: Deleting: link: linkables are ... LinkableM (Thu Jun 4 13:55:23 CEST 2009) main:Main [DotO original.o] Linking original ... *** Linker: gcc -v -o original -DDONT_WANT_WIN32_DLL_SUPPORT original.o -L/Library/Frameworks/GHC.framework /Versions/610/usr/lib/ghc-6.10.1/mtl-1.1.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr /lib/ghc-6.10.1/base-4.0.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/ integer-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/ghc- prim-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1 -lHSmtl-1.1.0.2 -lHSbase-4.0.0.0 -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm -lffi -lgmp -ldl -u _ghczmprim_GHCziTypes_Izh_static_info -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure -u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure -u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure -u _base_GHCziConc_ensureIOManagerIsRunning_closure -Wl,-search_paths_first Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program- transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5488) /usr/libexec/gcc/i686-apple-darwin9/4.0.1/collect2 -dynamic -arch i386 -macosx_version_min 10.5.7 -weak_reference_mismatches non-weak -u _ghczmprim_GHCziTypes_Izh_static_info -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure -u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure -u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure -u _base_GHCziConc_ensureIOManagerIsRunning_closure -o original -lcrt1.10.5.o -L/Library/Frameworks/GHC.framework/ Versions/610/usr/lib/ghc-6.10.1/mtl-1.1.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/base-4.0.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/integer-0.1.0.0 -L/Library/Frameworks/GHC.framework /Versions/610/usr/lib/ghc-6.10.1/ghc-prim-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1 -L/usr/lib/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple- darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 /../../.. original.o -lHSmtl-1.1.0.2 -lHSbase-4.0.0.0 -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm -lffi -lgmp -ldl -search_paths_first -lgcc_s.10.5 -lgcc -lSystem link: done *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0 $ ./original ^C $ ghc -fforce-recomp --make condensed [1 of 1] Compiling Main ( condensed.hs, condensed.o ) Linking condensed ... $ ./condensed ^C 13:50 memleak$ ghc -O -fforce-recomp --make condensed [1 of 1] Compiling Main ( condensed.hs, condensed.o ) Linking condensed ... $ ./condensed ^C }}} I have checked with ghc-6.8.2 on "Linux 2.6.27-11-generic 1 SMP Wed Apr 1 20:53:41 UTC 2009 x86_64 GNU/Linux" and with ghc-6.10.1 and 6.11.200903331 on "Darwin 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386" Here are some more runs with -fno-full-laziness and/or -fno-cse. Neither switch affects the memory requirements with -O: {{{ $ ghc -fno-full-laziness -O -fforce-recomp --make condensed [1 of 1] Compiling Main ( condensed.hs, condensed.o ) Linking condensed ... $ ./condensed ^C $ ghc -fno-cse -O -fforce-recomp --make condensed [1 of 1] Compiling Main ( condensed.hs, condensed.o ) Linking condensed ... $ ./condensed ^C $ ghc -fno-full-laziness -fno-cse -O -fforce-recomp --make condensed [1 of 1] Compiling Main ( condensed.hs, condensed.o ) Linking condensed ... $ ./condensed ^C }}} The program original.hs contains an alternative implementation of 'iterDepth' that seems to hint at the problem. I think, the argument of 'runDepthBound' is held in memory for a good reason there. The program condensed.hs contains four superflous occurrences of 'id' that seem to play together to cause the memory leak. If all of them are present then the program uses lots of space with -O, if either one is missing it runs in constant space. The program always runs in constant space without -O. I think, the space leak is caused by holding the arguments of 'id' in memory. If that is true, however, I don't see why *all* occurrences of 'id' are necessary to cause the leak. I think the original program and all versions of the condensed program should run in constant space with and without -O. It would be nice if the alternative version of the original program would run in constant space too but I see that there is sharing that may prevent this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 4 09:00:32 2009 From: trac at galois.com (GHC) Date: Thu Jun 4 08:44:26 2009 Subject: [GHC] #3273: memory leak due to optimisation In-Reply-To: <043.8d7f62a0a1af41f2de804ebbbba872f7@localhost> References: <043.8d7f62a0a1af41f2de804ebbbba872f7@localhost> Message-ID: <052.0209be9fd29a5f9e1d12ac55fc96c4fd@localhost> #3273: memory leak due to optimisation ------------------------------+--------------------------------------------- Reporter: sebf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by int-e): {{{-fno-full-laziness}}} helps actually, but the option must come ''after'' the {{{-O}}} option: {{{ # ghc_version 6.8.3 # ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.3 # ghc -fforce-recomp condensed.hs -o condensed && /usr/bin/time ./condensed +RTS -M20M 49995000 51.25user 0.18system 0:51.68elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+775minor)pagefaults 0swaps # ghc -O -fforce-recomp condensed.hs -o condensed && /usr/bin/time ./condensed +RTS -M20M Heap exhausted; Current maximum heap size is 19996672 bytes (19 Mb); use `+RTS -M' to increase it. Command exited with non-zero status 251 1.88user 0.01system 0:01.92elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5423minor)pagefaults 0swaps # ghc -fno-cse -O -fforce-recomp condensed.hs -o condensed && /usr/bin/time ./condensed +RTS -M20M Heap exhausted; Current maximum heap size is 19996672 bytes (19 Mb); use `+RTS -M' to increase it. Command exited with non-zero status 251 1.89user 0.00system 0:01.91elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+5423minor)pagefaults 0swaps # ghc -O -fno-full-laziness -fforce-recomp condensed.hs -o condensed && /usr/bin/time ./condensed +RTS -M20M 49995000 34.84user 0.14system 0:38.53elapsed 90%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+772minor)pagefaults 0swaps # uname -a Linux zombie 2.6.28.9 #1 PREEMPT Thu Apr 30 14:58:05 CEST 2009 i686 AMD Athlon(TM) XP 2500+ AuthenticAMD GNU/Linux }}} {{{ghc-6.10.3}}} and HEAD of a week ago exhibit similar behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 4 09:02:13 2009 From: trac at galois.com (GHC) Date: Thu Jun 4 08:46:07 2009 Subject: [GHC] #3273: memory leak due to optimisation In-Reply-To: <043.8d7f62a0a1af41f2de804ebbbba872f7@localhost> References: <043.8d7f62a0a1af41f2de804ebbbba872f7@localhost> Message-ID: <052.700a6acdb58e3d625728ff1c4d3cee56@localhost> #3273: memory leak due to optimisation ------------------------------+--------------------------------------------- Reporter: sebf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by int-e): {{{# ghc -fno-cse -O}}} should have been {{{# ghc -O -fno-cse}}} of course. But it makes no difference to the result -- {{{-fno-cse}}} does not help here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 4 09:22:35 2009 From: trac at galois.com (GHC) Date: Thu Jun 4 09:06:30 2009 Subject: [GHC] #3274: Add System.FilePath.Cygwin Message-ID: <051.26cec4bbfc888314c03b702b9312954c@localhost> #3274: Add System.FilePath.Cygwin -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I propose we add the module {{{System.FilePath.Cygwin}}} to the filepath library. This module would be based on {{{System.FilePath.Windows}}} but with {{{'/'}}} as the preferred path separator, rather than {{{'\\'}}} as for Windows. This module would never be available as {{{System.FilePath}}}, and would always have to be imported specifically if wanted. The desire for this module comes from working with the Cygwin shell, which supports Windows syntax but requires the alternative separator. I have been using such a module for a few months, and find it very useful. There are no backward compatibility concerns, as it is a new separate module. Discussion deadline: 18th June 2009. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 4 13:50:49 2009 From: trac at galois.com (GHC) Date: Thu Jun 4 13:35:37 2009 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.7e8cbafc440cb3e597cdcb75363dc10d@localhost> #1876: Complete shared library support ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: duncan Type: task | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by Pete): * cc: 1@234.cx (added) Comment: "Although we could use LD_LIBRARY_PATH to include the appropriate directory, that feels like a dirty hack: the standard Linux practice seems to be to put any shared libraries the linker needs to find where it will find them by default." Most packages I've seen install shared libraries in $PREFIX/lib. If you accept the default $PREFIX, this means they will go in /usr/local/lib, and the linker is normally set so it will find them there. If a package (deb, rpm or whatever) is being built, then $PREFIX will usually be set to /usr. In this case, the libraries will go in /usr/lib and again the linker will find them. If you decide to install the package in a private directory, the linker won't find the libraries. In this case you can set the executable's rpath to the directory where the libraries are to be found. The downside is that this makes the executables non-portable. If Fred installs the libraries in ~fred/lib and Jim installs them in ~jim/lib, they won't be able to run each other's executables. The rpath will be set correctly for the person who compiled the executable, but no one else. At this point you have to set LD_LIBRARY_PATH and work round it that way. The Debian package of ALSA takes a different approach. It installs its libraries in /usr/lib/alsa-lib/ and installs /etc/ld.so.conf.d/libasound2.conf which points to them. (This file contains a single line, '/usr/lib/alsa-lib'.) This approach makes sense, I imagine, if you are installing a lot of libraries and don't want to clutter up /usr/lib. I was just doing some experiments to make sure I'd got this right. I created foo.c: #include void blah() { printf("Hello World!\n"); } and bar.c: extern void blah(); main() { blah(); } First of all I build foo.c into a shared library: $ gcc -fPIC -shared foo.c -o libfoo.so I can then link bar.c in two ways. Here is the first option: $ gcc bar.c -o bar -L. -lfoo $ ./bar ./bar: error while loading shared libraries: libfoo.so: cannot open shared object file: No such file or directory $ LD_LIBRARY_PATH=. ./bar Hello World! Second option: $ gcc bar.c -o bar -Wl,--rpath=/home/pc -L. -lfoo $ ./bar Hello World! I hope this is helpful. I'm not a functional programming expert, so I can't implement this myself. On the other hand, I'm happy to help with any of these operating system issues. My email is 1@234.cx if you want anything from me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 4 17:21:46 2009 From: trac at galois.com (GHC) Date: Thu Jun 4 17:05:39 2009 Subject: [GHC] #3275: ghc: panic! (the 'impossible' happened) Message-ID: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> #3275: ghc: panic! (the 'impossible' happened) --------------------+------------------------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- I downloaded the beta of the Haskell Platform installer from http://hackage.haskell.org/platform/2009.2.0.1/haskell- platform-2009.2.0.1-beta1-i386.dmg and when I tried to cabal install the HEAD version of darcs, I got this error message: [ 57 of 134] 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 a2ZC6} [lid], ww1{v a2ZC7} [lid], ww2{v a2ZC8} [lid]] [!, !, _, _] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Darcs repo version (last patch; see attached for context file): Mon Jun 1 10:19:28 BST 2009 Petr Rockai * Remove tentativelyMerge from Gorsvet, as it's unused and confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 4 17:26:24 2009 From: trac at galois.com (GHC) Date: Thu Jun 4 17:10:17 2009 Subject: [GHC] #3275: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> References: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> Message-ID: <055.f5ffb4f6c8ed74feb8949edbc3bbfabc@localhost> #3275: ghc: panic! (the 'impossible' happened) ----------------------+----------------------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by EricKow): In the event that this is at all relevant, I was simultaneously trying to compile HaXml 1.13 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 4 17:28:48 2009 From: trac at galois.com (GHC) Date: Thu Jun 4 17:12:41 2009 Subject: [GHC] #3275: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> References: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> Message-ID: <055.2b9b4678b49a6a91aa304db8f0365f6f@localhost> #3275: ghc: panic! (the 'impossible' happened) ----------------------+----------------------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by EricKow): Also, I'm pleased to report that this error does not go away if I type "cabal install" a second (or Nth time). So I'll be glad to do any debugging steps you request. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 4 22:24:29 2009 From: trac at galois.com (GHC) Date: Thu Jun 4 22:08:23 2009 Subject: [GHC] #3276: FilePath.addTrailingPathSeparator "" = "/" Message-ID: <045.c94373ccfee4669a603a10ee0b36cb4d@localhost> #3276: FilePath.addTrailingPathSeparator "" = "/" -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Since we often consider the filepath `""` to be synonymous with `"."`, then `addTrailingPathSeparator ""` should be "./" not "/". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 5 03:44:14 2009 From: trac at galois.com (GHC) Date: Fri Jun 5 03:28:07 2009 Subject: [GHC] #3273: memory leak due to optimisation In-Reply-To: <043.8d7f62a0a1af41f2de804ebbbba872f7@localhost> References: <043.8d7f62a0a1af41f2de804ebbbba872f7@localhost> Message-ID: <052.ef746eea00d22117083d4135f1a19d13@localhost> #3273: memory leak due to optimisation -----------------------------------------+---------------------------------- Reporter: sebf | Owner: Type: run-time performance bug | 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 simonmar): * difficulty: => Unknown * type: bug => run-time performance bug * milestone: => 6.12 branch Comment: We already have a ticket for the full-laziness issue: #917. Do you think there's anything else going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 5 04:30:02 2009 From: trac at galois.com (GHC) Date: Fri Jun 5 04:14:03 2009 Subject: [GHC] #3273: memory leak due to optimisation In-Reply-To: <043.8d7f62a0a1af41f2de804ebbbba872f7@localhost> References: <043.8d7f62a0a1af41f2de804ebbbba872f7@localhost> Message-ID: <052.26805ab2d9c29beed6a44b1bacde8ba6@localhost> #3273: memory leak due to optimisation -----------------------------------------+---------------------------------- Reporter: sebf | Owner: Type: run-time performance bug | 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 sebf): Replying to [comment:3 simonmar]: After examining a core dump I am now pretty sure that the leak is caused by the full-laziness optimization and the original program could benefit from a mechanism to selectively disable it like mentioned by simonpj in that other ticket. The behaviour of the condensed program is still a bit weird because it is unclear (to me at least) why removing an 'id' call affects the full laziness optimization in this example. However, section 4.9.2 of the GHC user guide says explicitly that "GHC doesn't consistently apply full- laziness" so it may be fine to apply it if all 'id's are there and not if one is missing. If so, then there is nothing to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 5 06:34:57 2009 From: trac at galois.com (GHC) Date: Fri Jun 5 06:18:49 2009 Subject: [GHC] #3277: ghc-6.8.2: panic! (the 'impossible' happened) RnEnv.lookupImportedName Message-ID: <047.0eb0687378e057ea5b71774bbee9b502@localhost> #3277: ghc-6.8.2: panic! (the 'impossible' happened) RnEnv.lookupImportedName ---------------------+------------------------------------------------------ Reporter: newhoggy | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 ---------------------+------------------------------------------------------ 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 Fri Jun 5 07:02:32 2009 From: trac at galois.com (GHC) Date: Fri Jun 5 06:46:23 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.a51f429ba10849408b3e46ecf52fd8dc@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 | -------------------------+-------------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Can you try with GHC 6.10.3? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 5 08:26:59 2009 From: trac at galois.com (GHC) Date: Fri Jun 5 08:10:50 2009 Subject: [GHC] #3278: Make lazy unlifted bindings an error Message-ID: <044.11b4f7b53bb5a6813f99f6121e427808@localhost> #3278: Make lazy unlifted bindings an error --------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler (Type checker) | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------------+------------------------------------- Remove `Opt_WarnLazyUnliftedBindings`, and turn the `warnTc` into an `checkTc`. Remove `-Werror` from test T2806. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 5 10:16:03 2009 From: trac at galois.com (GHC) Date: Fri Jun 5 10:00:02 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.91b56c179f44740727a378cbba062c74@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 | Testcase: Os: Windows | Architecture: x86 --------------------------+------------------------------------------------- Comment (by EricKow): Perhaps you meant to submit this to the [http://sourceforge.net/tracker/?group_id=73133 wxHaskell bugtracker]? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 5 11:57:10 2009 From: trac at galois.com (GHC) Date: Fri Jun 5 11:41:02 2009 Subject: [GHC] #2806: Require bang-patterns for unlifted bindings In-Reply-To: <046.9d55d0c05fffd15719c6c19b63c006aa@localhost> References: <046.9d55d0c05fffd15719c6c19b63c006aa@localhost> Message-ID: <055.b2c02f7ae2ae3cd84ad02f5e84da45a7@localhost> #2806: Require bang-patterns for unlifted bindings ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: igloo Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2806 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * testcase: => T2806 * status: new => closed * resolution: => fixed Comment: Now completed, documented, and a test added. I've also opened #3278 to remind us to make it an error, rather than a warning, in GHC 6.14. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 5 12:06:42 2009 From: trac at galois.com (GHC) Date: Fri Jun 5 11:50:33 2009 Subject: [GHC] #3279: Segmentation fault in reactive program Message-ID: <045.28ccfad62541fcb8fe7651779666954e@localhost> #3279: Segmentation fault in reactive program -----------------------------+---------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86_64 (amd64) -----------------------------+---------------------------------------------- Trying to debug reactive, I triggered what appears to be a GHC bug. To clarify: - Replacing "foo `unamb` bar `unamb` baz" with foldl1 unamb [foo,bar,baz] in one particular function causes a segmentation fault at runtime, in all possible permutations of -threaded/nonthreaded and GHC 6.10.3/6.11. Further, a number of different changes do the same, quite unpredictably. The hackage version of reactive does not exhibit this bug. I've attached a quite minimal patch to it that causes this, as well as a test program to trigger it. I've been trying to debug this myself, with very little success. No level of core-lint or debug checks causes this code to trigger assertions instead of outright segfaults. Incidentally, lazysmallcheck-0.3, a dependency of reactive, does not compile against 6.11 due to a name change in the Data.Generics interface. I've uploaded a fixed version to http://brage.info/~svein/lsc.tar.gz. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 5 13:02:53 2009 From: trac at galois.com (GHC) Date: Fri Jun 5 12:46:52 2009 Subject: [GHC] #3279: Segmentation fault in reactive program In-Reply-To: <045.28ccfad62541fcb8fe7651779666954e@localhost> References: <045.28ccfad62541fcb8fe7651779666954e@localhost> Message-ID: <054.b7b6ea7867a5e69232267307da5c1af5@localhost> #3279: Segmentation fault in reactive program ------------------------------+--------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86_64 (amd64) ------------------------------+--------------------------------------------- Comment (by Baughn): Editing crash.hs to cut down on the number of imports, funnily enough, caused the program to progress further before crashing. It still crashes, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 5 13:33:52 2009 From: trac at galois.com (GHC) Date: Fri Jun 5 13:17:47 2009 Subject: [GHC] #3119: Make ghc-6.10 use a non-executable stack (by bumping libffi) In-Reply-To: <047.52c2d20209bcb3a33fa5cded0d11d880@localhost> References: <047.52c2d20209bcb3a33fa5cded0d11d880@localhost> Message-ID: <056.e737eaba0c6bf35d088ecf6751780a71@localhost> #3119: Make ghc-6.10 use a non-executable stack (by bumping libffi) ---------------------------------+------------------------------------------ Reporter: kolmodin | Owner: igloo Type: task | Status: closed Priority: high | 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: The HEAD now has 3.0.8 too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 5 13:54:14 2009 From: trac at galois.com (GHC) Date: Fri Jun 5 13:38:06 2009 Subject: [GHC] #3279: Segmentation fault in reactive program In-Reply-To: <045.28ccfad62541fcb8fe7651779666954e@localhost> References: <045.28ccfad62541fcb8fe7651779666954e@localhost> Message-ID: <054.8392cfb7b703f9b1376f7dc6214fd210@localhost> #3279: Segmentation fault in reactive program ------------------------------+--------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86_64 (amd64) ------------------------------+--------------------------------------------- Comment (by int-e): Apparently {{{stg_sel_ret_0_upd_info}}} is called with an {{{stg_dummy_ret_closure}}} argument. Where does it come from? {{{RaiseAsync.c}}}? {{{ > ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.3 > gdb ./crash -ex 'break stg_sel_ret_0_upd_info' -ex 'run' -ex 'c 477' -ex 'i r' GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Breakpoint 1 at 0x8142e8c Starting program: /var/home/bf3/t/reactive/crash [Thread debugging using libthread_db enabled] [New Thread 0xb7ecb6c0 (LWP 10828)] [Switching to Thread 0xb7ecb6c0 (LWP 10828)] Breakpoint 1, 0x08142e8c in stg_sel_ret_0_upd_info () Current language: auto; currently asm Will ignore next 476 crossings of breakpoint 1. Continuing. "never-never" Breakpoint 1, 0x08142e8c in stg_sel_ret_0_upd_info () eax 0xb7dcb4c8 -1210272568 ecx 0xb7d00000 -1211105280 edx 0xb7d01960 -1211098784 ebx 0x81819c8 135797192 esp 0xbffbe8ac 0xbffbe8ac ebp 0xb7cf2fa4 0xb7cf2fa4 esi 0x817edc8 135785928 edi 0xb7dcc314 -1210268908 eip 0x8142e8c 0x8142e8c eflags 0x246 [ PF ZF IF ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) x $esi & -4 0x817edc8 : 0x08142d4c (gdb) ni 8 Program received signal SIGSEGV, Segmentation fault. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 5 22:12:31 2009 From: trac at galois.com (GHC) Date: Fri Jun 5 21:56:28 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.584c612105c3c2b144b559377d47f03e@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 | -------------------------+-------------------------------------------------- Comment (by newhoggy): I just installed 6.10.3 on Mac OS X, and it works fine giving the following errors: $ ./quick.lhs XStream/Test/Library/QuickOrder.hs:19:25: Ambiguous occurrence `secCode' It could refer to either `XStream.Test.Library.QuickOrder.secCode', defined at XStream/Test/Library/QuickOrder.hs:8:5 or `AMP.secCode', imported from XStream.Amp at XStream/Test/Library/QuickOrder.hs:5:0-24 (defined at XStream/Amp.hs:30:5) XStream/Test/Library/QuickOrder.hs:20:25: Ambiguous occurrence `boardId' It could refer to either `XStream.Test.Library.QuickOrder.boardId', defined at XStream/Test/Library/QuickOrder.hs:9:5 or `AMP.boardId', imported from XStream.Amp at XStream/Test/Library/QuickOrder.hs:5:0-24 (defined at XStream/Amp.hs:31:5) XStream/Test/Library/QuickOrder.hs:22:22: Ambiguous occurrence `buySell' It could refer to either `XStream.Test.Library.QuickOrder.buySell', defined at XStream/Test/Library/QuickOrder.hs:10:5 or `AMP.buySell', imported from XStream.Amp at XStream/Test/Library/QuickOrder.hs:5:0-24 (defined at XStream/Amp.hs:52:5) XStream/Test/Library/QuickOrder.hs:23:20: Ambiguous occurrence `type_' It could refer to either `XStream.Test.Library.QuickOrder.type_', defined at XStream/Test/Library/QuickOrder.hs:11:5 or `AMP.type_', imported from XStream.Amp at XStream/Test/Library/QuickOrder.hs:5:0-24 (defined at XStream/Amp.hs:51:5) XStream/Test/Library/QuickOrder.hs:26:20: Ambiguous occurrence `price' It could refer to either `XStream.Test.Library.QuickOrder.price', defined at XStream/Test/Library/QuickOrder.hs:12:5 or `AMP.price', imported from XStream.Amp at XStream/Test/Library/QuickOrder.hs:5:0-24 (defined at XStream/Amp.hs:74:5) XStream/Test/Library/QuickOrder.hs:27:23: Ambiguous occurrence `quantity' It could refer to either `XStream.Test.Library.QuickOrder.quantity', defined at XStream/Test/Library/QuickOrder.hs:13:5 or `AMP.quantity', imported from XStream.Amp at XStream/Test/Library/QuickOrder.hs:5:0-24 (defined at XStream/Amp.hs:76:5) Do fixes get backported to earlier versions? Thanks, -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 5 23:16:35 2009 From: trac at galois.com (GHC) Date: Fri Jun 5 23:00:25 2009 Subject: [GHC] #3273: memory leak due to optimisation In-Reply-To: <043.8d7f62a0a1af41f2de804ebbbba872f7@localhost> References: <043.8d7f62a0a1af41f2de804ebbbba872f7@localhost> Message-ID: <052.8fce3d2ed4249d3bfe9e4af8a4572b04@localhost> #3273: memory leak due to optimisation -----------------------------------------+---------------------------------- Reporter: sebf | Owner: Type: run-time performance bug | 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 int-e): It's a rather more interesting case than #917 - only the first 10k elements of the list {{{[1..]}}} are evaluated, which don't account for the huge memory blowup that we observed. I've looked at the core for {{{condensed.hs}}}. Basically what happens is that {{{plus}}} gets turned into {{{ plus a b = S (\c -> let unSac = unS a c unSbc = unS b c in \d -> if d==0 then [] else unSac (d-1) ++ unSbc (d-1)) }}} and {{{runS}}} gets turned into {{{ runS a = let runa = run a in concatMap runa [10000] }}} With these two changes the program blows up even without optimizations. It's still quite amazing to me, but apparently there is just enough explicit sharing to hold onto the complete {{{natSum}}} computation in some form. I'm curious how the ''id'' functions affect this - maybe they influence arity analysis and that in turn has an effect on the candidates for floating out? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 6 01:19:29 2009 From: trac at galois.com (GHC) Date: Sat Jun 6 01:03:21 2009 Subject: [GHC] #3280: The order of arguments to the function passed to nubBy got swapped somehow Message-ID: <044.3c8fa074464e1da7a1a920048af3ac0f@localhost> #3280: The order of arguments to the function passed to nubBy got swapped somehow -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- According to the Report: {{{ nubBy :: (a -> a -> Bool) -> [a] -> [a] nubBy eq [] = [] nubBy eq (x:xs) = x : nubBy eq (filter (\y -> not (eq x y)) xs) }}} Hence, we should have that {{{ nubBy (<) (1:2:[]) = 1 : nubBy (<) (filter (\y -> not (1 < y)) (2:[])) = 1 : nubBy (<) [] = 1 : [] }}} However in ghc-6.10.3: {{{ Prelude Data.List> nubBy (<) [1,2] [1,2] }}} The order of the parameters to the function which is passed to nubBy is *important* since the function might not be an equivalence relation. nubBy is more generally useful for sieving even when the relation is not symmetric. groupBy, for a similar reason, has applications for grouping beyond those provided by equivalence relations, and I think we should be able to rely on its behaviour. Moreover, I contend that the Report's order is more sensible, since the parameters to the relation stay in the left-to-right order in which they occurred in the list. - Cale -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 6 01:20:21 2009 From: trac at galois.com (GHC) Date: Sat Jun 6 01:04:11 2009 Subject: [GHC] #3281: The order of arguments to the function passed to nubBy got swapped somehow Message-ID: <044.53559b01fc05c43804a4e2deab6825fc@localhost> #3281: The order of arguments to the function passed to nubBy got swapped somehow -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- According to the Report: {{{ nubBy :: (a -> a -> Bool) -> [a] -> [a] nubBy eq [] = [] nubBy eq (x:xs) = x : nubBy eq (filter (\y -> not (eq x y)) xs) }}} Hence, we should have that {{{ nubBy (<) (1:2:[]) = 1 : nubBy (<) (filter (\y -> not (1 < y)) (2:[])) = 1 : nubBy (<) [] = 1 : [] }}} However in ghc-6.10.3: {{{ Prelude Data.List> nubBy (<) [1,2] [1,2] }}} The order of the parameters to the function which is passed to nubBy is *important* since the function might not be an equivalence relation. nubBy is more generally useful for sieving even when the relation is not symmetric. groupBy, for a similar reason, has applications for grouping beyond those provided by equivalence relations, and I think we should be able to rely on its behaviour. Moreover, I contend that the Report's order is more sensible, since the parameters to the relation stay in the left-to-right order in which they occurred in the list. - Cale -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 6 01:26:20 2009 From: trac at galois.com (GHC) Date: Sat Jun 6 01:10:10 2009 Subject: [GHC] #3281: The order of arguments to the function passed to nubBy got swapped somehow In-Reply-To: <044.53559b01fc05c43804a4e2deab6825fc@localhost> References: <044.53559b01fc05c43804a4e2deab6825fc@localhost> Message-ID: <053.71c8b39705d55957b78f3b469c7e0d68@localhost> #3281: The order of arguments to the function passed to nubBy got swapped somehow ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: duplicate Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by guest): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 6 22:04:19 2009 From: trac at galois.com (GHC) Date: Sat Jun 6 21:48:07 2009 Subject: [GHC] #3279: Segmentation fault in reactive program In-Reply-To: <045.28ccfad62541fcb8fe7651779666954e@localhost> References: <045.28ccfad62541fcb8fe7651779666954e@localhost> Message-ID: <054.faaa9e67e9147f9fa5dee394a0456bfc@localhost> #3279: Segmentation fault in reactive program ------------------------------+--------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86_64 (amd64) ------------------------------+--------------------------------------------- Comment (by Baughn): Probably something to do with that, yes. I've traced the problem to the exception-handling code in Unamb.hs; if I comment out the killThreads in race everything works fine (if inefficiently), as no exceptions are ever thrown. Meanwhile, if I replace the call to restartingUnsafePerformIO with just unsafePerformIO, the program fails to crash, but also fails to work. restartingUnsafePerformIO is a very dodgy piece of code. I'd focus any efforts on that. Meanwhile, I still haven't managed to produce a simple test-case, even though I now know it's unamb. (Well, I suspected that all along, of course..) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 7 10:08:37 2009 From: trac at galois.com (GHC) Date: Sun Jun 7 09:52:24 2009 Subject: [GHC] #3279: Segmentation fault in reactive program In-Reply-To: <045.28ccfad62541fcb8fe7651779666954e@localhost> References: <045.28ccfad62541fcb8fe7651779666954e@localhost> Message-ID: <054.2c5c4ae619cd7a1cbc2a498e3f5065ce@localhost> #3279: Segmentation fault in reactive program ------------------------------+--------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86_64 (amd64) ------------------------------+--------------------------------------------- Comment (by Baughn): Going by int-e's research, this bug may be 64-bit only; it fails to trigger on his 32-bit system using 6.11 (and possibly 6.10? I didn't ask.) The attached patch turns it into an assertion failure, when compiled with -debug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 7 12:09:43 2009 From: trac at galois.com (GHC) Date: Sun Jun 7 11:53:39 2009 Subject: [GHC] #3279: Segmentation fault in reactive program In-Reply-To: <045.28ccfad62541fcb8fe7651779666954e@localhost> References: <045.28ccfad62541fcb8fe7651779666954e@localhost> Message-ID: <054.519fc68bd16584749589af063074cfaf@localhost> #3279: Segmentation fault in reactive program ------------------------------+--------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86_64 (amd64) ------------------------------+--------------------------------------------- Changes (by int-e): * cc: int-e@gmx.de (added) Comment: I was testing ghc 6.11 with the wrong version of 'unamb' version (the hackage one instead of the darcs head). Now I can reproduce the crash with ghc 6.11 as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 7 15:03:43 2009 From: trac at galois.com (GHC) Date: Sun Jun 7 14:47:30 2009 Subject: [GHC] #3279: Segmentation fault in reactive program In-Reply-To: <045.28ccfad62541fcb8fe7651779666954e@localhost> References: <045.28ccfad62541fcb8fe7651779666954e@localhost> Message-ID: <054.cf4a23c3dc642652308b16c72cea6741@localhost> #3279: Segmentation fault in reactive program ------------------------------+--------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86_64 (amd64) ------------------------------+--------------------------------------------- Comment (by int-e): FTR: I've confirmed that the {{{stg_dummy_ret_closure}}} comes from {{{RaiseAsync.c}}} by adding an additional {{{stg_dummy_ret_ra_closure}}} and using that in {{{RaiseAsync.c}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 7 17:15:01 2009 From: trac at galois.com (GHC) Date: Sun Jun 7 16:58:47 2009 Subject: [GHC] #3282: How to start an emacs editor within ghci asynchronously with :edit filename.hs :set editor emacs & don't go Message-ID: <048.be8dd9462b3573e642dcec0dfb5c7624@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 | Component: GHCi Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ----------------------------+----------------------------------------------- Hi Haskell Team, if i set my editor to ":set editor emacs &" and - say- want to edit my aaa.hs file , I enter ":edit aaa.hs", the ghci console answers: "/bin/sh: a.hs: not found", instead of opening emacs asynchronously. (":set editor nohup emacs" does not help either) then while editing emacs even i can enter commands ? into ghci, but they are not performed at all. GHCi's work goes on not before I close emacs. help is appreciated, Hape - Novice ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 7 21:13:26 2009 From: trac at galois.com (GHC) Date: Sun Jun 7 20:57:13 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.7d3fa840ebdedf40f0c5f9869903db03@localhost> #3260: Linking stage2 on PPC gives "scattered reloc r_address too large" ----------------------+----------------------------------------------------- Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: critical | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: powerpc ----------------------+----------------------------------------------------- Comment (by thorkilnaur): The problem appeared between the PPC Mac OS X builds http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20head%202/builds/223 and http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20head%202/builds/224. Searching the patches applied between those two builds, I have found that the problem appears precisely when the patch {{{ Fri Apr 3 10:46:34 CEST 2009 simonpj@microsoft.com * Adjust inlining heursitics }}} is applied. I have also tried to unpull this patch from the HEAD repository of the {{{tnaur PPC OSX head 2}}} builder and then the build succeeds. (The {{{tnaur PPC OSX head 2}}} builder has suffered from other errors lately, the latest build that reports the error reported in the present ticket is http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20head%202/builds/252/steps/compile/logs/stdio.) Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 8 01:31:04 2009 From: trac at galois.com (GHC) Date: Mon Jun 8 01:14:48 2009 Subject: [GHC] #3283: Selective disabling of unused bind warnings Message-ID: <042.99c53619193c24de1883dd2c0ccb355d@localhost> #3283: Selective disabling of unused bind warnings -----------------------------+---------------------------------------------- Reporter: ajd | 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 like to compile with -fwarn-unused-binds to keep my code clean, but I think a couple of extra flags to control this would be useful: * -fno-warn-unused-fields which would turn off warnings for record field names that were not used. I know you can prefix them with _, but then when you do use them then you have to change the name, etc. * A {-# USED f, g, h, ... #-} pragma to tell the compiler not to warn about the functions given in the pragma. I can see how especially the second could be controversial as it introduces an incompatibility, but I think both of these features could be put to good use. Not very high priority, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 8 04:25:31 2009 From: trac at galois.com (GHC) Date: Mon Jun 8 04:09:31 2009 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> Message-ID: <060.d87acfedd19414dbbe1dcde33fb2520e@localhost> #2615: ghci doesn't play nice with linker scripts ---------------------------------+------------------------------------------ Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by fasta): * cc: fasta (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 8 06:36:36 2009 From: trac at galois.com (GHC) Date: Mon Jun 8 06:20:20 2009 Subject: [GHC] #3284: ghc: panic! (the 'impossible' happened). RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph Message-ID: <049.4914c49b41cf056fab45d2733464764f@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 | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 -----------------------------+---------------------------------------------- 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 Mon Jun 8 06:54:59 2009 From: trac at galois.com (GHC) Date: Mon Jun 8 06:38:48 2009 Subject: [GHC] #3279: Segmentation fault in reactive program In-Reply-To: <045.28ccfad62541fcb8fe7651779666954e@localhost> References: <045.28ccfad62541fcb8fe7651779666954e@localhost> Message-ID: <054.92d80a1e981f2f7eb4e896cf22fb5868@localhost> #3279: Segmentation fault in reactive program -------------------------------+-------------------------------------------- Reporter: Baughn | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * component: Compiler => Runtime System * owner: => simonmar * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 8 08:21:07 2009 From: trac at galois.com (GHC) Date: Mon Jun 8 08:04:51 2009 Subject: [GHC] #3285: "PAP object entered" on executable with profiling Message-ID: <046.a867b46d0c7fc391829dcfde12d494ae@localhost> #3285: "PAP object entered" on executable with profiling --------------------+------------------------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- We're developing a tool that translates System Fc (GHC Core) to VHDL, and thus make use of the GHC API. When I try running my compiled executable with profiling support. I get the following error: {{{ $ clash library IEEE; use IEEE.std_logic_1164.all; use IEEE.numeric_std.all; package types is clash: internal error: PAP object entered! (GHC version 6.10.3 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap }}} When I run my executable without profiling support compiled in, I do not get the above error, and the program translates a piece of Haskell to VHDL just fine. This is the command I use to compile my executable with profiling support, it should also give some insight into which libraries we use: {{{ ghc -package ghc -package transformers -package ForSyDe -package prettyclass -package data-accessor -package ghc-paths -package data-accessor-template -package tfp -package tfvec HsValueMap.hs CoreShow.hs FlattenTypes.hs VHDLTypes.hs TranslatorTypes.hs GhcTools.hs HsTools.hs CoreTools.hs Flatten.hs Pretty.hs VHDL.hs Translator.hs -o clash -fforce-recomp --make -osuf p_o -hisuf p_hi -prof -auto -auto-all -dcore-lint }}} I have no idea what might cause this problem. If you could give some hints on how to debug this problem, I might be able to give a more useful bug report. Also, I can supply the necessary files on request so that you can reproduce this error. You can contact me on: -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 8 12:22:24 2009 From: trac at galois.com (GHC) Date: Mon Jun 8 12:06:09 2009 Subject: [GHC] #3279: Segmentation fault in reactive program In-Reply-To: <045.28ccfad62541fcb8fe7651779666954e@localhost> References: <045.28ccfad62541fcb8fe7651779666954e@localhost> Message-ID: <054.02a2dfa085ca087a985240054cb22e37@localhost> #3279: Segmentation fault in reactive program -------------------------------+-------------------------------------------- Reporter: Baughn | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by Baughn): There was a bug inside Unamb.hs. I think I'd best paste the relevant code.. race a b = block $ do v <- newEmptyMVar let f x = forkIO $ putCatch x v ta <- f a tb <- f b - We rely on killing the threads forked here in order to limit excessive work, but as you can see I'd forgotten to unblock exceptions first. Switching to a corrected implementation race a b = block $ do v <- newEmptyMVar let f x = forkIO $ putCatch (unblock x) v ta <- f a tb <- f b removed that problem. It also removed the crash. However, I have a feeling it may still exist in potentia, as a race condition. At any rate, that's a place to start; exceptions thrown to blocked threads that go on to evaluate bottoms. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 8 12:24:07 2009 From: trac at galois.com (GHC) Date: Mon Jun 8 12:07:51 2009 Subject: [GHC] #3279: Segmentation fault in reactive program In-Reply-To: <045.28ccfad62541fcb8fe7651779666954e@localhost> References: <045.28ccfad62541fcb8fe7651779666954e@localhost> Message-ID: <054.e6aefe7ca43b1e534ac7e3f30edaaefa@localhost> #3279: Segmentation fault in reactive program -------------------------------+-------------------------------------------- Reporter: Baughn | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by Baughn): Formatting messed up. Corrected, here: Before: race a b = block $ do[[BR]] v <- newEmptyMVar[[BR]] let f x = forkIO $ putCatch (unblock x) v[[BR]] ta <- f a[[BR]] tb <- f b[[BR]] After: race a b = block $ do[[BR]] v <- newEmptyMVar[[BR]] let f x = forkIO $ putCatch (unblock x) v[[BR]] ta <- f a[[BR]] tb <- f b[[BR]] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 9 07:52:37 2009 From: trac at galois.com (GHC) Date: Tue Jun 9 07:36:24 2009 Subject: [GHC] #3276: FilePath.addTrailingPathSeparator "" = "/" In-Reply-To: <045.c94373ccfee4669a603a10ee0b36cb4d@localhost> References: <045.c94373ccfee4669a603a10ee0b36cb4d@localhost> Message-ID: <054.fb7877642a19dc827350d6ccc8c59dd2@localhost> #3276: FilePath.addTrailingPathSeparator "" = "/" ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: bug | 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 | ----------------------------------+----------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: But the current directory should be ".", not "": #2034 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 9 08:01:30 2009 From: trac at galois.com (GHC) Date: Tue Jun 9 07:45:11 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.3ccaf10617b5f281073a3dfd2bc1d765@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: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: See #2528 for why this was changed. I have no opinion, fight it out amongst yourselves :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 9 08:04:46 2009 From: trac at galois.com (GHC) Date: Tue Jun 9 07:48:26 2009 Subject: [GHC] #3285: "PAP object entered" on executable with profiling In-Reply-To: <046.a867b46d0c7fc391829dcfde12d494ae@localhost> References: <046.a867b46d0c7fc391829dcfde12d494ae@localhost> Message-ID: <055.fb2b3164f408a43abffcf2d29861b35b@localhost> #3285: "PAP object entered" on executable with profiling -------------------------+-------------------------------------------------- Reporter: darchon | Owner: Type: 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): * difficulty: => Unknown * milestone: => 6.12.1 Comment: If you're using the interpreter via the GHC API, then be advised that it doesn't work with profiling. Nevertheless, there ought to be a better error message (see also #2197). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 9 09:26:25 2009 From: trac at galois.com (GHC) Date: Tue Jun 9 09:10:05 2009 Subject: [GHC] #3286: junk `naughty x86_64 register' after expression Message-ID: <044.a884c108b16324d08849108fcabffd26@localhost> #3286: junk `naughty x86_64 register' after expression -----------------------------+---------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler (NCG) | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Linux | Architecture: x86_64 (amd64) -----------------------------+---------------------------------------------- This is a cut-down version of the `hmm` and `logfloat` packages on hackage. On amd64/Linux, the 6.10 branch can build this, but the HEAD fails with: {{{ $ ghc -fforce-recomp -O --make A.hs [1 of 2] Compiling B ( B.hs, B.o ) [2 of 2] Compiling A ( A.hs, A.o ) /tmp/ghc29040_0/ghc29040_0.s: Assembler messages: /tmp/ghc29040_0/ghc29040_0.s:393:0: Error: junk `naughty x86_64 register' after expression }}} `A.hs`: {{{ module A (train) where import qualified Data.Map as M import Data.List (groupBy, foldl') import Data.Maybe (fromMaybe, fromJust) import Data.Function (on) import B type Prob = LogFloat learn_states :: (Ord state) => [(observation, state)] -> M.Map state Prob learn_states xs = histogram $ map snd xs learn_observations :: (Ord state, Ord observation) => M.Map state Prob -> [(observation, state)] -> M.Map (observation, state) Prob learn_observations state_prob = M.mapWithKey f . histogram where f (_, state) prob = prob / (fromJust $ M.lookup state state_prob) histogram :: (Ord a) => [a] -> M.Map a Prob histogram xs = let hist = foldl' undefined M.empty xs in M.map (/ M.fold (+) 0 hist) hist train :: (Ord observation, Ord state) => [(observation, state)] -> (observation -> [Prob]) train sample = model where states = learn_states sample state_list = M.keys states observations = learn_observations states sample observation_probs = fromMaybe (fill state_list []) . (flip M.lookup $ M.fromList $ map (\ (e, xs) -> (e, fill state_list xs)) $ map (\ xs -> (fst $ head xs, map snd xs)) $ groupBy ((==) `on` fst) [(observation, (state, prob)) | ((observation, state), prob) <- M.toAscList observations]) model = observation_probs fill :: Eq state => [state] -> [(state, Prob)] -> [Prob] fill = undefined }}} `B.hs`: {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} module B (LogFloat) where newtype LogFloat = LogFloat Double deriving (Eq, Ord, Num, Show) instance Fractional LogFloat where (/) (LogFloat x) (LogFloat y) | x == 1 && y == 1 = error "(/)" | otherwise = LogFloat (x-y) fromRational = LogFloat . fromRational }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 9 09:48:37 2009 From: trac at galois.com (GHC) Date: Tue Jun 9 09:32:18 2009 Subject: [GHC] #3287: Malformed LANGUAGE pragma causes GHC panic Message-ID: <044.fcccf2cd0a3305081b02d2c17735a495@localhost> #3287: Malformed LANGUAGE pragma causes GHC panic -----------------------------+---------------------------------------------- Reporter: caitt | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.10.2 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Hi, I tried to compile file starting with {-# LANGUAGE -XExistentialQuantification #-} which is of course wrong, but GHC should handle this more gracefully than ghc: panic! (the 'impossible' happened) (GHC version 6.10.2 for i386-unknown-linux): getOptions'.parseLanguage(2) went past eof token The 6.8.2 version surprisingly works better: test.hs:1:0: cannot parse LANGUAGE pragma -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 9 10:00:48 2009 From: trac at galois.com (GHC) Date: Tue Jun 9 09:45:12 2009 Subject: [GHC] #2933: LDFLAGS ignored by build system In-Reply-To: <045.854117476da424db3736910ffba011f0@localhost> References: <045.854117476da424db3736910ffba011f0@localhost> Message-ID: <054.1b59ea4bf47fe32cff785e89f0bd05a8@localhost> #2933: LDFLAGS ignored by build system ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by maeder): related to this ticket seems to be my problem when building ghc-6.10.3. I get the failure: {{{ Preprocessing library base-4.1.0.0... ld.so.1: CPUTime_hsc_make: fatal: libgmp.so.3: open failed: No such file or directory running dist/build/System/CPUTime_hsc_make failed command was: dist/build/System/CPUTime_hsc_make >dist/build/System/CPUTime.hs }}} after {{{ ./configure --with-gmp-includes=/opt/csw/include --with-gmp- libraries=/opt/csw/lib gmake }}} without LD_LIBRARY_PATH being set. It seems CPUTime_hsc_make is linked using -L/opt/csw/lib, but this path is not found when CPUTime_hsc_make is executed. Configuring without the with-gmp-flags everything works fine (because ghc re-builds gmp) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 9 10:17:22 2009 From: trac at galois.com (GHC) Date: Tue Jun 9 10:01:01 2009 Subject: [GHC] #3275: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> References: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> Message-ID: <055.bd49635a8de435e47b21a6d08033ae2b@localhost> #3275: ghc: panic! (the 'impossible' happened) -------------------------+-------------------------------------------------- Reporter: EricKow | Owner: Type: 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: > I downloaded the beta of the Haskell Platform installer from > http://hackage.haskell.org/platform/2009.2.0.1/haskell- > platform-2009.2.0.1-beta1-i386.dmg > > and when I tried to cabal install the HEAD version of darcs, I got this > error message: > [ 57 of 134] 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 a2ZC6} [lid], ww1{v a2ZC7} [lid], ww2{v a2ZC8} [lid]] > [!, !, _, _] > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > Darcs repo version (last patch; see attached for context file): > Mon Jun 1 10:19:28 BST 2009 Petr Rockai > * Remove tentativelyMerge from Gorsvet, as it's unused and confusing. New description: I downloaded the beta of the Haskell Platform installer from http://hackage.haskell.org/platform/2009.2.0.1/haskell- platform-2009.2.0.1-beta1-i386.dmg and when I tried to cabal install the HEAD version of darcs, I got this error message: {{{ [ 57 of 134] 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 a2ZC6} [lid], ww1{v a2ZC7} [lid], ww2{v a2ZC8} [lid]] [!, !, _, _] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Darcs repo version (last patch; see attached for context file): {{{ Mon Jun 1 10:19:28 BST 2009 Petr Rockai * Remove tentativelyMerge from Gorsvet, as it's unused and confusing. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 9 10:17:53 2009 From: trac at galois.com (GHC) Date: Tue Jun 9 10:01:37 2009 Subject: [GHC] #3287: Malformed LANGUAGE pragma causes GHC panic In-Reply-To: <044.fcccf2cd0a3305081b02d2c17735a495@localhost> References: <044.fcccf2cd0a3305081b02d2c17735a495@localhost> Message-ID: <053.b8186fa4e1b8d9ca54b44bac6ff553bc@localhost> #3287: Malformed LANGUAGE pragma causes GHC panic ----------------------------------+----------------------------------------- Reporter: caitt | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.2 Severity: minor | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report! See #3153 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 9 11:36:19 2009 From: trac at galois.com (GHC) Date: Tue Jun 9 11:19:57 2009 Subject: [GHC] #3275: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> References: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> Message-ID: <055.969886778d9323cab9aeae35cfdd83d0@localhost> #3275: ghc: panic! (the 'impossible' happened) -------------------------+-------------------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * milestone: => 6.10.4 Comment: I can't reproduce this on my OS X/x86 machine, with the 6.10.3 installer from the GHC download page and a hand-compiled cabal-install. I also can't install that beta. It says {{{ The following install step failed: run postinstall script for hp- postflight. Con tact the software manufacturer for assistance. }}} Eric, can you see if you can reproduce it by running `./Setup build`, or even `ghc --make`, by hand please? If you could boil it down to a minimal testcase then that would be very useful indeed. Just try replacing right hand sides of top-level things with undefined, and remove functions and imports that are no longer used as a result (warnings are a great help here). In particular, removing dependencies on other packages, and removing any special preprocessing etc, is valuable, so that the bug can be reproduced with just `ghc --make ...`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 9 12:15:02 2009 From: trac at galois.com (GHC) Date: Tue Jun 9 11:58:59 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.60b2c3e691473383d180b7174030a869@localhost> #3137: ghc 6.10.2 fails to compile on Mac OS X Leopard ---------------------------------+------------------------------------------ Reporter: mvanier | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Can someone who can reproduce this try building the HEAD please? There are now some Cabal patches in it, such as {{{ Sun May 31 20:34:12 BST 2009 Duncan Coutts * Always build ar files with indexes Since we have to be able to use these inplace we always need the index it's not enough to just make the index on installing. This particularly affects OSX. }}} that might fix the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 9 12:29:34 2009 From: trac at galois.com (GHC) Date: Tue Jun 9 12:13:17 2009 Subject: [GHC] #3276: FilePath.addTrailingPathSeparator "" = "/" In-Reply-To: <045.c94373ccfee4669a603a10ee0b36cb4d@localhost> References: <045.c94373ccfee4669a603a10ee0b36cb4d@localhost> Message-ID: <054.678c388ec568d3acbd5b73a6f4a6d545@localhost> #3276: FilePath.addTrailingPathSeparator "" = "/" ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: bug | 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 duncan): Sure, when it returns the current directory as a filepath that should be ".", but when I (or actually the end user) use "" as an input that's still the current directory and clearly not the root directory. Or are we saying that "" as an input should be an error? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 9 12:33:58 2009 From: trac at galois.com (GHC) Date: Tue Jun 9 12:18:20 2009 Subject: [GHC] #2933: LDFLAGS ignored by build system In-Reply-To: <045.854117476da424db3736910ffba011f0@localhost> References: <045.854117476da424db3736910ffba011f0@localhost> Message-ID: <054.d6a599d83bf931a1096d8efaaa4189ae@localhost> #2933: LDFLAGS ignored by build system ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [comment:5 maeder]: > related to this ticket seems to be my problem when building ghc-6.10.3. I get the failure: > > {{{ > Preprocessing library base-4.1.0.0... > ld.so.1: CPUTime_hsc_make: fatal: libgmp.so.3: open failed: No such file or directory > running dist/build/System/CPUTime_hsc_make failed > command was: dist/build/System/CPUTime_hsc_make >dist/build/System/CPUTime.hs > }}} > without LD_LIBRARY_PATH being set. > > It seems CPUTime_hsc_make is linked using -L/opt/csw/lib, but this path is not found when CPUTime_hsc_make is executed. We (or maybe hsc2hs) should use -rpath in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 9 15:41:02 2009 From: trac at galois.com (GHC) Date: Tue Jun 9 15:24:43 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.617bcc5115c400d371a0f63d1ce59568@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: Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Clearly we must have `nub = nubBy (==)`. So perhaps that means we need to fix `nub` to bring it in line with the previous definition of `nubBy` (if that's agreed to be the sensible definition). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 9 17:30:38 2009 From: trac at galois.com (GHC) Date: Tue Jun 9 17:14:18 2009 Subject: [GHC] #3288: GC assertion failure in reactive program Message-ID: <045.65aeaae2456294cc6dd5e6fd9db05b84@localhost> #3288: GC assertion failure in reactive program -----------------------------+---------------------------------------------- Reporter: Baughn | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.11 | Severity: normal Keywords: | Testcase: crash.hs Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- In the same vein as [http://hackage.haskell.org/trac/ghc/ticket/3279 bug #3279], this time I've triggered an assertion failure in the GC by adding Debug.Trace.trace expressions. The exact same failure occurs in both 6.10.3 and 6.11, apparently completely deterministically. A darcs patch to add the crash to reactive, and a program to trigger it, are both attached. Expected output: {{{ svein@eris ~ $ ./crash "never-never" crash: internal error: scavenge_one: strange object 28 (GHC version 6.11.20090605 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 Jun 9 22:24:41 2009 From: trac at galois.com (GHC) Date: Tue Jun 9 22:08:20 2009 Subject: [GHC] #3289: make -j3 (or make -j30) occasionally fails on 6.11 Message-ID: <047.70666110621d92af3cf2b3e0ea735059@localhost> #3289: make -j3 (or make -j30) occasionally fails on 6.11 --------------------------------------+------------------------------------- Reporter: gbeshers | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: makefile dependency split | Testcase: Os: Linux | Architecture: x86_64 (amd64) --------------------------------------+------------------------------------- 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 Wed Jun 10 04:32:23 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 04:16:03 2009 Subject: [GHC] #3285: "PAP object entered" on executable with profiling In-Reply-To: <046.a867b46d0c7fc391829dcfde12d494ae@localhost> References: <046.a867b46d0c7fc391829dcfde12d494ae@localhost> Message-ID: <055.12f271732173fd5d132687d951f57dbc@localhost> #3285: "PAP object entered" on executable with profiling -------------------------+-------------------------------------------------- Reporter: darchon | Owner: Type: 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 | -------------------------+-------------------------------------------------- Comment (by darchon): We do not make use of the interpreter directly, but yes, we certainly do make use of functions I think the interpreter uses as well, as we sometimes have to evaluate a Haskell expression. We use functions such as HscMain.compileExpr and also some of the other API functions to rename, type-check, simplefy, desugar, etc. some Haskell expressions. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 10 04:48:28 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 04:32:06 2009 Subject: [GHC] #3276: FilePath.addTrailingPathSeparator "" = "/" In-Reply-To: <045.c94373ccfee4669a603a10ee0b36cb4d@localhost> References: <045.c94373ccfee4669a603a10ee0b36cb4d@localhost> Message-ID: <054.639b89a01922de433313d4709f8bf2d3@localhost> #3276: FilePath.addTrailingPathSeparator "" = "/" ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: bug | 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 simonmar): "" isn't a valid `FilePath`, in the sense that passing it to an OS function expecting a `FilePath` will result in an error. So I think that `System.FilePath` should never return "" as a directory name, and it should probably raise an error if "" is passed in too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 10 04:50:48 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 04:34:25 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.159c1cdbf80d6c0f84bd1e429908f1e5@localhost> #2197: GHCi doesn't work when built with way=p ---------------------------------+------------------------------------------ Reporter: SamB | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): See also #3285 - we should give a better error message when someone tries to use the GHC API in profiled mode. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 10 04:51:56 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 04:35:34 2009 Subject: [GHC] #3285: "PAP object entered" on executable with profiling In-Reply-To: <046.a867b46d0c7fc391829dcfde12d494ae@localhost> References: <046.a867b46d0c7fc391829dcfde12d494ae@localhost> Message-ID: <055.d43ffecb434eb927830ddbdda1fc6b41@localhost> #3285: "PAP object entered" on executable with profiling -------------------------+-------------------------------------------------- Reporter: darchon | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: closing as duplicate after adding a note to #2197 - thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 10 04:53:48 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 04:37:25 2009 Subject: [GHC] #3288: GC assertion failure in reactive program In-Reply-To: <045.65aeaae2456294cc6dd5e6fd9db05b84@localhost> References: <045.65aeaae2456294cc6dd5e6fd9db05b84@localhost> Message-ID: <054.060e80091e6e66bb1589a18894cd350b@localhost> #3288: GC assertion failure in reactive program ---------------------------------+------------------------------------------ Reporter: Baughn | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.4 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: crash.hs | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * owner: => simonmar * milestone: => 6.10.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 10 09:58:24 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 09:42:00 2009 Subject: [GHC] #3290: Add Functor, Applicative, Monad, and Monoid instances for ParseResult Message-ID: <047.533c2be1a845c9c65a70d5ca34eb8067@localhost> #3290: Add Functor, Applicative, Monad, and Monoid instances for ParseResult -----------------------------+---------------------------------------------- Reporter: YitzGale | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 6.10.3 | Severity: normal Keywords: haskell-src | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- In the haskell-src package, add the following instances to !ParseResult: {{{ instance Functor ParseResult instance Applicative ParseResult instance Monad ParseResult instance Monoid m => Monoid (ParseResult m) }}} This makes it more convenient to traverse and modify a syntax tree that is the result of the parser. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 10 12:47:00 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 12:30:38 2009 Subject: [GHC] #3276: FilePath.addTrailingPathSeparator "" = "/" In-Reply-To: <045.c94373ccfee4669a603a10ee0b36cb4d@localhost> References: <045.c94373ccfee4669a603a10ee0b36cb4d@localhost> Message-ID: <054.28e6afaaa30e77d196ab301eae61f54a@localhost> #3276: FilePath.addTrailingPathSeparator "" = "/" ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: bug | 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 duncan): I'm not sure people will be happy, that means: {{{ x "" = error "" y = error }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 10 12:48:11 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 12:31:48 2009 Subject: [GHC] #3291: "Thread blocked indefinitely" kills the program despite being caught Message-ID: <053.fb53b1fc888659080c438c349e98c0a5@localhost> #3291: "Thread blocked indefinitely" kills the program despite being caught -----------------------------+---------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Perhaps this is just me misunderstanding the semantics of exceptions, but the following program: """ import Test.HUnit.Lang import Control.Concurrent.STM import Control.Exception import Control.Concurrent import Control.Concurrent.MVar main = do mv <- newEmptyMVar forkIO $ do r <- performTestCase (atomically retry) print "Yeaahh!" print r evaluate r putMVar mv r print "Cool, let's see what we get" r <- takeMVar mv print r print "Am I printed?" """ Should in my opinion, when run, print "Am I printed". This is because the "Thread blocked indefinitely" exception is caught by HUnit. However, this happens instead: """ mbolingbroke@mb566 ~/Junk $ ./Repro "Cool, let's see what we get" "Yeaahh!" Just (False,"thread blocked indefinitely") Repro: thread blocked indefinitely """ NB: I get the expected behaviour if I run it within GHCi, but not if I compile the program. This is causing problems for test-framework (see http://bsp.lighthouseapp.com/projects/15661-hs-test-framework/tickets/1 -exits-immediately-on-thread-blocked-indefinitely-exception#ticket-1-2) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 10 13:25:01 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 13:08:48 2009 Subject: [GHC] #3290: Add Functor, Applicative, Monad, and Monoid instances for ParseResult In-Reply-To: <047.533c2be1a845c9c65a70d5ca34eb8067@localhost> References: <047.533c2be1a845c9c65a70d5ca34eb8067@localhost> Message-ID: <056.c4f6b399f5980d2a4ac98056468c3a3f@localhost> #3290: Add Functor, Applicative, Monad, and Monoid instances for ParseResult -------------------------------+-------------------------------------------- Reporter: YitzGale | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.3 Severity: normal | Resolution: Keywords: haskell-src | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by nibro): I've added this patch in entirety to haskell-src-exts, thanks a lot !YitzGale! Why use haskell-src...? ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 10 13:28:47 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 13:12:25 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.f522b2a31407b4fb54c6961639d40812@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 zooko): "each time this happens, the memory usage goes up a bit - even though even last bit of the history will get discarded once the page has been constructed and sent off to the client. (We've checked for memory leaks" If the memory usage continues to grow when a substantially similar task is being performed over and over, then this is a memory leak. That's a separate issue from returning memory to the OS. Personally I don't think returning memory to the OS is worth the effort. The OS will swap it out anyway when it is unused. (Hint: never look at the "virtual memory size" on linux. It is a useless and misleading number -- it doesn't correlate with anything that we actually care about.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 10 13:36:21 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 13:20:03 2009 Subject: [GHC] #3291: "Thread blocked indefinitely" kills the program despite being caught In-Reply-To: <053.fb53b1fc888659080c438c349e98c0a5@localhost> References: <053.fb53b1fc888659080c438c349e98c0a5@localhost> Message-ID: <062.ceea9db3f09db40abb98a94182bd5626@localhost> #3291: "Thread blocked indefinitely" kills the program despite being caught ------------------------------+--------------------------------------------- Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by enolan): * cc: echo@echonolan.net (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 10 14:42:27 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 14:27:03 2009 Subject: [GHC] #3275: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> References: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> Message-ID: <055.aaefdc88f6b3a1aeadd8d5e3345043ce@localhost> #3275: ghc: panic! (the 'impossible' happened) -------------------------+-------------------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by GregoryCollins): I can reproduce this also -- hoping it isn't an issue with the platform libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 10 15:01:37 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 14:45:12 2009 Subject: [GHC] #3292: Add an 'ignore' function to Control.Monad Message-ID: <044.27c764de47060e5a6666b1886ee80198@localhost> #3292: Add an 'ignore' function to Control.Monad -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.10.2 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- See http://www.haskell.org/pipermail/libraries/2009-June/thread.html#11880 In short, add a 'ignore :: m a -> m ()' function to Control.Monad. This lets us do things like 'forkIO $ ignore stuff', as opposed to throwing around all sorts of '>> return ()'. This function could be widely used by many libraries & apps, and has been repeatedly invented and suggested (see the thread). So far no one has said a word against it. {{{ - -- | Convenience function. This is particularly good for 'forkIO' and 'forM_', -- as they demand return types of 'IO ()', but most interesting IO functions -- don't return void. So one can wrap them with 'ignore' (essentially a call to 'unit'). ignore :: Functor f => f a -> f () ignore = fmap (const ()) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 10 16:43:10 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 16:26:46 2009 Subject: [GHC] #3293: Implement shiftLInteger and shiftRInteger Message-ID: <044.df0bc2082d2b67a740bace217a62079f@localhost> #3293: Implement shiftLInteger and shiftRInteger -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Currently `shift` for `Integer` (in `Data.Bits`) is defined in terms of `(*)`, `div` and `^`. Instead, `integer-*` should export `shiftLInteger` and `shiftRInteger`, which can be more efficient. We should do this after the builtin-primop/FFI-imported-primop stuff is worked out, so that we can use a suitable GMP function for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 10 17:58:31 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 17:42:09 2009 Subject: [GHC] #3294: Large compilation time/memory consumption Message-ID: <046.0a15417e538aeef3254b5152fea74b37@localhost> #3294: Large compilation time/memory consumption -----------------------------------------+---------------------------------- Reporter: pumpkin | Owner: Type: compile-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 -----------------------------------------+---------------------------------- 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 Wed Jun 10 18:34:55 2009 From: trac at galois.com (GHC) Date: Wed Jun 10 18:18:31 2009 Subject: [GHC] #3295: Null deref by threaded runtime scheduler Message-ID: <044.c2ef3bf0c2dff07fbe94ef6f704ea47f@localhost> #3295: Null deref by threaded runtime scheduler -----------------------------------------------------+---------------------- Reporter: A1kmm | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.11 | Severity: major Keywords: crash, nullderef, threaded, parallel, GC | Testcase: Os: Linux | Architecture: ia64 -----------------------------------------------------+---------------------- Using ghc and runtime built from HEAD on Tuesday (although this has been an issue on older builds I tried as well), the ghc runtime crashes on a null deref. The system is a 24-processor Intel Xeon 2.66 GHz shared memory system running Linux 2.6.16.60-0.34-smp in 64 bit mode (from SUSE 10 SP2). This only happens when the program is compiled with -threaded (threaded runtime), but doesn't happen with the threaded debug runtime. It also only happens when +RTS -N2 or a greater number of threads is passed to the runtime. It doesn't happen when -g1 is passed to turn off distributed garbage collection. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1241594176 (LWP 20751)] 0x000000000067262c in schedule (initialCapability=, task=0x994370) at rts/Schedule.c:672 672 return (waiting_for_gc || (gdb) list 667 // - another thread is initiating a GC 668 // - another Task is returning from a foreign call 669 // - the thread at the head of the run queue cannot be run 670 // by this Task (it is bound to another Task, or it is unbound 671 // and this task it bound). 672 return (waiting_for_gc || 673 cap->returning_tasks_hd != NULL || 674 (!emptyRunQueue(cap) && (task->tso == NULL 675 ? cap->run_queue_hd->bound != NULL 676 : cap->run_queue_hd->bound != task))); (gdb) print cap $1 = (Capability *) 0x0 (gdb) print *task $2 = {id = 1241594176, cap = 0x0, stopped = 7160552, suspended_tso = 0x0, tso = 0x7fccc4, stat = NoStatus, ret = 0x0, cond = {__data = {__lock = 1, __futex = 0, __total_seq = 1, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x84e340, __nwaiters = 10033872, __broadcast_seq = 0}, __size = "\001\000\000\000\000\000\000\000\001", '\0' , "@?\204\000\000\000\000\000?\032\231\000\000\000\000", __align = 1}, lock = {__data = { __lock = 0, __count = 1, __owner = 0, __nusers = 0, __kind = 22668, __spins = 0, __list = {__prev = 0x5793, __next = 0x85afd}}, __size = "\000\000\000\000\001", '\0' , "\214X\000\000\000\000\000\000\223W\000\000\000\000\000\000?Z\b\000\000\000\000", __align = 4294967296}, wakeup = 547420, elapsedtimestart = 202, muttimestart = 0, mut_time = 0, mut_etime = 0, gc_time = 0, gc_etime = 10033296, prev = 0x994370, next = 0x0, return_link = 0x0, all_link = 0x0, prev_stack = 0x9945c0} (gdb) info threads * 21 Thread 1241594176 (LWP 20751) 0x000000000067262c in schedule (initialCapability=, task=0x994370) at rts/Schedule.c:672 20 Thread 1233201472 (LWP 20750) 0x000000000067262c in schedule (initialCapability=, task=0x9b4930) at rts/Schedule.c:672 19 Thread 1224808768 (LWP 20749) 0x000000000067262c in schedule (initialCapability=, task=0x9b2df0) at rts/Schedule.c:672 18 Thread 1216416064 (LWP 20748) 0x000000000067262c in schedule (initialCapability=, task=0x9b12b0) at rts/Schedule.c:672 17 Thread 1208023360 (LWP 20747) 0x000000000067262c in schedule (initialCapability=, task=0x9af770) at rts/Schedule.c:672 16 Thread 1199630656 (LWP 20746) 0x000000000067262c in schedule (initialCapability=, task=0x9adc30) at rts/Schedule.c:672 15 Thread 1191237952 (LWP 20745) 0x000000000067262c in schedule (initialCapability=, task=0x9ac0f0) at rts/Schedule.c:672 14 Thread 1182845248 (LWP 20744) 0x000000000067262c in schedule (initialCapability=, task=0x9aa5b0) at rts/Schedule.c:672 13 Thread 1174452544 (LWP 20743) 0x000000000067262c in schedule (initialCapability=, task=0x9a8a70) at rts/Schedule.c:672 12 Thread 1166059840 (LWP 20742) 0x000000000067262c in schedule (initialCapability=, task=0x9a6f30) at rts/Schedule.c:672 11 Thread 1157667136 (LWP 20741) 0x000000000067262c in schedule (initialCapability=, task=0x9a53f0) at rts/Schedule.c:672 10 Thread 1149274432 (LWP 20740) 0x000000000067262c in schedule (initialCapability=, task=0x9a38b0) at rts/Schedule.c:672 9 Thread 1140881728 (LWP 20739) 0x000000000067262c in schedule (initialCapability=, task=0x9a1d70) at rts/Schedule.c:672 8 Thread 1132489024 (LWP 20738) 0x000000000067262c in schedule (initialCapability=, task=0x9a0230) at rts/Schedule.c:672 7 Thread 1124096320 (LWP 20737) 0x000000000067262c in schedule (initialCapability=, task=0x99e6f0) at rts/Schedule.c:672 6 Thread 1115703616 (LWP 20736) 0x000000000067262c in schedule (initialCapability=, task=0x99cbb0) at rts/Schedule.c:672 5 Thread 1107310912 (LWP 20735) 0x000000000067262c in schedule (initialCapability=, task=0x99b070) at rts/Schedule.c:672 4 Thread 1098918208 (LWP 20734) 0x000000000067262c in schedule (initialCapability=, task=0x999530) at rts/Schedule.c:672 3 Thread 1090525504 (LWP 20733) 0x000000000067262c in schedule (initialCapability=, task=0x9979f0) at rts/Schedule.c:672 2 Thread 1082132800 (LWP 20732) 0x00002aae2fa22548 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 1 Thread 46927615298704 (LWP 20729) 0x00002aae2fa20553 in pthread_cond_signal@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 The values of *task and the thread in which the crash occurs is not always consistent, but the stacktrace is. For example, another crash... (gdb) bt #0 0x000000000067262c in schedule (initialCapability=, task=0x9b4930) at rts/Schedule.c:672 #1 0x0000000000673205 in workerStart (task=0x9915e0) at rts/Schedule.c:2033 #2 0x00002aae0cd1a143 in start_thread () from /lib64/libpthread.so.0 #3 0x00002aae0ceee8cd in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () (gdb) print *task $6 = {id = 1233201472, cap = 0x0, stopped = 11791697, suspended_tso = 0x0, tso = 0x25ed0f1, stat = NoStatus, ret = 0x0, cond = {__data = {__lock = 1, __futex = 0, __total_seq = 1, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x84e800, __nwaiters = 10033872, __broadcast_seq = 0}, __size = "\001\000\000\000\000\000\000\000\001", '\0' , "?\204\000\000\000\000\000?\032\231\000\000\000\000", __align = 1}, lock = {__data = {__lock = 0, __count = 1, __owner = 0, __nusers = 0, __kind = 875, __spins = 0, __list = {__prev = 0x33a, __next = 0x2da2b}}, __size = "\000\000\000\000\001", '\0' , "k\003\000\000\000\000\000\000:\003\000\000\000\000\000\000+?\002\000\000\000\000", __align = 4294967296}, wakeup = 186902, elapsedtimestart = 24, muttimestart = 0, mut_time = 0, mut_etime = 0, gc_time = 0, gc_etime = 10033296, prev = 0x9b4930, next = 0x0, return_link = 0x0, all_link = 0x0, prev_stack = 0x9b4b80} (gdb) info threads 22 Thread 1249986880 (LWP 20846) 0x00002aae0cd20548 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 21 Thread 1241594176 (LWP 20845) 0x00002aae0cd1e1c6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 * 20 Thread 1233201472 (LWP 20844) 0x000000000067262c in schedule (initialCapability=, task=0x9b4930) at rts/Schedule.c:672 19 Thread 1224808768 (LWP 20843) 0x000000000067262c in schedule (initialCapability=, task=0x9b2df0) at rts/Schedule.c:672 18 Thread 1216416064 (LWP 20842) 0x000000000067262c in schedule (initialCapability=, task=0x9b12b0) at rts/Schedule.c:672 17 Thread 1208023360 (LWP 20841) 0x000000000067262c in schedule (initialCapability=, task=0x9af770) at rts/Schedule.c:672 16 Thread 1199630656 (LWP 20840) 0x000000000067262c in schedule (initialCapability=, task=0x9adc30) at rts/Schedule.c:672 15 Thread 1191237952 (LWP 20839) 0x000000000067262c in schedule (initialCapability=, task=0x9ac0f0) at rts/Schedule.c:672 14 Thread 1182845248 (LWP 20838) 0x000000000067262c in schedule (initialCapability=, task=0x9aa5b0) at rts/Schedule.c:672 13 Thread 1174452544 (LWP 20837) gcWorkerThread (cap=) at includes/SpinLock.h:45 12 Thread 1166059840 (LWP 20836) 0x000000000067262c in schedule (initialCapability=, task=0x9a6f30) at rts/Schedule.c:672 11 Thread 1157667136 (LWP 20835) 0x000000000067262c in schedule (initialCapability=, task=0x9a53f0) at rts/Schedule.c:672 10 Thread 1149274432 (LWP 20834) 0x000000000067262c in schedule (initialCapability=, task=0x9a38b0) at rts/Schedule.c:672 9 Thread 1140881728 (LWP 20833) 0x000000000067262c in schedule (initialCapability=, task=0x9a1d70) at rts/Schedule.c:672 8 Thread 1132489024 (LWP 20832) 0x000000000067262c in schedule (initialCapability=, task=0x9a0230) at rts/Schedule.c:672 7 Thread 1124096320 (LWP 20831) 0x000000000067262c in schedule (initialCapability=, task=0x99e6f0) at rts/Schedule.c:672 6 Thread 1115703616 (LWP 20830) 0x000000000067262c in schedule (initialCapability=, task=0x99cbb0) at rts/Schedule.c:672 5 Thread 1107310912 (LWP 20829) 0x000000000067262c in schedule (initialCapability=, task=0x99b070) at rts/Schedule.c:672 4 Thread 1098918208 (LWP 20827) 0x000000000067262c in schedule (initialCapability=, task=0x999530) at rts/Schedule.c:672 3 Thread 1090525504 (LWP 20826) 0x000000000067262c in schedule (initialCapability=, task=0x9979f0) at rts/Schedule.c:672 2 Thread 1082132800 (LWP 20825) 0x00002aae0cee86e2 in select () from /lib64/libc.so.6 1 Thread 46927031233680 (LWP 20824) 0x00002aae0cd1c2ef in pthread_mutex_lock () from /lib64/libpthread.so.0 valgrind memcheck does not report any errors prior to the NULL deref: ==20983== Thread 2: ==20983== Invalid read of size 8 ==20983== at 0x67262C: schedule (Schedule.c:672) ==20983== by 0x673204: workerStart (Schedule.c:2033) ==20983== by 0x58E4142: start_thread (in /lib64/libpthread-2.4.so) ==20983== by 0x5AB78CC: clone (in /lib64/libc-2.4.so) ==20983== Address 0x1d0 is not stack'd, malloc'd or (recently) free'd ==20983== ==20983== Process terminating with default action of signal 11 (SIGSEGV) valgrind helgrind reports numerous possible data race conditions, including one between schedule and GarbageCollect just prior to the crash: ==21106== Possible data race during read of size 8 at 0x5ccc300 by thread #5 ==21106== at 0x672612: schedule (Schedule.c:367) ==21106== by 0x673204: workerStart (Schedule.c:2033) ==21106== by 0x4A24A1E: mythread_wrapper (hg_intercepts.c:194) ==21106== by 0x58E7142: start_thread (in /lib64/libpthread-2.4.so) ==21106== by 0x5ABA8CC: clone (in /lib64/libc-2.4.so) ==21106== This conflicts with a previous write of size 8 by thread #1 ==21106== at 0x679B8D: GarbageCollect (SpinLock.h:55) ==21106== by 0x6712D0: scheduleDoGC (Schedule.c:1522) ==21106== by 0x672C77: schedule (Schedule.c:621) ==21106== by 0x66FF84: real_main (RtsMain.c:68) ==21106== by 0x67009D: hs_main (RtsMain.c:117) ==21106== by 0x5A17183: (below main) (in /lib64/libc-2.4.so) I am still working on whether I can make a small program to reproduce this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 11 06:53:37 2009 From: trac at galois.com (GHC) Date: Thu Jun 11 06:37:16 2009 Subject: [GHC] #3292: Add an 'ignore' function to Control.Monad In-Reply-To: <044.27c764de47060e5a6666b1886ee80198@localhost> References: <044.27c764de47060e5a6666b1886ee80198@localhost> Message-ID: <053.a8108ca54f0abb35c65ef506f1a7315a@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 ------------------------------+--------------------------------------------- Changes (by guest): * cc: kfrdbs@gmail.com (added) Comment: [http://www.nabble.com/Adding-an-ignore-function-to-Control.Monad- td23966574.html Nabble link for those who use it] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 11 10:34:07 2009 From: trac at galois.com (GHC) Date: Thu Jun 11 10:17:43 2009 Subject: [GHC] #3295: Null deref by threaded runtime scheduler In-Reply-To: <044.c2ef3bf0c2dff07fbe94ef6f704ea47f@localhost> References: <044.c2ef3bf0c2dff07fbe94ef6f704ea47f@localhost> Message-ID: <053.870658376c58c880d3a60fb1d182c4b7@localhost> #3295: Null deref by threaded runtime scheduler ---------------------------------------------------------+------------------ Reporter: A1kmm | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: major | Resolution: Keywords: crash, nullderef, threaded, parallel, GC | Difficulty: Unknown Testcase: | Os: Linux Architecture: ia64 | ---------------------------------------------------------+------------------ Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * owner: => simonmar * milestone: => 6.12.1 Old description: > Using ghc and runtime built from HEAD on Tuesday (although this has been > an issue on older builds I tried as well), the ghc runtime crashes on a > null deref. > > The system is a 24-processor Intel Xeon 2.66 GHz shared memory system > running Linux 2.6.16.60-0.34-smp in 64 bit mode (from SUSE 10 SP2). > > This only happens when the program is compiled with -threaded (threaded > runtime), but doesn't happen with the threaded debug runtime. > > It also only happens when +RTS -N2 or a greater number of threads is > passed to the runtime. It doesn't happen when -g1 is passed to turn off > distributed garbage collection. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1241594176 (LWP 20751)] > 0x000000000067262c in schedule (initialCapability=, > task=0x994370) at rts/Schedule.c:672 > 672 return (waiting_for_gc || > (gdb) list > 667 // - another thread is initiating a GC > 668 // - another Task is returning from a foreign call > 669 // - the thread at the head of the run queue cannot be run > 670 // by this Task (it is bound to another Task, or it is > unbound > 671 // and this task it bound). > 672 return (waiting_for_gc || > 673 cap->returning_tasks_hd != NULL || > 674 (!emptyRunQueue(cap) && (task->tso == NULL > 675 ? cap->run_queue_hd->bound > != NULL > 676 : cap->run_queue_hd->bound > != task))); > (gdb) print cap > $1 = (Capability *) 0x0 > (gdb) print *task > $2 = {id = 1241594176, cap = 0x0, stopped = 7160552, suspended_tso = 0x0, > tso = 0x7fccc4, stat = NoStatus, ret = 0x0, cond = {__data = {__lock = 1, > __futex = 0, > __total_seq = 1, __wakeup_seq = 0, __woken_seq = 0, __mutex = > 0x84e340, __nwaiters = 10033872, __broadcast_seq = 0}, > __size = "\001\000\000\000\000\000\000\000\001", '\0' times>, "@?\204\000\000\000\000\000?\032\231\000\000\000\000", __align = > 1}, lock = {__data = { > __lock = 0, __count = 1, __owner = 0, __nusers = 0, __kind = 22668, > __spins = 0, __list = {__prev = 0x5793, __next = 0x85afd}}, > __size = "\000\000\000\000\001", '\0' , > "\214X\000\000\000\000\000\000\223W\000\000\000\000\000\000?Z\b\000\000\000\000", > __align = 4294967296}, > wakeup = 547420, elapsedtimestart = 202, muttimestart = 0, mut_time = > 0, mut_etime = 0, gc_time = 0, gc_etime = 10033296, prev = 0x994370, next > = 0x0, return_link = 0x0, > all_link = 0x0, prev_stack = 0x9945c0} > (gdb) info threads > * 21 Thread 1241594176 (LWP 20751) 0x000000000067262c in schedule > (initialCapability=, task=0x994370) at > rts/Schedule.c:672 > 20 Thread 1233201472 (LWP 20750) 0x000000000067262c in schedule > (initialCapability=, task=0x9b4930) at > rts/Schedule.c:672 > 19 Thread 1224808768 (LWP 20749) 0x000000000067262c in schedule > (initialCapability=, task=0x9b2df0) at > rts/Schedule.c:672 > 18 Thread 1216416064 (LWP 20748) 0x000000000067262c in schedule > (initialCapability=, task=0x9b12b0) at > rts/Schedule.c:672 > 17 Thread 1208023360 (LWP 20747) 0x000000000067262c in schedule > (initialCapability=, task=0x9af770) at > rts/Schedule.c:672 > 16 Thread 1199630656 (LWP 20746) 0x000000000067262c in schedule > (initialCapability=, task=0x9adc30) at > rts/Schedule.c:672 > 15 Thread 1191237952 (LWP 20745) 0x000000000067262c in schedule > (initialCapability=, task=0x9ac0f0) at > rts/Schedule.c:672 > 14 Thread 1182845248 (LWP 20744) 0x000000000067262c in schedule > (initialCapability=, task=0x9aa5b0) at > rts/Schedule.c:672 > 13 Thread 1174452544 (LWP 20743) 0x000000000067262c in schedule > (initialCapability=, task=0x9a8a70) at > rts/Schedule.c:672 > 12 Thread 1166059840 (LWP 20742) 0x000000000067262c in schedule > (initialCapability=, task=0x9a6f30) at > rts/Schedule.c:672 > 11 Thread 1157667136 (LWP 20741) 0x000000000067262c in schedule > (initialCapability=, task=0x9a53f0) at > rts/Schedule.c:672 > 10 Thread 1149274432 (LWP 20740) 0x000000000067262c in schedule > (initialCapability=, task=0x9a38b0) at > rts/Schedule.c:672 > 9 Thread 1140881728 (LWP 20739) 0x000000000067262c in schedule > (initialCapability=, task=0x9a1d70) at > rts/Schedule.c:672 > 8 Thread 1132489024 (LWP 20738) 0x000000000067262c in schedule > (initialCapability=, task=0x9a0230) at > rts/Schedule.c:672 > 7 Thread 1124096320 (LWP 20737) 0x000000000067262c in schedule > (initialCapability=, task=0x99e6f0) at > rts/Schedule.c:672 > 6 Thread 1115703616 (LWP 20736) 0x000000000067262c in schedule > (initialCapability=, task=0x99cbb0) at > rts/Schedule.c:672 > 5 Thread 1107310912 (LWP 20735) 0x000000000067262c in schedule > (initialCapability=, task=0x99b070) at > rts/Schedule.c:672 > 4 Thread 1098918208 (LWP 20734) 0x000000000067262c in schedule > (initialCapability=, task=0x999530) at > rts/Schedule.c:672 > 3 Thread 1090525504 (LWP 20733) 0x000000000067262c in schedule > (initialCapability=, task=0x9979f0) at > rts/Schedule.c:672 > 2 Thread 1082132800 (LWP 20732) 0x00002aae2fa22548 in > __lll_mutex_lock_wait () from /lib64/libpthread.so.0 > 1 Thread 46927615298704 (LWP 20729) 0x00002aae2fa20553 in > pthread_cond_signal@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > > The values of *task and the thread in which the crash occurs is not > always consistent, but the stacktrace is. For example, another crash... > > (gdb) bt > #0 0x000000000067262c in schedule (initialCapability= out>, task=0x9b4930) at rts/Schedule.c:672 > #1 0x0000000000673205 in workerStart (task=0x9915e0) at > rts/Schedule.c:2033 > #2 0x00002aae0cd1a143 in start_thread () from /lib64/libpthread.so.0 > #3 0x00002aae0ceee8cd in clone () from /lib64/libc.so.6 > #4 0x0000000000000000 in ?? () > (gdb) print *task > $6 = {id = 1233201472, cap = 0x0, stopped = 11791697, suspended_tso = > 0x0, tso = 0x25ed0f1, stat = NoStatus, ret = 0x0, cond = {__data = > {__lock = 1, __futex = 0, > __total_seq = 1, __wakeup_seq = 0, __woken_seq = 0, __mutex = > 0x84e800, __nwaiters = 10033872, __broadcast_seq = 0}, > __size = "\001\000\000\000\000\000\000\000\001", '\0' times>, "?\204\000\000\000\000\000?\032\231\000\000\000\000", __align = > 1}, lock = {__data = {__lock = 0, > __count = 1, __owner = 0, __nusers = 0, __kind = 875, __spins = 0, > __list = {__prev = 0x33a, __next = 0x2da2b}}, > __size = "\000\000\000\000\001", '\0' , > "k\003\000\000\000\000\000\000:\003\000\000\000\000\000\000+?\002\000\000\000\000", > __align = 4294967296}, > wakeup = 186902, elapsedtimestart = 24, muttimestart = 0, mut_time = 0, > mut_etime = 0, gc_time = 0, gc_etime = 10033296, prev = 0x9b4930, next = > 0x0, return_link = 0x0, > all_link = 0x0, prev_stack = 0x9b4b80} > (gdb) info threads > 22 Thread 1249986880 (LWP 20846) 0x00002aae0cd20548 in > __lll_mutex_lock_wait () from /lib64/libpthread.so.0 > 21 Thread 1241594176 (LWP 20845) 0x00002aae0cd1e1c6 in > pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 > * 20 Thread 1233201472 (LWP 20844) 0x000000000067262c in schedule > (initialCapability=, task=0x9b4930) at > rts/Schedule.c:672 > 19 Thread 1224808768 (LWP 20843) 0x000000000067262c in schedule > (initialCapability=, task=0x9b2df0) at > rts/Schedule.c:672 > 18 Thread 1216416064 (LWP 20842) 0x000000000067262c in schedule > (initialCapability=, task=0x9b12b0) at > rts/Schedule.c:672 > 17 Thread 1208023360 (LWP 20841) 0x000000000067262c in schedule > (initialCapability=, task=0x9af770) at > rts/Schedule.c:672 > 16 Thread 1199630656 (LWP 20840) 0x000000000067262c in schedule > (initialCapability=, task=0x9adc30) at > rts/Schedule.c:672 > 15 Thread 1191237952 (LWP 20839) 0x000000000067262c in schedule > (initialCapability=, task=0x9ac0f0) at > rts/Schedule.c:672 > 14 Thread 1182845248 (LWP 20838) 0x000000000067262c in schedule > (initialCapability=, task=0x9aa5b0) at > rts/Schedule.c:672 > 13 Thread 1174452544 (LWP 20837) gcWorkerThread (cap= out>) at includes/SpinLock.h:45 > 12 Thread 1166059840 (LWP 20836) 0x000000000067262c in schedule > (initialCapability=, task=0x9a6f30) at > rts/Schedule.c:672 > 11 Thread 1157667136 (LWP 20835) 0x000000000067262c in schedule > (initialCapability=, task=0x9a53f0) at > rts/Schedule.c:672 > 10 Thread 1149274432 (LWP 20834) 0x000000000067262c in schedule > (initialCapability=, task=0x9a38b0) at > rts/Schedule.c:672 > 9 Thread 1140881728 (LWP 20833) 0x000000000067262c in schedule > (initialCapability=, task=0x9a1d70) at > rts/Schedule.c:672 > 8 Thread 1132489024 (LWP 20832) 0x000000000067262c in schedule > (initialCapability=, task=0x9a0230) at > rts/Schedule.c:672 > 7 Thread 1124096320 (LWP 20831) 0x000000000067262c in schedule > (initialCapability=, task=0x99e6f0) at > rts/Schedule.c:672 > 6 Thread 1115703616 (LWP 20830) 0x000000000067262c in schedule > (initialCapability=, task=0x99cbb0) at > rts/Schedule.c:672 > 5 Thread 1107310912 (LWP 20829) 0x000000000067262c in schedule > (initialCapability=, task=0x99b070) at > rts/Schedule.c:672 > 4 Thread 1098918208 (LWP 20827) 0x000000000067262c in schedule > (initialCapability=, task=0x999530) at > rts/Schedule.c:672 > 3 Thread 1090525504 (LWP 20826) 0x000000000067262c in schedule > (initialCapability=, task=0x9979f0) at > rts/Schedule.c:672 > 2 Thread 1082132800 (LWP 20825) 0x00002aae0cee86e2 in select () from > /lib64/libc.so.6 > 1 Thread 46927031233680 (LWP 20824) 0x00002aae0cd1c2ef in > pthread_mutex_lock () from /lib64/libpthread.so.0 > > valgrind memcheck does not report any errors prior to the NULL deref: > ==20983== Thread 2: > ==20983== Invalid read of size 8 > ==20983== at 0x67262C: schedule (Schedule.c:672) > ==20983== by 0x673204: workerStart (Schedule.c:2033) > ==20983== by 0x58E4142: start_thread (in /lib64/libpthread-2.4.so) > ==20983== by 0x5AB78CC: clone (in /lib64/libc-2.4.so) > ==20983== Address 0x1d0 is not stack'd, malloc'd or (recently) free'd > ==20983== > ==20983== Process terminating with default action of signal 11 (SIGSEGV) > > valgrind helgrind reports numerous possible data race conditions, > including one between schedule and GarbageCollect just prior to the > crash: > ==21106== Possible data race during read of size 8 at 0x5ccc300 by thread > #5 > ==21106== at 0x672612: schedule (Schedule.c:367) > ==21106== by 0x673204: workerStart (Schedule.c:2033) > ==21106== by 0x4A24A1E: mythread_wrapper (hg_intercepts.c:194) > ==21106== by 0x58E7142: start_thread (in /lib64/libpthread-2.4.so) > ==21106== by 0x5ABA8CC: clone (in /lib64/libc-2.4.so) > ==21106== This conflicts with a previous write of size 8 by thread #1 > ==21106== at 0x679B8D: GarbageCollect (SpinLock.h:55) > ==21106== by 0x6712D0: scheduleDoGC (Schedule.c:1522) > ==21106== by 0x672C77: schedule (Schedule.c:621) > ==21106== by 0x66FF84: real_main (RtsMain.c:68) > ==21106== by 0x67009D: hs_main (RtsMain.c:117) > ==21106== by 0x5A17183: (below main) (in /lib64/libc-2.4.so) > > I am still working on whether I can make a small program to reproduce > this. New description: Using ghc and runtime built from HEAD on Tuesday (although this has been an issue on older builds I tried as well), the ghc runtime crashes on a null deref. The system is a 24-processor Intel Xeon 2.66 GHz shared memory system running Linux 2.6.16.60-0.34-smp in 64 bit mode (from SUSE 10 SP2). This only happens when the program is compiled with -threaded (threaded runtime), but doesn't happen with the threaded debug runtime. It also only happens when +RTS -N2 or a greater number of threads is passed to the runtime. It doesn't happen when -g1 is passed to turn off distributed garbage collection. {{{ Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1241594176 (LWP 20751)] 0x000000000067262c in schedule (initialCapability=, task=0x994370) at rts/Schedule.c:672 672 return (waiting_for_gc || (gdb) list 667 // - another thread is initiating a GC 668 // - another Task is returning from a foreign call 669 // - the thread at the head of the run queue cannot be run 670 // by this Task (it is bound to another Task, or it is unbound 671 // and this task it bound). 672 return (waiting_for_gc || 673 cap->returning_tasks_hd != NULL || 674 (!emptyRunQueue(cap) && (task->tso == NULL 675 ? cap->run_queue_hd->bound != NULL 676 : cap->run_queue_hd->bound != task))); (gdb) print cap $1 = (Capability *) 0x0 (gdb) print *task $2 = {id = 1241594176, cap = 0x0, stopped = 7160552, suspended_tso = 0x0, tso = 0x7fccc4, stat = NoStatus, ret = 0x0, cond = {__data = {__lock = 1, __futex = 0, __total_seq = 1, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x84e340, __nwaiters = 10033872, __broadcast_seq = 0}, __size = "\001\000\000\000\000\000\000\000\001", '\0' , "@?\204\000\000\000\000\000?\032\231\000\000\000\000", __align = 1}, lock = {__data = { __lock = 0, __count = 1, __owner = 0, __nusers = 0, __kind = 22668, __spins = 0, __list = {__prev = 0x5793, __next = 0x85afd}}, __size = "\000\000\000\000\001", '\0' , "\214X\000\000\000\000\000\000\223W\000\000\000\000\000\000?Z\b\000\000\000\000", __align = 4294967296}, wakeup = 547420, elapsedtimestart = 202, muttimestart = 0, mut_time = 0, mut_etime = 0, gc_time = 0, gc_etime = 10033296, prev = 0x994370, next = 0x0, return_link = 0x0, all_link = 0x0, prev_stack = 0x9945c0} (gdb) info threads * 21 Thread 1241594176 (LWP 20751) 0x000000000067262c in schedule (initialCapability=, task=0x994370) at rts/Schedule.c:672 20 Thread 1233201472 (LWP 20750) 0x000000000067262c in schedule (initialCapability=, task=0x9b4930) at rts/Schedule.c:672 19 Thread 1224808768 (LWP 20749) 0x000000000067262c in schedule (initialCapability=, task=0x9b2df0) at rts/Schedule.c:672 18 Thread 1216416064 (LWP 20748) 0x000000000067262c in schedule (initialCapability=, task=0x9b12b0) at rts/Schedule.c:672 17 Thread 1208023360 (LWP 20747) 0x000000000067262c in schedule (initialCapability=, task=0x9af770) at rts/Schedule.c:672 16 Thread 1199630656 (LWP 20746) 0x000000000067262c in schedule (initialCapability=, task=0x9adc30) at rts/Schedule.c:672 15 Thread 1191237952 (LWP 20745) 0x000000000067262c in schedule (initialCapability=, task=0x9ac0f0) at rts/Schedule.c:672 14 Thread 1182845248 (LWP 20744) 0x000000000067262c in schedule (initialCapability=, task=0x9aa5b0) at rts/Schedule.c:672 13 Thread 1174452544 (LWP 20743) 0x000000000067262c in schedule (initialCapability=, task=0x9a8a70) at rts/Schedule.c:672 12 Thread 1166059840 (LWP 20742) 0x000000000067262c in schedule (initialCapability=, task=0x9a6f30) at rts/Schedule.c:672 11 Thread 1157667136 (LWP 20741) 0x000000000067262c in schedule (initialCapability=, task=0x9a53f0) at rts/Schedule.c:672 10 Thread 1149274432 (LWP 20740) 0x000000000067262c in schedule (initialCapability=, task=0x9a38b0) at rts/Schedule.c:672 9 Thread 1140881728 (LWP 20739) 0x000000000067262c in schedule (initialCapability=, task=0x9a1d70) at rts/Schedule.c:672 8 Thread 1132489024 (LWP 20738) 0x000000000067262c in schedule (initialCapability=, task=0x9a0230) at rts/Schedule.c:672 7 Thread 1124096320 (LWP 20737) 0x000000000067262c in schedule (initialCapability=, task=0x99e6f0) at rts/Schedule.c:672 6 Thread 1115703616 (LWP 20736) 0x000000000067262c in schedule (initialCapability=, task=0x99cbb0) at rts/Schedule.c:672 5 Thread 1107310912 (LWP 20735) 0x000000000067262c in schedule (initialCapability=, task=0x99b070) at rts/Schedule.c:672 4 Thread 1098918208 (LWP 20734) 0x000000000067262c in schedule (initialCapability=, task=0x999530) at rts/Schedule.c:672 3 Thread 1090525504 (LWP 20733) 0x000000000067262c in schedule (initialCapability=, task=0x9979f0) at rts/Schedule.c:672 2 Thread 1082132800 (LWP 20732) 0x00002aae2fa22548 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 1 Thread 46927615298704 (LWP 20729) 0x00002aae2fa20553 in pthread_cond_signal@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 }}} The values of *task and the thread in which the crash occurs is not always consistent, but the stacktrace is. For example, another crash... {{{ (gdb) bt #0 0x000000000067262c in schedule (initialCapability=, task=0x9b4930) at rts/Schedule.c:672 #1 0x0000000000673205 in workerStart (task=0x9915e0) at rts/Schedule.c:2033 #2 0x00002aae0cd1a143 in start_thread () from /lib64/libpthread.so.0 #3 0x00002aae0ceee8cd in clone () from /lib64/libc.so.6 #4 0x0000000000000000 in ?? () (gdb) print *task $6 = {id = 1233201472, cap = 0x0, stopped = 11791697, suspended_tso = 0x0, tso = 0x25ed0f1, stat = NoStatus, ret = 0x0, cond = {__data = {__lock = 1, __futex = 0, __total_seq = 1, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x84e800, __nwaiters = 10033872, __broadcast_seq = 0}, __size = "\001\000\000\000\000\000\000\000\001", '\0' , "?\204\000\000\000\000\000?\032\231\000\000\000\000", __align = 1}, lock = {__data = {__lock = 0, __count = 1, __owner = 0, __nusers = 0, __kind = 875, __spins = 0, __list = {__prev = 0x33a, __next = 0x2da2b}}, __size = "\000\000\000\000\001", '\0' , "k\003\000\000\000\000\000\000:\003\000\000\000\000\000\000+?\002\000\000\000\000", __align = 4294967296}, wakeup = 186902, elapsedtimestart = 24, muttimestart = 0, mut_time = 0, mut_etime = 0, gc_time = 0, gc_etime = 10033296, prev = 0x9b4930, next = 0x0, return_link = 0x0, all_link = 0x0, prev_stack = 0x9b4b80} (gdb) info threads 22 Thread 1249986880 (LWP 20846) 0x00002aae0cd20548 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 21 Thread 1241594176 (LWP 20845) 0x00002aae0cd1e1c6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 * 20 Thread 1233201472 (LWP 20844) 0x000000000067262c in schedule (initialCapability=, task=0x9b4930) at rts/Schedule.c:672 19 Thread 1224808768 (LWP 20843) 0x000000000067262c in schedule (initialCapability=, task=0x9b2df0) at rts/Schedule.c:672 18 Thread 1216416064 (LWP 20842) 0x000000000067262c in schedule (initialCapability=, task=0x9b12b0) at rts/Schedule.c:672 17 Thread 1208023360 (LWP 20841) 0x000000000067262c in schedule (initialCapability=, task=0x9af770) at rts/Schedule.c:672 16 Thread 1199630656 (LWP 20840) 0x000000000067262c in schedule (initialCapability=, task=0x9adc30) at rts/Schedule.c:672 15 Thread 1191237952 (LWP 20839) 0x000000000067262c in schedule (initialCapability=, task=0x9ac0f0) at rts/Schedule.c:672 14 Thread 1182845248 (LWP 20838) 0x000000000067262c in schedule (initialCapability=, task=0x9aa5b0) at rts/Schedule.c:672 13 Thread 1174452544 (LWP 20837) gcWorkerThread (cap=) at includes/SpinLock.h:45 12 Thread 1166059840 (LWP 20836) 0x000000000067262c in schedule (initialCapability=, task=0x9a6f30) at rts/Schedule.c:672 11 Thread 1157667136 (LWP 20835) 0x000000000067262c in schedule (initialCapability=, task=0x9a53f0) at rts/Schedule.c:672 10 Thread 1149274432 (LWP 20834) 0x000000000067262c in schedule (initialCapability=, task=0x9a38b0) at rts/Schedule.c:672 9 Thread 1140881728 (LWP 20833) 0x000000000067262c in schedule (initialCapability=, task=0x9a1d70) at rts/Schedule.c:672 8 Thread 1132489024 (LWP 20832) 0x000000000067262c in schedule (initialCapability=, task=0x9a0230) at rts/Schedule.c:672 7 Thread 1124096320 (LWP 20831) 0x000000000067262c in schedule (initialCapability=, task=0x99e6f0) at rts/Schedule.c:672 6 Thread 1115703616 (LWP 20830) 0x000000000067262c in schedule (initialCapability=, task=0x99cbb0) at rts/Schedule.c:672 5 Thread 1107310912 (LWP 20829) 0x000000000067262c in schedule (initialCapability=, task=0x99b070) at rts/Schedule.c:672 4 Thread 1098918208 (LWP 20827) 0x000000000067262c in schedule (initialCapability=, task=0x999530) at rts/Schedule.c:672 3 Thread 1090525504 (LWP 20826) 0x000000000067262c in schedule (initialCapability=, task=0x9979f0) at rts/Schedule.c:672 2 Thread 1082132800 (LWP 20825) 0x00002aae0cee86e2 in select () from /lib64/libc.so.6 1 Thread 46927031233680 (LWP 20824) 0x00002aae0cd1c2ef in pthread_mutex_lock () from /lib64/libpthread.so.0 }}} valgrind memcheck does not report any errors prior to the NULL deref: {{{ ==20983== Thread 2: ==20983== Invalid read of size 8 ==20983== at 0x67262C: schedule (Schedule.c:672) ==20983== by 0x673204: workerStart (Schedule.c:2033) ==20983== by 0x58E4142: start_thread (in /lib64/libpthread-2.4.so) ==20983== by 0x5AB78CC: clone (in /lib64/libc-2.4.so) ==20983== Address 0x1d0 is not stack'd, malloc'd or (recently) free'd ==20983== ==20983== Process terminating with default action of signal 11 (SIGSEGV) }}} valgrind helgrind reports numerous possible data race conditions, including one between schedule and GarbageCollect just prior to the crash: {{{ ==21106== Possible data race during read of size 8 at 0x5ccc300 by thread #5 ==21106== at 0x672612: schedule (Schedule.c:367) ==21106== by 0x673204: workerStart (Schedule.c:2033) ==21106== by 0x4A24A1E: mythread_wrapper (hg_intercepts.c:194) ==21106== by 0x58E7142: start_thread (in /lib64/libpthread-2.4.so) ==21106== by 0x5ABA8CC: clone (in /lib64/libc-2.4.so) ==21106== This conflicts with a previous write of size 8 by thread #1 ==21106== at 0x679B8D: GarbageCollect (SpinLock.h:55) ==21106== by 0x6712D0: scheduleDoGC (Schedule.c:1522) ==21106== by 0x672C77: schedule (Schedule.c:621) ==21106== by 0x66FF84: real_main (RtsMain.c:68) ==21106== by 0x67009D: hs_main (RtsMain.c:117) ==21106== by 0x5A17183: (below main) (in /lib64/libc-2.4.so) }}} I am still working on whether I can make a small program to reproduce this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 11 10:39:49 2009 From: trac at galois.com (GHC) Date: Thu Jun 11 10:23:29 2009 Subject: [GHC] #3291: "Thread blocked indefinitely" kills the program despite being caught In-Reply-To: <053.fb53b1fc888659080c438c349e98c0a5@localhost> References: <053.fb53b1fc888659080c438c349e98c0a5@localhost> Message-ID: <062.cbab79aa42b6c8e8c0d5e834688c6d3d@localhost> #3291: "Thread blocked indefinitely" kills the program despite being caught ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.10.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => invalid Old description: > Perhaps this is just me misunderstanding the semantics of exceptions, but > the following program: > > """ > import Test.HUnit.Lang > import Control.Concurrent.STM > > import Control.Exception > > import Control.Concurrent > import Control.Concurrent.MVar > > main = do > mv <- newEmptyMVar > forkIO $ do > r <- performTestCase (atomically retry) > print "Yeaahh!" > print r > evaluate r > putMVar mv r > print "Cool, let's see what we get" > r <- takeMVar mv > print r > print "Am I printed?" > """ > > Should in my opinion, when run, print "Am I printed". This is because the > "Thread blocked indefinitely" exception is caught by HUnit. However, this > happens instead: > > """ > mbolingbroke@mb566 ~/Junk > $ ./Repro > "Cool, let's see what we get" > "Yeaahh!" > Just (False,"thread blocked indefinitely") > Repro: thread blocked indefinitely > """ > > NB: I get the expected behaviour if I run it within GHCi, but not if I > compile the program. > > This is causing problems for test-framework (see > http://bsp.lighthouseapp.com/projects/15661-hs-test-framework/tickets/1 > -exits-immediately-on-thread-blocked-indefinitely-exception#ticket-1-2) New description: Perhaps this is just me misunderstanding the semantics of exceptions, but the following program: {{{ import Test.HUnit.Lang import Control.Concurrent.STM import Control.Exception import Control.Concurrent import Control.Concurrent.MVar main = do mv <- newEmptyMVar forkIO $ do r <- performTestCase (atomically retry) print "Yeaahh!" print r evaluate r putMVar mv r print "Cool, let's see what we get" r <- takeMVar mv print r print "Am I printed?" }}} Should in my opinion, when run, print "Am I printed". This is because the "Thread blocked indefinitely" exception is caught by HUnit. However, this happens instead: {{{ mbolingbroke@mb566 ~/Junk $ ./Repro "Cool, let's see what we get" "Yeaahh!" Just (False,"thread blocked indefinitely") Repro: thread blocked indefinitely }}} NB: I get the expected behaviour if I run it within GHCi, but not if I compile the program. This is causing problems for test-framework (see http://bsp.lighthouseapp.com/projects/15661-hs-test-framework/tickets/1 -exits-immediately-on-thread-blocked-indefinitely-exception#ticket-1-2) Comment: The GC determines which threads are blocked indefinitely: those that are unreachable from any root can never be woken up. So what's happening here is that when the forkIO'd thread becomes unreachable, the main thread is also unreachable. Both threads therefore get BlockedIndefinitely exceptions. If you want the main thread to stay alive, you can add a {{{ myThreadId >>= newStablePtr }}} to `main`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 11 10:42:18 2009 From: trac at galois.com (GHC) Date: Thu Jun 11 10:25:59 2009 Subject: [GHC] #3296: mention also -RTS after stack overflow Message-ID: <045.b258499c759b06282a80550677967359@localhost> #3296: mention also -RTS after stack overflow -----------------------------+---------------------------------------------- Reporter: maeder | Owner: Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 6.10.3 | Severity: trivial Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- a stack overflow is shown as follows: {{{ Stack space overflow: current size 8388608 bytes. Use `+RTS -Ksize' to increase it. }}} Maybe the usage message for the RTS option can be improved wrt putting this option last or using -RTS -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 11 10:44:54 2009 From: trac at galois.com (GHC) Date: Thu Jun 11 10:28:28 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.a2efedbe74657844f23100b9ec015fbb@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): Replying to [comment:11 zooko]: > If the memory usage continues to grow when a substantially similar task is being performed over and over, then this is a memory leak. That's a separate issue from returning memory to the OS. Exactly. If anyone can demonstrate a leak, please create a separate ticket. > Personally I don't think returning memory to the OS is worth the effort. The OS will swap it out anyway when it is unused. (Hint: never look at the "virtual memory size" on linux. It is a useless and misleading number -- it doesn't correlate with anything that we actually care about.) Which is why it hasn't been addressed so far. But there are people who still care about the absolute virtual size of their processes - perhaps because they want to avoid the swapping, or maybe just because they don't like seeing huge processes in `top`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 11 20:49:52 2009 From: trac at galois.com (GHC) Date: Thu Jun 11 20:34:22 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.fd42a945ff7d4044d4a0df37ffcdbcf9@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 | ----------------------------------------+----------------------------------- Comment (by SamB): Okay, it seems to me that in order to solve this problem, GHC needs to be able to prove, somehow or other, that each method to be derived can be safely converted from the one type to the other. Correct? And the main choice here is whether it should A. try to do this on it's own, and prove that it can just cast between the one and the other or B. require the user to explicitly provide Functor, BiFunctor, etc. instances for GHC to use during this process, yes? Probably it is best to take an approach that we can be sure is safe without too many aspirins, and use approach B, but have GHC issue a warning whenever it is unable to optimize away the coercions for some of the methods, and therefore unable to re-use the dictionary. The rules for the derivation itself should preferably be written up in a paper so that the other compilers, too, can benefit from this extremely convenient feature, though doubtless it will become somewhat less convenient in some ways if this bug is fixed. For this approach to work well with multi-parameter types, however, we'd presumably need to add a lot more Functor-related classes to base, would we not? But which ones? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 11 21:57:57 2009 From: trac at galois.com (GHC) Date: Thu Jun 11 21:41:46 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.216a4ee5fc80dce5653d59e77dd2f786@localhost> #3137: ghc 6.10.2 fails to compile on Mac OS X Leopard ---------------------------------+------------------------------------------ Reporter: mvanier | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by mvanier): ghc HEAD does indeed compile now on Mac OS X Leopard (from the command line; I haven't tested it with XCode). This was just the ghc core without the extra libraries, which I'll try next. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 12 08:30:08 2009 From: trac at galois.com (GHC) Date: Fri Jun 12 08:13:40 2009 Subject: [GHC] #3276: FilePath.addTrailingPathSeparator "" = "/" In-Reply-To: <045.c94373ccfee4669a603a10ee0b36cb4d@localhost> References: <045.c94373ccfee4669a603a10ee0b36cb4d@localhost> Message-ID: <054.9075ca2e844f2f25926700f07d48450c@localhost> #3276: FilePath.addTrailingPathSeparator "" = "/" ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: bug | 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 simonmar): Yes, the point is that if you're using "" to mean ".", then that's wrong. It's only System.FilePath that has this behaviour, the OS interface doesn't (try `changeCurrentDirectory ""`). I suppose to avoid breakage we could just make System.FilePath accept "" as it currently does, giving it the same meaning as ".", but it would never yield "" as a directory name. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 12 09:43:03 2009 From: trac at galois.com (GHC) Date: Fri Jun 12 09:26:35 2009 Subject: [GHC] #3297: Compiler panic on incorrect code (TcTyFuns.flattenType: synonym family in a rank-n type) Message-ID: <048.6b2e6afb6975be0e0c389f8b6c47df0c@localhost> #3297: Compiler panic on incorrect code (TcTyFuns.flattenType: synonym family in a rank-n type) ----------------------+----------------------------------------------------- Reporter: hesselink | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 ----------------------+----------------------------------------------------- On the following code sample the compiler panics with: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.11.20090403 for i386-unknown-linux): TcTyFuns.flattenType: synonym family in a rank-n type }}} I found this when working on some code when I made a mistake; the code should not type check, but should probably not crash the compiler either. I simplified the code to: {{{ {-# LANGUAGE TypeFamilies , KindSignatures , RankNTypes #-} type family PF a :: (* -> *) -> * -> * class Ix a where type Es a :: * -> * from :: a -> PF a (Es a) a crash :: (forall n. Es a n) -> a crash = from }}} It seems similar to #3101, but that one was about data types. A similar example also seems to be in #1897, but this bug doesn't seem to fit that ticket's description. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 12 17:07:59 2009 From: trac at galois.com (GHC) Date: Fri Jun 12 16:51:29 2009 Subject: [GHC] #3298: Add swap to Data.Tuple Message-ID: <041.b0c2cdf17e67a092210f2327e17cca5e@localhost> #3298: Add swap to Data.Tuple -----------------------------+---------------------------------------------- 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 think swap is a widely accepted name for the function. There is only the question of strictness. I suggest swap for the lazy version and swap' for the strict version swap ~(a,b) = (b,a) swap' (a,b) = (b,a) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 13 13:27:28 2009 From: trac at galois.com (GHC) Date: Sat Jun 13 13:10:55 2009 Subject: [GHC] #3299: Error building HEAD on OS X: missing gmp.h Message-ID: <044.32b6ebaa96b6830af3d57ca8d51e4a7b@localhost> #3299: Error building HEAD on OS X: missing gmp.h --------------------+------------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- I got a fresh tree from darcs of ghc+libraries, ran `./configure` and `make`. Make failed with the following error: {{{ "inplace/bin/mkdependC" -f libraries/integer-gmp/dist- install/build/.depend-v.tmp -- -O -g -O2 -Ilibraries/integer-gmp/. -I/Users/judah/Programming/dontbackup/ghc/includes -I/Users/judah/Programming/dontbackup/ghc/libffi/build/include -- libraries/integer-gmp/cbits/float.c || ( "rm" -f libraries/integer-gmp /dist-install/build/.depend-v; exit 1 ) libraries/integer-gmp/cbits/float.c:13:17: error: gmp.h: No such file or directory libraries/integer-gmp/cbits/float.c:13:17: error: gmp.h: No such file or directory }}} Actually, this error did not cause the build to stop, but it was the earliest that I could find in the log (attached). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 13 18:17:55 2009 From: trac at galois.com (GHC) Date: Sat Jun 13 18:01:23 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.7d566e997b995e7e1fd878135a543eb1@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 | -------------------------+-------------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.12.1 Comment: Thanks for the report. I'll sort this out when applying the Integer/gmp patches from Duncan. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 13 20:45:00 2009 From: trac at galois.com (GHC) Date: Sat Jun 13 20:28:26 2009 Subject: [GHC] #3300: System.Directory.getDirectoryContents not unicode-aware under Windows Message-ID: <042.70f85210b7c6f2f297e9bed1b5b08002@localhost> #3300: System.Directory.getDirectoryContents not unicode-aware under Windows -----------------------------+---------------------------------------------- Reporter: shu | Owner: Type: bug | Status: new Priority: normal | Component: libraries/directory Version: 6.10.3 | Severity: major Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Under Windows, System.Directory.getDirectoryContents seems to apply encoding conversions on filenames at the syscall level. I have several files with Japanese names, but my default program locale is English. Unicode-aware applications (that is, most modern Windows programs) have no problems with this. Calling getDirectoryContents on a folder with Japanese names, however, returns strings consisted of question marks "???". If I switch the default program locale to, say, Japanese, then the files are returned in ShiftJIS, but I lose information such as accented Latin characters. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 13 21:03:19 2009 From: trac at galois.com (GHC) Date: Sat Jun 13 20:46:44 2009 Subject: [GHC] #3298: Add swap to Data.Tuple In-Reply-To: <041.b0c2cdf17e67a092210f2327e17cca5e@localhost> References: <041.b0c2cdf17e67a092210f2327e17cca5e@localhost> Message-ID: <050.9ab32f45129f4509965bf7fa75cdfa2b@localhost> #3298: Add swap to Data.Tuple ------------------------------+--------------------------------------------- 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 YitzGale): I would usually spell this {{{ swap = uncurry $ flip (,) }}} That supports your choice of the lazy version as unprimed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 13 21:24:08 2009 From: trac at galois.com (GHC) Date: Sat Jun 13 21:08:32 2009 Subject: [GHC] #3275: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> References: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> Message-ID: <055.4f69a21cd7fe3313b8a92288100c7dc9@localhost> #3275: ghc: panic! (the 'impossible' happened) -------------------------+-------------------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by EricKow): Success! Here's the smallest I can get it {{{ {-# OPTIONS_GHC -O2 #-} module Foo where import Text.Regex ( matchRegex ) import Data.Maybe ( isJust ) foo :: IO (FilePath -> FilePath) foo = do regexes <- return undefined let isbin f = or $ map (\r -> isJust $ matchRegex r f) regexes ftf f = if isbin f then undefined else undefined return ftf }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 14 01:02:22 2009 From: trac at galois.com (GHC) Date: Sun Jun 14 00:46:11 2009 Subject: [GHC] #3301: Update Haskeline Message-ID: <042.39eb2fb65f452fed35078da0d81f6675@localhost> #3301: Update Haskeline -----------------------------+---------------------------------------------- Reporter: cjs | Owner: Type: merge | Status: new Priority: normal | Component: GHCi Version: 6.10.3 | Severity: major Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- GHC 6.10.3 switched from readline/editline to [http://trac.haskell.org/haskeline Haskeline] as the command-line editor in ghci. Unfortunately, this lost a lot of the vi-mode editing functionality, as the version of Haskeline ghci uses had very limited support for vi mode. This support has been improving quickly in Haskeline's trunk, thanks to vi-mode users using the release and submitting bug reports. When the next version of GHC is released, a new release of Haskeline with all of these updates should be cut, and incorporated into GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 14 01:22:21 2009 From: trac at galois.com (GHC) Date: Sun Jun 14 01:06:09 2009 Subject: [GHC] #3302: Where-clause environments for GHCi Message-ID: <042.5c0ec265d0b74126ec10ff4afe70b130@localhost> #3302: Where-clause environments for GHCi -----------------------------+---------------------------------------------- Reporter: cjs | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Often in ghci I'd like to interactively debug and play with functions in the `where` clause of a top-level definition. Currently, this requires one to change the code, lifting the definitions in question to the top level and adding appropriate parameters. Given a definition such as {{{ top :: Int -> Int top x = mult 4 - mult 3 + mult 2 where mult n = x * n }}} it would be nice to type something such as `:environment top 2` to put me in an envrionment where `mult` is available and `mult 4` will evaluate to `8`. (Obviously this becomes more useful with more complex definitions.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 14 08:44:16 2009 From: trac at galois.com (GHC) Date: Sun Jun 14 08:28:44 2009 Subject: [GHC] #3275: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> References: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> Message-ID: <055.4291e9a374a3884f32a8e7c3d9988b72@localhost> #3275: ghc: panic! (the 'impossible' happened) -------------------------+-------------------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by igloo): Great stuff, thanks Eric! I can now reproduce this: {{{ {-# OPTIONS_GHC -O2 #-} module Foo where import Text.Regex isJust :: Maybe a -> Bool isJust (Just _) = True isJust Nothing = False foo :: IO (FilePath -> FilePath) foo = do regexes <- return undefined let isbin f = or $ map (\r -> isJust $ matchRegex r f) regexes ftf f = if isbin f then undefined else undefined return ftf }}} {{{ $ ghc --make q [1 of 1] Compiling Foo ( q.hs, q.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-apple-darwin): cat_evals base:GHC.Arr.Array{d rfk} [ww{v aLo} [lid], ww1{v aLp} [lid], ww2{v aLq} [lid]] [!, !, _, _] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It looks like despite the installer failing, I'm still getting `regex- compat` from `/Library/Frameworks/HaskellPlatform.framework`. There is also a copy in `/Library/Frameworks/GHC.framework`. Core lint says: {{{ $ ghc --make q -dcore-lint [1 of 1] Compiling Foo ( q.hs, q.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-apple-darwin): Iface Lint failure Unfolding of regex-compat-0.71.0.1:Text.Regex.matchRegex{v r3n} : In a case alternative: (base:Data.Maybe.Nothing{d r8}) In a case alternative, data constructor isn't in scrutinee type: Scrutinee type constructor: ghc-prim:GHC.Types.[]{(w) tc 317} Data con: base:Data.Maybe.Nothing{d r8} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} In {{{ ghc --show-iface /Library/Frameworks/HaskellPlatform.framework/lib/regex- compat-0.71.0.1/ghc-6.10.3/Text/Regex.hi }}} is {{{ 3170b173e0108c4d0f4e4a6c458e962b matchRegex :: Text.Regex.Posix.Wrap.Regex -> GHC.Base.String -> Data.Maybe.Maybe [GHC.Base.String] {- Arity: 2 Strictness: LL Unfolding: (\ p :: Text.Regex.Posix.Wrap.Regex str :: GHC.Base.String -> case @ (Data.Maybe.Maybe [GHC.Base.String]) Text.Regex.Posix.String.a4 p str of wild { Data.Maybe.Nothing -> Data.Maybe.Nothing @ [GHC.Base.String] Data.Maybe.Just preMApost -> Data.Maybe.Just @ [GHC.Base.String] (case @ [[GHC.Types.Char]] preMApost of w { (ww, ww1, ww2) -> case @ [[GHC.Types.Char]] Text.Regex.Base.Context.$wlvl3 @ [GHC.Types.Char] ww ww1 ww2 of ww3 { (# ww4, ww5, ww6, ww7 #) -> ww7 } }) }) -} 5497cf2d6b99de31ced55bda7d2a1265 }}} In {{{ ghc --show-iface /Library/Frameworks/HaskellPlatform.framework/lib/regex- posix-0.72.0.3/ghc-6.10.3/Text/Regex/Posix/String.hi }}} is {{{ 270f3a6a066ef52e8035aeae31f61c08 a4 :: Text.Regex.Posix.Wrap.Regex -> GHC.Base.String -> [Text.Regex.Base.RegexLike.MatchText GHC.Base.String] {- Arity: 2 Strictness: LL -} cd1e8839869c9407d5b2d1f9af8a4d06 }}} In {{{ ghc --show-iface /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.3/regex- posix-0.72.0.3/Text/Regex/Posix/String.hi }}} is {{{ 340c19d7034daffc230c61fd7b7524a7 a4 :: Text.Regex.Posix.Wrap.Regex -> GHC.Base.String -> Data.Maybe.Maybe (GHC.Base.String, Text.Regex.Base.RegexLike.MatchText GHC.Base.String, GHC.Base.String) {- Arity: 2 Strictness: LL -} 57f7a827fcdc372c03316de2b8a05865 }}} so it looks like the problem is that `regex-compat` got built against the `regex-posix` that comes with GHC rather than the one that comes with the Haskell platform. So, two questions: Why did this happen? Isn't the fingerprinting meant to catch this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 14 13:42:30 2009 From: trac at galois.com (GHC) Date: Sun Jun 14 13:26:18 2009 Subject: [GHC] #3302: Where-clause environments for GHCi In-Reply-To: <042.5c0ec265d0b74126ec10ff4afe70b130@localhost> References: <042.5c0ec265d0b74126ec10ff4afe70b130@localhost> Message-ID: <051.fce6763d105d4719ae7e6c18e219d33a@localhost> #3302: Where-clause environments for GHCi ------------------------------+--------------------------------------------- Reporter: cjs | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by dherington): It seems what you want is already provided (unless I misunderstand): bash-3.2$ cat Test.hs top :: Int -> Int top x = mult 4 - mult 3 + mult 2 where mult n = x * n bash-3.2$ ghci Test.hs 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 ( Test.hs, interpreted ) Ok, modules loaded: Main. *Main> :step top 2 Stopped at Test.hs:(2,0)-(4,21) _result :: Int = _ [Test.hs:(2,0)-(4,21)] *Main> :step Stopped at Test.hs:2:8-31 _result :: Int = _ mult :: Int -> Int = _ [Test.hs:2:8-31] *Main> mult 4 8 [Test.hs:2:8-31] *Main> -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 14 13:44:35 2009 From: trac at galois.com (GHC) Date: Sun Jun 14 13:28:13 2009 Subject: [GHC] #3302: Where-clause environments for GHCi In-Reply-To: <042.5c0ec265d0b74126ec10ff4afe70b130@localhost> References: <042.5c0ec265d0b74126ec10ff4afe70b130@localhost> Message-ID: <051.5cb76e980b7c24ae94ad84422e97d7d9@localhost> #3302: Where-clause environments for GHCi ------------------------------+--------------------------------------------- Reporter: cjs | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by dherington): (Sorry, I'm new to Trac and botched the formatting. Trying again...) {{{ bash-3.2$ cat Test.hs top :: Int -> Int top x = mult 4 - mult 3 + mult 2 where mult n = x * n bash-3.2$ ghci Test.hs 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 ( Test.hs, interpreted ) Ok, modules loaded: Main. *Main> :step top 2 Stopped at Test.hs:(2,0)-(4,21) _result :: Int = _ [Test.hs:(2,0)-(4,21)] *Main> :step Stopped at Test.hs:2:8-31 _result :: Int = _ mult :: Int -> Int = _ [Test.hs:2:8-31] *Main> mult 4 8 [Test.hs:2:8-31] *Main> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 14 17:53:13 2009 From: trac at galois.com (GHC) Date: Sun Jun 14 17:36:35 2009 Subject: [GHC] #3303: Allow multi-line deprecation messages. Message-ID: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> #3303: Allow multi-line deprecation messages. -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Sometimes one line just isn't enough. There's two related issues, pretty source code and pretty warning messages. It is a bit annoying when a `DEPRECATED` pragma stretches on past 80-100 columns or whatever. Does the ordinary multi-line Haskell string syntax work in this situation? Even if it does it's not useful in practice due to the cpp-incompatibility, and because it's a pragma, we cannot use the normal `++` trick. The other is presenting multi-line error messages to the user. Sometimes we want to present more info, like not just what the alternative is but for example when the alternative was added and when the deprecated thing will be removed. In Cabal for example we've got ugly hack: {{{ {-# DEPRECATED defaultUserHooks "Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2\n compatibility in which case you must stick with defaultUserHooks" #-} }}} Yes it's really that wide :-) Reformatted: {{{ {-# DEPRECATED defaultUserHooks "Use simpleUserHooks or autoconfUserHooks, unless you \ need Cabal-1.2\n compatibility in which \ case you must stick with defaultUserHooks" #-} }}} Note the silly `"\n "` to make the multi-line message line up ok in current ghc versions. To allow embedded '\n' more sensibly, it just needs a slight tweak in the rendering. Split the message into lines and then use `hsep` or equivalent. That way we get correct indenting for free. I'm not sure how long single-line messages get printed, but Cabal solves this problem for its error messages by re-wrapping text, though it also respects embedded newlines (to force line breaks or paragraph breaks). {{{ -- | Wraps text to the default line width. Existing newlines are preserved. wrapText :: String -> String wrapText = unlines . concatMap (map unwords . wrapLine 79 . words) . lines -- | Wraps a list of words to a list of lines of words of a particular width. wrapLine :: Int -> [String] -> [[String]] wrapLine width = wrap 0 [] where wrap :: Int -> [String] -> [String] -> [[String]] wrap 0 [] (w:ws) | length w + 1 > width = wrap (length w) [w] ws wrap col line (w:ws) | col + length w + 1 > width = reverse line : wrap 0 [] (w:ws) wrap col line (w:ws) = let col' = col + length w + 1 in wrap col' (w:line) ws wrap _ [] [] = [] wrap _ line [] = [reverse line] }}} There's also a more sophisticated version of this using the `Doc` type in the gtk2hs code gen utils. It has a parameter for the line width and handles prefix text on the first line. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 14 19:08:08 2009 From: trac at galois.com (GHC) Date: Sun Jun 14 18:51:32 2009 Subject: [GHC] #3293: Implement shiftLInteger and shiftRInteger In-Reply-To: <044.df0bc2082d2b67a740bace217a62079f@localhost> References: <044.df0bc2082d2b67a740bace217a62079f@localhost> Message-ID: <053.d0efaeafbf2ef392afbdb18b192d9787@localhost> #3293: Implement shiftLInteger and shiftRInteger ---------------------------------+------------------------------------------ Reporter: igloo | Owner: 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 | ---------------------------------+------------------------------------------ Comment (by igloo): Also, `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 Sun Jun 14 21:17:06 2009 From: trac at galois.com (GHC) Date: Sun Jun 14 21:00:30 2009 Subject: [GHC] #3304: define gcd 0 0 = 0 Message-ID: <045.185c8414dc74a05b9b8c81a6506a335e@localhost> #3304: define gcd 0 0 = 0 -----------------------------+---------------------------------------------- Reporter: stevec | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Please make any comments on the libraries list by Tuesday 15th September 2009. A suggestion to change 'gcd 0 0' from[[BR]] gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined"[[BR]] to[[BR]] gcd 0 0 = 0 The proposal has been discussed on haskell-cafe@haskell.org http://www.haskell.org/pipermail/haskell-cafe/2009-May/060788.html and there was a lot of support for the suggested change. Current code: libraries/base/GHC/Real.lhs {{{ -- | @'gcd' x y@ is the greatest (positive) integer that divides both @x@ -- and @y@; for example @'gcd' (-3) 6@ = @3@, @'gcd' (-3) (-6)@ = @3@, -- @'gcd' 0 4@ = @4@. @'gcd' 0 0@ raises a runtime error. gcd :: (Integral a) => a -> a -> a gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined" gcd x y = gcd' (abs x) (abs y) where gcd' a 0 = a gcd' a b = gcd' b (a `rem` b) }}} Suggested code: {{{ -- | @'gcd' x y@ is the greatest (positive) integer that divides both @x@ -- and @y@; for example @'gcd' (-3) 6@ = @3@, @'gcd' (-3) (-6)@ = @3@, -- @'gcd' 0 4@ = @4@. @'gcd' 0 0@ is defined to be 0. gcd :: (Integral a) => a -> a -> a gcd x y = gcd' (abs x) (abs y) where gcd' a 0 = a gcd' a b = gcd' b (a `rem` b) }}} [Note: I tried following the instructions at http://www.haskell.org/haskellwiki/Library_submissions to create a darcs patch. I successfully downloaded a copy of HEAD, but was unable to create a patch: $ darcs record libraries/base/GHC/Real.lhs Recording changes in "libraries/base/GHC/Real.lhs": No changes in selected files or directories! I would claim that the instructions are insufficient for a darcs beginner. ] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 15 05:12:34 2009 From: trac at galois.com (GHC) Date: Mon Jun 15 04:55:55 2009 Subject: [GHC] #3303: Allow multi-line deprecation messages. In-Reply-To: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> References: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> Message-ID: <054.98dde79e85f005bf9ab5ee1d7605c1a4@localhost> #3303: Allow multi-line deprecation messages. ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by duncan): On a similar topic, it's annoying not being able to control whether a type or identically named constructor is being deprecated. Consider: {{{ data Foo = Foo ... }}} This is a very common idiom. But now we want to switch to smart constructors {{{ foo :: ... -> Foo }}} and eventually stop exporting the constructor `Foo`. But we cannot specify just the constructor, only both. According to the [http://haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning- deprecated-pragma user guide] the workaround would be to have a module that imports one but not the other, however while that's possible for the type it's not possible for the constructor. How about {{{ {-# DEPRECATED constructor Foo "use `foo' instead" #-} }}} and while we're at it, might as well have {{{ {-# DEPRECATED type Foo "..." #-} }}} leaving the unqualified case meaning both as it does now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 15 10:18:47 2009 From: trac at galois.com (GHC) Date: Mon Jun 15 10:02:08 2009 Subject: [GHC] #2811: Unicode support for text I/O In-Reply-To: <044.4bcdd3c48e1395a70346b0b750638356@localhost> References: <044.4bcdd3c48e1395a70346b0b750638356@localhost> Message-ID: <053.ece0162ec9ca7c5fc3ce81834e236893@localhost> #2811: Unicode support for text I/O ---------------------------------+------------------------------------------ Reporter: igloo | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Done. {{{ Fri Jun 12 06:56:31 PDT 2009 Simon Marlow * Rewrite of the IO library, including Unicode support }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 15 16:19:20 2009 From: trac at galois.com (GHC) Date: Mon Jun 15 16:02:42 2009 Subject: [GHC] #3271: New methods for Data.Sequence In-Reply-To: <053.cc9895e43857ea386bfb254a48e9e83f@localhost> References: <053.cc9895e43857ea386bfb254a48e9e83f@localhost> Message-ID: <062.26276f1a019ce2653607bb963d596357@localhost> #3271: New methods for Data.Sequence -------------------------------+-------------------------------------------- Reporter: LouisWasserman | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by LouisWasserman): New additional method: a sort method, possibly faster than the Data.List equivalent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 15 21:40:33 2009 From: trac at galois.com (GHC) Date: Mon Jun 15 21:23:54 2009 Subject: [GHC] #3305: panic message "impossible happened" loadobj: failed loading SOE packages and trying to run main1 in Animation.lhs Message-ID: <051.558ce25b2ee78a9e988e8e8d099ba07d@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 | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------------+-------------------------------------------------- ghc v. 6.10 error trying to run main1 in SOE.Animation.lhs package. No similar problem with ghc-6.8, which functions properly. I have had this error with a cabal installed upgrade of SOE to the GL, gtk graphics libraries and with another installation where I installed the SOE-2007.zip file to a folder and used ghc to compile each file individually. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 16 06:10:38 2009 From: trac at galois.com (GHC) Date: Tue Jun 16 05:53:58 2009 Subject: [GHC] #3270: Stop using PackedString in template-haskell; drop packedstring as a bootlib In-Reply-To: <047.ae96a250e59fa9f3dea9027a4dd53845@localhost> References: <047.ae96a250e59fa9f3dea9027a4dd53845@localhost> Message-ID: <056.eda4ba10ca12521ef37f877a53b4fa5d@localhost> #3270: Stop using PackedString in template-haskell; drop packedstring as a bootlib ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: None | 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. In template-haskell: {{{ Fri Jun 12 11:17:36 BST 2009 Simon Marlow * abstractify ModName, PkgName and OccName; drop dependency on packedstring }}} And ghc: {{{ Mon May 18 05:09:57 PDT 2009 Simon Marlow * drop packedstring; it is no longer required by template-haskell }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 16 08:36:11 2009 From: trac at galois.com (GHC) Date: Tue Jun 16 08:19:30 2009 Subject: [GHC] #3128: hClose leaves file descriptor open if it fails In-Reply-To: <045.f474a379b598a39e20f417ce0f4de22b@localhost> References: <045.f474a379b598a39e20f417ce0f4de22b@localhost> Message-ID: <054.150e207fdbc4d12a9196190a6765b501@localhost> #3128: hClose leaves file descriptor open if it fails ---------------------------------+------------------------------------------ Reporter: Baughn | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Tue Jun 16 04:07:55 PDT 2009 Simon Marlow * Fix #3128: file descriptor leak when hClose fails }}} and a test: {{{ Tue Jun 16 04:40:36 PDT 2009 Simon Marlow * add test for #3128 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 16 08:36:50 2009 From: trac at galois.com (GHC) Date: Tue Jun 16 08:20:08 2009 Subject: [GHC] #2678: hLookAhead + hSetBuffering = unsupported operation (Illegal seek) In-Reply-To: <044.ebc0cd7ca21089d8e742f250c2a46ae6@localhost> References: <044.ebc0cd7ca21089d8e742f250c2a46ae6@localhost> Message-ID: <053.8f9a4153d5ff3ecb840628aad27276ef@localhost> #2678: hLookAhead + hSetBuffering = unsupported operation (Illegal seek) ---------------------------------+------------------------------------------ Reporter: igloo | Owner: simonmar Type: bug | 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 simonmar): * status: new => closed * resolution: => fixed Comment: Works in HEAD. Added a test: {{{ Tue Jun 16 03:18:01 PDT 2009 Simon Marlow * Add test for #2678 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 16 09:15:25 2009 From: trac at galois.com (GHC) Date: Tue Jun 16 08:58:45 2009 Subject: [GHC] #3288: GC assertion failure in reactive program In-Reply-To: <045.65aeaae2456294cc6dd5e6fd9db05b84@localhost> References: <045.65aeaae2456294cc6dd5e6fd9db05b84@localhost> Message-ID: <054.10c624a286ef90deda257c0f4908d608@localhost> #3288: GC assertion failure in reactive program ---------------------------------+------------------------------------------ Reporter: Baughn | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.4 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: crash.hs | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): I have failed to reproduce this on both x86/Linux and x86-64/Linux, using today's GHC. Here's what I have installed: {{{ $ ~/builds/32testing/inplace/bin/ghc-pkg list /playpen/simonmar/testing/inplace/lib/package.conf: Cabal-1.7.2, array-0.2.0.1, base-3.0.3.0, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, directory-1.0.0.2, (dph-base-0.4.0), (dph-par-0.4.0), (dph-prim-interface-0.4.0), (dph-prim-par-0.4.0), (dph-prim-seq-0.4.0), (dph-seq-0.4.0), extensible-exceptions-0.1.1.0, ffi-1.0, filepath-1.1.0.1, (ghc-6.11), ghc-prim-0.1.0.0, haskeline-0.6.1.6, haskell98-1.0.1.0, hpc-0.5.0.2, integer-0.1.0.0, mtl-1.1.0.2, old-locale-1.0.0.1, old-time-1.0.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0, syb-0.1.0.0, template-haskell-2.4.0.0, terminfo-0.3.1, unix-2.3.1.0, utf8-string-0.3.4 /home/simonmar/.ghc/i386-linux-6.11/package.conf: MemoTrie-0.4.5, QuickCheck-2.1.0.1, Stream-0.3.1, TypeCompose-0.6.4, category-extras-0.53.5, checkers-0.2, lazysmallcheck-0.3, reactive-0.11, unamb-0.2.2, vector-space-0.5.7 }}} I applied your patch to reactive, using the darcs repo of reactive from yesterday. {{{ > ./crash "never-never" crash: BothBottom [2] 16909 exit 1 ./crash }}} Should I try different versions of anything? If so, what? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 16 09:26:06 2009 From: trac at galois.com (GHC) Date: Tue Jun 16 09:09:28 2009 Subject: [GHC] #3279: Segmentation fault in reactive program In-Reply-To: <045.28ccfad62541fcb8fe7651779666954e@localhost> References: <045.28ccfad62541fcb8fe7651779666954e@localhost> Message-ID: <054.321775f03e34c470672b6099965dca45@localhost> #3279: Segmentation fault in reactive program -------------------------------+-------------------------------------------- Reporter: Baughn | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by simonmar): I don't have any luck reproducing this one either. (see #3288) {{{ ~/scratch/3288 > ./crash3279 "never-never" crash3279: BothBottom }}} {{{ ~/scratch/3288 > ./crash3279-2 "never-never" crash3279-2: BothBottom }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 16 09:53:30 2009 From: trac at galois.com (GHC) Date: Tue Jun 16 09:36:52 2009 Subject: [GHC] #3279: Segmentation fault in reactive program In-Reply-To: <045.28ccfad62541fcb8fe7651779666954e@localhost> References: <045.28ccfad62541fcb8fe7651779666954e@localhost> Message-ID: <054.e35715184819e7a22ae818fd2f8f8eed@localhost> #3279: Segmentation fault in reactive program -------------------------------+-------------------------------------------- Reporter: Baughn | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by Baughn): Yes, sorry. See my last message. The last version of unamb that still reliably exhibits the bug is 0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 16 09:54:10 2009 From: trac at galois.com (GHC) Date: Tue Jun 16 09:37:29 2009 Subject: [GHC] #3288: GC assertion failure in reactive program In-Reply-To: <045.65aeaae2456294cc6dd5e6fd9db05b84@localhost> References: <045.65aeaae2456294cc6dd5e6fd9db05b84@localhost> Message-ID: <054.ca660823a2a41cc6155683a49a0804c3@localhost> #3288: GC assertion failure in reactive program ---------------------------------+------------------------------------------ Reporter: Baughn | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.4 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: crash.hs | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by Baughn): There is further information in #3279, but basically you need unamb 0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 16 18:39:00 2009 From: trac at galois.com (GHC) Date: Tue Jun 16 18:22:28 2009 Subject: [GHC] #367: Infinite loops can hang Concurrent Haskell In-Reply-To: <046.5a2b87104f229d7899f0f85ea5bfdf9e@localhost> References: <046.5a2b87104f229d7899f0f85ea5bfdf9e@localhost> Message-ID: <055.fa11c1ea1b98444feaece862de89e98e@localhost> #367: Infinite loops can hang Concurrent Haskell -------------------------------------+-------------------------------------- Reporter: simonpj | Owner: nobody Type: bug | Status: assigned 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): * keywords: => scheduler allocation -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 16 19:49:17 2009 From: trac at galois.com (GHC) Date: Tue Jun 16 19:32:38 2009 Subject: [GHC] #3279: Segmentation fault in reactive program In-Reply-To: <045.28ccfad62541fcb8fe7651779666954e@localhost> References: <045.28ccfad62541fcb8fe7651779666954e@localhost> Message-ID: <054.a42854387e0f1cd47a2510eb6539f4dc@localhost> #3279: Segmentation fault in reactive program -------------------------------+-------------------------------------------- Reporter: Baughn | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by int-e): Here's a testcase for you. It does not crash, but it prints wrong results (112459785 instead of 2 here; Baughn tested it on a 64 bit maching and got 1114609665). I've also verified that your patch to {{{unblock}}} fixes this behaviour. {{{ -- test for #3279 import System.IO.Unsafe import GHC.Conc import Control.Exception import Prelude hiding (catch) f :: Int f = (1 +) . unsafePerformIO $ do error "foo" `catch` \(SomeException e) -> do myThreadId >>= flip throwTo e -- point X unblock $ return 1 main :: IO () main = do evaluate f `catch` \(SomeException e) -> return 0 -- the evaluation of 'x' is now suspended at point X tid <- block $ forkIO (evaluate f >> return ()) killThread tid -- now execute the 'unblock' above with a pending exception yield -- should print 1 + 1 = 2 print f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 03:57:18 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 03:40:34 2009 Subject: [GHC] #3306: Improve syntax for GADT + records Message-ID: <046.d67bbf39466d205ecf2349957e851ca2@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 | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- This [http://www.haskell.org/pipermail/glasgow-haskell- users/2009-June/017391.html email thread] raised the question of defining data constructors that * use GADT syntax * and record syntax * and have class constraints This combination isn't supported in GHC 6.10, but it's annoying that it isn't. The problem is just coming up with a plausible syntax. Probably the most plausible possibilities are {{{ (A) data RecContTest a where Show a => C { showable :: Show a => a } :: RecContTest a (B) data RecContTest a where C :: Show a => { showable :: Show a => a } -> RecContTest a }}} The latter (B) looks best to me. I dislike (A) because part of the type (the "Show a =>") occurs before the constructor name C, and part appears after. On the other hand, (B) has something that looks vaguely like a type {{{ { x::ty, y::ty } -> ty }}} but that's not really valid type syntax. (Mind you, the ! marks in a constructor signature aren't part of valid types either, so maybe it's not so bad to have a special form in constructor declarations.) But if we were going to adopt (B), then even when there is no class context we should really say {{{ (B) data RecTest a where B :: { arg :: a } -> RecTest a }}} rather than the current syntax which is {{{ (A) data RecTest a where B { arg :: a } :: RecTest a }}} [Note the different placement of the double colon and arrow in (B).] My take on this * (B) looks nicer, but it would represent a breaking change * But perhaps not many people use record-style syntax + GADT-style syntax * And better to make breaking changes sooner than later Question for everyone: * are (A) and (B) the only choices? * do you agree (B) is best There are some replies on the above email thread. Please add further opinions as comments to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 04:48:18 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 04:31:35 2009 Subject: [GHC] #3298: Add swap to Data.Tuple In-Reply-To: <041.b0c2cdf17e67a092210f2327e17cca5e@localhost> References: <041.b0c2cdf17e67a092210f2327e17cca5e@localhost> Message-ID: <050.bd1481cfae6ea00568019b45ec384551@localhost> #3298: Add swap to Data.Tuple ------------------------------+--------------------------------------------- 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 MartijnVanSteenbergen): Whichever version is chosen, I think it should be reexported as part of the Prelude, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 05:03:34 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 04:46:53 2009 Subject: [GHC] #3279: Segmentation fault in reactive program In-Reply-To: <045.28ccfad62541fcb8fe7651779666954e@localhost> References: <045.28ccfad62541fcb8fe7651779666954e@localhost> Message-ID: <054.7fa0304673c2d07193f2d5a7fd523c1c@localhost> #3279: Segmentation fault in reactive program -------------------------------+-------------------------------------------- Reporter: Baughn | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.4 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge * milestone: 6.12.1 => 6.10.4 Comment: Thanks for the testcase! Fixed {{{ Tue Jun 16 08:24:55 PDT 2009 Simon Marlow * Fix #3279, #3288: fix crash encountered when calling unblock inside unsafePerformIO }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 05:04:17 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 04:47:33 2009 Subject: [GHC] #3288: GC assertion failure in reactive program In-Reply-To: <045.65aeaae2456294cc6dd5e6fd9db05b84@localhost> References: <045.65aeaae2456294cc6dd5e6fd9db05b84@localhost> Message-ID: <054.06781fc72fe0bc00c66918e64cd19a32@localhost> #3288: GC assertion failure in reactive program ---------------------------------+------------------------------------------ Reporter: Baughn | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.4 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: crash.hs | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: This bug turns out to be the same as #3288 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 05:10:59 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 04:54:16 2009 Subject: [GHC] #3288: GC assertion failure in reactive program In-Reply-To: <045.65aeaae2456294cc6dd5e6fd9db05b84@localhost> References: <045.65aeaae2456294cc6dd5e6fd9db05b84@localhost> Message-ID: <054.d2c02b5aa3d75e20a2883a57c4749552@localhost> #3288: GC assertion failure in reactive program ---------------------------------+------------------------------------------ Reporter: Baughn | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.4 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: crash.hs | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): oops, I meant to say "the same as #3279" -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 06:31:05 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 06:14:20 2009 Subject: [GHC] #3298: Add swap to Data.Tuple In-Reply-To: <041.b0c2cdf17e67a092210f2327e17cca5e@localhost> References: <041.b0c2cdf17e67a092210f2327e17cca5e@localhost> Message-ID: <050.b6a24f5c7d1f314124a243bdd0faf406@localhost> #3298: Add swap to Data.Tuple ------------------------------+--------------------------------------------- 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 YitzGale): I wrote: > That supports your choice of the lazy version as unprimed. I now retract that comment, based on discussion in the thread on haskell-cafe: http://www.haskell.org/pipermail/haskell-cafe/2009-June/062772.html I now support the addition of only the strict version: {{{ swap (a, b) = (b, a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 06:33:34 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 06:16:51 2009 Subject: [GHC] #3298: Add swap to Data.Tuple In-Reply-To: <041.b0c2cdf17e67a092210f2327e17cca5e@localhost> References: <041.b0c2cdf17e67a092210f2327e17cca5e@localhost> Message-ID: <050.57883bd790f067699b3e61344301cd2d@localhost> #3298: Add swap to Data.Tuple ---------------------------------+------------------------------------------ Reporter: r6 | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: Replying to [comment:1 YitzGale]: > I would usually spell this > > {{{ > swap = uncurry $ flip (,) > }}} > > That supports your choice of the lazy version as unprimed. I had tongue firmly in cheek when I suggested using this definition on haskell-cafe a while ago. I am not sure whether to be horrified or amused that some people would actually prefer to write it that way! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 06:45:55 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 06:29:13 2009 Subject: [GHC] #3298: Add swap to Data.Tuple In-Reply-To: <041.b0c2cdf17e67a092210f2327e17cca5e@localhost> References: <041.b0c2cdf17e67a092210f2327e17cca5e@localhost> Message-ID: <050.12be6846bc40e11e098a4ec8c31e70ab@localhost> #3298: Add swap to Data.Tuple ---------------------------------+------------------------------------------ Reporter: r6 | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by MartijnVanSteenbergen): Maybe a bit of both? :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 06:50:16 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 06:33:31 2009 Subject: [GHC] #3298: Add swap to Data.Tuple In-Reply-To: <041.b0c2cdf17e67a092210f2327e17cca5e@localhost> References: <041.b0c2cdf17e67a092210f2327e17cca5e@localhost> Message-ID: <050.cbcf50c26ea3af6bd07fa4e79da122b6@localhost> #3298: Add swap to Data.Tuple ---------------------------------+------------------------------------------ Reporter: r6 | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by YitzGale): I wrote: > > {{{swap = uncurry $ flip (,)}}} simonmar wrote: > I had tongue firmly in cheek when I suggested using this definition on haskell-cafe a while ago. I am not sure whether to be horrified or amused that some people would actually prefer to write it that way! He he, I didn't even remember that, perhaps I didn't see it. Anyway, I never meant to suggest that it should actually be written that way in the libraries. Just that the laziness of the natural points-free version is evidence in support of laziness. And I have retracted even that claim. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 09:05:51 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 08:49:14 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.cd61d47d89c62e53dfed621d0d583a5d@localhost> #3132: x86 code generator generates bad FPU register names -------------------------------+-------------------------------------------- Reporter: int-e | Owner: nobody Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Wed Jun 17 14:02:27 BST 2009 Simon Marlow * Fix #3132: a case of bogus code generation }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 09:07:28 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 08:50:45 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.28fd36a48fbe09540e1a3f72b13e7d06@localhost> #3132: x86 code generator generates bad FPU register names -------------------------------+-------------------------------------------- Reporter: int-e | Owner: nobody Type: bug | Status: reopened 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 simonmar): * status: closed => reopened * resolution: fixed => Comment: Ah, we need to leave this ticket open, as a reminder to investigate the issue in the new code generator. See comments in `codeGen/CgCase.lhs`, search for `3132`. The test case is in `codeGen/should_compile/3132.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 12:59:35 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 12:42:49 2009 Subject: [GHC] #3306: Improve syntax for GADT + records In-Reply-To: <046.d67bbf39466d205ecf2349957e851ca2@localhost> References: <046.d67bbf39466d205ecf2349957e851ca2@localhost> Message-ID: <055.82385179a19da873383982fc0be6840d@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 isaacdupree): Who implements GHC's version of the syntax currently? GHC and haskell-src- exts, I guess. Both well-maintained. If we choose (B), I guess the current GADT-records syntax can/should be kept with a 'deprecated' warning for a few releases? (A) reminds me a little too much of how C tried to make declarations and uses look the same (e.g. function-pointers) and ended up with something nearly incomprehensible! With (A) and (B), I have a silly question. {{{ data Silly a where Silly :: a -> forall b. b -> Silly a (which would parse like Silly :: a -> (forall b. b -> Silly a) ) }}} Is that allowed or useful? (interacts with impredicativity, IIRC)... Because neither records syntax allows you even to attempt that. -Isaac -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 13:45:57 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 13:29:13 2009 Subject: [GHC] #3271: New methods for Data.Sequence In-Reply-To: <053.cc9895e43857ea386bfb254a48e9e83f@localhost> References: <053.cc9895e43857ea386bfb254a48e9e83f@localhost> Message-ID: <062.d64de945fe586ad2f2ef5467a3e7ad88@localhost> #3271: New methods for Data.Sequence -------------------------------+-------------------------------------------- Reporter: LouisWasserman | Owner: LouisWasserman Type: proposal | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Changes (by LouisWasserman): * owner: => LouisWasserman -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 14:46:35 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 14:29:54 2009 Subject: [GHC] #367: Infinite loops can hang Concurrent Haskell In-Reply-To: <046.5a2b87104f229d7899f0f85ea5bfdf9e@localhost> References: <046.5a2b87104f229d7899f0f85ea5bfdf9e@localhost> Message-ID: <055.a747f05476d9d6992a582f9025b58552@localhost> #367: Infinite loops can hang Concurrent Haskell -------------------------------------+-------------------------------------- Reporter: simonpj | Owner: nobody Type: bug | Status: assigned 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 | -------------------------------------+-------------------------------------- Comment (by SamB): According to CapabilitiesAndScheduling: We do have a time-slice mechanism: the timer interrupt (see Timer.c) sets the context_switch flag, which causes the running thread to return to the scheduler the next time a heap check fails (at the end of the current nursery block). When a heap check fails, the thread doesn't necessarily always return to the scheduler: as long as the context_switch flag isn't set, and there is another block in the nursery, it resets Hp and HpLim? to point to the new block, and continues. To fix this bug, we need a way for the timer signal handler to *force* the Haskell code to stop in bounded time. Two ways that come to mind for the handler to force a stop are: 1. insert a breakpoint (or a special jump?) at some pre-arranged point in any arbitrarily-long allocation-free loop, such that the breakpoint signal handler can safely enter the schedular 2. use some sort of instruction-by-instruction Call Frame Information, something like that of DWARF 2 and up, to figure out the innermost frame's stack layout. Approach 1 is kind of icky insofar as it might cause spurious stops in other threads, or worse! For those unfamiliar with it: DWARF's CFI represents a function of type (IP value ? register name) ? Maybe (how to find the value of that register in the caller), where Nothing means "that register got clobbered". Obviously, we would also need information about which of the interrupted code's registers and stack slots represented pointers that should be followed by the garbage collector for approach 2 to work. Any other ideas about how the timer handler can guarantee re-entering the scheduler in bounded time? There *is* the obvious "check every time around a non-allocating loop" approach, but it seems obvious that that would cost far too much where we can least afford it. (Is this actually true? So many things that seem obvious aren't...) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 15:47:30 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 15:30:44 2009 Subject: [GHC] #3306: Improve syntax for GADT + records In-Reply-To: <046.d67bbf39466d205ecf2349957e851ca2@localhost> References: <046.d67bbf39466d205ecf2349957e851ca2@localhost> Message-ID: <055.121a7610303fb312214d5e8e609f66a4@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 | ---------------------------------+------------------------------------------ Old description: > This [http://www.haskell.org/pipermail/glasgow-haskell- > users/2009-June/017391.html email thread] raised the question of defining > data constructors that > * use GADT syntax > * and record syntax > * and have class constraints > This combination isn't supported in GHC 6.10, but it's annoying that it > isn't. The problem is just coming up with a plausible syntax. Probably > the most plausible possibilities are > {{{ > (A) data RecContTest a where > Show a => C { showable :: Show a => a } :: RecContTest a > > (B) data RecContTest a where > C :: Show a => { showable :: Show a => a } -> RecContTest a > }}} > The latter (B) looks best to me. I dislike (A) because part of the type > (the "Show a =>") occurs before the constructor name C, and part appears > after. On the other hand, (B) has something that looks vaguely like a > type > {{{ > { x::ty, y::ty } -> ty > }}} > but that's not really valid type syntax. (Mind you, the ! marks in a > constructor signature aren't part of valid types either, so maybe it's > not so bad to have a special form in constructor declarations.) > > But if we were going to adopt (B), then even when there is no class > context we should really say > {{{ > (B) data RecTest a where > B :: { arg :: a } -> RecTest a > }}} > rather than the current syntax which is > {{{ > (A) data RecTest a where > B { arg :: a } :: RecTest a > }}} > [Note the different placement of the double colon and arrow in (B).] > > My take on this > * (B) looks nicer, but it would represent a breaking change > * But perhaps not many people use record-style syntax + GADT-style > syntax > * And better to make breaking changes sooner than later > > Question for everyone: > > * are (A) and (B) the only choices? > * do you agree (B) is best > > There are some replies on the above email thread. Please add further > opinions as comments to this ticket. New description: This [http://www.haskell.org/pipermail/glasgow-haskell- users/2009-June/017391.html email thread] raised the question of defining data constructors that * use GADT syntax * and record syntax * and have class constraints This combination isn't supported in GHC 6.10, but it's annoying that it isn't. The problem is just coming up with a plausible syntax. Probably the most plausible possibilities are {{{ (A) data RecContTest a where Show a => C { showable :: a } :: RecContTest a (B) data RecContTest a where C :: Show a => { showable :: a } -> RecContTest a }}} The latter (B) looks best to me. I dislike (A) because part of the type (the "Show a =>") occurs before the constructor name C, and part appears after. On the other hand, (B) has something that looks vaguely like a type {{{ { x::ty, y::ty } -> ty }}} but that's not really valid type syntax. (Mind you, the ! marks in a constructor signature aren't part of valid types either, so maybe it's not so bad to have a special form in constructor declarations.) But if we were going to adopt (B), then even when there is no class context we should really say {{{ (B) data RecTest a where B :: { arg :: a } -> RecTest a }}} rather than the current syntax which is {{{ (A) data RecTest a where B { arg :: a } :: RecTest a }}} [Note the different placement of the double colon and arrow in (B).] My take on this * (B) looks nicer, but it would represent a breaking change * But perhaps not many people use record-style syntax + GADT-style syntax * And better to make breaking changes sooner than later Question for everyone: * are (A) and (B) the only choices? * do you agree (B) is best There are some replies on the above email thread. Please add further opinions as comments to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 20:44:03 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 20:27:17 2009 Subject: [GHC] #3300: System.IO and System.Directory functions not Unicode-aware under Windows In-Reply-To: <042.70f85210b7c6f2f297e9bed1b5b08002@localhost> References: <042.70f85210b7c6f2f297e9bed1b5b08002@localhost> Message-ID: <051.39b314b9630b59b495e4db6c99a6a3cc@localhost> #3300: System.IO and System.Directory functions not Unicode-aware under Windows ---------------------------------+------------------------------------------ Reporter: shu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 6.11 Severity: major | Resolution: Keywords: unicode | Testcase: Os: Windows | Architecture: Unknown/Multiple ---------------------------------+------------------------------------------ Changes (by YitzGale): * keywords: => unicode * cc: YitzGale (added) * version: 6.10.3 => 6.11 * os: Unknown/Multiple => Windows * summary: System.Directory.getDirectoryContents not unicode-aware under Windows => System.IO and System.Directory functions not Unicode-aware under Windows Comment: This is a more general problem - summary changed to reflect that. See detailed discussion in this thread: http://www.haskell.org/pipermail /haskell-cafe/2009-June/062795.html Besides getDirectoryContents, at least the following functions also need to be fixed, because they are ACP-only: openFile c_stat c_chmod c_SearchPath c_SHGetFolderPath -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 21:13:23 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 20:56:37 2009 Subject: [GHC] #3307: System.IO and System.Directory functions not Unicode-aware under Unix Message-ID: <047.ddb3891fe2d3c253095b502cf5958591@localhost> #3307: System.IO and System.Directory functions not Unicode-aware under Unix ------------------------------+--------------------------------------------- Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.11 | Severity: normal Keywords: directory unicode | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Under Unix, file paths are represented as raw bytes in a String. That is not user-friendly, because a String is supposed to be decoded Unicode, and it is conventional in Unix to view those raw bytes as encoded according to the current locale. In addition, this is not consistent with Windows, where file paths are natively Unicode and represented as such in the String. (Well, they will be consistently once #3300 is completed.) On the other hand, this raises various complications (what about encoding errors, and what if encode.decode is not the identity due to normalisation, etc.) The following cases ought to work consistently for all file operations in System.IO and System.Directory: * A !FilePath from getArgs * A !FilePath from getDirectoryContents * A !FilePath in Unicode from a String literal, * A !FilePath read from a Handle and decoded into Unicode See discussion in the thread http://www.haskell.org/pipermail/haskell- cafe/2009-June/062795.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 21:19:07 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 21:02:20 2009 Subject: [GHC] #3308: getArgs should return Unicode on Windows Message-ID: <047.349ab7e0a032ccecf479f1bc43886f9b@localhost> #3308: getArgs should return Unicode on Windows ---------------------+------------------------------------------------------ Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.11 | Severity: normal Keywords: unicode | Testcase: Os: Windows | Architecture: Unknown/Multiple ---------------------+------------------------------------------------------ This is what is expected, and it is needed for file paths read from the command-line to work (once #3300 is completed). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 21:29:59 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 21:13:12 2009 Subject: [GHC] #3309: getArgs should return Unicode on Unix Message-ID: <047.aeeed4251d6d88157f87d6d7a9cbe6b7@localhost> #3309: getArgs should return Unicode on Unix -----------------------------+---------------------------------------------- Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.11 | Severity: normal Keywords: unicode | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The raw bytes of args should be decoded according to the current locale. An additional function should be added: {{{ getArgsBytes :: IO [Word8] }}} to provide access to the raw bytes. This change needs to be coordinated with #3007 so that it will still work to read a file name from the command line args and use it to access a file. This change should also be made on Windows: #3008 See the discussion at http://www.haskell.org/pipermail/haskell- cafe/2009-June/062795.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 21:36:01 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 21:19:14 2009 Subject: [GHC] #3300: System.IO and System.Directory functions not Unicode-aware under Windows In-Reply-To: <042.70f85210b7c6f2f297e9bed1b5b08002@localhost> References: <042.70f85210b7c6f2f297e9bed1b5b08002@localhost> Message-ID: <051.42de39d6feeca60738cacfa587390a68@localhost> #3300: System.IO and System.Directory functions not Unicode-aware under Windows ---------------------------------+------------------------------------------ Reporter: shu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/directory | Version: 6.11 Severity: major | Resolution: Keywords: unicode | Testcase: Os: Windows | Architecture: Unknown/Multiple ---------------------------------+------------------------------------------ Comment (by YitzGale): This change needs to be coordinated with #3308 ("getArgs should return Unicode on Windows") so that it will still work to read a file path from the command line and use it to access files. See also #3307 ("System.IO and System.Directory functions not Unicode- aware under Unix"). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 21:38:02 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 21:21:14 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.e68e15f923751967c7c6736e32c6eaf3@localhost> #3307: System.IO and System.Directory functions not Unicode-aware under Unix -------------------------------+-------------------------------------------- Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: directory unicode | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by YitzGale): This change needs to be coordinated with #3309 ("getArgs should return Unicode on Unix") so that it will still work to read a file paths from the command line and use them to access files. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 17 21:40:03 2009 From: trac at galois.com (GHC) Date: Wed Jun 17 21:23:16 2009 Subject: [GHC] #3308: getArgs should return Unicode on Windows In-Reply-To: <047.349ab7e0a032ccecf479f1bc43886f9b@localhost> References: <047.349ab7e0a032ccecf479f1bc43886f9b@localhost> Message-ID: <056.7a4b3979eac1edea5dbd86d0f2c9819e@localhost> #3308: getArgs should return Unicode on Windows ----------------------------+----------------------------------------------- Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: unicode | Testcase: Os: Windows | Architecture: Unknown/Multiple ----------------------------+----------------------------------------------- Comment (by YitzGale): See also: #3309 ("getArgs should return Unicode on Unix"). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 18 06:44:34 2009 From: trac at galois.com (GHC) Date: Thu Jun 18 06:27:47 2009 Subject: [GHC] #3300: System.IO and System.Directory functions not Unicode-aware under Windows In-Reply-To: <042.70f85210b7c6f2f297e9bed1b5b08002@localhost> References: <042.70f85210b7c6f2f297e9bed1b5b08002@localhost> Message-ID: <051.84c30ac0b485c9f8dfd0b62370cbfabc@localhost> #3300: System.IO and System.Directory functions not Unicode-aware under Windows ------------------------------------+--------------------------------------- Reporter: shu | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/directory | Version: 6.11 Severity: major | Resolution: Keywords: unicode | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 18 10:08:18 2009 From: trac at galois.com (GHC) Date: Thu Jun 18 09:51:29 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.b6acdd5f83f7be2aaa529c58523486dc@localhost> #3307: System.IO and System.Directory functions not Unicode-aware under Unix -------------------------------+-------------------------------------------- Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: directory unicode | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by duncan): Replying to [ticket:3307 YitzGale]: > Under Unix, file paths are represented as raw bytes in a String. > That is not user-friendly, because a String is supposed to be > decoded Unicode, and it is conventional in Unix to view those > raw bytes as encoded according to the current locale. Unfortunately it is not conventional on Unix to interpret file names as Unicode, decoded from the current locale. When presenting file names to the user in a user interface some decoding is necessary, though there is not universal agreement that the locale is the right one. For example glib uses UTF-8 always, unless you set some special env var to tell it to use the current locale (the latter is considered a compatibility hack that will be phased out). Certainly it's the case that FilePath as a Haskell `String` is not accurate for Unix paths (though it is for Windows and OSX). Something more accurate would be (an adt containing) a pair of the original binary filename and a Unicode human readable `String` decoding of it. It needs both because the decoding may be lossy. On Windows and OSX the binary part would not be needed because they use Unicode natively. The problem with making `getArgs` and `openFile` return Unicode is it may be impossible to open certain files passed on the command line (those for which the decoding is lossy). I would argue the solution is to move `FilePath` to being opaque, rather than towards it being properly interpreted as a Haskell Unicode `String`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 18 14:44:36 2009 From: trac at galois.com (GHC) Date: Thu Jun 18 14:27:47 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.3f514829bf5d13676fbfddc36eb50927@localhost> #3307: System.IO and System.Directory functions not Unicode-aware under Unix -------------------------------+-------------------------------------------- Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: directory unicode | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by YitzGale): Replying to [comment:2 duncan]: > Unfortunately it is not conventional on Unix to interpret file > names as Unicode, decoded from the current locale. AFAIK shells running in all modern vterms and xterms display them this way. > For example glib uses UTF-8 always, unless you set some special > env var to tell it to use the current locale (the latter is considered > a compatibility hack that will be phased out). Oh really? Is that because we can soon assume that all locales are UTF-8? If so, it makes our work easier, as Ketil pointed out. What does Qt do? > Something more accurate would be (an adt... Yes, a richer type would be a tremendous help. But simonmar has pointed out that it would break H98 compatibility, so it doesn't seem to be an option. > The problem with making `getArgs` and `openFile` return Unicode is it > may be impossible to open certain files passed on the command line > (those for which the decoding is lossy). On the other hand, they are decoded on other platforms. We don't want to make it impossible to write platform-independent code for any program that reads its args. Would that actually happen for users using any normal UI and any normal input method? It has always been possible in Unix to create weird file names that are very difficult to deal with, but it won't happen in normal usage. We can provide a Unix-specific hack for the odd case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 18 19:56:56 2009 From: trac at galois.com (GHC) Date: Thu Jun 18 19:40:10 2009 Subject: [GHC] #3310: `show BlockedIndefinitely` should not equal `show BlockedOnDeadMVar` Message-ID: <045.d15d45f5a8175ad9674d39f51d4c22e6@localhost> #3310: `show BlockedIndefinitely` should not equal `show BlockedOnDeadMVar` -----------------------------+---------------------------------------------- Reporter: enolan | 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 -----------------------------+---------------------------------------------- `show BlockedIndefinitely` and `show BlockedOnDeadMVar` should, IMO, evaluate to inequal strings that reflect the difference in cause of the exception. Them being equal is confusing for programmers trying to find the source of their crashes when the exception is printed to console. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 18 22:47:47 2009 From: trac at galois.com (GHC) Date: Thu Jun 18 22:30:59 2009 Subject: [GHC] #3311: web page direct me to a tarball that can't build Message-ID: <044.afa23adcfce0291b03d71c955864f234@localhost> #3311: web page direct me to a tarball that can't build -----------------------------+---------------------------------------------- Reporter: zooko | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I started here: http://hackage.haskell.org/trac/ghc/wiki/Building . Then I followed the link to "Getting the sources" and read the "Source distributions" section of this page: http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources , then followed the link to http://www.haskell.org/ghc/download.html and then downloaded a tarball named http://www.haskell.org/ghc/dist/current/dist/ghc-6.11.20090617-src.tar.bz2 . This tarball doesn't have all the ingredients necessary to follow the instructions on the first page (wiki/Building). Some kind passerby took pity on me and directed me to download this tarball instead: http://darcs.haskell.org/ghc-HEAD-2009-05-16-ghc-corelibs- testsuite.tar.bz2 . That one worked better. Perhaps the "Source distributions" section of http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources should point to that one instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 18 22:54:11 2009 From: trac at galois.com (GHC) Date: Thu Jun 18 22:37:20 2009 Subject: [GHC] #3312: no darcs and no VERSION file Message-ID: <044.8bacdee4fc43cf8a128dd2de27730115@localhost> #3312: no darcs and no VERSION file -----------------------------+---------------------------------------------- Reporter: zooko | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Trying to port ghc to OpenBSD/sparc64 so that I can build darcs there so that I can use darcs, I got this tarball: http://darcs.haskell.org/ghc-HEAD-2009-05-16-ghc-corelibs- testsuite.tar.bz2 And then started following the instructions on http://hackage.haskell.org/trac/ghc/wiki/Building/Porting . The {{{./configure --enable-hc-boot}}} step failed with: {{{ configure: error: failed to detect version date: check that darcs is in your path }}} {{{find . -name '*VERSION*'}}} turned up no hits, so I guess that the {{{VERSION}}} file is being accidentally omitted from the tarball. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 19 07:19:17 2009 From: trac at galois.com (GHC) Date: Fri Jun 19 07:02:28 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.f5c1975ea55fc9d8e2176e8e0d1b45ad@localhost> #3307: System.IO and System.Directory functions not Unicode-aware under Unix -------------------------------+-------------------------------------------- Reporter: YitzGale | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: directory unicode | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by duncan): Replying to [comment:3 YitzGale]: A good reference on what glib does and recommends is here: http://library.gnome.org/devel/glib/stable/glib-Character-Set- Conversion.html See the description section, after the synopsis. > > The problem with making `getArgs` and `openFile` return Unicode is it > > may be impossible to open certain files passed on the command line > > (those for which the decoding is lossy). > > On the other hand, they are decoded on other platforms. They use the native Unicode representation on other platforms. I don't see that that is an argument to use a non-native representation on Unix platforms. > We don't want to make it impossible to write platform-independent code for any > program that reads its args. Unfortunately as it stands it is impossible for platform-independent code to have both of these properties simultaneously: * Read all files passed on the command line * Display file names to humans accurately in a user interface. Currently we get the first property and you're proposing to drop that and switch to the second. It's pretty well ingrained that `FilePath` is the type for specifying files eg to open them (it's specified by H98). It's a much more recent problem that we want to display Unicode file names in user interfaces. For portable code, how about we add a function: {{{ filePathToString :: FilePath -> String }}} On Unix this would decode. On Windows and OSX it'd be the identity since on those platforms the string would already have been decoded. It means we treat `FilePath` as if it were an ADT (with differing representation on different platforms) but without actually switching to an opaque type. > Would that actually happen for users using any normal UI and any normal > input method? Generating new names is not a huge problem. The user selects a name in Unicode and if the conversion to a FilePath is impossible or lossy then the user can be prompted to select a different name. Note that does need another function: {{{ filePathFromString :: String -> Maybe FilePath }}} > It has always been possible in Unix to create weird file > names that are very difficult to deal with, but it won't happen in normal > usage. We can provide a Unix-specific hack for the odd case. The most frustrating thing for a user would be selecting a file, having the app read it, but be unable to save back to the exact same file because of lossy decoding. That's why such apps are supposed to save the real file name, and translate that into a string, but they must keep the original name because the decoding can be lossy. Unfortunately that's not a case we can just provide Unix-specific hacks for, it can happen for almost any portable app. Eg consider apps that translate `.foo` file into `.bar` files (like, say a compiler, preprocessor). If we decode `filename.foo` into Unicode but it's a lossy conversion then saving `filename.bar` may work, but the file names will no longer correspond which could break things (think chars replaced by '?'). So my suggestion basically is, keep `FilePath` as a file path, and convert to/from String for human consumption. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 19 15:20:06 2009 From: trac at galois.com (GHC) Date: Fri Jun 19 15:03:20 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.c62a44e8d42074a848e86bfc55cbc1bf@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: Component: Compiler (Type checker) | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------------------------+-------------------------------------- Changes (by chak): * owner: => chak Comment: The use of a synonym family in a rank-n type is something GHC cannot handle currently. In fact, I am not at all sure how the current approach to type checking with synonym families can be generalised to combine with arbitrary rank-n types (i.e., this is a conceptual, not just an implementation problem). The compiler panic indicates that situation; the error message should be more user-friendly, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 19 19:21:59 2009 From: trac at galois.com (GHC) Date: Fri Jun 19 19:05:08 2009 Subject: [GHC] #3313: Uncertain bug report (panic!) Message-ID: <056.afdd6dd2b6671bd71703bba915e82288@localhost> #3313: Uncertain bug report (panic!) ------------------------------+--------------------------------------------- Reporter: semanticprecision | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 ------------------------------+--------------------------------------------- Hi, I really have no clue what happened; ghc panic!'d without much info, as far as I can tell. I've attached the files I've been working with. In attempting `:l imageloader` in ghc, a panic! is achieved. That's about the extent of it. Everything was working fine (well, wan't compiling, but I ripped out the guts and was piecing it back together; but still, no crashing) until I changed the cast on line 26 of ImageLoader.hs. (I'm a Haskell n00b, hence the overtly inefficient and poorly-formatted code) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 19 19:25:06 2009 From: trac at galois.com (GHC) Date: Fri Jun 19 19:08:15 2009 Subject: [GHC] #3313: Uncertain bug report (panic!) In-Reply-To: <056.afdd6dd2b6671bd71703bba915e82288@localhost> References: <056.afdd6dd2b6671bd71703bba915e82288@localhost> Message-ID: <065.ee04298d56ab1720a24d3a1e230d503b@localhost> #3313: Uncertain bug report (panic!) -------------------------------+-------------------------------------------- Reporter: semanticprecision | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 -------------------------------+-------------------------------------------- Comment (by semanticprecision): Additional info: Windows XP Home. Here's the actual error message: {{{ Prelude Data.Word> :l imageloader [1 of 5] Compiling ArrayMethods ( ArrayMethods.hs, interpreted ) [2 of 5] Compiling Color ( Color.hs, interpreted ) [3 of 5] Compiling Image ( Image.hs, interpreted ) [4 of 5] Compiling GrayscalePNG ( GrayscalePNG.hs, interpreted ) [5 of 5] Compiling ImageLoader ( imageloader.hs, interpreted ) : panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-unknown-mingw32): schemeE(AnnCase).my_discr __word 1 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :q Leaving GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 19 19:51:42 2009 From: trac at galois.com (GHC) Date: Fri Jun 19 19:34:50 2009 Subject: [GHC] #3313: Uncertain bug report (panic!) In-Reply-To: <056.afdd6dd2b6671bd71703bba915e82288@localhost> References: <056.afdd6dd2b6671bd71703bba915e82288@localhost> Message-ID: <065.895d43d27a5a526213af2a58f8676092@localhost> #3313: Uncertain bug report (panic!) -------------------------------+-------------------------------------------- Reporter: semanticprecision | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 -------------------------------+-------------------------------------------- Comment (by semanticprecision): Replying to [comment:1 semanticprecision]: More more info: bug was fixed by replacing {{{ bytesToGrayscaleImage bytes 1 dimensions = Just ( listToImage ( byteStringToPixels bytes 1 color1 ) dimensions ) bytesToGrayscaleImage bytes 2 dimensions = Just ( listToImage ( byteStringToPixels bytes 2 color2 ) dimensions ) bytesToGrayscaleImage bytes 3 dimensions = Just ( listToImage ( byteStringToPixels bytes 3 color3 ) dimensions ) bytesToGrayscaleImage bytes 4 dimensions = Just ( listToImage ( byteStringToPixels bytes 4 color4 ) dimensions ) bytesToGrayscaleImage _ _ _ = Nothing }}} with {{{ bytesToGrayscaleImage bytes depth dimensions | depth == 1 = Just ( listToImage ( byteStringToPixels bytes 1 color1 ) dimensions ) | depth == 2 = Just ( listToImage ( byteStringToPixels bytes 2 color2 ) dimensions ) | depth == 3 = Just ( listToImage ( byteStringToPixels bytes 3 color3 ) dimensions ) | depth == 4 = Just ( listToImage ( byteStringToPixels bytes 4 color4 ) dimensions ) | otherwise = Nothing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 20 04:30:30 2009 From: trac at galois.com (GHC) Date: Sat Jun 20 04:13:37 2009 Subject: [GHC] #3314: Add compilation date to +RTS --info Message-ID: <044.ba2b5095895a2d1777a79a9b191f08e5@localhost> #3314: Add compilation date to +RTS --info -----------------------------+---------------------------------------------- Reporter: Orphi | 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 don't know how hard this would be, but it would be nice to add a timestamp in +RTS --info to show the date/time when the program was compiled. Additionally, it would be nice to be able to get at this programmatically - System.Info would seem a logical place. (Presumably if the program is interpreted rather than compiled, the "compilation time" would be the current time.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 20 06:52:29 2009 From: trac at galois.com (GHC) Date: Sat Jun 20 06:35:36 2009 Subject: [GHC] #3315: Add generalised "lookup" function Message-ID: <046.c82ce153a867ca40d2078a55a59c2144@localhost> #3315: Add generalised "lookup" function -----------------------------+---------------------------------------------- Reporter: skorpan | Owner: Type: feature request | Status: new Priority: normal | Component: Prelude Version: 6.11 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I think it would be very nice to have a default implementation of a generalised `lookup` function, such as `lookupWith`. The code I'm currently using is very simple and straight-forward: {{{ lookupWith :: (a -> Bool) -> [(a, b)] -> Maybe b lookupWith _ [] = Nothing lookupWith p ((x, y):xs) | p x = Just y | otherwise = lookupWith p xs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 20 07:14:27 2009 From: trac at galois.com (GHC) Date: Sat Jun 20 06:57:33 2009 Subject: [GHC] #3316: Deadlock in non-threaded RTS with hPutBuf Message-ID: <045.c4804c6e196e261ae7140fb9ed110793@localhost> #3316: Deadlock in non-threaded RTS with hPutBuf -------------------+-------------------------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- Using the non-threaded RTS, the attached program works fine in 6.8.2, but deadlocks in 6.8.3 and later GHCs (including 6.10.3 and 6.11.20090618). The program forks (runInteractiveProcess) two copies of cat, then forks off two separate threads (forkIO) to write a large buffer to stdin of each copy, and also lazily reads the outputs of each copy of cat, forcing the results with an equality test. From strace, it looks like 6.8.2 is correctly selecting on multiple FDs at once (though just 3, rather than all 4, which I don't understand), whereas 6.8.3 doesn't and hence ends up in a deadlock when the pipe it wants to use blocks while some other pipe is actually ready. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 20 13:16:12 2009 From: trac at galois.com (GHC) Date: Sat Jun 20 12:59:19 2009 Subject: [GHC] #3317: Ctrl-C is not received during a call to runProcess Message-ID: <044.b8fbf935b40c287d4e3429d36f807f8e@localhost> #3317: Ctrl-C is not received during a call to runProcess --------------------+------------------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- The following program runs `cat` as an external process, and tries to kill it if an exception such as ctrl-c is received. {{{ module Main where import System.Process import Control.Exception (finally) main = do pid <- runProcess "cat" [] Nothing Nothing Nothing Nothing Nothing waitForProcess pid `finally` do putStrLn "killing" terminateProcess pid print "Done!" }}} With ghc-6.8.3, the subprocess is killed when ctrl-c is pressed. However, with ghc-6.10.3 the program acts oddly: {{{ $ ./raw ^C^C $ cat: stdin: Input/output error }}} The first time that ctrl-c is pressed, it is ignored. The second time, it kills the program (without calling the handler set by `finally`) but the cat program is still running. I ran into this bug because it makes custom Cabal `Setup.hs` scripts unkillable by ctrl-c. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 20 17:26:25 2009 From: trac at galois.com (GHC) Date: Sat Jun 20 17:10:37 2009 Subject: [GHC] #3275: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> References: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> Message-ID: <055.25bf48dd4be6419724e4c0250e03939b@localhost> #3275: ghc: panic! (the 'impossible' happened) -------------------------+-------------------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by GregoryCollins): As a workaround, you can run: {{{ sudo cabal install -O2 --reinstall regex-base regex-compat regex-posix }}} which seems to clear up the problem for me. The underlying issue still remains. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 20 17:27:10 2009 From: trac at galois.com (GHC) Date: Sat Jun 20 17:11:31 2009 Subject: [GHC] #3275: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> References: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> Message-ID: <055.82582511a25afad22c6638e8345a5495@localhost> #3275: ghc: panic! (the 'impossible' happened) -------------------------+-------------------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by GregoryCollins): Sorry, I meant to say: {{{ sudo cabal install -O2 --reinstall --global regex-base regex-compat regex- posix }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 20 18:31:24 2009 From: trac at galois.com (GHC) Date: Sat Jun 20 18:15:29 2009 Subject: [GHC] #3275: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> References: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> Message-ID: <055.5266bd4143176cf36c2cc78ee7be103e@localhost> #3275: ghc: panic! (the 'impossible' happened) -------------------------+-------------------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by GregoryCollins): Haskell platform is tracking this as http://trac.haskell.org/haskell- platform/ticket/71, I'll cc: this message to the ticket there. There must be some subtle ABI incompatibility that is triggering this. Actually, I bet I know what's causing this. Roughly speaking, here's the sequence of events when I build the installer: * I install GHC from binary * I build the libraries in LISTED order (we'll return to this): {{{ ... regex-base ==0.72.0.2, regex-compat ==0.71.0.1, regex-posix ==0.72.0.3, ... }}} * Each library gets packaged into a .pkg file which, when installed, copies the generated libs to the destination and runs "ghc-pkg register" So regex-compat gets built against GHC's regex-posix instead of the platform's, then we build a NEW regex-posix against the platform libraries and GHC panics when you try to use -compat. The two regex-posix libraries have the same version number but are installed in different places and obviously aren't binary-identical, probably some autogenerated symbol names are different. The obvious workaround is to build and install the platform libraries in strict topological order -- could we re-order haskell-platform.cabal so that each library's dependencies are listed before it? Or could someone tell me how to do this topological sort using the Cabal library? Hopefully this message will create an "aha!" moment for someone who knows the GHC internals better than I do (which is to say, "not at all"). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 20 19:02:28 2009 From: trac at galois.com (GHC) Date: Sat Jun 20 18:46:35 2009 Subject: [GHC] #3275: ghc: panic! (the 'impossible' happened) In-Reply-To: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> References: <046.d2de4bede2e4e5da4bab0ab4ca5b6196@localhost> Message-ID: <055.abc174af224b56c3a217b9b3882dcc10@localhost> #3275: ghc: panic! (the 'impossible' happened) -------------------------+-------------------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.4 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: OK, that does indeed explain why it happened. You'll need to either build the packages in topological order, or to just not rebuild the packages that GHC comes with anyway. This will be less of an issue in 6.12 when the GHC installer won't install any extralibs. And to answer my other question: No, fingerprints aren't meant to catch this problem. We will doubtless think more about this when we come to working out the details of dealing with shared libraries. I'll therefore close this ticket. As Gregory said, the problem in the OS X platform installer is being tracked here: http://trac.haskell.org/haskell- platform/ticket/71 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 21 08:43:01 2009 From: trac at galois.com (GHC) Date: Sun Jun 21 08:26:09 2009 Subject: [GHC] #3318: Export System.Process.syncProcess Message-ID: <046.b28a001895783d41cd060d5dcf33714e@localhost> #3318: Export System.Process.syncProcess -----------------------------+---------------------------------------------- Reporter: skorpan | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/process Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I don't see any reason as to why `syncProcess` is not exported from `System.Process`. It is only made available through `system` and `rawSystem`, which is not enough for running a synchronous process with redirected `stdout`, `stderr` and `stdin`. Therefore, I propose that `syncProcess` is exported. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 21 12:50:12 2009 From: trac at galois.com (GHC) Date: Sun Jun 21 12:33:15 2009 Subject: [GHC] #3318: Export System.Process.syncProcess In-Reply-To: <046.b28a001895783d41cd060d5dcf33714e@localhost> References: <046.b28a001895783d41cd060d5dcf33714e@localhost> Message-ID: <055.6a2fb09b3219109f0a8467cea7a194a4@localhost> #3318: Export System.Process.syncProcess -------------------------------+-------------------------------------------- Reporter: skorpan | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/process | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by duncan): I would like to propose instead that the `CreateProcess` record be extended with something to indicate that it is a foreground process and that therefore while it is running, control-c handling be delegated to that process. This feature request is already documented in ticket #2301. Then `syncProcess` will be redundant, or implemented trivially as: {{{ (_,_,_,p) <- createProcess c waitForProcess p }}} (as it is implemented already in the Windows case). This is so simple that it does not need to be provided by the process library. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 21 12:50:52 2009 From: trac at galois.com (GHC) Date: Sun Jun 21 12:33:56 2009 Subject: [GHC] #2301: Proper handling of SIGINT/SIGQUIT In-Reply-To: <045.f06a53427920f75d02000e2372e27573@localhost> References: <045.f06a53427920f75d02000e2372e27573@localhost> Message-ID: <054.fa2dd69aeba09d3682942738a7ebb606@localhost> #2301: Proper handling of SIGINT/SIGQUIT ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/process | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by duncan): See #3318. There is clearly demand for running foreground processes with delegated Control-C handling. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 22 00:07:02 2009 From: trac at galois.com (GHC) Date: Sun Jun 21 23:50:03 2009 Subject: [GHC] #3319: Template Haskell generates invalid code for import foreign address declaration Message-ID: <044.e25f5d73903b316ad0c30309f677e836@localhost> #3319: Template Haskell generates invalid code for import foreign address declaration --------------------+------------------------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: major Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- For example, splicing {{{ForeignD (ImportF CCall Unsafe "&" (mkName "foo") (AppT (ConT ''Ptr) (ConT ''())))}}} GHC generates code equivalent to {{{foreign import ccall unsafe "foo" foo :: Ptr ()}}} but not {{{foreign import ccall unsafe "&" foo :: Ptr ()}}}. -ddump-splices shows something like {{{foreign import ccall unsafe "static & &foo" foo :: Ptr ()}}}. GHC can splice this (and produce bogus code) but can not compile this code literally, generating invalid assembler name {{{_&foo}}} for {{{foo}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 22 03:40:18 2009 From: trac at galois.com (GHC) Date: Mon Jun 22 03:23:24 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.6e4e76d9e1c56965ecf7a092d8ff62a3@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: Component: Compiler (Type checker) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Actually I see no reason ''in principle'' why this shouldn't work, but clearly we need to think about the details. Meanwhile a better error message would be a good idea; but even after that's done, let's leave the ticket open until we decide what the long-term answer is. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 22 04:57:01 2009 From: trac at galois.com (GHC) Date: Mon Jun 22 04:40:04 2009 Subject: [GHC] #3318: Export System.Process.syncProcess In-Reply-To: <046.b28a001895783d41cd060d5dcf33714e@localhost> References: <046.b28a001895783d41cd060d5dcf33714e@localhost> Message-ID: <055.57bf9c48f52301541f261c53f3bf5e93@localhost> #3318: Export System.Process.syncProcess ----------------------------------+----------------------------------------- Reporter: skorpan | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries/process | Version: 6.10.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Agree with duncan. See also #2233 for other changes we want to make in the `System.Process` API. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 22 09:22:10 2009 From: trac at galois.com (GHC) Date: Mon Jun 22 09:05:12 2009 Subject: [GHC] #3320: Parallel program crashes using GHC 6.11 under OS X Message-ID: <043.9852f1b0e0c1c860f254ba4ef6d4265e@localhost> #3320: Parallel program crashes using GHC 6.11 under OS X --------------------+------------------------------------------------------- Reporter: sebf | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- The attached program dies with a bus error when compiled {{{-threaded}}} with GHC 6.11 under OS X on an Intel Mac Book Core 2 Duo and run with {{{-N3}}}. Using {{{-N1}}} or {{{-N2}}} works fine. It also works when using GHC 6.10.3 under OS X or GHC 6.11 under Linux. {{{ $ ~/Applications/ghc/bin/ghc -v -fforce-recomp --make -threaded idfs Glasgow Haskell Compiler, Version 6.11.20090618, for Haskell 98, stage 2 booted by GHC version 6.10.3 Using package config file: /Users/sebf/Applications/ghc/lib/ghc-6.11.20090618/package.conf Using package config file: /Users/sebf/.ghc/i386-darwin-6.11.20090618/package.conf hiding package base-3.0.3.0 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.0 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 template-haskell mapped to template-haskell-2.4.0.0 wired-in package dph-seq mapped to dph-seq-0.4.0 wired-in package dph-par mapped to dph-par-0.4.0 Hsc static flags: -static *** Chasing dependencies: Chasing modules from: *idfs.hs Stable obj: [Main] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = Mon Jun 22 14:56:13 CEST 2009 ms_mod = main:Main, ms_imps = [import Control.Parallel.Strategies (using, seqList, r0), import Control.Parallel (par)] ms_srcimps = [] }] compile: input file idfs.hs Created temporary directory: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc87766_0 *** Checking old interface for main:Main: [1 of 1] Compiling Main ( idfs.hs, idfs.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 512 *** Simplifier Phase gentle: Result size = 297 Result size = 297 *** Specialise: Result size = 297 *** Float inwards: Result size = 297 *** Simplifier Phase 2 [main]: Result size = 421 Result size = 364 Result size = 295 Result size = 287 Result size = 287 *** Simplifier Phase 1 [main]: Result size = 251 Result size = 251 *** Simplifier Phase 0 [main]: Result size = 372 Result size = 323 Result size = 316 *** Demand analysis: Result size = 316 *** Worker Wrapper binds: Result size = 351 *** GlomBinds: *** Simplifier Phase 0 [post-worker-wrapper]: Result size = 344 Result size = 325 *** Common sub-expression: Result size = 324 *** Float inwards: Result size = 324 *** Simplifier Phase 0 [final]: Result size = 325 Result size = 325 *** Tidy Core: Result size = 325 *** CorePrep: Result size = 408 *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler: gcc -I. -c /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc87766_0/ghc87766_0.s -o idfs.o -DDONT_WANT_WIN32_DLL_SUPPORT *** Deleting temp files: Deleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc87766_0/ghc87766_0.s Upsweep completely successful. *** Deleting temp files: Deleting: link: linkables are ... LinkableM (Mon Jun 22 15:12:56 CEST 2009) main:Main [DotO idfs.o] Linking idfs ... *** Linker: gcc -v -o idfs -DDONT_WANT_WIN32_DLL_SUPPORT idfs.o -L/Users/sebf/.cabal/lib/parallel-1.1.0.1/ghc-6.11.20090618 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/containers-0.2.0.1 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/base-3.0.3.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/syb-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/array-0.2.0.1 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/base-4.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/integer-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/ghc-prim-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618 -lHSrtsmain -lHSparallel-1.1.0.1 -lHScontainers-0.2.0.1 -lHSbase-3.0.3.0 -lHSsyb-0.1.0.0 -lHSarray-0.2.0.1 -lHSbase-4.1.0.0 -liconv -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts_thr -lm -u _ghczmprim_GHCziTypes_Izh_static_info -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOziException_stackOverflow_closure -u _base_GHCziIOziException_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure -u _base_GHCziIOziException_blockedOnDeadMVar_closure -u _base_GHCziIOziException_blockedIndefinitely_closure -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure -u _base_GHCziConc_ensureIOManagerIsRunning_closure -u _base_GHCziConc_runSparks_closure -u _base_GHCziConc_runHandlers_closure -Wl,-search_paths_first -read_only_relocs warning -lHSffi -framework GMP -lpthread Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable- languages=c,objc,c++,obj-c++ --program-transform- name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5488) /usr/libexec/gcc/i686-apple-darwin9/4.0.1/collect2 -dynamic -arch i386 -macosx_version_min 10.5.7 -read_only_relocs warning -weak_reference_mismatches non-weak -u _ghczmprim_GHCziTypes_Izh_static_info -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOziException_stackOverflow_closure -u _base_GHCziIOziException_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure -u _base_GHCziIOziException_blockedOnDeadMVar_closure -u _base_GHCziIOziException_blockedIndefinitely_closure -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure -u _base_GHCziConc_ensureIOManagerIsRunning_closure -u _base_GHCziConc_runSparks_closure -u _base_GHCziConc_runHandlers_closure -o idfs -lcrt1.10.5.o -L/Users/sebf/.cabal/lib/parallel-1.1.0.1/ghc-6.11.20090618 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/containers-0.2.0.1 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/base-3.0.3.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/syb-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/array-0.2.0.1 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/base-4.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/integer-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618/ghc-prim-0.1.0.0 -L/Users/sebf/Applications/ghc//lib/ghc-6.11.20090618 -L/usr/lib/i686 -apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple- darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple- darwin9/4.0.1/../../.. idfs.o -lHSrtsmain -lHSparallel-1.1.0.1 -lHScontainers-0.2.0.1 -lHSbase-3.0.3.0 -lHSsyb-0.1.0.0 -lHSarray-0.2.0.1 -lHSbase-4.1.0.0 -liconv -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts_thr -lm -search_paths_first -lHSffi -framework GMP -lpthread -lgcc_s.10.5 -lgcc -lSystem link: done *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc87766_0 $ ./idfs 500 $ ./idfs +RTS -N1 500 $ ./idfs +RTS -N2 500 $ ./idfs +RTS -N3 Bus error }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 22 10:47:35 2009 From: trac at galois.com (GHC) Date: Mon Jun 22 10:30:36 2009 Subject: [GHC] #3320: Parallel program crashes using GHC 6.11 under OS X In-Reply-To: <043.9852f1b0e0c1c860f254ba4ef6d4265e@localhost> References: <043.9852f1b0e0c1c860f254ba4ef6d4265e@localhost> Message-ID: <052.835a5d8705e45e2e50be54aebade1dab@localhost> #3320: Parallel program crashes using GHC 6.11 under OS X -------------------------------+-------------------------------------------- Reporter: sebf | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * owner: => simonmar * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 22 14:24:02 2009 From: trac at galois.com (GHC) Date: Mon Jun 22 14:07:03 2009 Subject: [GHC] #3321: -fhpc assumes original sources relative to the current directory Message-ID: <045.e36e70091ef09c2231ae7feacc97785c@localhost> #3321: -fhpc assumes original sources relative to the current directory -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- For the most part, ghc can be invoked in a manner that is independent of the current directory by suitable use of `-i` options. With `-fhpc` it appears that the hpc bits always look in the current directory to find original source files. Consider the following file layout: {{{ Codec/Compression/Zlib/Stream.hsc dist/build/Codec/Compression/Zlib/Stream.hs examples/gunzip.hs }}} Now if we `cd` to `examples` and run: {{{ ghc --make gunzip.hs -lz -i../ -i../dist/build }}} then it works fine. It finds `Codec/Compression/Zlib/Stream.hs` in `../dist/build` and it never bothers to look for the original source of course. Now in `-fhpc` mode it has to also find the original sources so that it can match things back to them. However just adding -fhpc to the above command fails: {{{ ghc --make gunzip.hs -lz -i../ -i../dist/build -fhpc [1 of 4] Compiling Codec.Compression.Zlib.Stream ( ../dist/build/Codec/Compression/Zlib/Stream.hs, ../dist/build/Codec/Compression/Zlib/Stream.o ) Codec/Compression/Zlib/Stream.hsc: getModificationTime: does not exist (No such file or directory) }}} So it's clearly not looking in the directory given by `-i..` for the original sources. Also, the failure mode is a bit unfriendly. Cabal sometimes takes advantage of the fact that ghc can be invoked in a manner that is independent of the current directory, and we would like to add hpc support into Cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 22 21:08:15 2009 From: trac at galois.com (GHC) Date: Mon Jun 22 20:51:14 2009 Subject: [GHC] #3049: STM with data invariants crashes GHC In-Reply-To: <046.1d33a67baae883decd123e9a74ad7517@localhost> References: <046.1d33a67baae883decd123e9a74ad7517@localhost> Message-ID: <055.6ddbb2a9f546bafac552d105b07f6603@localhost> #3049: STM with data invariants crashes GHC ---------------------------------+------------------------------------------ Reporter: simonpj | 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 | ---------------------------------+------------------------------------------ Comment (by int-e): Here's a more enlightening example: {{{ import GHC.Conc main = do t <- atomically $ do alwaysSucceeds (return 42) return 23 print t }}} This will print 42 instead of 23. I believe that if any invariants are checked, the result of {{{atomically}}} will be that of the last invariant. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 22 22:33:33 2009 From: trac at galois.com (GHC) Date: Mon Jun 22 22:16:31 2009 Subject: [GHC] #3316: Deadlock in non-threaded RTS with hPutBuf In-Reply-To: <045.c4804c6e196e261ae7140fb9ed110793@localhost> References: <045.c4804c6e196e261ae7140fb9ed110793@localhost> Message-ID: <054.5eb8db3eb594100fbc8494bad4a3c010@localhost> #3316: Deadlock in non-threaded RTS with hPutBuf ----------------------+----------------------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by duncan): It looks like it'd be possible to set our end of the pipe as non-blocking, leaving the other end as blocking. The attached C prog checks if the `O_NONBLOCK` setting for the two ends of a pipe are shared or not. On Linux and Solaris they appear to be independent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 02:56:46 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 02:46:09 2009 Subject: [GHC] #2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator) In-Reply-To: <046.4436609d3a414ddff94df71de1efe346@localhost> References: <046.4436609d3a414ddff94df71de1efe346@localhost> Message-ID: <055.c7a646ecaef0e6dc1ac3442ad3d1eae2@localhost> #2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator) ---------------------------------+------------------------------------------ Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by guest): I want to give my vote for Karel's request. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 05:23:23 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 05:06:23 2009 Subject: [GHC] #3049: STM with data invariants crashes GHC In-Reply-To: <046.1d33a67baae883decd123e9a74ad7517@localhost> References: <046.1d33a67baae883decd123e9a74ad7517@localhost> Message-ID: <055.a708f06dc1f2cdd286d77b9385ed36d6@localhost> #3049: STM with data invariants crashes GHC ---------------------------------+------------------------------------------ Reporter: simonpj | 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 ertai): * cc: nicolas.pouillard@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 06:27:53 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 06:10:53 2009 Subject: [GHC] #3316: Deadlock in non-threaded RTS with hPutBuf In-Reply-To: <045.c4804c6e196e261ae7140fb9ed110793@localhost> References: <045.c4804c6e196e261ae7140fb9ed110793@localhost> Message-ID: <054.3d3c0c1363667cf031e09e2c053a94d9@localhost> #3316: Deadlock in non-threaded RTS with hPutBuf -------------------------+-------------------------------------------------- Reporter: ganesh | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.12.1 Comment: A problem with using `O_NONBLOCK` is that you might pass this `Handle` to another process, for example when constructing a pipeline of processes using `createProcess`. Strictly speaking in that case we should set the FD to be blocking again, but right now we don't have support for changing the blocking mode on an existing Handle. I suppose I'll have to do that first. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 06:48:05 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 06:31:04 2009 Subject: [GHC] #3322: Tag base libraries Message-ID: <047.6380de96933ec553e06c3fee90642415@localhost> #3322: Tag base libraries -----------------------------+---------------------------------------------- Reporter: YitzGale | Owner: Type: task | Status: new Priority: normal | Component: libraries/base Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Please tag the base libraries, so that we can darcs get --partial and submit patches with sane context. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 07:14:17 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 06:57:16 2009 Subject: [GHC] #3323: panic: funArgTy Message-ID: <047.8f9fe6697ba182cf9c87104ebe4c50fd@localhost> #3323: panic: funArgTy --------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------------+------------------------------------- The following module crashes GHC 6.11.20090615: {{{ module V where import GHC.IO.Handle.Types import GHC.IO.Handle.Internals f :: Handle -> IO () f hdl = withHandle_ "" hdl $ \h -> return h{haDevice=undefined} }}} results: {{{ $ ghc-testing2 --make V.hs [1 of 1] Compiling V ( V.hs, V.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 6.11.20090615 for x86_64-unknown-linux): funArgTy ghc-prim:GHC.Unit.(){(w) tc 40} }}} It imports some internals of the IO library; I tried to reproduce it with a completely standalone module, but failed. The field `haDevice` of `Handle__` has existential type - normally GHC rejects a record update when the field has existential type, but does not in this case, I'm not sure why. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 07:25:37 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 07:08:37 2009 Subject: [GHC] #3300: System.IO and System.Directory functions not Unicode-aware under Windows In-Reply-To: <042.70f85210b7c6f2f297e9bed1b5b08002@localhost> References: <042.70f85210b7c6f2f297e9bed1b5b08002@localhost> Message-ID: <051.37cbc52db72d51ec5097a17b36f9a6dd@localhost> #3300: System.IO and System.Directory functions not Unicode-aware under Windows ------------------------------------+--------------------------------------- Reporter: shu | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/directory | Version: 6.11 Severity: major | Resolution: Keywords: unicode | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Comment (by simonmar): I have done `openFile`, `getDirectoryContents`, and everything that uses `c_stat`. libraries/base: {{{ Thu Jun 18 06:54:58 PDT 2009 Simon Marlow * Windows: Unicode openFile and stat functions }}} libraries/Win32: {{{ Thu Jun 18 03:19:31 PDT 2009 Simon Marlow * add findFirstFile, findNextFile, findClose }}} libraries/directory: {{{ Thu Jun 18 06:48:58 PDT 2009 Simon Marlow * Windows: Unicode getDirectoryContents and setPermissions }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 07:25:56 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 07:08:54 2009 Subject: [GHC] #3324: Add Foldable and Traversable instances for ((,) a) Message-ID: <047.8947bef7cc0f665b60675f311754fd4d@localhost> #3324: Add Foldable and Traversable instances for ((,) a) -----------------------------+---------------------------------------------- Reporter: YitzGale | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- These instances are pretty obvious, and no more or less trivial than the existing instances for Prelude types. I have found them to be useful. Since we are touching these modules anyway, I am attaching two additional minor patches to this proposal. One is to add a few additional explicit method implementations in the Foldable and Traversable instances for Prelude types. These might sometimes be slightly more efficient, and they better match the strictness and style of the existing explicit method implementations. The other is to fix the documentation for the functions fmapDefault and foldMapDefault in Data.Traversable. Contrary to what is stated, these cannot be used as methods in superclasses, since the superclasses must already exist before these functions can be defined. Instead, I have paraphrased what is stated in the documentation above: that the corresponding superclass methods should be equivalent to these. Discussion period: two weeks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 08:09:37 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 07:52:35 2009 Subject: [GHC] #3325: ghci debugger sometime doesn't notice that Integers are Integers Message-ID: <044.8521015b6f803e8f2ebf61aa1e1f946a@localhost> #3325: ghci debugger sometime doesn't notice that Integers are Integers -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: 2740, break001, break006, break026, hist001, print003, print005, print006, print010, print012, print014 Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- The ghci debugger sometime doesn't notice that Integers are Integers. For example: {{{ --- ./ghci.debugger/scripts/2740.stdout.normalised 2009-06-23 12:52:07.000000000 +0100 +++ ./ghci.debugger/scripts/2740.run.stdout.normalised 2009-06-23 12:52:07.000000000 +0100 @@ -6,5 +6,5 @@ y :: a = _ x = (_t1::a) y = (_t2::a) -x = 1 -y = 2 +x = GHC.Integer.GMP.Internals.S# 1 +y = GHC.Integer.GMP.Internals.S# 2 *** unexpected failure for 2740(ghci) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 10:51:21 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 10:40:44 2009 Subject: [GHC] #2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator) In-Reply-To: <046.4436609d3a414ddff94df71de1efe346@localhost> References: <046.4436609d3a414ddff94df71de1efe346@localhost> Message-ID: <055.3d835fb5143a42edd79c98a29bb585e0@localhost> #2959: Merge in LambdaVM (Haskell to Java/JVM bytecode translator) ---------------------------------+------------------------------------------ Reporter: kgardas | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: 6.12 branch => _|_ Comment: For this to be merged in, we need at the very least * an active maintainer, willing to work with us to merge it and to keep it working * tests * documentation And we'd need to do a thorough code and design review. This is a significant piece of work, and so far we've had no interaction with anyone involved in building it. For now, I'm moving it out of the 6.12.1 milestone, since I very much doubt that it can happen in that timeframe. If the pieces come together, then we can consider it for a future milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 12:31:20 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 12:14:18 2009 Subject: [GHC] #3326: the recompilation checker should take CPP flags into account Message-ID: <047.f460b2673a1733e129e3e26d96037ca8@localhost> #3326: the recompilation checker should take CPP flags into account -----------------------------+---------------------------------------------- Reporter: bkomuves | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The C preprocessor can be used (or maybe abused) to provide different configurations of the same program. I often build programs with a command like {{{ghc --make -DOPTION1 -DOPTION3 main.hs}}} Now if I try to rebuild with different CPP flags, ghc won't recompile anything, since no source file changed (however, they become different after the CPP pass). Ticket #437 is loosely related. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 15:06:44 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 14:49:42 2009 Subject: [GHC] #3324: Add Foldable and Traversable instances for ((, ) a) In-Reply-To: <047.8947bef7cc0f665b60675f311754fd4d@localhost> References: <047.8947bef7cc0f665b60675f311754fd4d@localhost> Message-ID: <056.07111f24aad2d79e5138fdfa5d0367c2@localhost> #3324: Add Foldable and Traversable instances for ((,) a) ------------------------------+--------------------------------------------- Reporter: YitzGale | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by LouisWasserman): "The other is to fix the documentation for the functions fmapDefault and foldMapDefault in Data.Traversable. Contrary to what is stated, these cannot be used as methods in superclasses, since the superclasses must already exist before these functions can be defined." I don't think this is correct. Here is a sample usage of fmapDefault in Data.Sequence (which definitely compiles): {{{ instance Functor ViewL where fmap = fmapDefault instance Foldable ViewL where foldMap = foldMapDefault instance Traversable ViewL where traverse _ EmptyL = pure EmptyL traverse f (x :< xs) = (:<) <$> f x <*> traverse f xs }}} This is exactly what I expected from the original documentation. What actually happens is that, in the case of the Functor instance, the Functor instance -- specifically, fmapDefault -- is defined in terms of the Traversable instance, and the Traversable instance depends on the Functor instance. This sets up a legal recursion. The following, in contrast, would not be legal: {{{ data Foo a b = ... instance Traversable (Foo a) => Functor (Foo a) where fmap = fmapDefault instance Traversable (Foo a) where ... }}} This would have set up a loop of dependencies, but in the first example, the key is that the presence of the Functor instance (combined with the Traversable instance) implies that fmapDefault is defined, and is therefore legal. I hope I'm making sense, but as I read it, the original documentation was correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 16:05:24 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 15:48:25 2009 Subject: [GHC] #3049: STM with data invariants crashes GHC In-Reply-To: <046.1d33a67baae883decd123e9a74ad7517@localhost> References: <046.1d33a67baae883decd123e9a74ad7517@localhost> Message-ID: <055.662435f685a5d1c1e2257034929a18e1@localhost> #3049: STM with data invariants crashes GHC ---------------------------------+------------------------------------------ Reporter: simonpj | 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 int-e): * cc: int-e@gmx.de (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 17:17:58 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 17:00:55 2009 Subject: [GHC] #3311: web page direct me to a tarball that can't build In-Reply-To: <044.afa23adcfce0291b03d71c955864f234@localhost> References: <044.afa23adcfce0291b03d71c955864f234@localhost> Message-ID: <053.6868810715859e343fdb01f6ece30c05@localhost> #3311: web page direct me to a tarball that can't build ---------------------------------+------------------------------------------ Reporter: zooko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Comment: Building http://www.haskell.org/ghc/dist/current/dist/ghc-6.11.20090617-src.tar.bz2 builds fine for me. Can you please give more details on what goes wrong, what platform you are on, what commands you are running, etc? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 18:28:46 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 18:11:43 2009 Subject: [GHC] #3311: web page direct me to a tarball that can't build In-Reply-To: <044.afa23adcfce0291b03d71c955864f234@localhost> References: <044.afa23adcfce0291b03d71c955864f234@localhost> Message-ID: <053.a58f77df74f489f875b42b3f390dc99f@localhost> #3311: web page direct me to a tarball that can't build ---------------------------------+------------------------------------------ Reporter: zooko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by zooko): Platform: OpenBSD/sparc64 -- attempting to port GHC (unregisterised), following http://hackage.haskell.org/trac/ghc/wiki/Building/Porting , and here is the result: {{{ $ time sh boot 2>&1 | tee ../zooko.boot.log.txt grep: packages: No such file or directory Booting . Booting libraries/base Booting libraries/directory Booting libraries/old-time Booting libraries/process Booting libraries/terminfo Booting libraries/unix sh: boot-pkgs: No such file or directory 4m17.36s real 1m41.38s user 0m19.47s system }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 18:41:07 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 18:24:02 2009 Subject: [GHC] #3311: web page direct me to a tarball that can't build In-Reply-To: <044.afa23adcfce0291b03d71c955864f234@localhost> References: <044.afa23adcfce0291b03d71c955864f234@localhost> Message-ID: <053.1e3a51ebc260d34796ebaf05f56ea671@localhost> #3311: web page direct me to a tarball that can't build ---------------------------------+------------------------------------------ Reporter: zooko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by zooko): When I do the same process with http://darcs.haskell.org/ghc- HEAD-2009-05-16-ghc-corelibs-testsuite.tar.bz2 I get further: {{{ $ time sh boot 2>&1 | tee ../zooko.boot3.log.txt Booting . Booting libraries/base Booting libraries/directory Booting libraries/old-time Booting libraries/process Booting libraries/terminfo Booting libraries/unix 2m7.37s real 1m39.02s user 0m20.15s system }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 18:44:46 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 18:27:41 2009 Subject: [GHC] #3311: web page direct me to a tarball that can't build In-Reply-To: <044.afa23adcfce0291b03d71c955864f234@localhost> References: <044.afa23adcfce0291b03d71c955864f234@localhost> Message-ID: <053.28b6fb8295a15766daf297b02dc8b2b7@localhost> #3311: web page direct me to a tarball that can't build ---------------------------------+------------------------------------------ Reporter: zooko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by zooko): After that {{{sh boot}}} step works with the {{{-corelibs-testsuite}}} tarball, then I hit #3312 (no darcs and no VERSION file). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 18:54:32 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 18:37:28 2009 Subject: [GHC] #3312: no darcs and no VERSION file In-Reply-To: <044.8bacdee4fc43cf8a128dd2de27730115@localhost> References: <044.8bacdee4fc43cf8a128dd2de27730115@localhost> Message-ID: <053.7d7fb0e08a17c3918b3b66153a1f6465@localhost> #3312: no darcs and no VERSION file ------------------------------+--------------------------------------------- Reporter: zooko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by zooko): I created a {{{VERSION}}} file and that got past this problem to another problem, saying "no $ver_date, check that darcs is installed". I guess the tarball should have a {{{VERSION}}} file added. I got past this problem by the following extra step before {{{./configure}}}: {{{ /bin/rm -rf ./_darcs }}} I suggest that the configure script try running "darcs" and then if it fails move on without a ver_date instead of testing for the existence of _darcs and then trying to run darcs and then failing hard if it doesn't get a ver_date. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 19:54:56 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 19:37:56 2009 Subject: [GHC] #3049: STM with data invariants crashes GHC In-Reply-To: <046.1d33a67baae883decd123e9a74ad7517@localhost> References: <046.1d33a67baae883decd123e9a74ad7517@localhost> Message-ID: <055.f6c58d4756f3a112981a76b98cc8b990@localhost> #3049: STM with data invariants crashes GHC ---------------------------------+------------------------------------------ Reporter: simonpj | 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 dbueno): * cc: dbueno@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 23 20:40:54 2009 From: trac at galois.com (GHC) Date: Tue Jun 23 20:24:10 2009 Subject: [GHC] #2285: Solaris 9 build fails at stage2 with undefined symbol errors (for libm symbols) In-Reply-To: <048.9d281a64a969b94451f675cf7f831df1@localhost> References: <048.9d281a64a969b94451f675cf7f831df1@localhost> Message-ID: <057.06b1f2fb72824dad5433bcc47a0b6470@localhost> #2285: Solaris 9 build fails at stage2 with undefined symbol errors (for libm symbols) --------------------------+------------------------------------------------- Reporter: TimBishop | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | --------------------------+------------------------------------------------- Comment (by guest): These symbols come from libm.so.2, the c99-compatible libm. Problem is, most Solaris 9 systems in the wild don't have the c99 patches, which apparently are only available if you have a service contract with Sun. I don't know if the c99 libm has a static version, but suspect it doesn't because Sun strongly deprecates static linking to system libraries. If so, trying to force use of libm.a on a system with the c99 patches will probably have very unfortunate effects. I have some horrible ugliness to work around this, including some environment variables to force ld to accept libm.so.1 in lieu of libm.so.2 (for bootstrap; the generated compiler uses libm.so.1) and lame (casting, instead of using the FP hardware in single precision mode) implementations of the single precision trig functions that I force into libHSmain.a. Things would be much easier if libm.so.2 were actually available to mortals.... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 24 07:46:48 2009 From: trac at galois.com (GHC) Date: Wed Jun 24 07:29:44 2009 Subject: [GHC] #1820: Windows segfault-catching only works for the main thread In-Reply-To: <047.7ca539e672ab08a35be7d52badf17eec@localhost> References: <047.7ca539e672ab08a35be7d52badf17eec@localhost> Message-ID: <056.6ea6c0e63adb2988653400eefb825da1@localhost> #1820: Windows segfault-catching only works for the main thread -------------------------------------------------+-------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: derefnull(ghci), divbyzero(ghci) | Os: Windows Architecture: Unknown/Multiple | -------------------------------------------------+-------------------------- Comment (by igloo): See also the mingw GCC 4.4.0 announcement info on exceptions: http://sourceforge.net/project/shownotes.php?release_id=691876 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 24 08:23:03 2009 From: trac at galois.com (GHC) Date: Wed Jun 24 08:06:00 2009 Subject: [GHC] #3317: Ctrl-C is not received during a call to runProcess In-Reply-To: <044.b8fbf935b40c287d4e3429d36f807f8e@localhost> References: <044.b8fbf935b40c287d4e3429d36f807f8e@localhost> Message-ID: <053.4d33450ba299699edb701eae28ce870d@localhost> #3317: Ctrl-C is not received during a call to runProcess ----------------------------------+----------------------------------------- Reporter: judah | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: libraries/process | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * component: Compiler => libraries/process * milestone: => 6.10.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 24 10:10:29 2009 From: trac at galois.com (GHC) Date: Wed Jun 24 09:53:24 2009 Subject: [GHC] #3317: Ctrl-C is not received during a call to runProcess In-Reply-To: <044.b8fbf935b40c287d4e3429d36f807f8e@localhost> References: <044.b8fbf935b40c287d4e3429d36f807f8e@localhost> Message-ID: <053.1ed68a6c4f8d8622fde4fe6eae4886f4@localhost> #3317: Ctrl-C is not received during a call to runProcess ----------------------------------+----------------------------------------- Reporter: judah | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.4 Component: libraries/process | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Wed Jun 24 13:37:48 BST 2009 Simon Marlow * unblock user signals in the child (fixes #3317) Wed Jun 24 13:41:06 BST 2009 Simon Marlow * Add a mutex around the Unix version of runInteractiveProcess() since it blocks/unblocks signals }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 24 10:47:39 2009 From: trac at galois.com (GHC) Date: Wed Jun 24 10:30:34 2009 Subject: [GHC] #3166: recompilation checking too optimistic about infix ops In-Reply-To: <045.c56a4930c6b4384da33ae7e1caaf1d10@localhost> References: <045.c56a4930c6b4384da33ae7e1caaf1d10@localhost> Message-ID: <054.666aa1147c134db7000bf8f37188a2b4@localhost> #3166: recompilation checking too optimistic about infix ops ---------------------------------+------------------------------------------ Reporter: roland | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: No response from submitter; I'm assuming this is complete. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 24 11:00:59 2009 From: trac at galois.com (GHC) Date: Wed Jun 24 10:44:00 2009 Subject: [GHC] #3049: STM with data invariants crashes GHC In-Reply-To: <046.1d33a67baae883decd123e9a74ad7517@localhost> References: <046.1d33a67baae883decd123e9a74ad7517@localhost> Message-ID: <055.5c92522e4c4cbd50c86ca88540b4f94a@localhost> #3049: STM with data invariants crashes GHC ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * component: Compiler => Runtime System * resolution: => fixed Comment: Fixed: {{{ Wed Jun 24 07:15:30 PDT 2009 Simon Marlow * propagate the result of atomically properly (fixes #3049) }}} the patch came from Tim Harris, with a couple of fixes by me. Looks like Tim based his patch on int-e's patch attached to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 24 12:23:21 2009 From: trac at galois.com (GHC) Date: Wed Jun 24 12:06:14 2009 Subject: [GHC] #3327: Cannot paste into ghci on windows Message-ID: <043.4776861a900af51ee3315be8ee4af71f@localhost> #3327: Cannot paste into ghci on windows --------------------+------------------------------------------------------- Reporter: boml | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- Only the first character of the string that one tries to paste into the console actually gets pasted. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 24 13:05:06 2009 From: trac at galois.com (GHC) Date: Wed Jun 24 12:48:02 2009 Subject: [GHC] #3323: panic: funArgTy In-Reply-To: <047.8f9fe6697ba182cf9c87104ebe4c50fd@localhost> References: <047.8f9fe6697ba182cf9c87104ebe4c50fd@localhost> Message-ID: <056.5181620b4519309d258af95cc69c43e5@localhost> #3323: panic: funArgTy ----------------------------------------+----------------------------------- Reporter: simonmar | Owner: simonpj 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: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * owner: => simonpj Comment: I'm on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 24 13:41:03 2009 From: trac at galois.com (GHC) Date: Wed Jun 24 13:23:57 2009 Subject: [GHC] #3316: Deadlock in non-threaded RTS with hPutBuf In-Reply-To: <045.c4804c6e196e261ae7140fb9ed110793@localhost> References: <045.c4804c6e196e261ae7140fb9ed110793@localhost> Message-ID: <054.1615bb2606673f433f8c4633059bf784@localhost> #3316: Deadlock in non-threaded RTS with hPutBuf -------------------------+-------------------------------------------------- Reporter: ganesh | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by guest): Correct; the ends of a pipe are independent fds and their blocking states are independent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Jun 24 16:40:57 2009 From: trac at galois.com (GHC) Date: Wed Jun 24 16:23:52 2009 Subject: [GHC] #3327: Cannot paste into ghci on windows In-Reply-To: <043.4776861a900af51ee3315be8ee4af71f@localhost> References: <043.4776861a900af51ee3315be8ee4af71f@localhost> Message-ID: <052.d1e6a230910d873d24f89d6c5529d1e9@localhost> #3327: Cannot paste into ghci on windows ---------------------+------------------------------------------------------ Reporter: boml | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ---------------------+------------------------------------------------------ Comment (by judahj): This is a Haskeline issue which was fixed in version 0.6.1.6, a minor release with two bugfixes. We should make sure that ghc-6.10.4 ships with that version of haskeline. The linear order of the patches in the repo is not great, so we should pull all patches from that release using: {{{ darcs pull --to-tag=0.6.1.6 }}} The changes after 0.6.1.6 are not minor enough to be suited for ghc-6.10.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 02:35:03 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 02:18:07 2009 Subject: [GHC] #3328: base's FD.hs defines exports setNonBlockingMode on Windows hosts Message-ID: <042.8cf8b10d310cf365b8b72ab2173bc2f6@localhost> #3328: base's FD.hs defines exports setNonBlockingMode on Windows hosts --------------------+------------------------------------------------------- Reporter: shu | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- 6.11 currently does not compile under Windows due to `setNonBlockingMode` in base/GHC/IO/FD.hs. I'm not sure what the behavior of it should be on Windows, perhaps identity on `fd`: {{{ setNonBlockingMode :: FD -> Bool -> IO FD #ifndef mingw32_HOST_OS setNonBlockingMode fd set = do setNonBlockingFD (fdFD fd) set return fd{ fdIsNonBlocking = fromEnum set } #else setNonBlockingMode fd _ = return fd #endif }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 02:42:07 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 02:25:24 2009 Subject: [GHC] #3329: Errors Building 6.10.3 on NetBSD 4.0 Message-ID: <042.a79f04c63210b2fd7097ecd4b82fa86e@localhost> #3329: Errors Building 6.10.3 on NetBSD 4.0 -----------------------------+---------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86_64 (amd64) -----------------------------+---------------------------------------------- Trying to build 6.10.3 using 6.8.2 on an amd64 NetBSD 4.0, I ran into several problems. 1. `./configure --with-gmp-includes=/usr/pkg/include --with-gmp- libraries=/usr/pkg/lib` did not work; the build system could not find gmp.h. Changing libraries/Makefile to give the cabal setup command `--extra-include-dirs=/usr/pkg/include --extra-lib-dirs=/usr/pkg/lib` let it find the include file, but it still couldn't find the library. I finally had to symlink `/usr/lib/libgmp.so.3` to `/usr/pkg/lib/libgmp.so.3` to get it to compile and link. 2. It seems that the installPackage package triggers some thread issues: {{{ gmake -C installPackage with-stage-2 gmake[3]: Entering directory `/usr/local/ghc/src/ghc-6.10.3/utils/installPackage' /usr/local/ghc/src/ghc-6.10.3/libraries/cabal-bin /usr/pkg/bin/ghc /usr/local/ghc/src/ghc-6.10.3/libraries/bootstrapping.conf 1.6.0.3 configure --distpref dist-install \ --prefix=/NONEXISTENT --bindir=/NONEXISTENT --libdir=/NONEXISTENT --libexecdir=/NONEXISTENT --datadir=/NONEXISTENT --docdir=/NONEXISTENT --haddockdir=/NONEXISTENT --htmldir=/NONEXISTENT \ --with- compiler=/usr/local/ghc/src/ghc-6.10.3/ghc/stage2-inplace/ghc --with-hc- pkg=/usr/local/ghc/src/ghc-6.10.3/utils/ghc-pkg/install-inplace/bin/ghc- pkg --package-db /usr/local/ghc/src/ghc-6.10.3/stage3.package.conf \ --libsubdir='$pkgid' --with-gcc=gcc --with- ld=/usr/bin/ld --hsc2hs-option=-I/usr/pkg/include --configure-option ='--with-gmp-includes=/usr/pkg/include' --configure-option='--with-gmp- libraries=/usr/pkg/lib' --configure-option=--with-cc="gcc" --with- hsc2hs=/usr/local/ghc/src/ghc-6.10.3/utils/hsc2hs/install- inplace/bin/hsc2hs \ --constraint="Cabal == 1.6.0.3" Configuring installPackage-1.0... ghc: Error detected by libpthread: Invalid mutex. Detected by file "/u/production/nbsd/instance/nbsd/src-4/lib/libpthread/pthread_mutex.c", line 334, function "pthread_mutex_unlock". See pthread(3) for information. gmake[3]: *** [with-stage-2] Error 134 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 03:32:07 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 03:15:01 2009 Subject: [GHC] #3323: panic: funArgTy In-Reply-To: <047.8f9fe6697ba182cf9c87104ebe4c50fd@localhost> References: <047.8f9fe6697ba182cf9c87104ebe4c50fd@localhost> Message-ID: <056.68901242dda22addb476b1066ee3f5fd@localhost> #3323: panic: funArgTy --------------------------------------------+------------------------------- Reporter: simonmar | Owner: simonpj 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: typecheck/should_fail/T3323 | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------------+------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T3323 * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Thu Jun 25 00:23:40 PDT 2009 simonpj@microsoft.com * Fix Trac #3323: naughty record selectors again Ignore-this: 5ea70e631a2104ae7bf139f89a91a63a I boobed when I decoupled record selectors from their data types. The most straightforward and robust fix means attaching the TyCon of a record selector to its IfaceIdInfo, so you'll need to rebuild all .hi files That said, the fix is easy. }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 04:00:55 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 03:43:49 2009 Subject: [GHC] #3324: Add Foldable and Traversable instances for ((, ) a) In-Reply-To: <047.8947bef7cc0f665b60675f311754fd4d@localhost> References: <047.8947bef7cc0f665b60675f311754fd4d@localhost> Message-ID: <056.ae42cc94b34ca9494cea386a84cb8fa2@localhost> #3324: Add Foldable and Traversable instances for ((,) a) ------------------------------+--------------------------------------------- Reporter: YitzGale | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by YitzGale): As noted by Ross Paterson on the libraries list: yes, you are correct, I was wrong. Except that it should be noted that using fmapDefault will only work if an explicit implementation was provided for traverse, otherwise infinite recursion will result. The thread is here: http://www.haskell.org/pipermail/libraries/2009-June/011991.html I will paste below my next attempt that I posted to the list in reply to Ross. The ideas are: * to note the requirement of a traverse implementation * to make explicit what we mean by using these functions to create Functor and Foldable instances * to note more clearly the other use of the two default functions: to test the consistency of a Traversable instance against the Foldable and Functor instances. Of course another option would be to keep it simple - keep the original, with just an added note about the requirement of an explicit traverse. Here's the new proposal that I wrote in my reply to Ross: In the documentation for class Traversable, change (`fmapDefault`) to (see `fmapDefault`), similarly for foldMapDefault. Documentation for fmapDefault: {{{ -- | This function should be equivalent to `fmap` in -- the `Functor` superclass instance. If you do not -- already have a `Functor` instance, you can use -- this function to define one: -- -- > instance Functor T where -- > fmap = fmapDefault -- -- Note, however, that this will lead to infinite -- recursion if you did not provide an explicit -- implementation of the `traverse` method. }}} Documentation for foldMapDefault: {{{ -- This function should be equivalent to `foldMap` in -- the `Foldable` superclass instance. If you do not -- already have a `Foldable` instance, you -- can use this function to define one: -- -- > instance Foldable T where -- > foldMap = foldMapDefault }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 04:25:25 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 04:08:17 2009 Subject: [GHC] #3328: base's FD.hs defines and exports setNonBlockingMode on Windows hosts In-Reply-To: <042.8cf8b10d310cf365b8b72ab2173bc2f6@localhost> References: <042.8cf8b10d310cf365b8b72ab2173bc2f6@localhost> Message-ID: <051.7693152ebd8d40d7900d9530b8eb40ad@localhost> #3328: base's FD.hs defines and exports setNonBlockingMode on Windows hosts ----------------------------+----------------------------------------------- Reporter: shu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Windows | Architecture: x86 ----------------------------+----------------------------------------------- Changes (by shu): * summary: base's FD.hs defines exports setNonBlockingMode on Windows hosts => base's FD.hs defines and exports setNonBlockingMode on Windows hosts -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 04:55:54 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 04:38:47 2009 Subject: [GHC] #2120: Arrays allow out-of-bounds indexes In-Reply-To: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> References: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> Message-ID: <055.9d67af0c8b6b869e3e9f77f29c2db9de@localhost> #2120: Arrays allow out-of-bounds indexes ----------------------------------+----------------------------------------- Reporter: amthrax | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by simonpj): Triggered by this thread http://www.haskell.org/pipermail/haskell- cafe/2009-June/063399.html, I had quick look. There are two range tests under discussion * One tests every index supplied by the client of the array, against the original bounds. We should never leave this test out. * The other tests the `Int` offset computed by `index`, in case the `Ix` instance for this type is bogus. We can omit this check iff we trust the instance. The only safe thing to do (and Haskell is supposed to be a safe language) is to do both checks, thus (in `GHC.Arr`): {{{ safeIndex :: Ix i => (i, i) -> Int -> i -> Int safeIndex (l,u) n i = let i' = index (l,u) i in if (0 <= i') && (i' < n) then i' else error "Error in array index" }}} (Note the use of `index` rather than `unsafeIndex`.) To avoid the double test in the (wildly common) cases of indexing using the (trusted) built-in instances for `Int`, `(Int,Int)` etc, we could use a RULE to call version of `safeIndex` that did only one test. Furthermore, we should improve the "Error in array index" error message. If we have the first client-oriented test in place, then this second error can read something like "The index method for an Ix instance returned offset N, but the array has size M". I don't see how to say ''which'' type, sadly. `Typeable` is not a superclass of `Ix`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 04:57:33 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 04:40:26 2009 Subject: [GHC] #2120: Arrays allow out-of-bounds indexes In-Reply-To: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> References: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> Message-ID: <055.ece40d0477f306a118e6087f770fac48@localhost> #2120: Arrays allow out-of-bounds indexes ----------------------------------+----------------------------------------- Reporter: amthrax | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonpj): * priority: normal => high Comment: I'll change this to high priority to make sure we get to it for 6.12. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 09:08:20 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 08:51:12 2009 Subject: [GHC] #3316: Deadlock in non-threaded RTS with hPutBuf In-Reply-To: <045.c4804c6e196e261ae7140fb9ed110793@localhost> References: <045.c4804c6e196e261ae7140fb9ed110793@localhost> Message-ID: <054.83a75880c22c6b1486d315fa63fa5430@localhost> #3316: Deadlock in non-threaded RTS with hPutBuf -------------------------+-------------------------------------------------- Reporter: ganesh | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Tue Jun 23 06:44:06 PDT 2009 Simon Marlow * Fix #3316: use O_NONBLOCK on GHC's end of the pipe Ignore-this: f2110bc863ba7028495d09416d419241 But clear the O_NONBLOCK flag if we pass this FD to another sub-process using createProcess with UseHandle. }}} I'm not going to merge this into 6.10.4 however, since this code has changed a lot between 6.10 and HEAD, and it's a potentially destabilising change. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 09:11:35 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 08:54:26 2009 Subject: [GHC] #3327: Cannot paste into ghci on windows In-Reply-To: <043.4776861a900af51ee3315be8ee4af71f@localhost> References: <043.4776861a900af51ee3315be8ee4af71f@localhost> Message-ID: <052.10a5f24305a703c575ad2026ca16867e@localhost> #3327: Cannot paste into ghci on windows -----------------------+---------------------------------------------------- Reporter: boml | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.4 Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by simonmar): * difficulty: => Unknown * milestone: => 6.10.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 09:13:48 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 08:56:40 2009 Subject: [GHC] #3328: base's FD.hs defines and exports setNonBlockingMode on Windows hosts In-Reply-To: <042.8cf8b10d310cf365b8b72ab2173bc2f6@localhost> References: <042.8cf8b10d310cf365b8b72ab2173bc2f6@localhost> Message-ID: <051.0a7efe8da32ca1717a156b04f8e99050@localhost> #3328: base's FD.hs defines and exports setNonBlockingMode on Windows hosts -------------------------------+-------------------------------------------- Reporter: shu | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Sorry, my fault. Now fixed: {{{ Thu Jun 25 02:46:09 PDT 2009 Simon Marlow * fix build failure on Windows }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 09:54:11 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 09:37:03 2009 Subject: [GHC] #3330: Type checker hangs Message-ID: <060.111b0979bdfa1b272261462ee3c542d4@localhost> #3330: Type checker hangs ----------------------------------+----------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ----------------------------------+----------------------------------------- The following module causes `ghc --make` and `ghci` to hang. `-ddump-tc- trace` produces output indefinitely. {{{ {-# LANGUAGE GADTs #-} {-# LANGUAGE FlexibleContexts #-} import Generics.MultiRec import Control.Monad.Writer data AnyF s f where AnyF :: s ix -> f ix -> AnyF s f children :: HFunctor s (PF s) => s ix -> (PF s) r ix -> [AnyF s r] children p x = execWriter (hmapM p collect x) where collect :: (HFunctor s (PF s)) => s ix -> r ix -> Writer [AnyF s r] (r ix) collect w x = tell [AnyF w x] >> return x }}} Module `Generics.MultiRec` is from Hackage package `multirec-0.4`. The code contains a type error: if arguments `p` and `collect` are swapped the code compiles fine. I haven't tried making this example any smaller. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 11:15:04 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 10:57:55 2009 Subject: [GHC] #3303: Allow multi-line deprecation messages. In-Reply-To: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> References: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> Message-ID: <054.a49a83012251bbc366c874e3fbc8fe49@localhost> #3303: Allow multi-line deprecation messages. ---------------------------------+------------------------------------------ Reporter: duncan | 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: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Concerning line wrapping, it's not clear that you want GHC to re-wrap your text at arbitrary places. You might care where the line breaks are. How about this: instead of giving one string, you can instead give a list of strings, which are displayed on successive lines. So input is: {{{ {-# DEPRECATED defaultUserHooks ["Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2" , "compatibility in which case you must stick with defaultUserHooks"] #-} }}} The output would look as you'd expect. This is nice because it's backward compatible, and deals with points from the original report. Concerning constructors vs types, the very same thing comes up with fixity declarations, at least when you use GHC's ability to have infix type constructors: {{{ infix 4 :+: }}} I'd be happy with a disambiguating prefix `constructor`, `type`, or `class`; at least when there ''was'' ambiguity. That means making `constructor` a new `special_id`, but it wouldn't be a keyword except in these two special situations, like other `special_id`s. Comments? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 11:25:32 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 11:08:23 2009 Subject: [GHC] #3330: Type checker hangs In-Reply-To: <060.111b0979bdfa1b272261462ee3c542d4@localhost> References: <060.111b0979bdfa1b272261462ee3c542d4@localhost> Message-ID: <069.a0162542f2bdc79a62d6c6df889d1214@localhost> #3330: Type checker hangs -------------------------------------+-------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------+-------------------------------------- Changes (by MartijnVanSteenbergen): * version: 6.10.1 => 6.10.3 Comment: Reproducible in GHC 6.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 12:09:56 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 11:52:46 2009 Subject: [GHC] #3322: Tag base libraries In-Reply-To: <047.6380de96933ec553e06c3fee90642415@localhost> References: <047.6380de96933ec553e06c3fee90642415@localhost> Message-ID: <056.5e16cf64dbd1f49c2435eb47b2de7ef6@localhost> #3322: Tag base libraries ---------------------------------+------------------------------------------ Reporter: YitzGale | Owner: Type: task | Status: closed Priority: normal | Milestone: 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 * difficulty: => Unknown * resolution: => fixed Comment: I've done `darcs tag --checkpoint && darcs optimize` in all the repos. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 13:58:07 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 13:40:58 2009 Subject: [GHC] #3311: web page direct me to a tarball that can't build In-Reply-To: <044.afa23adcfce0291b03d71c955864f234@localhost> References: <044.afa23adcfce0291b03d71c955864f234@localhost> Message-ID: <053.b6f8fd5c237834612271e8c12532d7b9@localhost> #3311: web page direct me to a tarball that can't build ---------------------------------+------------------------------------------ Reporter: zooko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | 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: Aha, thanks. I've added the missing files to the source dists. Running `sh boot` with `ghc-6.11.20090624-src.tar.bz2` works. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 14:58:48 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 14:41:39 2009 Subject: [GHC] #3331: control-monad-queue performance regression Message-ID: <046.199bea4da34b828d923df9304139778a@localhost> #3331: control-monad-queue performance regression -------------------------------------+-------------------------------------- Reporter: lpsmith | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------+-------------------------------------- {{{ $ cabal unpack control-monad-queue $ cd control-monad-queue-0.0.9.1/tests $ ghc --make -O2 Time.hs -i.. $ ./Time allison 34 20 $ ./Time corec1 34 20 $ ./Time corec2 34 20 }}} Runs anywhere from 16-32% slower on GHC 6.10.3 than GHC 6.8.3, and allocates significantly more memory. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Jun 25 20:01:14 2009 From: trac at galois.com (GHC) Date: Thu Jun 25 19:44:08 2009 Subject: [GHC] #3330: Type checker hangs In-Reply-To: <060.111b0979bdfa1b272261462ee3c542d4@localhost> References: <060.111b0979bdfa1b272261462ee3c542d4@localhost> Message-ID: <069.07626b4392a8368e532ef92375cee3b2@localhost> #3330: Type checker hangs -------------------------------------+-------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------+-------------------------------------- Comment (by chak): Would you mind trying with the current development version? There have been significant changes to the type checker (and I haven't got multirec handy). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 26 02:45:23 2009 From: trac at galois.com (GHC) Date: Fri Jun 26 02:28:35 2009 Subject: [GHC] #3330: Type checker hangs In-Reply-To: <060.111b0979bdfa1b272261462ee3c542d4@localhost> References: <060.111b0979bdfa1b272261462ee3c542d4@localhost> Message-ID: <069.3ef5fc75b83fff6eee571ecfc3ccec4b@localhost> #3330: Type checker hangs -------------------------------------+-------------------------------------- Reporter: MartijnVanSteenbergen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------+-------------------------------------- Comment (by MartijnVanSteenbergen): I'm afraid that will take me a significant amount of time. :-( What I've done instead is change the example to be independent of multirec, moving some definitions into the snippet. I've also tried to make it smaller, removing some function arguments, type arguments and class constraints and replacing definitions by undefined. In what is left I cannot find anything else I can remove without causing GHC not to hang anymore. {{{ {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} import Control.Monad.Writer data AnyF (s :: * -> *) = AnyF class HFunctor (f :: (* -> *) -> * -> *) type family PF (phi :: * -> *) :: (* -> *) -> * -> * children :: s ix -> (PF s) r ix -> [AnyF s] children p x = execWriter (hmapM p collect x) collect :: HFunctor (PF s) => s ix -> r ix -> Writer [AnyF s] (r ix) collect = undefined hmapM :: (forall ix. phi ix -> r ix -> m (r' ix)) -> phi ix -> f r ix -> m (f r' ix) hmapM = undefined }}} Does that help? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 26 09:17:24 2009 From: trac at galois.com (GHC) Date: Fri Jun 26 09:00:13 2009 Subject: [GHC] #3319: Template Haskell generates invalid code for import foreign address declaration In-Reply-To: <044.e25f5d73903b316ad0c30309f677e836@localhost> References: <044.e25f5d73903b316ad0c30309f677e836@localhost> Message-ID: <053.569de32fb57a776ea3e3dd0b7ef7dd3e@localhost> #3319: Template Haskell generates invalid code for import foreign address declaration ---------------------------------+------------------------------------------ Reporter: awson | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.3 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => fixed * os: Windows => Unknown/Multiple * milestone: => 6.12.1 Comment: Fixed: {{{ Fri Jun 26 10:54:21 BST 2009 Simon Marlow * Fix #3319, and do various tidyups at the same time - converting a THSyn FFI declaration to HsDecl was broken; fixed - pretty-printing of FFI declarations was variously bogus; fixed - there was an unused "library" field in CImport; removed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 26 12:52:44 2009 From: trac at galois.com (GHC) Date: Fri Jun 26 12:35:32 2009 Subject: [GHC] #3332: take n (take m list) returns [] for some m. Message-ID: <045.db9b644f43a950ee14a0bf08b51c7820@localhost> #3332: take n (take m list) returns [] for some m. -------------------+-------------------------------------------------------- Reporter: fcamel | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- See the example below. I think the second output should be [1], too. I also tried ghc and runghc, and the results were the same. {{{ ghci> take 1 (take (10^11) [1..]) [1] it :: [Integer] ghci> take 1 (take (10^12) [1..]) [] it :: [Integer] ghci> take 1 (take (10^13) [1..]) [1] it :: [Integer] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Jun 26 13:43:08 2009 From: trac at galois.com (GHC) Date: Fri Jun 26 13:25:56 2009 Subject: [GHC] #3332: take n (take m list) returns [] for some m. In-Reply-To: <045.db9b644f43a950ee14a0bf08b51c7820@localhost> References: <045.db9b644f43a950ee14a0bf08b51c7820@localhost> Message-ID: <054.01aea676b5cdc05c7f4250c13c92a13e@localhost> #3332: take n (take m list) returns [] for some m. -------------------------+-------------------------------------------------- Reporter: fcamel | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Thanks for the report. But actually, this is not a bug: On a 32bit machine, `(10^12) :: Int` is `-727379968`. This will give you `[1]`: {{{ import Data.List take 1 (genericTake (10^12) [1..]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Jun 27 19:59:42 2009 From: trac at galois.com (GHC) Date: Sat Jun 27 19:42:28 2009 Subject: [GHC] #3333: GHCi doesn't load weak symbols Message-ID: <047.f7df20b3080234226b9f5744151738a8@localhost> #3333: GHCi doesn't load weak symbols ----------------------------------+----------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.3 | Severity: normal Keywords: weak, dynamic loading | Testcase: Os: Linux | Architecture: x86 ----------------------------------+----------------------------------------- GHCi fails to load modules with weak symbols. The compiler, in contrast, has no trouble with them. The attached Cabal package demonstrates the problem. After building and installing: {{{ :Prelude> :m +WeakTest Prelude WeakTest> weak_test 0 Loading package WeakTest-0 ... linking ... : /home/cirodrig/.cabal/lib/WeakTest-0/ghc-6.10.3/HSWeakTest-0.o: unknown symbol `weak_test' }}} I encountered this problem while trying to build a package that contains C++ code. Because GCC generates weak symbols when compiling C++, libraries that contain C++ code will not work in GHCi. (Granted, this is not the only problem with mixing C++ and Haskell.) -- Ticket URL: GHC The Glasgow Haskell Compiler From conal at conal.net Sun Jun 28 00:39:50 2009 From: conal at conal.net (Conal Elliott) Date: Sun Jun 28 00:22:53 2009 Subject: panic "initC: srt_lbl" on 6.10.3 Message-ID: I'm getting "panic! (the 'impossible' happened) / initC: srt_lbl" in ghc 6.10.3. Does anyone have an educated guess about initC: srt_lbl ? Oddly, ghci doesn't throw the panic. When I comment out some GADT code, the panic goes away. - Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/glasgow-haskell-bugs/attachments/20090628/d0c898c2/attachment.html From trac at galois.com Sun Jun 28 08:13:21 2009 From: trac at galois.com (GHC) Date: Sun Jun 28 07:56:20 2009 Subject: [GHC] #3290: Add Functor, Applicative, Monad, and Monoid instances for ParseResult In-Reply-To: <047.533c2be1a845c9c65a70d5ca34eb8067@localhost> References: <047.533c2be1a845c9c65a70d5ca34eb8067@localhost> Message-ID: <056.e15f2888e2198b4e747a083d3e3bf37c@localhost> #3290: Add Functor, Applicative, Monad, and Monoid instances for ParseResult -------------------------------+-------------------------------------------- Reporter: YitzGale | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.11 Severity: normal | Resolution: Keywords: haskell-src | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Changes (by YitzGale): * version: 6.10.3 => 6.11 Comment: The discussion period of two weeks announced on the libraries mailing list has passed. Other than noting that the patch has already been applied to haskell-src-exts, there has been no further discussion. Please apply the patch and close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 28 09:35:17 2009 From: trac at galois.com (GHC) Date: Sun Jun 28 09:18:10 2009 Subject: [GHC] #3290: Add Functor, Applicative, Monad, and Monoid instances for ParseResult In-Reply-To: <047.533c2be1a845c9c65a70d5ca34eb8067@localhost> References: <047.533c2be1a845c9c65a70d5ca34eb8067@localhost> Message-ID: <056.fb22dfefac0c0f89ead2a2a2ad2ce032@localhost> #3290: Add Functor, Applicative, Monad, and Monoid instances for ParseResult -------------------------------+-------------------------------------------- Reporter: YitzGale | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.11 Severity: normal | Resolution: fixed Keywords: haskell-src | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Changes (by ross): * status: new => closed * resolution: => fixed Comment: applied -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 28 13:49:57 2009 From: trac at galois.com (GHC) Date: Sun Jun 28 13:32:41 2009 Subject: [GHC] #3333: GHCi doesn't load weak symbols In-Reply-To: <047.f7df20b3080234226b9f5744151738a8@localhost> References: <047.f7df20b3080234226b9f5744151738a8@localhost> Message-ID: <056.a3bee78cb145da619d96737d7910ac8e@localhost> #3333: GHCi doesn't load weak symbols -----------------------------------+---------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: Keywords: weak, dynamic loading | Testcase: Os: Linux | Architecture: x86 -----------------------------------+---------------------------------------- Comment (by heatsink): I investigated the linking rules for weak symbols in ELF, http://www.skyfree.org/linux/references/ELF_Format.pdf . If I understand correctly, the linking precedence is: global undefined < weak undefined < weak defined < global defined The highest-precedence symbol is used for relocation. If it's "weak undefined", then the symbol gets an absolute address of NULL. If "weak defined", an arbitrary definition of the symbol is chosen. This should be do-able when loading a batch of object files. Because libraries get loaded incrementally, not all situations can be handled properly. If a previously loaded weak symbol would get "promoted" to a higher precedence, GHCi will have to abort, as it currently does for conflicting global definitions. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 28 16:58:05 2009 From: trac at galois.com (GHC) Date: Sun Jun 28 16:40:49 2009 Subject: [GHC] #3279: Segmentation fault in reactive program In-Reply-To: <045.28ccfad62541fcb8fe7651779666954e@localhost> References: <045.28ccfad62541fcb8fe7651779666954e@localhost> Message-ID: <054.f9fcfc2a91104a7f3d5bd99e54c32a37@localhost> #3279: Segmentation fault in reactive program -------------------------------+-------------------------------------------- Reporter: Baughn | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.4 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 28 16:58:18 2009 From: trac at galois.com (GHC) Date: Sun Jun 28 16:41:00 2009 Subject: [GHC] #3317: Ctrl-C is not received during a call to runProcess In-Reply-To: <044.b8fbf935b40c287d4e3429d36f807f8e@localhost> References: <044.b8fbf935b40c287d4e3429d36f807f8e@localhost> Message-ID: <053.d328753be261507cfc7c5bff385c3660@localhost> #3317: Ctrl-C is not received during a call to runProcess ----------------------------------+----------------------------------------- Reporter: judah | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.4 Component: libraries/process | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 28 16:59:06 2009 From: trac at galois.com (GHC) Date: Sun Jun 28 16:41:48 2009 Subject: [GHC] #3327: Cannot paste into ghci on windows In-Reply-To: <043.4776861a900af51ee3315be8ee4af71f@localhost> References: <043.4776861a900af51ee3315be8ee4af71f@localhost> Message-ID: <052.6006d7f525554befb0f83d7100972f96@localhost> #3327: Cannot paste into ghci on windows -----------------------+---------------------------------------------------- Reporter: boml | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.4 Component: GHCi | 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: I've pulled the important patches from that tag. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 28 18:25:38 2009 From: trac at galois.com (GHC) Date: Sun Jun 28 18:09:27 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.4c08c9a8582cd367a70861bfe92d6741@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 | ----------------------------------------+----------------------------------- Comment (by SamB): Well, we had a conversation about this on IRC today, and Cale has convinced me that there is a bug in the definition of ~ in your papers. The main reason that newtypes exist is 1) to ensure that things are not confused with the original type, and 2) to allow separate instances to be written without overhead.[[BR]] For ~ to resolve them as the same type goes against both.[[BR]] Basically, the way that ~ is treating newtype right now is how it ought to be treating 'type' -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 28 19:00:45 2009 From: trac at galois.com (GHC) Date: Sun Jun 28 18:43:26 2009 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@localhost> References: <045.2638646abdcf216191d07c9810407703@localhost> Message-ID: <054.7ff731ec166e4382e2d9a63d1c9521f5@localhost> #2893: Implement "Quantified contexts" proposal ---------------------------------+------------------------------------------ Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: proposal | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by porges): A short version... we allow contexts of the form: {{{ (forall a. Bar f a) => Foo f }}} And more generally, these contexts can have contexts of their own: {{{ (forall a. (Baz a) => Bar f a) => Foo f }}} I'm not sure if the 'more general' version adds extra difficulty in type- checking, as I am not very familiar with its intricacies. Forgive my stupidity, I don't understand where the typechecking (at least in the first) becomes so difficult?the context means that there is an instance available which is free in the specified variable. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Jun 28 22:43:34 2009 From: trac at galois.com (GHC) Date: Sun Jun 28 22:26:15 2009 Subject: [GHC] #3334: Strange closure type error on macports GHC 6.10.1 Message-ID: <047.f82e382278d17b45a86383d3a24d0c2d@localhost> #3334: Strange closure type error on macports GHC 6.10.1 ---------------------+------------------------------------------------------ Reporter: crutcher | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple ---------------------+------------------------------------------------------ user 0m2.453s sys 0m0.396s crutcher-mac:~/haskell crutcher$ time ./cell +RTS -N2 cell: internal error: evacuate: strange closure type 63559 (GHC version 6.10.1 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap real 0m1.258s user 0m1.459s sys 0m0.203s crutcher-mac:~/haskell crutcher$ ls Cell.hi Cell.hs Cell.o cell rwh.4.hs crutcher-mac:~/haskell crutcher$ rm Cell.hi Cell.o cell crutcher-mac:~/haskell crutcher$ ghc -O2 Cell.hs -o cell --make -threaded [1 of 1] Compiling Main ( Cell.hs, Cell.o ) Linking cell ... crutcher-mac:~/haskell crutcher$ time ./cell +RTS -N2 cell: internal error: evacuate: strange closure type 34063 (GHC version 6.10.1 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug real 0m0.730s user 0m0.826s sys 0m0.122s -- Ticket URL: GHC The Glasgow Haskell Compiler From marlowsd at gmail.com Mon Jun 29 05:27:37 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Mon Jun 29 05:10:19 2009 Subject: panic "initC: srt_lbl" on 6.10.3 In-Reply-To: References: Message-ID: <4A488909.8090005@gmail.com> On 28/06/2009 05:39, Conal Elliott wrote: > I'm getting "panic! (the 'impossible' happened) / initC: srt_lbl" in ghc > 6.10.3. Does anyone have an educated guess about initC: srt_lbl ? > Oddly, ghci doesn't throw the panic. > > When I comment out some GADT code, the panic goes away. It's a pretty generic failure. -dcore-lint might trigger a failure earlier, but that probably won't help you. We need to reproduce the bug. Can you tell us how? (don't worry if the code depends on external packages, but ideally keep the dependencies to a minimum if you can). Cheers, Simon From trac at galois.com Mon Jun 29 05:56:27 2009 From: trac at galois.com (GHC) Date: Mon Jun 29 05:39:07 2009 Subject: [GHC] #3334: Strange closure type error on macports GHC 6.10.1 In-Reply-To: <047.f82e382278d17b45a86383d3a24d0c2d@localhost> References: <047.f82e382278d17b45a86383d3a24d0c2d@localhost> Message-ID: <056.c7c60707a180c2fda00d9775cfc1877e@localhost> #3334: Strange closure type error on macports GHC 6.10.1 ---------------------------------+------------------------------------------ Reporter: crutcher | 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: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown * milestone: => 6.12.1 Comment: Not reproducible here with 6.10.3 on x86-Linux or x86-64-Linux. Could you try upgrading GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 29 06:26:51 2009 From: trac at galois.com (GHC) Date: Mon Jun 29 06:09:52 2009 Subject: [GHC] #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. In-Reply-To: <047.158ac52b7977b3e9f47680935a918275@localhost> References: <047.158ac52b7977b3e9f47680935a918275@localhost> Message-ID: <056.c7614f0b02bf5f007a0a640246079323@localhost> #635: Replace use of select() in the I/O manager with epoll/kqueue/etc. ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by hajile): * cc: elijah.epifanov@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 29 08:42:58 2009 From: trac at galois.com (GHC) Date: Mon Jun 29 08:25:38 2009 Subject: [GHC] #3335: make some Applicative functions into methods, and split off Data.Functor Message-ID: <043.088ab986c5172cef4daab943f384779a@localhost> #3335: make some Applicative functions into methods, and split off Data.Functor -----------------------------+---------------------------------------------- Reporter: ross | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The following functions {{{ (<$) :: Functor f => a -> f b -> f a (*>) :: Applicative f => f a -> f b -> f b (<*) :: Applicative f => f a -> f b -> f a some :: Alternative f => f a -> f [a] many :: Alternative f => f a -> f [a] }}} are moved into the corresponding classes, with the existing implementations as default definitions. This gives people creating instances the option of defining specialized implementations of these functions, though they should be equivalent to the default definitions. Although (<$) is now a method of the Functor class, it is hidden in the re-export by the Prelude, Control.Monad and Monad. The new module Data.Functor exposes the full class, plus the function (<$>). These are also re-exported by Control.Applicative. Discussion on libraries@haskell.org to 20th July 2009. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 29 10:32:02 2009 From: trac at galois.com (GHC) Date: Mon Jun 29 10:14:42 2009 Subject: [GHC] #3336: Following gcc behaviour with regards to calling conventions on x86_64 Message-ID: <053.2867833c6ad9a83e8721822ccc5e3e0d@localhost> #3336: Following gcc behaviour with regards to calling conventions on x86_64 ----------------------------------------+----------------------------------- Reporter: JeffersonHeard | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: calling convention, stdcall | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------------------------+----------------------------------- 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 Jun 29 12:50:48 2009 From: trac at galois.com (GHC) Date: Mon Jun 29 12:33:37 2009 Subject: [GHC] #3082: Unclear warning message: Attempting to re-export hidden constructors In-Reply-To: <042.a5c4cd3afa0abc022930d0824ba94bfa@localhost> References: <042.a5c4cd3afa0abc022930d0824ba94bfa@localhost> Message-ID: <051.b727effd8c2f0f238b4be1f83509808c@localhost> #3082: Unclear warning message: Attempting to re-export hidden constructors ---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by ross): * type: proposal => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 29 12:51:38 2009 From: trac at galois.com (GHC) Date: Mon Jun 29 12:34:17 2009 Subject: [GHC] #3072: considerations for management of shared libs In-Reply-To: <045.6f777a46b5d4eb212ac94c917f9f3ef8@localhost> References: <045.6f777a46b5d4eb212ac94c917f9f3ef8@localhost> Message-ID: <054.91912ce73ccd4eb827b6e5c0e6168c27@localhost> #3072: considerations for management of shared libs ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Package system | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by ross): * type: proposal => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 29 12:52:38 2009 From: trac at galois.com (GHC) Date: Mon Jun 29 12:35:17 2009 Subject: [GHC] #2254: have Control.Arrow re-export (>>>) and (<<<) In-Reply-To: <043.08bb6362803b2111fd61efa7055513a2@localhost> References: <043.08bb6362803b2111fd61efa7055513a2@localhost> Message-ID: <052.bdab2d855f44acf8ebeb6d375e915b3a@localhost> #2254: have Control.Arrow re-export (>>>) and (<<<) ---------------------------------+------------------------------------------ Reporter: ross | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by ross): * status: new => closed * resolution: => fixed Comment: fait accompli -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Jun 29 19:07:42 2009 From: trac at galois.com (GHC) Date: Mon Jun 29 18:50:23 2009 Subject: [GHC] #2813: Create a utf8 bytestring-a-like In-Reply-To: <044.ad636022be236bf694f594b538272960@localhost> References: <044.ad636022be236bf694f594b538272960@localhost> Message-ID: <053.4587a0912d98e17a910219dd9bb3582e@localhost> #2813: Create a utf8 bytestring-a-like ----------------------------------+----------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | 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 Tue Jun 30 05:06:12 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 04:48:58 2009 Subject: [GHC] #3300: System.IO and System.Directory functions not Unicode-aware under Windows In-Reply-To: <042.70f85210b7c6f2f297e9bed1b5b08002@localhost> References: <042.70f85210b7c6f2f297e9bed1b5b08002@localhost> Message-ID: <051.9110e8be4b1d6e7c810f318b38a629e0@localhost> #3300: System.IO and System.Directory functions not Unicode-aware under Windows ------------------------------------+--------------------------------------- Reporter: shu | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/directory | Version: 6.11 Severity: major | Resolution: fixed Keywords: unicode | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: These changes are now complete. libraries/Win32: {{{ Mon Jun 29 03:47:50 PDT 2009 Simon Marlow * add SHGetFolderPath support }}} libraries/directory: {{{ Mon Jun 29 04:26:04 PDT 2009 Simon Marlow * move Win32 SearchPath and SHGetFolderPath into the Win32 package }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 30 05:41:19 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 05:24:02 2009 Subject: [GHC] #1884: Win64 Port In-Reply-To: <047.1fa130761f7e9ddaef7c551aeff5576e@localhost> References: <047.1fa130761f7e9ddaef7c551aeff5576e@localhost> Message-ID: <056.f63492dc20b12ff50bcfc2210584dbc5@localhost> #1884: Win64 Port -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * milestone: 6.12.1 => _|_ Comment: We have no immediate plans to work on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 30 05:50:01 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 05:37:06 2009 Subject: [GHC] #2970: detecting readline in top-level ./configure is no guarantee of readline support In-Reply-To: <045.071488a2ab1aa6304b45ea4e23fd8c3b@localhost> References: <045.071488a2ab1aa6304b45ea4e23fd8c3b@localhost> Message-ID: <054.3d988536331080fa7f0c48f426be5b5b@localhost> #2970: detecting readline in top-level ./configure is no guarantee of readline support ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: we're using haskeline now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 30 05:58:57 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 05:41:36 2009 Subject: [GHC] #3232: Remove registerised -fvia-C In-Reply-To: <044.8ef2aabc1c214894ed9094970ca92d33@localhost> References: <044.8ef2aabc1c214894ed9094970ca92d33@localhost> Message-ID: <053.6d604ac2136d76464eadac5d28eb4ed4@localhost> #3232: Remove registerised -fvia-C ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 6.14 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: 6.12.1 => 6.14 branch Comment: Not likely for 6.12.x. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 30 05:59:40 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 05:42:22 2009 Subject: [GHC] #3254: add a configure option to turn off profiling In-Reply-To: <050.9d9a599d02ae49f1bbe8ca17c16117c7@localhost> References: <050.9d9a599d02ae49f1bbe8ca17c16117c7@localhost> Message-ID: <059.74e165e26e6734693ef29bc72f19d0bf@localhost> #3254: add a configure option to turn off profiling ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 30 06:01:38 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 05:44:21 2009 Subject: [GHC] #2833: internal error: throwTo: unrecognised why_blocked value In-Reply-To: <044.241eea212892e1f7fdf89a6a715bfb1f@localhost> References: <044.241eea212892e1f7fdf89a6a715bfb1f@localhost> Message-ID: <053.662f8a0500c7b17eb02ae4b38f5f6829@localhost> #2833: internal error: throwTo: unrecognised why_blocked value ---------------------------------+------------------------------------------ Reporter: lilac | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: No response; closing as fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 30 06:07:15 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 05:49:59 2009 Subject: [GHC] #3045: GHCI Crashes Under Windows when loading compiled code In-Reply-To: <045.753f237853c90b31fef839a556ac402c@localhost> References: <045.753f237853c90b31fef839a556ac402c@localhost> Message-ID: <054.bee8f8580ece4c77911fa171b01a78dc@localhost> #3045: GHCI Crashes Under Windows when loading compiled code -------------------------+-------------------------------------------------- Reporter: jburck | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: No response; closing as dup of #2973 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 30 07:57:07 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 07:39:44 2009 Subject: [GHC] #3337: Proposal: expose Unicode and newline translation from System.IO Message-ID: <047.51c010c54df2cc5daad1df04dbf9cffa@localhost> #3337: Proposal: expose Unicode and newline translation from System.IO -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- For the proposed new additions, see: * [http://www.haskell.org/~simonmar/base/System-IO.html#23 System.IO (Unicode encoding/decoding)] * [http://www.haskell.org/~simonmar/base/System-IO.html#25 System.IO (Newline conversion)] Patch, and Haddocks for the base package, attached. Discussion period: 2 weeks (14 July). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 30 12:31:30 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 12:14:07 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.9c0ac54c8d7630f2f90f51cdc5e456c7@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 guest): * cc: gwern0@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 30 12:37:15 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 12:19:56 2009 Subject: [GHC] #3338: Revert to old key bindings in ghci Message-ID: <045.35191b7c6f5ee392dc082d2230077aa6@localhost> #3338: Revert to old key bindings in ghci -----------------------------+---------------------------------------------- Reporter: Raevel | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.10.3 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- As of GHC 6.10.3, ghci uses Haskeline. Some of the key bindings that previously existed are no longer bound. For instance, C-p/C-n were previously bound to the same keys as up/down arrow respectively. I have only tested this on Mac OS X 10.5, but I assume it is an issue for all OS's. I would like C-p/C-n to be bound like they were previously. The following lines in .haskeline do what I request: bind: ctrl-p up bind: ctrl-n down -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 30 14:38:07 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 14:20:45 2009 Subject: [GHC] #3338: Revert to old key bindings in ghci In-Reply-To: <045.35191b7c6f5ee392dc082d2230077aa6@localhost> References: <045.35191b7c6f5ee392dc082d2230077aa6@localhost> Message-ID: <054.4fd46458ffc3db3269498f2265657851@localhost> #3338: Revert to old key bindings in ghci ------------------------------+--------------------------------------------- Reporter: Raevel | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: minor | Resolution: fixed Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by judahj): * status: new => closed * resolution: => fixed Comment: Thanks for the report! We've already added those bindings in the development repo of Haskeline, so they should be included in ghc-6.12.1. If you come across any more key bindings that you'd like added, please log a ticket at http://trac.haskell.org/haskeline. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 30 17:36:04 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 17:18:39 2009 Subject: [GHC] #3339: Data.Monoid: Add (+>) as a synonym for mappend Message-ID: <042.626638ce45ff16ad4ce623d16cab0138@localhost> #3339: Data.Monoid: Add (+>) as a synonym for mappend -----------------------------+---------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This proposal was, I think, originally suggested by Jules Bean. The idea is to add two functions to the `Data.Monoid` module, `(+>)` and `(<+)`, corresponding to different uses of `mappend`. These should not be methods of the `Monoid` typeclass, but top-level functions. I hope (but slightly doubt) that the visual nature of the two operators might help to counter the thought that monoids are just for gluing things together. {{{ (+>) :: (Monoid a) => a -> a -> a a +> b = a `mappend` b (<+) :: (Monoid a) => a -> a -> a a <+ b = b `mappend` a infixl 4 +> infixl 4 <+ }}} Proposed deadline: two weeks. If this looks reasonable, I'll attach darcs patches. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 30 19:22:11 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 19:04:46 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.55ab5c8f0447909c341dc2f4cc706875@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): I dislike the asymmetry. The ++ operator is not commutative but we don't artificially make it visually asymmetric. Why not take Ross's proposal and use <> as in Data.Sequence. For the sake of the discussion, perhaps someone should also explain why we cannot just generalise the type of ++. There's a separate argument that we should not. Also, what is the purpose of the flipped append? Why do we want to dedicate a symbol for flipped append? I use monoid operations a lot and I cannot think of a single use of flipped append. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 30 22:30:42 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 22:13:49 2009 Subject: [GHC] #3012: A little deriving for GADTs In-Reply-To: <044.94324394f531ef37390c0c5f7ffabb55@localhost> References: <044.94324394f531ef37390c0c5f7ffabb55@localhost> Message-ID: <053.7519379636e837abdc0c5ec9210b9d43@localhost> #3012: A little deriving for GADTs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by FSalad): * cc: daniels@community.haskell.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 30 22:39:50 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 22:22:40 2009 Subject: [GHC] #3012: A little deriving for GADTs In-Reply-To: <044.94324394f531ef37390c0c5f7ffabb55@localhost> References: <044.94324394f531ef37390c0c5f7ffabb55@localhost> Message-ID: <053.fca53b2d62125af31dd0e71c0432a085@localhost> #3012: A little deriving for GADTs ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by FSalad): Replying to [comment:1 simonpj]: > So perhaps we should accept ANY data type (GADT or whatever) with standalone deriving, and say "it's your fault" if the derived code doesn't typecheck? Sounds like a good idea. I've written several completely boilerplate instances for GADTs recently and this would have been very convenient :) I wouldn't find "it's your fault"-type behaviour unintuitive for StandaloneDeriving. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Jun 30 23:10:46 2009 From: trac at galois.com (GHC) Date: Tue Jun 30 22:53:22 2009 Subject: [GHC] #2979: better support for FFI C wrappers for macros in system headers In-Reply-To: <045.050d142d1954d12d764c4cd94c9c38c8@localhost> References: <045.050d142d1954d12d764c4cd94c9c38c8@localhost> Message-ID: <054.712b144963b38872c33f9c6ad41dd2d2@localhost> #2979: better support for FFI C wrappers for macros in system headers ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | 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 iquiw): * cc: iku.iwasa@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler