From trac at galois.com Sun Mar 2 09:23:26 2008 From: trac at galois.com (GHC) Date: Sun Mar 2 09:21:05 2008 Subject: [GHC] #2059: Erroneous results in trigonometric functions for > double-precision values In-Reply-To: <056.3e619538850693ad9b65e875780ac3cb@localhost> References: <056.3e619538850693ad9b65e875780ac3cb@localhost> Message-ID: <065.48f0c1c10a04cd4733a8ded042e5410b@localhost> #2059: Erroneous results in trigonometric functions for > double-precision values -------------------------------+-------------------------------------------- Reporter: daniel.is.fischer | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 2 10:26:47 2008 From: trac at galois.com (GHC) Date: Sun Mar 2 10:24:25 2008 Subject: [GHC] #2133: Add an instance for IArray (IOToDiffArray IOUArray) Bool Message-ID: <047.84d1024b9f4e1b32d187e48c3a931e7f@localhost> #2133: Add an instance for IArray (IOToDiffArray IOUArray) Bool -------------------------+-------------------------------------------------- Reporter: Deewiant | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- An instance for `IArray (IOToDiffArray IOUArray) Bool` is missing from Data.Array.Diff. There doesn't seem to be any good reason for this: all the other `IArray UArray a` instances defined in Data.Array.IArray have corresponding instances. `Bool` is the sole exception. They cannot be added in user code without copying the entire Data.Array.Diff source, since the instances require internal functions which aren't exposed. Since all the instances are defined in exactly the same way, only varying the second type parameter, this requires practically zero work: just copy any of the other instances and replace the type parameter with `Bool`. A `Show` instance should also be provided. Both are in the patch. To be sure that the instances haven't been omitted because they don't work, I wrote a few QuickCheck properties (attached) and it seems that it does work without any trouble. Suggested deadline for discussion: 17th March 2008. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 2 10:37:31 2008 From: trac at galois.com (GHC) Date: Sun Mar 2 10:35:10 2008 Subject: [GHC] #2082: In ghci, :i leaves out parens in type In-Reply-To: <052.f371aa73fee3aae45f7806e8fd54c670@localhost> References: <052.f371aa73fee3aae45f7806e8fd54c670@localhost> Message-ID: <061.ee3b0d5e987e1209e046a5d9b32cda50@localhost> #2082: In ghci, :i leaves out parens in type ---------------------------+------------------------------------------------ Reporter: chad.scherrer | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: ghci030 | Architecture: x86 Os: Linux | ---------------------------+------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 2 15:41:35 2008 From: trac at galois.com (GHC) Date: Sun Mar 2 15:39:11 2008 Subject: [GHC] #2059: Erroneous results in trigonometric functions for > double-precision values In-Reply-To: <056.3e619538850693ad9b65e875780ac3cb@localhost> References: <056.3e619538850693ad9b65e875780ac3cb@localhost> Message-ID: <065.85f88b3618fe63fec4a7f0431687c7bb@localhost> #2059: Erroneous results in trigonometric functions for > double-precision values -------------------------------+-------------------------------------------- Reporter: daniel.is.fischer | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Comment (by igloo): OK, the problem is that the `fsin` instruction (and, I assume, its friends) only take arguments with absolute value `<= 2^63`. The reason it works in C is that they look to see if the out-of-range flag is set when they call it, and if so take the sine of the remainder after dividing by `2 * pi` (only it's slightly more complicated, as they really take the partial remainder, which means they might have to do it multiple times): {{{ 0xf7f810f0 : fldl 0x4(%esp) 0xf7f810f4 : fsin 0xf7f810f6 : fnstsw %ax 0xf7f810f8 : test $0x400,%eax 0xf7f810fd : jne 0xf7f81100 0xf7f810ff : ret 0xf7f81100 : fldpi 0xf7f81102 : fadd %st(0),%st 0xf7f81104 : fxch %st(1) 0xf7f81106 : fprem1 0xf7f81108 : fnstsw %ax 0xf7f8110a : test $0x400,%eax 0xf7f8110f : jne 0xf7f81106 0xf7f81111 : fstp %st(1) 0xf7f81113 : fsin 0xf7f81115 : ret }}} I guess we should do the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 2 16:06:53 2008 From: trac at galois.com (GHC) Date: Sun Mar 2 16:04:34 2008 Subject: [GHC] #1899: compiler does not halt In-Reply-To: <044.2d1523d14ae1f01a86eeaaf884416abd@localhost> References: <044.2d1523d14ae1f01a86eeaaf884416abd@localhost> Message-ID: <053.af140cd5f49e4dc220dc88a68fcd0831@localhost> #1899: compiler does not halt ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T1899 | Architecture: x86_64 (amd64) Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 2 16:07:11 2008 From: trac at galois.com (GHC) Date: Sun Mar 2 16:04:47 2008 Subject: [GHC] #2111: Incorrect arrow rec {} notation crashes in ghci In-Reply-To: <044.65925b3e4836aa227396b3392eadc917@localhost> References: <044.65925b3e4836aa227396b3392eadc917@localhost> Message-ID: <053.e2a49edff9e15723efa1eb09c42bf899@localhost> #2111: Incorrect arrow rec {} notation crashes in ghci ----------------------+----------------------------------------------------- Reporter: luqui | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2111 | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 2 16:07:38 2008 From: trac at galois.com (GHC) Date: Sun Mar 2 16:05:27 2008 Subject: [GHC] #2112: Bad error message for malformed GADTs In-Reply-To: <042.a8a3c695a5ecaa9d8d8b6be2b59a726e@localhost> References: <042.a8a3c695a5ecaa9d8d8b6be2b59a726e@localhost> Message-ID: <051.ef995d80fb9482eafddbc10532cdb934@localhost> #2112: Bad error message for malformed GADTs -------------------------------------+-------------------------------------- Reporter: tim | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: tcfail146 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 2 16:07:54 2008 From: trac at galois.com (GHC) Date: Sun Mar 2 16:05:35 2008 Subject: [GHC] #2114: Bad error message for omitting -XExistentialQuantification flag In-Reply-To: <042.28403ebb48dbf904f743e7e47a5efd41@localhost> References: <042.28403ebb48dbf904f743e7e47a5efd41@localhost> Message-ID: <051.e7ff09550d20eb6b3fb080e91788e786@localhost> #2114: Bad error message for omitting -XExistentialQuantification flag -------------------------------------+-------------------------------------- Reporter: tim | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rnfail052, rnfail053 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 2 16:10:02 2008 From: trac at galois.com (GHC) Date: Sun Mar 2 16:07:43 2008 Subject: [GHC] #2126: Misleading error message for newtype with no constructors In-Reply-To: <042.76c0e53865b0febc05402345d0a1b7df@localhost> References: <042.76c0e53865b0febc05402345d0a1b7df@localhost> Message-ID: <051.94de3b171f1d177dded947248c963880@localhost> #2126: Misleading error message for newtype with no constructors -------------------------------------+-------------------------------------- Reporter: tim | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.8.1 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2126 | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 2 16:10:52 2008 From: trac at galois.com (GHC) Date: Sun Mar 2 16:08:29 2008 Subject: [GHC] #2130: Mulitple comparisons on Word types produce redundant comparisons In-Reply-To: <043.bb69d7139f7b8c77fac9419da7252b2c@localhost> References: <043.bb69d7139f7b8c77fac9419da7252b2c@localhost> Message-ID: <052.04fb5610733dc39fb7a66e06d399e723@localhost> #2130: Mulitple comparisons on Word types produce redundant comparisons -------------------------------+-------------------------------------------- Reporter: dons | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: performance, Word | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 2 16:11:33 2008 From: trac at galois.com (GHC) Date: Sun Mar 2 16:09:19 2008 Subject: [GHC] #1971: unjustified warning about documentation In-Reply-To: <045.5f2dce829598b3d2d0f493e57a8d1616@localhost> References: <045.5f2dce829598b3d2d0f493e57a8d1616@localhost> Message-ID: <054.faf3a525a2012197f1a80749cc871e46@localhost> #1971: unjustified warning about documentation --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Build System | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in 6.8 and HEAD branches. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 2 16:35:48 2008 From: trac at galois.com (GHC) Date: Sun Mar 2 16:33:24 2008 Subject: [GHC] #2122: file locked even though hClose called In-Reply-To: <049.be63a8f92d13b1b85271244f7bf7fa0f@localhost> References: <049.be63a8f92d13b1b85271244f7bf7fa0f@localhost> Message-ID: <058.38bdf1faf2cdba9f787e87801fb39f78@localhost> #2122: file locked even though hClose called ----------------------------+----------------------------------------------- Reporter: JeremyShaw | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: 2122 | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * testcase: => 2122 * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 2 18:57:25 2008 From: trac at galois.com (GHC) Date: Sun Mar 2 18:55:03 2008 Subject: [GHC] #1899: compiler does not halt In-Reply-To: <044.2d1523d14ae1f01a86eeaaf884416abd@localhost> References: <044.2d1523d14ae1f01a86eeaaf884416abd@localhost> Message-ID: <053.8d4bc60a6ee20a5798331dcf634703c1@localhost> #1899: compiler does not halt ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T1899 | Architecture: x86_64 (amd64) Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 3 09:49:16 2008 From: trac at galois.com (GHC) Date: Mon Mar 3 09:46:57 2008 Subject: [GHC] #1992: 6.8.2 intermittent build failure on multiple OS X versions In-Reply-To: <044.6e3d43e6297883ec96aae365685c0c7d@localhost> References: <044.6e3d43e6297883ec96aae365685c0c7d@localhost> Message-ID: <053.4ba34a021ddfed5aa37f3c07b3415034@localhost> #1992: 6.8.2 intermittent build failure on multiple OS X versions ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by gw): Once you see it, the bug is obvious. In rts/posix/FileLock.c, the lockFile routine only records a pointer from the first fd seen to the lock structure. If another fd read locks the same file, the second fd isn't recorded in the fd_hash, and the read lock count is not decremented when the second fd is closed. Here is the patch that fixes the problem: {{{ --- rts/posix/FileLock.c.sav 2008-02-20 05:47:14.000000000 -0500 +++ rts/posix/FileLock.c 2008-02-20 05:48:28.000000000 -0500 @@ -88,6 +88,12 @@ if (for_writing || lock->readers < 0) { return -1; } + + // have we seen this fd before? + if (lookupHashTable(fd_hash, fd) == NULL) { + insertHashTable(fd_hash, fd, lock); + } + lock->readers++; return 0; } }}} The last test in ghc-regress/lib/IO/openFile005 does put the hash tables into an inconsistent state, without tripping over the bug. I've added a test to trigger it. I'll darcs send these as patches to the 6.8 branch. The problem is not specific to OS X. It's still a bit puzzling why no one else has seen it, although as I mentioned before, it may have caused the version detection failure seen in Cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 3 09:58:59 2008 From: trac at galois.com (GHC) Date: Mon Mar 3 09:56:41 2008 Subject: [GHC] #1992: 6.8.2 intermittent build failure on multiple OS X versions In-Reply-To: <044.6e3d43e6297883ec96aae365685c0c7d@localhost> References: <044.6e3d43e6297883ec96aae365685c0c7d@localhost> Message-ID: <053.719e5a9136767eb8f50c2b1fbe0bf572@localhost> #1992: 6.8.2 intermittent build failure on multiple OS X versions ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: Aha! I already fixed this bug (#2122), and added a test for it. Thanks for diagnosing it, though. I didn't add the "if (lookupHashTable(fd_hash, fd) == NULL)" test when I fixed it though, just unconditionally added the mapping to the hash table. Is that test necessary? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 3 11:27:40 2008 From: trac at galois.com (GHC) Date: Mon Mar 3 11:25:21 2008 Subject: [GHC] #2134: Intermittent file locking bug in installPackage.hs Message-ID: <041.defdf7e8a14c6388acd7b4588b2e7fd6@localhost> #2134: Intermittent file locking bug in installPackage.hs ------------------------+--------------------------------------------------- Reporter: gw | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- After fixing the bug in ticket #1992, I still saw lock occasional lock errors building ghc. Dumping all of the fd/dev/inode info in lockFile and unlockFile showed that the lock hash tables were not inconsistent, as they had been in #1992, but that a write lock was being placed on a file before a read lock was released. The culprit is the reading of the configuration in libraries/installPackage.hs ({{{lbi <- getConfig verbosity}}}). This ultimately uses tryGetConfigStateFile from libraries/Cabal/Distribution/Simple/Configure.hs. And this function uses readFile to read in the configuration file. The dump of fd/dev/inode info showed that readFile was acquiring a lock that was not released before the end of the program. Occasionally, there was an attempt to obtain a write lock on the same dev/inode, leading to a lock error. It looks as if this is the laziness problem with readFile noted in the IO library documentation. Making the read of the configuration file strict and explicitly closing the handle fixes the problem for me. Here is the patch: {{{ --- libraries/Cabal/Distribution/Simple/Configure.hs.sav 2008-03-01 17:01:39.000000000 -0500 +++ libraries/Cabal/Distribution/Simple/Configure.hs 2008-03-01 17:04:25.000000000 -0500 @@ -130,7 +130,7 @@ import qualified System.Info ( os, arch ) import System.IO - ( hPutStrLn, stderr ) + ( hPutStrLn, stderr, openFile, IOMode(..), hGetContents, hClose ) import Text.PrettyPrint.HughesPJ ( comma, punctuate, render, nest, sep ) @@ -146,7 +146,9 @@ let dieMsg = "error reading " ++ filename ++ "; run \"setup configure\" command?\n" if (not e) then return $ Left dieMsg else do - str <- readFile filename + hdl <- openFile filename ReadMode + str <- hGetContents hdl >>= \s -> last s `seq` return s + hClose hdl case reads str of [(bi,_)] -> return $ Right bi _ -> return $ Left dieMsg }}} I'm still not certain why the bug occurs only some of the time, and whether it is OS dependent. But readFile's holding of the lock for an unpredictable time is just asking for trouble. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 3 11:47:54 2008 From: trac at galois.com (GHC) Date: Mon Mar 3 11:45:34 2008 Subject: [GHC] #1992: 6.8.2 intermittent build failure on multiple OS X versions In-Reply-To: <044.6e3d43e6297883ec96aae365685c0c7d@localhost> References: <044.6e3d43e6297883ec96aae365685c0c7d@localhost> Message-ID: <053.dc6a401d7cebb08bf56285459676951b@localhost> #1992: 6.8.2 intermittent build failure on multiple OS X versions ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by gw): Having looked at it again, the test "if (lookupHashTable(fd_hash, fd) == NULL)" is not probably not necessary, as long as we can guarantee that no fd will attempt to lock twice. A belt and suspenders approach is {{{ --- /Users/gwright/src/macports- trunk/dports/lang/ghc/work/ghc-6.8.2/rts/posix/FileLock.c.sav 2008-03-03 11:40:14.000000000 -0500 +++ /Users/gwright/src/macports- trunk/dports/lang/ghc/work/ghc-6.8.2/rts/posix/FileLock.c 2008-03-03 11:43:40.000000000 -0500 @@ -88,6 +88,17 @@ if (for_writing || lock->readers < 0) { return -1; } + + // have we seen this fd before? + if (lookupHashTable(fd_hash, fd) == NULL) { + insertHashTable(fd_hash, fd); + } + else + { + errorBelch("fd %d tries to lock the same file twice", fd); + return -1; + } + lock->readers++; return 0; } }}} I'm using this in the new macports 6.8.2 until I can convince myself that double locking is really impossible. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 3 12:18:36 2008 From: trac at galois.com (GHC) Date: Mon Mar 3 12:16:19 2008 Subject: [GHC] #1992: 6.8.2 intermittent build failure on multiple OS X versions In-Reply-To: <044.6e3d43e6297883ec96aae365685c0c7d@localhost> References: <044.6e3d43e6297883ec96aae365685c0c7d@localhost> Message-ID: <053.3374b5226b2ecff173e38852886d41e0@localhost> #1992: 6.8.2 intermittent build failure on multiple OS X versions ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by gw): Of course, what I meant was {{{ --- rts/posix/FileLock.c.sav 2008-03-03 11:40:14.000000000 -0500 +++ rts/posix/FileLock.c 2008-03-03 11:43:40.000000000 -0500 @@ -88,6 +88,17 @@ if (for_writing || lock->readers < 0) { return -1; } + + // have we seen this fd before? + if (lookupHashTable(fd_hash, fd) == NULL) { + insertHashTable(fd_hash, fd, lock); + } + else + { + errorBelch("fd %d tries to lock the same file twice", fd); + return -1; + } + lock->readers++; return 0; } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 3 18:23:17 2008 From: trac at galois.com (GHC) Date: Mon Mar 3 18:21:08 2008 Subject: [GHC] #738: ghc can't load files with selinux Enforcing In-Reply-To: <065.24a0770a4c910c3e35b946b29e1c1608@localhost> References: <065.24a0770a4c910c3e35b946b29e1c1608@localhost> Message-ID: <074.4db428b0c2931518f09184c62949f3aa@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.8 branch Component: Runtime System | Version: 6.6.1 Severity: normal | Resolution: Keywords: selinux | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------------------+----------------------------------- Comment (by guest): From the program point of view there is commentry here about how to avoid this by doing two separate mappings, one writeable and one executable. http://people.redhat.com/drepper/selinux-mem.html That supposedly increases security but looks a bit ugly to me but since I guess it's only needed in one place it might not be too bad??? From the local operating system point of view, you have to change the binary to have a context which allows executable memory. You can either look on a fedora system where darcs works or you can find an appropriate context with. sesearch --allow --target execmem and what we work out is that probably we want unconfined_execmem_exec_t so the command chcon -t unconfined_execmem_exec_t /usr/bin/darcs fixes this problem. (experiment with doing "chcon -t bin_t /usr/bin/darcs" to break it again) Michael De La Rue; posting as guest till I have better working private mail. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 4 17:59:43 2008 From: trac at galois.com (GHC) Date: Tue Mar 4 17:57:20 2008 Subject: [GHC] #2135: Warn if functions are exported whose types cannot be written Message-ID: <043.35b90084d0b2e9ea71da1e13a35480dd@localhost> #2135: Warn if functions are exported whose types cannot be written --------------------------------+------------------------------------------- Reporter: dons | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: warnings | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- It should be possible to warn if a function is exported from a module whose type is hidden, and thus the function's type can't be written down directly by the user. With the proliferation in type level programming in Haskell (and its use in libraries), situations can arise where functions are exported from a module which can be used, but whose type cannote be written, but where the type is complex enough that it really is required to write it down for the code to compile. This happened recently in the takusen library. A warning for this situation would help authors of libraries avoid this situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 4 20:50:04 2008 From: trac at galois.com (GHC) Date: Tue Mar 4 20:47:33 2008 Subject: [GHC] #2136: Not warned about unused recursive bindings Message-ID: <044.36da76cdb274dec6c2086dc5b0767ee6@localhost> #2136: Not warned about unused recursive bindings -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: rn063 Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- If we have this module: {{{ module Q where v :: a v = let x = x in undefined w :: a w = let y = 'a' in undefined }}} then we get warned that `y` is unused, but not that `x` is: {{{ q.hs:8:8: Warning: Defined but not used: `y' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 4 20:53:36 2008 From: trac at galois.com (GHC) Date: Tue Mar 4 20:51:07 2008 Subject: [GHC] #2136: Not warned about unused recursive bindings In-Reply-To: <044.36da76cdb274dec6c2086dc5b0767ee6@localhost> References: <044.36da76cdb274dec6c2086dc5b0767ee6@localhost> Message-ID: <053.f1ee0286c97ca3ec3f2dd7509ff50528@localhost> #2136: Not warned about unused recursive bindings ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: rn063 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): Forgot to say: Compiling with `ghc -fforce-recomp -Wall -c q.hs`. Also affects the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 4 20:55:48 2008 From: trac at galois.com (GHC) Date: Tue Mar 4 20:53:18 2008 Subject: [GHC] #2137: Location of shadowed binding is wrong in warning Message-ID: <044.44ee490b4171e22911243bf12a9d127e@localhost> #2137: Location of shadowed binding is wrong in warning -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: rn064 Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- If we have this module: {{{ module Q where z :: a z = r where _a = 'a' _f r = r _b = 'b' r = undefined _c = 'c' }}} then the location of the shadowed `r` is wrong (it's the same as the location of the one doing the shadowing): {{{ $ ghc -fforce-recomp -Wall -c q.hs q.hs:8:11: Warning: This binding for `r' shadows the existing binding bound at q.hs:8:11 In the definition of `_f' }}} 6.8 is fine (it doesn't try to give the location). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 4 20:59:42 2008 From: trac at galois.com (GHC) Date: Tue Mar 4 20:57:11 2008 Subject: [GHC] #2138: :i doesn't show constraints on datatypes Message-ID: <044.b5ae18c2495eb476ce9b65250204c213@localhost> #2138: :i doesn't show constraints on datatypes -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: ghci031 Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- If we have this module: {{{ module Q where data Eq a => D a = C a }}} then `:i` in ghci doesn't show the constraint: {{{ *Q> :i D data D a = C a -- Defined at q.hs:4:13 }}} Affects both HEAD and 6.8 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 4 21:24:13 2008 From: trac at galois.com (GHC) Date: Tue Mar 4 21:21:47 2008 Subject: [GHC] #2135: Warn if functions are exported whose types cannot be written In-Reply-To: <043.35b90084d0b2e9ea71da1e13a35480dd@localhost> References: <043.35b90084d0b2e9ea71da1e13a35480dd@localhost> Message-ID: <052.9050fff504e9605fa801a03c12b5354d@localhost> #2135: Warn if functions are exported whose types cannot be written -----------------------------+---------------------------------------------- Reporter: dons | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: warnings | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: Type synonyms make this trickier, e.g.: {{{ module Q (TypeSyn, v) where v :: RealType v = Val type TypeSyn = RealType data RealType = Val }}} Perhaps this warning should only be used for values which have explicit type signatures, and should warn if the types in the explicit type signature aren't exported? I think we'd also have to ignore types that aren't defined in the current module, as we don't want to have to re-export all the types we use in our type signatures. But if we do that then we can be tripped up by modules hidden at the package level. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 5 04:01:49 2008 From: trac at galois.com (GHC) Date: Wed Mar 5 03:59:22 2008 Subject: [GHC] #2135: Warn if functions are exported whose types cannot be written In-Reply-To: <043.35b90084d0b2e9ea71da1e13a35480dd@localhost> References: <043.35b90084d0b2e9ea71da1e13a35480dd@localhost> Message-ID: <052.c61b6d48805b20a18fd32fd8c97b5ac4@localhost> #2135: Warn if functions are exported whose types cannot be written -----------------------------+---------------------------------------------- Reporter: dons | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: warnings | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by simonpj): An unambiguous (and easier-to-check) specification might be this: * Warn if a module `M` exports a function ''with an explicit type signature'' that mentions one or more type constructors that are defined in `M` but not exported. If you want to check for explicit type signatures, there's a flag for that. (Albeit no flag to check for explicit type sigs on exports, but ignore non-exported functions. That would be another easy to add flag.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 5 13:47:41 2008 From: trac at galois.com (GHC) Date: Wed Mar 5 13:45:15 2008 Subject: [GHC] #2050: GHCi should keep a persistent history file In-Reply-To: <042.e949aba920f4285accf4bf1e428e3654@localhost> References: <042.e949aba920f4285accf4bf1e428e3654@localhost> Message-ID: <051.5569c3929fc9f71113e62e8005e16058@localhost> #2050: GHCi should keep a persistent history file -----------------------------+---------------------------------------------- Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by judah): I've added a new version of ajd's patch, which works with the types of read/writeHistory that were settled on in #2053. Two other things: - The history file is saved as ~/.ghci_history (but not if the home directory can't be retrieved) - The history is limited to 100 entries (to prevent the history file from growing too big) Does this look OK? Note that the history size can be changed by calling `stifleHistory` in the `.ghci` file. -- Ticket URL: GHC The Glasgow Haskell Compiler From chad.scherrer at gmail.com Wed Mar 5 14:02:38 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Wed Mar 5 14:12:41 2008 Subject: ghc-6.8.2 overflows stack Message-ID: Hello, I'm trying to compile stream-fusion-0.1.1 with profiling enabled, and it's overflowing the stack. $ runghc Setup.lhs configure -pO Configuring stream-fusion-0.1.1... $ runghc Setup.lhs build Preprocessing library stream-fusion-0.1.1... Building stream-fusion-0.1.1... [2 of 3] Compiling Data.List.Stream ( Data/List/Stream.hs, dist/build/Data/List/Stream.o ) stack overflow: use +RTS -K to increase it Has anyone seen this before? Is it a known bug? Thanks, Chad From chad.scherrer at gmail.com Wed Mar 5 14:20:46 2008 From: chad.scherrer at gmail.com (Chad Scherrer) Date: Wed Mar 5 14:18:28 2008 Subject: ghc-6.8.2 overflows stack References: Message-ID: Chad Scherrer gmail.com> writes: > I'm trying to compile stream-fusion-0.1.1 with profiling enabled, and it's > overflowing the stack. Sorry to reply to my own post, but I wanted to add that it works just fine if you compile Setup.lhs first, but not with runghc. Chad From Christian.Maeder at dfki.de Wed Mar 5 15:13:41 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Wed Mar 5 15:11:18 2008 Subject: ghc-6.8.2 overflows stack In-Reply-To: References: Message-ID: <47CEFEF5.4050206@dfki.de> Chad Scherrer wrote: > Hello, > > I'm trying to compile stream-fusion-0.1.1 with profiling enabled, and it's > overflowing the stack. > > $ runghc Setup.lhs configure -pO > Configuring stream-fusion-0.1.1... > > $ runghc Setup.lhs build > Preprocessing library stream-fusion-0.1.1... > Building stream-fusion-0.1.1... > [2 of 3] Compiling Data.List.Stream ( Data/List/Stream.hs, > dist/build/Data/List/Stream.o ) > stack overflow: use +RTS -K to increase it > > Has anyone seen this before? Is it a known bug? Why bug? I also had to increase the stack size when compiling with profiling. It's a plain, though big, binary: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/linux/daily/hets.bz2 I use the additional flags: -prof -auto-all -osuf p_o +RTS -K100m -RTS HTH Christian From trac at galois.com Wed Mar 5 18:57:14 2008 From: trac at galois.com (GHC) Date: Wed Mar 5 18:54:41 2008 Subject: [GHC] #2118: deriving for GRose In-Reply-To: <045.57b7b214a8eb05be517b22ad66f257fd@localhost> References: <045.57b7b214a8eb05be517b22ad66f257fd@localhost> Message-ID: <054.18946227e20594c5240de05f0bf2707e@localhost> #2118: deriving for GRose ----------------------------------------------------+----------------------- Reporter: alexey | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: type classes, undecidable instances | Testcase: Architecture: x86 | Os: MacOS X ----------------------------------------------------+----------------------- Comment (by fons): Quoting the ghc 6.8.2 manual [1] '' "The rule is this: each constraint in the inferred instance context must consist only of type variables, with no repetitions. This rule is applied regardless of flags. If you want a more exotic context, you can write it yourself, using the standalone deriving mechanism."'' And indeed, using the standalone deriving mechanism (flag -XStandaloneDeriving) we can create a Show instance of GRose: {{{ {-# LANGUAGE StandaloneDeriving #-} data GRose ff a = GRose a (ff (GRose ff a)) deriving instance (Show a, Show (ff (GRose ff a))) => Show (GRose ff a) }}} [1] http://www.haskell.org/ghc/docs/6.8.2/html/users_guide/deriving.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 6 05:58:10 2008 From: trac at galois.com (GHC) Date: Thu Mar 6 05:55:35 2008 Subject: [GHC] #2139: have a way to specify listening host in Network (listenOn) Message-ID: <042.f1e27014281434b23f7986ebe1b0c228@localhost> #2139: have a way to specify listening host in Network (listenOn) --------------------------------+------------------------------------------- Reporter: phr | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- I want to run a local (127.0.0.1) server and there doesn't appear to be any way to specify the IP address to bind to in the listenOn function. I can only listen on a port number, which I guess exposes the port to the internet. I guess I could do this with the more cumbersome Network.Socket module, but this operation is basic enough that I think the higher level module should have it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 6 06:50:54 2008 From: trac at galois.com (GHC) Date: Thu Mar 6 06:48:26 2008 Subject: [GHC] #2118: deriving for GRose In-Reply-To: <045.57b7b214a8eb05be517b22ad66f257fd@localhost> References: <045.57b7b214a8eb05be517b22ad66f257fd@localhost> Message-ID: <054.409104e3566578cd03229a48af9997f7@localhost> #2118: deriving for GRose -------------------------------------------------+-------------------------- Reporter: alexey | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: type classes, undecidable instances | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | -------------------------------------------------+-------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Fons is right. Hence I'm closing this as "not a bug". Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 6 06:59:02 2008 From: trac at galois.com (GHC) Date: Thu Mar 6 06:56:26 2008 Subject: [GHC] #2140: cpuTimePrecision is wrong for me on Windows (XP) Message-ID: <044.c00dea462eff931d52d78fdca8894af2@localhost> #2140: cpuTimePrecision is wrong for me on Windows (XP) -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Windows -------------------------------+-------------------------------------------- (From Adrian Hey) Looking at the source code, this seems to be fixed at 1000000000 independent of hardware. I'm not sure if this is supposed to be the same on all Windows XP systems, but it's wrong on my machine at least. getCPUTime always returns a multiple of 15625000000 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 6 09:13:06 2008 From: trac at galois.com (GHC) Date: Thu Mar 6 09:17:04 2008 Subject: [GHC] #783: performance problem compiling large file In-Reply-To: <044.a7a580fed8a85952633cd84570dae070@localhost> References: <044.a7a580fed8a85952633cd84570dae070@localhost> Message-ID: <053.e62919d3bab1a98926e53faf341183d7@localhost> #783: performance problem compiling large file -------------------------+-------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: Keywords: performance | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------+-------------------------------------------------- Changes (by simonpj): * owner: => igloo * type: compile-time performance bug => merge Comment: OK I have fixed the immediate problem. {{{ Thu Mar 6 13:47:34 GMT 2008 simonpj@microsoft.com * Fix Trac #783: improve short-cutting literals in the type checker }}} Ian can you merge, and (somehow) add a test case to the test suite? I'm not sure how to fully solve the quadratic behaviour in general. The reason that the lits were appearing in the SRT is because the dictionary for `Num Float` has a CAF in it. So, as Ian says, there really are N sub- SRTs for the various stages of evaluation. However things are now less bad than before: * Ian has made the SRTs use bitmaps: {{{ Wed Feb 27 06:45:05 PST 2008 Ian Lynagh * Add and use seqBitmap when constructing SRTs }}} * The above patch from me makes the literal problem go away for `Float` and `Double` (common cases) However, as Simon M says, I'm not sure why the N sub-SRTS don't all share a single table, and that should really kill off the quadratic behaviour in this case. That is the remaining bit that would be worth investigating. Maybe leave the ticket open for that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 6 09:20:54 2008 From: trac at galois.com (GHC) Date: Thu Mar 6 09:18:29 2008 Subject: [GHC] #2138: :i doesn't show constraints on datatypes In-Reply-To: <044.b5ae18c2495eb476ce9b65250204c213@localhost> References: <044.b5ae18c2495eb476ce9b65250204c213@localhost> Message-ID: <053.6ceaf85f05529679281e75a04367bc40@localhost> #2138: :i doesn't show constraints on datatypes ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: ghci031 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => igloo * type: bug => merge Comment: Fixed by {{{ Thu Mar 6 13:46:51 GMT 2008 simonpj@microsoft.com * Fix Trac #2138: print the 'stupid theta' of a data type }}} Ian: pls merge and add test case (I can't push just now because darcs.haskell.org is slow.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 7 10:51:39 2008 From: trac at galois.com (GHC) Date: Fri Mar 7 10:49:00 2008 Subject: [GHC] #2141: Internal error on invalid record update Message-ID: <041.12bd6af75f291bf77b61c12a037ef054@localhost> #2141: Internal error on invalid record update ------------------------+--------------------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- A silly function: {{{ foo :: () -> () foo x = x { foo = 1 } }}} 6.8.2 says: {{{ GHC internal error: `foo' is not in scope In the expression: x {foo = 1} In the definition of `foo': foo x = x {foo = 1} }}} HEAD's message is a bit more illuminating: {{{ GHC internal error: `foo' is not in scope during type checking, but it passed the renamer tcg_type_env of environment: [] In the expression: x {foo = 1} In the definition of `foo': foo x = x {foo = 1} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 8 10:23:26 2008 From: trac at galois.com (GHC) Date: Sat Mar 8 10:20:44 2008 Subject: [GHC] #2142: :b doesn't invoke :browse, or even generate an ambiguous command error Message-ID: <043.092835305ce494a68c91d5b535c09f14@localhost> #2142: :b doesn't invoke :browse, or even generate an ambiguous command error ------------------------+--------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Previously, :b Prelude would show the things exported by Prelude. Now, it emits the mysterious error message: {{{ module 'Prelude' is not interpreted }}} I am told that this is because it is GHCi is invoking :break instead of :browse. Shouldn't this result in GHCi complaining that :b is ambiguous? I also think :b should be explicitly defined as an alias for :browse. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 8 11:45:30 2008 From: trac at galois.com (GHC) Date: Sat Mar 8 11:42:49 2008 Subject: [GHC] #789: BCOs can only have 64k instructions In-Reply-To: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> References: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> Message-ID: <055.853f48b4c197f3aae6de2bb2f2bf60b8@localhost> #789: BCOs can only have 64k instructions ---------------------+------------------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: BCO | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------+------------------------------------------------------ Comment (by dbueno): I've added an attachment of a test case that triggers this error. The error specifically is: ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-apple-darwin): linkBCO: >= 64k insns in BCO Since this error happens on Linux too, I won't change the Operating System; but I just want to point out this happens on Mac OS X too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 9 09:35:13 2008 From: trac at galois.com (GHC) Date: Sun Mar 9 09:32:30 2008 Subject: [GHC] #2143: Yhc's sort is faster than GHC's Message-ID: <051.957b307ec22b893e4ac872796076b55a@localhost> #2143: Yhc's sort is faster than GHC's -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: NeilMitchell Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -----------------------------+---------------------------------------------- The sort code in the Yhc libraries is faster than GHC. In some cases its asymptotically better. Some benchmarks have shown a doubling in performance. I know why this is, but will need to make sure the code is as good as it can be, check all the benchmarks agree etc. Original work by Ian: http://www.haskell.org/pipermail/glasgow-haskell- users/2002-May/003376.html I will track this down and aim for a libraries proposal in a month or so. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 9 14:50:55 2008 From: trac at galois.com (GHC) Date: Sun Mar 9 14:48:18 2008 Subject: [GHC] #2144: The OpenGL binding uses withCAStringLen where it should use withCAString Message-ID: <044.a9bfa5d2a9d4a01529a5e62dcfe8d13d@localhost> #2144: The OpenGL binding uses withCAStringLen where it should use withCAString ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- In the module `Graphics.Rendering.OpenGL.GL.Shaders` (and possibly in other parts of the OpenGL binding, I didn't check) when passing a string to the OpenGL drivers, the library always uses `withCAStringLen` to marshal the strings, which does not put the required the zero byte at the end of the string. This causes the functions `getAttribLocation`, `bindAttribLocation` and `uniformLocation` to fail randomly (it was a real pain to localize this bug...). The solution is to use `withCAString` in these cases instead (and meantime, as a workaround, to put the zero character there manually in the client code). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 9 15:40:25 2008 From: trac at galois.com (GHC) Date: Sun Mar 9 15:37:39 2008 Subject: [GHC] #2145: ghc does not terminate (renamer/typechecker?) Message-ID: <049.0ee5e2acc81be79a6a498ba0443e4fa5@localhost> #2145: ghc does not terminate (renamer/typechecker?) ---------------------------+------------------------------------------------ Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux ---------------------------+------------------------------------------------ When doing {{{ ghc --make -v SRS/Bounded/Paths.hs }}} the compiler seems stuck: {{{ [5 of 5] Compiling SRS.Bounded.Paths ( SRS/Bounded/Paths.hs, SRS/Bounded/Paths.o ) *** Parser: *** Renamer/typechecker: }}} Nothing happens, for minutes, and then I hit CTRL-C. The problem seems to be triggered by calls of "modify" in the line {{{ edges = [ modify w1 af, new, modify w2 at ] }}} because if it is replaced with {{{ edges = [ af, new, at ] }}} then compilation succeeds. {{{ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2.20080113 uname -a Linux noname 2.6.22.17-0.1-default #1 SMP 2008/02/10 20:01:04 UTC i686 i686 i386 GNU/Linux }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 9 17:28:57 2008 From: trac at galois.com (GHC) Date: Sun Mar 9 17:26:11 2008 Subject: [GHC] #2145: ghc does not terminate (renamer/typechecker?) In-Reply-To: <049.0ee5e2acc81be79a6a498ba0443e4fa5@localhost> References: <049.0ee5e2acc81be79a6a498ba0443e4fa5@localhost> Message-ID: <058.0ec1b757467da8356ef1fb038e3de060@localhost> #2145: ghc does not terminate (renamer/typechecker?) ---------------------------+------------------------------------------------ Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux ---------------------------+------------------------------------------------ Comment (by j.waldmann): I notice the behaviour is different with version 6.9.20080305 (it terminates and complains about type errors). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 9 18:34:12 2008 From: trac at galois.com (GHC) Date: Sun Mar 9 18:31:25 2008 Subject: [GHC] #2145: ghc does not terminate (renamer/typechecker?) In-Reply-To: <049.0ee5e2acc81be79a6a498ba0443e4fa5@localhost> References: <049.0ee5e2acc81be79a6a498ba0443e4fa5@localhost> Message-ID: <058.799f7de712bd23e51899859ff528d0ab@localhost> #2145: ghc does not terminate (renamer/typechecker?) ------------------------+--------------------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------+--------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report! This sounds like #1899, fixed in the 6.8 branch and HEAD. Please reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 9 20:34:21 2008 From: trac at galois.com (GHC) Date: Sun Mar 9 20:32:04 2008 Subject: [GHC] #1372: Recompilation checker should consider package versions (and other factors) In-Reply-To: <047.92f71ee86626c48c755328a887f3d959@localhost> References: <047.92f71ee86626c48c755328a887f3d959@localhost> Message-ID: <056.8a683f2fbf2441fad1e5584320ca5db5@localhost> #1372: Recompilation checker should consider package versions (and other factors) ----------------------+----------------------------------------------------- Reporter: bringert | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by tim): * cc: chevalier@alum.wellesley.edu (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 10 03:38:24 2008 From: trac at galois.com (GHC) Date: Mon Mar 10 03:35:46 2008 Subject: [GHC] #1780: runInteractiveProcess broken with >2 processes on POSIX In-Reply-To: <044.d5b4cf5d496c65f6f766ac301f4fef42@localhost> References: <044.d5b4cf5d496c65f6f766ac301f4fef42@localhost> Message-ID: <053.53127168a68f09f69ff11a40535e15a2@localhost> #1780: runInteractiveProcess broken with >2 processes on POSIX -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/process | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Comment (by michal.palka): It would be nice to have it fixed. Last time I stepped on it I had to resort to using {{{runProcess "sh" ["cmd1 | cmd2"]}}} and deal with escaping the parameters. It would also be nice to be able to set a Handle into blocking mode. This way I could pass a Handle returned from {{{runInteractiveProcess}}} to an invocation of {{{runProcess}}} to form a pipe. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 10 13:57:35 2008 From: trac at galois.com (GHC) Date: Mon Mar 10 13:54:47 2008 Subject: [GHC] #974: Add partitionEithers, lefts, rights to Data.Either In-Reply-To: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> References: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> Message-ID: <053.95419f0da0c173ae49c61ea79d3fe6c6@localhost> #974: Add partitionEithers, lefts, rights to Data.Either ----------------------------+----------------------------------------------- Reporter: guest | Owner: Igloo Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by r6): * status: reopened => new * owner: => Igloo Comment: The deadline has passed, and there has been no objection to using the name partitionEithers. The patch should be applied. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 10 15:39:31 2008 From: trac at galois.com (GHC) Date: Mon Mar 10 15:36:42 2008 Subject: [GHC] #1346: bootstrap from HC files In-Reply-To: <047.353746f1d61af31dcc9643e79add3cec@localhost> References: <047.353746f1d61af31dcc9643e79add3cec@localhost> Message-ID: <056.06b1874bb99137ee93ee78183cb9d356@localhost> #1346: bootstrap from HC files --------------------------+------------------------------------------------- Reporter: simonmar | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Architecture: Unknown Os: Unknown | --------------------------+------------------------------------------------- Changes (by kili): * cc: kili@openbsd.org (added) Comment: I'd like to see this fixed for ghc-6.8.3, because for a proper OpenBSD port, bootstrapping from a precompiled binary is a no-go. I hope to get the time to review, cleanup and attach my current diffs until next week. Current state is that I'm able to create an unregisterised HC file bundle and bootstrap a working stage1 from this bundle (on i386), but the next step still doesn't work because some of the -inplace tools (ghc-pkg is one of them) aren't available yet. Please note: if you don't consider this important enough for 6.8.3, I can as well keep the patches locally in the OpenBSD port and try to adopt them for 6.10.1 later. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 11 10:17:06 2008 From: trac at galois.com (GHC) Date: Tue Mar 11 10:14:19 2008 Subject: [GHC] #2146: Decomposition rule for equalities is too weak in case of higher-kinded type families Message-ID: <043.4e7d20bb20215044f4485928ab1623de@localhost> #2146: Decomposition rule for equalities is too weak in case of higher-kinded type families -------------------------+-------------------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.9 | Severity: minor Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- {{{ foo :: (F Int a ~ F Int [a]) => a -> [a] foo = undefined }}} gives us {{{ Occurs check: cannot construct the infinite type: a = [a] }}} but {{{ foo :: (F Int a ~ F Bool [a]) => a -> [a] foo = undefined }}} doesn't - although both should lead to the same error. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 11 11:48:56 2008 From: trac at galois.com (GHC) Date: Tue Mar 11 11:46:06 2008 Subject: [GHC] #2147: unhelpful error message for a misplaced DEPRECATED pragma Message-ID: <044.4706a1b0e36567a842f434c8ed45f7f6@localhost> #2147: unhelpful error message for a misplaced DEPRECATED pragma ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- The error message on a misplaced DEPRECATED pragma is less than helpful. Note that it was the latter of these that bit me. '''% cat Main.hs''' module Main where import Foo.Bar main = return () '''% cat Foo/Bar.hs''' {-# DEPRECATED foo "bar" #-} module Foo.Bar (foo) where foo = undefined '''% ghc -c Foo/Bar.hs''' Foo/Bar.hs:4:0: parse error on input `module' '''% ghc --make Main.hs''' Foo/Bar.hs:1:0: file name does not match module name `Main' -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 11 17:02:35 2008 From: trac at galois.com (GHC) Date: Tue Mar 11 16:59:45 2008 Subject: [GHC] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 Message-ID: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 -------------------------------+-------------------------------------------- Reporter: twhitehead | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- I have some fairly simple code using !ByteStrings to parses fasta files (http://en.wikipedia.org/wiki/Fasta_format) and generate all the M-length suffixes. When I set it to hold enough M-length suffixes is memory that several GiB of RAM are consumed, it either segment faults or loops infinitely (the pared down code I've attached infinitely loops with the given parameters, while my original code segment faulted). I hooked into the attached version while it was infinitely looping one with gdb and did a backtrace. {{{ #0 0x0000000000460ef4 in free_list_push_forwards () #1 0x0000000000461357 in freeGroup () #2 0x000000000046222f in GarbageCollect () #3 0x000000000045d33f in scheduleDoGC () #4 0x000000000045dd36 in scheduleWaitThread () #5 0x000000000045aa01 in real_main () #6 0x000000000045aad3 in main () }}} Disassembling the free_list_push_forwards routine revealed that it was infinitely stuck in the while loop because the tail of the passed block descriptor (list) was circular and the passed block descriptor had a larger block count than any of the block descriptors in its circular tail. I also noted that the block descriptors composing the tail where not non- decreasing by block count up to the circular point (I don't know if this is a problem though). When I compile with -debug, I get the following (first two lines is program output): {{{ Starting new sorted block at 139609412 (/tmp/PChunk3790.tmp) Starting new sorted block at 255642977 (/tmp/PChunk3791.tmp) Bug-debug: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 (GHC version 6.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I've attached the Bug.hs code (which is the pared down version of my code). A gzipped version of the input file (~3GiB) can be found at ftp://ftp.ncbi.nlm.nih.gov/blast/db/FASTA/nr.gz. To generate the above output, I compiled with "ghc -debug -O2 --make Bug" and with "./Bug-debug nr 8 67108864" (i.e., generate blocks of 67108864 8-character suffixes from the fasta file nr). From what I've seen so far, the problem seem linked to the complexity of the code and the amount of memory used. I've never had any problems as long as I stay under 4GiB of RAM, and the more I pared down the code, the more memory I had to make it use before it would start to demonstrate the problem (with the parameters above the pared down code uses just over 16GiB). I could possibly pare the code down further. I do not know at all what I'm talking about, but from the little I've seen so far, I wonder if it is related to the 64bit memory space (e.g., having enough blocks that it can actually loops a 32bit counter tracking them, etc.). NOTE: I compiled ghc from source from http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2-src.tar.bz2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 11 18:51:22 2008 From: trac at galois.com (GHC) Date: Tue Mar 11 18:48:43 2008 Subject: [GHC] #2149: literate haskell support for hasktags - patch below Message-ID: <048.206abf414df7c8de20700eca0410dbac@localhost> #2149: literate haskell support for hasktags - patch below --------------------------------+------------------------------------------- Reporter: MarcWeber | Owner: Type: feature request | Status: new Priority: normal | Component: None Version: 6.8.2 | Severity: trivial Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Igloo told me to create a ticket. here it is. I hope that type "feature request" is fine? I haven't tested everything but now it finds most tags I hope You can get the patch and apply it: http://mawercer.de/patch_3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 11 20:19:40 2008 From: trac at galois.com (GHC) Date: Tue Mar 11 20:16:58 2008 Subject: [GHC] #2142: :b doesn't invoke :browse, or even generate an ambiguous command error In-Reply-To: <043.092835305ce494a68c91d5b535c09f14@localhost> References: <043.092835305ce494a68c91d5b535c09f14@localhost> Message-ID: <052.e7531f47aae9c25d04f907cb91fd85bd@localhost> #2142: :b doesn't invoke :browse, or even generate an ambiguous command error -------------------------+-------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Comment (by jyrinx): Much agreed. :b is something people are used to writing constantly for :browse (at least I am), whereas :break is less common. (I hate it when ease of use is trumped by lexicographical happenstance ...) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 11 22:32:15 2008 From: trac at galois.com (GHC) Date: Tue Mar 11 22:29:32 2008 Subject: [GHC] #2050: GHCi should keep a persistent history file In-Reply-To: <042.e949aba920f4285accf4bf1e428e3654@localhost> References: <042.e949aba920f4285accf4bf1e428e3654@localhost> Message-ID: <051.3753a0a77b4cd5e3345265031b6bf6c1@localhost> #2050: GHCi should keep a persistent history file -----------------------------+---------------------------------------------- Reporter: ajd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by ajd): Looks good to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 12 09:07:12 2008 From: trac at galois.com (GHC) Date: Wed Mar 12 09:04:31 2008 Subject: [GHC] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost> References: <050.c31695132cb1b93380c95a8b6c208782@localhost> Message-ID: <059.20b1c068cb7ae4d3b6dbef09567c288a@localhost> #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Comment (by maeder): With your attached patch (that I don't understand) I was able to compile ghc-6.8.2 from sources. I'll try if that fixes #2117, too. {{{ m03:ghc-6.8.2 maeder$ otool -L compiler/stage2/ghc-6.8.2 compiler/stage2/ghc-6.8.2: GNUreadline.framework/Versions/A/GNUreadline (compatibility version 5.0.0, current version 5.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0) /opt/local/lib/libgmp.3.dylib (compatibility version 8.0.0, current version 8.2.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) m03:ghc-6.8.2 maeder$ uname -a Darwin m03.informatik.uni-bremen.de 9.2.0 Darwin Kernel Version 9.2.0: Tue Feb 5 16:15:19 PST 2008; root:xnu-1228.3.13~1/RELEASE_PPC Power Macintosh }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 12 13:26:24 2008 From: trac at galois.com (GHC) Date: Wed Mar 12 13:23:41 2008 Subject: [GHC] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 In-Reply-To: <050.c31695132cb1b93380c95a8b6c208782@localhost> References: <050.c31695132cb1b93380c95a8b6c208782@localhost> Message-ID: <059.a35ce25a18cc92b589068471e101d622@localhost> #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 -------------------------+-------------------------------------------------- Reporter: thorkilnaur | Owner: thorkilnaur Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | -------------------------+-------------------------------------------------- Changes (by maeder): * version: 6.9 => 6.8.2 Comment: Yes, the patch fixes #2117, too. (at least I could install the package parsec-3.0.0) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 12 16:05:00 2008 From: trac at galois.com (GHC) Date: Wed Mar 12 16:02:14 2008 Subject: [GHC] #2142: :b doesn't invoke :browse, or even generate an ambiguous command error In-Reply-To: <043.092835305ce494a68c91d5b535c09f14@localhost> References: <043.092835305ce494a68c91d5b535c09f14@localhost> Message-ID: <052.309a8caa4a20a170dbb65025ce020063@localhost> #2142: :b doesn't invoke :browse, or even generate an ambiguous command error ----------------------+----------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: The question is, is `:browse` really the more common operation, or is it just that you are used to `:b` being an alias for it, and haven't started using the GHCi debugger yet? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 12 18:06:33 2008 From: trac at galois.com (GHC) Date: Wed Mar 12 18:03:44 2008 Subject: [GHC] #2050: GHCi should keep a persistent history file In-Reply-To: <042.e949aba920f4285accf4bf1e428e3654@localhost> References: <042.e949aba920f4285accf4bf1e428e3654@localhost> Message-ID: <051.ef00827f026c0ee4c5fafedd0251baab@localhost> #2050: GHCi should keep a persistent history file -----------------------------+---------------------------------------------- Reporter: ajd | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Wed Mar 12 14:57:24 PDT 2008 Simon Marlow * #2050: save the GHCi history in ~/.ghc/ghci_history Modified version of Judah's patch }}} I decided to put the history file in `~/.ghc/ghci_history`, as we're starting to use `~/.ghc` consistently for GHC-related configuration files now. Also I limited the history to 100 items only when saving the file, during a GHCi run there is no limit (as before). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 12 18:30:21 2008 From: trac at galois.com (GHC) Date: Wed Mar 12 18:27:28 2008 Subject: [GHC] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 In-Reply-To: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> References: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> Message-ID: <058.8c5c3544780d57fb9625de40f2a54d91@localhost> #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 ------------------------+--------------------------------------------------- Reporter: twhitehead | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ------------------------+--------------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown Comment: Sounds nasty - I'll investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 12 18:30:46 2008 From: trac at galois.com (GHC) Date: Wed Mar 12 18:27:51 2008 Subject: [GHC] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 In-Reply-To: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> References: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> Message-ID: <058.e6dd784feadb6673b048c67d2e8d2ec3@localhost> #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 ----------------------------+----------------------------------------------- Reporter: twhitehead | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * component: Compiler => Runtime System * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 12 18:35:14 2008 From: trac at galois.com (GHC) Date: Wed Mar 12 18:32:24 2008 Subject: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!! In-Reply-To: <057.ee3a70497de9cc3d83abf1aab5293225@localhost> References: <057.ee3a70497de9cc3d83abf1aab5293225@localhost> Message-ID: <066.9482f96e997cda9fb093139cf62c98c6@localhost> #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!! -------------------------------------------------+-------------------------- Reporter: jvlask@hotmail.com | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.6 Severity: critical | Resolution: Keywords: ghci foreign ffi dll import stdcall | Difficulty: Moderate (1 day) Testcase: | Architecture: x86 Os: Windows | -------------------------------------------------+-------------------------- Changes (by simonmar): * milestone: 6.8.3 => 6.10 branch Comment: Bumping this to 6.10. The stdcall part will be fixed by libffi, which I hope to start using for GHCi in 6.10, and we'll make sure the dllexport bit is fixed then too. In the meantime, the workaround is to compile the offending source file rather than interpret it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 13 00:04:42 2008 From: trac at galois.com (GHC) Date: Thu Mar 13 00:01:52 2008 Subject: [GHC] #2142: :b doesn't invoke :browse, or even generate an ambiguous command error In-Reply-To: <043.092835305ce494a68c91d5b535c09f14@localhost> References: <043.092835305ce494a68c91d5b535c09f14@localhost> Message-ID: <052.cdca75fe1082c260f1524aa51e3481ea@localhost> #2142: :b doesn't invoke :browse, or even generate an ambiguous command error ----------------------+----------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by jyrinx): Yeah, fair enough :-) Hey, why not make ":ls" a synonym for :browse? That would do in a pinch, and as a bonus it's unlikely we're going to want to add any more commands beginning "ls" ... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 13 00:49:39 2008 From: trac at galois.com (GHC) Date: Thu Mar 13 00:46:42 2008 Subject: [GHC] #2150: allow definition of functions in the interpreter Message-ID: <047.707db7ad75cfe5cdae8b632c9265f000@localhost> #2150: allow definition of functions in the interpreter --------------------------------+------------------------------------------- Reporter: ahrivera | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Right now, the only way to define functions is through the .hs files. Other interpreted languages such as Python allow the user to define functions in the command line. This is very helpful when one wants to prototype some quick functions. One way to do it could be to detect when one declares the function and then enable a mode where one can add definitions. For example: Prelude> x:: Int ->Int[[BR]] *definition*> x a = a + 1[[BR]] *definition*>[[BR]] Prelude> x 10[[BR]] 11[[BR]] Prelude>[[BR]] Please consider adding this functionality to GHCI. Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 13 05:42:47 2008 From: trac at galois.com (GHC) Date: Thu Mar 13 05:39:50 2008 Subject: [GHC] #2150: allow definition of functions in the interpreter In-Reply-To: <047.707db7ad75cfe5cdae8b632c9265f000@localhost> References: <047.707db7ad75cfe5cdae8b632c9265f000@localhost> Message-ID: <056.bd0a63ed8dfc1433e1711d8067f5efb4@localhost> #2150: allow definition of functions in the interpreter -----------------------------+---------------------------------------------- Reporter: ahrivera | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => worksforme Old description: > Right now, the only way to define functions is through the .hs files. > Other interpreted languages such as Python allow the user to define > functions in the command line. This is very helpful when one wants to > prototype some quick functions. > > One way to do it could be to detect when one declares the function and > then enable a mode where one can add definitions. For example: > > Prelude> x:: Int ->Int[[BR]] > > *definition*> x a = a + 1[[BR]] > > *definition*>[[BR]] > > Prelude> x 10[[BR]] > > 11[[BR]] > > Prelude>[[BR]] > > Please consider adding this functionality to GHCI. > > Thanks New description: Right now, the only way to define functions is through the .hs files. Other interpreted languages such as Python allow the user to define functions in the command line. This is very helpful when one wants to prototype some quick functions. One way to do it could be to detect when one declares the function and then enable a mode where one can add definitions. For example: {{{ Prelude> x:: Int ->Int *definition*> x a = a + 1 *definition*> Prelude> x 10 11 }}} Please consider adding this functionality to GHCI. Thanks Comment: Happily it's there already: {{{ Prelude> let x a = a+1 Prelude> x 10 11 }}} Multi-line definitions are, admittedly, less convenient. You have to write them on one line, but you can use braces and semicolons to put multiple lines on one line. {{{ Prelude> let { x::Int -> Int; x a = a+1 } }}} Perhaps there should be a "mode" as you imply above. Something like this: {{{ Prelude> let { *def*> x a = a+1 *def*> } Prelude> }}} But the details of such a design are not obvious to me. I'll close this since the feature is there. If it's specifically the multi-line thing you want, then open a new ticket for that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 13 08:31:12 2008 From: trac at galois.com (GHC) Date: Thu Mar 13 08:28:14 2008 Subject: [GHC] #2151: GADTs in function Patterns Message-ID: <047.2f6478e8e827595da4825a54c1ec722c@localhost> #2151: GADTs in function Patterns -------------------------+-------------------------------------------------- Reporter: hpacheco | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: blocker Keywords: | Testcase: Architecture: Multiple | Os: Multiple -------------------------+-------------------------------------------------- I have found a bug on the compiler (at least ghc >6.8.2). For some module (yes, the example does nothing at all): module Test where data Type a where Func :: Type a -> Type b -> Type (a -> b) PF :: Type a -> Type (PF a) data PF a where ID :: PF (a -> a) test :: Type a -> a -> a test (PF (Func _ _)) ID = ID I get the impossible: $ ghci Test.hs -fglasgow-exts GHCi, version 6.9.20080303: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Test ( Test.hs, interpreted ) ghc-6.9.20080303: panic! (the 'impossible' happened) (GHC version 6.9.20080303 for i386-apple-darwin): Coercion.splitCoercionKindOf $co${tc aog} [tv] t_ao8{tv} [tau] ~ a{tv aob} [sk] -> a{tv aob} [sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug However, the following implementations of test compiles ok: test :: Type a -> a -> a test (PF _) ID = ID test :: Type a -> a -> a test (PF (Func _ _)) x = x It has something to do with mixing different GADTs contructors. NOTE: This same code used to work fine in ghc 6.6, but I have ben told the whole GADT type checing was redone in 6.9. However, with 6.8.2 I still get the same error. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 13 10:44:30 2008 From: trac at galois.com (GHC) Date: Thu Mar 13 10:41:43 2008 Subject: [GHC] #2151: GADTs in function Patterns In-Reply-To: <047.2f6478e8e827595da4825a54c1ec722c@localhost> References: <047.2f6478e8e827595da4825a54c1ec722c@localhost> Message-ID: <056.04b6f39f6ca27d9d16db578dc1a0aae6@localhost> #2151: GADTs in function Patterns ----------------------+----------------------------------------------------- Reporter: hpacheco | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Changes (by simonpj): * owner: => chak * difficulty: => Unknown Old description: > I have found a bug on the compiler (at least ghc >6.8.2). For some module > (yes, the example does nothing at all): > > module Test where > > data Type a where > Func :: Type a -> Type b -> Type (a -> b) > PF :: Type a -> Type (PF a) > > data PF a where > ID :: PF (a -> a) > > test :: Type a -> a -> a > test (PF (Func _ _)) ID = ID > > I get the impossible: > > $ ghci Test.hs -fglasgow-exts > GHCi, version 6.9.20080303: http://www.haskell.org/ghc/ :? for help > Loading package base ... linking ... done. > [1 of 1] Compiling Test ( Test.hs, interpreted ) > ghc-6.9.20080303: panic! (the 'impossible' happened) > (GHC version 6.9.20080303 for i386-apple-darwin): > Coercion.splitCoercionKindOf > $co${tc aog} [tv] > t_ao8{tv} [tau] ~ a{tv aob} [sk] -> a{tv aob} [sk] > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > However, the following implementations of test compiles ok: > > test :: Type a -> a -> a > test (PF _) ID = ID > > test :: Type a -> a -> a > test (PF (Func _ _)) x = x > > It has something to do with mixing different GADTs contructors. > > NOTE: This same code used to work fine in ghc 6.6, but I have ben told > the whole GADT type checing was redone in 6.9. However, with 6.8.2 I > still get the same error. New description: I have found a bug on the compiler (at least ghc >6.8.2). For some module (yes, the example does nothing at all): {{{ module Test where data Type a where Func :: Type a -> Type b -> Type (a -> b) PF :: Type a -> Type (PF a) data PF a where ID :: PF (a -> a) test :: Type a -> a -> a test (PF (Func _ _)) ID = ID }}} I get the impossible: {{{ $ ghci Test.hs -fglasgow-exts GHCi, version 6.9.20080303: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Test ( Test.hs, interpreted ) ghc-6.9.20080303: panic! (the 'impossible' happened) (GHC version 6.9.20080303 for i386-apple-darwin): Coercion.splitCoercionKindOf $co${tc aog} [tv] t_ao8{tv} [tau] ~ a{tv aob} [sk] -> a{tv aob} [sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} However, the following implementations of test compiles ok: {{{ test :: Type a -> a -> a test (PF _) ID = ID test :: Type a -> a -> a test (PF (Func _ _)) x = x }}} It has something to do with mixing different GADTs contructors. NOTE: This same code used to work fine in ghc 6.6, but I have ben told the whole GADT type checing was redone in 6.9. However, with 6.8.2 I still get the same error. Comment: Indeed type inference is being changed a lot at the moment, by Manuel, so I'm assigning this to him. Thanks very much fr a nice boiled-down example. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 13 14:46:55 2008 From: trac at galois.com (GHC) Date: Thu Mar 13 14:43:57 2008 Subject: [GHC] #2150: allow definition of functions in the interpreter In-Reply-To: <047.707db7ad75cfe5cdae8b632c9265f000@localhost> References: <047.707db7ad75cfe5cdae8b632c9265f000@localhost> Message-ID: <056.a460e78e3e70cd3a499f95dcf86f0cd3@localhost> #2150: allow definition of functions in the interpreter -----------------------------+---------------------------------------------- Reporter: ahrivera | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by simonmar): in fact we do have multi-line commands, thanks to Claus: {{{ Prelude> :{ Prelude| let x = Prelude| 1 + 2 Prelude| :} Prelude> x 3 Prelude> }}} This was introduced in 6.8.2, and is documented: [http://www.haskell.org/ghc/docs/latest/html/users_guide/interactive- evaluation.html#ghci-stmts] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 13 16:51:07 2008 From: trac at galois.com (GHC) Date: Thu Mar 13 16:48:12 2008 Subject: [GHC] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 In-Reply-To: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> References: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> Message-ID: <058.5fb066c6f9f34d48c936369629b47546@localhost> #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 ----------------------------+----------------------------------------------- Reporter: twhitehead | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Comment (by twhitehead): I managed to cleanup the code even further and still have it exhibit the bug. The new code just generate a list of M N-length substrings (when I said prefixes above, I meant substrings) from the fixed !ByteString ['0'..'Z']. Compiling as above ("ghc --make -O2 -debug Bug") and running with "./Bug 8 134217728" (i.e., N=8 and M=134217728) produces the following after about an hour and three quarters: {{{ Starting block 0 Starting block 1 Memory leak detected gen 0 blocks : 57 gen 1 blocks : 2523057 nursery : 128 allocate() : 0 retainer : 0 arena blocks : 0 exec : 0 free : 5830 total : 2529072 in system : 3555720 Bug_: internal error: ASSERTION FAILED: file sm/Storage.c, line 1206 (GHC version 6.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I'll attach the simplified code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 13 17:12:04 2008 From: trac at galois.com (GHC) Date: Thu Mar 13 17:09:06 2008 Subject: [GHC] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 In-Reply-To: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> References: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> Message-ID: <058.93e430ab2a3cbb3bf6545001c7d89525@localhost> #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 ----------------------------+----------------------------------------------- Reporter: twhitehead | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Comment (by twhitehead): I just noticed that I didn't read that output close enough, and my further simplified code is actually dieing on a different assert (line 1206 in sm/Storage.c versus 1126). PS: Thanks very much for looking into these bugs. : ) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 13 18:16:52 2008 From: trac at galois.com (GHC) Date: Thu Mar 13 18:13:54 2008 Subject: [GHC] #2152: bogus inlining of foreign import "foo.h &foo" Message-ID: <047.0a1ee6738155b38bc12c1c5c56928fad@localhost> #2152: bogus inlining of foreign import "foo.h &foo" -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Foreign imports with include file annotations are not supposed to be inlined, because if they end up crossing a module boundary the include file might not be available when compiling the importing module. This works by making the Id representing the foreign call NOINLINE, which is done in `DsForeign.dsCImport`. Unfortunately with the example below, the Id still gets inlined into another binding, and thereby escapes the module. {{{ module Curses (screen_size) where import Foreign data WINDOW = WINDOW type WINDOWptr = Ptr WINDOW foreign import ccall unsafe "curses.h & stdscr" stdscrp :: Ptr WINDOWptr screen_size :: IO () screen_size = do stdscr <- peek stdscrp return () }}} Compile with GHC 6.8.2, -O. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 13 18:17:36 2008 From: trac at galois.com (GHC) Date: Thu Mar 13 18:14:37 2008 Subject: [GHC] #2153: GHCi does not have a :source command to load further .ghci files Message-ID: <043.51c925bf8ca398d8c29d97455f25e3eb@localhost> #2153: GHCi does not have a :source command to load further .ghci files ------------------------+--------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- This makes it difficult to put useful GHCi commands under version control (in such a way that they can be used) without having everyone share a common .ghci file for a project. For example, see http://comments.gmane.org/gmane.comp.lang.haskell.jhc/101 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 13 18:31:16 2008 From: trac at galois.com (GHC) Date: Thu Mar 13 18:28:19 2008 Subject: [GHC] #2153: GHCi does not have a :source command to load further .ghci files In-Reply-To: <043.51c925bf8ca398d8c29d97455f25e3eb@localhost> References: <043.51c925bf8ca398d8c29d97455f25e3eb@localhost> Message-ID: <052.70f2a927facf9000113066e36b8d61be@localhost> #2153: GHCi does not have a :source command to load further .ghci files ------------------------+--------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Comment (by claus): {{{ :def source readFile }}} put that in your .ghci, and you're ready to go (check the ghci user guide on :def, :cmd, etc.). you might also find this interesting: [http://www.haskell.org/pipermail/haskell-cafe/2007-September/032260.html getting more out of ghci] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 13 18:38:30 2008 From: trac at galois.com (GHC) Date: Thu Mar 13 18:35:37 2008 Subject: [GHC] #2154: Stack overflow due to unsafePerformIO Message-ID: <043.7137f0b823f9f7dd32a3caa48b6a582e@localhost> #2154: Stack overflow due to unsafePerformIO ------------------------+--------------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- The following program, extracted from a utf8 decoder for ByteStrings, overflows the stack when run with rules on. Speaking to SimonM, this is due to the stack squeezing optimisation not working for unsafePerformIO, meaning the resulting loop actually uses up stack. {{{ import qualified Data.ByteString.Char8 as S main = putStrLn $ filter (\x -> enc x /= [x]) list where list = ['\0'..'\x10ffff'] ++ ['\0'..'\10'] {-# NOINLINE enc #-} enc :: Char -> String enc x = S.singleton x `seq` [x] }}} After fusing and optimising, S.singleton here is allocated using unsafePerformIO to wrap the allocation, and seems to run out of stack. However, I've confirmed this code does work if its changed to use unsafeDupablePerformIO. I'm filing this ticket to get documentation on what is going on here, so we can have something to point to if it comes up again, and to clarify that unsafeDupablePerformIO is the correct fix. SimonM, could you summarise what the issue is? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 13 19:40:04 2008 From: trac at galois.com (GHC) Date: Thu Mar 13 19:37:06 2008 Subject: [GHC] #2155: More deadlock issues with concurrent I/O Message-ID: <046.2b787244ac57309bd0e0c416ba277e1a@localhost> #2155: More deadlock issues with concurrent I/O -------------------------------+-------------------------------------------- Reporter: dfranke | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- The following hangs on the current ghc-STABLE snapshot, and shouldn't. {{{ module Main where import Control.Concurrent import qualified Data.ByteString.Lazy.Char8 as B import System.IO import System.Process launch :: B.ByteString -> IO B.ByteString launch i = do (hin,hout,herr,ph) <- runInteractiveProcess "cat" [] Nothing Nothing -- forkIO $ collect ph -- This doesn't seem to be relevant to the problem. forkIO $ do B.hPut hin i hClose hin B.hGetContents hout collect :: ProcessHandle -> IO () collect ph = do waitForProcess ph return () main :: IO () main = let i = B.pack "foo" in do o <- foldl (>>=) (return i) (take 5 (repeat launch)) B.putStrLn o }}} See also #1936. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 13 22:23:27 2008 From: trac at galois.com (GHC) Date: Thu Mar 13 22:20:28 2008 Subject: [GHC] #2104: Add Labels In-Reply-To: <045.8e0dd3d5e2a0d3899747780f8d7a3947@localhost> References: <045.8e0dd3d5e2a0d3899747780f8d7a3947@localhost> Message-ID: <054.a2d29148b8b9f26c932a89ca1708a1d5@localhost> #2104: Add Labels -----------------------------+---------------------------------------------- Reporter: barney | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: Thanks for the suggestion; I'll put it in the 6.10 milestone for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 13 22:26:30 2008 From: trac at galois.com (GHC) Date: Thu Mar 13 22:23:30 2008 Subject: [GHC] #2106: parts of Language.Haskell.TH.Ppr in wrong package? In-Reply-To: <047.c014a420f0474b6a03da8414cec14c2b@localhost> References: <047.c014a420f0474b6a03da8414cec14c2b@localhost> Message-ID: <056.171da0bfe7aafd202f32477d06960758@localhost> #2106: parts of Language.Haskell.TH.Ppr in wrong package? ------------------------------+--------------------------------------------- Reporter: Frederik | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/pretty | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Hi Frederik, If you'd like to propose an addition to the pretty library, then can you please make a proposal as described in the library submissions policy?: http://www.haskell.org/haskellwiki/Library_submissions Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 03:24:01 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 03:21:01 2008 Subject: [GHC] #2106: parts of Language.Haskell.TH.Ppr in wrong package? In-Reply-To: <047.c014a420f0474b6a03da8414cec14c2b@localhost> References: <047.c014a420f0474b6a03da8414cec14c2b@localhost> Message-ID: <056.842e6915cf2d49c880625e740539aa4d@localhost> #2106: parts of Language.Haskell.TH.Ppr in wrong package? ------------------------------+--------------------------------------------- Reporter: Frederik | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/pretty | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by Frederik): Hi Igloo, I don't have time to fix the bug, I was under the impression that submitting it might be helpful, sorry if it is too minor... Here is what I have for personal use, if that is worth anything: {{{ module Fu.PrettyPrint (Pretty(..), pshow, ppr, ppr_) where import Text.PrettyPrint class Pretty a where toDoc :: a -> Doc myStyle = Style {mode=PageMode,lineLength=100,ribbonsPerLine=0.1} pshow :: Pretty a => a -> String pshow x = renderStyle myStyle $ toDoc x ppr :: Pretty a => a -> IO () ppr x = putStrLn $ renderStyle myStyle $ toDoc x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 03:25:01 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 03:22:01 2008 Subject: [GHC] #2106: parts of Language.Haskell.TH.Ppr in wrong package? In-Reply-To: <047.c014a420f0474b6a03da8414cec14c2b@localhost> References: <047.c014a420f0474b6a03da8414cec14c2b@localhost> Message-ID: <056.bf036a2d977bb19283dfa8bd2b9ab437@localhost> #2106: parts of Language.Haskell.TH.Ppr in wrong package? ------------------------------+--------------------------------------------- Reporter: Frederik | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/pretty | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Comment (by Frederik): (without the ", ppr_" in the first line, sorry) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 08:37:24 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 08:34:30 2008 Subject: [GHC] #2156: compilation math/truncate bug with optimization enabled Message-ID: <046.2a8dd59bec3a6add575599c4a29f05cc@localhost> #2156: compilation math/truncate bug with optimization enabled ------------------------+--------------------------------------------------- Reporter: trevorm | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: critical Keywords: | Testcase: Architecture: x86 | Os: Linux ------------------------+--------------------------------------------------- The following code produces different results depending on whether it is compiled with optimization (-O1/-O2) or not. The unoptimized program when run outputs the correct value (3), the optimized one outputs an incorrect value (2) {{{ module Main where import IO lg8base2 :: Int lg8base2 = truncate (log 8 / log 2) main :: IO() main = do hPutStrLn stdout $ show lg8base2 }}} Output of gcc -v {{{ Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable- languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable- shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include- dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-targets=all --enable- checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.3 20071123 (prerelease) (Debian 4.2.2-4) }}} Sequence of compiles / runs {{{ trevor@tmlinux:~/haskell$ ghc --make test [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... trevor@tmlinux:~/haskell$ ./test 3 trevor@tmlinux:~/haskell$ rm test.o trevor@tmlinux:~/haskell$ ghc -O2 --make test [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... trevor@tmlinux:~/haskell$ ./test 2 }}} Output of compilation phase with -v is attached (test.unoptimized.output & test.optimized.output) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 10:47:15 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 10:44:14 2008 Subject: [GHC] #2157: Equality Constraints with Type Families Message-ID: <047.9207b8f452560eac1f90c6a1629a593a@localhost> #2157: Equality Constraints with Type Families -------------------------+-------------------------------------------------- Reporter: hpacheco | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- For the implementation of fixpoint recursive definitions for a datatype I have defined the family: {{{ type family F a :: * -> * type FList a x = Either () (a,x) type instance F [a] = FList a type instance F Int = Either One }}} for which we can define functor instances {{{ instance (Functor (F [a])) where fmap _ (Left _) = Left () fmap f (Right (a,x)) = Right (a,f x) ... }}} However, in the definition of recursive patterns over these representation, I need some coercions to hold such as {{{ F d c ~ F a (c,a) }}} but in the current implementation they are evaluated as {{{ F d ~ F a /\ c ~(c,a) }}} what does not express the semantics of "fully parameterized equality" that I was expecting You can find a pratical example in ([http://groups.google.com/group/fa.haskell/browse_thread/thread/6ea21dcade9e632f/01148521c33ac29a my conversions at the haskell-cafe mailing list]) In order to avoid this, the family could be redefined as {{{ type family F a x :: * type instance F [a] x = Either() (a,x) type instance F Int x = Either One x }}} but this would mean that I cannot define instances for Functor (F a) because not enough parameters passed to F. PS. This might sound more as a feature request than a bug, so sorry if I misplaced this information. I am willing to work on this subject to help supporting my test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 11:24:45 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 11:21:47 2008 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.0b16b0840537a8bd8f2d23c5292dbe53@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by tibbe): * cc: johan.tibell@gmail.com (added) * severity: minor => normal Comment: I need this to be able to do I/O in a forked process in order to implement a daemonized mode for my web server. I need to do something like: {{{ server :: IO () main = if daemonize then forkProcess $ server else server }}} I also need to do some I/O before forking (i.e. call `getArgs` to get command line flags to pass to `GetOpt`) to figure out if I should daemonize the process or not. Note that my web server is a library which `serve` method will be called by user code so I can't provide a wrapper script that forks the process since I don't have a binry to call. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 12:26:08 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 12:23:07 2008 Subject: [GHC] #2153: GHCi does not have a :source command to load further .ghci files In-Reply-To: <043.51c925bf8ca398d8c29d97455f25e3eb@localhost> References: <043.51c925bf8ca398d8c29d97455f25e3eb@localhost> Message-ID: <052.e02af47e3d1ac45a103c2104c9252daf@localhost> #2153: GHCi does not have a :source command to load further .ghci files ---------------------+------------------------------------------------------ Reporter: SamB | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 12:29:45 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 12:26:48 2008 Subject: [GHC] #2154: Stack overflow due to unsafePerformIO In-Reply-To: <043.7137f0b823f9f7dd32a3caa48b6a582e@localhost> References: <043.7137f0b823f9f7dd32a3caa48b6a582e@localhost> Message-ID: <052.af39563b8ca41e6f9d8dd7ffef60b2fd@localhost> #2154: Stack overflow due to unsafePerformIO ----------------------------+----------------------------------------------- Reporter: dons | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by simonmar): * owner: => igloo * difficulty: => Unknown * type: bug => merge * milestone: => 6.8.3 Comment: Fixed in this patch I committed yesterday: {{{ Thu Feb 7 04:24:45 PST 2008 Simon Marlow * Tweaks to stack squeezing 1. We weren't squeezing two frames if one of them was a marked update frame. This is easy to fix. 2. The heuristic to decide whether to squeeze was a little conservative. It's worth copying 3 words to save an update frame. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 12:45:01 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 12:42:00 2008 Subject: [GHC] #2155: More deadlock issues with concurrent I/O In-Reply-To: <046.2b787244ac57309bd0e0c416ba277e1a@localhost> References: <046.2b787244ac57309bd0e0c416ba277e1a@localhost> Message-ID: <055.29908878b2e60fea80571400f9933572@localhost> #2155: More deadlock issues with concurrent I/O -------------------------------+-------------------------------------------- Reporter: dfranke | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/process | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * component: Runtime System => libraries/process * milestone: => 6.8.3 Comment: I strongly suspect this is the same as #1780, but leaving it open so that we can check. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 12:45:35 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 12:42:48 2008 Subject: [GHC] #1780: runInteractiveProcess broken with >2 processes on POSIX In-Reply-To: <044.d5b4cf5d496c65f6f766ac301f4fef42@localhost> References: <044.d5b4cf5d496c65f6f766ac301f4fef42@localhost> Message-ID: <053.0b291930e5d255313d7e8667f69eeffc@localhost> #1780: runInteractiveProcess broken with >2 processes on POSIX -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/process | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Comment (by simonmar): See also the probably-duplicate #2155. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 12:50:47 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 12:47:46 2008 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.0d6f302d35b4ccc400439135cf305b26@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by simonmar): I'd advise against this. forking is a total pain in a multi-threaded program, and I really don't want to commit to making it work for anything other than simple fork/exec type usage (and possibly not even that - doing the fork/exec in C is better). Do you really need both -threaded and `forkProcess`? Can you fork in C ''before'' starting up the Haskell runtime? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 13:20:39 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 13:17:39 2008 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.2621d1adc4e35138b8142f433a1f7fb2@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by tibbe): It doesn't work without `-threaded` either! My library exports the following function: {{{ serve :: Application -> IO () }}} Where `Application` is a handler type function in the spirit of `Request -> Response IO`. The intended usage is for the user who wants to build a web application to import my library and write a function e.g. {{{ fileServer :: Application }}} and have a `main` that looks something like: {{{ main = serve fileServer }}} The insides of the library are in principle those of HWS. `serve` reads lots of configuration flags such as `--port` and `--daemonize` from the command line so the user can get a functioning web application server that he or she can deploy in production with little fuzz. I can't see how I can support this interface and still fork in C. It seems to me like the user needs to write the startup code in C and call `main` from it. Not a nice user experience. If there is a way to write a C library that forks and include it in my library and still retain the same API I will of course use it as an intermediate solution but I still would prefer to be able to fork processes from inside Haskell. Forking, even in a restricted version, is something that would be useful in Haskell. I think daemonizing processes is a perfect example of where it's needed. I also think it is a necessary feature for server type applications. I understand that this might be difficult from a technical perspective, yet it is something other languages have so it must be possible. If I understood the issue better I could try to help come up with a solution and also try to implement it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 13:53:38 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 13:50:39 2008 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.31cd946a165bc5df4b424cfa73782589@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by igloo): Replying to [comment:3 simonmar]: > I'd advise against this. forking is a total pain in a multi-threaded program, and I really don't want to commit to making it work for anything other than simple fork/exec type usage (and possibly not even that - doing the fork/exec in C is better). > > Do you really need both -threaded and `forkProcess`? Can you fork in C ''before'' starting up the Haskell runtime? I really think we ought to be able to say something like {{{ main = do args <- getArgs configFile <- readConfigFile let config = args .+. configFile if runAsDaemon config then daemonise realMain else realMain }}} (where `daemonise` does the standard double-forking thing) without having to resort to writing C code. Using `forkIO`, `forkOS` etc before `daemonise` wouldn't necessarily have to be supported. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 13:56:39 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 13:53:38 2008 Subject: [GHC] #2156: compilation math/truncate bug with optimization enabled In-Reply-To: <046.2a8dd59bec3a6add575599c4a29f05cc@localhost> References: <046.2a8dd59bec3a6add575599c4a29f05cc@localhost> Message-ID: <055.098b3ff8bc3813b755605f89bd85626c@localhost> #2156: compilation math/truncate bug with optimization enabled -------------------------+-------------------------------------------------- Reporter: trevorm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Comment (by dons): On a core 2 duo, I'm unable to reproduce this: {{{ $ ghc --make A.hs -o A -no-recomp $ ./A 3 $ ghc --make -O2 A.hs -o A -no-recomp $ ./A 3 $ ghc --make -O2 -fvia-C A.hs -o A -no-recomp $ ./A 3 $ ghc --make -O2 -fvia-C -optc-O9 A.hs -o A -no-recomp $ ./A 3 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 14:03:04 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 14:00:05 2008 Subject: [GHC] #974: Add partitionEithers, lefts, rights to Data.Either In-Reply-To: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> References: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> Message-ID: <053.66af232e174116088e01e2ec12fa02f3@localhost> #974: Add partitionEithers, lefts, rights to Data.Either ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: Igloo => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 14:05:54 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 14:02:58 2008 Subject: [GHC] #2156: compilation math/truncate bug with optimization enabled In-Reply-To: <046.2a8dd59bec3a6add575599c4a29f05cc@localhost> References: <046.2a8dd59bec3a6add575599c4a29f05cc@localhost> Message-ID: <055.5f3c2105f59628cf92d1379f53183e92@localhost> #2156: compilation math/truncate bug with optimization enabled -------------------------+-------------------------------------------------- Reporter: trevorm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Comment (by taruti): i386 Debian system with GHC 6.8.2 (athlon xp 2ghz if relevant) taruti@oz:/tmp$ ghc --make a.hs -o a -no-recomp && ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... 3 taruti@oz:/tmp$ ghc --make a.hs -o a -no-recomp -O2 -fasm && ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... 2 taruti@oz:/tmp$ ghc --make a.hs -o a -no-recomp -O2 -fvia-c && ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... 3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 14:08:07 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 14:05:05 2008 Subject: [GHC] #2156: compilation math/truncate bug with optimization enabled In-Reply-To: <046.2a8dd59bec3a6add575599c4a29f05cc@localhost> References: <046.2a8dd59bec3a6add575599c4a29f05cc@localhost> Message-ID: <055.a53ab316a7a6a7f34c3c1484c667f727@localhost> #2156: compilation math/truncate bug with optimization enabled -------------------------+-------------------------------------------------- Reporter: trevorm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Comment (by taruti): The same, but with proper formatting: i386 Debian system with GHC 6.8.2 (athlon xp 2ghz if relevant) {{{ taruti@oz:/tmp$ ghc --make a.hs -o a -no-recomp && ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... 3 taruti@oz:/tmp$ ghc --make a.hs -o a -no-recomp -O2 -fasm && ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... 2 taruti@oz:/tmp$ ghc --make a.hs -o a -no-recomp -O2 -fvia-c && ./a [1 of 1] Compiling Main ( a.hs, a.o ) Linking a ... 3 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 14:15:15 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 14:12:18 2008 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.2eb1296c2ab251b2183ad4b917e0f3ce@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by tibbe): Implementing igloo's suggestion will solve my current problem. I'm still interested in workarounds that would allow me (by jumping through some hoops) to export the same API but internally daemonize the process using some C code. Note that I need to executed some Haskell code (that is single threaded) before I can invoke the C code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 15:10:24 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 15:07:22 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.1910ee81c1f613077b9bfbfe793fd839@localhost> #2157: Equality Constraints with Type Families -------------------------+-------------------------------------------------- Reporter: hpacheco | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- Comment (by hpacheco): I meant conversations, not conversions :P -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 15:38:33 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 15:35:34 2008 Subject: [GHC] #2149: literate haskell support for hasktags - patch below In-Reply-To: <048.206abf414df7c8de20700eca0410dbac@localhost> References: <048.206abf414df7c8de20700eca0410dbac@localhost> Message-ID: <057.58f9bbf7ee9d9b1706b0514b86252151@localhost> #2149: literate haskell support for hasktags - patch below -----------------------------+---------------------------------------------- Reporter: MarcWeber | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: None | Version: 6.8.2 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: Unfortunately, these patches don't validate for me: {{{ == make all - --no-print-directory -r --jobserver-fds=3,4 - --jobserver- fds=3,4 -j; in /home/ian/ghc/darcs/val/utils/hasktags ------------------------------------------------------------------------ /usr/bin/ghc -Werror -H64m -Onot -fasm -Wall -c HaskTags.hs -o HaskTags.o -ohi HaskTags.hi HaskTags.hs:198:40: Not in scope: `fromLiterate' HaskTags.hs:199:13: Illegal signature in pattern: [[Token]] Use -fglasgow-exts to permit it make[2]: *** [HaskTags.o] Error 1 Failed making all in hasktags: 1 make[1]: *** [all] Error 1 make: *** [stage1] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 16:12:29 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 16:09:36 2008 Subject: [GHC] #2107: "make install" doesn't install local copy of manual In-Reply-To: <042.eca0231bd2811cd8c01aa5a60d7a4d69@localhost> References: <042.eca0231bd2811cd8c01aa5a60d7a4d69@localhost> Message-ID: <051.07f9c796bb8ff1908b4cb10ff73e2edc@localhost> #2107: "make install" doesn't install local copy of manual -----------------------------+---------------------------------------------- Reporter: tim | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Build System | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: For what it's worth, the current behaviour matches http://www.gnu.org/prep/standards/html_node/Standard-Targets.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 16:15:53 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 16:12:52 2008 Subject: [GHC] #2116: ghci should try to read erroneous modules partially In-Reply-To: <049.057d3d778b5cc727821ad8871b5a5e34@localhost> References: <049.057d3d778b5cc727821ad8871b5a5e34@localhost> Message-ID: <058.f310acd185a2b7fd202cd7cbef8f3d90@localhost> #2116: ghci should try to read erroneous modules partially -----------------------------+---------------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch Comment: This would be nice, but sounds fiddly to do. I'll put it in the 6.10 branch for now, but I expect it will get punted. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 16:17:56 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 16:15:03 2008 Subject: [GHC] #2117: ppc "./Setup build" seg-faults on Mac OS leopard In-Reply-To: <045.49291ad5dcecd52c54fd505935d3d802@localhost> References: <045.49291ad5dcecd52c54fd505935d3d802@localhost> Message-ID: <054.64cf848a9e16310499e5606243236133@localhost> #2117: ppc "./Setup build" seg-faults on Mac OS leopard ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 16:23:49 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 16:20:47 2008 Subject: [GHC] #2119: explicitly importing deprecated symbols should elicit the deprecation warning In-Reply-To: <045.affc63bba10af8681f58c8409e4aaf99@localhost> References: <045.affc63bba10af8681f58c8409e4aaf99@localhost> Message-ID: <054.ca6866785718be3f2ebf70d37975d9a5@localhost> #2119: explicitly importing deprecated symbols should elicit the deprecation warning -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Unfortunately, putting this into 6.8.3 could break programs compiled with `-Werror`, so let's fix it in 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 16:36:27 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 16:33:25 2008 Subject: [GHC] #2120: Arrays allow out-of-bounds indexes In-Reply-To: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> References: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> Message-ID: <055.b1bfe96d5673da937329c08030189933@localhost> #2120: Arrays allow out-of-bounds indexes -------------------------------+-------------------------------------------- Reporter: amthrax | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: When fixing #1046 and #1610, some people were worried about the performance overhead of checking both that the index was within the range (in terms of the Ix class), and also that we were looking for a value within the real range (i.e. offset in [0..rangeSize)). We used to do just the first check, which meant that you could access memory that you shouldn't with a funky Ix instance. Now we do just the second check, meaning if you ask for an out-of-range index then you might successfully get a value back. Would you like to make a [http://www.haskell.org/haskellwiki/Library_submissions proposal] for doing both checks? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 16:37:57 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 16:34:56 2008 Subject: [GHC] #2120: Arrays allow out-of-bounds indexes In-Reply-To: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> References: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> Message-ID: <055.ef2d6ab590e26faa41cb364e5be4f5fa@localhost> #2120: Arrays allow out-of-bounds indexes -------------------------------+-------------------------------------------- Reporter: amthrax | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Comment (by igloo): See also: http://www.haskell.org/pipermail/haskell- cafe/2008-March/040598.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 16:45:06 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 16:42:16 2008 Subject: [GHC] #2128: Space leak with :trace In-Reply-To: <047.d2c047a7adb527bf1745d0129337ce92@localhost> References: <047.d2c047a7adb527bf1745d0129337ce92@localhost> Message-ID: <056.98e7ba36a2cdd3377db630e0737c0a7c@localhost> #2128: Space leak with :trace ----------------------+----------------------------------------------------- Reporter: mnislaih | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 16:48:28 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 16:45:27 2008 Subject: [GHC] #2133: Add an instance for IArray (IOToDiffArray IOUArray) Bool In-Reply-To: <047.84d1024b9f4e1b32d187e48c3a931e7f@localhost> References: <047.84d1024b9f4e1b32d187e48c3a931e7f@localhost> Message-ID: <056.4c1e96e4c68f0bd7ba478544a6c467b5@localhost> #2133: Add an instance for IArray (IOToDiffArray IOUArray) Bool -------------------------------+-------------------------------------------- Reporter: Deewiant | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 16:49:27 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 16:46:23 2008 Subject: [GHC] #2129: runInteractiveCommand/Process docs don't mention if handles are text or binary In-Reply-To: <045.fab4515899caecbd52d0aae843491315@localhost> References: <045.fab4515899caecbd52d0aae843491315@localhost> Message-ID: <054.20ddd5b2b34825a23eafad16d172fedc@localhost> #2129: runInteractiveCommand/Process docs don't mention if handles are text or binary -------------------------------+-------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/process | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: Just a doc fix, so let's do it for 6.8.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 16:53:44 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 16:50:47 2008 Subject: [GHC] #2135: Warn if functions are exported whose types cannot be written In-Reply-To: <043.35b90084d0b2e9ea71da1e13a35480dd@localhost> References: <043.35b90084d0b2e9ea71da1e13a35480dd@localhost> Message-ID: <052.8116e6a3acc2ee3db669eeb0e2ab0130@localhost> #2135: Warn if functions are exported whose types cannot be written -----------------------------+---------------------------------------------- Reporter: dons | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: warnings | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 17:00:31 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 16:57:28 2008 Subject: [GHC] #2139: have a way to specify listening host in Network (listenOn) In-Reply-To: <042.f1e27014281434b23f7986ebe1b0c228@localhost> References: <042.f1e27014281434b23f7986ebe1b0c228@localhost> Message-ID: <051.cf2b88281e2709662e4d2b783d6d2794@localhost> #2139: have a way to specify listening host in Network (listenOn) -----------------------------+---------------------------------------------- Reporter: phr | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Hi phr, Thanks for the suggestion. Could you please submit it as a [http://www.haskell.org/haskellwiki/Library_submissions proposal]? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 17:03:18 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 17:00:16 2008 Subject: [GHC] #974: Add partitionEithers, lefts, rights to Data.Either In-Reply-To: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> References: <044.771c90fc72736a1914b3f63a62b98bc6@localhost> Message-ID: <053.dc1b0f50243ac01c901fedab678f4880@localhost> #974: Add partitionEithers, lefts, rights to Data.Either ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Patch applied, thanks! {{{ Fri Mar 14 19:30:37 GMT 2008 Ian Lynagh * Add partitionEithers, lefts, and rights. Patch from Russell O'Connor, trac proposal #974. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 17:13:02 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 17:10:00 2008 Subject: [GHC] #2140: cpuTimePrecision is wrong for me on Windows (XP) In-Reply-To: <044.c00dea462eff931d52d78fdca8894af2@localhost> References: <044.c00dea462eff931d52d78fdca8894af2@localhost> Message-ID: <053.14dceb4411ad241f0f3e4f820d25fef4@localhost> #2140: cpuTimePrecision is wrong for me on Windows (XP) ----------------------------+----------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Windows | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Can I ask what you're using this value for? Does anyone happen to know where we can get real values for this for any platforms? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 17:27:30 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 17:24:32 2008 Subject: [GHC] #2142: :b doesn't invoke :browse, or even generate an ambiguous command error In-Reply-To: <043.092835305ce494a68c91d5b535c09f14@localhost> References: <043.092835305ce494a68c91d5b535c09f14@localhost> Message-ID: <052.78a811b0a8238251cd400d96b9ce97a9@localhost> #2142: :b doesn't invoke :browse, or even generate an ambiguous command error ----------------------+----------------------------------------------------- Reporter: SamB | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 17:27:51 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 17:24:52 2008 Subject: [GHC] #2143: Yhc's sort is faster than GHC's In-Reply-To: <051.957b307ec22b893e4ac872796076b55a@localhost> References: <051.957b307ec22b893e4ac872796076b55a@localhost> Message-ID: <060.15dbe3974555a179734131d26b25e2e9@localhost> #2143: Yhc's sort is faster than GHC's ----------------------------+----------------------------------------------- Reporter: NeilMitchell | Owner: NeilMitchell Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 17:31:43 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 17:28:45 2008 Subject: [GHC] #2144: The OpenGL binding uses withCAStringLen where it should use withCAString In-Reply-To: <044.a9bfa5d2a9d4a01529a5e62dcfe8d13d@localhost> References: <044.a9bfa5d2a9d4a01529a5e62dcfe8d13d@localhost> Message-ID: <053.298e09bf6de62ce3646da59299b06e9f@localhost> #2144: The OpenGL binding uses withCAStringLen where it should use withCAString -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.2 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Thanks for the report; however, bugs in OpenGL should be reported to its maintainer, Sven Panne . -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 17:32:47 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 17:29:48 2008 Subject: [GHC] #2146: Decomposition rule for equalities is too weak in case of higher-kinded type families In-Reply-To: <043.4e7d20bb20215044f4485928ab1623de@localhost> References: <043.4e7d20bb20215044f4485928ab1623de@localhost> Message-ID: <052.80997ccad338ba435d2f5d1698fc3618@localhost> #2146: Decomposition rule for equalities is too weak in case of higher-kinded type families -------------------------------------+-------------------------------------- Reporter: chak | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 17:34:07 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 17:31:04 2008 Subject: [GHC] #2147: unhelpful error message for a misplaced DEPRECATED pragma In-Reply-To: <044.4706a1b0e36567a842f434c8ed45f7f6@localhost> References: <044.4706a1b0e36567a842f434c8ed45f7f6@localhost> Message-ID: <053.9efb193458c33c82bad0de9bed17e2dc@localhost> #2147: unhelpful error message for a misplaced DEPRECATED pragma ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: Thanks for the report, we'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 17:38:57 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 17:35:57 2008 Subject: [GHC] #2149: literate haskell support for hasktags - patch below In-Reply-To: <048.206abf414df7c8de20700eca0410dbac@localhost> References: <048.206abf414df7c8de20700eca0410dbac@localhost> Message-ID: <057.71ff5e680048f4ba62f93a225b6c7d75@localhost> #2149: literate haskell support for hasktags - patch below -----------------------------+---------------------------------------------- Reporter: MarcWeber | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: None | Version: 6.8.2 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 17:40:55 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 17:37:56 2008 Subject: [GHC] #2151: GADTs in function Patterns In-Reply-To: <047.2f6478e8e827595da4825a54c1ec722c@localhost> References: <047.2f6478e8e827595da4825a54c1ec722c@localhost> Message-ID: <056.ec2bbde2355ab20818c8eea251f858a1@localhost> #2151: GADTs in function Patterns ----------------------+----------------------------------------------------- Reporter: hpacheco | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 17:46:56 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 17:43:53 2008 Subject: [GHC] #2132: Optimise nested comparisons In-Reply-To: <046.ba0b25228872b80f2daed8d0d0f8352f@localhost> References: <046.ba0b25228872b80f2daed8d0d0f8352f@localhost> Message-ID: <055.3ec9c365c9477cac1a1fef0a932fda78@localhost> #2132: Optimise nested comparisons --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by igloo): * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 17:48:19 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 17:45:20 2008 Subject: [GHC] #2154: Stack overflow due to unsafePerformIO In-Reply-To: <043.7137f0b823f9f7dd32a3caa48b6a582e@localhost> References: <043.7137f0b823f9f7dd32a3caa48b6a582e@localhost> Message-ID: <052.dbc47a5aa0887629c86b96ab480879bd@localhost> #2154: Stack overflow due to unsafePerformIO ----------------------------+----------------------------------------------- Reporter: dons | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 17:49:50 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 17:46:48 2008 Subject: [GHC] #2138: :i doesn't show constraints on datatypes In-Reply-To: <044.b5ae18c2495eb476ce9b65250204c213@localhost> References: <044.b5ae18c2495eb476ce9b65250204c213@localhost> Message-ID: <053.d6c8a24298067485782d660abbc00e69@localhost> #2138: :i doesn't show constraints on datatypes ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: ghci031 | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 18:36:45 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 18:33:43 2008 Subject: [GHC] #2002: problems with very large (list) literals In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> Message-ID: <060.0295e740e1ff18efec0a3416a4a8a771@localhost> #2002: problems with very large (list) literals ------------------------------------------+--------------------------------- Reporter: Isaac Dupree | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Comment (by igloo): Looking at modules like this: {{{ module W where w :: [Int] w = [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100] }}} one problem is in !OccAnal. As we go down the desugared list syntax tree we go around this loop: {{{ occAnal env app@(App _ _) = occAnalApp env (collectArgs app) occAnalApp env (Var fun, args) = case occAnalArgs env args of (args_uds, args') -> (fun_uds +++ f args_uds, _) occAnalArgs _env args = case mapAndUnzip (occAnal arg_env) args of (arg_uds_s, args') -> (f arg_uds_s, _) }}} As written, we build up a huge closure of `+++`s, which gives a stack overflow when we try to evaluate it. If we rewrite it along the lines of {{{ occAnalApp env (Var fun, args) = case occAnalArgs env args of (args_uds, args') -> let uds = fun_uds +++ f args_uds in uds `seq` (uds, _) }}} then we have to go all the way along the spine to do the top-level `seq`, so we get a stack overflow again. It's not immediately obvious whether or not we can make the occurence analyser pass the usage details around as an accumulating parameter, along with a little more state, to avoid the stack usage. ---- When compiling with {{{ ghc -cpp -fglasgow-exts -fforce-recomp -fasm -funbox-strict-fields -c W.hs +RTS -p -hyTSO -h -xt }}} This table shows the fewest list elements needed for the stack to need to grow to a given size: {{{ number of list elements Stack size (kB) bytes per list element 300 250 833 600 500 833 1200 1000 833 2300 2000 870 4500 4000 889 8900 8000 899 }}} (where the stack size is the peak usage of the heap graph). So that looks linear to me, and about 100 words per stack element. That's an order of magnitude more than I'd have expected, but it's not completely inplausible. However, even if we made it an order of magnitude smaller, I think people would still run into the limit. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 14 19:36:42 2008 From: trac at galois.com (GHC) Date: Fri Mar 14 19:33:41 2008 Subject: [GHC] #2116: ghci should try to read erroneous modules partially In-Reply-To: <049.057d3d778b5cc727821ad8871b5a5e34@localhost> References: <049.057d3d778b5cc727821ad8871b5a5e34@localhost> Message-ID: <058.33f9911237a43872de967b5c9edcd7a1@localhost> #2116: ghci should try to read erroneous modules partially -----------------------------+---------------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by claus): * cc: claus (added) Comment: i don't know whether type errors can be caught locally, without ghci losing its place during load, but if yes, one could try to replace each erroneous definition with calls to error: {{{ f x = x+True }}} might become {{{ f x = error "No instance for (Num Bool) arising from a use of `+' at :1:10-15 Possible fix: add an instance declaration for (Num Bool) In the expression: x + True In the definition of `f': f x = x + True" }}} while trying to continue loading the rest of the module (which should be marked as partially loaded). does that sound plausible? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 15 00:18:35 2008 From: trac at galois.com (GHC) Date: Sat Mar 15 00:15:33 2008 Subject: [GHC] #2158: deriving (Ix) and listArray give unexpected results Message-ID: <044.54d602356c43d2c31db7911ab87aa37c@localhost> #2158: deriving (Ix) and listArray give unexpected results ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.6 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- When `arrayList` is used together with a derived instance of `Ix`, the results are not the same as what the Haskell 98 report suggests. {{{ import Data.Array import Data.Ix data Pos = Pos Integer Integer deriving (Show, Eq, Ord, Ix) {- -- copied from the H98 report, with (,) replaced by Pos instance Ix Pos where range (Pos l l', Pos u u') = [ Pos i i' | i <- range (l, u), i' <- range (l', u') ] index (Pos l l', Pos u u') (Pos i i') = index (l, u) i * rangeSize (l', u') + index (l', u') i' inRange (Pos l l', Pos u u') (Pos i i') = inRange (l, u) i && inRange (l', u') i' -} contents = concat $ [ "ABCD" , "wxyz" , "1234" ] -- example definition of listArray from the H98 report listArray98 b xs = array b (range b `zip` xs) array1 = listArray (Pos 0 0, Pos 2 3) contents array2 = listArray98 (Pos 0 0, Pos 2 3) contents main = if array1 == array2 then putStrLn "arrays are equal" else putStrLn "arrays are NOT equal" }}} In this example, `array1` and `array2` should be equal, but they are not. The `listArray` function interprets its argument list in a different order from `listArray98`. The underlying problem seems to be that the integer indices produced by the derived `Ix` do not agree with the order implied by `range`, but `listArray` assumes that they do. Replacing either the `Ix` instance or the `listArray` definition with the H98 version gives correct results. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 15 10:33:02 2008 From: trac at galois.com (GHC) Date: Sat Mar 15 10:30:01 2008 Subject: [GHC] #1057: Implicit parameters on breakpoints In-Reply-To: <047.66b204e37a019adbedd5273436434765@localhost> References: <047.66b204e37a019adbedd5273436434765@localhost> Message-ID: <056.d2b250f32fdee7d2db85e82768299ab1@localhost> #1057: Implicit parameters on breakpoints ------------------------------------+--------------------------------------- Reporter: mnislaih | Owner: mnislaih Type: bug | Status: assigned Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: ghci.debugger/break004 | Architecture: Unknown Os: Unknown | ------------------------------------+--------------------------------------- Comment (by igloo): What's the status of this bug? `break004` isn't run by `ghci.debugger/scripts/all.T`, and it doesn't use implicit parameters, so I'm a bit confused. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 15 10:35:53 2008 From: trac at galois.com (GHC) Date: Sat Mar 15 10:32:52 2008 Subject: [GHC] #1208: ghci-6.6 aborts at initialization In-Reply-To: <062.ab3c9c029380a68d5ae87f83fa9dd0ee@localhost> References: <062.ab3c9c029380a68d5ae87f83fa9dd0ee@localhost> Message-ID: <071.9dda4bbd8a20505e573892cb17c8a3c3@localhost> #1208: ghci-6.6 aborts at initialization -------------------------------------+-------------------------------------- Reporter: dfeustel@mindspring.com | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.6 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: OpenBSD | -------------------------------------+-------------------------------------- Changes (by igloo): * status: new => closed * cc: Don, Stewart, (removed) * cc: dons@galois.com (added) * resolution: => duplicate Comment: This looks like a duplicate of #1225; please reopen if I'm wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 15 12:23:47 2008 From: trac at galois.com (GHC) Date: Sat Mar 15 12:20:42 2008 Subject: [GHC] #1057: Implicit parameters on breakpoints In-Reply-To: <047.66b204e37a019adbedd5273436434765@localhost> References: <047.66b204e37a019adbedd5273436434765@localhost> Message-ID: <056.ecb315ac13e7e234dc1d55ac7fd0f54d@localhost> #1057: Implicit parameters on breakpoints ------------------------------------+--------------------------------------- Reporter: mnislaih | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: ghci.debugger/break015 | Architecture: Unknown Os: Unknown | ------------------------------------+--------------------------------------- Changes (by mnislaih): * testcase: ghci.debugger/break004 => ghci.debugger/break015 * status: assigned => new * version: 6.6 => 6.8.2 * owner: mnislaih => Comment: The defect still exists and the test is break015. I am not going to fix it, as a lot has changed since I did the 1st prototype implementation. I don't know exactly how the debugger captures locals currently, the code was written by Simon and Bernie, and I don't feel comfortable fixing this ticket on myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 15 14:13:57 2008 From: trac at galois.com (GHC) Date: Sat Mar 15 14:10:52 2008 Subject: [GHC] #2159: Use a more efficient representation than [DynFlag] Message-ID: <044.7464fd042e6f0696195045db2d1740fe@localhost> #2159: Use a more efficient representation than [DynFlag] ---------------------------------------------+------------------------------ Reporter: igloo | Owner: Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown ---------------------------------------------+------------------------------ In `compiler/typecheck/TcRnMonad.lhs`, if I replace the existing definitions with {{{ traceOptIf _ _ = return () traceOptTcRn _ _ = return () dumpTcRn _ = return () }}} then we see an improvement in nofib's "Compile Times" sections: {{{ -1 s.d. ----- -8.5% +1 s.d. ----- +1.8% Average ----- -3.5% }}} By using some sort of bitmap representation, we ought to see a modest compile time improvement from all the checks that the trace functions make, as well as various other checks that are made (do we need to warn about missing sigs, are overlapping instances allowed, etc). The tricky bit is designing it so that it is hard to shoot yourself in the foot. `Lexer.x` already has a bitmap (`genericsBit`, `ffiBit` etc) but the mapping of feature to bit number is done by hand, which isn't ideal. Perhaps this is even important enough to deserve a language extension? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 15 17:42:19 2008 From: trac at galois.com (GHC) Date: Sat Mar 15 17:39:17 2008 Subject: [GHC] #1491: Extension RecordWildCards is broken In-Reply-To: <044.1c11c0db7ccc38a1eead17582e964255@localhost> References: <044.1c11c0db7ccc38a1eead17582e964255@localhost> Message-ID: <053.195e4b39e605c5390fa809834d46e7b9@localhost> #1491: Extension RecordWildCards is broken ----------------------+----------------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rn065 | Architecture: Unknown Os: Windows | ----------------------+----------------------------------------------------- Changes (by igloo): * testcase: => rn065 * status: new => closed * resolution: => fixed Comment: Test rn065 added. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 16 16:19:36 2008 From: trac at galois.com (GHC) Date: Sun Mar 16 16:16:28 2008 Subject: [GHC] #2160: "internal error: PAP object entered!" when running ghci compiled with profiling Message-ID: <044.7238efc2bf75e79eeb5aa57cfd0f92e1@localhost> #2160: "internal error: PAP object entered!" when running ghci compiled with profiling -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- With this mk/build.mk: {{{ GhcCompilerWays=p GhcThreaded=NO GhcProfiled=YES #GhcDebugged=YES GhcRTSWays += debug_p WAY_debug_p_HC_OPTS += -O0 -optc-O0 -optc-g MakefileDeps = NO }}} I get this: {{{ $ compiler/stage2/ghc-inplace --interactive GHCi, version 6.9.20080315: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. ghc-6.9.20080315: internal error: PAP object entered! (GHC version 6.9.20080315 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Unfortunately, there isn't a smaller example in the full testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 16 17:17:09 2008 From: trac at galois.com (GHC) Date: Sun Mar 16 17:14:00 2008 Subject: [GHC] #2128: Space leak with :trace In-Reply-To: <047.d2c047a7adb527bf1745d0129337ce92@localhost> References: <047.d2c047a7adb527bf1745d0129337ce92@localhost> Message-ID: <056.411cff09e6a634141fdd4764bb15e42d@localhost> #2128: Space leak with :trace ----------------------+----------------------------------------------------- Reporter: mnislaih | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 16 17:44:56 2008 From: trac at galois.com (GHC) Date: Sun Mar 16 17:41:58 2008 Subject: [GHC] #1809: type families: difference in type-checking between compile-time and run-time In-Reply-To: <044.879122f54c5461e5758b1573a08f9e47@localhost> References: <044.879122f54c5461e5758b1573a08f9e47@localhost> Message-ID: <053.35631dc0fe1f8f29bf44cb7164aaee9e@localhost> #1809: type families: difference in type-checking between compile-time and run- time ----------------------+----------------------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by ganesh): * cc: ganesh@earth.li (added) Comment: An even simpler example: {{{ module Test6 where type family Id a type instance Id Int = Int five :: Id Int five = 5 -- This typechecks ok, but show five at the ghci prompt doesn't foo = show five }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 16 20:56:23 2008 From: trac at galois.com (GHC) Date: Sun Mar 16 20:53:17 2008 Subject: [GHC] #2128: Space leak with :trace In-Reply-To: <047.d2c047a7adb527bf1745d0129337ce92@localhost> References: <047.d2c047a7adb527bf1745d0129337ce92@localhost> Message-ID: <056.0afb7162f6cfe83d1f38de4cfc4df596@localhost> #2128: Space leak with :trace ----------------------+----------------------------------------------------- Reporter: mnislaih | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.8: {{{ Sun Mar 16 14:17:48 PDT 2008 Ian Lynagh * Fix a space leak in :trace (trac #2128) We were doing lots of cons'ing and tail'ing without forcing the tails, so were building up lots of thunks. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 16 20:57:32 2008 From: trac at galois.com (GHC) Date: Sun Mar 16 20:54:22 2008 Subject: [GHC] #856: Build system issues on ia64 In-Reply-To: <057.a1731f680944bd8fa23371e27e5be953@localhost> References: <057.a1731f680944bd8fa23371e27e5be953@localhost> Message-ID: <066.7980861e98895670ea3f9ec80021cbef@localhost> #856: Build system issues on ia64 --------------------------------+------------------------------------------- Reporter: red5_2@hotmail.com | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.8 branch Component: Build System | Version: 6.4.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: ia64 Os: Linux | --------------------------------+------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.8 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 16 20:59:00 2008 From: trac at galois.com (GHC) Date: Sun Mar 16 20:56:06 2008 Subject: [GHC] #1893: ghc should say when it is failing due to -Werror In-Reply-To: <044.0401494a45a0a9a9c8f2e2eedad7e1e3@localhost> References: <044.0401494a45a0a9a9c8f2e2eedad7e1e3@localhost> Message-ID: <053.fc4f14c5d0ace8565f0441e074c819a9@localhost> #1893: ghc should say when it is failing due to -Werror ----------------------+----------------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed in HEAD and 6.8 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 16 21:38:00 2008 From: trac at galois.com (GHC) Date: Sun Mar 16 21:35:02 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.7c72a1c95c4c48ccd60ef0e5b505d812@localhost> #2157: Equality Constraints with Type Families ----------------------------------------+----------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------------+----------------------------------- Changes (by chak): * owner: => chak * type: bug => feature request * os: Unknown => Multiple * component: Compiler => Compiler (Type checker) * architecture: Unknown => Multiple Comment: I'd like to find a solution here, but as far as I can see, there is no bug in GHC's type checker. In fact, if GHC would admit any of your code, it would also allow programs that are not type safe. In particular, given your second definition, {{{ type family F a x :: * }}} if we would allow partial applications, as in `Functor (F a)`, we would get an inconsistent system; see Section 3.6 in [http://www.cse.unsw.edu.au/~chak/papers/SCPD07.html]. On the other hand, given {{{ type family F a :: * -> * }}} an equality of the form `F a1 b1 ~ F a2 b2` implies `F a1 ~ F a2` and `b1 ~ b2` as always in Haskell (this is what Mark Jones called higher-kinded unification in his paper about constructor classes). In other words, given a type (f :: * -> * -> *), the partial application `f t` is well-formed exactly if the decomposition rule holds (i.e., `f a1 b1 ~ f a2 b2` implies `f a1 ~ f a2` and `b1 ~ b2`). These two properties are causally linked, you cannot get one without the other. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 16 21:50:39 2008 From: trac at galois.com (GHC) Date: Sun Mar 16 21:47:36 2008 Subject: [GHC] #1809: type families: difference in type-checking between compile-time and run-time In-Reply-To: <044.879122f54c5461e5758b1573a08f9e47@localhost> References: <044.879122f54c5461e5758b1573a08f9e47@localhost> Message-ID: <053.15268d45014662a23ff0386b7729c4c0@localhost> #1809: type families: difference in type-checking between compile-time and run- time ----------------------+----------------------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: Ganesh, I suspect you used an older compiler. This works fine for me in 6.9.20080313. (It actually should already work for quite a while. When I fixed the problem, I didn't realise it was the same as the one reported in this bug.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 16 23:54:04 2008 From: trac at galois.com (GHC) Date: Sun Mar 16 23:50:53 2008 Subject: [GHC] #2161: GHC threaded RTS will call the finaliser of a ForeignPtr while references still exist Message-ID: <042.1f1f726f7231a63c84f81fe14419c18e@localhost> #2161: GHC threaded RTS will call the finaliser of a ForeignPtr while references still exist -------------------------------+-------------------------------------------- Reporter: agl | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- I believe that I've managed to distill a crash which has been driving me crazy for a few days into a short enough test case (22 lines) that it might be useful. In short: the threaded RTS will call the finialiser of a ForeignPtr while an exception handler still holds a reference to it: {{{ % ghc -make fptest.hs cbits.c -threaded [1 of 1] Compiling Main ( fptest.hs, fptest.o ) Linking fptest ... % ./fptest New object getting created: 66f010 Finaliser getting called for 66f010 Use called for 66f010 }}} I'm hoping that this is useful to someone who knows the RTS. Cheers, -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 05:40:08 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 05:36:59 2008 Subject: [GHC] #2162: panic! (the 'impossible' happened) while compiling XMonadContrib Message-ID: <044.7fc048ee753a66d1c255ec61e3bd414f@localhost> #2162: panic! (the 'impossible' happened) while compiling XMonadContrib -----------------------+---------------------------------------------------- Reporter: ivant | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Unknown -----------------------+---------------------------------------------------- I was rebuilding XMonadContrib without doing Cabal clean first. I got the "panic!" message. The problem was persistent: if I started Cabal build again, I was getting the same message. After I did Cabal clean followed by Cabal build, the problem disappeared. Seem to be a problem with interacting with previously compiled code. Here is the output of GHC: {{{ [108 of 117] Compiling XMonad.Config.Sjanssen ( XMonad/Config/Sjanssen.hs, dist/build/XMonad/Config/Sjanssen.o ) ghc-6.8.2: panic! (the 'impossible' happened) (GHC version 6.8.2 for i386-unknown-linux): bind_args xmonad-0.6:XMonad.Core.:DLayoutClass{d r19g} [tpl_B2{v} [lid], tpl_B3{v} [lid], tpl_B4{v} [lid], tpl_B5{v} [lid], tpl_B6{v} [lid], tpl_B7{v} [lid], tpl_B8{v} [lid], tpl_B9{v} [lid]] [TYPE xmonad-contrib-0.6:XMonad.Layout.HintedTile.HintedTile{tc r19zx}, TYPE X11-1.4.1:Graphics.X11.Types.Window{tc r5}, xmonad-contrib-0.6:XMonad.Layout.HintedTile.$f4{v r19zw} [gid] @ base:GHC.Word.Word32{tc 333}, xmonad-contrib-0.6:XMonad.Layout.HintedTile.doLayout{v r19zv} [gid], xmonad-contrib-0.6:XMonad.Layout.HintedTile.$dmpureLayout{v r19zu} [gid], xmonad-contrib-0.6:XMonad.Layout.HintedTile.a1{v r19zt} [gid] `cast` (base:GHC.Prim.right{(w) tc 34E} (base:GHC.Prim.inst{(w) tc 34H} (base:GHC.Prim.inst{(w) tc 34H} (base:GHC.Prim.trans{(w) tc 34y} (forall (layout{tv i28Jn} [tv] :: base:GHC.Prim.*{(w) tc 34d} -> base:GHC.Prim.*{(w) tc 34d}) a{tv i28Jo} [tv]. (xmonad-0.6:XMonad.Core.LayoutClass{tc rzi} layout{tv i28Jn} [tv] a{tv i28Jo} [tv]) => layout{tv i28Jn} [tv] a{tv i28Jo} [tv] -> X11-1.4.1:Graphics.X11.Xlib.Types.Rectangle{tc ruD} -> xmonad-0.6:XMonad.Core.XConf{tc rz} -> xmonad-0.6:XMonad.Core.XState{tc ry} -> base:GHC.Prim.sym{(w) tc 34v} ((base:GHC.IOBase.:CoIO{tc rx}) (([(a{tv i28Jo} [tv], X11-1.4.1:Graphics.X11.Xlib.Types.Rectangle{tc ruD})], base:Data.Maybe.Maybe{tc rB} (layout{tv i28Jn} [tv] a{tv i28Jo} [tv])), xmonad-0.6:XMonad.Core.XState{tc ry}))) (forall (layout{tv i28Jp} [tv] :: base:GHC.Prim.*{(w) tc 34d} -> base:GHC.Prim.*{(w) tc 34d}) a{tv i28Jq} [tv]. (xmonad-0.6:XMonad.Core.LayoutClass{tc rzi} layout{tv i28Jp} [tv] a{tv i28Jq} [tv]) => layout{tv i28Jp} [tv] a{tv i28Jq} [tv] -> X11-1.4.1:Graphics.X11.Xlib.Types.Rectangle{tc ruD} -> base:GHC.Prim.right{(w) tc 34E} (base:GHC.Prim.inst{(w) tc 34H} (base:GHC.Prim.trans{(w) tc 34y} (forall a1{tv i28Jr} [tv]. a1{tv i28Jr} [tv] -> base:GHC.Prim.trans{(w) tc 34y} (xmonad-0.6:XMonad.Core.XConf{tc rz} -> base:GHC.Prim.sym{(w) tc 34v} ((mtl-1.1.0.0:Control.Monad.State.Lazy.:CoStateT{tc ru}) xmonad-0.6:XMonad.Core.XState{tc ry} base:GHC.IOBase.IO{tc 32I} a1{tv i28Jr} [tv])) (base:GHC.Prim.sym{(w) tc 34v} ((mtl-1.1.0.0:Control.Monad.Reader.:CoReaderT{tc rt}) xmonad-0.6:XMonad.Core.XConf{tc rz} (mtl-1.1.0.0:Control.Monad.State.Lazy.StateT{tc rv} xmonad-0.6:XMonad.Core.XState{tc ry} base:GHC.IOBase.IO{tc 32I}) a1{tv i28Jr} [tv]))) (forall a1{tv i28Js} [tv]. a1{tv i28Js} [tv] -> base:GHC.Prim.sym{(w) tc 34v} (xmonad-0.6:XMonad.Core.:CoX{tc rs}) a1{tv i28Js} [tv])) ([(a{tv i28Jq} [tv], X11-1.4.1:Graphics.X11.Xlib.Types.Rectangle{tc ruD})], base:Data.Maybe.Maybe{tc rB} (layout{tv i28Jp} [tv] a{tv i28Jq} [tv]))))) xmonad- contrib-0.6:XMonad.Layout.HintedTile.HintedTile{tc r19zx}) X11-1.4.1:Graphics.X11.Types.Window{tc r5}) :: xmonad- contrib-0.6:XMonad.Layout.HintedTile.HintedTile{tc r19zx} X11-1.4.1:Graphics.X11.Types.Window{tc r5} -> X11-1.4.1:Graphics.X11.Xlib.Types.Rectangle{tc ruD} -> xmonad-0.6:XMonad.Core.XConf{tc rz} -> xmonad-0.6:XMonad.Core.XState{tc ry} -> base:GHC.Prim.State#{(w) tc 32q} base:GHC.Prim.RealWorld{(w) tc 31E} -> (# base:GHC.Prim.State#{(w) tc 32q} base:GHC.Prim.RealWorld{(w) tc 31E}, (([(X11-1.4.1:Graphics.X11.Types.Window{tc r5}, X11-1.4.1:Graphics.X11.Xlib.Types.Rectangle{tc ruD})], base:Data.Maybe.Maybe{tc rB} (xmonad- contrib-0.6:XMonad.Layout.HintedTile.HintedTile{tc r19zx} X11-1.4.1:Graphics.X11.Types.Window{tc r5})), xmonad-0.6:XMonad.Core.XState{tc ry}) #) ~ xmonad- contrib-0.6:XMonad.Layout.HintedTile.HintedTile{tc r19zx} X11-1.4.1:Graphics.X11.Types.Window{tc r5} -> X11-1.4.1:Graphics.X11.Xlib.Types.Rectangle{tc ruD} -> xmonad-0.6:XMonad.Core.X{tc rD} ([(X11-1.4.1:Graphics.X11.Types.Window{tc r5}, X11-1.4.1:Graphics.X11.Xlib.Types.Rectangle{tc ruD})], base:Data.Maybe.Maybe{tc rB} (xmonad- contrib-0.6:XMonad.Layout.HintedTile.HintedTile{tc r19zx} X11-1.4.1:Graphics.X11.Types.Window{tc r5}))), xmonad-contrib-0.6:XMonad.Layout.HintedTile.$dmhandleMessage{v r19zs} [gid], xmonad-contrib-0.6:XMonad.Layout.HintedTile.pureMessage{v r19zr} [gid], xmonad-contrib-0.6:XMonad.Layout.HintedTile.description{v r19zq} [gid]] scrut: xmonad-contrib-0.6:XMonad.Layout.HintedTile.$f1{v r19yR} [gid] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Sjanssen.hs is {{{ {-# OPTIONS_GHC -fno-warn-missing-signatures #-} module XMonad.Config.Sjanssen (sjanssenConfig) where import XMonad hiding (Tall(..)) import qualified XMonad.StackSet as W import XMonad.Actions.CopyWindow import XMonad.Layout.Tabbed import XMonad.Layout.HintedTile import XMonad.Config (defaultConfig) import XMonad.Layout.NoBorders import XMonad.Hooks.DynamicLog import XMonad.Hooks.ManageDocks import XMonad.Prompt import XMonad.Prompt.Shell import XMonad.Util.Run (spawnPipe) import XMonad.Layout.DwmStyle import qualified Data.Map as M import System.IO (hPutStrLn) sjanssenConfig = do xmobar <- spawnPipe "xmobar" return $ defaultConfig { terminal = "urxvtc" , workspaces = ["irc", "web"] ++ map show [3 .. 7 :: Int] ++ ["mail", "im"] , logHook = dynamicLogWithPP $ sjanssenPP { ppOutput = hPutStrLn xmobar } , modMask = mod4Mask , mouseBindings = \(XConfig {modMask = modm}) -> M.fromList $ [ ((modm, button1), (\w -> focus w >> mouseMoveWindow w)) , ((modm, button2), (\w -> focus w >> windows W.swapMaster)) , ((modm.|. shiftMask, button1), (\w -> focus w >> mouseResizeWindow w)) ] , keys = \c -> mykeys c `M.union` keys defaultConfig c , layoutHook = dwmStyle shrinkText myTheme $ avoidStruts $ smartBorders (tiled Tall ||| tiled Wide ||| Full ||| tabbed shrinkText myTheme) , manageHook = manageHook defaultConfig <+> manageDocks } where tiled = HintedTile 1 0.03 0.5 mykeys (XConfig {modMask = modm, workspaces = ws}) = M.fromList $ [((modm, xK_p ), shellPrompt myPromptConfig) ,((modm .|. shiftMask, xK_c ), kill1) ,((modm .|. shiftMask .|. controlMask, xK_c ), kill) ,((modm .|. shiftMask, xK_0 ), windows $ \w -> foldr copy w ws) ,((modm, xK_b ), sendMessage ToggleStruts) ] myFont = "xft:Bitstream Vera Sans Mono:pixelsize=10" myTheme = defaultTheme { fontName = myFont } myPromptConfig = defaultXPConfig { position = Top , font = myFont , promptBorderWidth = 0 } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From Christian.Maeder at dfki.de Mon Mar 17 07:31:59 2008 From: Christian.Maeder at dfki.de (Christian Maeder) Date: Mon Mar 17 07:28:51 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <47D8F305.1060202@dfki.de> <47D90BA4.3050805@dfki.de> <47DA4399.3040604@dfki.de> <47DA58CE.6080508@dfki.de> Message-ID: <47DE56AF.6000900@dfki.de> Thanks Chris! This should fix http://hackage.haskell.org/trac/ghc/ticket/1958 http://hackage.haskell.org/trac/ghc/ticket/2117 Thorkil, you called your patch "illustrative only". I suggest to commit it. Any objections? Thanks for the patch, anyway. Cheers Christian My built can be found at: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.8.2-powerpc-apple-darwin-static-libs.tar.bz2 It uses static libs for gmp, ncurses and readline, but should run on tiger and leopard ppc. (#1845, #2031 are still problems) C.M.Brown wrote: > Hi Christian, > > The build went without any problems, the log can be found here: > > http://www.cs.kent.ac.uk/people/rpg/cmb21/inst.log.gz > > kind regards, > Chris. > From trac at galois.com Mon Mar 17 07:41:52 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 07:38:50 2008 Subject: [GHC] #2117: ppc "./Setup build" seg-faults on Mac OS leopard In-Reply-To: <045.49291ad5dcecd52c54fd505935d3d802@localhost> References: <045.49291ad5dcecd52c54fd505935d3d802@localhost> Message-ID: <054.80254de8cf7396c23f606d690fc922d5@localhost> #2117: ppc "./Setup build" seg-faults on Mac OS leopard ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by maeder): should be fixed by the patch in #1958 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 08:50:42 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 08:47:44 2008 Subject: [GHC] #2031: relocation overflow In-Reply-To: <045.02b5c8981d759aa3391df46bf05998bf@localhost> References: <045.02b5c8981d759aa3391df46bf05998bf@localhost> Message-ID: <054.3d590a3201d0784b6eecf280f558864e@localhost> #2031: relocation overflow ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by maeder): I've recompiled the above binary-dist using the patch from #1958. Now I get under leopard with an unoptimized binary the following error: {{{ hets: internal error: evacuate(static): strange closure type 24576 (GHC version 6.8.2 for powerpc_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} But I'm not sure if the patch is causing this. (I may have not noticed this error before on tiger.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 09:14:13 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 09:11:07 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.47fba4aaca8fb526c255ef2bff618d8c@localhost> #2157: Equality Constraints with Type Families ----------------------------------------+----------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------------+----------------------------------- Comment (by claus): Replying to [comment:2 chak]: > On the other hand, given > {{{ > type family F a :: * -> * > }}} > an equality of the form `F a1 b1 ~ F a2 b2` implies `F a1 ~ F a2` and `b1 ~ b2` as always in Haskell i had problems with this statement, until i stopped thinking of "type functions" (which would allow constant functions violating your assumption) and thought of "phantom types" (all type parameters matter, even if they disappear in the result). if that association is useful, though, you might want to disallow partially applied type synonyms in type instances - `Const` and `f` seem fishy here (wrt your implication, at least): {{{ {-# LANGUAGE TypeFamilies #-} type family Const a :: * -> * type instance Const a = C a type C a t = a f :: Const Bool Int -> Const Bool Char -> Const Bool Bool f i c = False -- f i c = i -- f i c = i && True -- f i c = (i || c) type family Const2 a :: * -> * type instance Const2 a = Ct a newtype Ct a t = Ct a g :: Const2 Bool Int -> Const2 Bool Char -> Const2 Bool Bool g i c = Ct False -- g i c = Ct i -- g i c = Ct (i && True) -- g i c = Ct (i || c) }}} for `Const` and `f`, `GHCi, version 6.9.20080217` happily accepts `i && True` and `i || c`, converting between `Const Bool *` and `Bool`, but does not accept `i`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 11:08:32 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 11:05:29 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.427c4cdf6ad29938ebf41d8d2f77e680@localhost> #2157: Equality Constraints with Type Families ----------------------------------------+----------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------------+----------------------------------- Comment (by hpacheco): I understood your points and they do make sense, but do you think that this is a feasible feature request or it should never be supported? I have just remembered that, still for the family {{{ type family F a x :: * type instance F [a] x = Either () (a,x) type instance F Int x = Either () x }}} we can write "partial-evaluated classes for F" whenever not all type parameters are in use. For the Functor class this would mean: {{{ class FunctorF x where fmapF :: (a -> b) -> F x a -> F x b instance FunctorF [a] where fmapF _ (Left _) = Left () fmapF f (Right (a,x)) = Right (a,f x) instance FunctorF Int where fmapF _ (Left ()) = Left () fmapF f (Right n) = Right (f n) }}} At first glance it is less generic but seems to work. However, a previous function (for the family F a :: * -> *) {{{ hylo :: (Functor (F d)) => d -> (F d c -> c) -> (a -> F d a) -> a -> c hylo d g h = g . fmap (hylo d g h) . h }}} if translated to {{{ hylo :: (FunctorF d) => d -> (F d c -> c) -> (a -> F d a) -> a -> c hylo d g h = g . fmapF (hylo d g h) . h }}} does not compile with the explicit type signature. Without a type signature it compiles and infers the signature (does not make sense to me) {{{ hylo :: forall t d c a. (FunctorF d) => t -> (F d c -> c) -> (a -> F d a) -> a -> c }}} However, if this signature is passed explicitly, it does not compile again. There must be a bug somewhere in this scheme, or am I missing something huge? Regards, hugo -- Ticket URL: GHC The Glasgow Haskell Compiler From naur at post11.tele.dk Mon Mar 17 12:10:14 2008 From: naur at post11.tele.dk (Thorkil Naur) Date: Mon Mar 17 12:09:40 2008 Subject: ANN: ghc 6.8.2 from MacPorts In-Reply-To: <20080317113203.VDTQ10334.fep25.mail.dk@smtprelay11.ispgateway.de> References: <50CC9CBD-56CD-463B-A5A1-154503419C21@comcast.net> <20080317113203.VDTQ10334.fep25.mail.dk@smtprelay11.ispgateway.de> Message-ID: <200803171710.15455.naur@post11.tele.dk> Hello Christian, On Monday 17 March 2008 12:31, Christian Maeder wrote: > Thanks Chris! > > This should fix > http://hackage.haskell.org/trac/ghc/ticket/1958 > http://hackage.haskell.org/trac/ghc/ticket/2117 > > Thorkil, you called your patch "illustrative only". I suggest to commit > it. Any objections? Thanks for the patch, anyway. No objections at all, since the patch does appear to solve some real problems. But I would suggest that we keep at least #1958 open, until we have understood the problem better. As described in #1958, the patch is what I would call a lucky guess, based on several experiments with different versions of very small assembly language programs that triggered the linker error message. I, at least, would not claim to understand what goes on in detail. I have not head from Apple since reporting the problem. I checked a few weeks ago and currently I am actually unable to access the bug reporter. I have a plan eventually to try to figure out what the real problem is (that is, debugging the linker), but haven't gotten around to it so far. > > Cheers Christian > > My built can be found at: > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/ghcs/ghc-6.8.2-powerpc-apple-darwin-static-libs.tar.bz2 > It uses static libs for gmp, ncurses and readline, but should run on > tiger and leopard ppc. (#1845, #2031 are still problems) > > C.M.Brown wrote: > > Hi Christian, > > > > The build went without any problems, the log can be found here: > > > > http://www.cs.kent.ac.uk/people/rpg/cmb21/inst.log.gz > > > > kind regards, > > Chris. > > > > Thanks to you all for working on this matter. Best regards Thorkil From trac at galois.com Mon Mar 17 12:52:06 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 12:48:55 2008 Subject: [GHC] #1185: can't do I/O in the child of forkProcess with -threaded In-Reply-To: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> References: <047.505ed9940eff9ef82094c96c7212dfa3@localhost> Message-ID: <056.719ccbf405ec167a4e2291ea75da1a4e@localhost> #1185: can't do I/O in the child of forkProcess with -threaded ----------------------------+----------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: _|_ Component: Runtime System | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by simonmar): Replying to [comment:4 tibbe]: > It doesn't work without `-threaded` either! Then there could be a real bug here - can you give us complete reproduction instructions? We certainly intend to support `forkProcess` in the non-threaded RTS. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 12:56:34 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 12:53:22 2008 Subject: [GHC] #2002: problems with very large (list) literals In-Reply-To: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> References: <051.64c621f5afc3e8cbd43368bfecf19488@localhost> Message-ID: <060.0c93d9c7f284339556b99610872d9b72@localhost> #2002: problems with very large (list) literals ------------------------------------------+--------------------------------- Reporter: Isaac Dupree | Owner: Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------------------------+--------------------------------- Comment (by simonmar): IMO, we should just bump GHC's stack limit. Given that GHC may reasonably use stack that is linear in the size of the program, having a low fixed limit will arbitrarily reject some programs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 13:08:37 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 13:05:36 2008 Subject: [GHC] #2031: relocation overflow In-Reply-To: <045.02b5c8981d759aa3391df46bf05998bf@localhost> References: <045.02b5c8981d759aa3391df46bf05998bf@localhost> Message-ID: <054.f534973b01d897e1c690e3ef88de0a8e@localhost> #2031: relocation overflow ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by maeder): This `evacuate(static)` bug does not occur on tiger. In fact the relocation error is also gone for a slightly smaller binary. Interestingly an optimized binary works correctly on leopard, too! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 13:36:24 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 13:33:16 2008 Subject: [GHC] #2162: panic! (the 'impossible' happened) while compiling XMonadContrib In-Reply-To: <044.7fc048ee753a66d1c255ec61e3bd414f@localhost> References: <044.7fc048ee753a66d1c255ec61e3bd414f@localhost> Message-ID: <053.f5b4d1235686585aa167b71cbb6b31a9@localhost> #2162: panic! (the 'impossible' happened) while compiling XMonadContrib -------------------------+-------------------------------------------------- Reporter: ivant | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Testcase: Architecture: x86 | Os: Unknown -------------------------+-------------------------------------------------- Changes (by dons): * status: new => closed * resolution: => duplicate Comment: Duplicate of issues relating to 1372, http://hackage.haskell.org/trac/ghc/ticket/1372 Now that xmonad as a library is stable, cabal not noticing it should clean after a darcs pull, and subsequent type, linker or runtime errors, is the most common source of user complaints about xmonad, fwiw. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 13:40:13 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 13:37:01 2008 Subject: [GHC] #2161: finaliser of a ForeignPtr called while references from unreachable threads exist In-Reply-To: <042.1f1f726f7231a63c84f81fe14419c18e@localhost> References: <042.1f1f726f7231a63c84f81fe14419c18e@localhost> Message-ID: <051.54edfd1e9230d46f51dde9b951a50168@localhost> #2161: finaliser of a ForeignPtr called while references from unreachable threads exist ----------------------------+----------------------------------------------- Reporter: agl | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Changes (by simonmar): * difficulty: => Unknown * summary: GHC threaded RTS will call the finaliser of a ForeignPtr while references still exist => finaliser of a ForeignPtr called while references from unreachable threads exist * milestone: => _|_ Comment: Ok, what's happening here is the thread that has a reference to the `ForeignPtr` is itself unreachable, and so the GC considers both the thread and the `ForeignPtr` unreachable. It then sends an exception to the thread, and starts the finalizer for the `ForeignPtr` simultaneously. This is similar to the case where two finalizers refer to each others' `ForeignPtr`s: they can both be invoked simultaneously. You may argue that a reference from a thread, even an unreachable one, should keep a `ForeignPtr` alive. But it's equally valid to argue the reverse: a reference from a finalizer should keep a thread alive - you don't want a thread to be considered deadlocked if it can be unblocked by a finalizer. We can't have both, because then a cycle between a finalizer and a thread would never be collected even when both were unreachable. OTOH, perhaps this is a case where C finalizers should be treated differently from Haskell finalizers. A weak pointer with a C finalizer could be kept alive by an unreachable thread. I'll leave this bug open to remind us if we ever special-case C finalizers (which is probably a good idea for other reasons). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 14:21:24 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 14:18:22 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.c38842eea1c1fb5ae55946055fe324b2@localhost> #2157: Equality Constraints with Type Families ----------------------------------------+----------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------------+----------------------------------- Comment (by hpacheco): Well, it seems to work if the add a "magic" dummy argument to fmapF. {{{ class FunctorF x where fmapF :: d -> (a -> b) -> F x a -> F x b hylo :: (FunctorF d) => d -> (F d c -> c) -> (a -> F d a) -> a -> c hylo d g h = g . fmapF d (hylo d g h) . h }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 16:05:56 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 16:02:58 2008 Subject: [GHC] #783: performance problem compiling large file In-Reply-To: <044.a7a580fed8a85952633cd84570dae070@localhost> References: <044.a7a580fed8a85952633cd84570dae070@localhost> Message-ID: <053.ce85930bbd31466f171d4367734c9829@localhost> #783: performance problem compiling large file -------------------------+-------------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: Keywords: performance | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------+-------------------------------------------------- Comment (by igloo): I've merged the patch. Also, just to clarify, the patch `Add and use seqBitmap when constructing SRTs` is actually in a later stage of the compiler (although I did find that problem while looking at this bug). Going directly to a bitmap, rather than first making the `SRTEntries`, might be a way to fix this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 17:35:30 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 17:32:49 2008 Subject: [GHC] #1809: type families: difference in type-checking between compile-time and run-time In-Reply-To: <044.879122f54c5461e5758b1573a08f9e47@localhost> References: <044.879122f54c5461e5758b1573a08f9e47@localhost> Message-ID: <053.bd091e007aeb7cabf45eb5074856f4b0@localhost> #1809: type families: difference in type-checking between compile-time and run- time ----------------------+----------------------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Comment (by ganesh): Thanks - I've now checked that it is fixed in 6.9.20080316 - but it was definitely broken in 6.9.20080310, in case that's of any interest to you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 18:45:42 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 18:42:37 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.2f99d18ea1e9d36cf455b428315a218b@localhost> #2157: Equality Constraints with Type Families ----------------------------------------+----------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------------+----------------------------------- Comment (by hpacheco): Curiously if I have {{{ fff a = fmapF a id }}} it compiles correctly. But if I infer the type signature of fff I get {{{ fff :: forall d x. (FunctorF d) => d -> F d x -> F d x }}} On the other side, a similar problem as before arises when {{{ fff :: forall d x. (FunctorF d) => d -> F d x -> F d x fff a = fmapF a id }}} fails to compile. This must be a bug. Sorry for all this posts. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 19:35:04 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 19:31:52 2008 Subject: [GHC] #2104: Add Labels In-Reply-To: <045.8e0dd3d5e2a0d3899747780f8d7a3947@localhost> References: <045.8e0dd3d5e2a0d3899747780f8d7a3947@localhost> Message-ID: <054.47e2e724776c35971a77b7089db8f5cc@localhost> #2104: Add Labels -----------------------------+---------------------------------------------- Reporter: barney | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by barney): We probably want labels to be automatically in most of the standard classes, with trivial instances like {{{ instance Eq 'name where _==_ = True }}} so that {{{deriving}}} works for types constructed from them. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 19:38:56 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 19:35:42 2008 Subject: [GHC] #2163: GHC makes thunks for Integers we are strict in Message-ID: <044.669eae6b361993c49cbaa68b68f5129a@localhost> #2163: GHC makes thunks for Integers we are strict in -----------------------------------------+---------------------------------- Reporter: igloo | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- We know that timesInteger is strict in both arguments: {{{ $ ./ghc --show-iface ~/ghc/darcs/val/libraries/base/dist/build/GHC/Num.hi | grep -C2 "^timesInteger" plusInteger :: GHC.Num.Integer -> GHC.Num.Integer -> GHC.Num.Integer {- Arity: 2 HasNoCafRefs Strictness: SS -} timesInteger :: GHC.Num.Integer -> GHC.Num.Integer -> GHC.Num.Integer {- Arity: 2 HasNoCafRefs Strictness: SS -} class (GHC.Base.Eq a, GHC.Show.Show a) => Num a }}} but given this code: {{{ module W where f :: Integer -> Integer f x = let x' = x + 3 in x' * x' }}} we still make a thunk for `x'`: {{{ $ ./ghc -c w.hs -O -fforce-recomp -ddump-simpl ==================== Tidy Core ==================== W.lvl :: GHC.Num.Integer [GlobalId] [NoCafRefs Str: DmdType] W.lvl = GHC.Num.S# 3 W.f :: GHC.Num.Integer -> GHC.Num.Integer [GlobalId] [Arity 1 NoCafRefs Str: DmdType S] W.f = \ (x_a5h :: GHC.Num.Integer) -> let { x'_sa7 [ALWAYS Just S] :: GHC.Num.Integer [Str: DmdType] x'_sa7 = GHC.Num.plusInteger x_a5h W.lvl } in GHC.Num.timesInteger x'_sa7 x'_sa7 }}} The same is true in both the 6.8 branch and the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 20:17:40 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 20:14:29 2008 Subject: [GHC] #2163: GHC makes thunks for Integers we are strict in In-Reply-To: <044.669eae6b361993c49cbaa68b68f5129a@localhost> References: <044.669eae6b361993c49cbaa68b68f5129a@localhost> Message-ID: <053.77eea1dfb89886426ec4221a144a6455@localhost> #2163: GHC makes thunks for Integers we are strict in --------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by dons): * cc: dons@galois.com (added) Comment: Weird, I get this code, with -O {{{ W.lvl :: GHC.Num.Integer [GlobalId] [NoCafRefs Str: DmdType] W.lvl = GHC.Num.S# 3 W.f :: GHC.Num.Integer -> GHC.Num.Integer [GlobalId] [Arity 1 NoCafRefs Str: DmdType S] W.f = \ (x_a5l :: GHC.Num.Integer) -> case GHC.Num.plusInteger x_a5l W.lvl of wild_ab3 { GHC.Num.S# i_ab5 -> case GHC.Prim.mulIntMayOflo# i_ab5 i_ab5 of wild2_abb { __DEFAULT -> case GHC.Prim.int2Integer# i_ab5 of wild3_abc { (# s_abe, d_abf #) -> GHC.Num.$stimesInteger s_abe d_abf s_abe d_abf }; 0 -> GHC.Num.S# (GHC.Prim.*# i_ab5 i_ab5) }; GHC.Num.J# ds_abw ds1_abx -> case GHC.Prim.timesInteger# ds_abw ds1_abx ds_abw ds1_abx of wild2_abM { (# s_abO, d_abP #) -> GHC.Num.J# s_abO d_abP } } }}} and -O2: {{{W.lvl :: GHC.Num.Integer [GlobalId] [NoCafRefs Str: DmdType] W.lvl = GHC.Num.S# 3 W.f :: GHC.Num.Integer -> GHC.Num.Integer [GlobalId] [Arity 1 NoCafRefs Str: DmdType S] W.f = \ (x_a5l :: GHC.Num.Integer) -> case GHC.Num.plusInteger x_a5l W.lvl of wild_ab3 { GHC.Num.S# i_ab5 -> case GHC.Prim.mulIntMayOflo# i_ab5 i_ab5 of wild2_abb { __DEFAULT -> case GHC.Prim.int2Integer# i_ab5 of wild3_abc { (# s_abe, d_abf #) -> GHC.Num.$stimesInteger s_abe d_abf s_abe d_abf }; 0 -> GHC.Num.S# (GHC.Prim.*# i_ab5 i_ab5) }; GHC.Num.J# ds_abw ds1_abx -> case GHC.Prim.timesInteger# ds_abw ds1_abx ds_abw ds1_abx of wild2_abM { (# s_abO, d_abP #) -> GHC.Num.J# s_abO d_abP } } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 22:15:12 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 22:12:00 2008 Subject: [GHC] #2164: zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd Message-ID: <044.65631559df6ce2cd79a1eb038ea82f5f@localhost> #2164: zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd ------------------------+--------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- So, I was recently looking at ZMachine, which is an emulator written in Haskell for the Infocom text adventures. It can be gotten from darcs here: . Anyway, I did some editing and installed and I tried it out on one of the text adventures SamB included in the repo: gwern@localhost:1013~/bin/ZMachine>zmachine Museum.z5 [10:06PM] [finding abbrev 0 at $84][finding abbrev 1 at $8c][(0,"look"),(5,"map")] [(0,"look"),(5,"map")] zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd (GHC version 6.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort zmachine Museum.z5 In this case, one of the objects in the room was a map, so I typed in the sensible 'look map', and that is what happened. (In case you were wondering, 'look at map' works fine, but you can then go 'look map' and it crashes with the same exact error.) SamB doesn't remember putting in anything dangerous which he'd expect to do that. More importantly, when he runs from the same repo and tries out the same sequence he sees: 21:57 < SamB> [finding abbrev 0 at $84][finding abbrev 1 at $8c][(0,"look"),(5,"map")] 21:57 < SamB> [(0,"look"),(5,"map")] No crash. He says he's on a Pentium 4, i386 architecture, while I'm using a quad-core Intel (x86_64, ~amd64 Gentoo) --- SamB: Linux hydrogen 2.6.22-2-686 #1 SMP Fri Aug 31 00:24:01 UTC 2007 i686 GNU/Linux gwern@localhost:1013~/bin/ZMachine>uname -a [10:07PM] Linux localhost 2.6.24-gentoo-r3 #6 SMP PREEMPT Fri Mar 14 21:40:34 EDT 2008 x86_64 Intel(R) Core(TM)2 Quad CPU @ 2.40GHz GenuineIntel GNU/Linux gwern@localhost:1014~/bin/ZMachine>ghc-pkg list [10:12PM] /usr/lib64/ghc-6.8.2/package.conf: ALUT-2.1.0.0, Cabal-1.2.3.0, GLUT-2.1.1.1, HDBC-1.1.4, HDBC-odbc-1.1.4.0, HDBC-postgresql-1.1.4.0, HDBC-sqlite3-1.1.4.0, HGL-3.2.0.0, HTTP-3001.0.4, HUnit-1.2.0.0, OpenAL-1.3.1.1, OpenGL-2.2.1.1, QuickCheck-1.1.0.0, Stream-0.2.2, X11-1.4.1, X11-xft-0.2, array-0.1.0.0, arrows-0.3, base-3.0.1.0, bytestring-0.9.0.1, bytestring-0.9.0.4, bzlib-0.4.0.1, cairo-0.9.12.1, cgi-3001.1.5.2, containers-0.1.0.1, cpphs-1.5, directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, fingertree-0.0, (ghc-6.8.2), glade-0.9.12.1, glib-0.9.12.1, gtk-0.9.12.1, gtkglext-0.9.12.1, harp-0.2, haskell-src-1.0.1.1, haskell-src-exts-0.2, haskell98-1.0.1.0, hpc-0.5.0.0, hscolour-1.9, hslogger-1.0.4, hsql-1.7, hsql-mysql-1.7, hsql-odbc-1.7, hsql-postgresql-1.7, hsql-sqlite3-1.7, html-1.0.1.1, hxt-7.5, iconv-0.4, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, polyparse-1.1, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, soegtk-0.9.12.1, stm-2.1.1.0, svgcairo-0.9.12.1, tagsoup-0.4, template-haskell-2.2.0.0, time-1.1.2.0, unix-2.3.0.0, utf8-string-0.2, uulib-0.9.5, xhtml-3000.0.2.2, xmonad-0.6, xmonad-contrib-0.6 /home/gwern/.ghc/x86_64-linux-6.8.2/package.conf: AGI-1.1.1, ArrayRef-0.1, AvlTree-2.4, CC-delcont-0.2, COrdering-2.1, Cabal-1.3.3, Cabal-1.3.6, Cabal-1.3.7, Chart-0.5, ChasingBottoms-1.2.2, Codec-Compression-LZF-0.2, ConfigFile-1.0.4, Conjure-0.1, ContArrow-0.0.3, Crypto-4.1.0, DBus-0.1, DeepArrow-0.0.1, DisTract-0.2.5, EdisonAPI-1.2.1, EdisonCore-1.2.1.1, Encode-0.7, Etherbunny-0.3, FileManip-0.3.1, Finance-Quote-Yahoo-0.4.1, FiniteMap-0.1, GLFW-0.2, GLUT-2.1.1.1, HAppS-Data-0.9.1, HAppS-IxSet-0.9.1, HAppS-Server-0.9.1, HAppS-State-0.9.1, HAppS-Util-0.9.1, HCL-1.2, HFuse-0.1, HGL-3.2.0.0, HList-0.1, {HPDF-1.3}, HSH-1.2.5, HStringTemplate-0.1, HTF-0.1, HTTP-3001.0.0, HTTP-Simple-0.1, HaLex-1.1, HaXml-1.13.3, HaXml-1.19.2, HsJudy-0.1, HsJudy-0.1.1, HsOpenSSL-0.3.1, HsSyck-0.41, HsSyck-0.42, IFS-0.1.1, IOSpec-0.1.1, Imlib-0.1, IndentParser-0.2.1, ListLike-1.0.1, MaybeT-0.1.1, MissingH-1.0.0, NewBinary-0.1, OpenGL-2.2.1.1, PArrows-0.1, PostgreSQL-0.2, Postmaster-0.1, QuickCheck-2.0, RJson-0.1, Ranged-sets-0.1.1, Safe-0.1, Shellac-0.9.1, Shellac-readline-0.9, TV-0.2, TypeCompose-0.3, TypeCompose-0.4, {Unixutils-1.14}, X11-1.4.1, X11-1.4.1.20080127, X11-xft-0.2, YamlReference-0.6, ZFS-0.0, anydbm-1.0.4, anydbm-1.0.5, base64-string-0.1, bencode-0.3, binary-0.4.1, binary-strict-0.1, binary-strict-0.2.1, binary-strict-0.2.2, binary-strict-0.3.0, bio-0.2, bio-0.3.3, bktrees-0.2.1, blockio-0.0-2006-02-03, bytestring-0.9.0.1, bytestring-0.9.0.4, cgi-3001.1.5.1, cgi-3001.1.5.2, cgi-undecidable-3000.0.0, child-0.0-2005-02-14, chunks-2007.4.18, condorcet-0.0.1, csv-0.1.1, curl-1.3.2, dataenc-0.10.2, dbus-haskell-0.1, {debian-1.2}, denominate-0.4.1, derive-0.1, derive-0.1.1, dimensional-0.7.2, dlist-0.4, dsp-0.2.1, encoding-0.3, event-list-0.0.5, exif-3000.0.0, fec-0.1.1, filepath-1.1.0.0, fingertree-0.0, fixpoint-0.1, flock-0.1, folkung-2.3, frag-1.1, fst-0.9, ftphs-1.0.4, gal-1.0, gd-3000.4.0, genericserialize-0.1, greencard-3.0.1, greencard-lib-3.0.1, haddock-2.0.0.0, haddock-2.1.0, halfs-0.2, harp-0.2.1, harpy-0.4, haskell-src-exts-0.2.1, haskelldb-0.11, haxr-3000.0.1, hera-ajaxgui-2.1-dev, hera-engine-2.1-dev, hera-prelude-2.1-dev, hfov-1, hinotify-0.2, hinstaller-2007.5.13, hmarkup-3000.0.1, hmatrix-0.2.0.0, hopenssl-0.0-2005-02-14, hosc-0.1, hosc-0.2, hs-fltk-0.2.5, hsc3-0.2, hscurses-1.1, hscurses-1.2, hscurses-1.3, hsdns-1.1, hsemail-1.1, hslogger-1.0.2, hslua-0.2, hsntp-0.1, hsp-0.2, hspr-sh-0.3, hspread-0.2, hstats-0.2, hstringtemplate-0.1, html-1.0.1.1, hybrid-2.0, i18n-0.2, i18n-0.3, idris-0.0.1, infix-0.1, interlude-0.1, ipprint-0.3, irc-0.4, ivor-0.1.5, lax-0.0.0, lazysmallcheck-0.1, libGenI-0.16, libmpd-0.1.3, loch-0.2, magic-1.0.7, markov-chain-0.0.1, memcached-0.1, mersenne-random-0.1, metaplug-0.1.1, midi-0.0.4, miniplex-0.2.2, monad-param-0.0.2, monadLib-3.3.0, monadenv-0.0-2005-02-14, mtlparse-0.0.0.5, nano-md5-0.1.1, network-bytestring-0.1.1, network-bytestring-0.1.1.2, non-negative-0.0.1, numbers-2007.9.25, oeis-0.1, parse-dimacs-1.0, parsedate-3000.0.0, pcap-0.4.2, pcre-light-0.2.1, pcre-light-0.3, plugins-1.1, polyparse-1.1, popenhs-1.0.0, postmaster-0.1, powermate-0.1, pqc-0.2, propgrid-0.1, pugs-HsSyck-0.2, pugs-HsSyck-0.41, pugs-hsregex-1.0, pureMD5-0.1.0, pureMD5-0.1.1, rbr-0.7, rbr-0.8.3, reactive-0.4, regex-base-0.72.0.1, regex-base-0.93.1, regex-posix-0.72.0.2, regex-posix-0.93.1, rss-3000.0.1, safecopy-0.3, scgi-0.1, selenium-0.2.2, sessions-2008.2.20, shell-pipe-0.1, simpleargs-0.1, smallcheck-0.2, smallcheck-0.2.1, stream-fusion-0.1.1, strict-0.3, strict-concurrency-0.1, stringsearch-0.2, supercollider-ht-0.0, syb-with-class-0.4, tagsoup-0.3, tagsoup-0.4, tagsoup-0.5, tar-0.1.1.1, template-0.1.1.1, terminfo-0.1, type-int-0.3, type-level-0.1, uniplate-1.0.1, unix-compat-0.1.2.1, unix-pty-light-0.1, value-supply-0.1, vty-3.0.0, whim-0.1, wl-pprint-1.0, xhtml-3000.0.2.1, xhtml-3000.0.2.2, xmonad-0.6, xmonad-contrib-0.6, xsact-1.6, zlib-0.4.0.2 -- gwern -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 17 22:27:27 2008 From: trac at galois.com (GHC) Date: Mon Mar 17 22:24:15 2008 Subject: [GHC] #2163: GHC makes thunks for Integers we are strict in In-Reply-To: <044.669eae6b361993c49cbaa68b68f5129a@localhost> References: <044.669eae6b361993c49cbaa68b68f5129a@localhost> Message-ID: <053.f7c94edfa25158ec5518407f39e7d210@localhost> #2163: GHC makes thunks for Integers we are strict in --------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Comment (by igloo): We discussed this on IRC - the difference is that Don has an unfolding for `timesInteger`, presumably because he has {{{ SRC_HC_OPTS = -H32m -O2 }}} in his `mk/build.mk`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 18 06:05:24 2008 From: trac at galois.com (GHC) Date: Tue Mar 18 06:02:18 2008 Subject: [GHC] #2117: ppc "./Setup build" seg-faults on Mac OS leopard In-Reply-To: <045.49291ad5dcecd52c54fd505935d3d802@localhost> References: <045.49291ad5dcecd52c54fd505935d3d802@localhost> Message-ID: <054.2a2ed35334b3427e9b29482e62e21a7f@localhost> #2117: ppc "./Setup build" seg-faults on Mac OS leopard ----------------------+----------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by maeder): one furthe note: while the segmentation fault is fixed the irritating warning "'ld: atom sorting error for ...`" is not gone, but can be ignored. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 18 12:12:35 2008 From: trac at galois.com (GHC) Date: Tue Mar 18 12:09:27 2008 Subject: [GHC] #2163: GHC makes thunks for Integers we are strict in In-Reply-To: <044.669eae6b361993c49cbaa68b68f5129a@localhost> References: <044.669eae6b361993c49cbaa68b68f5129a@localhost> Message-ID: <053.c31478c8c9cbf73d2dee4bfe4f4061f1@localhost> #2163: GHC makes thunks for Integers we are strict in --------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: run-time performance bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.9 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: `let` can be strict in Core - it doesn't always indicate a thunk. If you use `-ddump-stg` you'll see that the expression is evaluated strictly, no thunk is built. (don't worry, this often catches me out too. Perhaps a strict let should be indicated more explicitly in `-ddump-simpl`). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 18 12:42:32 2008 From: trac at galois.com (GHC) Date: Tue Mar 18 12:39:17 2008 Subject: [GHC] #2133: Add an instance for IArray (IOToDiffArray IOUArray) Bool In-Reply-To: <047.84d1024b9f4e1b32d187e48c3a931e7f@localhost> References: <047.84d1024b9f4e1b32d187e48c3a931e7f@localhost> Message-ID: <056.c7f1a3b49d67635a05cdccb48129c0a2@localhost> #2133: Add an instance for IArray (IOToDiffArray IOUArray) Bool -------------------------------+-------------------------------------------- Reporter: Deewiant | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Comment (by Deewiant): Discussion time is over; the archive can be found at http://www.haskell.org/pipermail/libraries/2008-March/009414.html No comments were made. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 18 13:38:48 2008 From: trac at galois.com (GHC) Date: Tue Mar 18 13:35:45 2008 Subject: [GHC] #1699: Fix network wrt abstract unix sockets In-Reply-To: <064.885c49d5fecaaffdac334b45404fbbd4@localhost> References: <064.885c49d5fecaaffdac334b45404fbbd4@localhost> Message-ID: <073.bcbe93a5b6089c8230983dd466cc1b6f@localhost> #1699: Fix network wrt abstract unix sockets ---------------------------------------+------------------------------------ Reporter: kolmodin@dtek.chalmers.se | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.6.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ---------------------------------------+------------------------------------ Changes (by duncan): * severity: normal => major Comment: I'd like to point out that this is actually important. Kolmodin didn't explain what he needs this for, he needs it for the [http://dbus.freedesktop.org/ D-Bus] library that he has written. The library is pretty cool. Progress on the lib has been stalled for months because of this issue. Instead of using the D-Bus C library he has written a protocol level implementation in pure Haskell. It works fairly well and is nearly complete. The D-Bus protocol uses unix sockets and on Linux it uses an "abstract" unix socket. Normal unix sockets use the filesystem namespace while "abstract" unix sockets live in a separate namespace. This is of course a linux only extension but it is nevertheless essential to support in some manner. The quirk in the implementation of abstract unix sockets on linux is that it reuses the same system call as normal unix sockets but one has to prepend a '\0' to the name. This works because the length of the string name is given explicitly when making the system call. It doesn't work in the network lib binding because we assume (not unreasonably) that there are no embeded '\0' characters in the socket name. As I see it we have two options, explicitly support them in the API, eg by providing a linux-only function to open an abstract unix socket, and it'd handle the prepending of the '\0'. Alternatively we could not explicitly support this linux-only feature, but not actively prevent it. We could do the latter by changing the handling of CStrings in the socket binding so that it uses CStringLen with an explicit length and therefore allows embedded '\0' characters. I think I'd advocate the latter approach. It does not change the Haskell api, it does not affect other operating systems and it does not explicitly advertise support for this OS-specific feature, but it does not prevent it from working. We don't often need this quirky feature but in at least this one case it's essential. So we need to come to some decision. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 18 15:42:32 2008 From: trac at galois.com (GHC) Date: Tue Mar 18 15:39:19 2008 Subject: [GHC] #2165: Type checker for Type families Message-ID: <047.1189d6f687984192acc01b6aecbe6360@localhost> #2165: Type checker for Type families -------------------------+-------------------------------------------------- Reporter: hpacheco | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- For a type family and a class definition: type family F a x :: * class FunctorF x where fmapF :: d -> (a -> b) -> F x a -> F x b Curiously if I have {{{ fff a = fmapF a id }}} it compiles correctly. But if I infer the type signature of fff I get {{{ fff :: forall d x. (FunctorF d) => d -> F d x -> F d x }}} On the other side, a similar problem as before arises when {{{ fff :: forall d x. (FunctorF d) => d -> F d x -> F d x fff a = fmapF a id }}} This follows up from http://hackage.haskell.org/trac/ghc/ticket/2157 On Tue, Mar 18, 2008 at 7:03 PM, Ryan Ingram wrote: Interestingly, this works when you also give a type signature to "id": {{{ fff :: forall d x. (FunctorF d) => d -> F d x -> F d x fff a = fmapF a (id :: x -> x) }}} compiles for me (ghc6.8.2). There's probably a bug in the type checker; inference is working with no type signatures, but checking fails. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 18 18:31:30 2008 From: trac at galois.com (GHC) Date: Tue Mar 18 18:28:23 2008 Subject: [GHC] #1699: Fix network wrt abstract unix sockets In-Reply-To: <064.885c49d5fecaaffdac334b45404fbbd4@localhost> References: <064.885c49d5fecaaffdac334b45404fbbd4@localhost> Message-ID: <073.34aa68614553c685d09404d4fba6980e@localhost> #1699: Fix network wrt abstract unix sockets ---------------------------------------+------------------------------------ Reporter: kolmodin@dtek.chalmers.se | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.6.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ---------------------------------------+------------------------------------ Comment (by kolmodin): Right, maybe I should have been more clear why I've been bugging you about this :) It seems that D-Bus is the main app forcing languages to implement this linux specific feature, ruby also implemented it to support a pure ruby implementation. While forced to keep track of the address length I also wrote the previous post to clean up a bit. Many other languages expose the C network API to their users. As we've noticed above, the difference is a prepending {{{'\0'}}} instead of a trailing one. Just making the network lib understand {{{(UnixSocket ('\0:path))}}} would be perfectly fine by me, reusing the previous constructor. That would work on any linux system, and on other *nix it would probably complain that the address path is zero bytes long. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 19 07:39:28 2008 From: trac at galois.com (GHC) Date: Wed Mar 19 07:36:12 2008 Subject: [GHC] #2166: minBound `rem` (-1) fails Message-ID: <048.d9e4a08beac82a119a49bd5bd8ce1bb9@localhost> #2166: minBound `rem` (-1) fails --------------------------+------------------------------------------------- Reporter: atsampson | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: x86 | Os: Linux --------------------------+------------------------------------------------- I would expect both of the following operations to return 0, on the grounds that anything rem/mod -1 is zero: {{{ Prelude> (minBound :: Int) `rem` (-1) *** Exception: arithmetic overflow Prelude> (minBound :: Int) `mod` (-1) *** Exception: arithmetic overflow }}} In GHC 6.8.2, the instances of Integral for the various integer types explicitly check for this case and throw the error: {{{ rem x@(I32# x#) y@(I32# y#) | y == 0 = divZeroError | x == minBound && y == (-1) = overflowError | otherwise = I32# (x# `remInt32#` y#) }}} The current behaviour makes some sense in that rem/mod's behaviours are defined in terms of quot/div which can't give a sensible output for these input values -- but I can't really see anything wrong with changing the second guard there to return {{{0}}}. (I ran into this while implementing constant expression folding in a compiler for the occam programming language; the occam compiler test suite explicitly checks that {{{minBound `rem` (-1) == 0}}}.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 19 08:29:08 2008 From: trac at galois.com (GHC) Date: Wed Mar 19 08:25:51 2008 Subject: [GHC] #2156: compilation math/truncate bug with optimization enabled In-Reply-To: <046.2a8dd59bec3a6add575599c4a29f05cc@localhost> References: <046.2a8dd59bec3a6add575599c4a29f05cc@localhost> Message-ID: <055.88fac99e8f8ce734ba5dc9b192005dc2@localhost> #2156: compilation math/truncate bug with optimization enabled -------------------------+-------------------------------------------------- Reporter: trevorm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- Comment (by trevorm): On investigating further I see that the optimized code generated is {{{ subl $8, %esp ; fnstcw 4(%esp) ffree %st(7) ; fld %st(0) movzwl 4(%esp), %eax ; orl $0xC00, %eax movl %eax, 0(%esp) ; fldcw 0(%esp) fistpl 0(%esp) fldcw 4(%esp) ; movl 0(%esp), %eax }}} which sets rounding mode to chop and then converts to integer. So the value 2 is correct according to the definition of truncate. So the optimized code behaves as if the values are Double precision, while the unoptimized code behaves as if they have better (infinite?) precision -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 19 10:10:09 2008 From: trac at galois.com (GHC) Date: Wed Mar 19 10:06:55 2008 Subject: [GHC] #2133: Add an instance for IArray (IOToDiffArray IOUArray) Bool In-Reply-To: <047.84d1024b9f4e1b32d187e48c3a931e7f@localhost> References: <047.84d1024b9f4e1b32d187e48c3a931e7f@localhost> Message-ID: <056.0928df70d1652b13e474c15734d23959@localhost> #2133: Add an instance for IArray (IOToDiffArray IOUArray) Bool -------------------------------+-------------------------------------------- Reporter: Deewiant | Owner: igloo Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 19 10:15:20 2008 From: trac at galois.com (GHC) Date: Wed Mar 19 10:12:02 2008 Subject: [GHC] #1611: Data.Map, Data.IntMap documentation In-Reply-To: <044.0a1673a15438e997efb02c442861a7c1@localhost> References: <044.0a1673a15438e997efb02c442861a7c1@localhost> Message-ID: <053.54dfa2aa2acce2102f1abb21472b46d5@localhost> #1611: Data.Map, Data.IntMap documentation ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Difficult (1 week) Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 19 11:08:02 2008 From: trac at galois.com (GHC) Date: Wed Mar 19 11:04:46 2008 Subject: [GHC] #2166: minBound `rem` (-1) fails In-Reply-To: <048.d9e4a08beac82a119a49bd5bd8ce1bb9@localhost> References: <048.d9e4a08beac82a119a49bd5bd8ce1bb9@localhost> Message-ID: <057.e78cdf89c164ca05c78fa26754b41abd@localhost> #2166: minBound `rem` (-1) fails ----------------------------+----------------------------------------------- Reporter: atsampson | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.8.2 Severity: minor | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: It would be odd for {{{ (minBound :: Int) `rem` (-1) }}} to be different to {{{ snd ((minBound :: Int) `quotRem` (-1)) }}} Perhaps we could also say {{{ quotRem x y | x == minBound && y == (-1) = (overflowError, 0) }}} although then the exception won't be thrown until later (is that good or bad?). Anyway, can you please make a [http://www.haskell.org/haskellwiki/Library_submissions library submissions proposal] for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 19 12:44:15 2008 From: trac at galois.com (GHC) Date: Wed Mar 19 12:40:58 2008 Subject: [GHC] #2133: Add an instance for IArray (IOToDiffArray IOUArray) Bool In-Reply-To: <047.84d1024b9f4e1b32d187e48c3a931e7f@localhost> References: <047.84d1024b9f4e1b32d187e48c3a931e7f@localhost> Message-ID: <056.aafba0c157ca0a84d50d3ce8379182b1@localhost> #2133: Add an instance for IArray (IOToDiffArray IOUArray) Bool -------------------------------+-------------------------------------------- Reporter: Deewiant | Owner: igloo Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Patch applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 19 12:44:28 2008 From: trac at galois.com (GHC) Date: Wed Mar 19 12:41:12 2008 Subject: [GHC] #1611: Data.Map, Data.IntMap documentation In-Reply-To: <044.0a1673a15438e997efb02c442861a7c1@localhost> References: <044.0a1673a15438e997efb02c442861a7c1@localhost> Message-ID: <053.442af9d13f4871d25bde8270f3fa26d6@localhost> #1611: Data.Map, Data.IntMap documentation ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Difficult (1 week) Testcase: | Architecture: Multiple Os: Multiple | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Patch applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 19 19:11:11 2008 From: trac at galois.com (GHC) Date: Wed Mar 19 19:08:00 2008 Subject: [GHC] #2156: compilation math/truncate bug with optimization enabled In-Reply-To: <046.2a8dd59bec3a6add575599c4a29f05cc@localhost> References: <046.2a8dd59bec3a6add575599c4a29f05cc@localhost> Message-ID: <055.6d93566c237a75607fc9b85de8bada97@localhost> #2156: compilation math/truncate bug with optimization enabled ----------------------+----------------------------------------------------- Reporter: trevorm | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: So I take it this is an instance of the unpredictability in floating-point that we get on x86 due to the floating point registers being wider than a Double? When compiling via C we use gcc's `-ffloat-store` which forces the precision to be 64 bits everywhere (albeit expensively). The native code generator does not do this, although #594 will fix it eventually. See also #1916, where the previously buggy truncate implementation was fixed in the x86 native code gen in 6.8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 19 20:24:31 2008 From: trac at galois.com (GHC) Date: Wed Mar 19 20:21:15 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.fa662ad75dc7a1823bfad4c8c27754b1@localhost> #2157: Equality Constraints with Type Families ----------------------------------------+----------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------------+----------------------------------- Comment (by chak): Replying to [comment:3 claus]: > Replying to [comment:2 chak]: > > On the other hand, given > > {{{ > > type family F a :: * -> * > > }}} > > an equality of the form `F a1 b1 ~ F a2 b2` implies `F a1 ~ F a2` and `b1 ~ b2` as always in Haskell > > i had problems with this statement, until i stopped thinking of "type functions" (which would allow constant functions violating your assumption) and thought of "phantom types" (all type parameters matter, even if they disappear in the result). if that association is useful, though, you might want to disallow partially applied type synonyms in type instances - `Const` and `f` seem fishy here (wrt your implication, at least): {{{ {-# LANGUAGE TypeFamilies #-} type family Const a :: * -> * type instance Const a = C a type C a t = a }}} Why do you think `Const` is fishy? Maybe I should make more precise what I regard as ''partial application'' in the context of type families. If you look at [http://haskell.org/haskellwiki/GHC/Type_families the type family specification] in Section 7.1, it says that the arity of a type family is the number of parameters given in the type family declaration. In the case of `Const`, this is 1 (namely `a`), '''not''' 2 (as you might think if you only consider the kind of `Const`). Whenever a type family is used, you must supply '''at least''' as many type arguments as the arity of the type family suggests. So, in the case of `Const`, a single argument suffices. Do you think Section 7 of [http://haskell.org/haskellwiki/GHC/Type_families the type family specification] is unclear on that matter. If so, I'd be grateful for any suggestions that make the specification clearer. NB: The rules for what constitutes a valid partial application of a vanilla type synonym are different, see [http://www.haskell.org/ghc/docs/latest/html/users_guide/data-type- extensions.html#type-synonyms] This may be somewhat confusing, but I don't think there is much we can do about this, as the present definitions are crucial to get a sound type system. (Well, we could restrict what you can do with vanilla synonyms, but we'd like to stay backwards compatible to H98 and, I guess, people would also not be happy to sacrifice any of the currently offered expressiveness.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 19 20:39:00 2008 From: trac at galois.com (GHC) Date: Wed Mar 19 20:35:45 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.8f2fb533ecc26630f6c9a3bdaca46c25@localhost> #2157: Equality Constraints with Type Families ----------------------------------------+----------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------------+----------------------------------- Comment (by chak): Replying to [comment:6 hpacheco]: > Curiously if I have > > > {{{ > fff a = fmapF a id > }}} > > > it compiles correctly. > But if I infer the type signature of fff I get > > > {{{ > fff :: forall d x. (FunctorF d) => d -> F d x -> F d x > }}} > > > On the other side, a similar problem as before arises when > > > {{{ > fff :: forall d x. (FunctorF d) => d -> F d x -> F d x > fff a = fmapF a id > }}} > > > fails to compile. > This must be a bug. Sorry for all this posts. No, it's not as bug. The problem is that the variable `x` occurs '''only''' as a type-index to the type family in the signature. Remember from above, as the arity of `F` is 2, given `F a1 b1 ~ F a2 b2` we '''can not''' deduce that `a1 ~ a2` and `b1 ~ b2`. (We need to explain that better in the type family documentation...) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 19 20:42:37 2008 From: trac at galois.com (GHC) Date: Wed Mar 19 20:39:21 2008 Subject: [GHC] #2165: Type checker for Type families In-Reply-To: <047.1189d6f687984192acc01b6aecbe6360@localhost> References: <047.1189d6f687984192acc01b6aecbe6360@localhost> Message-ID: <056.83b796cdfbaffc2fb6f44851b913f37a@localhost> #2165: Type checker for Type families ----------------------------------------+----------------------------------- Reporter: hpacheco | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- Changes (by chak): * owner: => chak Comment: This is not a bug as I just explained in #2157. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 19 20:42:59 2008 From: trac at galois.com (GHC) Date: Wed Mar 19 20:39:42 2008 Subject: [GHC] #2165: Type checker for Type families In-Reply-To: <047.1189d6f687984192acc01b6aecbe6360@localhost> References: <047.1189d6f687984192acc01b6aecbe6360@localhost> Message-ID: <056.905d6c9da05a031631423dce26077b8f@localhost> #2165: Type checker for Type families ----------------------------------------+----------------------------------- Reporter: hpacheco | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: invalid Keywords: | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------+----------------------------------- Changes (by chak): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 20 06:34:06 2008 From: trac at galois.com (GHC) Date: Thu Mar 20 06:30:58 2008 Subject: [GHC] #2167: The -main-is option to runghc does not appear to work. Message-ID: <042.26782109759233e42fa49e7dd26bf4be@localhost> #2167: The -main-is option to runghc does not appear to work. -----------------------+---------------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: NetBSD -----------------------+---------------------------------------------------- The -main-is option to runghc does not appear to work, at least not when specifying a package name. Create Hello.hs: module Hello where main = putStrLn "Hello." and then try to run it: runghc -main-is Hello Hello.hs You will see: :1:113: Failed to load interface for `Main': Use -v to see a list of the files searched for. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 20 08:44:22 2008 From: trac at galois.com (GHC) Date: Thu Mar 20 08:41:05 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.8beb2171a878d84f08a75004ee83a6b7@localhost> #2157: Equality Constraints with Type Families ----------------------------------------+----------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------------+----------------------------------- Comment (by claus): Replying to [comment:7 chak]: > > > {{{ > > > type family F a :: * -> * > > > }}} > > > an equality of the form `F a1 b1 ~ F a2 b2` implies `F a1 ~ F a2` and `b1 ~ b2` as always in Haskell > > > > i had problems with this statement, until i stopped thinking of "type functions" (which would allow constant functions violating your assumption) and thought of "phantom types" (all type parameters matter, even if they disappear in the result). if that association is useful, though, you might want to disallow partially applied type synonyms in type instances - `Const` and `f` seem fishy here (wrt your implication, at least): > {{{ > {-# LANGUAGE TypeFamilies #-} > > type family Const a :: * -> * > type instance Const a = C a > type C a t = a > }}} > > Why do you think `Const` is fishy? because: - type synonym `C` appears partially applied in what amounts to a type class instance parameter position (the rhs of the Const instance) - the implementation definitely does not behave as if your decomposition played any role (parameters of both `Const Bool Int` and `Const Bool Char` are used as/converted to `Bool`, hence equal types even though `Int` does not equal `Char`). nor do the permitted and not-permitted conversions in `f` seem consistent - compare also: http://www.haskell.org/pipermail/haskell-cafe/2008-March/040788.html http://www.haskell.org/pipermail/haskell-cafe/2008-March/040790.html > Maybe I should make more precise what I regard as ''partial application'' in the context of type families. it isn't about partial applications of type families (even though the different sorts of parameters there take some getting used to), but about good old-fashioned partial applications of type synonyms in new contexts. i guess they are permitted here because the rhs of a type instance uses the same grammar non-terminal as the rhs of a type synonym, but i suspect that the rhs of a type instance might have to be treated like a type parameter of a type class instance. but that is just a guess - the main issues here are the decomposition rule, which i don't quite understand, and which doesn't quite seem to be used in the implementation, and the equalities/conversions permitted in the implementation, which do not seem to be consistent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 20 09:20:45 2008 From: trac at galois.com (GHC) Date: Thu Mar 20 09:18:22 2008 Subject: [GHC] #1687: A faster (^)-function. In-Reply-To: <064.1e051c3fce5c2da263cdc0424cf20634@localhost> References: <064.1e051c3fce5c2da263cdc0424cf20634@localhost> Message-ID: <073.f7c7633c76daa361c97ec752c4143208@localhost> #1687: A faster (^)-function. ---------------------------------------+------------------------------------ Reporter: moonlite@dtek.chalmers.se | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Prelude | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------------------------+------------------------------------ Changes (by igloo): * milestone: 6.8 branch => _|_ Comment: I've changed the definition to: {{{ (^) :: (Num a, Integral b) => a -> b -> a x0 ^ y0 | y0 < 0 = error "Negative exponent" | y0 == 0 = 1 | otherwise = f x0 y0 1 where -- x0 ^ y0 = (x ^ y) * z f x y z | even y = f (x * x) (y `quot` 2) z | y == 1 = x * z | otherwise = f (x * x) ((y - 1) `quot` 2) (x * z) }}} which is as fast as I've seen for `Int`, and matches your definition's performance for `Integer` when computing {{{(2^(2^27)) `mod` 2}}}, but it's about half the speed of your definition when computing {{{(2^((2^27)-1)) `mod` 2}}}. I don't know why that is - I can't see a reason at the core/STG level. I'll leave the ticket open, but milestone _|_, in case anyone wants to look into it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 20 10:56:22 2008 From: trac at galois.com (GHC) Date: Thu Mar 20 10:53:05 2008 Subject: [GHC] #1699: Fix network wrt abstract unix sockets In-Reply-To: <064.885c49d5fecaaffdac334b45404fbbd4@localhost> References: <064.885c49d5fecaaffdac334b45404fbbd4@localhost> Message-ID: <073.6fb7b2748849f301029e312f990518a0@localhost> #1699: Fix network wrt abstract unix sockets ---------------------------------------+------------------------------------ Reporter: kolmodin@dtek.chalmers.se | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.6.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ---------------------------------------+------------------------------------ Comment (by igloo): I'm having a bit of trouble seeing exactly what change you want to make, hidden amongst all the type-changing cleanup. Can we do what you want by just having a new function `foo'` which is the same as some existing function `foo` except that it takes a length argument rather than calculating the length itself? Or have I got the wrong end of the stick? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 20 11:08:08 2008 From: trac at galois.com (GHC) Date: Thu Mar 20 11:04:47 2008 Subject: [GHC] #2164: zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd In-Reply-To: <044.65631559df6ce2cd79a1eb038ea82f5f@localhost> References: <044.65631559df6ce2cd79a1eb038ea82f5f@localhost> Message-ID: <053.7fffe5e7c8afad0fdca2ab83bbe4fd98@localhost> #2164: zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > So, I was recently looking at ZMachine, which is an emulator written in > Haskell for the Infocom text adventures. It can be gotten from darcs > here: . > > Anyway, I did some editing and installed and I tried it out on one of the > text adventures SamB included in the repo: > > gwern@localhost:1013~/bin/ZMachine>zmachine Museum.z5 > [10:06PM] > [finding abbrev 0 at $84][finding abbrev 1 at $8c][(0,"look"),(5,"map")] > [(0,"look"),(5,"map")] > zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd > (GHC version 6.8.2 for x86_64_unknown_linux) > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > zsh: abort zmachine Museum.z5 > > In this case, one of the objects in the room was a map, so I typed in the > sensible 'look map', and that is what happened. (In case you were > wondering, 'look at map' works fine, but you can then go 'look map' and > it crashes with the same exact error.) > > SamB doesn't remember putting in anything dangerous which he'd expect to > do that. More importantly, when he runs from the same repo and tries out > the same sequence he sees: > 21:57 < SamB> [finding abbrev 0 at $84][finding abbrev 1 at > $8c][(0,"look"),(5,"map")] > 21:57 < SamB> [(0,"look"),(5,"map")] > > No crash. He says he's on a Pentium 4, i386 architecture, while I'm using > a quad-core Intel (x86_64, ~amd64 Gentoo) > > --- > SamB: Linux hydrogen 2.6.22-2-686 #1 SMP Fri Aug 31 00:24:01 UTC 2007 > i686 GNU/Linux > > gwern@localhost:1013~/bin/ZMachine>uname -a > [10:07PM] > Linux localhost 2.6.24-gentoo-r3 #6 SMP PREEMPT Fri Mar 14 21:40:34 EDT > 2008 x86_64 Intel(R) Core(TM)2 Quad CPU @ 2.40GHz GenuineIntel GNU/Linux > > gwern@localhost:1014~/bin/ZMachine>ghc-pkg list > [10:12PM] > /usr/lib64/ghc-6.8.2/package.conf: > ALUT-2.1.0.0, Cabal-1.2.3.0, GLUT-2.1.1.1, HDBC-1.1.4, > HDBC-odbc-1.1.4.0, HDBC-postgresql-1.1.4.0, HDBC-sqlite3-1.1.4.0, > HGL-3.2.0.0, HTTP-3001.0.4, HUnit-1.2.0.0, OpenAL-1.3.1.1, > OpenGL-2.2.1.1, QuickCheck-1.1.0.0, Stream-0.2.2, X11-1.4.1, > X11-xft-0.2, array-0.1.0.0, arrows-0.3, base-3.0.1.0, > bytestring-0.9.0.1, bytestring-0.9.0.4, bzlib-0.4.0.1, > cairo-0.9.12.1, cgi-3001.1.5.2, containers-0.1.0.1, cpphs-1.5, > directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, fingertree-0.0, > (ghc-6.8.2), glade-0.9.12.1, glib-0.9.12.1, gtk-0.9.12.1, > gtkglext-0.9.12.1, harp-0.2, haskell-src-1.0.1.1, > haskell-src-exts-0.2, haskell98-1.0.1.0, hpc-0.5.0.0, hscolour-1.9, > hslogger-1.0.4, hsql-1.7, hsql-mysql-1.7, hsql-odbc-1.7, > hsql-postgresql-1.7, hsql-sqlite3-1.7, html-1.0.1.1, hxt-7.5, > iconv-0.4, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, > old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.0, > parsec-2.1.0.0, polyparse-1.1, pretty-1.0.0.0, process-1.0.0.0, > random-1.0.0.0, readline-1.0.1.0, regex-base-0.72.0.1, > regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, > soegtk-0.9.12.1, stm-2.1.1.0, svgcairo-0.9.12.1, tagsoup-0.4, > template-haskell-2.2.0.0, time-1.1.2.0, unix-2.3.0.0, > utf8-string-0.2, uulib-0.9.5, xhtml-3000.0.2.2, xmonad-0.6, > xmonad-contrib-0.6 > /home/gwern/.ghc/x86_64-linux-6.8.2/package.conf: > AGI-1.1.1, ArrayRef-0.1, AvlTree-2.4, CC-delcont-0.2, > COrdering-2.1, Cabal-1.3.3, Cabal-1.3.6, Cabal-1.3.7, Chart-0.5, > ChasingBottoms-1.2.2, Codec-Compression-LZF-0.2, ConfigFile-1.0.4, > Conjure-0.1, ContArrow-0.0.3, Crypto-4.1.0, DBus-0.1, > DeepArrow-0.0.1, DisTract-0.2.5, EdisonAPI-1.2.1, > EdisonCore-1.2.1.1, Encode-0.7, Etherbunny-0.3, FileManip-0.3.1, > Finance-Quote-Yahoo-0.4.1, FiniteMap-0.1, GLFW-0.2, GLUT-2.1.1.1, > HAppS-Data-0.9.1, HAppS-IxSet-0.9.1, HAppS-Server-0.9.1, > HAppS-State-0.9.1, HAppS-Util-0.9.1, HCL-1.2, HFuse-0.1, > HGL-3.2.0.0, HList-0.1, {HPDF-1.3}, HSH-1.2.5, HStringTemplate-0.1, > HTF-0.1, HTTP-3001.0.0, HTTP-Simple-0.1, HaLex-1.1, HaXml-1.13.3, > HaXml-1.19.2, HsJudy-0.1, HsJudy-0.1.1, HsOpenSSL-0.3.1, > HsSyck-0.41, HsSyck-0.42, IFS-0.1.1, IOSpec-0.1.1, Imlib-0.1, > IndentParser-0.2.1, ListLike-1.0.1, MaybeT-0.1.1, MissingH-1.0.0, > NewBinary-0.1, OpenGL-2.2.1.1, PArrows-0.1, PostgreSQL-0.2, > Postmaster-0.1, QuickCheck-2.0, RJson-0.1, Ranged-sets-0.1.1, > Safe-0.1, Shellac-0.9.1, Shellac-readline-0.9, TV-0.2, > TypeCompose-0.3, TypeCompose-0.4, {Unixutils-1.14}, X11-1.4.1, > X11-1.4.1.20080127, X11-xft-0.2, YamlReference-0.6, ZFS-0.0, > anydbm-1.0.4, anydbm-1.0.5, base64-string-0.1, bencode-0.3, > binary-0.4.1, binary-strict-0.1, binary-strict-0.2.1, > binary-strict-0.2.2, binary-strict-0.3.0, bio-0.2, bio-0.3.3, > bktrees-0.2.1, blockio-0.0-2006-02-03, bytestring-0.9.0.1, > bytestring-0.9.0.4, cgi-3001.1.5.1, cgi-3001.1.5.2, > cgi-undecidable-3000.0.0, child-0.0-2005-02-14, chunks-2007.4.18, > condorcet-0.0.1, csv-0.1.1, curl-1.3.2, dataenc-0.10.2, > dbus-haskell-0.1, {debian-1.2}, denominate-0.4.1, derive-0.1, > derive-0.1.1, dimensional-0.7.2, dlist-0.4, dsp-0.2.1, > encoding-0.3, event-list-0.0.5, exif-3000.0.0, fec-0.1.1, > filepath-1.1.0.0, fingertree-0.0, fixpoint-0.1, flock-0.1, > folkung-2.3, frag-1.1, fst-0.9, ftphs-1.0.4, gal-1.0, gd-3000.4.0, > genericserialize-0.1, greencard-3.0.1, greencard-lib-3.0.1, > haddock-2.0.0.0, haddock-2.1.0, halfs-0.2, harp-0.2.1, harpy-0.4, > haskell-src-exts-0.2.1, haskelldb-0.11, haxr-3000.0.1, > hera-ajaxgui-2.1-dev, hera-engine-2.1-dev, hera-prelude-2.1-dev, > hfov-1, hinotify-0.2, hinstaller-2007.5.13, hmarkup-3000.0.1, > hmatrix-0.2.0.0, hopenssl-0.0-2005-02-14, hosc-0.1, hosc-0.2, > hs-fltk-0.2.5, hsc3-0.2, hscurses-1.1, hscurses-1.2, hscurses-1.3, > hsdns-1.1, hsemail-1.1, hslogger-1.0.2, hslua-0.2, hsntp-0.1, > hsp-0.2, hspr-sh-0.3, hspread-0.2, hstats-0.2, hstringtemplate-0.1, > html-1.0.1.1, hybrid-2.0, i18n-0.2, i18n-0.3, idris-0.0.1, > infix-0.1, interlude-0.1, ipprint-0.3, irc-0.4, ivor-0.1.5, > lax-0.0.0, lazysmallcheck-0.1, libGenI-0.16, libmpd-0.1.3, > loch-0.2, magic-1.0.7, markov-chain-0.0.1, memcached-0.1, > mersenne-random-0.1, metaplug-0.1.1, midi-0.0.4, miniplex-0.2.2, > monad-param-0.0.2, monadLib-3.3.0, monadenv-0.0-2005-02-14, > mtlparse-0.0.0.5, nano-md5-0.1.1, network-bytestring-0.1.1, > network-bytestring-0.1.1.2, non-negative-0.0.1, numbers-2007.9.25, > oeis-0.1, parse-dimacs-1.0, parsedate-3000.0.0, pcap-0.4.2, > pcre-light-0.2.1, pcre-light-0.3, plugins-1.1, polyparse-1.1, > popenhs-1.0.0, postmaster-0.1, powermate-0.1, pqc-0.2, > propgrid-0.1, pugs-HsSyck-0.2, pugs-HsSyck-0.41, pugs-hsregex-1.0, > pureMD5-0.1.0, pureMD5-0.1.1, rbr-0.7, rbr-0.8.3, reactive-0.4, > regex-base-0.72.0.1, regex-base-0.93.1, regex-posix-0.72.0.2, > regex-posix-0.93.1, rss-3000.0.1, safecopy-0.3, scgi-0.1, > selenium-0.2.2, sessions-2008.2.20, shell-pipe-0.1, simpleargs-0.1, > smallcheck-0.2, smallcheck-0.2.1, stream-fusion-0.1.1, strict-0.3, > strict-concurrency-0.1, stringsearch-0.2, supercollider-ht-0.0, > syb-with-class-0.4, tagsoup-0.3, tagsoup-0.4, tagsoup-0.5, > tar-0.1.1.1, template-0.1.1.1, terminfo-0.1, type-int-0.3, > type-level-0.1, uniplate-1.0.1, unix-compat-0.1.2.1, > unix-pty-light-0.1, value-supply-0.1, vty-3.0.0, whim-0.1, > wl-pprint-1.0, xhtml-3000.0.2.1, xhtml-3000.0.2.2, xmonad-0.6, > xmonad-contrib-0.6, xsact-1.6, zlib-0.4.0.2 > > -- > gwern New description: So, I was recently looking at ZMachine, which is an emulator written in Haskell for the Infocom text adventures. It can be gotten from darcs here: . Anyway, I did some editing and installed and I tried it out on one of the text adventures SamB included in the repo: {{{ gwern@localhost:1013~/bin/ZMachine>zmachine Museum.z5 [10:06PM] [finding abbrev 0 at $84][finding abbrev 1 at $8c][(0,"look"),(5,"map")] [(0,"look"),(5,"map")] zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd (GHC version 6.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort zmachine Museum.z5 }}} In this case, one of the objects in the room was a map, so I typed in the sensible 'look map', and that is what happened. (In case you were wondering, 'look at map' works fine, but you can then go 'look map' and it crashes with the same exact error.) SamB doesn't remember putting in anything dangerous which he'd expect to do that. More importantly, when he runs from the same repo and tries out the same sequence he sees: {{{ 21:57 < SamB> [finding abbrev 0 at $84][finding abbrev 1 at $8c][(0,"look"),(5,"map")] 21:57 < SamB> [(0,"look"),(5,"map")] }}} No crash. He says he's on a Pentium 4, i386 architecture, while I'm using a quad-core Intel (x86_64, ~amd64 Gentoo) --- {{{ SamB: Linux hydrogen 2.6.22-2-686 #1 SMP Fri Aug 31 00:24:01 UTC 2007 i686 GNU/Linux gwern@localhost:1013~/bin/ZMachine>uname -a [10:07PM] Linux localhost 2.6.24-gentoo-r3 #6 SMP PREEMPT Fri Mar 14 21:40:34 EDT 2008 x86_64 Intel(R) Core(TM)2 Quad CPU @ 2.40GHz GenuineIntel GNU/Linux gwern@localhost:1014~/bin/ZMachine>ghc-pkg list [10:12PM] /usr/lib64/ghc-6.8.2/package.conf: ALUT-2.1.0.0, Cabal-1.2.3.0, GLUT-2.1.1.1, HDBC-1.1.4, HDBC-odbc-1.1.4.0, HDBC-postgresql-1.1.4.0, HDBC-sqlite3-1.1.4.0, HGL-3.2.0.0, HTTP-3001.0.4, HUnit-1.2.0.0, OpenAL-1.3.1.1, OpenGL-2.2.1.1, QuickCheck-1.1.0.0, Stream-0.2.2, X11-1.4.1, X11-xft-0.2, array-0.1.0.0, arrows-0.3, base-3.0.1.0, bytestring-0.9.0.1, bytestring-0.9.0.4, bzlib-0.4.0.1, cairo-0.9.12.1, cgi-3001.1.5.2, containers-0.1.0.1, cpphs-1.5, directory-1.0.0.0, fgl-5.4.1.1, filepath-1.1.0.0, fingertree-0.0, (ghc-6.8.2), glade-0.9.12.1, glib-0.9.12.1, gtk-0.9.12.1, gtkglext-0.9.12.1, harp-0.2, haskell-src-1.0.1.1, haskell-src-exts-0.2, haskell98-1.0.1.0, hpc-0.5.0.0, hscolour-1.9, hslogger-1.0.4, hsql-1.7, hsql-mysql-1.7, hsql-odbc-1.7, hsql-postgresql-1.7, hsql-sqlite3-1.7, html-1.0.1.1, hxt-7.5, iconv-0.4, mtl-1.1.0.0, network-2.1.0.0, old-locale-1.0.0.0, old-time-1.0.0.0, packedstring-0.1.0.0, parallel-1.0.0.0, parsec-2.1.0.0, polyparse-1.1, pretty-1.0.0.0, process-1.0.0.0, random-1.0.0.0, readline-1.0.1.0, regex-base-0.72.0.1, regex-compat-0.71.0.1, regex-posix-0.72.0.2, rts-1.0, soegtk-0.9.12.1, stm-2.1.1.0, svgcairo-0.9.12.1, tagsoup-0.4, template-haskell-2.2.0.0, time-1.1.2.0, unix-2.3.0.0, utf8-string-0.2, uulib-0.9.5, xhtml-3000.0.2.2, xmonad-0.6, xmonad-contrib-0.6 /home/gwern/.ghc/x86_64-linux-6.8.2/package.conf: AGI-1.1.1, ArrayRef-0.1, AvlTree-2.4, CC-delcont-0.2, COrdering-2.1, Cabal-1.3.3, Cabal-1.3.6, Cabal-1.3.7, Chart-0.5, ChasingBottoms-1.2.2, Codec-Compression-LZF-0.2, ConfigFile-1.0.4, Conjure-0.1, ContArrow-0.0.3, Crypto-4.1.0, DBus-0.1, DeepArrow-0.0.1, DisTract-0.2.5, EdisonAPI-1.2.1, EdisonCore-1.2.1.1, Encode-0.7, Etherbunny-0.3, FileManip-0.3.1, Finance-Quote-Yahoo-0.4.1, FiniteMap-0.1, GLFW-0.2, GLUT-2.1.1.1, HAppS-Data-0.9.1, HAppS-IxSet-0.9.1, HAppS-Server-0.9.1, HAppS-State-0.9.1, HAppS-Util-0.9.1, HCL-1.2, HFuse-0.1, HGL-3.2.0.0, HList-0.1, {HPDF-1.3}, HSH-1.2.5, HStringTemplate-0.1, HTF-0.1, HTTP-3001.0.0, HTTP-Simple-0.1, HaLex-1.1, HaXml-1.13.3, HaXml-1.19.2, HsJudy-0.1, HsJudy-0.1.1, HsOpenSSL-0.3.1, HsSyck-0.41, HsSyck-0.42, IFS-0.1.1, IOSpec-0.1.1, Imlib-0.1, IndentParser-0.2.1, ListLike-1.0.1, MaybeT-0.1.1, MissingH-1.0.0, NewBinary-0.1, OpenGL-2.2.1.1, PArrows-0.1, PostgreSQL-0.2, Postmaster-0.1, QuickCheck-2.0, RJson-0.1, Ranged-sets-0.1.1, Safe-0.1, Shellac-0.9.1, Shellac-readline-0.9, TV-0.2, TypeCompose-0.3, TypeCompose-0.4, {Unixutils-1.14}, X11-1.4.1, X11-1.4.1.20080127, X11-xft-0.2, YamlReference-0.6, ZFS-0.0, anydbm-1.0.4, anydbm-1.0.5, base64-string-0.1, bencode-0.3, binary-0.4.1, binary-strict-0.1, binary-strict-0.2.1, binary-strict-0.2.2, binary-strict-0.3.0, bio-0.2, bio-0.3.3, bktrees-0.2.1, blockio-0.0-2006-02-03, bytestring-0.9.0.1, bytestring-0.9.0.4, cgi-3001.1.5.1, cgi-3001.1.5.2, cgi-undecidable-3000.0.0, child-0.0-2005-02-14, chunks-2007.4.18, condorcet-0.0.1, csv-0.1.1, curl-1.3.2, dataenc-0.10.2, dbus-haskell-0.1, {debian-1.2}, denominate-0.4.1, derive-0.1, derive-0.1.1, dimensional-0.7.2, dlist-0.4, dsp-0.2.1, encoding-0.3, event-list-0.0.5, exif-3000.0.0, fec-0.1.1, filepath-1.1.0.0, fingertree-0.0, fixpoint-0.1, flock-0.1, folkung-2.3, frag-1.1, fst-0.9, ftphs-1.0.4, gal-1.0, gd-3000.4.0, genericserialize-0.1, greencard-3.0.1, greencard-lib-3.0.1, haddock-2.0.0.0, haddock-2.1.0, halfs-0.2, harp-0.2.1, harpy-0.4, haskell-src-exts-0.2.1, haskelldb-0.11, haxr-3000.0.1, hera-ajaxgui-2.1-dev, hera-engine-2.1-dev, hera-prelude-2.1-dev, hfov-1, hinotify-0.2, hinstaller-2007.5.13, hmarkup-3000.0.1, hmatrix-0.2.0.0, hopenssl-0.0-2005-02-14, hosc-0.1, hosc-0.2, hs-fltk-0.2.5, hsc3-0.2, hscurses-1.1, hscurses-1.2, hscurses-1.3, hsdns-1.1, hsemail-1.1, hslogger-1.0.2, hslua-0.2, hsntp-0.1, hsp-0.2, hspr-sh-0.3, hspread-0.2, hstats-0.2, hstringtemplate-0.1, html-1.0.1.1, hybrid-2.0, i18n-0.2, i18n-0.3, idris-0.0.1, infix-0.1, interlude-0.1, ipprint-0.3, irc-0.4, ivor-0.1.5, lax-0.0.0, lazysmallcheck-0.1, libGenI-0.16, libmpd-0.1.3, loch-0.2, magic-1.0.7, markov-chain-0.0.1, memcached-0.1, mersenne-random-0.1, metaplug-0.1.1, midi-0.0.4, miniplex-0.2.2, monad-param-0.0.2, monadLib-3.3.0, monadenv-0.0-2005-02-14, mtlparse-0.0.0.5, nano-md5-0.1.1, network-bytestring-0.1.1, network-bytestring-0.1.1.2, non-negative-0.0.1, numbers-2007.9.25, oeis-0.1, parse-dimacs-1.0, parsedate-3000.0.0, pcap-0.4.2, pcre-light-0.2.1, pcre-light-0.3, plugins-1.1, polyparse-1.1, popenhs-1.0.0, postmaster-0.1, powermate-0.1, pqc-0.2, propgrid-0.1, pugs-HsSyck-0.2, pugs-HsSyck-0.41, pugs-hsregex-1.0, pureMD5-0.1.0, pureMD5-0.1.1, rbr-0.7, rbr-0.8.3, reactive-0.4, regex-base-0.72.0.1, regex-base-0.93.1, regex-posix-0.72.0.2, regex-posix-0.93.1, rss-3000.0.1, safecopy-0.3, scgi-0.1, selenium-0.2.2, sessions-2008.2.20, shell-pipe-0.1, simpleargs-0.1, smallcheck-0.2, smallcheck-0.2.1, stream-fusion-0.1.1, strict-0.3, strict-concurrency-0.1, stringsearch-0.2, supercollider-ht-0.0, syb-with-class-0.4, tagsoup-0.3, tagsoup-0.4, tagsoup-0.5, tar-0.1.1.1, template-0.1.1.1, terminfo-0.1, type-int-0.3, type-level-0.1, uniplate-1.0.1, unix-compat-0.1.2.1, unix-pty-light-0.1, value-supply-0.1, vty-3.0.0, whim-0.1, wl-pprint-1.0, xhtml-3000.0.2.1, xhtml-3000.0.2.2, xmonad-0.6, xmonad-contrib-0.6, xsact-1.6, zlib-0.4.0.2 }}} -- gwern -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 20 11:10:26 2008 From: trac at galois.com (GHC) Date: Thu Mar 20 11:07:05 2008 Subject: [GHC] #2164: zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd In-Reply-To: <044.65631559df6ce2cd79a1eb038ea82f5f@localhost> References: <044.65631559df6ce2cd79a1eb038ea82f5f@localhost> Message-ID: <053.9560e3f0c5f8c4c4c93bee525a909567@localhost> #2164: zmachine: internal error: task 0xa031e0: main thread 1 has been GC'd ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 Comment: Thanks for the report. It would be really useful if someone could boil this down to as small an example as possible. Especially useful, if possible, would be removing the dependency on gtk2hs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 22 05:05:07 2008 From: trac at galois.com (GHC) Date: Sat Mar 22 05:01:41 2008 Subject: [GHC] #2168: ghci should show haddock comments for identifier Message-ID: <049.47be5fa91ec9885f4a8847376f7f589a@localhost> #2168: ghci should show haddock comments for identifier --------------------------------+------------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- This came up in comp.lang.haskell recently: http://groups.google.com/group/comp.lang.haskell/msg/ae69f720377e7a3f I like the idea. Immediate thoughts: * if ghci reads the source file, it can read haddock annotations * if ghci reads the interface file only (for library modules), it needs to find the installed documentation On the other hand the requested feature is a typical IDE functionality (cf. Eclipse/show source/show javadoc) and it's perhaps a bit much to require that from ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 22 12:50:04 2008 From: trac at galois.com (GHC) Date: Sat Mar 22 12:46:35 2008 Subject: [GHC] #2169: Compilation fails first time without giving an error, later succeeds without changing code Message-ID: <043.846fc3dda75c676953124f0b37d400e0@localhost> #2169: Compilation fails first time without giving an error, later succeeds without changing code -------------------------------+-------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- There is one particular module in our Haskell project that causes GHC to act oddly. We compile using GHC --make Main, and compilation on this particular module often fails on the first attempt. There are no errors given, just a lot of warnings of the form "Defined but not used: ..." (we are *not* using -Werror anywhere). All these warnings are about unused bindings (e.g. foo x y = x, gives unused warning about y) -- even though we don't use the -fwarn-unused-matches option anywhere, nor -Wall. If you then try to execute the same command several times, it usually succeeds on around the fourth attempt, without altering anything whatsoever. This bug is persistent -- it happens often, usually from a clean start (of compiling the whole project). The command used for GHC is: {{{ghc $(GHC_OPTS) -o tock$(EXEEXT) --make Main -odir obj -hidir obj}}} where: {{{ GHC_OPTS = \ -fglasgow-exts \ -fwarn-deprecations \ -fwarn-duplicate-exports \ -fwarn-incomplete-record-updates \ -fwarn-missing-fields \ -fwarn-missing-methods \ -fwarn-missing-signatures \ -fwarn-overlapping-patterns \ -fwarn-simple-patterns \ -fwarn-type-defaults \ -fwarn-unused-binds \ -fwarn-unused-imports \ -ibackends -ichecks -icommon -idata -iflow -ifrontends -ipass -itransformations \ -v -dcore-lint -XUndecidableInstances -fwarn-tabs -fwarn- monomorphism-restriction }}} (The -v and -dcore-lint flags were added to try and track down the bug). Output from the failed compilation is as follows: {{{ compile: input file flow/FlowGraph.hs *** Checking old interface for main:FlowGraph: [42 of 51] Compiling FlowGraph ( flow/FlowGraph.hs, obj/FlowGraph.o ) *** Parser: *** Renamer/typechecker: flow/FlowGraph.hs:274:10: Warning: Defined but not used: `m' flow/FlowGraph.hs:322:26: Warning: Defined but not used: `m' flow/FlowGraph.hs:334:40: Warning: Defined but not used: `m' flow/FlowGraph.hs:339:36: Warning: Defined but not used: `m' flow/FlowGraph.hs:339:38: Warning: Defined but not used: `rep' flow/FlowGraph.hs:357:31: Warning: Defined but not used: `outStartA' flow/FlowGraph.hs:375:27: Warning: Defined but not used: `m' flow/FlowGraph.hs:383:26: Warning: Defined but not used: `str' flow/FlowGraph.hs:383:31: Warning: Defined but not used: `route' flow/FlowGraph.hs:391:27: Warning: Defined but not used: `m' flow/FlowGraph.hs:398:26: Warning: Defined but not used: `m' flow/FlowGraph.hs:415:49: Warning: Defined but not used: `m' flow/FlowGraph.hs:419:19: Warning: Defined but not used: `pId' flow/FlowGraph.hs:419:24: Warning: Defined but not used: `nStart' flow/FlowGraph.hs:419:32: Warning: Defined but not used: `nEnd' flow/FlowGraph.hs:419:46: Warning: Defined but not used: `m' flow/FlowGraph.hs:430:19: Warning: Defined but not used: `pId' flow/FlowGraph.hs:430:24: Warning: Defined but not used: `nStart' flow/FlowGraph.hs:430:32: Warning: Defined but not used: `nEnd' flow/FlowGraph.hs:443:19: Warning: Defined but not used: `pId' flow/FlowGraph.hs:443:24: Warning: Defined but not used: `nStart' flow/FlowGraph.hs:443:32: Warning: Defined but not used: `nEnd' flow/FlowGraph.hs:509:46: Warning: Defined but not used: `m' flow/FlowGraph.hs:557:20: Warning: Defined but not used: `m' *** Deleting temp files: Deleting: /tmp/ghc2747_0/ghc2747_0.s Warning: deleting non-existent /tmp/ghc2747_0/ghc2747_0.s Upsweep partially successful. *** Deleting temp files: Deleting: link(batch): upsweep (partially) failed OR Main.main not exported; not linking. *** Deleting temp files: Deleting: /tmp/ghc2747_0/ghc2747_1.hscpp /tmp/ghc2747_0/ghc2747_0.hscpp *** Deleting temp dirs: Deleting: /tmp/ghc2747_0 make[1]: *** [tock] Error 1 make[1]: Leaving directory `/home/neil/work/tock/branches/ghc-bug' make: *** [all] Error 2 }}} When the compilation later succeeds the output is as follows: {{{ compile: input file flow/FlowGraph.hs *** Checking old interface for main:FlowGraph: [42 of 51] Compiling FlowGraph ( flow/FlowGraph.hs, obj/FlowGraph.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size = 11538 *** Core Linted result of Desugar: *** Simplify: Result size = 8648 *** Core Linted result of Simplifier phase 0, iteration 1 out of 4: Result size = 7809 *** Core Linted result of Simplifier phase 0, iteration 2 out of 4: Result size = 7797 *** Core Linted result of Simplifier phase 0, iteration 3 out of 4: Result size = 7797 *** Core Linted result of Simplify phase 0 done: *** Tidy Core: Result size = 7959 *** Core Linted result of Tidy Core: writeBinIface: 37 Names writeBinIface: 167 dict entries *** CorePrep: Result size = 9571 *** Core Linted result of CorePrep: *** Stg2Stg: *** CodeGen: *** CodeOutput: *** Assembler: gcc -march=athlon64 -Wa,--noexecstack -Iflow -c /tmp/ghc3185_0/ghc3185_0.s -o obj/FlowGraph.o *** Deleting temp files: Deleting: /tmp/ghc3185_0/ghc3185_0.s }}} The code in question is from http://offog.org/darcs/tock/ (version as of 22/3/08 4pm) -- I don't think it would easy to isolate the problem. The module in question (flow/FlowGraph.hs) can be found there. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 22 15:30:56 2008 From: trac at galois.com (GHC) Date: Sat Mar 22 15:27:27 2008 Subject: [GHC] #2169: Compilation fails first time without giving an error, later succeeds without changing code In-Reply-To: <043.846fc3dda75c676953124f0b37d400e0@localhost> References: <043.846fc3dda75c676953124f0b37d400e0@localhost> Message-ID: <052.948a86511b61d151aea47efa19b32779@localhost> #2169: Compilation fails first time without giving an error, later succeeds without changing code -------------------------------+-------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- Comment (by ajd): I `darcs get`'d the mentioned source tree and couldn't reproduce the bug (albeit on 32-bit Linux). I did get a type error on the "frontends/ParseOccam" module, though... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 22 16:20:45 2008 From: trac at galois.com (GHC) Date: Sat Mar 22 16:17:19 2008 Subject: [GHC] #2169: Compilation fails first time without giving an error, later succeeds without changing code In-Reply-To: <043.846fc3dda75c676953124f0b37d400e0@localhost> References: <043.846fc3dda75c676953124f0b37d400e0@localhost> Message-ID: <052.8f4384a3879bf210a686ec992b7d3f40@localhost> #2169: Compilation fails first time without giving an error, later succeeds without changing code ----------------------+----------------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: Thanks for the report! You are actually using `-Werror` in the generated `data/OrdAST.hs`. This shouldn't cause compilation of FlowGraph to fail, but I suspect it is the culprit nevertheless. You should be able to confirm that by removing the -Werror and seeing if it fixes it. Can you please make a tarball of just Haskell source files, so that we only need to run a `ghc --make ...` command to reproduce the problem? It would also make our lives a lot easier if you could remove dependencies on non-boot-libraries, and make the example as small as possible. The easiest way to do both of these is to replace function definitions with `undefined` and then remove unused functions, checking that the problem hasn't fixed itself as you go. Thanks Ian -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 22 17:46:01 2008 From: trac at galois.com (GHC) Date: Sat Mar 22 17:42:32 2008 Subject: [GHC] #2169: Compilation fails first time without giving an error, later succeeds without changing code In-Reply-To: <043.846fc3dda75c676953124f0b37d400e0@localhost> References: <043.846fc3dda75c676953124f0b37d400e0@localhost> Message-ID: <052.9227f5050dec7a461865c836be7c1b77@localhost> #2169: Compilation fails first time without giving an error, later succeeds without changing code ----------------------+----------------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by nccb): Sorry about that - I had forgotten about the auto-generated modules having custom errors. I think you have spotted it; FlowGraph is compiled directly after OrdAST, and it seems that sometimes the per-module settings from OrdAST have "bled through" into FlowGraph (we are using -fwarn- unused-matches in OrdAST, sorry for not noticing that in the original report). What seems especially odd is that FlowGraph can fail a second time, when OrdAST has already been compiled (some problem with temporary files?). I'll try and trim it down into a neater testcase. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 22 18:17:32 2008 From: trac at galois.com (GHC) Date: Sat Mar 22 18:14:07 2008 Subject: [GHC] #2170: make install fails for x86 ubuntu linux Message-ID: <049.0d556eeabc4a78a94c949fcc072ba5e9@localhost> #2170: make install fails for x86 ubuntu linux ---------------------------+------------------------------------------------ Reporter: skurtzberg | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: minor Keywords: | Testcase: Architecture: x86 | Os: Linux ---------------------------+------------------------------------------------ Using the binary x86 distribution, make install fails. Recently (or at least fairly recently) ubuntu changed the symlink /bin/sh to point to /bin/dash. This greatly speeds up many things, but breaks other things. To work around, delete the link, create a link pointing to a more compliant shell (I tested with zsh, presumably bash works as well), do make install, then revert the link. This can be considered a documentation issue rather than a bug, but perhaps there's a minor script change that will work with dash as well as other common shells. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 22 19:58:25 2008 From: trac at galois.com (GHC) Date: Sat Mar 22 19:54:57 2008 Subject: [GHC] #2169: Compilation fails first time without giving an error, later succeeds without changing code In-Reply-To: <043.846fc3dda75c676953124f0b37d400e0@localhost> References: <043.846fc3dda75c676953124f0b37d400e0@localhost> Message-ID: <052.534a305023374ccda4d0e98b019a41fe@localhost> #2169: Compilation fails first time without giving an error, later succeeds without changing code ----------------------+----------------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by nccb): I'm having real trouble slimming down the testcase. If I remove modules from the build process, the error goes away. If I remove some functions, it also disappears. Here is what I am fairly certain of: * Options in an OPTIONS_GHC pragma in data/OrdAST.hs are being applied to flow/FlowGraph.hs, as long as it is the next module in the build process for --make. * The error occurs even though flow/FlowGraph.hs doesn't even import data/OrdAST.hs * The error always occurs if you add a function (and thus change the automatically-determined export list) in a module they both depend on, such as common/Utils.hs and recompile * The error can occur even when data/OrdAST.hs is not recompiled (presumably it is still scanned for the module dependencies) * The error seems to disappear when data/OrdAST.hs exports a function; the error only occurs when data/OrdAST.hs exports nothing at all, or exports only type-class instances (for types not in its view). * Removing module imports from Main that are normally compiled before data/OrdAST.hs and flow/FlowGraph.hs, and that are directly impored by neither, can make the error go away. * The error seems to only occur if both modules import *qualified* AST, but as different things (e.g. import qualified AST, versus import qualified AST as A). I think every other module in the code imports AST as A, so that may be a bit of a confounding factor too. * If I move all the modules from their subdirectories into the main directory, the problem disappears I had suspected the problem was to do with the orphan instance declarations in data/OrdAST.hs but the error seems to occur even with the instance declarations removed. My best guess now is that the problem is somehow to do with the qualified imports, not exporting anything, the OPTIONS_GHC pragma and seems to be very specific to the build order. I've attached the tarball. Extract the files and run "sh compile.sh". If that doesn't produce the error immediately, let the compilation finish and then in common/Utils.hs, uncomment/comment (it's the toggling that does it) the two "foo" lines near the top of the file. Then re-run compile.sh. On my machine this will then produce the problem every time. If you re-run compile.sh until compilation succeeds, you can then toggle the lines in common/Utils.hs again to produce the problem again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 22 20:48:04 2008 From: trac at galois.com (GHC) Date: Sat Mar 22 20:44:35 2008 Subject: [GHC] #2169: Compilation fails first time without giving an error, later succeeds without changing code In-Reply-To: <043.846fc3dda75c676953124f0b37d400e0@localhost> References: <043.846fc3dda75c676953124f0b37d400e0@localhost> Message-ID: <052.f502a00b1c992fff125a79ea89e344e3@localhost> #2169: Compilation fails first time without giving an error, later succeeds without changing code ----------------------+----------------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by igloo): Thanks for the tarball, and your investigations! Unfortunately, using a Debian-compiled ghc: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 }}} the first time, and after the first and second toggles, I just get this: {{{ [41 of 51] Compiling OrdAST ( data/OrdAST.hs, obj/OrdAST.o ) [42 of 51] Compiling FlowGraph ( flow/FlowGraph.hs, obj/FlowGraph.o ) [43 of 51] Compiling UsageCheckUtils ( checks/UsageCheckUtils.hs, obj/UsageCheckUtils.o ) }}} This is a really irritating bug. I've seen it before, but never been able to get a reproducible testcase. If you unpack the tarball in a different directory, with different length, can you still reproduce it? Do you remember where your GHC binary came from? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 23 07:41:33 2008 From: trac at galois.com (GHC) Date: Sun Mar 23 07:38:09 2008 Subject: [GHC] #2169: Compilation fails first time without giving an error, later succeeds without changing code In-Reply-To: <043.846fc3dda75c676953124f0b37d400e0@localhost> References: <043.846fc3dda75c676953124f0b37d400e0@localhost> Message-ID: <052.4a08b0457c5ccc7e49bc783ff30c1da5@localhost> #2169: Compilation fails first time without giving an error, later succeeds without changing code ----------------------+----------------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by nccb): If I extract the tarball to a fresh new directory, I get the bug first- time. I'm not quite sure what you mean by "different length". My GHC is installed via Gentoo's package manager. I seem to remember it works by downloading a binary bootstrap of the latest GHC, then compiling the latest GHC with it for my machine in specific. It should therefore be a native x86_64 build. I don't have any particularly crazy flags set for it (not sure if the CFLAGS would be relevant anyway, but they are -O2 -march=athlon64). {{{ $ ghc -v Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 2 booted by GHC version 6.8.2 Using package config file: /usr/lib64/ghc-6.8.2/package.conf wired-in package base mapped to base-3.0.1.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0.1.0 wired-in package template-haskell mapped to template-haskell-2.2.0.0 wired-in package ndp not found. Hsc static flags: -static }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 23 08:47:51 2008 From: trac at galois.com (GHC) Date: Sun Mar 23 08:44:21 2008 Subject: [GHC] #2171: Parallel program crashes Message-ID: <042.91539dd5667f046cb861faa36a106615@localhost> #2171: Parallel program crashes ------------------------------------------------+--------------------------- Reporter: fed | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: critical Keywords: parallel, crash, race condition | Testcase: Architecture: x86 | Os: Windows ------------------------------------------------+--------------------------- I wrote a parallel program for computing prime numbers (see code below). Compiled it using ghc -threaded --make primes.hs Then run primes 200000 200010 +RTS -N2 -sstderr In 80% of runs the program crashes with segmentation fault message. My operating system is Windows XP SP2. One time I saw a typical Windows red cross dialog box with access violation report as a result of the run. But few times the program finished with correct result. {{{ module Main where import System.Environment import Control.Parallel.Strategies import Data.Maybe chunkSize = 1000 threads = 2 maybePrimes :: [Maybe Integer] maybePrimes = Just 2 : Just 3 : Just 5 : [ if isPrime x then (Just x) else Nothing | x <- candidates 7 11 ] where candidates a1 a2 = a1 : a2 : candidates (a1+6) (a2+6) isPrime x = all ((0 /=) . (x `mod`)) $ takeWhile ((x>=).(^2)) primes splitOnSubLists :: Int -> [a] -> [[a]] splitOnSubLists n xs = let (begin, end) = splitAt n xs in begin : splitOnSubLists n end maybePrimes2 :: [Maybe Integer] maybePrimes2 = concat $ parBuffer (threads-1) rnf $ splitOnSubLists chunkSize maybePrimes primes :: [Integer] primes = catMaybes maybePrimes2 main = do args <- getArgs (first, last) <- case args of [] -> return (10, 19) (x:[]) -> return (f, f+9) where f = read x (x:y:_) -> return (read x, read y) let p = drop (first-1) $ take last $ zip [1..] primes in mapM (\(x,y) -> putStrLn (show x ++ " -> " ++ show y)) p }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 23 10:51:06 2008 From: trac at galois.com (GHC) Date: Sun Mar 23 10:47:35 2008 Subject: [GHC] #1291: Binary Solaris build fails on Solaris 9 In-Reply-To: <044.da39aece29339a0f32ded51c36797f3d@localhost> References: <044.da39aece29339a0f32ded51c36797f3d@localhost> Message-ID: <053.adfd34f4fd50eceaa61d8feceffccae1@localhost> #1291: Binary Solaris build fails on Solaris 9 --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Build System | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Comment (by guest): The fundamental problem is that the GHC binary package was built on a Solaris 9 release with the C99 patches installed. These patches are not publicly available, and many Solaris 9 systems don't have them. There is no clean fix for this. A very ugly solution is: - cd /usr/lib; ln -s libm.so.1 libm.so.2 - LD_NOVERSION=1 export LD_NOVERSION - create a file with stubs for the C99 (float) functions (e.g. sinf()) which invoke the (double) versions, and "ar r" this to libHSbase.a; otherwise programs compiled with the binary GHC will fail to link - alter the GHC build sequence to add this object to the *new* libHSbase.a, because GHC assumes the existence of the C99 functions instead of testing and substituting the (double) versions -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 23 11:05:06 2008 From: trac at galois.com (GHC) Date: Sun Mar 23 11:01:35 2008 Subject: [GHC] #2172: ghci / ghc -e outputs terminal escapes even when redirected to file/pipe Message-ID: <044.f93433813c2b45db5849d9e5c67f6742@localhost> #2172: ghci / ghc -e outputs terminal escapes even when redirected to file/pipe ----------------------------------------------------------+----------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: terminal escape sequences non-interactive | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------------------------+----------------- When running the interpreter (ghc --interactive, ghc -e, or runhaskell) with stdout redirected to a file, pipe, or other non-tty, ghc sends some terminal initialization sequences. This can be reproduced in a KDE konsole window: ``ghc -e 'putStrLn "hi" >file'' will write an extraneous [?1034h to the file. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 23 12:02:44 2008 From: trac at galois.com (GHC) Date: Sun Mar 23 11:59:13 2008 Subject: [GHC] #1291: Binary Solaris build fails on Solaris 9 In-Reply-To: <044.da39aece29339a0f32ded51c36797f3d@localhost> References: <044.da39aece29339a0f32ded51c36797f3d@localhost> Message-ID: <053.afa8902acdaeae6435bda66338701296@localhost> #1291: Binary Solaris build fails on Solaris 9 --------------------------+------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: _|_ Component: Build System | Version: 6.6.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: Here's the end of the previous message with trac formatting: * {{{cd /usr/lib; ln -s libm.so.1 libm.so.2}}} * {{{LD_NOVERSION=1 export LD_NOVERSION}}} * create a file with stubs for the C99 (float) functions (e.g. `sinf()`) which invoke the (double) versions, and "ar r" this to libHSbase.a; otherwise programs compiled with the binary GHC will fail to link * alter the GHC build sequence to add this object to the *new* libHSbase.a, because GHC assumes the existence of the C99 functions instead of testing and substituting the (double) versions I'm closing this ticket, as it doesn't look like there's a GHC bug here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 23 12:44:23 2008 From: trac at galois.com (GHC) Date: Sun Mar 23 12:40:55 2008 Subject: [GHC] #2172: ghci / ghc -e outputs terminal escapes even when redirected to file/pipe In-Reply-To: <044.f93433813c2b45db5849d9e5c67f6742@localhost> References: <044.f93433813c2b45db5849d9e5c67f6742@localhost> Message-ID: <053.26505934f4047eecbc50e05c17447b25@localhost> #2172: ghci / ghc -e outputs terminal escapes even when redirected to file/pipe ----------------------------------------------------------+----------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: terminal escape sequences non-interactive | Testcase: Architecture: Unknown | Os: Unknown ----------------------------------------------------------+----------------- Changes (by judah): * status: new => closed * resolution: => duplicate Comment: This has been fixed for 6.8.3 as #2027. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 23 16:52:14 2008 From: trac at galois.com (GHC) Date: Sun Mar 23 16:48:43 2008 Subject: [GHC] #2173: Typo in Network.accept docs Message-ID: <044.01d03293e6a8502088aeff2340bbe079@localhost> #2173: Typo in Network.accept docs ------------------------+--------------------------------------------------- Reporter: larsv | Owner: Type: bug | Status: new Priority: normal | Component: libraries/network Version: 6.8.2 | Severity: trivial Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- In the [http://hackage.haskell.org/packages/archive/network/2.1.0.0/doc/html/Network.html#v%3Aaccept Network docs] on Hackage, "operations" is misspelled as "opertaions". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 23 17:46:06 2008 From: trac at galois.com (GHC) Date: Sun Mar 23 17:42:35 2008 Subject: [GHC] #2174: :p in GHCi debugger is broken for Integer Message-ID: <044.1d80568861fbb1d73964b812140274cd@localhost> #2174: :p in GHCi debugger is broken for Integer -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- `:p` used to do this for Integers: {{{ Prelude> let i = Just (10::Integer) Prelude> :p i i = Just 10 }}} but it now does this: {{{ Prelude> let i = Just (10::Integer) Prelude> :p i i = Just (_t1::Integer) }}} but I can't see an obvious reason why. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 23 17:55:59 2008 From: trac at galois.com (GHC) Date: Sun Mar 23 17:52:27 2008 Subject: [GHC] #2175: stableptr003 fails Message-ID: <044.d06ef41a33cee91ab166dec272f5c106@localhost> #2175: stableptr003 fails -------------------------+-------------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- The first element (at least) of the lists in the `stableptr003` test now differ: {{{ +[(1,10001),(2,2),(3,3),(4,6),(5,5),... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 23 19:10:03 2008 From: trac at galois.com (GHC) Date: Sun Mar 23 19:06:33 2008 Subject: [GHC] #601: Replace GMP In-Reply-To: <047.118762464fe3464def09b9461b8cccc5@localhost> References: <047.118762464fe3464def09b9461b8cccc5@localhost> Message-ID: <056.500965d168534260b1abbab0e53175a6@localhost> #601: Replace GMP ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: None Severity: normal | Resolution: None Keywords: | Difficulty: Difficult (1 week) Testcase: N/A | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): In the HEAD, `integer` is now a separate package, by default provided by `libraries/integer-gmp`. If you make a variant in `libraries/integer-foo` and change `libraries/Makefile` to refer to `integer-foo` instead of `integer-gmp` then it will use your variant instead. You need to export the same functions with the same types. The current package is just the old GMP implementation, and still uses primitives from the RTS. If anyone is interested in workong on this, it would be very interesting to: * Write an Integer performance suite * Compare the current implementation to a direct GMP binding, i.e. not using RTS primitives * Compare the GMP implementation to a pure Haskell binding, e.g. http://www.haskell.org/pipermail/libraries/2007-August/007909.html * Compare the GMP implementation to a binding to a BSD-licenced C library -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 24 11:31:02 2008 From: trac at galois.com (GHC) Date: Mon Mar 24 11:27:28 2008 Subject: [GHC] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 In-Reply-To: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> References: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> Message-ID: <058.206010e56c278caab8181ca47dc74796@localhost> #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 ----------------------------+----------------------------------------------- Reporter: twhitehead | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Comment (by twhitehead): One last simplification. The program now just endlessly generates the integer list [1..M], where M is a command-line argument, from back to front as a sequence of (:) thunks. Compiling as above ("ghc --make -O2 -debug Bug") and running with "./Bug 134217728" (i.e., M=134217728) produces the following after about two days (the third time generating the sequence): {{{ Starting block 0 Starting block 1 Starting block 2 Bug: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 (GHC version 6.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I'll attach the simplified code. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 24 13:01:15 2008 From: trac at galois.com (GHC) Date: Mon Mar 24 12:57:47 2008 Subject: [GHC] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 In-Reply-To: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> References: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> Message-ID: <058.3f463c9fac993d0e26369e721b79f8e2@localhost> #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 ----------------------------+----------------------------------------------- Reporter: twhitehead | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Comment (by simonmar): Before investigating this, can you tell me which version of the program fails in the shortest amount of time? Or if you know of any RTS flag settings that make it fail sooner? It's more important to reproduce the error quickly rather than to have the simplest program. In fact for RTS bugs the program itself is sometimes not relevant at all, although having as few dependencies as possible is always good, and all other things being equal a smaller program is always better. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 24 16:54:43 2008 From: trac at galois.com (GHC) Date: Mon Mar 24 16:51:08 2008 Subject: [GHC] #2169: Compilation fails first time without giving an error, later succeeds without changing code In-Reply-To: <043.846fc3dda75c676953124f0b37d400e0@localhost> References: <043.846fc3dda75c676953124f0b37d400e0@localhost> Message-ID: <052.5a498eca3c1393999134b9783e1946f7@localhost> #2169: Compilation fails first time without giving an error, later succeeds without changing code ----------------------+----------------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by simonmar): I can't reproduce it either (on x86). I looked at the code in GHC and can't see any obvious bugs in this area. The way that the bug seems to be hard to reproduce indicates that it is based on something fragile - perhaps some runtime mutation with unsafePerformIO, or some strange RTS bug. But it looks like it might only be reproducible on x86_64 - Ian, do you have a 64-bit box to test it on? I don't have easy access to one right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 24 17:37:04 2008 From: trac at galois.com (GHC) Date: Mon Mar 24 17:33:31 2008 Subject: [GHC] #2169: Compilation fails first time without giving an error, later succeeds without changing code In-Reply-To: <043.846fc3dda75c676953124f0b37d400e0@localhost> References: <043.846fc3dda75c676953124f0b37d400e0@localhost> Message-ID: <052.6cbc9359e02575f435cf2660470b1ae1@localhost> #2169: Compilation fails first time without giving an error, later succeeds without changing code ----------------------+----------------------------------------------------- Reporter: nccb | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Comment (by igloo): My tests higher up were on amd64/Linux (Debian). Unfortunately, Duncan's amd64/Linux (Gentoo) box is broken at the moment, so he can't try it there. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 24 22:32:59 2008 From: trac at galois.com (GHC) Date: Mon Mar 24 22:29:34 2008 Subject: [GHC] #1148: Bad warnings about unused imports that are in fact needed In-Reply-To: <045.bee1b922a3147d2353135cd2446dcba2@localhost> References: <045.bee1b922a3147d2353135cd2446dcba2@localhost> Message-ID: <054.d9642b92b7533564215aead17b463c13@localhost> #1148: Bad warnings about unused imports that are in fact needed -----------------------------------+---------------------------------------- Reporter: brianh | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: Keywords: warning unused import | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -----------------------------------+---------------------------------------- Changes (by Eelis-): * version: 6.6 => 6.8.2 Comment: I ran into this bug, and isolated it to this: {{{ import List import Prelude main = return () where b = List.null "" }}} GHC warns that nothing from List is used, but the code fails to compile without the import. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 25 02:25:51 2008 From: trac at galois.com (GHC) Date: Tue Mar 25 02:22:28 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.1499133d109d0c004de6ab3bc2b88862@localhost> #2157: Equality Constraints with Type Families ----------------------------------------+----------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------------+----------------------------------- Comment (by chak): Replying to [comment:9 claus]: > Replying to [comment:7 chak]: > > {{{ > > {-# LANGUAGE TypeFamilies #-} > > > > type family Const a :: * -> * > > type instance Const a = C a > > type C a t = a > > }}} > > > > Why do you think `Const` is fishy? > > because: > > - type synonym `C` appears partially applied in what amounts to a type class instance parameter position (the rhs of the Const instance) I don't agree that the lhs of a type instance amounts to a type class instance parameter position; type instance have nothing to do with type classes. However, I think I now understand what you are worried about. It is the interaction of type families and GHC's generalised type synonyms (i.e., type synonyms that may be partially applied). I agree that it does lead to an odd interaction, because the outcome may depend on the order in which the type checker performs various operations. In particular, whether it first applies a type instance declaration to reduce a type family application or whether it first performs decomposition. The most clean solution may indeed be to outlaw partial applications of vanilla type synonyms in the rhes of type instances. (Which is what I will implement unless anybody has a better idea.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 25 10:30:20 2008 From: trac at galois.com (GHC) Date: Tue Mar 25 10:26:45 2008 Subject: [GHC] #2176: H98 module Array exports non-H98 instance Functor ((->) a) Message-ID: <045.a9dd1faca636f175591a794f8e7a99a8@localhost> #2176: H98 module Array exports non-H98 instance Functor ((->) a) ------------------------+--------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: libraries/haskell98 Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Here's a subtle problem for which we have global class instances to thank. Take a look at how many modules in base and the other core libraries re- export the class instances defined in Control.Monad.Instances. A lot do. Indeed the Data.Array and thus the H98 Array module does. That's very bad. It makes it easy to accidentally write non-portable non-H98 code. This bit us in Cabal. We try to keep Cabal working with ghc, nhc98, hugs etc. Malcolm discovered that we were relying on the instance Functor ((->) a) but were not importing it for nhc98 at least. Nothing in Cabal imports Control.Monad.Instances so I was wondering how we were coming to end up with it. Turns out we're getting it at least via Data.Array. Tracking down the source of instances is quite tricky. I wonder if there is anything we can do to make it easier? I was using ghc --show-iface on all the imports to try and find it. In this case it was easier because all I had to look for was Control.Monad.Instances as an orphan module. We should audit which modules are importing Control.Monad.Instances and see if they're essential or just convenience. The point of Control.Monad.Instances being in a separate module was that it'd not be in scope by default. That's defeated if other standard modules use it. For example does Control.Applicative really need it? In fact Control.Applicative is probably the root offender here, it's the one that causes Data.Array to re-export the unwanted instances. Do we need a Control.Applicative.Instances perhaps for the Applicative ((->) a) instance? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 25 11:20:53 2008 From: trac at galois.com (GHC) Date: Tue Mar 25 11:17:16 2008 Subject: [GHC] #2176: H98 module Array exports non-H98 instance Functor ((->) a) In-Reply-To: <045.a9dd1faca636f175591a794f8e7a99a8@localhost> References: <045.a9dd1faca636f175591a794f8e7a99a8@localhost> Message-ID: <054.063747b2071c67b1f6a75ebd736ebd08@localhost> #2176: H98 module Array exports non-H98 instance Functor ((->) a) ------------------------------------+--------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell98 | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------------------+--------------------------------------- Comment (by ross): Here's a test for this bug: {{{ module ShouldCompile where -- import all Haskell 98 modules import Array import Char import Complex import CPUTime import Directory import IO import Ix import List import Locale import Maybe import Monad import Numeric import Random import Ratio import System import Time -- This will fail if any of the Haskell 98 modules indirectly import -- Control.Monad.Instances instance Functor ((->) r) where fmap = (.) }}} This can be used to show that Array is the only H98 module where this bites. The problem is that it defines Foldable and Traversable instances for the Array type, and thus needs those modules and Control.Applicative, which they import. (Another vector is Control.Monad.Fix, imported by Control.Arrow, but that doesn't seem to lead to H98 modules.) I believe that these instances are a Good Thing, and we want them everywhere, except in H98 modules. I think the fix is to have an extra version of Data.Array, without the Foldable and Traversable instances (which are orphans anyway), and have Array import that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 25 11:26:41 2008 From: trac at galois.com (GHC) Date: Tue Mar 25 11:23:04 2008 Subject: [GHC] #2176: H98 module Array exports non-H98 instance Functor ((->) a) In-Reply-To: <045.a9dd1faca636f175591a794f8e7a99a8@localhost> References: <045.a9dd1faca636f175591a794f8e7a99a8@localhost> Message-ID: <054.2c79af09967e1e52b10b18523935bd7d@localhost> #2176: H98 module Array exports non-H98 instance Functor ((->) a) ------------------------------------+--------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell98 | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------------------+--------------------------------------- Comment (by ross): To clarify, it's the Functor and Monad instances in Control.Monad.Instances that are the Good Thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 25 11:51:51 2008 From: trac at galois.com (GHC) Date: Tue Mar 25 11:48:14 2008 Subject: [GHC] #2176: H98 module Array exports non-H98 instance Functor ((->) a) In-Reply-To: <045.a9dd1faca636f175591a794f8e7a99a8@localhost> References: <045.a9dd1faca636f175591a794f8e7a99a8@localhost> Message-ID: <054.4c217603730df4e7a56b9b4e4a249250@localhost> #2176: H98 module Array exports non-H98 instance Functor ((->) a) ------------------------------------+--------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell98 | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------------------+--------------------------------------- Comment (by claus): Replying to [ticket:2176 duncan]: > Tracking down the source of instances is quite tricky. I wonder if there is anything we can do to make it easier? I was using ghc --show-iface on all the imports to try and find it. use ghci and :info? {{{ GHCi, version 6.9.20080217: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :i Functor class Functor f where fmap :: (a -> b) -> f a -> f b -- Defined in GHC.Base instance Functor Maybe -- Defined in Data.Maybe instance Functor [] -- Defined in GHC.Base instance Functor IO -- Defined in GHC.IOBase Prelude> :m +Data.Array Prelude Data.Array> :i Functor class Functor f where fmap :: (a -> b) -> f a -> f b -- Defined in GHC.Base instance (Ix i) => Functor (Array i) -- Defined in GHC.Arr instance Functor ((->) r) -- Defined in Control.Monad.Instances instance Functor ((,) a) -- Defined in Control.Monad.Instances instance Functor (Either a) -- Defined in Control.Monad.Instances instance Functor Maybe -- Defined in Data.Maybe instance Functor [] -- Defined in GHC.Base instance Functor IO -- Defined in GHC.IOBase Prelude Data.Array> }}} one problem with this is that instances aren't managed properly in ghci sessions: {{{ Prelude Data.Array> :m -Data.Array Prelude> :i Functor class Functor f where fmap :: (a -> b) -> f a -> f b -- Defined in GHC.Base instance Functor ((->) r) -- Defined in Control.Monad.Instances instance Functor ((,) a) -- Defined in Control.Monad.Instances instance Functor (Either a) -- Defined in Control.Monad.Instances instance Functor Maybe -- Defined in Data.Maybe instance Functor [] -- Defined in GHC.Base instance Functor IO -- Defined in GHC.IOBase Prelude> }}} i thought the latter was a known bug, but i can't seem to find the ticket.. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 25 13:55:28 2008 From: trac at galois.com (GHC) Date: Tue Mar 25 13:51:53 2008 Subject: [GHC] #2176: H98 module Array exports non-H98 instance Functor ((->) a) In-Reply-To: <045.a9dd1faca636f175591a794f8e7a99a8@localhost> References: <045.a9dd1faca636f175591a794f8e7a99a8@localhost> Message-ID: <054.7b22ecbef767e81522db27d29a82b18c@localhost> #2176: H98 module Array exports non-H98 instance Functor ((->) a) ------------------------------------+--------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/haskell98 | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------------------+--------------------------------------- Comment (by ross): No good: Data.Foldable and Data.Traversable also import Control.Applicative. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 25 14:17:27 2008 From: trac at galois.com (GHC) Date: Tue Mar 25 14:13:50 2008 Subject: [GHC] #2174: :p in GHCi debugger is broken for Integer In-Reply-To: <044.1d80568861fbb1d73964b812140274cd@localhost> References: <044.1d80568861fbb1d73964b812140274cd@localhost> Message-ID: <053.bc6dc609a9ce46068ca146ec7bfc884b@localhost> #2174: :p in GHCi debugger is broken for Integer ---------------------+------------------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Comment (by mnislaih): Imho there is nothing fundamentally broken with :p in this example. It just shows that GHC has become a little lazier w.r.t. Integers. I have tried but can't find the exact patch producing this change, but it seems to be due to the move of Integer into its own package. By its nature, imho it is not reasonable to expect that the output of :print will remain the same across GHC versions, as the evaluation strategy in Haskell is not defined and GHC may change it over different versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 25 14:17:42 2008 From: trac at galois.com (GHC) Date: Tue Mar 25 14:14:05 2008 Subject: [GHC] #2174: :p in GHCi debugger is broken for Integer In-Reply-To: <044.1d80568861fbb1d73964b812140274cd@localhost> References: <044.1d80568861fbb1d73964b812140274cd@localhost> Message-ID: <053.5b54ab20aed97dd692f00bf7f9fc35e3@localhost> #2174: :p in GHCi debugger is broken for Integer ---------------------+------------------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by mnislaih): * cc: mnislaih@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 25 16:11:47 2008 From: trac at galois.com (GHC) Date: Tue Mar 25 16:08:09 2008 Subject: [GHC] #2173: Typo in Network.accept docs In-Reply-To: <044.01d03293e6a8502088aeff2340bbe079@localhost> References: <044.01d03293e6a8502088aeff2340bbe079@localhost> Message-ID: <053.6ad9bd1bfc957a511805ad9ad3682274@localhost> #2173: Typo in Network.accept docs -------------------------------+-------------------------------------------- Reporter: larsv | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/network | Version: 6.8.2 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Fixed, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Mar 25 21:05:48 2008 From: trac at galois.com (GHC) Date: Tue Mar 25 21:02:21 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.ca9dcd7a5d737dc5aaeb90cadd7b2c66@localhost> #2157: Equality Constraints with Type Families ----------------------------------------+----------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------------+----------------------------------- Comment (by chak): See also the clarification in [http://www.haskell.org/pipermail/haskell- cafe/2008-March/040983.html] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 26 05:24:42 2008 From: trac at galois.com (GHC) Date: Wed Mar 26 05:21:08 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.543c8a51fb28d146fcf98ec10ccf8661@localhost> #2157: Equality Constraints with Type Families ----------------------------------------+----------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------------+----------------------------------- Comment (by chak): Also [http://www.haskell.org/pipermail/haskell- cafe/2008-March/040989.html] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 26 10:16:42 2008 From: trac at galois.com (GHC) Date: Wed Mar 26 10:13:02 2008 Subject: [GHC] #2174: :p in GHCi debugger is broken for Integer In-Reply-To: <044.1d80568861fbb1d73964b812140274cd@localhost> References: <044.1d80568861fbb1d73964b812140274cd@localhost> Message-ID: <053.6fd709f8c3b346d72ad00aa6a4b66eeb@localhost> #2174: :p in GHCi debugger is broken for Integer ---------------------+------------------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: OK, I now understand what's going on. We used to make `S# 10#`, which is fully evaluated so got printed. We now make `smallInteger 10#` which is not fully evaluated. So the new behaviour seems fine to me. I've updated the test accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 26 12:17:46 2008 From: trac at galois.com (GHC) Date: Wed Mar 26 12:14:08 2008 Subject: [GHC] #2174: :p in GHCi debugger is broken for Integer In-Reply-To: <044.1d80568861fbb1d73964b812140274cd@localhost> References: <044.1d80568861fbb1d73964b812140274cd@localhost> Message-ID: <053.06eb8b536fb09e5995bbc628525f2a2a@localhost> #2174: :p in GHCi debugger is broken for Integer ---------------------+------------------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Comment (by simonmar): Are we sure that nothing has regressed w.r.t. efficiency here? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 26 12:36:07 2008 From: trac at galois.com (GHC) Date: Wed Mar 26 12:32:26 2008 Subject: [GHC] #2174: :p in GHCi debugger is broken for Integer In-Reply-To: <044.1d80568861fbb1d73964b812140274cd@localhost> References: <044.1d80568861fbb1d73964b812140274cd@localhost> Message-ID: <053.8f16a9f5ecb0c7fa6813149285943c68@localhost> #2174: :p in GHCi debugger is broken for Integer ---------------------+------------------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Comment (by igloo): The definition is just {{{ {-# INLINE smallInteger #-} smallInteger :: Int# -> Integer smallInteger i = S# i }}} so there should be no difference when compiling. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 26 17:15:46 2008 From: trac at galois.com (GHC) Date: Wed Mar 26 17:12:15 2008 Subject: [GHC] #1699: Fix network wrt abstract unix sockets In-Reply-To: <064.885c49d5fecaaffdac334b45404fbbd4@localhost> References: <064.885c49d5fecaaffdac334b45404fbbd4@localhost> Message-ID: <073.8f94e39801732911128b8599a78839f1@localhost> #1699: Fix network wrt abstract unix sockets ---------------------------------------+------------------------------------ Reporter: kolmodin@dtek.chalmers.se | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.6.1 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ---------------------------------------+------------------------------------ Comment (by kolmodin): See attachment:aus_simple.dpatch for a patch without cleanups that adds support for AUS. You can poke a socket address with {{{pokeSockAddr}}}, but not get the same back with {{{peekSockAddr}}}. I don't know if we really need that property, or what would be recommended. From testing I think python handles it the same way, you get an empty address path. Can't recall if the first patch handles it differently. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 26 19:01:41 2008 From: trac at galois.com (GHC) Date: Wed Mar 26 18:58:00 2008 Subject: [GHC] #2177: Can Data.Unique safely derive Typeable? Message-ID: <045.8724b926d6549afcfc85d1a3ada0af59@localhost> #2177: Can Data.Unique safely derive Typeable? --------------------------------+------------------------------------------- Reporter: japple | Owner: Type: feature request | Status: new Priority: normal | Component: libraries/directory Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown --------------------------------+------------------------------------------- Stand-alone deriving does not work: {{{ The data constructors of `Unique' are not all in scope so you cannot derive an instance for it In the stand-alone deriving instance for `Typeable Unique' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Mar 26 19:31:38 2008 From: trac at galois.com (GHC) Date: Wed Mar 26 19:27:57 2008 Subject: [GHC] #2178: GHC.Prim.Any replaces forall-bound type variables in GHCi Message-ID: <045.687d545a12776fce1441e39194f45642@localhost> #2178: GHC.Prim.Any replaces forall-bound type variables in GHCi -----------------------+---------------------------------------------------- Reporter: japple | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Load {{{ see :: IO (a -> b) see = return $ undefined }}} in GHCi {{{ *Main> g <- see *Main> :t g g :: GHC.Prim.Any -> GHC.Prim.Any }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 27 05:10:33 2008 From: trac at galois.com (GHC) Date: Thu Mar 27 05:06:49 2008 Subject: [GHC] #2178: GHC.Prim.Any replaces forall-bound type variables in GHCi In-Reply-To: <045.687d545a12776fce1441e39194f45642@localhost> References: <045.687d545a12776fce1441e39194f45642@localhost> Message-ID: <054.d6552d1ec34691df6196c1e3261b4673@localhost> #2178: GHC.Prim.Any replaces forall-bound type variables in GHCi --------------------+------------------------------------------------------- Reporter: japple | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | --------------------+------------------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Looks fine to me. 'see' has type 'forall a,b. IO (a->b)'. You bind it, so 'g' must have type 't1 -> t2' for some types 't1' and 't2'. There is no generalisation in a bind, so GHC must choose some types for 't1' and 't2'... and it has. It's essential for soundness that we don't generalise in a bind, otherwise we'd get the ML polymorphic reference problem. If you say {{{ r <- newIORef [] }}} you do not want 'r :: forall a. IORef [a]'. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 27 06:00:52 2008 From: trac at galois.com (GHC) Date: Thu Mar 27 05:57:24 2008 Subject: [GHC] #1148: Bad warnings about unused imports that are in fact needed In-Reply-To: <045.bee1b922a3147d2353135cd2446dcba2@localhost> References: <045.bee1b922a3147d2353135cd2446dcba2@localhost> Message-ID: <054.d325ee7e91a74ed1d5fdc2f1e90d654b@localhost> #1148: Bad warnings about unused imports that are in fact needed -----------------------------------+---------------------------------------- Reporter: brianh | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: Keywords: warning unused import | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -----------------------------------+---------------------------------------- Comment (by simonpj): This is actually a slightly different issue to the one that started this ticket. Consider {{{ module Foo(x) where import List(null) x = 3 y1 = null y2 = y1 y3 = y2 }}} What would you like? * Report `y3` unused, only. The trouble here is that when you delete `y3` you now get a new warning that `y2` is unused. And so on. * Report `y3,y2,y1,null` all unused? This gets them all in one one go, but if you don't respond to them all (e.g. you delete only `y1`), the module won't compile. And currently different flags affect unused (a) imports and (b) local bindings, so GHC might report `null` unused, but not `y3,y2,y1`. It's not clear what the best design is. Currently GHC follows the latter, but I'm open to suggestions. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 27 09:00:26 2008 From: trac at galois.com (GHC) Date: Thu Mar 27 08:56:47 2008 Subject: [GHC] #2179: Improve error message when `main' is not of the right type Message-ID: <047.bbe528ebb3bf93f65afc730c1ab28125@localhost> #2179: Improve error message when `main' is not of the right type -------------------------------+-------------------------------------------- Reporter: amiddelk | Owner: Type: proposal | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: trivial Keywords: | Testcase: Architecture: x86_64 (amd64) | Os: Linux -------------------------------+-------------------------------------------- If you run the following module with GHC(i): > module Main where > main = "hi" You get the error message: > Couldn't match expected type `IO a' against inferred type `[Char]' > In the first argument of `GHC.TopHandler.runMainIO', namely `main' > When checking the type of the function `main' The error message would be a bit nicer if the second line was hidden. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 27 13:40:00 2008 From: trac at galois.com (GHC) Date: Thu Mar 27 13:36:49 2008 Subject: [GHC] #2180: Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock Message-ID: <045.aae0aee80d987ae754764eec42f593a9@localhost> #2180: Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock --------------------------------+------------------------------------------- Reporter: Baughn | Owner: Baughn Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 6.9 | Severity: minor Keywords: | Testcase: Architecture: Unknown | Os: Multiple --------------------------------+------------------------------------------- The runtime system's deadlock detection, being a debugging feature, rightly doesn't break a deadlock if there's any chance a signal will do so later. However, if the only installed signal is XCPU - cpu time-limit exceeded - then that will almost never happen in practice; any program that does want to wait for it will be waiting quite literally years. As such, it seems best if XCPU is left out of the signal-detection logic. The attached patch does this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 27 14:25:55 2008 From: trac at galois.com (GHC) Date: Thu Mar 27 14:22:44 2008 Subject: [GHC] #2180: Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock In-Reply-To: <045.aae0aee80d987ae754764eec42f593a9@localhost> References: <045.aae0aee80d987ae754764eec42f593a9@localhost> Message-ID: <054.856bbbb2ab10b254f6fd2a7129156355@localhost> #2180: Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock --------------------------------+------------------------------------------- Reporter: Baughn | Owner: Baughn Type: feature request | Status: assigned Priority: normal | Milestone: Component: Runtime System | Version: 6.9 Severity: minor | Resolution: Keywords: | Testcase: Architecture: Unknown | Os: Multiple --------------------------------+------------------------------------------- Changes (by Baughn): * status: new => assigned -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 27 15:57:15 2008 From: trac at galois.com (GHC) Date: Thu Mar 27 15:53:31 2008 Subject: [GHC] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 In-Reply-To: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> References: <049.51a60eabf072f65f71f65ffe2a95214c@localhost> Message-ID: <058.117b38ae82285f318bfd1ec73ea8675c@localhost> #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126 ----------------------------+----------------------------------------------- Reporter: twhitehead | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------+----------------------------------------------- Comment (by twhitehead): The one that fails the quickest so far is Bug.2.hs (3hrs 10min). As noted above, however, the exact error message is slightly different than the others. I also have also not discovered any RTS flags to speed up the time to crash (so far I have only tried -H10g). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 27 19:21:45 2008 From: trac at galois.com (GHC) Date: Thu Mar 27 19:18:05 2008 Subject: [GHC] #2181: internal error: END_TSO_QUEUE object entered! Message-ID: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> #2181: internal error: END_TSO_QUEUE object entered! -------------------------+-------------------------------------------------- Reporter: cconnett | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: sparc | Os: Solaris -------------------------+-------------------------------------------------- internal error: END_TSO_QUEUE object entered! (GHC version 6.8.2 for sparc_sun_solaris2) This error occurs if I pass -optc-O2 or greater. At -optc-O1 it does not occur. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Mar 27 20:07:54 2008 From: trac at galois.com (GHC) Date: Thu Mar 27 20:04:15 2008 Subject: [GHC] #2182: ghci session retains instances after :m -Module Message-ID: <044.c09df8f4b72158c8c14035187a5540c9@localhost> #2182: ghci session retains instances after :m -Module ------------------------+--------------------------------------------------- Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.9 | Severity: normal Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- {{{ $ compiler/stage2/ghc-inplace --interactive GHCi, version 6.9.20080317: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :i Functor class Functor f where fmap :: (a -> b) -> f a -> f b -- Defined in GHC.Base instance Functor Maybe -- Defined in Data.Maybe instance Functor [] -- Defined in GHC.Base instance Functor IO -- Defined in GHC.IOBase Prelude> fmap not (True,True) :1:0: No instance for (Functor ((,) Bool)) arising from a use of `fmap' at :1:0-19 Possible fix: add an instance declaration for (Functor ((,) Bool)) In the expression: fmap not (True, True) In the definition of `it': it = fmap not (True, True) Prelude> :m +Data.Array Prelude Data.Array> :i Functor class Functor f where fmap :: (a -> b) -> f a -> f b -- Defined in GHC.Base instance (Ix i) => Functor (Array i) -- Defined in GHC.Arr instance Functor ((->) r) -- Defined in Control.Monad.Instances instance Functor ((,) a) -- Defined in Control.Monad.Instances instance Functor (Either a) -- Defined in Control.Monad.Instances instance Functor Maybe -- Defined in Data.Maybe instance Functor [] -- Defined in GHC.Base instance Functor IO -- Defined in GHC.IOBase Prelude Data.Array> fmap not (True,True) (True,False) Prelude Data.Array> :m -Data.Array Prelude> :i Functor class Functor f where fmap :: (a -> b) -> f a -> f b -- Defined in GHC.Base instance Functor ((->) r) -- Defined in Control.Monad.Instances instance Functor ((,) a) -- Defined in Control.Monad.Instances instance Functor (Either a) -- Defined in Control.Monad.Instances instance Functor Maybe -- Defined in Data.Maybe instance Functor [] -- Defined in GHC.Base instance Functor IO -- Defined in GHC.IOBase Prelude> fmap not (True,True) (True,False) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 28 18:04:53 2008 From: trac at galois.com (GHC) Date: Fri Mar 28 18:01:06 2008 Subject: [GHC] #2183: GHCi Message-ID: <043.869397c66b65e1a24406b7eb921527f2@localhost> #2183: GHCi -----------------------+---------------------------------------------------- Reporter: iago | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- First of all, excuse me for my poor English. The command history doesn't work correctly, it remembers any thing that you enter to the prompt, for example, it remembers an empty line like a command. {{{ Prelude> 1+1 2 }}} Now if you press up-arrow GHCi remembers the last statement: 1+1. OK but if you enter an empty line... {{{ Prelude> Prelude> }}} If you press up-arrow now, GHCi remembers the empty line, and not the correct last expression (1+1). You have to press the up-arrow key again to obtain the correct last expression 1+1. I have installed the GHC 6.8.2 Debian Sid package. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 28 19:42:33 2008 From: trac at galois.com (GHC) Date: Fri Mar 28 19:38:46 2008 Subject: [GHC] #2183: GHCi In-Reply-To: <043.869397c66b65e1a24406b7eb921527f2@localhost> References: <043.869397c66b65e1a24406b7eb921527f2@localhost> Message-ID: <052.ed3241df445be4f398e2359cf85cf0e7@localhost> #2183: GHCi -----------------------+---------------------------------------------------- Reporter: iago | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Changes (by judah): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. This has been fixed for 6.8.3 as #2073. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 28 20:20:21 2008 From: trac at galois.com (GHC) Date: Fri Mar 28 20:16:36 2008 Subject: [GHC] #2183: GHCi In-Reply-To: <043.869397c66b65e1a24406b7eb921527f2@localhost> References: <043.869397c66b65e1a24406b7eb921527f2@localhost> Message-ID: <052.a40f12d9a4122ffeffd05f58c870cf4e@localhost> #2183: GHCi -----------------------+---------------------------------------------------- Reporter: iago | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Testcase: Architecture: x86 | Os: Linux -----------------------+---------------------------------------------------- Comment (by iago): Replying to [comment:1 judah]: > Thanks for the report. This has been fixed for 6.8.3 as #2073. Sorry, I looked for another bug report, but I forgot to select the option to filter closed reports. And sorry for the stupid title "GHCi" too, I used Preview button but I only see it when I submit the report ;/ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Mar 28 20:50:09 2008 From: trac at galois.com (GHC) Date: Fri Mar 28 20:46:24 2008 Subject: [GHC] #2184: if findExecutable finds a file that matchs the argument don't check if it is an executable Message-ID: <043.14945e7e7a44f91d6d7e77f4c5d2fcfb@localhost> #2184: if findExecutable finds a file that matchs the argument don't check if it is an executable ------------------------------------------------+--------------------------- Reporter: iago | Owner: Type: bug | Status: new Priority: normal | Component: libraries/directory Version: 6.8.2 | Severity: normal Keywords: findExecutable check executable | Testcase: Architecture: x86 | Os: Linux ------------------------------------------------+--------------------------- When search finds a file that matchs with the fileName argument of findExecutable, it doesn't check if the file is an executable file. {{{ do path <- getEnv "PATH" search (splitSearchPath path) where fileName = binary <.> exeExtension search :: [FilePath] -> IO (Maybe FilePath) search [] = return Nothing search (d:ds) = do let path = d fileName b <- doesFileExist path if b then return (Just path) else search ds }}} findExecutable mustn't returns a file that it isn't an executable file, for example (~/bin is in PATH variable) {{{ $ touch ~/bin/foofile $ ghci $ :m System.Directory $ findExecutable "foofile" }}} shows that findExecutable returns IO (Just "/home/iago/bin/foofile"). Altought is not a bug, could be good add a new funcion (findExecutables for example) to return all the executables in all the paths of PATH variable that matchs with a given filename (like which -a). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 29 09:41:40 2008 From: trac at galois.com (GHC) Date: Sat Mar 29 09:37:51 2008 Subject: [GHC] #2185: Memory leak with parMap Message-ID: <044.5c6962ddf20fe9d5c3ed9f8bcf46a5b6@localhost> #2185: Memory leak with parMap -----------------------------------------+---------------------------------- Reporter: igloo | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -----------------------------------------+---------------------------------- With the attached `All.hs`, if you run the program without any arguments (so that it uses `parMap rnf` in `gen_blocks_list`) then its memory usage keeps going up, even though at the top level it's just running the same computation 5 times in a row. Memory usage goes up to over 100M. If you give an argument (any argument, so that it uses `map` instead) then memory usage is constant and only a few megs. Happens in 6.8.2 and the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 29 09:44:51 2008 From: trac at galois.com (GHC) Date: Sat Mar 29 09:41:01 2008 Subject: [GHC] #2185: Memory leak with parMap In-Reply-To: <044.5c6962ddf20fe9d5c3ed9f8bcf46a5b6@localhost> References: <044.5c6962ddf20fe9d5c3ed9f8bcf46a5b6@localhost> Message-ID: <053.d29322fe2447672d6b2c043290e76442@localhost> #2185: Memory leak with parMap --------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Comment (by igloo): Forgot to say: Compiling with {{{ ghc -Wall -fforce-recomp All.hs --make -fasm -O2 -threaded -fglasgow-exts -funbox-strict-fields -fbang-patterns -debug }}} I haven't experimented with other flags. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 29 15:28:49 2008 From: trac at galois.com (GHC) Date: Sat Mar 29 15:25:01 2008 Subject: [GHC] #2186: unsafePerformIO prevents space leak? Message-ID: <043.a1d3979db09afe9cd755cca819ea107a@localhost> #2186: unsafePerformIO prevents space leak? -------------------------+-------------------------------------------------- Reporter: ravi | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: normal Keywords: | Testcase: Architecture: Multiple | Os: Linux -------------------------+-------------------------------------------------- Sadly, I don't have a concrete testcase for this, but I've fixed this issue in the Bluespec compiler more than once, so I have a strong suspicion that there's a GHC bug (or lack of optimization) going on here. The basic situation is that I have a deeply nested structures of IORefs (I once measured one particular instance as including chains over 300 IORefs deep). I want to walk this structure recursively (it does not contain loops) without mutating it to compute a property of this structure. Generally speaking I'm either looking to accumulate certain kinds of nodes or I'm looking to detect the presence or absence of a certain kind of node. If I traverse this structure in the IO monad (using readIORef directly and recursing and combining using things like mapM and foldM) I see a huge space leak (which can be confirmed with profiling). If I take the same traversal and wrap up the readIORef inside an unsafePerformIO (and change mapM to map and the like) the space leak disappears. This surprised me because I thought it would be the sort of thing GHC could figure out. I'm sorry I can't easily give you a testcase, but I hope I've included enough detail that you have a fighting chance of reproducing it. Please let me know if you have any questions. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 29 16:04:41 2008 From: trac at galois.com (GHC) Date: Sat Mar 29 16:01:32 2008 Subject: [GHC] #1699: Fix network wrt abstract unix sockets In-Reply-To: <064.885c49d5fecaaffdac334b45404fbbd4@localhost> References: <064.885c49d5fecaaffdac334b45404fbbd4@localhost> Message-ID: <073.127b5640c37b2d9f1d2e5efefffd1d90@localhost> #1699: Fix network wrt abstract unix sockets ---------------------------------------+------------------------------------ Reporter: kolmodin@dtek.chalmers.se | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/network | Version: 6.6.1 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ---------------------------------------+------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I've applied aus_simple.dpatch. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 29 16:13:56 2008 From: trac at galois.com (GHC) Date: Sat Mar 29 16:10:22 2008 Subject: [GHC] #2187: Top-level bindings are broken for polymorphic values Message-ID: <045.4e9ad0d5e8f90abbc43e5cdae1d520dd@localhost> #2187: Top-level bindings are broken for polymorphic values ------------------------+--------------------------------------------------- Reporter: yallop | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.2 | Severity: major Keywords: | Testcase: Architecture: Unknown | Os: Unknown ------------------------+--------------------------------------------------- Top-level pattern bindings don't work for polymorphic values. Here's an example program: {{{ [x] = [id] }}} ghci gives this the type {{{ *Main> :t x x :: GHC.Prim.Any -> GHC.Prim.Any }}} which can't be used {{{ *Main> x () :1:2: Couldn't match expected type `GHC.Prim.Any' against inferred type `()' In the first argument of `x', namely `()' In the expression: x () In the definition of `it': it = x () }}} Adding a type signature doesn't help: {{{ x :: a -> a [x] = [id] Couldn't match expected type `forall a. a -> a' against inferred type `a -> a' Probable cause: `id' is applied to too few arguments In the expression: id In the expression: [id] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Mar 29 16:32:36 2008 From: trac at galois.com (GHC) Date: Sat Mar 29 16:29:05 2008 Subject: [GHC] #2186: unsafePerformIO prevents space leak? In-Reply-To: <043.a1d3979db09afe9cd755cca819ea107a@localhost> References: <043.a1d3979db09afe9cd755cca819ea107a@localhost> Message-ID: <052.64cb824075f0537b393c06cb3915cc8a@localhost> #2186: unsafePerformIO prevents space leak? -------------------------+-------------------------------------------------- Reporter: ravi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Testcase: Architecture: Multiple | Os: Linux -------------------------+-------------------------------------------------- Comment (by tim): Have you tried compiling the monadic version with {{{-fno-state-hack}}}? See http://www.haskell.org/ghc/docs/latest/html/users_guide/options- optimise.html It's not a solution, but it would be interesting to know what happens if you try that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 08:14:11 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 08:10:36 2008 Subject: [GHC] #2186: unsafePerformIO prevents space leak? In-Reply-To: <043.a1d3979db09afe9cd755cca819ea107a@localhost> References: <043.a1d3979db09afe9cd755cca819ea107a@localhost> Message-ID: <052.76f27d3b7db12927673b6d00fd13b9c6@localhost> #2186: unsafePerformIO prevents space leak? ----------------------+----------------------------------------------------- Reporter: ravi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: I'm not sure I follow. If you do something like {{{ do bools <- mapM readIORef refs return (and bools) }}} then all the `Bool`s will need to be in memory at once, as all the `readIORef`s will be run before `mapM` returns, whereas {{{ and (map (unsafePerformIO . readIORef) refs) }}} would run in constant space. Have I misunderstood the problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 08:43:05 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 08:39:28 2008 Subject: [GHC] #2187: Top-level bindings are broken for polymorphic values In-Reply-To: <045.4e9ad0d5e8f90abbc43e5cdae1d520dd@localhost> References: <045.4e9ad0d5e8f90abbc43e5cdae1d520dd@localhost> Message-ID: <054.eaa143d8e0e6350be3c47ba172940142@localhost> #2187: Top-level bindings are broken for polymorphic values ----------------------+----------------------------------------------------- Reporter: yallop | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the report. Your first example is deliberately broken (relative to Haskell98); see http://www.haskell.org/ghc/docs/latest/html/users_guide/monomorphism.html for details, or use `-XNoMonoPatBinds` to get the Haskell98-specified behaviour. If you give a type signature for `x` then I would have expected it to work; Simon? yallop, I assume you ran into this problem in a real program? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 10:42:05 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 10:38:17 2008 Subject: [GHC] #2104: Add Labels In-Reply-To: <045.8e0dd3d5e2a0d3899747780f8d7a3947@localhost> References: <045.8e0dd3d5e2a0d3899747780f8d7a3947@localhost> Message-ID: <054.61f7897e511eee976fad1e82fccfbb7e@localhost> #2104: Add Labels -----------------------------+---------------------------------------------- Reporter: barney | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 10:42:05 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 10:38:20 2008 Subject: [GHC] #2120: Arrays allow out-of-bounds indexes In-Reply-To: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> References: <046.df9dbe29ac2a6f0cde1841f7056aebbe@localhost> Message-ID: <055.7d1104314c10bc54fdfb1a6c3b1a4eb4@localhost> #2120: Arrays allow out-of-bounds indexes -------------------------------+-------------------------------------------- Reporter: amthrax | Owner: Type: bug | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 10:42:05 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 10:38:23 2008 Subject: [GHC] #2157: Equality Constraints with Type Families In-Reply-To: <047.9207b8f452560eac1f90c6a1629a593a@localhost> References: <047.9207b8f452560eac1f90c6a1629a593a@localhost> Message-ID: <056.cec23e62893f087a016e59e70700e14e@localhost> #2157: Equality Constraints with Type Families -------------------------------------+-------------------------------------- Reporter: hpacheco | Owner: chak Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -------------------------------------+-------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 10:42:05 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 10:38:35 2008 Subject: [GHC] #2167: The -main-is option to runghc does not appear to work. In-Reply-To: <042.26782109759233e42fa49e7dd26bf4be@localhost> References: <042.26782109759233e42fa49e7dd26bf4be@localhost> Message-ID: <051.facec44cc2ae40237e789cbb6984c6d0@localhost> #2167: The -main-is option to runghc does not appear to work. ----------------------+----------------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: NetBSD | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > The -main-is option to runghc does not appear to work, at least not when > specifying a package name. Create Hello.hs: > > module Hello where > main = putStrLn "Hello." > > and then try to run it: > > runghc -main-is Hello Hello.hs > > You will see: > > :1:113: > Failed to load interface for `Main': > Use -v to see a list of the files searched for. New description: The -main-is option to runghc does not appear to work, at least not when specifying a package name. Create Hello.hs: {{{ module Hello where main = putStrLn "Hello." }}} and then try to run it: {{{ runghc -main-is Hello Hello.hs }}} You will see: {{{ :1:113: Failed to load interface for `Main': Use -v to see a list of the files searched for. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 10:44:17 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 10:40:24 2008 Subject: [GHC] #2168: ghci should show haddock comments for identifier In-Reply-To: <049.47be5fa91ec9885f4a8847376f7f589a@localhost> References: <049.47be5fa91ec9885f4a8847376f7f589a@localhost> Message-ID: <058.fcd545ebf064e3964cfb10599d5dd7fa@localhost> #2168: ghci should show haddock comments for identifier -----------------------------+---------------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > This came up in comp.lang.haskell recently: > http://groups.google.com/group/comp.lang.haskell/msg/ae69f720377e7a3f > > I like the idea. > > Immediate thoughts: > * if ghci reads the source file, it can read haddock annotations > * if ghci reads the interface file only (for library modules), > it needs to find the installed documentation > > On the other hand the requested feature is a typical IDE functionality > (cf. Eclipse/show source/show javadoc) and it's perhaps a bit much > to require that from ghci. New description: This came up in comp.lang.haskell recently: http://groups.google.com/group/comp.lang.haskell/msg/ae69f720377e7a3f I like the idea. Immediate thoughts: * if ghci reads the source file, it can read haddock annotations * if ghci reads the interface file only (for library modules), it needs to find the installed documentation On the other hand the requested feature is a typical IDE functionality (cf. Eclipse/show source/show javadoc) and it's perhaps a bit much to require that from ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 10:52:32 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 10:48:42 2008 Subject: [GHC] #2184: if findExecutable finds a file that matchs the argument, check if it is an executable In-Reply-To: <043.14945e7e7a44f91d6d7e77f4c5d2fcfb@localhost> References: <043.14945e7e7a44f91d6d7e77f4c5d2fcfb@localhost> Message-ID: <052.d0259b7cc5facff62099d69e30d6608c@localhost> #2184: if findExecutable finds a file that matchs the argument, check if it is an executable ---------------------------------------------+------------------------------ Reporter: iago | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/directory | Version: 6.8.2 Severity: normal | Resolution: Keywords: findExecutable check executable | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ---------------------------------------------+------------------------------ Changes (by igloo): * difficulty: => Unknown * summary: if findExecutable finds a file that matchs the argument don't check if it is an executable => if findExecutable finds a file that matchs the argument, check if it is an executable * milestone: => 6.8.3 Comment: Thanks for the report; we should be able to fix this for 6.8.3. For your proposed `findExecutables` addition, please follow the [http://www.haskell.org/haskellwiki/Library_submissions library submissions] procedure. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 10:53:55 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 10:50:17 2008 Subject: [GHC] #2186: unsafePerformIO prevents space leak? In-Reply-To: <043.a1d3979db09afe9cd755cca819ea107a@localhost> References: <043.a1d3979db09afe9cd755cca819ea107a@localhost> Message-ID: <052.2a95392fa46ad10908b496538c438210@localhost> #2186: unsafePerformIO prevents space leak? ----------------------+----------------------------------------------------- Reporter: ravi | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 10:59:13 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 10:55:21 2008 Subject: [GHC] #2182: ghci session retains instances after :m -Module In-Reply-To: <044.c09df8f4b72158c8c14035187a5540c9@localhost> References: <044.c09df8f4b72158c8c14035187a5540c9@localhost> Message-ID: <053.5d4090344d841af45b4b932aba3b7a42@localhost> #2182: ghci session retains instances after :m -Module ---------------------+------------------------------------------------------ Reporter: claus | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------+------------------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thans for the report. #333 claims to have fixed this, but if so then it looks like it broke again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 11:01:45 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 10:58:05 2008 Subject: [GHC] #2181: internal error: END_TSO_QUEUE object entered! In-Reply-To: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> References: <047.dee38a6db16ff9d02335c0fd5c0c9f51@localhost> Message-ID: <056.2a009db6a7d12f683d6c0afc30f69d1b@localhost> #2181: internal error: END_TSO_QUEUE object entered! ----------------------+----------------------------------------------------- Reporter: cconnett | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: Thanks for the report; however, without a test case this is virtually impossible to fix, or to confirm that we have fixed the bug that you are seeing. Can you please attach some code that triggers the problem to this ticket, and say exactly what commands you are running? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 11:06:59 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 11:03:07 2008 Subject: [GHC] #2176: H98 module Array exports non-H98 instance Functor ((->) a) In-Reply-To: <045.a9dd1faca636f175591a794f8e7a99a8@localhost> References: <045.a9dd1faca636f175591a794f8e7a99a8@localhost> Message-ID: <054.78abebd0320fe5639c3e928d521a936d@localhost> #2176: H98 module Array exports non-H98 instance Functor ((->) a) ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/haskell98 | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 11:22:47 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 11:18:58 2008 Subject: [GHC] #2171: Parallel program crashes In-Reply-To: <042.91539dd5667f046cb861faa36a106615@localhost> References: <042.91539dd5667f046cb861faa36a106615@localhost> Message-ID: <051.944e0e2d4637971f7ee9a0738fddc696@localhost> #2171: Parallel program crashes ---------------------------------------------+------------------------------ Reporter: fed | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: Keywords: parallel, crash, race condition | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ---------------------------------------------+------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.3 Comment: I can't reproduce this with the 6.8.2 Windows installer on XP x86, nor the head on Linux/amd64. Can anyone else reproduce it? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 11:28:12 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 11:24:22 2008 Subject: [GHC] #2179: Improve error message when `main' is not of the right type In-Reply-To: <047.bbe528ebb3bf93f65afc730c1ab28125@localhost> References: <047.bbe528ebb3bf93f65afc730c1ab28125@localhost> Message-ID: <056.6b45392ef4fca2ecb65ef7b5eacdcd28@localhost> #2179: Improve error message when `main' is not of the right type ----------------------+----------------------------------------------------- Reporter: amiddelk | Owner: Type: proposal | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------+----------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Agreed; thanks for the report! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 11:42:52 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 11:39:00 2008 Subject: [GHC] #2177: Can Data.Unique safely derive Typeable? In-Reply-To: <045.8724b926d6549afcfc85d1a3ada0af59@localhost> References: <045.8724b926d6549afcfc85d1a3ada0af59@localhost> Message-ID: <054.85078c45bc608885c82646085406c420@localhost> #2177: Can Data.Unique safely derive Typeable? -----------------------------+---------------------------------------------- Reporter: japple | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: I'm not sure whether you mean: * You want a `Typeable Unique` instance in the base library * You want `Unique`'s constructor exposed so that you can derive instances for it * You think standalone deriving should work for types which don't expose their constructors Can you clarify please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 12:21:34 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 12:17:41 2008 Subject: [GHC] #2171: Parallel program crashes In-Reply-To: <042.91539dd5667f046cb861faa36a106615@localhost> References: <042.91539dd5667f046cb861faa36a106615@localhost> Message-ID: <051.a51af8367a093ef5b76e191e9697c55c@localhost> #2171: Parallel program crashes ---------------------------------------------+------------------------------ Reporter: fed | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: Keywords: parallel, crash, race condition | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ---------------------------------------------+------------------------------ Comment (by fed): It's rather strange because I can reproduce the problem again and again and I have seen a lot of "Segmentation fault/access violation in generated code" outputs. Probably exactly the same type of dual core processor is required ? AMD Athlon x2. I am attaching generated exe-file just in case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 12:51:01 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 12:47:14 2008 Subject: [GHC] #2170: make install fails for x86 ubuntu linux In-Reply-To: <049.0d556eeabc4a78a94c949fcc072ba5e9@localhost> References: <049.0d556eeabc4a78a94c949fcc072ba5e9@localhost> Message-ID: <058.494e67dcb25af3d6a1d973e109d83810@localhost> #2170: make install fails for x86 ubuntu linux ------------------------+--------------------------------------------------- Reporter: skurtzberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ------------------------+--------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. I've just installed `ghc-6.9.20080323-x86_64 -unknown-linux.tar.bz2` and `ghc-6.8.2.20080323-x86_64-unknown- linux.tar.bz2` with `/bin/sh` as `dash`, and had no problems. If something still isn't working for you, please open a bug report, including the command that is being run and what the error is. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 12:52:03 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 12:48:11 2008 Subject: [GHC] #2168: ghci should show haddock comments for identifier In-Reply-To: <049.47be5fa91ec9885f4a8847376f7f589a@localhost> References: <049.47be5fa91ec9885f4a8847376f7f589a@localhost> Message-ID: <058.da034706928c8416b2f19f6c19400420@localhost> #2168: ghci should show haddock comments for identifier -----------------------------+---------------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by igloo): The link says: {{{ I really like the feature (in other languages like python) which shows you the doc string for a function or object. For example if I type from the python interpreter: >> help(function) I get the docstring of function defined as def function(): """ docstring for function""" Is it possible to have something similar in haskell?? The type of the object is very useful, but a little comment would be even better... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 12:56:00 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 12:52:08 2008 Subject: [GHC] #2168: ghci should show haddock comments for identifier In-Reply-To: <049.47be5fa91ec9885f4a8847376f7f589a@localhost> References: <049.47be5fa91ec9885f4a8847376f7f589a@localhost> Message-ID: <058.cdc4b1fb7912f7616112c62394afae1d@localhost> #2168: ghci should show haddock comments for identifier -----------------------------+---------------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by igloo): * milestone: => 6.10 branch Comment: If we want an IDE to be able to do it then we probably want the functionality to be in the GHC API, at which point GHCi may as well do it. I don't think looking for the installed docs is a good idea; better would be to put the info in the `.hi` file (or another file installed alongside the `.o` and `.hi` files; perhaps it would even make sense to spit the parsed source out into a file, so that we can also do things like :list?). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 13:34:18 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 13:30:39 2008 Subject: [GHC] #2167: The -main-is option to runghc does not appear to work. In-Reply-To: <042.26782109759233e42fa49e7dd26bf4be@localhost> References: <042.26782109759233e42fa49e7dd26bf4be@localhost> Message-ID: <051.dcaee721370de4aa6d1c617d5a46b6d2@localhost> #2167: The -main-is option to runghc does not appear to work. ----------------------+----------------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: NetBSD | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. Happily, this has already been fixed (see #1312), although note that you need to escape `Hello`: {{{ runghc -main-is --ghc-arg=Hello Hello.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 13:52:48 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 13:49:22 2008 Subject: [GHC] #2180: Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock In-Reply-To: <045.aae0aee80d987ae754764eec42f593a9@localhost> References: <045.aae0aee80d987ae754764eec42f593a9@localhost> Message-ID: <054.8397faa09b4bc61547c19a6ad8c8b8fc@localhost> #2180: Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock -----------------------------+---------------------------------------------- Reporter: Baughn | Owner: Baughn Type: feature request | Status: assigned Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.10 branch Comment: Thanks for the suggestion, and patch! It feels a little ad-hoc to me, and some applications may use the signal for other purposes; any other opinions? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 14:16:22 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 14:12:32 2008 Subject: [GHC] #2158: deriving (Ix) and listArray give unexpected results In-Reply-To: <044.54d602356c43d2c31db7911ab87aa37c@localhost> References: <044.54d602356c43d2c31db7911ab87aa37c@localhost> Message-ID: <053.6186b8cc26390615ab35db48db6beefb@localhost> #2158: deriving (Ix) and listArray give unexpected results ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.8.3 Comment: Right, http://haskell.org/onlinereport/ix.html says that {{{ range (l,u) !! index (l,u) i == i -- when i is in range }}} must hold, but {{{ Prelude Foo Data.Array> let l = Pos 0 0; u = Pos 2 3; i = Pos 0 1 in range (l,u) !! index (l,u) i == i False }}} I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 15:41:25 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 15:37:32 2008 Subject: [GHC] #2158: deriving (Ix) and listArray give unexpected results In-Reply-To: <044.54d602356c43d2c31db7911ab87aa37c@localhost> References: <044.54d602356c43d2c31db7911ab87aa37c@localhost> Message-ID: <053.7c1dab31e0a48a43d97efcd323c2921e@localhost> #2158: deriving (Ix) and listArray give unexpected results ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: arr019 | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * testcase: => arr019 * type: bug => merge Comment: Fixed in the HEAD: {{{ Sun Mar 30 19:28:13 BST 2008 Ian Lynagh * Derive a valid Ix instance for data Foo = Foo Int Int The old one didn't satisfy the axioms. See trac #2158 for details. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 15:46:05 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 15:42:41 2008 Subject: [GHC] #2180: Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock In-Reply-To: <045.aae0aee80d987ae754764eec42f593a9@localhost> References: <045.aae0aee80d987ae754764eec42f593a9@localhost> Message-ID: <054.0198923e0b4c721e4b67b1586271996c@localhost> #2180: Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock -----------------------------+---------------------------------------------- Reporter: Baughn | Owner: Baughn Type: feature request | Status: assigned Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | -----------------------------+---------------------------------------------- Comment (by Baughn): You are quite right. This patch fixes the immediate problem caused by another patch to lambdabot (that still hasn't been applied) removing loop detection in this specific instance, but a more discriminating system could be helpful. How about if I write a patch adding an explicit mask/unmask call for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 16:06:49 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 16:02:56 2008 Subject: [GHC] #2171: Parallel program crashes In-Reply-To: <042.91539dd5667f046cb861faa36a106615@localhost> References: <042.91539dd5667f046cb861faa36a106615@localhost> Message-ID: <051.0eeeb5dfec2a0bfa6d22ccd2628bdae2@localhost> #2171: Parallel program crashes ---------------------------------------------+------------------------------ Reporter: fed | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: Keywords: parallel, crash, race condition | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ---------------------------------------------+------------------------------ Comment (by igloo): Ah, OK - I only have single-processor machines. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 16:16:49 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 16:12:56 2008 Subject: [GHC] #2171: Parallel program crashes In-Reply-To: <042.91539dd5667f046cb861faa36a106615@localhost> References: <042.91539dd5667f046cb861faa36a106615@localhost> Message-ID: <051.ab5fbeabcaccbdb7b7c7d165d87b2780@localhost> #2171: Parallel program crashes ---------------------------------------------+------------------------------ Reporter: fed | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: critical | Resolution: Keywords: parallel, crash, race condition | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ---------------------------------------------+------------------------------ Comment (by judah): I can reproduce this on my iMac (2.4 GHz Intel Core 2 Duo). I get a {{{Bus error}}} about half of the times that I run the program. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 17:13:29 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 17:09:34 2008 Subject: [GHC] #2188: TH scoping problem Message-ID: <044.2bbd6efb87952e5e65fa7406d244cf0e@localhost> #2188: TH scoping problem ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Template Haskell | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: TH_scope Architecture: Unknown | Os: Unknown ---------------------------------+------------------------------------------ In the HEAD, these modules: {{{ module TH_scope where import TH_scope_helper x :: () x = () where hold = $( wibble [d| hold :: () hold = () |] ) }}} {{{ module TH_scope_helper where import Language.Haskell.TH wibble :: Q [Dec] -> Q Exp wibble _ = [| 'a' |] }}} give: {{{ TH_scope.hs:8:31: Misplaced type signature: hold :: () The type signature must be given where `hold' is declared }}} Renaming the outer `hold` fixes it. The 6.8 branch seems OK. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 17:35:10 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 17:31:17 2008 Subject: [GHC] #2014: getLinkDeps panic In-Reply-To: <043.959b8170a1a6ec2b7cea0d1cfc8fd3ff@localhost> References: <043.959b8170a1a6ec2b7cea0d1cfc8fd3ff@localhost> Message-ID: <052.29222a7e052b368d11b1a12fdc204838@localhost> #2014: getLinkDeps panic ----------------------+----------------------------------------------------- Reporter: fons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.3 Component: Compiler | Version: 6.8.2 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by igloo): I hit #2188 a lot while trying to make a minimal test case for this. Giving up for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Mar 30 17:45:13 2008 From: trac at galois.com (GHC) Date: Sun Mar 30 17:41:24 2008 Subject: [GHC] #2168: ghci should show haddock comments for identifier In-Reply-To: <049.47be5fa91ec9885f4a8847376f7f589a@localhost> References: <049.47be5fa91ec9885f4a8847376f7f589a@localhost> Message-ID: <058.cc1773e0ed3483820e6d0c610e506614@localhost> #2168: ghci should show haddock comments for identifier -----------------------------+---------------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Changes (by claus): * cc: claus (added) Comment: the [http://www.cs.kent.ac.uk/~cr3/toolbox/haskell/Vim/ haskellmode for vim plugins] have supported this for quite some time, but only for installed packages, by going the awkward route of parsing the urls out of the `doc-index-*.html` files. replacing that hack with something supported by ghc would be nice. haddock comments are often meant to be used from within a browser, with interlinkage/highlighting/etc, so the plugins call a browser, and i'd recommend ghci doing the same, separating out the need for a text/console- renderer. that reduces the problem to 1 finding the correct base urls, which is mostly ghc-pkg responsibility (currently outside ghc api, i think) - `ghc --print-docdir` would give one location; `ghc-pkg field '*' haddock-html` gives all locations (the latter is a recent addition to `ghc-pkg` and not yet used in the haskellmode plugins). 2 constructing the correct relative urls, which ghc api ought to provide help with 3 finding the correct tool instance (which `ghc-pkg` is the one to call for the current `ghci` session?). there's a ticket somewhere for this general problem, iirc. 4 do something about sources/modules not yet processed by haddock given solutions to 2&3, accessible from within ghci, one could then use `ghc-pkg` to construct the complete url for an identifier, and call a browser for it. i'd be tempted to require running haddock to avoid treating 4 specially, but a purely cmdline-based interface might be nice, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 31 05:01:47 2008 From: trac at galois.com (GHC) Date: Mon Mar 31 04:58:04 2008 Subject: [GHC] #2187: Top-level bindings are broken for polymorphic values In-Reply-To: <045.4e9ad0d5e8f90abbc43e5cdae1d520dd@localhost> References: <045.4e9ad0d5e8f90abbc43e5cdae1d520dd@localhost> Message-ID: <054.06a77bd5424823da037ed32867f369c0@localhost> #2187: Top-level bindings are broken for polymorphic values ----------------------+----------------------------------------------------- Reporter: yallop | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by yallop): Thanks for the reply. Yes, I ran into the problem in a real program. I have code that looks like this: {{{ (x1,...,xn) = (e1,...en) where y = e z = f }}} which is generated via Template Haskell. Sometimes the bindings are supposed to be polymorphic, sometimes not. It looks like I have two choices, neither of which is particularly desirable: 1. Change the generation scheme to emit less elegant code, which will also complicate the generation code. 2. Require all users of the library to add -XNoMonoPatBinds From a user's perspective (at least, from this user's), defaulting to monomorphic pattern bindings looks like quite an unfortunate choice: 1. It doesn't bring any actual benefits to the user (that I can see). 2. It breaks compatibility with Haskell 98, so code that works on other implementations mysteriously fails without so much as a warning. 3. It generates quite unusable code: there's no realistic use for functions of type {{{ GHC.Prim.Any -> GHC.Prim.Any }}} so why default to generating that sort of thing? 4. It makes it more difficult to transform programs, since you can no longer replace {{{ x = f (a,b) }}} with {{{ (c,d) = (a,b) f (c,d) }}} It's difficult to see how it can simplify the implementation, since you still have to cope with -XNoMonoPatBinds. There must be *some* reason for this change, but what can it be? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 31 05:52:19 2008 From: trac at galois.com (GHC) Date: Mon Mar 31 05:48:25 2008 Subject: [GHC] #838: GHC binary for FreeBSD/amd64 In-Reply-To: <044.99d7d73649e2c40163a15f6117571bf0@localhost> References: <044.99d7d73649e2c40163a15f6117571bf0@localhost> Message-ID: <053.463b4f0427288cd6138b7a5bdcb96e0c@localhost> #838: GHC binary for FreeBSD/amd64 -----------------------------+---------------------------------------------- Reporter: alter | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: x86_64 (amd64) Os: FreeBSD | -----------------------------+---------------------------------------------- Comment (by cce): I'm wondering if this has had any progress. What needs to be done? It seems that we lack a bootstrap file, what is this? Can you cross-compile a bootstrap from another architecture? Anyway, having ghc running on 64 bits would be very nice -- I'm unable to run xmonad on my system without this compiled on amd64 arch. Thank you kindly for any help you may provide. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 31 09:26:32 2008 From: trac at galois.com (GHC) Date: Mon Mar 31 09:22:43 2008 Subject: [GHC] #838: GHC binary for FreeBSD/amd64 In-Reply-To: <044.99d7d73649e2c40163a15f6117571bf0@localhost> References: <044.99d7d73649e2c40163a15f6117571bf0@localhost> Message-ID: <053.8749d89588fa25f8f3627bfca367b280@localhost> #838: GHC binary for FreeBSD/amd64 -----------------------------+---------------------------------------------- Reporter: alter | Owner: igloo Type: feature request | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: N/A | Architecture: x86_64 (amd64) Os: FreeBSD | -----------------------------+---------------------------------------------- Comment (by guest): We have a bootstrap tarball for the FreeBSD port at http://www.freshports.org/lang/ghc. There was some problem with darcs, but we'd have to ask Olli about it since I couldn't keep track of AMD64 things (he's on the haskell@-alias, so we should here from him soon)..I'm not sure this was related to only FreeBSD 7. Volker -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 31 12:45:09 2008 From: trac at galois.com (GHC) Date: Mon Mar 31 12:41:21 2008 Subject: [GHC] #1475: Adding imports and exports with Template Haskell In-Reply-To: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> References: <044.e6912bf72a7a61e5dd62c8e0004e6c4e@localhost> Message-ID: <053.b0078b1e54b65a08b9b86b44ab19dada@localhost> #1475: Adding imports and exports with Template Haskell ------------------------------+--------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ------------------------------+--------------------------------------------- Changes (by m4dc4p): * version: 6.6.1 => 6.8.2 Comment: I would love for template haskell to be able to add imports. I am using haskelldb to write strongly-typed SQL queries. These queries depend on a compile time representation of the database schema. That representation is obtained by running a program which produces Haskell source describing a given set of tables, etc. If TH could write import statements, I could dynamically generated my modules and then import them in one go. My queries would always be compiled against the most recent schema! It would be a great feature to have. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 31 12:51:29 2008 From: trac at galois.com (GHC) Date: Mon Mar 31 12:47:43 2008 Subject: [GHC] #1148: Bad warnings about unused imports that are in fact needed In-Reply-To: <045.bee1b922a3147d2353135cd2446dcba2@localhost> References: <045.bee1b922a3147d2353135cd2446dcba2@localhost> Message-ID: <054.61ca3f4bdbc9e9c338071125a8e65501@localhost> #1148: Bad warnings about unused imports that are in fact needed -----------------------------------+---------------------------------------- Reporter: brianh | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: Keywords: warning unused import | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -----------------------------------+---------------------------------------- Comment (by simonmar): I like the current behaviour. GHC used to have the former behaviour, and there were complaints that we didn't detect unused cycles. (I presume the original bug about reporting unused qualified names still stands, though). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 31 12:54:01 2008 From: trac at galois.com (GHC) Date: Mon Mar 31 12:50:04 2008 Subject: [GHC] #2185: Memory leak with parMap In-Reply-To: <044.5c6962ddf20fe9d5c3ed9f8bcf46a5b6@localhost> References: <044.5c6962ddf20fe9d5c3ed9f8bcf46a5b6@localhost> Message-ID: <053.aa99e8561961a975968b6203de58c0ef@localhost> #2185: Memory leak with parMap --------------------------------------+------------------------------------- Reporter: igloo | Owner: simonmar Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------------+------------------------------------- Changes (by simonmar): * owner: => simonmar * milestone: 6.8.3 => 6.10 branch Comment: I think sparks are currently treated as roots by the GC, which is wrong. I won't get around to fixing this in 6.8.3, but I'll do it in the new GC code in 6.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 31 13:04:33 2008 From: trac at galois.com (GHC) Date: Mon Mar 31 13:01:02 2008 Subject: [GHC] #2180: Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock In-Reply-To: <045.aae0aee80d987ae754764eec42f593a9@localhost> References: <045.aae0aee80d987ae754764eec42f593a9@localhost> Message-ID: <054.b379fe2ef51b5114c31b42aab2107757@localhost> #2180: Any installed signal handler stops deadlock detection, but XCPU never happens in a deadlock -----------------------------+---------------------------------------------- Reporter: Baughn | Owner: Baughn Type: feature request | Status: assigned Priority: normal | Milestone: 6.10 branch Component: Runtime System | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Multiple | -----------------------------+---------------------------------------------- Comment (by simonmar): I think this needs to be under programmer control if we do it at all. Also, the patch doesn't affect the behaviour of the threaded RTS, we should make sure the two behave consistently. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 31 13:11:12 2008 From: trac at galois.com (GHC) Date: Mon Mar 31 13:07:17 2008 Subject: [GHC] #2168: ghci should show haddock comments for identifier In-Reply-To: <049.47be5fa91ec9885f4a8847376f7f589a@localhost> References: <049.47be5fa91ec9885f4a8847376f7f589a@localhost> Message-ID: <058.96305238da31a226d89b5bad5e5ca4dc@localhost> #2168: ghci should show haddock comments for identifier -----------------------------+---------------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -----------------------------+---------------------------------------------- Comment (by simonmar): The documentation is stored in the Haddock interface file now, and Haddock has a library that provides access to the .haddock files. So it seems to me the right way to go is for GHCi to invoke the Haddock library to get the docs. Unfortunately this needs some restructuring: the Haddock library would become a boot package. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 31 13:28:30 2008 From: trac at galois.com (GHC) Date: Mon Mar 31 13:24:48 2008 Subject: [GHC] #1148: Bad warnings about unused imports that are in fact needed In-Reply-To: <045.bee1b922a3147d2353135cd2446dcba2@localhost> References: <045.bee1b922a3147d2353135cd2446dcba2@localhost> Message-ID: <054.2fcca21f8b6418f56e9dc8700677fdbc@localhost> #1148: Bad warnings about unused imports that are in fact needed -----------------------------------+---------------------------------------- Reporter: brianh | Owner: Type: bug | Status: new Priority: lowest | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: trivial | Resolution: Keywords: warning unused import | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | -----------------------------------+---------------------------------------- Comment (by Eelis-): Hm, I'm confused. Maybe my testcase was bad, because it might've suggested that the warning was simply a consequence of b being unused. Here's a better testcase: {{{ import List import Prelude main = do l <- getLine print $ List.null l }}} Here there can be absolutely no doubt that List.null is used, yet still GHC warns that nothing from List is used. Furthermore, the warning goes away if the "import Prelude" line is removed or if the two import lines are reversed. It seems to me that this can only be considered a genuine bug, not a reasonable consequence of any particular design choice. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 31 16:49:53 2008 From: trac at galois.com (GHC) Date: Mon Mar 31 16:46:35 2008 Subject: [GHC] #1673: Template Haskell support for type families In-Reply-To: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> References: <065.e2dcaba876dc26f94848b54efa34a3d4@localhost> Message-ID: <074.e1f4fbba2b77fb1af1627059cc99dad3@localhost> #1673: Template Haskell support for type families ----------------------------------------+----------------------------------- Reporter: g9ks157k@acme.softbase.org | Owner: Type: feature request | Status: new Priority: low | Milestone: 6.10 branch Component: Template Haskell | Version: 6.7 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------------------------+----------------------------------- Changes (by ganesh): * cc: ganesh@earth.li (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 31 17:04:49 2008 From: trac at galois.com (GHC) Date: Mon Mar 31 17:01:09 2008 Subject: [GHC] #2187: Top-level bindings are broken for polymorphic values In-Reply-To: <045.4e9ad0d5e8f90abbc43e5cdae1d520dd@localhost> References: <045.4e9ad0d5e8f90abbc43e5cdae1d520dd@localhost> Message-ID: <054.4672d7b64fdb9765da69f25a98a9b31e@localhost> #2187: Top-level bindings are broken for polymorphic values ----------------------+----------------------------------------------------- Reporter: yallop | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Comment (by simonmar): Linking to the Haskell' page with the motivation for this change: [http://hackage.haskell.org/cgi-bin/haskell- prime/trac.cgi/wiki/MonomorphicPatternBindings] As for whether it makes the implementation simpler, I presume the intention was to deprecate and eventually remove `-XNoMonoPatBinds` at which point the complexities to deal with polymorphic pattern bindings would go away. (however we can't do that while we still want to support Haskell 98, of course). I'm going to follow up on this with the Haskell' committee. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Mar 31 17:22:49 2008 From: trac at galois.com (GHC) Date: Mon Mar 31 17:18:51 2008 Subject: [GHC] #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP Message-ID: <047.b31f95b84e60784da45a33105d44ed84@localhost> #2189: hSetBuffer stdin NoBuffering doesn't seem to work in ghc 6.8.2 on Windows XP -----------------------------------------------+---------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.8.2 | Severity: normal Keywords: hsetbuffering buffering buffer | Testcase: Architecture: x86 | Os: Windows -----------------------------------------------+---------------------------- The following program repeats inputted characters until the escape key is pressed. {{{ import IO import Monad import Char main :: IO () main = do hSetBuffering stdin NoBuffering inputLoop inputLoop :: IO () inputLoop = do i <- getContents mapM_ putChar $ takeWhile ((/= 27) . ord) i }}} Because of the "hSetBuffering stdin NoBuffering" line it should not be necessary to press the enter key between keystrokes. This program works correctly in WinHugs (sep 2006 version). However, GHC 6.8.2 does not repeat the characters until the enter key is pressed. The problem was reproduced with all GHC executables (ghci, ghc, runghc, runhaskell), using both cmd.exe and command.com on Windows XP Professional. -- Ticket URL: GHC The Glasgow Haskell Compiler