From trac at galois.com Mon Dec 1 03:29:47 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 03:23:16 2008 Subject: [GHC] #2729: Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version) In-Reply-To: <047.e60b778bc8c8ee75007c390c57c1ee7f@localhost> References: <047.e60b778bc8c8ee75007c390c57c1ee7f@localhost> Message-ID: <056.e5c6aa03a03221b29cba131ed00654d3@localhost> #2729: Stuck when compiling XMonad.StackSet in xmonad 0.9 (hackage version) -------------------------------+-------------------------------------------- Reporter: mnislaih | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by simonpj): Excellent news! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 04:22:39 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 04:16:09 2008 Subject: [GHC] #2440: Bad code with type families In-Reply-To: <041.36cfaf77666d90945b8031e68cebdd8a@localhost> References: <041.36cfaf77666d90945b8031e68cebdd8a@localhost> Message-ID: <050.818bed28f59b65b2a95e89ec658ed0ea@localhost> #2440: Bad code with type families -----------------------------------------+---------------------------------- Reporter: rl | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by simonpj): Yes, I think that's exactly the problem. The eta-expander needs to be smarter. But, as you pointed out when we met, in general that means making use of the coercion terms in the expression; we can no longer say "this term e of type ty has arity 3; please eta-expand it", because the coercion terms needed to do so may be complicated. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 05:06:00 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 04:59:32 2008 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.ce44f425ed1c9bc75b06bdc2357a8ff6@localhost> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -----------------------------------------------+---------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------------+---------------------------- Changes (by simonpj): * priority: high => normal Comment: We'd like to see this solved, but it looks as if it'd be a lot of work for a relatively narrow case. Can anyone else help? Meanwhile, reducing priority. Simon & Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 05:10:55 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 05:04:23 2008 Subject: [GHC] #2297: Profiler is inconsistent about biography for GHC's heap In-Reply-To: <044.fbea862bca1709c4fb82e649273727f1@localhost> References: <044.fbea862bca1709c4fb82e649273727f1@localhost> Message-ID: <053.37eac0b9f929aac0bf2c389e81b3ff75@localhost> #2297: Profiler is inconsistent about biography for GHC's heap ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Profiling | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * priority: high => normal Comment: Decreasing priority. (High cost-to-benefit ratio!) Simon & Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 08:10:22 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 08:03:50 2008 Subject: [GHC] #2831: Floated error expressions get poor strictness, leaving bad arity Message-ID: <046.8cc1f5167158ac5c2c686513574acede@localhost> #2831: Floated error expressions get poor strictness, leaving bad arity ---------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------------+------------------------------------ GHC is careful to ensure that {{{ f = \x. case x of [] -> error "urk" (y:ys) -> \z. }}} gets arity 2. It does this by giving `error` an infinite arity. But if the error call is floated out by full laziness thus {{{ lvl = error "urk" f = \x. case x of [] -> lvl (y:ys) -> \z. }}} it's a bit less obvious. But it's ok: the strictness analyser disovers that `lvl` diverges. Alas, if `f` is marked INLINE, there's a danger that this does not happen properly, perhaps because the inlining happens after strictness analysis. Or because the error message involves the parameter: {{{ {-# INLINE f #-} f = \x. case x of [] -> error ("urk" ++ x) (y:ys) -> \z. }}} I think I've seen this in connection with array indexing (where the error case is the index out of bounds error). I'm recording this ticket so that I don't forget about this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 08:11:25 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 08:04:54 2008 Subject: [GHC] #149: missed CSE opportunity In-Reply-To: <045.82dbf1ade5f39047db873a9122708a49@localhost> References: <045.82dbf1ade5f39047db873a9122708a49@localhost> Message-ID: <054.6cd0b0baf16f85869189f67858ca97cc@localhost> #149: missed CSE opportunity -----------------------------------------+---------------------------------- Reporter: nobody | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 5.04.2 Severity: minor | Resolution: None Keywords: optimisations | Difficulty: Moderate (1 day) Testcase: simplrun006 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonpj): * milestone: 6.10.2 => _|_ Comment: GHC currently does not do full-blown CSE, partly because it's a bit harder than what is done now, and partly because doing so can introduce space leaks. There is scope for experimentation here, but we're removing it from the immediate milestone. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 08:12:36 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 08:06:03 2008 Subject: [GHC] #2826: Panic compiling lhc-0.6.20081127 In-Reply-To: <043.1a89b950dd25b1bbdfca8fd6e9acbc4c@localhost> References: <043.1a89b950dd25b1bbdfca8fd6e9acbc4c@localhost> Message-ID: <052.bc3bc71493fcefa116f61ab886709b79@localhost> #2826: Panic compiling lhc-0.6.20081127 ---------------------------------+------------------------------------------ Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown * milestone: => 6.10.2 Comment: Suspected dup of #2685. Could you test with a recent snapshot? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 08:17:24 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 08:10:52 2008 Subject: [GHC] #2830: undefined reference to `base_DataziTuple_Z63T_con_info' when using instances with context In-Reply-To: <046.d28b188329eef21fa8e1a7ec215f6dde@localhost> References: <046.d28b188329eef21fa8e1a7ec215f6dde@localhost> Message-ID: <055.40ca0086828a7988f105fd0562504850@localhost> #2830: undefined reference to `base_DataziTuple_Z63T_con_info' when using instances with context -------------------------+-------------------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Happily this works fine in 6.8.3, 6.10.1, and HEAD. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 09:49:32 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 09:43:01 2008 Subject: [GHC] #2818: schedule: invalid what_next field In-Reply-To: <047.464b7aed990b24af643c9609b75f7b8f@localhost> References: <047.464b7aed990b24af643c9609b75f7b8f@localhost> Message-ID: <056.33bedb8637939591fefd6ef1db049d7e@localhost> #2818: schedule: invalid what_next field -------------------------------+-------------------------------------------- Reporter: kkwweett | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: schedule | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Works with the HEAD. I'm pretty sure it was fixed by this patch: {{{ Thu Nov 6 11:40:45 GMT 2008 Simon Marlow * Cope with ThreadRelocated when traversing the blocked_queue Fixes "invalid what_next field" in ioref001 on Windows, and perhaps others }}} which has already been merged. Please test again with a snapshot and re- open the bug if it still fails for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 10:05:45 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 09:59:15 2008 Subject: [GHC] #2815: On windows, hGetLine stdin leaks like an inside trader In-Reply-To: <043.3df837702ae4600d2a6b83af98512acb@localhost> References: <043.3df837702ae4600d2a6b83af98512acb@localhost> Message-ID: <052.a9bb38e5d009cc406bd6e93d88346c5d@localhost> #2815: On windows, hGetLine stdin leaks like an inside trader ---------------------------------+------------------------------------------ Reporter: sclv | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): I can't reproduce it today. I'm wondering if I really saw it before or just thought I did. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 10:07:55 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 10:01:23 2008 Subject: [GHC] #2712: Parallel GC scheduling problems In-Reply-To: <047.e61225a9faf204b963254a4027c9403b@localhost> References: <047.e61225a9faf204b963254a4027c9403b@localhost> Message-ID: <056.4d46f1025ed4070413a076795bb895f4@localhost> #2712: Parallel GC scheduling problems -----------------------------------------+---------------------------------- Reporter: simonmar | Owner: simonmar Type: run-time performance bug | Status: closed Priority: high | Milestone: 6.12 branch Component: Runtime System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonmar): * status: new => closed * version: 6.10.1 => 6.11 * resolution: => fixed * milestone: 6.10.2 => 6.12 branch Comment: Done in the HEAD, but I probably won't backport because the changes are too large and potentially destabilising. Here's the main patch, for reference: {{{ Fri Nov 21 15:12:33 GMT 2008 Simon Marlow * Use mutator threads to do GC, instead of having a separate pool of GC threa ds Previously, the GC had its own pool of threads to use as workers when doing parallel GC. There was a "leader", which was the mutator thread that initiated the GC, and the other threads were taken from the pool. This was simple and worked fine for sequential programs, where we did most of the benchmarking for the parallel GC, but falls down for parallel programs. When we have N mutator threads and N cores, at GC time we would have to stop N-1 mutator threads and start up N-1 GC threads, and hope that the OS schedules them all onto separate cores. It practice it doesn't, as you might expect. Now we use the mutator threads to do GC. This works quite nicely, particularly for parallel programs, where each mutator thread scans its own spark pool, which is probably in its cache anyway. There are some flag changes: -g is removed (-g1 is still accepted for backwards compat). There's no way to have a different number of GC threads than mutator threads now. -q1 Use one OS thread for GC (turns off parallel GC) -qg Use parallel GC for generations >= (default: 1) Using parallel GC only for generations >=1 works well for sequential programs. Compiling an ordinary sequential program with -threaded and running it with -N2 or more should help if you do a lot of GC. I've found that adding -qg0 (do parallel GC for generation 0 too) speeds up some parallel programs, but slows down some sequential programs. Being conservative, I left the threshold at 1. ToDo: document the new options. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 10:19:45 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 10:13:14 2008 Subject: [GHC] #1870: ghc-6.8.1 panics compiling regex-tdfa-0.93 In-Reply-To: <053.ed75b86fd46ffdb671ac3109a1855225@localhost> References: <053.ed75b86fd46ffdb671ac3109a1855225@localhost> Message-ID: <062.0cf8814e4931a476bcee6ddd80a029d0@localhost> #1870: ghc-6.8.1 panics compiling regex-tdfa-0.93 ---------------------------------+------------------------------------------ Reporter: ChrisKuklewicz | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * priority: normal => low * milestone: 6.10.2 => _|_ Comment: I think I'm going to make this low-priority for now, and remove it from the 6.10.2 milestone. Reason: there's an easy workaround, and it's in territory that is going to be upheaved (again) when we implement the Haskell Prime spec for bindings #2357. As a result, it's hard to motivate myself to invest in fixing this one. If it's important to anyone, then sing out. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 10:20:21 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 10:13:49 2008 Subject: [GHC] #1870: ghc-6.8.1 panics compiling regex-tdfa-0.93 In-Reply-To: <053.ed75b86fd46ffdb671ac3109a1855225@localhost> References: <053.ed75b86fd46ffdb671ac3109a1855225@localhost> Message-ID: <062.c957978c707543977705ac704f3f01e6@localhost> #1870: ghc-6.8.1 panics compiling regex-tdfa-0.93 ---------------------------------+------------------------------------------ Reporter: ChrisKuklewicz | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): PS: I remembered another reason: it's relatively laborious to reproduce! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 10:20:33 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 10:14:02 2008 Subject: [GHC] #2829: GHC_SEARCH_PATH broken In-Reply-To: <046.fd61e0b6076af34dcd134be33a9c2d6e@localhost> References: <046.fd61e0b6076af34dcd134be33a9c2d6e@localhost> Message-ID: <055.4679fa896ca01583ce7310ddec829c8c@localhost> #2829: GHC_SEARCH_PATH broken ---------------------------------+------------------------------------------ Reporter: droundy | Owner: Type: bug | Status: new Priority: lowest | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => lowest * difficulty: => Unknown * milestone: => 6.10.2 Comment: Could you be more specific about what doesn't work? I tried some simple tests here and it seems to be working as advertised for me. Prio: lowest while waiting for feedback. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 10:22:15 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 10:16:27 2008 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.c133dcffe571edb64f611c51ca2b5a3c@localhost> #1876: Complete shared library support ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: clemens Type: task | Status: assigned Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Grab the GHC sources, configure with `--enable-shared`, build as normal and report problems that you encounter. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 10:24:59 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 10:18:26 2008 Subject: [GHC] #2081: GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.b71828e28c7a416e9d0a4431a9549409@localhost> #2081: GHC reports internal error: stg_ap_v_ret ---------------------------------+------------------------------------------ Reporter: thorkilnaur | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): I've slightly lost track of what this ticket is about. Thorkil: is there still a reproducible bug, if so on which platform(s), and with which version(s) of GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From droundy at darcs.net Mon Dec 1 11:57:33 2008 From: droundy at darcs.net (David Roundy) Date: Mon Dec 1 11:50:18 2008 Subject: [GHC] #2829: GHC_SEARCH_PATH broken In-Reply-To: <055.4679fa896ca01583ce7310ddec829c8c@localhost> References: <046.fd61e0b6076af34dcd134be33a9c2d6e@localhost> <055.4679fa896ca01583ce7310ddec829c8c@localhost> Message-ID: <20081201165732.GA25834@darcs.net> On Mon, Dec 01, 2008 at 03:20:33PM -0000, GHC wrote: > Could you be more specific about what doesn't work? I tried some simple > tests here and it seems to be working as advertised for me. Ah, when I rerun my tests, it seems that I can only reproduce the brokenness in ghc 6.8.2. I guess it must have been fixed in ghc 6.10.1. I was sure that I'd tested it in ghc 6.10.1, but I guess I must have made a mistake. Sorry about the false alarm! $ cp /srv/home/droundy/.ghc/x86_64-linux-6.8.2/package.conf foo foldable-desktop:tmp$ GHC_PACKAGE_PATH=/tmp/foo: ghc-pkg list /tmp/foo: {Chart-0.9}, {HFuse-0.2.1}, {QuickCheck-2.0}, {a-1.0}, {b-2.0}, {data-accessor-0.1.4}, {data-accessor-template-0.1.4}, {franchise-0.0}, {franchise-0.0.1}, {franchise-0.0.2}, {franchise-0.0.3}, {franchise-0.0.5}, {franchise-0.0.6}, {franchise-0.0.7}, {parsec-3.0.0}, {xmonad-0.7} $ cp /home/droundy/.ghc/i386-linux-6.6/package.conf foo rof:tmp$ GHC_PACKAGE_PATH=/tmp/foo: ghc-pkg list /usr/lib/ghc-6.6/package.conf: Cabal-1.1.6, GLUT-2.0, HGL-3.1, HTTP-2006.7.7, HUnit-1.1, MissingH-0.16.0, OpenGL-2.1, QuickCheck-1.0, X11-1.2, base-2.0, fgl-5.3, (ghc-6.6), haskell98-1.0, html-1.0, mtl-1.0, network-2.0, parsec-2.0, readline-1.0, regex-base-0.71, regex-compat-0.71, regex-posix-0.71, rts-1.0, stm-2.0, template-haskell-2.0, unix-1.0 /home/droundy/.ghc/i386-linux-6.6/package.conf: Cabal-1.2.2.0, GSL-0.6, X11-1.4.2, cairo-0.9.11.1, filepath-1.1.0.0, franchise-0.0.7, glib-0.9.11.1, gtk-0.9.11.1, hscolour-1.10, xmonad-0.7 /tmp/foo: Cabal-1.2.2.0, GSL-0.6, X11-1.4.2, cairo-0.9.11.1, filepath-1.1.0.0, franchise-0.0.7, glib-0.9.11.1, gtk-0.9.11.1, hscolour-1.10, xmonad-0.7 -- David Roundy http://www.darcs.net From trac at galois.com Mon Dec 1 15:34:23 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 15:27:59 2008 Subject: [GHC] #2832: GHC -split-objs, Doesn't Print Error If GHC Built With SplitObjs = NO. Message-ID: <046.70ce203c528d9187aa1e90914e4360f2@localhost> #2832: GHC -split-objs, Doesn't Print Error If GHC Built With SplitObjs = NO. -----------------------------+---------------------------------------------- Reporter: dejones | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: split-objs, ghc | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- If GHC is called with flag -split-objs but GHC was built with SplitObjs = NO, then GHC simply ignores the -split-objs flag; however, GHC should print an error message and exit, stating that GHC was built without support for split objects. Please refer to the thread on the gtk2hs-users mailing list ([Gtk2hs- users] Gtk2Hs Linker Errors, Simple Window from Tutorial) for a test case and the resulting linker problems that occurred when building gtk2hs. http://sourceforge.net/mailarchive/forum.php?thread_name=fe05cbe50811301138q474b99c5kf48497d932e7cb14%40mail.gmail.com&forum_name =gtk2hs-users http://sourceforge.net/mailarchive/forum.php?thread_name=1228147821.13936.78.camel%40aconit&forum_name =gtk2hs-users http://sourceforge.net/mailarchive/forum.php?thread_name=20081201184819.GB13054%40zombie.inf .tu-dresden.de&forum_name=gtk2hs-users -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 15:42:48 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 15:36:23 2008 Subject: [GHC] #2832: GHC -split-objs, Doesn't Print Error If GHC Built With SplitObjs = NO. In-Reply-To: <046.70ce203c528d9187aa1e90914e4360f2@localhost> References: <046.70ce203c528d9187aa1e90914e4360f2@localhost> Message-ID: <055.8b6e14cff38d90d0a6d35183dcd5781b@localhost> #2832: GHC -split-objs, Doesn't Print Error If GHC Built With SplitObjs = NO. ------------------------------+--------------------------------------------- Reporter: dejones | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: split-objs, ghc | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by duncan): See also http://hackage.haskell.org/trac/hackage/ticket/421 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 16:03:32 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 15:57:02 2008 Subject: [GHC] #2833: internal error: throwTo: unrecognised why_blocked value Message-ID: <044.241eea212892e1f7fdf89a6a715bfb1f@localhost> #2833: internal error: throwTo: unrecognised why_blocked value -------------------+-------------------------------------------------------- Reporter: lilac | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------+-------------------------------------------------------- The attached file, built with reactive 0.9.6 with the change listed below (fix for reactive bug#14), exhibits some strange behaviour. When built with -threaded and run without +RTS -N, everything is fine. When run with +RTS -N2, it slows down dramatically (using <10% CPU on each of my cores) and eventually crashes with: {{{ Main: internal error: throwTo: unrecognised why_blocked value (GHC version 6.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The change to reactive (from http://hpaste.org/12528#a2) is to replace snapshotWith in FRP/Reactive/PrimRecursive.hs with: {{{ snapshotWith :: forall a b c t. Ord t => (a -> b -> c) -> EventG t a -> ReactiveG t b -> EventG t c snapshotWith f es rs = listEG . zip (eats es) . zipWith f (evals es) $ rats rs (eats es) evals :: EventG t a -> [a] evals (Event (Future (Max MaxBound, _))) = [] evals (Event (Future (_, ~(v `Stepper` es)))) = v:evals es eats :: EventG t a -> [t] eats (Event (Future (Max MaxBound, ~(_ `Stepper` es)))) = [] eats (Event (Future (Max (NoBound t), ~(_ `Stepper` es)))) = t:eats es eats (Event (Future (Max MinBound, ~(_ `Stepper` es)))) = eats es }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 16:17:57 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 16:11:29 2008 Subject: [GHC] #2834: DLL compilation does not work as it did in 6.8.3 Message-ID: <049.fbd95995696798fc65a836c1f3181ab2@localhost> #2834: DLL compilation does not work as it did in 6.8.3 ------------------------+--------------------------------------------------- Reporter: lewissandy | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: DLL, Shared | Testcase: Os: Windows | Architecture: Unknown/Multiple ------------------------+--------------------------------------------------- Creating a windows DLL in GHC 6.10.1 in accordance with the "adder" example in the GHC documentation (section 12.6) results in a large number of undefined reference errors. The same code compiles without error in 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 16:49:49 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 16:43:18 2008 Subject: [GHC] #2835: Handles leak to processes spawned by runInteractiveProcess Message-ID: <043.3c94728a55d9daf6eec39fd3bc05b945@localhost> #2835: Handles leak to processes spawned by runInteractiveProcess -----------------------------+---------------------------------------------- Reporter: sclv | Owner: Type: bug | Status: new Priority: normal | Component: libraries/process Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I believe this is related to http://hackage.haskell.org/trac/ghc/ticket/2650 however this occurs on Linux and Windows both, as far as I can tell. Attached is the test case. It opens a simple server which echoes everything to stdout with two exceptions: commands beginning with q signal "quit" and commands beginning with "l" signal launching a new process. {{{ 1) Launch sockLeak. Telnet to port 9020. Type in some junk. It will be echoed. 2) Type in "q". The connection will terminate. 3) Telnet in again. This time, type "l". Now type "q". The connection has not terminated. 4) This is clearly because the handle to the socket has gotten passed to the child process somehow. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 1 18:32:56 2008 From: trac at galois.com (GHC) Date: Mon Dec 1 18:26:32 2008 Subject: [GHC] #2836: Data.Typeable does not use qualified names Message-ID: <044.8f82fa3eeec008c76155a3a9d33ae83d@localhost> #2836: Data.Typeable does not use qualified names -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The TyCon in Data.Typeable does not provide the qualified type name. This can be very annoying if you try to use a TypeRep as a stored representation of a type (within a run it's OK with the equality on TypeRep). I suggest that the TyCon be enhanced to contain a qualified name, but that the current API be maintained, except for adding some new functions to access qualified name. If prodded I could provide the Data.Typeable implementation and the fix to ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 02:40:09 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 02:33:48 2008 Subject: [GHC] #2717: Add nubWith, nubOrd In-Reply-To: <050.81576ece7ea2f3fe706671e03fa58430@localhost> References: <050.81576ece7ea2f3fe706671e03fa58430@localhost> Message-ID: <059.555adbc3cffd81725391c133488ad2ed@localhost> #2717: Add nubWith, nubOrd ---------------------------------+------------------------------------------ Reporter: Bart Massey | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by Bart Massey): I've attached two patches---base.patch against libraries/base and containers.patch against libraries/containers---that conform to the general list consensus on functionality. Data.List is now unchanged except for documentation. Data.Set implements nubOrd, and Data.IntSet implements nubInt. I will ask for one more round of patch review and then request that these patches be applied. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 03:45:05 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 03:38:41 2008 Subject: [GHC] #2836: Data.Typeable does not use qualified names In-Reply-To: <044.8f82fa3eeec008c76155a3a9d33ae83d@localhost> References: <044.8f82fa3eeec008c76155a3a9d33ae83d@localhost> Message-ID: <053.83600061c92a2ec2d7c944357415a908@localhost> #2836: Data.Typeable does not use qualified names ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Old description: > The TyCon in Data.Typeable does not provide the qualified type name. > This can be very annoying if you try to use a TypeRep as a stored > representation of a type (within a run it's OK with the equality on > TypeRep). > > I suggest that the TyCon be enhanced to contain a qualified name, but > that the current API be maintained, except for adding some new functions > to access qualified name. > > If prodded I could provide the Data.Typeable implementation and the fix > to ghc. New description: The !TyCon in Data.Typeable does not provide the qualified type name. This can be very annoying if you try to use a !TypeRep as a stored representation of a type (within a run it's OK with the equality on !TypeRep). I suggest that the !TyCon be enhanced to contain a qualified name, but that the current API be maintained, except for adding some new functions to access qualified name. If prodded I could provide the Data.Typeable implementation and the fix to ghc. Comment: Your suggestion sounds plausible to me. There is some design to do first. Currently `Data.Typeable.TyCon` is really just a string (plus a key for comparison). Maybe you want three strings? * The package name * The module name * The !TyCon name plus accessor functions. Another possibility (unavailable when `Data.Typeable` was designed I think) would be to use a Template Haskell name: `Language.Haskell.TH.Syntax.Name`. After all, `Data.Typeable` is just another form of reflection, like TH. I'm not sure what the tradeoffs are though. For example, TH names don't have a key for fast comparison. (But the keys are quite a nuisance in some ways because they may differ from run to run.) I suggest you progress this via the library process: make proposals, encourage discussion. Actually implementing it will not be hard. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 03:50:44 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 03:44:11 2008 Subject: [GHC] #2832: GHC -split-objs, Doesn't Print Error If GHC Built With SplitObjs = NO. In-Reply-To: <046.70ce203c528d9187aa1e90914e4360f2@localhost> References: <046.70ce203c528d9187aa1e90914e4360f2@localhost> Message-ID: <055.0824920953ffdb687cc73f64a10367a3@localhost> #2832: GHC -split-objs, Doesn't Print Error If GHC Built With SplitObjs = NO. ---------------------------------+------------------------------------------ Reporter: dejones | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: split-objs, ghc | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown * milestone: => 6.10.2 Comment: `SplitObjs` is overloaded: it means both enable splitting (`-split-objs`) and also build the bootlibs with splitting on. There's no good reason to want to disable splitting support completely, unless the platform doesn't support it. So we should have two separate knobs here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 04:09:23 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 04:03:22 2008 Subject: [GHC] #2750: Bug in Data.Generics In-Reply-To: <044.cd214fdda0ee80175fd522907e79182f@localhost> References: <044.cd214fdda0ee80175fd522907e79182f@localhost> Message-ID: <053.fe583df5ff586ac98eb02a9174939699@localhost> #2750: Bug in Data.Generics ---------------------------------+------------------------------------------ Reporter: guest | Owner: dreixel Type: bug | Status: assigned Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by dreixel): * status: new => assigned * owner: jose magalhaes => dreixel Comment: Attached patch correcting the typo. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 04:28:43 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 04:22:08 2008 Subject: [GHC] #2829: GHC_SEARCH_PATH broken In-Reply-To: <046.fd61e0b6076af34dcd134be33a9c2d6e@localhost> References: <046.fd61e0b6076af34dcd134be33a9c2d6e@localhost> Message-ID: <055.a51e8e45f29b3ba3be6031a7aa1aca2a@localhost> #2829: GHC_SEARCH_PATH broken ---------------------------------+------------------------------------------ Reporter: droundy | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => worksforme Comment: Submitter reports that it now works with 6.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 04:30:03 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 04:23:34 2008 Subject: [GHC] #2834: DLL compilation does not work as it did in 6.8.3 In-Reply-To: <049.fbd95995696798fc65a836c1f3181ab2@localhost> References: <049.fbd95995696798fc65a836c1f3181ab2@localhost> Message-ID: <058.4262e2ec8f732cd7428b63d9509cf5b7@localhost> #2834: DLL compilation does not work as it did in 6.8.3 ---------------------------------+------------------------------------------ Reporter: lewissandy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: DLL, Shared | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Duplicate of #2745 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 04:39:03 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 04:32:31 2008 Subject: [GHC] #2835: Handles leak to processes spawned by runInteractiveProcess In-Reply-To: <043.3c94728a55d9daf6eec39fd3bc05b945@localhost> References: <043.3c94728a55d9daf6eec39fd3bc05b945@localhost> Message-ID: <052.0294b7e4c3b62cbfda78a055987f9e7e@localhost> #2835: Handles leak to processes spawned by runInteractiveProcess ----------------------------------+----------------------------------------- Reporter: sclv | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/process | Version: 6.10.1 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: Normally, only pipes created by the `System.Process` library are closed in child processes, all other FDs are inherited by default. You can request that all FDs are closed by using the new `close_fds` flag to `createProcess`; try this replacement for the line containing `runProcess` in your example: {{{ forkIO $ createProcess (proc (dir pn) ["arg"]){ close_fds=True } >> forever (threadDelay 100000) }}} This behaviour is fairly standard, it's what `popen` on Unix does, and it also follows the Python library. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 04:42:19 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 04:35:52 2008 Subject: [GHC] #2836: Data.Typeable does not use qualified names In-Reply-To: <044.8f82fa3eeec008c76155a3a9d33ae83d@localhost> References: <044.8f82fa3eeec008c76155a3a9d33ae83d@localhost> Message-ID: <053.55cc05ccb0ae990a5035742ec40da773@localhost> #2836: Data.Typeable does not use qualified names ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): See also #1841 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 05:33:52 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 05:27:21 2008 Subject: [GHC] #2837: Vectoriser doesn't work with dph-seq Message-ID: <043.a08931e2ea9f7718b448163e777da8b7@localhost> #2837: Vectoriser doesn't work with dph-seq -----------------------------+---------------------------------------------- Reporter: chak | Owner: rl Type: bug | Status: new Priority: normal | Component: Data Parallel Haskell Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Given {{{ {-# LANGUAGE PArr, ParallelListComp #-} {-# OPTIONS -fvectorise #-} module DotP (dotp_double) where import qualified Prelude import Data.Array.Parallel.Prelude import Data.Array.Parallel.Prelude.Double dotp_double :: [:Double:] -> [:Double:] -> Double dotp_double xs ys = sumP [:x * y | x <- xs | y <- ys:] }}} We can compile with `dph-par` {{{ TacticalGrace chak 12 (.../haskell/ndp): ghc -c -Odph -funbox-strict- fields -fcpr-off -threaded -package dph-par dotp.hs }}} but not with `dph-seq` {{{ TacticalGrace chak 11 (.../haskell/ndp): ghc -c -Odph -funbox-strict- fields -fcpr-off -threaded -package dph-seq dotp.hs *** Vectorisation error *** Variable not vectorised: Data.Array.Parallel.Prelude.Base.Double.sumP }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 05:59:53 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 05:53:22 2008 Subject: [GHC] #2837: Vectoriser should give a better error message In-Reply-To: <043.a08931e2ea9f7718b448163e777da8b7@localhost> References: <043.a08931e2ea9f7718b448163e777da8b7@localhost> Message-ID: <052.db6404dd9a35186c7f6904aad345fa23@localhost> #2837: Vectoriser should give a better error message -----------------------------------+---------------------------------------- Reporter: chak | Owner: rl Type: bug | Status: new Priority: normal | Milestone: Component: Data Parallel Haskell | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------------+---------------------------------------- Changes (by chak): * summary: Vectoriser doesn't work with dph-seq => Vectoriser should give a better error message Comment: Resolved on IRC. The additional flag `-fdph-seq` has been missing from the invocation. However, the error message should be better (or both flags be combined into one). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 06:01:31 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 05:54:58 2008 Subject: [GHC] #2837: Vectoriser should give a better error message In-Reply-To: <043.a08931e2ea9f7718b448163e777da8b7@localhost> References: <043.a08931e2ea9f7718b448163e777da8b7@localhost> Message-ID: <052.4c211aeae7e4ae4cecbdc8661e888dbf@localhost> #2837: Vectoriser should give a better error message -----------------------------------+---------------------------------------- Reporter: chak | Owner: rl Type: bug | Status: closed Priority: normal | Milestone: Component: Data Parallel Haskell | Version: 6.10.1 Severity: normal | Resolution: worksforme Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------------+---------------------------------------- Changes (by chak): * status: new => closed * resolution: => worksforme Comment: It turns out that just providing `-fdph-seq` or `-fdph-par` is actually already sufficient (the correct package flag is being implied). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 06:08:23 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 06:01:50 2008 Subject: [GHC] #2560: killThread and getChanContents appear to interact strangely In-Reply-To: <053.7b90af27065da85db72f8f049c3b99b1@localhost> References: <053.7b90af27065da85db72f8f049c3b99b1@localhost> Message-ID: <062.2759902e2900195aa17cf042304788c9@localhost> #2560: killThread and getChanContents appear to interact strangely ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: I've spent a long time staring at this ticket today, and I'm not convinced there's a bug. `modifyMVar` is exception-safe, and so is `getChanContents`, as far as I can tell. Ian's point is true, that you can't guarantee to keep exceptions blocked when calling a library function, but I don't think that makes anything unsafe in this case. Exception-safety is all about making sure that `MVars` get replaced if an exception is raised, and I think that always holds for `modifyMVar` and `getChanContents`. No, I suspect there's a bug in the program logic. It just loops when it gets to a chunk size of 1, and if you look at the definition of `readWithTimeout`, you can see why. If the chunk size is 1, it just recurses with the same value for `n`. At least, that's my guess - I don't fully understand what this program is trying to do. If you disagree, plesae re-open the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 06:36:11 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 06:29:35 2008 Subject: [GHC] #2838: -fast codeGen doesn't truncate CMMInt's at the right place Message-ID: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> #2838: -fast codeGen doesn't truncate CMMInt's at the right place -----------------------------+---------------------------------------------- Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- With this sample program: {{{ {-# LANGUAGE MagicHash, UnboxedTuples #-} module Simpl(complement) where import GHC.Base import GHC.Num complement (I# x#) = I# (word2Int# (int2Word# (4294967295#) `xor#` int2Word# (-1#))) }}} And compiling with {{{ -O0 -fasm }}} on 6.10 or a recent head blows up in the assembler due to the constant. {{{ Assembler messages: Error: missing or invalid immediate expression `-4294967296' taken as 0 Error: suffix or operands invalid for `mov' }}} After some debugging with SPJ, we believe that what is happening is: {{{CMMInt}}}is storing {{{4294967295}}} as an Integer. This magic number is {{{(2^32) - 1}}}. {{{4294967295 ^ -1}}} is {{{00..011..1 ^ 11..111..1 = 11..100..0}}} which is {{{(-4294967296)}}} We think internally using Integer arithmatic is fine (in e.g. CmmOpt), however truncation isn't happening correctly when turning the Integer into a real Int; makeImmediate in nativeGen\machineRegs looks like a possible culprit. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 06:38:11 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 06:31:36 2008 Subject: [GHC] #2081: GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.db561a391bd04b25f661a3ce8fae91eb@localhost> #2081: GHC reports internal error: stg_ap_v_ret ---------------------------------+------------------------------------------ Reporter: thorkilnaur | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by thorkilnaur): I have a particular build of a particular version of the HEAD (http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20head%202/builds/142) with which I can reproduce the problem on PPC Mac OS X 10.5: {{{ $ uname -a Darwin thorkil-naurs-mac-mini.local 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep 3 11:31:44 PDT 2008; root:xnu-1228.7.58~1/RELEASE_PPC Power Macintosh $ ../../ghc/stage1-inplace/ghc -fforce-recomp --make timeout -O2 [1 of 1] Compiling Main ( timeout.hs, timeout.o ) Linking timeout ... $ ./timeout 200 "echo Something" timeout: internal error: stg_ap_p_ret (GHC version 6.11.20081003 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Something Abort trap $ }}} That particular HEAD build is the latest for which this happened. The latest STABLE build for which it happened is http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20stable%202/builds/180. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 07:17:59 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 07:11:25 2008 Subject: [GHC] #2081: GHC reports internal error: stg_ap_v_ret In-Reply-To: <050.436412791af8536dabd2387bab7c6cbf@localhost> References: <050.436412791af8536dabd2387bab7c6cbf@localhost> Message-ID: <059.ed9c5eba1326641bcf6a0129a88c9f57@localhost> #2081: GHC reports internal error: stg_ap_v_ret ---------------------------------+------------------------------------------ Reporter: thorkilnaur | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => worksforme Comment: Let's close this ticket, and open a new ticket if it re-emerges. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 07:59:37 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 07:53:13 2008 Subject: [GHC] #2760: Data.Generics.Basics.mkNorepType spelled wrong In-Reply-To: <044.b3884d30a8391ab9f46e5542669e8ee1@localhost> References: <044.b3884d30a8391ab9f46e5542669e8ee1@localhost> Message-ID: <053.f876d2a376d989ac962ac26520a03141@localhost> #2760: Data.Generics.Basics.mkNorepType spelled wrong ----------------------------------+----------------------------------------- Reporter: guest | Owner: dreixel Type: bug | Status: assigned Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by dreixel): * status: new => assigned * owner: jose magalhaes => dreixel * summary: Data.Generics.Basics.mkNoreptype spelled wrong => Data.Generics.Basics.mkNorepType spelled wrong Comment: I marked mkNorepType as deprecated and introduced a new functions mkNoRepType. Also replaced the uses of mkNorepType in GHC by mkNoRepType to avoid deprecated warnings. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 09:44:00 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 09:37:26 2008 Subject: [GHC] #2838: -fasm codeGen doesn't truncate CMMInt's at the right place In-Reply-To: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> References: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> Message-ID: <062.3f547e616fea48cb57ee0cfff66bbbe3@localhost> #2838: -fasm codeGen doesn't truncate CMMInt's at the right place ------------------------------+--------------------------------------------- Reporter: TristanAllwood | 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 ------------------------------+--------------------------------------------- Changes (by TristanAllwood): * summary: -fast codeGen doesn't truncate CMMInt's at the right place => -fasm codeGen doesn't truncate CMMInt's at the right place Comment: For reference, the test case does seem to be handled fine with {{{-fnew- codegen}}} in Today's Head. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 10:36:16 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 10:29:41 2008 Subject: [GHC] #2839: Integer not documented in latest docs Message-ID: <053.5999defb877c69f25bce4ee37808f714@localhost> #2839: Integer not documented in latest docs -----------------------------+---------------------------------------------- Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The haddock documentation on the website for Integer is missing, which causes e.g. http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html http://www.haskell.org/ghc/docs/6.10-latest/html/libraries/base/Prelude.html http://www.haskell.org/ghc/docs/6.10.1/html/libraries/base/Prelude.html to not link to it. nominolo suggested that it's due to the new integer-gmp package not being haddocked with everything else by a bot -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 10:58:14 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 10:51:46 2008 Subject: [GHC] #2838: -fasm codeGen doesn't truncate CMMInt's at the right place In-Reply-To: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> References: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> Message-ID: <062.18d29e21791c630c0ce9755f3a50d496@localhost> #2838: -fasm codeGen doesn't truncate CMMInt's at the right place ------------------------------+--------------------------------------------- Reporter: TristanAllwood | 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 TristanAllwood): given it's wrapped in #ifdef powepc, makeImmediate was probably a red herring. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 12:17:25 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 12:11:00 2008 Subject: [GHC] #1074: -fwarn-unused-imports complains about wrong import In-Reply-To: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> References: <044.4c9395b3e6188ac7c118df9e58cf802d@localhost> Message-ID: <053.3899caf668cb6fcb35785910974b2eb5@localhost> #1074: -fwarn-unused-imports complains about wrong import ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by tibbe): * cc: johan.tibell@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 17:38:46 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 17:32:13 2008 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@localhost> References: <047.b31f95b84e60784da45a33105d44ed84@localhost> Message-ID: <056.b0fe8047968eaf2dc58fad766d0e376a@localhost> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -----------------------------------------------+---------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: hsetbuffering buffering buffer | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------------+---------------------------- Changes (by ryani): * cc: ryani (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 2 17:39:53 2008 From: trac at galois.com (GHC) Date: Tue Dec 2 17:33:19 2008 Subject: [GHC] #806: hGetBufNonBlocking doesn't work on Windows In-Reply-To: <053.4faf11bcb1c323d37868059a7808a067@localhost> References: <053.4faf11bcb1c323d37868059a7808a067@localhost> Message-ID: <062.eec9be5a0d0f6b22d786abc61fe382b8@localhost> #806: hGetBufNonBlocking doesn't work on Windows -------------------------------+-------------------------------------------- Reporter: titto@kamus.it | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: libraries/base | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: hGetBuf001 | Os: Windows Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by ryani): * cc: ryani (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 3 04:31:25 2008 From: trac at galois.com (GHC) Date: Wed Dec 3 04:24:49 2008 Subject: [GHC] #2838: -fasm codeGen doesn't truncate CMMInt's at the right place In-Reply-To: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> References: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> Message-ID: <062.a749f98377837291cd6615478ef31979@localhost> #2838: -fasm codeGen doesn't truncate CMMInt's at the right place ---------------------------------+------------------------------------------ Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: Replying to [comment:1 TristanAllwood]: > For reference, the test case does seem to be handled fine with {{{-fnew- codegen}}} in Today's Head. I suspect this is by accident, as the new codegen is not running `CmmOpt`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 3 04:32:53 2008 From: trac at galois.com (GHC) Date: Wed Dec 3 04:26:16 2008 Subject: [GHC] #2839: Integer not documented in latest docs In-Reply-To: <053.5999defb877c69f25bce4ee37808f714@localhost> References: <053.5999defb877c69f25bce4ee37808f714@localhost> Message-ID: <062.cb74f4aa5d9e600dc01564bb733743dc@localhost> #2839: Integer not documented in latest docs ---------------------------------+------------------------------------------ Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.10.2 Old description: > The haddock documentation on the website for Integer is missing, which > causes e.g. > > http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html > http://www.haskell.org/ghc/docs/6.10-latest/html/libraries/base/Prelude.html > http://www.haskell.org/ghc/docs/6.10.1/html/libraries/base/Prelude.html > > to not link to it. > > nominolo suggested that it's due to the new integer-gmp package not being > haddocked with everything else by a bot New description: The haddock documentation on the website for Integer is missing, which causes e.g. * [http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html] * [http://www.haskell.org/ghc/docs/6.10-latest/html/libraries/base/Prelude.html] * [http://www.haskell.org/ghc/docs/6.10.1/html/libraries/base/Prelude.html] to not link to it. nominolo suggested that it's due to the new integer-gmp package not being haddocked with everything else by a bot Comment: Another important doc bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 3 05:57:41 2008 From: trac at galois.com (GHC) Date: Wed Dec 3 05:51:03 2008 Subject: [GHC] #2502: segfault with GHC.Handle.fdToHandle' In-Reply-To: <046.3af147e9b383729d4b3cbb7db169730e@localhost> References: <046.3af147e9b383729d4b3cbb7db169730e@localhost> Message-ID: <055.bcd849c9b80d4c8f8c9b51fe198b23cd@localhost> #2502: segfault with GHC.Handle.fdToHandle' ------------------------+--------------------------------------------------- Reporter: EricKow | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: None | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: FreeBSD Architecture: x86 | ------------------------+--------------------------------------------------- Changes (by thorkilnaur): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 3 19:31:52 2008 From: trac at galois.com (GHC) Date: Wed Dec 3 19:25:14 2008 Subject: [GHC] #2757: runghc doesn't respond to --help / --version In-Reply-To: <047.8ea527abd27e35ccd572a6a7f32be73f@localhost> References: <047.8ea527abd27e35ccd572a6a7f32be73f@localhost> Message-ID: <056.8d75379f4d260ef468a990563e838e89@localhost> #2757: runghc doesn't respond to --help / --version ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: igloo Type: bug | Status: reopened Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: closed => reopened * resolution: fixed => * summary: runghc doesn't respond to --help => runghc doesn't respond to --help / --version Comment: runghc's cabal files claims it to be version 0.67 currently. Is that a useful version number, or should we just switch to using the GHC version? Hmm, if we want to put the GHC version number in the Cabal file then we'll have to generate the Cabal file...sigh. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 3 21:03:42 2008 From: trac at galois.com (GHC) Date: Wed Dec 3 20:57:14 2008 Subject: [GHC] #2750: Bug in Data.Generics In-Reply-To: <044.cd214fdda0ee80175fd522907e79182f@localhost> References: <044.cd214fdda0ee80175fd522907e79182f@localhost> Message-ID: <053.d802767198f684571724f1257129a2bc@localhost> #2750: Bug in Data.Generics ---------------------------------+------------------------------------------ Reporter: guest | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: assigned => closed * resolution: => fixed Comment: Thanks, applied to HEAD and 6.10 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 4 09:23:38 2008 From: trac at galois.com (GHC) Date: Thu Dec 4 09:16:57 2008 Subject: [GHC] #2840: Top level string literals Message-ID: <046.8553bc6421fed56d88dda5bac312c55f@localhost> #2840: Top level string literals ---------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------------+------------------------------------ At the moment GHC's internal language does not allow any top-level definitions of unlifted type, and for the most part rightly so. But consider this: {{{ f :: Int -> String f n = let a::Addr# = "foo" in let g y = ...a...g... in g n }}} Here we'd like to float the definitions out thus: {{{ a::Addr# = "foo" g y = ...a...g... f n = g n }}} This is much better. Usually this happens, but not here, because we don't allow a top-level binding for an `Addr#`. But really perhaps we should allow an exception for ''literals'', which can safely be bound at top level. For literals other than strings, this doesn't make any difference, because we inline them freely. But for literal strings we don't want to make lots of copies of them; on the contrary we'd like to CSE identical strings. So it'd help to be able to bind them at top level. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 4 10:40:40 2008 From: trac at galois.com (GHC) Date: Thu Dec 4 10:33:59 2008 Subject: [GHC] #2420: Multi-method classes are inlined/specialized better than single-method classes for strict types In-Reply-To: <048.3992ed493cb4d18feeaa36522408a406@localhost> References: <048.3992ed493cb4d18feeaa36522408a406@localhost> Message-ID: <057.70eda6d773370c5f0b815c70f56e46d5@localhost> #2420: Multi-method classes are inlined/specialized better than single-method classes for strict types ---------------------------------+------------------------------------------ Reporter: sedillard | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I think this is fixed in GHC 6.10. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 4 10:44:58 2008 From: trac at galois.com (GHC) Date: Thu Dec 4 10:38:16 2008 Subject: [GHC] #2841: Ghci + foreign export declarations result in undefined symbols Message-ID: <044.b0747800033e264d294e9c1520f847f6@localhost> #2841: Ghci + foreign export declarations result in undefined symbols -------------------+-------------------------------------------------------- Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 6.10.1 | Severity: major Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------+-------------------------------------------------------- When using ghci and foreign export declarations, calling any function, _even_ test, will result in an unknown symbol error. Another bug is that the compiler is not purely functional in the sense that without history (see below) it is possible for it to work in one instance, but even then it doesn't. GHCi should have the property that if X works in a state S of the OS (collection of files, etc), then it should work in all states S', obtained by adding extra stuff to S, but not modifying anything. Currently, GHCi is breaking this fundamental property. {{{ $ ghci New.hs *Main> foo 1 : New_stub.o: unknown symbol `Main_zdffoozuavi_closure' }}} {{{ {-# LANGUAGE ForeignFunctionInterface #-} -- save in a file New.hs foreign export ccall foo :: Int -> IO Int -- add this line and ghci will return something like New_stub.o: unknown symbol `Main_zdffoozuaIc_closure' -- if you first try without the line, it works. If you still have stub files in the current directory, it will fail with the same message as before. foo :: Int -> IO Int foo = return . length . f f :: Int -> [Int] f 0 = [] f n = n:(f (n-1)) test = 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 5 00:05:57 2008 From: trac at galois.com (GHC) Date: Thu Dec 4 23:59:13 2008 Subject: [GHC] #2842: http://darcs.haskell.org/darcsweb/ throwing errors. Message-ID: <043.148ddb378151a29e56e684c5277e227e@localhost> #2842: http://darcs.haskell.org/darcsweb/ throwing errors. -----------------------------+---------------------------------------------- Reporter: hydo | Owner: Type: bug | Status: new Priority: normal | Component: External Core Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Click any link at http://darcs.haskell.org/darcsweb/ and you'll see. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 5 08:48:24 2008 From: trac at galois.com (GHC) Date: Fri Dec 5 08:41:40 2008 Subject: [GHC] #2843: Missing "Defined but not used" for recursive expressions Message-ID: <044.19b68ec1d205ec8eb1a618fa0da438d4@localhost> #2843: Missing "Defined but not used" for recursive expressions -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- {{{ a :: Int a = let b = "foo"++b in 42 }}} In this example {{{b}}} is not really used, but there is no warning by GHC. I assume this is so because {{{b}}} calls itself. If I remove {{{++b}}} then I get the warning as expected. (This reminds on the difference between a purely reference counting garbage collector and a correct one.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 5 18:22:20 2008 From: trac at galois.com (GHC) Date: Fri Dec 5 18:15:34 2008 Subject: [GHC] #2844: incorrect results when not compiling with optimisation Message-ID: <044.b6f4de74c6673f2c75a92a91b0801ec0@localhost> #2844: incorrect results when not compiling with optimisation -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: random1283 Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- This is a cut-down `random1283`. `R.hs`: {{{ module R (randomIO) where class Num a => Random a where randomIO :: IO a instance Random Int where randomIO = return 10003 }}} `s.hs`: {{{ import R main :: IO () main = do r >>= print r >>= print r :: IO Int r = randomIO }}} {{{ $ rm *.o *.hi s $ ghc -c R.hs $ ghc s.hs R.o -o s $ ./s -4611686018427387865 -4611686018427387865 $ rm *.o *.hi s $ ghc -c R.hs $ ghc s.hs R.o -o s -O $ ./s 10003 10003 $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.11.20081205 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 5 18:35:54 2008 From: trac at galois.com (GHC) Date: Fri Dec 5 18:29:08 2008 Subject: [GHC] #2844: incorrect results when not compiling with optimisation In-Reply-To: <044.b6f4de74c6673f2c75a92a91b0801ec0@localhost> References: <044.b6f4de74c6673f2c75a92a91b0801ec0@localhost> Message-ID: <053.3d9ffb2f5a22c56c89962176a77bc1b8@localhost> #2844: incorrect results when not compiling with optimisation ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: random1283 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Incidentally, {{{ (gdb) print /x -4611686018427387865 $1 = 0xc000000000000027 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 5 19:03:51 2008 From: trac at galois.com (GHC) Date: Fri Dec 5 18:57:05 2008 Subject: [GHC] #2845: break018 skips a step Message-ID: <044.0003cf5e2a1fd7406c40a8a9f2419a73@localhost> #2845: break018 skips a step -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: break018 Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- The `break018` test is failing: {{{ @@ -1,13 +1,11 @@ Stopped at ../mdo.hs:(29,0)-(31,26) -_result :: IO (N a) = _ -Stopped at ../mdo.hs:(29,15)-(31,26) -_result :: IO (N Char) = _ -x :: Char = 'h' -xs :: [Char] = _ +_result :: (# GHC.Prim.State# GHC.Prim.RealWorld, N a #) = _ Stopped at ../mdo.hs:29:29-41 _result :: IO (N Char) = _ f :: N Char = _ l :: N Char = _ x :: Char = 'h' Stopped at ../mdo.hs:(7,0)-(8,41) -_result :: IO (N a) = _ +_result :: (# GHC.Prim.State# GHC.Prim.RealWorld, N a #) = _ +Stopped at ../mdo.hs:7:25-38 +_result :: IO (IORef Bool) = _ *** unexpected failure for break018(ghci) }}} What's happening here is that as we `:st` through the evaluation we aren't stopping at the `mdo` expression any more; we go straight from the entire `l2dll` to the `newNode` expression: {{{ l2dll :: [a] -> IO (N a) l2dll (x:xs) = mdo c <- newNode l x f (f, l) <- l2dll' c xs return c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 5 19:52:00 2008 From: trac at galois.com (GHC) Date: Fri Dec 5 19:45:15 2008 Subject: [GHC] #2813: Create a utf8 bytestring-a-like In-Reply-To: <044.ad636022be236bf694f594b538272960@localhost> References: <044.ad636022be236bf694f594b538272960@localhost> Message-ID: <053.c7886bd3c443c701c91a4e96fc3433f5@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 bos): * cc: bos@serpentine.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 5 23:01:58 2008 From: trac at galois.com (GHC) Date: Fri Dec 5 22:55:16 2008 Subject: [GHC] #2846: GHC crash by type signature Message-ID: <047.702be30b58ea1c05667f49195863703f@localhost> #2846: GHC crash by type signature ------------------------+--------------------------------------------------- Reporter: mm_freak | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: major Keywords: crash, type | Testcase: Os: Linux | Architecture: x86_64 (amd64) ------------------------+--------------------------------------------------- Quick and dirty, this is the bug: {{{ Prelude> [1,2,3] :: [Num a => a] ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): TcTyFuns.flattenType: unexpected PredType }}} I'm running Gentoo Linux. I can reproduce this bug in the interpreter as well as in the compiler. It seems like it happens only with {{{-fglasgow- exts}}}, and only if you use {{{show}}} on that specific list. It doesn't happen, if you only use the head or the tail of the list. There is also no problem with appending something using {{{(++)}}} or consing through {{{(:)}}}. This is an amd64 architecture, but I'm using a 32 bits system, so this should be irrelevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 06:18:57 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 06:12:10 2008 Subject: [GHC] #2813: Create a utf8 bytestring-a-like In-Reply-To: <044.ad636022be236bf694f594b538272960@localhost> References: <044.ad636022be236bf694f594b538272960@localhost> Message-ID: <053.52f2a620e394f66049102159e749bd52@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 tibbe): * cc: johan.tibell@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 07:03:23 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 06:56:36 2008 Subject: [GHC] #2847: Failure on OPTION_* pramgas other than GHC Message-ID: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> #2847: Failure on OPTION_* pramgas other than GHC -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- GHC should not attempt to look at other peoples pragmas. For example: {{{ {-# OPTIONS_DERIVE --derive=Data,Typeable,Eq,Ord #-} module Example where data Foo = Bar }}} This worked fine with GHC 6.8, but doesn't with GHC 6.10. It says: {{{ C:\Neil\derive>ghc Example.hs -c Example.hs:1:11-48: unknown flag in {-# OPTIONS #-} pragma: _DERIVE Example.hs:1:11-48: unknown flag in {-# OPTIONS #-} pragma: --derive=Data,Typeable,Eq,Ord }}} I consider this to be a major regression, as it breaks (amongst other things) the Yhc compiler, the Derive tool, and my thesis. I suspect it will also break anything Malcolm has set up with OPTION_YHC or OPTION_NHC pragmas. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 07:05:33 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 06:58:46 2008 Subject: [GHC] #2848: ThreadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. Message-ID: <045.2e7f92bb3f888287061f94509936d31a@localhost> #2848: ThreadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. -----------------------------+---------------------------------------------- Reporter: tomekz | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: critical Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- We(*) have found a serious bug in the non-threaded RTS on 32-bit *nix systems. Calling threadDelay at certain clock-time intervals can make the thread wait forever. This happens regularly, approximately every 49 days 17 hours, or, more accurately, every (2^32 / 1000) seconds. You can reproduce the bug with a simple program, if you set your machine's clock to a specially crafted time. In this description I assume a 32-bit *nix system, where the type unsigned long has 32 bits. If you want to see this happen, here is an instruction: Test.hs: {{{ import Control.Concurrent main = threadDelay 5000000 -- 5 secs }}} Running on Linux, as root: {{{ # date --set 'Thu Jan 22 20:20:10 UTC 2009' +%s; strace ./Delay ... gettimeofday({1232655610, 12122}, NULL) = 0 gettimeofday({1232655610, 12171}, NULL) = 0 gettimeofday({1232655610, 12195}, NULL) = 0 select(0, [], [], NULL, {5, 20000}) = 0 (Timeout) gettimeofday({1232655615, 32125}, NULL) = 0 select(0, [], [], NULL, {0, 4000}) = 0 (Timeout) gettimeofday({1232655615, 35777}, NULL) = 0 select(0, [], [], NULL, {0, 4000}) = 0 (Timeout) gettimeofday({1232655615, 40039}, NULL) = 0 select(0, [], [], NULL, {4294, 951296} }}} The runtime slept for more than 5 seconds, but it didn't wake up the thread, but instead started waiting for an evil looking amount of time. I've managed to find the exact location of the bug, in function getourtimeofday() in rts/posix/Itimer.c. Other parts of non-threaded RTS, and especially the function awaitEvent(rtsBool) in rts/posix/Select.c, assume that the results of getourtimeofday() use the full range of values in lnat. But this isn't so. Let's take a look at the current version of this function: {{{ lnat getourtimeofday(void) { struct timeval tv; nat interval; interval = RtsFlags.MiscFlags.tickInterval; if (interval == 0) { interval = 50; } gettimeofday(&tv, (struct timezone *) NULL); // cast to lnat because nat may be 64 bit when int is only 32 bit return ((lnat)tv.tv_sec * 1000 / interval + (lnat)tv.tv_usec / (interval * 1000)); } }}} Look at the first half of the expression in the return statement: {{{ (lnat)tv.tv_sec * 1000 / interval }}} Here, tv.tv_sec is first converted to lnat, than multiplied by 1000, and finally divided by interval. lnat is defined as "unsigned long" - on a 32-bit system this is usually a 32-bit type. The result of multiplying by 1000 will have its higher bits lost and it will be in the range [0 .. 2^32 - 1]. Dividing it by interval will shrink the range to [0 .. (2^32 - 1) / interval]. With default value of tickInterval - which is 50 - this will be [0 .. 85899345]. Adding the second part of the expression can only increase it by (999999 / (interval * 1000)), which is equal to 19 with default settings. So, for default parameters, the result of getourtimeofday() will be in [0 .. 85899364]. Why is it a problem? It's quite simple: When a thread executes threadDelay the runtime calculates the tick at which it should be woken up. In our example, threadDelay is executed at tick 85899266, and the time of wake-up is probably calculated as 85899266 + 5 * (1000 / 50) = 85899366. This is greater then the biggest value getourtimeofday() can return. At this point I've probably already given too much detail, so I'll stop. I think the fix is quite easy: just perform the problematic part of computation on a wider integral type and cast it to lnat at the end. There is also an easy workaround: compile your program with -threaded. The threaded runtime does not use this code, and AFAICT, the time is tracked using a 64-bit number of microseconds. When I was trying to understand the problem, for some time the culprit for me was the "clever trick" mentionad at the top of rts/posix/Select.c. Now I understand it better and think it's innocent. We have found this bug in GHC 6.6, and it's still there in the HEAD. (*) "We" means Mariusz G?darowski, Przemys?aw Kosiak, Jakub Bogusz and Tomasz Zielonka - employees of Gemius SA in Poland. Mariusz and Przemek encountered this bug in their haskell system for distributing computations on a cluster. Mariusz and Jakub provided data about the symptoms of the problem - that was invaluable because, as you can now see, the bug was very difficult to reproduce. Tomasz finally spent four hours in solitude to nail the bug, and another hour to write this report. The problem repeated itself for serveral months, and in desperation Mariusz started to think about rewriting the system in C++. Unfortunately, there is still such a posibility, because we have another similar problem to solve. We are more optimistic now, but this event raised some doubts about the development model of GHC. We are afraid that with the current emphasis on adding new features you may be adding bugs faster that you are removing them :-/ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 07:06:38 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 06:59:51 2008 Subject: [GHC] #2848: ThreadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.10c3d68e0eb96650cd6e3b3a750dff9c@localhost> #2848: ThreadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ------------------------------------------------------------+--------------- Reporter: tomekz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------------------------------------+--------------- Changes (by tomekz): * keywords: => ticks getourtimeofday threadDelay non-threaded -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 07:07:33 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 07:00:46 2008 Subject: [GHC] #2848: ThreadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.2ab104ef20fa2069e69f2447458bd06b@localhost> #2848: ThreadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ------------------------------------------------------------+--------------- Reporter: tomekz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Testcase: Os: Linux | Architecture: x86 ------------------------------------------------------------+--------------- Changes (by tomekz): * version: 6.10.1 => 6.8.1 * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 07:07:53 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 07:01:06 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.7ca8efadae5ec44c93b96397e6a37736@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ------------------------------------------------------------+--------------- Reporter: tomekz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Testcase: Os: Linux | Architecture: x86 ------------------------------------------------------------+--------------- Changes (by tomekz): * summary: ThreadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. => threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 07:10:55 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 07:05:56 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.c0114d1a7d02d2a3aaf572cb61b2415f@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ------------------------------------------------------------+--------------- Reporter: tomekz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Testcase: Os: Linux | Architecture: x86 ------------------------------------------------------------+--------------- Changes (by tomekz): * cc: tomasz.zielonka@gemius.pl, mariusz.gadarowski@gemius.pl, przemyslaw.kosiak@gemius.pl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 07:15:19 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 07:10:13 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.e5abf0520b801c6b91e596f306b03a0d@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ------------------------------------------------------------+--------------- Reporter: tomekz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Testcase: Os: Linux | Architecture: x86 ------------------------------------------------------------+--------------- Comment (by tomekz): Sorry for messing the report up with superscripts. I wanted to use the ^ character literally, as an exponentiation operator. Is there a way to edit the description now? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 07:15:37 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 07:10:31 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.0e720e2207bf5bf24294fce39a8afd35@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ------------------------------------------------------------+--------------- Reporter: tomekz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Testcase: Os: Linux | Architecture: x86 ------------------------------------------------------------+--------------- Comment (by tomekz): Damn! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 08:28:22 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 08:21:34 2008 Subject: [GHC] #2844: incorrect results when not compiling with optimisation In-Reply-To: <044.b6f4de74c6673f2c75a92a91b0801ec0@localhost> References: <044.b6f4de74c6673f2c75a92a91b0801ec0@localhost> Message-ID: <053.f7e88044435584c10dca4c629cf3cf40@localhost> #2844: incorrect results when not compiling with optimisation ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: random1283 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Well boiled down! This is a pretty serious bug. I'm ''astonished'' that it hasn't broken anything else. I'll get on it on the plane... Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 10:11:21 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 10:04:46 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.2a4a212140b9ca3b70d88b8cd36f167a@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ---------------------------------------------------------------+------------ Reporter: tomekz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------------------------+------------ Changes (by igloo): * difficulty: => Unknown Old description: > We(*) have found a serious bug in the non-threaded RTS on 32-bit *nix > systems. > Calling threadDelay at certain clock-time intervals can make the thread > wait forever. This happens regularly, approximately every 49 days 17 > hours, > or, more accurately, every (2^32 / 1000) seconds. You can reproduce the > bug with > a simple program, if you set your machine's clock to a specially crafted > time. > > In this description I assume a 32-bit *nix system, where the type > unsigned long has 32 bits. > > If you want to see this happen, here is an instruction: > > Test.hs: > > {{{ > import Control.Concurrent > > main = threadDelay 5000000 -- 5 secs > }}} > > Running on Linux, as root: > > {{{ > # date --set 'Thu Jan 22 20:20:10 UTC 2009' +%s; strace ./Delay > ... > gettimeofday({1232655610, 12122}, NULL) = 0 > gettimeofday({1232655610, 12171}, NULL) = 0 > gettimeofday({1232655610, 12195}, NULL) = 0 > select(0, [], [], NULL, {5, 20000}) = 0 (Timeout) > gettimeofday({1232655615, 32125}, NULL) = 0 > select(0, [], [], NULL, {0, 4000}) = 0 (Timeout) > gettimeofday({1232655615, 35777}, NULL) = 0 > select(0, [], [], NULL, {0, 4000}) = 0 (Timeout) > gettimeofday({1232655615, 40039}, NULL) = 0 > select(0, [], [], NULL, {4294, 951296} > }}} > > The runtime slept for more than 5 seconds, but it didn't wake up the > thread, but instead started waiting for an evil looking amount of time. > > I've managed to find the exact location of the bug, in function > getourtimeofday() in rts/posix/Itimer.c. Other parts of non-threaded > RTS, and especially the function awaitEvent(rtsBool) in > rts/posix/Select.c, assume that the results of getourtimeofday() use the > full range of values in lnat. But this isn't so. Let's take a look at > the current version of this function: > > {{{ > lnat > getourtimeofday(void) > { > struct timeval tv; > nat interval; > interval = RtsFlags.MiscFlags.tickInterval; > if (interval == 0) { interval = 50; } > gettimeofday(&tv, (struct timezone *) NULL); > // cast to lnat because nat may be 64 bit when int is only 32 bit > return ((lnat)tv.tv_sec * 1000 / interval + > (lnat)tv.tv_usec / (interval * 1000)); > } > }}} > > Look at the first half of the expression in the return statement: > > {{{ > (lnat)tv.tv_sec * 1000 / interval > }}} > > Here, tv.tv_sec is first converted to lnat, than multiplied by 1000, and > finally divided by interval. lnat is defined as "unsigned long" - on a > 32-bit system this is usually a 32-bit type. The result of multiplying > by 1000 will have its higher bits lost and it will be in the range [0 .. > 2^32 - 1]. Dividing it by interval will shrink the range to [0 .. (2^32 > - 1) / interval]. With default value of tickInterval - which is 50 - > this will be [0 .. 85899345]. Adding the second part of the expression > can only increase it by (999999 / (interval * 1000)), which is equal to > 19 with default settings. > > So, for default parameters, the result of getourtimeofday() will be in > [0 .. 85899364]. Why is it a problem? It's quite simple: When a thread > executes threadDelay the runtime calculates the tick at which it should > be woken up. In our example, threadDelay is executed at tick 85899266, > and the time of wake-up is probably calculated as 85899266 + 5 * (1000 / > 50) = 85899366. This is greater then the biggest value getourtimeofday() > can return. > > At this point I've probably already given too much detail, so I'll > stop. I think the fix is quite easy: just perform the problematic part > of computation on a wider integral type and cast it to lnat at the end. > > There is also an easy workaround: compile your program with -threaded. > The threaded runtime does not use this code, and AFAICT, the time is > tracked using a 64-bit number of microseconds. > > When I was trying to understand the problem, for some time the culprit > for me was the "clever trick" mentionad at the top of > rts/posix/Select.c. Now I understand it better and think it's innocent. > > We have found this bug in GHC 6.6, and it's still there in the HEAD. > > (*) "We" means Mariusz G?darowski, Przemys?aw Kosiak, Jakub Bogusz and > Tomasz Zielonka - employees of Gemius SA in Poland. > Mariusz and Przemek encountered this bug in their haskell system for > distributing computations on a cluster. Mariusz and Jakub provided data > about the symptoms of the problem - that was invaluable > because, as you can now see, the bug was very difficult to reproduce. > Tomasz finally spent four hours in solitude to nail the bug, and another > hour to write this report. The problem repeated itself for serveral > months, and in desperation Mariusz started to think about rewriting the > system in C++. Unfortunately, there is still such a posibility, because > we have another similar problem to solve. We are more optimistic now, but > this event raised some doubts about the development model of GHC. We are > afraid that with the current emphasis on adding new features you may be > adding > bugs faster that you are removing them :-/ New description: We(*) have found a serious bug in the non-threaded RTS on 32-bit *nix systems. Calling threadDelay at certain clock-time intervals can make the thread wait forever. This happens regularly, approximately every 49 days 17 hours, or, more accurately, every `(2^32 / 1000)` seconds. You can reproduce the bug with a simple program, if you set your machine's clock to a specially crafted time. In this description I assume a 32-bit *nix system, where the type unsigned long has 32 bits. If you want to see this happen, here is an instruction: Test.hs: {{{ import Control.Concurrent main = threadDelay 5000000 -- 5 secs }}} Running on Linux, as root: {{{ # date --set 'Thu Jan 22 20:20:10 UTC 2009' +%s; strace ./Delay ... gettimeofday({1232655610, 12122}, NULL) = 0 gettimeofday({1232655610, 12171}, NULL) = 0 gettimeofday({1232655610, 12195}, NULL) = 0 select(0, [], [], NULL, {5, 20000}) = 0 (Timeout) gettimeofday({1232655615, 32125}, NULL) = 0 select(0, [], [], NULL, {0, 4000}) = 0 (Timeout) gettimeofday({1232655615, 35777}, NULL) = 0 select(0, [], [], NULL, {0, 4000}) = 0 (Timeout) gettimeofday({1232655615, 40039}, NULL) = 0 select(0, [], [], NULL, {4294, 951296} }}} The runtime slept for more than 5 seconds, but it didn't wake up the thread, but instead started waiting for an evil looking amount of time. I've managed to find the exact location of the bug, in function getourtimeofday() in rts/posix/Itimer.c. Other parts of non-threaded RTS, and especially the function awaitEvent(rtsBool) in rts/posix/Select.c, assume that the results of getourtimeofday() use the full range of values in lnat. But this isn't so. Let's take a look at the current version of this function: {{{ lnat getourtimeofday(void) { struct timeval tv; nat interval; interval = RtsFlags.MiscFlags.tickInterval; if (interval == 0) { interval = 50; } gettimeofday(&tv, (struct timezone *) NULL); // cast to lnat because nat may be 64 bit when int is only 32 bit return ((lnat)tv.tv_sec * 1000 / interval + (lnat)tv.tv_usec / (interval * 1000)); } }}} Look at the first half of the expression in the return statement: {{{ (lnat)tv.tv_sec * 1000 / interval }}} Here, tv.tv_sec is first converted to lnat, than multiplied by 1000, and finally divided by interval. lnat is defined as "unsigned long" - on a 32-bit system this is usually a 32-bit type. The result of multiplying by 1000 will have its higher bits lost and it will be in the range `[0 .. 2^32 - 1]`. Dividing it by interval will shrink the range to `[0 .. (2^32 - 1) / interval]`. With default value of tickInterval - which is `50` - this will be `[0 .. 85899345]`. Adding the second part of the expression can only increase it by `(999999 / (interval * 1000))`, which is equal to 19 with default settings. So, for default parameters, the result of getourtimeofday() will be in `[0 .. 85899364]`. Why is it a problem? It's quite simple: When a thread executes threadDelay the runtime calculates the tick at which it should be woken up. In our example, threadDelay is executed at tick 85899266, and the time of wake-up is probably calculated as `85899266 + 5 * (1000 / 50) = 85899366`. This is greater then the biggest value `getourtimeofday()` can return. At this point I've probably already given too much detail, so I'll stop. I think the fix is quite easy: just perform the problematic part of computation on a wider integral type and cast it to lnat at the end. There is also an easy workaround: compile your program with -threaded. The threaded runtime does not use this code, and AFAICT, the time is tracked using a 64-bit number of microseconds. When I was trying to understand the problem, for some time the culprit for me was the "clever trick" mentionad at the top of rts/posix/Select.c. Now I understand it better and think it's innocent. We have found this bug in GHC 6.6, and it's still there in the HEAD. (*) "We" means Mariusz G?darowski, Przemys?aw Kosiak, Jakub Bogusz and Tomasz Zielonka - employees of Gemius SA in Poland. Mariusz and Przemek encountered this bug in their haskell system for distributing computations on a cluster. Mariusz and Jakub provided data about the symptoms of the problem - that was invaluable because, as you can now see, the bug was very difficult to reproduce. Tomasz finally spent four hours in solitude to nail the bug, and another hour to write this report. The problem repeated itself for serveral months, and in desperation Mariusz started to think about rewriting the system in C++. Unfortunately, there is still such a posibility, because we have another similar problem to solve. We are more optimistic now, but this event raised some doubts about the development model of GHC. We are afraid that with the current emphasis on adding new features you may be adding bugs faster that you are removing them :-/ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 10:18:16 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 10:11:38 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.a4c3212f9b48538445d8b7c058b82d73@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ---------------------------------------------------------------+------------ Reporter: tomekz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------------------------+------------ Comment (by igloo): Replying to [ticket:2848 tomekz]: > > We are more optimistic now, but > this event raised some doubts about the development model of GHC. We are > afraid that with the current emphasis on adding new features you may be adding > bugs faster that you are removing them :-/ If you want to discuss this, I think it would be best to bring it up on the glasgow-haskell-users mailing list, rather than burying it in a bug report where most people won't see it and where it could drown out the actual bug report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 14:23:33 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 14:16:58 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.0ca448156be78ff1040cac878535caba@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ---------------------------------------------------------------+------------ Reporter: tomekz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------------------------+------------ Comment (by tomekz): Good point. Perhaps we are exaggerating. What this bug can tell us is probably not about the development model, but about how much GHC is used for critical, continuously running systems. One would think that someone should already encounter this. On the other hand, the bug won't manifest itself in a threaded runtime, and such systems may tend to use it... In fact, the main components of our system use the threaded RTS, and bug manifested itself in a small program which is the command-line interface to the system. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 14:31:30 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 14:24:51 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.110ee3a074b792b4861ce5c0429ac9ec@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ---------------------------------------------------------------+------------ Reporter: tomekz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------------------------+------------ Comment (by dons): tomekz, Galois has a lot of continuously running systems (as there are also in the wider Haskell industrial and open source world (e.g. xmonad!)), and I'm not aware of anyone encountering this. Typically we use the threaded runtime though, if using threadDelay, for any serious system, which might explain the result. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 14:47:11 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 14:40:33 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.c57fcc30e1034a8f421a8510dbbec0ee@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ---------------------------------------------------------------+------------ Reporter: tomekz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------------------------+------------ Comment (by tomekz): Ha! I've just found these words from Simon Marlow, in glasgow-haskell- users thread "ghci and ghc -threaded broken with pipes & forking" from March 2007: In fact you should think of the non-threaded RTS as deprecated. It isn't Haskell'-compliant, for one thing (assuming that Haskell' will probably require non-blocking foreign calls). I'm hesitant to actually deprecate it, for a few reasons: the threaded RTS is so much more complicated, it might have some adverse performance impliciations, and there are still people who want to run everything in a single OS thread, for whatever reason. But having multiple variants of the RTS is a maintenance and testing headache. One more reason to deprecate the non-threaded RTS, or at least to pick the threaded by default. I'll add something to that discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 19:25:33 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 19:18:43 2008 Subject: [GHC] #2831: Floated error expressions get poor strictness, leaving bad arity In-Reply-To: <046.8cc1f5167158ac5c2c686513574acede@localhost> References: <046.8cc1f5167158ac5c2c686513574acede@localhost> Message-ID: <055.53a5ccf06722efe19979baa7c15a7aa0@localhost> #2831: Floated error expressions get poor strictness, leaving bad arity -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 19:26:48 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 19:19:58 2008 Subject: [GHC] #2823: Another arity expansion bug In-Reply-To: <046.50a7eb0bd1d6f872efa506bccfff4122@localhost> References: <046.50a7eb0bd1d6f872efa506bccfff4122@localhost> Message-ID: <055.a647fb8149c660d24f84251d2ba13bc0@localhost> #2823: Another arity expansion bug -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 19:28:26 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 19:21:35 2008 Subject: [GHC] #2822: Arity expansion not working right In-Reply-To: <046.15a4d7e08c29ef55ed5596df1606d405@localhost> References: <046.15a4d7e08c29ef55ed5596df1606d405@localhost> Message-ID: <055.334fd90536d29bd6b50f3440b217bf2e@localhost> #2822: Arity expansion not working right -----------------------------------------+---------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 19:39:25 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 19:32:49 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.a457be9ae333a038608f39dde4e0f5fc@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ---------------------------------------------------------------+------------ Reporter: tomekz | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------------------------+------------ Changes (by igloo): * priority: normal => high * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 19:39:55 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 19:33:16 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.8b65e3d6a8afc708b1db6491a4038103@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ---------------------------------------------------------------+------------ Reporter: tomekz | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------------------------+------------ Comment (by igloo): Thanks for the detailed diagnosis! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 19:47:04 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 19:40:15 2008 Subject: [GHC] #2847: Failure on OPTION_* pramgas other than GHC In-Reply-To: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> References: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> Message-ID: <060.053097ef0aefe426fcda7baf7f756e37@localhost> #2847: Failure on OPTION_* pramgas other than GHC ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 19:48:48 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 19:42:02 2008 Subject: [GHC] #2846: GHC crash by type signature In-Reply-To: <047.702be30b58ea1c05667f49195863703f@localhost> References: <047.702be30b58ea1c05667f49195863703f@localhost> Message-ID: <056.6d8e4a89dbe197a7bdc1fed831576d44@localhost> #2846: GHC crash by type signature ---------------------------------+------------------------------------------ Reporter: mm_freak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: crash, type | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple * milestone: => 6.10.2 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 6 19:53:23 2008 From: trac at galois.com (GHC) Date: Sat Dec 6 19:46:35 2008 Subject: [GHC] #2843: Missing "Defined but not used" for recursive expressions In-Reply-To: <044.19b68ec1d205ec8eb1a618fa0da438d4@localhost> References: <044.19b68ec1d205ec8eb1a618fa0da438d4@localhost> Message-ID: <053.6de4ab5781f79a1b95f049200a4a7b1d@localhost> #2843: Missing "Defined but not used" for recursive expressions ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. Happily, 6.10.1 (and the HEAD) already warns about this correctly: {{{ b.hs:4:6: Warning: Defined but not used: `b' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 00:52:59 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 00:46:08 2008 Subject: [GHC] #2849: RegAllocLinear.getStackSlotFor: out of stack slots Message-ID: <043.e245679f34edc0a3b4b7999d23ae571a@localhost> #2849: RegAllocLinear.getStackSlotFor: out of stack slots --------------------+------------------------------------------------------- Reporter: hydo | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- bash$ sudo cabal install --global HAppSHelpers ... 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.1 for i386-apple-darwin): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug bash-3.2$ ghc-pkg list /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/./package.conf: Cabal-1.6.0.1, HAppS-Data-0.9.3, HAppS-IxSet-0.9.3, HAppS-Server-0.9.3.1, HAppS-State-0.9.3, HAppS-Util-0.9.3, HSH-1.2.6, HStringTemplate-0.4.3, HStringTemplateHelpers-0.0.3, HTTP-3001.1.3, HUnit-1.2.0.3, HaXml-1.13.3, MissingH-1.0.2.1, QuickCheck-1.2.0.0, array-0.2.0.0, base-3.0.3.0, base-4.0.0.0, binary-0.4.4, bytestring-0.9.1.4, cairo-0.9.13, containers-0.2.0.0, directory-1.0.0.2, (dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3), editline-0.2.1.0, filepath-1.1.0.1, gconf-0.9.13, (ghc-6.10.1), ghc-prim-0.1.0.0, glade-0.9.13, glib-0.9.13, gnomevfs-0.9.13, gtk-0.9.13, gtkglext-0.9.13, haddock-2.3.0, haskell-src-1.0.1.3, haskell98-1.0.1.0, hpc-0.5.0.2, hscolour-1.10.1, hslogger-1.0.6, hspread-0.3, html-1.0.1.2, integer-0.1.0.0, mtl-1.1.0.2, network-2.2.0.1, old-locale-1.0.0.1, old-time-1.0.0.1, packedstring-0.1.0.1, parallel-1.1.0.0, parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.0, pureMD5-0.2.4, random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, safe-0.2, soegtk-0.9.13, sourceview-0.9.13, stm-2.1.1.2, svgcairo-0.9.13, syb-0.1.0.0, syb-with-class-0.4, template-haskell-2.3.0.0, terminfo-0.2.2.1, time-1.1.2.2, unix-2.3.1.0, utf8-string-0.3.3, xhtml-3000.2.0.1, zip-archive-0.1.1.1, zlib-0.4.0.4, zlib-0.5.0.0 bash-3.2$ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 07:10:34 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 07:03:44 2008 Subject: [GHC] #2842: http://darcs.haskell.org/darcsweb/ throwing errors. In-Reply-To: <043.148ddb378151a29e56e684c5277e227e@localhost> References: <043.148ddb378151a29e56e684c5277e227e@localhost> Message-ID: <052.9d20066dcb24024fd855cdc2c0406b5d@localhost> #2842: http://darcs.haskell.org/darcsweb/ throwing errors. ---------------------------------+------------------------------------------ Reporter: hydo | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: External Core | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC Comment: Thanks for letting us know -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 07:45:45 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 07:38:56 2008 Subject: [GHC] #2841: Ghci + foreign export declarations result in undefined symbols In-Reply-To: <044.b0747800033e264d294e9c1520f847f6@localhost> References: <044.b0747800033e264d294e9c1520f847f6@localhost> Message-ID: <053.cc97370bc2aed05afc3183a64f2d8ced@localhost> #2841: Ghci + foreign export declarations result in undefined symbols ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler (FFI) | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => _|_ Comment: This is documented as not working: * http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci.html#ftn.id2575959 * http://www.haskell.org/ghc/docs/latest/html/users_guide/ghci-faq.html but I can't find a bug report for it, so I'll leave this one open. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 07:52:16 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 07:45:26 2008 Subject: [GHC] #2838: -fasm codeGen doesn't truncate CMMInt's at the right place In-Reply-To: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> References: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> Message-ID: <062.b5fa62b224a53ea1bbaca9ad3521e5f6@localhost> #2838: -fasm codeGen doesn't truncate CMMInt's at the right place ---------------------------------+------------------------------------------ Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.10.2 Comment: What platform do you see this on? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 08:17:45 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 08:11:00 2008 Subject: [GHC] #2828: TcTyFuns.uMeta: normalisation shouldn't allow x ~ x In-Reply-To: <044.818395155a9d2081de37d5cedbd2ca16@localhost> References: <044.818395155a9d2081de37d5cedbd2ca16@localhost> Message-ID: <053.1ccbd792ffef96bcc09982ebfd2d41ca@localhost> #2828: TcTyFuns.uMeta: normalisation shouldn't allow x ~ x -------------------------+-------------------------------------------------- Reporter: pizza | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 08:18:21 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 08:11:32 2008 Subject: [GHC] #2827: Win32 releases lack versioned binaries In-Reply-To: <044.f4f9519bc323ffec43db3e4ff5846813@localhost> References: <044.f4f9519bc323ffec43db3e4ff5846813@localhost> Message-ID: <053.a71ca827328cfcb6c144e01f3df6f681@localhost> #2827: Win32 releases lack versioned binaries ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10.2 Comment: Thanks for the report. These will likely be fixed at the same time, so I think keeping them in one ticket is OK. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 10:11:39 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 10:04:50 2008 Subject: [GHC] #2763: while installing cabal from darcs, 1.6.0.1 and 1.4.0.2 In-Reply-To: <044.967654beccd358d1d0ac92f7259473da@localhost> References: <044.967654beccd358d1d0ac92f7259473da@localhost> Message-ID: <053.c06c5cecf1d82cf495466e0663a74445@localhost> #2763: while installing cabal from darcs, 1.6.0.1 and 1.4.0.2 ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: cabal ghc ubuntu | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.10 branch Comment: I can't reproduce this. I don't know what the error means OTTOMH, so I'll leave it open for now, but my suspicion is that the problem is that a library upgrade left another library in a broken state or something. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 14:25:31 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 14:18:40 2008 Subject: [GHC] #2849: RegAllocLinear.getStackSlotFor: out of stack slots In-Reply-To: <043.e245679f34edc0a3b4b7999d23ae571a@localhost> References: <043.e245679f34edc0a3b4b7999d23ae571a@localhost> Message-ID: <052.fd4658a017a030d6ec3ea2d36924b95b@localhost> #2849: RegAllocLinear.getStackSlotFor: out of stack slots -------------------------+-------------------------------------------------- Reporter: hydo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > bash$ sudo cabal install --global HAppSHelpers > ... > 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.1 for i386-apple-darwin): > RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- > graph > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > bash-3.2$ ghc-pkg list > /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/./package.conf: > Cabal-1.6.0.1, HAppS-Data-0.9.3, HAppS-IxSet-0.9.3, > HAppS-Server-0.9.3.1, HAppS-State-0.9.3, HAppS-Util-0.9.3, > HSH-1.2.6, HStringTemplate-0.4.3, HStringTemplateHelpers-0.0.3, > HTTP-3001.1.3, HUnit-1.2.0.3, HaXml-1.13.3, MissingH-1.0.2.1, > QuickCheck-1.2.0.0, array-0.2.0.0, base-3.0.3.0, base-4.0.0.0, > binary-0.4.4, bytestring-0.9.1.4, cairo-0.9.13, containers-0.2.0.0, > directory-1.0.0.2, (dph-base-0.3), (dph-par-0.3), > (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3), > (dph-seq-0.3), editline-0.2.1.0, filepath-1.1.0.1, gconf-0.9.13, > (ghc-6.10.1), ghc-prim-0.1.0.0, glade-0.9.13, glib-0.9.13, > gnomevfs-0.9.13, gtk-0.9.13, gtkglext-0.9.13, haddock-2.3.0, > haskell-src-1.0.1.3, haskell98-1.0.1.0, hpc-0.5.0.2, > hscolour-1.10.1, hslogger-1.0.6, hspread-0.3, html-1.0.1.2, > integer-0.1.0.0, mtl-1.1.0.2, network-2.2.0.1, old-locale-1.0.0.1, > old-time-1.0.0.1, packedstring-0.1.0.1, parallel-1.1.0.0, > parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.0, pureMD5-0.2.4, > random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1, > regex-posix-0.72.0.3, rts-1.0, safe-0.2, soegtk-0.9.13, > sourceview-0.9.13, stm-2.1.1.2, svgcairo-0.9.13, syb-0.1.0.0, > syb-with-class-0.4, template-haskell-2.3.0.0, terminfo-0.2.2.1, > time-1.1.2.2, unix-2.3.1.0, utf8-string-0.3.3, xhtml-3000.2.0.1, > zip-archive-0.1.1.1, zlib-0.4.0.4, zlib-0.5.0.0 > bash-3.2$ New description: {{{ bash$ sudo cabal install --global HAppSHelpers ... 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.1 for i386-apple-darwin): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{ bash-3.2$ ghc-pkg list /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/./package.conf: Cabal-1.6.0.1, HAppS-Data-0.9.3, HAppS-IxSet-0.9.3, HAppS-Server-0.9.3.1, HAppS-State-0.9.3, HAppS-Util-0.9.3, HSH-1.2.6, HStringTemplate-0.4.3, HStringTemplateHelpers-0.0.3, HTTP-3001.1.3, HUnit-1.2.0.3, HaXml-1.13.3, MissingH-1.0.2.1, QuickCheck-1.2.0.0, array-0.2.0.0, base-3.0.3.0, base-4.0.0.0, binary-0.4.4, bytestring-0.9.1.4, cairo-0.9.13, containers-0.2.0.0, directory-1.0.0.2, (dph-base-0.3), (dph-par-0.3), (dph-prim-interface-0.3), (dph-prim-par-0.3), (dph-prim-seq-0.3), (dph-seq-0.3), editline-0.2.1.0, filepath-1.1.0.1, gconf-0.9.13, (ghc-6.10.1), ghc-prim-0.1.0.0, glade-0.9.13, glib-0.9.13, gnomevfs-0.9.13, gtk-0.9.13, gtkglext-0.9.13, haddock-2.3.0, haskell-src-1.0.1.3, haskell98-1.0.1.0, hpc-0.5.0.2, hscolour-1.10.1, hslogger-1.0.6, hspread-0.3, html-1.0.1.2, integer-0.1.0.0, mtl-1.1.0.2, network-2.2.0.1, old-locale-1.0.0.1, old-time-1.0.0.1, packedstring-0.1.0.1, parallel-1.1.0.0, parsec-2.1.0.1, pretty-1.0.1.0, process-1.0.1.0, pureMD5-0.2.4, random-1.0.0.1, regex-base-0.72.0.2, regex-compat-0.71.0.1, regex-posix-0.72.0.3, rts-1.0, safe-0.2, soegtk-0.9.13, sourceview-0.9.13, stm-2.1.1.2, svgcairo-0.9.13, syb-0.1.0.0, syb-with-class-0.4, template-haskell-2.3.0.0, terminfo-0.2.2.1, time-1.1.2.2, unix-2.3.1.0, utf8-string-0.3.3, xhtml-3000.2.0.1, zip-archive-0.1.1.1, zlib-0.4.0.4, zlib-0.5.0.0 bash-3.2$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 14:26:42 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 14:19:51 2008 Subject: [GHC] #2849: RegAllocLinear.getStackSlotFor: out of stack slots In-Reply-To: <043.e245679f34edc0a3b4b7999d23ae571a@localhost> References: <043.e245679f34edc0a3b4b7999d23ae571a@localhost> Message-ID: <052.6c219c350abd629ee30ed73e741c300c@localhost> #2849: RegAllocLinear.getStackSlotFor: out of stack slots -------------------------+-------------------------------------------------- Reporter: hydo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. This looks like a duplicate of #1993. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 14:29:54 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 14:23:13 2008 Subject: [GHC] #2836: Data.Typeable does not use qualified names In-Reply-To: <044.8f82fa3eeec008c76155a3a9d33ae83d@localhost> References: <044.8f82fa3eeec008c76155a3a9d33ae83d@localhost> Message-ID: <053.fd0541613607e629f86e99f1dc1d78a4@localhost> #2836: Data.Typeable does not use qualified names ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 14:32:10 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 14:25:18 2008 Subject: [GHC] #2833: internal error: throwTo: unrecognised why_blocked value In-Reply-To: <044.241eea212892e1f7fdf89a6a715bfb1f@localhost> References: <044.241eea212892e1f7fdf89a6a715bfb1f@localhost> Message-ID: <053.b774a05975514b1318fec57767a56391@localhost> #2833: internal error: throwTo: unrecognised why_blocked value ---------------------------------+------------------------------------------ Reporter: lilac | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Old description: > The attached file, built with reactive 0.9.6 with the change listed below > (fix for reactive bug#14), exhibits some strange behaviour. When built > with -threaded and run without +RTS -N, everything is fine. When run with > +RTS -N2, it slows down dramatically (using <10% CPU on each of my cores) > and eventually crashes with: > {{{ > Main: internal error: throwTo: unrecognised why_blocked value > (GHC version 6.10.1 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > }}} > > The change to reactive (from http://hpaste.org/12528#a2) is to replace > snapshotWith in FRP/Reactive/PrimRecursive.hs with: > {{{ > snapshotWith :: forall a b c t. Ord t => > (a -> b -> c) -> EventG t a -> ReactiveG t b -> EventG t > c > snapshotWith f es rs = listEG . zip (eats es) . zipWith f (evals es) $ > rats rs (eats es) > > evals :: EventG t a -> [a] > evals (Event (Future (Max MaxBound, _))) = [] > evals (Event (Future (_, ~(v `Stepper` es)))) = v:evals es > > eats :: EventG t a -> [t] > eats (Event (Future (Max MaxBound, ~(_ `Stepper` es)))) = [] > eats (Event (Future (Max (NoBound t), ~(_ `Stepper` es)))) = t:eats es > eats (Event (Future (Max MinBound, ~(_ `Stepper` es)))) = eats es > }}} New description: The attached file, built with reactive 0.9.6 with the change listed below (fix for reactive bug!#14), exhibits some strange behaviour. When built with -threaded and run without +RTS -N, everything is fine. When run with +RTS -N2, it slows down dramatically (using <10% CPU on each of my cores) and eventually crashes with: {{{ Main: internal error: throwTo: unrecognised why_blocked value (GHC version 6.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The change to reactive (from http://hpaste.org/12528#a2) is to replace snapshotWith in FRP/Reactive/PrimRecursive.hs with: {{{ snapshotWith :: forall a b c t. Ord t => (a -> b -> c) -> EventG t a -> ReactiveG t b -> EventG t c snapshotWith f es rs = listEG . zip (eats es) . zipWith f (evals es) $ rats rs (eats es) evals :: EventG t a -> [a] evals (Event (Future (Max MaxBound, _))) = [] evals (Event (Future (_, ~(v `Stepper` es)))) = v:evals es eats :: EventG t a -> [t] eats (Event (Future (Max MaxBound, ~(_ `Stepper` es)))) = [] eats (Event (Future (Max (NoBound t), ~(_ `Stepper` es)))) = t:eats es eats (Event (Future (Max MinBound, ~(_ `Stepper` es)))) = eats es }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 14:32:38 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 14:25:45 2008 Subject: [GHC] #2833: internal error: throwTo: unrecognised why_blocked value In-Reply-To: <044.241eea212892e1f7fdf89a6a715bfb1f@localhost> References: <044.241eea212892e1f7fdf89a6a715bfb1f@localhost> Message-ID: <053.92a0363984a55a8108950579e4cc2c37@localhost> #2833: internal error: throwTo: unrecognised why_blocked value ---------------------------------+------------------------------------------ Reporter: lilac | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.10.2 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 15:34:46 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 15:28:07 2008 Subject: [GHC] #2760: Data.Generics.Basics.mkNorepType spelled wrong In-Reply-To: <044.b3884d30a8391ab9f46e5542669e8ee1@localhost> References: <044.b3884d30a8391ab9f46e5542669e8ee1@localhost> Message-ID: <053.729b03fc7486dd23b3b9faa7764de415@localhost> #2760: Data.Generics.Basics.mkNorepType spelled wrong ----------------------------------+----------------------------------------- Reporter: guest | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: assigned => closed * resolution: => fixed Comment: Applied, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 16:04:11 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 15:57:21 2008 Subject: [GHC] #2838: -fasm codeGen doesn't truncate CMMInt's at the right place In-Reply-To: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> References: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> Message-ID: <062.5fd8096f762d8d4fa2b8d8787d17b0c9@localhost> #2838: -fasm codeGen doesn't truncate CMMInt's at the right place ---------------------------------+------------------------------------------ Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by TristanAllwood): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 16:22:31 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 16:15:38 2008 Subject: [GHC] #2655: Control.Exception's Haddock document drop instruction about Extensible Exceptions In-Reply-To: <047.1bde2d0a50f92799bbadb2d6cc5101e0@localhost> References: <047.1bde2d0a50f92799bbadb2d6cc5101e0@localhost> Message-ID: <056.da7f69669c4becc2b767c5d52895daa7@localhost> #2655: Control.Exception's Haddock document drop instruction about Extensible Exceptions ---------------------------------+------------------------------------------ Reporter: shelarcy | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 16:37:51 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 16:31:03 2008 Subject: [GHC] #2699: broken pipe errors are too noisy In-Reply-To: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> References: <044.4d8cfcf130a4f232512c2899cde1f85e@localhost> Message-ID: <053.03a7f73274ff56e73e5733564e63fd2f@localhost> #2699: broken pipe errors are too noisy ---------------------------------+------------------------------------------ Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by int-e): So I gave this a try -- see the attachment. (The attachment is a shell script, because the changes span several packages, and I wanted the result to be readable and easy to apply.) There are several places in the libraries where {{{IOError}}} isn't used abstractly. My approach was to replace the constructor uses by a combination of {{{mkIOError}}} and {{{ioeSetErrorString}}}. The idea is that this way, the code should continue to work with {{{ghc-6.10.1}}} and also survive future changes to the {{{IOError}}} type, without adding more {{{#ifdef}}} clutter. Does this approach seem reasonable? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 7 22:43:19 2008 From: trac at galois.com (GHC) Date: Sun Dec 7 22:36:28 2008 Subject: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work Message-ID: <042.bfabde61c4aa31a17887ff9436d679ab@localhost> #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work -----------------------------+---------------------------------------------- Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- It would be nice if we could do stuff like this: {{{ {-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies, FlexibleContexts, FlexibleInstances #-} class K a where bar :: a -> a class K (B a) => M a where data B a :: * foo :: B a -> B a instance M Bool where data B Bool = B1Bool Bool | B2Bool Bool foo = id instance K (B Bool) where bar = id instance M Int where newtype B Int = BInt (B Bool) deriving K foo = id }}} which currently gives the error {{{ foo.hs:17:41: Can't make a derived instance of `K (B Int)' (even with cunning newtype deriving: the newtype may be recursive) In the newtype instance declaration for `B' }}} However, the newtype is not recursive, it is just an associated datatype from another class, so it seems like this ought to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 04:52:27 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 04:45:35 2008 Subject: [GHC] #2838: -fasm codeGen doesn't truncate CMMInt's at the right place In-Reply-To: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> References: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> Message-ID: <062.d2aaf572eb5b7d7773cf1f8d0a48e5be@localhost> #2838: -fasm codeGen doesn't truncate CMMInt's at the right place ---------------------------------+------------------------------------------ Reporter: TristanAllwood | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by TristanAllwood): * os: Windows => Unknown/Multiple Comment: I can reproduce under both Windows (vista) and linux i686 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 06:13:12 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 06:06:18 2008 Subject: [GHC] #2851: Deriving doesn't work when type families are involved Message-ID: <044.53dff063407021fb8c52e3be3626a0f5@localhost> #2851: Deriving doesn't work when type families are involved -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The following does not work: {{{ type family F a :: * data D a = D (F a) deriving (Show) }}} The natural way of adding an instance does work (with enough extensions turned on): {{{ instance (Show (F a)) => Show (D a) where show (D x) = "D " ++ show x }}} It would be nice if the deriving mechanism could derive this code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 06:34:35 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 06:27:40 2008 Subject: [GHC] #2852: Type family checking oddity Message-ID: <044.fdac353512d121dcac11b2fbc3873f76@localhost> #2852: Type family checking oddity -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Consider the following snipped {{{ class C a where type T a data D a = D (T a) }}} If we now ask for the type of D we get {{{ > :t D D :: T a -> D a }}} I find this odd. The type T is in class C, so why is there no context on D saying so? It would be natural. Now try some expression {{{ > D True :1:2: Couldn't match expected type `T a' against inferred type `Bool' In the first argument of `D', namely `True' In the expression: D True In the definition of `it': it = D True }}} But this isn't really type incorrect, we just don't know yet. To remedy the problem we can use a context on the data declaration. {{{ data (C a) => D a = D (T a) }}} And we try again {{{ > :t D True D True :: (Bool ~ T a, C a) => D a }}} This is what I would have expected in the first try as well; a context indicating what must hold for this to be type correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 06:55:05 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 06:48:12 2008 Subject: [GHC] #2853: Defaulting not used enough with type families Message-ID: <044.1dcb2375550c7c9b5f4c185145522a7d@localhost> #2853: Defaulting not used enough with type families -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Consider this module {{{ {-# LANGUAGE TypeFamilies, ExtendedDefaultRules #-} module Bug3 where class C t where type T t instance C Integer where type T Integer = Integer data (C t, Num t) => D t = D (T t) instance Show (D a) where show _ = "" }}} Now let's try to ask for the type of (D 5) {{{ *Bug3> :t D 5 D 5 :: (Num (T t), C t, Num t) => D t }}} That's great. Now if we try to show this value it should have type {{{ (Num (T t), C t, Num t) => String }}} And now the defaulting mechanism should set t to Integer, which would resolve the rest of the context. But instead we get this: {{{ *Bug3> :t show (D 5) :1:8: No instance for (Num (T t)) arising from the literal `5' at :1:8 Possible fix: add an instance declaration for (Num (T t)) In the first argument of `D', namely `5' In the first argument of `show', namely `(D 5)' In the expression: show (D 5) }}} It looks like the defaulting never got used. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 07:05:41 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 06:58:47 2008 Subject: [GHC] #2854: Extended defaulting rules not used for super classes Message-ID: <044.cced03302e6b813ef4785978186cb6ee@localhost> #2854: Extended defaulting rules not used for super classes -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Consider the following module {{{ {-# LANGUAGE ExtendedDefaultRules #-} module Bug4 where class (Num a) => C a where f :: a -> a instance C Integer where f = (+1) x = show (f 5) }}} The type of x is {{{ x :: (C a) => String }}} and since a is ambiguous the defaulting rules should be used. Since Num is a superclass of C the type variable should be defaulted to Integer. But instead we get an error. Removing the Num superclass of C makes it work, since the type of x is {{{ x ::: (Num a, C a) => String }}} and the defaulting kicks in as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 07:09:22 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 07:02:36 2008 Subject: [GHC] #2852: Type family checking oddity In-Reply-To: <044.fdac353512d121dcac11b2fbc3873f76@localhost> References: <044.fdac353512d121dcac11b2fbc3873f76@localhost> Message-ID: <053.7eaea81d78f37eeed8da14c4aea7b341@localhost> #2852: Type family checking oddity ------------------------------+--------------------------------------------- Reporter: guest | 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 ------------------------------+--------------------------------------------- Changes (by guest): * cc: lennart@augustsson.net (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 07:09:49 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 07:03:00 2008 Subject: [GHC] #2853: Defaulting not used enough with type families In-Reply-To: <044.1dcb2375550c7c9b5f4c185145522a7d@localhost> References: <044.1dcb2375550c7c9b5f4c185145522a7d@localhost> Message-ID: <053.4de5499faf3ba5451333c6f72956ac2d@localhost> #2853: Defaulting not used enough with type families ------------------------------+--------------------------------------------- Reporter: guest | 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 ------------------------------+--------------------------------------------- Changes (by guest): * cc: lennart@augustsson.net (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 07:10:09 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 07:03:22 2008 Subject: [GHC] #2854: Extended defaulting rules not used for super classes In-Reply-To: <044.cced03302e6b813ef4785978186cb6ee@localhost> References: <044.cced03302e6b813ef4785978186cb6ee@localhost> Message-ID: <053.702d0e363da66bc05e5f8e0f87d6c82b@localhost> #2854: Extended defaulting rules not used for super classes ------------------------------+--------------------------------------------- Reporter: guest | 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 ------------------------------+--------------------------------------------- Changes (by guest): * cc: lennart@augustsson.net (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 07:11:27 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 07:04:39 2008 Subject: [GHC] #2851: Deriving doesn't work when type families are involved In-Reply-To: <044.53dff063407021fb8c52e3be3626a0f5@localhost> References: <044.53dff063407021fb8c52e3be3626a0f5@localhost> Message-ID: <053.693de3292e29e4466a00a537ef7a4070@localhost> #2851: Deriving doesn't work when type families are involved ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by guest): * cc: lennart@augustsson.net (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 07:53:02 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 07:46:14 2008 Subject: [GHC] #2855: Surprising type (family) type derived Message-ID: <044.b3122af4202b8ff227a37c8b058b0ea3@localhost> #2855: Surprising type (family) type derived -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Consider the following module {{{ {-# LANGUAGE TypeFamilies #-} module Bug5 where class C a where type T a f :: T a -> T a -> T a data D a = D { t :: T a } g r = f (t r) (t r) }}} Now ask for the type of g {{{ *Bug5> :t g g :: (T a ~ T a1, C a1) => D a -> T a1 }}} Why isn't the type {{{ g :: (C a) => D a -> T a }}} ? The strange type is a minor nuisance, but it gets worse {{{ {-# LANGUAGE TypeFamilies #-} module Bug6 where class C a where type T a type U a f :: T a -> T a -> T a x :: U a -> T a data D a = D { t :: T a, u :: U a } g r = f (t r) (x (u r)) }}} This doesn't type check at all. An even simpler example that fails: {{{ {-# LANGUAGE TypeFamilies, ScopedTypeVariables #-} module Bug7 where class C a where type T a type U a x :: U a -> T a data D a = D (U a) g :: (C a) => D a -> T a g (D u) = x u }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 09:59:05 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 09:52:11 2008 Subject: [GHC] #2847: Failure on OPTION_* pramgas other than GHC In-Reply-To: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> References: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> Message-ID: <060.360181112f7782305cca97b5766ebe2d@localhost> #2847: Failure on OPTION_* pramgas other than GHC ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high Comment: regression -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 10:20:51 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 10:14:00 2008 Subject: [GHC] #1779: unknown symbol `hs_hpc_module' In-Reply-To: <044.e238a8559ffe0a21198f4a819a87e869@localhost> References: <044.e238a8559ffe0a21198f4a819a87e869@localhost> Message-ID: <053.ea28a58399a3ba2143b08ed7db6fea49@localhost> #1779: unknown symbol `hs_hpc_module' ---------------------------------+------------------------------------------ Reporter: guest | Owner: AndyGill Type: bug | Status: reopened Priority: low | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: minor | Resolution: Keywords: hpc | Difficulty: Unknown Testcase: hpc_ghc_ghci | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by spl): * cc: leather@cs.uu.nl (added) * version: 6.9 => 6.10.1 Comment: I ran this minimal testcase manually on GHC 6.8.3 and 6.10.1 using !MacPorts installations, and it passed both. I also just verified that it failed on GHCi 6.10.1 on Windows. I think this problem is related to #1907, which we have been experiencing with [http://www.cs.uu.nl/wiki/GenericProgramming/EMGM EMGM] using 6.8.3 and 6.10.1. For both #1907 and this test case, Linux and Windows have failed while !MacPorts has not. We have been using GHC, not GHCi, for EMGM. Has the problem been determined, yet? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 10:26:37 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 10:19:47 2008 Subject: [GHC] #2841: Ghci + foreign export declarations result in undefined symbols In-Reply-To: <044.b0747800033e264d294e9c1520f847f6@localhost> References: <044.b0747800033e264d294e9c1520f847f6@localhost> Message-ID: <053.d11976d8f6e77b15d85b97f31d7de5f4@localhost> #2841: Ghci + foreign export declarations result in undefined symbols ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler (FFI) | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by fasta): From the FAQ {{{ Unfortunately not. We haven't implemented it yet. Please compile any offending modules by hand before loading them into GHCi. }}} This information is not correct. Recompiling the offending modules by hand and then loading them in ghci does work, but calling one of the exported functions results in unknown symbol `_GLOBAL_OFFSET_TABLE_'. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 10:53:27 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 10:46:42 2008 Subject: [GHC] #2855: Surprising type (family) type derived In-Reply-To: <044.b3122af4202b8ff227a37c8b058b0ea3@localhost> References: <044.b3122af4202b8ff227a37c8b058b0ea3@localhost> Message-ID: <053.2370eaae8af561a9d205f67e5b89ba8f@localhost> #2855: Surprising type (family) type derived ------------------------------+--------------------------------------------- Reporter: guest | 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 guest): Here's more of the same kind: {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts #-} module Bug8 where class C a where type T a type U a x :: U a -> T a --foo :: (C a) => U a -> T a foo ua = x ua }}} This compiles, and the type of foo is the one in the signature. But if the signature is included there are type errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 11:12:54 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 11:06:06 2008 Subject: [GHC] #2856: GeneralizedNewtypeDeriving doesn't work with data families Message-ID: <044.b28574462f0debc35277b395a6c8b810@localhost> #2856: GeneralizedNewtypeDeriving doesn't work with data families -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Observe: {{{ {-# LANGUAGE TypeFamilies, GeneralizedNewtypeDeriving #-} module Bug9 where class C a where data D a instance C Bool where newtype D Bool = DInt Int deriving (Eq, Show, Num) }}} The deriving of Num fails, whereas the corresponding standalone newtype works fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 11:48:36 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 11:41:48 2008 Subject: [GHC] #2855: Surprising type (family) type derived In-Reply-To: <044.b3122af4202b8ff227a37c8b058b0ea3@localhost> References: <044.b3122af4202b8ff227a37c8b058b0ea3@localhost> Message-ID: <053.4f690b22f68b92e0a32d07ac765d88c5@localhost> #2855: Surprising type (family) type derived ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown * type: bug => feature request Comment: I'm afraid these aren't bugs. They all arise because type synonym families (unlike data type families) do not have to be injective. For example you ask re `Bug5` why GHC doesn't get the type {{{ g :: (C a) => D a -> T a }}} Answer: because that's not the most general type. The type GHC gives is strictly more general. Suppose {{{ type instance T Int = Char type instance T Bool = Char }}} then `T Int ~ T Bool`, but of course `Int` and `Bool` are different types. The other examples you give are more tiresome. For example: {{{ class C a where type T a type U a x :: U a -> T a data D a = D (U a) g :: (C a) => D a -> T a g (D u) = x u }}} We know that `(u :: U a)`, but at what type should we call the polymorphic function `x`? Let's say at some type `a1`. Then since `x` is applied to `u` we know that `U a` should be the same type as `U a1`, ''but that does not require `a` to be the same type as `a1`'', as we saw above. In this case, it's vexing because the only solution to `(U a ~ U a1)`, where (i) `a` is a skolem constant, and (ii) no other equality constraints are available to solve it, is `a~a1`. But GHC doesn't do that kind of "the only solution" reasoning. Yet anyway. In general, a function with a polymorphic type variable that occurs only under a type function is likely to give rise to this kind of trouble. We're also thinking about allowing you to declare theat a type function is injective, which would solve this problem in a different way. I hope that explains it a bit. I'll leave this open as a feature request... perhaps for injective type functions. (Although I'm not sure whether that'd work in your application.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 12:10:40 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 12:03:55 2008 Subject: [GHC] #2851: Deriving doesn't work when type families are involved In-Reply-To: <044.53dff063407021fb8c52e3be3626a0f5@localhost> References: <044.53dff063407021fb8c52e3be3626a0f5@localhost> Message-ID: <053.d15f6dccd45f61563c0caf3de6339e9d@localhost> #2851: Deriving doesn't work when type families are involved ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Well, it's tricky. The 'deriving' mechanism is supposed to produce nice, well-behaved, terminating instances, so it insists (as the H98 report says) on producing an instance context whose constraints are of the form `(C a)`, where `a` is a type variable. Fortunately, GHC has just what you want: standalone deriving. Try this: {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts, UndecidableInstances, StandaloneDeriving #-} type family F a :: * data D a = D (F a) deriving instance Show (F a) => Show (D a) }}} You get to specify the context for the instance, and GHC adds the code for the `Show` methods. Notice that you have to add `FlexibleContexts` and `UndecidableInstances` .... and rightly so. I find this approach works much better than requiring these flags for an instance declaration that the user never sees. So I'll close this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 12:13:55 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 12:07:05 2008 Subject: [GHC] #2855: Surprising type (family) type derived In-Reply-To: <044.b3122af4202b8ff227a37c8b058b0ea3@localhost> References: <044.b3122af4202b8ff227a37c8b058b0ea3@localhost> Message-ID: <053.a9623678fc824bb28af6a2c94258387b@localhost> #2855: Surprising type (family) type derived ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by guest): So what about my attached last example? It's another one of these the type that ghc reports cannot be inserted in the code. Very frustrating. You say "At what type should we call the poymorphic function x?" Well, I want it to be the x from the dictionary (C a) that I'm passing. So there is no doubt at what type it should be called, it's at type (U a). I guess there's no way to express that. This is very annoying, because it means that the associated types simply don't work for some of the tasks that I thought they were supposed to solve. I can provide a real life example if that helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 12:27:58 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 12:21:09 2008 Subject: [GHC] #2855: Surprising type (family) type derived In-Reply-To: <044.b3122af4202b8ff227a37c8b058b0ea3@localhost> References: <044.b3122af4202b8ff227a37c8b058b0ea3@localhost> Message-ID: <053.d51080343ada9f793abc09e6c58da935@localhost> #2855: Surprising type (family) type derived ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Several things going on here. Concerning type signatures, it's indeed annoying that a program can have an inferred type that can't be used as a type signature. I plan to fix that by rejecting both programs. You won't like that, but it's silly to accept one but not the other. I think there's a ticket open for this, but I'm not sure which one... Concering "I want it to be the x from the dictionary (C a) that I'm passing". Yes, I know. That's why I said it's vexing; indeed, the solution you suggest is the ''only'' solution that will work. All I'm saying is that this is a new form of reasoning, which GHC does not in any way implement at the moment. It'd take a bit of study to figure out how to do it, or indeed if there is any well-behaved, principal solution. If you can work one out, do tell us! Can you not design your functions so that they take at least one parameter that does not live inside a type-function application? Or, would you be willing for your type functions to be injective, or would that be too restrictive for your application? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 12:46:28 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 12:39:33 2008 Subject: [GHC] #2844: incorrect results when not compiling with optimisation In-Reply-To: <044.b6f4de74c6673f2c75a92a91b0801ec0@localhost> References: <044.b6f4de74c6673f2c75a92a91b0801ec0@localhost> Message-ID: <053.42c07a8303d4ee3ed424f92eac5369c2@localhost> #2844: incorrect results when not compiling with optimisation ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: random1283 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Mon Dec 8 17:35:25 GMT Standard Time 2008 simonpj@microsoft.com * Inject implicit bindings after CoreTidy, not before Simplify }}} The commit message amplifies. Thanks for boiling it down so well. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 18:52:20 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 18:45:24 2008 Subject: [GHC] #2440: Bad code with type families In-Reply-To: <041.36cfaf77666d90945b8031e68cebdd8a@localhost> References: <041.36cfaf77666d90945b8031e68cebdd8a@localhost> Message-ID: <050.cd5967f621cebd0334e7ceb778b37c50@localhost> #2440: Bad code with type families -----------------------------------------+---------------------------------- Reporter: rl | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by batterseapower): Is there some reason the coercion for this case is so complicated? It seems to me (with my admittedly limited knowledge of type coercions) that we could improve it to: (trans (sym (GHC.ST.NTCo:ST s GHC.Types.Int)) ((sym (Foo.TFCo:R1:M s)) GHC.Types.Int)) :: STRep s Int ~ M (Vec s) Int Here I have used the rewrite rules: trans (x :: a ~ a) (x :: a ~ a) ==> x sym (x :: a ~ a) ==> x trans x (y :: a ~ a) ==> x And optionally you could also do: trans (sym x) (sym y) ==> sym (trans x y) I don't think this helps fixing this bug at all, but it seemed a bit fishy to me, and doing this improvement would at least help readability of Core. Am I way off base here? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 18:53:18 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 18:46:22 2008 Subject: [GHC] #2440: Bad code with type families In-Reply-To: <041.36cfaf77666d90945b8031e68cebdd8a@localhost> References: <041.36cfaf77666d90945b8031e68cebdd8a@localhost> Message-ID: <050.0e1eac4b1e24d0f092d176cb57dbec50@localhost> #2440: Bad code with type families -----------------------------------------+---------------------------------- Reporter: rl | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by batterseapower): (Repost for formatting reasons...) Is there some reason the coercion for this case is so complicated? It seems to me (with my admittedly limited knowledge of type coercions) that we could improve it to: {{{ (trans (sym (GHC.ST.NTCo:ST s GHC.Types.Int)) ((sym (Foo.TFCo:R1:M s)) GHC.Types.Int)) :: STRep s Int ~ M (Vec s) Int }}} Here I have used the rewrite rules: {{{ trans (x :: a ~ a) (x :: a ~ a) ==> x sym (x :: a ~ a) ==> x trans x (y :: a ~ a) ==> x }}} And optionally you could also do: {{{ trans (sym x) (sym y) ==> sym (trans x y) }}} I don't think this helps fixing this bug at all, but it seemed a bit fishy to me, and doing this improvement would at least help readability of Core. Am I way off base here? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 19:00:20 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 18:53:25 2008 Subject: [GHC] #2762: Excessive heap usage In-Reply-To: <044.bf1fb1b8e171504548cbe3cb91273ef8@localhost> References: <044.bf1fb1b8e171504548cbe3cb91273ef8@localhost> Message-ID: <053.fd4fe88938ee3f0a0b3c8a5e53a94385@localhost> #2762: Excessive heap usage ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by batterseapower): Replying to [comment:4 igloo]: > Fixing the space leak is important to me. If the performance is an issue, then perhaps it should be an `-O2`-only optimisation? Perhaps. It seems to cost about 9% of the compile time of a -O build, so it's not a /massive/ problem. Anyway, I looked a bit more at this arity stuff tonight and I've managed to fix a few bugs in the analysis, as well as make it work across several modules - this makes it /slightly/ more effective, and has fixed the problems I mentioned above. I'm going to continue tuning and extending it, and will talk to Simon PJ when I have something potentially viable for HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 20:04:18 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 19:57:31 2008 Subject: [GHC] #2851: Improve error message for failed deriving In-Reply-To: <044.53dff063407021fb8c52e3be3626a0f5@localhost> References: <044.53dff063407021fb8c52e3be3626a0f5@localhost> Message-ID: <053.9994926462a4c894b483d9c77519808f@localhost> #2851: Improve error message for failed deriving ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by guest): * status: closed => reopened * component: Compiler => Compiler (Type checker) * resolution: invalid => * summary: Deriving doesn't work when type families are involved => Improve error message for failed deriving Comment: (I don't have a ghc-6.10 here to test, so maybe it's already good, but) It would be nice if, when deriving fails but standalone deriving might work, the error message would suggest to you to try standalone deriving. (and warn you what other extensions you might need. ...And ideally it would even suggest the whole deriving-line e.g. {{{ deriving instance Show (F a) => Show (D a) }}} , but of course one of the issues is that GHC can't always even make a good guess at what you want the context to be.) -Isaac Dupree -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 20:08:13 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 20:01:27 2008 Subject: [GHC] #2852: Type family checking oddity In-Reply-To: <044.fdac353512d121dcac11b2fbc3873f76@localhost> References: <044.fdac353512d121dcac11b2fbc3873f76@localhost> Message-ID: <053.0ff2e715e8df4328263b55b2f030ff98@localhost> #2852: Type family checking oddity ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: worksforme Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by chak): * status: new => closed * resolution: => worksforme Comment: Replying to [ticket:2852 guest]: > Consider the following snipped {{{ class C a where type T a data D a = D (T a) }}} > If we now ask for the type of D we get {{{ > :t D D :: T a -> D a }}} > I find this odd. The type T is in class C, so why is there no context on D saying so? It would be natural. In the first proposal of associated types, we used to require such a context, but subsequently decided that there is really no basis for this requirement. Take this definition: {{{ myid :: T a -> T a myid x = x }}} Why should we require a `C a` context here? No class methods are used, no evidence is needed. Also, what if your definition would have been {{{ newtype D a = D (T a) }}} Then, `D` cannot have a context. In the case of associated '''data''' declarations it would actually be rather inconvenient to require contexts. Say, we have {{{ class D a where data DT a }}} We might want to use `DT` partially applied, as in `F D`, where `F :: (* -> *) -> *`. What context should we use here? So, the right way to think of an associated type {{{ class C a where type T a }}} is as syntactic sugar for {{{ type family T a class C a }}} It's convenient to bundle families that are defined in lock step with a class as an associated types. You get a warning if you forget to define the family instance in a class instance and it highlights the structure of your code for a human reader. (And it allows for associated synonym defaults.) However, there is really nothing semantically deep about associating a family with a class. > Now try some expression {{{ > D True :1:2: Couldn't match expected type `T a' against inferred type `Bool' In the first argument of `D', namely `True' In the expression: D True In the definition of `it': it = D True }}} > But this isn't really type incorrect, we just don't know yet. To remedy the problem we can use a context on the data declaration. > {{{ data (C a) => D a = D (T a) }}} > And we try again {{{ > :t D True D True :: (Bool ~ T a, C a) => D a }}} > This is what I would have expected in the first try as well; a context indicating what must hold for this to be type correct. You forgot the `:t` in front of the `D True` the first time around. Works fine with me in 6.10.1 and the HEAD: {{{ *Main> :t D True D True :: (Bool ~ T a) => D a }}} So, I think, this was only a typo during the ghci interaction. Hence, closing the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 20:48:48 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 20:42:02 2008 Subject: [GHC] #2853: Defaulting not used enough with type families In-Reply-To: <044.1dcb2375550c7c9b5f4c185145522a7d@localhost> References: <044.1dcb2375550c7c9b5f4c185145522a7d@localhost> Message-ID: <053.62421ec26cc31b4db3412634fc0c24e6@localhost> #2853: Defaulting not used enough with type families ------------------------------+--------------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by chak): * owner: => chak Comment: No, defaulting is not used, but I also '''don't''' think it should be used in this example. The Haskell Report says: "[...]an ambiguous type variable, v, is defaultable if: * v appears only in constraints of the form C v, where C is a class, and * at least one of these classes is a numeric class, (that is, Num or a subclass of Num), and * all of these classes are defined in the Prelude or a standard library" The above code clearly violates the third condition (`C` is not a standard class). However, I think, we should discuss what would happen for this program: {{{ {-# LANGUAGE TypeFamilies, ExtendedDefaultRules #-} module Bug3 where class C t where type T t instance C Integer where type T Integer = Integer data (Num t) => D t = D (T t) instance Show (D a) where show _ = "" }}} Now, we get (without defaulting): `(Num (T t), Num t) => String`. Literally speaking, this still violates the first condition from the Haskell Report. However, you might argue that -in the presence of type families- we should generalise the definition of the Report to permit classes of the form `C (T v1..vn))` in contexts to which the default rules applies. SimonPJ, what do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 21:17:05 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 21:10:21 2008 Subject: [GHC] #2855: Surprising type (family) type derived In-Reply-To: <044.b3122af4202b8ff227a37c8b058b0ea3@localhost> References: <044.b3122af4202b8ff227a37c8b058b0ea3@localhost> Message-ID: <053.324f1559bbf906581b41a4d5d62aba21@localhost> #2855: Surprising type (family) type derived ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by chak): This is a duplicate of #1897, is it not? As far as I am concerned, I still think, we should solve this problem in the way Lennart proposed when we discussed this last: http://www.mail- archive.com/haskell-cafe@haskell.org/msg39774.html (after type inference, do type '''checking''' again with the inferred signatures). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 21:20:53 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 21:14:06 2008 Subject: [GHC] #2856: GeneralizedNewtypeDeriving doesn't work with data families In-Reply-To: <044.b28574462f0debc35277b395a6c8b810@localhost> References: <044.b28574462f0debc35277b395a6c8b810@localhost> Message-ID: <053.2b1057f4845c1dd7932f437825397c7f@localhost> #2856: GeneralizedNewtypeDeriving doesn't work with data families ------------------------------+--------------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by chak): * owner: => chak -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 8 21:25:54 2008 From: trac at galois.com (GHC) Date: Mon Dec 8 21:19:00 2008 Subject: [GHC] #2440: Bad code with type families In-Reply-To: <041.36cfaf77666d90945b8031e68cebdd8a@localhost> References: <041.36cfaf77666d90945b8031e68cebdd8a@localhost> Message-ID: <050.8bab83ded7a46318b0a45501bb660ea3@localhost> #2440: Bad code with type families -----------------------------------------+---------------------------------- Reporter: rl | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by chak): Replying to [comment:7 batterseapower]: > (Repost for formatting reasons...) > > Is there some reason the coercion for this case is so complicated? It seems to me (with my admittedly limited knowledge of type coercions) that we could improve it to: You are right that coercions sometimes get overly complicated. That is often due to shortcomings of the representation used when generating these coercions. We would like to fix that, but so far haven't settled on exactly how (and also like to avoid rearranging the source in many places). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 00:09:46 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 00:02:53 2008 Subject: [GHC] #2857: sync-all ignores --complete Message-ID: <045.4730aa92f2a05590e209c59fd9fc86c8@localhost> #2857: sync-all ignores --complete -----------------------------+---------------------------------------------- Reporter: megacz | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.1 | Severity: major Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The ordering of the if...elsif...etc branches appears to be slightly off. A patch to fix this is attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 03:21:27 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 03:14:31 2008 Subject: [GHC] #2858: Segmentation fault due to race between IO manager and installSignals. Message-ID: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> #2858: Segmentation fault due to race between IO manager and installSignals. --------------------------------------------+------------------------------- Reporter: dsh | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.10.1 | Severity: normal Keywords: posix signal threaded IOmanager | Testcase: Os: Linux | Architecture: Unknown/Multiple --------------------------------------------+------------------------------- Hello, consider the attached test case. To reproduce the problem please [[BR]] 1. compile the attached test case with -threaded[[BR]] 2. enable core dumps in the shell,[[BR]] 3. run infinite loop until core dump appears,[[BR]] 4. to make core dumps actually appear run infinite pkill -TERM Test in another shell.[[BR]] Regards,[[BR]] Dmitry -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 03:39:05 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 03:32:08 2008 Subject: [GHC] #2858: Segmentation fault due to race between IO manager and installSignals. In-Reply-To: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> References: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> Message-ID: <051.b19fda0c4a1163e7ccefd3f26670fb77@localhost> #2858: Segmentation fault due to race between IO manager and installSignals. ---------------------------------------------+------------------------------ Reporter: dsh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: posix signal threaded IOmanager | Testcase: Os: Linux | Architecture: Unknown/Multiple ---------------------------------------------+------------------------------ Comment (by dsh): With this fix I get assertion with sanity checks enabled about deadlock.[[BR]] May be IO manager should read its pipe in non-blocking mode? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 04:01:10 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 03:54:16 2008 Subject: [GHC] #2859: Reduce coercion terms to normal form Message-ID: <046.917b9c8dce2bb6503705b21f0c69b712@localhost> #2859: Reduce coercion terms to normal form -------------------------------------------+-------------------------------- Reporter: simonpj | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------------+-------------------------------- Sometimes coercion terms in a Core program grow absurdly big, and can readily be simplified to be much more compact. Example: * #2627 * #2440 Big coercion terms have no runtime impact, but they may make compilation slower. I speculate that it should be possible to use transformations such as those Max suggests in his comment on #2440, as a confluent, terminating rewriting system that makes coercion terms smaller, or, better still, rewrites them to a normal form. Then we can use "smart constructors" for coercion terms, so that they are always kept in normal form. Identity coercions occur a lot, but are not so easy to recognise. I've also wondered about having some special representation for the identity. This ticket is to remind us to look for such a rewrite system. Max, perhaps? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 04:01:51 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 03:54:57 2008 Subject: [GHC] #2440: Bad code with type families In-Reply-To: <041.36cfaf77666d90945b8031e68cebdd8a@localhost> References: <041.36cfaf77666d90945b8031e68cebdd8a@localhost> Message-ID: <050.a0c8f76f2eb3275415ec3f9b68b6ddf6@localhost> #2440: Bad code with type families -----------------------------------------+---------------------------------- Reporter: rl | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Comment (by simonpj): Right. I've opened a ticket for this: #2859. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 04:01:46 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 03:55:00 2008 Subject: [GHC] #2853: Defaulting not used enough with type families In-Reply-To: <044.1dcb2375550c7c9b5f4c185145522a7d@localhost> References: <044.1dcb2375550c7c9b5f4c185145522a7d@localhost> Message-ID: <053.227b646736dd1d0cf3d6ef97f44073b6@localhost> #2853: Defaulting not used enough with type families ------------------------------+--------------------------------------------- Reporter: guest | Owner: chak 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 guest): The point of ExtendedDefaultRules is to get away from the draconian Haskell-98 rules. The one that is especially annoying is that all classes have to be standard ones (that rules should be removed for Haskell', I think). I'm not sure why the rules insist on only the form (C v). If there's some technical reason for this I guess I'm out of luck. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 04:04:34 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 03:57:46 2008 Subject: [GHC] #2852: Type family checking oddity In-Reply-To: <044.fdac353512d121dcac11b2fbc3873f76@localhost> References: <044.fdac353512d121dcac11b2fbc3873f76@localhost> Message-ID: <053.aada511adefb0eec57657a56bdc2794a@localhost> #2852: Type family checking oddity ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: worksforme Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by guest): Fair enough. As the summary said, this was more an oddity than a bug. I'd say it's still somewhat surprising to use something (the type) from a class and not get the context, but I see the technical reasons for leaving it out. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 04:08:47 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 04:01:53 2008 Subject: [GHC] #1897: Type families: type signature rejected In-Reply-To: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> References: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> Message-ID: <053.02fc0c22ba0b6eef7f676486dfcaf392@localhost> #1897: Type families: type signature rejected ----------------------------------------+----------------------------------- Reporter: guest | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Comment (by simonpj): See also #2855 (another instance of the same problem). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 04:09:04 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 04:02:17 2008 Subject: [GHC] #2855: Surprising type (family) type derived In-Reply-To: <044.b3122af4202b8ff227a37c8b058b0ea3@localhost> References: <044.b3122af4202b8ff227a37c8b058b0ea3@localhost> Message-ID: <053.3e2dab5f588ba3a058239b8f1f27d8af@localhost> #2855: Surprising type (family) type derived ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: Yes, it's a dup. So I'll close it now, having linked from #1897 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 04:12:45 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 04:05:55 2008 Subject: [GHC] #2851: Improve error message for failed deriving In-Reply-To: <044.53dff063407021fb8c52e3be3626a0f5@localhost> References: <044.53dff063407021fb8c52e3be3626a0f5@localhost> Message-ID: <053.2ac2d641cd3d4def154e75445fdbfbed@localhost> #2851: Improve error message for failed deriving ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Comment (by guest): I did try 'deriving instance', but without the context. With a context it works like a charm. But like Isaac says, it would be nice with a better error message, since it wasn't obvious to me that the 'deriving instance' would do the trick. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 04:21:27 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 04:14:39 2008 Subject: [GHC] #2853: Defaulting not used enough with type families In-Reply-To: <044.1dcb2375550c7c9b5f4c185145522a7d@localhost> References: <044.1dcb2375550c7c9b5f4c185145522a7d@localhost> Message-ID: <053.fd709fdd2bbfd411587ad15d9bd26695@localhost> #2853: Defaulting not used enough with type families ---------------------------------+------------------------------------------ Reporter: guest | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: But see #2641 which argues for making the rules ''less'' liberal, not more liberal. This is a usability issue, not a technical one. If you care enough to drive a discussion (perhaps on ghc-users) to a consensus, I'd be happy to implement the outcome. Rather than have two tickets about the semantics of `ExtendedDefaultRules`, I'll close this ticket and link to it from #2641. Simon (PS: also related: #1877.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 04:23:55 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 04:17:07 2008 Subject: [GHC] #2641: Make -XExtendedDeafultRules a bit less liberal In-Reply-To: <046.d5d4eb9f2d648fc88d0b44a928fdd436@localhost> References: <046.d5d4eb9f2d648fc88d0b44a928fdd436@localhost> Message-ID: <055.a04dbf2bfaefa9189182a314bf888f77@localhost> #2641: Make -XExtendedDeafultRules a bit less liberal ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * cc: lennart@augustsson.net (added) Comment: See also #2853 (only closed because it duplicates this one), which argues to make `ExtendedDefaultRules` ''more'' liberal, not less! When finally fixing this, it'd be worth dealing with #1877 at the same time. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 04:25:35 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 04:18:46 2008 Subject: [GHC] #2851: Improve error message for failed deriving In-Reply-To: <044.53dff063407021fb8c52e3be3626a0f5@localhost> References: <044.53dff063407021fb8c52e3be3626a0f5@localhost> Message-ID: <053.83b110f600bcb50f2872f2db28cb4eb1@localhost> #2851: Improve error message for failed deriving ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Comment (by simonpj): OK I'll think about that. Meanwhile, the user guide for standalone deriving should have told you about the need for a context. Yell if it needs to be improved. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 04:31:56 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 04:25:01 2008 Subject: [GHC] #2838: -fasm codeGen doesn't truncate CMMInt's at the right place In-Reply-To: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> References: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> Message-ID: <062.284725340f7895d37c058a43f9e75562@localhost> #2838: -fasm codeGen doesn't truncate CMMInt's at the right place ---------------------------------+------------------------------------------ Reporter: TristanAllwood | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 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 Tue Dec 9 05:05:39 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 04:58:54 2008 Subject: [GHC] #2641: Make -XExtendedDeafultRules a bit less liberal In-Reply-To: <046.d5d4eb9f2d648fc88d0b44a928fdd436@localhost> References: <046.d5d4eb9f2d648fc88d0b44a928fdd436@localhost> Message-ID: <055.546b626f3b29a566130d48d0f275c5a0@localhost> #2641: Make -XExtendedDeafultRules a bit less liberal ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by guest): There's no contradiction between #2853 and this bug report. In #2853 I argue that the defaulting rules should be more liberal about what the context can be when defaulting, but with the context still containing a Num. This report complains about a type being defaulted to (). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 05:08:44 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 05:01:54 2008 Subject: [GHC] #2851: Improve error message for failed deriving In-Reply-To: <044.53dff063407021fb8c52e3be3626a0f5@localhost> References: <044.53dff063407021fb8c52e3be3626a0f5@localhost> Message-ID: <053.704261e7fdb5f4b6fe55368a4ebdaa95@localhost> #2851: Improve error message for failed deriving ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Comment (by guest): It would be an improvement if the error message just mentions standalone deriving, without giving the actual needed line of code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 05:21:31 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 05:14:50 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.bd862f303d141cc6cd8a3ef4ec2407fc@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ---------------------------------------------------------------+------------ Reporter: tomekz | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------------------------+------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 05:27:26 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 05:20:31 2008 Subject: [GHC] #2841: Ghci + foreign export declarations result in undefined symbols In-Reply-To: <044.b0747800033e264d294e9c1520f847f6@localhost> References: <044.b0747800033e264d294e9c1520f847f6@localhost> Message-ID: <053.84f1d598711af6368d677453c3e8568a@localhost> #2841: Ghci + foreign export declarations result in undefined symbols ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler (FFI) | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): please create a new ticket describing ''exactly'' the sequence of actions that lead to the error. I haven't been able to reproduce the error you mentioned from the information you give above. {{{ ~/scratch > cat 2841.hs {-# LANGUAGE ForeignFunctionInterface #-} module M2841 where -- save in a file New.hs foreign export ccall foo :: Int -> IO Int -- add this line and ghci will return something like New_stub.o: unknown symbol `Main_zdffoozuaIc_closure' -- if you first try without the line, it works. If you still have stub files in the current directory, it will fail with the same message as before. foo :: Int -> IO Int foo = return . length . f f :: Int -> [Int] f 0 = [] f n = n:(f (n-1)) test = 1 ~/scratch > ghc -c 2841.hs compilation IS NOT required ~/scratch > ghci 2841.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. $HOME/.ghci Ok, modules loaded: M2841. Prelude M2841> foo 3 3 Prelude M2841> f 1 [1] Prelude M2841> test 1 Prelude M2841> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 05:34:25 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 05:27:32 2008 Subject: [GHC] #2641: Make -XExtendedDeafultRules a bit less liberal In-Reply-To: <046.d5d4eb9f2d648fc88d0b44a928fdd436@localhost> References: <046.d5d4eb9f2d648fc88d0b44a928fdd436@localhost> Message-ID: <055.882bcd0bc96ebdb890b45caec3c64ae4@localhost> #2641: Make -XExtendedDeafultRules a bit less liberal ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Would you care to write a careful specification of your proposed new `ExtendedDefaultRules` rules? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 05:48:33 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 05:41:44 2008 Subject: [GHC] #2641: Make -XExtendedDeafultRules a bit less liberal In-Reply-To: <046.d5d4eb9f2d648fc88d0b44a928fdd436@localhost> References: <046.d5d4eb9f2d648fc88d0b44a928fdd436@localhost> Message-ID: <055.d37c401cc14fbeba97b1bf84eb5b27a7@localhost> #2641: Make -XExtendedDeafultRules a bit less liberal ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Old description: > The `-XExtendedDefaultRules` flag is very liberal about type-class > defaults. Perhaps too liberal: > {{{ > > *Main> quickCheck (\xs -> reverse xs == xs) > > +++ OK, passed 100 tests. > }}} > Not good (reverse on lists is not the identity function). I expect a type > error! Reason: reverse on list of () is indeed the identity function! > > [http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive- > evaluation.html#extended-default-rules The rules] are currently these: > * All of the classes Ci are single-parameter type classes. > * At least one of the classes Ci is numeric, or is Show, Eq, or Ord. > > Maybe we should tighten up the second rule to say: > * '''All''' of the classes Ci is numeric, or is Show, Eq, or Ord. > Then the Quickcheck example would not bogusly succeed in typechecking, > because there's an `Arbitrary` constraint involved. > > This ticket is to record the idea and canvas opinion. Record thoughts > below. New description: The `-XExtendedDefaultRules` flag is very liberal about type-class defaults. Perhaps too liberal: {{{ > *Main> quickCheck (\xs -> reverse xs == xs) > +++ OK, passed 100 tests. }}} Not good (reverse on lists is not the identity function). I expect a type error! Reason: reverse on list of () is indeed the identity function! [http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive- evaluation.html#extended-default-rules The rules] are currently these: * All of the classes Ci are single-parameter type classes. * At least one of the classes Ci is numeric, or is Show, Eq, or Ord. Maybe we should tighten up the second rule to say: * '''All''' of the classes Ci is numeric, or is Show, Eq, or Ord. Then the Quickcheck example would not bogusly succeed in typechecking, because there's an `Arbitrary` constraint involved. This ticket is to record the idea and canvas opinion. Record thoughts below. See also * #2853 * #2854 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 05:58:43 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 05:51:47 2008 Subject: [GHC] #2860: Redundant unblocking in POSIX generic_handler Message-ID: <042.2727ad23f19fb18f0134c48d09681776@localhost> #2860: Redundant unblocking in POSIX generic_handler ----------------------------------+----------------------------------------- Reporter: dsh | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: trivial Keywords: POSIX generic_handler | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------------------+----------------------------------------- Generic handler redundantly unblocks signal at the end of generic handler. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 06:11:54 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 06:04:58 2008 Subject: [GHC] #2858: Segmentation fault due to race between IO manager and installSignals. In-Reply-To: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> References: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> Message-ID: <051.c31fcd97a38574ad66adcf4849fc6a3a@localhost> #2858: Segmentation fault due to race between IO manager and installSignals. ------------------------------------------------+--------------------------- Reporter: dsh | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: posix signal threaded IOmanager | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 06:12:06 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 06:05:09 2008 Subject: [GHC] #2858: Segmentation fault due to race between IO manager and installSignals. In-Reply-To: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> References: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> Message-ID: <051.cb89d5366783c5d7edd33b0db0b243d3@localhost> #2858: Segmentation fault due to race between IO manager and installSignals. ------------------------------------------------+--------------------------- Reporter: dsh | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: posix signal threaded IOmanager | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Changes (by simonmar): * milestone: => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 06:38:43 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 06:32:00 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.582e2b1cd98f23313bbe37e051d5ae8b@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ---------------------------------------------------------------+------------ Reporter: tomekz | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: fixed Keywords: ticks getourtimeofday threadDelay non-threaded | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------------------------+------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Thanks for a great bug report. The code is now: {{{ // Avoid overflow when we multiply seconds by 1000. See #2848 return (lnat)((StgWord64)tv.tv_sec * 1000 / interval + (StgWord64)tv.tv_usec / (interval * 1000)); }}} fixed by this patch: {{{ Tue Dec 9 10:56:00 GMT 2008 Simon Marlow * Fix #2848: avoid overflow during time calculation }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 06:49:55 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 06:42:58 2008 Subject: [GHC] #2838: -fasm codeGen doesn't truncate CMMInt's at the right place In-Reply-To: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> References: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> Message-ID: <062.c56c40199fbc3e2f11c9615c193d118f@localhost> #2838: -fasm codeGen doesn't truncate CMMInt's at the right place ---------------------------------+------------------------------------------ Reporter: TristanAllwood | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed, thanks: {{{ Tue Dec 9 02:55:15 PST 2008 Simon Marlow * Fix #2838: we should narrow a CmmInt before converting to ImmInteger }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 06:50:32 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 06:43:47 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.9e49dc3dd016eccb33b73971be756c1f@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ---------------------------------------------------------------+------------ Reporter: tomekz | Owner: simonmar Type: merge | Status: reopened Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------------------------+------------ Changes (by simonmar): * status: closed => reopened * type: bug => merge * resolution: fixed => Comment: oops, still needs to be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 06:50:41 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 06:43:54 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.9d4a912df2fd10d6ff896af95ad94b62@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ---------------------------------------------------------------+------------ Reporter: tomekz | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: Keywords: ticks getourtimeofday threadDelay non-threaded | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------------------------+------------ Changes (by simonmar): * status: reopened => new * owner: simonmar => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 07:10:21 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 07:03:24 2008 Subject: [GHC] #2861: stage2 crash: PAP object entered! Message-ID: <047.c536937e353cb32aada209ba41cc326f@localhost> #2861: stage2 crash: PAP object entered! -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- With stage2 today: {{{ $ ./ghc/stage2-inplace/ghc -package foo ghc: internal error: PAP object entered! (GHC version 6.11 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Interestingly, `-dcore-lint` doesn't find any errors. Looking at the `-ddump-simpl` output for `Packages.hs`, this is the function that is supposed to throw the exception containing the error message for an unknown package. It has been suspiciously eta-expanded a bit... {{{ a_r5fu :: GHC.Base.String -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.IOBase.IO [PackageConfig.PackageConfig] [GlobalId] [Arity 25] a_r5fu = \ (p_a1Pc :: GHC.Base.String) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ (eta22_s5c7 :: GHC.Prim.State# GHC.Prim.RealWorld) -> (\ (eta23_s5dN :: GHC.Prim.State# GHC.Prim.RealWorld) -> ((Panic.ghcError @ (GHC.IOBase.IO [PackageConfig.PackageConfig]) (Panic.CmdLineError (Pretty.fullRender @ GHC.Base.String Pretty.PageMode Pretty.lvl1 Pretty.lvl Pretty.string_txt (GHC.Types.[] @ GHC.Types.Char) (Pretty.Beside lvl_r5fs GHC.Bool.True (Pretty.text p_a1Pc))))) `cast` (GHC.IOBase.NTCo:IO [PackageConfig.PackageConfig] :: GHC.IOBase.IO [PackageConfig.PackageConfig] ~ GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, [PackageConfig.PackageConfig] #))) eta23_s5dN) `cast` (sym (GHC.IOBase.NTCo:IO [PackageConfig.PackageConfig]) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, [PackageConfig.PackageConfig] #) ~ GHC.IOBase.IO [PackageConfig.PackageConfig]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 07:11:46 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 07:04:48 2008 Subject: [GHC] #2592: Can't profile when the heap maximum is hit In-Reply-To: <046.6ff10d2040e94a9b4e4cc6a778189212@localhost> References: <046.6ff10d2040e94a9b4e4cc6a778189212@localhost> Message-ID: <055.7f23a151be399ec777aeba9bc427eb5a@localhost> #2592: Can't profile when the heap maximum is hit ---------------------------------+------------------------------------------ Reporter: adekoba | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: Keywords: profile, heap | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: {{{ Tue Dec 9 02:59:19 PST 2008 Simon Marlow * Fix #2592: do an orderly shutdown when the heap is exhausted Really we should be raising an exception in this case, but that's tricky (see comments). At least now we shut down the runtime correctly rather than just exiting. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 08:03:01 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 07:56:06 2008 Subject: [GHC] #2847: Failure on OPTION_* pramgas other than GHC In-Reply-To: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> References: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> Message-ID: <060.3ebac9ad8c6caf820835675a0659fb8c@localhost> #2847: Failure on OPTION_* pramgas other than GHC ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): I cannot reproduce this with 6.10.1. The Cabal sources contain many instances of things like: {{{ {-# OPTIONS_NHC98 -cpp #-} {-# OPTIONS_JHC -fcpp #-} }}} and we get no warnings for these at all (and we're using -Wall and no flags to suppress any kinds of warnings). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 08:11:35 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 08:04:39 2008 Subject: [GHC] #2847: Failure on OPTION_* pramgas other than GHC In-Reply-To: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> References: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> Message-ID: <060.e6984fdc91bb4ab9325561084786fde0@localhost> #2847: Failure on OPTION_* pramgas other than GHC ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by NeilMitchell): But if you have: {{{ {-# OPTIONS_NHC -cpp #-} }}} Then suddenly it stops working and gives an error. It seems somewhere in GHC there is a central registry of what Haskell compilers there are... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 08:12:49 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 08:05:52 2008 Subject: [GHC] #2847: Failure on OPTION_* pramgas other than GHC In-Reply-To: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> References: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> Message-ID: <060.b590682670112e4c743deac5daa51663@localhost> #2847: Failure on OPTION_* pramgas other than GHC ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by NeilMitchell): {{{OPTIONS_YHC}}} also fails, so that central registry lacks Yhc at the very least. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 08:41:46 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 08:34:53 2008 Subject: [GHC] #2847: Failure on OPTION_* pramgas other than GHC In-Reply-To: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> References: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> Message-ID: <060.0c0470cf77c1dcb2bba1ef40c5777ad4@localhost> #2847: Failure on OPTION_* pramgas other than GHC ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): See `ghc/compiler/parser/Lexer.x` line 267: {{{ "{-#" $whitechar* (OPTIONS_HUGS|options_hugs|OPTIONS_NHC98|options_nhc98|OPTIONS_JHC|options_jhc|CFILES|cfiles) }}} Clearly this is not the right approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 09:07:06 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 09:00:11 2008 Subject: [GHC] #2847: Failure on OPTION_* pramgas other than GHC In-Reply-To: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> References: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> Message-ID: <060.b40ef32cfb758a5c00fd1dd9de2aef07@localhost> #2847: Failure on OPTION_* pramgas other than GHC ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Replying to [comment:6 duncan]: > See `ghc/compiler/parser/Lexer.x` line 267: > > {{{ > "{-#" $whitechar* (OPTIONS_HUGS|options_hugs|OPTIONS_NHC98|options_nhc98|OPTIONS_JHC|options_jhc|CFILES|cfiles) > }}} > > Clearly this is not the right approach. We need this to be able to warn about unrecognised pragmas. But we also need to not parse `OPTIONS_foo` as an `OPTIONS` pragma, so we don't try to treat `_foo` and the pragma contents as a flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 09:18:39 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 09:11:43 2008 Subject: [GHC] #2847: Failure on OPTION_* pramgas other than GHC In-Reply-To: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> References: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> Message-ID: <060.546aeabd048a97b13cb7c220fdd56da8@localhost> #2847: Failure on OPTION_* pramgas other than GHC ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by NeilMitchell): Surely OPTIONS_* where * is not GHC should be treated as a valid pragma aimed at someone else? I don't want users of Derive or Yhc being told that their pragma is invalid. I also have a CATCH pragma that I've used in a few places. I realise that GHC wants to give good error reporting, but it seems a shame that I have to centrally register pragmas. Could there be a {-# KNOWN_PRAGMA Catch #-} style pragma? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 09:23:45 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 09:17:01 2008 Subject: [GHC] #2759: Data.Generics.ConstrRep isn't general enough In-Reply-To: <044.ed7d09d66854fb1616fb1d1343b2d811@localhost> References: <044.ed7d09d66854fb1616fb1d1343b2d811@localhost> Message-ID: <053.9dec04df22cf6c19703fb18a5ccf4ae7@localhost> #2759: Data.Generics.ConstrRep isn't general enough ----------------------------------+----------------------------------------- Reporter: guest | Owner: dreixel Type: bug | Status: assigned Priority: normal | Milestone: 6.12 branch Component: libraries (other) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by dreixel): * status: new => assigned * owner: jose magalhaes => dreixel Comment: Attached patches to fix it. A user visible change is the type of function mkFloatConstr. It was previously '!DataType -> Double -> Constr', it's now '(Real a) => !DataType -> a -> Constr'. This should cause no problems with existing code, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 09:26:01 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 09:19:03 2008 Subject: [GHC] #2862: GHC Panic in ByteCodeGen Message-ID: <047.13dee4cada75e20f59aa08e4590d7cec@localhost> #2862: GHC Panic in ByteCodeGen -----------------------------+---------------------------------------------- Reporter: nominolo | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Try to load the following problem with {{{ghc --interactive}}} of the latest HEAD. {{{ {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} class Search id a where search :: a -> () instance Search id () where search d = undefined -- works: -- instance Search () () where search d = undefined }}} You get an irrefutable pattern match error in ByteCodeGen:644 The code calls {{{splitApp}}} and expects an {{{AnnVar v}}}. What it gets instead is: {{{ \ (@ id{tv af0} [sk]) -> search1{v rfK} [gid] @ id{tv af0} [sk] }}} The argument to splitApp was: {{{ ((((\ (@ id{tv af0} [sk]) -> search1{v rfK} [gid] @ id{tv af0} [sk]) `cast` (forall id{tv af0} [sk]. ghc-prim:GHC.Prim.sym{(w) tc 34v} (main:Main.NTCo:T:Search{tc rfe} id{tv af0} [sk] ghc-prim:GHC.Unit.(){(w) tc 40}) :: forall id{tv af0} [sk]. ghc-prim:GHC.Unit.(){(w) tc 40} -> ghc- prim:GHC.Unit.(){(w) tc 40} ~ forall id{tv af0} [sk]. main:Main.T:Search{tc rf8} id{tv af0} [sk] ghc-prim:GHC.Unit.(){(w) tc 40})) @ etaT_sg1{tv} [tv]) `cast` (main:Main.NTCo:T:Search{tc rfe} etaT_sg1{tv} [tv] ghc-prim:GHC.Unit.(){(w) tc 40} :: main:Main.T:Search{tc rf8} etaT_sg1{tv} [tv] ghc-prim:GHC.Unit.(){(w) tc 40} ~ ghc-prim:GHC.Unit.(){(w) tc 40} -> ghc-prim:GHC.Unit.(){(w) tc 40})) eta_sg2{v} [lid] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 09:38:10 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 09:31:13 2008 Subject: [GHC] #2847: Failure on OPTION_* pramgas other than GHC In-Reply-To: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> References: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> Message-ID: <060.54ce1527ab71abd92983994c823d319b@localhost> #2847: Failure on OPTION_* pramgas other than GHC ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Replying to [comment:8 NeilMitchell]: > Surely OPTIONS_* where * is not GHC should be treated as a valid pragma aimed at someone else? I'd certainly want a warning for `OPTIONS_HGC`, `OPTIONS_FGX`, etc. > I don't want users of Derive or Yhc being told that their pragma is invalid. They are told their pragma is "unrecognised", not "invalid". > I also have a CATCH pragma that I've used in a few places. I realise that GHC wants to give good error reporting, but it seems a shame that I have to centrally register pragmas. Could there be a {-# KNOWN_PRAGMA Catch #-} style pragma? We could do that. We might have to jiggle things around a bit to make it all work out. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 09:48:12 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 09:41:16 2008 Subject: [GHC] #2847: Failure on OPTION_* pramgas other than GHC In-Reply-To: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> References: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> Message-ID: <060.2edf2fed6953eb7231e498243206ac39@localhost> #2847: Failure on OPTION_* pramgas other than GHC ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by NeilMitchell): I wouldn't want a warning for {{{OPTIONS_HGC}}}, I don't think its sensible to make GHC have a registry of what is good vs bad compiler names. If however, you do want to keep a closed list of possible values, can OPTIONS_DERIVE and OPTIONS_YHC and OPTIONS_CATCH all be added to the "good" list. The {{{KNOWN_PRAGMA}}} thing is less important, but might still be nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 10:20:16 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 10:13:21 2008 Subject: [GHC] #2841: Ghci + foreign export declarations result in undefined symbols In-Reply-To: <044.b0747800033e264d294e9c1520f847f6@localhost> References: <044.b0747800033e264d294e9c1520f847f6@localhost> Message-ID: <053.070d2663e7dfa55caa161d9470bf037d@localhost> #2841: Ghci + foreign export declarations result in undefined symbols ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler (FFI) | Version: 6.10.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by fasta): I wrongly assumed that one only needs the stub files in a compiled state. If one has .o then indeed the workaround works. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 10:32:24 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 10:25:39 2008 Subject: [GHC] #2641: Make -XExtendedDeafultRules a bit less liberal In-Reply-To: <046.d5d4eb9f2d648fc88d0b44a928fdd436@localhost> References: <046.d5d4eb9f2d648fc88d0b44a928fdd436@localhost> Message-ID: <055.681cc764d511f7211e12d7d3e32d94ca@localhost> #2641: Make -XExtendedDeafultRules a bit less liberal ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): The new rules should also take account of #2854. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 10:34:24 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 10:27:35 2008 Subject: [GHC] #2641: Revise the rules for -XExtendedDeafultRules In-Reply-To: <046.d5d4eb9f2d648fc88d0b44a928fdd436@localhost> References: <046.d5d4eb9f2d648fc88d0b44a928fdd436@localhost> Message-ID: <055.9617e77d044476e06411e68f512400cb@localhost> #2641: Revise the rules for -XExtendedDeafultRules ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * summary: Make -XExtendedDeafultRules a bit less liberal => Revise the rules for -XExtendedDeafultRules -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 10:35:00 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 10:28:08 2008 Subject: [GHC] #2854: Extended defaulting rules not used for super classes In-Reply-To: <044.cced03302e6b813ef4785978186cb6ee@localhost> References: <044.cced03302e6b813ef4785978186cb6ee@localhost> Message-ID: <053.364523799dea4af2d916f0dc426f8f25@localhost> #2854: Extended defaulting rules not used for super classes ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Hmm, well that does seem reasonable. But it depends on how we ultimately reformulate the `-XExtendedDefaultRules` rules (#2641). So I'll close this ticket to leave #2641 as the ticket where we figure out what to do for extended default rules. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 10:56:32 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 10:49:46 2008 Subject: [GHC] #2847: Failure on OPTION_* pramgas other than GHC In-Reply-To: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> References: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> Message-ID: <060.bcb950d369cab6db547238b7c9fa0d2c@localhost> #2847: Failure on OPTION_* pramgas other than GHC ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:7 igloo]: > Replying to [comment:6 duncan]: > > See `ghc/compiler/parser/Lexer.x` line 267: > > > > {{{ > > "{-#" $whitechar* (OPTIONS_HUGS|options_hugs|OPTIONS_NHC98|options_nhc98|OPTIONS_JHC|options_jhc|CFILES|cfiles) > > }}} > > > > Clearly this is not the right approach. > > We need this to be able to warn about unrecognised pragmas. > > But we also need to not parse `OPTIONS_foo` as an `OPTIONS` pragma, so we don't try to treat `_foo` and the pragma contents as a flag. Right, all the pragmas should require whitespace after the pragma name. I find it strange that `OPTIONS_HUGS` is not an unrecognised pragma, but `OPTIONS_YHC` is, surely we should be consistent here, where the only consistent thing to do is treat them both as unrecognised from the point of view of GHC. I can see that this might cause difficulties for people who want to use `-Werror -Wall` and use compiler-specific pragmas, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 11:11:48 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 11:04:51 2008 Subject: [GHC] #2847: Failure on OPTION_* pramgas other than GHC In-Reply-To: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> References: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> Message-ID: <060.07f81ac680342e7cbe0e15c0db7ccfba@localhost> #2847: Failure on OPTION_* pramgas other than GHC ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [comment:11 simonmar]: > I can see that this might cause difficulties for people who want to use `-Werror -Wall` and use compiler-specific pragmas, though. Which surely includes the core libraries since ghc likes to build them with -Werror during validate. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 11:34:58 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 11:28:02 2008 Subject: [GHC] #2863: ghc manual should note FFI non-compliance Message-ID: <045.dfae7d7031a0787f381988e11c3bf9e8@localhost> #2863: ghc manual should note FFI non-compliance -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The FFI spec says about hs_init and hs_exit: In addition to nested calls to `hs_init()`, the Haskell system may be de-initialised with `hs_exit()` and be re-initialised with `hs_init()` at a later point in time. The GHC manual says in the FFI chapter: There can be multiple calls to `hs_init()`, but each one should be matched by one (and only one) call to `hs_exit()`[11]. and adds in the footnote: [11] The outermost `hs_exit()` will actually de-initialise the system. NOTE that currently GHC's runtime cannot reliably re-initialise after this has happened. The chapter on known bugs and infelicities should have a section on non- compliance with the FFI part of the spec and should note this limitation, that `hs_init()` does not necessarily work after the last `hs_exit()` call. Of course if this can be fixed then that would be great. If not then perhaps it is better to make it fail obviously rather than possibly working or possibly going horribly wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 11:43:27 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 11:36:30 2008 Subject: [GHC] #2863: ghc manual should note FFI non-compliance In-Reply-To: <045.dfae7d7031a0787f381988e11c3bf9e8@localhost> References: <045.dfae7d7031a0787f381988e11c3bf9e8@localhost> Message-ID: <054.f4c1479884256be432aba6b37b9ea9b5@localhost> #2863: ghc manual should note FFI non-compliance ---------------------------------+------------------------------------------ Reporter: duncan | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 11:50:11 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 11:43:15 2008 Subject: [GHC] #2858: Segmentation fault due to race between IO manager and installSignals. In-Reply-To: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> References: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> Message-ID: <051.4776c226269d8ff3fd758bbbb5786e96@localhost> #2858: Segmentation fault due to race between IO manager and installSignals. ------------------------------------------------+--------------------------- Reporter: dsh | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: posix signal threaded IOmanager | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Comment (by dsh): Hello,[[BR]] It look like Haskell handlers are not freed after stg_sig_install in System.Posix.Signals[[BR]] Also freeing StablePtr in stg_sig_install leaves signal_handlers in inconsistent state.[[BR]] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 12:10:07 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 12:03:10 2008 Subject: [GHC] #2861: stage2 crash: PAP object entered! In-Reply-To: <047.c536937e353cb32aada209ba41cc326f@localhost> References: <047.c536937e353cb32aada209ba41cc326f@localhost> Message-ID: <056.36999c8e52562e9fac44e50eb8ce6848@localhost> #2861: stage2 crash: PAP object entered! ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I don't know why we get a PAP-entered fault when Lint is happy, but I do know the cause of the bizarre eta expansion. This fixes it: {{{ Tue Dec 9 17:03:02 GMT Standard Time 2008 simonpj@microsoft.com * Fix Trac #2861: bogus eta expansion Urghlhl! I "tided up" the treatment of the "state hack" in CoreUtils, but missed an unexpected interaction with the way that a bottoming function simply swallows excess arguments. There's a long Note [State hack and bottoming functions] to explain (which accounts for most of the new lines of code). }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 12:40:08 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 12:33:23 2008 Subject: [GHC] #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug Message-ID: <045.8041176773063583641ec33524fcf0dd@localhost> #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug --------------------+------------------------------------------------------- Reporter: megacz | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: major Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- The compiler asked me to report this. /Users/megacz/proj/icfp09/ghc/ghc/stage1-inplace/ghc -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081208 -hide-all-packages -no-user-package-conf -i -idist-stage2/build -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise -idist-stage2/build/autogen -Idist- stage2/build/autogen -Idist-stage2/build -I../libffi/build/include -Istage2plus -I../libraries/base/cbits -I../libraries/base/include -I. -Iparser -Iutils -optP-DGHCI -optP-include -optPdist- stage2/build/autogen/cabal_macros.h -odir dist-stage2/build -hidir dist- stage2/build -stubdir dist-stage2/build -package Cabal-1.5.5 -package array-0.2.0.0 -package base-4.0.0.0 -package bytestring-0.9.1.4 -package containers-0.2.0.0 -package directory-1.0.0.2 -package filepath-1.1.0.1 -package haskell98-1.0.1.0 -package hpc-0.5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.1 -package template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -prof -hisuf p_hi -hcsuf p_hc -osuf p_o -idist- stage2/build -H32m -O -Rghc-timing -O2 -c nativeGen/MachRegs.lhs -o dist-stage2/build/MachRegs.p_o -ohi dist-stage2/build/MachRegs.p_hi ghc: panic! (the 'impossible' happened) (GHC version 6.11.20081208 for i386-apple-darwin): CoreToStg.myCollectArgs (__scc {trivColorable ghc-6.11.20081208:MachRegs !} ghc-6.11.20081208:MachRegs.isSqueesed{v r2zH} [gid] 0 0) eta_s2Gv{v} [lid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> make[4]: *** [dist-stage2/build/MachRegs.p_o] Error 1 make[3]: *** [all] Error 1 make[2]: *** [build.stage.2] Error 2 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 This is using git HEAD, commit 2aba6f168b7bcb4f8c7c8e8f7cdc340a0ccb56e7 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 13:52:32 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 13:45:35 2008 Subject: [GHC] #2847: Failure on OPTION_* pramgas other than GHC In-Reply-To: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> References: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> Message-ID: <060.3e93a8bea9206d959c98d43af995ec49@localhost> #2847: Failure on OPTION_* pramgas other than GHC ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 14:48:38 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 14:41:44 2008 Subject: [GHC] #2865: Add more autocompletions in GHCi for :set and :show Message-ID: <050.1d3854c99bbd9f86a838cbf3c9bfc105@localhost> #2865: Add more autocompletions in GHCi for :set and :show -----------------------------+---------------------------------------------- Reporter: salty-horse | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.11 | Severity: trivial Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- GHCi already has tab completions for several :set options, but not all of them. :show also has a limited number of options and could be completed. The (untested) attached patch addresses both issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 14:51:36 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 14:44:43 2008 Subject: [GHC] #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug In-Reply-To: <045.8041176773063583641ec33524fcf0dd@localhost> References: <045.8041176773063583641ec33524fcf0dd@localhost> Message-ID: <054.4b5b557f8056d97e1a8e52b032156f9d@localhost> #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug ----------------------+----------------------------------------------------- Reporter: megacz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by megacz): FWIW, this happens on x86-linux as well: /afs/megacz.com/work/ghc/ghc/stage1-inplace/ghc -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081208 -hide-all-packages -no-user- package-conf -i -idist-stage2/build -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise -idist-stage2/build/autogen -Idist-stage2/build/autogen -Idist- stage2/build -I../libffi/build/include -Istage2plus -I../libraries/base/cbits -I../libraries/base/include -I. -Iparser -Iutils -optP-DGHCI -optP-include -optPdist-stage2/build/autogen/cabal_macros.h -odir dist-stage2/build -hidir dist-stage2/build -stubdir dist- stage2/build -package Cabal-1.5.5 -package array-0.2.0.0 -package base-4.0.0.0 -package bytestring-0.9.1.4 -package containers-0.2.0.0 -package directory-1.0.0.2 -package filepath-1.1.0.1 -package haskell98-1.0.1.0 -package hpc-0.5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.1 -package template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -prof -hisuf p_hi -hcsuf p_hc -osuf p_o -idist- stage2/build -H32m -O -Rghc-timing -O2 -c nativeGen/MachRegs.lhs -o dist-stage2/build/MachRegs.p_o -ohi dist-stage2/build/MachRegs.p_hi ghc: panic! (the 'impossible' happened) (GHC version 6.11.20081208 for i386-unknown-linux): CoreToStg.myCollectArgs (__scc {trivColorable ghc-6.11.20081208:MachRegs !} ghc-6.11.20081208:MachRegs.isSqueesed{v r2zH} [gid] 0 0) eta_s2Gv{v} [lid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> make[4]: *** [dist-stage2/build/MachRegs.p_o] Error 1 make[3]: *** [all] Error 1 make[3]: Leaving directory `/afs/megacz.com/work/ghc/compiler' make[2]: *** [build.stage.2] Error 2 make[2]: Leaving directory `/afs/megacz.com/work/ghc/compiler' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/afs/megacz.com/work/ghc' make: *** [bootstrap2] Error 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 15:02:46 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 14:55:52 2008 Subject: [GHC] #2865: Add more tab completions in GHCi for :set and :show In-Reply-To: <050.1d3854c99bbd9f86a838cbf3c9bfc105@localhost> References: <050.1d3854c99bbd9f86a838cbf3c9bfc105@localhost> Message-ID: <059.86526a51d7f356701422ab007cdbc464@localhost> #2865: Add more tab completions in GHCi for :set and :show ------------------------------+--------------------------------------------- Reporter: salty-horse | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.11 Severity: trivial | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by salty-horse): * summary: Add more autocompletions in GHCi for :set and :show => Add more tab completions in GHCi for :set and :show -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 15:25:13 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 15:18:56 2008 Subject: [GHC] #1968: data family + GADT: not implemented yet In-Reply-To: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> References: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> Message-ID: <052.d57fc95bf8924b1344124da59efc5309@localhost> #1968: data family + GADT: not implemented yet ---------------------------------------------------+------------------------ Reporter: Remi | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: data type family GADT choose_univs | Difficulty: Moderate (1 day) Testcase: GADT13 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------------+------------------------ Changes (by jeltsch): * cc: g9ks157k@acme.softbase.org (added) Comment: Replying to [comment:4 chak]: > What do you mean by "varying non-instance type"? Whether you write > {{{data family Blah x y :: *}}} or {{{data family Blah x :: * -> *}}} > makes no difference whatsoever for data families. I think it ''does'' make a difference if you use associated types. Consider this: {{{ {-# LANGUAGE TypeFamilies, GADTs #-} class C t where data D t :: * -> * instance C Bool where data D Bool Int = A }}} This doesn?t work, since the compiler expects a type variable at the place of the {{{Int}}}. Even more, you cannot introduce another constructor which constructs a {{{D Bool Char}}}, for example. With GADT syntax allowed in data family instance declarations, you could write the following: {{{ {-# LANGUAGE TypeFamilies, GADTs #-} class C t where data D t :: * -> * instance C Bool where data D Bool where A :: D Bool Int B :: D Bool Char }}} This code would also be different to declaring two different data family instances ({{{D Bool Int}}} and {{{D Bool Char}}}) in that it makes it impossible to introduce, say, a {{{D Bool Double}}} instance later. This might be exactly what a library designer wants I?d like to be able to use GADTs as data family instances for both of the above reasons. I think, I?d have good use for them. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 15:46:26 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 15:39:47 2008 Subject: [GHC] #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug In-Reply-To: <045.8041176773063583641ec33524fcf0dd@localhost> References: <045.8041176773063583641ec33524fcf0dd@localhost> Message-ID: <054.1b4530f5cb561b723e341759951cea61@localhost> #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug -------------------------+-------------------------------------------------- Reporter: megacz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > The compiler asked me to report this. > > /Users/megacz/proj/icfp09/ghc/ghc/stage1-inplace/ghc > -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081208 > -hide-all-packages -no-user-package-conf -i -idist-stage2/build > -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis > -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude -iprofiling > -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal > -itypecheck -itypes -iutils -ivectorise -idist-stage2/build/autogen > -Idist-stage2/build/autogen -Idist-stage2/build -I../libffi/build/include > -Istage2plus -I../libraries/base/cbits -I../libraries/base/include -I. > -Iparser -Iutils -optP-DGHCI -optP-include -optPdist- > stage2/build/autogen/cabal_macros.h -odir dist-stage2/build -hidir dist- > stage2/build -stubdir dist-stage2/build -package Cabal-1.5.5 -package > array-0.2.0.0 -package base-4.0.0.0 -package bytestring-0.9.1.4 -package > containers-0.2.0.0 -package directory-1.0.0.2 -package filepath-1.1.0.1 > -package haskell98-1.0.1.0 -package hpc-0.5.0.2 -package old-time-1.0.0.1 > -package process-1.0.1.1 -package template-haskell-2.3.0.0 -package > unix-2.3.1.0 -O -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP > -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface > -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses > -XFlexibleInstances -XRank2Types -XScopedTypeVariables > -XDeriveDataTypeable -prof -hisuf p_hi -hcsuf p_hc -osuf p_o -idist- > stage2/build -H32m -O -Rghc-timing -O2 -c nativeGen/MachRegs.lhs -o > dist-stage2/build/MachRegs.p_o -ohi dist-stage2/build/MachRegs.p_hi > ghc: panic! (the 'impossible' happened) > (GHC version 6.11.20081208 for i386-apple-darwin): > CoreToStg.myCollectArgs > (__scc {trivColorable ghc-6.11.20081208:MachRegs !} > ghc-6.11.20081208:MachRegs.isSqueesed{v r2zH} [gid] 0 0) > eta_s2Gv{v} [lid] > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > < (3 samples), 38M in use, 0.00 INIT (0.00 elapsed), 0.36 MUT (0.46 > elapsed), 0.16 GC (0.19 elapsed) :ghc>> > make[4]: *** [dist-stage2/build/MachRegs.p_o] Error 1 > make[3]: *** [all] Error 1 > make[2]: *** [build.stage.2] Error 2 > make[1]: *** [stage2] Error 2 > make: *** [bootstrap2] Error 2 > > > This is using git HEAD, commit 2aba6f168b7bcb4f8c7c8e8f7cdc340a0ccb56e7 New description: The compiler asked me to report this. {{{ /Users/megacz/proj/icfp09/ghc/ghc/stage1-inplace/ghc -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -package-name ghc-6.11.20081208 -hide-all-packages -no-user-package-conf -i -idist-stage2/build -inativeGen -ibasicTypes -icmm -icodeGen -icoreSyn -icprAnalysis -ideSugar -ighci -ihsSyn -iiface -imain -iparser -iprelude -iprofiling -irename -isimplCore -isimplStg -ispecialise -istgSyn -istranal -itypecheck -itypes -iutils -ivectorise -idist-stage2/build/autogen -Idist- stage2/build/autogen -Idist-stage2/build -I../libffi/build/include -Istage2plus -I../libraries/base/cbits -I../libraries/base/include -I. -Iparser -Iutils -optP-DGHCI -optP-include -optPdist- stage2/build/autogen/cabal_macros.h -odir dist-stage2/build -hidir dist- stage2/build -stubdir dist-stage2/build -package Cabal-1.5.5 -package array-0.2.0.0 -package base-4.0.0.0 -package bytestring-0.9.1.4 -package containers-0.2.0.0 -package directory-1.0.0.2 -package filepath-1.1.0.1 -package haskell98-1.0.1.0 -package hpc-0.5.0.2 -package old-time-1.0.0.1 -package process-1.0.1.1 -package template-haskell-2.3.0.0 -package unix-2.3.1.0 -O -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -prof -hisuf p_hi -hcsuf p_hc -osuf p_o -idist- stage2/build -H32m -O -Rghc-timing -O2 -c nativeGen/MachRegs.lhs -o dist-stage2/build/MachRegs.p_o -ohi dist-stage2/build/MachRegs.p_hi ghc: panic! (the 'impossible' happened) (GHC version 6.11.20081208 for i386-apple-darwin): CoreToStg.myCollectArgs (__scc {trivColorable ghc-6.11.20081208:MachRegs !} ghc-6.11.20081208:MachRegs.isSqueesed{v r2zH} [gid] 0 0) eta_s2Gv{v} [lid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug <> make[4]: *** [dist-stage2/build/MachRegs.p_o] Error 1 make[3]: *** [all] Error 1 make[2]: *** [build.stage.2] Error 2 make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2 }}} This is using git HEAD, commit 2aba6f168b7bcb4f8c7c8e8f7cdc340a0ccb56e7 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 15:56:27 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 15:49:34 2008 Subject: [GHC] #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug In-Reply-To: <045.8041176773063583641ec33524fcf0dd@localhost> References: <045.8041176773063583641ec33524fcf0dd@localhost> Message-ID: <054.3c94ec31819f24f7aa4877c3089aae9d@localhost> #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug -------------------------+-------------------------------------------------- Reporter: megacz | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * milestone: => 6.12 branch Comment: Can you say how are you building GHC please? i.e. what commands you are using, what you have in mk/build.mk, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 16:24:01 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 16:17:05 2008 Subject: [GHC] #2866: panic with GADTs + NoMonomorphismRestriction Message-ID: <045.3aec99e8c08f1ff61a0976868facff0f@localhost> #2866: panic with GADTs + NoMonomorphismRestriction -------------------+-------------------------------------------------------- Reporter: ganesh | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- The program below causes {{{ ganesh@defoe:~/temp$ ghc -c Test.hs ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): initC: srt_lbl }}} with ghc, and {{{ *Test> E 5 ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): nameModule xs{v afT} }}} with ghci The problem goes away with ghc -O. {{{ {-# LANGUAGE GADTs, NoMonomorphismRestriction #-} module Test where data Expr a = E Int deriving Show data IsSeq a where IsSeq :: IsSeq [a] isSeq :: Expr a -> IsSeq a isSeq = undefined mkSeq :: [Expr [a]] -> Expr [a] mkSeq = undefined unSeq :: Expr [a] -> [Expr [a]] unSeq = undefined sequenceEquality :: Expr a -> Expr a sequenceEquality x = case isSeq x of IsSeq -> let xs = unSeq x in mkSeq xs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 16:34:59 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 16:28:00 2008 Subject: [GHC] #2867: Make a pragma that tells GHC that another pragma name is OK Message-ID: <044.b8d409e55bb3523a205a81d0c4d153a4@localhost> #2867: Make a pragma that tells GHC that another pragma name is OK -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- GHC warns about unrecognised pragmas, but other impls can add pragmas inbetween GHC releases. If you want to use those pragmas then you can't just use `-Wall -Werror` when compiling. We could make a pragma to tell GHC to not warn about other pragmas, e.g. {{{ {-# KNOWN_PRAGMA FOO #-} }}} would make GHC not warn about `FOO` pragmas. Suggested in #2847. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 16:36:52 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 16:29:56 2008 Subject: [GHC] #2847: Failure on OPTION_* pramgas other than GHC In-Reply-To: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> References: <051.dd1f2b974cccfad9d6d95ef3d090ceff@localhost> Message-ID: <060.02d4d9bd90976410aed0dd2943155aac@localhost> #2847: Failure on OPTION_* pramgas other than GHC ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in the HEAD by: {{{ Tue Dec 9 19:03:18 GMT 2008 Ian Lynagh * Parse pragma names better; trac #2847 We require that pragma names are not followed by pragma character, defined as isAlphaNum c || c == '_' }}} and {{{ Tue Dec 9 19:17:24 GMT 2008 Ian Lynagh * Add OPTIONS_CATCH,DERIVE,YHC to those that GHC knows about; trac #2847 }}} and in the 6.10 branch by: {{{ Tue Dec 9 21:18:54 GMT 2008 Ian Lynagh * Merge some of the #2847 fixes to the 6.10 branch The patches didn't merge cleanly. I've only made the notFollowedByPragmaChar fix to the OPTIONS pragma. }}} I've opened #2867 for the `KNOWN_PRAGMA` suggestion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 19:30:10 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 19:23:12 2008 Subject: [GHC] #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug In-Reply-To: <045.8041176773063583641ec33524fcf0dd@localhost> References: <045.8041176773063583641ec33524fcf0dd@localhost> Message-ID: <054.4aad4ce59177d16ee0d717a12a2b5b9f@localhost> #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug -------------------------+-------------------------------------------------- Reporter: megacz | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by megacz): I issued these commands to acquire a fresh ghc tree (from scratch) and build it: git clone http://darcs.haskell.org/ghc.git ghc cd ghc curl 'http://hackage.haskell.org/trac/ghc/attachment/ticket/2857/fix-sync- all-patch?format=raw' | patch -p1 ./sync-all --complete get sh boot ./configure && make -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 19:31:06 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 19:24:12 2008 Subject: [GHC] #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug In-Reply-To: <045.8041176773063583641ec33524fcf0dd@localhost> References: <045.8041176773063583641ec33524fcf0dd@localhost> Message-ID: <054.53e88f47f6ef4cb4f5f5ab59b2c9b2ef@localhost> #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug -------------------------+-------------------------------------------------- Reporter: megacz | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by megacz): Er, formatted more nicely, that should be: {{{ git clone http://darcs.haskell.org/ghc.git ghc cd ghc curl 'http://hackage.haskell.org/trac/ghc/attachment/ticket/2857 /fix-sync-all-patch?format=raw' | patch -p1 ./sync-all --complete get sh boot ./configure && make }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 19:31:37 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 19:24:39 2008 Subject: [GHC] #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug In-Reply-To: <045.8041176773063583641ec33524fcf0dd@localhost> References: <045.8041176773063583641ec33524fcf0dd@localhost> Message-ID: <054.bd6b85a59bb5552b6dc02c3e5656560b@localhost> #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug -------------------------+-------------------------------------------------- Reporter: megacz | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by megacz): Sorry, one more try with the formatting: {{{ git clone http://darcs.haskell.org/ghc.git ghc cd ghc curl 'http://hackage.haskell.org/trac/ghc/attachment/ticket/2857/fix-sync- all-patch?format=raw' | patch -p1 ./sync-all --complete get sh boot ./configure && make }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 9 21:42:24 2008 From: trac at galois.com (GHC) Date: Tue Dec 9 21:35:26 2008 Subject: [GHC] #2160: "internal error: PAP object entered!" when running ghci compiled with profiling In-Reply-To: <044.7238efc2bf75e79eeb5aa57cfd0f92e1@localhost> References: <044.7238efc2bf75e79eeb5aa57cfd0f92e1@localhost> Message-ID: <053.c3d17d0dec2f270a1524a0cc8dfc249f@localhost> #2160: "internal error: PAP object entered!" when running ghci compiled with profiling ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | 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 Wed Dec 10 00:12:55 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 00:05:59 2008 Subject: [GHC] #2866: panic with GADTs + NoMonomorphismRestriction In-Reply-To: <045.3aec99e8c08f1ff61a0976868facff0f@localhost> References: <045.3aec99e8c08f1ff61a0976868facff0f@localhost> Message-ID: <054.d9cf0d214a6424543b1b82b41e5e9809@localhost> #2866: panic with GADTs + NoMonomorphismRestriction -------------------------+-------------------------------------------------- Reporter: ganesh | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonpj): * owner: => igloo * difficulty: => Unknown Comment: Thanks. I'm 99% certain that this is a dup of #2799, which has been fixed. Ian, can you just check that this program works on the 6.10 branch, and then close? It is certainly OK in the HEAD. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 00:50:06 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 00:43:47 2008 Subject: [GHC] #1968: data family + GADT: not implemented yet In-Reply-To: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> References: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> Message-ID: <052.852aebc0525108e30d1e4d1af52e7d6c@localhost> #1968: data family + GADT: not implemented yet ---------------------------------------------------+------------------------ Reporter: Remi | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: data type family GADT choose_univs | Difficulty: Moderate (1 day) Testcase: GADT13 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------------+------------------------ Comment (by simonpj): Can we be more specific about what this ticket is about? The HEAD (but not 6.10) does indeed accept GADT syntax for data type families. (I implemented that a few months ago, but I think I forgot to tell anyone.) So the following program compiles fine; I believe it meets the hopes expressed by 'guest' and Wolfgang. {{{ {-# LANGUAGE GADTs, TypeFamilies, KindSignatures #-} module Foo where data family Blah x :: * -> * data instance Blah Char a where Char1 :: Blah Char Int Char2 :: Blah Char Bool foo :: Blah Char a -> a foo Char1 = 2 foo Char2 = False ------------------- class C t where data D t :: * -> * instance C Bool where data D Bool a where A :: D Bool Int B :: D Bool Char }}} Does that do it? Shall we close the ticket? I've updated the docs to say explicitly that GADT syntax -- including actually defining a GADT as Wolfgang wants -- is allowed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 01:13:10 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 01:06:13 2008 Subject: [GHC] #2866: panic with GADTs + NoMonomorphismRestriction In-Reply-To: <045.3aec99e8c08f1ff61a0976868facff0f@localhost> References: <045.3aec99e8c08f1ff61a0976868facff0f@localhost> Message-ID: <054.e375d576fa814f37adcf93f45484f1dc@localhost> #2866: panic with GADTs + NoMonomorphismRestriction -------------------------+-------------------------------------------------- Reporter: ganesh | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by ganesh): * status: new => closed * resolution: => duplicate Comment: Thanks, I've confirmed this is ok on my original program with 6.10.1.20081209 Apologies for the dupe - I did search trac for the message, but for some unknown reason concluded that because all the bugs in the results page were crossed out, they couldn't be relevant! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 02:49:36 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 02:42:36 2008 Subject: [GHC] #2868: `par` `pseq` does not work as expected Message-ID: <046.4a753e52337d402e72287bba9ddadde5@localhost> #2868: `par` `pseq` does not work as expected --------------------------------+------------------------------------------- Reporter: hoangta | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.1 | Severity: major Keywords: par, pseq, parallel | Testcase: Os: Linux | Architecture: Unknown/Multiple --------------------------------+------------------------------------------- The following Wombat program is from "A Tutorial on Parallel and Concurrent Programming in Haskell". It does not work as expected on my computer (Core(TM)2 Quad CPU). Only one core is used when I watch by "mpstat -P ALL 1 200". I compile and run by: ghc --make -threaded wombat.hs ./wombat +RTS -N4 and the result is: par sum: 119201850 par time: 20.932636 seconds. seq sum: 119201850 seq time: 20.926783 seconds. Please check if is is a bug. ---- wombat.hs ---- import System.Time import Control.Parallel fib :: Int -> Int fib 0 = 0 fib 1 = 1 fib n = fib (n-1) + fib (n-2) secDiff :: ClockTime -> ClockTime -> Float secDiff (TOD secs1 psecs1) (TOD secs2 psecs2) = fromInteger (psecs2 - psecs1) / 1e12 + fromInteger (secs2 - secs1) mkList :: Int -> [Int] mkList n = [1..n-1] relprime :: Int -> Int -> Bool relprime x y = gcd x y == 1 euler :: Int -> Int euler n = length (filter (relprime n) (mkList n)) sumEuler :: Int -> Int sumEuler = sum . (map euler) . mkList seqSumFibEuler:: Int -> Int -> Int seqSumFibEuler a b = fib a + sumEuler b parSumFibEuler a b = f `par` (e `pseq` (e+ f)) where f = fib a e = sumEuler b r1 = seqSumFibEuler 40 7450 r2 = parSumFibEuler 40 7450 main :: IO () main = do t0 <- getClockTime pseq r1 (return()) t1 <- getClockTime putStrLn ("seq sum: " ++ show r1) putStrLn ("seq time: " ++ show (secDiff t0 t1) ++ " seconds.") t0 <- getClockTime pseq r2 (return()) t1 <- getClockTime putStrLn ("par sum: " ++ show r2) putStrLn ("par time: " ++ show (secDiff t0 t1) ++ " seconds.") -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 03:27:53 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 03:21:31 2008 Subject: [GHC] #1968: data family + GADT: not implemented yet In-Reply-To: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> References: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> Message-ID: <052.340cf6daa1f59ed2d04e0bc3f964ec5a@localhost> #1968: data family + GADT: not implemented yet ---------------------------------------------------+------------------------ Reporter: Remi | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: data type family GADT choose_univs | Difficulty: Moderate (1 day) Testcase: GADT13 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------------+------------------------ Comment (by jeltsch): Replying to [comment:12 simonpj]: > Does that do it? Shall we close the ticket? This seems to solve my problem. So as far as I?m concerned, this ticket can be closed. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 04:00:58 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 03:53:59 2008 Subject: [GHC] #2867: Make a pragma that tells GHC that another pragma name is OK In-Reply-To: <044.b8d409e55bb3523a205a81d0c4d153a4@localhost> References: <044.b8d409e55bb3523a205a81d0c4d153a4@localhost> Message-ID: <053.172fcf6cb426363b342ddfa3b00f770e@localhost> #2867: Make a pragma that tells GHC that another pragma name is OK ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: 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 NeilMitchell): * cc: ndmitchell@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 04:50:32 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 04:44:15 2008 Subject: [GHC] #1968: data family + GADT: not implemented yet In-Reply-To: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> References: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> Message-ID: <052.314d0540e12afef35ebc2d32da77bbac@localhost> #1968: data family + GADT: not implemented yet ---------------------------------------------------+------------------------ Reporter: Remi | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: data type family GADT choose_univs | Difficulty: Moderate (1 day) Testcase: GADT13 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------------+------------------------ Comment (by TristanAllwood): Does everything I want, from my pov the ticket can be closed. Cheers, Tris ('guest') -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 04:56:17 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 04:49:17 2008 Subject: [GHC] #2858: Segmentation fault due to race between IO manager and installSignals. In-Reply-To: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> References: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> Message-ID: <051.634c6a2db20019df03f810330346e5d3@localhost> #2858: Segmentation fault due to race between IO manager and installSignals. ------------------------------------------------+--------------------------- Reporter: dsh | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: posix signal threaded IOmanager | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Comment (by dsh): Replying to [comment:1 dsh]: > With this fix I get assertion with sanity checks enabled about deadlock.[[BR]] > > May be IO manager should read its pipe in non-blocking mode? Small clarification. The deadlock I see happens if one of the following RTS setup is used [[BR]] 1. "+RTS -N2 -g1 -DS --install-handlers=no -RTS"[[BR]] 2. "+RTS -N1 -DS --install-handlers=no -RTS"[[BR]] I observe the issue with slightly more complex program (using createProcess from System.Process). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 06:10:59 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 06:04:01 2008 Subject: [GHC] #2160: "internal error: PAP object entered!" when running ghci compiled with profiling In-Reply-To: <044.7238efc2bf75e79eeb5aa57cfd0f92e1@localhost> References: <044.7238efc2bf75e79eeb5aa57cfd0f92e1@localhost> Message-ID: <053.1b30c0b5710be43df3ba2be86d56fff2@localhost> #2160: "internal error: PAP object entered!" when running ghci compiled with profiling ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: There's another ticket about this: #2197, and since that one has more commentary I'm closing this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 06:13:55 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 06:06:56 2008 Subject: [GHC] #2868: `par` `pseq` does not work as expected In-Reply-To: <046.4a753e52337d402e72287bba9ddadde5@localhost> References: <046.4a753e52337d402e72287bba9ddadde5@localhost> Message-ID: <055.14182276edea3982cad5eb0e47618135@localhost> #2868: `par` `pseq` does not work as expected ------------------------------------+--------------------------------------- Reporter: hoangta | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: major | Resolution: Keywords: par, pseq, parallel | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Easy (1 hr) * os: Linux => Unknown/Multiple * milestone: => 6.10.2 Comment: Ok, this is a known bug but we don't have a ticket for it. Thanks for the report. It affects programs that create just one spark - the scheduler's load- balancing algorithm isn't doing its job properly in that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 06:14:40 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 06:07:39 2008 Subject: [GHC] #2868: `par` `pseq` does not work as expected In-Reply-To: <046.4a753e52337d402e72287bba9ddadde5@localhost> References: <046.4a753e52337d402e72287bba9ddadde5@localhost> Message-ID: <055.1e257eff673445b9ad50129009b51b7d@localhost> #2868: `par` `pseq` does not work as expected ------------------------------------+--------------------------------------- Reporter: hoangta | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: major | Resolution: Keywords: par, pseq, parallel | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Old description: > The following Wombat program is from "A Tutorial on Parallel and > Concurrent Programming in Haskell". It does not work as expected on my > computer (Core(TM)2 Quad CPU). Only one core is used when I watch by > "mpstat -P ALL 1 200". I compile and run by: > ghc --make -threaded wombat.hs > ./wombat +RTS -N4 > > and the result is: > par sum: 119201850 > par time: 20.932636 seconds. > seq sum: 119201850 > seq time: 20.926783 seconds. > > Please check if is is a bug. > > ---- wombat.hs ---- > import System.Time > import Control.Parallel > > fib :: Int -> Int > fib 0 = 0 > fib 1 = 1 > fib n = fib (n-1) + fib (n-2) > > secDiff :: ClockTime -> ClockTime -> Float > secDiff (TOD secs1 psecs1) (TOD secs2 psecs2) = > fromInteger (psecs2 - psecs1) / 1e12 + fromInteger (secs2 - > secs1) > > mkList :: Int -> [Int] > mkList n = [1..n-1] > > relprime :: Int -> Int -> Bool > relprime x y = gcd x y == 1 > > euler :: Int -> Int > euler n = length (filter (relprime n) (mkList n)) > > sumEuler :: Int -> Int > sumEuler = sum . (map euler) . mkList > > seqSumFibEuler:: Int -> Int -> Int > seqSumFibEuler a b = fib a + sumEuler b > > parSumFibEuler a b = f `par` (e `pseq` (e+ f)) > where > f = fib a > e = sumEuler b > > r1 = seqSumFibEuler 40 7450 > r2 = parSumFibEuler 40 7450 > > main :: IO () > main = > do > t0 <- getClockTime > pseq r1 (return()) > t1 <- getClockTime > putStrLn ("seq sum: " ++ show r1) > putStrLn ("seq time: " ++ show (secDiff t0 t1) ++ " > seconds.") > t0 <- getClockTime > pseq r2 (return()) > t1 <- getClockTime > putStrLn ("par sum: " ++ show r2) > putStrLn ("par time: " ++ show (secDiff t0 t1) ++ " > seconds.") New description: The following Wombat program is from "A Tutorial on Parallel and Concurrent Programming in Haskell". It does not work as expected on my computer (Core(TM)2 Quad CPU). Only one core is used when I watch by "mpstat -P ALL 1 200". I compile and run by: {{{ ghc --make -threaded wombat.hs ./wombat +RTS -N4 }}} and the result is: {{{ par sum: 119201850 par time: 20.932636 seconds. seq sum: 119201850 seq time: 20.926783 seconds. }}} Please check if is is a bug. {{{ ---- wombat.hs ---- import System.Time import Control.Parallel fib :: Int -> Int fib 0 = 0 fib 1 = 1 fib n = fib (n-1) + fib (n-2) secDiff :: ClockTime -> ClockTime -> Float secDiff (TOD secs1 psecs1) (TOD secs2 psecs2) = fromInteger (psecs2 - psecs1) / 1e12 + fromInteger (secs2 - secs1) mkList :: Int -> [Int] mkList n = [1..n-1] relprime :: Int -> Int -> Bool relprime x y = gcd x y == 1 euler :: Int -> Int euler n = length (filter (relprime n) (mkList n)) sumEuler :: Int -> Int sumEuler = sum . (map euler) . mkList seqSumFibEuler:: Int -> Int -> Int seqSumFibEuler a b = fib a + sumEuler b parSumFibEuler a b = f `par` (e `pseq` (e+ f)) where f = fib a e = sumEuler b r1 = seqSumFibEuler 40 7450 r2 = parSumFibEuler 40 7450 main :: IO () main = do t0 <- getClockTime pseq r1 (return()) t1 <- getClockTime putStrLn ("seq sum: " ++ show r1) putStrLn ("seq time: " ++ show (secDiff t0 t1) ++ " seconds.") t0 <- getClockTime pseq r2 (return()) t1 <- getClockTime putStrLn ("par sum: " ++ show r2) putStrLn ("par time: " ++ show (secDiff t0 t1) ++ " seconds.") }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 06:18:56 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 06:11:58 2008 Subject: [GHC] #2867: Make a pragma that tells GHC that another pragma name is OK In-Reply-To: <044.b8d409e55bb3523a205a81d0c4d153a4@localhost> References: <044.b8d409e55bb3523a205a81d0c4d153a4@localhost> Message-ID: <053.50b905c57dd5c3987a6facb9bafd99c4@localhost> #2867: Make a pragma that tells GHC that another pragma name is OK ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: 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 simonmar): Wouldn't it be better to do something like this {{{ {-# OPTIONS_GHC -fno-warn-unrecognised-pragma FOO #-} }}} And then we can document that the default options include {{{ -fno-warn-unrecognised-pragma OPTIONS_HUGS etc. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 06:45:45 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 06:39:23 2008 Subject: [GHC] #1968: data family + GADT: not implemented yet In-Reply-To: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> References: <043.23a4d08c9eaa4d1c4c93b9abe9a12e10@localhost> Message-ID: <052.27b586c49a380d866808e7277149b369@localhost> #1968: data family + GADT: not implemented yet ---------------------------------------------------+------------------------ Reporter: Remi | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: fixed Keywords: data type family GADT choose_univs | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------------+------------------------ Changes (by simonpj): * testcase: GADT13 => * status: new => closed * resolution: => fixed Comment: OK, I'm closing this. Would one of you care to add a testsuite case (or submit a patch) so that we have a test for this feature? I'm removing gadt13 as a test, since that test seems entirely unrelated to this ticket. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 07:43:56 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 07:36:58 2008 Subject: [GHC] #2869: Linking problem in S390 and ARM Message-ID: <045.3e236853ab34b715950705d6f98bf7ea@localhost> #2869: Linking problem in S390 and ARM -------------------+-------------------------------------------------------- Reporter: marcot | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: arm -------------------+-------------------------------------------------------- The bug is described in http://bugs.debian.org/482503 . -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 07:45:30 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 07:38:31 2008 Subject: [GHC] #2870: User signals are not blocked before 'fork' in runInteractiveProcess Message-ID: <042.e53acc7954108a66f75c2330d39f6f71@localhost> #2870: User signals are not blocked before 'fork' in runInteractiveProcess -------------------------------------------+-------------------------------- Reporter: dsh | Owner: Type: bug | Status: new Priority: normal | Component: libraries/process Version: 6.10.1 | Severity: normal Keywords: threaded runInteractiveProcess | Testcase: Os: Unknown/Multiple | Architecture: x86_64 (amd64) -------------------------------------------+-------------------------------- Hello,[[BR]] It is possible that the parent process handles user-defined interrupts for the child process. IOManager pipe and generic_handler is inherited in the child process. Pipe and generic_handler are used in threaded RTS. Although the race window before 'exec' is small.[[BR]] Regards,[[BR]] Dmitry -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 07:53:49 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 07:46:51 2008 Subject: [GHC] #2867: Make a way to tell GHC that a pragma name should be "recognised" In-Reply-To: <044.b8d409e55bb3523a205a81d0c4d153a4@localhost> References: <044.b8d409e55bb3523a205a81d0c4d153a4@localhost> Message-ID: <053.c6ef1182683e05ec7bb6a364738f8160@localhost> #2867: Make a way to tell GHC that a pragma name should be "recognised" ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: 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 igloo): * summary: Make a pragma that tells GHC that another pragma name is OK => Make a way to tell GHC that a pragma name should be "recognised" -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 08:51:20 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 08:44:22 2008 Subject: [GHC] #2863: ghc manual should note FFI non-compliance In-Reply-To: <045.dfae7d7031a0787f381988e11c3bf9e8@localhost> References: <045.dfae7d7031a0787f381988e11c3bf9e8@localhost> Message-ID: <054.e1bbb80a89b59b26b55e46f7980321a5@localhost> #2863: ghc manual should note FFI non-compliance ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge * milestone: => 6.10.2 Comment: Done: {{{ Tue Dec 9 16:43:22 GMT 2008 Simon Marlow * Document hs_init() infelicity (#2863) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 09:29:28 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 09:22:30 2008 Subject: [GHC] #2869: Linking problem in S390 and ARM In-Reply-To: <045.3e236853ab34b715950705d6f98bf7ea@localhost> References: <045.3e236853ab34b715950705d6f98bf7ea@localhost> Message-ID: <054.173d44b5a67e03cf16de45a99dfabc02@localhost> #2869: Linking problem in S390 and ARM -------------------------+-------------------------------------------------- Reporter: marcot | 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: arm | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Looking at the buildlog here: http://buildd.debian.org/fetch.cgi?&pkg=gtk2hs&ver=0.9.13-4&arch=s390&stamp=1227883724&file=log the build goes: {{{ mkdir -p gtk/Graphics/UI/Gtk/Abstract/Widget_split /usr/bin/ghc -split-objs gtk/Graphics/UI/Gtk/Abstract/Widget.hs -o gtk/Graphics/UI/Gtk/Abstract/Widget.o if test -f gtk/Graphics/UI/Gtk/Abstract/Widget.o; then :; else find gtk/Graphics/UI/Gtk/Abstract/Widget_split/ -name '*.o' > gtk/Graphics/UI/Gtk/Abstract/Widget_split/list; /usr/bin/ld -r -x -o gtk/Graphics/UI/Gtk/Abstract/Widget.o @gtk/Graphics/UI/Gtk/Abstract/Widget_split/list; fi [...] ./mk/link-splitobjs.sh libHSgtk.a [...] gtk/Graphics/UI/Gtk/Abstract/Widget.o [...] }}} and `link-splitobjs.sh` looks like: {{{ for obj in $@; do dir=`dirname ${obj}`/`basename ${obj} .o`_split if test -d ${dir}; then find ${dir}/ -name '*.o' >> ${lib}.list else echo ${obj} >> ${lib}.list fi done }}} Debian's s390 is built with `SplitObjs=NO`, so the `-split-objs` flag is ignored. It looks like the gtk2hs build system copes with this when making the module `.o` file, by checking if the `.o` file already exists, but not when making the package archive, as that directory will always exist. So it will not include the object file in the archive. I haven't actually done a build, so please reopen if you think I've missed something. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 09:44:09 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 09:37:08 2008 Subject: [GHC] #2868: `par` `pseq` does not work as expected In-Reply-To: <046.4a753e52337d402e72287bba9ddadde5@localhost> References: <046.4a753e52337d402e72287bba9ddadde5@localhost> Message-ID: <055.008c868463464772567d22835b118454@localhost> #2868: `par` `pseq` does not work as expected ------------------------------------+--------------------------------------- Reporter: hoangta | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: major | Resolution: Keywords: par, pseq, parallel | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * milestone: 6.10.2 => 6.12 branch Comment: Copy of more detailed reply I sent to ghc-users: Your program is suffering from microbenchmarkitis, I'm afraid. There's only one spark, which tickles a bug in the scheduler in 6.10.1 and earlier (but sometimes doesn't happen due to random scheduling behaviour). Even with that fixed, the program uses fib which tickles another bug: when optimised, fib doesn't do any allocation, and GHC's scheduler relies on allocation happening at regular enough intervals. In 6.10.1 we never get to do load-balancing in this example, because fib doesn't ever yield control to the scheduler. In HEAD, where we have work- stealing and don't rely on the scheduler for load-balancing, the load- balancing problem goes away but reveals another problem: the second thread wants to GC, but in order to GC it has to synchronise with the other running threads, but the other thread is running fib and never yields. We can fix this by allowing CPUs to GC independently (which we plan to do), but even then you could still run into the same problem because eventually a global GC will be required. If you really want to see the program running in parallel, turn off -O. --------- I've now fixed the scheduling bug in stable. {{{ Wed Dec 10 14:42:35 GMT 2008 Simon Marlow * Fix (part of) #2868: do load-balancing when there's only one spark }}} There's a similar bug in HEAD (but it happens less often), so I'm leaving the ticket open. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 10:31:47 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 10:24:47 2008 Subject: [GHC] #2815: On windows, hGetLine stdin leaks like an inside trader In-Reply-To: <043.3df837702ae4600d2a6b83af98512acb@localhost> References: <043.3df837702ae4600d2a6b83af98512acb@localhost> Message-ID: <052.86efe46b95a210050f8ee98044184a36@localhost> #2815: On windows, hGetLine stdin leaks like an inside trader ---------------------------------+------------------------------------------ Reporter: sclv | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => worksforme Comment: I still can't reproduce it, trying 6.10.1 and HEAD, with or without -threaded, cmd.exe or Cygwin bash. I'll have to close the ticket. If anyone can find a way to reproduce it, please re-open. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 10:34:55 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 10:27:55 2008 Subject: [GHC] #2869: Linking problem in S390 and ARM In-Reply-To: <045.3e236853ab34b715950705d6f98bf7ea@localhost> References: <045.3e236853ab34b715950705d6f98bf7ea@localhost> Message-ID: <054.36248d59cbf71792579061c6742e4ffe@localhost> #2869: Linking problem in S390 and ARM -------------------------+-------------------------------------------------- Reporter: marcot | 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: arm | -------------------------+-------------------------------------------------- Comment (by duncan): Marco claims he's done a build of gtk2hs using ./configure --disable- split-objs and it still failed. Hopefully he'll post a link to that and re-open this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 10:50:24 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 10:43:29 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.66cb2e2062e7c56ac67990cf1c3b1173@localhost> #1364: Finalizers not guaranteed to run before the program exits -------------------------------------+-------------------------------------- Reporter: tomac@pacific.net.au | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: feature request => merge Comment: Ok, I've finally reviewed, amended, tested and pushed these patches. Under normal circumstances we wouldn't push this into the stable branch, because it constitutes a new feature and makes a minor API change. However, there is strong demand for this feature, and the API change is really very minor (a new primop). Patches to merge: in GHC: {{{ Wed Dec 10 15:04:25 GMT 2008 Simon Marlow * FIX #1364: added support for C finalizers that run as soon as the value is not longer reachable. Patch originally by Ivan Tomac , amended by Simon Marlow: - mkWeakFinalizer# commoned up with mkWeakFinalizerEnv# - GC parameters to ALLOC_PRIM fixed }}} to libraries/base: {{{ Wed Dec 10 15:05:10 GMT 2008 Ivan Tomac * FIX #1364: added support for C finalizers that run as soon as the value is no longer reachable. Patch amended by Simon Marlow: - mkWeakFinalizer# commoned up with mkWeakFinalizerEnv# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 10:57:14 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 10:50:13 2008 Subject: [GHC] #2160: "internal error: PAP object entered!" when running ghci compiled with profiling In-Reply-To: <044.7238efc2bf75e79eeb5aa57cfd0f92e1@localhost> References: <044.7238efc2bf75e79eeb5aa57cfd0f92e1@localhost> Message-ID: <053.74080ef13b2732517485692f2d12798f@localhost> #2160: "internal error: PAP object entered!" when running ghci compiled with profiling ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by guest): Simon: is this really the same one? 'PAP object entered' doesn't look like Sam's '/dist/build/HSghc-prim-0.1.o: unknown symbol `traceCcszh_fast'' error. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 10:57:29 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 10:50:30 2008 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.6cd97b30be0fbed8ddd1b5d7554f65f7@localhost> #2197: GHCi doesn't work when built with way=p ---------------------------------+------------------------------------------ Reporter: SamB | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by guest): * cc: gwern0@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 11:04:44 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 10:57:45 2008 Subject: [GHC] #2769: Export mapAccumR from Data.Map, Data.IntMap In-Reply-To: <047.6884ccd8725fc9653ca909dcd5164d50@localhost> References: <047.6884ccd8725fc9653ca909dcd5164d50@localhost> Message-ID: <056.0ea077dcfb763f58fc005dc91cbd1639@localhost> #2769: Export mapAccumR from Data.Map, Data.IntMap ----------------------------------+----------------------------------------- Reporter: Deewiant | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.11 Severity: normal | Resolution: Keywords: containers | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by Deewiant): I think I've let this sit for long enough now. Discussion was short, with only one response: Ross Paterson suggested that the name be `mapAccumRWithKey` instead of just `mapAccumR` as the latter is available through `Traversable` with a different type. I agree with this change and attached is the revised patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 15:12:54 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 15:05:53 2008 Subject: [GHC] #2871: "Prologue junk?" error when building GHC Message-ID: <047.340efbd5b95f62aac88650d45afdbdde@localhost> #2871: "Prologue junk?" error when building GHC ---------------------+------------------------------------------------------ Reporter: Deewiant | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 ---------------------+------------------------------------------------------ As far as I can tell this is a bug in the Evil Mangler. This is on Windows, using MSYS to build. The relevant `make` output, compiling the HEAD: {{{ make -C rts make[1]: Entering directory `/D/Programming/src/ghc-HEAD/rts' d:/Programming/src/ghc-HEAD/ghc/stage1-inplace/ghc -fvia-C -static -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c Apply.cmm -o Apply.o Prologue junk?: .globl _stg_ap_0_fast _stg_ap_0_fast: /APP # 9 "C:\Temp\/ghc3572_0/ghc3572_0.hc" 1 make[1]: *** [Apply.o] Error 9 make[1]: Leaving directory `/D/Programming/src/ghc-HEAD/rts' make: *** [stage1] Error 2 }}} This happens also when building 6.10.1, so it's not a HEAD problem. I didn't try other GHC versions. `gcc --version`: {{{ gcc.exe (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502 }}} Attached is a `.raw_s` obtained by running the ghc command with `-keep- raw-s-file`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 16:40:37 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 16:33:35 2008 Subject: [GHC] #2872: sparc -mcpu=v9 is not used in assembly phase Message-ID: <045.560447626eec7a2ff3f9465e35a5352d@localhost> #2872: sparc -mcpu=v9 is not used in assembly phase --------------------+------------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Os: Solaris | Architecture: sparc --------------------+------------------------------------------------------- The ghc `DriverPipeline.hs` adds `-mcpu=v9` when compiling .hs files on sparc: {{{ #ifdef sparc_TARGET_ARCH -- We only support SparcV9 and better because V8 lacks an atomic CAS -- instruction. Note that the user can still override this -- (e.g., -mcpu=ultrasparc) as GCC picks the "best" -mcpu flag -- regardless of the ordering. -- -- This is a temporary hack. ++ ["-mcpu=v9"] #endif }}} This is great, but it does not add -mcpu=v9 when it calls gcc to assemble the .s file. So it fails because the .s file uses v9 instructions but we're not telling the assembler to use v9: {{{ /tmp/ghc16216_0/ghc16216_0.split__1.s:22:0: Error: Architecture mismatch on "blu,pn %icc,.LL4". /tmp/ghc16216_0/ghc16216_0.split__1.s:22:0: (Requires v9|v9a|v9b; requested architecture is v8.) }}} If one re-runs that failing command with -opta-mcpu=v9 then of course it works. The general rule is that any -mcpu flags passed to gcc at the compile stage also have to be passed to gcc at the assembly phase. Looking at the code it appears that the `-mcpu=v9` flag is passed for the `HCc` and `As` but not `SplitAs` phases. Of course the `SplitAs` phase is used during ghc bootstrapping which is where I found this failure. This is in ghc-6.8.3 but the code looks to be the same in 6.10 so I don't think it's already been fixed. The workaround is to use `SRC_HC_OPTS=-opta-mcpu=v9` in `mk/build.mk`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 18:33:05 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 18:26:04 2008 Subject: [GHC] #2873: ghc-pkg list/dump --package-conf=missing returns successful error code Message-ID: <045.d3448bbf66f00ef8dc9dae0dc42ea1ff@localhost> #2873: ghc-pkg list/dump --package-conf=missing returns successful error code -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- If the user supplies a missing package file then ghc-pkg should return a non-0 exit code to indicate failure. {{{ $ ghc-pkg list --package-conf=missing missing: }}} (I note that we need a trac component for "Package system" tickets.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 10 18:34:00 2008 From: trac at galois.com (GHC) Date: Wed Dec 10 18:26:57 2008 Subject: [GHC] #2873: ghc-pkg list/dump --package-conf=missing returns successful error code In-Reply-To: <045.d3448bbf66f00ef8dc9dae0dc42ea1ff@localhost> References: <045.d3448bbf66f00ef8dc9dae0dc42ea1ff@localhost> Message-ID: <054.6426e772cdf94d895bdbe4641cc562d5@localhost> #2873: ghc-pkg list/dump --package-conf=missing returns successful error code ------------------------------+--------------------------------------------- Reporter: duncan | 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 duncan): The same goes for `--global-conf=` I expect they share the same code path. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 11 06:02:39 2008 From: trac at galois.com (GHC) Date: Thu Dec 11 05:55:36 2008 Subject: [GHC] #2160: "internal error: PAP object entered!" when running ghci compiled with profiling In-Reply-To: <044.7238efc2bf75e79eeb5aa57cfd0f92e1@localhost> References: <044.7238efc2bf75e79eeb5aa57cfd0f92e1@localhost> Message-ID: <053.8166fb1d30b4e05d457b7d5c3384e137@localhost> #2160: "internal error: PAP object entered!" when running ghci compiled with profiling ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:5 guest]: > Simon: is this really the same one? 'PAP object entered' doesn't look like Sam's '/dist/build/HSghc-prim-0.1.o: unknown symbol `traceCcszh_fast'' error. SamB said in that ticket "Btw, the symbol mentioned in the error is from something I'm working on... but the non_p ghci loads fine." Also, both tickets are about running a profiled GHC with --interactive, which is known to not work. I'd expect a crash on running the first bit of dynamically loaded or interpreted code (what we see here), but missing symbols on loading objects is to be expected too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 11 07:05:03 2008 From: trac at galois.com (GHC) Date: Thu Dec 11 06:58:10 2008 Subject: [GHC] #2874: Error message doesn't mention extension that is missing Message-ID: <044.244748ee082046ce491869b3d395636a@localhost> #2874: Error message doesn't mention extension that is missing -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- If you forget to turn on a language extension then the error message usually mentions the missing extension. Not this message: {{{ Illegal polymorphic or qualified type: forall a. (Tradeable a) => a -> b In the type signature for `withSomeAgingContract': withSomeAgingContract :: (forall a. (Tradeable a) => a -> b) -> SomeAgingContract -> b }}} It should mention Rank2Types (or RankNTypes). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 11 09:58:35 2008 From: trac at galois.com (GHC) Date: Thu Dec 11 09:51:36 2008 Subject: [GHC] #2875: Correct SYB's representation of Char Message-ID: <046.b0f5f032bb0b9756d1b0c1824b96239d@localhost> #2875: Correct SYB's representation of Char -----------------------------+---------------------------------------------- Reporter: dreixel | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- SYB uses `DataRep` to represent datatypes: {{{ -- | Public representation of datatypes data DataRep = AlgRep [Constr] | IntRep | FloatRep | StringRep | NoRep }}} I believe that `StringRep` should be `CharRep`. Note that `IntRep` is used for the primitive `Int` and `Integer` datatypes, `FloatRep` for `Float` and `Double`, and `StringRep` (apparently) for `Char`. `String`, however, is represented as `AlgRep [[],(:)]`: {{{ *Main> dataTypeOf 'p' DataType {tycon = "Prelude.Char", datarep = StringRep} *Main> dataTypeOf "p" DataType {tycon = "Prelude.[]", datarep = AlgRep [[],(:)]} }}} This makes sense, since `String` is not a primitive datatype. But it causes the apparently wrong behavior: {{{ *Main> fromConstr (mkStringConstr (dataTypeOf "a") "ab") :: String "*** Exception: mkStringConstr *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "ab") :: String "*** Exception: constrIndex }}} The correct way of using `mkStringConstr` is to construct a `Char`. This, however, only works for strings with a single character: {{{ *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "b") :: Char 'b' *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "ab") :: Char *** Exception: gunfold *Main> fromConstr (mkStringConstr (dataTypeOf 'a') "") :: Char *** Exception: gunfold }}} I find this behavior counterintuitive. Therefore I propose to rename `StringRep` to `CharRep` and `mkStringConstr` to `mkCharConstr`. For backwards compatibility, this entails: * Deprecating `mkStringConstr` and `StringConstr` * Deprecating `mkStringRep` and `StringRep` * Introducing `mkCharConstr` and `CharConstr` * Introducing `mkCharRep` and `CharRep` Additionally, due to deprecation warnings, the following have to change as well: * libraries/template-haskell/Language/Haskell/TH/Quote.hs * compiler/utils/Serialized.hs I'm attaching a patch with the proposed changes. I propose a discussion period of 4 weeks, therefore until the 8th of January. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 11 10:25:03 2008 From: trac at galois.com (GHC) Date: Thu Dec 11 10:17:59 2008 Subject: [GHC] #2876: Inconsistent error message Message-ID: <044.5a28c6b93763f0b6cbcb3674dddddbbb@localhost> #2876: Inconsistent error message -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Most error messages mention language extensions needed, this one mentions a deprectaed flag: {{{ Illegal instance declaration for `...' (the Coverage Condition fails for one of the functional dependencies; Use -fallow-undecidable-instances to permit this) }}} It should instead mention -XUndecidableInstances. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 11 11:33:55 2008 From: trac at galois.com (GHC) Date: Thu Dec 11 11:27:05 2008 Subject: [GHC] #2852: Type family checking oddity In-Reply-To: <044.fdac353512d121dcac11b2fbc3873f76@localhost> References: <044.fdac353512d121dcac11b2fbc3873f76@localhost> Message-ID: <053.5909d1484dac6632423d93e767c47777@localhost> #2852: Type family checking oddity ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: worksforme Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by guest): * cc: kfrdbs@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 11 11:48:49 2008 From: trac at galois.com (GHC) Date: Thu Dec 11 11:41:46 2008 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.b3c308671727bc8b064108ea7f99db93@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10.2 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: _|_ => 6.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 11 18:53:17 2008 From: trac at galois.com (GHC) Date: Thu Dec 11 18:46:17 2008 Subject: [GHC] #2877: crash when printig a list (IO ()) Message-ID: <044.0933e1ca77e0ef5175110397abfb4837@localhost> #2877: crash when printig a list (IO ()) --------------------+------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86_64 (amd64) --------------------+------------------------------------------------------- data InputSignal = IS1 | IS2 data OutputSignal = OS1 Widget [Int] | OS2 Widget [String] type Widget = InputSignal -> OutputSignal testWidgetSignalProcessor :: (Int, Int, Int) -> Widget testWidgetSignalProcessor pos@(x, y, z) IS1 = OS1 (testWidgetSignalProcessor pos) [1, 2, 3] testWidgetSignalProcessor pos@(x, y, z) IS2 = OS2 (testWidgetSignalProcessor (666, 666, 666)) ["ich", "kack", "ab"] makeTestWidget :: (Int, Int, Int) -> Widget makeTestWidget pos = testWidgetSignalProcessor pos display :: OutputSignal -> IO () display (OS1 widget list) = print list display (OS2 widget list) = print list test :: IO () test = do let testWidget = makeTestWidget (0, 0, 0) display $ testWidget IS1 display $ testWidget IS2 when i enter "test" at the interpreter-prompt (i'm using ghci from emacs), it crashes with the following message: : panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-mingw32): loadObj: failed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 11 21:55:53 2008 From: trac at galois.com (GHC) Date: Thu Dec 11 21:48:47 2008 Subject: [GHC] #2872: sparc -mcpu=v9 is not used in assembly phase In-Reply-To: <045.560447626eec7a2ff3f9465e35a5352d@localhost> References: <045.560447626eec7a2ff3f9465e35a5352d@localhost> Message-ID: <054.5496f19a2f27505c7a5ce45fdf5e1965@localhost> #2872: sparc -mcpu=v9 is not used in assembly phase ----------------------+----------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Solaris | Architecture: sparc ----------------------+----------------------------------------------------- Comment (by rl): I wasn't aware of `SplitAs` when I implemented this. Is that used instead of `As` when `SPLIT_OBJS=YES`? In any case, could you please add the same chunk of code to `SplitAs` and test it. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 12 07:10:57 2008 From: trac at galois.com (GHC) Date: Fri Dec 12 07:03:52 2008 Subject: [GHC] #2868: `par` `pseq` does not work as expected In-Reply-To: <046.4a753e52337d402e72287bba9ddadde5@localhost> References: <046.4a753e52337d402e72287bba9ddadde5@localhost> Message-ID: <055.6369926f7c10cb8d706f90be70cc0f6b@localhost> #2868: `par` `pseq` does not work as expected ------------------------------------+--------------------------------------- Reporter: hoangta | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.1 Severity: major | Resolution: fixed Keywords: par, pseq, parallel | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD too {{{ Wed Dec 10 08:46:44 PST 2008 Simon Marlow * wake up other Capabilities even when there is only one spark (see #2868) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 12 14:51:15 2008 From: trac at galois.com (GHC) Date: Fri Dec 12 14:44:10 2008 Subject: [GHC] #2863: ghc manual should note FFI non-compliance In-Reply-To: <045.dfae7d7031a0787f381988e11c3bf9e8@localhost> References: <045.dfae7d7031a0787f381988e11c3bf9e8@localhost> Message-ID: <054.1366641f2f1874f83fa6e60d74f97806@localhost> #2863: ghc manual should note FFI non-compliance ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 12 14:51:43 2008 From: trac at galois.com (GHC) Date: Fri Dec 12 14:44:52 2008 Subject: [GHC] #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. In-Reply-To: <045.2e7f92bb3f888287061f94509936d31a@localhost> References: <045.2e7f92bb3f888287061f94509936d31a@localhost> Message-ID: <054.2fb2c10ffafc460f36b4c297aa215a6d@localhost> #2848: threadDelay can wait forever, next time on January 22, 2009, around 20:00 UTC. ---------------------------------------------------------------+------------ Reporter: tomekz | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.10.2 Component: Runtime System | Version: 6.8.1 Severity: critical | Resolution: fixed Keywords: ticks getourtimeofday threadDelay non-threaded | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------------------------+------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 12 15:02:03 2008 From: trac at galois.com (GHC) Date: Fri Dec 12 14:54:55 2008 Subject: [GHC] #2878: panic while compiling Cabal-1.6.0.1 Message-ID: <045.546c16a32de57181a9229bd36cb27ab8@localhost> #2878: panic while compiling Cabal-1.6.0.1 -----------------------------+---------------------------------------------- Reporter: dvogel | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: major Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- While compiling Cabal-1.6.0.1, as packaged with Cabal-0.6.0, I got: [16 of 50] Compiling Distribution.Simple.Utils ( Distribution/Simple/Utils.hs, dist/build/Distribution/Simple/Utils.o ) ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for x86_64-unknown-linux): applyTypeToArgs unix-2.3.0.0:System.Posix.Signals.a38{v rov8} [gid] (unix-2.3.0.0:System.Posix.Signals.a5{v rov7} [gid] `cast` (base:GHC.Prim.sym{(w) tc 34v} (base:Foreign.C.Types.:CoCInt{tc r1dN}) :: base:GHC.Int.Int32{tc 3V} ~ base:Foreign.C.Types.CInt{tc r17X})) unix-2.3.0.0:System.Posix.Signals.Ignore{v rov6} [gid] (base:Data.Maybe.Nothing{v r6E} [gid] @ unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rov5}) eta{v apCg} [lid] (# base:GHC.Prim.State#{(w) tc 32q} base:GHC.Prim.RealWorld{(w) tc 31E}, unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rov5} #) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 12 15:02:22 2008 From: trac at galois.com (GHC) Date: Fri Dec 12 14:55:17 2008 Subject: [GHC] #2878: panic while compiling Cabal-1.6.0.1 In-Reply-To: <045.546c16a32de57181a9229bd36cb27ab8@localhost> References: <045.546c16a32de57181a9229bd36cb27ab8@localhost> Message-ID: <054.150427c7fa8fd4baac364c5d794c3759@localhost> #2878: panic while compiling Cabal-1.6.0.1 ------------------------------+--------------------------------------------- Reporter: dvogel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: major | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86_64 (amd64) ------------------------------+--------------------------------------------- Changes (by dvogel): * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 14 10:52:17 2008 From: trac at galois.com (GHC) Date: Sun Dec 14 10:45:05 2008 Subject: [GHC] #2879: ghci : set - unset Message-ID: <049.d50946bf3230c8feb2683a1944bd9785@localhost> #2879: ghci : set - unset -----------------------------+---------------------------------------------- Reporter: rileyrgdev | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- reading Real World Haskell one of the first "get comfortable" tasks is to modify the Haskell prompt. I would have expected :unset to revert it. But it does not. Prelude Data.Ratio>:unset prompt unknown option: 'prompt' Being new to Haskell I'm not sure if I am wrong, this is a bug or this is a feature request. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 14 13:23:39 2008 From: trac at galois.com (GHC) Date: Sun Dec 14 13:16:26 2008 Subject: [GHC] #2880: GHC panic when printing Unique Message-ID: <043.34b40ae3109ae5a456a6f165b01ff6bc@localhost> #2880: GHC panic when printing Unique -----------------------------+---------------------------------------------- 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 -----------------------------+---------------------------------------------- The following program causes panic: {{{ import UniqSupply main = mkSplitUniqSupply 'x' >>= print . uniqFromSupply }}} The error message is: {{{ ghcbug: ghcbug: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): Static flags have not been initialised! Please call GHC.newSession or GHC.parseStaticFlags early enough. }}} I have encountered this on an Apple !MacBook with GHC 6.10.1 and could reproduce it on a Linux PC with the same GHC version. The module !UniqSupply comes from the ghc package which is hidden by default. So before compiling it (or running it in GHCi) type {{{ ghc-pkg expose ghc }}} in a shell. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 14 20:58:00 2008 From: trac at galois.com (GHC) Date: Sun Dec 14 20:50:46 2008 Subject: [GHC] #2881: Basif Fibonacci function using Word causes ghci to panic. - 6.10.1 Message-ID: <045.420cfc29b1544ee41369697a28301360@localhost> #2881: Basif Fibonacci function using Word causes ghci to panic. - 6.10.1 ---------------------------------+------------------------------------------ Reporter: axman6 | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: panic Word fibonacci | Testcase: Os: Unknown/Multiple | Architecture: x86 ---------------------------------+------------------------------------------ When inputting the function: {{{ let fib :: Word -> Word; fib 0 = 1; fib 1 = 1; fib n = l + r where l = fib (n-2); r = fib (n-1) }}} GHCi produces a panic error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): schemeE(AnnCase).my_discr __word 0 }}} It has been confirmed on both OS X 10.5.5 and linux -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 14 22:10:42 2008 From: trac at galois.com (GHC) Date: Sun Dec 14 22:03:29 2008 Subject: [GHC] #2881: Basic Fibonacci function using Word causes ghci to panic. - 6.10.1 In-Reply-To: <045.420cfc29b1544ee41369697a28301360@localhost> References: <045.420cfc29b1544ee41369697a28301360@localhost> Message-ID: <054.567ca3c3ad3bc4e0ff52a42f98b5419c@localhost> #2881: Basic Fibonacci function using Word causes ghci to panic. - 6.10.1 ----------------------------------+----------------------------------------- Reporter: axman6 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: panic Word fibonacci | Testcase: Os: Unknown/Multiple | Architecture: x86 ----------------------------------+----------------------------------------- Changes (by axman6): * summary: Basif Fibonacci function using Word causes ghci to panic. - 6.10.1 => Basic Fibonacci function using Word causes ghci to panic. - 6.10.1 Comment: from #ghc: {{{ 14:02 < mmorrow> weird: 14:02 < mmorrow> ghci> case undefined of (0::Word) -> undefined 14:02 < mmorrow> panics 14:02 < mmorrow> but 14:02 < mmorrow> ghci> case undefined of (0::Word32) -> undefined 14:02 < mmorrow> *** Exception: Prelude.undefined 14:02 < mmorrow> (and Word{8,16,32,64} all work) 14:03 < mmorrow> this works too 14:03 < mmorrow> case (0::Word) of _ -> undefined [and] 14:03 < mmorrow> case (0::Word) of 0 -> undefined 14:05 < mmorrow> ghci> case 0 of (0::Word) -> undefined 14:05 < mmorrow> *** Exception: Prelude.undefined 14:05 < mmorrow> ghci> case undefined of (0::Word) -> undefined 14:05 < mmorrow> ghc: panic! (the 'impossible' happened)... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 14 22:11:39 2008 From: trac at galois.com (GHC) Date: Sun Dec 14 22:04:26 2008 Subject: [GHC] #2881: Basic Fibonacci function using Word causes ghci to panic. - 6.10.1 In-Reply-To: <045.420cfc29b1544ee41369697a28301360@localhost> References: <045.420cfc29b1544ee41369697a28301360@localhost> Message-ID: <054.83b0dda7554f9b6444ded196b1d35696@localhost> #2881: Basic Fibonacci function using Word causes ghci to panic. - 6.10.1 ----------------------------------+----------------------------------------- Reporter: axman6 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: panic Word fibonacci | Testcase: Os: Unknown/Multiple | Architecture: x86 ----------------------------------+----------------------------------------- Comment (by axman6): The full error message from the previous comment: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): schemeE(AnnCase).my_discr __word 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 15 07:31:02 2008 From: trac at galois.com (GHC) Date: Mon Dec 15 07:23:54 2008 Subject: [GHC] #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug In-Reply-To: <045.8041176773063583641ec33524fcf0dd@localhost> References: <045.8041176773063583641ec33524fcf0dd@localhost> Message-ID: <054.2a174565d45ba92785acf32ea91222d9@localhost> #2864: ghc: panic! (the 'impossible' happened) -- Please report this as a GHC bug -------------------------+-------------------------------------------------- Reporter: megacz | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Worked around this bug for now: {{{ Mon Dec 15 02:02:21 PST 2008 Simon Marlow * Revert CorePrep part of "Completely new treatment of INLINE pragmas..." The original patch said: * I made some changes to the way in which eta expansion happens in CorePrep, mainly to ensure that *arguments* that become let-bound are also eta-expanded. I'm still not too happy with the clarity and robustness fo the result. Unfortunately this change apparently broke some invariants that were relied on elsewhere, and in particular lead to panics when compiling with profiling on. Will re-investigate in the new year. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 15 07:31:53 2008 From: trac at galois.com (GHC) Date: Mon Dec 15 07:24:38 2008 Subject: [GHC] #2862: GHC Panic in ByteCodeGen In-Reply-To: <047.13dee4cada75e20f59aa08e4590d7cec@localhost> References: <047.13dee4cada75e20f59aa08e4590d7cec@localhost> Message-ID: <056.19836c6ce2e641ba382dd71f009e1ac1@localhost> #2862: GHC Panic in ByteCodeGen ---------------------------------+------------------------------------------ Reporter: nominolo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: It works after this partial reversion: {{{ Mon Dec 15 02:02:21 PST 2008 Simon Marlow * Revert CorePrep part of "Completely new treatment of INLINE pragmas..." The original patch said: * I made some changes to the way in which eta expansion happens in CorePrep, mainly to ensure that *arguments* that become let-bound are also eta-expanded. I'm still not too happy with the clarity and robustness fo the result. Unfortunately this change apparently broke some invariants that were relied on elsewhere, and in particular lead to panics when compiling with profiling on. Will re-investigate in the new year. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 15 11:26:07 2008 From: trac at galois.com (GHC) Date: Mon Dec 15 11:18:51 2008 Subject: [GHC] #2882: variable escaping in existential type error on 6.8 but not 6.10 Message-ID: <044.8b6f5cfd150ae2e517d1a35ff8e144b1@localhost> #2882: variable escaping in existential type error on 6.8 but not 6.10 -----------------------------+---------------------------------------------- Reporter: ckeen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 -----------------------------+---------------------------------------------- I wrote a patch for darcs that does the following: {{{ 'l' -> do let selected = case get_choices pc of (first_chs:>_:>last_chs) -> if whichch == Last || whichch == FirstReversed then last_chs else first_chs putStrLn $ "---- Already selected "++things++" ----" mapM_ putDocLn $ mapFL (\a -> showPatch `unseal2` (seal2 $ tp_patch a)) selected }}} where {{{ get_choices :: Patchy p => PatchChoices p C(x y) -> (FL (TaggedPatch p) :> FL (TaggedPatch p) :> FL (TaggedPatch p)) C(x y) data (a1 :> a2) C(x y) = FORALL(z) (a1 C(x z)) :> (a2 C(z y)) data FL a C(x z) where (:>:) :: a C(x y) -> FL a C(y z) -> FL a C(x z) NilFL :: FL a C(x x) }}} This gives an error with ghc-6.8.2 on Mac OS X (others have reported errors with 6.8.3 as well): {{{ Inferred type is less polymorphic than expected Quantified type variable `z2' escapes When checking an existential match that binds first_chs :: FL (TaggedPatch p) x z1 last_chs :: FL (TaggedPatch p) z2 z The pattern(s) have type(s): (:>) (FL (TaggedPatch p)) (FL (TaggedPatch p) :> FL (TaggedPatch p)) x z The body has type: FL (TaggedPatch p) z2 z In a case alternative: (first_chs :> _ :> last_chs) -> if whichch == Last || whichch == FirstReversed then last_chs else first_chs In the expression: case get_choices pc of (first_chs :> _ :> last_chs) -> if whichch == Last || whichch == FirstReversed then last_chs else first_chs }}} I have been convinced that this is indeed a programming error by the fine people on #ghc. So the remaining question is: Why does it work on ghc-6.10.1? I will try if I can construct a simpler test case. Thanks, Christian -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 15 11:36:58 2008 From: trac at galois.com (GHC) Date: Mon Dec 15 11:29:41 2008 Subject: [GHC] #2882: variable escaping in existential type error on 6.8 but not 6.10 In-Reply-To: <044.8b6f5cfd150ae2e517d1a35ff8e144b1@localhost> References: <044.8b6f5cfd150ae2e517d1a35ff8e144b1@localhost> Message-ID: <053.497fd2e2064f22be18525d8b7670f830@localhost> #2882: variable escaping in existential type error on 6.8 but not 6.10 ------------------------------+--------------------------------------------- Reporter: ckeen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 ------------------------------+--------------------------------------------- Changes (by ckeen): * status: new => closed * resolution: => invalid Comment: actually this has been identified as a user error. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 15 20:57:43 2008 From: trac at galois.com (GHC) Date: Mon Dec 15 20:50:50 2008 Subject: [GHC] #2883: setitimer(ITIMER_VIRTUAL) is not always available Message-ID: <047.b40f4ae8b455c2e4eb614a1510a0781b@localhost> #2883: setitimer(ITIMER_VIRTUAL) is not always available -----------------------------+---------------------------------------------- Reporter: sthibaul | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- On some limited systems, setitimer(ITIMER_VIRTUAL) returns ENOSYS because the kernel does not provide a way to schedule timers based on virtual time. In such a case, rts/posix/Itimer.c should use ITIMER_REAL. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 15 22:33:33 2008 From: trac at galois.com (GHC) Date: Mon Dec 15 22:26:15 2008 Subject: [GHC] #2884: Compiled code performance worsens when module names are long enough Message-ID: <049.881bd6a7c8430691cda844d87df64824@localhost> #2884: Compiled code performance worsens when module names are long enough -----------------------------+---------------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Attached to this report is an example where by simply renaming a module, performance degrades 2.5 times. {{{ #diff long-modname-ver.hs short-modname-ver.hs 2c2 < import VeryLongModuleName --- > import ShortM #diff VeryLongModuleName.hs ShortM.hs 1c1 < module VeryLongModuleName --- > module ShortM #ghc --make -O2 -Wall long-modname-ver.hs #ghc --make -O2 -Wall short-modname-ver.hs #time -p ./long-modname-ver > /dev/null real 55.90 user 55.17 sys 0.51 #time -p ./short-modname-ver > /dev/null real 22.23 user 21.97 sys 0.10 }}} According to some measures by dons, the threshold seems to be at module length 10 (see attached graph). Some further disussion on this thread [http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/16037]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 15 22:49:22 2008 From: trac at galois.com (GHC) Date: Mon Dec 15 22:42:04 2008 Subject: [GHC] #2885: Late and confusing error on uncallable class method Message-ID: <047.ce20e9ec9214d3f798b1054ab8be4dea@localhost> #2885: Late and confusing error on uncallable class method ---------------------+------------------------------------------------------ Reporter: blamario | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ---------------------+------------------------------------------------------ This has been discussed on Haskell Caf? (http://www.haskell.org/pipermail /haskell-cafe/2008-December/051856.html), I'm reporting it here in case something can be done to help other confused souls in future. In short, the error message reported by GHC (6.10.1): {{{ Could not deduce (Container x y) from the context (Container x y1) arising from a use of `wrapper' at Test.hs:11:22-30 Possible fix: add (Container x y) to the context of the type signature for `liftWrap' In the expression: wrapper x In the expression: (if wrapper x then rewrap . f . unwrap else id) x In the definition of `liftWrap': liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x }}} does not begin to indicate that the actual problem with the following program is in the type class declaration: {{{ {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances #-} import Data.Maybe class Container x y where wrapper :: x -> Bool unwrap :: x -> y rewrap :: y -> x liftWrap :: Container x y => (y -> y) -> (x -> x) liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x instance Container (Maybe x) x where wrapper = isJust unwrap = fromJust rewrap = Just main = print (liftWrap (succ :: Int -> Int) (Just 1 :: Maybe Int)) }}} If the 'wrapper' method can never be called in any possible context, there should be an error report at the point where the method is declared. I don't think that's a controversial statement. Even if the compiler allows the declaration under the assumption that the useless method is never called, it should at least emit a strong warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 16 03:45:13 2008 From: trac at galois.com (GHC) Date: Tue Dec 16 03:37:57 2008 Subject: [GHC] #2886: Haddock documentation missing for haskell98 Message-ID: <051.7be3a445a4dfe9c51a6be3318abe3d2c@localhost> #2886: Haddock documentation missing for haskell98 -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The random library is empty: http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98/Random.html As is Ratio: http://www.haskell.org/ghc/docs/latest/html/libraries/haskell98/Ratio.html These issues were reported on the haskell@ list by Ron Legere -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 16 04:48:35 2008 From: trac at galois.com (GHC) Date: Tue Dec 16 04:41:17 2008 Subject: [GHC] #2884: Compiled code performance worsens when module names are long enough In-Reply-To: <049.881bd6a7c8430691cda844d87df64824@localhost> References: <049.881bd6a7c8430691cda844d87df64824@localhost> Message-ID: <058.2689e6f7b67df295e34177f3034e254d@localhost> #2884: Compiled code performance worsens when module names are long enough -----------------------------------------+---------------------------------- Reporter: jcpetruzza | 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: I think this is another example that we can trace back to optimisation problems with record selectors. If we look at the Core for `nodeFor`: {{{ VeryLongModuleName.nodeFor :: GHC.Types.Int -> VeryLongModuleName.T -> VeryLongModuleName.T [GlobalId] [Arity 2 Str: DmdType LS] VeryLongModuleName.nodeFor = \ (ds_dhX :: GHC.Types.Int) (ds1_dhY :: VeryLongModuleName.T) -> case ds1_dhY of wild_B1 { VeryLongModuleName.Nil -> VeryLongModuleName.Nil; VeryLongModuleName.Node ipv_ski ipv1_skj ipv2_skk ipv3_skl -> case ds_dhX of wild1_alg { GHC.Types.I# x#_ali -> case VeryLongModuleName.val wild_B1 of wild11_alk { GHC.Types.I# y#_alm -> case GHC.Prim.<# x#_ali y#_alm of wild2_alq { GHC.Bool.False -> case GHC.Prim.==# x#_ali y#_alm of wild12_alt { GHC.Bool.False -> VeryLongModuleName.right wild_B1; GHC.Bool.True -> wild_B1 }; GHC.Bool.True -> VeryLongModuleName.left wild_B1 } } } } }}} The record selector `VeryLongModuleName.val` has not been inlined, whereas in the `ShortM` version it has: {{{ ShortM.nodeFor :: GHC.Types.Int -> ShortM.T -> ShortM.T [GlobalId] [Arity 2 NoCafRefs Str: DmdType LS] ShortM.nodeFor = \ (ds_di1 :: GHC.Types.Int) (ds1_di2 :: ShortM.T) -> case ds1_di2 of wild_B1 { ShortM.Nil -> ShortM.Nil; ShortM.Node ipv_skm ipv1_skn ipv2_sko ipv3_skp -> case ds_di1 of wild1_alk { GHC.Types.I# x#_alm -> case GHC.Prim.<# x#_alm ipv_skm of wild2_alu { GHC.Bool.False -> case GHC.Prim.==# x#_alm ipv_skm of wild11_alx { GHC.Bool.False -> ipv2_sko; GHC.Bool.True -> wild_B1 }; GHC.Bool.True -> ipv1_skn } } } }}} This is almost certainly because the length of the error string pushes the definition of `val` just over the size limit for inlining (in this case the error string will disappear after inlining, but the inliner isn't clever enough to know this). What's more, this wouldn't be a problem if the inliner was using the optimised definition of the record selector, in which the error string had been pulled out to the top level. We've encountered a few cases like this recently - I sent one to Simon a few weeks ago (I don't think I ticketed it, though). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 16 04:52:36 2008 From: trac at galois.com (GHC) Date: Tue Dec 16 04:45:19 2008 Subject: [GHC] #2884: Compiled code performance worsens when module names are long enough In-Reply-To: <049.881bd6a7c8430691cda844d87df64824@localhost> References: <049.881bd6a7c8430691cda844d87df64824@localhost> Message-ID: <058.65734efeb3e473c27b9d3cdccb3705f6@localhost> #2884: Compiled code performance worsens when module names are long enough -----------------------------------------+---------------------------------- Reporter: jcpetruzza | 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 simonmar): Oh, and I should say that the effect is so extreme in this case because the same problem applies to all instances of all 4 record selectors for the `T` type. The program will be doing a lot of repeated evaluations at runtime. You could probably work around it by defining your own record selectors instead of using the automatically generated ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 16 10:32:18 2008 From: trac at galois.com (GHC) Date: Tue Dec 16 10:25:01 2008 Subject: [GHC] #2886: Haddock documentation missing for haskell98 In-Reply-To: <051.7be3a445a4dfe9c51a6be3318abe3d2c@localhost> References: <051.7be3a445a4dfe9c51a6be3318abe3d2c@localhost> Message-ID: <060.83f99bffdd50ef28d8824a6afa29d5d6@localhost> #2886: Haddock documentation missing for haskell98 ------------------------------+--------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: duplicate Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by NeilMitchell): * status: new => closed * resolution: => duplicate Comment: Dupe of #2746 (I did search before report this issue, but the search is fairly useless!) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 17 05:18:14 2008 From: trac at galois.com (GHC) Date: Wed Dec 17 05:10:52 2008 Subject: [GHC] #2880: GHC panic when printing Unique In-Reply-To: <043.34b40ae3109ae5a456a6f165b01ff6bc@localhost> References: <043.34b40ae3109ae5a456a6f165b01ff6bc@localhost> Message-ID: <052.18eb1fb63ab903dc33e53edc4511f0f2@localhost> #2880: GHC panic when printing Unique ------------------------------+--------------------------------------------- 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 batterseapower): I don't think this is actually a bug. Printing a Unique actually does require access to the static flags, so you need to initialize them as the panic suggests. The relevant code is in Unique.lhs: {{{ pprUnique :: Unique -> SDoc pprUnique uniq | opt_SuppressUniques = empty -- Used exclusively to suppress uniques so you | otherwise -- can compare output easily = case unpkUnique uniq of (tag, u) -> finish_ppr tag u (text (iToBase62 u)) }}} Note the use of opt_SuppressUniques, a static flag, which pulls on the staticFlags thunk and hence causes the panic. I'm not sure we actually intend UniqSupply et al. to be used outside the context of GHC session, so this behaviour does not surprise me... You can probably fix it by doing: {{{ import UniqSupply import StaticFlagParser (parseStaticFlags) main = do parseStaticFlags [] mkSplitUniqSupply 'x' >>= print . uniqFromSupply }}} This will most likely continue to work in the future, but there are no guarantees :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 17 05:41:38 2008 From: trac at galois.com (GHC) Date: Wed Dec 17 05:34:15 2008 Subject: [GHC] #2880: GHC panic when printing Unique In-Reply-To: <043.34b40ae3109ae5a456a6f165b01ff6bc@localhost> References: <043.34b40ae3109ae5a456a6f165b01ff6bc@localhost> Message-ID: <052.9747637309c4aa878007c676565f5209@localhost> #2880: GHC panic when printing Unique ------------------------------+--------------------------------------------- Reporter: sebf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by sebf): * status: new => closed * resolution: => fixed Comment: Thank you for the clarifications! I have not been aware that using UniqSupply requires any additional initialization and thought the message referred to something that is usually done but forgotten. What would be the preferred thing to do, when writing a library that needs unique identifiers? Reimplement them, put them on Hackage/github and hope that GHC experts find the time to optimize them like their own? A package on Hackage that can be used by ghc *and* other libraries seems preferable. But I don't know how easy or difficult it is to factor out uniques from ghc... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 17 05:59:18 2008 From: trac at galois.com (GHC) Date: Wed Dec 17 05:51:55 2008 Subject: [GHC] #2880: GHC panic when printing Unique In-Reply-To: <043.34b40ae3109ae5a456a6f165b01ff6bc@localhost> References: <043.34b40ae3109ae5a456a6f165b01ff6bc@localhost> Message-ID: <052.e2fbbbd07e586220bcf607eb964943cf@localhost> #2880: GHC panic when printing Unique ------------------------------+--------------------------------------------- Reporter: sebf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by batterseapower): Factoring out Uniques would be /fairly/ straightforward - I think the only surprising dependency of Uniques comes from that use of the static flag, which is only used when printing them. This is easily avoided by defining a new Show instance that does not use pprUnique. However, I'm not sure we want GHC to have another dependency (and hence boot package), so we would probably not depend on that package ourselves - but you are welcome to copy the code :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 17 12:18:42 2008 From: trac at galois.com (GHC) Date: Wed Dec 17 12:11:18 2008 Subject: [GHC] #2887: Segfault while configuring Cabal 1.6.0.1 on OS X 10.5 Message-ID: <042.ed7dbc0df59c928988eada06283bfab4@localhost> #2887: Segfault while configuring Cabal 1.6.0.1 on OS X 10.5 --------------------+------------------------------------------------------- Reporter: ozy | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: powerpc --------------------+------------------------------------------------------- An unknown issue prevents Cabal from being built successfully on PPC Macs. I've tried compiling GHC from source with no change in the behavior. The following output is from Cabal's included Setup program, run inside GDB: {{{ (gdb) run configure --user +RTS -DSs Starting program: [...]/Cabal-1.6.0.1/Setup configure --user +RTS -DSs Reading symbols for shared libraries +++. done new task (taskCount: 1) task exiting new task (taskCount: 1) created thread 1, stack size = f1 words new bound thread (1) ### NEW SCHEDULER LOOP (task: 0x7005a0, cap: 0x3e7d98) -->> running thread 1 ThreadRunGHC ... --<< thread 1 (ThreadRunGHC) stopped, StackOverflow increasing stack size from 241 words to 1009. -->> running thread 1 ThreadRunGHC ... thread 1 did a safe foreign call thread 1: re-entering RTS --<< thread 1 (ThreadRunGHC) stopped, yielding -->> running thread 1 ThreadRunGHC ... --<< thread 1 (ThreadRunGHC) stopped, yielding -->> running thread 1 ThreadRunGHC ... --<< thread 1 (ThreadRunGHC) stopped, yielding -->> running thread 1 ThreadRunGHC ... --<< thread 1 (ThreadRunGHC) stopped, yielding -->> running thread 1 ThreadRunGHC ... thread 1 did a safe foreign call thread 1: re-entering RTS --<< thread 1 (ThreadRunGHC) stopped, yielding -->> running thread 1 ThreadRunGHC ... --<< thread 1 (ThreadRunGHC) stopped: HeapOverflow all threads: threads on capability 0: thread 1 @ 0x97d000 is not blocked other threads: Setup: internal error: ASSERTION FAILED: file Sanity.c, line 241 (GHC version 6.10.1 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. 0x94e29af0 in __kill () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 17 13:01:19 2008 From: trac at galois.com (GHC) Date: Wed Dec 17 12:53:57 2008 Subject: [GHC] #2888: Source file that compiled fine no longer compiles after touching it. Message-ID: <045.7d892b7ba37ca77835fa69178fb9751e@localhost> #2888: Source file that compiled fine no longer compiles after touching it. -----------------------------+---------------------------------------------- Reporter: Eelis- | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- In the following session, {{{t.hs}}} first compiles fine, then after being touched, no longer does: {{{ eelis ~/sand : cat M.hs {-# LANGUAGE TypeFamilies #-} module M where class C a where data D :: * -> * eelis ~/sand : cat t.hs {-# LANGUAGE TypeFamilies #-} import M data Bla = Bla instance C Bla where data D a = D main = return () eelis ~/sand : ghc --make t.hs [1 of 2] Compiling M ( M.hs, M.o ) [2 of 2] Compiling Main ( t.hs, t.o ) Linking t ... eelis ~/sand : touch t.hs eelis ~/sand : ghc --make t.hs [2 of 2] Compiling Main ( t.hs, t.o ) t.hs:4:21: Type indexes must match class instance head Found a but expected Bla In the associated type instance for `D' In the instance declaration for `C Bla' }}} It seems to me that {{{t.hs}}} should either compile both times, or not compile at all, but not only part of the time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 17 13:05:50 2008 From: trac at galois.com (GHC) Date: Wed Dec 17 12:58:35 2008 Subject: [GHC] #2887: Segfault while configuring Cabal 1.6.0.1 on OS X 10.5 In-Reply-To: <042.ed7dbc0df59c928988eada06283bfab4@localhost> References: <042.ed7dbc0df59c928988eada06283bfab4@localhost> Message-ID: <051.83b66c1e958b5d2cf30739b682b467e9@localhost> #2887: Segfault while configuring Cabal 1.6.0.1 on OS X 10.5 ----------------------+----------------------------------------------------- Reporter: ozy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: powerpc ----------------------+----------------------------------------------------- Comment (by maeder): I have no problem. Cabal-1.6.0.1 is part of the http://www.haskell.org/ghc/dist/6.10.1/maeder/ghc-6.10.1-powerpc-apple- darwin.tar.bz2 (that also runs on PPC Leopard) "+RTS -DSs" is not supported by the Setup file created with "ghc --make Setup.hs" (compiling 50 modules). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 17 13:24:06 2008 From: trac at galois.com (GHC) Date: Wed Dec 17 13:16:48 2008 Subject: [GHC] #1364: Finalizers not guaranteed to run before the program exits In-Reply-To: <059.db0f5b638555483a7832474f38ff8320@localhost> References: <059.db0f5b638555483a7832474f38ff8320@localhost> Message-ID: <068.1c5b4d0e206f076b5e1a1383531bac68@localhost> #1364: Finalizers not guaranteed to run before the program exits -------------------------------------+-------------------------------------- Reporter: tomac@pacific.net.au | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Runtime 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: Both merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 17 14:48:09 2008 From: trac at galois.com (GHC) Date: Wed Dec 17 14:40:49 2008 Subject: [GHC] #2592: Can't profile when the heap maximum is hit In-Reply-To: <046.6ff10d2040e94a9b4e4cc6a778189212@localhost> References: <046.6ff10d2040e94a9b4e4cc6a778189212@localhost> Message-ID: <055.95fe4e3ecb8e000ea8036ddd1d066d0d@localhost> #2592: Can't profile when the heap maximum is hit ---------------------------------+------------------------------------------ Reporter: adekoba | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Profiling | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: profile, heap | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged, -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 17 16:49:21 2008 From: trac at galois.com (GHC) Date: Wed Dec 17 16:42:05 2008 Subject: [GHC] #2838: -fasm codeGen doesn't truncate CMMInt's at the right place In-Reply-To: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> References: <053.7420cc78a99b2590a5d679c7953f1b9f@localhost> Message-ID: <062.1ffcb421648e95a716ddd121407b57bd@localhost> #2838: -fasm codeGen doesn't truncate CMMInt's at the right place ---------------------------------+------------------------------------------ Reporter: TristanAllwood | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 17 18:16:29 2008 From: trac at galois.com (GHC) Date: Wed Dec 17 18:09:05 2008 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic In-Reply-To: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> References: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> Message-ID: <055.aba8aa75d79864c0f722177d8caa5958@localhost> #2808: createDirectoryIfMissing should be atomic ------------------------------------+--------------------------------------- Reporter: EricKow | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 18 07:29:25 2008 From: trac at galois.com (GHC) Date: Thu Dec 18 07:22:00 2008 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic In-Reply-To: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> References: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> Message-ID: <055.9631131f36ac6aa6707390f4fe99a893@localhost> #2808: createDirectoryIfMissing should be atomic ------------------------------------+--------------------------------------- Reporter: EricKow | Owner: igloo Type: merge | Status: reopened Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by duncan): * status: closed => reopened * resolution: fixed => Comment: There are a few question marks with the new code: The code is now race-free but the error codes are not accurate. `createDirectoryIfMissing True "foo"` will succeed if a file `foo` exists. It is not entirely clear that it guarantees not to recurse infinitely. The termination condition relies on `dropFileName . dropTrailingPathSeparator` making the path shorter, on some base directory existing or being created or on an exception other than `isDoesNotExistError` being generated by `createDirectory`. It could create the same directory again and again if some other thread or process deleted the directories it had already created. There is the danger of it getting into a fight with another process doing `rm -r` in a dir where `createDirectoryIfMissing` is creating dirs. A fix for the third issue would be to change the second `createDirectoryIfMissing` call to use `False`. Here is an alternative implementation for review. I think it addresses the three points above. {{{ import System.Directory (createDirectory, doesDirectoryExist) import System.FilePath import System.IO.Error hiding (try) import Control.Exception createDirectoryIfMissing :: Bool -> FilePath -> IO () createDirectoryIfMissing _ "" = return () createDirectoryIfMissing create_parents dir0 | create_parents = createDirs (parents dir0) | otherwise = createDir dir0 throw where parents = reverse . scanl1 (++) . splitPath . normalise createDirs [] = return () createDirs (dir:dirs) = createDir dir $ \_ -> do createDirs dirs createDir dir throw createDir :: FilePath -> (IOException -> IO ()) -> IO () createDir dir notExistHandler = do r <- try $ createDirectory dir case (r :: Either IOException ()) of Right () -> return () Left e | isDoesNotExistError e -> notExistHandler e -- createDirectory (and indeed POSIX mkdir) does not distinguish -- between a dir already existing and a file already existing. So we -- check for it here. Unfortunately there is a slight race condition -- here, but we think it is benign. It could report an exeption in -- the case that the dir did exist but another process deletes it -- before we can check that it did indeed exist. | isAlreadyExistsError e -> do exists <- doesDirectoryExist dir if exists then return () else throw e | otherwise -> throw e }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 18 09:55:38 2008 From: trac at galois.com (GHC) Date: Thu Dec 18 09:48:12 2008 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic In-Reply-To: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> References: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> Message-ID: <055.2018e4f9e2440c910ab4f251143e9b0a@localhost> #2808: createDirectoryIfMissing should be atomic ------------------------------------+--------------------------------------- Reporter: EricKow | Owner: igloo Type: merge | Status: reopened Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Comment (by duncan): Updated to address Simon's comments and to handle the two `create_parents` cases in a more similar way, especially when it comes to trailing directory separators. Ignoring comments it looks like: {{{ createDirectoryIfMissing create_parents path0 | create_parents = createDirs (parents path0) | otherwise = createDirs (take 1 (parents path0)) where parents = reverse . scanl1 () . splitDirectories . normalise createDirs [] = return () createDirs (dir:[]) = createDir dir throw createDirs (dir:dirs) = createDir dir $ \_ -> do createDirs dirs createDir dir throw createDir :: FilePath -> (IOException -> IO ()) -> IO () createDir dir notExistHandler = do r <- try $ createDirectory dir case (r :: Either IOException ()) of Right () -> return () Left e | isDoesNotExistError e -> notExistHandler e | isAlreadyExistsError e -> do exists <- doesDirectoryExist dir if exists then return () else throw e | otherwise -> throw e }}} There are two changes, one is to use `scanl1 () . splitDirectories` instead of `scanl1 (++) . splitPath`. The other is to add a clause: {{{ createDirs (dir:[]) = createDir dir throw }}} So that we do not attempt to create the last dir twice. When it fails there's not more parent dirs to try so it's a hard failure. That also means we can use `createDirs` in the `not create_parents` case. We don't just pass `head (parents path0)` because it will be empty when `path0 == ""`. Using `take 1` covers both cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 18 16:57:20 2008 From: trac at galois.com (GHC) Date: Thu Dec 18 16:49:54 2008 Subject: [GHC] #2889: Compilation fails - Can't opne temporary Message-ID: <046.8fe469503d4d0471dd07d5bc59e9501a@localhost> #2889: Compilation fails - Can't opne temporary --------------------+------------------------------------------------------- Reporter: fobrock | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- When compiling (either a .hs or linking .o's), the following error is reported and the .exe is not created: C:\PROGRA~1\GHC\bin/windres: can't open temporary file `\/cca02256.irc': Invalid argument Although it does not seem to be a disk space problme ("Invalid argument"), I tried -tmpdir and the error was still reported. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 19 06:21:29 2008 From: trac at galois.com (GHC) Date: Fri Dec 19 06:14:00 2008 Subject: [GHC] #2002: problems with very large (list) literals In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> Message-ID: <060.580fec688e6a2822f66dc22a9f328d3a@localhost> #2002: problems with very large (list) literals ---------------------------------------------+------------------------------ Reporter: Isaac Dupree | Owner: simonmar Type: compile-time performance bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------+------------------------------ Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: Tested today with GHC HEAD. Compiling a 100k-element [Int] list takes just less than a minute with -O0, and needs up to 200M stack (I'll bump the default max stack size for GHC). The profile looks like this: {{{ SimplTopBinds SimplCore 44.9 27.5 NativeCodeGen CodeOutput 13.7 12.4 CoreTidy HscMain 9.6 8.2 CorePrep HscMain 8.1 5.1 CodeGen HscMain 7.5 12.7 pprNativeCode AsmCodeGen 4.4 11.3 }}} The object file was 22M, but I don't see any obvious ways to reduce that significantly - most of that size is the symbols. There is one word per static `(:)` that we could eliminate by generating a special version of the `(:)` info table with CONSTR_STATIC_NOCAF; I'm not sure whether that's worthwhile in general. GHC needed 2.2G on this machine (x86_64/Linux). Bottom line: there's nothing obviously bad here. The time and memory requirements increase roughly linearly with the length of the list, although we should bump the default max stack size. The simplifier is the obvious place to look to start optimising. I didn't try compiling with -O, but I'm not at all surprised if it takes a lot longer - don't do that! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 19 06:25:04 2008 From: trac at galois.com (GHC) Date: Fri Dec 19 06:17:35 2008 Subject: [GHC] #2890: Library docs are missing source links Message-ID: <047.5d9f8bb2c0907720ec70f2f23485d487@localhost> #2890: Library docs are missing source links -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Our library docs used to have links to HsColoured source code - what happened to them? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 19 06:25:14 2008 From: trac at galois.com (GHC) Date: Fri Dec 19 06:17:46 2008 Subject: [GHC] #2890: Library docs are missing source links In-Reply-To: <047.5d9f8bb2c0907720ec70f2f23485d487@localhost> References: <047.5d9f8bb2c0907720ec70f2f23485d487@localhost> Message-ID: <056.6150662850c24a3cea23cca606e09261@localhost> #2890: Library docs are missing source links ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Old description: > Our library docs used to have links to HsColoured source code - what > happened to them? New description: Our library docs used to have links to !HsColoured source code - what happened to them? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 19 09:44:10 2008 From: trac at galois.com (GHC) Date: Fri Dec 19 09:36:42 2008 Subject: [GHC] #2858: Segmentation fault due to race between IO manager and installSignals. In-Reply-To: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> References: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> Message-ID: <051.e071075a7b8c51294b3ae2b5afecc041@localhost> #2858: Segmentation fault due to race between IO manager and installSignals. ------------------------------------------------+--------------------------- Reporter: dsh | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: posix signal threaded IOmanager | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Comment (by simonmar): Sorry, I can't reproduce the problem. I run `Test.hs` over and over again in one window, and run `killall -TERM Test` over and over (in a while loop) in another window, and so far no core dumps. Is there something I'm missing? In any case I think a fix for this will probably have to wait until I've finished the signal overhaul (so 6.12), unless the fix is easy. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 19 13:25:36 2008 From: trac at galois.com (GHC) Date: Fri Dec 19 13:18:09 2008 Subject: [GHC] #2002: problems with very large (list) literals In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> Message-ID: <060.8e1e5dc3c12e4e0a3ba192dca7c6db66@localhost> #2002: problems with very large (list) literals ---------------------------------------------+------------------------------ Reporter: Isaac Dupree | Owner: simonmar Type: compile-time performance bug | Status: closed Priority: high | Milestone: 6.10.2 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------------------------+------------------------------ Comment (by guest): re: your last two paragraphs. I'd like to be able to compile with -O for the sake of the other parts of the module. Maybe GHC can detect when there's a large literal that it shouldn't try to optimize with? Or maybe a code writer could annotate it with NOINLINE or some other pragma that tells GHC not to try to waste time optimizing it? (perhaps as if it were in a separate module that were compiled with -O0... Actually putting it in a separate module would be an especial nuisance for a tool like Alex to generate). But I guess I don't have an urgent problem here. -Isaac Dupree -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 19 15:05:45 2008 From: trac at galois.com (GHC) Date: Fri Dec 19 14:58:15 2008 Subject: [GHC] #2891: threadDelay appears to use excessive CPU in GHCi Message-ID: <049.e486b1f0b04e32b03f5954cc3c1db385@localhost> #2891: threadDelay appears to use excessive CPU in GHCi -----------------------+---------------------------------------------------- Reporter: JeremyShaw | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -----------------------+---------------------------------------------------- I have the following simple program: import Control.Concurrent main = threadDelay (10^6) >> main If I run it in GHCi it requires 2-5% of my CPU. If i compile it, it takes 0% of my CPU. It does not matter if I compile -O0, -O2, -threaded, it always uses 0% (which is good). I have only tested this under Linux (Ubuntu Hardy) and GHC 6.8.3 on one machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 19 18:26:06 2008 From: trac at galois.com (GHC) Date: Fri Dec 19 18:18:37 2008 Subject: [GHC] #2858: Segmentation fault due to race between IO manager and installSignals. In-Reply-To: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> References: <042.66eb6ec18a38c005a97f785a4f8debb7@localhost> Message-ID: <051.a1fb74b1487765fb52327e920673ea48@localhost> #2858: Segmentation fault due to race between IO manager and installSignals. ------------------------------------------------+--------------------------- Reporter: dsh | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: libraries/base | Version: 6.10.1 Severity: normal | Resolution: Keywords: posix signal threaded IOmanager | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Comment (by dsh): I see, I got them infrequently too..[[BR]] For me the problem looks like[[BR]] 1. There could be 2 commands (I mean bytes) in IO manager pipe for the same signal, received when the handler was user defined; [[BR]] 2. Then IO manager scheduled the handler (executed first command), which invalidated 'signal_handlers' table (replacing StablePtr with special constant STG_SIG_DFL)[[BR]] 3. It is incorrect for IO manager to schedule process the second command using 'signal_handlers' table.[[BR]] Quick fix would be always to check the 'signal_handlers' table entry in IO manager.[[BR]] It would not be worse than ignoring signals after space overflow in non- threaded version[[BR]] Dmitry[[BR]] P.S. Could you try random small delays? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 20 12:42:20 2008 From: trac at galois.com (GHC) Date: Sat Dec 20 12:34:49 2008 Subject: [GHC] #2316: Add Applicative instances for all MTL Monads In-Reply-To: <047.6c77bc0cfe5b195806e995b0a81d8474@localhost> References: <047.6c77bc0cfe5b195806e995b0a81d8474@localhost> Message-ID: <056.4da0d8fd2405613b854122fcc79f56c7@localhost> #2316: Add Applicative instances for all MTL Monads ----------------------------------+----------------------------------------- Reporter: sjanssen | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by basvandijk): Without checking for similar proposals I also made a patch that adds Applicative and Alternative instances for all types in mtl. Next time I will look and save me the work. == Differences == There are differences however, between the original and my patch. * I don't write `pure` and `<*>` in terms of `return` and `ap`. Instead I define them directly. Maybe this is a bit more efficient. * I try not to require Monad as a superclass for the Applicative instances for all the transformer types. This also means that some Functor instances now have an Applicative instead of a Monad constraint. I don't know if this is really important but I found it clearer and more flexible. == Summary of my changes == Here's a summary of my changes: * Cont * Added `instance Applicative (Cont r)` * Replaced: `instance (Monad m) => Functor (ContT r m)` with: `instance Functor (ContT r m)` * Added `instance Applicative m => Applicative (ContT r m)` * Error * Added: `instance Applicative (Either e)` * Added: `instance (Error e) => Alternative (Either e)` * Replaced: `instance (Monad m) => Functor (ErrorT e m)` with: `instance Applicative m => Functor (ErrorT e m)` * Added: `instance Applicative m => Applicative (ErrorT e m)` * Added: `instance (Alternative m, Error e) => Alternative (ErrorT e m)` * Identity * Added: `instance Applicative Identity` * List * Replaced: `instance (Monad m) => Functor (ListT m` with: `instance Applicative m => Functor (ListT m)` * Added: `instance Applicative m => Applicative (ListT m)` * Added: `instance Alternative m => Alternative (ListT m)` * RWS (both lazy and strict) (Unfortunately I couldn't get rid of the Monad constraints) * Added: `instance Monoid w => Applicative (RWS r w s)` * Addedd: `instance (Monad m, Monoid w) => Applicative (RWST r w s m)` * Added: `instance (MonadPlus m, Monoid w) => Alternative (RWST r w s m)` * Reader * Added: `instance Applicative (Reader r)` * Replaced: `instance (Monad m) => Functor (ReaderT r m)` with: `instance (Applicative m) => Functor (ReaderT r m)` * Added: `instance Applicative m => Applicative (ReaderT r m)` * Added: `instance Alternative m => Alternative (ReaderT r m)` * State (both lazy and strict) (Unfortunately I couldn't get rid of the Monad constraints) * Added: `instance Applicative (State s)` * Added: `instance Monad m => Applicative (StateT s m)` * Added: `instance MonadPlus m => Alternative (StateT s m)` * Writer (both lazy and strict) * Added: `instance Monoid w => Applicative (Writer w)` * Replaced: `instance (Monad m) => Functor (WriterT w m)` with: `instance (Applicative m, Monoid w) => Functor (WriterT w m)` * Added: `instance (Applicative m, Monoid w) => Applicative (WriterT w m)` * Added: `instance (Alternative m, Monoid w) => Alternative (WriterT w m)` == Questions == I also had some questions: * Does it make sense adding Applicative counterparts to the Monad* classes? For example: * `class Applicative f => ApplicativeError e g | f -> e where ...` * `class Applicative f => ApplicativeState s f | f -> s where ...` * `class Applicative f => ApplicativeReader r f | f -> r where ...` * `class (Applicative f, Monoid w) => ApplicativeWriter w f | f -> w where ...` * `class (Monoid w, ApplicativeReader r f, ApplicativeWriter w f, ApplicatveState s f) => ApplicativeRWS r w s f | f -> r, f -> w, f -> s where ...` * `class (Applicative m) => ApplicativeCont m where ...` * `class ApplicativeTrans t where lift :: Applicative f => f a -> t f a` * Can we get rid of the Monad and !MonadPlus constraints in the Applicative and Alternative instances for StateT and RWST? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 20 17:30:51 2008 From: trac at galois.com (GHC) Date: Sat Dec 20 17:23:24 2008 Subject: [GHC] #2887: Segfault while configuring Cabal 1.6.0.1 on OS X 10.5 In-Reply-To: <042.ed7dbc0df59c928988eada06283bfab4@localhost> References: <042.ed7dbc0df59c928988eada06283bfab4@localhost> Message-ID: <051.879d8f97b8c4d63298ba7bbc4c1e5196@localhost> #2887: Segfault while configuring Cabal 1.6.0.1 on OS X 10.5 ----------------------+----------------------------------------------------- Reporter: ozy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: powerpc ----------------------+----------------------------------------------------- Comment (by ozy): On the recommendation of the one person I've encountered who experienced this problem, I upgraded my compiler toolchain (Apple Xcode 3.0 to 3.1), which resolved the problem. Is there some channel through which to advise against compiling GHC with certain compiler or linker versions? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 22 05:12:14 2008 From: trac at galois.com (GHC) Date: Mon Dec 22 05:04:41 2008 Subject: [GHC] #2887: Segfault while configuring Cabal 1.6.0.1 on OS X 10.5 In-Reply-To: <042.ed7dbc0df59c928988eada06283bfab4@localhost> References: <042.ed7dbc0df59c928988eada06283bfab4@localhost> Message-ID: <051.e853057da0d5539492ca74bdfaf441a4@localhost> #2887: Segfault while configuring Cabal 1.6.0.1 on OS X 10.5 -------------------------+-------------------------------------------------- Reporter: ozy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | -------------------------+-------------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Please put the information in here: [wiki:Building/Prerequisites] in the MacOS X section, and move any relevant parts from [wiki:Building/MacOSX] while you're at it. I'd like to get all the information about "what things are needed for building GHC" in one place. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 22 05:22:27 2008 From: trac at galois.com (GHC) Date: Mon Dec 22 05:14:52 2008 Subject: [GHC] #2887: Segfault while configuring Cabal 1.6.0.1 on OS X 10.5 In-Reply-To: <042.ed7dbc0df59c928988eada06283bfab4@localhost> References: <042.ed7dbc0df59c928988eada06283bfab4@localhost> Message-ID: <051.6e63e1b1a1d7b463095f289bfb2c48b5@localhost> #2887: Segfault while configuring Cabal 1.6.0.1 on OS X 10.5 -------------------------+-------------------------------------------------- Reporter: ozy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | -------------------------+-------------------------------------------------- Comment (by maeder): Right, ghc on PPC Leopard is unusable without Xcode 3.1. This should be made clear on the download page. (I had linking problems or seg-faults with Xcode 3.0 as described in #1958) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 22 05:26:54 2008 From: trac at galois.com (GHC) Date: Mon Dec 22 05:19:17 2008 Subject: [GHC] #2891: threadDelay appears to use excessive CPU in GHCi In-Reply-To: <049.e486b1f0b04e32b03f5954cc3c1db385@localhost> References: <049.e486b1f0b04e32b03f5954cc3c1db385@localhost> Message-ID: <058.fa0f7aacb5ee35e79ad72627166eb39e@localhost> #2891: threadDelay appears to use excessive CPU in GHCi ---------------------------+------------------------------------------------ Reporter: JeremyShaw | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---------------------------+------------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Ok, this program repeatedly waits for one second. When this is run with the threaded RTS, here's what happens: * the program calls threadDelay * 1/3 of a second later, the RTS notices that the program is idle and does a GC * after 1 second, the program wakes up again, etc. so we get a full GC every second, which accounts for the 2% CPU usage: in GHCi there's about 5Mb of stuff in the heap when idle. You'll see the same effect when compiling the program with `-threaded`, but there the heap will be almost empty, so the GC won't take much time. Without `-threaded` there is no idle-time GC. You can turn off the idle-time GC with the `-I0` RTS option, e.g. {{{ ghci +RTS -I0 }}} The idle-time GC isn't there just for performance reasons, it's also for detecting deadlock. If the program has deadlocked, the only way to detect that (and send `BlockedIndefinitely` exceptions) is to do a GC, but we want to wait until the program looks idle before initiating the GC, hence the current behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 22 09:06:17 2008 From: trac at galois.com (GHC) Date: Mon Dec 22 08:58:49 2008 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@localhost> References: <047.8e9c859b4db83c0d687094f53af0d886@localhost> Message-ID: <056.960fec95f9c11b28066f64ba72f910ac@localhost> #393: functions without implementations ----------------------------------------+----------------------------------- Reporter: c_maeder | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: None Severity: normal | Resolution: None Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Comment (by maeder): see http://trac.haskell.org/haddock/ticket/66#comment:2 for a further motivation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 22 10:08:00 2008 From: trac at galois.com (GHC) Date: Mon Dec 22 10:00:30 2008 Subject: [GHC] #2892: (threadDelay (-1)) hangs Message-ID: <045.cacf950ebeacdae764843c5be42d3ce1@localhost> #2892: (threadDelay (-1)) hangs -------------------+-------------------------------------------------------- Reporter: dancor | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- threadDelay silently hangs forever given a negative delay interval. It seems like this should at least be documented, but further is probably suboptimal magical behavior that leads to harder-to-find bugs; instead this should be an error. Conceivably threadDelay could take Maybe Int but that seems kind of out there. Here is some discussion from #haskell: 06:39 < dancor> do other ppl agree that (threadDelay (-1)) hanging silently is bug? 06:39 < dancor> i guess you might want infinite hang, hm 06:39 < Cale> dancor: I think I might agree with that, though now that you mention it, it's very handy. 06:39 < Cale> dancor: A lot of things which would cause a thread to block forever will throw an exception and kill the thread. 06:40 < Cale> (an exception which you'd often wish were silent) 06:40 < Cale> But threadDelay is the wrong place for that 06:40 < b_jonas> dancor: yeah, the thread should just be garbage-collected 06:42 * quicksilver uses "forever (threadDelay maxBound)" I'm on Debian lenny: ~ uname -a Linux pima 2.6.26-1-686-bigmem #1 SMP Sat Nov 8 19:46:36 UTC 2008 i686 GNU/Linux ~ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 ~ cat threadHang.hs import Control.Concurrent main = threadDelay (-1) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 22 10:10:02 2008 From: trac at galois.com (GHC) Date: Mon Dec 22 10:02:33 2008 Subject: [GHC] #2892: (threadDelay (-1)) hangs In-Reply-To: <045.cacf950ebeacdae764843c5be42d3ce1@localhost> References: <045.cacf950ebeacdae764843c5be42d3ce1@localhost> Message-ID: <054.ab5e4056b4500344ff6c309aa58f2217@localhost> #2892: (threadDelay (-1)) hangs ----------------------+----------------------------------------------------- Reporter: dancor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by dancor): Very sorry, here is the description with proper formatting: threadDelay silently hangs forever given a negative delay interval. It seems like this should at least be documented, but further is probably suboptimal magical behavior that leads to harder-to-find bugs; instead this should be an error. Conceivably threadDelay could take Maybe Int but that seems kind of out there. Here is some discussion from #haskell: {{{ 06:39 < dancor> do other ppl agree that (threadDelay (-1)) hanging silently is bug? 06:39 < dancor> i guess you might want infinite hang, hm 06:39 < Cale> dancor: I think I might agree with that, though now that you mention it, it's very handy. 06:39 < Cale> dancor: A lot of things which would cause a thread to block forever will throw an exception and kill the thread. 06:40 < Cale> (an exception which you'd often wish were silent) 06:40 < Cale> But threadDelay is the wrong place for that 06:40 < b_jonas> dancor: yeah, the thread should just be garbage-collected 06:42 * quicksilver uses "forever (threadDelay maxBound)" }}} I'm on Debian lenny: {{{ ~ uname -a Linux pima 2.6.26-1-686-bigmem #1 SMP Sat Nov 8 19:46:36 UTC 2008 i686 GNU/Linux ~ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.1 ~ cat threadHang.hs import Control.Concurrent main = threadDelay (-1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 22 10:12:01 2008 From: trac at galois.com (GHC) Date: Mon Dec 22 10:04:23 2008 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic In-Reply-To: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> References: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> Message-ID: <055.c2a864425d8accba9ac5d7b1ad2620f9@localhost> #2808: createDirectoryIfMissing should be atomic ------------------------------------+--------------------------------------- Reporter: EricKow | Owner: igloo Type: merge | Status: reopened Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Comment (by simonmar): Dropping some notes here so I don't forget over the holidays: * This new version fails `createDirectory001`, because the dir gets removed between `createDirectory` and `doesDirectoryExist`, resulting in a isAlreadyExists exception being thrown. We could do better here by calling `System.Posix.getFileStatus` if available. (ToDo: what about Windows?) * the test should check for two threads both doing `createDirectoryIfExists; cleanup` too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 22 11:48:58 2008 From: trac at galois.com (GHC) Date: Mon Dec 22 11:41:21 2008 Subject: [GHC] #2808: createDirectoryIfMissing should be atomic In-Reply-To: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> References: <046.21f1a9c564db33e6ee9ef7b6ede88c51@localhost> Message-ID: <055.c4a0b8d04a447aa6e64a3b2093d76b12@localhost> #2808: createDirectoryIfMissing should be atomic ------------------------------------+--------------------------------------- Reporter: EricKow | Owner: igloo Type: merge | Status: reopened Priority: normal | Milestone: 6.10.2 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Comment (by duncan): Just to clarify for other readers... `createDirectoryIfMissing` cannot be simultaneously atomic and sensible. The problem is that POSIX `mkdir` does not distinguish if a directory already exists vs if a file already exists. We want to fail in one case and `return ()` in the other. One way to square this circle is to test for the existence of the directory separately from the call to `mkdir`. The original code did the test before. That meant it was non-atomic and a `createDirectoryIfMissing` raced against itself would sometimes fail with an exception about the directory already existing. The current code does not do the test at all. That means that we `return ()` when a file exists and this is not sensible. The proposed code does the test afterwards. This makes the `mkdir` bit atomic but we can get a wrong exception if another thread does something else between the `mkdir` and test. The proposed code goes wrong when another thread deletes the directory in between the call to `createDirectory` and `doesDirectoryExist` and in this case throws an already-exists exception which is a bit confusing. Ideally in this scenario there would be no exception (though if it were a parent dir that was deleted then we would expect an exception when it tries to create the child directory). There are really three cases that we want to distinguish when `createDirectory` throws a `AlreadyExistsError`: * a dir exists, in which case we return (); * a non-directory filesystem object exists, in which case we re-throw the exception; * no filesystem object exists, in which case we return (). It just so happens that we can handle these three cases with just `doesFileExist` because we want to do the same thing in two cases that `doesFileExist` identifies. This also relies on the fact that `doesFileExist` considers all non-directory files to be files, including symlinks, sockets, fifos, etc. If that ever changes then this trick does not work. It is more explicit to use the internal `withFileStatus` function. Another behavior question is if `createDirectoryIfMissing` should ever attempt to re-create a directory that it previously created and got subsequently deleted. The current `createDirectory001` test assumes this behavior by racing `removeDirectoryRecursive` with `createDirectoryIfMissing` and expecting no exceptions. If instead we think that `createDirectoryIfMissing` should create each parent directory at most once then the test cannot assume never to encounter a does-not- exist exception. This is because the thread running `createDirectoryIfMissing` could make a parent dir, the other thread delete it and the first thread then try to make the child directory inside the now-deleted parent directory. The proposed code has this behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 22 23:32:34 2008 From: trac at galois.com (GHC) Date: Mon Dec 22 23:25:01 2008 Subject: [GHC] #1355: Interactive I/O with ghc doesn't prompt until after reading In-Reply-To: <056.60dc4ed30510a27061c57e0e9396b85b@localhost> References: <056.60dc4ed30510a27061c57e0e9396b85b@localhost> Message-ID: <065.4f0df97df08a2d67f3ce2c4e24cc9df9@localhost> #1355: Interactive I/O with ghc doesn't prompt until after reading ----------------------------------------------+----------------------------- Reporter: ok@cs.otago.ac.nz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Prelude | Version: 6.2 Severity: normal | Resolution: invalid Keywords: interactive stdio late prompt | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------------+----------------------------- Comment (by guest): I agree with the bug report, it's bitten me a few times, and note that using hFlush requires importing System.IO which should not be required in these very simple programs. main = do { putStr "Enter your name: "; name <- getLine; print $ "hello ++ name } is one the first programs anyone writes in any language and it shouldn't require a bunch of web searching to find out what is wrong and how to fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 23 04:41:21 2008 From: trac at galois.com (GHC) Date: Tue Dec 23 04:33:41 2008 Subject: [GHC] #2893: Implement "Quantified contexts" proposal Message-ID: <045.2638646abdcf216191d07c9810407703@localhost> #2893: Implement "Quantified contexts" proposal -----------------------------+---------------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: proposal | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- See: http://haskell.org/haskellwiki/Quantified_contexts Motivating example is collapsing insomeway-identical classes such as Monoid and MonadPlus into a single class (with accompanying functions). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 23 07:16:45 2008 From: trac at galois.com (GHC) Date: Tue Dec 23 07:09:04 2008 Subject: [GHC] #2894: Documentation for "even" missing Message-ID: <051.915bb1c85de628cda06f20972aedc55e@localhost> #2894: Documentation for "even" missing -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html You can find odd, but not even. Probably caused by: http://trac.haskell.org/haddock/ticket/69 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 23 07:23:20 2008 From: trac at galois.com (GHC) Date: Tue Dec 23 07:15:38 2008 Subject: [GHC] #2894: Documentation for "even" missing In-Reply-To: <051.915bb1c85de628cda06f20972aedc55e@localhost> References: <051.915bb1c85de628cda06f20972aedc55e@localhost> Message-ID: <060.27fb485f845991be58728252035da481@localhost> #2894: Documentation for "even" missing ------------------------------+--------------------------------------------- Reporter: NeilMitchell | 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 ------------------------------+--------------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) Comment: The documentation for "even" is missing, but I've no idea what else has got lost - therefore this bug is probably quite high priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 23 11:09:15 2008 From: trac at galois.com (GHC) Date: Tue Dec 23 11:01:34 2008 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@localhost> References: <045.2638646abdcf216191d07c9810407703@localhost> Message-ID: <054.c6fb30d81216cd59cd316922da34cd4f@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 | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by guest): * cc: id@isaac.cedarswampstudios.org (added) Comment: My initial sense is this is a nice proposal. I wonder a little bit how this would interact with other typeclass needs. What's an example of a function that would need to be typed {{{ :: (Monad m, forall a. Monoid (m a)) => (something or other) }}} ? And would the compiler be able to infer the signature if it wasn't written? (and is this even the right forum to be asking these questions in? Who wrote the proposal, and when?) -Isaac Dupree -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 23 20:27:31 2008 From: trac at galois.com (GHC) Date: Tue Dec 23 20:19:48 2008 Subject: [GHC] #2895: Implement the "Class System Extension" proposal Message-ID: <045.2e780b2005a63fcc016bfcaa8726c1e8@localhost> #2895: Implement the "Class System Extension" proposal -----------------------------+---------------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: proposal | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- See: http://haskell.org/haskellwiki/Class_system_extension_proposal Executive summary: 1. Class and instance declarations would allow method implementations to be given for any methods in the class or any ancestor class. 2. Whenever an instance declaration is visible there would always be a full set of instance declarations for all ancestor classes, by supplementing the set of explicitly given instance declarations that are visible in a module by automatically generated implicit instance declarations. 3. The most specific method implementation would always be chosen (ie prefer an explicit instance method over a class method and prefer a subclass method to a superclass method) 4. Modules would only export explicit instance declarations -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 24 02:12:32 2008 From: trac at galois.com (GHC) Date: Wed Dec 24 02:04:51 2008 Subject: [GHC] #2896: Warning suggestion: argument not necessarily a binary operator Message-ID: <045.d1206251042c791ccaaa9743fd236ce8@localhost> #2896: Warning suggestion: argument not necessarily a binary operator -----------------------------+---------------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- As an example: {{{ let fn (+) = 1; fn x = 2 in fn 1 }}} The suggested warning is that: if an argument to a function consists entirely of characters which are symbols (all isSymbol), and the type of that argument isn't (a -> b -> c), then produce a warning. Suggested wording is something along the lines of "Warning: the argument '(+)' isn't necessarily a binary operator, although it looks like one. This may be confusing to readers of your code." -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 24 02:19:01 2008 From: trac at galois.com (GHC) Date: Wed Dec 24 02:11:37 2008 Subject: [GHC] #2896: Warning suggestion: argument not necessarily a binary operator In-Reply-To: <045.d1206251042c791ccaaa9743fd236ce8@localhost> References: <045.d1206251042c791ccaaa9743fd236ce8@localhost> Message-ID: <054.341f7348968d90de11a4689472f86b93@localhost> #2896: Warning suggestion: argument not necessarily a binary operator ------------------------------+--------------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by cjs): The issue with warnings is that there has to be a way to "fix" them: that is to say, a way to change the code to say, "yes, this is what I really want to do." An example is the warning you get for "import Foo" when you need only the instances from module Foo; you'll get a warning, but you can fix it with "import Foo ()" to explicitly declare why you're doing something. So what does one do to the code in this case to say, "Yes, I really mean this," and shut off the warning? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 24 04:50:56 2008 From: trac at galois.com (GHC) Date: Wed Dec 24 04:43:25 2008 Subject: [GHC] #2897: HsFFI.h not found in include path Message-ID: <042.b2d6e868e73bff261558ad2f8fec87f6@localhost> #2897: HsFFI.h not found in include path --------------------------------+------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 6.10.1 | Severity: major Keywords: include ffi hsffi.h | Testcase: Os: Linux | Architecture: x86 --------------------------------+------------------------------------------- Using the ghc 6.1.0 package for libedit2 downloaded from the GHC downloads page, on Ubuntu 8.04.1, attempting to compile an hsc file fails with: {{{ In file included from /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.c:1: /usr/local/lib/ghc-6.10.1/hsc2hs-0.67/template-hsc.h:4:19: error: HsFFI.h: No such file or directory compiling /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.c failed command was: /usr/bin/gcc -c /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.c -o /u/cjs/co/client/tsuru/trader/build/src/trader/src/HX/Empty_hsc_make.o }}} I note that the command does not include a -I option. Either running the command by hand with an appropriate -I option, or setting the environment variable {{{CPATH=/usr/local/lib/ghc-6.10.1/include}}} fixes the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 24 06:43:27 2008 From: trac at galois.com (GHC) Date: Wed Dec 24 06:35:43 2008 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@localhost> References: <045.2638646abdcf216191d07c9810407703@localhost> Message-ID: <054.1225f6a3324cdf0d09d155ed953e1373@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 | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by porges): Well here's an example: today I was trying to write an instance of Applicative for things that are Monoids and Foldable (started by generalizing from [a]): This is currently not possible because Applicative & Foldable are both (* -> *) and Monoids are (*). As far as I can tell, the proposal would allow something like this: {{{ instance (Foldable l, forall a. Monoid (l a)) => Applicative l where fs <*> xs = foldMap (<$> xs) fs }}} I may be horribly wrong, however :) (Also I can't implement pure :P) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 25 00:19:02 2008 From: trac at galois.com (GHC) Date: Thu Dec 25 00:11:18 2008 Subject: [GHC] #2898: crash when interpreting Message-ID: <045.4b1c4995fd828c01fa73119237ba0b1d@localhost> #2898: crash when interpreting -------------------+-------------------------------------------------------- Reporter: nolrai | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- when I interpret my file Utilities/ChoiceMonad.hs from ghci-haskline I get the following message: [2 of 2][Compiling Utilities.ChoiceMonad ( Utilities/ChoiceMonad.hs, interpreted ) ghci-haskeline: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): ByteCodeGen.schemeE: unhandled case \ (@ a1{tv a1qQ} [sk] :: ghc-prim:GHC.Prim.*{(w) tc 34d}) (@ b1{tv a1qR} [sk] :: ghc-prim:GHC.Prim.*{(w) tc 34d}) -> case {tick (main:Utilities.ChoiceMonad, 169)}{v d1z7} [gid] @ (ghc-prim:GHC.Prim.State#{(w) tc 32q} ghc-prim:GHC.Prim.RealWorld{(w) tc 31E}) {(a1{tv a1qQ} [sk] -> b1{tv a1qR} [sk]) -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw} m{tv aQH} [sk] a1{tv a1qQ} [sk] -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw} m{tv aQH} [sk] b1{tv a1qR} [sk]} of (tick{v s29j} [lid] :: ghc-prim:GHC.Prim.State#{(w) tc 32q} ghc-prim:GHC.Prim.RealWorld{(w) tc 31E}) { __DEFAULT -> let { sat_s20H{v} [lid] :: (a1{tv a1qQ} [sk] -> b1{tv a1qR} [sk]) -> main:Utilities.LeafyTree.LeafyTree{tc rfw} a1{tv a1qQ} [sk] -> main:Utilities.LeafyTree.LeafyTree{tc rfw} b1{tv a1qR} [sk] [] sat_s20H{v} [lid] = base:GHC.Base.fmap{v r5G} [gid] @ main:Utilities.LeafyTree.LeafyTree{tc rfw} main:Utilities.LeafyTree.$f4{v rfq} [gid] @ a1{tv a1qQ} [sk] @ b1{tv a1qR} [sk] } in let { sat_s20F{v} [lid] :: (main:Utilities.LeafyTree.LeafyTree{tc rfw} a1{tv a1qQ} [sk] -> main:Utilities.LeafyTree.LeafyTree{tc rfw} b1{tv a1qR} [sk]) -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw} m{tv aQH} [sk] a1{tv a1qQ} [sk] -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw} m{tv aQH} [sk] b1{tv a1qR} [sk] [] sat_s20F{v} [lid] = main:Utilities.ChoiceMonad.inChoiceT{v rLn} [gid] @ m{tv aQH} [sk] @ a1{tv a1qQ} [sk] @ b1{tv a1qR} [sk] $dMonad1{v s20D} [lid] } in base:GHC.Base..{v r4k} [gid] @ (main:Utilities.LeafyTree.LeafyTree{tc rfw} a1{tv a1qQ} [sk] -> main:Utilities.LeafyTree.LeafyTree{tc rfw} b1{tv a1qR} [sk]) @ (main:Utilities.ChoiceMonad.ChoiceT{tc rJw} m{tv aQH} [sk] a1{tv a1qQ} [sk] -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw} m{tv aQH} [sk] b1{tv a1qR} [sk]) @ (a1{tv a1qQ} [sk] -> b1{tv a1qR} [sk]) sat_s20F{v} [lid] sat_s20H{v} [lid] } Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug but if i do "ghc --make Utilities/ChoiceMonad.hs" that works and I can then load it with ghci-haskline, at least until I modify it and need to compile again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 26 16:33:19 2008 From: trac at galois.com (GHC) Date: Fri Dec 26 16:25:36 2008 Subject: [GHC] #2900: Confusing error message for monadic function with wrong number of arguments Message-ID: <042.cbd4b88a3fe2bde042fd065b7021c09a@localhost> #2900: Confusing error message for monadic function with wrong number of arguments -----------------------------+---------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.1 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- If I compile the following code: {{{ import Control.Monad.State foo :: MonadIO m => Int -> m () foo x y = return () }}} I get the error message: {{{ bug.hs:6:10: Couldn't match expected type `()' against inferred type `m ()' In the expression: return () In the definition of `foo': foo x y = return () }}} On the other hand, if I change foo's type signature to: {{{ foo :: Int -> IO () }}} I get the more helpful: {{{ bug.hs:6:0: The equation(s) for `foo' have two arguments, but its type `Int -> IO ()' has only one }}} It would be good if the second error message appeared in the first case as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 26 16:28:05 2008 From: trac at galois.com (GHC) Date: Fri Dec 26 16:26:34 2008 Subject: [GHC] #2899: GADT type inference with existentials Message-ID: <046.65d5a2099cbe920e5924d98bc673cc59@localhost> #2899: GADT type inference with existentials ------------------------------------+--------------------------------------- Reporter: jochemb | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.1 | Severity: normal Keywords: GADT, existential types | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------------+--------------------------------------- The following code works in GHC 6.8.2: {{{ {-# OPTIONS -fglasgow-exts #-} module Test where data Existential = forall a. Ex (GADT a) data GADT :: * -> * where GCon :: Int -> GADT () -- g :: Existential -> Int g (Ex (GCon x)) = x }}} The compiler correctly infers the type of x in the definition of g, and correctly infers the type of g. In GHC 6.10.1, however, this fails with: {{{ Test.hs:10:12: GADT pattern match with non-rigid result type `t' Solution: add a type signature In the definition of `g': g (Ex (GCon x)) = x Failed, modules loaded: none. }}} The solution, to include the type signature of g (that I have commented out), works, but why can't GHC figure out the type of g? GHC 6.8.2 could! An equivalent version with a non-GADT instead, works correctly: {{{ data GADT a = GCon Int }}} Ticket #2206 might be related. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 26 16:28:21 2008 From: trac at galois.com (GHC) Date: Fri Dec 26 16:26:47 2008 Subject: [GHC] #2899: GADT type inference with existentials In-Reply-To: <046.65d5a2099cbe920e5924d98bc673cc59@localhost> References: <046.65d5a2099cbe920e5924d98bc673cc59@localhost> Message-ID: <055.e05fdb9f8a2d226fc8de36205877aa98@localhost> #2899: GADT type inference with existentials -------------------------------------+-------------------------------------- Reporter: jochemb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: Keywords: GADT, existential types | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------+-------------------------------------- Changes (by jochemb): * cc: jochem@functor.nl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 26 17:31:51 2008 From: trac at galois.com (GHC) Date: Fri Dec 26 17:24:01 2008 Subject: [GHC] #323: Exponential behaviour with type synonyms In-Reply-To: <046.92361e61265669139fc7234a18aa8785@localhost> References: <046.92361e61265669139fc7234a18aa8785@localhost> Message-ID: <055.d49ae55b76636e9ebbc59e58d7976aa4@localhost> #323: Exponential behaviour with type synonyms ----------------------------------------+----------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: low | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.4.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: syn-perf2 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Comment (by sunrise): {{{ #!html This works ok for me.. but It probably needs feedback. haskell Air Jordan }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 26 17:31:57 2008 From: trac at galois.com (GHC) Date: Fri Dec 26 17:24:05 2008 Subject: [GHC] #1205: ghci reports functions not in scope after loading a .hs, if there is a .o present In-Reply-To: <044.bd60efe42aee3f1abdd3292b0526501b@localhost> References: <044.bd60efe42aee3f1abdd3292b0526501b@localhost> Message-ID: <053.0c982ed827bc8d91054234080fe19abd@localhost> #1205: ghci reports functions not in scope after loading a .hs, if there is a .o present ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: feature request | Status: closed Priority: high | Milestone: 6.10 branch Component: GHCi | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by sunrise): {{{ #!html This works ok for me.. but It probably needs feedback. haskell Air Jordan }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 26 17:32:01 2008 From: trac at galois.com (GHC) Date: Fri Dec 26 17:24:10 2008 Subject: [GHC] #1337: Fix wrong indentation from Text.PrettyPrint.HughesPJ fill (fcat and fsep) In-Reply-To: <050.0d1c36f5d6cac580edd71d8a018225c6@localhost> References: <050.0d1c36f5d6cac580edd71d8a018225c6@localhost> Message-ID: <059.c1ea9feb6e7aabce1cac7dc89f306aec@localhost> #1337: Fix wrong indentation from Text.PrettyPrint.HughesPJ fill (fcat and fsep) ---------------------------------+------------------------------------------ Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: closed Priority: normal | Milestone: 6.10.1 Component: libraries/pretty | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: Pp003 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by sunrise): {{{ #!html This works ok for me.. but It probably needs feedback. haskell Air Jordan }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 26 17:32:05 2008 From: trac at galois.com (GHC) Date: Fri Dec 26 17:24:15 2008 Subject: [GHC] #2233: Overhaul System.Process In-Reply-To: <047.24a366415ff9b59c03e5bf49850898a6@localhost> References: <047.24a366415ff9b59c03e5bf49850898a6@localhost> Message-ID: <056.7b18cdb5fb16d9d161e2c27dfe60128e@localhost> #2233: Overhaul System.Process ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/process | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by sunrise): {{{ #!html This works ok for me.. but It probably needs feedback. haskell Air Jordan }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 26 17:31:54 2008 From: trac at galois.com (GHC) Date: Fri Dec 26 17:24:52 2008 Subject: [GHC] #1895: Allow aliases in GHCi module imports In-Reply-To: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> References: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> Message-ID: <053.935f55527e65cf57b97b8f21dc75a379@localhost> #1895: Allow aliases in GHCi module imports ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by sunrise): {{{ #!html This works ok for me.. but It probably needs feedback. haskell Air Jordan }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 05:08:50 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 05:00:50 2008 Subject: [GHC] #2876: Inconsistent error message In-Reply-To: <044.5a28c6b93763f0b6cbcb3674dddddbbb@localhost> References: <044.5a28c6b93763f0b6cbcb3674dddddbbb@localhost> Message-ID: <053.b069ea5f2c6904afe4faea01ed1662b3@localhost> #2876: Inconsistent error message ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => worksforme Comment: This looks ok to me in the 6.10 branch sources, and when running GHC 6.10.1 on this program {{{ {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances #-} module Foo where class C a b | a->b instance C [a] d }}} I get {{{ bash-3.2$ ghc -c Foo.hs Foo.hs:6:0: Illegal instance declaration for `C [a] d' (the Coverage Condition fails for one of the functional dependencies; Use -XUndecidableInstances to permit this) In the instance declaration for `C [a] d' }}} Are you sure you are using 6.10? If so, re-open this bug with more info. Thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 05:15:42 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 05:07:44 2008 Subject: [GHC] #2877: crash when printig a list (IO ()) In-Reply-To: <044.0933e1ca77e0ef5175110397abfb4837@localhost> References: <044.0933e1ca77e0ef5175110397abfb4837@localhost> Message-ID: <053.396ba9def38537c5194e8eef92ae51b1@localhost> #2877: crash when printig a list (IO ()) -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Old description: > data InputSignal = IS1 | > IS2 > > data OutputSignal = OS1 Widget [Int] | > OS2 Widget [String] > > type Widget = InputSignal -> OutputSignal > > testWidgetSignalProcessor :: (Int, Int, Int) -> Widget > testWidgetSignalProcessor pos@(x, y, z) IS1 = OS1 > (testWidgetSignalProcessor pos) [1, 2, 3] > testWidgetSignalProcessor pos@(x, y, z) IS2 = OS2 > (testWidgetSignalProcessor (666, 666, 666)) ["ich", "kack", "ab"] > > makeTestWidget :: (Int, Int, Int) -> Widget > makeTestWidget pos = testWidgetSignalProcessor pos > > display :: OutputSignal -> IO () > display (OS1 widget list) = print list > display (OS2 widget list) = print list > > test :: IO () > test = do > let testWidget = makeTestWidget (0, 0, 0) > display $ testWidget IS1 > display $ testWidget IS2 > > when i enter "test" at the interpreter-prompt (i'm using ghci from > emacs), it crashes with the following message: > > : panic! (the 'impossible' happened) > (GHC version 6.10.1 for i386-unknown-mingw32): > loadObj: failed New description: {{{ data InputSignal = IS1 | IS2 data OutputSignal = OS1 Widget [Int] | OS2 Widget [String] type Widget = InputSignal -> OutputSignal testWidgetSignalProcessor :: (Int, Int, Int) -> Widget testWidgetSignalProcessor pos@(x, y, z) IS1 = OS1 (testWidgetSignalProcessor pos) [1, 2, 3] testWidgetSignalProcessor pos@(x, y, z) IS2 = OS2 (testWidgetSignalProcessor (666, 666, 666)) ["ich", "kack", "ab"] makeTestWidget :: (Int, Int, Int) -> Widget makeTestWidget pos = testWidgetSignalProcessor pos display :: OutputSignal -> IO () display (OS1 widget list) = print list display (OS2 widget list) = print list test :: IO () test = do let testWidget = makeTestWidget (0, 0, 0) display $ testWidget IS1 display $ testWidget IS2 }}} when i enter "test" at the interpreter-prompt (i'm using ghci from emacs), it crashes with the following message: {{{ : panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-mingw32): loadObj: failed }}}} Comment: That's odd. On our x86_64 machine it works fine: {{{ [1 of 1] Compiling T2877 ( T2877.hs, interpreted ) Ok, modules loaded: T2877. *T2877> test [1,2,3] ["ich","kack","ab"] *T2877> }}} Can others try? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 05:24:19 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 05:16:19 2008 Subject: [GHC] #2878: panic while compiling Cabal-1.6.0.1 In-Reply-To: <045.546c16a32de57181a9229bd36cb27ab8@localhost> References: <045.546c16a32de57181a9229bd36cb27ab8@localhost> Message-ID: <054.27d2179e885d0d52e6f6dcb55f4cc1af@localhost> #2878: panic while compiling Cabal-1.6.0.1 -------------------------------+-------------------------------------------- Reporter: dvogel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Old description: > While compiling Cabal-1.6.0.1, as packaged with Cabal-0.6.0, I got: > > [16 of 50] Compiling Distribution.Simple.Utils ( > Distribution/Simple/Utils.hs, dist/build/Distribution/Simple/Utils.o ) > ghc-6.8.2: panic! (the 'impossible' happened) > (GHC version 6.8.2 for x86_64-unknown-linux): > applyTypeToArgs > unix-2.3.0.0:System.Posix.Signals.a38{v rov8} [gid] > (unix-2.3.0.0:System.Posix.Signals.a5{v rov7} [gid] > `cast` (base:GHC.Prim.sym{(w) tc 34v} > (base:Foreign.C.Types.:CoCInt{tc r1dN}) > :: base:GHC.Int.Int32{tc 3V} > ~ > base:Foreign.C.Types.CInt{tc r17X})) > unix-2.3.0.0:System.Posix.Signals.Ignore{v rov6} [gid] > (base:Data.Maybe.Nothing{v r6E} [gid] > @ unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rov5}) > eta{v apCg} [lid] > (# base:GHC.Prim.State#{(w) tc 32q} > base:GHC.Prim.RealWorld{(w) tc 31E}, > unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rov5} #) New description: While compiling Cabal-1.6.0.1, as packaged with Cabal-0.6.0, I got: {{{ [16 of 50] Compiling Distribution.Simple.Utils ( Distribution/Simple/Utils.hs, dist/build/Distribution/Simple/Utils.o ) ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for x86_64-unknown-linux): applyTypeToArgs unix-2.3.0.0:System.Posix.Signals.a38{v rov8} [gid] (unix-2.3.0.0:System.Posix.Signals.a5{v rov7} [gid] `cast` (base:GHC.Prim.sym{(w) tc 34v} (base:Foreign.C.Types.:CoCInt{tc r1dN}) :: base:GHC.Int.Int32{tc 3V} ~ base:Foreign.C.Types.CInt{tc r17X})) unix-2.3.0.0:System.Posix.Signals.Ignore{v rov6} [gid] (base:Data.Maybe.Nothing{v r6E} [gid] @ unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rov5}) eta{v apCg} [lid] (# base:GHC.Prim.State#{(w) tc 32q} base:GHC.Prim.RealWorld{(w) tc 31E}, unix-2.3.0.0:System.Posix.Signals.SignalSet{tc rov5} #) }}} Comment: That's odd; we use Cabal in GHC itself, so we compile it all the time. Does the same thing happen with GHC 6.10? You might want to remove all `.hi` files, just in case there's some kind of out-of-date-ness fooling the recompilation checker. If it works in 6.10, we'll probably treat this as won't-fix because we won't release another version of 6.8. If it fails in 6.10, please can you describe exactly how to reproduce it? Many thanks. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 08:36:24 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 08:28:35 2008 Subject: [GHC] #2896: Warning suggestion: argument not necessarily a binary operator In-Reply-To: <045.d1206251042c791ccaaa9743fd236ce8@localhost> References: <045.d1206251042c791ccaaa9743fd236ce8@localhost> Message-ID: <054.4e827912af6789a24bc3a782b39043fb@localhost> #2896: Warning suggestion: argument not necessarily a binary operator ---------------------------------+------------------------------------------ Reporter: porges | Owner: Type: feature request | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * priority: normal => low * difficulty: => Unknown * milestone: => _|_ Comment: Also don't forget that GHC supports unary postfix operators http://www.haskell.org/ghc/dist/current/docs/users_guide/syntax-extns.html #postfix-operators. I can see your motivation. The benefit is small, but perceptible. However, the design is not obvious, as the comments in this ticket make clear. So I'll make it low priority for now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 09:05:04 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 08:57:09 2008 Subject: [GHC] #2206: GADT pattern match with non-rigid return type In-Reply-To: <046.ef46bda025b4e7ab59ca8efa3b49bcc6@localhost> References: <046.ef46bda025b4e7ab59ca8efa3b49bcc6@localhost> Message-ID: <055.dfb351fcabad675fbe64dffcdbd828ec@localhost> #2206: GADT pattern match with non-rigid return type ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: gadt-escape1 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Indeed GHC 6.10 now (correctly) reports {{{ $ ghc -c T2206.hs T2206.hs:12:51: GADT pattern match with non-rigid result type `t' Solution: add a type signature In a case alternative: Hidden (ExpInt _) a -> a In the expression: case (hval :: Hidden) of { Hidden (ExpInt _) a -> a } In the definition of `weird': weird = case (hval :: Hidden) of { Hidden (ExpInt _) a -> a } }}} which seems like a decent error message. So I'll close this one. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 08:59:09 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 08:57:29 2008 Subject: [GHC] #2899: GADT type inference with existentials In-Reply-To: <046.65d5a2099cbe920e5924d98bc673cc59@localhost> References: <046.65d5a2099cbe920e5924d98bc673cc59@localhost> Message-ID: <055.13ee6e6d193488358661c04ed9512e18@localhost> #2899: GADT type inference with existentials ----------------------------------------+----------------------------------- Reporter: jochemb | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: GADT, existential types | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: This is by design, I'm afraid. See * http://haskell.org/haskellwiki/Upgrading_packages#Changes_to_GADT_matching * http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type- extensions.html#gadt (last bullet) The trouble with 6.8.2 is that while it would sometimes guess right, it could also fail in an unpredictable way, so 6.10 is a bit more conservative, but also a bit more predictable. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 10:30:30 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 10:22:35 2008 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@localhost> References: <045.2638646abdcf216191d07c9810407703@localhost> Message-ID: <054.1ebdbb0baa0813e93e1adcdcec2dc17c@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 | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown * milestone: => _|_ Comment: I had trouble following the proposal. I didn't see how Section 3 addressed the issues raised in Sections 1 and 2. For example, to avoid the cascade of `Typeable2`, `Typeable3` etc classes the solution is presumably polymorphism at the kind level. (Tim Sheard's language Omega has this.) Still, I recognise the merit of quantification in contexts. Indeed, Ralf Hinze and I suggested it back in 2000 in Section 7 of [http://research.microsoft.com/en-us/um/people/simonpj/papers/derive.htm Derivable type classes]. (This section is rather independent of the rest of the paper.) However, attractive as it is, it's quite a big step to add something akin to local instance declarations. Our ICFP'08 paper [http://research.microsoft.com/~simonpj/papers/assoc-types/index.htm Type checking with open type functions] relies rather crucially on ''not'' having such local instances. (We've managed to simplify the algorithm quite a bit since then, but it still relies on that assumption.) So I'm not sure I see how to make quantified contexts compatible with type functions, and all the other stuff in Haskell. But their lack is clearly a wart, and one that may become more pressing. Meanwhile, clarifying the proposal would be a good thing, even if it's not adopted right away. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 10:56:33 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 10:48:34 2008 Subject: [GHC] #2895: Implement the "Class System Extension" proposal In-Reply-To: <045.2e780b2005a63fcc016bfcaa8726c1e8@localhost> References: <045.2e780b2005a63fcc016bfcaa8726c1e8@localhost> Message-ID: <054.576817ef8f9130bc5acfc303dd10940d@localhost> #2895: Implement the "Class System Extension" 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 | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown * milestone: => _|_ Comment: There seems to be a lot of overlap between * [http://haskell.org/haskellwiki/Class_system_extension_proposal] * [http://haskell.org/haskellwiki/Superclass_defaults] (Section 1) * Parts of [http://repetae.net/john/recent/out/classalias.html] although I don't think they are quite the same. It's hard to be sure because they are written at very different levels of detail. I gather that the basic idea is to allow {{{ class D a where opD :: ... class D a => C a where opC :: ... opC = ... opD = ...opC... instance C Int where opC = ... }}} This leaves me with lots of questions: * The above instance declaration for C implies an implicit instance declaration for D: {{{ instance D Int where opD = ...opC... }}} But what triggers that behaviour? Is it the mere existence of a single default method for D in the class declaration for C? * There is no textual clue that we get an instance for D. Shouldn't there be? As the other proposal suggests, perhaps {{{ instance (C Int, D Int) where opC = ... }}} But that is bad in another way: now we can't re-factor C into two classes without changing the instances of C, which was one of John Meacham's specific goals. * What if there already is an instance for D? Is that ok? If an existing explicit instance somehow suppresses the implicit instance, there is even more going on in invisible implicit-land. What if the explicit instance was not exactly the same, but merely overlapped? I think a good way to make the proposal(s) more precise would be to give a translation into ordinary Haskell. That would answer some of these questions. Interesting stuff here, but it needs a bit of work. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 11:30:28 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 11:22:32 2008 Subject: [GHC] #1897: Type families: type signature rejected In-Reply-To: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> References: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> Message-ID: <053.25af5c5c2d470389c9b736393d9c3a20@localhost> #1897: Type families: type signature rejected ----------------------------------------+----------------------------------- Reporter: guest | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Comment (by simonpj): See also http://haskell.org/haskellwiki/GHC/Type_system#Type_signatures_and_ambiguity for an example unrelated to type functions. See also #2885 for yet another example. We must sort out this ambiguity problem. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 11:31:38 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 11:23:37 2008 Subject: [GHC] #2885: Late and confusing error on uncallable class method In-Reply-To: <047.ce20e9ec9214d3f798b1054ab8be4dea@localhost> References: <047.ce20e9ec9214d3f798b1054ab8be4dea@localhost> Message-ID: <056.94f427fc91f74955880caa319924c459@localhost> #2885: Late and confusing error on uncallable class method -------------------------------+-------------------------------------------- Reporter: blamario | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Yes, you are quite right. This is a bad and long-standing problem; the ticket that gathers the pointers is #1897. I've cross-referenced it from here, and will close this as a duplicate. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 11:35:24 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 11:27:27 2008 Subject: [GHC] #1897: Ambiguous types and rejected type signatures In-Reply-To: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> References: <044.e733a0c0c6af2d1a744b7039f7ad31a7@localhost> Message-ID: <053.6e84a5fa2c5d2e11d4b09baf4abd959e@localhost> #1897: Ambiguous types and rejected type signatures ----------------------------------------+----------------------------------- Reporter: guest | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------------------+----------------------------------- Changes (by simonpj): * summary: Type families: type signature rejected => Ambiguous types and rejected type signatures Old description: > The following programm does not compile: > > {{{ > {-# LANGUAGE TypeFamilies #-} > > import Control.Monad > import Data.Maybe > > class Bug s where > type Depend s > > next :: s -> Depend s -> Maybe s > start :: s > > isValid :: (Bug s) => [Depend s] -> Bool > isValid ds = isJust $ foldM next start ds > }}} > > Error: > {{{ > GHCi, version 6.9.20071105: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > [1 of 1] Compiling Main ( GHC-Bug.hs, interpreted ) > Bug.hs:13:39: > Couldn't match expected type `Depend a' > against inferred type `Depend s' > Expected type: [Depend a] > Inferred type: [Depend s] > In the third argument of `foldM', namely `ds' > In the second argument of `($)', namely `foldM next start ds' > Failed, modules loaded: none. > }}} > > When one elides the type signature the program compiles yielding the > offending signature: > {{{ > Prelude> :r > [1 of 1] Compiling Main ( GHC-Bug.hs, interpreted ) > Ok, modules loaded: Main. > *Main> :t isValid > isValid :: (Bug a) => [Depend a] -> Bool > }}} > > Compiler version: 6.9.20071105 > > Best regards, > Harald Holtmann (haskell@zeuxis.de) New description: This ticket collects a bunch of examples where GHC * Rejects a function with a type signature but, if the type signature is removed, accepts the function and infers precisely the type that was originally specified. * Accepts type signatures that are utterly ambiguous; that is, the function could never be called, or only in the presence of bizarre instance declarations. * Rejects definitions that clearly have a unique typing. Original example: the following programm does not compile: {{{ {-# LANGUAGE TypeFamilies #-} import Control.Monad import Data.Maybe class Bug s where type Depend s next :: s -> Depend s -> Maybe s start :: s isValid :: (Bug s) => [Depend s] -> Bool isValid ds = isJust $ foldM next start ds }}} Error: {{{ GHCi, version 6.9.20071105: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( GHC-Bug.hs, interpreted ) Bug.hs:13:39: Couldn't match expected type `Depend a' against inferred type `Depend s' Expected type: [Depend a] Inferred type: [Depend s] In the third argument of `foldM', namely `ds' In the second argument of `($)', namely `foldM next start ds' Failed, modules loaded: none. }}} When one elides the type signature the program compiles yielding the offending signature: {{{ Prelude> :r [1 of 1] Compiling Main ( GHC-Bug.hs, interpreted ) Ok, modules loaded: Main. *Main> :t isValid isValid :: (Bug a) => [Depend a] -> Bool }}} Compiler version: 6.9.20071105 Best regards, Harald Holtmann (haskell@zeuxis.de) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 11:53:15 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 11:45:25 2008 Subject: [GHC] #2874: Error message doesn't mention extension that is missing In-Reply-To: <044.244748ee082046ce491869b3d395636a@localhost> References: <044.244748ee082046ce491869b3d395636a@localhost> Message-ID: <053.240feeea6cdda73ee3ec9490d1e6c5e4@localhost> #2874: Error message doesn't mention extension that is missing ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Are you really using GHC 6.10? This is what I get: {{{ {-# LANGUAGE ScopedTypeVariables #-} -- Switch on 'forall' keyword module T2874 where f :: (forall a. a->a) -> Int f x = 3 }}} When I compile I see: {{{ bash-3.2$ ghc -c T2874.hs T2874.hs:5:0: Illegal polymorphic or qualified type: forall a. a -> a Perhaps you intended to use -XRankNTypes or -XRank2Types In the type signature for `f': f :: (forall a. a -> a) -> Int bash-3.2$ }}} which is fine. Can you give a test case? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 12:20:53 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 12:13:04 2008 Subject: [GHC] #2900: Confusing error message for monadic function with wrong number of arguments In-Reply-To: <042.cbd4b88a3fe2bde042fd065b7021c09a@localhost> References: <042.cbd4b88a3fe2bde042fd065b7021c09a@localhost> Message-ID: <051.5cc1504f1eef80c8903219dc14e26786@localhost> #2900: Confusing error message for monadic function with wrong number of arguments ----------------------------------------+----------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * cc: chak (added) * difficulty: => Unknown Comment: Good example! Sadly, it's quite awkward to fix. Here's what is happening. * GHC tries to make the type `Int -> m ()` look like `ty1 -> ty2 -> ty3` (to match the syntactic form of the LHS. * It's ''possible'' that the context `(MonadIO m)` might have, as a "superclass" the equality `m ~ (->) Int`. In that case we'd get `ty2 = Int`, `ty3 = ()`. * Because `m` might be elucidated by the context, GHC can't reject the result type `(m ())` right away. Instead it invents a fresh type variable alpha, and generates the contraint that `(m ~ (->) alpha)`, leaving the constraint to be solved later. * Now we go on to the RHS, and that gives a type error. What we really want here is to solve the first constraint "eagerly", and proceed only if it succeeds. The type checker isn't set up to do that at the moment, but this is an interesting example to bear in mind, thank you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 12:42:03 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 12:34:02 2008 Subject: [GHC] #2901: GHC crashes with "impossible happened ... RnEnv.lookupImportedName" if using DisambiguateRecordFields and qualifiers In-Reply-To: <050.9405f648f357f40a4eae06c7f56b7f1b@localhost> References: <050.9405f648f357f40a4eae06c7f56b7f1b@localhost> Message-ID: <059.09f17adf11a52edb41da7e3614323ed1@localhost> #2901: GHC crashes with "impossible happened ... RnEnv.lookupImportedName" if using DisambiguateRecordFields and qualifiers -------------------------+-------------------------------------------------- Reporter: spookylukey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------------+-------------------------------------------------- Comment (by spookylukey): Actually, the 'Foo.hs' file is not needed to reproduce the bug, just download Main.hs and attempt to open in ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 12:39:24 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 12:37:44 2008 Subject: [GHC] #2901: GHC crashes with "impossible happened ... RnEnv.lookupImportedName" if using DisambiguateRecordFields and qualifiers Message-ID: <050.9405f648f357f40a4eae06c7f56b7f1b@localhost> #2901: GHC crashes with "impossible happened ... RnEnv.lookupImportedName" if using DisambiguateRecordFields and qualifiers ------------------------+--------------------------------------------------- Reporter: spookylukey | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ------------------------+--------------------------------------------------- If you specify DisambiguateRecordFields as an option, and then try to use qualifiers for field names in a data constructor, GHC crashes like this: {{{ ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): RnEnv.lookupImportedName F.field{v} }}} See attached files for example -- simply do 'ghci Main.hs' to see the bug. This bug means that if you use field disambiguation in part of a module, you have to use it everywhere in that module. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 29 17:35:27 2008 From: trac at galois.com (GHC) Date: Mon Dec 29 17:27:32 2008 Subject: [GHC] #2902: Example where ghc 6.10.1 fails to optimize recursive instance function calls Message-ID: <047.82275b0f80fb63e95aa6dfb32e5bfe1f@localhost> #2902: Example where ghc 6.10.1 fails to optimize recursive instance function calls -------------------------------------+-------------------------------------- Reporter: Syzygies | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: class instance | Testcase: Os: MacOS X | Architecture: x86_64 (amd64) -------------------------------------+-------------------------------------- Using ghc 6.10.1, I get over a 3x performance boost on the attached toy example, by moving instance function definitions out of the instance declaration, so that recursive calls avoid the class dictionary. According to SPJ, ghc 6.10.1 is supposed to perform this optimization automatically. I am reporting it as a bug at his request, following a discussion on the glasgow-haskell-users@haskell.org list. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 30 06:35:10 2008 From: trac at galois.com (GHC) Date: Tue Dec 30 06:27:09 2008 Subject: [GHC] #2881: Basic Fibonacci function using Word causes ghci to panic. - 6.10.1 In-Reply-To: <045.420cfc29b1544ee41369697a28301360@localhost> References: <045.420cfc29b1544ee41369697a28301360@localhost> Message-ID: <054.144a3e939a42b6ed7a79699202c132c0@localhost> #2881: Basic Fibonacci function using Word causes ghci to panic. - 6.10.1 -------------------------------------+-------------------------------------- Reporter: axman6 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: panic Word fibonacci | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------------+-------------------------------------- Changes (by simonpj): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.10 branch Comment: Ah. It seems that GHC's bytecode lacks an instruction for comparing `Word` values, for use when discriminating among case alternatives. I'm going to assign this to Simon M to decide what to do: * Add a suitable byte code, or * Call a primop as a Haskell function (probably better; more general) What about string literals too? In general, it's bad that the bytecode generator just falls over; it'd be much better for it to say "I can't do X", and recover gracefully. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 30 08:17:29 2008 From: trac at galois.com (GHC) Date: Tue Dec 30 08:09:27 2008 Subject: [GHC] #2898: crash when interpreting In-Reply-To: <045.4b1c4995fd828c01fa73119237ba0b1d@localhost> References: <045.4b1c4995fd828c01fa73119237ba0b1d@localhost> Message-ID: <054.85ae65ccf743435d56cd51472a8a4c9b@localhost> #2898: crash when interpreting -------------------------+-------------------------------------------------- Reporter: nolrai | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown Old description: > when I interpret my file Utilities/ChoiceMonad.hs from ghci-haskline I > get the following message: > > [2 of 2][Compiling Utilities.ChoiceMonad ( Utilities/ChoiceMonad.hs, > interpreted ) > ghci-haskeline: panic! (the 'impossible' happened) > (GHC version 6.10.1 for i386-unknown-linux): > ByteCodeGen.schemeE: unhandled case > \ (@ a1{tv a1qQ} [sk] :: ghc-prim:GHC.Prim.*{(w) tc 34d}) > (@ b1{tv a1qR} [sk] :: ghc-prim:GHC.Prim.*{(w) tc 34d}) -> > case {tick (main:Utilities.ChoiceMonad, 169)}{v d1z7} [gid] > @ (ghc-prim:GHC.Prim.State#{(w) tc 32q} > ghc-prim:GHC.Prim.RealWorld{(w) tc 31E}) > {(a1{tv a1qQ} [sk] -> b1{tv a1qR} [sk]) > -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw} > m{tv aQH} [sk] a1{tv a1qQ} [sk] > -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw} > m{tv aQH} [sk] b1{tv a1qR} [sk]} > of (tick{v s29j} [lid] :: ghc-prim:GHC.Prim.State#{(w) tc 32q} > ghc-prim:GHC.Prim.RealWorld{(w) tc > 31E}) > { __DEFAULT -> > let { > sat_s20H{v} [lid] :: (a1{tv a1qQ} [sk] -> b1{tv a1qR} [sk]) > -> main:Utilities.LeafyTree.LeafyTree{tc > rfw} a1{tv a1qQ} [sk] > -> main:Utilities.LeafyTree.LeafyTree{tc > rfw} b1{tv a1qR} [sk] > [] > sat_s20H{v} [lid] = > base:GHC.Base.fmap{v r5G} [gid] > @ main:Utilities.LeafyTree.LeafyTree{tc rfw} > main:Utilities.LeafyTree.$f4{v rfq} [gid] > @ a1{tv a1qQ} [sk] > @ b1{tv a1qR} [sk] } in > let { > sat_s20F{v} [lid] :: (main:Utilities.LeafyTree.LeafyTree{tc rfw} > a1{tv a1qQ} [sk] > -> main:Utilities.LeafyTree.LeafyTree{tc > rfw} b1{tv a1qR} [sk]) > -> main:Utilities.ChoiceMonad.ChoiceT{tc > rJw} > m{tv aQH} [sk] a1{tv a1qQ} [sk] > -> main:Utilities.ChoiceMonad.ChoiceT{tc > rJw} > m{tv aQH} [sk] b1{tv a1qR} [sk] > [] > sat_s20F{v} [lid] = > main:Utilities.ChoiceMonad.inChoiceT{v rLn} [gid] > @ m{tv aQH} [sk] > @ a1{tv a1qQ} [sk] > @ b1{tv a1qR} [sk] > $dMonad1{v s20D} [lid] } in > base:GHC.Base..{v r4k} [gid] > @ (main:Utilities.LeafyTree.LeafyTree{tc rfw} a1{tv a1qQ} [sk] > -> main:Utilities.LeafyTree.LeafyTree{tc rfw} b1{tv a1qR} > [sk]) > @ (main:Utilities.ChoiceMonad.ChoiceT{tc rJw} > m{tv aQH} [sk] a1{tv a1qQ} [sk] > -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw} > m{tv aQH} [sk] b1{tv a1qR} [sk]) > @ (a1{tv a1qQ} [sk] -> b1{tv a1qR} [sk]) > sat_s20F{v} [lid] > sat_s20H{v} [lid] > } > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > but if i do "ghc --make Utilities/ChoiceMonad.hs" that works and I can > then load it with ghci-haskline, at least until I modify it and need to > compile again. New description: when I interpret my file Utilities/ChoiceMonad.hs from ghci-haskline I get the following message: {{{ [2 of 2][Compiling Utilities.ChoiceMonad ( Utilities/ChoiceMonad.hs, interpreted ) ghci-haskeline: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-unknown-linux): ByteCodeGen.schemeE: unhandled case \ (@ a1{tv a1qQ} [sk] :: ghc-prim:GHC.Prim.*{(w) tc 34d}) (@ b1{tv a1qR} [sk] :: ghc-prim:GHC.Prim.*{(w) tc 34d}) -> case {tick (main:Utilities.ChoiceMonad, 169)}{v d1z7} [gid] @ (ghc-prim:GHC.Prim.State#{(w) tc 32q} ghc-prim:GHC.Prim.RealWorld{(w) tc 31E}) {(a1{tv a1qQ} [sk] -> b1{tv a1qR} [sk]) -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw} m{tv aQH} [sk] a1{tv a1qQ} [sk] -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw} m{tv aQH} [sk] b1{tv a1qR} [sk]} of (tick{v s29j} [lid] :: ghc-prim:GHC.Prim.State#{(w) tc 32q} ghc-prim:GHC.Prim.RealWorld{(w) tc 31E}) { __DEFAULT -> let { sat_s20H{v} [lid] :: (a1{tv a1qQ} [sk] -> b1{tv a1qR} [sk]) -> main:Utilities.LeafyTree.LeafyTree{tc rfw} a1{tv a1qQ} [sk] -> main:Utilities.LeafyTree.LeafyTree{tc rfw} b1{tv a1qR} [sk] [] sat_s20H{v} [lid] = base:GHC.Base.fmap{v r5G} [gid] @ main:Utilities.LeafyTree.LeafyTree{tc rfw} main:Utilities.LeafyTree.$f4{v rfq} [gid] @ a1{tv a1qQ} [sk] @ b1{tv a1qR} [sk] } in let { sat_s20F{v} [lid] :: (main:Utilities.LeafyTree.LeafyTree{tc rfw} a1{tv a1qQ} [sk] -> main:Utilities.LeafyTree.LeafyTree{tc rfw} b1{tv a1qR} [sk]) -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw} m{tv aQH} [sk] a1{tv a1qQ} [sk] -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw} m{tv aQH} [sk] b1{tv a1qR} [sk] [] sat_s20F{v} [lid] = main:Utilities.ChoiceMonad.inChoiceT{v rLn} [gid] @ m{tv aQH} [sk] @ a1{tv a1qQ} [sk] @ b1{tv a1qR} [sk] $dMonad1{v s20D} [lid] } in base:GHC.Base..{v r4k} [gid] @ (main:Utilities.LeafyTree.LeafyTree{tc rfw} a1{tv a1qQ} [sk] -> main:Utilities.LeafyTree.LeafyTree{tc rfw} b1{tv a1qR} [sk]) @ (main:Utilities.ChoiceMonad.ChoiceT{tc rJw} m{tv aQH} [sk] a1{tv a1qQ} [sk] -> main:Utilities.ChoiceMonad.ChoiceT{tc rJw} m{tv aQH} [sk] b1{tv a1qR} [sk]) @ (a1{tv a1qQ} [sk] -> b1{tv a1qR} [sk]) sat_s20F{v} [lid] sat_s20H{v} [lid] } Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} but if i do "ghc --make Utilities/ChoiceMonad.hs" that works and I can then load it with ghci-haskline, at least until I modify it and need to compile again. Comment: Excellent report thank you. What's happening is that `CorePrep` find an application of a strict function {{{ f (/\a. blah) ... }}} and transforms it to this: {{{ case (/\a. blah) of { DEFAULT -> ... } }}} If there had been a value lambda, then `mkLocalNonRec` would have generated a let, not a case. The unexpected type lambda confuses the code generator. In fact, since all code generators simply ignore type lambdas, there is no reason to disallow them, unlike value lambdas which are supposed to occur only on the RHS of let/recs. So I tidied up `ByteCodeGen` by systematically using a fucntion `bcView` (bytecode view) that discards casts, notes, type abstractions, and type applications. Result is shorter, more robust code. Patch to come. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 30 10:12:32 2008 From: trac at galois.com (GHC) Date: Tue Dec 30 10:04:28 2008 Subject: [GHC] #2898: crash when interpreting In-Reply-To: <045.4b1c4995fd828c01fa73119237ba0b1d@localhost> References: <045.4b1c4995fd828c01fa73119237ba0b1d@localhost> Message-ID: <054.efae12cef3d1c15ba15417e607877796@localhost> #2898: crash when interpreting -------------------------+-------------------------------------------------- Reporter: nolrai | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Fixed by {{{ Tue Dec 30 06:59:48 PST 2008 simonpj@microsoft.com * Tidy up treatment of big lambda (fixes Trac #2898) }}} Pls merge Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 30 10:13:23 2008 From: trac at galois.com (GHC) Date: Tue Dec 30 10:05:20 2008 Subject: [GHC] #2901: GHC crashes with "impossible happened ... RnEnv.lookupImportedName" if using DisambiguateRecordFields and qualifiers In-Reply-To: <050.9405f648f357f40a4eae06c7f56b7f1b@localhost> References: <050.9405f648f357f40a4eae06c7f56b7f1b@localhost> Message-ID: <059.d5e5201b74216333819eae139bab06d4@localhost> #2901: GHC crashes with "impossible happened ... RnEnv.lookupImportedName" if using DisambiguateRecordFields and qualifiers -----------------------------------------+---------------------------------- Reporter: spookylukey | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rename/should_fail/T2901 | Os: Linux Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonpj): * testcase: => rename/should_fail/T2901 * difficulty: => Unknown * type: bug => merge * owner: => igloo Comment: Fixed by {{{ Tue Dec 30 07:04:45 PST 2008 simonpj@microsoft.com * Refactor RnEnv to fix Trac #2901 }}} Pls merge Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 30 11:20:38 2008 From: trac at galois.com (GHC) Date: Tue Dec 30 11:12:38 2008 Subject: [GHC] #2888: Source file that compiled fine no longer compiles after touching it. In-Reply-To: <045.7d892b7ba37ca77835fa69178fb9751e@localhost> References: <045.7d892b7ba37ca77835fa69178fb9751e@localhost> Message-ID: <054.9193398425f5e1d3dc5082d4e5657b15@localhost> #2888: Source file that compiled fine no longer compiles after touching it. ---------------------------------+------------------------------------------ Reporter: Eelis- | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown Comment: Excellent bug. Patch coming. In fact, your class declaration is bogus, and will in future be rejected, because you have not given any type indices to D. You want {{{ class C a where { data D a :: * } }}} This wasn't the bug in GHC, mind you. If you are interested, read `Note [Avoid name clashes for associated data types]` in `TcHsType`. I've added a test T2888, but it simply tests the new error message when there are no type indices at all. I'm not sure it's worth the bother to set up a multi-module test to reproduce the original bug. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 30 12:05:11 2008 From: trac at galois.com (GHC) Date: Tue Dec 30 11:57:16 2008 Subject: [GHC] #2851: Improve error message for failed deriving In-Reply-To: <044.53dff063407021fb8c52e3be3626a0f5@localhost> References: <044.53dff063407021fb8c52e3be3626a0f5@localhost> Message-ID: <053.5680b93637d03e345f60b0704280f651@localhost> #2851: Improve error message for failed deriving -------------------------------------------+-------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_fail/T2851 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by simonpj): * testcase: => deriving/should_fail/T2851 * status: reopened => new * type: feature request => merge * owner: => igloo Comment: OK, I've done that {{{ Tue Dec 30 16:59:06 GMT 2008 simonpj@microsoft.com * Improve error message in deriving (fix Trac #2851) }}} The error now says: {{{ T2851.hs:8:14: No instance for (Show (F a)) arising from the 'deriving' clause of a data type declaration at T2851.hs:8:14-17 Possible fix: add an instance declaration for (Show (F a)) Alternative fix: use a standalone 'deriving instance' declaration instead, so you can specify the instance context yourself When deriving the instance for (Show (D a)) }}} Please merge. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 30 12:07:04 2008 From: trac at galois.com (GHC) Date: Tue Dec 30 11:59:02 2008 Subject: [GHC] #2888: Source file that compiled fine no longer compiles after touching it. In-Reply-To: <045.7d892b7ba37ca77835fa69178fb9751e@localhost> References: <045.7d892b7ba37ca77835fa69178fb9751e@localhost> Message-ID: <054.6504cb5dd163e3e572a65422edb2ddaf@localhost> #2888: Source file that compiled fine no longer compiles after touching it. ------------------------------------------------+--------------------------- Reporter: Eelis- | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: indexed-types/should_fail/T2888 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------------------+--------------------------- Changes (by simonpj): * testcase: => indexed-types/should_fail/T2888 * owner: simonpj => igloo * type: bug => merge Comment: Here's the patch: {{{ Tue Dec 30 16:44:32 GMT 2008 simonpj@microsoft.com * Avoid nasty name clash with associated data types (fixes Trac #2888) The main bug was in TcHsType; see Note [Avoid name clashes for associated data types]. However I did a bit of re-factoring while I was about it. }}} Not in the commit message (accidentally) but I added a test for empty type indices. Currently it's an error not a warning. Pls merge Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 30 13:27:14 2008 From: trac at galois.com (GHC) Date: Tue Dec 30 13:19:11 2008 Subject: [GHC] #2903: Incorrect length for CWStringLen on Win32 Message-ID: <047.0158a89ccdee21aca9b74548b424b8b7@localhost> #2903: Incorrect length for CWStringLen on Win32 ---------------------+------------------------------------------------------ Reporter: asklinge | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple ---------------------+------------------------------------------------------ The functions newCWStringLen and withCWStringLen return a CWStringLen with incorrect length on Win32 platform. The length returned is the length of the original Haskell String, but it should be the length of the UTF-16 encoded string (which may be longer if the original string contained any code points > 0xFFFF). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 31 00:53:40 2008 From: trac at galois.com (GHC) Date: Wed Dec 31 00:45:42 2008 Subject: [GHC] #2467: orphan instance warnings are badly behaved In-Reply-To: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> References: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> Message-ID: <054.685dc441538864c0b7443222f51409b9@localhost> #2467: orphan instance warnings are badly behaved ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by Syzygies): It came up in my code that I needed > instance Foldable ((,) a) where foldr f z (_,y) = f y z which is completely parallel to the Functor instance, but unlike the Functor instance is not provided by the standard libraries. There is no way that this instance can be anything but an orphan in my code (I shouldn't change Data.Foldable on a whim, it would make my code non-portable), so in this case I would argue that it is wrong for -Wall -Werror to abort compilation over this. I added -fno-warn-orphans, but that is a clunky fix which now deprives me of that warning when it might be relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 31 00:59:38 2008 From: trac at galois.com (GHC) Date: Wed Dec 31 00:52:50 2008 Subject: [GHC] #1673: Template Haskell support for type families In-Reply-To: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> References: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> Message-ID: <074.0df2a2548b5a7c119cadaa64ec28fda8@localhost> #1673: Template Haskell support for type families -------------------------------------------+-------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: feature request | Status: new Priority: low | Milestone: 6.10 branch Component: Template Haskell | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------------------+-------------------------------- Comment (by AndyGill): Having this is important to the kure-your-boilerplate work. It would save quite a bit of typing for KURE users. Any chance for 6.12? AndyG -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 31 04:03:38 2008 From: trac at galois.com (GHC) Date: Wed Dec 31 03:55:40 2008 Subject: [GHC] #2467: orphan instance warnings are badly behaved In-Reply-To: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> References: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> Message-ID: <054.6805d931948305994ce5c95ccff389c6@localhost> #2467: orphan instance warnings are badly behaved ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Indeed, your code is legitimate, and that's why warnings are just warnings! More concretely, what would you like? A special kind of warning that (uniquely) does not make -Werror abort the compilation? That seems a bit irregular... But perhaps you have something in mind. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 31 07:05:21 2008 From: trac at galois.com (GHC) Date: Wed Dec 31 06:57:18 2008 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@localhost> Message-ID: <060.b017fbad383b8229ef07792e1a5f5900@localhost> #2615: ghci doesn't play nice with linker scripts ---------------------------------+------------------------------------------ Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by maeder): * version: 6.8.3 => 6.10.1 Comment: This bug stops me from using template haskell (that uses ghci) and gtk in the sources for a cabal package. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 31 09:16:39 2008 From: trac at galois.com (GHC) Date: Wed Dec 31 09:08:36 2008 Subject: [GHC] #2846: Impredicativity bug: GHC crash by type signature In-Reply-To: <047.702be30b58ea1c05667f49195863703f@localhost> References: <047.702be30b58ea1c05667f49195863703f@localhost> Message-ID: <056.3f50ec1f5ba414ca26b52ee79fc59e96@localhost> #2846: Impredicativity bug: GHC crash by type signature ---------------------------------+------------------------------------------ Reporter: mm_freak | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: major | Resolution: Keywords: crash, type | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * summary: GHC crash by type signature => Impredicativity bug: GHC crash by type signature * milestone: 6.10.2 => 6.12 branch Comment: What's happening here is that `-fglasgow-exts` implies `-XImpredicativeTypes` and `-XFlexibleContexts`. Then we get a constraint `(Show [Num a => a])`, which should never happen. The impredicative machinery should not allow polymorphism in class constraints, but that check isn't implemented. The impredicative stuff needs a proper overhaul (Dimitrios is working on it) so I do not propose to tweak it now. But this should be fixed in due course. Meanwhile, I propose to '''stop''' `-fglasgow-exts` from implying `-XImpredicativeTypes`. I don't want to encourage use of impredicativity until it's working properly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 31 10:36:29 2008 From: trac at galois.com (GHC) Date: Wed Dec 31 10:28:29 2008 Subject: [GHC] #2467: orphan instance warnings are badly behaved In-Reply-To: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> References: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> Message-ID: <054.d87ac5baba9b640350c3c76a4fd33f6b@localhost> #2467: orphan instance warnings are badly behaved ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by Syzygies): Reflecting further, I noticed that these manual sections go together nicely: > 5.1.2. Command line options in source files > 5.6.12. Orphan modules and instance declarations In particular, the phrase stands out > in some circumstances, the OPTIONS_GHC pragma is the Right Thing. Moving ''-fno-warn-orphans'' from the command line to a particular orphan file is idiomatic GHC for my situation. I already have a module containing helper functions such as {{{ foldrC ? (Foldable d, Foldable e, Foldable f) ? (c a ? d (e (f a))) ? (a ? b ? b) ? b ? c a ? b foldrC gi h y = foldr (flip $ foldr (flip $ foldr h)) y . gi }}} for defining deep Foldable instances that go through a newtype and three layers of structure. {{{ instance Foldable ((,) a) where foldr f z (_,y) = f y z }}} can arise as one of those layers, so this is a natural place to put such orphans. Instance declarations are just as hard on the programmer as on GHC itself. For example, ''Functor ((,) a)'' is documented in Control.Monad, but importing Control.Monad doesn't expose this instance. ''Functor ((,) a)'' is not documented in Data.Foldable, but importing Data.Foldable does expose this instance. This left me perplexed as to why I could define deep Functor instances that relied on ''Functor ((,) a)'', but I couldn't write ''foldr (+) 2 (1,2)'' in ghci. I was left believing that this was some compiler magic I didn't understand, until I started using ''ghc --show- iface'', and spelunking the library source code. If I could have one wish related to instance declarations, it wouldn't have to do with these orphan warnings, but rather with better control over duplicate instance declarations. For example, I can't import Data.Foldable and at the same time try to redefine ''instance Monad ((->) a)''; there is no ''hiding'' clause that affects instances. Perhaps this is a moot point, as I have yet to find a standard library instance that has a reasonable alternative definition. One can imagine Haskell' providing missing instances anytime it can prove that there is only one possible definition. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 31 10:59:12 2008 From: trac at galois.com (GHC) Date: Wed Dec 31 10:51:18 2008 Subject: [GHC] #2856: GeneralizedNewtypeDeriving doesn't work with data families In-Reply-To: <044.b28574462f0debc35277b395a6c8b810@localhost> References: <044.b28574462f0debc35277b395a6c8b810@localhost> Message-ID: <053.5667c06efb1a9d0739417457a3d1ed1f@localhost> #2856: GeneralizedNewtypeDeriving doesn't work with data families ----------------------------------------------+----------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_compile/T2856 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------------+----------------------------- Changes (by simonpj): * testcase: => deriving/should_compile/T2856 * difficulty: => Unknown * type: bug => merge * owner: chak => igloo Comment: Good point, thank you. Fixed by {{{ Wed Dec 31 14:41:51 GMT 2008 simonpj@microsoft.com * Fix Trac #2856: make deriving work for type families }}} Merge this only if it's easy. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 31 11:02:00 2008 From: trac at galois.com (GHC) Date: Wed Dec 31 10:53:59 2008 Subject: [GHC] #2851: Improve error message for failed deriving In-Reply-To: <044.53dff063407021fb8c52e3be3626a0f5@localhost> References: <044.53dff063407021fb8c52e3be3626a0f5@localhost> Message-ID: <053.50024dd13e27c63b0782ea934840fd2d@localhost> #2851: Improve error message for failed deriving -------------------------------------------+-------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_fail/T2851 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Comment (by simonpj): PS: I did a bit more, because the previous patch suggested the same fix for overlapping instances, which is misleading {{{ Wed Dec 31 06:35:21 PST 2008 simonpj@microsoft.com * Improve error reporting for 'deriving' }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 31 11:12:28 2008 From: trac at galois.com (GHC) Date: Wed Dec 31 11:05:17 2008 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.d0d97a5420dc09e6b610226b5ff40828@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.10 branch Component: Compiler (Type checker) | Version: 6.7 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Comment (by simonpj): See #2721 for another example. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 31 11:33:18 2008 From: trac at galois.com (GHC) Date: Wed Dec 31 11:25:11 2008 Subject: [GHC] #2721: Newtype deriving doesn't work with type families In-Reply-To: <041.2b37e78c0fdcc1135c0e600ca8b06d99@localhost> References: <041.2b37e78c0fdcc1135c0e600ca8b06d99@localhost> Message-ID: <050.035983fb5c342e22ac23e9186ec0a22a@localhost> #2721: Newtype deriving doesn't work with type families -------------------------------------------+-------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_fail/T2721 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by simonpj): * testcase: => deriving/should_fail/T2721 Old description: > This assumes `-XTypeFamiles -XGeneralizedNewtypeDeriving`. Example: > {{{ > class C a where > type T a > foo :: a -> T a > > instance C Int where > type T Int = Int > foo = id > > newtype N = N Int deriving(C) > }}} > This happily produces an `instance C N` but no `type instance T N`. It > should either (preferably) generate > {{{ > type instance T N = Int > }}} > or fail. The example also compiles if `T` is a data family (the `Int` > instance needs to be change accordingly). It should probably fail in this > case. > > BTW, this also compiles fine, with rather dramatic consequences: > {{{ > type family T a > class C a where > foo :: a -> T a > > type instance T Int = Int > instance C Int where > foo = id > > type instance T N = Double > newtype N = N Int deriving(C) > }}} > I guess this last example is the same bug as `#1496`. I wonder if the > deriving clause could generate something like: > {{{ > instance T Int ~ T N => C Int > }}} New description: This assumes `-XTypeFamiles -XGeneralizedNewtypeDeriving`. Example: {{{ class C a where type T a foo :: a -> T a instance C Int where type T Int = Int foo = id newtype N = N Int deriving(C) }}} This happily produces an `instance C N` but no `type instance T N`. It should either (preferably) generate {{{ type instance T N = Int }}} or fail. The example also compiles if `T` is a data family (the `Int` instance needs to be change accordingly). It should probably fail in this case. BTW, this also compiles fine, with rather dramatic consequences: {{{ type family T a class C a where foo :: a -> T a type instance T Int = Int instance C Int where foo = id type instance T N = Double newtype N = N Int deriving(C) }}} I guess this last example is the same bug as #1496. I wonder if the deriving clause could generate something like: {{{ instance T Int ~ T N => C Int }}} Comment: Good point. For now I'm just going to make it fail. It's quite a bit more work to make it generate the extra instance, and the fact that it does not work at all for 'data' convinced me. It's annoying that you therefore cannot do newtype-deriving for a class with an associated type. An alternative is to allow top-level declarations for associated types, and check that these exist when doing the instance decl. So this would be valid: {{{ class C a where type T a op :: a -> T a type instance T Int = Bool instance C Int where op x = True }}} So I'll leave this open to record the idea, but meanwhile I'll push a patch to make it fail uniformly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 31 11:37:36 2008 From: trac at galois.com (GHC) Date: Wed Dec 31 11:29:36 2008 Subject: [GHC] #2904: Broken pipe when quitting "ghc --show-iface file.hi | less" Message-ID: <047.1dde102b30eaac69c74e2b5b730d160f@localhost> #2904: Broken pipe when quitting "ghc --show-iface file.hi | less" -----------------------------+---------------------------------------------- Reporter: Syzygies | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: trivial Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Here is an example of a very minor rough edge in ghc: {{{ % ghc --show-iface Matrix.hi | less ghc: : hFlush: resource vanished (Broken pipe) }}} If one quits ''less'' before reading all the output (a likely scenario), one sees this predictable error message. I'd argue that one should suppress this message, so users learn to pay attention to the messages they do see. A work-around is {{{ % ghc --show-iface Matrix.hi 2> /dev/null | less }}} but this suppresses other messages one might want to see. My attempts at a more precise work-around get me into "damned if you do, damned if you don't" territory. For example, {{{ % (ghc --show-iface Matrix.hi 2| grep -v 'Broken') | less }}} doesn't work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 31 11:45:11 2008 From: trac at galois.com (GHC) Date: Wed Dec 31 11:37:04 2008 Subject: [GHC] #2721: Newtype deriving doesn't work with type families In-Reply-To: <041.2b37e78c0fdcc1135c0e600ca8b06d99@localhost> References: <041.2b37e78c0fdcc1135c0e600ca8b06d99@localhost> Message-ID: <050.68c5ed756e090ff054f475e1d4c27573@localhost> #2721: Newtype deriving doesn't work with type families -------------------------------------------+-------------------------------- Reporter: rl | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.10.2 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: deriving/should_fail/T2721 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by simonpj): * owner: => igloo * type: bug => merge Comment: This is the patch {{{ Wed Dec 31 16:43:00 GMT 2008 simonpj@microsoft.com * Fix Trac #2721: reject newtype deriving if the class has associated types }}} Pls merge; then leave the ticket open as feature request for 6.12 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 31 20:44:59 2008 From: trac at galois.com (GHC) Date: Wed Dec 31 20:37:00 2008 Subject: [GHC] #2467: orphan instance warnings are badly behaved In-Reply-To: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> References: <045.75a28e8407597d8ed7d594d8f7eb5b3c@localhost> Message-ID: <054.9c2e191718482059807e02d1639c4ad9@localhost> #2467: orphan instance warnings are badly behaved ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by ross): Replying to [comment:7 Syzygies]: > It came up in my code that I needed > > > instance Foldable ((,) a) where foldr f z (_,y) = f y z > > which is completely parallel to the Functor instance, but unlike the Functor instance is not provided by the standard libraries. > > There is no way that this instance can be anything but an orphan in my code (I shouldn't change Data.Foldable on a whim, it would make my code non-portable), so in this case I would argue that it is wrong for -Wall -Werror to abort compilation over this. I added -fno-warn-orphans, but that is a clunky fix which now deprives me of that warning when it might be relevant. The compiler is right: the instance is an orphan, and it's right to warn about it, because orphan instances are inevitably a pain. The orphan instances of Monad and Functor for Prelude type constructors (which you noted) are a case in point; unfortunately they had to be orphans to avoid breaking compatibility with Haskell 98. The right fix in this case is to get the above instance (and one for Either, and Traversable instances for (,) and Either) into Data.Foldable and Data.Traversable. Unfortunately that won't help you until next September/October (and will give you a messy changeover then). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 31 23:25:11 2008 From: trac at galois.com (GHC) Date: Wed Dec 31 23:17:05 2008 Subject: [GHC] #2905: require -XGADTs in order to pattern-match GADTs Message-ID: <044.e288cc24bdc7d119176c55c76be624e8@localhost> #2905: require -XGADTs in order to pattern-match GADTs -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: proposal | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Without -XGADTs, pattern-matching GADTs causes weird typechecking problems (due to the lack of implied -XRelaxedPolyRec), see this thread http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/16064 , and some history in bug #2004 I propose that pattern-matching against any constructor that uses sufficient GADT features that it's particularly confused without -XRelaxedPolyRec, should require -XGADTs (I don't understand the issue well enough to know if what I'm saying makes sense. I guess ordinary data and mere existentials don't need it, even when defined with GADT syntax...?) Alternately we could just require -XRelaxedPolyRec, but that seems even more confusing (and it wouldn't help make code portable to other compilers, as GADTs are definitely being used). Or if Haskell-prime ever comes around and makes -XRelaxedPolyRec default (is it planning to?), then the issue might be moot. I don't think the argument (against requiring -XGADTs) by parallel to -XOverlappingInstances is particularly strong... -XOverlappingInstances has an implicit effect on a module's class definitions... also I don't necessarily agree with that we made that decision for existing flags either :-) --Isaac Dupree -- Ticket URL: GHC The Glasgow Haskell Compiler