From trac at galois.com Tue Sep 1 03:32:42 2009 From: trac at galois.com (GHC) Date: Tue Sep 1 03:12:15 2009 Subject: [GHC] #3310: `show BlockedIndefinitely` should not equal `show BlockedOnDeadMVar` In-Reply-To: <045.d15d45f5a8175ad9674d39f51d4c22e6@localhost> References: <045.d15d45f5a8175ad9674d39f51d4c22e6@localhost> Message-ID: <054.57ad2f7fa50cbb3067d75fc312634e23@localhost> #3310: `show BlockedIndefinitely` should not equal `show BlockedOnDeadMVar` ---------------------------------+------------------------------------------ Reporter: enolan | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: I went a bit further and actually changed the exception names. {{{ Sun Aug 30 16:28:50 BST 2009 Simon Marlow * Address #3310 - Rename BlockedOnDeadMVar -> BlockedIndefinitelyOnMVar - Rename BlockedIndefinitely -> BlockedIndefinitelyOnSTM - instance Show BlockedIndefinitelyOnMVar is now "blocked indefinitely in an MVar operation" - instance Show BlockedIndefinitelyOnSTM is now "blocked indefinitely in an STM transaction" clients using Control.OldException will be unaffected (the new exceptions are mapped to the old names). However, for base4-compat we'll need to make a version of catch/try that does a similar mapping. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 1 03:38:43 2009 From: trac at galois.com (GHC) Date: Tue Sep 1 03:18:09 2009 Subject: [GHC] #1466: Stack check for AP_STACK In-Reply-To: <047.7c173e1376e77f3c13da1413f2657210@localhost> References: <047.7c173e1376e77f3c13da1413f2657210@localhost> Message-ID: <056.c6139616b15b2e0fdaa3584fd609714c@localhost> #1466: Stack check for AP_STACK ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: concprog001 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * component: Runtime System => Compiler * milestone: 6.12.1 => 6.14.1 Comment: Bumping to 6.14.1 as this is work to do in the new codegen. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 1 05:09:14 2009 From: trac at galois.com (GHC) Date: Tue Sep 1 04:48:40 2009 Subject: [GHC] #3480: Easily make Typeable keys pure, so that Typeable can be handled efficiently across communications Message-ID: <044.e3702794ded3f91904f114f506e31845@localhost> #3480: Easily make Typeable keys pure, so that Typeable can be handled efficiently across communications ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: task | Status: new Priority: normal | Component: libraries/base Version: | Severity: trivial Keywords: Typeable, efficiency | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------+------------------------------------------ Data.Typeable: Easily make Typeable keys pure(used in Eq), so that Typeable keys don?t vary from run to run. This permits an efficient storage of the keys in files and to be transmitted trough communications as well as processed without loss of efficiency. Actually gaining efficiency probably, since the keys caches are not necessary. Currently, whenever the user needs to communicate types, he must transmit the full string name for each type. Moreover, in the reception, the programmer is forced to handle these full string keys for mapping types to handlers, in equality checks etc. if the type keys are pure, the efficiency of key handling can be keept across communications. short description of task: Istead of using a Hash( stringType, generatedKey) use hashString (string- of-type) Long description: 1) drop the cache drop newKey 2) use instead the expression: Key $ hashString str whenever a new key is needed from the package Data.HashTable: hashString :: String -> Int the key obtained is pure so: 3) drop the "IO" in typeRepKey signature -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 1 10:50:22 2009 From: trac at galois.com (GHC) Date: Tue Sep 1 10:30:32 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.fdd470a8cce58794662af7aaf28dd1ab@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by guest): * cc: njloof@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 1 14:38:35 2009 From: trac at galois.com (GHC) Date: Tue Sep 1 14:18:17 2009 Subject: [GHC] #3459: ghci 6.10.4 and 6.10.1 crash with a big list In-Reply-To: <046.37f1fbfe6457c6d9dc39b6d0b0bfdcb4@localhost> References: <046.37f1fbfe6457c6d9dc39b6d0b0bfdcb4@localhost> Message-ID: <055.fa7535e52753079ce772afeb75ee780d@localhost> #3459: ghci 6.10.4 and 6.10.1 crash with a big list ---------------------+------------------------------------------------------ Reporter: joaoraf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: major | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 ---------------------+------------------------------------------------------ Comment (by Bart Massey): Confirmed. This has been around since GHC 6.8 at least, and fails with other big lists also. I'm not sure I agree the severity is "major", but I agree that it should be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 1 17:16:29 2009 From: trac at galois.com (GHC) Date: Tue Sep 1 16:56:06 2009 Subject: [GHC] #3459: ghci 6.10.4 and 6.10.1 crash with a big list In-Reply-To: <046.37f1fbfe6457c6d9dc39b6d0b0bfdcb4@localhost> References: <046.37f1fbfe6457c6d9dc39b6d0b0bfdcb4@localhost> Message-ID: <055.cc73e965b0a19abe812f155a644a7b7c@localhost> #3459: ghci 6.10.4 and 6.10.1 crash with a big list ------------------------+--------------------------------------------------- Reporter: joaoraf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: major | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------+--------------------------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: This almost certainly a dup of #780, which has been fixed recently. Try with the HEAD. If it fails, re-open the bug, but I'll close it meanwhile. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 1 17:57:55 2009 From: trac at galois.com (GHC) Date: Tue Sep 1 17:37:18 2009 Subject: [GHC] #3476: Compiler warning about non-exhaustive pattern match with GADT and type-signature In-Reply-To: <053.d13bf6f894f1cc3c85b9d23db6b510dc@localhost> References: <053.d13bf6f894f1cc3c85b9d23db6b510dc@localhost> Message-ID: <062.959985498e2af09c834b90e702c4351c@localhost> #3476: Compiler warning about non-exhaustive pattern match with GADT and type- signature ----------------------------------------+----------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | ----------------------------------------+----------------------------------- Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Happily this already works in the HEAD (and hence in the upcoming 6.12 release) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 2 03:55:42 2009 From: trac at galois.com (GHC) Date: Wed Sep 2 03:35:07 2009 Subject: [GHC] #711: shutdownHaskell() does not return allocated memory on Unix In-Reply-To: <075.111d4b2a7cd4bd954079dae4e1641cbc@localhost> References: <075.111d4b2a7cd4bd954079dae4e1641cbc@localhost> Message-ID: <084.f4d26e7e12d3fc3e74b6a74d619f7d2b@localhost> #711: shutdownHaskell() does not return allocated memory on Unix -----------------------------------------------------+---------------------- Reporter: lennart.augustsson@credit-suisse.com | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.5 Severity: minor | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------------------+---------------------- Changes (by simonmar): * priority: low => high * owner: igloo => simonmar * milestone: _|_ => 6.12.1 Comment: Just noticed this patch. I'll review and commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 2 04:19:46 2009 From: trac at galois.com (GHC) Date: Wed Sep 2 03:59:07 2009 Subject: [GHC] #3481: Nightly snapshot fails to install Message-ID: <043.648802f336c6762629e495848f7ef257@localhost> #3481: Nightly snapshot fails to install -------------------+-------------------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- Last night's x86_64-linux nightly snapshot fails to install with: {{{ gcc -E -I/usr/local/include -I/home/dons/include -undef -traditional -P -DINSTALLING -DLIB_DIR='"/home/dons/lib/ghc-6.11.20090901"' -DINCLUDE_DIR='"/home/dons/lib/ghc-6.11.20090901/include"' -x c -Iincludes libffi/package.conf.in | grep -v '^#pragma GCC' | sed -e 's/""//g' -e 's/:[ ]*,/: /g' >libffi/package.conf.install gcc -E -I/usr/local/include -I/home/dons/include -undef -traditional -P -DINSTALLING -DLIB_DIR='"/home/dons/lib/ghc-6.11.20090901"' -DINCLUDE_DIR='"/home/dons/lib/ghc-6.11.20090901/include"' -DPAPI_INCLUDE_DIR="" -DPAPI_LIB_DIR="" -x c -Iincludes rts/package.conf.in | grep -v '^#pragma GCC' | sed -e 's/""//g' -e 's/:[ ]*,/: /g' >rts/package.conf.install rts/package.conf.in:4: error: rts/Config.h: No such file or directory make[1]: *** No rule to make target `utils/haddock/dist/build/tmp/haddock', needed by `install_libexecs'. Stop. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 2 08:24:43 2009 From: trac at galois.com (GHC) Date: Wed Sep 2 08:04:51 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.be6d871a725a866c25b06159e3afcc92@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by sekl): * cc: skluft@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 2 15:24:54 2009 From: trac at galois.com (GHC) Date: Wed Sep 2 15:04:14 2009 Subject: [GHC] #3482: Esc key no longer works in GHCi on Windows Message-ID: <044.ae6f78e469317a20a9332c2126d9402d@localhost> #3482: Esc key no longer works in GHCi on Windows --------------------+------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Severity: minor Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- I recently upgraded from 6.8.1 to 6.10.4. In GHCi 6.8.1 when I typed something at its command prompt and decided I didn't like it I could press Esc to erase a command line. That was very handy. In GHCi 6.10.4 hitting Esc does nothing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 2 20:03:13 2009 From: trac at galois.com (GHC) Date: Wed Sep 2 19:42:34 2009 Subject: [GHC] #959: Debugging info(?) leaks out: "Urk! Inventing strangely-kinded void TyCon" In-Reply-To: <044.3bf1d700079be84fe2d08b3da62c85d3@localhost> References: <044.3bf1d700079be84fe2d08b3da62c85d3@localhost> Message-ID: <053.3dc9469acf59aa96d0b351a80e0fc193@localhost> #959: Debugging info(?) leaks out: "Urk! Inventing strangely-kinded void TyCon" ----------------------------------------+----------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler (Type checker) | Version: 6.6 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: tcfail188 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Comment (by ganesh): I have encountered this in darcs when trying to make our phantom types be of some complicated (and arbitrarily chosen) kind to minimise the risk of them being instantiated with a real type (which would then lead to a risk of unsafeCoerce happening on those real types due to other aspects of the way we use phantom types). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 2 21:09:01 2009 From: trac at galois.com (GHC) Date: Wed Sep 2 20:48:21 2009 Subject: [GHC] #3483: Some mechanism for eliminating "absurd" patterns Message-ID: <044.05fb1984acc37eefec1ed6383058af74@localhost> #3483: Some mechanism for eliminating "absurd" patterns -----------------------------+---------------------------------------------- Reporter: ryani | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This is to help with type-level programming and doing dependent-like programming in Haskell. {{{ data TEq :: * -> * -> * where TEq :: TEq a a -- This declaration fails to compile because bringing (Int ~ Bool) -- into scope on the RHS is unsound. broken :: TEq Int Bool -> Int broken TEq = 1 -- Proposal: -- "!" replaces "=" in function declaration to say "this pattern is absurd" proposal :: TEq Int Bool -> r proposal TEq ! -- If, for some reason the pattern match succeeds, -- (basically, someone broke type safety with unsafeCoerce) -- the result could be something like calling: -- error "absurd pattern at FILE:LINE" }}} I'm not sure that "!" works with Haskell's syntax, but it does call attention to the pattern. The idea is that anywhere that putting "= some_rhs" would cause the compiler to fail because it can prove that the type environment is unsound in some fashion, you could use "!" to give a valid function definition. The same extension would be used for case statements, of course. See also #2006, which is related in spirit if not in implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 2 21:32:58 2009 From: trac at galois.com (GHC) Date: Wed Sep 2 21:12:17 2009 Subject: [GHC] #2110: Rules to eliminate casted id's In-Reply-To: <044.f3b76b9e96701f6ebb57092f8cedf6df@localhost> References: <044.f3b76b9e96701f6ebb57092f8cedf6df@localhost> Message-ID: <053.89f0042b5cfc737db4f750707724be4b@localhost> #2110: Rules to eliminate casted id's ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by ryani): * cc: ryani.spam@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 2 22:47:31 2009 From: trac at galois.com (GHC) Date: Wed Sep 2 22:26:51 2009 Subject: [GHC] #3484: GHC diverges when proving nonequality of types Message-ID: <044.b24389c149623a55fb40be839d0a136b@localhost> #3484: GHC diverges when proving nonequality of types -----------------------------+---------------------------------------------- Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Conor posted an interesting suggestion for proving type non-equality here: http://www.nabble.com/Re%3A-Is-it-possible-to-prove-type-*non*-equality- in-Haskell--p25153135.html I implemented it on my Nat framework and got GHC to diverge: {{{ C:\haskell>ghc -c Absurd.hs stack overflow: use +RTS -K to increase it }}} I've attempted to shrink the code as much as possible and still reproduce the error; attached is the result. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 3 00:43:35 2009 From: trac at galois.com (GHC) Date: Thu Sep 3 00:22:56 2009 Subject: [GHC] #3482: Esc key no longer works in GHCi on Windows In-Reply-To: <044.ae6f78e469317a20a9332c2126d9402d@localhost> References: <044.ae6f78e469317a20a9332c2126d9402d@localhost> Message-ID: <053.14b47e4f0884f350e465a970941b738a@localhost> #3482: Esc key no longer works in GHCi on Windows ---------------------+------------------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: minor | Resolution: worksforme Keywords: | Testcase: Os: Windows | Architecture: x86 ---------------------+------------------------------------------------------ Changes (by judah): * status: new => closed * resolution: => worksforme Comment: You can add back that keybinding by creating a .haskeline file in your home directory with the following line: {{{ bind: escape control-e KillLine }}} Please re-open this ticket if that solution does not work for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 3 02:10:54 2009 From: trac at galois.com (GHC) Date: Thu Sep 3 01:50:13 2009 Subject: [GHC] #3485: "Illegal type synonym family application in instance" error is unnecessary, should be removed Message-ID: <053.3893e570e78fa71dd6ee013e3e60e14c@localhost> #3485: "Illegal type synonym family application in instance" error is unnecessary, should be removed -----------------------------+---------------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- GHC shouldn't complain about "Illegal type synonym family application in instance", since there's an obvious workaround: {{{ type family Fam t instance C (Fam Int) }}} can become {{{ type family Fam t instance (Fam Int ~ famint) => C famint }}} The programmer ought to be smart enough to notice that Fam is not a type- constructor, so "Fam Int" is going to overlap like a type-variable. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 3 03:52:05 2009 From: trac at galois.com (GHC) Date: Thu Sep 3 03:31:52 2009 Subject: [GHC] #2578: "ld: atom sorting error for ..." on OS X In-Reply-To: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> References: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> Message-ID: <053.40d2696480530a83fe73b760bb2dad6e@localhost> #2578: "ld: atom sorting error for ..." on OS X ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by colin-adams): * version: 6.9 => 6.10.4 Comment: Seconded. I didn't attempt to run my program last night (on a laptop - offline from the internet) - I assumed I would have to report the bug and await a fix. Fortunately, I googled first and found this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 3 07:39:32 2009 From: trac at galois.com (GHC) Date: Thu Sep 3 07:18:51 2009 Subject: [GHC] #3486: Data.ByteString.elemIndices causes SEGV Message-ID: <042.edd017489a67f7a628a8510b09ab86e5@localhost> #3486: Data.ByteString.elemIndices causes SEGV --------------------+------------------------------------------------------- Reporter: nwn | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- The elemIndices for strict ByteString causes SEGV in some situation. {{{ import Data.Int import qualified Data.ByteString as S main = do cs <- S.getContents let ps = S.elemIndices 10 cs putStrLn $ "S.length cs = " ++ show (S.length cs) putStrLn $ "length ps = " ++ show (length ps) }}} If above program gets some large input, it crashes. {{{ $ ghc --make ei [1 of 1] Compiling Main ( ei.hs, ei.o ) Linking ei ... $ yes | head -10000 | ./ei S.length cs = 20000 Segmentation fault }}} By the way, there might be a border of SEGV or not. {{{ $ yes | head -4096 | ./ei S.length cs = 8192 Segmentation fault $ yes | head -4095 | ./ei S.length cs = 8190 length ps = 4095 }}} And this script works fine. {{{ import qualified Data.ByteString as S import qualified Data.ByteString.Lazy as L main = do let cs = S.pack . take 8192 . cycle $ [48,10] ps = S.elemIndices 10 cs putStrLn $ "length cs = " ++ show (S.length cs) putStrLn $ "length ps = " ++ show (length ps) }}} I think there is causes about the bug in S.getContents or S.elemIndices or both. But I cannot figure out it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 3 09:34:22 2009 From: trac at galois.com (GHC) Date: Thu Sep 3 09:13:41 2009 Subject: [GHC] #3487: Data.ByteString.Lazy.elemIndices returns wrong results Message-ID: <042.4f1103cc60c42d21bbc9fb56583d59f1@localhost> #3487: Data.ByteString.Lazy.elemIndices returns wrong results -----------------------------+---------------------------------------------- Reporter: nwn | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 -----------------------------+---------------------------------------------- elemIndices for Lazy ByteString returns wrong results occasionally for huge input. {{{ -- lei.hs import qualified Data.ByteString.Lazy as L import Control.Monad main = do n <- fmap (length . L.elemIndices 10) L.getContents putStrLn (show n) }}} {{{ $ ghc --make lei [1 of 1] Compiling Main ( lei.hs, lei.o ) Linking lei ... $ yes | head -1000000 | ./lei 1000000 $ yes | head -1000000 | ./lei 999992 $ yes | head -1000000 | ./lei 999960 $ yes | head -1000000 | ./lei 1000000 $ yes | head -1000000 | ./lei 999976 }}} Without getContents, elemIndices works fine. {{{ import qualified Data.ByteString.Lazy as L import System.Environment main = do n <- fmap (read . head) getArgs let cs = L.pack . take (2*n) . cycle $ [48,10] ps = L.elemIndices 10 cs print (length ps) }}} {{{ $ ghc --make lei2.hs [1 of 1] Compiling Main ( lei2.hs, lei2.o ) Linking lei2 ... $ ./lei2 1000000 1000000 $ ./lei2 1000000 1000000 }}} So I think there is a problem about bytestring IO. And I heard this isn't reproduced in Windows' command prompt. This ticket is based on [http://www.sampou.org/cgi-bin/w3ml.cgi/haskell- jp/msg/381 a thread of haskell-jp]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 4 14:34:09 2009 From: trac at galois.com (GHC) Date: Fri Sep 4 14:13:24 2009 Subject: [GHC] #3488: Impossible happened: RegAllocLinear.getStackSlotFor: out of stack slots Message-ID: <042.efd3a6588858af62ce043efa2d483c4a@localhost> #3488: Impossible happened: RegAllocLinear.getStackSlotFor: out of stack slots -----------------------------+---------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The attached file crashes GHC 6.10.4 when compiled with -c -O2 -prof. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 4 23:23:49 2009 From: trac at galois.com (GHC) Date: Fri Sep 4 23:03:03 2009 Subject: [GHC] #3478: ghc.exe doesn't work In-Reply-To: <044.ef537b15bcf446bdfd601d48316f603f@localhost> References: <044.ef537b15bcf446bdfd601d48316f603f@localhost> Message-ID: <053.463db5888ee4a80a574df4d7852abcd2@localhost> #3478: ghc.exe doesn't work ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple ----------------------+----------------------------------------------------- Changes (by guest): * keywords: ghc.exe => * status: new => closed * resolution: => invalid Comment: To the original guest reporter: ghc.exe is the compiler, it not meant to be run interactively like ghci is, open a cmd window then run ghc with command line options. Resolving invalid. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 6 08:21:55 2009 From: trac at galois.com (GHC) Date: Sun Sep 6 08:01:49 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.708b3370f2dc4029353d76bb69cf0aa9@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by simonmar): I've added `x86_64-apple-darwin` to the list of Tier-2 platforms on [wiki:Platforms] (optimistically assuming that it works unregisterised, at least). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 6 14:30:44 2009 From: trac at galois.com (GHC) Date: Sun Sep 6 14:10:35 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.c8dac081c14dd256709f32335f25ba8d@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by wmealing): * cc: wmealing@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 6 18:25:08 2009 From: trac at galois.com (GHC) Date: Sun Sep 6 18:05:06 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.8c611286c896f5e536952837a9e8a5f3@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by geekiac): * cc: geekiac@gmail.com, silversys@btinternet.com, steven.smith@emrltd.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 6 20:18:43 2009 From: trac at galois.com (GHC) Date: Sun Sep 6 19:58:37 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.398e256474049a799d804f65f6747026@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by pumpkin): Replying to [comment:18 simonmar]: > I've added `x86_64-apple-darwin` to the list of Tier-2 platforms on [wiki:Platforms] (optimistically assuming that it works unregisterised, at least). I'm not sure it even works unregistered, actually. The unregistered OS X x86_64 ghc build that Ian Lynagh made a couple of months ago unfortunately included a bug that has since been fixed, that appeared (to Austin and me, at least) to prevent using it to build another GHC with it. And more recent attempts on my part to make a new unregistered build for x86_64 ran into several issues as described on #3472 . I've tried several times and have failed, but maybe my approach is incorrect, so I'd welcome it if anyone else on this CC list could try similar steps to see if it's PEBKAC :) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 6 20:26:54 2009 From: trac at galois.com (GHC) Date: Sun Sep 6 20:06:01 2009 Subject: [GHC] #3489: Adding some gmp bindings to integer-gmp (copied from the cvs-ghc list) Message-ID: <046.90f661b74011792a4af69e74c94446e3@localhost> #3489: Adding some gmp bindings to integer-gmp (copied from the cvs-ghc list) -----------------------------+---------------------------------------------- Reporter: pumpkin | Owner: Type: proposal | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This is my first patch for GHC, so I apologize in advance if I do something wrong! I've actually attached three patches for libraries/base, libraries/integer-gmp, and libraries/integer-simple, but because there is no change to any exposed API and only a couple of extra functions added to GHC.Integer, I'm sending it here instead of to libraries at haskell.org. Basically, I added cmm bindings to mpz_powm(_ui), mpz_tstbit, and mpz_sizeinbase. The modular exponentiation function is significantly faster than anything I could find in pure haskell, and the bit testing is way more efficient than the default Data.Bits implementation involving a potentially massive left shift (in fact, might that be better phrased as a right shift of the tested value?). The sizeinbase function (essentially an integer logarithm, unfortunately with the base restricted to a maximum of 62) also looked handy so I added it while I was there (at Bertram Felgenhauer's suggestion). So these patches amount to: * A one-line change to Data.Bits in base, adding our specialized testBit function. * Some cmm code additions in integer-gmp, plus the Haskell glue to make them usable from outside. * A very simplistic implementation of testBitInteger for integer-simple, so that the one-line change to Data.Bits doesn't fail when building with integer-simple. I've tested the code and it appears to be correct, and have validated it with both integer-simple and -gmp, in both cases encountering two unexpected ghci test failures (in OS X): ghci028 and 2816. Manuel Chakravarty said these were normal and that he'd experienced the build failures under OS X too, so I didn't look into them any more deeply. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 7 03:35:01 2009 From: trac at galois.com (GHC) Date: Mon Sep 7 03:14:10 2009 Subject: [GHC] #1262: mdo in Template Haskell In-Reply-To: <062.2857e038d8ba06eaa6e83d19ada8ff7e@localhost> References: <062.2857e038d8ba06eaa6e83d19ada8ff7e@localhost> Message-ID: <071.189aa6c4423f01957c7760f0d7b4ea3b@localhost> #1262: mdo in Template Haskell ----------------------------------------+----------------------------------- Reporter: philip.weaver@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by MartijnVanSteenbergen): * cc: MartijnVanSteenbergen (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 7 16:52:38 2009 From: trac at galois.com (GHC) Date: Mon Sep 7 16:31:51 2009 Subject: [GHC] #3484: GHC diverges when proving nonequality of types In-Reply-To: <044.b24389c149623a55fb40be839d0a136b@localhost> References: <044.b24389c149623a55fb40be839d0a136b@localhost> Message-ID: <053.edf50dc7fe6c39179b88c372432ee3bc@localhost> #3484: GHC diverges when proving nonequality of types ------------------------------+--------------------------------------------- Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by chak): We should probably document this somewhere: we know nothing about the properties of programs combining type families and rank-n types. It wouldn't surprise me if some of these programs lead to the type checker diverging. In other words, solving this problem likely requires some serious research into type systems combining type families and rank-n types. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 7 17:04:47 2009 From: trac at galois.com (GHC) Date: Mon Sep 7 16:43:56 2009 Subject: [GHC] #3485: "Illegal type synonym family application in instance" error is unnecessary, should be removed In-Reply-To: <053.3893e570e78fa71dd6ee013e3e60e14c@localhost> References: <053.3893e570e78fa71dd6ee013e3e60e14c@localhost> Message-ID: <062.68df8bca19f0c08f167b7d4a9ff44d96@localhost> #3485: "Illegal type synonym family application in instance" error is unnecessary, should be removed -------------------------------------+-------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------------+-------------------------------------- Changes (by chak): * status: new => closed * resolution: => invalid Comment: I am not sure what you are suggesting. We cannot automatically transform {{{ instance C (Fam Int) }}} into {{{ instance (Fam Int ~ famint) => C famint }}} This works if there is only one instance, but as soon as there are two such instances, they always overlap. Maybe you are suggesting that we should do it anyway and programmers should just take the implicit transformation into account. I don't think that this is a good idea. It's confusing for very little benefit (as you can always write the transformed instance yourself with little effort). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 7 17:12:28 2009 From: trac at galois.com (GHC) Date: Mon Sep 7 16:52:32 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.986c4469f6e80d7faf44bcdbf350dc73@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by chak): Replying to [comment:18 simonmar]: > I've added `x86_64-apple-darwin` to the list of Tier-2 platforms on [wiki:Platforms] (optimistically assuming that it works unregisterised, at least). Since the release of Snow Leopard (Mac OS X 10.5.8) x86_64-apple-darwin is the default for Macs. Given the upgrade price for Snow Leopard and the typical adoption rate of Macs users, this will soon be the most widely used Mac platform. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 03:07:17 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 02:46:30 2009 Subject: [GHC] #3484: GHC diverges when proving nonequality of types In-Reply-To: <044.b24389c149623a55fb40be839d0a136b@localhost> References: <044.b24389c149623a55fb40be839d0a136b@localhost> Message-ID: <053.000e69fe02856d482e228cc7e77b9643@localhost> #3484: GHC diverges when proving nonequality of types ---------------------------------+------------------------------------------ Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: It's true that we have not explicitly thought about higher rank, but I'm still surprised at divergence. Let's leave this open and on the type- families list, so that we remember to get back to it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 03:35:22 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 03:14:25 2009 Subject: [GHC] #3490: Relax superclass restrictions Message-ID: <046.d4ecd3a8759936af7853c82b7c4c099e@localhost> #3490: Relax superclass restrictions -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Severity: minor | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Doaitse points out that we currently reject {{{ class C a b | a -> b where class C a b => D a where }}} on the grounds that 'b' is not in scope in the second class decl. (Only type variables in the "head", namely (D a), can be mentioned in the superclass context.) My response to him was as follows. The easiest way forward is to re-express your program using type functions. Then class C will have just a single type parameter (a), with the 'b' part being expressed by a type function. That would resolve the problem rather nicely. Medium term, I think the Right Thing is to allow a class declaration {{{ class Q => C a b }}} (where Q is a context) if and only iff the type {{{ forall ab. Q => C a b }}} is unambiguous. What does "unambiguous" mean? As it happens, we are working on nailing that down right now. For example, here is a stupid but unambiguous declaration: {{{ type family F a class (b ~ F a, Eq b) => C a }}} I do not know of any non-stupid examples that would be rejected by the current rule, but there might be some. I'll open a ticket because I'd like to get to this when we have the other pieces working. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 03:35:40 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 03:14:43 2009 Subject: [GHC] #3491: Relax superclass restrictions Message-ID: <046.b6fd04394dc8a665bff9cc46e7abd115@localhost> #3491: Relax superclass restrictions -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Severity: minor | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Doaitse points out that we currently reject {{{ class C a b | a -> b where class C a b => D a where }}} on the grounds that 'b' is not in scope in the second class decl. (Only type variables in the "head", namely (D a), can be mentioned in the superclass context.) My response to him was as follows. The easiest way forward is to re-express your program using type functions. Then class C will have just a single type parameter (a), with the 'b' part being expressed by a type function. That would resolve the problem rather nicely. Medium term, I think the Right Thing is to allow a class declaration {{{ class Q => C a b }}} (where Q is a context) if and only iff the type {{{ forall ab. Q => C a b }}} is unambiguous. What does "unambiguous" mean? As it happens, we are working on nailing that down right now. For example, here is a stupid but unambiguous declaration: {{{ type family F a class (b ~ F a, Eq b) => C a }}} I do not know of any non-stupid examples that would be rejected by the current rule, but there might be some. I'll open a ticket because I'd like to get to this when we have the other pieces working. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 04:21:10 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 04:01:14 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.1708c7a1a28614bfaf2f04278b131814@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by maeder): Is there a workaround for template haskell (TH) code being compiled in 32bit mode? How does TH call ghc internally? (Adding "-optc-m32 -opta-m32 -optl-m32" to the installed ghci (and runghc?) did not help.) http://www.haskell.org/pipermail/haskell-cafe/2009-September/066009.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 05:39:36 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 05:18:41 2009 Subject: [GHC] #3492: Add TyThing -> HsSyn translation code from Haddock Message-ID: <047.e4d10615cff08a633af39815aac077cd@localhost> #3492: Add TyThing -> HsSyn translation code from Haddock -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- See attached; part of refactoring described in [wiki:Commentary/Compiler/TemplateHaskell]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 05:46:51 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 05:25:54 2009 Subject: [GHC] #3490: Relax superclass restrictions In-Reply-To: <046.d4ecd3a8759936af7853c82b7c4c099e@localhost> References: <046.d4ecd3a8759936af7853c82b7c4c099e@localhost> Message-ID: <055.146ce3bbf1bfc3723d33b08acc4d8120@localhost> #3490: Relax superclass restrictions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by claus): This sounded familiar. See #714 . -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 06:22:55 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 06:02:00 2009 Subject: [GHC] #3493: "make install" fails with error on rts/Config.h in HEAD Message-ID: <044.e3121a1d0ddafa3bdca737e47a0186e1@localhost> #3493: "make install" fails with error on rts/Config.h in HEAD -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Using the package from http://www.haskell.org/ghc/dist/current/dist/ghc-6.11.20090907-x86_64 -unknown-linux.tar.bz2 I think this is the symptom we need to find the cause of: {{{ rts/package.conf.in:4: error: rts/Config.h: No such file or directory }}} Full log: {{{ a1333478@dev2 ~/ghc-6.11.20090907 $ ./configure --prefix=$HOME checking for path to top of build tree... /home/a1333478/ghc-6.11.20090907 checking for perl... /usr/bin/perl checking if your perl works in shell scripts... yes checking for a BSD-compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for ar... /usr/bin/ar checking whether /usr/bin/ar is GNU ar... yes checking for ar arguments... q checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether ranlib is needed... no checking for sed... /bin/sed checking version of gcc... 4.1.2 checking how to run the C preprocessor... gcc -E checking for extra options to pass gcc when compiling via C... -fwrapv configure: creating ./config.status config.status: creating extra-gcc-opts config.status: creating mk/config.mk config.status: creating mk/install.mk **************************************************** Configuration done, ready to 'make install' (see README and INSTALL files for more info.) **************************************************** a1333478@dev2 ~/ghc-6.11.20090907 $ make install make -r --no-print-directory -f ghc.mk install BINDIST=YES NO_INCLUDE_DEPS=YES /usr/bin/install -c -m 755 -d /home/a1333478/bin "rm" -f /home/a1333478/bin/ghci-6.11.20090907 create () { touch $1 && chmod 755 $1 ; } && create /home/a1333478/bin/ghci-6.11.20090907 echo '#!/bin/sh' >> /home/a1333478/bin/ghci-6.11.20090907 echo 'exec /home/a1333478/bin/ghc-6.11.20090907 --interactive ${1+"$@"}' >> /home/a1333478/bin/ghci-6.11.20090907 chmod +x /home/a1333478/bin/ghci-6.11.20090907 "rm" -f /home/a1333478/bin/ghci ln -s ghci-6.11.20090907 /home/a1333478/bin/ghci /usr/bin/install -c -m 755 -d /home/a1333478/lib/ghc-6.11.20090907 /usr/bin/install -c -m 755 -d /home/a1333478/lib/ghc-6.11.20090907/include "cp" rts/dist/build/libHSrts.a rts/dist/build/libHSrts_p.a rts/dist/build /libHSrts-ghc6.11.20090907.so rts/dist/build/libHSrts_l.a rts/dist/build /libHSrts_debug-ghc6.11.20090907.so rts/dist/build/libHSrts_thr- ghc6.11.20090907.so rts/dist/build/libHSrts_thr_debug-ghc6.11.20090907.so rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_thr_p.a rts/dist/build/libHSrtsmain.a /home/a1333478/lib/ghc-6.11.20090907 /usr/bin/install -c -m 755 -d /home/a1333478/bin "rm" -f /home/a1333478/bin/haddock create () { touch $1 && chmod 755 $1 ; } && create /home/a1333478/bin/haddock echo '#!/bin/sh' >> /home/a1333478/bin/haddock echo 'executablename=/home/a1333478/lib/ghc-6.11.20090907/haddock' >> /home/a1333478/bin/haddock echo 'datadir=/home/a1333478/share' >> /home/a1333478/bin/haddock echo 'bindir=/home/a1333478/bin' >> /home/a1333478/bin/haddock echo 'topdir=/home/a1333478/lib/ghc-6.11.20090907' >> /home/a1333478/bin/haddock cat utils/haddock/haddock.wrapper >> /home/a1333478/bin/haddock chmod +x /home/a1333478/bin/haddock "rm" -f -r /home/a1333478/share/doc//html /usr/bin/install -c -m 755 -d /home/a1333478/share/doc//html "cp" -R utils/haddock/html /home/a1333478/share/doc//html /usr/bin/install -c -m 755 -d /home/a1333478/bin "rm" -f /home/a1333478/bin/hsc2hs create () { touch $1 && chmod 755 $1 ; } && create /home/a1333478/bin/hsc2hs echo '#!/bin/sh' >> /home/a1333478/bin/hsc2hs echo 'executablename=/home/a1333478/lib/ghc-6.11.20090907/hsc2hs' >> /home/a1333478/bin/hsc2hs echo 'datadir=/home/a1333478/share' >> /home/a1333478/bin/hsc2hs echo 'bindir=/home/a1333478/bin' >> /home/a1333478/bin/hsc2hs echo 'topdir=/home/a1333478/lib/ghc-6.11.20090907' >> /home/a1333478/bin/hsc2hs cat utils/hsc2hs/hsc2hs.wrapper >> /home/a1333478/bin/hsc2hs chmod +x /home/a1333478/bin/hsc2hs /usr/bin/install -c -m 644 utils/hsc2hs/template-hsc.h /home/a1333478/share /usr/bin/install -c -m 755 -d /home/a1333478/bin "rm" -f /home/a1333478/bin/ghc- pkg-6.11.20090907 create () { touch $1 && chmod 755 $1 ; } && create /home/a1333478/bin/ghc-pkg-6.11.20090907 echo '#!/bin/sh' >> /home/a1333478/bin /ghc-pkg-6.11.20090907 echo 'executablename=/home/a1333478/lib/ghc-6.11.20090907/ghc-pkg' >> /home/a1333478/bin/ghc-pkg-6.11.20090907 echo 'datadir=/home/a1333478/share' >> /home/a1333478/bin/ghc-pkg-6.11.20090907 echo 'bindir=/home/a1333478/bin' >> /home/a1333478/bin/ghc-pkg-6.11.20090907 echo 'topdir=/home/a1333478/lib/ghc-6.11.20090907' >> /home/a1333478/bin/ghc-pkg-6.11.20090907 cat utils/ghc-pkg/ghc-pkg.wrapper >> /home/a1333478/bin/ghc-pkg-6.11.20090907 chmod +x /home/a1333478/bin/ghc- pkg-6.11.20090907 /usr/bin/install -c -m 755 -d /home/a1333478/bin "rm" -f /home/a1333478/bin/ghc-pkg ln -s ghc-pkg-6.11.20090907 /home/a1333478/bin/ghc-pkg /usr/bin/install -c -m 755 -d /home/a1333478/bin "rm" -f /home/a1333478/bin/runghc create () { touch $1 && chmod 755 $1 ; } && create /home/a1333478/bin/runghc echo '#!/bin/sh' >> /home/a1333478/bin/runghc echo 'executablename=/home/a1333478/lib/ghc-6.11.20090907/runghc' >> /home/a1333478/bin/runghc echo 'datadir=/home/a1333478/share' >> /home/a1333478/bin/runghc echo 'bindir=/home/a1333478/bin' >> /home/a1333478/bin/runghc echo 'topdir=/home/a1333478/lib/ghc-6.11.20090907' >> /home/a1333478/bin/runghc cat utils/runghc/runghc.wrapper >> /home/a1333478/bin/runghc chmod +x /home/a1333478/bin/runghc "rm" -f /home/a1333478/bin/runhaskell ln -s runghc /home/a1333478/bin/runhaskell /usr/bin/install -c -m 755 -d /home/a1333478/bin "rm" -f /home/a1333478/bin/ghc-6.11.20090907 create () { touch $1 && chmod 755 $1 ; } && create /home/a1333478/bin/ghc-6.11.20090907 echo '#!/bin/sh' >> /home/a1333478/bin/ghc-6.11.20090907 echo 'executablename=/home/a1333478/lib/ghc-6.11.20090907/ghc-stage2' >> /home/a1333478/bin/ghc-6.11.20090907 echo 'datadir=/home/a1333478/share' >> /home/a1333478/bin/ghc-6.11.20090907 echo 'bindir=/home/a1333478/bin' >> /home/a1333478/bin/ghc-6.11.20090907 echo 'topdir=/home/a1333478/lib/ghc-6.11.20090907' >> /home/a1333478/bin/ghc-6.11.20090907 cat ghc/ghc.wrapper >> /home/a1333478/bin/ghc-6.11.20090907 chmod +x /home/a1333478/bin/ghc-6.11.20090907 "rm" -f /home/a1333478/bin/ghc ln -s ghc-6.11.20090907 /home/a1333478/bin/ghc gcc -E -undef -traditional -P -DINSTALLING -DLIB_DIR='"/home/a1333478/lib/ghc-6.11.20090907"' -DINCLUDE_DIR='"/home/a1333478/lib/ghc-6.11.20090907/include"' -x c -Iincludes libffi/package.conf.in | grep -v '^#pragma GCC' | sed -e 's/""//g' -e 's/:[ ]*,/: /g' >libffi/package.conf.install gcc -E -undef -traditional -P -DINSTALLING -DLIB_DIR='"/home/a1333478/lib/ghc-6.11.20090907"' -DINCLUDE_DIR='"/home/a1333478/lib/ghc-6.11.20090907/include"' -DPAPI_INCLUDE_DIR="" -DPAPI_LIB_DIR="" -x c -Iincludes rts/package.conf.in | grep -v '^#pragma GCC' | sed -e 's/""//g' -e 's/:[ ]*,/: /g' >rts/package.conf.install rts/package.conf.in:4: error: rts/Config.h: No such file or directory /usr/bin/install -c -m 755 -d /home/a1333478/lib/ghc-6.11.20090907 for i in utils/haddock/dist/build/tmp/haddock utils/hsc2hs/dist- install/build/tmp/hsc2hs utils/ghc-pkg/dist-install/build/tmp/ghc-pkg utils/runghc/dist/build/tmp/runghc ghc/stage2/build/tmp/ghc-stage2; do \ /usr/bin/install -c -m 755 $i /home/a1333478/lib/ghc-6.11.20090907; \ done /usr/bin/install -c -m 755 -d /home/a1333478/lib/ghc-6.11.20090907 "rm" -f /home/a1333478/lib/ghc-6.11.20090907/package.conf create () { touch $1 && chmod 644 $1 ; } && create /home/a1333478/lib/ghc-6.11.20090907/package.conf echo "[]" >> /home/a1333478/lib/ghc-6.11.20090907/package.conf "/home/a1333478/lib/ghc-6.11.20090907/ghc-pkg" --force --global-conf /home/a1333478/lib/ghc-6.11.20090907/package.conf update libffi/package.conf.install Reading package info from "libffi/package.conf.install" ... done. ffi-1.0: cannot find libHSffi.a on library path (ignoring) Writing new package config file... done. "/home/a1333478/lib/ghc-6.11.20090907/ghc-pkg" --force --global-conf /home/a1333478/lib/ghc-6.11.20090907/package.conf update rts/package.conf.install Reading package info from "rts/package.conf.install" ... done. Writing new package config file... done. "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc- stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/ghc-prim dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/integer-gmp dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/base dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/filepath dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/array dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/bytestring dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/containers dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/unix dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/old-locale dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/old-time dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/time dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/directory dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/process dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/random dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/extensible-exceptions dist- install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/haskell98 dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/hpc dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/pretty dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/syb dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/template-haskell dist- install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/base3-compat dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/Cabal dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/mtl dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/utf8-string dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/terminfo dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/haskeline dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/dph/dph-base dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/dph/dph-prim-interface dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/dph/dph-prim-seq dist- install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/dph/dph-prim-par dist- install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/dph/dph-seq dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && "inplace/bin/ghc-cabal" install /home/a1333478/lib/ghc-6.11.20090907/ghc-stage2 /home/a1333478/lib/ghc-6.11.20090907/ghc-pkg /home/a1333478/lib/ghc-6.11.20090907 libraries/dph/dph-par dist-install '' '/home/a1333478' '/home/a1333478/lib/ghc-6.11.20090907' '/home/a1333478/share/doc//html/libraries' && true Installing library in /home/a1333478/lib/ghc-6.11.20090907/ghc- prim-0.1.0.0 make[1]: *** [install_packages] Error 127 make: *** [install] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 07:00:48 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 06:39:52 2009 Subject: [GHC] #3490: Relax superclass restrictions In-Reply-To: <046.d4ecd3a8759936af7853c82b7c4c099e@localhost> References: <046.d4ecd3a8759936af7853c82b7c4c099e@localhost> Message-ID: <055.5b7ae980ba5f5c5371eccb8398c177e8@localhost> #3490: Relax superclass restrictions ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): Dead right -- thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 08:43:18 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 08:22:33 2009 Subject: [GHC] #783: SRTs bigger than they should be? In-Reply-To: <044.a7a580fed8a85952633cd84570dae070@localhost> References: <044.a7a580fed8a85952633cd84570dae070@localhost> Message-ID: <053.6be50d4832329a752280b8a88fac6038@localhost> #783: SRTs bigger than they should be? -----------------------------------------+---------------------------------- Reporter: guest | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.4.2 Severity: normal | Resolution: Keywords: performance | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by simonmar): * summary: performance problem compiling large file => SRTs bigger than they should be? * type: compile-time performance bug => run-time performance bug * milestone: 6.12.1 => 6.14.1 Comment: We should look at the SRTs in this example with the new code generator. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 08:43:46 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 08:22:51 2009 Subject: [GHC] #1136: High memory use when compiling many let bindings. In-Reply-To: <044.2f9aae100a9caba688d31e410efb3444@localhost> References: <044.2f9aae100a9caba688d31e410efb3444@localhost> Message-ID: <053.a7179c33dbf56ef6447705b8198fdc6d@localhost> #1136: High memory use when compiling many let bindings. ---------------------------------------------+------------------------------ Reporter: igloo | Owner: simonmar Type: compile-time performance bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: performance | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by simonmar): * owner: => simonmar Comment: I'll take another look at this before 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 09:19:26 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 08:58:30 2009 Subject: [GHC] #3403: linear stack usage where constant stack usage expected In-Reply-To: <044.c42570fd5e569e69e860d17ee2825cf7@localhost> References: <044.c42570fd5e569e69e860d17ee2825cf7@localhost> Message-ID: <053.78fb49fbb59276a536ec56b77333cd88@localhost> #3403: linear stack usage where constant stack usage expected -------------------------------------------+-------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: simplCore/should_run/T3403 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by simonpj): * testcase: => simplCore/should_run/T3403 * status: new => closed * resolution: => fixed Comment: Thanks for a fine bug report. It turned out that the CPR optimisation was interacting badly with the code generated by pattern matching. Happily, easy to fix. {{{ Tue Sep 8 14:14:00 BST 2009 simonpj@microsoft.com * Fix Trac #3403: interaction of CPR and pattern-match failure A fine bug report (#3403) demonstrated that we were losing the tail call property when a complicated pattern match was involved. After a bit of investigation I discovered that the culprit was the failure join-point introduced by the pattern matcher. It was a zero-argument thunk, which is not very CPR-friendly, and that interacted badly with CPR worker/wrapper. It's easy to fix, the same way that we fix other join points, by supplying a dummy argument (that is not really passed at runtime. M ./compiler/deSugar/DsUtils.lhs -12 +25 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 09:22:05 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 09:01:09 2009 Subject: [GHC] #3468: GHC panic: boxy_match_s In-Reply-To: <044.ef478f54ba5f4d944ccf7a1429e4456e@localhost> References: <044.ef478f54ba5f4d944ccf7a1429e4456e@localhost> Message-ID: <053.f2fedbe8159cc841832b1b07515342ca@localhost> #3468: GHC panic: boxy_match_s --------------------------------------------+------------------------------- Reporter: wkahl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: fixed Keywords: boxy_match_s | Difficulty: Unknown Testcase: typecheck/should_fail/T3468 | Os: Linux Architecture: powerpc | --------------------------------------------+------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T3468 * difficulty: => Unknown * status: new => closed * resolution: => fixed Comment: The underlying problem is that the bit of code that compares the `hs-boot` interface with the Real Truth gotten from the `.hs` file was forgetting to compare the kinds of the `TyCon`s involved. I've fixed that, so that this inconsistency won't happen again. Thank you for reporting it {{{ Tue Sep 8 14:03:50 BST 2009 simonpj@microsoft.com * Fix Trac #3468: improve checking for hs-boot interfaces When checking the interface exported by a hs-boot file against the Real Thing, I'd failed to check the kind of a type constructor. If you get it wrong, the inconsistency leads to all manner of mischief, as 'wkahl' reports in #3468. This patch should do the job. M ./compiler/typecheck/TcRnDriver.lhs -38 +52 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 10:10:12 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 09:49:26 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.a093a72c8e31d0da800ebeac5d97634f@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: reopened => new * owner: igloo => simonmar * milestone: 6.10.4 => 6.12.1 Comment: We need to look at this before 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 10:11:22 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 09:50:25 2009 Subject: [GHC] #3408: idle GC causes large CPU usage if run more frequently than 1 second In-Reply-To: <049.48be2d13214f4104fb7093c0a3d0accb@localhost> References: <049.48be2d13214f4104fb7093c0a3d0accb@localhost> Message-ID: <058.d06f530ca09757a14c1df26b5334fa44@localhost> #3408: idle GC causes large CPU usage if run more frequently than 1 second ---------------------------------+------------------------------------------ Reporter: JeremyShaw | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: idle GC | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * milestone: 6.12 branch => 6.12.1 Comment: I tried it on Linux and couldn't reproduce. Will investigate on Windows before 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 10:13:22 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 09:52:24 2009 Subject: [GHC] #3494: missing build system dependency Message-ID: <045.8de98aacac9d8b317157450367a72303@localhost> #3494: missing build system dependency -----------------------------+---------------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The `inplace/bin/ghc-cabal` does not get rebuilt automatically if the Cabal sources change. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 10:17:00 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 09:56:02 2009 Subject: [GHC] #3495: make install DESTDIR= is failing in ghc HEAD Message-ID: <045.ff2a4187d5c3667cca724b5d7a71c326@localhost> #3495: make install DESTDIR= is failing in ghc HEAD -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: major Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- `make install DESTDIR=$image` is failing currently with ghc HEAD. This is the method distro packages use so it'll need fixing before 6.12.1. The failing command is on the first instance of `ghc-cabal install` for the libs: {{{ "inplace/bin/ghc-cabal" install image/usr/... etc ghc-cabal: ghc-pkg dump failed }}} Unfortunately, it does not give any more info if I pass `-v3`. That flag seems to be swallowed rather than passed down. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 10:17:35 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 09:56:38 2009 Subject: [GHC] #3495: make install DESTDIR= is failing in ghc HEAD In-Reply-To: <045.ff2a4187d5c3667cca724b5d7a71c326@localhost> References: <045.ff2a4187d5c3667cca724b5d7a71c326@localhost> Message-ID: <054.8a78f4b7b7ed9acd3fbbe3f151043e45@localhost> #3495: make install DESTDIR= is failing in ghc HEAD ------------------------------+--------------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: major | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by duncan): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 10:25:53 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 10:04:58 2009 Subject: [GHC] #3473: System.Posix.Semaphore shouldn't create finalizers with Foreign.newForeignPtr In-Reply-To: <043.f9c52d751ae0cc6e4a228d8481612eb9@localhost> References: <043.f9c52d751ae0cc6e4a228d8481612eb9@localhost> Message-ID: <052.b6421a216a53262f83ad87553c74be5a@localhost> #3473: System.Posix.Semaphore shouldn't create finalizers with Foreign.newForeignPtr -------------------------------+-------------------------------------------- Reporter: kaol | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/unix | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown * milestone: => 6.12.1 Comment: I'll validate and push; thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 10:42:01 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 10:21:53 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.51f80cd4e63bc861a10fc4325a21e187@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by simonmar): Ok, just to summarise the situation: * 6.10.4 needs a tiny fix to work with Snow Leopard: add `-optc-m32 -opta-m32 -optl-m32` to the script `/usr/bin/ghc`, or wherever ghc lives on your system. If there is a problem with TH, then please make a separate ticket. * The 32-bit OS X distribution of GHC 6.12.1 will work on Snow Leopard without modification. * A 64-bit port is being worked on by various people (see e.g. #3472; we will help with the porting effort) * 64-bit OS X is, for the time being, a Tier-2 platform. That means we expect the community to support it, with guidance from GHC HQ. We don't hold up releases for it. (this is moot since there isn't even a working port at this stage, but still). However, depending on how much extra work is involved and the demand, we'll consider upgrading it to Tier-1 in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 10:52:52 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 10:31:55 2009 Subject: [GHC] #3479: Build from source fails with variables passed to configure In-Reply-To: <044.9b3cb4d5f450e5790f2e39cb68bcc8bf@localhost> References: <044.9b3cb4d5f450e5790f2e39cb68bcc8bf@localhost> Message-ID: <053.dc00deb0836fdd933142ab4053b89f98@localhost> #3479: Build from source fails with variables passed to configure ---------------------------------+------------------------------------------ Reporter: atler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: Ok, I claim that we should completely ignore `CFLAGS` and `LDFLAGS` settings. Does anyone disagree? GHC is not a C program: `CFLAGS` and `LDFLAGS` don't make sense here. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 11:26:56 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 11:06:04 2009 Subject: [GHC] #3479: Build from source fails with variables passed to configure In-Reply-To: <044.9b3cb4d5f450e5790f2e39cb68bcc8bf@localhost> References: <044.9b3cb4d5f450e5790f2e39cb68bcc8bf@localhost> Message-ID: <053.9b97abdd9624104224b6224d623f96c7@localhost> #3479: Build from source fails with variables passed to configure ---------------------------------+------------------------------------------ Reporter: atler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by atler): Actually I found the cause for this issue. All passed variables had space at the end, for example CFLAGS="-O2 -fno-strict-aliasing -fwrapv -march=i686 " which is stored in $CONFIGURE_ARGS as 'CFLAGS=-O2 -fno- strict-aliasing -fwrapv -march=i686 '. In mk/cabal-flags.mk $(space)' is used as a configure args separtor so it breaks in this case. I couldn't think of any simple solution to handle it (using only functions provided by make) but simple shell script would do the thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 13:04:06 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 12:44:06 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.8e913f944ccfe1f8fee61361c1c1dc84@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by simonpj): Just to add: what we would really like is for someone to step forward as the Maintainer of the X86_64 MacOS port of GHC. Then we really could make it a Tier-1 platform (see http://hackage.haskell.org/trac/ghc/wiki/Platforms). In principle its not hard: * MacOS is already in one Tier-1 platform (32 bit) * x86_64 is already in another Tier-1 platform (Linux) All we need to do is to put the two together -- and some folk are already working on that (#3472). But for us to sign up to Tier-1-ness, we need someone (or a small group) to sign up to being the maintainers. (Ben recently volunteered to be the maintainer for Sparc; thanks Ben.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 13:59:18 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 13:39:12 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.23021f50328a82ef5b612025b11d3235@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by pumpkin): Replying to [comment:25 simonpj]: > Just to add: what we would really like is for someone to step forward as the Maintainer of the X86_64 MacOS port of GHC. Then we really could make it a Tier-1 platform (see http://hackage.haskell.org/trac/ghc/wiki/Platforms). In principle its not hard: > * MacOS is already in one Tier-1 platform (32 bit) > * x86_64 is already in another Tier-1 platform (Linux) > All we need to do is to put the two together -- and some folk are already working on that (#3472). > > But for us to sign up to Tier-1-ness, we need someone (or a small group) to sign up to being the maintainers. > > (Ben recently volunteered to be the maintainer for Sparc; thanks Ben.) > > Simon I would definitely be willing to "co-maintain" this with someone else, but as a relative newcomer to Haskell and GHC (who hasn't even succeeded in making an unregistered build for this platform yet) I don't think I'd be suitable as a sole maintainer. Any experts out there who'd be willing to help? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 14:06:31 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 13:46:19 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.88ddecbfbe489ec6abf7d80adf67a1f5@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by geekiac): Replying to [comment:26 pumpkin]: I too would be happy to help to maintain this, however, I am also a relative newbie and would need assistance. If someone could point me in the right direction, I am a fast learner!!!! > Replying to [comment:25 simonpj]: > > Just to add: what we would really like is for someone to step forward as the Maintainer of the X86_64 MacOS port of GHC. Then we really could make it a Tier-1 platform (see http://hackage.haskell.org/trac/ghc/wiki/Platforms). In principle its not hard: > > * MacOS is already in one Tier-1 platform (32 bit) > > * x86_64 is already in another Tier-1 platform (Linux) > > All we need to do is to put the two together -- and some folk are already working on that (#3472). > > > > But for us to sign up to Tier-1-ness, we need someone (or a small group) to sign up to being the maintainers. > > > > (Ben recently volunteered to be the maintainer for Sparc; thanks Ben.) > > > > Simon > > I would definitely be willing to "co-maintain" this with someone else, but as a relative newcomer to Haskell and GHC (who hasn't even succeeded in making an unregistered build for this platform yet) I don't think I'd be suitable as a sole maintainer. Any experts out there who'd be willing to help? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 17:56:50 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 17:35:54 2009 Subject: [GHC] #3496: GHC panic while building the base library with Cabal Message-ID: <047.5c600ae82cf71150830a6ede7f6640ea@localhost> #3496: GHC panic while building the base library with Cabal ---------------------+------------------------------------------------------ Reporter: elliottt | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: major Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ---------------------+------------------------------------------------------ On a project here, we are building a custom version of ghc. Part of our build process involves building the base library with Cabal, which produces the following error message: {{{ [ 57 of 128] Compiling Data.Either ( Data/Either.hs, dist/build/Data/Either.o ) [ 58 of 128] Compiling System.IO.Error ( System/IO/Error.hs, dist/build/System/IO/Error.o ) [ 59 of 128] Compiling Text.Read ( Text/Read.hs, dist/build/Text/Read.o ) [ 60 of 128] Compiling Foreign.Ptr ( Foreign/Ptr.hs, dist/build/Foreign/Ptr.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: base:GHC.Word.W#{d 6w} [(32R, Type constructor `base:GHC.Word.Word{tc 32R}'), (32U, Type constructor `base:GHC.Word.Word8{tc 32U}'), (32X, Type constructor `base:GHC.Word.Word16{tc 32X}'), (333, Type constructor `base:GHC.Word.Word32{tc 333}'), (339, Type constructor `base:GHC.Word.Word64{tc 339}'), (r1ujj, Data constructor `base:GHC.Word.W64#{d r1ujj}'), (r1ujl, Data constructor `base:GHC.Word.W32#{d r1ujl}'), (r1ujn, Data constructor `base:GHC.Word.W16#{d r1ujn}'), (r1ujp, Data constructor `base:GHC.Word.W8#{d r1ujp}'), (r1ujr, Data constructor `base:GHC.Word.W#{d r1ujr}'), }}} The command that Cabal generated was this: {{{ /usr/bin/ghc -package-name base-4.1.0.0 --make -hide-all-packages -i -idist/build -i. \ -idist/build/autogen -Idist/build/autogen -Idist/build -Iinclude -optP- include \ -optPdist/build/autogen/cabal_macros.h -#include "HsBase.h" -odir dist/build \ -hidir dist/build -stubdir dist/build -package ghc-prim-0.1.0.0 -package integer-0.1.0.1 \ -package rts-1.0 -O -package-name base -XMagicHash -XExistentialQuantification -XRank2Types \ -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes \ -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XStandaloneDeriving \ -XPatternGuards -XEmptyDataDecls -XCPP Foreign.Concurrent GHC.Arr GHC.Base GHC.Classes GHC.Conc \ GHC.ConsoleHandler GHC.Desugar GHC.Enum GHC.Environment GHC.Err GHC.Exception GHC.Exts GHC.Float \ GHC.ForeignPtr GHC.Handle GHC.IO GHC.IOBase GHC.Int GHC.List GHC.Num GHC.PArr GHC.Pack GHC.Ptr \ GHC.Read GHC.Real GHC.ST GHC.STRef GHC.Show GHC.Stable GHC.Storable GHC.TopHandler GHC.Unicode \ GHC.Weak GHC.Word System.Timeout Control.Applicative Control.Arrow Control.Category \ Control.Concurrent Control.Concurrent.Chan Control.Concurrent.MVar Control.Concurrent.QSem \ Control.Concurrent.QSemN Control.Concurrent.SampleVar Control.Exception Control.Exception.Base \ Control.OldException Control.Monad Control.Monad.Fix Control.Monad.Instances Control.Monad.ST \ Control.Monad.ST.Lazy Control.Monad.ST.Strict Data.Bits Data.Bool Data.Char Data.Complex \ Data.Dynamic Data.Either Data.Eq Data.Data Data.Fixed Data.Foldable Data.Function Data.HashTable \ Data.IORef Data.Int Data.Ix Data.List Data.Maybe Data.Monoid Data.Ord Data.Ratio Data.STRef \ Data.STRef.Lazy Data.STRef.Strict Data.String Data.Traversable Data.Tuple Data.Typeable \ Data.Unique Data.Version Data.Word Debug.Trace Foreign Foreign.C Foreign.C.Error \ Foreign.C.String Foreign.C.Types Foreign.ForeignPtr Foreign.Marshal Foreign.Marshal.Alloc \ Foreign.Marshal.Array Foreign.Marshal.Error Foreign.Marshal.Pool Foreign.Marshal.Utils \ Foreign.Ptr Foreign.StablePtr Foreign.Storable Numeric Prelude System.Console.GetOpt \ System.CPUTime System.Environment System.Exit System.IO System.IO.Error System.IO.Unsafe \ System.Info System.Mem System.Mem.StableName System.Mem.Weak System.Posix.Internals \ System.Posix.Types Text.ParserCombinators.ReadP Text.ParserCombinators.ReadPrec Text.Printf \ Text.Read Text.Read.Lex Text.Show Text.Show.Functions Unsafe.Coerce }}} I noticed that if I remove the -O from the command that cabal generated, and rebuild after cleaning and re-configuring, the problem goes away. However, if I clean, reconfigure and use the command that Cabal generated, I get the same build error. This bug has been seen on x86 and x86_64 Linux installs. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 8 21:43:41 2009 From: trac at galois.com (GHC) Date: Tue Sep 8 21:23:38 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.d26e687c2c835852276fb78dcb0a6064@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by axman6): It's my ticket, so i guess i could take some responsibility. I'm not sure how useful I could be, or how much time i could spend, at least not until the summer holidays here (December to February). I've also never looked into GHC's source, so I'd probably need help too. So anyway, sign me up as co-maintainer, and i'll see how i can help when I have time. I'd also like to say thanks to everyone for the recent activity regarding this ticket. With Snow Leopard being the first Mac OS favouring 64-bit over 32, I think it's important that GHC move that way, so it doesn't feel left behind on the system. Replying to [comment:26 pumpkin]: > Replying to [comment:25 simonpj]: > > Just to add: what we would really like is for someone to step forward as the Maintainer of the X86_64 MacOS port of GHC. Then we really could make it a Tier-1 platform (see http://hackage.haskell.org/trac/ghc/wiki/Platforms). In principle its not hard: > > * MacOS is already in one Tier-1 platform (32 bit) > > * x86_64 is already in another Tier-1 platform (Linux) > > All we need to do is to put the two together -- and some folk are already working on that (#3472). > > > > But for us to sign up to Tier-1-ness, we need someone (or a small group) to sign up to being the maintainers. > > > > (Ben recently volunteered to be the maintainer for Sparc; thanks Ben.) > > > > Simon > > I would definitely be willing to "co-maintain" this with someone else, but as a relative newcomer to Haskell and GHC (who hasn't even succeeded in making an unregistered build for this platform yet) I don't think I'd be suitable as a sole maintainer. Any experts out there who'd be willing to help? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 03:24:12 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 03:03:15 2009 Subject: [GHC] #1262: mdo in Template Haskell In-Reply-To: <062.2857e038d8ba06eaa6e83d19ada8ff7e@localhost> References: <062.2857e038d8ba06eaa6e83d19ada8ff7e@localhost> Message-ID: <071.33a249e8c18c512fd1bfb04ecd562fd4@localhost> #1262: mdo in Template Haskell ----------------------------------------+----------------------------------- Reporter: philip.weaver@gmail.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Template Haskell | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Comment (by simonpj): See also #2798, where we propose to deprecate `mdo` in favour of a more modular `rec`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 04:01:09 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 03:40:18 2009 Subject: [GHC] #3497: Template Haskell support for GADTs Message-ID: <046.5070e39940e96fda263647e7217ed34d@localhost> #3497: Template Haskell support for GADTs -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Andres Loh asks that Template Haskell supports GADTs. Related tickets: #2399 (support view patterns), #1262 (support mdo/do rec). Really all that is needed here is for some motivated person to * Design the data types in `Language.Haskell.TH.Syntax` * Get a consensus that the design is a good one * Update pretty printers etc * Add conversions to and from from `HsSyn` to `TH.Syntax` (these are in `hsSyn/Convert.lhs` and `deSugar/DsMeta.lhs`). For the first two steps, the best plan might be to use the libraries process (ie make a proposal, give a discussion period etc). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 04:09:21 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 03:48:23 2009 Subject: [GHC] #3473: System.Posix.Semaphore shouldn't create finalizers with Foreign.newForeignPtr In-Reply-To: <043.f9c52d751ae0cc6e4a228d8481612eb9@localhost> References: <043.f9c52d751ae0cc6e4a228d8481612eb9@localhost> Message-ID: <052.12c01233fe532ef685c533ca744c786a@localhost> #3473: System.Posix.Semaphore shouldn't create finalizers with Foreign.newForeignPtr -------------------------------+-------------------------------------------- Reporter: kaol | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/unix | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Applied {{{ Tue Sep 8 07:25:36 PDT 2009 Simon Marlow * Use Foreign.Concurrent for Haskell finalizers (#3473) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 04:43:45 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 04:22:48 2009 Subject: [GHC] #3481: Nightly snapshot fails to install In-Reply-To: <043.648802f336c6762629e495848f7ef257@localhost> References: <043.648802f336c6762629e495848f7ef257@localhost> Message-ID: <052.413f324ee77c59234e80cb6d168f3b1f@localhost> #3481: Nightly snapshot fails to install -------------------------------+-------------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 04:49:20 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 04:28:23 2009 Subject: [GHC] #3495: make install DESTDIR= is failing in ghc HEAD In-Reply-To: <045.ff2a4187d5c3667cca724b5d7a71c326@localhost> References: <045.ff2a4187d5c3667cca724b5d7a71c326@localhost> Message-ID: <054.2e24d9320c10d2fb9f7d5d63ac1b8e89@localhost> #3495: make install DESTDIR= is failing in ghc HEAD ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 04:53:56 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 04:32:57 2009 Subject: [GHC] #3355: Refactor Template Haskell syntax conversions In-Reply-To: <047.1f46b8c5776cfa915775f27bfb2f30b5@localhost> References: <047.1f46b8c5776cfa915775f27bfb2f30b5@localhost> Message-ID: <056.0e33b155dd538d07974e29b374917c3b@localhost> #3355: Refactor Template Haskell syntax conversions ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Attached code from Haddock to convert !TyThing to !HsSyn (transformation "A" in [wiki:Commentary/Compiler/TemplateHaskell]). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 04:54:16 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 04:33:17 2009 Subject: [GHC] #3492: Add TyThing -> HsSyn translation code from Haddock In-Reply-To: <047.e4d10615cff08a633af39815aac077cd@localhost> References: <047.e4d10615cff08a633af39815aac077cd@localhost> Message-ID: <056.f23912ef6990b987b54104f7bd5801f2@localhost> #3492: Add TyThing -> HsSyn translation code from Haddock ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: see #3355 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 05:56:49 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 05:35:50 2009 Subject: [GHC] #3426: Misuse of SRC_HC_OPTS In-Reply-To: <044.fe3bb2fe382d4b2fb97083469558125d@localhost> References: <044.fe3bb2fe382d4b2fb97083469558125d@localhost> Message-ID: <053.ad43419584a34c70d11bd2baa00b39d6@localhost> #3426: Misuse of SRC_HC_OPTS ---------------------------------+------------------------------------------ Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 05:58:35 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 05:37:36 2009 Subject: [GHC] #3407: GHC.Prim documentation should mention GHC.Exts! In-Reply-To: <044.b2bcc86bcf34543dca950728f9a46ba1@localhost> References: <044.b2bcc86bcf34543dca950728f9a46ba1@localhost> Message-ID: <053.15d5ab95aeea9d21147d324a67fefa7f@localhost> #3407: GHC.Prim documentation should mention GHC.Exts! ---------------------------------+------------------------------------------ Reporter: RyanN | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Documentation | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: I've brought in the Haddock patches from Isaac Dupree's SoC project, which mostly fix the problems. I'm leaving #2337 open for now because we still have missing documentation for functions/types that were defined in a "hidden" module in a different package. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 08:52:44 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 08:31:46 2009 Subject: [GHC] #3498: IO library has no locale codec support on Windows Message-ID: <047.b785a95f081a328da553673bf1683b55@localhost> #3498: IO library has no locale codec support on Windows ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: 6.11 Severity: normal | Keywords: unicode Difficulty: Difficult (1 week) | Testcase: 2302, print021 Os: Windows | Architecture: Unknown/Multiple ---------------------------------+------------------------------------------ There is no support for the locale encoding (aka code page) on Windows in the new IO library. The main reason is that the `MultiByteToWideChar` API is insufficient to implement `BufferCodec`, because it doesn't do partial encodings (amongst other things). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 09:46:40 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 09:25:40 2009 Subject: [GHC] #3469: Error open file if name contain national symbol In-Reply-To: <044.8fe343c9395559f39f0fa1d947291b8a@localhost> References: <044.8fe343c9395559f39f0fa1d947291b8a@localhost> Message-ID: <053.56735191cb897fa34b32523731bcdb18@localhost> #3469: Error open file if name contain national symbol ---------------------------------+------------------------------------------ Reporter: Tonal | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: works with 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 10:50:39 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 10:29:39 2009 Subject: [GHC] #3408: idle GC causes large CPU usage if run more frequently than 1 second In-Reply-To: <049.48be2d13214f4104fb7093c0a3d0accb@localhost> References: <049.48be2d13214f4104fb7093c0a3d0accb@localhost> Message-ID: <058.38ca1889405080e1d4d33d28472a9e53@localhost> #3408: idle GC causes large CPU usage if run more frequently than 1 second ---------------------------------+------------------------------------------ Reporter: JeremyShaw | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: idle GC | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): I see the problem with GHCi 6.10.4+ on Windows. I think what is happening is this: * Haskeline is using `ReadConsoleInput` to wait for input * `ReadConsoleInput` returns non-key events * Windows is sending some non-key events every second or so * every 0.3 seconds of idle time, the RTS does another GC * setting -I large enough means that the RTS is never idle for long enough to trigger a GC I'm not sure what the best fix is. I'll make the default idle time longer for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 11:00:45 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 10:39:45 2009 Subject: [GHC] #2969: unix package built wrong on Solaris In-Reply-To: <045.0d30450289e14ebfae501919df8c4ac3@localhost> References: <045.0d30450289e14ebfae501919df8c4ac3@localhost> Message-ID: <054.4f40a79bf67acf44b2550126eb0098fe@localhost> #2969: unix package built wrong on Solaris -------------------------+-------------------------------------------------- Reporter: duncan | Owner: duncan Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Comment (by duncan): Seems to be working. I tested in ghc-6.10.4 which also includes the above patch. To make sure it keeps working on other ports it'd be good to add a trivial test of `getFileStatus` and `getSymbolicLinkStatus`. For example something along the lines of: {{{ import System.Posix.Files import System.Posix.Directory import System.Posix.IO import Control.Monad (when) main = do fs <- testRegular ds <- testDir testSymlink fs ds cleanup testRegular = do createFile "regular" ownerReadMode (fs, _) <- getStatus "regular" let expected = (False,False,False,True,False,False,False) actual = snd (statusElements fs) when (actual /= expected) $ fail "unexpected file ststus bits for regular file" return fs testDir = do createDirectory "dir" ownerReadMode (ds, _) <- getStatus "dir" let expected = (False,False,False,False,True,False,False) actual = snd (statusElements ds) when (actual /= expected) $ fail "unexpected file ststus bits for directory" return ds testSymlink fs ds = do createSymbolicLink "regular" "link-regular" createSymbolicLink "dir" "link-dir" (fs', ls) <- getStatus "link-regular" (ds', lds) <- getStatus "link-dir" let expected = (False,False,False,False,False,True,False) actualF = snd (statusElements ls) actualD = snd (statusElements lds) when (actualF /= expected) $ fail "unexpected file ststus bits for symlink to regular file" when (actualD /= expected) $ fail "unexpected file ststus bits for symlink to directory" when (statusElements fs /= statusElements fs') $ fail "status for a file does not match when it's accessed via a symlink" when (statusElements ds /= statusElements ds') $ fail "status for a directory does not match when it's accessed via a symlink" cleanup = do removeDirectory "dir" mapM_ removeLink ["regular", "link-regular", "link-dir"] getStatus f = do fs <- getFileStatus f ls <- getSymbolicLinkStatus f fd <- openFd f ReadOnly Nothing defaultFileFlags fs' <- getFdStatus fd when (statusElements fs /= statusElements fs') $ fail "getFileStatus and getFdStatus give inconsistent results" when (not (isSymbolicLink ls) && statusElements fs /= statusElements fs') $ fail $ "getFileStatus and getSymbolicLinkStatus give inconsistent results " ++ "on a file that is not a symbolic link" return (fs, ls) -- Yay for 17-element tuples! statusElements fs = (,) (deviceID fs ,fileMode fs ,linkCount fs ,fileOwner fs ,fileGroup fs ,specialDeviceID fs ,fileSize fs ,accessTime fs ,modificationTime fs ,statusChangeTime fs ) (isBlockDevice fs ,isCharacterDevice fs ,isNamedPipe fs ,isRegularFile fs ,isDirectory fs ,isSymbolicLink fs ,isSocket fs ) }}} This test works on Linux and Solaris with ghc-6.10.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 11:28:56 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 11:07:54 2009 Subject: [GHC] #2969: unix package built wrong on Solaris In-Reply-To: <045.0d30450289e14ebfae501919df8c4ac3@localhost> References: <045.0d30450289e14ebfae501919df8c4ac3@localhost> Message-ID: <054.20f7c3b095771d47803e7bb40cf76b7c@localhost> #2969: unix package built wrong on Solaris -------------------------+-------------------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Changes (by igloo): * owner: duncan => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 17:27:42 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 17:07:45 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.cb726aa50c4c22025dc057bf4d86e5ac@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by adamd): * cc: adam@duracz.net (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 20:42:52 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 20:22:47 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.3aa1830cddb962a2d3dfc3f43066c3f1@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by sudish): * cc: sudish@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 9 21:02:20 2009 From: trac at galois.com (GHC) Date: Wed Sep 9 20:42:09 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.79baebd236f26ecbc624021bad8d5f1c@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by christosc): * cc: c.chryssochoidis@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 04:47:16 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 04:26:17 2009 Subject: [GHC] #3499: darcs-all + MSYS manges the repo path Message-ID: <046.acad91d38902d0416237be247629dfe3@localhost> #3499: darcs-all + MSYS manges the repo path -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- In my defaultrepo I have an ssh path: `simonpj@darcs.haskell.org:/home/darcs/ghc`. (You may say I should use http, but it should work.) It used to work fine, including with `darcs-all`. But since these two patches {{{ Thu Aug 27 15:15:54 BST 2009 Simon Marlow * fix 'darcs-all rec' (amongst other things) Thu Aug 27 14:57:17 BST 2009 Simon Marlow * REDO: Add -r option to darcs-all, and remove push-all (#3375) }}} `darcs-all` fails badly on MSYS. What happens is that it tries to fetch from {{{ simonpj@darcs.haskell.org:c:\\msys\\1.0\\usr\\home\\darcs\\ghc }}} or something like that. Somehow the MSYS path mangling has got hold of the path, whereas it did not do so before. Happily, if I use an HTTP path `http://darcs.haskell.org/ghc` in my defaultrepo, all is well. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 04:57:27 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 04:36:28 2009 Subject: [GHC] #3500: Type functions and recursive dictionaries Message-ID: <046.2ed13f414fdea0237fa434043b777b31@localhost> #3500: Type functions and recursive dictionaries -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Stefan Holdermans reports: I've spotted a hopefully small but for us quite annoying bug in GHC's type checker: it loops when overloading resolving involves a circular constraint graph containing type-family applications. The following program demonstrates the problem: {{{ {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} type family F a :: * type instance F Int = (Int, ()) class C a instance C () instance (C (F a), C b) => C (a, b) f :: C (F a) => a -> Int f _ = 2 main :: IO () main = print (f (3 :: Int)) }}} My guess is that the loop is caused by the constraint `C (F Int)` that arises from the use of f in main: {{{ C (F Int) = C (Int, ()) <= C (F Int) }}} Indeed, overloading can be resolved successfully by "black-holing" the initial constraint, but it seems like the type checker refuses to do so. Can you confirm my findings? Since this problem arises in a piece of very mission-critical code, I would be pleased to learn about any workarounds. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 04:58:23 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 04:37:22 2009 Subject: [GHC] #3500: Type functions and recursive dictionaries In-Reply-To: <046.2ed13f414fdea0237fa434043b777b31@localhost> References: <046.2ed13f414fdea0237fa434043b777b31@localhost> Message-ID: <055.5c5b70629c782b723bbcfff26af5ee4d@localhost> #3500: Type functions and recursive dictionaries ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): You are trying to do something quite delicate here. The whole idea of solving constraints in a co-inductive way (building a recursive group of dictionary definitions) relies on spotting something we've seen before to "tie the knot". To date, the main application I knew for this fairly exotic idea was described in the SYB3 paper [1]. So I'm curious about your application (and that of anyone else) that relies on this recursive-dictionary-solving mechanism. Returning to your problem, this "loop spotting" mechanism is rather syntactic at the moment, whereas your application needs something more refined, involving equality modulo type function reductions. Alas, the constraint solving machinery for type classes and for type functions is not properly integrated. I'm amazed it works as well as it does, actually. We [Manuel, Dimitrios, and I] are (slowly, slowly) working on a complete rewrite of GHC's constraint-solving mechanism. I'm pretty sure that it'll solve this problem among many others. But don't hold your breath. It'll be months not weeks. But not years! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 05:05:15 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 04:44:12 2009 Subject: [GHC] #3501: Error thunks not being exposed with "B" strictness Message-ID: <046.49531cf39daa16853f84bad209d9cc5b@localhost> #3501: Error thunks not being exposed with "B" strictness ---------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------------+------------------------------------ At the moment GHC often floats `error "urk"` to the top level (which it should), after the strictness analyser. But since it's ''after'' strictness analysis, the exported thing doesn't have a strictness signature saying "I am a diverging term", which in turn loses useful optimisations in importing modules. An example is test T3286. If you compile it with `-O --ddump-simpl`, you'll see stuff like {{{ case T3286b.$fFractionalLogFloat3 `cast` (CoUnsafe T3286b.LogFloat GHC.Prim.Double# :: T3286b.LogFloat ~ GHC.Prim.Double#) of ww2_aGk { __DEFAULT -> (GHC.Types.D# ww2_aGk) `cast` (sym T3286b.NTCo:LogFloat :: GHC.Types.Double ~ T3286b.LogFloat) }}} But if you look at `T3286b.$fFractionalLogFloat3`, it turns out to be bottom, so the case should be eliminated. This is a long-standing infelicity; I'm making a ticket so I don't forget it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 05:07:48 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 04:46:46 2009 Subject: [GHC] #3451: HsFFI.h import doesn't work as installed In-Reply-To: <044.96cd9f1ba1f8fbdefd0037f9ec6aeee0@localhost> References: <044.96cd9f1ba1f8fbdefd0037f9ec6aeee0@localhost> Message-ID: <053.8c3b0fa411d737575910cf2d247ef911@localhost> #3451: HsFFI.h import doesn't work as installed -------------------------------+-------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => simonmar Comment: I'm looking at installing header files. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 05:37:33 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 05:16:34 2009 Subject: [GHC] #711: shutdownHaskell() does not return allocated memory on Unix In-Reply-To: <075.111d4b2a7cd4bd954079dae4e1641cbc@localhost> References: <075.111d4b2a7cd4bd954079dae4e1641cbc@localhost> Message-ID: <084.3a80132d41088a2b177e24a1de0c859d@localhost> #711: shutdownHaskell() does not return allocated memory on Unix -----------------------------------------------------+---------------------- Reporter: lennart.augustsson@credit-suisse.com | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.5 Severity: minor | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------------------+---------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Applied, thanks! {{{ Thu Sep 10 01:46:30 PDT 2009 Austin Seipp * FIX #711 implement osFreeAllMBlocks for unix }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 06:11:40 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 05:50:49 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.2d5bca9705625e863311f1f7f53514b6@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: Repeating the program, to get the markup right: {{{ module Main where import System import System.IO import System.Process import System.Directory import Control.Monad import Data.List import Control.Concurrent tempFile = "mytempfile.txt" run :: FilePath -> IO String run exe = do h <- openFile tempFile WriteMode pid <- runProcess exe [] Nothing Nothing Nothing (Just h) Nothing exitCode <- waitForProcess pid hClose h if exitCode /= ExitSuccess then error $ exe ++ " failed" else readFile tempFile main = replicateM_ 10 $ run "ls" }}} The program does indeed fail with `openFile: permission denied`, but it's not a problem with `runProcess`. In the `else` branch of the `if` you have a `readFile` which opens a lazy stream to read `tempfile`, and then the next iteration attempts to open the file for writing. It's illegal to have the same file open for both reading and writing, hence the error. Unfortunately neither myself nor Duncan Coutts spotted the problem immediately, because we were looking in the wrong place. `readFile` considered harmful, IMO! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 06:32:17 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 06:11:23 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.df02c5d339b8bd3b031db8a3e0d7888c@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by yugr): Fine but can I fix my code? I tried to use readFile $! tempFile (strict application) but it did not work... I think the task I want to solve here is rather general and needs solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 08:12:17 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 07:51:36 2009 Subject: [GHC] #593: Cache contents of package.conf in a binary file In-Reply-To: <047.a99c9d8473c0ecc64f8f3c14938451e0@localhost> References: <047.a99c9d8473c0ecc64f8f3c14938451e0@localhost> Message-ID: <056.3794f24c8fad491ec7de5ab5638d4852@localhost> #593: Cache contents of package.conf in a binary file ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: 6.12 branch Component: Package system | Version: 6.4.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed {{{ Thu Sep 10 03:27:03 PDT 2009 Simon Marlow * Change the representation of the package database - the package DB is a directory containing one file per package instance (#723) - there is a binary cache of the database (#593, #2089) - the binary package is now a boot package - there is a new package, bin-package-db, containing the Binary instance of InstalledPackageInfo for the binary cache. Also included in this patch - Use colour in 'ghc-pkg list' to indicate broken or hidden packages Broken packages are red, hidden packages are Colour support comes from the terminfo package, and is only used when - not --simple-output - stdout is a TTY - the terminal type has colour capability - Fix the bug that 'ghc-pkg list --user' shows everything as broken }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 08:10:40 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 07:51:54 2009 Subject: [GHC] #723: The package database should be a directory of files instead of a single file In-Reply-To: <047.d48131452f0eeb3c3d5c7fbcab422732@localhost> References: <047.d48131452f0eeb3c3d5c7fbcab422732@localhost> Message-ID: <056.be6fb524d4631be30a9a27297be3ab06@localhost> #723: The package database should be a directory of files instead of a single file ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: closed Priority: normal | Milestone: 6.12 branch Component: Package system | Version: 6.4.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: The package DB is now a directory of files by default (the old text-file format is still supported). {{{ Thu Sep 10 03:27:03 PDT 2009 Simon Marlow * Change the representation of the package database Ignore-this: 7c9b38ded7f753d5bb95743695700dbc - the package DB is a directory containing one file per package instance (#723) - there is a binary cache of the database (#593, #2089) - the binary package is now a boot package - there is a new package, bin-package-db, containing the Binary instance of InstalledPackageInfo for the binary cache. Also included in this patch - Use colour in 'ghc-pkg list' to indicate broken or hidden packages Broken packages are red, hidden packages are Colour support comes from the terminfo package, and is only used when - not --simple-output - stdout is a TTY - the terminal type has colour capability - Fix the bug that 'ghc-pkg list --user' shows everything as broken }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 08:14:02 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 07:52:59 2009 Subject: [GHC] #2089: reading the package db is slow In-Reply-To: <045.d775bdf76041d9776497ac4f6a221252@localhost> References: <045.d775bdf76041d9776497ac4f6a221252@localhost> Message-ID: <054.02e9e7ca76b43b76dc234d9ef7425434@localhost> #2089: reading the package db is slow ---------------------------------------------+------------------------------ Reporter: duncan | Owner: Type: compile-time performance bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Package system | Version: 6.8.2 Severity: minor | Resolution: fixed Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | ---------------------------------------------+------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed. Reading the package DB is several times quicker for me now. {{{ Thu Sep 10 03:27:03 PDT 2009 Simon Marlow * Change the representation of the package database - the package DB is a directory containing one file per package instance (#723) - there is a binary cache of the database (#593, #2089) - the binary package is now a boot package - there is a new package, bin-package-db, containing the Binary instance of InstalledPackageInfo for the binary cache. Also included in this patch - Use colour in 'ghc-pkg list' to indicate broken or hidden packages Broken packages are red, hidden packages are Colour support comes from the terminfo package, and is only used when - not --simple-output - stdout is a TTY - the terminal type has colour capability - Fix the bug that 'ghc-pkg list --user' shows everything as broken }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 08:54:06 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 08:33:14 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.41e25331ca7af92a30a0d683118a9efe@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by NeilMitchell): There are many solutions - a really simple one is to use http://hackage.haskell.org/packages/archive/bytestring/0.9.1.4/doc/html /Data-ByteString.html#v%3AreadFile That will read the file strictly, so you won't have a problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 08:56:05 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 08:35:09 2009 Subject: [GHC] #3502: GC leaks memory under -threaded Message-ID: <051.ec5dd029b60a429f785b70d51903ca73@localhost> #3502: GC leaks memory under -threaded -------------------------+-------------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.4 | Severity: critical Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple -------------------------+-------------------------------------------------- The following program leaks 2Mb/s under Windows: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.4 $ cat Test.hs import System.Mem import Control.Monad main = forever performGC $ ghc --make Test.hs -threaded $ Test.exe }}} This leak does not occur if you remove the {{{-threaded}}}, or if you run the same test on Linux. I am using {{{forever}}} to leak memory more quickly, but I believe the same issues will arise if {{{performGC}}} is called in the normal course of a program. I consider this leak to be critical, so have marked severity appropriately. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 15:24:25 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 15:03:24 2009 Subject: [GHC] #3503: Add __attribute__((constructor))-equivalent pragma Message-ID: <046.d3319a3d44a7c3235940f61a366ea149@localhost> #3503: Add __attribute__((constructor))-equivalent pragma -----------------------------+---------------------------------------------- Reporter: pumpkin | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- It would be nice to let one's library perform initialization tasks at load time. Then the integer-gmp allocation functions could be changed from within haskell and various other FFI libraries would be easier to bind to. As for syntax, maybe something like the following would work? {-# CONSTRUCTOR f #-} f :: IO () f = ... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 16:28:23 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 16:07:30 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.3e30cd774062ade5b633979485447ee3@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [comment:28 yugr]: > Fine but can I fix my code? I tried to use readFile $! tempFile (strict application) but it did not work... The point is readFile opens the file but does not read the content until you consume the String. The solution is either to 1) consume all the data, 2) use System.IO.withFile, or as Neil suggests, 3) to read the whole file into memory up front. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 16:30:27 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 16:09:24 2009 Subject: [GHC] #3503: Add __attribute__((constructor))-equivalent pragma In-Reply-To: <046.d3319a3d44a7c3235940f61a366ea149@localhost> References: <046.d3319a3d44a7c3235940f61a366ea149@localhost> Message-ID: <055.22f2b60b8d0215cd9fb01b682d082012@localhost> #3503: Add __attribute__((constructor))-equivalent pragma ------------------------------+--------------------------------------------- Reporter: pumpkin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by duncan): This is like the top level (safe) IO and top level reference proposals and is generally quite controversial. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 16:45:30 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 16:24:26 2009 Subject: [GHC] #3486: Data.ByteString.elemIndices causes SEGV In-Reply-To: <042.edd017489a67f7a628a8510b09ab86e5@localhost> References: <042.edd017489a67f7a628a8510b09ab86e5@localhost> Message-ID: <051.aa6b8cafe8bc6a1922ffa6f89ac7efc9@localhost> #3486: Data.ByteString.elemIndices causes SEGV -------------------------------+-------------------------------------------- Reporter: nwn | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.12.1 Comment: Thanks for the report. I'll try to reproduce this with 6.10.4 and the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 16:45:37 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 16:24:33 2009 Subject: [GHC] #3487: Data.ByteString.Lazy.elemIndices returns wrong results In-Reply-To: <042.4f1103cc60c42d21bbc9fb56583d59f1@localhost> References: <042.4f1103cc60c42d21bbc9fb56583d59f1@localhost> Message-ID: <051.c02f8fe0bf2a741a75c28643f196c792@localhost> #3487: Data.ByteString.Lazy.elemIndices returns wrong results -------------------------------+-------------------------------------------- Reporter: nwn | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * owner: => igloo * difficulty: => Unknown * milestone: => 6.12.1 Comment: Thanks for the report. I'll try to reproduce this with 6.10.4 and the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 10 20:23:57 2009 From: trac at galois.com (GHC) Date: Thu Sep 10 20:02:51 2009 Subject: [GHC] #3504: GHC panicks with a huge list in source code Message-ID: <044.348c0692fa710b5e5db91c0f801f026b@localhost> #3504: GHC panicks with a huge list in source code -------------------+-------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- Not sure if this is of any consequence, but I decided to generate some data as Haskell code direct, instead of loading it with 'properly', for test purposes. Removing some 50-80 lines from the file will result in ghc compiling it properly. [1 of 1] Compiling Main ( testdata.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for x86_64-unknown-linux): linkBCO: >= 64k insns in BCO -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 06:36:09 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 06:15:04 2009 Subject: [GHC] #3320: Parallel program crashes using GHC 6.11 under OS X In-Reply-To: <043.9852f1b0e0c1c860f254ba4ef6d4265e@localhost> References: <043.9852f1b0e0c1c860f254ba4ef6d4265e@localhost> Message-ID: <052.75eea45350e76b6992b5259948a9be47@localhost> #3320: Parallel program crashes using GHC 6.11 under OS X -------------------------------+-------------------------------------------- Reporter: sebf | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Thu Sep 10 08:16:23 PDT 2009 Simon Marlow * Fix #3320: we forgot to save/restore the GC register variable }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 06:41:26 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 06:20:22 2009 Subject: [GHC] #3467: GHC HEAD panics trying to splice a type In-Reply-To: <044.3bb6c981732c0f783366c3cd6fcdc2a5@localhost> References: <044.3bb6c981732c0f783366c3cd6fcdc2a5@localhost> Message-ID: <053.d58814bbc167aa4eccc63431958244ee@localhost> #3467: GHC HEAD panics trying to splice a type ---------------------------------+------------------------------------------ Reporter: awson | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: th/T3467 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * testcase: => th/T3467 * difficulty: => Unknown * status: new => closed * resolution: => fixed Comment: Excellent point, thank you for the report. It appears that when I added the ability to splice types in TH programs, I failed to pay attention to non-top-level splices -- that is, splices inside quotatation brackets. Fixed in HEAD, and hence in 6.12. I took the opportunity to do other stuff too. {{{ Thu Sep 10 13:58:48 BST 2009 simonpj@microsoft.com * Three improvements to Template Haskell (fixes #3467) This patch implements three significant improvements to Template Haskell. Declaration-level splices with no "$" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This change simply allows you to omit the "$(...)" wrapper for declaration-level TH splices. An expression all by itself is not legal, so we now treat it as a TH splice. Thus you can now say data T = T1 | T2 deriveMyStuff ''T where deriveMyStuff :: Name -> Q [Dec] This makes a much nicer interface for clients of libraries that use TH: no scary $(deriveMyStuff ''T). Nested top-level splices ~~~~~~~~~~~~~~~~~~~~~~~~ Previously TH would reject this, saying that splices cannot be nested: f x = $(g $(h 'x)) But there is no reason for this not to work. First $(h 'x) is run, yielding code that is spliced instead of the $(h 'x). Then (g ) is typechecked and run, yielding code that replaces the $(g ...) splice. So this simply lifts the restriction. Fix Trac #3467: non-top-level type splices ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It appears that when I added the ability to splice types in TH programs, I failed to pay attention to non-top-level splices -- that is, splices inside quotatation brackets. This patch fixes the problem. I had to modify HsType, so there's a knock-on change to Haddock. Its seems that a lot of lines of code has changed, but almost all the new lines are comments! General tidying up ~~~~~~~~~~~~~~~~~~ As a result of thinking all this out I re-jigged the data type ThStage, which had far too many values before. And I wrote a nice state transition diagram to make it all precise; see Note [Template Haskell state diagram] in TcSplice Lots more refactoring in TcSplice, resulting in significantly less code. (A few more lines, but actually less code -- the rest is comments.) I think the result is significantly cleaner. M ./compiler/deSugar/DsMeta.hs -44 +54 M ./compiler/hsSyn/HsTypes.lhs -11 +15 M ./compiler/parser/Lexer.x -1 +1 M ./compiler/parser/Parser.y.pp -8 +8 M ./compiler/parser/RdrHsSyn.lhs -2 +17 M ./compiler/rename/RnHsSyn.lhs -1 +2 M ./compiler/rename/RnTypes.lhs +2 M ./compiler/typecheck/Inst.lhs -1 +1 M ./compiler/typecheck/TcEnv.lhs -33 +7 M ./compiler/typecheck/TcExpr.lhs -18 +30 M ./compiler/typecheck/TcHsType.lhs -3 +9 M ./compiler/typecheck/TcRnTypes.lhs -17 +35 M ./compiler/typecheck/TcSimplify.lhs -21 M ./compiler/typecheck/TcSplice.lhs -191 +276 M ./docs/users_guide/glasgow_exts.xml -5 +23 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 06:46:31 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 06:25:26 2009 Subject: [GHC] #3479: Build from source fails with variables passed to configure In-Reply-To: <044.9b3cb4d5f450e5790f2e39cb68bcc8bf@localhost> References: <044.9b3cb4d5f450e5790f2e39cb68bcc8bf@localhost> Message-ID: <053.09187bc23503140429a11a3f8e128f34@localhost> #3479: Build from source fails with variables passed to configure ---------------------------------+------------------------------------------ Reporter: atler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Old description: > I'm trying to bootstrap ghc compiler with downloaded ghc binary > distribution (6.10.4). Passing some variables to ./configure for example: > > ./configure LDFLAGS="-Wl,--as-needed -Wl,-z,relro -Wl,-z,combreloc" > CFLAGS="-O2 -fno-strict-aliasing -fwrapv -march=i686" ... > > results in running configure scripts in libraries with incorrect options: > > (for base library) > > configure --with- > compiler=/home/users/atler/rpm/BUILD/ghc-6.10.4/ghc/stage1-inplace/ghc > --with-hc-pkg=/home/users/atler/rpm/BUILD/ghc-6.10.4/utils/ghc-pkg > /install-inplace/bin/ghc-pkg --prefix=/NONEXISTENT --bindir=/NONEXISTENT > --libdir=/NONEXISTENT --libexecdir=/NONEXISTENT --datadir=/NONEXISTENT > LDFLAGS=-Wl,--as-needed -Wl,-z,relro -Wl,-z,combreloc --configure- > option= CFLAGS=-O2 -fno-strict-aliasing -fwrapv -march=i686 ... > > Notice that --configure-option (added in mk/cabal-flags.mk) was not > stripped for CFLAGS, actually it's stripped only for the first variable. > This further results in passing --configure-option to gcc when testing > gcc usability which obviously fails. Another interesting part is though > compilation of base fails, compilation process still continues and ends > with some mysterious error about not met dependecies. New description: I'm trying to bootstrap ghc compiler with downloaded ghc binary distribution (6.10.4). Passing some variables to ./configure for example: {{{ ./configure LDFLAGS="-Wl,--as-needed -Wl,-z,relro -Wl,-z,combreloc" CFLAGS="-O2 -fno-strict-aliasing -fwrapv -march=i686" ... }}} results in running configure scripts in libraries with incorrect options: (for base library) {{{ configure --with- compiler=/home/users/atler/rpm/BUILD/ghc-6.10.4/ghc/stage1-inplace/ghc --with-hc-pkg=/home/users/atler/rpm/BUILD/ghc-6.10.4/utils/ghc-pkg /install-inplace/bin/ghc-pkg --prefix=/NONEXISTENT --bindir=/NONEXISTENT --libdir=/NONEXISTENT --libexecdir=/NONEXISTENT --datadir=/NONEXISTENT LDFLAGS=-Wl,--as-needed -Wl,-z,relro -Wl,-z,combreloc --configure-option= CFLAGS=-O2 -fno-strict-aliasing -fwrapv -march=i686 ... }}} Notice that --configure-option (added in mk/cabal-flags.mk) was not stripped for CFLAGS, actually it's stripped only for the first variable. This further results in passing --configure-option to gcc when testing gcc usability which obviously fails. Another interesting part is though compilation of base fails, compilation process still continues and ends with some mysterious error about not met dependecies. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 06:55:30 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 06:34:34 2009 Subject: [GHC] #3502: GC leaks memory under -threaded In-Reply-To: <051.ec5dd029b60a429f785b70d51903ca73@localhost> References: <051.ec5dd029b60a429f785b70d51903ca73@localhost> Message-ID: <060.2f81ffe2244211277c5f103837e00cc0@localhost> #3502: GC leaks memory under -threaded ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 Comment: Fairly sure this one is fixed, see * [http://www.haskell.org/pipermail/haskell-cafe/2009-July/064592.html] but I'll check for 6.12.1 anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 07:16:05 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 06:54:59 2009 Subject: [GHC] #3426: Misuse of SRC_HC_OPTS In-Reply-To: <044.fe3bb2fe382d4b2fb97083469558125d@localhost> References: <044.fe3bb2fe382d4b2fb97083469558125d@localhost> Message-ID: <053.0022acf53173fde69064a65224cf89ef@localhost> #3426: Misuse of SRC_HC_OPTS ---------------------------------+------------------------------------------ Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed {{{ Tue Sep 8 08:19:08 PDT 2009 Simon Marlow * add $(CONF_*_OPTS) for options that come from ./configure (fixes #3426) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 07:18:23 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 06:57:17 2009 Subject: [GHC] #3451: HsFFI.h import doesn't work as installed In-Reply-To: <044.96cd9f1ba1f8fbdefd0037f9ec6aeee0@localhost> References: <044.96cd9f1ba1f8fbdefd0037f9ec6aeee0@localhost> Message-ID: <053.7246b2ad187201b3eb8a5b6e1bd9028f@localhost> #3451: HsFFI.h import doesn't work as installed -------------------------------+-------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by simonmar): Fixed {{{ Thu Sep 10 05:18:31 PDT 2009 Simon Marlow * fix installation of header files (#3451) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 07:24:45 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 07:03:39 2009 Subject: [GHC] #3495: make install DESTDIR= is failing in ghc HEAD In-Reply-To: <045.ff2a4187d5c3667cca724b5d7a71c326@localhost> References: <045.ff2a4187d5c3667cca724b5d7a71c326@localhost> Message-ID: <054.b83c7c9969efa3763589dc4a69d2969f@localhost> #3495: make install DESTDIR= is failing in ghc HEAD ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: major | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: This is working for me now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 08:26:18 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 08:05:15 2009 Subject: [GHC] #2790: Use -fregs-graph by default In-Reply-To: <044.e23cb1a138a9b4ed2c315b0444e4b3fc@localhost> References: <044.e23cb1a138a9b4ed2c315b0444e4b3fc@localhost> Message-ID: <053.a58bca5e050b03eeff7e37678450c34b@localhost> #2790: Use -fregs-graph by default ---------------------------------+------------------------------------------ Reporter: igloo | Owner: benl Type: task | Status: assigned Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by Roel van Dijk): I'll comment on this ticket since all related tickets refer to this one. When building the [http://hackage.haskell.org/package/encoding-0.6.2 encoding-0.6.2] package with library profiling enabled GHC panics on the rather large (1010547 bytes) file [http://hackage.haskell.org/packages/archive/encoding/0.6.2/doc/html/Data- Encoding-GB18030.html Data.Encoding.GB18030] which is a Chinese character encoding. GHC panics with both the linear allocator and the graph colouring one. With linear allocator: {{{ [40 of 65] Compiling Data.Encoding.GB18030 ( dist/build/Data/Encoding/GB18030.hs, dist/build/Data/Encoding/GB18030.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph }}} With register graph colouring: {{{ [40 of 65] Compiling Data.Encoding.GB18030 ( dist/build/Data/Encoding/GB18030.hs, dist/build/Data/Encoding/GB18030.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): regSpill: out of spill slots! regs to spill = 800 slots left = 677 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 08:31:58 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 08:10:52 2009 Subject: [GHC] #3488: Impossible happened: RegAllocLinear.getStackSlotFor: out of stack slots In-Reply-To: <042.efd3a6588858af62ce043efa2d483c4a@localhost> References: <042.efd3a6588858af62ce043efa2d483c4a@localhost> Message-ID: <051.0db3f74499c1eb9bd9494450d1473459@localhost> #3488: Impossible happened: RegAllocLinear.getStackSlotFor: out of stack slots ------------------------------+--------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by Roel van Dijk): See also #2790 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 09:38:27 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 09:17:21 2009 Subject: [GHC] #3410: ghc fails to parse versioned GPL and LGPL license from package configuration In-Reply-To: <044.39d94639879dc1489fb7d2f72ceb71d0@localhost> References: <044.39d94639879dc1489fb7d2f72ceb71d0@localhost> Message-ID: <053.0fcd4bc7ec339ea01d7026ed90cad4e8@localhost> #3410: ghc fails to parse versioned GPL and LGPL license from package configuration ---------------------------------+------------------------------------------ Reporter: int-e | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Fixed {{{ Fri Sep 11 04:49:28 PDT 2009 Simon Marlow * Remove the old package.conf parser, use read instead (fixed #3410) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 09:53:37 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 09:32:32 2009 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.ccd733176358fb59c72d411eea49036a@localhost> #2337: Data.Array documentation utterly broken ---------------------------------+------------------------------------------ Reporter: japple | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Documentation | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Now fixed, mainly thanks to isaacdupree's SoC patches, and also thanks to David's subsequent fixes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 09:55:33 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 09:34:26 2009 Subject: [GHC] #3410: ghc fails to parse versioned GPL and LGPL license from package configuration In-Reply-To: <044.39d94639879dc1489fb7d2f72ceb71d0@localhost> References: <044.39d94639879dc1489fb7d2f72ceb71d0@localhost> Message-ID: <053.36c1440149927f5135bbeb36be76f577@localhost> #3410: ghc fails to parse versioned GPL and LGPL license from package configuration ---------------------------------+------------------------------------------ Reporter: int-e | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 09:55:56 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 09:34:51 2009 Subject: [GHC] #3451: HsFFI.h import doesn't work as installed In-Reply-To: <044.96cd9f1ba1f8fbdefd0037f9ec6aeee0@localhost> References: <044.96cd9f1ba1f8fbdefd0037f9ec6aeee0@localhost> Message-ID: <053.bc87cdac13787e535271ab71f1da7772@localhost> #3451: HsFFI.h import doesn't work as installed -------------------------------+-------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 09:58:24 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 09:37:27 2009 Subject: [GHC] #3502: GC leaks memory under -threaded In-Reply-To: <051.ec5dd029b60a429f785b70d51903ca73@localhost> References: <051.ec5dd029b60a429f785b70d51903ca73@localhost> Message-ID: <060.93ab48a1d3c63149017cf63bc907fcea@localhost> #3502: GC leaks memory under -threaded ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: critical | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Tested; it's flat now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 10:21:39 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 10:00:34 2009 Subject: [GHC] #3425: compileToCoreModule: ghc: panic! (the 'impossible' happened) In-Reply-To: <043.832f4b8a68b35787dd3f11dce0ad982a@localhost> References: <043.832f4b8a68b35787dd3f11dce0ad982a@localhost> Message-ID: <052.7b9728084fa1f25407cf25fd861813e9@localhost> #3425: compileToCoreModule: ghc: panic! (the 'impossible' happened) -------------------------------+-------------------------------------------- Reporter: iago | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: GHC API | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => invalid Comment: This is not a bug: you have to perform a little set up before you can use the GHC API. See [http://www.haskell.org/haskellwiki/GHC/As_a_library] for more information. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 10:24:11 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 10:03:04 2009 Subject: [GHC] #3334: Strange closure type error on macports GHC 6.10.1 In-Reply-To: <047.f82e382278d17b45a86383d3a24d0c2d@localhost> References: <047.f82e382278d17b45a86383d3a24d0c2d@localhost> Message-ID: <056.190053bf111ddd0d83641c64e9caaa8b@localhost> #3334: Strange closure type error on macports GHC 6.10.1 ---------------------------------+------------------------------------------ Reporter: crutcher | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => worksforme Comment: Over 2 months without a reply; assuming this is now fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 10:24:50 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 10:03:44 2009 Subject: [GHC] #3504: GHC panicks with a huge list in source code In-Reply-To: <044.348c0692fa710b5e5db91c0f801f026b@localhost> References: <044.348c0692fa710b5e5db91c0f801f026b@localhost> Message-ID: <053.eb002032daf2905c74107aec47b0e118@localhost> #3504: GHC panicks with a huge list in source code -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. This is a duplicate of #789, and is fixed in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 11:28:21 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 11:07:15 2009 Subject: [GHC] #3479: Build from source fails with variables passed to configure In-Reply-To: <044.9b3cb4d5f450e5790f2e39cb68bcc8bf@localhost> References: <044.9b3cb4d5f450e5790f2e39cb68bcc8bf@localhost> Message-ID: <053.af1b14f9aa387873f3808049870fbf26@localhost> #3479: Build from source fails with variables passed to configure ---------------------------------+------------------------------------------ Reporter: atler | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I've just tried this in a build of the HEAD, and I can't reproduce the problem, so I think this has already been fixed by the new build system. Please reopen this ticket if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 14:24:15 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 14:03:11 2009 Subject: [GHC] #3505: type mismatch error message with operator sections counts the arguments incorrectly Message-ID: <049.b0dca9b9c9ba59c25cb61ac760d64c4f@localhost> #3505: type mismatch error message with operator sections counts the arguments incorrectly -----------------------------+---------------------------------------------- Reporter: benmachine | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- It seems that when an operator section gets a Couldn't match... error, then the message regards the argument given as the second, even where it appears before the operator. A quick test case is: {{{ ghci> ('c' >>=) :1:1: Couldn't match expected type `m a' against inferred type `Char' In the second argument of `(>>=)', namely 'c' In the expression: ('c' >>=) In the definition of `it': it = ('c' >>=) }}} It seems to say "second argument" regardless of whether the argument appears before or after the operator. This happens on 6.10.4 and 6.11.20090911, but it doesn't seem to happen with 6.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 14:28:13 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 14:07:10 2009 Subject: [GHC] #3475: bump base version to 5, add base4-compat In-Reply-To: <047.4e76c774049ade104ab88a36737a01ed@localhost> References: <047.4e76c774049ade104ab88a36737a01ed@localhost> Message-ID: <056.82a2e6762427a013e41e3b4b12e6457c@localhost> #3475: bump base version to 5, add base4-compat ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: We talked about this briefly at ICFP, and we don't think there's a major change (like the Exceptions change between 3.* and 4.*) that warrants a bump to 5.*. I've therefore bumped the version to 4.2, and I don't think a compat library is worthwhile. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 14:28:55 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 14:07:50 2009 Subject: [GHC] #3505: type mismatch error message with operator sections counts the arguments incorrectly In-Reply-To: <049.b0dca9b9c9ba59c25cb61ac760d64c4f@localhost> References: <049.b0dca9b9c9ba59c25cb61ac760d64c4f@localhost> Message-ID: <058.63ac1f3ac62e43baef381ce005294f28@localhost> #3505: type mismatch error message with operator sections counts the arguments incorrectly ------------------------------+--------------------------------------------- Reporter: benmachine | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by benmachine): * cc: haskell@benmachine.co.uk (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 14:57:33 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 14:36:27 2009 Subject: [GHC] #3084: alow macros to redefine builtin GHCi commands In-Reply-To: <046.7f055f7e30420d89efe3f2db433a2d00@localhost> References: <046.7f055f7e30420d89efe3f2db433a2d00@localhost> Message-ID: <055.0b9af977eb3e4e243135532c4a9dc919@localhost> #3084: alow macros to redefine builtin GHCi commands ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 14:58:55 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 14:37:49 2009 Subject: [GHC] #3434: improve vi tags (add non-exported symbols, add tag kinds, add regex tags) In-Reply-To: <046.d2dbc3c59e7dd2597dcfc9a0bd98987b@localhost> References: <046.d2dbc3c59e7dd2597dcfc9a0bd98987b@localhost> Message-ID: <055.2460f1bc0bfd00a247406f0d5f325b4d@localhost> #3434: improve vi tags (add non-exported symbols, add tag kinds, add regex tags) ---------------------------------+------------------------------------------ Reporter: phercek | Owner: simonmar Type: feature request | Status: new Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: vim tags ctags | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * owner: => simonmar * milestone: 6.14.1 => 6.12.1 Comment: Assigning to Simon, as he said "If the patch goes in, I can do a quick test of :etags under emacs.". -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 17:56:54 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 17:35:47 2009 Subject: [GHC] #3465: Documentation for init in Prelude requires finite list In-Reply-To: <048.db8d722eaa5d04793b887d720d3f40fc@localhost> References: <048.db8d722eaa5d04793b887d720d3f40fc@localhost> Message-ID: <057.0b33966601609a97b96677ec780573ca@localhost> #3465: Documentation for init in Prelude requires finite list ---------------------------------+------------------------------------------ Reporter: MaxRabkin | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report; I've fixed the docs in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 18:05:12 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 17:44:05 2009 Subject: [GHC] #3466: broken link in "ghc --help" In-Reply-To: <044.fed7374cf357455fd732384b04324661@localhost> References: <044.fed7374cf357455fd732384b04324661@localhost> Message-ID: <053.dd86cf5dbd04b9c9d0bfabc80148970e@localhost> #3466: broken link in "ghc --help" ---------------------------------+------------------------------------------ Reporter: bastl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. A redirect for that URL has now been added. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 11 18:25:02 2009 From: trac at galois.com (GHC) Date: Fri Sep 11 18:03:56 2009 Subject: [GHC] #3474: Add a strict variant of iterate to Data.List In-Reply-To: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@localhost> References: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@localhost> Message-ID: <051.80485d34d370e1dc516626efd8654964@localhost> #3474: Add a strict variant of iterate to Data.List ---------------------------------+------------------------------------------ Reporter: mux | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 12 05:54:54 2009 From: trac at galois.com (GHC) Date: Sat Sep 12 05:33:46 2009 Subject: [GHC] #3434: improve vi tags (add non-exported symbols, add tag kinds, add regex tags) In-Reply-To: <046.d2dbc3c59e7dd2597dcfc9a0bd98987b@localhost> References: <046.d2dbc3c59e7dd2597dcfc9a0bd98987b@localhost> Message-ID: <055.b06e1e6c820f5a43526c22b5ac7f386b@localhost> #3434: improve vi tags (add non-exported symbols, add tag kinds, add regex tags) ---------------------------------+------------------------------------------ Reporter: phercek | Owner: simonmar Type: feature request | Status: new Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: vim tags ctags | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by phercek): You can ignore this comment completely. It is just about some ideas for emacs support which I do not really care about.[[BR]] I do not know emacs at all (installed it just now and read a bit about emacs TAGS in the manual). Anyway I tried two things: adding tag kinds and adding static tags to emacs TAGS.[[BR]] Although emacs does not have a special field for a tag kind it solves it by adding / to the tag name to distinguish different kinds with the same name. This is the way how it is done for Ada code so here is a patch which does the same for Haskell (it must be applied on top of improveVimTags.dpatch): {{{ diff -rN -u old-ghc.head/ghc/GhciTags.hs new-ghc.head/ghc/GhciTags.hs --- old-ghc.head/ghc/GhciTags.hs 2009-09-12 11:06:48.735680788 +0200 +++ new-ghc.head/ghc/GhciTags.hs 2009-09-12 11:06:48.975681765 +0200 @@ -192,10 +192,10 @@ -- etags format, for Emacs/XEmacs showETag :: TagInfo -> String -showETag TagInfo{ tagName = tag, tagLine = lineNo, tagCol = colNo, +showETag TagInfo{ tagName = tag, tagKind = kind, tagLine = lineNo, tagCol = colNo, tagSrcInfo = Just (srcLine,charPos) } = take colNo srcLine ++ tag - ++ "\x7f" ++ tag + ++ "\x7f" ++ tag ++ ('/':kind:[]) ++ "\x01" ++ show lineNo ++ "," ++ show charPos showETag _ = ghcError (CmdLineError "missing source file info in showETag") }}} Addition of tag kinds for emacs seems to work well. But, as far as I could figure it out, emacs support for static tags (symbols with file scope) is worse compared to vim. It still kind of works. Emacs can cycle over all tags with given name but it does not prefer jump to a local tag (the tag in the same file from which the jump was initiated). So in the case of name clashes it often jumps to incorrect locations. I think it should be possible to write an emacs macro which does this well. Still, the result is that it is questionable whether emacs tags should contain non-exported top level Haskell definitions by default. If you think it should then a patch which adds them is here (it must be applied on top of improveVimTags.dpatch): {{{ diff -rN -u old-ghc.head/ghc/GhciTags.hs new-ghc.head/ghc/GhciTags.hs --- old-ghc.head/ghc/GhciTags.hs 2009-09-12 11:06:48.735680788 +0200 +++ new-ghc.head/ghc/GhciTags.hs 2009-09-12 11:06:48.975681765 +0200 @@ -139,7 +139,7 @@ IO.try (writeFile file tags) collateAndWriteTags ETags file tagInfos = do -- etags style, Emacs/XEmacs - tagInfoGroups <- makeTagGroupsWithSrcInfo $filter tagExported tagInfos + tagInfoGroups <- makeTagGroupsWithSrcInfo tagInfos let tagGroups = map processGroup tagInfoGroups IO.try (writeFile file $ concat tagGroups) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 12 14:29:18 2009 From: trac at galois.com (GHC) Date: Sat Sep 12 14:08:10 2009 Subject: [GHC] #3486: Data.ByteString.elemIndices causes SEGV In-Reply-To: <042.edd017489a67f7a628a8510b09ab86e5@localhost> References: <042.edd017489a67f7a628a8510b09ab86e5@localhost> Message-ID: <051.77959ef653db8236576d7e9b0863234a@localhost> #3486: Data.ByteString.elemIndices causes SEGV -------------------------------+-------------------------------------------- Reporter: nwn | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by igloo): Reproducible with both. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 12 15:33:17 2009 From: trac at galois.com (GHC) Date: Sat Sep 12 15:12:08 2009 Subject: [GHC] #3486: Data.ByteString.elemIndices causes SEGV In-Reply-To: <042.edd017489a67f7a628a8510b09ab86e5@localhost> References: <042.edd017489a67f7a628a8510b09ab86e5@localhost> Message-ID: <051.1c055d237225a44b5f250ab055c09d94@localhost> #3486: Data.ByteString.elemIndices causes SEGV -------------------------------+-------------------------------------------- Reporter: nwn | Owner: duncan Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * priority: normal => high * owner: igloo => duncan Comment: The problem is in `elemIndices`: {{{ elemIndices :: Word8 -> ByteString -> [Int] elemIndices w (PS x s l) = inlinePerformIO $ withForeignPtr x $ \p -> do let ptr = p `plusPtr` s STRICT1(loop) loop n = let q = inlinePerformIO $ memchr (ptr `plusPtr` n) w (fromIntegral (l - n)) in if q == nullPtr then [] else let i = q `minusPtr` ptr in i : loop (i+1) return $! loop 0 }}} The lazy thunk using `p` escapes from the `withForeignPtr`, so `x` can be freed. Replacing `[]` with: {{{ inlinePerformIO $ do touchForeignPtr x return [] }}} makes the segfault go away. I'm assigning this to duncan so that he or Don can fix it in the upstream repo, and also check if any other functions have the same problem. I assume that this will also fix #3487. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 12 15:33:35 2009 From: trac at galois.com (GHC) Date: Sat Sep 12 15:12:26 2009 Subject: [GHC] #3487: Data.ByteString.Lazy.elemIndices returns wrong results In-Reply-To: <042.4f1103cc60c42d21bbc9fb56583d59f1@localhost> References: <042.4f1103cc60c42d21bbc9fb56583d59f1@localhost> Message-ID: <051.eb30ec64e7f281837bf0ec1084a44e38@localhost> #3487: Data.ByteString.Lazy.elemIndices returns wrong results -------------------------------+-------------------------------------------- Reporter: nwn | Owner: duncan Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * owner: igloo => duncan Comment: See #3486. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 12 16:20:55 2009 From: trac at galois.com (GHC) Date: Sat Sep 12 15:59:45 2009 Subject: [GHC] #3506: Can't compile 6.10.x from 6.8.3 Message-ID: <047.e1b800663bad3e194655131f11dc6a20@localhost> #3506: Can't compile 6.10.x from 6.8.3 ---------------------+------------------------------------------------------ Reporter: Pandarus | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.8.3 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ---------------------+------------------------------------------------------ Attempted compiles of 6.10.1, 6.10.3, and 6.10.4 all ended similarly. Compile messages for attempted compile of 6.10.1 ended with: [45 of 50] Compiling Distribution.Simple.GHC ( Distribution/Simple/GHC.hs, dist-bootstrapping/build/Distribution/Simple/GHC.o ) [46 of 50] Compiling Distribution.Simple.Build ( Distribution/Simple/Build.hs, dist- bootstrapping/build/Distribution/Simple/Build.o ) [47 of 50] Compiling Distribution.Simple.Haddock ( Distribution/Simple/Haddock.hs, dist- bootstrapping/build/Distribution/Simple/Haddock.o ) [48 of 50] Compiling Distribution.Simple.Configure ( Distribution/Simple/Configure.hs, dist- bootstrapping/build/Distribution/Simple/Configure.o ) [49 of 50] Compiling Distribution.Simple.Install ( Distribution/Simple/Install.hs, dist- bootstrapping/build/Distribution/Simple/Install.o ) [50 of 50] Compiling Distribution.Simple ( Distribution/Simple.hs, dist- bootstrapping/build/Distribution/Simple.o ) ghc-6.8.3: internal error: evacuate(static): strange closure type 1 (GHC version 6.8.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [bootstrapping.conf] Error 6 make[1]: Leaving directory `/home/dbridges/src/ghc-6.10.1/libraries' make: *** [stage1] Error 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 12 16:37:55 2009 From: trac at galois.com (GHC) Date: Sat Sep 12 16:16:45 2009 Subject: [GHC] #3506: Can't compile 6.10.x from 6.8.3 In-Reply-To: <047.e1b800663bad3e194655131f11dc6a20@localhost> References: <047.e1b800663bad3e194655131f11dc6a20@localhost> Message-ID: <056.ab9780296479688e32ab69af08edbe12@localhost> #3506: Can't compile 6.10.x from 6.8.3 -------------------------------+-------------------------------------------- Reporter: Pandarus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: The 6.8 branch is no longer being developed, so we won't be fixing this bug, I'm afraid. If you are unable to build a more recent GHC then you can download a binary distribution, or perhaps get a binary from your Linux distribution. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 12 17:22:41 2009 From: trac at galois.com (GHC) Date: Sat Sep 12 17:01:29 2009 Subject: [GHC] #3507: In TH, allow e.g. (type T) rather than ''T Message-ID: <044.394a7872ceb7e24fbb48578ce27ffb55@localhost> #3507: In TH, allow e.g. (type T) rather than ''T -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Template Haskell | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- In Template Haskell, allow (for example): {{{ deriveMyStuff (type T) }}} with the same meaning as the current: {{{ deriveMyStuff ''T }}} Discussion here: http://www.haskell.org/pipermail/template- haskell/2009-September/000735.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 12 17:42:32 2009 From: trac at galois.com (GHC) Date: Sat Sep 12 17:21:23 2009 Subject: [GHC] #3493: "make install" fails with error on rts/Config.h in HEAD In-Reply-To: <044.e3121a1d0ddafa3bdca737e47a0186e1@localhost> References: <044.e3121a1d0ddafa3bdca737e47a0186e1@localhost> Message-ID: <053.8e777afee0d6d28c53734645bdade53c@localhost> #3493: "make install" fails with error on rts/Config.h in HEAD ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown * component: Compiler => Build System * milestone: => 6.12.1 Comment: Thanks for the report. I think everything should be working now, but I will check the next nightly build before closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 12 17:42:46 2009 From: trac at galois.com (GHC) Date: Sat Sep 12 17:21:36 2009 Subject: [GHC] #3493: "make install" fails with error on rts/Config.h in HEAD In-Reply-To: <044.e3121a1d0ddafa3bdca737e47a0186e1@localhost> References: <044.e3121a1d0ddafa3bdca737e47a0186e1@localhost> Message-ID: <053.ad20cd6ac2dda958b5d46744fc08a267@localhost> #3493: "make install" fails with error on rts/Config.h in HEAD ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 12 17:45:05 2009 From: trac at galois.com (GHC) Date: Sat Sep 12 17:23:55 2009 Subject: [GHC] #3481: Nightly snapshot fails to install In-Reply-To: <043.648802f336c6762629e495848f7ef257@localhost> References: <043.648802f336c6762629e495848f7ef257@localhost> Message-ID: <052.ef63cde87b25069cd7e877647b0f9740@localhost> #3481: Nightly snapshot fails to install -------------------------------+-------------------------------------------- Reporter: dons | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * owner: => igloo Comment: Thanks for the report. I think everything should be working now, but I will check the next nightly build before closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 13 07:37:20 2009 From: trac at galois.com (GHC) Date: Sun Sep 13 07:16:10 2009 Subject: [GHC] #3508: Remove stg_noforceIO_info hack Message-ID: <044.d2d70b46c6b2f7166b57cd511cda3b73@localhost> #3508: Remove stg_noforceIO_info hack -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Remove `stg_noforceIO_info` hack. See http://www.haskell.org/pipermail /glasgow-haskell-users/2009-September/017724.html -- Ticket URL: GHC The Glasgow Haskell Compiler From chak at cse.unsw.edu.au Sun Sep 13 10:40:07 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Sun Sep 13 10:19:01 2009 Subject: #3485: "Illegal type synonym family application in instance" error is unnecessary, should be removed In-Reply-To: <4AA57B68.6030806@semantic.org> References: <053.3893e570e78fa71dd6ee013e3e60e14c@localhost> <062.68df8bca19f0c08f167b7d4a9ff44d96@localhost> <4AA57B68.6030806@semantic.org> Message-ID: Ashley Yakeley: > GHC wrote: >> #3485: "Illegal type synonym family application in instance" error >> is unnecessary, >> should be removed >> ------------------------------------- >> +-------------------------------------- >> Reporter: Ashley Yakeley | >> Owner: Type: bug >> | Status: closed Priority: >> normal | Milestone: >> Component: Compiler (Type checker) | Version: >> 6.10.4 Severity: normal | >> Resolution: invalid Keywords: >> | Testcase: Os: Unknown/ >> Multiple | Architecture: Unknown/Multiple >> ------------------------------------- >> +-------------------------------------- >> Changes (by chak): >> * status: new => closed >> * resolution: => invalid >> Comment: >> I am not sure what you are suggesting. We cannot automatically >> transform >> {{{ >> instance C (Fam Int) >> }}} >> into >> {{{ >> instance (Fam Int ~ famint) => C famint >> }}} >> This works if there is only one instance, but as soon as there are >> two >> such instances, they always overlap. >> Maybe you are suggesting that we should do it anyway and programmers >> should just take the implicit transformation into account. I don't >> think >> that this is a good idea. It's confusing for very little benefit >> (as you >> can always write the transformed instance yourself with little >> effort). > > I don't see what the problem is. "instance C (Fam Int)" has an > unambiguous, and logically acceptable, meaning to the compiler. Why > do we force the programmer to make an ugly workaround involving > introducing a type variable? I think the proposed change is confusing. Two instances instance C (Fam Int) instance C (Fam Bool) appear to be syntactically distinct, but they semantically overlap. The explicit form instance (Fam Int ~ famint) => C famint is IMHO much clearer and really not much more verbose. Manuel From trac at galois.com Sun Sep 13 11:57:07 2009 From: trac at galois.com (GHC) Date: Sun Sep 13 11:35:55 2009 Subject: [GHC] #3486: Data.ByteString.elemIndices causes SEGV In-Reply-To: <042.edd017489a67f7a628a8510b09ab86e5@localhost> References: <042.edd017489a67f7a628a8510b09ab86e5@localhost> Message-ID: <051.6f7611d6bd3cfc48fcbda81413fd14ec@localhost> #3486: Data.ByteString.elemIndices causes SEGV -------------------------------+-------------------------------------------- Reporter: nwn | Owner: duncan Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by duncan): Attached patch should fix it (and #3487). Just awaiting further review. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 13 19:00:53 2009 From: trac at galois.com (GHC) Date: Sun Sep 13 18:39:40 2009 Subject: [GHC] #3509: libffi.so not found on Mac OS X (10.5.8) Message-ID: <046.e078f62d85671282d5ab3883ebdd8e48@localhost> #3509: libffi.so not found on Mac OS X (10.5.8) --------------------+------------------------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- building with dynamic libraries on Mac OS X dies with an error about libffi.so To reproduce: add a build.mk with "GhcLibWays = v dyn" sh boot && ./configure --enable-shared && make If I copy one of the libffi*dylib files that does appear to have been built correctly to libffi.so, the build proceeds but then loops in the build process. partial trace: (cd .libs && rm -f libffi.5.dylib && cp -p libffi.5.0.9.dylib libffi.5.dylib) (cd .libs && rm -f libffi.dylib && cp -p libffi.5.0.9.dylib libffi.dylib) ar cru .libs/libffi.a src/debug.o src/prep_cif.o src/types.o src/raw_api.o src/java_raw_api.o src/closures.o src/x86/ffi.o src/x86/darwin.o src/x86/ffi64.o src/x86/darwin64.o "inplace/bin/mkdirhier" inplace/lib/ "cp" -p utils/hsc2hs/dist/build/tmp/hsc2hs inplace/lib/hsc2hs ranlib: file: .libs/libffi.a(ffi64.o) has no symbols ranlib: file: .libs/libffi.a(darwin64.o) has no symbolstouch inplace/lib/hsc2hs ranlib .libs/libffi.a ranlib: file: .libs/libffi.a(ffi64.o) has no symbols ranlib: file: .libs/libffi.a(darwin64.o) has no symbols creating libffi.la (cd .libs && rm -f libffi.la && cp -p ../libffi.la libffi.la) /bin/sh ./libtool --tag=CC --mode=link gcc -Wall -g -fexceptions -w -w -o libffi_convenience.la src/debug.lo src/prep_cif.lo src/types.lo src/raw_api.lo src/java_raw_api.lo src/closures.lo src/x86/ffi.lo src/x86/darwin.lo src/x86/ffi64.lo src/x86/darwin64.lo ar cru .libs/libffi_convenience.a src/.libs/debug.o src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/ffi.o src/x86/.libs/darwin.o src/x86/.libs/ffi64.o src/x86/.libs/darwin64.o ranlib: file: .libs/libffi_convenience.a(ffi64.o) has no symbols ranlib: file: .libs/libffi_convenience.a(darwin64.o) has no symbols ranlib .libs/libffi_convenience.a ranlib: file: .libs/libffi_convenience.a(ffi64.o) has no symbols ranlib: file: .libs/libffi_convenience.a(darwin64.o) has no symbols creating libffi_convenience.la (cd .libs && rm -f libffi_convenience.la && cp -p ../libffi_convenience.la libffi_convenience.la) make[4]: Leaving directory `/Users/mwotton/projects/ghc/libffi/build' make[3]: Leaving directory `/Users/mwotton/projects/ghc/libffi/build' cp .libs/libffi.5.0.9.dylib /Users/mwotton/projects/ghc/libffi/libffi.5.0.9.dylib (cd /Users/mwotton/projects/ghc/libffi && { cp -p -f libffi.5.0.9.dylib libffi.5.dylib || { rm -f libffi.5.dylib && cp -p libffi.5.0.9.dylib libffi.5.dylib; }; }) (cd /Users/mwotton/projects/ghc/libffi && { cp -p -f libffi.5.0.9.dylib libffi.dylib || { rm -f libffi.dylib && cp -p libffi.5.0.9.dylib libffi.dylib; }; }) cp .libs/libffi.lai /Users/mwotton/projects/ghc/libffi/libffi.la cp .libs/libffi.a /Users/mwotton/projects/ghc/libffi/libffi.a chmod 644 /Users/mwotton/projects/ghc/libffi/libffi.a ranlib /Users/mwotton/projects/ghc/libffi/libffi.a ranlib: file: /Users/mwotton/projects/ghc/libffi/libffi.a(ffi64.o) has no symbols ranlib: file: /Users/mwotton/projects/ghc/libffi/libffi.a(darwin64.o) has no symbols libtool: install: warning: remember to run `libtool --finish /usr/local/lib' touch libffi/stamp.ffi.build-shared "cp" libffi/libffi.a libffi/libHSffi.a "cp" libffi/libffi.so libffi/libHSffi-ghc6.11.20090913.dylib "cp" libffi/libffi.a libffi/libHSffi_p.a cp: libffi/libffi.so: No such file or directory make[1]: *** [libffi/libHSffi-ghc6.11.20090913.dylib] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 nice make -j 2 145.90s user 70.38s system 78% cpu 4:37.08 total -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 13 19:50:49 2009 From: trac at galois.com (GHC) Date: Sun Sep 13 19:29:38 2009 Subject: [GHC] #3509: libffi.so not found on Mac OS X (10.5.8) In-Reply-To: <046.e078f62d85671282d5ab3883ebdd8e48@localhost> References: <046.e078f62d85671282d5ab3883ebdd8e48@localhost> Message-ID: <055.dcf6ccfe08a17695efa98f1452c844c5@localhost> #3509: libffi.so not found on Mac OS X (10.5.8) --------------------------+------------------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Comment (by mwotton): that patch fixes it, it seems. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 13 20:18:13 2009 From: trac at galois.com (GHC) Date: Sun Sep 13 19:57:00 2009 Subject: [GHC] #3510: build system loops with GhcLibWays = "v dyn" on Mac Message-ID: <046.a0ea8c110da8a4eeee928d65531c2e70@localhost> #3510: build system loops with GhcLibWays = "v dyn" on Mac --------------------+------------------------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- Noticed it seemed to be looping on build so I ran this: make -d |grep "Must remake" it seems like it keeps building libffi.dylib.5... Must remake target `mk/are-validating.mk'. Must remake target `libffi/libffi.dylib.5'. Must remake target `libffi/libffi.dylib.5.0.9'. Must remake target `libffi/libHSffi-ghc6.11.20090913.dylib'. Must remake target `inplace/bin/hsc2hs'. Must remake target `libraries/hpc/dist- boot/build/Trace/Hpc/Reflect.hs'. Must remake target `libraries/hpc/dist-boot/build/.depend-v'. Must remake target `compiler/stage1/build/Fingerprint.hs'. Must remake target `utils/genprimopcode/dist/build/Lexer.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/Version.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/Package.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/Simple/Utils.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/Simple/InstallDirs.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/PackageDescription.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/Simple/Setup.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/Simple/PackageIndex.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/Simple/GHC/IPI641.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/Simple/GHC.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/Simple/Register.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/Simple/PreProcess.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/Simple/Build/PathsModule.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/Simple/Hugs.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/Simple/LHC.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/Simple/JHC.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/PackageDescription/Check.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/Simple/Configure.hi'. Must remake target `libraries/Cabal/dist- boot/build/Distribution/PackageDescription/Parse.hi'. Must remake target `libraries/hpc/dist- boot/build/Trace/Hpc/Reflect.o'. Must remake target `libraries/hpc/dist-boot/build/libHShpc-0.5.0.2.a'. Must remake target `libraries/binary/dist- boot/build/Data/Binary.hi'. Must remake target `compiler/stage1/build/.depend-v'. Must remake target `mk/are-validating.mk'. Must remake target `libffi/libffi.dylib.5'. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 13 21:19:36 2009 From: trac at galois.com (GHC) Date: Sun Sep 13 20:58:23 2009 Subject: [GHC] #3510: build system loops with GhcLibWays = "v dyn" on Mac In-Reply-To: <046.a0ea8c110da8a4eeee928d65531c2e70@localhost> References: <046.a0ea8c110da8a4eeee928d65531c2e70@localhost> Message-ID: <055.82df1a21551556ac4db3045e04c52cfb@localhost> #3510: build system loops with GhcLibWays = "v dyn" on Mac --------------------------+------------------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Changes (by mwotton): * version: 6.10.4 => 6.11 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 13 21:31:01 2009 From: trac at galois.com (GHC) Date: Sun Sep 13 21:09:47 2009 Subject: [GHC] #3510: build system loops with GhcLibWays = "v dyn" on Mac In-Reply-To: <046.a0ea8c110da8a4eeee928d65531c2e70@localhost> References: <046.a0ea8c110da8a4eeee928d65531c2e70@localhost> Message-ID: <055.b3262e37c457c36bab5057c166bd3d16@localhost> #3510: build system loops with GhcLibWays = "v dyn" on Mac --------------------------+------------------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Changes (by mwotton): * status: new => closed * resolution: => invalid Comment: Fixed by a better patch to http://hackage.haskell.org/trac/ghc/ticket/3509 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 13 21:51:54 2009 From: trac at galois.com (GHC) Date: Sun Sep 13 21:30:40 2009 Subject: [GHC] #3509: libffi.so not found on Mac OS X (10.5.8) In-Reply-To: <046.e078f62d85671282d5ab3883ebdd8e48@localhost> References: <046.e078f62d85671282d5ab3883ebdd8e48@localhost> Message-ID: <055.82445d823b6b19819da309af093cd73b@localhost> #3509: libffi.so not found on Mac OS X (10.5.8) --------------------------+------------------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Comment (by mwotton): but it breaks it for linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 13 23:00:44 2009 From: trac at galois.com (GHC) Date: Sun Sep 13 22:39:29 2009 Subject: [GHC] #3511: port GHC to OpenBSD/sparc64 (unregisterised is fine) Message-ID: <044.84975b11fc9b3b424090411fd29c2c83@localhost> #3511: port GHC to OpenBSD/sparc64 (unregisterised is fine) ----------------------------+----------------------------------------------- Reporter: zooko | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: port sparc64 | Testcase: Os: OpenBSD | Architecture: Other ----------------------------+----------------------------------------------- Folks: I'm a developer of the Tahoe-LAFS open source project (http://allmydata.org ) and we use darcs, and there is a contributor who would like to help us support Tahoe-LAFS on OpenBSD/sparc64 (note: not OpenBSD/sparc). It would be really nice if that contribute could use darcs to get the latest Tahoe-LAFS source code and to contribute patches. But, GHC isn't ported to OpenBSD/sparc64. This ticket is to request the feature of a port of GHC to OpenBSD/sparc64. An unregisterised port would be fine! Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 14 02:22:39 2009 From: trac at galois.com (GHC) Date: Mon Sep 14 02:01:24 2009 Subject: [GHC] #3512: template-hsc.h installed under /usr/share (datadir) Message-ID: <050.7896d37f2a18b0c32a408dd87cd7732d@localhost> #3512: template-hsc.h installed under /usr/share (datadir) -----------------------------+---------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- In ghc-6.10.4 hsc2hs's template-hsc.h gets installed as "/usr/lib/ghc-6.10.4/hsc2hs-0.67/template-hsc.h" whereas with 6.11 I see "/usr/share/template-hsc.h". (Maybe it is better to move it in the source into "hsc2hs/include/"?) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 14 05:34:18 2009 From: trac at galois.com (GHC) Date: Mon Sep 14 05:13:04 2009 Subject: [GHC] #3295: Null deref by threaded runtime scheduler In-Reply-To: <044.c2ef3bf0c2dff07fbe94ef6f704ea47f@localhost> References: <044.c2ef3bf0c2dff07fbe94ef6f704ea47f@localhost> Message-ID: <053.b6ac5c6758c111c64564dfc9d946ae5e@localhost> #3295: Null deref by threaded runtime scheduler ---------------------------------------------------------+------------------ Reporter: A1kmm | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: major | Resolution: Keywords: crash, nullderef, threaded, parallel, GC | Difficulty: Unknown Testcase: | Os: Linux Architecture: ia64 | ---------------------------------------------------------+------------------ Comment (by simonmar): This might be the same as #3320, which is fixed in HEAD. If you could test with either HEAD or the forthcoming 6.12.1 RC, that would be most helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 14 06:53:35 2009 From: trac at galois.com (GHC) Date: Mon Sep 14 06:32:21 2009 Subject: [GHC] #3294: Large compilation time/memory consumption In-Reply-To: <046.0a15417e538aeef3254b5152fea74b37@localhost> References: <046.0a15417e538aeef3254b5152fea74b37@localhost> Message-ID: <055.0fcae7763a137d289f1082d208384e33@localhost> #3294: Large compilation time/memory consumption ---------------------------------------------+------------------------------ Reporter: pumpkin | Owner: simonmar Type: compile-time performance bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ---------------------------------------------+------------------------------ Comment (by simonmar): The NCG has been leaking again, I just fixed it: {{{ Fri Sep 11 16:28:12 BST 2009 Simon Marlow * Fix a space leak in the native code gen (again) }}} This does reduce the peak memory usage for this test quite a lot, but we're still spending a lot of time in the NCG, and that needs investigating. Space leak test added as `space_leaks/T3294`, so hopefully this won't re-occur. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 14 08:14:12 2009 From: trac at galois.com (GHC) Date: Mon Sep 14 07:54:01 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.39b0028547e23e555d57752c82871e7d@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Changes (by agerdes): * cc: alex@cs.uu.nl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 14 08:31:52 2009 From: trac at galois.com (GHC) Date: Mon Sep 14 08:10:37 2009 Subject: [GHC] #3506: Can't compile 6.10.x from 6.8.3 In-Reply-To: <047.e1b800663bad3e194655131f11dc6a20@localhost> References: <047.e1b800663bad3e194655131f11dc6a20@localhost> Message-ID: <056.25a4a1a06c809a712f79b797ad883825@localhost> #3506: Can't compile 6.10.x from 6.8.3 -------------------------------+-------------------------------------------- Reporter: Pandarus | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by simonmar): If the error is different each time, it may be that your hardware is faulty. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 14 11:17:37 2009 From: trac at galois.com (GHC) Date: Mon Sep 14 10:56:22 2009 Subject: [GHC] #3084: alow macros to redefine builtin GHCi commands In-Reply-To: <046.7f055f7e30420d89efe3f2db433a2d00@localhost> References: <046.7f055f7e30420d89efe3f2db433a2d00@localhost> Message-ID: <055.c7ad55feeef9ec72cfa0812e1250040e@localhost> #3084: alow macros to redefine builtin GHCi commands ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: closed Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: pushed. {{{ Tue May 12 10:24:59 PDT 2009 Peter Hercek * alow macros to redefine builtin GHCi commands (implements #3084) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 14 11:21:10 2009 From: trac at galois.com (GHC) Date: Mon Sep 14 10:59:57 2009 Subject: [GHC] #3408: idle GC causes large CPU usage if run more frequently than 1 second In-Reply-To: <049.48be2d13214f4104fb7093c0a3d0accb@localhost> References: <049.48be2d13214f4104fb7093c0a3d0accb@localhost> Message-ID: <058.851742768df72c05e4367cc6f4187776@localhost> #3408: idle GC causes large CPU usage if run more frequently than 1 second ---------------------------------+------------------------------------------ Reporter: JeremyShaw | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: idle GC | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed {{{ Fri Sep 11 05:45:47 PDT 2009 Simon Marlow * Fix #3408: lengthen the idle GC time to 5s for GHC/GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 14 11:22:41 2009 From: trac at galois.com (GHC) Date: Mon Sep 14 11:01:36 2009 Subject: [GHC] #2063: x86_64: RTS linker depends on working MAP_32BIT In-Reply-To: <043.15abf9ca319b437728a2421245ad0407@localhost> References: <043.15abf9ca319b437728a2421245ad0407@localhost> Message-ID: <052.8352f13319413ef931e7a681a6622b55@localhost> #2063: x86_64: RTS linker depends on working MAP_32BIT -------------------------------+-------------------------------------------- Reporter: dons | Owner: simonmar Type: task | Status: closed Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: OpenBSD, Xen | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Assuming fixed; please re-open if not. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 14 11:23:36 2009 From: trac at galois.com (GHC) Date: Mon Sep 14 11:02:23 2009 Subject: [GHC] #2925: Linker mmap failure on FreeBSD/x86_64 In-Reply-To: <047.eaff3ca4aa8bcea6096eb0e3b35eda7f@localhost> References: <047.eaff3ca4aa8bcea6096eb0e3b35eda7f@localhost> Message-ID: <056.cb82f86ff72e0ce5b8390aab62c4a1dd@localhost> #2925: Linker mmap failure on FreeBSD/x86_64 -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: FreeBSD Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Assuming fixed; please re-open if not. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 14 11:54:18 2009 From: trac at galois.com (GHC) Date: Mon Sep 14 11:33:08 2009 Subject: [GHC] #3497: Template Haskell support for GADTs In-Reply-To: <046.5070e39940e96fda263647e7217ed34d@localhost> References: <046.5070e39940e96fda263647e7217ed34d@localhost> Message-ID: <055.9b5f891bf8f8ab375741c635f063d853@localhost> #3497: Template Haskell support for GADTs ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by guest): * cc: ariep@xs4all.nl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 14 12:09:27 2009 From: trac at galois.com (GHC) Date: Mon Sep 14 11:48:11 2009 Subject: [GHC] #3513: Network package does not work on Windows 2000 Message-ID: <044.d382601b86fb983edfc50f7450d8f520@localhost> #3513: Network package does not work on Windows 2000 --------------------+------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.10.4 | Severity: major Keywords: | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- I'm using GHC 6.10.4 on Windows 2000 SP4. I have this simple code: {{{ import Network main = listenOn (PortNumber 12345) >> return () }}} executing it with runhaskell fails: {{{ >runhaskell test.hs test.hs: C:\ghc\ghc-6.10.4\network-2.2.1.2\HSnetwork-2.2.1.2.o: unknown symbol `_getnameinfo' test.hs: test.hs: unable to load package `network-2.2.1.2' }}} It can be compiled and linked successfully (ghc --make test.hs), however when run, it fails with this message box: test.exe - Entry Point Not Found[[BR]] The procedure entry point freeaddrinfo could not be located in the dynamic link library WS2_32.DLL. It seems that the network package uses API functions: getaddrinfo, freeadrrinfo and getnameinfo. Those functions don't exist on Windows 2000 SP4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 15 07:19:24 2009 From: trac at galois.com (GHC) Date: Tue Sep 15 06:58:06 2009 Subject: [GHC] #3340: Better defaults for parallel GC settings In-Reply-To: <047.fcbb118c30a8f079699c4527915832cf@localhost> References: <047.fcbb118c30a8f079699c4527915832cf@localhost> Message-ID: <056.75790f99fc9294926144332adfb1638b@localhost> #3340: Better defaults for parallel GC settings ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed {{{ Tue Sep 15 01:40:00 PDT 2009 Simon Marlow * Improve the default parallel GC settings, and sanitise the flags (#3340) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 15 08:59:09 2009 From: trac at galois.com (GHC) Date: Tue Sep 15 08:37:52 2009 Subject: [GHC] #2953: deriving Functor, Foldable, Traversable In-Reply-To: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> References: <045.1ed3b38adbe9ad6aceca4244fe75f3c0@localhost> Message-ID: <054.5e1d0203e2656b16d0507ede8949f181@localhost> #2953: deriving Functor, Foldable, Traversable ---------------------------------+------------------------------------------ Reporter: twanvl | Owner: twanvl Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by MartijnVanSteenbergen): This is exciting stuff. :-D -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 15 09:27:38 2009 From: trac at galois.com (GHC) Date: Tue Sep 15 09:06:20 2009 Subject: [GHC] #3434: improve vi tags (add non-exported symbols, add tag kinds, add regex tags) In-Reply-To: <046.d2dbc3c59e7dd2597dcfc9a0bd98987b@localhost> References: <046.d2dbc3c59e7dd2597dcfc9a0bd98987b@localhost> Message-ID: <055.14d1b5a60a5d739605bd875bccd9294a@localhost> #3434: improve vi tags (add non-exported symbols, add tag kinds, add regex tags) ---------------------------------+------------------------------------------ Reporter: phercek | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: vim tags ctags | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: I have dutifully done a quick test of `:etags` under emacs, and tested the resulting TAGS file, and it seems to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 15 14:08:52 2009 From: trac at galois.com (GHC) Date: Tue Sep 15 13:47:39 2009 Subject: [GHC] #3271: New methods for Data.Sequence In-Reply-To: <053.cc9895e43857ea386bfb254a48e9e83f@localhost> References: <053.cc9895e43857ea386bfb254a48e9e83f@localhost> Message-ID: <062.c73c75114885ba20c4ac620d09cd2792@localhost> #3271: New methods for Data.Sequence ----------------------------------+----------------------------------------- Reporter: LouisWasserman | Owner: LouisWasserman Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by ross): * status: new => closed * resolution: => fixed Comment: This was discussed at length by Louis and Ross, with no dissent from anyone else. During the discussion the patch went through several iterations, cutting a lot of specialized code, but also adding several more methods. In committing the patch, I've tweaked the doc comments a little, and renamed foldWithIndexL and foldWithIndexR as foldlWithIndex and foldrWithIndex, parallelling foldlWithKey and foldrWithKey in Data.Map. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 15 15:43:02 2009 From: trac at galois.com (GHC) Date: Tue Sep 15 15:21:43 2009 Subject: [GHC] #3514: mallocPlainForeignPtrBytes -1000 gives runtime internal error: allocGroup: requested zero blocks Message-ID: <052.f949c738ea0d9d2b66116addc98fdaed@localhost> #3514: mallocPlainForeignPtrBytes -1000 gives runtime internal error: allocGroup: requested zero blocks --------------------------+------------------------------------------------- Reporter: andrewbirkett | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.4 | Severity: minor Keywords: | Testcase: Os: Linux | Architecture: x86 --------------------------+------------------------------------------------- Passing negative numbers to mallocPlainForeignPtrBytes causes the following to appear: {{{ Test: internal error: allocGroup: requested zero blocks (GHC version 6.10.4 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} Originally, a bug in my app meant that I called Data.ByteString.hGet with a negative 'numBytes' argument, however I've managed to boil it down to a one line test case involving just mallocPlainForeignPtrBytes as follows: {{{ $ cat Test.hs import GHC.ForeignPtr (mallocPlainForeignPtrBytes) main = mallocPlainForeignPtrBytes (-1000) $ ghc --make Test.hs [1 of 1] Compiling Main ( Test.hs, Test.o ) Linking Test ... $ ./Test Test: internal error: allocGroup: requested zero blocks (GHC version 6.10.4 for i386_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} The magnitude of the number appears to have some effect; with ghc 6.10.1 it seemed to reliably crash with numBytes <= -9. But when I upgraded to ghc 6.10.4, the test case started working. However, changing to -1000 reliably causes a crash on my box - perhaps the behaviour depends on heap layout. Either way, the function should probably behave more gracefully .. perhaps raising an exception. Full gory details of my setup (ie. ghc -v output, gcc version) are attached because they messed up the formatting. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 15 16:26:58 2009 From: trac at galois.com (GHC) Date: Tue Sep 15 16:05:38 2009 Subject: [GHC] #3515: Use --make mode by default Message-ID: <045.e62049566365cd39a9e7de440d8eeb80@localhost> #3515: Use --make mode by default -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Component: Driver Version: | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Terribly radical suggestion, have --make mode be the default. Just think of the annual number of keystrokes saved! It would not actually break the one-shot mode that build systems use. Proper build systems compile .hs modules using -c and they link by specifying .o files, not .hs files. Thus we can change the meaning of things like: {{{ ghc foo.hs -o foo }}} without changing the meaning of either of these: {{{ ghc -c foo.hs ghc foo.o -o foo }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 15 16:50:24 2009 From: trac at galois.com (GHC) Date: Tue Sep 15 16:29:05 2009 Subject: [GHC] #1102: Lambda unicode character lex In-Reply-To: <047.3274cd2b53d69d61deb3dee313b1b3f5@localhost> References: <047.3274cd2b53d69d61deb3dee313b1b3f5@localhost> Message-ID: <056.b66496d3c2e60a71ebfce4c57d637c9d@localhost> #1102: Lambda unicode character lex -----------------------------------------------+---------------------------- Reporter: humasect | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.6.1 Component: Compiler (Parser) | Version: 6.6 Severity: minor | Resolution: Keywords: lambda unicode lexical parse ? | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------------+---------------------------- Changes (by pumpkin): * status: closed => reopened * resolution: wontfix => * severity: major => minor Comment: Replying to [comment:1 simonmar]: > I removed the claim on the Haskell-prime wiki, and also removed the failed attempt to support unicode lambda from GHC. > > Further discussion is needed here: since ? is a lower-case letter, ?x is an identifier. If we want to treat this as meaning `\x`, that means ? would need to be treated as a "special" character (like parentheses for example). No other alphanumeric character has this property, currently. I'm reasonably sure this could be done unambiguously for the regular greek lambda, but it would add some complexity to the parse. As a simple alternative, we could use some of the new unicode characters from the "Math Alphanumeric Symbols" table (non-BMP). The following characters seem like valid candidates for really easy lexing (unfortunately almost no fonts actually provide glyphs for them, but in principle at least, it should be correct: ?? (1D6CC, MATHEMATICAL BOLD SMALL LAMBDA) ?? (1D706, MATHEMATICAL ITALIC SMALL LAMBDA) ?? (1D740, MATHEMATICAL BOLD ITALIC SMALL LAMBDA) ?? (1D77A, MATHEMATICAL SANS-SERIF BOLD SMALL LAMBDA) ?? (1D7B0, MATHEMATICAL SANS-SERIF BOLD ITALIC SMALL LAMBDA) What do people think? Would making all these characters lex to behave like a \ be correct behavior? It would still be nice to get the regular BMP greek lambda to have special behavior when to the left of a -> (or equivalent unicode character) but that's a little context-sensitive. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 15 17:09:07 2009 From: trac at galois.com (GHC) Date: Tue Sep 15 16:47:48 2009 Subject: [GHC] #3516: ppc64: broken 'foreign import wrapper' Message-ID: <045.4f80f07ad990ddd6d2b1b0efc839e556@localhost> #3516: ppc64: broken 'foreign import wrapper' -----------------------------+---------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: ffi, wrapper | Testcase: yet Os: Unknown/Multiple | Architecture: powerpc64 -----------------------------+---------------------------------------------- Attaching simple testcase failing horribly on ppc64: amd64 test output: {{{ $ ./dist/build/fct/fct C call:[result = 105] C call with registered C callback function:C(72)C(33)[result = 735] C call with registered Hs-C callback function:H(72)H(33)[result = 735] TEST PASSED }}} ppc64 test output: {{{ $ dist/build/fct/fct C call:[result = 105] C call with registered C callback function:C(72)C(33)[result = 735] C call with registered Hs-C callback function:[result = 105] Segmentation fault }}} As you see '''C call with registered Hs-C callback function''' called not a registered function, but something strange. There is no even registered callback (glo_cb == 0). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 15 17:48:50 2009 From: trac at galois.com (GHC) Date: Tue Sep 15 17:27:30 2009 Subject: [GHC] #3515: Use --make mode by default In-Reply-To: <045.e62049566365cd39a9e7de440d8eeb80@localhost> References: <045.e62049566365cd39a9e7de440d8eeb80@localhost> Message-ID: <054.a4468073c03da479707e72adbf90a89c@localhost> #3515: Use --make mode by default ------------------------------+--------------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Driver | Version: Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by NeilMitchell): Yhc did this, and UHC does this. It's a very sensible idea - people typing command lines at the prompt nearly always want --make, only Makefile's and build systems (or cabal) want to do anything else. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 15 18:02:11 2009 From: trac at galois.com (GHC) Date: Tue Sep 15 17:40:53 2009 Subject: [GHC] #2978: Add support for more characters to UnicodeSyntax In-Reply-To: <045.01e065f460d6968a8d3a0a8de34723f0@localhost> References: <045.01e065f460d6968a8d3a0a8de34723f0@localhost> Message-ID: <054.4879cd816067e4d1549e7540ddf4ad48@localhost> #2978: Add support for more characters to UnicodeSyntax ---------------------------------+------------------------------------------ Reporter: porges | Owner: simonmar Type: feature request | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by pumpkin): * cc: pumpkingod@gmail.com (added) Comment: This is related to #1102 (which I just reopened with some more talk about the options, if anyone's interested) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 15 18:02:33 2009 From: trac at galois.com (GHC) Date: Tue Sep 15 17:41:15 2009 Subject: [GHC] #1102: Lambda unicode character lex In-Reply-To: <047.3274cd2b53d69d61deb3dee313b1b3f5@localhost> References: <047.3274cd2b53d69d61deb3dee313b1b3f5@localhost> Message-ID: <056.05ba5fc887573235f2a7424f797ed127@localhost> #1102: Lambda unicode character lex -----------------------------------------------+---------------------------- Reporter: humasect | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.6.1 Component: Compiler (Parser) | Version: 6.6 Severity: minor | Resolution: Keywords: lambda unicode lexical parse ? | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------------+---------------------------- Changes (by pumpkin): * cc: pumpkingod@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 15 19:55:02 2009 From: trac at galois.com (GHC) Date: Tue Sep 15 19:33:42 2009 Subject: [GHC] #3517: GHC has lots of extra hidden IOErrorType values Message-ID: <045.81ae8140396d0673beafa7c1c19d5515@localhost> #3517: GHC has lots of extra hidden IOErrorType values -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I was fixing bytestring's hGet (see #3514) and I discover that I cannot produce the same exception as System.IO.hGet does in the same circumstance. There are two problems: One is that GHC's internal IOError has more information than one can set via System.IO.Error.mkIOError. In particular it has a function name. The other is that System.IO.hGet throws an `InvalidArgument` `IOErrorType`, however this is not exported and there are no smart constructors or testers for this error type. This is problematic for two reasons, portable code cannot generate these error types to mirror the standard System.IO and secondly no code can actually catch these errors except in a general "catch all" style because they cannot be distinguished from each other. Code that wants to mirror System.IO (like bytestring or utf8-string) has to import GHC.IO.Exception and use cpp to do it differently for hugs and nhc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 15 20:03:26 2009 From: trac at galois.com (GHC) Date: Tue Sep 15 19:42:04 2009 Subject: [GHC] #3514: mallocPlainForeignPtrBytes -1000 gives runtime internal error: allocGroup: requested zero blocks In-Reply-To: <052.f949c738ea0d9d2b66116addc98fdaed@localhost> References: <052.f949c738ea0d9d2b66116addc98fdaed@localhost> Message-ID: <061.8c09b43a67303039b6d6d911ed967af4@localhost> #3514: mallocPlainForeignPtrBytes -1000 gives runtime internal error: allocGroup: requested zero blocks ----------------------------+----------------------------------------------- Reporter: andrewbirkett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 ----------------------------+----------------------------------------------- Comment (by duncan): bytestring hGet is now fixed in the darcs repo. Also audited for other cases in the bytestring package. Looking at the GHC.ForeignPtr code, the following probably need fixing: {{{ mallocForeignPtr mallocForeignPtrBytes mallocPlainForeignPtr mallocPlainForeignPtrBytes }}} In the case of the non-"Bytes" versions that use `Storable`, that'd be a check for the Storable sizeOf function returning a negative value. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 15 23:55:35 2009 From: trac at galois.com (GHC) Date: Tue Sep 15 23:38:19 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.c8bea1b7c65a015b88238fe9163513dd@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by chak): Replying to [comment:25 simonpj]: > Just to add: what we would really like is for someone to step forward as the Maintainer of the X86_64 MacOS port of GHC. Then we really could make it a Tier-1 platform (see http://hackage.haskell.org/trac/ghc/wiki/Platforms). In principle its not hard: > * MacOS is already in one Tier-1 platform (32 bit) > * x86_64 is already in another Tier-1 platform (Linux) > All we need to do is to put the two together -- and some folk are already working on that (#3472). > > But for us to sign up to Tier-1-ness, we need someone (or a small group) to sign up to being the maintainers. > > (Ben recently volunteered to be the maintainer for Sparc; thanks Ben.) > > Simon The way I see it, as soon as GHC works as a 64 bit app on OS X, this will very soon be the main version for OS X and it's the maintenance of the 32 bit version that you need to worry about. I am currently listed (with Wolfgang Taller) as x86 platform maintainer. As soon as there is a 64 bit version of GHC on OS X, I will surely use that (as will most GHC users on Macs). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 00:30:16 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 00:09:05 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.3b2c3e8a26c0a88eae7ca7778ed9190f@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: Type: bug | Status: reopened Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by chak): * status: closed => reopened * version: 6.10.4 => 6.11 * resolution: fixed => * severity: critical => blocker Comment: I just verified that the patch quoted above is not sufficient to build GHC on Snow Leopard. Validate dies on the first file that the stage1 compiler tries to compile. (BTW, GHC does not run in 64 bit mode on SL. It's just that the Apple's compiler tool chain builds 64 bit binaries by default.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 02:25:27 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 02:04:08 2009 Subject: [GHC] #3512: template-hsc.h installed under /usr/share (datadir) In-Reply-To: <050.7896d37f2a18b0c32a408dd87cd7732d@localhost> References: <050.7896d37f2a18b0c32a408dd87cd7732d@localhost> Message-ID: <059.751ed27c22f8ee35bb90f622bd87c984@localhost> #3512: template-hsc.h installed under /usr/share (datadir) --------------------------+------------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Changes (by juhpetersen): * os: Unknown/Multiple => Linux Comment: I haven't tried newer nightlies but I think this is a 6.12 blocker. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 04:19:48 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 03:58:27 2009 Subject: [GHC] #3335: make some Applicative functions into methods, and split off Data.Functor In-Reply-To: <043.088ab986c5172cef4daab943f384779a@localhost> References: <043.088ab986c5172cef4daab943f384779a@localhost> Message-ID: <052.5f1a97cbc4849bee4fd9d8bab97fee1c@localhost> #3335: make some Applicative functions into methods, and split off Data.Functor ---------------------------------+------------------------------------------ Reporter: ross | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by ross): * status: new => closed * resolution: => fixed Comment: There was substantial discussion by 8 people over 2 months. * Making these methods redefinable allows significantly more efficient implementations for some instances (e.g. (<$) for Seq, (*>) and (<*) for parsers Edward Kmett is working on, some and many for first/empty calculations for recursive descent parsers). The same could be achieved by RULES, but these are GHC-only, and relying on the optimizer for asymptotic improvements is dangerous. * Other functions were suggested for the same treatment, but they can be left to another proposal: (**), liftA2 and pair (= liftA2 (,)). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 05:47:12 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 05:25:51 2009 Subject: [GHC] #3515: Use --make mode by default In-Reply-To: <045.e62049566365cd39a9e7de440d8eeb80@localhost> References: <045.e62049566365cd39a9e7de440d8eeb80@localhost> Message-ID: <054.d58e0e211c994c7e841269689c59fe72@localhost> #3515: Use --make mode by default ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Driver | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: => Unknown Comment: Yes, we're wondered about this before For some reason it wasn't straightforward, but I can't remember why now. Perhaps it was just that we'd have to detect when someone is trying to do batch linking. Ah, here's one problem: the `-c` option means "don't link", it's not a "mode" flag as such, and it works just as well with `--make` as in batch mode. So we have an ambiguity with `ghc -c foo.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 05:56:12 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 05:34:51 2009 Subject: [GHC] #3518: GHC GC rises greatly on -N8 compared to -N7 Message-ID: <043.15f71f7e7ae60cc7afd6fed694958d83@localhost> #3518: GHC GC rises greatly on -N8 compared to -N7 -------------------------------------+-------------------------------------- Reporter: nccb | Owner: Type: run-time performance bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------------------------+-------------------------------------- I've recently been benchmarking some parallel code on an 8-core x86 machine. I have graphed performance for -N1 through to -N8, but I often get a huge spike on -N8. I can produce this fairly reliably with the attached program, that simply spawns 8 threads that each spin writing to a TVar. Here is an example of the timings I get: {{{ time ./Main +RTS -N1 real 0m43.697s user 0m43.683s sys 0m0.016s time ./Main +RTS -N4 real 0m24.424s user 1m13.621s sys 0m0.208s time ./Main +RTS -N7 real 0m18.631s user 1m42.778s sys 0m0.260s time ./Main +RTS -N8 real 0m37.859s user 3m38.506s sys 0m0.632s }}} Spot the odd one out! It's not to do with having exactly 8 threads for 8 cores -- I get this problem with ~150 threads on 8 cores. When I run with -s, it seems like the GC is the reason: {{{ time ./Main +RTS -N7 -s 7,313,502,412 bytes allocated in the heap 108,812,664 bytes copied during GC 11,924 bytes maximum residency (100 sample(s)) 61,828 bytes maximum slop 5 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 4207 collections, 0 parallel, 1.18s, 1.17s elapsed Generation 1: 100 collections, 99 parallel, 0.18s, 0.04s elapsed Parallel GC work balance: 3.25 (285256 / 87661, ideal 7) Task 0 (worker) : MUT time: 5.56s ( 11.70s elapsed) GC time: 0.01s ( 0.01s elapsed) Task 1 (worker) : MUT time: 6.65s ( 11.70s elapsed) GC time: 1.16s ( 1.13s elapsed) Task 2 (worker) : MUT time: 0.03s ( 11.70s elapsed) GC time: 0.00s ( 0.00s elapsed) Task 3 (worker) : MUT time: 0.00s ( 11.70s elapsed) GC time: 0.00s ( 0.00s elapsed) Task 4 (worker) : MUT time: 9.93s ( 11.70s elapsed) GC time: 0.01s ( 0.01s elapsed) Task 5 (worker) : MUT time: 6.97s ( 11.70s elapsed) GC time: 0.00s ( 0.00s elapsed) Task 6 (worker) : MUT time: 8.25s ( 11.70s elapsed) GC time: 0.04s ( 0.02s elapsed) Task 7 (worker) : MUT time: 6.79s ( 11.72s elapsed) GC time: 0.00s ( 0.00s elapsed) Task 8 (worker) : MUT time: 3.70s ( 11.70s elapsed) GC time: 0.14s ( 0.03s elapsed) INIT time 0.00s ( 0.00s elapsed) MUT time 61.91s ( 11.70s elapsed) GC time 1.35s ( 1.21s elapsed) EXIT time 0.01s ( 0.02s elapsed) Total time 63.27s ( 12.93s elapsed) %GC time 2.1% (9.4% elapsed) Alloc rate 118,112,344 bytes per MUT second Productivity 97.9% of total user, 478.9% of total elapsed recordMutableGen_sync: 383 gc_alloc_block_sync: 2 whitehole_spin: 0 gen[0].steps[0].sync_todo: 0 gen[0].steps[0].sync_large_objects: 0 gen[0].steps[1].sync_todo: 16 gen[0].steps[1].sync_large_objects: 0 gen[1].steps[0].sync_todo: 175 gen[1].steps[0].sync_large_objects: 0 real 0m12.933s user 1m3.276s sys 0m0.248s time ./Main +RTS -N8 -s 7,316,581,044 bytes allocated in the heap 153,424,584 bytes copied during GC 11,964 bytes maximum residency (132 sample(s)) 65,916 bytes maximum slop 6 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 4711 collections, 4711 parallel, 136.08s, 21.38s elapsed Generation 1: 132 collections, 132 parallel, 6.12s, 0.93s elapsed Parallel GC work balance: 1.01 (38276826 / 38012855, ideal 8) Task 0 (worker) : MUT time: 0.00s ( 14.56s elapsed) GC time: 30.31s ( 4.74s elapsed) Task 1 (worker) : MUT time: 0.00s ( 14.56s elapsed) GC time: 25.09s ( 3.68s elapsed) Task 2 (worker) : MUT time: 0.00s ( 14.56s elapsed) GC time: 0.09s ( 0.01s elapsed) Task 3 (worker) : MUT time: 0.00s ( 14.56s elapsed) GC time: 0.00s ( 0.00s elapsed) Task 4 (worker) : MUT time: 0.98s ( 14.56s elapsed) GC time: 7.62s ( 1.17s elapsed) Task 5 (worker) : MUT time: 0.00s ( 14.56s elapsed) GC time: 13.09s ( 2.01s elapsed) Task 6 (worker) : MUT time: 5.81s ( 14.56s elapsed) GC time: 1.92s ( 0.28s elapsed) Task 7 (worker) : MUT time: 0.00s ( 14.56s elapsed) GC time: 25.12s ( 4.24s elapsed) Task 8 (worker) : MUT time: 0.95s ( 14.56s elapsed) GC time: 8.01s ( 1.20s elapsed) Task 9 (worker) : MUT time: 0.00s ( 14.56s elapsed) GC time: 30.94s ( 4.98s elapsed) INIT time 0.00s ( 0.00s elapsed) MUT time 65.37s ( 14.56s elapsed) GC time 142.20s ( 22.31s elapsed) EXIT time 0.00s ( 0.01s elapsed) Total time 207.57s ( 36.87s elapsed) %GC time 68.5% (60.5% elapsed) Alloc rate 111,922,106 bytes per MUT second Productivity 31.5% of total user, 177.3% of total elapsed recordMutableGen_sync: 597 gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].steps[0].sync_todo: 0 gen[0].steps[0].sync_large_objects: 0 gen[0].steps[1].sync_todo: 35296 gen[0].steps[1].sync_large_objects: 0 gen[1].steps[0].sync_todo: 557515 gen[1].steps[0].sync_large_objects: 0 real 0m36.873s user 3m27.569s sys 0m0.524s }}} See how the GC goes from 1s to 142s, just by virtue of -N8 instead of -N7. Increasing the heap size seems to alleviate the problem, but the difference is so severe (and unexpected, at least to me) that I thought I'd file a ticket. I am happy to try other flags if you want. This is all on GHC 6.10.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 06:23:22 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 06:03:05 2009 Subject: [GHC] #2965: GHC on OS X does not compile 64-bit In-Reply-To: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> References: <045.2214e7d1fe4dd43486128c197fdb9227@localhost> Message-ID: <054.726ac5156b3f7962da5f276c724be220@localhost> #2965: GHC on OS X does not compile 64-bit --------------------------------+------------------------------------------- Reporter: Axman6 | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | --------------------------------+------------------------------------------- Comment (by simonmar): I've removed Wolfgang as maintainer, as we haven't heard from him in a long time. That leaves you ;-) Any other interested maintainers, please add yourselves: [wiki:Contributors]. Bear in mind that the 64-bit build will use twice as much memory, so I can imagine some people might still want the 32-bit version, especially since a large proportion of OS X machines are laptops. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 06:26:07 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 06:04:58 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.e52a21e81ea83a33c4628ba01f9b13c7@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 06:26:18 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 06:05:10 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.c0713032eecac0836d85db875d29cff8@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: Type: bug | Status: reopened Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 07:00:18 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 06:38:58 2009 Subject: [GHC] #3518: GHC GC rises greatly on -N8 compared to -N7 In-Reply-To: <043.15f71f7e7ae60cc7afd6fed694958d83@localhost> References: <043.15f71f7e7ae60cc7afd6fed694958d83@localhost> Message-ID: <052.d1b042cf2435fafe61e464931e19e2ca@localhost> #3518: GHC GC rises greatly on -N8 compared to -N7 --------------------------------------+------------------------------------- Reporter: nccb | Owner: Type: run-time performance bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 --------------------------------------+------------------------------------- Comment (by NeilMitchell): I've seen this too. At -N8 some extra parallelism kicks in with the garbage collector, which destroys everything. The parallel GC in 6.12 is far better, so this issue will be obsolete then. Until then, I always pass {{{-N8 -g1}}} which turns off parallel GC and makes everything much faster again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 07:20:48 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 06:59:28 2009 Subject: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS In-Reply-To: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> References: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> Message-ID: <053.018cffdd742c727bb0c717bd4f053291@localhost> #698: GHC's internal memory allocator never releases memory back to the OS ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by NeilMitchell): * cc: ndmitchell@gmail.com (added) Comment: This issue is much more important now we have dll's. Imagine a program that calls out to a Haskell dll, and then returns some result. If the intermediate computation uses 200Mb of RAM then after returning it's very easy to have 200Mb of heap with virtually nothing in it. The argument that other Haskell bit's will soon reuse that heap is also less valid with dll's, as the main program will not be sharing the same heap. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 07:36:06 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 07:14:44 2009 Subject: [GHC] #3519: ghc: panic! (the 'impossible' happened) Message-ID: <044.f7668c50f47c7fd7a6c1b6746ff0381d@localhost> #3519: ghc: panic! (the 'impossible' happened) -------------------+-------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Severity: minor Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- $ ghci Main.hs GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): getOptions'.parseLanguage(1) went past eof token Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 08:43:04 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 08:21:43 2009 Subject: [GHC] #3518: GHC GC rises greatly on -N8 compared to -N7 In-Reply-To: <043.15f71f7e7ae60cc7afd6fed694958d83@localhost> References: <043.15f71f7e7ae60cc7afd6fed694958d83@localhost> Message-ID: <052.47dce7e50e217b3dd0c2dc07642ba115@localhost> #3518: GHC GC rises greatly on -N8 compared to -N7 -----------------------------------------+---------------------------------- Reporter: nccb | Owner: Type: run-time performance bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: This is fixed in 6.12.1. Please re-open if you still have problems with 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 09:29:06 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 09:07:56 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.7ccfbd2676db1c9094519a78f88645a1@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: chak Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by chak): * status: reopened => new * owner: => chak -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 09:56:09 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 09:34:50 2009 Subject: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS In-Reply-To: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> References: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> Message-ID: <053.0857b65658615d4815b3e198b49b63bc@localhost> #698: GHC's internal memory allocator never releases memory back to the OS ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * os: Linux => Unknown/Multiple Comment: I'm happy to provide pointers to anyone that wants to work on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 10:12:35 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 09:51:14 2009 Subject: [GHC] #3520: Implement Type and Pattern splicing Message-ID: <045.112ef03cd36b7e21ad673f8919fc0720@localhost> #3520: Implement Type and Pattern splicing -----------------------------+---------------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Component: Template Haskell Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- These are part of the proposal but do not exist in the current implementation, unless the docs are lying to me :) Pattern splicing is sort-of available via QuasiQuotes by not via "normal" TH. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 11:42:41 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 11:21:19 2009 Subject: [GHC] #3521: ld on mac won't allow -rpath unless you specify macosx_version_min 10.5 Message-ID: <046.0e41e1dd06acd0a37310a8fbecfb0663@localhost> #3521: ld on mac won't allow -rpath unless you specify macosx_version_min 10.5 --------------------+------------------------------------------------------- Reporter: mwotton | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- when trying to build a Haskell shared library on Mac OS X, linking fails with this error: ld: -rpath can only be used when targeting Mac OS X 10.5 or later this can be tracked down to the DriverPipeline.hs specifying macosx_version_min to be 10.3. This can be hacked around by passing 10.5 again, but is a bit fragile because ld on Mac takes the last version specified rather than the highest. There may be good reasons to retain <10.5 compatibility, but from IRC conversation with JaffaCake, ghc depends on 10.5 anyway, so this _should_ make no difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 13:41:17 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 13:19:55 2009 Subject: [GHC] #3522: conflicting Block.h on Snow Leopard Message-ID: <046.bbfe1f02e1bc5b8ae526903c9a7cbe3a@localhost> #3522: conflicting Block.h on Snow Leopard --------------------+------------------------------------------------------- Reporter: PaulLiu | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (FFI) Version: 6.10.4 | Severity: critical Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- Using GHC to compile C programs that includes will result in the following error: {{{ In file included from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/FSEvents.h:28, from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:218, from /System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20, from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:21, from test.c:1:0: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/include/Block.h:51:0: error: expected specifier-qualifier-list before ?StgPtr? ... }}} This is because somewhere down !CoreServices.h it includes Block.h, and expects it to be /usr/include/Block.h, which is a new file introduced since Snow Leopard (OS X 10.6). This is in direct conflict to the Block.h under GHC's include directory, which is somehow searched prior to the system directory. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 16:18:08 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 15:56:49 2009 Subject: [GHC] #1246: <= operators get compiled worse than == In-Reply-To: <045.b185d0777432d5c415c62f24c2ea15b7@localhost> References: <045.b185d0777432d5c415c62f24c2ea15b7@localhost> Message-ID: <054.63769e273a75c9925ae29059cbc40af3@localhost> #1246: <= operators get compiled worse than == -------------------------+-------------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * milestone: 6.12 branch => 6.14.1 Comment: To look at with the new codegen. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 16:22:29 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 16:01:11 2009 Subject: [GHC] #1498: Optimisation: eliminate unnecessary heap check in recursive function In-Reply-To: <047.d854a286f40f24efedada1697ad637ee@localhost> References: <047.d854a286f40f24efedada1697ad637ee@localhost> Message-ID: <056.18daf8de4913479e39e6abcb1e12eb68@localhost> #1498: Optimisation: eliminate unnecessary heap check in recursive function ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: 6.12 branch => 6.14.1 Comment: Another new codegen task. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 16:50:28 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 16:29:07 2009 Subject: [GHC] #1856: Improve error message for mutally recursive modules In-Reply-To: <044.c1a763269283b1196744ff64014c853b@localhost> References: <044.c1a763269283b1196744ff64014c853b@localhost> Message-ID: <053.dd46ff45083fa85952276efad029e55a@localhost> #1856: Improve error message for mutally recursive modules ------------------------------------------------------------+--------------- Reporter: guest | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: Modules Recursively Imported Error Messages | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------------------------------------------+--------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 22:42:34 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 22:21:16 2009 Subject: [GHC] #3471: configure fails for GHC 6.10.4 on Mac OS X 10.6 in 64-bit mode with previously-built GHC In-Reply-To: <049.cf9489a341286e2ed7b3a5f6baf71d74@localhost> References: <049.cf9489a341286e2ed7b3a5f6baf71d74@localhost> Message-ID: <058.86467f64f2a8cfe4f6e9c1326078bd4a@localhost> #3471: configure fails for GHC 6.10.4 on Mac OS X 10.6 in 64-bit mode with previously-built GHC ------------------------------+--------------------------------------------- Reporter: paulrbrown | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Severity: normal | Resolution: duplicate Keywords: configure | Testcase: Os: Unknown/Multiple | Architecture: x86 ------------------------------+--------------------------------------------- Changes (by chak): * status: new => closed * resolution: => duplicate Comment: This is not a problem with the GHC you are trying to build, but with the ghc from 10.5 that you try to use for bootstrapping. To use a GHC built on 10.5 on 10.6, you need to edit `/usr/bin/ghc` and add the flags `-optc-m32 -opta-m32 -optl-m32`. I attach the edited `/usr/bin/ghc` for GHC 6.10.4 if you just want to copy that. I'll close this ticket as it's a duplicate of #3400. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 16 23:38:39 2009 From: trac at galois.com (GHC) Date: Wed Sep 16 23:17:23 2009 Subject: [GHC] #3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger) In-Reply-To: <047.37055053b1160c638a5374c844089d6a@localhost> References: <047.37055053b1160c638a5374c844089d6a@localhost> Message-ID: <056.3fdaed021edef1e723a66718edf56f0e@localhost> #3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger) ---------------------------------+------------------------------------------ Reporter: bkomuves | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Build System | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by chak): * severity: major => minor Comment: I have been trying to enable building a compiler on 10.5 that can produce binaries for 10.4 and 10.5. (This is what the deployment target option of ./configure is for.) It is working to some degree, but I never managed to get it to fully boostrap (ie, so that I can build a compiler on 10.5 that also runs on 10.4). It requires a quite a bit of fiddling with linker options and similar and I found it hard to debug when it doesn't work (maybe due to my limited Mac dev experience. In any case, this is hard to do and really requires somebody with detailed knowledge of the mac os linker. (My changes were in the old build system, not sure how mangled they got in the new one.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 01:54:54 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 01:33:35 2009 Subject: [GHC] #2790: Use -fregs-graph by default In-Reply-To: <044.e23cb1a138a9b4ed2c315b0444e4b3fc@localhost> References: <044.e23cb1a138a9b4ed2c315b0444e4b3fc@localhost> Message-ID: <053.1ea9b963bb367b48bedf8bf1cb0ea1d0@localhost> #2790: Use -fregs-graph by default ---------------------------------+------------------------------------------ Reporter: igloo | Owner: benl Type: task | Status: assigned Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by benl): Ok, the reason the graph allocator is so slow now is because I broke it when I split NCG/MachCodeGen into architecture specific modules. When I did that I moved the SPILL and RELOAD meta-instructions into Liveness.hs/LiveInstr. In doing so I made it so the spill cleaner never gets a chance to clean them.. so if any virtual reg needs to be spilled, there ends up being a spill/reload instruction after/before every use. I didn't pick it up at the time because it all still _works_, there just ends up being more spill/reloads than needed. I'm working on a fix, but it probably won't be done for the RC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 04:13:25 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 03:52:00 2009 Subject: [GHC] #3523: Dead link in "7.2. Unboxed types and primitive operations" documentation Message-ID: <044.839c579a35992317824989ad262d2b8d@localhost> #3523: Dead link in "7.2. Unboxed types and primitive operations" documentation -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- On http://www.haskell.org/ghc/docs/latest/html/users_guide/primitives.html The link with the anchor text "detailed online documentation" pointing to http://www.haskell.org/ghc/docs/latest/html/libraries/base/GHC.Prim.html is dead. The correct URL is http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim/GHC- Prim.html -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 04:31:40 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 04:10:20 2009 Subject: [GHC] #3522: conflicting Block.h on Snow Leopard In-Reply-To: <046.bbfe1f02e1bc5b8ae526903c9a7cbe3a@localhost> References: <046.bbfe1f02e1bc5b8ae526903c9a7cbe3a@localhost> Message-ID: <055.4f935c09e5894692120c6918fa20c3f2@localhost> #3522: conflicting Block.h on Snow Leopard -------------------------------+-------------------------------------------- Reporter: PaulLiu | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (FFI) | Version: 6.10.4 Severity: critical | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: `Block.h` is now `rts/storage/Block.h` in 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 04:35:36 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 04:14:14 2009 Subject: [GHC] #3523: Dead link in "7.2. Unboxed types and primitive operations" documentation In-Reply-To: <044.839c579a35992317824989ad262d2b8d@localhost> References: <044.839c579a35992317824989ad262d2b8d@localhost> Message-ID: <053.b0938259a99da9d3b8296c36f88af0e3@localhost> #3523: Dead link in "7.2. Unboxed types and primitive operations" documentation ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: This has been fixed in 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 04:37:30 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 04:16:10 2009 Subject: [GHC] #2790: Use -fregs-graph by default In-Reply-To: <044.e23cb1a138a9b4ed2c315b0444e4b3fc@localhost> References: <044.e23cb1a138a9b4ed2c315b0444e4b3fc@localhost> Message-ID: <053.b18673476bd837d512a5a9983a7a0057@localhost> #2790: Use -fregs-graph by default ---------------------------------+------------------------------------------ Reporter: igloo | Owner: benl Type: task | Status: assigned Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: 6.12.1 => 6.14.1 Comment: Let's push this out to 6.14.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 05:35:12 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 05:13:49 2009 Subject: [GHC] #3512: template-hsc.h installed under /usr/share (datadir) In-Reply-To: <050.7896d37f2a18b0c32a408dd87cd7732d@localhost> References: <050.7896d37f2a18b0c32a408dd87cd7732d@localhost> Message-ID: <059.a11887139a3caf2d1e07b0927f188db1@localhost> #3512: template-hsc.h installed under /usr/share (datadir) ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 05:35:21 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 05:13:57 2009 Subject: [GHC] #3512: template-hsc.h installed under /usr/share (datadir) In-Reply-To: <050.7896d37f2a18b0c32a408dd87cd7732d@localhost> References: <050.7896d37f2a18b0c32a408dd87cd7732d@localhost> Message-ID: <059.0a4b96732c64609581d358ef218f89b1@localhost> #3512: template-hsc.h installed under /usr/share (datadir) ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 06:05:46 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 05:44:33 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.4c2904f573b21c4d55e2f1b9610d1d82@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: chak Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by chak): Just pushed {{{ Thu Sep 17 14:41:21 EST 2009 Manuel M T Chakravarty * Fix build on Mac OS 10.6 (Snow Leopard) - We have -m32 as machine-dependent option for gcc for a 32 bit build - Like on OpenBSD, SL requires -fno-stack-protector to avoid triggering the stack smashing checks inserted by gcc by default on this platform. }}} which fixes the build on SL and also validates on Leopard. NB: This fixes the build. However, the testsuite doesn't work as SL comes with Python 2.6.1, which apparently has a bug in on of its libraries that is tickled by GHC's testsuite. The error message is {{{ Traceback (most recent call last): File "../../driver/runtests.py", line 112, in maj = int(re.sub('[^0-9].*', '', maj)) File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/re.py", line 150, in sub return _compile(pattern, 0).sub(repl, string, count) TypeError: expected string or buffer }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 06:55:19 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 06:33:56 2009 Subject: [GHC] #3512: template-hsc.h installed under /usr/share (datadir) In-Reply-To: <050.7896d37f2a18b0c32a408dd87cd7732d@localhost> References: <050.7896d37f2a18b0c32a408dd87cd7732d@localhost> Message-ID: <059.97730babbc139b4aa864056f8695b93f@localhost> #3512: template-hsc.h installed under /usr/share (datadir) ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed {{{ Thu Sep 17 02:39:14 PDT 2009 Simon Marlow * put template-hsc.h in $(topdir) in an installation (on Unix) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 10:06:37 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 09:45:24 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.81beb7f1c72e4a1a09a52ae39ddc61b6@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: chak Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: The testsuite works now. Five tests are currently failing: {{{ Unexpected failures: TH_repE2(normal) TH_repPrim(normal) ann01(normal) ffi018_ghci(ghci) prog002(ghci) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 10:17:55 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 09:56:31 2009 Subject: [GHC] #2324: Data.Tree.Zipper in containers package In-Reply-To: <049.73ff21dd84d1ae329478d35cb5f6f5ed@localhost> References: <049.73ff21dd84d1ae329478d35cb5f6f5ed@localhost> Message-ID: <058.9896cfb2f359d21223b4ea65177c02d2@localhost> #2324: Data.Tree.Zipper in containers package ----------------------------------+----------------------------------------- Reporter: kr.angelov | Owner: kr.angelov Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by ross): * status: new => closed * resolution: => wontfix Comment: Several people argued for developing this as a separate package. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 10:55:36 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 10:34:15 2009 Subject: [GHC] #3453: Add "check" function to Control.Monad In-Reply-To: <051.70447cf639e8d603bf0c4d32cf8a4684@localhost> References: <051.70447cf639e8d603bf0c4d32cf8a4684@localhost> Message-ID: <060.8b527ad6b35b732917fdccb8b6f86215@localhost> #3453: Add "check" function to Control.Monad ---------------------------------+------------------------------------------ Reporter: JonFairbairn | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by JonFairbairn): I suspect the consensus on this is not to add this function, but to add mfilter instead. I'll open a separate ticket for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 11:03:10 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 10:41:50 2009 Subject: [GHC] #3524: Add mfilter to Control.Monad Message-ID: <051.0391717d448955e9ccc2e936d0523bd6@localhost> #3524: Add mfilter to Control.Monad -----------------------------+---------------------------------------------- Reporter: JonFairbairn | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- In the comments of #3453, I contemplated a filter function on MonadPlus. The consensus seems to be that this function is an appropriate addition. mfilter is just List.filter generalised to any MonadPlus. It must have been embodied in Monad comprehensions when we had those, so I'm sure it's simply an oversight that it hasn't been included here already. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 13:36:07 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 13:14:50 2009 Subject: [GHC] #3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger) In-Reply-To: <047.37055053b1160c638a5374c844089d6a@localhost> References: <047.37055053b1160c638a5374c844089d6a@localhost> Message-ID: <056.278a8f4357387eb42f0cc6b0715d0fa5@localhost> #3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger) ---------------------------------+------------------------------------------ Reporter: bkomuves | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Build System | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by bkomuves): I managed to build binaries on 10.5 which work on 10.4, however the solution was very hackish. In theory it is quite simple, but it needs knowledge about the ghc build system (which I don't have). What I did was the following: I recompiled the runtime system and the base library with passing the appropriate flags to gcc and the linker. These flags are listed on thread linked above. (I think the Unix library also has to be rebuild, but my program did not depend on it; and maybe some other fundamental libraries, but not many). After this, I have to pass the same flags when building my program, and then it will work on both 10.4 and 10.5 (if I don't pass the flags, it will still work on 10.5). The build system (this was with ghc 6.10.1, so I think that's the old build system) had in fact some infrastructure in it for doing exactly this, but it seems to be bitrotten, as it worked only for the runtime system, iirc (or maybe I made some mistakes, as I didn't build a full ghc). So I just patched manually various configure files and whatnot, very brute-force, but it worked. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 13:47:23 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 13:26:03 2009 Subject: [GHC] #3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger) In-Reply-To: <047.37055053b1160c638a5374c844089d6a@localhost> References: <047.37055053b1160c638a5374c844089d6a@localhost> Message-ID: <056.8dcf6de736bb6fc9d18e8dc7d7065007@localhost> #3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger) ---------------------------------+------------------------------------------ Reporter: bkomuves | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Build System | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by bkomuves): For reference, I think that the relevant flags are: {{{ -mmacosx-version-min=10.4 }}} for the compiler (that is, `gcc`), and {{{ -syslibroot /Developer/SDKs/MacOSX10.4u.sdk/ -macosx_version_min 10.4 -F/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks }}} for the linker (that is, `ld`, except when `gcc` is the linker, too...). Some of these may be superfluous. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 17:10:35 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 16:49:11 2009 Subject: [GHC] #3525: current dist source fail to build when Happy not found Message-ID: <047.e8d0b13e09f92e12644f76e9ae08b142@localhost> #3525: current dist source fail to build when Happy not found -----------------------------+---------------------------------------------- Reporter: kristerw | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The daily source tarballs from http://www.haskell.org/ghc/dist/current/dist/ errors out at configure time if Happy is not found. This error was introduced in the ghc-6.11.20090913-src.tar.bz2 source. A workaround to make it compile is to modify the configure script as: --- configure.orig 2009-09-17 23:07:01.000000000 +0200 +++ configure 2009-09-17 23:07:39.000000000 +0200 @@ -5605,7 +5605,7 @@ fi { echo "$as_me:$LINENO: result: $fptools_cv_happy_version" >&5 echo "${ECHO_T}$fptools_cv_happy_version" >&6; } -if test ! -f compiler/parser/Parser.hs || test ! -f compiler/main/ParsePkgConf.hs || test ! -f compiler/cmm/CmmParse.hs || test ! -f compiler/parser/ParserCore.hs +if test ! -f compiler/parser/Parser.hs || test ! -f compiler/cmm/CmmParse.hs || test ! -f compiler/parser/ParserCore.hs then fp_version1=$fptools_cv_happy_version; fp_version2=1.16 fp_save_IFS=$IFS; IFS='.' -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 17 20:28:19 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 20:06:59 2009 Subject: [GHC] #3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger) In-Reply-To: <047.37055053b1160c638a5374c844089d6a@localhost> References: <047.37055053b1160c638a5374c844089d6a@localhost> Message-ID: <056.d3b952b2d967698dbf72a8b6ae22f97d@localhost> #3354: binaries built with GHC on Mac OS X 10.5 (Leopard) do not work on 10.4 (Tiger) ---------------------------------+------------------------------------------ Reporter: bkomuves | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Build System | Version: 6.10.1 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by chak): Yes, that's what I did, too. Unfortunately, when you use such a compiler to compile GHC itself, then that GHC doesn't work on 10.4. You may want to try that yourself. In other words, this approach does work to some degree, but I couldn't get it to work for all programs (i.e., not for compiling GHC itself, which means other programs probably also break if they use the right features). -- Ticket URL: GHC The Glasgow Haskell Compiler From chak at cse.unsw.edu.au Thu Sep 17 20:56:15 2009 From: chak at cse.unsw.edu.au (Manuel M T Chakravarty) Date: Thu Sep 17 20:34:54 2009 Subject: #3485: "Illegal type synonym family application in instance" error is unnecessary, should be removed In-Reply-To: <1252873307.5134.9.camel@glastonbury> References: <053.3893e570e78fa71dd6ee013e3e60e14c@localhost> <062.68df8bca19f0c08f167b7d4a9ff44d96@localhost> <4AA57B68.6030806@semantic.org> <1252873307.5134.9.camel@glastonbury> Message-ID: Ashley Yakeley: > On Mon, 2009-09-14 at 00:40 +1000, Manuel M T Chakravarty wrote: >>> I don't see what the problem is. "instance C (Fam Int)" has an >>> unambiguous, and logically acceptable, meaning to the compiler. Why >>> do we force the programmer to make an ugly workaround involving >>> introducing a type variable? >> >> I think the proposed change is confusing. Two instances >> >> instance C (Fam Int) >> instance C (Fam Bool) >> >> appear to be syntactically distinct, but they semantically overlap. >> The explicit form >> >> instance (Fam Int ~ famint) => C famint >> >> is IMHO much clearer and really not much more verbose. > > It's really no different from this > > type Syn a = () > > instance C (Syn Int) > instance C (Syn Bool) It's quite different. A type synonym can always be unfolded. That is not the case for a type family; e.g., type family F a type instance F [Int] = ... instance C (F [a]) Whereas `instance C (Syn Int)' is synonymous to `instance C ()', there is no such "normal form" for `instance C (F [a])'. This is a fundamental difference between type synonyms and type families and the reason for most of the restrictions that we impose on type families over type synonyms (e.g., synonyms may be partially applied in some situations, whereas families may never be applied partially). Manuel From trac at galois.com Thu Sep 17 21:25:15 2009 From: trac at galois.com (GHC) Date: Thu Sep 17 21:03:49 2009 Subject: [GHC] #3526: Inliner behaviour with instances is confusing Message-ID: <042.8258495ea2dc159620716346effd3b92@localhost> #3526: Inliner behaviour with instances is confusing -----------------------------+---------------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I have a fairly simple typeclass: {{{ class Variate a where uniform :: Gen s -> ST s a }}} With instances like this: {{{ instance Variate Int8 where uniform = f where f = uniform1 fromIntegral {-# INLINE f #-} uniform1 :: (Word32 -> a) -> Gen s -> ST s a uniform1 f gen = do i <- uniformWord32 gen return $! f i {-# INLINE uniform1 #-} }}} Notice the peculiar form of the instance definition. I had to write the above instead of the more intuitive form: {{{ instance Variate Int8 where uniform = uniform1 fromIntegral {-# INLINE uniform #-} }}} With the more obvious form, GHC's inliner didn't fire at all for this, and I was unable to tell why. It was Duncan who suggested the more convoluted instance above. The result is about a 3x performance difference sometimes, so this has a noticeable effect. I'm not completely sure that this is a bug, but I don't know how to describe why one form works and the other doesn't, so the compiler's behaviour is surprising to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 18 06:45:24 2009 From: trac at galois.com (GHC) Date: Fri Sep 18 06:23:58 2009 Subject: [GHC] #3525: current dist source fail to build when Happy not found In-Reply-To: <047.e8d0b13e09f92e12644f76e9ae08b142@localhost> References: <047.e8d0b13e09f92e12644f76e9ae08b142@localhost> Message-ID: <056.120f292869ac2a9146707f0765aecd9b@localhost> #3525: current dist source fail to build when Happy not found ---------------------------------+------------------------------------------ Reporter: kristerw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown Comment: Thanks, I'll push. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 18 07:44:13 2009 From: trac at galois.com (GHC) Date: Fri Sep 18 07:22:45 2009 Subject: [GHC] #3527: unGetChan should be able to interrupt readChan Message-ID: <044.f53eb16287d724b9256e806dae312235@localhost> #3527: unGetChan should be able to interrupt readChan -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- If you are in the following situation: * A empty Chan shared between two threads * Another thread blocked reading the Chan * A main thread about to unGetChan to add something to its front Then the program will shortly die with "thread blocked indefinitely". The reason is that the thread doing readChan is modifying the read MVar of the Chan. This means that when unGetChan tries to modify it as well, the main thread blocks and nothing can make progress... A workaround (that sort of works for my situation) is to forkIO the unGetChan, so the main thread can continue going and write something to the channel at some point in the future. When that happens one of the unGetChan and readChan will be able to make progress. One of these two things needs to happen: * Better documentation for unGetChan, in particular WRT how it can experience this behaviour but writeChan cannot * A smarter implementation for getChan that allows its wait on the MVar to be serviced by an unGetChan Test program that demonstrates the problem: {{{ $ ghc --make Control/Concurrent/Benchmark/StressTest.hs && Control/Concurrent/Benchmark/StressTest.exe [1 of 1] Compiling Main ( Control\Concurrent\Benchmark\StressTest.hs, Control\Concurrent\Benchmark\StressTest.o ) Linking Control\Concurrent\Benchmark\StressTest.exe ... 1 Acting Done acting Writing readChan thread blocked indefinitely join Control.Concurrent.Parallel: parallel thread died. thread blocked indefinitely Exception on thread: Control.Concurrent.Parallel: parallel thread died. Control.Concurrent.Parallel: parallel thread died. thread blocked indefinitely StressTest.exe: thread blocked indefinitely }}} {{{ {-# LANGUAGE ScopedTypeVariables #-} import Control.Concurrent import Control.Monad import System.Random import GHC.Conc -------------------------- -- LIBRARY -- Much of the details in this module arose from discussions on haskell- cafe@ -- http://www.nabble.com/Parallel-combinator%2C-performance-advice- td22926243.html -- NB: this is modified from the "real" version for extra debuggability and simplicity {- REQUIREMENTS: * Fairness - the number of threads executing at any one time should be exactly the number specified (N). There should never be either N+1 or N-1 executing. * Reenterant - parallel_ computations can call other parallel_ computations. * Timeliness - it's best to stop as soon as the last task has finished, provided that doesn't violate the other principles. -} import GHC.Conc import Control.Concurrent import Control.Monad import Control.Exception as E import System.IO.Unsafe -- initialise on the main thread, and keep {-# NOINLINE mainThread #-} mainThread :: ThreadId mainThread = unsafePerformIO $ myThreadId -- True = kill the thread after it finishes {-# NOINLINE queue #-} queue :: Chan (IO Bool) queue = seq mainThread $ unsafePerformIO $ newChan {-# NOINLINE addWorker #-} addWorker :: IO () addWorker = do forkIO $ handle_exceptions "Exception on thread:" f return () where handle_exceptions :: String -> IO a -> IO a handle_exceptions str act = act `E.catch` \(e :: SomeException) -> do putStrLn $ str ++ " " ++ show e throwTo mainThread $ ErrorCall $ "Control.Concurrent.Parallel: parallel thread died.\n" ++ show e return (error "handle_exceptions") {-# NOINLINE f #-} f :: IO () f = do --putStrLn "Working" kill <- handle_exceptions "join" $ join $ handle_exceptions "readChan" $ readChan queue --putStrLn $ "Dying? " ++ show kill unless kill f -- If you don't call this then no one holds the queue, the queue gets -- GC'd, the threads find themselves blocked indefinately, and you get -- exceptions. This cleanly shuts down the threads, then the queue isn't important. -- Only call this AFTER all parallel_ calls have completed. {-# NOINLINE parallelStop #-} parallelStop :: IO () parallelStop = evaluate queue >> return () -- | Run the list of computations in parallel -- Rule: No thread should get pre-empted (although not a guarantee) -- On return all actions have been performed {-# NOINLINE parallel_ #-} parallel_ :: [IO a] -> IO () parallel_ xs = sequence_ xs {-# NOINLINE parallelBlock #-} parallelBlock :: IO a -> IO a parallelBlock act = E.bracket_ addWorker (putStrLn "Writing" >> unGetChan queue (return True) >> putStrLn "Done writing") (putStrLn "Acting" >> act >>= \x -> putStrLn "Done acting" >> return x) parallelReadMVar :: MVar a -> IO a parallelReadMVar = parallelBlock . readMVar --------------------------- -- TEST PROGRAM n :: Int n = 1000 randomDelay :: IO () randomDelay = do delay <- randomRIO (0, 100) threadDelay delay process :: MVar a -> IO () process m = do randomDelay p <- randomRIO (0, 1 :: Double) when (p < 0.4) (parallelReadMVar m >> return ()) randomDelay main :: IO () main = do print numCapabilities m <- newMVar () parallel_ $ replicate n $ process m parallelStop }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 18 07:44:56 2009 From: trac at galois.com (GHC) Date: Fri Sep 18 07:23:28 2009 Subject: [GHC] #3525: current dist source fail to build when Happy not found In-Reply-To: <047.e8d0b13e09f92e12644f76e9ae08b142@localhost> References: <047.e8d0b13e09f92e12644f76e9ae08b142@localhost> Message-ID: <056.cccb74e41234f04db563cf6a78507c04@localhost> #3525: current dist source fail to build when Happy not found ---------------------------------+------------------------------------------ Reporter: kristerw | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * component: Compiler => Build System * resolution: => fixed * milestone: => 6.12.1 Comment: Fixed {{{ Fri Sep 18 11:43:27 BST 2009 Simon Marlow * Fix #3525 - we were still checking for ParsePkgConf.hs, which is gone }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 18 08:23:45 2009 From: trac at galois.com (GHC) Date: Fri Sep 18 08:02:18 2009 Subject: [GHC] #3439: Improve the setup for ticky In-Reply-To: <046.97ec1b5f2b20c06c8559b26055a95a61@localhost> References: <046.97ec1b5f2b20c06c8559b26055a95a61@localhost> Message-ID: <055.513234f30b594f5fcd2ceb841f0ded31@localhost> #3439: Improve the setup for ticky ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Fixed {{{ Fri Sep 18 12:46:31 BST 2009 Simon Marlow * Fix #3439: -debug implies -ticky, and -ticky code links with any RTS }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 18 08:28:39 2009 From: trac at galois.com (GHC) Date: Fri Sep 18 08:07:12 2009 Subject: [GHC] #1856: Improve error message for mutally recursive modules In-Reply-To: <044.c1a763269283b1196744ff64014c853b@localhost> References: <044.c1a763269283b1196744ff64014c853b@localhost> Message-ID: <053.9c476c4467ae0329a9b2da02bc86aec3@localhost> #1856: Improve error message for mutally recursive modules ------------------------------------------------------------+--------------- Reporter: guest | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: Modules Recursively Imported Error Messages | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------------------------------------------+--------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Done {{{ Wed Sep 16 13:50:36 PDT 2009 Simon Marlow * improve the cyclic module error message as per #1856 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 18 09:08:50 2009 From: trac at galois.com (GHC) Date: Fri Sep 18 08:47:23 2009 Subject: [GHC] #1136: High memory use when compiling many let bindings. In-Reply-To: <044.2f9aae100a9caba688d31e410efb3444@localhost> References: <044.2f9aae100a9caba688d31e410efb3444@localhost> Message-ID: <053.59653688118ccec15c535e555e3b5376@localhost> #1136: High memory use when compiling many let bindings. ---------------------------------------------+------------------------------ Reporter: igloo | Owner: simonmar Type: compile-time performance bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.6 Severity: normal | Resolution: fixed Keywords: performance | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: I think this is now fixed. With 6.11.today, on x86_64, J compiles in 6s using 106MB, J2 compiles in 16s using 84MB. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 18 09:53:38 2009 From: trac at galois.com (GHC) Date: Fri Sep 18 09:32:12 2009 Subject: [GHC] #2881: Basic Fibonacci function using Word causes ghci to panic. - 6.10.1 In-Reply-To: <045.420cfc29b1544ee41369697a28301360@localhost> References: <045.420cfc29b1544ee41369697a28301360@localhost> Message-ID: <054.b8536f23ec0dcf360b18f6ba72eec61a@localhost> #2881: Basic Fibonacci function using Word causes ghci to panic. - 6.10.1 -------------------------------------+-------------------------------------- Reporter: axman6 | Owner: simonmar Type: bug | Status: closed Priority: low | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: panic Word fibonacci | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed {{{ Fri Sep 18 06:32:04 PDT 2009 Simon Marlow * implement case-on-Word in the byte code generator/interpreter (#2881) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 18 16:26:09 2009 From: trac at galois.com (GHC) Date: Fri Sep 18 16:05:23 2009 Subject: [GHC] #3339: Data.Monoid: Add (<>) as a synonym for mappend In-Reply-To: <042.626638ce45ff16ad4ce623d16cab0138@localhost> References: <042.626638ce45ff16ad4ce623d16cab0138@localhost> Message-ID: <051.185e3fe36f572b70a0941c7671cd1b69@localhost> #3339: Data.Monoid: Add (<>) as a synonym for mappend ---------------------------------+------------------------------------------ Reporter: bos | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by bos): * summary: Data.Monoid: Add (+>) as a synonym for mappend => Data.Monoid: Add (<>) as a synonym for mappend Comment: The revised proposal is now as follows: Use {{{<>}}}, with fixity of {{{infixr 6 <>}}}. The change would also involve updating the pretty-print library to use the monoidal version of this operator. Let's wrap this up in two weeks, this time for sure :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 19 06:13:57 2009 From: trac at galois.com (GHC) Date: Sat Sep 19 05:52:36 2009 Subject: [GHC] #3453: Add "check" function to Control.Monad In-Reply-To: <051.70447cf639e8d603bf0c4d32cf8a4684@localhost> References: <051.70447cf639e8d603bf0c4d32cf8a4684@localhost> Message-ID: <060.59ddeed35cfa30302384c436f193abc6@localhost> #3453: Add "check" function to Control.Monad ---------------------------------+------------------------------------------ Reporter: JonFairbairn | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by JonFairbairn): * status: new => closed * resolution: => wontfix Comment: I've opened ticket #3524 to add mfilter. To paraphrase what I said on the libraries mailing list, the consensus is not to add check because it is a small function that readily be written in terms of other well known ones, though this writing will be much easier in the presence of mfilter. I fear I should have made it clear in the proposal that the point of check is that it's more algebraically handy than guard, but as it's too late to replace guard we would have had to have both. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 19 08:46:34 2009 From: trac at galois.com (GHC) Date: Sat Sep 19 08:25:04 2009 Subject: [GHC] #3528: GHC crash: equality and class contexts on datatype accessor Message-ID: <044.eec1d206c18c7d342eac52daf23660b8@localhost> #3528: GHC crash: equality and class contexts on datatype accessor -------------------+-------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- The following program: {{{ {-# LANGUAGE FlexibleContexts, NoMonomorphismRestriction, Rank2Types, TypeFamilies #-} module Foo where class A a data B b = B { c :: (Int ~ Int, A b) => Int } d = c }}} produces the following bug when compiled with 'ghc foo.hs': {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): applyTypeToArgs ipv{v B4} [lid] $dA{v ag5} [lid] (ghc-prim:GHC.Types.Int{(w) tc 3J} ~ ghc-prim:GHC.Types.Int{(w) tc 3J}, main:Foo.A{tc rfx} b{tv ag2} [sk]) => ghc-prim:GHC.Types.Int{(w) tc 3J} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 19 08:58:01 2009 From: trac at galois.com (GHC) Date: Sat Sep 19 08:36:33 2009 Subject: [GHC] #3528: GHC crash: equality and class contexts on datatype accessor In-Reply-To: <044.eec1d206c18c7d342eac52daf23660b8@localhost> References: <044.eec1d206c18c7d342eac52daf23660b8@localhost> Message-ID: <053.96c812307c65cb7b88d1b61831a838ff@localhost> #3528: GHC crash: equality and class contexts on datatype accessor -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------------------------+-------------------------------------- Changes (by guest): * cc: reiner.pope@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 20 06:39:50 2009 From: trac at galois.com (GHC) Date: Sun Sep 20 06:18:23 2009 Subject: [GHC] #3528: GHC crash: equality and class contexts on datatype accessor In-Reply-To: <044.eec1d206c18c7d342eac52daf23660b8@localhost> References: <044.eec1d206c18c7d342eac52daf23660b8@localhost> Message-ID: <053.fdee09690b2465bf3b9ec5751c6320f9@localhost> #3528: GHC crash: equality and class contexts on datatype accessor -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.4 Severity: normal | Resolution: worksforme Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------------------------+-------------------------------------- Changes (by chak): * status: new => closed * resolution: => worksforme Comment: This works in the development version. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 20 12:16:34 2009 From: trac at galois.com (GHC) Date: Sun Sep 20 11:55:03 2009 Subject: [GHC] #3499: darcs-all + MSYS mangles the repo path In-Reply-To: <046.acad91d38902d0416237be247629dfe3@localhost> References: <046.acad91d38902d0416237be247629dfe3@localhost> Message-ID: <055.ea5d4e28f13d51182bb6229085e0a5b8@localhost> #3499: darcs-all + MSYS mangles the repo path ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => simonmar * summary: darcs-all + MSYS manges the repo path => darcs-all + MSYS mangles the repo path -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 20 12:31:27 2009 From: trac at galois.com (GHC) Date: Sun Sep 20 12:09:55 2009 Subject: [GHC] #3529: Can't push to checked-out repos any more Message-ID: <044.fe54603a788d5d6908bfbd77061fd170@localhost> #3529: Can't push to checked-out repos any more -------------------------------+-------------------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- I used to be able to do: {{{ ./push-all --ignore-failure --checked-out dippy:c:/msys/1.0/home/ian/ghc }}} to push to a checked-out repo, but following the change to `darcs-all` I don't think that there is a way to do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 21 01:40:12 2009 From: trac at galois.com (GHC) Date: Mon Sep 21 01:18:41 2009 Subject: [GHC] #3530: GHCi does not work on Snow Leopard Message-ID: <043.67172119f9bd273a2158fec836b33117@localhost> #3530: GHCi does not work on Snow Leopard --------------------+------------------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.11 | Severity: critical Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- When compiling GHC as a 32-bit application on Snow Leopard (Mac OS X 10.6), the generated ghci aborts with a Bus Error (null pointer dereference) on startup (after it has loaded all packages). This happens only when GHC was compiled on Snow Leopard (not if a binary built on Leopard is used on Snow Leopard) and if GHCi is used '''interactively''' (if a set of commands is redirected into ghci ?as in `ghc < myscript`? the problem doesn't occur). In addition to the failure of GHCi on startup for interactive use, the following five regression tests fail when validating: {{{ TH_repE2(normal) -- the failing declaration is: an_integer TH_repPrim(normal) -- the failing tests is: [| D# 24.6## |] ann01(normal) -- all annotations with a Double fail ffi018_ghci(ghci) prog002(ghci) }}} Moreover, with `WAY=ghci` in `codeGen/`, we have the following failures: {{{ cg014(ghci) cg024(ghci) cg026(ghci) cg028(ghci) cg034(ghci) cg035(ghci) cg044(ghci) }}} Observation: All of the failing tests use 'Double'. Workaround: For the 6.12 release, by building a 32-bit binary on Leopard for use on both Leopard and Snow Leopard, the fault on starting GHCi can be avoided. I haven't checked whether that avoids the problems with the listed regressions, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 21 02:02:39 2009 From: trac at galois.com (GHC) Date: Mon Sep 21 01:41:06 2009 Subject: [GHC] #3530: GHCi does not work on Snow Leopard In-Reply-To: <043.67172119f9bd273a2158fec836b33117@localhost> References: <043.67172119f9bd273a2158fec836b33117@localhost> Message-ID: <052.2275e4506d37213031a47a3e079b7c63@localhost> #3530: GHCi does not work on Snow Leopard ----------------------+----------------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.11 Severity: critical | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by chak): I did now run validate on Snow Leopard with a tree built on Leopard. It passed. Hence, the problems described in this ticket are entirely due to '''building''' on Snow Leopard. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 21 05:23:36 2009 From: trac at galois.com (GHC) Date: Mon Sep 21 05:02:02 2009 Subject: [GHC] #3529: Can't push to checked-out repos any more In-Reply-To: <044.fe54603a788d5d6908bfbd77061fd170@localhost> References: <044.fe54603a788d5d6908bfbd77061fd170@localhost> Message-ID: <053.9b07dac2fe2615125cf31a316057c88e@localhost> #3529: Can't push to checked-out repos any more ---------------------------------+------------------------------------------ Reporter: igloo | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * difficulty: Unknown => Easy (1 hr) Comment: Pushing to checked-out repos locally is fine, pushing to checked-out repos over SSH is missing, I imagine. Sorry for missing that, it's not a use- case I use myself. I'm sure it would be easy to add the `--checked-out` flag to `darcs-all`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 21 07:30:44 2009 From: trac at galois.com (GHC) Date: Mon Sep 21 07:09:09 2009 Subject: [GHC] #3398: Unicode output in GHC In-Reply-To: <047.de64825b187e674ad618957169425649@localhost> References: <047.de64825b187e674ad618957169425649@localhost> Message-ID: <056.73dca2af0f80bef8756c7671cb3f7d1c@localhost> #3398: Unicode output in GHC ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: 2816 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: All done. Windows code-page support is in, and GHC now goes through the IO library's encoding layer for pretty-printed output. GHCi output no longer goes through Haskeline's encoding layer. {{{ Fri Sep 18 07:40:41 PDT 2009 Simon Marlow * remove encoding of output using Haskeline; the IO library does it now (#3398) }}} Haskeline is still using its own encoding/decoding, as far as I'm aware. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 21 10:41:07 2009 From: trac at galois.com (GHC) Date: Mon Sep 21 10:19:34 2009 Subject: [GHC] #2034: In FilePath, current directory should be ".", not "" In-Reply-To: <044.ce5a2afddc700a95979f00cd58ea4c17@localhost> References: <044.ce5a2afddc700a95979f00cd58ea4c17@localhost> Message-ID: <053.50789b8d1df0f42eb9022c80fa8ea8cf@localhost> #2034: In FilePath, current directory should be ".", not "" ----------------------------------+----------------------------------------- Reporter: igloo | Owner: neil Type: proposal | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * type: bug => proposal -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 21 11:34:43 2009 From: trac at galois.com (GHC) Date: Mon Sep 21 11:13:31 2009 Subject: [GHC] #3531: Haddock needs tcRnGetInfo, hence GhcWithInterpreter YES Message-ID: <043.f3ae9723755c0a36083ac743990981c8@localhost> #3531: Haddock needs tcRnGetInfo, hence GhcWithInterpreter YES -------------------+-------------------------------------------------------- Reporter: donn | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: NetBSD | Architecture: x86 -------------------+-------------------------------------------------------- "Unregisterized" cross compile fails on stage2 build of Haddock because, in Interface.AttachInstances, TcRnDriver doesn't export tcRnGetInfo. Presumably because #ifdef GCHI is false when GhcWithInterpreter is NO. From 6.11.20090919 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 21 11:52:24 2009 From: trac at galois.com (GHC) Date: Mon Sep 21 11:30:47 2009 Subject: [GHC] #3499: darcs-all cannot use SSH repos with MSYS In-Reply-To: <046.acad91d38902d0416237be247629dfe3@localhost> References: <046.acad91d38902d0416237be247629dfe3@localhost> Message-ID: <055.cb3bb5252230835b8e9c654334d3d222@localhost> #3499: darcs-all cannot use SSH repos with MSYS ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * summary: darcs-all + MSYS mangles the repo path => darcs-all cannot use SSH repos with MSYS * component: Compiler => Build System * version: 6.10.4 => 6.11 * milestone: => 6.12 branch Comment: MSYS's perl is expanding `user@machine:/path` to `user@machine;c:/msys/1.0/usr/path`. It fails for the same reason that `scp user@machine:/path` fails on MSYS. As far as I know it's not possible to turn this behaviour off. You can work around it by using a different perl, e.g. Cygwin's perl: `c:/cygwin/bin/perl darcs-all pull`. Another one that works is {{{ /c/ghc/ghc-6.10.4/perl -I/c/msys/1.0/lib/perl5/5.6.1 darcs-all pull }}} I'm not sure what to do about this. The reason it is failing now and wasn't failing before is that we are now telling darcs exactly which repo to pull from, whereas before we were using whatever the default repos were. I think the new behaviour is better - you're less likely to accidentally push/pull to/from the wrong place. I suggest using http for pulling, and pushing via SSH using Cygwin or one of the workarounds above. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 21 17:09:12 2009 From: trac at galois.com (GHC) Date: Mon Sep 21 16:47:34 2009 Subject: [GHC] #3519: ghc: panic! (the 'impossible' happened) In-Reply-To: <044.f7668c50f47c7fd7a6c1b6746ff0381d@localhost> References: <044.f7668c50f47c7fd7a6c1b6746ff0381d@localhost> Message-ID: <053.2040e75f25ebc2f10024e20db7ae1bbe@localhost> #3519: ghc: panic! (the 'impossible' happened) ------------------------------+--------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86 ------------------------------+--------------------------------------------- Changes (by adrianadshead): * os: Linux => Unknown/Multiple Comment: Also happens on windows xp. error disappears when module Main where is added to the file. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 21 23:43:42 2009 From: trac at galois.com (GHC) Date: Mon Sep 21 23:22:05 2009 Subject: [GHC] #1102: Lambda unicode character lex In-Reply-To: <047.3274cd2b53d69d61deb3dee313b1b3f5@localhost> References: <047.3274cd2b53d69d61deb3dee313b1b3f5@localhost> Message-ID: <056.a9826055288c6efb20544b706abec72e@localhost> #1102: Lambda unicode character lex -----------------------------------------------+---------------------------- Reporter: humasect | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.6.1 Component: Compiler (Parser) | Version: 6.6 Severity: minor | Resolution: Keywords: lambda unicode lexical parse ? | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------------+---------------------------- Comment (by bos): Trouble is, all of those other lambdas have the Alphabetic property, just like the regular lambda. I have mathematical code that uses identifiers like ? and ?, so ? isn't that much of a stretch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 22 06:22:23 2009 From: trac at galois.com (GHC) Date: Tue Sep 22 06:00:52 2009 Subject: [GHC] #3532: haddock should support content indexing of versioned package dirs Message-ID: <050.349010e190ff2a924354f840d1a8ec2b@localhost> #3532: haddock should support content indexing of versioned package dirs -----------------------------+---------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- When generating the libraries/index.html file haddock generates broken urls to the documentation in versioned library doc directories. It also means it is not possible to have documentation indexed for more than one version of a library. To reproduce: * install mylibrary's docs in libraries/mylibrary-1.0.0.1 * run gen_contents_index in libraries Observe index.html links for mylibrary point to libraries/mylibrary/ not libraries/mylibrary-1.0.0.1/ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 22 08:46:27 2009 From: trac at galois.com (GHC) Date: Tue Sep 22 08:24:48 2009 Subject: [GHC] #3529: Can't push to checked-out repos any more In-Reply-To: <044.fe54603a788d5d6908bfbd77061fd170@localhost> References: <044.fe54603a788d5d6908bfbd77061fd170@localhost> Message-ID: <053.bd92924a57dbe21126295a655d9d3fcb@localhost> #3529: Can't push to checked-out repos any more ---------------------------------+------------------------------------------ Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed * milestone: => 6.12.1 Comment: Fixed {{{ Mon Sep 21 07:52:01 PDT 2009 Simon Marlow * Add the --checked-out flag; expand the docs/comments at the top }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 22 12:29:47 2009 From: trac at galois.com (GHC) Date: Tue Sep 22 12:08:14 2009 Subject: [GHC] #3533: mac installer package deletes old version of ghc Message-ID: <068.c01b30dc01c8d35f26692e95513280f4@localhost> #3533: mac installer package deletes old version of ghc ------------------------------------------+--------------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 ------------------------------------------+--------------------------------- The Mac installer package on the ghc downloads page (the .mpkg, not the .tar.bz2), deletes an existing installation of ghc if it already exists. There is no warning of this behaviour on the download page, or in the installer itself. At least a warning should be given. Even better, would be to leave the existing installation of ghc intact. Best of all would be for the installer to prompt whether you want to keep the old version or delete it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 22 12:45:32 2009 From: trac at galois.com (GHC) Date: Tue Sep 22 12:23:52 2009 Subject: [GHC] #3534: hSetBinaryMode fails after some input has been read Message-ID: <044.5b2bd2ca1c5e6c9624892314c1070226@localhost> #3534: hSetBinaryMode fails after some input has been read -----------------------------+---------------------------------------------- Reporter: judah | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- For the following program (`BadSeek.hs`), type a couple characters of input and press return. With ghc-6.10.3, it works fine; with ghc-6.11 it throws an error. {{{ module Main where import System.IO main = do getChar >>= print hSetBinaryMode stdin True getChar >>= print }}} With ghc-6.10: {{{ $ ./BadSeek ab 'a' 'b' }}} With ghc-6.11: {{{ $ ./BadSeek ab 'a' BadSeek: : hSetBinaryMode: illegal operation (cannot flush the read buffer of a text-mode handle) }}} The error goes away if the first 'getChar' is commented out. For libraries which are not yet using the Unicode I/O layer, having a way to temporarily set stdin to `BinaryMode` would be useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 22 13:33:21 2009 From: trac at galois.com (GHC) Date: Tue Sep 22 13:11:50 2009 Subject: [GHC] #3533: mac installer package deletes old version of ghc In-Reply-To: <068.c01b30dc01c8d35f26692e95513280f4@localhost> References: <068.c01b30dc01c8d35f26692e95513280f4@localhost> Message-ID: <077.85ac60272ce64cb17f627978ae6e6b6b@localhost> #3533: mac installer package deletes old version of ghc ----------------------------------------------+----------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ----------------------------------------------+----------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > The Mac installer package on the ghc downloads page (the .mpkg, not the > .tar.bz2), deletes an existing installation of ghc if it already exists. > There is no warning of this behaviour on the download page, or in the > installer itself. > > At least a warning should be given. Even better, would be to leave the > existing installation of ghc intact. Best of all would be for the > installer to prompt whether you want to keep the old version or delete > it. New description: The Mac installer package on the ghc downloads page (the .pkg, not the .tar.bz2), deletes an existing installation of ghc if it already exists. There is no warning of this behaviour on the download page, or in the installer itself. At least a warning should be given. Even better, would be to leave the existing installation of ghc intact. Best of all would be for the installer to prompt whether you want to keep the old version or delete it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 22 16:40:39 2009 From: trac at galois.com (GHC) Date: Tue Sep 22 16:19:20 2009 Subject: [GHC] #3535: GHC Panic compiling hgalib-0.2 Message-ID: <044.f7f8d24c1716e2599a3a517e852894dd@localhost> #3535: GHC Panic compiling hgalib-0.2 -------------------+-------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- Building hgalib-0.2 results in a compiler panic. GHC was compiled from source, version 6.10.4. Linux kernel 2.6.28-15-generic (Ubuntu), gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4), gcc target is i486. {{{ $ cabal install hgalib Resolving dependencies... Configuring hgalib-0.2... Preprocessing library hgalib-0.2... Building hgalib-0.2... Binary: Int64 truncated to fit in 32 bit Int ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): Prelude.chr: bad argument }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 22 16:56:59 2009 From: trac at galois.com (GHC) Date: Tue Sep 22 16:35:24 2009 Subject: [GHC] #3530: GHCi does not work on Snow Leopard In-Reply-To: <043.67172119f9bd273a2158fec836b33117@localhost> References: <043.67172119f9bd273a2158fec836b33117@localhost> Message-ID: <052.b47f730092dc66c38b1f53a3ffb958c0@localhost> #3530: GHCi does not work on Snow Leopard ----------------------+----------------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.11 Severity: critical | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by maurer): Maybe this is a useless comment, but as Snow Leopard requires a 64-bit machine anyways, and is explicitly trying to get rid of 32-bit code, it could make sense to drop 32-bit support on Snow Leopard and beyond. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 22 17:10:44 2009 From: trac at galois.com (GHC) Date: Tue Sep 22 16:49:06 2009 Subject: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS In-Reply-To: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> References: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> Message-ID: <053.dafc09a34c762aa26b6dbd81ffacd659@localhost> #698: GHC's internal memory allocator never releases memory back to the OS ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by crutcher): I want to work on this. It seems that there's little agreement on what the 'right' behavior is, because there are many different execution models for which different behaviors are preferable. It seems we need a means of setting a memory reclamation policy, and plugging in some number of implementations of that policy, with flags to set it. Off the top of my head, I see a few obvious ones: * Never return free memory (the current behavior) * Immediately return free memory (the notional behavior) * Return outstanding free memory on 'flush' events (nice for the dll case?) * Fixed Buffer - return free memory over X, for some buffer size X. * Ratio Buffer - return free memory over R, for some ratio of used memory. And there's this one, which I'd like to be able to play with, but has numerous knobs. * Derivative Ratio Buffer - at time t, estimate the derivative D(t) of memory use, and return free memory over R*D(t+h) for some ration R and time step h. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 22 17:24:21 2009 From: trac at galois.com (GHC) Date: Tue Sep 22 17:02:40 2009 Subject: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS In-Reply-To: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> References: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> Message-ID: <053.de7967528020a8f1cf9fabff373cd234@localhost> #698: GHC's internal memory allocator never releases memory back to the OS ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by guest): Fixed buffer would be quite acceptable for the Gitit (and most servers) use case, I think. I originally tried to work around the memory growth for darcs.net by adding the max heap option (the -m option IIRC); turned out that setting an upper bound didn't trigger returns to the OS but segfaults. -- gwern -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 22 17:33:38 2009 From: trac at galois.com (GHC) Date: Tue Sep 22 17:11:59 2009 Subject: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS In-Reply-To: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> References: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> Message-ID: <053.3cb9a51f11b6ff417fe90520ca406a40@localhost> #698: GHC's internal memory allocator never releases memory back to the OS ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by crutcher): I've been talking to a colleague about this, and it seems that we can host essentially all of the other approaches on the 'fixed buffer' approach, by periodically sparking a process to change the buffer size. I need to spend some more time mucking about; I'm using this as a ghc hacking starter project. I'd appreciate any suggestions :) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 22 18:39:08 2009 From: trac at galois.com (GHC) Date: Tue Sep 22 18:17:32 2009 Subject: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS In-Reply-To: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> References: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> Message-ID: <053.b2630bcb602f5350b8ac751a6948b0bc@localhost> #698: GHC's internal memory allocator never releases memory back to the OS ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by crutcher): meh. This page (pointed to by the code and the wiki) is absent: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC All of this comes down to the need for a process which, given a target X of memory to free, comes as close as reasonably possible to doing so. The simplest approach would be to release free blocks and megablocks until X is satisfied, or there are no more candidate blocks or megablocks. This will likely give us reasonable behavior in the allocBytes case, but without some form of compaction, this doesn't really solve the larger problem. I don't understand the garbage collector well enough yet, but I imagine we could entice it or some of its machinery to clear our candidate blocks for us. I'll keep reading :P -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 00:47:30 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 00:25:57 2009 Subject: [GHC] #3536: ghci doesn't resolve libm symbols properly on Windows Message-ID: <047.87cb7a9935e13b210e28ed87323478bd@localhost> #3536: ghci doesn't resolve libm symbols properly on Windows ---------------------+------------------------------------------------------ Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple ---------------------+------------------------------------------------------ The erf package on hackage uses the libm functions erf and erfc. This all works fine in ghc, but in ghci we get an error. To repeat: {{{ cabal install erf }}} Try compiling {{{ import Data.Number.Erf main = print $ erf (1::Double) }}} and it works fine. Now try {{{ ghci :m +Data.Number.Erf print $ erf (1::Double) }}} and the result is {{{ Loading package syb ... linking ... done. Loading package base-3.0.3.1 ... linking ... done. Loading package erf-1.0.0.0 ... linking ... : C:\Program Files\Haskell\erf-1.0.0.0\ghc-6.10.4\HSerf-1.0.0.0.o: unknown symbol `_erfc' : unable to load package `erf-1.0.0.0' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 04:31:07 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 04:09:27 2009 Subject: [GHC] #3534: hSetBinaryMode fails after some input has been read In-Reply-To: <044.5b2bd2ca1c5e6c9624892314c1070226@localhost> References: <044.5b2bd2ca1c5e6c9624892314c1070226@localhost> Message-ID: <053.711d5de660e73f3bc534e4767975be18@localhost> #3534: hSetBinaryMode fails after some input has been read ---------------------------------+------------------------------------------ Reporter: judah | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * owner: => simonmar * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 04:35:56 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 04:14:18 2009 Subject: [GHC] #3535: GHC Panic compiling hgalib-0.2 In-Reply-To: <044.f7f8d24c1716e2599a3a517e852894dd@localhost> References: <044.f7f8d24c1716e2599a3a517e852894dd@localhost> Message-ID: <053.2bf0539d4ad8a61969d3db05cee73926@localhost> #3535: GHC Panic compiling hgalib-0.2 -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => fixed * milestone: => 6.12.1 Comment: The hgalib package has some `.hi` files in it - please contact the maintainer. GHC 6.12.1 won't fail in this ugly way, it will ignore the `.hi` files. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 04:39:11 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 04:17:32 2009 Subject: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS In-Reply-To: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> References: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> Message-ID: <053.f48d1ae63d37c53a22fc4d303161db61@localhost> #698: GHC's internal memory allocator never releases memory back to the OS ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:18 guest]: > I originally tried to work around the memory growth for darcs.net by adding the max heap option (the -m option IIRC); turned out that setting an upper bound didn't trigger returns to the OS but segfaults. If you see a segfault, please report it! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 04:54:57 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 04:33:15 2009 Subject: [GHC] #698: GHC's internal memory allocator never releases memory back to the OS In-Reply-To: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> References: <044.7b3e64b5d690837bd58d2f69df4bfac4@localhost> Message-ID: <053.350f752743c5b8fbbbf1b5ad94301839@localhost> #698: GHC's internal memory allocator never releases memory back to the OS ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Runtime System | Version: 6.4.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Replying to [comment:17 crutcher]: > I want to work on this. > > It seems that there's little agreement on what the 'right' behavior is, because there are many different execution models for which different behaviors are preferable. It seems we need a means of setting a memory reclamation policy, and plugging in some number of implementations of that policy, with flags to set it. > > Off the top of my head, I see a few obvious ones: > * Never return free memory (the current behavior) > * Immediately return free memory (the notional behavior) > * Return outstanding free memory on 'flush' events (nice for the dll case?) > * Fixed Buffer - return free memory over X, for some buffer size X. > * Ratio Buffer - return free memory over R, for some ratio of used memory. > > And there's this one, which I'd like to be able to play with, but has numerous knobs. > * Derivative Ratio Buffer - at time t, estimate the derivative D(t) of memory use, and return free memory over R*D(t+h) for some ration R and time step h. Bear in mind that the actual memory requirements fluctuate over time due to GC activity. When the copying GC is being used, at a major GC we require F*L0+L1 memory, where L0 is the amount of live data at the last GC, L1 is the current live data, and F is the value set by `+RTS -F` (default 2). In practice we'll need a little bit more than this, because we GC the cycle after the limit has been reached. So I suggest that after a major GC we * estimate the amount of memory required at the next GC, assuming live data remains constant, call this M, and add a constant C * release any whole megablocks over this limit Provide a way to set C, and/or define it as a fraction of M. I imagine that C == M would be a reasonable default: keep double the current requirements around just in case. People who want to be frugal with memory could set C == M/3. Programs with wildly varying memory requirements will suffer a performance hit if C is too low. Memory could be released between GCs, but the live data value can only be calculated at a major GC, so it makes most sense to release memory at a major GC. Programs compiled with `-threaded` get an automatic major GC when they're idle (idle time set by `+RTS -I`), programs compiled without `-threaded` will have to call `System.Mem.performGC` to release memory if they intend to go idle. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 05:09:05 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 04:47:43 2009 Subject: [GHC] #3531: Haddock needs tcRnGetInfo, hence GhcWithInterpreter YES In-Reply-To: <043.f3ae9723755c0a36083ac743990981c8@localhost> References: <043.f3ae9723755c0a36083ac743990981c8@localhost> Message-ID: <052.57c5a1118e6b486bc2f714f66f0071af@localhost> #3531: Haddock needs tcRnGetInfo, hence GhcWithInterpreter YES -----------------------------+---------------------------------------------- Reporter: donn | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: NetBSD Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * owner: => simonmar * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 05:53:00 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 05:31:38 2009 Subject: [GHC] #3531: Haddock needs tcRnGetInfo, hence GhcWithInterpreter YES In-Reply-To: <043.f3ae9723755c0a36083ac743990981c8@localhost> References: <043.f3ae9723755c0a36083ac743990981c8@localhost> Message-ID: <052.0b449e6e5c32eb9d9a4a1faefb1f2afc@localhost> #3531: Haddock needs tcRnGetInfo, hence GhcWithInterpreter YES -----------------------------+---------------------------------------------- Reporter: donn | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: NetBSD Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Pushed, thanks! {{{ Sun Sep 20 19:13:19 BST 2009 Matthias Kilian * Don't build haddock if HADDOC_DOCS = NO, and disable HADDOC_DOCS if GhcWithInterpreter = NO }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 05:53:23 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 05:31:42 2009 Subject: [GHC] #3534: hSetBinaryMode fails after some input has been read In-Reply-To: <044.5b2bd2ca1c5e6c9624892314c1070226@localhost> References: <044.5b2bd2ca1c5e6c9624892314c1070226@localhost> Message-ID: <053.4b63a97a9e664600f7d6f911a6fd626c@localhost> #3534: hSetBinaryMode fails after some input has been read ---------------------------------+------------------------------------------ Reporter: judah | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: libraries/base | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed {{{ Wed Sep 23 10:04:45 BST 2009 Simon Marlow * Fix #3534: No need to flush the byte buffer when setting binary mode }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 06:49:42 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 06:28:00 2009 Subject: [GHC] #3537: Add missing NFData instances to parallel Message-ID: <052.18271cd784d6aae76f4ba5d739912c4b@localhost> #3537: Add missing NFData instances to parallel -----------------------------+---------------------------------------------- Reporter: Roel van Dijk | Owner: Type: proposal | Status: new Priority: normal | Component: libraries (other) Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- [http://hackage.haskell.org/packages/archive/parallel/1.1.0.1/doc/html /Control-Parallel-Strategies.html Control.Parallel.Strategies] contains many NFData instances for types defined in base, but not all. I propose adding NFData instances for all types in base where it makes sense. Attached is a patch which adds instances for most missing types. For many of those types it would be nicer to define the instances in the module where the type is defined, but that would require a circular dependency. Instances in patch: * [http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html /Data-Fixed.html Data.Fixed] (E6, E12, Fixed) * [http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html /Data-IORef.html Data.IORef] (IORef) * [http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html /Data-STRef.html Data.STRef] (STRef) * [http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html /Data-Unique.html Data.Unique] (Unique) * [http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html /Data-Version.html Data.Version] (Version) * [http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html/Foreign-C-Error.html Foreign.C.Error] (Errno) * [http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html/Foreign-C-Types.html Foreign.C.Types] (all of them) * [http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html /System-Exit.html System.Exit] (!ExitCode) * [http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html /System-IO.html System.IO] (IOMode, !SeekMode, !BufferMode) * [http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html /System-IO-Error.html System.IO.Error] (IOErrorType) * [http://hackage.haskell.org/packages/archive/base/4.1.0.0/doc/html /System-Mem-StableName.html System.Mem.StableName] (!StableName) For some types I had to resort to tricks like comparing a value with itself to force evaluation since I do not have access to all constructors. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 07:06:03 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 06:44:20 2009 Subject: [GHC] #3538: ghc 6.10.4 freebsd panic for language pragma of form: -foobar Message-ID: <044.044992d74ca05ca934c9a3a3e5662b7b@localhost> #3538: ghc 6.10.4 freebsd panic for language pragma of form: -foobar -----------------------------+---------------------------------------------- Reporter: kasse | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I am learning haskell, sorry if this is an irrelevant bug. Just following instructions from ghc. test.hs: {-# LANGUAGE -foobar #-} let x=2 --------------------------------------------- > :l test.hs ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for x86_64-unknown-freebsd): getOptions'.parseLanguage(2) went past eof token Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 08:44:51 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 08:23:08 2009 Subject: [GHC] #3538: ghc 6.10.4 freebsd panic for language pragma of form: -foobar In-Reply-To: <044.044992d74ca05ca934c9a3a3e5662b7b@localhost> References: <044.044992d74ca05ca934c9a3a3e5662b7b@localhost> Message-ID: <053.1f9ebf09248c31cc6893defc028ee98e@localhost> #3538: ghc 6.10.4 freebsd panic for language pragma of form: -foobar ---------------------------------+------------------------------------------ Reporter: kasse | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. Happily, this is already fixed in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 08:46:49 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 08:25:28 2009 Subject: [GHC] #3531: Haddock needs tcRnGetInfo, hence GhcWithInterpreter YES In-Reply-To: <043.f3ae9723755c0a36083ac743990981c8@localhost> References: <043.f3ae9723755c0a36083ac743990981c8@localhost> Message-ID: <052.a3d409fdf68db7fec6bd8124f6d2f880@localhost> #3531: Haddock needs tcRnGetInfo, hence GhcWithInterpreter YES -----------------------------+---------------------------------------------- Reporter: donn | Owner: simonmar Type: bug | Status: reopened Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: NetBSD Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by igloo): * status: closed => reopened * resolution: fixed => Comment: Is there a reason for this function to be enabled only if GHCi is? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 11:20:56 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 10:59:14 2009 Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled? In-Reply-To: <047.c01de827ffb9a59aafb72de68ac54369@localhost> References: <047.c01de827ffb9a59aafb72de68ac54369@localhost> Message-ID: <056.67609266bdce4e7febd8d4d2789acacc@localhost> #2798: Enable "rec" keyword when RecursiveDo is enabled? ---------------------------------+------------------------------------------ Reporter: nominolo | Owner: igloo Type: task | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: 6.12.1 => 6.14.1 Comment: Won't be done in time for 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 11:30:09 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 11:10:16 2009 Subject: [GHC] #1876: Complete shared library support In-Reply-To: <047.2ab772cd4150dcd51ba47e309570e649@localhost> References: <047.2ab772cd4150dcd51ba47e309570e649@localhost> Message-ID: <056.2aed288bf0ccba07b0597acedcf6aa47@localhost> #1876: Complete shared library support ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: duncan Type: task | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Difficult (1 week) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Shared libs are working on Linux in 6.12.1. We should open separate tickets for other tasks remaining to be done. A big thanks to everyone who has worked on getting shared library support into GHC over the years, particularly Wolfgang Thaller, Clemens Fruhwirth and Duncan Coutts. -- Ticket URL: GHC The Glasgow Haskell Compiler From duncan.coutts at worc.ox.ac.uk Wed Sep 23 13:22:13 2009 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed Sep 23 13:00:31 2009 Subject: [Haskell-cafe] help with cabal; trying to escape from configuration hell In-Reply-To: References: Message-ID: <1253726533.18961.4722.camel@localhost> On Tue, 2009-09-22 at 17:13 +0200, S. Doaitse Swierstra wrote: > I am trying to run happstack on my Mac, but unfortunately I am getting > error messages as described in: > > http://code.google.com/p/happstack/issues/detail?id=88 > > The cure seems to be to downgrade to network-2.2.0.1, but > unfortunately my installed cabal depends on network-2.2.1.4. > > I tried to re-install happstack using: > > cabal install happstack --reinstall --constraint="network==2.2.0.2" > > but unfortunately the ghc happily reports to link against > network-2.2.1.4: > > ... > Loading package parsec-2.1.0.1 ... linking ... done. > Loading package hsemail-1.3 ... linking ... done. > Loading package network-2.2.1.4 ... linking ... done. > Loading package SMTPClient-1.0.1 ... linking ... done. > Loading package time-1.1.4 ... linking ... done. > ... > > Can someone rescue me? Is that log output from when you are compiling happstack itself (and that snippet is the template haskell code being loaded) or is it when you are loading the final built package in ghci? If it's the TH bit then it appears to be an instance of this bug: http://hackage.haskell.org/trac/ghc/ticket/2555 The problem appears to be that while we compile happstack against network-2.2.0.2, when it comes to the template haskell stuff, it goes and picks up the latest version of network instead. GHC HQ have not been able to reproduce this so it would be useful if we could have more details on what you are finding. In particular a full log of this command would be useful: $ cabal install happstack -v --reinstall --constraint="network==2.2.0.2" Note the -v so that we will see how cabal invokes ghc. Attach the log to the ghc ticket above. Once you've saved the evidence, the workaround is to unregister the later network version, then ghc cannot possibly pick it. Duncan From trac at galois.com Wed Sep 23 14:42:59 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 14:21:15 2009 Subject: [GHC] #3448: Error with .so files in HEAD snapshot distribution In-Reply-To: <043.a632d5d0fb8b0e327915fe8944a060e4@localhost> References: <043.a632d5d0fb8b0e327915fe8944a060e4@localhost> Message-ID: <052.893e214dd84ba57e67692b1aa8d4c6f0@localhost> #3448: Error with .so files in HEAD snapshot distribution -------------------------------+-------------------------------------------- Reporter: dons | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed; installing `ghc-6.12.0.20090922-x86_64-unknown-linux.tar.bz2` succeeds. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 14:43:06 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 14:21:23 2009 Subject: [GHC] #3481: Nightly snapshot fails to install In-Reply-To: <043.648802f336c6762629e495848f7ef257@localhost> References: <043.648802f336c6762629e495848f7ef257@localhost> Message-ID: <052.aaf87121aec9cd8bd0316cfba3a4f50d@localhost> #3481: Nightly snapshot fails to install -------------------------------+-------------------------------------------- Reporter: dons | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed; installing `ghc-6.12.0.20090922-x86_64-unknown-linux.tar.bz2` succeeds. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 14:43:10 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 14:21:29 2009 Subject: [GHC] #3493: "make install" fails with error on rts/Config.h in HEAD In-Reply-To: <044.e3121a1d0ddafa3bdca737e47a0186e1@localhost> References: <044.e3121a1d0ddafa3bdca737e47a0186e1@localhost> Message-ID: <053.c35c3f9779047a15d3a62ce964199c56@localhost> #3493: "make install" fails with error on rts/Config.h in HEAD ---------------------------------+------------------------------------------ Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed; installing `ghc-6.12.0.20090922-x86_64-unknown-linux.tar.bz2` succeeds. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 16:44:22 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 16:22:38 2009 Subject: [GHC] #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 Message-ID: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 ---------------------+------------------------------------------------------ Reporter: elaforge | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 ---------------------+------------------------------------------------------ Searching trac for "ASSERTION FAILED" or Evac.c didn't turn this up, so here goes. I've been infrequently getting this on startup: {{{ seq: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 (GHC version 6.10.4 for i386_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is OS X 10.5.8. Starting the same program again with no changes works, so I can't trigger it consistently. Here's the traceback from the crashing thread: {{{ Thread 3 Crashed: 0 libSystem.B.dylib 0x94508c7e nanosleep$NOCANCEL$UNIX2003 + 0 1 libSystem.B.dylib 0x94502013 usleep$NOCANCEL$UNIX2003 + 61 2 libSystem.B.dylib 0x94519685 abort + 85 3 elaforge.seq.seq 0x00f71a06 rtsErrorMsgFn + 0 4 elaforge.seq.seq 0x00f717f3 barf + 33 5 elaforge.seq.seq 0x00f71846 errorBelch + 0 6 elaforge.seq.seq 0x00f85dfe evacuate + 91 7 elaforge.seq.seq 0x00f8f1b2 scavenge_one + 311 8 elaforge.seq.seq 0x00f8f695 scavenge_mutable_list + 268 9 elaforge.seq.seq 0x00f87248 GarbageCollect + 857 10 elaforge.seq.seq 0x00f78ffc scheduleDoGC + 526 11 elaforge.seq.seq 0x00f78044 schedule + 2538 12 elaforge.seq.seq 0x00f79a89 workerStart + 72 13 libSystem.B.dylib 0x9445e155 _pthread_start + 321 14 libSystem.B.dylib 0x9445e012 thread_start + 34 Thread 3 crashed with X86 Thread State (32-bit): eax: 0xb0184bd8 ebx: 0x94519639 ecx: 0x00000000 edx: 0x00000000 edi: 0x00000000 esi: 0x00002710 ebp: 0xb0184be8 esp: 0xb0184bbc ss: 0x0000001f efl: 0x00010202 eip: 0x94508c7e cs: 0x00000017 ds: 0x0000001f es: 0x0000001f fs: 0x0000001f gs: 0x00000037 cr2: 0x16d59990 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 18:11:46 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 17:50:01 2009 Subject: [GHC] #2969: unix package built wrong on Solaris In-Reply-To: <045.0d30450289e14ebfae501919df8c4ac3@localhost> References: <045.0d30450289e14ebfae501919df8c4ac3@localhost> Message-ID: <054.87bc24e7b097b5a65c8e3f33da575904@localhost> #2969: unix package built wrong on Solaris -------------------------+-------------------------------------------------- Reporter: duncan | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Test added to the `unix` package, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 19:42:15 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:20:31 2009 Subject: [GHC] #3494: missing build system dependency In-Reply-To: <045.8de98aacac9d8b317157450367a72303@localhost> References: <045.8de98aacac9d8b317157450367a72303@localhost> Message-ID: <054.30004f04185910d250f58bc7e3819236@localhost> #3494: missing build system dependency ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: minor | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: The problem is that this is really part of the build system. When we build it, we're just doing `ghc --make`; we don't know what the source are. I can't see what we could do to improve the situation, so I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 19:43:55 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:22:11 2009 Subject: [GHC] #3457: Impossible to specify pragmas compatible with multiple ghc versions In-Reply-To: <045.b42d9302a58a1a0f28ab9ef59d342a90@localhost> References: <045.b42d9302a58a1a0f28ab9ef59d342a90@localhost> Message-ID: <054.2d9e34d143d303c67fecbb03e64ab9b3@localhost> #3457: Impossible to specify pragmas compatible with multiple ghc versions ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Driver | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 19:44:41 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:22:56 2009 Subject: [GHC] #3458: Allocation where none should happen In-Reply-To: <044.0be4f1c62ed65da810608cbf23db2085@localhost> References: <044.0be4f1c62ed65da810608cbf23db2085@localhost> Message-ID: <053.7b7a968d196ea023cdcc827550bf1d81@localhost> #3458: Allocation where none should happen -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 19:47:06 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:25:30 2009 Subject: [GHC] #3460: Can't use superclass when type coercions are involved In-Reply-To: <044.244b3775004994168c2f11c29886a28f@localhost> References: <044.244b3775004994168c2f11c29886a28f@localhost> Message-ID: <053.06a841b617647e6c13e7f80d54a6a3d4@localhost> #3460: Can't use superclass when type coercions are involved ----------------------------------------+----------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 19:48:13 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:26:29 2009 Subject: [GHC] #3464: Find import declaration importing a certain function In-Reply-To: <044.30a4bd3b165086669168a65fc548f37a@localhost> References: <044.30a4bd3b165086669168a65fc548f37a@localhost> Message-ID: <053.9b6bbede0dd2416101576bb5390a37b3@localhost> #3464: Find import declaration importing a certain function ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Old description: > Given the command > > {{{:find foo}}} > > , find all import declaration that import this symbol. > > Example: > > > *ModA *ModB *ModC are loaded. > > Suppose the modules all export Data.List. > > So, > given > > module ModX(module Data.List) where import Data.List > with X \in {A,B,C} > > Now, when one currently does :i for a function in Data.List, one gets > back that it is defined in Data.List, but that's not the information the > user is interested in. The user wants to know which _modules_ define a > certain symbol, so in this case it should say that modules ModA, ModB and > ModC brought that symbol into scope. > > The user-interface could also simply be :i as it is now, but with one > extra line saying where it was imported. New description: Given the command {{{ :find foo }}} , find all import declaration that import this symbol. Example: {{{ > *ModA *ModB *ModC are loaded. }}} Suppose the modules all export Data.List. So, given {{{ module ModX(module Data.List) where import Data.List }}} with X \in {A,B,C} Now, when one currently does :i for a function in Data.List, one gets back that it is defined in Data.List, but that's not the information the user is interested in. The user wants to know which _modules_ define a certain symbol, so in this case it should say that modules ModA, ModB and ModC brought that symbol into scope. The user-interface could also simply be :i as it is now, but with one extra line saying where it was imported. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 19:49:09 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:27:26 2009 Subject: [GHC] #3464: Find import declaration importing a certain function In-Reply-To: <044.30a4bd3b165086669168a65fc548f37a@localhost> References: <044.30a4bd3b165086669168a65fc548f37a@localhost> Message-ID: <053.dc2f37ddfd960f8b18d630f385e58289@localhost> #3464: Find import declaration importing a certain function ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14 branch Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.14 branch Comment: Thanks for the suggestion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 20:05:07 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:43:22 2009 Subject: [GHC] #3532: haddock should support content indexing of versioned package dirs In-Reply-To: <050.349010e190ff2a924354f840d1a8ec2b@localhost> References: <050.349010e190ff2a924354f840d1a8ec2b@localhost> Message-ID: <059.50a8c23fe42076bf87af7d92e0cc90ef@localhost> #3532: haddock should support content indexing of versioned package dirs ------------------------------+--------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by juhpetersen): * cc: duncan (added) Comment: Duncan, any comment on this in the context of ghc-6.10.4, packaging haskell-platform network docs, and: {{{ cabal configure ... --htmldir=%{_docdir}/ghc/libraries/%{pkg_name}-%{version} cabal build cabal haddock (install) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 20:07:50 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:46:05 2009 Subject: [GHC] #3532: haddock should support content indexing of versioned package dirs In-Reply-To: <050.349010e190ff2a924354f840d1a8ec2b@localhost> References: <050.349010e190ff2a924354f840d1a8ec2b@localhost> Message-ID: <059.47fa710512d82234b63524bc406cac27@localhost> #3532: haddock should support content indexing of versioned package dirs ------------------------------+--------------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by juhpetersen): > cabal configure ... --htmldir=%{_docdir}/ghc/libraries/%{pkg_name}-%{version} I mean {{{ cabal configure ... --htmldir=/usr/share/doc/ghc/libraries/network-2.2.1.4 }}} ie parallel install of networks documentation. But this also applies to versioned new documentation of new system packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 20:15:38 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:53:53 2009 Subject: [GHC] #3480: Easily make Typeable keys pure, so that Typeable can be handled efficiently across communications In-Reply-To: <044.e3702794ded3f91904f114f506e31845@localhost> References: <044.e3702794ded3f91904f114f506e31845@localhost> Message-ID: <053.a47e438156fbdb9e225b03c0e6890b92@localhost> #3480: Easily make Typeable keys pure, so that Typeable can be handled efficiently across communications -------------------------------------+-------------------------------------- Reporter: guest | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: Severity: trivial | Resolution: Keywords: Typeable, efficiency | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------+-------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 20:14:52 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:54:13 2009 Subject: [GHC] #3470: OSX installer should give an informative error message when XCode is missing In-Reply-To: <053.606cf8b25459ae2fb498c9543397706e@localhost> References: <053.606cf8b25459ae2fb498c9543397706e@localhost> Message-ID: <062.53c4c42c2fe7152e6785d4317d350e9f@localhost> #3470: OSX installer should give an informative error message when XCode is missing -------------------------------+-------------------------------------------- Reporter: GregoryCollins | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 20:16:01 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:54:18 2009 Subject: [GHC] #3483: Some mechanism for eliminating "absurd" patterns In-Reply-To: <044.05fb1984acc37eefec1ed6383058af74@localhost> References: <044.05fb1984acc37eefec1ed6383058af74@localhost> Message-ID: <053.bb13e2df56ee5115562871bd0c81647d@localhost> #3483: Some mechanism for eliminating "absurd" patterns ---------------------------------+------------------------------------------ Reporter: ryani | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 20:16:25 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:54:44 2009 Subject: [GHC] #3484: GHC diverges when proving nonequality of types In-Reply-To: <044.b24389c149623a55fb40be839d0a136b@localhost> References: <044.b24389c149623a55fb40be839d0a136b@localhost> Message-ID: <053.386288cd17885cc61af8ce5880f9acb1@localhost> #3484: GHC diverges when proving nonequality of types ---------------------------------+------------------------------------------ Reporter: ryani | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 20:18:21 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:56:40 2009 Subject: [GHC] #2790: Use -fregs-graph by default In-Reply-To: <044.e23cb1a138a9b4ed2c315b0444e4b3fc@localhost> References: <044.e23cb1a138a9b4ed2c315b0444e4b3fc@localhost> Message-ID: <053.bdd312de16b534885768aaf65cdca53b@localhost> #2790: Use -fregs-graph by default ---------------------------------+------------------------------------------ Reporter: igloo | Owner: benl Type: task | Status: assigned Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): See also #3484 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 20:18:36 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:56:54 2009 Subject: [GHC] #2790: Use -fregs-graph by default In-Reply-To: <044.e23cb1a138a9b4ed2c315b0444e4b3fc@localhost> References: <044.e23cb1a138a9b4ed2c315b0444e4b3fc@localhost> Message-ID: <053.7600d519be6c8c8277d3e9d2db5187d9@localhost> #2790: Use -fregs-graph by default ---------------------------------+------------------------------------------ Reporter: igloo | Owner: benl Type: task | Status: assigned Priority: high | Milestone: 6.14.1 Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): I mean #3488 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 20:18:44 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:57:01 2009 Subject: [GHC] #3488: Impossible happened: RegAllocLinear.getStackSlotFor: out of stack slots In-Reply-To: <042.efd3a6588858af62ce043efa2d483c4a@localhost> References: <042.efd3a6588858af62ce043efa2d483c4a@localhost> Message-ID: <051.9a87a545056a175afd1c1d16b093361f@localhost> #3488: Impossible happened: RegAllocLinear.getStackSlotFor: out of stack slots ---------------------------------+------------------------------------------ Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 20:19:19 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:57:34 2009 Subject: [GHC] #3489: Adding some gmp bindings to integer-gmp (copied from the cvs-ghc list) In-Reply-To: <046.90f661b74011792a4af69e74c94446e3@localhost> References: <046.90f661b74011792a4af69e74c94446e3@localhost> Message-ID: <055.913914047566a4d9db8a9f87f4b7a6f4@localhost> #3489: Adding some gmp bindings to integer-gmp (copied from the cvs-ghc list) ---------------------------------+------------------------------------------ Reporter: pumpkin | Owner: Type: proposal | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 Comment: Thanks for the patch. We'll take a look in the 6.14 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 20:20:58 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 19:59:13 2009 Subject: [GHC] #3496: GHC panic while building the base library with Cabal In-Reply-To: <047.5c600ae82cf71150830a6ede7f6640ea@localhost> References: <047.5c600ae82cf71150830a6ede7f6640ea@localhost> Message-ID: <056.2c237693bbbf828dc5a3c23f1767ab58@localhost> #3496: GHC panic while building the base library with Cabal ---------------------------------+------------------------------------------ Reporter: elliottt | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 20:22:12 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 20:00:31 2009 Subject: [GHC] #3500: Type functions and recursive dictionaries In-Reply-To: <046.2ed13f414fdea0237fa434043b777b31@localhost> References: <046.2ed13f414fdea0237fa434043b777b31@localhost> Message-ID: <055.652469148854ca198fc3f4605a098e8a@localhost> #3500: Type functions and recursive dictionaries ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 20:24:25 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 20:02:40 2009 Subject: [GHC] #3503: Add __attribute__((constructor))-equivalent pragma In-Reply-To: <046.d3319a3d44a7c3235940f61a366ea149@localhost> References: <046.d3319a3d44a7c3235940f61a366ea149@localhost> Message-ID: <055.a81744b93361011e35b75ff8ba94c000@localhost> #3503: Add __attribute__((constructor))-equivalent pragma ---------------------------------+------------------------------------------ Reporter: pumpkin | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: minor | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: I'm going to close this ticket, due to the lack of consensus that it should be done, and what the design should be. As Duncan says, there have been some discussions about it on the lists. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 20:39:55 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 20:18:14 2009 Subject: [GHC] #3530: GHCi does not work on Snow Leopard In-Reply-To: <043.67172119f9bd273a2158fec836b33117@localhost> References: <043.67172119f9bd273a2158fec836b33117@localhost> Message-ID: <052.48177f75f3099a4b02a2237019ae4b88@localhost> #3530: GHCi does not work on Snow Leopard ----------------------+----------------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.11 Severity: critical | Resolution: Keywords: | Testcase: Os: MacOS X | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by altaic): Actually, Snow Leopard does not require a 64-bit machine, and all SL apps are x86/x86_64 Universal. I've read that gcc defaults to building x86_64, however on my core duo (read: 32-bit) mac, `gcc -dumpmachine` reports "i686-apple-darwin10" not "x86_64-apple-darwin10" as I imagine it would if that were true. So perhaps gcc defaults to the host arch in some manner (there is additional confusion because even on 64-bit machines SL defaults to booting the 32-bit kernel, but defaults to running and building 64-bit apps). Regardless, please don't drop 32-bit support! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 22:34:46 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 22:13:06 2009 Subject: [GHC] #3540: Parser accepts malformed types with implicit parameters Message-ID: <043.a36047b0c114003b419dbf8833abfb27@localhost> #3540: Parser accepts malformed types with implicit parameters -----------------------------+---------------------------------------------- Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The parser in GHC 6.11 currently accepts this: {{{ thing :: (?dude :: Int) -> Int thing = undefined }}} Where the type should really be written with => like {{{ thing :: (?dude :: Int) => Int thing = undefined }}} Running hlint on the malformed-but-accepted-by-GHC version crashes haskell-src-exts: {{{ benl@humboldt:~$ cat tmp/Main.hs main = undefined thing :: (?dude :: Int) -> Int thing = undefined benl@humboldt:~$ hlint tmp/Main.hs hlint: src/Language/Haskell/Exts/ParseUtils.hs:(841,18)-(863,53): Non- exhaustive patterns in case }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 23 22:36:26 2009 From: trac at galois.com (GHC) Date: Wed Sep 23 22:14:44 2009 Subject: [GHC] #3540: Parser accepts malformed types with implicit parameters In-Reply-To: <043.a36047b0c114003b419dbf8833abfb27@localhost> References: <043.a36047b0c114003b419dbf8833abfb27@localhost> Message-ID: <052.f24edf475a1ff1bb11d88a73d4b0b989@localhost> #3540: Parser accepts malformed types with implicit parameters -------------------------------+-------------------------------------------- Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by benl): The corresponding HLint ticket is [http://code.google.com/p/ndmitchell/issues/detail?id=219] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 05:17:47 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 04:56:12 2009 Subject: [GHC] #3536: ghci doesn't resolve libm symbols properly on Windows In-Reply-To: <047.87cb7a9935e13b210e28ed87323478bd@localhost> References: <047.87cb7a9935e13b210e28ed87323478bd@localhost> Message-ID: <056.a3b6271ae90f2ffd8051c38fffe12cb5@localhost> #3536: ghci doesn't resolve libm symbols properly on Windows ---------------------------------+------------------------------------------ Reporter: augustss | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * component: Compiler => Runtime System * difficulty: => Unknown * status: new => closed * resolution: => fixed * milestone: => 6.12.1 Comment: Fixed {{{ Wed Sep 23 03:52:40 PDT 2009 Simon Marlow * Add erf, erfc, erfff, erfcf (#3536) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 05:43:46 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 05:22:02 2009 Subject: [GHC] #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 In-Reply-To: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> References: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> Message-ID: <056.34517a23ad4f3dde7f080b31911ab0f9@localhost> #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 -------------------------------+-------------------------------------------- Reporter: elaforge | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * owner: => simonmar * milestone: => 6.12.1 Comment: Can you supply the program that fails? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 05:45:08 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 05:23:24 2009 Subject: [GHC] #3494: missing build system dependency In-Reply-To: <045.8de98aacac9d8b317157450367a72303@localhost> References: <045.8de98aacac9d8b317157450367a72303@localhost> Message-ID: <054.07fc864993b05bd9f38897f3badb91d3@localhost> #3494: missing build system dependency ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: reopened Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: closed => reopened * resolution: invalid => Comment: Couldn't we make ghc-cabal depend on `$(wildcard libraries/Cabal/Distribution/*.hs)` etc.? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 08:43:09 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 08:21:26 2009 Subject: [GHC] #3505: type mismatch error message with operator sections counts the arguments incorrectly In-Reply-To: <049.b0dca9b9c9ba59c25cb61ac760d64c4f@localhost> References: <049.b0dca9b9c9ba59c25cb61ac760d64c4f@localhost> Message-ID: <058.bc2cd47b17913e36405671eaa2297521@localhost> #3505: type mismatch error message with operator sections counts the arguments incorrectly ---------------------------------+------------------------------------------ Reporter: benmachine | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 09:24:57 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 09:03:12 2009 Subject: [GHC] #3509: libffi.so not found on Mac OS X (10.5.8) In-Reply-To: <046.e078f62d85671282d5ab3883ebdd8e48@localhost> References: <046.e078f62d85671282d5ab3883ebdd8e48@localhost> Message-ID: <055.0980d64514fc9cb7a7b6d668aa0453d2@localhost> #3509: libffi.so not found on Mac OS X (10.5.8) ---------------------------------+------------------------------------------ Reporter: mwotton | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Old description: > building with dynamic libraries on Mac OS X dies with an error about > libffi.so > > To reproduce: > add a build.mk with "GhcLibWays = v dyn" > sh boot && ./configure --enable-shared && make > > If I copy one of the libffi*dylib files that does appear to have been > built correctly to libffi.so, the build proceeds but then loops in the > build process. > > partial trace: > (cd .libs && rm -f libffi.5.dylib && cp -p libffi.5.0.9.dylib > libffi.5.dylib) > (cd .libs && rm -f libffi.dylib && cp -p libffi.5.0.9.dylib libffi.dylib) > ar cru .libs/libffi.a src/debug.o src/prep_cif.o src/types.o > src/raw_api.o src/java_raw_api.o src/closures.o src/x86/ffi.o > src/x86/darwin.o src/x86/ffi64.o src/x86/darwin64.o > "inplace/bin/mkdirhier" inplace/lib/ > "cp" -p utils/hsc2hs/dist/build/tmp/hsc2hs inplace/lib/hsc2hs > ranlib: file: .libs/libffi.a(ffi64.o) has no symbols > ranlib: file: .libs/libffi.a(darwin64.o) has no symbolstouch > inplace/lib/hsc2hs > > ranlib .libs/libffi.a > ranlib: file: .libs/libffi.a(ffi64.o) has no symbols > ranlib: file: .libs/libffi.a(darwin64.o) has no symbols > creating libffi.la > (cd .libs && rm -f libffi.la && cp -p ../libffi.la libffi.la) > /bin/sh ./libtool --tag=CC --mode=link gcc -Wall -g -fexceptions -w -w > -o libffi_convenience.la src/debug.lo src/prep_cif.lo src/types.lo > src/raw_api.lo src/java_raw_api.lo src/closures.lo src/x86/ffi.lo > src/x86/darwin.lo src/x86/ffi64.lo src/x86/darwin64.lo > ar cru .libs/libffi_convenience.a src/.libs/debug.o src/.libs/prep_cif.o > src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o > src/.libs/closures.o src/x86/.libs/ffi.o src/x86/.libs/darwin.o > src/x86/.libs/ffi64.o src/x86/.libs/darwin64.o > ranlib: file: .libs/libffi_convenience.a(ffi64.o) has no symbols > ranlib: file: .libs/libffi_convenience.a(darwin64.o) has no symbols > ranlib .libs/libffi_convenience.a > ranlib: file: .libs/libffi_convenience.a(ffi64.o) has no symbols > ranlib: file: .libs/libffi_convenience.a(darwin64.o) has no symbols > creating libffi_convenience.la > (cd .libs && rm -f libffi_convenience.la && cp -p > ../libffi_convenience.la libffi_convenience.la) > make[4]: Leaving directory `/Users/mwotton/projects/ghc/libffi/build' > make[3]: Leaving directory `/Users/mwotton/projects/ghc/libffi/build' > cp .libs/libffi.5.0.9.dylib > /Users/mwotton/projects/ghc/libffi/libffi.5.0.9.dylib > (cd /Users/mwotton/projects/ghc/libffi && { cp -p -f libffi.5.0.9.dylib > libffi.5.dylib || { rm -f libffi.5.dylib && cp -p libffi.5.0.9.dylib > libffi.5.dylib; }; }) > (cd /Users/mwotton/projects/ghc/libffi && { cp -p -f libffi.5.0.9.dylib > libffi.dylib || { rm -f libffi.dylib && cp -p libffi.5.0.9.dylib > libffi.dylib; }; }) > cp .libs/libffi.lai /Users/mwotton/projects/ghc/libffi/libffi.la > cp .libs/libffi.a /Users/mwotton/projects/ghc/libffi/libffi.a > chmod 644 /Users/mwotton/projects/ghc/libffi/libffi.a > ranlib /Users/mwotton/projects/ghc/libffi/libffi.a > ranlib: file: /Users/mwotton/projects/ghc/libffi/libffi.a(ffi64.o) has no > symbols > ranlib: file: /Users/mwotton/projects/ghc/libffi/libffi.a(darwin64.o) has > no symbols > libtool: install: warning: remember to run `libtool --finish > /usr/local/lib' > touch libffi/stamp.ffi.build-shared > "cp" libffi/libffi.a libffi/libHSffi.a > "cp" libffi/libffi.so libffi/libHSffi-ghc6.11.20090913.dylib > "cp" libffi/libffi.a libffi/libHSffi_p.a > cp: libffi/libffi.so: No such file or directory > make[1]: *** [libffi/libHSffi-ghc6.11.20090913.dylib] Error 1 > make[1]: *** Waiting for unfinished jobs.... > make: *** [all] Error 2 > nice make -j 2 145.90s user 70.38s system 78% cpu 4:37.08 total New description: building with dynamic libraries on Mac OS X dies with an error about libffi.so To reproduce: {{{ add a build.mk with "GhcLibWays = v dyn" sh boot && ./configure --enable-shared && make }}} If I copy one of the libffi*dylib files that does appear to have been built correctly to libffi.so, the build proceeds but then loops in the build process. partial trace: {{{ (cd .libs && rm -f libffi.5.dylib && cp -p libffi.5.0.9.dylib libffi.5.dylib) (cd .libs && rm -f libffi.dylib && cp -p libffi.5.0.9.dylib libffi.dylib) ar cru .libs/libffi.a src/debug.o src/prep_cif.o src/types.o src/raw_api.o src/java_raw_api.o src/closures.o src/x86/ffi.o src/x86/darwin.o src/x86/ffi64.o src/x86/darwin64.o "inplace/bin/mkdirhier" inplace/lib/ "cp" -p utils/hsc2hs/dist/build/tmp/hsc2hs inplace/lib/hsc2hs ranlib: file: .libs/libffi.a(ffi64.o) has no symbols ranlib: file: .libs/libffi.a(darwin64.o) has no symbolstouch inplace/lib/hsc2hs ranlib .libs/libffi.a ranlib: file: .libs/libffi.a(ffi64.o) has no symbols ranlib: file: .libs/libffi.a(darwin64.o) has no symbols creating libffi.la (cd .libs && rm -f libffi.la && cp -p ../libffi.la libffi.la) /bin/sh ./libtool --tag=CC --mode=link gcc -Wall -g -fexceptions -w -w -o libffi_convenience.la src/debug.lo src/prep_cif.lo src/types.lo src/raw_api.lo src/java_raw_api.lo src/closures.lo src/x86/ffi.lo src/x86/darwin.lo src/x86/ffi64.lo src/x86/darwin64.lo ar cru .libs/libffi_convenience.a src/.libs/debug.o src/.libs/prep_cif.o src/.libs/types.o src/.libs/raw_api.o src/.libs/java_raw_api.o src/.libs/closures.o src/x86/.libs/ffi.o src/x86/.libs/darwin.o src/x86/.libs/ffi64.o src/x86/.libs/darwin64.o ranlib: file: .libs/libffi_convenience.a(ffi64.o) has no symbols ranlib: file: .libs/libffi_convenience.a(darwin64.o) has no symbols ranlib .libs/libffi_convenience.a ranlib: file: .libs/libffi_convenience.a(ffi64.o) has no symbols ranlib: file: .libs/libffi_convenience.a(darwin64.o) has no symbols creating libffi_convenience.la (cd .libs && rm -f libffi_convenience.la && cp -p ../libffi_convenience.la libffi_convenience.la) make[4]: Leaving directory `/Users/mwotton/projects/ghc/libffi/build' make[3]: Leaving directory `/Users/mwotton/projects/ghc/libffi/build' cp .libs/libffi.5.0.9.dylib /Users/mwotton/projects/ghc/libffi/libffi.5.0.9.dylib (cd /Users/mwotton/projects/ghc/libffi && { cp -p -f libffi.5.0.9.dylib libffi.5.dylib || { rm -f libffi.5.dylib && cp -p libffi.5.0.9.dylib libffi.5.dylib; }; }) (cd /Users/mwotton/projects/ghc/libffi && { cp -p -f libffi.5.0.9.dylib libffi.dylib || { rm -f libffi.dylib && cp -p libffi.5.0.9.dylib libffi.dylib; }; }) cp .libs/libffi.lai /Users/mwotton/projects/ghc/libffi/libffi.la cp .libs/libffi.a /Users/mwotton/projects/ghc/libffi/libffi.a chmod 644 /Users/mwotton/projects/ghc/libffi/libffi.a ranlib /Users/mwotton/projects/ghc/libffi/libffi.a ranlib: file: /Users/mwotton/projects/ghc/libffi/libffi.a(ffi64.o) has no symbols ranlib: file: /Users/mwotton/projects/ghc/libffi/libffi.a(darwin64.o) has no symbols libtool: install: warning: remember to run `libtool --finish /usr/local/lib' touch libffi/stamp.ffi.build-shared "cp" libffi/libffi.a libffi/libHSffi.a "cp" libffi/libffi.so libffi/libHSffi-ghc6.11.20090913.dylib "cp" libffi/libffi.a libffi/libHSffi_p.a cp: libffi/libffi.so: No such file or directory make[1]: *** [libffi/libHSffi-ghc6.11.20090913.dylib] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 nice make -j 2 145.90s user 70.38s system 78% cpu 4:37.08 total }}} Comment: Thanks for the report -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 09:26:42 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 09:04:56 2009 Subject: [GHC] #3511: port GHC to OpenBSD/sparc64 (unregisterised is fine) In-Reply-To: <044.84975b11fc9b3b424090411fd29c2c83@localhost> References: <044.84975b11fc9b3b424090411fd29c2c83@localhost> Message-ID: <053.67253c1dbf48bc309fc230718545fd89@localhost> #3511: port GHC to OpenBSD/sparc64 (unregisterised is fine) -----------------------------+---------------------------------------------- Reporter: zooko | Owner: Type: task | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: port sparc64 | Difficulty: Unknown Testcase: | Os: OpenBSD Architecture: Other | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * type: feature request => task * milestone: => _|_ Comment: This task would need a volunteer to do the bootstrapping (and to get the native code generator working, if that is important to you). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 09:29:21 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 09:07:34 2009 Subject: [GHC] #3513: Network package does not work on Windows 2000 In-Reply-To: <044.d382601b86fb983edfc50f7450d8f520@localhost> References: <044.d382601b86fb983edfc50f7450d8f520@localhost> Message-ID: <053.24f0f319a30b6c95c024b87ce400bfbb@localhost> #3513: Network package does not work on Windows 2000 ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries (other) | Version: 6.10.4 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: This looks like a bug in the network package. Please file a ticket on the network trac: http://trac.haskell.org/network/ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 09:36:52 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 09:15:07 2009 Subject: [GHC] #3514: mallocPlainForeignPtrBytes -1000 gives runtime internal error: allocGroup: requested zero blocks In-Reply-To: <052.f949c738ea0d9d2b66116addc98fdaed@localhost> References: <052.f949c738ea0d9d2b66116addc98fdaed@localhost> Message-ID: <061.3357c7d3393f20522354fa31f774e1f8@localhost> #3514: mallocPlainForeignPtrBytes -1000 gives runtime internal error: allocGroup: requested zero blocks -------------------------------+-------------------------------------------- Reporter: andrewbirkett | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 09:37:44 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 09:16:01 2009 Subject: [GHC] #3515: Use --make mode by default In-Reply-To: <045.e62049566365cd39a9e7de440d8eeb80@localhost> References: <045.e62049566365cd39a9e7de440d8eeb80@localhost> Message-ID: <054.7f4fe50c17695b07c5d3ee2d92bdb169@localhost> #3515: Use --make mode by default ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Driver | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 09:45:09 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 09:23:24 2009 Subject: [GHC] #3516: ppc64: broken 'foreign import wrapper' In-Reply-To: <045.4f80f07ad990ddd6d2b1b0efc839e556@localhost> References: <045.4f80f07ad990ddd6d2b1b0efc839e556@localhost> Message-ID: <054.c1fcee998f970568a920a3e60c9438db@localhost> #3516: ppc64: broken 'foreign import wrapper' -------------------------------+-------------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: Compiler (FFI) | Version: 6.10.4 Severity: normal | Resolution: Keywords: ffi, wrapper | Difficulty: Unknown Testcase: yet | Os: Unknown/Multiple Architecture: powerpc64 | -------------------------------+-------------------------------------------- Changes (by igloo): * priority: normal => low * difficulty: => Unknown * milestone: => 6.12 branch Comment: Thanks for the report. This is not a tier 1 arch, so needs a volunteer to look into it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 09:54:38 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 09:32:52 2009 Subject: [GHC] #3517: GHC has lots of extra hidden IOErrorType values In-Reply-To: <045.81ae8140396d0673beafa7c1c19d5515@localhost> References: <045.81ae8140396d0673beafa7c1c19d5515@localhost> Message-ID: <054.9f320928109da58069817af5d530d339@localhost> #3517: GHC has lots of extra hidden IOErrorType values ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 Comment: Ideally we would be moving to an extensible exception hierarchy, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 09:55:33 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 09:33:50 2009 Subject: [GHC] #3519: ghc: panic! (the 'impossible' happened) In-Reply-To: <044.f7668c50f47c7fd7a6c1b6746ff0381d@localhost> References: <044.f7668c50f47c7fd7a6c1b6746ff0381d@localhost> Message-ID: <053.0e7afef8a56b1ea1bd2365beedee4fd6@localhost> #3519: ghc: panic! (the 'impossible' happened) -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * difficulty: => Unknown Old description: > $ ghci Main.hs > GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer ... linking ... done. > Loading package base ... linking ... done. > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.4 for i386-unknown-linux): > getOptions'.parseLanguage(1) went past eof token > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: {{{ $ ghci Main.hs GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): getOptions'.parseLanguage(1) went past eof token Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 09:56:31 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 09:34:45 2009 Subject: [GHC] #3519: ghc: panic! (the 'impossible' happened) In-Reply-To: <044.f7668c50f47c7fd7a6c1b6746ff0381d@localhost> References: <044.f7668c50f47c7fd7a6c1b6746ff0381d@localhost> Message-ID: <053.228d4a480e46068486800a9c0412374d@localhost> #3519: ghc: panic! (the 'impossible' happened) -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -----------------------+---------------------------------------------------- Comment (by igloo): {{{ {-# LANGUAGE TemplateHaskell, DeriveDataTypeable, MultiParamTypeClasses, TypeFamilies, FlexibleContexts #-} import Happstack.State import Data.Typeable --import Control.Monad.State --import Control.Monad.Reader --import Control.Concurrent (MVar) data AppState = AppState { i :: Int , j :: Int , s :: String } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 10:16:48 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 09:55:01 2009 Subject: [GHC] #3519: ghc: panic! (the 'impossible' happened) In-Reply-To: <044.f7668c50f47c7fd7a6c1b6746ff0381d@localhost> References: <044.f7668c50f47c7fd7a6c1b6746ff0381d@localhost> Message-ID: <053.1a591a245dbc3247214cd4a94260516a@localhost> #3519: ghc: panic! (the 'impossible' happened) -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * milestone: => 6.14.1 Comment: Thanks for the report. The HEAD now says {{{ Main.hs:6:13: cannot parse LANGUAGE pragma }}} but it works if you indent the `#-}`, presumably because layout is putting a `;` before it otherwise. I think I would expect the original input to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 10:19:32 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 09:57:46 2009 Subject: [GHC] #3521: ld on mac won't allow -rpath unless you specify macosx_version_min 10.5 In-Reply-To: <046.0e41e1dd06acd0a37310a8fbecfb0663@localhost> References: <046.0e41e1dd06acd0a37310a8fbecfb0663@localhost> Message-ID: <055.cde972fde6c6410d1d24b8584442cadd@localhost> #3521: ld on mac won't allow -rpath unless you specify macosx_version_min 10.5 ---------------------------------+------------------------------------------ Reporter: mwotton | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => Unknown * owner: => igloo * milestone: => 6.12.1 Comment: Thanks for the patch; I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 10:22:53 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 10:01:12 2009 Subject: [GHC] #3524: Add mfilter to Control.Monad In-Reply-To: <051.0391717d448955e9ccc2e936d0523bd6@localhost> References: <051.0391717d448955e9ccc2e936d0523bd6@localhost> Message-ID: <060.67d6ebdb38a60eb2321eda0f14de7f16@localhost> #3524: Add mfilter to Control.Monad ---------------------------------+------------------------------------------ Reporter: JonFairbairn | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 10:23:29 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 10:01:42 2009 Subject: [GHC] #3526: Inliner behaviour with instances is confusing In-Reply-To: <042.8258495ea2dc159620716346effd3b92@localhost> References: <042.8258495ea2dc159620716346effd3b92@localhost> Message-ID: <051.b97277de562c1041aecf7ef49daedc33@localhost> #3526: Inliner behaviour with instances is confusing ---------------------------------+------------------------------------------ Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 10:24:48 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 10:03:01 2009 Subject: [GHC] #3527: unGetChan should be able to interrupt readChan In-Reply-To: <044.f53eb16287d724b9256e806dae312235@localhost> References: <044.f53eb16287d724b9256e806dae312235@localhost> Message-ID: <053.dacec90c42e4b69b4f906ffc0682817a@localhost> #3527: unGetChan should be able to interrupt readChan ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14.1 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 10:25:38 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 10:03:59 2009 Subject: [GHC] #3530: GHCi does not work on Snow Leopard In-Reply-To: <043.67172119f9bd273a2158fec836b33117@localhost> References: <043.67172119f9bd273a2158fec836b33117@localhost> Message-ID: <052.87d2dca4181ce13c30d1fd6927897f7f@localhost> #3530: GHCi does not work on Snow Leopard -------------------------+-------------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.11 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 Comment: It would be great if someone could track this down. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 10:42:43 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 10:20:56 2009 Subject: [GHC] #3532: haddock should support content indexing of versioned package dirs In-Reply-To: <050.349010e190ff2a924354f840d1a8ec2b@localhost> References: <050.349010e190ff2a924354f840d1a8ec2b@localhost> Message-ID: <059.eaa26e530e60247d0e1257310dfedd1d@localhost> #3532: haddock should support content indexing of versioned package dirs ---------------------------------+------------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Documentation | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 10:43:19 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 10:21:38 2009 Subject: [GHC] #3537: Add missing NFData instances to parallel In-Reply-To: <052.18271cd784d6aae76f4ba5d739912c4b@localhost> References: <052.18271cd784d6aae76f4ba5d739912c4b@localhost> Message-ID: <061.c3170f5bf39a569c52e2250eb1230684@localhost> #3537: Add missing NFData instances to parallel ----------------------------------+----------------------------------------- Reporter: Roel van Dijk | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 10:43:11 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 10:21:41 2009 Subject: [GHC] #3533: mac installer package deletes old version of ghc In-Reply-To: <068.c01b30dc01c8d35f26692e95513280f4@localhost> References: <068.c01b30dc01c8d35f26692e95513280f4@localhost> Message-ID: <077.0f8a640a7bde6d3bccfa1128a32268ce@localhost> #3533: mac installer package deletes old version of ghc ----------------------------------------------+----------------------------- Reporter: malcolm.wallace@cs.york.ac.uk | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ----------------------------------------------+----------------------------- Changes (by igloo): * milestone: => 6.12 branch Comment: It would be great if someone could look into implementing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 10:43:38 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 10:21:59 2009 Subject: [GHC] #3540: Parser accepts malformed types with implicit parameters In-Reply-To: <043.a36047b0c114003b419dbf8833abfb27@localhost> References: <043.a36047b0c114003b419dbf8833abfb27@localhost> Message-ID: <052.828d92117187da5b974654f3bd1e6de5@localhost> #3540: Parser accepts malformed types with implicit parameters ----------------------------------+----------------------------------------- Reporter: benl | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler (Parser) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12 branch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 13:39:22 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 13:17:40 2009 Subject: [GHC] #3521: ld on mac won't allow -rpath unless you specify macosx_version_min 10.5 In-Reply-To: <046.0e41e1dd06acd0a37310a8fbecfb0663@localhost> References: <046.0e41e1dd06acd0a37310a8fbecfb0663@localhost> Message-ID: <055.7a4107eb74d816b7ba52ee904149b50b@localhost> #3521: ld on mac won't allow -rpath unless you specify macosx_version_min 10.5 ---------------------------------+------------------------------------------ Reporter: mwotton | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Applied, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 13:39:48 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 13:18:14 2009 Subject: [GHC] #3505: type mismatch error message with operator sections counts the arguments incorrectly In-Reply-To: <049.b0dca9b9c9ba59c25cb61ac760d64c4f@localhost> References: <049.b0dca9b9c9ba59c25cb61ac760d64c4f@localhost> Message-ID: <058.73088e5f8ebf6ac0ee7e363e3832c320@localhost> #3505: type mismatch error message with operator sections counts the arguments incorrectly ---------------------------------+------------------------------------------ Reporter: benmachine | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 14:25:58 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 14:04:16 2009 Subject: [GHC] #3530: GHCi does not work on Snow Leopard In-Reply-To: <043.67172119f9bd273a2158fec836b33117@localhost> References: <043.67172119f9bd273a2158fec836b33117@localhost> Message-ID: <052.e55434e18c29f6422ce1b9c2582a7a9d@localhost> #3530: GHCi does not work on Snow Leopard -------------------------+-------------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.11 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by altaic): It may be worthwhile to note that supporting builds of universal binaries would solve this issue. Or perhaps that depends on this issue. Those tickets are: http://hackage.haskell.org/trac/ghc/ticket/872 [[BR]] http://hackage.haskell.org/trac/ghc/ticket/964 Also, it's important to note that previously "Universal Binary" meant PPC+x86 in one binary, but post Snow Leopard it refers to x86+x86_64; PPC support was dropped for SL, and the new "deprecated" architecture is x86. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 16:56:57 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 16:35:12 2009 Subject: [GHC] #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 In-Reply-To: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> References: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> Message-ID: <056.f16a6ea481971603fea1d41da2bd507d@localhost> #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 -------------------------------+-------------------------------------------- Reporter: elaforge | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by elaforge): Well, it fails quite infrequently, and I can discern no pattern. It's done this 4 or 5 times since I upgraded to 6.10.4 (I never saw it before then). It's invoked with "+RTS -N2 -RTS" and links to various C libraries, some of which call back into haskell (yes I'm using "safe" for those). The crash is during startup but I think after some initialization has occurred. Since I can't trigger it reliably it's hard to track down. It's possible there's some corruption from my C code, that for some reason only causes a crash when the system clock is a prime number or something like that. Also the binary is 35mb... still want it? Maybe if you set it up running and quitting all night maybe you could get it to happen, but since I have no idea what's causing it, even that is not guaranteed. For that matter, maybe I should set it up to do that but I wouldn't know how to get more info out of the error... Sorry it's so vague! I'd be happy to help if you have suggestions. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Sep 24 21:52:17 2009 From: trac at galois.com (GHC) Date: Thu Sep 24 21:30:36 2009 Subject: [GHC] #3530: GHCi does not work on Snow Leopard In-Reply-To: <043.67172119f9bd273a2158fec836b33117@localhost> References: <043.67172119f9bd273a2158fec836b33117@localhost> Message-ID: <052.9b8ee908c2f6717504b33df1d89d4a05@localhost> #3530: GHCi does not work on Snow Leopard -------------------------+-------------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.11 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by chak): We definitely want '''both''' 32-bit and 64-bit support, but this ticket really is only about fixing the regression of GHCi from 32-bit Leopard to 32-bit Snow Leopard. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 25 10:06:02 2009 From: trac at galois.com (GHC) Date: Fri Sep 25 09:44:13 2009 Subject: [GHC] #3541: Allow local foreign imports Message-ID: <044.f182d5c0327086f8b5193630cf333bb0@localhost> #3541: Allow local foreign imports -----------------------------+---------------------------------------------- Reporter: mokus | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (FFI) Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I have no idea the level of difficulty this would entail, but it would be rather nice to be able to import foreign functions at scopes other than the top level. When writing glue code, especially for C++ where I often want to catch and haskellize exceptions, I find myself using wrappers quite a bit, for example: {{{ foreign import ccall "foo.h foo" raw_foo :: CString -> IO () foo :: String -> IO () foo s = withCString s raw_foo }}} Where I only want "foo" exported from the module. It's not that big a deal to list explicit exports, I know, but I would like to be able to say instead: {{{ foo :: String -> IO () foo s = withCString s raw_foo where foreign import ccall "foo.h foo" raw_foo :: CString -> IO () }}} In addition to reducing clutter in the top level namespace, it makes for less clutter on the left margin of the code, making it easier to scan through function names visually. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 25 18:49:33 2009 From: trac at galois.com (GHC) Date: Fri Sep 25 18:27:43 2009 Subject: [GHC] #3542: ghc-cabal deadlocks Message-ID: <044.1fecb1a5d877ecd5d5e8b6ef5145e963@localhost> #3542: ghc-cabal deadlocks -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Trying to build an OS X installer is currently deadlocking when {{{ inplace/bin/ghc-cabal install /Users/ian/ghc/6.12-branch/val/dest/Users/ian/ghc/6.12-branch/val/inst/lib/ghc-6.12.0.20090925 /ghc-stage2 /Users/ian/ghc/6.12-branch/val/dest/Users/ian/ghc/6.12-branch/val/inst/lib/ghc-6.12.0.20090925 /ghc-pkg /Users/ian/ghc/6.12-branch/val/dest/Users/ian/ghc/6.12-branch/val/inst/lib/ghc-6.12.0.20090925 compiler stage2 /Users/ian/ghc/6.12-branch/val/dest /Users/ian/ghc/6.12-branch/val/inst /Users/ian/ghc/6.12-branch/val/inst/lib/ghc-6.12.0.20090925 /Users/ian/ghc/6.12-branch/val/inst/share/doc/ghc/html/libraries }}} runs: {{{ /Users/ian/ghc/6.12-branch/val/dest/Users/ian/ghc/6.12-branch/val/inst/lib/ghc-6.12.0.20090925 /ghc-pkg --global-conf /Users/ian/ghc/6.12-branch/val/dest/Users/ian/ghc/6.12-branch/val/inst/lib/ghc-6.12.0.20090925/package.conf.d --force update - --global }}} Linking `ghc-cabal` with `-threaded` fixes the problem. I believe the problem is that when we are using a `DESTDIR` we get a large amount of warnings (more than a buffer full) like: {{{ ghc-6.12.0.20090925: file AsmCodeGen.hi is missing (ignoring) }}} so Cabal's `Distribution.Simple.Utils.rawSystemStdin`: {{{ _ <- forkIO $ do _ <- evaluate (length err); return () _ <- forkIO $ do _ <- evaluate (length out); return () -- push all the input hPutStr inh input hClose inh -- wait for the program to terminate exitcode <- waitForProcess pid unless (exitcode == ExitSuccess) (die err) }}} deadlocks unless it is compiled with `-threaded`, as the forked evaluate threads don't get a chance to run. The simple fix is to link with `-threaded`, but I'm not sure that we want to assume that `-threaded` works - especially as it needs to work in the bootstrapping compiler. Can we eliminate calls to this, and any other problematic, functions? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Sep 25 19:12:21 2009 From: trac at galois.com (GHC) Date: Fri Sep 25 18:50:35 2009 Subject: [GHC] #3543: -fext-core doesn't force recompilation when .hcr file doesn't exist Message-ID: <042.a500bc81bb090118bd5e70ada170bc6f@localhost> #3543: -fext-core doesn't force recompilation when .hcr file doesn't exist -----------------------------+---------------------------------------------- Reporter: tim | Owner: Type: bug | Status: new Priority: normal | Component: Driver Version: 6.10.4 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- If I do: ghc -o foo foo.hs and then immediately afterward: ghc -fext-core -c foo.hs and foo.hcr doesn't exist, ghc still says "Compilation is not required" and doesn't create the External Core file. It should generate the .hcr given the -fext-core flag, even if the .hi file is up to date. Sorry if this is a duplicate bug (I know that making the compilation manager pay attention to flags is an ongoing issue). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 26 10:46:27 2009 From: trac at galois.com (GHC) Date: Sat Sep 26 10:24:35 2009 Subject: [GHC] #3542: ghc-cabal deadlocks In-Reply-To: <044.1fecb1a5d877ecd5d5e8b6ef5145e963@localhost> References: <044.1fecb1a5d877ecd5d5e8b6ef5145e963@localhost> Message-ID: <053.80e7cec7b9800fda876ca8506dff6fa2@localhost> #3542: ghc-cabal deadlocks ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): That code really should not deadlock, even in the single threaded rts. It's just pushing and pulling from pipes. Is the IO library creating pipes in blocking mode or something? If so, that's what needs fixing. As far as I can see this code is correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 26 10:49:28 2009 From: trac at galois.com (GHC) Date: Sat Sep 26 10:27:35 2009 Subject: [GHC] #3542: ghc-cabal deadlocks In-Reply-To: <044.1fecb1a5d877ecd5d5e8b6ef5145e963@localhost> References: <044.1fecb1a5d877ecd5d5e8b6ef5145e963@localhost> Message-ID: <053.ba1c736e9c38c96380cc719187bdaa4d@localhost> #3542: ghc-cabal deadlocks ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): BTW, if it is that the pipes are opened in blocking mode, it's unnecessary. The blocking mode of each end of the pipe can be set independently, so it's possible to pass a blocking mode pipe to the other process and keep our end non-blocking. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Sep 26 10:55:36 2009 From: trac at galois.com (GHC) Date: Sat Sep 26 10:33:43 2009 Subject: [GHC] #3542: ghc-cabal deadlocks In-Reply-To: <044.1fecb1a5d877ecd5d5e8b6ef5145e963@localhost> References: <044.1fecb1a5d877ecd5d5e8b6ef5145e963@localhost> Message-ID: <053.f6669fd995c6d3b10e0bc8714f1b15bf@localhost> #3542: ghc-cabal deadlocks ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Ian points out that it's the `waitForProcess` that is the problem. That is the thing that blocks the whole process, when we're using the single threaded rts. We conjecture this code is impossible to write correctly using runInteractiveProcess and the single threaded rts. It may be possible using the newer createProcess function. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 27 11:14:51 2009 From: trac at galois.com (GHC) Date: Sun Sep 27 10:54:24 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.08bc5e72caa9d62a233bf16f5422da56@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: chak Type: bug | Status: reopened Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by GregoryCollins): * status: closed => reopened * resolution: fixed => Comment: I don't think that the advice on the mailing list is enough to fix all of the issues, which is why you're seeing test failures with FFI. I'm using the stock 6.10.4 OSX binary release on Snow Leopard, with the shell script wrappers patched to add "-optc-m32 -opta-m32 -optl-m32". I can't get zlib to build properly, I keep getting "incompatible zlib version" errors. After pounding my head at it for a while, and confirming "yes, I'm linking to the correct zlib" and "yes, this is a 32-bit executable", I decided to get to the bottom of it. I built a version of the C zlib in debugging mode and set a breakpoint on the init function. It's failing here (inflate.c line 152): {{{ if (version == Z_NULL || version[0] != ZLIB_VERSION[0] || stream_size != (int)(sizeof(z_stream))) return Z_VERSION_ERROR; }}} In gdb: {{{ (gdb) print stream_size $3 = 112 (gdb) print sizeof(z_stream) $4 = 56 }}} Hmm, that isn't right. Here's the relevant snippet of {{{Stream.hsc}}}: {{{ c_inflateInit2 :: StreamState -> CInt -> IO CInt c_inflateInit2 z n = withCAString #{const_str ZLIB_VERSION} $ \versionStr -> c_inflateInit2_ z n versionStr (#{const sizeof(z_stream)} :: CInt) }}} Looks like that "sizeof" is being executed in a 64-bit context by hsc2hs; I haven't seen this mentioned on the mailing list but I think users also need to patch /usr/bin/hsc2hs to read: {{{ exec /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/hsc2hs $tflag $HSC2HS_EXTRA --cflag="-m32" --lflag="-m32" ${1+"$@"} "$Iflag" }}} Does the aforementioned patch address this issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 27 12:12:58 2009 From: trac at galois.com (GHC) Date: Sun Sep 27 11:51:30 2009 Subject: [GHC] #2578: "ld: atom sorting error for ..." on OS X In-Reply-To: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> References: <044.426e3c7e28718ff62aa1ff6b2d89715c@localhost> Message-ID: <053.db93137bd53f890e562132f69989dfc6@localhost> #2578: "ld: atom sorting error for ..." on OS X ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.2 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: 6.12.1 => 6.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 27 16:30:23 2009 From: trac at galois.com (GHC) Date: Sun Sep 27 16:08:28 2009 Subject: [GHC] #3544: Add instance IsString ShowS where fromString = showString Message-ID: <049.9e51a8e67140bc1cfbcf407623a0d367@localhost> #3544: Add instance IsString ShowS where fromString = showString -----------------------------+---------------------------------------------- Reporter: basvandijk | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- It would be really nice to use [http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class- extensions.html#overloaded-strings OverloadedStrings] when writing a definition of [http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:showsPrec showsPrec] in an instance for Show. The attached patch adds the necessary instance to {{{base/GHC/Show.lhs}}}: {{{ instance IsString ShowS where fromString = showString }}} Note that this does require {{{TypeSynonymInstances}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 27 17:14:31 2009 From: trac at galois.com (GHC) Date: Sun Sep 27 16:52:36 2009 Subject: [GHC] #3545: As-patterns for type signatures Message-ID: <053.fe8bf7158bc08565495d5ddfb70742d3@localhost> #3545: As-patterns for type signatures -----------------------------+---------------------------------------------- Reporter: LouisWasserman | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The proposal: in any type signature, the presence of type variable x@pat matches the type specified by pat, and replaces any occurrences of the type variable x with pat. In particular, this might be comparable to defining type x (free variables in pat) = pat with scope solely to the right of the as-pattern. Alternately, it might be compared to an equality constraint (x ~ pat). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 27 21:29:01 2009 From: trac at galois.com (GHC) Date: Sun Sep 27 21:07:05 2009 Subject: [GHC] #2972: GHCi broken in GHC 6.10.1 In-Reply-To: <046.36c84703d6f462149fdd781bf29492ec@localhost> References: <046.36c84703d6f462149fdd781bf29492ec@localhost> Message-ID: <055.6cf6c75e74052fe5b527153d200ad34d@localhost> #2972: GHCi broken in GHC 6.10.1 ------------------------+--------------------------------------------------- Reporter: cemeyer | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: powerpc | ------------------------+--------------------------------------------------- Changes (by wkahl): * cc: kahl@cas.mcmaster.ca (added) Comment: Running from gdb, I saw it crashing always in libcurses. Disabling package terminfo by editing `libraries/terminfo/configure.ac` to contain impossible library names (`no-*`) for `curses` {{{ AC_CHECK_LIB(no-ncursesw, setupterm, HaveLibCurses=YES; LibCurses=ncursesw, AC_CHECK_LIB(no-ncurses, setupterm, HaveLibCurses=YES; LibCurses=ncurses, AC_CHECK_LIB(no-curses, setupterm, HaveLibCurses=YES; LibCurses=curses, HaveLibCurses=NO; LibCurses=not-installed))) }}} in ghc-6.10.4 gives me a GHCi that now segfaults at start-up only occasionally (instead of always, as before). And if it doesn't segfault, it appears to work, and even has command-line editing. (Silightly less than half the starts segfault, in over 50 attempts.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 27 21:30:40 2009 From: trac at galois.com (GHC) Date: Sun Sep 27 21:08:44 2009 Subject: [GHC] #2972: GHCi broken in GHC 6.10.1 In-Reply-To: <046.36c84703d6f462149fdd781bf29492ec@localhost> References: <046.36c84703d6f462149fdd781bf29492ec@localhost> Message-ID: <055.4c8c06228c828afeb766665d66f8483a@localhost> #2972: GHCi broken in GHC 6.10.1 ------------------------+--------------------------------------------------- Reporter: cemeyer | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: powerpc | ------------------------+--------------------------------------------------- Changes (by wkahl): * cc: kahl@cas.mcmaster.ca (removed) * cc: wkahl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Sep 27 23:45:38 2009 From: trac at galois.com (GHC) Date: Sun Sep 27 23:23:41 2009 Subject: [GHC] #3546: Use of float type in unregistered build freezes program Message-ID: <045.6ea33c309ca87fd9faa6c939333fbcac@localhost> #3546: Use of float type in unregistered build freezes program ---------------------------------------+------------------------------------ Reporter: dterei | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: | Severity: critical Keywords: float unregistered freezes | Testcase: arith006 Os: Unknown/Multiple | Architecture: Unknown/Multiple ---------------------------------------+------------------------------------ If you compile a ghc HEAD version in unregistered mode there is a bug that causes any programs compiled by this ghc to freeze when they try to access a float. == build.mk == {{{ SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O GhcStage2HcOpts = -O2 GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 -XGenerics GhcLibWays += p SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO GhcUnregisterised = YES GhcWithNativeCodeGen = NO }}} == Program which produces bug: == {{{ main = do putStrLn "Print float test" putStrLn (show (1.2312341::Float)) }}} == Steps to reproduce == 1. Compile latest version of ghc from darcs using the above build.mk configuration (other build.mk trigger the bug as well, must be unregistered though). 2. Compile the above haskell program with this ghc. 3. Run the program, it will freeze indefinitely 4. The test case ''arith006'' also triggers the bug. == My machine == * x86, Ubuntu 9.04, 32 bit. * uname -v {{{ Linux david-laptop 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux }}} * gcc -v {{{ Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --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.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable- targets=all --with-tune=generic --enable-checking=release --build=i486 -linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 06:19:35 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 05:57:38 2009 Subject: [GHC] #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 In-Reply-To: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> References: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> Message-ID: <056.74e58631f2f2e65eb0622be0b90c9bfb@localhost> #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 -------------------------------+-------------------------------------------- Reporter: elaforge | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by simonmar): Sorry for not being clear - I'd like the ''source code'' not the binary. We need to be able to reproduce the failure in order to fix it. Another helpful thing you could do is to try to reduce the problem - remove parts of your program until the failure goes away. I understand this might be difficult if the failure is hard to reproduce. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 07:15:24 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 06:53:26 2009 Subject: [GHC] #3542: ghc-cabal deadlocks In-Reply-To: <044.1fecb1a5d877ecd5d5e8b6ef5145e963@localhost> References: <044.1fecb1a5d877ecd5d5e8b6ef5145e963@localhost> Message-ID: <053.c576b413fc70970b1108ae09bf381fd7@localhost> #3542: ghc-cabal deadlocks ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): I mentioned this to Ian this morning on the phone, but just to record it here: it is indeed possible to write this code correctly using the single- threaded RTS, an example of how to do so is the implementation of `readProcess` and `readProcessWithExitCode` in recent versions of `System.Process`. Here's a snippet: {{{ readProcess cmd args input = do (Just inh, Just outh, _, pid) <- createProcess (proc cmd args){ std_in = CreatePipe, std_out = CreatePipe, std_err = Inherit } -- fork off a thread to start consuming the output output <- hGetContents outh outMVar <- newEmptyMVar _ <- forkIO $ C.evaluate (length output) >> putMVar outMVar () -- now write and flush any input when (not (null input)) $ do hPutStr inh input; hFlush inh hClose inh -- done with stdin -- wait on the output takeMVar outMVar hClose outh -- wait on the process ex <- waitForProcess pid ... }}} the idea is that you block on an `MVar` instead of in `waitForProcess`. This assumes that if the process goes away then the pipe will also go away and the threads will stop. Actually I think the code should be using `finally` to make sure the `MVar` gets written even if an exception is raised. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 07:21:47 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 06:59:50 2009 Subject: [GHC] #3546: Use of float type in unregistered build freezes program In-Reply-To: <045.6ea33c309ca87fd9faa6c939333fbcac@localhost> References: <045.6ea33c309ca87fd9faa6c939333fbcac@localhost> Message-ID: <054.f21179169439ada477598e5a1a2713a7@localhost> #3546: Use of float type in unregistered build freezes program -------------------------------------------+-------------------------------- Reporter: dterei | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: Severity: critical | Resolution: Keywords: float unregistered freezes | Difficulty: Unknown Testcase: arith006 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * owner: => simonmar * milestone: => 6.12.1 Comment: Fascinating. I can reproduce on our unregisterised nightly build. I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 08:00:29 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 07:38:31 2009 Subject: [GHC] #3547: Improve granularity of UndecidableInstances Message-ID: <042.ab1d6403ab4b4f4b9e3a8bbdc17f05e1@localhost> #3547: Improve granularity of UndecidableInstances -----------------------------+---------------------------------------------- Reporter: ksf | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Currently, as a LANGUAGE pragma, UndecidableInstances can only be set once per file: Assuming that there are enough occasions where one would only need to enable it for one or two instances in a bigger source and considering that the warnings emitted if UndecidableInstances is not set are actually useful, it makes sense to support enabling the extension only on a per-instance basis. proposed syntax: {{{ {-# LANGUAGE UndecidableInstances #-} [code] {-# NOLANGUAGE UndecidableInstances #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 09:23:14 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 09:01:18 2009 Subject: [GHC] #3548: test T3294 incorrectly reported as error for unregistered build Message-ID: <045.3508f93b8c2d71a124ee09b2c47fcd9e@localhost> #3548: test T3294 incorrectly reported as error for unregistered build -----------------------------+---------------------------------------------- Reporter: dterei | Owner: Type: bug | Status: new Priority: normal | Component: Test Suite Version: 6.10.4 | Severity: normal Keywords: | Testcase: T3294 Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The testsuite test, ''T3294'' is incorrectly reported as an error when the testsuite is ran against an unregistered build of GHC. The test is set to run in only the ''normal'' way. When GHC is built without a native code generator then the normal way is through the C code generator and so the test runs instead of being skipped. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 09:46:23 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 09:24:27 2009 Subject: [GHC] #3546: Use of float type in unregistered build freezes program In-Reply-To: <045.6ea33c309ca87fd9faa6c939333fbcac@localhost> References: <045.6ea33c309ca87fd9faa6c939333fbcac@localhost> Message-ID: <054.fd08d50592924520d5766df4ff521420@localhost> #3546: Use of float type in unregistered build freezes program -------------------------------------------+-------------------------------- Reporter: dterei | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: Severity: critical | Resolution: Keywords: float unregistered freezes | Difficulty: Unknown Testcase: arith006 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Comment (by dterei): Another test failing in unregistered mode is ''1852''. Given it deals with floats I assume its related to this bug. However unlike all the other tests which fail by freezing, this one fails quite spectacularly by printing out 4 huge numbers instead of the expected '[1,2,3,4]'. The output produces 11M of data. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 09:56:53 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 09:34:54 2009 Subject: [GHC] #3546: Use of float type in unregistered build freezes program In-Reply-To: <045.6ea33c309ca87fd9faa6c939333fbcac@localhost> References: <045.6ea33c309ca87fd9faa6c939333fbcac@localhost> Message-ID: <054.649a53132f7fb3dfcd1611d81e57ed8a@localhost> #3546: Use of float type in unregistered build freezes program -------------------------------------------+-------------------------------- Reporter: dterei | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: Severity: critical | Resolution: Keywords: float unregistered freezes | Difficulty: Unknown Testcase: arith006 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------------+-------------------------------- Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed (nice bug!) {{{ Mon Sep 28 05:44:55 PDT 2009 Simon Marlow * emitRetUT: cope with arguments overlapping with results (#3546) In decodeFloat_Int# we have the C-- code: mp_tmp1 = Sp - WDS(1); mp_tmp_w = Sp - WDS(2); /* arguments: F1 = Float# */ arg = F1; /* Perform the operation */ foreign "C" __decodeFloat_Int(mp_tmp1 "ptr", mp_tmp_w "ptr", arg) []; /* returns: (Int# (mantissa), Int# (exponent)) */ RET_NN(W_[mp_tmp1], W_[mp_tmp_w]); Which all looks quite reasonable. The problem is that RET_NN() might assign the results to the stack (with an unregisterised back end), and in this case the arguments to RET_NN() refer to the same stack slots that will be assigned to. The code generator should do the right thing here, but it wasn't - it was assuming that it could assign the results sequentially. A 1-line fix to use emitSimultaneously rather than emitStmts (plus comments). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 09:58:51 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 09:36:57 2009 Subject: [GHC] #3530: GHCi does not work on Snow Leopard In-Reply-To: <043.67172119f9bd273a2158fec836b33117@localhost> References: <043.67172119f9bd273a2158fec836b33117@localhost> Message-ID: <052.f2b505a87615ceb778298262e22cf731@localhost> #3530: GHCi does not work on Snow Leopard -------------------------+-------------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.11 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by simonmar): There's a possibility that this may have been fixed by #3546. Might be worth trying again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 12:20:31 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 11:58:32 2009 Subject: [GHC] #3549: unlit does not follow H98 spec Message-ID: <045.eacb9764be0b8b701a8c620148ff0200@localhost> #3549: unlit does not follow H98 spec -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The Haskell 98 spec has this to say about the [http://haskell.org/onlinereport/syntax-iso.html Latex \begin{code} \end{code}] style: An alternative style of literate programming is particularly suitable for use with the LaTeX text processing system. In this convention, only those parts of the literate program that are entirely enclosed between \begin{code}...\end{code} delimiters are treated as program text; all other lines are comment. More precisely: * Program code begins on the first line following a line that begins \begin{code}. * Program code ends just before a subsequent line that begins \end{code} (ignoring string literals, of course). The key phrases are "a line that begins \begin{code}" and "line that begins \end{code}". This means the semantics is something like: {{{ classifyLine s | "\\begin{code}" `isPrefixOf` s = BeginCode | "\\end{code}" `isPrefixOf` s = EndCode }}} GHC's `unlit` C program uses: {{{ if (strcmp(buf, "\\begin{code}") == 0) return BEGIN; }}} The equivalent semantics in the style above would be: {{{ classifyLine s | "\\begin{code}" == s = BeginCode | "\\end{code}" == s = EndCode }}} It seems fairly clear from the spec that GHC's unlit program is wrong in this respect. The practical consequence is that Cabal's unlit and GHC's one do not match and this [http://haskell.org/pipermail/haskell- cafe/2009-September/066780.html catches people out]. There is [http://www.haskell.org/haskellwiki/Literate_programming#Hiding_code_from_Haskell explicit advice on the Haskell wiki] recommending that people take advantage of this GHC bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 12:50:44 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 12:28:45 2009 Subject: [GHC] #3549: unlit does not follow H98 spec In-Reply-To: <045.eacb9764be0b8b701a8c620148ff0200@localhost> References: <045.eacb9764be0b8b701a8c620148ff0200@localhost> Message-ID: <054.fea5fe003b3f640937efb781fa2501b3@localhost> #3549: unlit does not follow H98 spec ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Comment: I thought that following http://www.haskell.org/pipermail/haskell/2001-December/008549.html we decided that only lines starting `\begin{code}` or `\end{code}` and followed only by whitespace marked literate code boundaries, but I now can't find any evidence of that. Anyway, that still seems the most sensible definition to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 12:52:09 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 12:30:13 2009 Subject: [GHC] #3542: ghc-cabal deadlocks In-Reply-To: <044.1fecb1a5d877ecd5d5e8b6ef5145e963@localhost> References: <044.1fecb1a5d877ecd5d5e8b6ef5145e963@localhost> Message-ID: <053.8ce7c8918ca1e556198e21a562d57f1b@localhost> #3542: ghc-cabal deadlocks ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Ah yes, ok and I guess that extends ok to discarding both stdout and stderr. We just wait for both MVars. Perhaps it'd be useful to have an extra `StdStream` constructor for `UseNullHandle` (or a better name) to use `/dev/null` on POSIX or `nul` on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 13:13:44 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 12:51:57 2009 Subject: [GHC] #3549: unlit does not follow H98 spec In-Reply-To: <045.eacb9764be0b8b701a8c620148ff0200@localhost> References: <045.eacb9764be0b8b701a8c620148ff0200@localhost> Message-ID: <054.eb12d44090afdc16e5db0a903b96820d@localhost> #3549: unlit does not follow H98 spec ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by malcolm.wallace@cs.york.ac.uk): The case prompting this bug report has LaTeX comments (i.e. introduced with a % char) after, but on the same line as, \begin{code} and \end{code}. This seems entirely reasonable - the %-introduced comment belongs to the document language, not to Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 13:23:16 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 13:01:26 2009 Subject: [GHC] #3549: unlit does not follow H98 spec In-Reply-To: <045.eacb9764be0b8b701a8c620148ff0200@localhost> References: <045.eacb9764be0b8b701a8c620148ff0200@localhost> Message-ID: <054.56bdc96d06c06e51e038d36aefcc2535@localhost> #3549: unlit does not follow H98 spec ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Replying to [comment:2 malcolm.wallace@cs.york.ac.uk]: > The case prompting this bug report has LaTeX comments (i.e. introduced with a % char) after, but on the same line as, \begin{code} and \end{code}. This seems entirely reasonable - the %-introduced comment belongs to the document language, not to Haskell. What seems entirely reasonable to you? That a `\begin{code}%...` line should be treated as starting a code section, or that it should not be? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 14:01:24 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 13:39:33 2009 Subject: [GHC] #3549: unlit does not follow H98 spec In-Reply-To: <045.eacb9764be0b8b701a8c620148ff0200@localhost> References: <045.eacb9764be0b8b701a8c620148ff0200@localhost> Message-ID: <054.7b7fe91eef923042f2607f14ea6f3bc0@localhost> #3549: unlit does not follow H98 spec ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by malcolm.wallace@cs.york.ac.uk): It seems reasonable to me that \end{code} % foo should be treated as ending a code section. Given that \begin{bar} something \end{bar} is legal LaTeX, for any given bar, it is up to the definition of the bar environment what it does with the enclosed text, including the text that appears on the same line as the introducing \begin{}. The definition in the Haskell Report of the \begin{code} environment is clear that any text on the same line is discarded. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 14:10:39 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 13:48:40 2009 Subject: [GHC] #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 In-Reply-To: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> References: <047.ce838bf90bf0705c86e1a5b8acf0114d@localhost> Message-ID: <056.7f389a8779edce5a550d3f549deee116@localhost> #3539: internal error: ASSERTION FAILED: file sm/Evac.c, line 368 -------------------------------+-------------------------------------------- Reporter: elaforge | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by elaforge): Ah, I see. Yes, it's hard to track it down. I link to C for GUI and for access to OS X midi, with about 20k lines of haskell and 8k lines of c++, so it could do with some reduction. I'm guessing it has to do with the C binding since it seems to crash while calling into C to set up the GUI. Also there are a couple of threads running at that point, though all C calls are serialized through a single thread. I'm putting in some more logging to try to figure out where it happens. It's actually happened more frequently lately so if it keeps up this frequency I might actually be able to figure out where it is... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 16:45:58 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 16:24:08 2009 Subject: [GHC] #3549: unlit does not follow H98 spec In-Reply-To: <045.eacb9764be0b8b701a8c620148ff0200@localhost> References: <045.eacb9764be0b8b701a8c620148ff0200@localhost> Message-ID: <054.6ac07ea445db1199275d0cffa0fc1dad@localhost> #3549: unlit does not follow H98 spec ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by jmillikin): * cc: jmillikin@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 17:38:12 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 17:16:20 2009 Subject: [GHC] #3550: Dynamic libraries don't work on Mac OS/X Message-ID: <056.c6f0034a4d5f342c60f11476270241e0@localhost> #3550: Dynamic libraries don't work on Mac OS/X ------------------------------+--------------------------------------------- Reporter: StephenBlackheath | Owner: StephenBlackheath Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: major Keywords: dynamic mac osx | Testcase: http://upcycle.it/~blackh/ghc/test-case.tar.bz2 Os: MacOS X | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- GHC doesn't build properly on Mac OS/X when dynamic library support is enabled. And, when GHC is successfully built with dynamic library support (with tweaks), it doesn't build or link dynamic libraries properly. I've provided a set of patches, broken up with explanations. We need to discuss whether adding an -install-name option to GHC is acceptable to the GHC team. Note: A separate patch for Cabal uses the new -install-name option. Without this applying this in the ghc tree, the Cabal installed along with ghc will not generate shared libraries on Mac OS/X with the right install name. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 19:39:05 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 19:17:13 2009 Subject: [GHC] #3549: unlit does not follow H98 spec In-Reply-To: <045.eacb9764be0b8b701a8c620148ff0200@localhost> References: <045.eacb9764be0b8b701a8c620148ff0200@localhost> Message-ID: <054.3c0fb1f134ea97ea9bffd15a291fe31f@localhost> #3549: unlit does not follow H98 spec ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Hmm, the report says that {{{ Program code ends just before a subsequent line that begins \end{code} (ignoring string literals, of course). }}} which suggests that the first `\end{code}` in: {{{ \begin{code} foo = "hello\ \end{code}" \end{code} }}} does not end the code block, but I don't think the unlit'er should have to be able to know whether or not it is inside a string literal (and thus have to keep track of at least string literals and comment depth). I suggest clarifying (and possibly changing) the design with H'2011, and no action until then. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 20:02:46 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 19:41:02 2009 Subject: [GHC] #3550: Dynamic libraries don't work on Mac OS/X In-Reply-To: <056.c6f0034a4d5f342c60f11476270241e0@localhost> References: <056.c6f0034a4d5f342c60f11476270241e0@localhost> Message-ID: <065.043e82e6b64b6844a8d1e4d1bca6213f@localhost> #3550: Dynamic libraries don't work on Mac OS/X -------------------------------+-------------------------------------------- Reporter: StephenBlackheath | Owner: StephenBlackheath Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: dynamic mac osx | Testcase: http://upcycle.it/~blackh/ghc/test-case.tar.bz2 Os: MacOS X | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by chak): From what I understand about dylibs on Mac OS, the proposed -install-name option does make sense. I had a quick lock at the patch and it seems reasonable to me. I haven't validated it, though. I'm in favour of accepting these changes. I'll be happy to validate this and push if GHC HQ is happy with this. Not sure how you want to handle the Cabal part of this. Duncan? (There needs to be an additional patch to the GHC docs, though, to document the new option.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 20:20:56 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 19:58:59 2009 Subject: [GHC] #3551: Tests conc069 and conc070 failing for unregistered build Message-ID: <045.94f74b3da2564c9807512be40aa93367@localhost> #3551: Tests conc069 and conc070 failing for unregistered build -----------------------------+---------------------------------------------- Reporter: dterei | Owner: Type: bug | Status: new Priority: normal | Component: Test Suite Version: | Severity: normal Keywords: | Testcase: conc069 Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The two tests ''conc069'' and ''conc070'' both fail for an unregistered build. I believe the issue is that both these tests are meant to be skipped. ''conc069'' requires a threaded RTS, which isn't possible in an unregistered build and ''conc070'' runs fine but apparently produces slightly different output for an unregistered build. The driver file for these test, ''./concurrent/should_run/all.T'' contains the following: {{{ if ('threaded1' in config.run_ways): threaded_ways = ['ghci','threaded1','threaded2'] else: threaded_ways = [] test('conc069', only_ways(threaded_ways), compile_and_run, ['']) # this test gives slightly different results for non-threaded ways, so omit # those for now. test('conc070', only_ways(threaded_ways), compile_and_run, ['']) test('conc070', only_ways(threaded_ways), compile_and_run, ['']) }}} My understanding is that the if clause is meant to skip the test if 'threaded1' hasn't been set. However the else clause doesn't achieve this, giving only_ways and empty list instead causes it to run every way. Changing these lines to: {{{ if ('threaded1' in config.run_ways): threaded_ways = ['ghci','threaded1','threaded2'] else: threaded_ways = [''] }}} Seems to work as intended, causing ''conc069'' and ''conc070'' to be skipped when not using a threaded RTS. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 20:26:51 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 20:05:07 2009 Subject: [GHC] #3550: Dynamic libraries don't work on Mac OS/X In-Reply-To: <056.c6f0034a4d5f342c60f11476270241e0@localhost> References: <056.c6f0034a4d5f342c60f11476270241e0@localhost> Message-ID: <065.eabf9a7f7cfb00fbcf42a0b488f30e8e@localhost> #3550: Dynamic libraries don't work on Mac OS/X -------------------------------+-------------------------------------------- Reporter: StephenBlackheath | Owner: StephenBlackheath Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: dynamic mac osx | Testcase: http://upcycle.it/~blackh/ghc/test-case.tar.bz2 Os: MacOS X | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by StephenBlackheath): If there's general agreement with the approach, I'll write a patch for the docs. Another thing - this line in the patch... -install-name $(ghclibdir)/`basename "$$@" | sed 's/^libHS//;s/[-]ghc.*//'`/`basename "$$@"` ...is a bit brittle because it second-guesses the behaviour of other makefiles, so some re-factoring is probably desirable here (assuming you decide to go with this approach). --- Some other Mac OS/X issues: 1. The general wisdom of using absolute paths on Mac OS/X: My take on it is that GHC does things the "Unix way" where it installs into an absolute location. If you want to package your application up Mac OS/X style (where the whole directory is required to be moveable), then the developer needs to make a process for doing that anyway. Perhaps at that point, they would just add the extra step of modifying all the shipped libraries to use relative paths (this can be done using a Mac OS/X system utility). 2. You can't run an app (one that has a library and an executable in it) from the build tree because it wants to use the install location. I don't know the solution to this, but it's only a minor annoyance mostly, and it seems to me that it could be dealt with later as a separate issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Sep 28 20:49:19 2009 From: trac at galois.com (GHC) Date: Mon Sep 28 20:27:32 2009 Subject: [GHC] #3530: GHCi does not work on Snow Leopard In-Reply-To: <043.67172119f9bd273a2158fec836b33117@localhost> References: <043.67172119f9bd273a2158fec836b33117@localhost> Message-ID: <052.16a7ae82c1f439c6c7de50eede1513a1@localhost> #3530: GHCi does not work on Snow Leopard -------------------------+-------------------------------------------------- Reporter: chak | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.11 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by chak): Replying to [comment:7 simonmar]: > There's a possibility that this may have been fixed by #3546. Might be worth trying again. No, unfortunately, the fix to #3546 doesn't change anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 29 04:08:49 2009 From: trac at galois.com (GHC) Date: Tue Sep 29 03:46:52 2009 Subject: [GHC] #3464: Find import declaration importing a certain function In-Reply-To: <044.30a4bd3b165086669168a65fc548f37a@localhost> References: <044.30a4bd3b165086669168a65fc548f37a@localhost> Message-ID: <053.3e7f33bdf0370acf123474576b5e7341@localhost> #3464: Find import declaration importing a certain function ---------------------------------+------------------------------------------ Reporter: fasta | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14 branch Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): The current behaviour of ":i" is this: {{{ Prelude> :i map map :: (a -> b) -> [a] -> [b] -- Defined in GHC.Base }}} I believe your suggestion is that you would like to see: {{{ Prelude> :i map map :: (a -> b) -> [a] -> [b] -- Defined in GHC.Base -- Imported from Prelude }}} The "Imported" info would specify which of the modules open in this session exports that entity. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 29 05:03:32 2009 From: trac at galois.com (GHC) Date: Tue Sep 29 04:41:31 2009 Subject: [GHC] #3520: Implement Type and Pattern splicing In-Reply-To: <045.112ef03cd36b7e21ad673f8919fc0720@localhost> References: <045.112ef03cd36b7e21ad673f8919fc0720@localhost> Message-ID: <054.4f5b8239db541e90e0209dc8e3919cb4@localhost> #3520: Implement Type and Pattern splicing ---------------------------------+------------------------------------------ Reporter: porges | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Type splices are fully implemented in the upcoming 6.10. Pattern splices are a whole different ball of wax. I have no clue how to do them. See http://haskell.org/pipermail/template- haskell/2003-February/000021.html, and section 8 of http://research.microsoft.com/~simonpj/papers/meta-haskell/notes2.ps As you say, pattern splices are kind-of-supported via !QuasiQuotes. So I'll close this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 29 07:34:03 2009 From: trac at galois.com (GHC) Date: Tue Sep 29 07:12:02 2009 Subject: [GHC] #3552: Unreachable code in optimised CMM code Message-ID: <046.863a422aebb3430703cdb620bd6e5c42@localhost> #3552: Unreachable code in optimised CMM code -------------------------------+-------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Ben found that GHC is gnerating some unreachable C-- code. While the NCG should handle that case, it's curious, so I'm recording it as a ticket to look at with the new codegen pipeline. While working on the NCG I've come across this: {{{ benl@mavericks:~/devel/ghc/ghc-head-incoming> inplace/bin/ghc-stage1 -c rts/Updates.cmm -ddump-opt-cmm ==================== Optimised Cmm ==================== ... cp: _ch::I32 = I32[_cb::I32 + 4]; I32[_ch::I32] = _c6::I32; I32[_cb::I32 + 4] = _ch::I32 + 4; I32[_c6::I32 + 0] = stg_IND_OLDGEN_info; jump (I32[Sp + 0]) (); cq: goto cq; } }}} The goto instruction at cq: is unreachable. However, in nativeGen/RegAlloc/Linear/Main.hs we have: {{{ {- from John Dias's patch 2008/10/16: The linear-scan allocator sometimes allocates a block before allocating one of its predecessors, which could lead to inconsistent allocations. Make it so a block is only allocated if a predecessor has set the "incoming" assignments for the block, or if it's the procedure's entry block. BL 2009/02: Careful. If the assignment for a block doesn't get set for some reason then this function will loop. We should probably do some more sanity checking to guard against this eventuality. -} }}} I'm in a situation where the linear allocator is looping because it's trying to wait for a predecessor of cq: to set the incoming register assignments, but that never happens because it's unreachable. I don't know why it wasn't looping until now, maybe because i've wibbled some function and caused some previously undemanded computation to hit this loop. Do we want the allocator to accept the above code, or just panic? Is this a bug in the Cmm code generator, or is there a good reason why there is an unreachable loop in this code? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 29 07:47:27 2009 From: trac at galois.com (GHC) Date: Tue Sep 29 07:25:26 2009 Subject: [GHC] #3544: Add instance IsString ShowS where fromString = showString In-Reply-To: <049.9e51a8e67140bc1cfbcf407623a0d367@localhost> References: <049.9e51a8e67140bc1cfbcf407623a0d367@localhost> Message-ID: <058.91c0b57489bcefc73a0b7adecb445530@localhost> #3544: Add instance IsString ShowS where fromString = showString ------------------------------+--------------------------------------------- Reporter: basvandijk | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by basvandijk): [http://thread.gmane.org/gmane.comp.lang.haskell.libraries/11993 This] is the thread on libraries@haskell.org about this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 29 08:46:56 2009 From: trac at galois.com (GHC) Date: Tue Sep 29 08:24:53 2009 Subject: [GHC] #3519: ghc: panic! (the 'impossible' happened) In-Reply-To: <044.f7668c50f47c7fd7a6c1b6746ff0381d@localhost> References: <044.f7668c50f47c7fd7a6c1b6746ff0381d@localhost> Message-ID: <053.e9c2f191d94c14bdbeb5423f95274607@localhost> #3519: ghc: panic! (the 'impossible' happened) -----------------------+---------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.10.4 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -----------------------+---------------------------------------------------- Comment (by simonpj): So the issue here is what? That we'd like a closing #-} to work even if is not indented? The same applies to RULES incidentally. I don't object to that... but if that is indeed the issue, we should perhaps create a new ticket for it, and close this one Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 29 09:57:54 2009 From: trac at galois.com (GHC) Date: Tue Sep 29 09:35:58 2009 Subject: [GHC] #3553: parallel gc suffers badly if one thread is descheduled Message-ID: <047.48e7cf5ad32bf05ce8bca6e11b9273f8@localhost> #3553: parallel gc suffers badly if one thread is descheduled -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Runtime System | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- The parallel GC synchronisation uses pure spinlocks, which leads to a severe decline in performance when one thread is descheduled. This is the main cause of the "last core parallel slowdown": using a `-N` value that matches the number of cores in the machine can be slower than using one fewer. The effect seems to be quite bad on Linux, reports are that it is less of an issue on OS X. Switching to mutexes would help, but it isn't easy because we sometimes unlock these from a different thread than they were locked from, and standard mutexes don't let you do that (the locks in question are `mut_spin` and `gc_spin` in the `GcThread` structure). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 29 10:10:25 2009 From: trac at galois.com (GHC) Date: Tue Sep 29 09:48:24 2009 Subject: [GHC] #3552: Unreachable code in optimised CMM code In-Reply-To: <046.863a422aebb3430703cdb620bd6e5c42@localhost> References: <046.863a422aebb3430703cdb620bd6e5c42@localhost> Message-ID: <055.2c2cd1c3d1cbebdb50d28f99ec1fb8ce@localhost> #3552: Unreachable code in optimised CMM code ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): These unreachable blocks are left behind by the flattener, `CgMonad.flattenCgStmts`. Here's the comment: {{{ -- A label at the end of a function or fork: this label must not be reachable, -- but it might be referred to from another BB that also isn't reachable. -- Eliminating these has to be done with a dead-code analysis. For now, -- we just make it into a well-formed block by adding a recursive jump. flatten [CgLabel id] = ( [CmmBranch id], [BasicBlock id [CmmBranch id]] ) }}} I think it happens when you write something like {{{ if (e) { ... } else { ... } }}} at the end of a C-- procedure, the code generation for this looks like (`CmmParse.ifThenElse`): {{{ ifThenElse cond then_part else_part = do then_id <- code newLabelC join_id <- code newLabelC c <- cond emitCond c then_id else_part stmtEC (CmmBranch join_id) code (labelC then_id) then_part -- fall through to join code (labelC join_id) }}} So it leaves a join-point label at the end; it doesn't know whether the join point is reachable or not. Can this ticket be closed, or should we wait until the symptom that Ben described is also fixed? All this is different in the new code generator, I imagine... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 29 10:16:49 2009 From: trac at galois.com (GHC) Date: Tue Sep 29 09:54:48 2009 Subject: [GHC] #3542: ghc-cabal deadlocks In-Reply-To: <044.1fecb1a5d877ecd5d5e8b6ef5145e963@localhost> References: <044.1fecb1a5d877ecd5d5e8b6ef5145e963@localhost> Message-ID: <053.a8ffa26011aa5f1f62952ffe97974db4@localhost> #3542: ghc-cabal deadlocks ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Mon Sep 28 10:45:53 PDT 2009 Ian Lynagh * Fix deadlocks when calling waitForProcess; GHC trac #3542 We now wait on MVars indicating that stdout and stderr have been closed before making the waitForProcess call. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 29 10:27:48 2009 From: trac at galois.com (GHC) Date: Tue Sep 29 10:06:00 2009 Subject: [GHC] #3550: Dynamic libraries don't work on Mac OS/X In-Reply-To: <056.c6f0034a4d5f342c60f11476270241e0@localhost> References: <056.c6f0034a4d5f342c60f11476270241e0@localhost> Message-ID: <065.406bb0fff0995661f35fec2e848a0607@localhost> #3550: Dynamic libraries don't work on Mac OS/X ----------------------------------------------------------------+----------- Reporter: StephenBlackheath | Owner: StephenBlackheath Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: dynamic mac osx | Difficulty: Unknown Testcase: http://upcycle.it/~blackh/ghc/test-case.tar.bz2 | Os: MacOS X Architecture: Unknown/Multiple | ----------------------------------------------------------------+----------- Changes (by simonmar): * difficulty: => Unknown Comment: The patches are generally fine. I wonder whether `-install-name` is the best name for the flag: it's a bit generic. Perhaps `-dylib-install- name`? The `sed` stuff is indeed unsightly, but I don't see any easy way to fix it, because the knowledge about where a library is finally installed lives in Cabal at the moment. I presume this patch subsumes the patch "rejig dylib names on Mac only" sent to the `cvs-ghc` list by `mwotton@gmail.com`? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 29 10:56:27 2009 From: trac at galois.com (GHC) Date: Tue Sep 29 10:34:26 2009 Subject: [GHC] #3551: Tests conc069 and conc070 failing for unregistered build In-Reply-To: <045.94f74b3da2564c9807512be40aa93367@localhost> References: <045.94f74b3da2564c9807512be40aa93367@localhost> Message-ID: <054.5a365e8d918a1698b066d3d3bf4c594c@localhost> #3551: Tests conc069 and conc070 failing for unregistered build ---------------------------------+------------------------------------------ Reporter: dterei | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: conc069 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar * difficulty: => Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 29 11:40:16 2009 From: trac at galois.com (GHC) Date: Tue Sep 29 11:18:28 2009 Subject: [GHC] #3550: Dynamic libraries don't work on Mac OS/X In-Reply-To: <056.c6f0034a4d5f342c60f11476270241e0@localhost> References: <056.c6f0034a4d5f342c60f11476270241e0@localhost> Message-ID: <065.048d674988aa77acd82492cf7ad04ba4@localhost> #3550: Dynamic libraries don't work on Mac OS/X ----------------------------------------------------------------+----------- Reporter: StephenBlackheath | Owner: StephenBlackheath Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: dynamic mac osx | Difficulty: Unknown Testcase: http://upcycle.it/~blackh/ghc/test-case.tar.bz2 | Os: MacOS X Architecture: Unknown/Multiple | ----------------------------------------------------------------+----------- Comment (by StephenBlackheath): -dylib-install-name is better for several reasons, so I'll add that to my to-do list for after everyone's commented. I didn't give the name of the option any thought - it's just a slightly modified version of Apple's name. I've been doing this in communication with mwotton (a.k.a. blackdog) so yes, this patch replaces anything he sent for Mac dylibs previously. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 29 12:06:00 2009 From: trac at galois.com (GHC) Date: Tue Sep 29 11:44:02 2009 Subject: [GHC] #3489: Adding some gmp bindings to integer-gmp (copied from the cvs-ghc list) In-Reply-To: <046.90f661b74011792a4af69e74c94446e3@localhost> References: <046.90f661b74011792a4af69e74c94446e3@localhost> Message-ID: <055.32c368fc77c2b6b915ec8e9cb9e151c1@localhost> #3489: Adding some gmp bindings to integer-gmp (copied from the cvs-ghc list) ---------------------------------+------------------------------------------ Reporter: pumpkin | Owner: Type: proposal | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by spl): * cc: leather@cs.uu.nl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Sep 29 14:39:12 2009 From: trac at galois.com (GHC) Date: Tue Sep 29 14:18:40 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.01d955a141149ec7537a4fdb829ef7cb@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: chak Type: bug | Status: reopened Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: blocker | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by duncan): This looks like the right explanation for the symptoms when using zlib. The program compiled by hsc2hs does need to be using the same environment as everything else. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 30 04:40:15 2009 From: trac at galois.com (GHC) Date: Wed Sep 30 04:18:23 2009 Subject: [GHC] #3554: ASSERT failed! file TcMType.lhs line 349 Message-ID: <047.d25d30bbfd2ca44b41deb2a3c8a4f5bd@localhost> #3554: ASSERT failed! file TcMType.lhs line 349 --------------------------------------+------------------------------------- Reporter: simonmar | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12.2 Component: Compiler (Type checker) | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: T2627b Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------------+------------------------------------- Test `T2627b` is failing with an assertion failure with a DEBUG compiler: {{{ =====> T2627b(normal) cd ./indexed-types/should_fail && '/64playpen/buildbot/x86_64-linux- head/build/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -dno-debug-output -c T2627b.hs >T2627b.comp.stderr 2>&1 Actual stderr output differs from expected: --- ./indexed-types/should_fail/T2627b.stderr.normalised 2009-09-29 21:47:01.000000000 +0100 +++ ./indexed-types/should_fail/T2627b.comp.stderr.normalised 2009-09-29 21:47:01.000000000 +0100 @@ -1,8 +1,7 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 6.13.20090929 for x86_64-unknown-linux): + ASSERT failed! file TcMType.lhs line 349 +t_aju{tv} [tau] + }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Sep 30 23:16:20 2009 From: trac at galois.com (GHC) Date: Wed Sep 30 22:54:23 2009 Subject: [GHC] #3550: Dynamic libraries don't work on Mac OS/X In-Reply-To: <056.c6f0034a4d5f342c60f11476270241e0@localhost> References: <056.c6f0034a4d5f342c60f11476270241e0@localhost> Message-ID: <065.806b005ef5f8f734f33df88931da7a4f@localhost> #3550: Dynamic libraries don't work on Mac OS/X ----------------------------------------------------------------+----------- Reporter: StephenBlackheath | Owner: StephenBlackheath Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: major | Resolution: Keywords: dynamic mac osx | Difficulty: Unknown Testcase: http://upcycle.it/~blackh/ghc/test-case.tar.bz2 | Os: MacOS X Architecture: Unknown/Multiple | ----------------------------------------------------------------+----------- Comment (by mwotton): yeah, this subsumes my stuff and then some. will have another test in a bit with any luck. -- Ticket URL: GHC The Glasgow Haskell Compiler