From trac at galois.com Sat Sep 1 02:55:41 2007 From: trac at galois.com (GHC) Date: Sat Sep 1 02:46:28 2007 Subject: [GHC] #1655: System.Posix.User.getGroupEntryForName incorrect error for non-existent group Message-ID: <071.fff4d5ebbea684844bcaa9075daa149e@localhost> #1655: System.Posix.User.getGroupEntryForName incorrect error for non-existent group -----------------------------+---------------------------------------------- Reporter: Eelis | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/unix | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Os: Linux Testcase: | Architecture: x86_64 (amd64) -----------------------------+---------------------------------------------- The following program: {{{ import System.Posix.User main :: IO () main = getGroupEntryForName "monkeys" >> return () }}} gives the following output (on a system without a "monkeys" group): {{{ *** Exception: getGroupEntryForName: failed (Success) }}} The "(Success)" part is obviously wrong. The problem is that the getGroupEntryForName implementation throws errno if getgrnam_r wrote NULL to the pointer pointed to by its last parameter, while the [http://www.opengroup.org/onlinepubs/009695399/functions/getgrnam.html getgrnam_r specification] makes no guarantees about errno being set in that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 1 07:18:15 2007 From: trac at galois.com (GHC) Date: Sat Sep 1 07:08:54 2007 Subject: [GHC] #738: ghc can't load files with selinux Enforcing In-Reply-To: <071.33da88894e5515388ab442ae9f5b8cbd@localhost> References: <071.33da88894e5515388ab442ae9f5b8cbd@localhost> Message-ID: <080.82cb2626da98eca9c0faf38d5a3f82ad@localhost> #738: ghc can't load files with selinux Enforcing -------------------------------------------+-------------------------------- Reporter: jon.fairbairn@cl.cam.ac.uk | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: 6.6.2 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: selinux | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -------------------------------------------+-------------------------------- Comment (by panne): Remember that at some point we *do* need writeable and executable memory (for Haskell callbacks, see createAdjustor in Adjustor.c). There have been various attempts to fix problems related to newer security concepts, but obviously we are still not where we want to be. So the basic question is: How can we tell the underlying OS "It is OK for the GHC RTS to generate executable code?". How do other language implementations with e.g. JITs solve this problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 1 08:48:37 2007 From: trac at galois.com (GHC) Date: Sat Sep 1 08:39:17 2007 Subject: [GHC] #1226: Add flags --full-flag-help and --print-docdir In-Reply-To: <071.4bd494aa8d78319b1149135826956f8a@localhost> References: <071.4bd494aa8d78319b1149135826956f8a@localhost> Message-ID: <080.50c953804aae4a98d48a3320604add99@localhost> #1226: Add flags --full-flag-help and --print-docdir --------------------------------+------------------------------------------- Reporter: igloo | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.8 Component: Driver | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * priority: high => normal Comment: There's now a `--print-docdir` flag that prints where the docs are on the assumption that they exist. That's probably all we'll do for 6.8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 2 14:26:16 2007 From: trac at galois.com (GHC) Date: Sun Sep 2 14:16:51 2007 Subject: [GHC] #1656: Bignum exponentiation yields wrong results Message-ID: <071.a2c822d82ed40f41966c77ed157a366c@localhost> #1656: Bignum exponentiation yields wrong results ------------------------------------+--------------------------------------- Reporter: rvb@minet.uni-jena.de | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: major | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86_64 (amd64) ------------------------------------+--------------------------------------- I've used the following GHC program: main = print $ 9^9^9 The result was right in the number of digits (approx. 350 millions) but the last to digits are 94. By quick modular exponentiation, one finds out that 9^9^9 mod 100 = 89. So the number is obviously wrong. Looking further, at least the last 100 digits are wrong. I have redone the calculation with demo/calc/calc.c included in the distribution of the GNU gmp library. This yields a different number, that could be correct ( 89, but I don't know if it is otherwise correct) In both cases, the same libgmp3 shared object was used. But the GHC version constantly used 8 GiB of memory and four hours just for outputting the value in base 10, while the calculation of the value had been finished in about 5 minutes. demo/calc/calc.c used about 30 minutes for the whole job. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 2 14:27:07 2007 From: trac at galois.com (GHC) Date: Sun Sep 2 14:17:42 2007 Subject: [GHC] #1656: Bignum exponentiation yields wrong results In-Reply-To: <071.a2c822d82ed40f41966c77ed157a366c@localhost> References: <071.a2c822d82ed40f41966c77ed157a366c@localhost> Message-ID: <080.cf9dabb582eab1d9810035b29fc41301@localhost> #1656: Bignum exponentiation yields wrong results --------------------------------------+------------------------------------- Reporter: rvb@minet.uni-jena.de | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86_64 (amd64) | --------------------------------------+------------------------------------- Comment (by rvb@minet.uni-jena.de): Ok, ... that was meant to read {{{ main = print $ 9^9^9 }}} Hope that's better now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 2 14:35:25 2007 From: trac at galois.com (GHC) Date: Sun Sep 2 14:26:03 2007 Subject: [GHC] #1656: Bignum exponentiation yields wrong results In-Reply-To: <071.a2c822d82ed40f41966c77ed157a366c@localhost> References: <071.a2c822d82ed40f41966c77ed157a366c@localhost> Message-ID: <080.8bc63481dd668cea262e141d181be823@localhost> #1656: Bignum exponentiation yields wrong results --------------------------------------+------------------------------------- Reporter: rvb@minet.uni-jena.de | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86_64 (amd64) | --------------------------------------+------------------------------------- Comment (by rvb@minet.uni-jena.de): Ok, both the GHC calculated number and the C calculated one have exactly 369693101 digits. So the GHC computed number is probably not just truncated. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 2 15:30:55 2007 From: trac at galois.com (GHC) Date: Sun Sep 2 15:21:31 2007 Subject: [GHC] #1656: Bignum exponentiation yields wrong results In-Reply-To: <071.a2c822d82ed40f41966c77ed157a366c@localhost> References: <071.a2c822d82ed40f41966c77ed157a366c@localhost> Message-ID: <080.19a066019e827d25c4eb61cdf2b2ea0c@localhost> #1656: Bignum exponentiation yields wrong results --------------------------------------+------------------------------------- Reporter: rvb@minet.uni-jena.de | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86_64 (amd64) | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: => 6.8 Comment: Thanks for the report. This reminds me of #867, but that is fixed in 6.6. Unfortunately I don't have 8G of RAM, so reproducing this is non-trivial. I tried with some smaller examples, but couldn't reproduce it. If anyone has a smaller example then please let us know, but of course it's possible that it is only when >2G of RAM is being used that problems happen. Thanks Ian -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 2 16:07:58 2007 From: trac at galois.com (GHC) Date: Sun Sep 2 15:58:34 2007 Subject: [GHC] #1656: Bignum exponentiation yields wrong results In-Reply-To: <071.a2c822d82ed40f41966c77ed157a366c@localhost> References: <071.a2c822d82ed40f41966c77ed157a366c@localhost> Message-ID: <080.0fc658d0408a35975bf4a14c8f405ba0@localhost> #1656: Bignum exponentiation yields wrong results --------------------------------------+------------------------------------- Reporter: rvb@minet.uni-jena.de | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86_64 (amd64) | --------------------------------------+------------------------------------- Comment (by rvb@minet.uni-jena.de): I neither have 8G of RAM. (that's why it took so long, constantiously swapping) {{{ dd if=/dev/zero of=swap count=20000000 # 10G mkswap swap sapon swap }}} Unfortunately, it takes some hours this way. I am just redoing the computation during the night to see if the error is reproducible. But maybe you can come up with an example which is only a few bigger than 2GiB. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 2 16:42:05 2007 From: trac at galois.com (GHC) Date: Sun Sep 2 16:32:40 2007 Subject: [GHC] #1657: throwTo + unsafeInterleaveIO oddness Message-ID: <071.b05f702f040214a444fbf8b30e9f78ec@localhost> #1657: throwTo + unsafeInterleaveIO oddness -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86 -----------------------------+---------------------------------------------- I suspect this is related/dup of #418 but it's biting me with something I've been doing, so here's another test case. I have a long-running computation which returns a list which I then consume. I'm working on a visualizer app, where I want to update the visualizer in real-time while running the computation. I wrote some glue which takes the list and computes it in a background thread, returning a piece every X microseconds. Code will be attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 2 20:08:21 2007 From: trac at galois.com (GHC) Date: Sun Sep 2 19:58:56 2007 Subject: [GHC] #1658: CSE changes semantics Message-ID: <071.8019f42e2360edbba02c9abad11f2258@localhost> #1658: CSE changes semantics -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Os: Multiple Testcase: | Architecture: Multiple -----------------------+---------------------------------------------------- Create file: main = print $ 1/0 - 1/0 Compile with -O0, it outputs: NaN Compile with -O1, it outputs: 0.0 Compile with -O1 -fno-cse, it outputs: NaN -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 03:16:13 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 03:06:47 2007 Subject: [GHC] #1656: Bignum exponentiation yields wrong results In-Reply-To: <071.a2c822d82ed40f41966c77ed157a366c@localhost> References: <071.a2c822d82ed40f41966c77ed157a366c@localhost> Message-ID: <080.c7bb1c8126d4b6352a06e0f23cca17f8@localhost> #1656: Bignum exponentiation yields wrong results --------------------------------------+------------------------------------- Reporter: rvb@minet.uni-jena.de | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86_64 (amd64) | --------------------------------------+------------------------------------- Comment (by rvb@minet.uni-jena.de): This time, I got the same result as with C+gmp, but used a different program: {{{ power acc _ 0 = acc power acc x n | odd n = power (x * acc) (x * x) ((n - 1) `div` 2) | even n = power acc (x * x) (n `div` 2) main = let (^^^) = power 1 in do writeFile "myresult" . show $ 9 ^^^ (9 ^^^ 9) }}} Note: this time I used writeFile directly instead of print and redirecting the output, and I am using an exponentiation algorithm different from the one in the base library. Although I don't see why that would lead to different results. (I haven't looked at the base one very much) I'll try once again with writeFile and the builtin ^, to see whether print and redirection messed with my number. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 04:42:31 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 04:33:05 2007 Subject: [GHC] #1190: base:System.Posix.Signals is empty on Windows In-Reply-To: <071.5d663bc584bb71d515b51069ce7dc464@localhost> References: <071.5d663bc584bb71d515b51069ce7dc464@localhost> Message-ID: <080.4959c5396f24b8deb5f7a1d02fea6220@localhost> #1190: base:System.Posix.Signals is empty on Windows -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------------+-------------------------------------------- Changes (by simonmar): * resolution: => fixed * status: new => closed Comment: Ian did this in 6.8 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 05:05:03 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 04:55:36 2007 Subject: [GHC] #1038: selector thunks not working? space leak in standard example In-Reply-To: <071.0880400400aca4277be1db1a2c937e43@localhost> References: <071.0880400400aca4277be1db1a2c937e43@localhost> Message-ID: <080.ac9489021d0076f47fd1cf50a26693ef@localhost> #1038: selector thunks not working? space leak in standard example -----------------------------------+---------------------------------------- Reporter: tullsen@galois.com | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: x86 | -----------------------------------+---------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: Patch attached. I'm not going to push this until after 6.8.1, as it needs plenty of testing. For 6.8.1 I'm going to simply bump the depth limit for selector thunks, which also makes the example run in constant space, though more slowly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 06:09:08 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 05:59:41 2007 Subject: [GHC] #1623: ghci: 20 wakeups per second In-Reply-To: <071.943b8784fb882f26b4a9958204f2994d@localhost> References: <071.943b8784fb882f26b4a9958204f2994d@localhost> Message-ID: <080.f04522593a7553ef7585a7e36f1813cd@localhost> #1623: ghci: 20 wakeups per second -------------------------------+-------------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'm doing this -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 06:25:28 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 06:16:01 2007 Subject: [GHC] #1657: throwTo + unsafeInterleaveIO oddness In-Reply-To: <071.b05f702f040214a444fbf8b30e9f78ec@localhost> References: <071.b05f702f040214a444fbf8b30e9f78ec@localhost> Message-ID: <080.acdbd41d00833262aa9bd232f9f1680a@localhost> #1657: throwTo + unsafeInterleaveIO oddness -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by guest): * cc: => ryani.spam@gmail.com Comment: I just realized I didn't really describe what the bug actually is :) If the "throwTo" happens while the system in in a particular state (it seems to happen most often while the evaluation is printing something), then the exception gets embedded into the computation in progress and re- sent every time that computation is resumed, so a single throwTo causes the computation not to be resumable. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 09:17:30 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 09:08:04 2007 Subject: [GHC] #1648: ghci linker does not know about rts_getWord64 In-Reply-To: <071.5df3409d3d8ba3e9b3d06caf19429449@localhost> References: <071.5df3409d3d8ba3e9b3d06caf19429449@localhost> Message-ID: <080.0144d2664e79d1d628642b65b192b163@localhost> #1648: ghci linker does not know about rts_getWord64 -------------------------------+-------------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Runtime System | Version: 6.6.1 Severity: major | Resolution: Keywords: | Difficulty: Easy (1 hr) Os: Linux | Testcase: Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: validating a fix for this -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 09:19:34 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 09:10:07 2007 Subject: [GHC] #1659: Cabal build problem with GHC <= 6.4 Message-ID: <071.0056e34025859ecb7ccffafb8b5ed569@localhost> #1659: Cabal build problem with GHC <= 6.4 --------------------------------+------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8 Component: libraries (other) | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown --------------------------------+------------------------------------------- {{{ ghc-6.2.2 -H16m -O -I. -Iinclude -Rghc-timing -H32m -O -I../libraries -fglasgow-exts -no-recomp -c Distribution/Compat/Map.hs -o Distribution/Compat/Map.o -ohi Distribution/Compat/Map.hi ../libraries/Cabal/Distribution/Compat/Map.hs:68: Inferred type is less polymorphic than expected Quantified type variable `b' is unified with another quantified type variable `k' When trying to generalise the type inferred for `difference' Signature type: forall k a b. (Ord k) => Map k a -> Map k b -> Map k a Type to generalise: Map k a -> Map k k -> Map k a When checking the type signature for `difference' When generalising the type(s) for `difference' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 10:03:49 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 09:54:22 2007 Subject: [GHC] #1659: Cabal build problem with GHC <= 6.4 In-Reply-To: <071.0056e34025859ecb7ccffafb8b5ed569@localhost> References: <071.0056e34025859ecb7ccffafb8b5ed569@localhost> Message-ID: <080.c400bc38d145869d73c81bf23956042b@localhost> #1659: Cabal build problem with GHC <= 6.4 ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.8 Component: libraries (other) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'm validating a fix -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 10:17:52 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 10:08:25 2007 Subject: [GHC] #1658: CSE changes semantics In-Reply-To: <071.8019f42e2360edbba02c9abad11f2258@localhost> References: <071.8019f42e2360edbba02c9abad11f2258@localhost> Message-ID: <080.8b40dbcc0cb8a0a28e13c098f9231f78@localhost> #1658: CSE changes semantics -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | -------------------------+-------------------------------------------------- Comment (by guest): Someone must have added rewrite rules for floating point assuming they have sensible properties. That's not the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 10:31:10 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 10:21:42 2007 Subject: [GHC] #1648: ghci linker does not know about rts_getWord64 In-Reply-To: <071.5df3409d3d8ba3e9b3d06caf19429449@localhost> References: <071.5df3409d3d8ba3e9b3d06caf19429449@localhost> Message-ID: <080.320746ab58e198150db0b797e0f030b1@localhost> #1648: ghci linker does not know about rts_getWord64 -------------------------------+-------------------------------------------- Reporter: duncan | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: Runtime System | Version: 6.6.1 Severity: major | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Os: Linux | Testcase: ffi019 Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * resolution: => fixed * testcase: => ffi019 * status: new => closed Comment: Fixed, thanks. {{{ Mon Sep 3 14:16:25 BST 2007 Simon Marlow * FIX #1648: rts_mkWord64 was missing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 10:32:20 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 10:22:53 2007 Subject: [GHC] #1623: ghci: 20 wakeups per second In-Reply-To: <071.943b8784fb882f26b4a9958204f2994d@localhost> References: <071.943b8784fb882f26b4a9958204f2994d@localhost> Message-ID: <080.83718ce98fa2e9343336235e00abd2e2@localhost> #1623: ghci: 20 wakeups per second -------------------------------+-------------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | -------------------------------+-------------------------------------------- Changes (by simonmar): * resolution: => fixed * status: new => closed Comment: Fixed: {{{ Mon Sep 3 06:25:23 PDT 2007 Simon Marlow * FIX #1623: disable the timer signal when the system is idle (threaded RTS only) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 10:35:27 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 10:25:59 2007 Subject: [GHC] #806: hGetBufNonBlocking doesn't work on Windows In-Reply-To: <071.6fdd7104c4a929cf285dec2625f1db25@localhost> References: <071.6fdd7104c4a929cf285dec2625f1db25@localhost> Message-ID: <080.3e32e2e4530bfd8f6dbe82e31ae4023f@localhost> #806: hGetBufNonBlocking doesn't work on Windows -------------------------------+-------------------------------------------- Reporter: titto@kamus.it | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: libraries/base | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Os: Windows | Testcase: hGetBuf001 Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: simonmar => Comment: I'm not going to fix this anytime soon, so remove my lock -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 10:37:11 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 10:27:44 2007 Subject: [GHC] #1372: Recompilation checker should consider package versions (and other factors) In-Reply-To: <071.e047166ac778d0984cec10f693b8b038@localhost> References: <071.e047166ac778d0984cec10f693b8b038@localhost> Message-ID: <080.a72f686ef121cf3a665ef3200d4cf2f9@localhost> #1372: Recompilation checker should consider package versions (and other factors) -------------------------+-------------------------------------------------- Reporter: bringert | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * priority: high => normal Comment: We're unlikely to do any more on this for 6.8 -- Ticket URL: GHC The Glasgow Haskell Compiler From Simon.Frankau at barclayscapital.com Mon Sep 3 11:07:09 2007 From: Simon.Frankau at barclayscapital.com (Simon.Frankau@barclayscapital.com) Date: Mon Sep 3 10:58:20 2007 Subject: Request for inline control of warning level Message-ID: <46C922AFEABBF842AEE63C02007F7F3A02BBBE3B@LDNPCMEU305VEUA.INTRANET.BARCAPINT.COM> OPTIONS_GHC pragmas allow warnings to be enabled or disabled for a particular file, but there are some limitations: * It doesn't override command-line settings (being tacked on the start, rather than the end, of the options lists, I believe) * It doesn't work on sections of the code, but rather the whole file. Warnings pragmas on many C++ compilers allow you to locally enable/disable warnings (and push/pop warning state), so that you can compile with full warnings and warnings-as-errors, and still do explicit warning-generating behaviour where you really want to. I think this would be a nice feature for GHC to have. It could be argued that it would just be preferable to fix your code so it generate warnings, but sometimes it just seems cleaner to actually write what you mean, and make the warnings system ignore it, and that option currently isn't available. Thanks, Simon Frankau. PS: I'm still mailing bugs/requests rather than using Trac, since my attempts to login with guest/guest don't seem to stick. I'm still guessing it's the proxy we have, but any thoughts on the matter would be appreciated. ------------------------------------------------------------------------ For important statutory and regulatory disclosures and more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ------------------------------------------------------------------------ From trac at galois.com Mon Sep 3 11:13:28 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 11:04:00 2007 Subject: [GHC] #1660: Can't make DLLs anymore Message-ID: <071.5cfdded7bcdd124f52472dc613c83e49@localhost> #1660: Can't make DLLs anymore ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Driver | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86 ----------------------+----------------------------------------------------- I'm trying to build a DLL on Windows, but the flag --mk-dll is gone. Instead there is a flag --shared, but it doesn't do the same thing. Furthermore, the flag --optdll to pass arguments to the DLL maker is gone. The documentation still refers to --mk-dll, btw. This is with the ghc-6.7.20070824 snapshot. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 11:15:19 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 11:05:52 2007 Subject: [GHC] #1661: Can't use FFI anymore. Message-ID: <071.fc74b1f88c2f85cff41bb04194c566be@localhost> #1661: Can't use FFI anymore. ---------------------------+------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Os: Windows Testcase: | Architecture: x86 ---------------------------+------------------------------------------------ I'm trying to use the ghc-6.7.20070824 snapshot on Windows, but it's impossible to use FFI because Rts.h includes gmp.h, and there is no gmp.h. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 11:16:23 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 11:06:55 2007 Subject: [GHC] #1660: Can't make DLLs anymore In-Reply-To: <071.5cfdded7bcdd124f52472dc613c83e49@localhost> References: <071.5cfdded7bcdd124f52472dc613c83e49@localhost> Message-ID: <080.24604f1dab47701553a9a4e74fce025d@localhost> #1660: Can't make DLLs anymore ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Driver | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | ------------------------+--------------------------------------------------- Changes (by guest): * cc: => lennart.augustsson@credit-suisse.com -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 11:17:49 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 11:08:22 2007 Subject: [GHC] #1601: ghc-6.6.1: internal error: evacuate: strange closure type 7600 In-Reply-To: <071.b5b480bd446ba6b822b4578a21f88d0e@localhost> References: <071.b5b480bd446ba6b822b4578a21f88d0e@localhost> Message-ID: <080.32dda3e4113ff09070f61cd75307efee@localhost> #1601: ghc-6.6.1: internal error: evacuate: strange closure type 7600 -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * resolution: => worksforme * status: new => closed Comment: On my x86/Ubuntu box with GHC 6.6 I didn't manage to compile all of kaya, but I did get past the Haskell bit, so I guess I can't reproduce the bug either, at least with this setup. This kind of error is often indicative of a hardware failure, so I'm closing it until/unless we can find a better repro case. -- Ticket URL: GHC The Glasgow Haskell Compiler From simonpj at microsoft.com Mon Sep 3 11:28:21 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Sep 3 11:18:56 2007 Subject: Request for inline control of warning level In-Reply-To: <46C922AFEABBF842AEE63C02007F7F3A02BBBE3B@LDNPCMEU305VEUA.INTRANET.BARCAPINT.COM> References: <46C922AFEABBF842AEE63C02007F7F3A02BBBE3B@LDNPCMEU305VEUA.INTRANET.BARCAPINT.COM> Message-ID: | OPTIONS_GHC pragmas allow warnings to be enabled or disabled for a | particular file, but there are some limitations: | | * It doesn't override command-line settings (being tacked on the start, | rather than the end, of the options lists, I believe) I don't think this is right -- or if it is, it's a bug. The OPTIONS_GHC stuff is supposed to override command-line opts | * It doesn't work on sections of the code, but rather the whole file. True, and it'd be great to give more local pragma control -- a good feature request. Someone might want to work out details of the programmer's eye view and make a Trac feature request Simon From trac at galois.com Mon Sep 3 11:32:38 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 11:23:12 2007 Subject: [GHC] #1660: Can't make DLLs anymore In-Reply-To: <071.5cfdded7bcdd124f52472dc613c83e49@localhost> References: <071.5cfdded7bcdd124f52472dc613c83e49@localhost> Message-ID: <080.a707e27ea914d54cf7c2563348075b55@localhost> #1660: Can't make DLLs anymore ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8 Component: Driver | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | ------------------------+--------------------------------------------------- Changes (by simonmar): * milestone: => 6.8 Comment: Clemens is working on this - the plan was to have `--mk-dll` restored to be a synonym for `-shared`. In what way does `-shared` not do the same thing for you? In a small test I did it produced a reasonable DLL, but I admit to not having much clue here. -- Ticket URL: GHC The Glasgow Haskell Compiler From Simon.Frankau at barclayscapital.com Mon Sep 3 11:42:03 2007 From: Simon.Frankau at barclayscapital.com (Simon.Frankau@barclayscapital.com) Date: Mon Sep 3 11:32:36 2007 Subject: Request for inline control of warning level In-Reply-To: Message-ID: <46C922AFEABBF842AEE63C02007F7F3A02BBBE3C@LDNPCMEU305VEUA.INTRANET.BARCAPINT.COM> Simon Peyton-Jones wrote: > Simon Frankau wrote: > | OPTIONS_GHC pragmas allow warnings to be enabled or disabled for a > | particular file, but there are some limitations: > | > | * It doesn't override command-line settings (being tacked on the > | start, rather than the end, of the options lists, I believe) > > I don't think this is right -- or if it is, it's a bug. The > OPTIONS_GHC stuff is supposed to override command-line opts I'm afraid I read the documentation on this one. A quick test gives the impression that it's actually sticking the warning flags on the end, rather than the start (at least in 6.6). However, this is at odds with the documentation: http://www.haskell.org/ghc/docs/latest/html/users_guide/using-ghc.html#s ource-file-options . Perhaps an update of the documentation is due? :) Cheers, Simon Frankau. ------------------------------------------------------------------------ For important statutory and regulatory disclosures and more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ------------------------------------------------------------------------ From trac at galois.com Mon Sep 3 11:43:14 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 11:33:47 2007 Subject: [GHC] #1660: Can't make DLLs anymore In-Reply-To: <071.5cfdded7bcdd124f52472dc613c83e49@localhost> References: <071.5cfdded7bcdd124f52472dc613c83e49@localhost> Message-ID: <080.fd6206dde956c4406a3a2db7d628816f@localhost> #1660: Can't make DLLs anymore ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8 Component: Driver | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | ------------------------+--------------------------------------------------- Comment (by guest): It's important to be able to pass a .def file to the DLL maker so you can control export and naming of symbols exactly. It seems that the new setup uses ld rather than dlltool to create the DLL, so I have no idea how to do this anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From simonmarhaskell at gmail.com Mon Sep 3 11:49:21 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Sep 3 11:39:59 2007 Subject: Request for inline control of warning level In-Reply-To: References: <46C922AFEABBF842AEE63C02007F7F3A02BBBE3B@LDNPCMEU305VEUA.INTRANET.BARCAPINT.COM> Message-ID: <46DC2D01.8050504@gmail.com> (I can't resist the opportunity to extend this conversation to 3 Simons :-) Simon Peyton-Jones wrote: > | OPTIONS_GHC pragmas allow warnings to be enabled or disabled for a > | particular file, but there are some limitations: > | > | * It doesn't override command-line settings (being tacked on the start, > | rather than the end, of the options lists, I believe) > > I don't think this is right -- or if it is, it's a bug. The OPTIONS_GHC stuff is supposed to override command-line opts The Users Guide says: NOTE: the contents of OPTIONS_GHC are prepended to the command-line options, so you do have the ability to override OPTIONS_GHC settings via the command line. So GHC is at least behaving as documented. > | * It doesn't work on sections of the code, but rather the whole file. > > True, and it'd be great to give more local pragma control -- a good feature request. Someone might want to work out details of the programmer's eye view and make a Trac feature request There's a ticket for it: http://hackage.haskell.org/trac/ghc/ticket/602 Cheers, Simon From trac at galois.com Mon Sep 3 12:15:06 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 12:05:40 2007 Subject: [GHC] #1661: Can't use FFI anymore. In-Reply-To: <071.fc74b1f88c2f85cff41bb04194c566be@localhost> References: <071.fc74b1f88c2f85cff41bb04194c566be@localhost> Message-ID: <080.74be587f1e57cae24ef3d67f0b750706@localhost> #1661: Can't use FFI anymore. -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8 Component: Build System | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => 6.8 Comment: This should already be fixed, but I'll wait for a more recent snapshot to build so we can check before closing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 13:58:06 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 13:48:41 2007 Subject: [GHC] #1658: CSE changes semantics In-Reply-To: <071.8019f42e2360edbba02c9abad11f2258@localhost> References: <071.8019f42e2360edbba02c9abad11f2258@localhost> Message-ID: <080.957ab0980597924e5d2398e993310da0@localhost> #1658: CSE changes semantics -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | -------------------------+-------------------------------------------------- Comment (by chevalier@alum.wellesley.edu): Right: GHC.Base contains the rule: {{{"x# -# x#" forall x#. x# -# x# = 0#}}} but (NaN - NaN) is NaN, not 0. That's why the bug only gets triggered when CSE is on: otherwise, the code isn't of the form (x - x). -Tim -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 14:04:21 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 13:54:55 2007 Subject: [GHC] #1658: CSE changes semantics In-Reply-To: <071.8019f42e2360edbba02c9abad11f2258@localhost> References: <071.8019f42e2360edbba02c9abad11f2258@localhost> Message-ID: <080.d34306b56ebcb53ce764894503c2c90e@localhost> #1658: CSE changes semantics -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | -------------------------+-------------------------------------------------- Comment (by sorear): That rule is correct - for all x# :: Int#, x# -# x# is 0#. Remember -# is only usable on integers. Double subtraction uses -##. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 14:05:43 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 13:56:18 2007 Subject: [GHC] #1658: CSE changes semantics In-Reply-To: <071.8019f42e2360edbba02c9abad11f2258@localhost> References: <071.8019f42e2360edbba02c9abad11f2258@localhost> Message-ID: <080.fc89a376c3a6ee2f7d840228607e6bea@localhost> #1658: CSE changes semantics -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | -------------------------+-------------------------------------------------- Changes (by sorear): * cc: => sorear -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 14:13:02 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 14:03:38 2007 Subject: [GHC] #1658: CSE changes semantics In-Reply-To: <071.8019f42e2360edbba02c9abad11f2258@localhost> References: <071.8019f42e2360edbba02c9abad11f2258@localhost> Message-ID: <080.6c87d9545faa4b5ecde73bce247fb95f@localhost> #1658: CSE changes semantics -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | -------------------------+-------------------------------------------------- Comment (by chevalier@alum.wellesley.edu): Ah, good catch. But there's an equivalent rule for Doubles, too: {{{"minusDouble x x" forall x#. (-##) x# x# = 0.0##}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 16:32:52 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 16:23:26 2007 Subject: [GHC] #1038: selector thunks not working? space leak in standard example In-Reply-To: <071.0880400400aca4277be1db1a2c937e43@localhost> References: <071.0880400400aca4277be1db1a2c937e43@localhost> Message-ID: <080.7713664675da72981e4946e2fdc53825@localhost> #1038: selector thunks not working? space leak in standard example -----------------------------------+---------------------------------------- Reporter: tullsen@galois.com | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: x86 | -----------------------------------+---------------------------------------- Changes (by guest): * cc: => kfrdbs@gmail.com -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 20:17:34 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 20:08:06 2007 Subject: [GHC] #1080: Arrows desguaring does not take account of bindings in patterns In-Reply-To: <071.d5ca1c35d76845f0df8e39088a1eb459@localhost> References: <071.d5ca1c35d76845f0df8e39088a1eb459@localhost> Message-ID: <080.800e3b404f681ee832cc25b330a27630@localhost> #1080: Arrows desguaring does not take account of bindings in patterns -------------------------+-------------------------------------------------- Reporter: simonpj | Owner: ross Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: arrowcase1 Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by ross): * resolution: => fixed * status: new => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 20:42:47 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 20:33:18 2007 Subject: [GHC] #1662: mistranslation of arrow notation Message-ID: <071.972b1a299187cdac7ca7b9bdd3393571@localhost> #1662: mistranslation of arrow notation --------------------------+------------------------------------------------- Reporter: ross | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: arrowrun004 | Architecture: Unknown --------------------------+------------------------------------------------- (Split from #1333) arrowrun004 has a core lint failure for all ways: {{{ *** Core Lint Errors: in result of Desugar *** : In the expression: >>>_aEC @ () @ () @ GHC.Base.Int >>>_aEC is out of scope *** Offending Program *** [...] Main.expr :: Main.ExprParser () GHC.Base.Int [] Main.expr = >>>_aEC @ () @ () @ GHC.Base.Int (arr_aEB [...] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 20:52:12 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 20:42:43 2007 Subject: [GHC] #1662: mistranslation of arrow notation In-Reply-To: <071.972b1a299187cdac7ca7b9bdd3393571@localhost> References: <071.972b1a299187cdac7ca7b9bdd3393571@localhost> Message-ID: <080.95e5b46f0b17186a16a96bfe778a08e8@localhost> #1662: mistranslation of arrow notation -------------------------+-------------------------------------------------- Reporter: ross | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: arrowrun004 Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by ross): The source program {{{ expr = proc () -> do x <- term -< () expr' -< x }}} is translated by the type checker to (simplified a bit): {{{ expr = proc (){(w) d 70} { arr{v aEB} [lid] = arr{v 01V} [gid] @ (BTParser{tc rdM} ESym{tc rdD}) $dArrow{v aEE} [lid] $dArrow{v aEE} [lid] = $f4{v rqS} [lid] @ ESym{tc rdD} >>>{v aEC} [lid] = (>>>{v 01W} [gid]) @ (BTParser{tc rdM} ESym{tc rdD}) $dArrow{v aEF} [lid] $dArrow{v aEF} [lid] = $dArrow{v aEE} [lid] first{v aED} [lid] = first{v 01X} [gid] @ (BTParser{tc rdM} ESym{tc rdD}) $dArrow{v aEG} [lid] $dArrow{v aEG} [lid] = $dArrow{v aEE} [lid] } -> do ((x{v aeB} [lid] :: Int{(w) tc 3J})) <- term{v rdq} [lid] -< (){(w) v 71} [gid] expr'{v rdo} [lid] -< x{v aeB} [lid] }}} These bindings ought not to be attached to the pattern of `proc`, because the scope of ''pat'' in `proc` ''pat'' `->` ''cmd'' is not the whole of ''cmd'' but only the subexpressions that are fed into arrows. The bindings should be placed outside the `proc` expression, so that they scope over the whole thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 20:57:25 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 20:47:55 2007 Subject: [GHC] #1333: core lint failures from arrow notation + HPC In-Reply-To: <071.be966384635925e3caaa2bbfc941b2c4@localhost> References: <071.be966384635925e3caaa2bbfc941b2c4@localhost> Message-ID: <080.084119f0d145d32be586d792f0342885@localhost> #1333: core lint failures from arrow notation + HPC -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: arrowrun001 arrowrun002 arrowrun003 Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by ross): * testcase: arrowrun001 arrowrun004 => arrowrun001 arrowrun002 arrowrun003 * summary: core lint failures in arrow tests => core lint failures from arrow notation + HPC Comment: Created a separate bug report (#1662) for arrowrun004, which is a different issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 21:03:20 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 20:53:52 2007 Subject: [GHC] #1662: mistranslation of arrow notation In-Reply-To: <071.972b1a299187cdac7ca7b9bdd3393571@localhost> References: <071.972b1a299187cdac7ca7b9bdd3393571@localhost> Message-ID: <080.de86c699457992f743909209c3ea553a@localhost> #1662: mistranslation of arrow notation ----------------------------------------+----------------------------------- Reporter: ross | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: arrowrun004 Architecture: Multiple | ----------------------------------------+----------------------------------- Changes (by ross): * architecture: Unknown => Multiple * component: Compiler => Compiler (Type checker) * milestone: => 6.8 * version: 6.6.1 => 6.7 * os: Unknown => Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 21:18:41 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 21:09:11 2007 Subject: [GHC] #1333: core lint failures from arrow notation + HPC In-Reply-To: <071.be966384635925e3caaa2bbfc941b2c4@localhost> References: <071.be966384635925e3caaa2bbfc941b2c4@localhost> Message-ID: <080.9c9197264bbcb19a9b193b04493777f3@localhost> #1333: core lint failures from arrow notation + HPC -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: arrowrun001 arrowrun002 arrowrun003 Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by ross): This input expression {{{ proc env -> do ~(Bl b) <- eval e1 -< env if b then eval e2 -< env else eval e3 -< env }}} is turned into this prior to desugaring: {{{ proc ((env{v auF} [lid] :: [(Id{tc rsH}, Val{tc rsD} a{tv awm} [sk])])) -> do ~(Bl{d rsF} ((b{v auH} [lid] :: Bool{(w) tc 3c}))) <- tick<34>(e1{v auB} [lid]tick<33>(e1{v auB} [lid]eval{v aAK} [lid] e1{v auB} [lid]) -< env{v auF} [lid]) tick<38>(b{v auH} [lid] e2{v auC} [lid] e3{v auD} [lid] if tick<35>(b{v auH} [lid]) then tick<36>(e2{v auC} [lid]eval{v aAO} [lid] e2{v auC} [lid]) -< env{v auF} [lid] else tick<37>(e3{v auD} [lid]eval{v aAR} [lid] e3{v auD} [lid]) -< env{v auF} [lid]) }}} This not legal in arrow notation, for which the bindings of a pattern in `do` notation are not in scope for the whole of subsequent statements, just the expressions to the right of {{{-<}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 3 21:30:44 2007 From: trac at galois.com (GHC) Date: Mon Sep 3 21:21:16 2007 Subject: [GHC] #1333: core lint failures from arrow notation + HPC In-Reply-To: <071.be966384635925e3caaa2bbfc941b2c4@localhost> References: <071.be966384635925e3caaa2bbfc941b2c4@localhost> Message-ID: <080.785969f53a05aa2bc2fdaf21f5cd89e0@localhost> #1333: core lint failures from arrow notation + HPC -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: arrowrun001 arrowrun002 arrowrun003 Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by ross): In the above example, the problematic variable is `auH`. The use in the condition of the `if` is OK; it's the one outside the `if` that is the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 04:05:27 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 03:55:58 2007 Subject: [GHC] #1333: core lint failures from arrow notation + HPC In-Reply-To: <071.be966384635925e3caaa2bbfc941b2c4@localhost> References: <071.be966384635925e3caaa2bbfc941b2c4@localhost> Message-ID: <080.b9d5eda2f1f969634b94e89f7d211f03@localhost> #1333: core lint failures from arrow notation + HPC -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: arrowrun001 arrowrun002 arrowrun003 Architecture: Unknown | -------------------------+-------------------------------------------------- Comment (by simonpj): Ross, Andy Thanks for investigating, Ross. Can you two work together to figure out together what is the Right Thing to do here? Ross knows arrows, Andy knows hpc. Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 04:22:34 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 04:13:06 2007 Subject: [GHC] #1658: CSE changes semantics In-Reply-To: <071.8019f42e2360edbba02c9abad11f2258@localhost> References: <071.8019f42e2360edbba02c9abad11f2258@localhost> Message-ID: <080.9636eca23aa997ab62c7b0c93b8e5137@localhost> #1658: CSE changes semantics -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | -------------------------+-------------------------------------------------- Comment (by simonpj): OK -- I guess we should just remove that rule (or rather comment it out with an explanation, so that someone doesn't just re-add it later!) Right? If so, would someone go ahead? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 04:23:32 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 04:14:02 2007 Subject: [GHC] #1660: Can't make DLLs anymore In-Reply-To: <071.5cfdded7bcdd124f52472dc613c83e49@localhost> References: <071.5cfdded7bcdd124f52472dc613c83e49@localhost> Message-ID: <080.f79112aafbf9a94bc074586ec557d767@localhost> #1660: Can't make DLLs anymore ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8 Component: Driver | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | ------------------------+--------------------------------------------------- Changes (by simonmar): * cc: lennart.augustsson@credit-suisse.com => lennart.augustsson@credit- suisse.com, Clemens Fruhwirth Comment: I believe you just add `foo.def` to the command line, and GHC will pass it to the linker. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 04:25:15 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 04:15:46 2007 Subject: [GHC] #1644: Problem with interface file (.hi) for a particular function In-Reply-To: <071.fa493524be55d4214471bd0c68820545@localhost> References: <071.fa493524be55d4214471bd0c68820545@localhost> Message-ID: <080.e104c7e5240dbd221ff7293dbc19fc36@localhost> #1644: Problem with interface file (.hi) for a particular function -------------------------------------------+-------------------------------- Reporter: daniel.j.larsson@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------------------------+-------------------------------- Comment (by simonpj): Daniel, OK. To progress, we still need to reproduce it. Can you give specific instructions? E.g. download package X from url Y, run program Z (attached), etc etc. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 04:28:48 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 04:19:21 2007 Subject: [GHC] #1651: panic when interactively evaluating expression with a family type In-Reply-To: <071.0d1b994aa7a8a202a6018c0a5f048c80@localhost> References: <071.0d1b994aa7a8a202a6018c0a5f048c80@localhost> Message-ID: <080.ac3a0d808aa03ff05b4d3cd1eedc9266@localhost> #1651: panic when interactively evaluating expression with a family type ----------------------------------------+----------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------------+----------------------------------- Comment (by chak): Fixed the panic as per SimonPJ's suggestion. The bogus missing instance error remains to be corrected. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 04:58:42 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 04:49:12 2007 Subject: [GHC] #1660: Can't make DLLs anymore In-Reply-To: <071.5cfdded7bcdd124f52472dc613c83e49@localhost> References: <071.5cfdded7bcdd124f52472dc613c83e49@localhost> Message-ID: <080.aff9cd26be991479bd9f797912de2b08@localhost> #1660: Can't make DLLs anymore ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.8 Component: Driver | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | ------------------------+--------------------------------------------------- Changes (by guest): * resolution: => fixed * status: new => closed Comment: It works to pass the .def file as a regular argument, so I'm closing this. The documentation should be updated. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 05:18:00 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 05:08:30 2007 Subject: [GHC] #1660: Can't make DLLs anymore In-Reply-To: <071.5cfdded7bcdd124f52472dc613c83e49@localhost> References: <071.5cfdded7bcdd124f52472dc613c83e49@localhost> Message-ID: <080.b7ac33c4751fb56a77ac945c51681276@localhost> #1660: Can't make DLLs anymore ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.8 Component: Driver | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | ------------------------+--------------------------------------------------- Comment (by simonmar): Thanks for testing this Lennart! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 05:40:31 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 05:31:01 2007 Subject: [GHC] #1663: Critical sections not deallocated Message-ID: <071.207d58bb3aa8b5467b5897f8d130f0b3@localhost> #1663: Critical sections not deallocated -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.7 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Os: Windows Testcase: | Architecture: x86 -----------------------------+---------------------------------------------- There's a number of critical sections in the Windows RTS that are allocated, but never freed (DeleteCriticalSection): {{{ ASyncIO.c: queue_lock IOManager.c: ioMan->manLock, ioMan->active_work_lock WorkQueue.c: wq->queueLock }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 07:09:17 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 06:59:48 2007 Subject: [GHC] #1656: Bignum exponentiation yields wrong results In-Reply-To: <071.a2c822d82ed40f41966c77ed157a366c@localhost> References: <071.a2c822d82ed40f41966c77ed157a366c@localhost> Message-ID: <080.f8fa8f34d3e4cd5097effc181dc820e8@localhost> #1656: Bignum exponentiation yields wrong results --------------------------------------+------------------------------------- Reporter: rvb@minet.uni-jena.de | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86_64 (amd64) | --------------------------------------+------------------------------------- Comment (by rvb@minet.uni-jena.de): I again failed to reproduce it. This time using my power function and print with shell redirection. For the next night, I'll just retry the original example to see if the bug is reproducible at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 08:11:44 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 08:02:17 2007 Subject: [GHC] #1644: Problem with interface file (.hi) for a particular function In-Reply-To: <071.fa493524be55d4214471bd0c68820545@localhost> References: <071.fa493524be55d4214471bd0c68820545@localhost> Message-ID: <080.5c9ca25c63ac2b8c256309ab1a006b6b@localhost> #1644: Problem with interface file (.hi) for a particular function -------------------------------------------+-------------------------------- Reporter: daniel.j.larsson@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------------------------+-------------------------------- Comment (by daniel.j.larsson@gmail.com): I'm running ghc 6.6.1 on Ubuntu gutsy, and here's what ghc-pkg reports: {{{ $ ghc-pkg list /usr/lib/ghc-6.6.1/package.conf: Cabal-1.1.3, Cabal-1.1.6.2, HAppS-0.8.8, HTTP-3000.0.1, HUnit-1.1.1, HaXml-1.13.2, LDAP-0.6.1, QuickCheck-1.0.1, X11-1.2.1, X11-extras-0.2, arrows-0.2.1, base-2.1.1, binary-0.3, cdr-1.0.0, fgl-5.4.1, filepath-1.0, generic-xml-0.1, (ghc-6.6.1), haskell-src-exts-0.2, haskell98-1.0, hslogger-1.0.2, hsql-1.6, hsql-mysql-1.6, hsql-postgresql-1.6, hsql-sqlite3-1.0, html-1.0.1, hxt-7.2, mtl-1.0.1, network-2.0.1, parsec-2.0, readline-1.0, regex-base-0.72, regex-compat-0.71, regex-posix-0.71, rts-1.0, sfhs-1.0.0, stm-2.0, syb-with-class-0.3, template-haskell-2.1, time-1.1.1, unix-2.1, vty-3.0.0, xhtml-3000.0.2 }}} I managed to cut down the problem to this: {{{ import Control.Arrow -- Nonsense function foo = first [second] main = do putStrLn $ foo 10 }}} Compiling this nonsense program fails with: {{{ $ ghc Test.hs Test.o: In function `s11w_info': (.text+0xde): undefined reference to `Main_foo_closure' Test.o: In function `s11w_srt': (.rodata+0x4): undefined reference to `Main_foo_closure' collect2: ld returned 1 exit status }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 08:46:37 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 08:37:06 2007 Subject: [GHC] #1644: Problem with interface file (.hi) for a particular function In-Reply-To: <071.fa493524be55d4214471bd0c68820545@localhost> References: <071.fa493524be55d4214471bd0c68820545@localhost> Message-ID: <080.18a36b6437d9c78dd41a44bd3f6be71c@localhost> #1644: Problem with interface file (.hi) for a particular function -------------------------------------------+-------------------------------- Reporter: daniel.j.larsson@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------------------------+-------------------------------- Comment (by simonmar): Perhaps you have a `Test.o` in the current directory that is confusing GHC? Try removing all `.o` and `.hi` files first. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 08:52:48 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 08:43:17 2007 Subject: [GHC] #1658: CSE changes semantics In-Reply-To: <071.8019f42e2360edbba02c9abad11f2258@localhost> References: <071.8019f42e2360edbba02c9abad11f2258@localhost> Message-ID: <080.09d14ce7b2f3bae78fee9438c89d40c1@localhost> #1658: CSE changes semantics -------------------------+-------------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | -------------------------+-------------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 09:39:15 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 09:29:45 2007 Subject: [GHC] #1644: Problem with interface file (.hi) for a particular function In-Reply-To: <071.fa493524be55d4214471bd0c68820545@localhost> References: <071.fa493524be55d4214471bd0c68820545@localhost> Message-ID: <080.1f3b41b8e48f33fdb463b44345739b5b@localhost> #1644: Problem with interface file (.hi) for a particular function -------------------------------------------+-------------------------------- Reporter: daniel.j.larsson@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------------------------+-------------------------------- Comment (by daniel.j.larsson@gmail.com): {{{ $ rm *.hi *.o $ ghc Test.hs Test.o: In function `s11w_info': (.text+0xde): undefined reference to `Main_foo_closure' Test.o: In function `s11w_srt': (.rodata+0x4): undefined reference to `Main_foo_closure' collect2: ld returned 1 exit status }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 09:46:07 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 09:36:38 2007 Subject: [GHC] #1644: Problem with interface file (.hi) for a particular function In-Reply-To: <071.fa493524be55d4214471bd0c68820545@localhost> References: <071.fa493524be55d4214471bd0c68820545@localhost> Message-ID: <080.603c603dd7cc04433f00a88092b8d3ae@localhost> #1644: Problem with interface file (.hi) for a particular function -------------------------------------------+-------------------------------- Reporter: daniel.j.larsson@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------------------------+-------------------------------- Comment (by daniel.j.larsson@gmail.com): Note that I didn't expect this code to actually compile. Also, try this in ghci: {{{ $ ghci ... Loading package base ... linking ... done. Prelude> :t Control.Arrow.first [Control.Arrow.second] Prelude> }}} I'm not getting any output at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 09:49:24 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 09:39:54 2007 Subject: [GHC] #1644: Problem with interface file (.hi) for a particular function In-Reply-To: <071.fa493524be55d4214471bd0c68820545@localhost> References: <071.fa493524be55d4214471bd0c68820545@localhost> Message-ID: <080.77984d9c0dee511a7a607f80b1d2a382@localhost> #1644: Problem with interface file (.hi) for a particular function -------------------------------------------+-------------------------------- Reporter: daniel.j.larsson@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------------------------+-------------------------------- Comment (by simonpj): Great test! You've localised it brilliantly. It's quite reproducible and utterly wrong. I'm investigating. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 10:35:46 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 10:26:17 2007 Subject: [GHC] #1644: Problem with interface file (.hi) for a particular function In-Reply-To: <071.fa493524be55d4214471bd0c68820545@localhost> References: <071.fa493524be55d4214471bd0c68820545@localhost> Message-ID: <080.fd524fb639359831cb1791b1453ec145@localhost> #1644: Problem with interface file (.hi) for a particular function -------------------------------------------+-------------------------------- Reporter: daniel.j.larsson@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------------------------+-------------------------------- Comment (by simonpj): Ah I vaguely remember this. The HEAD says: {{{ Foo8.hs:7:12: Couldn't match expected type `a b c' against inferred type `[a1]' In the first argument of `first', namely `['x']' In the expression: first ['x'] In the definition of `foo': foo = first ['x'] }}} which is right. (I changed `second` to `'x'` to simplify further.) The trouble with 6.6.1 is that it raises an exception without having any error messages in the set of errors, and that is most unexpected. I can't remember exactly which bug showed this in 6.6, or when it was fixed, but it certainly seems OK in the HEAD so I'm disinclined to pursue it further. Nevertheless the symptoms are most unhelpful, so I'll add a bit more error checking. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 11:21:34 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 11:12:04 2007 Subject: [GHC] #1644: Problem with interface file (.hi) for a particular function In-Reply-To: <071.fa493524be55d4214471bd0c68820545@localhost> References: <071.fa493524be55d4214471bd0c68820545@localhost> Message-ID: <080.8e0ec44128b3ae56c5ab04fcf4f08dec@localhost> #1644: Problem with interface file (.hi) for a particular function -------------------------------------------+-------------------------------- Reporter: daniel.j.larsson@gmail.com | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------------------------+-------------------------------- Comment (by daniel.j.larsson@gmail.com): Great! I'm happy enough with a fixed HEAD :). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 11:31:05 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 11:21:35 2007 Subject: [GHC] #1660: Can't make DLLs anymore In-Reply-To: <071.5cfdded7bcdd124f52472dc613c83e49@localhost> References: <071.5cfdded7bcdd124f52472dc613c83e49@localhost> Message-ID: <080.3e480a731d2156f705039e193ee50bfa@localhost> #1660: Can't make DLLs anymore ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: reopened Priority: high | Milestone: 6.8 Component: Driver | Version: 6.7 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Os: Windows | Testcase: Architecture: x86 | ------------------------+--------------------------------------------------- Changes (by clemens): * resolution: fixed => * severity: normal => minor * status: closed => reopened Comment: I was about to commit a patch that fixes the .def issue. We have to strip -Wl--export-all-symbols (or similar) from the gcc invocation (otherwise .def makes only limited sense). My intention was to update the ghc user manual along with it, but it doesn't fit into the "Windows stuff" section anymore, because ghc -shared is cross-platform. Where would this stuff go? Create a new chapter? Reopening ticket (feel free to bug me, if this still shows up unresolved in a month) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 11:34:34 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 11:25:05 2007 Subject: [GHC] #1658: CSE changes semantics In-Reply-To: <071.8019f42e2360edbba02c9abad11f2258@localhost> References: <071.8019f42e2360edbba02c9abad11f2258@localhost> Message-ID: <080.3196722468a4eea23ed4cbfdc2396de2@localhost> #1658: CSE changes semantics -------------------------+-------------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Multiple | Testcase: num014 Architecture: Multiple | -------------------------+-------------------------------------------------- Changes (by igloo): * resolution: => fixed * testcase: => num014 * status: new => closed Comment: I've added a test to the testsuite and removed 3 rules: {{{ This gives wrong answer (0) for NaN - NaN (should be NaN): "minusDouble x x" forall x#. (-##) x# x# = 0.0## This gives wrong answer (0) for 0 * NaN (should be NaN): "timesDouble 0.0 x" forall x#. (*##) 0.0## x# = 0.0## This gives wrong answer (0) for NaN * 0 (should be NaN): "timesDouble x 0.0" forall x#. (*##) x# 0.0## = 0.0## }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 11:47:12 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 11:37:41 2007 Subject: [GHC] #1644: Problem with interface file (.hi) for a particular function In-Reply-To: <071.fa493524be55d4214471bd0c68820545@localhost> References: <071.fa493524be55d4214471bd0c68820545@localhost> Message-ID: <080.513b68f74949e487ec24d30fe6695f27@localhost> #1644: Problem with interface file (.hi) for a particular function -------------------------------------------+-------------------------------- Reporter: daniel.j.larsson@gmail.com | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------------------------+-------------------------------- Changes (by simonpj): * resolution: => wontfix * status: new => closed Comment: OK, I'll close it as 'wontfix' for now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 4 17:30:59 2007 From: trac at galois.com (GHC) Date: Tue Sep 4 17:21:31 2007 Subject: [GHC] #1664: configure unsuccessful on binary build Message-ID: <071.cce95dec8ef71cfeb6574d221a74daf7@localhost> #1664: configure unsuccessful on binary build -----------------------------------------+---------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 6.7 Severity: blocker | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: x86 -----------------------------------------+---------------------------------- I tried to install the nightly snapshot of the file {{{ghc-6.7.20070820- i386-unknown-linux.tar.bz2}}}. I ran ./configure with just a --prefix option. I got the following output: {{{ checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu Which we'll further canonicalise into: i386-unknown-linux checking for path to top of build tree... ./configure: line 1433: cd: utils/pwd: No such file or directory ./configure: line 1438: -v0: command not found ./configure: line 1441: utils/pwd/pwd: No such file or directory configure: error: cannot determine current directory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 5 02:52:15 2007 From: trac at galois.com (GHC) Date: Wed Sep 5 02:42:44 2007 Subject: [GHC] #1656: Bignum exponentiation yields wrong results In-Reply-To: <071.a2c822d82ed40f41966c77ed157a366c@localhost> References: <071.a2c822d82ed40f41966c77ed157a366c@localhost> Message-ID: <080.936bec2dd81fc950f303ea77bdd3c9ba@localhost> #1656: Bignum exponentiation yields wrong results --------------------------------------+------------------------------------- Reporter: rvb@minet.uni-jena.de | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: major | Resolution: Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86_64 (amd64) | --------------------------------------+------------------------------------- Comment (by rvb@minet.uni-jena.de): Ok, it is not reprodicble, not even using the original program. This of course means, that nobody knows that has even caused the wrong calculation... whether it was GHC, libgmp, a bug in the kernel or the hardware, that might have been triggered by the heavy load or what else. Feel free to close the bug, then. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 5 07:33:55 2007 From: trac at galois.com (GHC) Date: Wed Sep 5 07:24:22 2007 Subject: [GHC] #1659: Cabal build problem with GHC <= 6.4 In-Reply-To: <071.0056e34025859ecb7ccffafb8b5ed569@localhost> References: <071.0056e34025859ecb7ccffafb8b5ed569@localhost> Message-ID: <080.fa31d05b8fd27942f320bf7a68d688be@localhost> #1659: Cabal build problem with GHC <= 6.4 ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.8 Component: libraries (other) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Comment (by simonmar): Fixed: {{{ Mon Sep 3 07:02:32 PDT 2007 Simon Marlow * make this buildable with GHC 6.2.x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 5 07:34:08 2007 From: trac at galois.com (GHC) Date: Wed Sep 5 07:24:35 2007 Subject: [GHC] #1659: Cabal build problem with GHC <= 6.4 In-Reply-To: <071.0056e34025859ecb7ccffafb8b5ed569@localhost> References: <071.0056e34025859ecb7ccffafb8b5ed569@localhost> Message-ID: <080.16b61c0da1a23ea596f3cd72ed1b5c4d@localhost> #1659: Cabal build problem with GHC <= 6.4 ----------------------------------+----------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.8 Component: libraries (other) | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Changes (by simonmar): * resolution: => fixed * status: new => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 5 08:15:26 2007 From: trac at galois.com (GHC) Date: Wed Sep 5 08:05:52 2007 Subject: [GHC] #1650: .boot modules interact badly with the ghci debugger In-Reply-To: <071.cc3c6143e16a80758ecd93b68d999fe7@localhost> References: <071.cc3c6143e16a80758ecd93b68d999fe7@localhost> Message-ID: <080.d6768b7cd5cf92877e8e3ac432a0c158@localhost> #1650: .boot modules interact badly with the ghci debugger -------------------------+-------------------------------------------------- Reporter: mnislaih | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.8 Component: GHCi | Version: 6.7 Severity: normal | Resolution: fixed Keywords: debugger | Difficulty: Unknown Os: Unknown | Testcase: break022 break023 Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * resolution: => fixed * status: new => closed Comment: Fixed: {{{ Wed Sep 5 11:47:16 BST 2007 Simon Marlow * FIX #1650: ".boot modules interact badly with the ghci debugger" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 5 08:24:20 2007 From: trac at galois.com (GHC) Date: Wed Sep 5 08:14:47 2007 Subject: [GHC] #1526: -fobject-code doesn't apply to expressions typed at the prompt In-Reply-To: <071.159d2e28686c8badf9268b69d2898da2@localhost> References: <071.159d2e28686c8badf9268b69d2898da2@localhost> Message-ID: <080.c9514d112e7512654081d75dab72ff9c@localhost> #1526: -fobject-code doesn't apply to expressions typed at the prompt -------------------------+-------------------------------------------------- Reporter: sorear | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * milestone: 6.8 => _|_ * summary: -fobject-code is ignored for interactive compilation => -fobject-code doesn't apply to expressions typed at the prompt -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 5 08:27:37 2007 From: trac at galois.com (GHC) Date: Wed Sep 5 08:18:03 2007 Subject: [GHC] #1629: Upgrade regex-base,compat,posix with GHC 6.8 In-Reply-To: <071.2fafec9572a8c7a048526931a5beb7d7@localhost> References: <071.2fafec9572a8c7a048526931a5beb7d7@localhost> Message-ID: <080.190d365b7a9536b75df62d355a0ffba1@localhost> #1629: Upgrade regex-base,compat,posix with GHC 6.8 ----------------------------------------------------------------+----------- Reporter: Chris Kuklewicz | Owner: Chris Kuklewicz Type: proposal | Status: new Priority: normal | Milestone: 6.8 Component: libraries (other) | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: Architecture: Multiple | ----------------------------------------------------------------+----------- Changes (by igloo): * owner: => Chris Kuklewicz Comment: Hi Chris, As discussed as while ago on IRC, now that the regex packages are not corelibs but extralibs, there's no need for the repo to follow the GHC release schedule. Please feel free to merge changes in as you think best. One other thing: It would make life simpler if we can tar up the code release with GHC, put it on hackage and then bump the version number in the repo (so we don't end up with two different 0.91 versions). Thanks Ian -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 5 08:33:42 2007 From: trac at galois.com (GHC) Date: Wed Sep 5 08:24:08 2007 Subject: [GHC] #1501: Panic in RegisterAlloc In-Reply-To: <071.21c0e810775eaa153e91f784170c58b2@localhost> References: <071.21c0e810775eaa153e91f784170c58b2@localhost> Message-ID: <080.4defa5318694f73f912eb97a344ceb67@localhost> #1501: Panic in RegisterAlloc -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: Compiler (NCG) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Multiple | Testcase: cmm002 Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * resolution: => fixed * status: new => closed Comment: I think the register allocator is confused because `x` is used without being assigned to, so the allocator doesn't think it's live. If you add an assignment to `x` it compiles without error. Furthermore, the new graph-colouring allocator handles this just fine, so I'm going to close the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 5 08:48:57 2007 From: trac at galois.com (GHC) Date: Wed Sep 5 08:39:24 2007 Subject: [GHC] #1500: NCG: shortcutBranch doesn't handle loops properly In-Reply-To: <071.57f121ecf80c0beb80c2817a63881ca0@localhost> References: <071.57f121ecf80c0beb80c2817a63881ca0@localhost> Message-ID: <080.5f24514edca5f4f7d911694a6b8b5f8b@localhost> #1500: NCG: shortcutBranch doesn't handle loops properly ---------------------------------+------------------------------------------ Reporter: Michael D. Adams | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 Component: Compiler (NCG) | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Os: Multiple | Testcase: cmm001 Architecture: x86 | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: 6.8 => 6.10 * summary: Infinite loop caused by Cmm => NCG: shortcutBranch doesn't handle loops properly Comment: The `shortcutBranch` optimisation in the NCG doesn't cope with loops very well. Fortunately this doesn't cause us any problems right now, because it hardly ever gets presented with any loops (only RTS code). In 6.10 the plan is to overhaul all this code anyway, so we'll fix this at the same time. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 5 10:26:14 2007 From: trac at galois.com (GHC) Date: Wed Sep 5 10:16:40 2007 Subject: [GHC] #738: ghc can't load files with selinux Enforcing In-Reply-To: <071.33da88894e5515388ab442ae9f5b8cbd@localhost> References: <071.33da88894e5515388ab442ae9f5b8cbd@localhost> Message-ID: <080.0e705cba18b9d77a31e4265f1629ce25@localhost> #738: ghc can't load files with selinux Enforcing -------------------------------------------+-------------------------------- Reporter: jon.fairbairn@cl.cam.ac.uk | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: 6.6.2 Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: selinux | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -------------------------------------------+-------------------------------- Comment (by Andrew Haley ): We have already worked around this problem in libffi. The full gory details are not appropriate here, but there's a patch at http://gcc.gnu.org/ml/java-patches/2007-q1/msg00567.html I don't know if you are using libffi or using your own Foreign Function library to generate your callbacks. If you use libffi it's just a matter of upgrading; if you don't use libffi, I strongly recommend that you consider doing so. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 5 10:31:16 2007 From: trac at galois.com (GHC) Date: Wed Sep 5 10:21:41 2007 Subject: [GHC] #1665: rnf should work for any value or rnf should be implemented in the compiler Message-ID: <071.97cc4e9249d9097eb125f46871f31bbc@localhost> #1665: rnf should work for any value or rnf should be implemented in the compiler --------------------------------+------------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown --------------------------------+------------------------------------------- Currently rnf is implemented in a type class NFData in Control.Parallel.Strategies. This is not general enough, since it doesn't work for values that only exist in a monad. E.g. something built in the ST monad that uses unsafeInterleaveST cannot be converted to head normal form via rnf, since it cannot return a "Done" value, only a ST s Done value. A solution would be to have the function rnf implemented in the compiler. Its specification would be to evaluate its argument to head normal form and then return it. This is much more convenient to users, since they don't need to implement the boiler-plate code for every data type encountered. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 5 10:47:15 2007 From: trac at galois.com (GHC) Date: Wed Sep 5 10:37:42 2007 Subject: [GHC] #1656: Bignum exponentiation yields wrong results In-Reply-To: <071.a2c822d82ed40f41966c77ed157a366c@localhost> References: <071.a2c822d82ed40f41966c77ed157a366c@localhost> Message-ID: <080.10c5c2dfcde30d66bd4b59411c7bbfee@localhost> #1656: Bignum exponentiation yields wrong results --------------------------------------+------------------------------------- Reporter: rvb@minet.uni-jena.de | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: Compiler | Version: 6.6 Severity: major | Resolution: worksforme Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86_64 (amd64) | --------------------------------------+------------------------------------- Changes (by igloo): * resolution: => worksforme * status: new => closed Comment: OK, thanks for looking into it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 5 15:29:25 2007 From: trac at galois.com (GHC) Date: Wed Sep 5 15:19:51 2007 Subject: [GHC] #1665: rnf should work for any value or rnf should be implemented in the compiler In-Reply-To: <071.97cc4e9249d9097eb125f46871f31bbc@localhost> References: <071.97cc4e9249d9097eb125f46871f31bbc@localhost> Message-ID: <080.17c860d1d7d8240e4aa96b366ff9cba4@localhost> #1665: rnf should work for any value or rnf should be implemented in the compiler ----------------------------------+----------------------------------------- Reporter: iampure@gmail.com | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.7 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------+----------------------------------------- Changes (by igloo): * resolution: => wontfix * status: new => closed Comment: I'm not sure exactly what you're asking for. It sounds like you might want one of unsafePerformST (which you can define with unsafeSTToIO and unsafePerformIO; I don't think there's a particularly good reason it doesn't exist), rnfM (a monadic variant of rnf which you'd have to implement), or to solve your problem in a different way. If you still think there's a need for rnf to be primitive and to behave differently, please could you give a motivating example? It might be better to initially discuss the problem on an appropriate mailing list. Thanks Ian -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 5 15:35:51 2007 From: trac at galois.com (GHC) Date: Wed Sep 5 15:26:19 2007 Subject: [GHC] #1664: configure unsuccessful on binary build In-Reply-To: <071.cce95dec8ef71cfeb6574d221a74daf7@localhost> References: <071.cce95dec8ef71cfeb6574d221a74daf7@localhost> Message-ID: <080.9bfafda4b1a28fa843b61c185300014e@localhost> #1664: configure unsuccessful on binary build -------------------------------------------+-------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 6.7 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Os: Linux | Testcase: Architecture: x86 | -------------------------------------------+-------------------------------- Changes (by igloo): * resolution: => fixed * status: new => closed Comment: Thanks for the report. This has been fixed since that bindist was made; once a more recent bindist is made it should work. Thanks Ian -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 5 20:38:08 2007 From: trac at galois.com (GHC) Date: Wed Sep 5 20:28:31 2007 Subject: [GHC] #1651: panic when interactively evaluating expression with a family type In-Reply-To: <071.0d1b994aa7a8a202a6018c0a5f048c80@localhost> References: <071.0d1b994aa7a8a202a6018c0a5f048c80@localhost> Message-ID: <080.2f5e4a904a970a632ac2aef9b227c29c@localhost> #1651: panic when interactively evaluating expression with a family type ----------------------------------------+----------------------------------- Reporter: chak | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Unknown | Testcase: Architecture: Unknown | ----------------------------------------+----------------------------------- Changes (by chak): * resolution: => fixed * status: new => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 6 05:14:54 2007 From: trac at galois.com (GHC) Date: Thu Sep 6 05:05:18 2007 Subject: [GHC] #1666: -Werror aborts too early Message-ID: <071.d16aec2f2cd3cb784de8b51283ea92b4@localhost> #1666: -Werror aborts too early --------------------------+------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 6.10 Component: Compiler | Version: 6.6.1 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Os: Unknown Testcase: | Architecture: Unknown --------------------------+------------------------------------------------- When `-Werror` is on, we'd like to see all the warnings before the compilation aborts. At the moment, if a given stage of the compiler generates warnings (e.g. the renamer), we stop right there and don't go on to do further stages, even though we could. This isn't completely trivial to fix, we need to remember somewhere that warnings were generated earlier, or remember the warnings themselves. -- Ticket URL: GHC The Glasgow Haskell Compiler From simonpj at microsoft.com Thu Sep 6 05:51:05 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Sep 6 05:41:32 2007 Subject: ghci :browse! and type of class methods ([GHC] #1617) In-Reply-To: <00a601c7ebcc$ec33ec30$13358351@cr3lt> References: <071.ffafd57cbbcdcaa6f2ce9e1b42fb9fc8@localhost> <080.c0588789573c56c7f56d56679e7b47b8@localhost> <00a601c7ebcc$ec33ec30$13358351@cr3lt> Message-ID: | i would still like to know how one is supposed to display | the type of class methods, and why 'it' is not bound in the | same naive way i've used to bind 'output'. once these two About the it/output thing, I don't know. Can you be more explicit about what your question is? Concerning class methods... | *Main> :b! Control.Monad | fail :: Monad m -> forall a. String -> m a I can't explain why this does not print as (Monad m) => ... I'll try applying your patch when I have a clean build to hand. | also, if the class method has its own context, as in: | | class C a where c :: Num b => a -> b | | we get two levels of context, instead of a single merged context: | | *Main> :b! Main | class C a where c :: (Num b) => a -> b | c :: C a -> forall b. (Num b) => a -> b I think the right thing here is to change Type.dropForAlls, so that it drops for-alls nested to the right of arrows. Then you'd get c :: (C a, Num b) => a -> b However, if you *ask* to display the foralls, then the only thing to do is to display the actual type, as you do here: | *Main> :set -fglasgow-exts | | *Main> :b! Main | class C a where c :: forall b. (Num b) => a -> b | c :: forall a. (C a) => forall b. (Num b) => a -> b This *really is* c's type, so it's only honest to say so. (I'm not sure why -fglasgow-exts switches on forall-printing; that seems odd. Is it really what GHC does? We should surely have a flag for that.) Simon From trac at galois.com Thu Sep 6 06:50:33 2007 From: trac at galois.com (GHC) Date: Thu Sep 6 06:40:57 2007 Subject: [GHC] #919: Cryptic type error message (should be syntax error) In-Reply-To: <071.48504f2bbe295252966053d8c7c9d08f@localhost> References: <071.48504f2bbe295252966053d8c7c9d08f@localhost> Message-ID: <080.03257ae415e9889ba7001d5db93ec894@localhost> #919: Cryptic type error message (should be syntax error) ---------------------------------------------+------------------------------ Reporter: josef.svenningsson@gmail.com | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.5 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | ---------------------------------------------+------------------------------ Changes (by simonmar): * resolution: => fixed * testcase: => * status: new => closed Comment: Definitely fixed, error is now: {{{ 919.hs:1:20: Illegal operator `.' in type `forall a . ((a -> Maybe (b, a)) -> a -> c)' (Use -XTypeOperators to allow operators in types) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 6 06:51:32 2007 From: trac at galois.com (GHC) Date: Thu Sep 6 06:41:55 2007 Subject: [GHC] #1465: Type errors due to different package versions are a bit cryptic In-Reply-To: <071.e4fb77c2fcf1e24d850d41720de443e2@localhost> References: <071.e4fb77c2fcf1e24d850d41720de443e2@localhost> Message-ID: <080.7503bfc720492ebd4ad0aac414cb61ea@localhost> #1465: Type errors due to different package versions are a bit cryptic ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 Component: Compiler (Type checker) | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Moderate (1 day) Os: Unknown | Testcase: tcfail182, bug1465, mod180 Architecture: Unknown | ----------------------------------------+----------------------------------- Changes (by simonmar): * difficulty: Easy (1 hr) => Moderate (1 day) * resolution: => fixed * testcase: tcfail182 => tcfail182, bug1465, mod180 * status: new => closed Comment: Fixed: {{{ Thu Sep 6 10:37:44 BST 2007 Simon Marlow * FIX #1465, error messages could sometimes say things like "A.T doesn't match A.T" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From igloo at earth.li Thu Sep 6 08:29:24 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Sep 6 08:19:47 2007 Subject: ghci :browse! and type of class methods ([GHC] #1617) In-Reply-To: References: <071.ffafd57cbbcdcaa6f2ce9e1b42fb9fc8@localhost> <080.c0588789573c56c7f56d56679e7b47b8@localhost> <00a601c7ebcc$ec33ec30$13358351@cr3lt> Message-ID: <20070906122923.GA3424@matrix.chaos.earth.li> On Thu, Sep 06, 2007 at 10:51:05AM +0100, Simon Peyton-Jones wrote: > > (I'm not sure why -fglasgow-exts switches on forall-printing; that > seems odd. I think it's because it turns on things like rank-n types. > Is it really what GHC does? We should surely have a flag > for that.) -f(no-)print-explicit-foralls controls whether or not they're printed (the flag isn't in GHC < 6.7). Thanks Ian From trac at galois.com Thu Sep 6 08:46:32 2007 From: trac at galois.com (GHC) Date: Thu Sep 6 08:36:56 2007 Subject: [GHC] #1667: make install tries to write to /share Message-ID: <071.945b8dd355103f4f2b4cb36cf62ec94a@localhost> #1667: make install tries to write to /share --------------------------------+------------------------------------------- Reporter: iampure@gmail.com | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8 Component: Compiler | Version: 6.7 Severity: normal | Keywords: Difficulty: Unknown | Os: Unknown Testcase: | Architecture: Unknown --------------------------------+------------------------------------------- With this configure command {{{./configure --prefix=$HOME --with-ghc=/usr/bin/ghc-6.6.1 }}} (and all the other usual commands) doing make install gives (it tries to write to the /share directory, which should be $HOME/share in my case): ------------------------------------------------------------------------ == Finished recursively making `install' for ways: p debug thr thr_p thr_debug ... PWD = /home/foo/haskell/ghc/rts ------------------------------------------------------------------------ ------------------------------------------------------------------------ == make install -r; in /home/foo/haskell/ghc/libraries ------------------------------------------------------------------------ if ifBuildable/ifBuildable base; then \ cd base && \ ../installPackage/installPackage "" /home/foo $prefix/share/ghc /home/foo/share/doc/ghc/libraries /home/foo/haskell/ghc/utils/ghc-pkg/ghc- pkg-inplace /home/foo/lib/ghc-6.7.20070906/package.conf; \ fi installPackage: /share: createDirectory: permission denied (Permission denied) make[1]: *** [install.library.base] Error 1 make: *** [install] Error 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From claus.reinke at talk21.com Thu Sep 6 09:04:13 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Thu Sep 6 08:55:12 2007 Subject: ghci :browse! and type of class methods ([GHC] #1617) References: <071.ffafd57cbbcdcaa6f2ce9e1b42fb9fc8@localhost><080.c0588789573c56c7f56d56679e7b47b8@localhost><00a601c7ebcc$ec33ec30$13358351@cr3lt> Message-ID: <012001c7f086$6db8cce0$9a328351@cr3lt> > About the it/output thing, I don't know. Can you be more explicit > about what your question is? i was worried about using a different method of implementing what seemed to be the same thing. Simon M cleared up that 'it' is slightly more complex, due to type dependencies. > Concerning class methods... > > | *Main> :b! Control.Monad > | fail :: Monad m -> forall a. String -> m a > > I can't explain why this does not print as (Monad m) => ... > I'll try applying your patch when I have a clean build to hand. thanks, that is my main question about this part. perhaps i'm just using the wrong printTyTh