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