From trac at galois.com Sat Aug 1 07:00:41 2009 From: trac at galois.com (GHC) Date: Sat Aug 1 06:42:41 2009 Subject: [GHC] #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) In-Reply-To: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> References: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> Message-ID: <056.019eacdd676ea154a43a57e713d3d451@localhost> #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by andrewbirkett): * cc: andy@nobugs.org (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 1 12:35:32 2009 From: trac at galois.com (GHC) Date: Sat Aug 1 12:16:31 2009 Subject: [GHC] #789: BCOs can only have 64k instructions: linkBCO: >= 64k insns in BCO In-Reply-To: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> References: <046.dd5b1d4a62c636e51e886c3d53bcf8d3@localhost> Message-ID: <055.a04f5e062820bd579b70246342d08199@localhost> #789: BCOs can only have 64k instructions: linkBCO: >= 64k insns in BCO ------------------------+--------------------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: GHCi | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: BCO | Difficulty: Unknown Testcase: T789 | Os: Linux Architecture: x86 | ------------------------+--------------------------------------------------- Changes (by igloo): * testcase: => T789 * status: new => closed * resolution: => fixed Comment: Fixed by {{{ Sat Aug 1 16:32:03 BST 2009 Ian Lynagh * Allow more than 64k instructions in a BCO; fixes #789 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 2 06:45:47 2009 From: trac at galois.com (GHC) Date: Sun Aug 2 06:26:43 2009 Subject: [GHC] #3370: Put DiffArray in its own diffarray package In-Reply-To: <044.358443d8c33e79bf89bf7ebfe52581be@localhost> References: <044.358443d8c33e79bf89bf7ebfe52581be@localhost> Message-ID: <053.f8aa074b19ce6e99e65dbfdd95c7e791@localhost> #3370: Put DiffArray in its own diffarray package ----------------------------------+----------------------------------------- Reporter: igloo | Owner: igloo Type: proposal | Status: new Priority: normal | Milestone: _|_ Component: libraries (other) | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * owner: => igloo Comment: There were a couple of replies, both in favour of the proposal. Consensus: accept proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 2 09:35:18 2009 From: trac at galois.com (GHC) Date: Sun Aug 2 09:16:14 2009 Subject: [GHC] #3370: Put DiffArray in its own diffarray package In-Reply-To: <044.358443d8c33e79bf89bf7ebfe52581be@localhost> References: <044.358443d8c33e79bf89bf7ebfe52581be@localhost> Message-ID: <053.9414ef71badc12a11fdb4b1c9d5f29dd@localhost> #3370: Put DiffArray in its own diffarray package ----------------------------------+----------------------------------------- Reporter: igloo | Owner: igloo Type: proposal | Status: closed Priority: normal | Milestone: _|_ Component: libraries (other) | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Done. It's now in its own package, at http://code.haskell.org/diffarray/ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 2 09:47:04 2009 From: trac at galois.com (GHC) Date: Sun Aug 2 09:28:00 2009 Subject: [GHC] #2727: DiffArray performance unusable for advertized purpose In-Reply-To: <044.19ebac4c441c1f8e8ea00498a3c1e235@localhost> References: <044.19ebac4c441c1f8e8ea00498a3c1e235@localhost> Message-ID: <053.55702ddd4e0905b9c86b5ca74f03b54b@localhost> #2727: DiffArray performance unusable for advertized purpose -----------------------------------------+---------------------------------- Reporter: claus | Owner: Type: run-time performance bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.11 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: diffarray is now in its own package. Ticket moved to here: http://trac.haskell.org/diffarray/ticket/2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 2 09:48:01 2009 From: trac at galois.com (GHC) Date: Sun Aug 2 09:28:57 2009 Subject: [GHC] #1259: Accessing undefined value in DiffArray returns misleading error message In-Reply-To: <044.97473dce64ad187f3ecc9ad5b5fc7c0b@localhost> References: <044.97473dce64ad187f3ecc9ad5b5fc7c0b@localhost> Message-ID: <053.ecb69be0156a2035854182decc2999b3@localhost> #1259: Accessing undefined value in DiffArray returns misleading error message ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.6 Severity: normal | Resolution: invalid Keywords: | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => invalid Comment: diffarray is now in its own package. Ticket moved to here: http://trac.haskell.org/diffarray/ticket/1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 2 12:16:26 2009 From: trac at galois.com (GHC) Date: Sun Aug 2 11:57:23 2009 Subject: [GHC] #3410: ghc fails to parse versioned GPL and LGPL license from package configuration Message-ID: <044.39d94639879dc1489fb7d2f72ceb71d0@localhost> #3410: ghc fails to parse versioned GPL and LGPL license from package configuration -----------------------------+---------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I used this shell script to reproduce the problem: {{{ #! /bin/sh DIR=$(mktemp -d); cd ${DIR}; trap "cd /; rm -r ${DIR}" EXIT echo "[]" > P ghc-pkg -f P register - > /dev/null < /dev/null < GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 2 12:47:58 2009 From: trac at galois.com (GHC) Date: Sun Aug 2 12:28:54 2009 Subject: [GHC] #2781: Install permissions broken In-Reply-To: <044.61bd22c82633a255fd3e3d2cc7138fa8@localhost> References: <044.61bd22c82633a255fd3e3d2cc7138fa8@localhost> Message-ID: <053.0b1b7e7b2360b750d6c788ec5e070c57@localhost> #2781: Install permissions broken ------------------------------------+--------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: install permissions | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ------------------------------------+--------------------------------------- Changes (by igloo): * status: reopened => closed * resolution: => fixed Comment: Should all be fixed by: {{{ Sun Aug 2 17:12:37 BST 2009 Ian Lynagh * Fix permissions when installing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 2 14:35:35 2009 From: trac at galois.com (GHC) Date: Sun Aug 2 14:16:31 2009 Subject: [GHC] #3411: Extra file in snapshots from HEAD branch Message-ID: <047.ae5d89aff3e630dd047100a1a5edd6aa@localhost> #3411: Extra file in snapshots from HEAD branch -----------------------------+---------------------------------------------- Reporter: kristerw | Owner: Type: bug | Status: new Priority: normal | Component: None Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- There seems to be a some problem with the script that builds the HEAD branch snapshots; libraries/integer-gmp/gmp contains obj-files etc. from as Linux build, and libraries/integer-gmp/cbits contains a Linux binary mkGmpDerivedConstants. This cause problems when building on non-Linux platforms... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 2 16:11:44 2009 From: trac at galois.com (GHC) Date: Sun Aug 2 15:52:41 2009 Subject: [GHC] #3412: the 'impossible' happened (expectJust chooseExternalIds) Message-ID: <044.fec948dfdeed4bf48f363a94eb2fda9e@localhost> #3412: the 'impossible' happened (expectJust chooseExternalIds) -----------------------------+---------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This module fails to compile with ghc head (with optimizations and using a 'perf' build): {{{ module Bug where import Ix newtype U = U Int deriving (Eq, Ord) instance Ix U where index (U from, U to) (U idx) = index (from, to) idx }}} The output is as follows - the underlined part is the identifier that it fails to find. (I added a {{{++ show id}}} to the message.) {{{ # ghc -c -fforce-recomp -O Bug.hs ghc-stage2: panic! (the 'impossible' happened) (GHC version 6.11.20090801 for i386-unknown-linux): expectJust chooseExternalIds { GHC.Arr.$windex2 } ^^^^^^^^^^^^^^^^ }}} Here's a stripped down version of {{{Ix.hs}}} that still exhibits the bug, to make the example more self-contained. It has to be compiled with -O as well: {{{ module Ix2 where class Ix a where index :: (a, a) -> a -> Int instance Ix Int where index (m, n) i | m <= i && i <= n = m - i | otherwise = indexError i {-# NOINLINE indexError #-} indexError :: a -> b indexError _ = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 2 17:35:07 2009 From: trac at galois.com (GHC) Date: Sun Aug 2 17:16:04 2009 Subject: [GHC] #3411: Extra file in snapshots from HEAD branch In-Reply-To: <047.ae5d89aff3e630dd047100a1a5edd6aa@localhost> References: <047.ae5d89aff3e630dd047100a1a5edd6aa@localhost> Message-ID: <056.7fb3074c685898ccb7c24c09657364ac@localhost> #3411: Extra file in snapshots from HEAD branch ---------------------------------+------------------------------------------ Reporter: kristerw | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 6.11 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. Fixed by {{{ Sun Aug 2 20:57:59 BST 2009 Ian Lynagh * Clean GMP properly; fixes #3411 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 2 18:40:44 2009 From: trac at galois.com (GHC) Date: Sun Aug 2 18:21:40 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.3311c01dbc8a1892316fd492e471c85e@localhost> #3410: ghc fails to parse versioned GPL and LGPL license from package configuration ------------------------------+--------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by guest): * cc: aslatter@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 2 23:14:47 2009 From: trac at galois.com (GHC) Date: Sun Aug 2 22:56:05 2009 Subject: [GHC] #3409: type variable out of scope in worker/wrapper transformation In-Reply-To: <045.9adc3defe572c3fa16e2251d91a15c7c@localhost> References: <045.9adc3defe572c3fa16e2251d91a15c7c@localhost> Message-ID: <054.826ca20657a14097d0ce5779f1d56514@localhost> #3409: type variable out of scope in worker/wrapper transformation ------------------------------+--------------------------------------------- Reporter: judahj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by chak): * owner: => chak -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 3 05:02:06 2009 From: trac at galois.com (GHC) Date: Mon Aug 3 04:43:00 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.6b2e728a78a8dbf9bb11da63fc942dcb@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 | ---------------------------------+------------------------------------------ Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * owner: => simonmar * milestone: => 6.12.1 Comment: The binary package DB (#593) will fix this. I have it working, but it's in the queue to be pushed after some other changes to the package system, so I can't push it right away. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 3 06:45:21 2009 From: trac at galois.com (GHC) Date: Mon Aug 3 06:26:17 2009 Subject: [GHC] #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use In-Reply-To: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> References: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> Message-ID: <056.949f0f8d8e53dbf139cbc23c0a72cf9f@localhost> #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use ---------------------------------+------------------------------------------ Reporter: seliopou | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: darcs git | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: assigned => new * owner: seliopou => simonmar * milestone: => 6.12.1 Comment: The patch works for me, I'll push. Thanks for the contribution! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 3 06:58:53 2009 From: trac at galois.com (GHC) Date: Mon Aug 3 06:39:46 2009 Subject: [GHC] #3412: the 'impossible' happened (expectJust chooseExternalIds) In-Reply-To: <044.fec948dfdeed4bf48f363a94eb2fda9e@localhost> References: <044.fec948dfdeed4bf48f363a94eb2fda9e@localhost> Message-ID: <053.d7d8bcc058855c111fbb6d1fa8501e49@localhost> #3412: the 'impossible' happened (expectJust chooseExternalIds) ---------------------------------+------------------------------------------ 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 | ---------------------------------+------------------------------------------ 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 Mon Aug 3 09:23:11 2009 From: trac at galois.com (GHC) Date: Mon Aug 3 09:04:04 2009 Subject: [GHC] #3412: the 'impossible' happened (expectJust chooseExternalIds) In-Reply-To: <044.fec948dfdeed4bf48f363a94eb2fda9e@localhost> References: <044.fec948dfdeed4bf48f363a94eb2fda9e@localhost> Message-ID: <053.bd89de70548a6fa2328b87b1ec9c7bc5@localhost> #3412: the 'impossible' happened (expectJust chooseExternalIds) ---------------------------------+------------------------------------------ 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, thanks. {{{ Mon Aug 3 12:28:03 BST 2009 Simon Marlow * Fix #3412: the worker of an Id might not be a local Id }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 3 11:27:17 2009 From: trac at galois.com (GHC) Date: Mon Aug 3 11:08:12 2009 Subject: [GHC] #3402: internal error: ARR_WORDS object entered! In-Reply-To: <044.eda0f81b8249dde6fbc220a86607b25d@localhost> References: <044.eda0f81b8249dde6fbc220a86607b25d@localhost> Message-ID: <053.15cedf84c55b5e08507bf461b4c2e35b@localhost> #3402: internal error: ARR_WORDS object entered! ---------------------------------+------------------------------------------ Reporter: tibbe | 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 simonmar): * cc: morrow@moonpatio.com (added) * difficulty: => Unknown Comment: Mat, could this be an issue with Vacuum? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 3 11:29:56 2009 From: trac at galois.com (GHC) Date: Mon Aug 3 11:10:50 2009 Subject: [GHC] #3412: the 'impossible' happened (expectJust chooseExternalIds) In-Reply-To: <044.fec948dfdeed4bf48f363a94eb2fda9e@localhost> References: <044.fec948dfdeed4bf48f363a94eb2fda9e@localhost> Message-ID: <053.fafdcf809e9a6bf8518a6c402880900e@localhost> #3412: the 'impossible' happened (expectJust chooseExternalIds) ---------------------------------+------------------------------------------ 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 Mon Aug 3 13:59:10 2009 From: trac at galois.com (GHC) Date: Mon Aug 3 13:40:14 2009 Subject: [GHC] #2353: GHC inliner doesn't In-Reply-To: <044.0a130fadcfff13182791f64ebade3181@localhost> References: <044.0a130fadcfff13182791f64ebade3181@localhost> Message-ID: <053.246dd2ede91b15279c3b01540ab63169@localhost> #2353: GHC inliner doesn't ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by ross): I think I've just tripped over this one. In Data.Foldable, there is {{{ toList :: Foldable t => t a -> [a] toList t = build (\ c n -> Data.Foldable.foldr c n t) }}} so I would expect {{{ f :: Foldable t => t a -> [a] f xs = last (map (:[]) (toList xs)) }}} (only using last to simplify the example) to deforest to the equivalent of {{{ f xs = last (Data.Foldable.foldr (\ x -> [x]:) [] xs) }}} but it doesn't, because toList isn't inlined until too late, even if I give it an INLINE pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 3 17:56:59 2009 From: trac at galois.com (GHC) Date: Mon Aug 3 17:37:58 2009 Subject: [GHC] #3135: ext-core docs missing from web site In-Reply-To: <042.d47502914c2b1d33dc6652d04aeb8f42@localhost> References: <042.d47502914c2b1d33dc6652d04aeb8f42@localhost> Message-ID: <051.a3844e9cfa12f2d759887f3cb9c2e789@localhost> #3135: ext-core docs missing from web site ---------------------------------+------------------------------------------ Reporter: tim | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.10.2 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by tim): * status: closed => reopened * resolution: fixed => Comment: Link is borked again. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 4 06:36:12 2009 From: trac at galois.com (GHC) Date: Tue Aug 4 06:17:03 2009 Subject: [GHC] #3413: configure fails when generated with debian's autoconf 2.64-1 from unstable Message-ID: <051.28cd8daefa9e15f72864e5e7a841f7e1@localhost> #3413: configure fails when generated with debian's autoconf 2.64-1 from unstable -------------------------+-------------------------------------------------- Reporter: explicitcall | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------------+-------------------------------------------------- when doing `sh boot&&./configure` on ghc-HEAD with latest patches with debian's autoconf 2.64-1 from unstable installed, I get this: {{{ checking for ghc-pkg matching /home/user/local/bin/ghc... /home/user/local/bin/ghc-pkg ./configure: line 6156: syntax error near unexpected token `indResVersion=$fptools_cv_windres_version' ./configure: line 6156: `fi indResVersion=$fptools_cv_windres_version;' }}} after that configure script stops when I downgrade to autoconf 2.63-3 from testing, configure runs normally generated buggy configure script is attached -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 4 10:19:36 2009 From: trac at galois.com (GHC) Date: Tue Aug 4 10:00:29 2009 Subject: [GHC] #3374: Profiling libraries are not installed In-Reply-To: <046.8d56386f212a852d9f6e4247f2bbcfa0@localhost> References: <046.8d56386f212a852d9f6e4247f2bbcfa0@localhost> Message-ID: <055.b0223f5cb8ba53bcb7ef59ba53d1eb37@localhost> #3374: Profiling libraries are not installed -------------------------------+-------------------------------------------- Reporter: scsibug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by akiel): * difficulty: => Unknown * os: MacOS X => Linux Comment: I can confirm this. I have version ghc-6.11.20090803. The *_p.a" files are inside the build dirs but wouldn't be installed. I'm on Linux (Ubuntu 9.04) amd64 GHC 6.10.4 as base. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 4 11:05:34 2009 From: trac at galois.com (GHC) Date: Tue Aug 4 10:46:23 2009 Subject: [GHC] #3381: PROPOSAL: Remove Control.OldException In-Reply-To: <044.bea515c2e882a187756034c0cc466b95@localhost> References: <044.bea515c2e882a187756034c0cc466b95@localhost> Message-ID: <053.ded17f67055a2784d098e0dc1ed10e5f@localhost> #3381: PROPOSAL: Remove Control.OldException ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | 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: Some people thought it is too soon to remove `Control.OldException`, so it has been marked deprecated instead. If we do a `base4-compat` in GHC 6.12 then we will remove it from base 5. -- Ticket URL: GHC The Glasgow Haskell Compiler From slavomir.kaslev at gmail.com Tue Aug 4 13:42:43 2009 From: slavomir.kaslev at gmail.com (Slavomir Kaslev) Date: Tue Aug 4 13:23:31 2009 Subject: Data.List permutations Message-ID: <171dfd0a0908041042g1d615ef0m24b1ed5309e2b855@mail.gmail.com> A friend mine, new to functional programming, was entertaining himself by writing different combinatorial algorithms in Haskell. He asked me for some help so I sent him my quick and dirty solutions for generating variations and permutations: > inter x [] = [[x]] > inter x yys@(y:ys) = [x:yys] ++ map (y:) (inter x ys) > perm [] = [[]] > perm (x:xs) = concatMap (inter x) (perm xs) > vari 0 _ = [[]] > vari _ [] = [] > vari k (x:xs) = concatMap (inter x) (vari (k-1) xs) ++ vari k xs After that I found out that nowadays there is a permutation function in the Data.List module: > permutations :: [a] -> [[a]] > permutations xs0 = xs0 : perms xs0 [] > where > perms [] _ = [] > perms (t:ts) is = foldr interleave (perms ts (t:is)) (permutations is) > where interleave xs r = let (_,zs) = interleave' id xs r in zs > interleave' _ [] r = (ts, r) > interleave' f (y:ys) r = let (us,zs) = interleave' (f . (y:)) ys r > in (y:us, f (t:y:us) : zs) I was surprised to find that not only my version is much simpler from the one in Data.List but it also performs better. Here are some numbers from my rather old ghc 6.8.1 running ubuntu on my box: *Main> length $ permutations [1..10] 3628800 (10.80 secs, 2391647384 bytes) *Main> length $ perm [1..10] 3628800 (8.58 secs, 3156902672 bytes) I would like to suggest to change the current implementation in Data.List with the simpler one. Also, it would be nice to add variations and combinations in the Data.List module. Cheers. -- Slavomir Kaslev From slavomir.kaslev at gmail.com Tue Aug 4 13:52:47 2009 From: slavomir.kaslev at gmail.com (Slavomir Kaslev) Date: Tue Aug 4 13:33:35 2009 Subject: Data.List permutations In-Reply-To: <171dfd0a0908041042g1d615ef0m24b1ed5309e2b855@mail.gmail.com> References: <171dfd0a0908041042g1d615ef0m24b1ed5309e2b855@mail.gmail.com> Message-ID: <171dfd0a0908041052o1c28a843w6fa7c7bc419c60de@mail.gmail.com> On Tue, Aug 4, 2009 at 8:42 PM, Slavomir Kaslev wrote: > A friend mine, new to functional programming, was entertaining himself by > writing different combinatorial algorithms in Haskell. He asked me for some > help so I sent him my quick and dirty solutions for generating variations and > permutations: > >> inter x [] = [[x]] >> inter x yys@(y:ys) = [x:yys] ++ map (y:) (inter x ys) > >> perm [] = [[]] >> perm (x:xs) = concatMap (inter x) (perm xs) > >> vari 0 _ = [[]] >> vari _ [] = [] >> vari k (x:xs) = concatMap (inter x) (vari (k-1) xs) ++ vari k xs > > After that I found out that nowadays there is a permutation function in the > Data.List module: > >> permutations ? ? ? ? ? ?:: [a] -> [[a]] >> permutations xs0 ? ? ? ?= ?xs0 : perms xs0 [] >> ? where >> ? ? perms [] ? ? _ ?= [] >> ? ? perms (t:ts) is = foldr interleave (perms ts (t:is)) (permutations is) >> ? ? ? where interleave ? ?xs ? ? r = let (_,zs) = interleave' id xs r in zs >> ? ? ? ? ? ? interleave' _ [] ? ? r = (ts, r) >> ? ? ? ? ? ? interleave' f (y:ys) r = let (us,zs) = interleave' (f . (y:)) ys r >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?in ?(y:us, f (t:y:us) : zs) > > I was surprised to find that not only my version is much simpler from the one > in Data.List but it also performs better. Here are some numbers from my rather > old ghc 6.8.1 running ubuntu on my box: > > *Main> length $ permutations [1..10] > 3628800 > (10.80 secs, 2391647384 bytes) > *Main> length $ perm [1..10] > 3628800 > (8.58 secs, 3156902672 bytes) > > I would like to suggest to change the current implementation in Data.List with > the simpler one. Also, it would be nice to add variations and combinations in > the Data.List module. > > Cheers. > > -- > Slavomir Kaslev > Oops. It seems I should have used the glasgow-haskell-users mailing list. FIXED -- Slavomir Kaslev From trac at galois.com Wed Aug 5 02:06:22 2009 From: trac at galois.com (GHC) Date: Wed Aug 5 01:47:10 2009 Subject: [GHC] #3414: GHC does not configure with autoconf 2.64 Message-ID: <042.279f785473841a44241410e9254c6818@localhost> #3414: GHC does not configure with autoconf 2.64 -----------------------------+---------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Lots of errors occur. Some stem from "dnl"s that cause "fi"s and "done"s to stack up (i.e. you get fidone on one line instead of fi\ndone). I have a patch to aclocal.m4 that causes the main "configure" script to work, as well as one for the base package; unfortunately, terminfo also has issues and I am still looking into those. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 5 02:11:27 2009 From: trac at galois.com (GHC) Date: Wed Aug 5 01:52:14 2009 Subject: [GHC] #3414: GHC does not configure with autoconf 2.64 In-Reply-To: <042.279f785473841a44241410e9254c6818@localhost> References: <042.279f785473841a44241410e9254c6818@localhost> Message-ID: <051.d338380da75ce726b6217f916e239ae6@localhost> #3414: GHC does not configure with autoconf 2.64 ------------------------------+--------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: duplicate Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by ajd): * status: new => closed * resolution: => duplicate Comment: Oops...somebody beat me to it...terribly sorry about that... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 5 02:12:16 2009 From: trac at galois.com (GHC) Date: Wed Aug 5 01:53:04 2009 Subject: [GHC] #3413: configure fails when generated with debian's autoconf 2.64-1 from unstable In-Reply-To: <051.28cd8daefa9e15f72864e5e7a841f7e1@localhost> References: <051.28cd8daefa9e15f72864e5e7a841f7e1@localhost> Message-ID: <060.bff0b5c514434f31d10378264027c45e@localhost> #3413: configure fails when generated with debian's autoconf 2.64-1 from unstable --------------------------+------------------------------------------------- Reporter: explicitcall | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Comment (by ajd): See #3414, especially the two patches attached to that ticket which I think fix a couple of the issues; not all of them though. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 5 06:11:20 2009 From: trac at galois.com (GHC) Date: Wed Aug 5 05:52:09 2009 Subject: [GHC] #3402: internal error: ARR_WORDS object entered! In-Reply-To: <044.eda0f81b8249dde6fbc220a86607b25d@localhost> References: <044.eda0f81b8249dde6fbc220a86607b25d@localhost> Message-ID: <053.6490f211d9f82de216152a0808f18f06@localhost> #3402: internal error: ARR_WORDS object entered! ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => invalid * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 5 16:11:32 2009 From: trac at galois.com (GHC) Date: Wed Aug 5 15:52:19 2009 Subject: [GHC] #3413: configure fails when generated with debian's autoconf 2.64-1 from unstable In-Reply-To: <051.28cd8daefa9e15f72864e5e7a841f7e1@localhost> References: <051.28cd8daefa9e15f72864e5e7a841f7e1@localhost> Message-ID: <060.7a7e178e133a0a64ecc3678072ae6f34@localhost> #3413: configure fails when generated with debian's autoconf 2.64-1 from unstable --------------------------+------------------------------------------------- Reporter: explicitcall | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple --------------------------+------------------------------------------------- Comment (by ajd): It looks like those three patches (one in this ticket and two in #3414) will solve the problem - at least, they did for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 5 18:39:38 2009 From: trac at galois.com (GHC) Date: Wed Aug 5 18:20:23 2009 Subject: [GHC] #3415: Peculiar anomaly with record style data types and deriving Read Message-ID: <050.2481151a4ef68f7d4d12b992b9eae4cb@localhost> #3415: Peculiar anomaly with record style data types and deriving Read ------------------------+--------------------------------------------------- Reporter: DinoMorelli | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 ------------------------+--------------------------------------------------- -- Given this data type data Foo = Foo { foo :: Int } deriving (Read, Show) -- this fails bar :: Foo bar = read "Foo 42" -- However, non-record-style construction is allowed: baz :: Foo baz = Foo 42 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 6 09:24:06 2009 From: trac at galois.com (GHC) Date: Thu Aug 6 09:04:54 2009 Subject: [GHC] #3135: ext-core docs missing from web site In-Reply-To: <042.d47502914c2b1d33dc6652d04aeb8f42@localhost> References: <042.d47502914c2b1d33dc6652d04aeb8f42@localhost> Message-ID: <051.291a8562c23a56cfebcd2593bd6df621@localhost> #3135: ext-core docs missing from web site ---------------------------------+------------------------------------------ Reporter: tim | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * status: reopened => new * owner: => igloo * milestone: 6.10.2 => 6.12.1 Comment: Ian, could you look at this, pls? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 6 09:36:18 2009 From: trac at galois.com (GHC) Date: Thu Aug 6 09:17:06 2009 Subject: [GHC] #3135: ext-core docs missing from web site In-Reply-To: <042.d47502914c2b1d33dc6652d04aeb8f42@localhost> References: <042.d47502914c2b1d33dc6652d04aeb8f42@localhost> Message-ID: <051.62376cb8f5cf126fa7b4116aa7b323c8@localhost> #3135: ext-core docs missing from web site ---------------------------------+------------------------------------------ Reporter: tim | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): PS: and redirect the broken link on http://www.haskell.org/ghc/documentation.html ? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 6 10:08:05 2009 From: trac at galois.com (GHC) Date: Thu Aug 6 09:48:52 2009 Subject: [GHC] #3416: maximumBy uses too much stack Message-ID: <046.92a18780aff581cd9cc2254f3d845a56@localhost> #3416: maximumBy uses too much stack -----------------------------+---------------------------------------------- Reporter: bdonlan | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- maximumBy uses too much stack when working on long lists: {{{ Prelude Data.List> maximumBy compare [1..1000000] *** Exception: stack overflow }}} Here's a fixed implementation; the only change is replacing foldl1 with foldl1'. {{{ -- | The 'maximumBy' function takes a comparison function and a list -- and returns the greatest element of the list by the comparison function. -- The list must be finite and non-empty. maximumBy :: (a -> a -> Ordering) -> [a] -> a maximumBy _ [] = error "List.maximumBy: empty list" maximumBy cmp xs = foldl1' maxBy xs where maxBy x y = case cmp x y of GT -> x _ -> y }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 6 10:15:09 2009 From: trac at galois.com (GHC) Date: Thu Aug 6 09:55:54 2009 Subject: [GHC] #2465: View + Pattern Match not fused sufficiently In-Reply-To: <044.d33f6438c82e85b6cd4f00a3e01e2de0@localhost> References: <044.d33f6438c82e85b6cd4f00a3e01e2de0@localhost> Message-ID: <053.edd38f8f9644006ec05d44b23faec005@localhost> #2465: View + Pattern Match not fused sufficiently -----------------------------------------+---------------------------------- Reporter: ryani | Owner: Type: run-time performance bug | Status: new Priority: low | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by simonmar): * type: compile-time performance bug => run-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 6 10:18:14 2009 From: trac at galois.com (GHC) Date: Thu Aug 6 09:58:57 2009 Subject: [GHC] #3417: Data.Array.IO.hGetArray should be implemented. Message-ID: <044.4fe87e98cecbfb577c4777a984e7c8b6@localhost> #3417: Data.Array.IO.hGetArray should be implemented. -----------------------------+---------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Component: libraries (other) Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This is a leftover from the IO library rewrite. Right now {{{hGetArray}}} is defined as {{{undefined}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 6 10:20:15 2009 From: trac at galois.com (GHC) Date: Thu Aug 6 10:00:58 2009 Subject: [GHC] #3417: Data.Array.IO.hGetArray should be implemented. In-Reply-To: <044.4fe87e98cecbfb577c4777a984e7c8b6@localhost> References: <044.4fe87e98cecbfb577c4777a984e7c8b6@localhost> Message-ID: <053.25432df8f99ff8e4fbf5fcfee02e8bb8@localhost> #3417: Data.Array.IO.hGetArray should be implemented. ----------------------------------+----------------------------------------- Reporter: int-e | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries (other) | 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 Comment: regression, I need to fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 6 10:25:13 2009 From: trac at galois.com (GHC) Date: Thu Aug 6 10:05:58 2009 Subject: [GHC] #3417: Data.Array.IO.hGetArray should be implemented. In-Reply-To: <044.4fe87e98cecbfb577c4777a984e7c8b6@localhost> References: <044.4fe87e98cecbfb577c4777a984e7c8b6@localhost> Message-ID: <053.31faf867f2828fedc766bbd817a551d0@localhost> #3417: Data.Array.IO.hGetArray should be implemented. ----------------------------------+----------------------------------------- Reporter: int-e | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries (other) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by int-e): Or we could remove the function. There's at least one user though: the {{{c2hs}}} version that {{{gtk2hs}}} comes with. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 6 11:28:53 2009 From: trac at galois.com (GHC) Date: Thu Aug 6 11:09:36 2009 Subject: [GHC] #3418: Equality constraint causes ghc panic Message-ID: <046.4d0ae1a783985a2b7fcedd0e6c104820@localhost> #3418: Equality constraint causes ghc panic ------------------------------------------------------+--------------------- Reporter: blarsen | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: type families, equality constraint, panic | Testcase: Os: Linux | Architecture: x86_64 (amd64) ------------------------------------------------------+--------------------- I have the following module: {{{ {-# LANGUAGE TypeFamilies #-} module GhcBug where newtype (a ~ b) => S a b = S { unS :: a } }}} Loading this in ghci results in this: {{{ > :l GhcBug [1 of 1] Compiling GhcBug ( GhcBug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for x86_64-unknown-linux): typePrimRep a{tv a1MH} [tv] ~ b{tv a1MI} [tv] 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 Aug 6 11:59:54 2009 From: trac at galois.com (GHC) Date: Thu Aug 6 11:40:38 2009 Subject: [GHC] #3419: Incorrect "unnecessary import" warning Message-ID: <051.9b501dfeb3f845847a9d65fa1e7b4552@localhost> #3419: Incorrect "unnecessary import" warning -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- With the code: {{{ {-# OPTIONS_GHC -Wall -fno-warn-missing-methods #-} module Test where import Data.Typeable import Data.Data data Test = Test instance Typeable Test where }}} I get the warning: {{{ Warning: Module `Data.Typeable' is imported, but nothing from it is used except perhaps instances visible in `Data.Typeable' To suppress this warning, use: import Data.Typeable() }}} It seems like it's decided to pick up Typeable from Data.Data, but it's also available from Data.Typeable which would be a better choice. I'm not sure how this should be solved, but the current behaviour seems incorrect. Perhaps if two modules are imported, both of which export the same thing, they should both be allowed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 6 12:49:19 2009 From: trac at galois.com (GHC) Date: Thu Aug 6 12:30:06 2009 Subject: [GHC] #3419: Incorrect "unnecessary import" warning In-Reply-To: <051.9b501dfeb3f845847a9d65fa1e7b4552@localhost> References: <051.9b501dfeb3f845847a9d65fa1e7b4552@localhost> Message-ID: <060.b2c6e23e970e98d5b1fedb283726058d@localhost> #3419: Incorrect "unnecessary import" warning ---------------------------------+------------------------------------------ Reporter: NeilMitchell | 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: As it happens, the HEAD says {{{ bash-3.2$ ~/builds/HEAD/inplace/bin/ghc-stage2 -c T3419.hs T3419.hs:4:0: Warning: The import of `Data.Data' is redundant except perhaps to import instances from `Data.Data' To import instances alone, use: import Data.Data() }}} but we are making an arbitrary choice here; either import can be omitted without making the program fail to compile. Still, I don't think it's right to say nothing here; after all, only one of those imports is needed. Why do you think that "the current behaviour is incorrect"?. See [wiki:Commentary/Compiler/UnusedImports] for what we've now done in the HEAD. Feel free to suggest specifications other than the one given there. For example, you could say that the "home module" of an entity dominates, so in this case pick `Data.Typeable` over `Data.Data`. That might be why your nose twitched? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 6 13:20:35 2009 From: trac at galois.com (GHC) Date: Thu Aug 6 13:01:19 2009 Subject: [GHC] #3419: Incorrect "unnecessary import" warning In-Reply-To: <051.9b501dfeb3f845847a9d65fa1e7b4552@localhost> References: <051.9b501dfeb3f845847a9d65fa1e7b4552@localhost> Message-ID: <060.871f93cede399aba9d777f8100ba1564@localhost> #3419: Incorrect "unnecessary import" warning ---------------------------------+------------------------------------------ Reporter: NeilMitchell | 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 NeilMitchell): It seems wrong to make an arbitrary choice. In my example Typeable should be imported from Data.Typeable usually, because that is the "home module" - but I certainly wouldn't want GHC to know about home modules. I think the only sensible answer for a warning is to identify the set of modules from which only one is required, and list them all - anything else is non- deterministic. Of course, the alternative would be to not give a warning at all. Consider: {{{ import Data.Typeable import Data.Data instance Data Foo where instance Typeable Foo where }}} In this case technically the Typeable import is unnecessary, but I don't think it's something that should be warned on, as arguably it's better style. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 6 13:24:07 2009 From: trac at galois.com (GHC) Date: Thu Aug 6 13:04:50 2009 Subject: [GHC] #3420: Missing warning on duplicate import Message-ID: <051.5c6bbf5e9a7731e3587c88a116bee249@localhost> #3420: Missing warning on duplicate import -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The following program does not give a warning: {{{ {-# OPTIONS_GHC -Wall #-} import Data.List import Data.List main :: IO () main = print $ sort "hello" }}} But this program does: {{{ {-# OPTIONS_GHC -Wall #-} import Data.List(sort) import Data.List main :: IO () main = print $ sort "hello" }}} with: {{{ Warning: Redundant import of: `sort' It is also imported from Data.List at Test.hs:4:0-15 }}} It seems surprising that 100% identical imports aren't given as warnings, as in the first example. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 6 20:15:56 2009 From: trac at galois.com (GHC) Date: Thu Aug 6 19:57:02 2009 Subject: [GHC] #3418: Equality constraint causes ghc panic In-Reply-To: <046.4d0ae1a783985a2b7fcedd0e6c104820@localhost> References: <046.4d0ae1a783985a2b7fcedd0e6c104820@localhost> Message-ID: <055.786afecd53d239dac78a0031034c9e50@localhost> #3418: Equality constraint causes ghc panic -------------------------------------------------------+-------------------- Reporter: blarsen | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: type families, equality constraint, panic | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------------------------------------------+-------------------- Changes (by chak): * owner: => chak -- Ticket URL: GHC The Glasgow Haskell Compiler From dons at galois.com Thu Aug 6 22:34:08 2009 From: dons at galois.com (Don Stewart) Date: Thu Aug 6 22:16:53 2009 Subject: [westondan@imageworks.com: Re: [Haskell-cafe] Hugs faster and more reliable than GHC for large list monad 'do' block] Message-ID: <20090807023408.GA2894@whirlpool.galois.com> ----- Forwarded message from Dan Weston ----- Date: Thu, 6 Aug 2009 13:59:45 -0700 From: Dan Weston To: Henning Thielemann Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Hugs faster and more reliable than GHC for large list monad 'do' block I assume for the return line, you meant to return a list, not a tuple. ghc doesn't support a 600-tuple. In any case, returning a list, I have verified that this problem exists in ghc 6.10.3, for -O0 and -O2. For -O0, it compiles and links fine, but gives this runtime message: z: internal error: scavenge: unimplemented/strange closure type -1 @ 0x2a95a8e000 (GHC version 6.10.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort Maybe it is attempting to unroll these loops, even with -O0? Dan Henning Thielemann wrote: > Today a student has shown me a program that consists of a large 'do' > block for the list monad. The program looks like > > do x1 <- [0..3] > x2 <- [0..2] > ... > x600 <- [0..5] > guard (x1+x2+2*x3 >= 0) > ... > return (x1,x2,....,x600) > > It was actually generated by another program. The results were: > > GHC-6.4 was not able to compile that program at all, because it > stopped because of memory exhaustion. > GHC-6.8.2 finished compilation after two minutes but the program > aborted quickly because of a corrupt thunk identifier. > GHC-6.10 not yet tested. > Hugs-2006 executed the program without complaining and showed the > first result after a few seconds: (0,0,0,0,0,...,0). > > Eventually the program must run on a Linux cluster with a not up-to-date > Linux kernel, that is, I suspect newer GHC versions cannot be used due > to the 'timer_create' problem. (At least, the 'cabal' executable that I > generated with a GHC-6.8.2 had this problem when running on the cluster > which reminded me on the problems with GHC-6.8 itself running on older > Linux kernels.) > > Since the list monad sorts the variable values in lexicographic order > which is inappropriate for the considered problem, I recommended the use > of control-monad-omega. Luke, I hope this monad can cope with 600 > variables. :-) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ----- End forwarded message ----- From trac at galois.com Fri Aug 7 05:35:29 2009 From: trac at galois.com (GHC) Date: Fri Aug 7 05:16:09 2009 Subject: [GHC] #3421: Iface Lint failure panic with HEAD ghc-stage1 Message-ID: <053.b0e0c1c5c1c3699b282fdfc9b7a206d7@localhost> #3421: Iface Lint failure panic with HEAD ghc-stage1 ---------------------------+------------------------------------------------ Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ---------------------------+------------------------------------------------ A.hs: {{{ module A where class C1 a where c1 :: p a -> Maybe a class C2 a where c2 :: a instance (C1 a) => C2 (Maybe a) where c2 = c1 undefined }}} B.hs: {{{ module B where import A c2' :: (C1 a) => Maybe a c2' = c2 }}} Compiling them with "ghc-stage1 -dcore-lint -O2" gives this: {{{ inplace/bin/ghc-stage1 -c A.hs -dcore-lint -O2 && inplace/bin/ghc-stage1 -c B.hs -dcore-lint -O2 ghc-stage1: panic! (the 'impossible' happened) (GHC version 6.11.20090806 for x86_64-unknown-linux): Iface Lint failure Unfolding of main:A.$fC2Maybe_c2{v r33} : In the expression: ($dC1{v aed} [lid] `cast` (main:A.NTCo:T:C1{tc r31} a{tv aec} [tv] :: main:A.T:C1{tc r36} a{tv aec} [tv] ~ forall (p{tv ael} [tv] :: ghc-prim:GHC.Prim.*{(w) tc 34d} -> ghc-prim:GHC.Prim.*{(w) tc 34d}). p{tv ael} [tv] a{tv aec} [tv] -> base:Data.Maybe.Maybe{tc rm} a{tv aec} [tv])) @ ghc-prim:GHC.Prim.Any{(w) tc 31N} Kinds don't match in type application: Type variable: p{tv ael} [tv] :: ghc-prim:GHC.Prim.*{(w) tc 34d} -> ghc-prim:GHC.Prim.*{(w) tc 34d} Arg type: ghc-prim:GHC.Prim.Any{(w) tc 31N} :: ghc-prim:GHC.Prim.*{(w) tc 34d} 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 Fri Aug 7 09:22:20 2009 From: trac at galois.com (GHC) Date: Fri Aug 7 09:03:01 2009 Subject: [GHC] #3419: Incorrect "unnecessary import" warning In-Reply-To: <051.9b501dfeb3f845847a9d65fa1e7b4552@localhost> References: <051.9b501dfeb3f845847a9d65fa1e7b4552@localhost> Message-ID: <060.12f6d6cf25c449554c93cbdf622a7b10@localhost> #3419: Incorrect "unnecessary import" warning ---------------------------------+------------------------------------------ Reporter: NeilMitchell | 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): We recently rewrote the code for this warning in the HEAD, and found a couple of places where there were non-obvious choices. One was the case you're describing, where there are re-exports. The two choices were * '''consider both imports used'''; assuming, as you say, that the user has mentally allocated different imported entites to different imports, so the user believes that they are both used even though one of them is technically redundant. I had another example of this, with `Control.Monad.State`, `Control.Monad.Reader` and `Control.Monad`. * '''consider only the first import used'''; this is what is currently implemented. The first import decl to provide each of Data and Typeable is `Data.Typeable`, so nothing marks `Data.Data` as used, so it is warned about. The other was to do with restricted vs complete imports. In this module: {{{ module Foo where import Data.List (sort) import Data.List f = sort }}} which import should we warn about? Both of these are just a question of what we want; the code changes required are minimal. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 7 10:07:14 2009 From: trac at galois.com (GHC) Date: Fri Aug 7 09:48:01 2009 Subject: [GHC] #3420: Missing warning on duplicate import In-Reply-To: <051.5c6bbf5e9a7731e3587c88a116bee249@localhost> References: <051.5c6bbf5e9a7731e3587c88a116bee249@localhost> Message-ID: <060.d22f57e9ac12b26afa7aa999d161dac5@localhost> #3420: Missing warning on duplicate import ---------------------------------+------------------------------------------ Reporter: NeilMitchell | 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. This warning's implementation has been overhauled in the HEAD, and you now do get a warning in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 7 12:09:58 2009 From: trac at galois.com (GHC) Date: Fri Aug 7 11:50:39 2009 Subject: [GHC] #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use In-Reply-To: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> References: <047.6f40a13a3a0c6f7f07534a2fd4532a18@localhost> Message-ID: <056.c76f65d60d51c9af31ca8423c3c0b0d0@localhost> #3375: Add a command-line option to the darcs-all script to specify the darcs repository to use ---------------------------------+------------------------------------------ Reporter: seliopou | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.3 Severity: trivial | Resolution: wontfix Keywords: darcs git | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: This patch broke things like {{{ $ ./darcs-all rec }}} so I've rolled it back. As we discussed on IRC before, I think this change only really helps if you are trying to use multiple version control systems, so it should be made in the `sync-all` script rather than the `darcs-all` script. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 7 14:49:13 2009 From: trac at galois.com (GHC) Date: Fri Aug 7 14:29:56 2009 Subject: [GHC] #3413: configure fails when generated with debian's autoconf 2.64-1 from unstable In-Reply-To: <051.28cd8daefa9e15f72864e5e7a841f7e1@localhost> References: <051.28cd8daefa9e15f72864e5e7a841f7e1@localhost> Message-ID: <060.fcbb23eace1460da70ebbae60e3659c3@localhost> #3413: configure fails when generated with debian's autoconf 2.64-1 from unstable --------------------------+------------------------------------------------- Reporter: explicitcall | Owner: igloo 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 ajd): * owner: => igloo Comment: Assigning to igloo since patches have been posted. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 7 15:04:26 2009 From: trac at galois.com (GHC) Date: Fri Aug 7 14:45:16 2009 Subject: [GHC] #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) In-Reply-To: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> References: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> Message-ID: <056.39243b26d560612d04821b35ed3ff6e9@localhost> #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.9 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by ajd): * owner: => igloo Comment: I've attached a patch to GHC and a patch to the testsuite that ought to fix the problem by turning off the checker for any definition that includes view patterns. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 7 15:42:46 2009 From: trac at galois.com (GHC) Date: Fri Aug 7 15:23:26 2009 Subject: [GHC] #3413: configure fails when generated with debian's autoconf 2.64-1 from unstable In-Reply-To: <051.28cd8daefa9e15f72864e5e7a841f7e1@localhost> References: <051.28cd8daefa9e15f72864e5e7a841f7e1@localhost> Message-ID: <060.304be4575157e49550b3cbd1d484b7b1@localhost> #3413: configure fails when generated with debian's autoconf 2.64-1 from unstable ---------------------------------+------------------------------------------ Reporter: explicitcall | Owner: 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 igloo): * owner: igloo => * difficulty: => Unknown Comment: Thanks; I've applied the other two patches, and sent this one to Judah. -- Ticket URL: GHC The Glasgow Haskell Compiler From kyagrd at gmail.com Fri Aug 7 20:01:54 2009 From: kyagrd at gmail.com (Ahn, Ki Yung) Date: Fri Aug 7 19:50:41 2009 Subject: Impossible happened while compiling the lunabot Message-ID: kyagrd@kyavaio:~/tmp/lunabot$ which ghc /usr/bin/ghc kyagrd@kyavaio:~/tmp/lunabot$ uname -a Linux kyavaio 2.6.29-2-686 #1 SMP Sun May 17 17:56:29 UTC 2009 i686 GNU/Linux kyagrd@kyavaio:~/tmp$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.4 kyagrd@kyavaio:~/tmp$ darcs get http://moonpatio.com/repos/lunabot kyagrd@kyavaio:~/tmp$ cd lunabot kyagrd@kyavaio:~/tmp/lunabot$ cabal install haskell-src-meta vacuum ... kyagrd@kyavaio:~/tmp/lunabot$ cabal build Preprocessing library lunabot-0.9.9... Building lunabot-0.9.9... [3 of 5] Compiling Luna.Bot.Eval.PackageConf ( Luna/Bot/Eval/PackageConf.hs, dist/build/Luna/Bot/Eval/PackageConf.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): No match in record selector Var.tcTyVarDetails Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug From trac at galois.com Sat Aug 8 01:58:10 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 01:38:49 2009 Subject: [GHC] #3422: No match in record selector Var.tcTyVarDetails Message-ID: <044.30dbb53910f9c5e4fb4c74981ede85ce@localhost> #3422: No match in record selector Var.tcTyVarDetails -------------------------------------------+-------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: deriving instance, type family | Testcase: Os: Linux | Architecture: x86 -------------------------------------------+-------------------------------- See http://hpaste.org/fastcgi/hpaste.fcgi/view?id=7993#a7993 This also happens on ghc 6.10.4 KiYungAhn -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 8 01:58:36 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 01:39:52 2009 Subject: [GHC] #3423: (Standalone deriving + tyfamilies + recursive instance cxt + UndecidableInstances + ghc >= 6.10.2) No match in record selector Var.tcTyVarDetails Message-ID: <045.2396ec1e7c80b838e7d57390c1854284@localhost> #3423: (Standalone deriving + tyfamilies + recursive instance cxt + UndecidableInstances + ghc >= 6.10.2) No match in record selector Var.tcTyVarDetails -----------------------------+---------------------------------------------- Reporter: morrow | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This seems to have been introduced in 6.10.2: {{{ {-# OPTIONS_GHC -fglasgow-exts #-} {-# LANGUAGE UndecidableInstances #-} module Bug where newtype Trie m k a = Trie (Maybe a, m (SubKey k) (Trie m k a)) type family SubKey k type instance SubKey [k] = k deriving instance (Eq (m k (Trie m [k] a)) ,Eq a) => Eq (Trie m [k] a) }}} which fails with: {{{ [m@monire ~]$ ghc -O2 -c --make Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for x86_64-unknown-linux): No match in record selector Var.tcTyVarDetails Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Matt -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 8 02:01:48 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 01:42:53 2009 Subject: [GHC] #3423: No match in record selector Var.tcTyVarDetails with ghc >= 6.10.2 In-Reply-To: <045.2396ec1e7c80b838e7d57390c1854284@localhost> References: <045.2396ec1e7c80b838e7d57390c1854284@localhost> Message-ID: <054.834d20097b13f4ceab03e0433fe882ad@localhost> #3423: No match in record selector Var.tcTyVarDetails with ghc >= 6.10.2 ------------------------------+--------------------------------------------- Reporter: morrow | 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 ------------------------------+--------------------------------------------- Changes (by morrow): * summary: (Standalone deriving + tyfamilies + recursive instance cxt + UndecidableInstances + ghc >= 6.10.2) No match in record selector Var.tcTyVarDetails => No match in record selector Var.tcTyVarDetails with ghc >= 6.10.2 Comment: Shortened title. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 8 02:04:23 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 01:45:30 2009 Subject: [GHC] #3423: No match in record selector Var.tcTyVarDetails with ghc >= 6.10.2 In-Reply-To: <045.2396ec1e7c80b838e7d57390c1854284@localhost> References: <045.2396ec1e7c80b838e7d57390c1854284@localhost> Message-ID: <054.eeaf24a5b1985d771de5ba814cdb9e90@localhost> #3423: No match in record selector Var.tcTyVarDetails with ghc >= 6.10.2 ------------------------------+--------------------------------------------- Reporter: morrow | 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 morrow): Actually, looking at that i guess the type family aspect is probably irrelevant. (?) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 8 02:18:43 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 01:59:50 2009 Subject: [GHC] #3402: internal error: ARR_WORDS object entered! In-Reply-To: <044.eda0f81b8249dde6fbc220a86607b25d@localhost> References: <044.eda0f81b8249dde6fbc220a86607b25d@localhost> Message-ID: <053.1063604907cc87cf027c9fe5823c2453@localhost> #3402: internal error: ARR_WORDS object entered! ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Not GHC Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by morrow): I've fixed the problem in vacuum, and will update the hackage package shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 8 13:31:55 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 13:12:32 2009 Subject: [GHC] #3424: Corrupt executable when compiling large do block for List monad Message-ID: <044.0e7bdc71d50ace8354623d9f560b19d9@localhost> #3424: Corrupt executable when compiling large do block for List monad -------------------+-------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- For a program that like {{{ z :: [[Int]] z = do x1 <- [0..3] x2 <- [0..3] x3 <- [0..3] x4 <- [0..3] x5 <- [0..3] x6 <- [0..3] x7 <- [0..3] ... x600 <- [0..3] guard (x1+x2+2*x3 >= 0) return [x1,x2,x3,...,x600] }}} the compiler generates a program, that aborts with {{{ internal error: scavenge: unimplemented/strange closure type -1 @ }}} . Description and example Haskell program can be found here: http://www.haskell.org/pipermail/haskell-cafe/2009-August/065001.html Maybe related: #830 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 8 14:58:43 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 14:39:32 2009 Subject: [GHC] #3179: Linking unix package fails In-Reply-To: <044.ae8162f5a98c9f4e805028c0bd796c43@localhost> References: <044.ae8162f5a98c9f4e805028c0bd796c43@localhost> Message-ID: <053.13582299e43c0b40de42266ff5aecff8@localhost> #3179: Linking unix package fails -------------------------------+-------------------------------------------- Reporter: eelco | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/unix | Version: 6.10.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by dufflebunk): The problem may be caused by glibc and your kernel not agreeing on using NPTL or non-NPTL threads. If you set an env var {{{ LD_ASSUME_KERNEL=2.4.1 }}} It should tell the system to use the non-NPTL linuxthread libraries. That gets rid of the librt error for me... although I get another error about not being able to get the version of GHC. I don't know that the new error is related to this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 8 18:13:46 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 17:54:23 2009 Subject: [GHC] #3386: RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph In-Reply-To: <049.5b3494ecafeb0e231ba14cf4473a8bc4@localhost> References: <049.5b3494ecafeb0e231ba14cf4473a8bc4@localhost> Message-ID: <058.54e38bb663f6fcaac7be2d9f8eb8a0b7@localhost> #3386: RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph ---------------------------------+------------------------------------------ Reporter: StefanWehr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: stack slots | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Old description: > Using ghc 6.10.4, I tried to install the crypto lib (version 4.1.0) via > "cabal install crypto". However, ghc fails: > > [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test > /SHA1Test-tmp/Main.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.4 for i386-unknown-linux): > RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- > graph > > OS: Ubuntu Linux (Hardy), 32 bit New description: Using ghc 6.10.4, I tried to install the crypto lib (version 4.1.0) via "cabal install crypto". However, ghc fails: {{{ [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test /SHA1Test-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs- graph }}} OS: Ubuntu Linux (Hardy), 32 bit -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 8 18:14:37 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 17:55:13 2009 Subject: [GHC] #3386: RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph In-Reply-To: <049.5b3494ecafeb0e231ba14cf4473a8bc4@localhost> References: <049.5b3494ecafeb0e231ba14cf4473a8bc4@localhost> Message-ID: <058.5f0c30550a0311e0887bc5a86ad75617@localhost> #3386: RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph ---------------------------------+------------------------------------------ Reporter: StefanWehr | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: duplicate Keywords: stack slots | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. This is a duplicate of #2790, so I'll close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 8 18:17:52 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 17:58:28 2009 Subject: [GHC] #2507: quotation characters in error messages In-Reply-To: <051.38b1ebfeec872e08862a450e1303ba1d@localhost> References: <051.38b1ebfeec872e08862a450e1303ba1d@localhost> Message-ID: <060.b269d59cf36c2ddd62e89f3f6ff4ce53@localhost> #2507: quotation characters in error messages ---------------------------------+------------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): See also #3398. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 8 18:58:22 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 18:38: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.d22557df0b63d3e9d330877f8e1abbee@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: critical | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. This should be fixed by: {{{ Sat Aug 8 23:25:37 BST 2009 Ian Lynagh * Pass -m32 to gcc on i386 and ppc OS X This makes GHC work even if you are actually running it in 64bit mode, e.g. on OS X 10.6 Snow. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 8 19:07:16 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 18:47:51 2009 Subject: [GHC] #3415: Peculiar anomaly with record style data types and deriving Read In-Reply-To: <050.2481151a4ef68f7d4d12b992b9eae4cb@localhost> References: <050.2481151a4ef68f7d4d12b992b9eae4cb@localhost> Message-ID: <059.6706df702d34f2d80d1547dd8d12c98e@localhost> #3415: Peculiar anomaly with record style data types and deriving Read ----------------------------+----------------------------------------------- Reporter: DinoMorelli | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: Thanks for the report; however, this is not a bug. The [http://haskell.org/onlinereport/derived.html#sect10.4 Haskell Report, section 10.4] says {{{ If the constructor is defined using record syntax, the derived Read will parse only the record-syntax form, and furthermore, the fields must be given in the same order as the original declaration. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 8 19:23:37 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 19:04:14 2009 Subject: [GHC] #3424: Corrupt executable when compiling large do block for List monad In-Reply-To: <044.0e7bdc71d50ace8354623d9f560b19d9@localhost> References: <044.0e7bdc71d50ace8354623d9f560b19d9@localhost> Message-ID: <053.13580618d6628635e6a7edbca09d90e2@localhost> #3424: Corrupt executable when compiling large do block for List monad -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 Comment: Thanks for the report. On amd64/Linux with the HEAD, ghci is failing with {{{ *Main> main [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0: internal error: scavenge_one: strange object 28 (GHC version 6.11.20090808 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} but compiling and running without -O works. Compiling with -O hasn't finished yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 8 19:26:04 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 19:06:39 2009 Subject: [GHC] #3424: Corrupt executable when compiling large do block for List monad In-Reply-To: <044.0e7bdc71d50ace8354623d9f560b19d9@localhost> References: <044.0e7bdc71d50ace8354623d9f560b19d9@localhost> Message-ID: <053.16ffd10738793ce23b709bd7d428c6d7@localhost> #3424: Corrupt executable when compiling large do block for List monad -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by igloo): Replying to [comment:1 igloo]: > Compiling with -O hasn't finished yet. Now finished, and works fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 8 19:52:17 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 19:32:58 2009 Subject: [GHC] #3135: ext-core docs missing from web site In-Reply-To: <042.d47502914c2b1d33dc6652d04aeb8f42@localhost> References: <042.d47502914c2b1d33dc6652d04aeb8f42@localhost> Message-ID: <051.938df5661ff1cff64f66572115ccfe89@localhost> #3135: ext-core docs missing from web site ---------------------------------+------------------------------------------ Reporter: tim | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Documentation | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Both done. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 8 23:54:46 2009 From: trac at galois.com (GHC) Date: Sat Aug 8 23:35:58 2009 Subject: [GHC] #3409: type variable out of scope in worker/wrapper transformation In-Reply-To: <045.9adc3defe572c3fa16e2251d91a15c7c@localhost> References: <045.9adc3defe572c3fa16e2251d91a15c7c@localhost> Message-ID: <054.16e20c9dd777d1f8b1e54d2822a4b8d0@localhost> #3409: type variable out of scope in worker/wrapper transformation ------------------------------+--------------------------------------------- Reporter: judahj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by chak): Is this connected to #3421. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 9 04:59:32 2009 From: trac at galois.com (GHC) Date: Sun Aug 9 04:40:17 2009 Subject: [GHC] #3422: No match in record selector Var.tcTyVarDetails In-Reply-To: <044.30dbb53910f9c5e4fb4c74981ede85ce@localhost> References: <044.30dbb53910f9c5e4fb4c74981ede85ce@localhost> Message-ID: <053.b94eb00e9197316bf8b6830a5a23193b@localhost> #3422: No match in record selector Var.tcTyVarDetails --------------------------------------------+------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: deriving instance, type family | Testcase: Os: Linux | Architecture: x86 --------------------------------------------+------------------------------- Changes (by chak): * owner: => chak Comment: {{{ {-# OPTIONS_GHC -fglasgow-exts #-} {-# LANGUAGE UndecidableInstances #-} module GHCBug where newtype Trie m k a = Trie (Maybe a, m (SubKey k) (Trie m k a)) type family SubKey k type instance SubKey [k] = k deriving instance (Eq (m k (Trie m [k] a)) ,Eq a) => Eq (Trie m [k] a) {- [m@monire ~]$ ghc -O2 -c --make GHCBug.hs [1 of 1] Compiling GHCBug ( GHCBug.hs, GHCBug.o ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for x86_64-unknown-linux): No match in record selector Var.tcTyVarDetails 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 Sun Aug 9 05:04:03 2009 From: trac at galois.com (GHC) Date: Sun Aug 9 04:45:04 2009 Subject: [GHC] #3422: No match in record selector Var.tcTyVarDetails In-Reply-To: <044.30dbb53910f9c5e4fb4c74981ede85ce@localhost> References: <044.30dbb53910f9c5e4fb4c74981ede85ce@localhost> Message-ID: <053.87f3f3e34255b3647d7d8da49ca6a2a7@localhost> #3422: No match in record selector Var.tcTyVarDetails --------------------------------------------+------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: deriving instance, type family | Testcase: Os: Linux | Architecture: x86 --------------------------------------------+------------------------------- Comment (by chak): Happens in the HEAD, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 9 05:05:41 2009 From: trac at galois.com (GHC) Date: Sun Aug 9 04:46:18 2009 Subject: [GHC] #3422: No match in record selector Var.tcTyVarDetails In-Reply-To: <044.30dbb53910f9c5e4fb4c74981ede85ce@localhost> References: <044.30dbb53910f9c5e4fb4c74981ede85ce@localhost> Message-ID: <053.6ee3700a5a154f6f41565a6368d16895@localhost> #3422: No match in record selector Var.tcTyVarDetails --------------------------------------------+------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: deriving instance, type family | Testcase: Os: Linux | Architecture: x86 --------------------------------------------+------------------------------- Comment (by chak): Duplicate of #3423 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 9 05:05:56 2009 From: trac at galois.com (GHC) Date: Sun Aug 9 04:46:53 2009 Subject: [GHC] #3422: No match in record selector Var.tcTyVarDetails In-Reply-To: <044.30dbb53910f9c5e4fb4c74981ede85ce@localhost> References: <044.30dbb53910f9c5e4fb4c74981ede85ce@localhost> Message-ID: <053.af711a433744e8cf912c91982b4e6eab@localhost> #3422: No match in record selector Var.tcTyVarDetails --------------------------------------------+------------------------------- Reporter: guest | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: duplicate Keywords: deriving instance, type family | Testcase: Os: Linux | Architecture: x86 --------------------------------------------+------------------------------- Changes (by chak): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 9 05:06:29 2009 From: trac at galois.com (GHC) Date: Sun Aug 9 04:47:34 2009 Subject: [GHC] #3423: No match in record selector Var.tcTyVarDetails with ghc >= 6.10.2 In-Reply-To: <045.2396ec1e7c80b838e7d57390c1854284@localhost> References: <045.2396ec1e7c80b838e7d57390c1854284@localhost> Message-ID: <054.aeaab045e5651f937a29657dd9db9b04@localhost> #3423: No match in record selector Var.tcTyVarDetails with ghc >= 6.10.2 ------------------------------+--------------------------------------------- Reporter: morrow | 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): Happens in the HEAD , too. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 9 10:01:08 2009 From: trac at galois.com (GHC) Date: Sun Aug 9 09:41:46 2009 Subject: [GHC] #3392: export copyPermissions from System.Directory In-Reply-To: <044.f43f9c0d4bae4a938d0ec3b5319129f9@localhost> References: <044.f43f9c0d4bae4a938d0ec3b5319129f9@localhost> Message-ID: <053.ae8f8670eb5af90174d164c211c27f84@localhost> #3392: export copyPermissions from System.Directory ------------------------------------+--------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries/directory | 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: Thread is here: http://www.haskell.org/pipermail/libraries/2009-July/012195.html There was no discussion. Proposal applied. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 9 10:01:08 2009 From: trac at galois.com (GHC) Date: Sun Aug 9 09:41:47 2009 Subject: [GHC] #3393: Add openFileTemplate, openBinaryFileTemplate to System.IO In-Reply-To: <044.9de646c5d20af2930ed2bccac502e1ac@localhost> References: <044.9de646c5d20af2930ed2bccac502e1ac@localhost> Message-ID: <053.eaafa14644e9c2fd9c2388736afa737f@localhost> #3393: Add openFileTemplate, openBinaryFileTemplate to System.IO ---------------------------------+------------------------------------------ Reporter: igloo | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | 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: There was some discussion over naming. I've made this change, using the suggested {{{ openBinaryTempFileWithDefaultPermissions openTempFileWithDefaultPermissions }}} names, which are clear, if a little long. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 9 12:38:26 2009 From: trac at galois.com (GHC) Date: Sun Aug 9 12:19:10 2009 Subject: [GHC] #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) In-Reply-To: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> References: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> Message-ID: <056.d1ff0857d2aa894eb80de4a52ea2356d@localhost> #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) ---------------------------------+------------------------------------------ Reporter: rwbarton | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.9 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Thanks, patches applied. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 9 15:22:51 2009 From: trac at galois.com (GHC) Date: Sun Aug 9 15:03:25 2009 Subject: [GHC] #3094: Some GHC.* module should export word size and heap object header size In-Reply-To: <045.907bdf02870cf9d7a457cb5fba873bca@localhost> References: <045.907bdf02870cf9d7a457cb5fba873bca@localhost> Message-ID: <054.4dd475531ff30e6fbd0eeabaf6c5e0b2@localhost> #3094: Some GHC.* module should export word size and heap object header size ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Done: {{{ Sun Aug 9 19:32:52 BST 2009 Ian Lynagh * Add a GHC.Constants module; fixes trac #3094 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 9 16:07:55 2009 From: trac at galois.com (GHC) Date: Sun Aug 9 15:48:28 2009 Subject: [GHC] #3378: [Patch] Make 'group' into a special ID when TransformListComp is on In-Reply-To: <053.bb0c2863cc6b81c9d59a0b979dc0de10@localhost> References: <053.bb0c2863cc6b81c9d59a0b979dc0de10@localhost> Message-ID: <062.5ea27b3048780dcebfd1bdcdb212d4ca@localhost> #3378: [Patch] Make 'group' into a special ID when TransformListComp is on ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | 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: I think a special ID makes sense, so I've applied these patches; thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 10 10:15:26 2009 From: trac at galois.com (GHC) Date: Mon Aug 10 09:55:57 2009 Subject: [GHC] #3407: GHC.Prim documentation should mention GHC.Exts! In-Reply-To: <044.b2bcc86bcf34543dca950728f9a46ba1@localhost> References: <044.b2bcc86bcf34543dca950728f9a46ba1@localhost> Message-ID: <053.2c4d4d372efac7b6bab4c20a1a7d855a@localhost> #3407: GHC.Prim documentation should mention GHC.Exts! ---------------------------------+------------------------------------------ Reporter: RyanN | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: Another oddity. The documentation for GHC.Exts, in its Synopsis, says: {{{ Int (I#) data Word = W# Word# Float (F#) Double (D#) Char (C#) }}} Note the absence of `data` for `Int`, `Float` etc. This must be wrong. Also, we should add a pointer to GHC.Exts in the Overview for GHC.Prim and GHC.Types. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 10 10:44:17 2009 From: trac at galois.com (GHC) Date: Mon Aug 10 10:24:48 2009 Subject: [GHC] #3425: compileToCoreModule: ghc: panic! (the 'impossible' happened) Message-ID: <043.832f4b8a68b35787dd3f11dce0ad982a@localhost> #3425: compileToCoreModule: ghc: panic! (the 'impossible' happened) -------------------+-------------------------------------------------------- Reporter: iago | Owner: Type: bug | Status: new Priority: normal | Component: GHC API Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- The following code on GHCi {{{ runGhc (Just "/home/mads/iabal/opt/ghc-6.10.4/lib/ghc-6.10.4/.") (compileToCoreModule "./foo.hs") }}} causes a GHC Panic {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for x86_64-unknown-linux): no package state yet: call GHC.setSessionDynFlags Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} foo.hs is attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 10 12:46:36 2009 From: trac at galois.com (GHC) Date: Mon Aug 10 12:27:23 2009 Subject: [GHC] #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) In-Reply-To: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> References: <047.ecbd48e54b1bf1fee3a4558a1775b513@localhost> Message-ID: <056.95703fbbbcb8d38924378ae97587fdb0@localhost> #2395: "Pattern match(es) are overlapped" warning with a single view pattern (ghc 6.9.20080606) ---------------------------------------------+------------------------------ Reporter: rwbarton | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.9 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: deSugar/should_compile/T2395 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------+------------------------------ Changes (by simonpj): * testcase: => deSugar/should_compile/T2395 Comment: I've improved the fix with {{{ Mon Aug 10 15:11:58 BST 2009 simonpj@microsoft.com * Improve the recent changes to overlap-checking for view patters The previous patch simply gave up for view patterns; this version instead treats them like n+k patterns and gives signficantly better results. Less code, too. M ./compiler/deSugar/Check.lhs -85 +101 M ./compiler/hsSyn/HsPat.lhs -29 +1 }}} and added a test case Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 10 12:47:46 2009 From: trac at galois.com (GHC) Date: Mon Aug 10 12:28:16 2009 Subject: [GHC] #3421: Iface Lint failure panic with HEAD ghc-stage1 In-Reply-To: <053.b0e0c1c5c1c3699b282fdfc9b7a206d7@localhost> References: <053.b0e0c1c5c1c3699b282fdfc9b7a206d7@localhost> Message-ID: <062.6def8ac1e59bad55c7af9a7a64d51d6e@localhost> #3421: Iface Lint failure panic with HEAD ghc-stage1 -------------------------------+-------------------------------------------- Reporter: Ashley Yakeley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.11 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: Urk. Thanks. Turned out be be a typo in `TysPrim`: {{{ Mon Aug 10 09:43:20 PDT 2009 simonpj@microsoft.com * Fix Trac #3421: a typo in TysPrim Ignore-this: 67af95909862d672c6eb738c52458873 This is just a blatant typo, where Any1 :: *->* was getting mixed up with Any :: *. M ./compiler/prelude/TysPrim.lhs -1 +1 }}} I'm not going to bother with a regression test. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 10 13:15:11 2009 From: trac at galois.com (GHC) Date: Mon Aug 10 12:55:42 2009 Subject: [GHC] #3424: Corrupt executable when compiling large do block for List monad In-Reply-To: <044.0e7bdc71d50ace8354623d9f560b19d9@localhost> References: <044.0e7bdc71d50ace8354623d9f560b19d9@localhost> Message-ID: <053.ac2a443d71a06d21e21a0029fcccd300@localhost> #3424: Corrupt executable when compiling large do block for List monad -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by flaggy): The attached program (z.hs) works fine on ubuntu 8.10 32 bits. Ghc package version is: ghc-6.8.2-6ubuntu2. $ ghc z.hs $ ./a.out [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 10 18:31:13 2009 From: trac at galois.com (GHC) Date: Mon Aug 10 18:11:45 2009 Subject: [GHC] #3424: Corrupt executable when compiling large do block for List monad In-Reply-To: <044.0e7bdc71d50ace8354623d9f560b19d9@localhost> References: <044.0e7bdc71d50ace8354623d9f560b19d9@localhost> Message-ID: <053.a0d08e15ee07ff3c25ffbd2e02aa9459@localhost> #3424: Corrupt executable when compiling large do block for List monad -------------------------+-------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by flaggy): I have just tested on debian lenny amd64 package version 6.8.2dfsg1-1 and I've got the same thing as Igloo. The right output followed by ghc bug report and core dump. This is the output of my earlier test using time to measure how long it took, we can see that on ubuntu it didn't take too long to compile: {{{ $ time ghc z.hs real 0m9.230s user 0m7.772s sys 0m0.376s $ time ./a.out [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0] real 0m0.016s user 0m0.004s sys 0m0.016s $ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 11 07:00:34 2009 From: trac at galois.com (GHC) Date: Tue Aug 11 06:41:03 2009 Subject: [GHC] #3426: Misuse of SRC_HC_OPTS Message-ID: <044.fe3bb2fe382d4b2fb97083469558125d@localhost> #3426: Misuse of SRC_HC_OPTS -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Originally reported here: http://www.haskell.org/pipermail/cvs- ghc/2009-May/048719.html ---- {{{ Thu May 21 07:19:38 PDT 2009 Ian Lynagh * Don't overwrite the *OPTS/*Opts variables in mk/validate-settings.mk Overwriting means we lose the -m64 on OS X 64. M ./mk/validate-settings.mk -5 +5 }}} This is a bit worrying. We are really mis-using SRC_HC_OPTS all over the place (e.g. build.mk.sample), but usually we get away with it because SRC_HC_OPTS is only used for things like optimisation and heap settings that won't cause the build to fail if they are lost. The right thing to do would be to introduce new variables for flags like optimisation and heap settings, that can safely be overriden, and keep SRC_HC_OPTS for flags that are part of the build system. In any case, we need to do something here. If SRC_HC_OPTS cannot be overridden, the docs are wrong, and build.mk.sample is broken. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 11 10:29:08 2009 From: trac at galois.com (GHC) Date: Tue Aug 11 10:09: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.b3692b765315cf05a0d39c05029c49e4@localhost> #3407: GHC.Prim documentation should mention GHC.Exts! ---------------------------------+------------------------------------------ Reporter: RyanN | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): It looks like the "Int (I#)" etc is because the types are defined in another package. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 11 10:49:44 2009 From: trac at galois.com (GHC) Date: Tue Aug 11 10:30:14 2009 Subject: [GHC] #3395: Template Haskell crashes In-Reply-To: <051.8ddfdbe5023ec6ecffaddcf454ad0905@localhost> References: <051.8ddfdbe5023ec6ecffaddcf454ad0905@localhost> Message-ID: <060.3544ffd9c85b06ec0a9833ea32c8faf7@localhost> #3395: Template Haskell crashes ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: th/T3395 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * testcase: => th/T3395 Comment: I've improved error reporting when this kind of thing happens {{{ Tue Aug 11 07:36:55 PDT 2009 simonpj@microsoft.com * Refactor, and improve error messages (cf Trac #3395) Ignore-this: e7205f5bcf8408ff791ba19156e48461 The Convert stuff should not panic if the programmer hands over an invalid TH term; instead it should give a graceful error message. Largely this had been done, but not for do-blocks, so this patch fixes that problem. Moreover, I did some refactoring and tidying up, which is why so many lines of code have changed M ./compiler/hsSyn/Convert.lhs -153 +146 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 11 12:52:08 2009 From: trac at galois.com (GHC) Date: Tue Aug 11 12:33:09 2009 Subject: [GHC] #3409: type variable out of scope in worker/wrapper transformation In-Reply-To: <045.9adc3defe572c3fa16e2251d91a15c7c@localhost> References: <045.9adc3defe572c3fa16e2251d91a15c7c@localhost> Message-ID: <054.4d7b6fad934dba44b8e05bd5c0f5aa8d@localhost> #3409: type variable out of scope in worker/wrapper transformation ---------------------------------+------------------------------------------ Reporter: judahj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonpj): * difficulty: => Unknown Comment: No, it's quite different. Here is a much smaller example: {{{ data T = forall a. T a (Funny a) type Funny a = Bool f :: T -> Bool f (T x n) = n }}} This kills Lint because the type of the RHS is `(Funny a)` where `a` is existentially quantified. For future reference, I boiled down the original program to this simpler form: {{{ newtype Size s = Size Int data ArrayS d e = ArrayS d e data Array1 e = forall s . Array1 (Size s) (ArrayS (Size s) e) -- Array1 :: forall e s. Size s -> ArrayS (Size s) e -> Array1 e copy :: Int -> Array1 a -> Array1 a copy _ (Array1 s a) = Array1 s $ (ArrayS s (bang a)) -- Array1 s :: ArrayS (Size s) a -> Array1 a -- s :: Size s -- a :: ArrayS (Size s) a -- ArrayS :: Size s -> a -> ArrayS (Size s) a -- i :: AccessIx (ArrayS (Size s) a) = Ix s -- bang a :: AccessResult (ArrayS (Size s) a) = a -- ArrayS s (bang a) :: ArrayS (Size s) (AccessResult (ArrayS (Size s) a)) class Access a where type AccessResult a bang :: a -> AccessResult a instance Access (ArrayS d a) where type AccessResult (ArrayS d a) = a }}} Just recording this for now. There's nothing actually wrong, but Lint should not bleat. I'll have to think about what the best fix is. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 11 15:19:28 2009 From: trac at galois.com (GHC) Date: Tue Aug 11 15:00:08 2009 Subject: [GHC] #3409: type variable out of scope in worker/wrapper transformation In-Reply-To: <045.9adc3defe572c3fa16e2251d91a15c7c@localhost> References: <045.9adc3defe572c3fa16e2251d91a15c7c@localhost> Message-ID: <054.0cfdcb81ee6e0d2a92ed324282c624dd@localhost> #3409: type variable out of scope in worker/wrapper transformation ---------------------------------+------------------------------------------ Reporter: judahj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by judahj): Actually, I think there's something more serious going on. I saved your above module as `ArrayExt.hs`, and created a new file named `MyCopy.hs`: {{{ module MyCopy where import ArrayExt mycopy :: Array1 a -> Array1 a mycopy = copy 0 }}} Compiling each module separately produces an error: {{{ $ ghc --make -O2 ArrayExt.hs -fglasgow-exts [...] $ ghc --make -O2 MyCopy.hs [2 of 2] Compiling MyCopy ( MyCopy.hs, MyCopy.o ) The interface for `main:ArrayExt' Declaration for copy Unfolding of ArrayExt.copy: Iface type variable out of scope: s }}} Strangely, if I compile them both with one call to `ghc --make` then the error doesn't occur. Also, I'm not sure whether in the above case the error actually stops the compilation, but if I do something similar with my original example then it very clearly stops ghc, with a message like the one in this bug's description. I'm pretty sure this is something to do with type functions, since I was able to work around the problem using fundeps. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 11 17:12:52 2009 From: trac at galois.com (GHC) Date: Tue Aug 11 16:53:44 2009 Subject: [GHC] #3409: type variable out of scope in worker/wrapper transformation In-Reply-To: <045.9adc3defe572c3fa16e2251d91a15c7c@localhost> References: <045.9adc3defe572c3fa16e2251d91a15c7c@localhost> Message-ID: <054.f96b73b798d530d4c0791daeaadc9cac@localhost> #3409: type variable out of scope in worker/wrapper transformation ---------------------------------+------------------------------------------ Reporter: judahj | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by judahj): Just to clarify, you can reproduce a definite non-lint error as follows: `cd` into `worker-issue-0.0.1`, and run: {{{ $ ghc --make -O2 -fglasgow-exts Array.hs [1 of 2] Compiling Size ( Size.hs, Size.o ) [2 of 2] Compiling Array ( Array.hs, Array.o ) $ ghc --make -O2 -fglasgow-exts Foo.hs [3 of 3] Compiling Foo ( Foo.hs, Foo.o ) The interface for `main:Array' Declaration for $wcopy: Iface type variable out of scope: s Cannot continue after interface file error }}} where `Foo.hs` is {{{ module Foo where import Array import Foreign.Storable mycopy :: Storable a => Array1 a -> Array1 a mycopy = copy 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 11 17:24:20 2009 From: trac at galois.com (GHC) Date: Tue Aug 11 17:04:47 2009 Subject: [GHC] #3406: 'impossible' happened while messing around with ScopedTypeVariables In-Reply-To: <044.9724012c5b1b2098374ba8fb8be5fa12@localhost> References: <044.9724012c5b1b2098374ba8fb8be5fa12@localhost> Message-ID: <053.bd97245ced654057d4c6fd9a5c98659f@localhost> #3406: 'impossible' happened while messing around with ScopedTypeVariables -----------------------------------+---------------------------------------- Reporter: RyanN | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: ScopedTypeVariabes | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -----------------------------------+---------------------------------------- Changes (by simonpj): * owner: => simonpj * difficulty: => Unknown Comment: I'll take this. I'm hot on the trail. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 11 18:49:44 2009 From: trac at galois.com (GHC) Date: Tue Aug 11 18:30:11 2009 Subject: [GHC] #3139: automate "cabal check" in ghc release process In-Reply-To: <045.7ab42017b14002b12bbbb131a40f00d6@localhost> References: <045.7ab42017b14002b12bbbb131a40f00d6@localhost> Message-ID: <054.2509469e38e541c7ba38f81ff7e787ca@localhost> #3139: automate "cabal check" in ghc release process ---------------------------------+------------------------------------------ Reporter: duncan | Owner: Type: task | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by: {{{ Tue Aug 11 22:25:59 BST 2009 Ian Lynagh * Check Cabal packages when validating This checks that hackage would accept the packages. Currently warnings are printed, but don't result in failure. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 11 19:49:58 2009 From: trac at galois.com (GHC) Date: Tue Aug 11 19:30:26 2009 Subject: [GHC] #3216: Terminal output in GHCi 10.3 on Mac OS X In-Reply-To: <044.015402d518098531d13d84633eabcb1e@localhost> References: <044.015402d518098531d13d84633eabcb1e@localhost> Message-ID: <053.4e501396d63d640ced8b8fe4af26929e@localhost> #3216: Terminal output in GHCi 10.3 on Mac OS X ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => worksforme Comment: No response from submitter, so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 12 10:18:10 2009 From: trac at galois.com (GHC) Date: Wed Aug 12 09:58:36 2009 Subject: [GHC] #3089: Sanity checker false positive (presumably) In-Reply-To: <044.7c0b171724271f62443ee855d47aa195@localhost> References: <044.7c0b171724271f62443ee855d47aa195@localhost> Message-ID: <053.67b7322abea7f6672f88f5d1435781d7@localhost> #3089: Sanity checker false positive (presumably) ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Runtime 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: Aha, so OpenGL wasn't required after all. I've fixed this: {{{ Wed Aug 12 14:38:17 BST 2009 Ian Lynagh * Fix a sanity check; fixes #3089 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 12 10:27:22 2009 From: trac at galois.com (GHC) Date: Wed Aug 12 10:07:46 2009 Subject: [GHC] #3083: Win32 package should bind SHGetFolderPath In-Reply-To: <045.07ec9167505060698bef96705be4add8@localhost> References: <045.07ec9167505060698bef96705be4add8@localhost> Message-ID: <054.e17de50c081e833ff072cbb290911e63@localhost> #3083: Win32 package should bind SHGetFolderPath ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: Can you please submit this as a [http://www.haskell.org/haskellwiki/Library_submissions library submissions proposal]? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 12 10:29:16 2009 From: trac at galois.com (GHC) Date: Wed Aug 12 10:09:45 2009 Subject: [GHC] #3124: warning -F: directory name (/Users/me/Library/Frameworks) does not exist In-Reply-To: <044.91542ec2427008db2e834afd5933f41c@localhost> References: <044.91542ec2427008db2e834afd5933f41c@localhost> Message-ID: <053.e107bd29a0618bc29075908e880990ab@localhost> #3124: warning -F: directory name (/Users/me/Library/Frameworks) does not exist -------------------------+-------------------------------------------------- Reporter: 7stud | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This sounds like it only applies to old bindists, so I'm closing the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 12 10:57:00 2009 From: trac at galois.com (GHC) Date: Wed Aug 12 10:37:38 2009 Subject: [GHC] #3179: Linking unix package fails In-Reply-To: <044.ae8162f5a98c9f4e805028c0bd796c43@localhost> References: <044.ae8162f5a98c9f4e805028c0bd796c43@localhost> Message-ID: <053.a1f6b1f88fd088863425ce111fab2aa7@localhost> #3179: Linking unix package fails -------------------------------+-------------------------------------------- Reporter: eelco | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/unix | Version: 6.10.2 Severity: major | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: This looks like it is some kernel/libc mismatch, and thus not a GHC bug. If you disagree, please re-open this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 12 11:42:49 2009 From: trac at galois.com (GHC) Date: Wed Aug 12 11:23:16 2009 Subject: [GHC] #3199: System.Environment provides no access to argv[0] In-Reply-To: <044.697a3b3acea49077d005dd1587a2b57f@localhost> References: <044.697a3b3acea49077d005dd1587a2b57f@localhost> Message-ID: <053.28dab1fbe7229139d2249e83ca971263@localhost> #3199: System.Environment provides no access to argv[0] ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: The report just says {{{ Computation getProgName returns the name of the program as it was invoked. }}} I suggest you make a [http://www.haskell.org/haskellwiki/Library_submissions library submissions proposal] for this, and for #3200, so we can get agreement on what the best functionality is. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 12 11:42:58 2009 From: trac at galois.com (GHC) Date: Wed Aug 12 11:23:22 2009 Subject: [GHC] #3200: System.Environment.withProgName strips everything before the last slash In-Reply-To: <044.6c7a0324fd6d877811b6a46ca881b0e2@localhost> References: <044.6c7a0324fd6d877811b6a46ca881b0e2@localhost> Message-ID: <053.8c3de1c5b5dce86fd2ed7a2879856c28@localhost> #3200: System.Environment.withProgName strips everything before the last slash ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: See #3199 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 12 11:59:41 2009 From: trac at galois.com (GHC) Date: Wed Aug 12 11:40:05 2009 Subject: [GHC] #3303: Allow multi-line deprecation messages. In-Reply-To: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> References: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> Message-ID: <054.481bfc09ad9d7603e1212f6b70097ffa@localhost> #3303: Allow multi-line deprecation messages. ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 12 16:05:08 2009 From: trac at galois.com (GHC) Date: Wed Aug 12 15:45:32 2009 Subject: [GHC] #3427: control what sort of entity a deprecated pragma applies to Message-ID: <044.6e5c26a8435c2fcde3f9de3ab4769428@localhost> #3427: control what sort of entity a deprecated pragma applies to -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | 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 -------------------------------+-------------------------------------------- Originally reported as part of #3303. ---- It's annoying not being able to control whether a type or identically named constructor is being deprecated. Consider: {{{ data Foo = Foo ... }}} This is a very common idiom. But now we want to switch to smart constructors {{{ foo :: ... -> Foo }}} and eventually stop exporting the constructor Foo. But we cannot specify just the constructor, only both. According to the [http://haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning- deprecated-pragma user guide] the workaround would be to have a module that imports one but not the other, however while that's possible for the type it's not possible for the constructor. How about {{{ {-# DEPRECATED constructor Foo "use `foo' instead" #-} }}} and while we're at it, might as well have {{{ {-# DEPRECATED type Foo "..." #-} }}} leaving the unqualified case meaning both as it does now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 12 16:05:29 2009 From: trac at galois.com (GHC) Date: Wed Aug 12 15:45:53 2009 Subject: [GHC] #3303: Allow multi-line deprecation messages. In-Reply-To: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> References: <045.504e3e8992fc7aa97369c63a127f30a6@localhost> Message-ID: <054.3afddd748b48f624581612ba969e1659@localhost> #3303: Allow multi-line deprecation messages. ---------------------------------+------------------------------------------ Reporter: duncan | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 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 fixed the original issue: {{{ Wed Aug 12 19:59:12 BST 2009 Ian Lynagh * Add support for multi-line deprecated pragmas; trac #3303 }}} and filed the other one as #3427. -- Ticket URL: GHC The Glasgow Haskell Compiler From dons at galois.com Wed Aug 12 16:17:22 2009 From: dons at galois.com (Don Stewart) Date: Wed Aug 12 16:00:00 2009 Subject: Impossible happened while compiling the lunabot In-Reply-To: References: Message-ID: <20090812201722.GN29909@whirlpool.galois.com> kyagrd: > kyagrd@kyavaio:~/tmp/lunabot$ which ghc > /usr/bin/ghc > kyagrd@kyavaio:~/tmp/lunabot$ uname -a > Linux kyavaio 2.6.29-2-686 #1 SMP Sun May 17 17:56:29 UTC 2009 i686 > GNU/Linux > kyagrd@kyavaio:~/tmp$ ghc --version > The Glorious Glasgow Haskell Compilation System, version 6.10.4 > kyagrd@kyavaio:~/tmp$ darcs get http://moonpatio.com/repos/lunabot > kyagrd@kyavaio:~/tmp$ cd lunabot > kyagrd@kyavaio:~/tmp/lunabot$ cabal install haskell-src-meta vacuum > ... > kyagrd@kyavaio:~/tmp/lunabot$ cabal build > Preprocessing library lunabot-0.9.9... > Building lunabot-0.9.9... > [3 of 5] Compiling Luna.Bot.Eval.PackageConf ( > Luna/Bot/Eval/PackageConf.hs, dist/build/Luna/Bot/Eval/PackageConf.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.4 for i386-unknown-linux): > No match in record selector Var.tcTyVarDetails > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Please file a bug here: http://hackage.haskell.org/trac/ghc/newticket?type=bug From trac at galois.com Wed Aug 12 16:39:43 2009 From: trac at galois.com (GHC) Date: Wed Aug 12 16:20:07 2009 Subject: [GHC] #3082: Unclear warning message: Attempting to re-export hidden constructors In-Reply-To: <042.a5c4cd3afa0abc022930d0824ba94bfa@localhost> References: <042.a5c4cd3afa0abc022930d0824ba94bfa@localhost> Message-ID: <051.bb13ef42f0aab69db62bf7f38b1ef7e0@localhost> #3082: Unclear warning message: Attempting to re-export hidden constructors ---------------------------------+------------------------------------------ Reporter: ksf | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: It looks like Simon's original fix has fixed the problem sufficiently, so I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 12 18:13:23 2009 From: trac at galois.com (GHC) Date: Wed Aug 12 17:53:47 2009 Subject: [GHC] #3173: Install fails when using DESTDIR In-Reply-To: <045.8d36b199003970aa7bab88684104eafe@localhost> References: <045.8d36b199003970aa7bab88684104eafe@localhost> Message-ID: <054.19511e45be583ecd6536c2e75450b86d@localhost> #3173: Install fails when using DESTDIR -----------------------------+---------------------------------------------- Reporter: fidori | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: DESTDIR | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This now works with the new build system, in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 12 18:28:31 2009 From: trac at galois.com (GHC) Date: Wed Aug 12 18:09:03 2009 Subject: [GHC] #1845: unconditional relative branch out of range (GHC version 6.8.1/6.8.2 for powerpc_apple_darwin) In-Reply-To: <044.65389402080b2ab045a1b2fde12245f8@localhost> References: <044.65389402080b2ab045a1b2fde12245f8@localhost> Message-ID: <053.1c6b44fd40ac9b84b56bba7e85f92330@localhost> #1845: unconditional relative branch out of range (GHC version 6.8.1/6.8.2 for powerpc_apple_darwin) -------------------------+-------------------------------------------------- Reporter: guest | Owner: thorkilnaur Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: powerpc | -------------------------+-------------------------------------------------- Changes (by igloo): * priority: low => normal * milestone: 6.12.1 => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 12 18:38:00 2009 From: trac at galois.com (GHC) Date: Wed Aug 12 18:18:36 2009 Subject: [GHC] #2285: Solaris 9 build fails at stage2 with undefined symbol errors (for libm symbols) In-Reply-To: <048.9d281a64a969b94451f675cf7f831df1@localhost> References: <048.9d281a64a969b94451f675cf7f831df1@localhost> Message-ID: <057.9cfa0a8f7357b560b93847db1a96e923@localhost> #2285: Solaris 9 build fails at stage2 with undefined symbol errors (for libm symbols) --------------------------+------------------------------------------------- Reporter: TimBishop | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Solaris Architecture: sparc | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: My understanding is that this isn't a GHC bug, and that with a recent version of Solaris there won't be a problem, so I'm closing the ticket. Please re-open if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 13 05:13:04 2009 From: trac at galois.com (GHC) Date: Thu Aug 13 04:53:28 2009 Subject: [GHC] #3428: Wrong pragma parsing Message-ID: <044.6fff3c68b090c532da2af6f966b67158@localhost> #3428: Wrong pragma parsing --------------------+------------------------------------------------------- Reporter: boris | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.10.2 | Severity: normal Keywords: pragma | Testcase: Os: Windows | Architecture: x86 --------------------+------------------------------------------------------- If I write the following code with pragma LANGUAGE and extension concatenated, ghci complains about unrecognized pragma but loads module. {{{ {-# LANGUAGEExistentialQuantification #-} module TestHS where data ShowBox = forall s.Show s => SB s instance Show ShowBox where show (SB s) = show s list :: [ShowBox] list = [SB "sdf", SB 4, SB True, SB (Nothing::Maybe())] }}} If pragma is not recognized, the extension ExistentialQuantification should not be loaded and so file should not compile. Another strange thing is that when I :reload file in ghci it does not complain about pragma anymore. It is needed to close ghci and open it once again to see error about not recognized pragma. Also I think that if pragma concatenated with following information is legal it will give ambiguity for cases like adding pragma SPECIAL with existing pragma SPECIALIZE. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 13 05:13:41 2009 From: trac at galois.com (GHC) Date: Thu Aug 13 04:54:04 2009 Subject: [GHC] #3428: Wrong pragma parsing In-Reply-To: <044.6fff3c68b090c532da2af6f966b67158@localhost> References: <044.6fff3c68b090c532da2af6f966b67158@localhost> Message-ID: <053.0065faf6eb3e5a7d6454bc8bc220d307@localhost> #3428: Wrong pragma parsing -------------------------------+-------------------------------------------- Reporter: boris | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.3 Severity: normal | Resolution: Keywords: pragma | Testcase: Os: Windows | Architecture: x86 -------------------------------+-------------------------------------------- Changes (by boris): * version: 6.10.2 => 6.10.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 13 08:40:13 2009 From: trac at galois.com (GHC) Date: Thu Aug 13 08:21:14 2009 Subject: [GHC] #3007: GHC seems to ignore the package name of modules imported with {#- SOURCE #-} In-Reply-To: <046.111251f57247f17187bc3cbd93be08f3@localhost> References: <046.111251f57247f17187bc3cbd93be08f3@localhost> Message-ID: <055.3e957b327d8df62192aaecbdc7e65301@localhost> #3007: GHC seems to ignore the package name of modules imported with {#- SOURCE #-} -------------------------------+-------------------------------------------- Reporter: jeltsch | Owner: igloo Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 13 11:31:09 2009 From: trac at galois.com (GHC) Date: Thu Aug 13 11:11:32 2009 Subject: [GHC] #3395: Template Haskell crashes In-Reply-To: <051.8ddfdbe5023ec6ecffaddcf454ad0905@localhost> References: <051.8ddfdbe5023ec6ecffaddcf454ad0905@localhost> Message-ID: <060.aba602a8e82dc704bba07b796d457898@localhost> #3395: Template Haskell crashes ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: th/T3395 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): In the `template-haskell` library, I've also added a Haddock's documentation note to the `Exp` type about how to use `CompE`. {{{ Thu Aug 13 16:29:41 BST 2009 simonpj@microsoft.com * Document 'CompE' better (see Trac #3395) }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 13 12:22:26 2009 From: trac at galois.com (GHC) Date: Thu Aug 13 12:03:20 2009 Subject: [GHC] #3409: type variable out of scope in worker/wrapper transformation In-Reply-To: <045.9adc3defe572c3fa16e2251d91a15c7c@localhost> References: <045.9adc3defe572c3fa16e2251d91a15c7c@localhost> Message-ID: <054.ffb63d87c48b6d45ba7772c9c8a322b8@localhost> #3409: type variable out of scope in worker/wrapper transformation -----------------------------------------------+---------------------------- Reporter: judahj | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: typecheck/should_compile/T3409 | Os: Unknown/Multiple Architecture: Unknown/Multiple | -----------------------------------------------+---------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T3409 * status: new => closed * resolution: => fixed Comment: In fact it's as I said. Fixed by {{{ Thu Aug 13 09:11:54 PDT 2009 simonpj@microsoft.com * Fix Trac #3409: type synonyms that discard their arguments Type synonyms that don't mention one of their type parameters on the RHS are a pain in the neck. This patch fixes a long-standing bug (that simply has not appeared before) in that exprType could return a type mentioning an existentially-quantified variable (in one of those ignored argument positions). See CoreUtils Note [Existential variables and silly type synonyms] The fix is not entirely beautiful, but it works, and is very localised. M ./compiler/coreSyn/CoreUtils.lhs -1 +32 M ./compiler/types/Type.lhs -1 +24 }}} I checked that the original test, and the examples you gave subsequentlyl, all work fine with the patch applied. Thanks for identifying this bug. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 13 12:53:38 2009 From: trac at galois.com (GHC) Date: Thu Aug 13 12:34:35 2009 Subject: [GHC] #3007: GHC seems to ignore the package name of modules imported with {#- SOURCE #-} In-Reply-To: <046.111251f57247f17187bc3cbd93be08f3@localhost> References: <046.111251f57247f17187bc3cbd93be08f3@localhost> Message-ID: <055.efd7dfa5c90966ef510075cb83d3d67b@localhost> #3007: GHC seems to ignore the package name of modules imported with {#- SOURCE #-} -------------------------------+-------------------------------------------- Reporter: jeltsch | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Thu Aug 13 17:24:35 BST 2009 Ian Lynagh * Only look up whether a module's SOURCE-imported if it's in the current package Suppose we import anotherPackage:M, which exports things from anotherPackage:Internal. Then GHC will want to read anotherPackage:Internal.hi. However, if we have also SOURCE-imported thisPackage:Internal then we don't want GHC to try to read anotherPackage:Internal.hi-boot instead. The mapping that tells us whether a module is SOURCE-imported uses just the module name for the key, so we have to check the package ID before looking it up. Fixes #3007. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 13 12:56:47 2009 From: trac at galois.com (GHC) Date: Thu Aug 13 12:37:42 2009 Subject: [GHC] #2977: Install phase fails when using --enable-shared In-Reply-To: <045.994e869e093bd3112bffee0662aa176e@localhost> References: <045.994e869e093bd3112bffee0662aa176e@localhost> Message-ID: <054.7ae434c89d78f32dbb65dc0672c85fe0@localhost> #2977: Install phase fails when using --enable-shared -------------------------------+-------------------------------------------- Reporter: ingmar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | 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: `--enable-shared` is now the default in the HEAD on platforms that support it, and `make install` still works, so I'm closing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 14 07:08:31 2009 From: trac at galois.com (GHC) Date: Fri Aug 14 06:49:24 2009 Subject: [GHC] #3007: GHC seems to ignore the package name of modules imported with {#- SOURCE #-} In-Reply-To: <046.111251f57247f17187bc3cbd93be08f3@localhost> References: <046.111251f57247f17187bc3cbd93be08f3@localhost> Message-ID: <055.0016aa1704870a84ce83ede28f458c4b@localhost> #3007: GHC seems to ignore the package name of modules imported with {#- SOURCE #-} -------------------------------+-------------------------------------------- Reporter: jeltsch | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: driver/T3007 | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonpj): * testcase: => driver/T3007 Comment: Looking at the patch, I could see how to improve it a bit, so that if you `{#- SOURCE #-}` import a module from a different package, you get civilised error message: {{{ Foo.hs:3:0: You cannot {-# SOURCE #-} import a module from another package but `Data.List' is from package `base' }}} The patch is this: {{{ Fri Aug 14 12:02:14 BST 2009 simonpj@microsoft.com * Improve fix to Trac #3007 This patch tides up Ian's fix a little. In particular, if if you {-# SOURCE #-} import a module from a different package, you now get a much more civlised error message. M ./compiler/iface/LoadIface.lhs -14 +36 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 14 07:43:30 2009 From: trac at galois.com (GHC) Date: Fri Aug 14 07:23:56 2009 Subject: [GHC] #3165: :history throws "Irrefutable pattern failed" exception In-Reply-To: <046.98732e4c9934d7000eb5550f93cd4a26@localhost> References: <046.98732e4c9934d7000eb5550f93cd4a26@localhost> Message-ID: <055.1cc7558e91dac64d5f5e4c7cb224450c@localhost> #3165: :history throws "Irrefutable pattern failed" exception ------------------------+--------------------------------------------------- Reporter: greenrd | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: GHCi | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------+--------------------------------------------------- Comment (by igloo): Can you attach a testcase so that we can reproduce the problem, please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 14 07:47:30 2009 From: trac at galois.com (GHC) Date: Fri Aug 14 07:27:48 2009 Subject: [GHC] #3161: non-blocking read operations in Chan, Sem, QSem, SampleVar In-Reply-To: <053.85efed2401b79008b99b978e2ea1b3fc@localhost> References: <053.85efed2401b79008b99b978e2ea1b3fc@localhost> Message-ID: <062.56addd7f0de55000bf8ba245851873f7@localhost> #3161: non-blocking read operations in Chan, Sem, QSem, SampleVar ---------------------------------+------------------------------------------ Reporter: ChrisKuklewicz | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: Can you please make a [http://www.haskell.org/haskellwiki/Library_submissions library submissions proposal] for this? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 14 08:10:08 2009 From: trac at galois.com (GHC) Date: Fri Aug 14 07:50:27 2009 Subject: [GHC] #3429: Segfault when running with +RTS -N2 Message-ID: <044.e690845a92c0fd98b3a90535a9e04248@localhost> #3429: Segfault when running with +RTS -N2 -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- This program: {{{ import Control.Concurrent import Control.Concurrent.MVar import Control.Exception import System.IO main :: IO () main = do hSetBuffering stdout NoBuffering let loop = doit >> loop loop doit :: IO () doit = do v <- newMVar '.' t <- forkIO (foo v) threadDelay 1000 killThread t takeMVar v >>= putChar foo :: MVar Char -> IO () foo v = do let loop = do withMVar v $ \x -> evaluate x loop loop }}} segfaults for me on amd64/Linux when compiled with a validated HEAD and run with `+RTS -N2`: {{{ $ ghc --make j -threaded [1 of 1] Compiling Main ( j.hs, j.o ) Linking j ... $ ./j +RTS -N2 zsh: segmentation fault ./j +RTS -N2 $ ./j +RTS -N2 ......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................zsh: segmentation fault ./j +RTS -N2 $ ./j +RTS -N2 ...........................................zsh: segmentation fault ./j +RTS -N2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 15 13:00:20 2009 From: trac at galois.com (GHC) Date: Sat Aug 15 12:40:37 2009 Subject: [GHC] #3430: ghci crashes Message-ID: <051.7288f438eac16623dc959303accfb5cc@localhost> #3430: ghci crashes -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Given the two attached files, HLint.hs and System.Console.CmdArgs.hs, if I do: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.10.3.20090530 $ runhaskell HLint.hs helm }}} Then GHC segfaults. This is on Windows Vista. I looked in to reducing this bug, and totally failed. If I modify a single line, even totally unconnected, then it works. If I reduce any single output string in the program by even 1 character, it then starts working. I suspect there is a off-by-one error at some boundary condition, so while the error is 100% repeatable, it doesn't look like an easy one to debug. I suspect that something trivial like a change in the desugaring of any construct will stop this bug happening with this particular file. However, I suspect that just means the bug moves to a different magic constant and will still be there underneath. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 16 15:37:49 2009 From: trac at galois.com (GHC) Date: Sun Aug 16 15:18:03 2009 Subject: [GHC] #3431: Loading this module causes panic in interpreter. Message-ID: <043.8f0b4e0a78325f9938686ca09a662380@localhost> #3431: Loading this module causes panic in interpreter. -----------------------------+---------------------------------------------- Reporter: jsnx | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Severity: major Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This file causes a panic when I try to load it in {{{ghci}}}; but it compiles okay with {{{ghc}}}. {{{ Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :load Submutations.hs [1 of 1] Compiling Submutations ( Submutations.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-apple-darwin): schemeE(AnnCase).my_discr __word 0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} This bug has been observed with 6.10.3 on OS X and 6.10.4 on both OS X and x86_64 Linux. When the definition of `permutations` is commented out and replaced with `undefined`, the problem goes away. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 16 15:48:54 2009 From: trac at galois.com (GHC) Date: Sun Aug 16 15:29:08 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.6594a716b2f2f71065bd466776633f34@localhost> #2881: Basic Fibonacci function using Word causes ghci to panic. - 6.10.1 -------------------------------------+-------------------------------------- Reporter: axman6 | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: 6.12 branch Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: Keywords: panic Word fibonacci | Difficulty: Easy (1 hr) Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | -------------------------------------+-------------------------------------- Comment (by igloo): Duplicated by #3431. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 16 15:48:54 2009 From: trac at galois.com (GHC) Date: Sun Aug 16 15:29:09 2009 Subject: [GHC] #3431: Loading this module causes panic in interpreter. In-Reply-To: <043.8f0b4e0a78325f9938686ca09a662380@localhost> References: <043.8f0b4e0a78325f9938686ca09a662380@localhost> Message-ID: <052.7cc8306e4df447f0f4a4f8b29aa9fc81@localhost> #3431: Loading this module causes panic in interpreter. ---------------------------------+------------------------------------------ Reporter: jsnx | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: major | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report. This is a duplicate of #2881, so I'll close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 16 16:04:14 2009 From: trac at galois.com (GHC) Date: Sun Aug 16 15:44:27 2009 Subject: [GHC] #3431: Loading this module causes panic in interpreter. In-Reply-To: <043.8f0b4e0a78325f9938686ca09a662380@localhost> References: <043.8f0b4e0a78325f9938686ca09a662380@localhost> Message-ID: <052.b73e8f7f33bd397d44928ff6894d4a0b@localhost> #3431: Loading this module causes panic in interpreter. ---------------------------------+------------------------------------------ Reporter: jsnx | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: major | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by jsnx): Replying to [comment:1 igloo]: > Thanks for the report. This is a duplicate of #2881, so I'll close this ticket. Is #3425 related? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 16 17:26:44 2009 From: trac at galois.com (GHC) Date: Sun Aug 16 17:06:56 2009 Subject: [GHC] #3431: Loading this module causes panic in interpreter. In-Reply-To: <043.8f0b4e0a78325f9938686ca09a662380@localhost> References: <043.8f0b4e0a78325f9938686ca09a662380@localhost> Message-ID: <052.43860fdf6d3de9fa89deeb8553cda21a@localhost> #3431: Loading this module causes panic in interpreter. ---------------------------------+------------------------------------------ Reporter: jsnx | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: major | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by jsnx): Replying to [comment:2 jsnx]: > Replying to [comment:1 igloo]: > > Thanks for the report. This is a duplicate of #2881, so I'll close this ticket. > > Is #3425 related? No, I guess not -- #2881 has to do with pattern matches on `Word`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 16 18:27:33 2009 From: trac at galois.com (GHC) Date: Sun Aug 16 18:07:45 2009 Subject: [GHC] #1924: Rewrite the handling of values we get from ./configure In-Reply-To: <044.9ce32a75cdc46063892169755ff2cb07@localhost> References: <044.9ce32a75cdc46063892169755ff2cb07@localhost> Message-ID: <053.1bf5572c2daa4d3a2aec17adc6cf49c6@localhost> #1924: Rewrite the handling of values we get from ./configure ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by: {{{ Fri Aug 14 15:45:49 PDT 2009 Ian Lynagh * Make our install variables etc compliant with GNU standards; fixes #1924 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 06:13:12 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 05:53:21 2009 Subject: [GHC] #3432: ghc panic because of incorrect module Message-ID: <043.cd2cad0ca79fa41a5887312b19be696b@localhost> #3432: ghc panic because of incorrect module -----------------------------+---------------------------------------------- Reporter: lant | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- the GHC message was: " ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): getOptions'.parseLanguage(2) went past eof token " it happened during compilation incorrect module. I use {-# LANGUAGE -XExistentialQuantification #-} instead of {-# OPTIONS -XExistentialQuantification #-} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 06:48:23 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 06:28:42 2009 Subject: [GHC] #2362: allow full import syntax in GHCi In-Reply-To: <051.a17c861cfc196911194c3abd0e428c4d@localhost> References: <051.a17c861cfc196911194c3abd0e428c4d@localhost> Message-ID: <060.e7fe08e6892bf56bd72f9c6b6532a7ad@localhost> #2362: allow full import syntax in GHCi ---------------------------------+------------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: high | Milestone: 6.14 branch Component: Compiler | Version: 6.8.2 Severity: normal | Resolution: Keywords: ghci, import | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: 6.12.1 => 6.14 branch Comment: Not going to happen for 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 06:54:01 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 06:34:12 2009 Subject: [GHC] #2442: Heuristics to improve error messages for badly referenced things In-Reply-To: <053.d96b74737451be892238b37815ca44b6@localhost> References: <053.d96b74737451be892238b37815ca44b6@localhost> Message-ID: <062.f7dcdac803a113b616c372ec88d78b48@localhost> #2442: Heuristics to improve error messages for badly referenced things ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: simonpj Type: feature request | Status: new Priority: high | Milestone: 6.14 branch Component: Compiler | Version: 6.9 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: 6.12.1 => 6.14 branch Comment: Ran out of time; still needs review, and there might be some concerns about performance. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 06:56:22 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 06:36:32 2009 Subject: [GHC] #2451: New signal-handling API In-Reply-To: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> References: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> Message-ID: <056.110d421edc61853ef5e8c1e6d768faa8@localhost> #2451: New signal-handling API ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: proposal | Status: new Priority: high | Milestone: 6.14 branch Component: libraries/unix | 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 branch Comment: No time before 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 06:59:46 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 06:40:02 2009 Subject: [GHC] #2790: Use -fregs-graph by default In-Reply-To: <044.e23cb1a138a9b4ed2c315b0444e4b3fc@localhost> References: <044.e23cb1a138a9b4ed2c315b0444e4b3fc@localhost> Message-ID: <053.734de42d4c2c8cfe57913912c1540c68@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 simonmar): Ben - do you plan to look into this in time for 6.12.1? (RC 11 Sept) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 07:09:14 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 06:49:28 2009 Subject: [GHC] #3132: cgCase of PrimAlts needs care in new codegen In-Reply-To: <044.486f0fa3ddd7b77dad74344aee019e46@localhost> References: <044.486f0fa3ddd7b77dad74344aee019e46@localhost> Message-ID: <053.3921ea66e526e95a8660ad9b54def6e2@localhost> #3132: cgCase of PrimAlts needs care in new codegen -------------------------------+-------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * summary: x86 code generator generates bad FPU register names => cgCase of PrimAlts needs care in new codegen * milestone: 6.12.1 => 6.14.1 Comment: Bumped - no new codegen in 6.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 07:09:49 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 06:50:02 2009 Subject: [GHC] #3132: cgCase of PrimAlts needs care in new codegen In-Reply-To: <044.486f0fa3ddd7b77dad74344aee019e46@localhost> References: <044.486f0fa3ddd7b77dad74344aee019e46@localhost> Message-ID: <053.677839d158a5f8d9bfe5c669dd74b4c2@localhost> #3132: cgCase of PrimAlts needs care in new codegen -------------------------------+-------------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: high | Milestone: 6.14.1 Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by simonmar): See also #3286 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 07:10:25 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 06:50:34 2009 Subject: [GHC] #3286: junk `naughty x86_64 register' after expression In-Reply-To: <044.a884c108b16324d08849108fcabffd26@localhost> References: <044.a884c108b16324d08849108fcabffd26@localhost> Message-ID: <053.0004df667eac04c07e221c6cfe082891@localhost> #3286: junk `naughty x86_64 register' after expression -------------------------------+-------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * owner: => igloo Comment: Allegedly fixed by #3132 - Ian could you check please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 07:12:18 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 06:52:29 2009 Subject: [GHC] #3295: Null deref by threaded runtime scheduler In-Reply-To: <044.c2ef3bf0c2dff07fbe94ef6f704ea47f@localhost> References: <044.c2ef3bf0c2dff07fbe94ef6f704ea47f@localhost> Message-ID: <053.0f2eade552eecb337a7d74a7461eb9e7@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): Did you manage to find a small reproducible test case? Is the bug still reproducible with the current HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 07:12:51 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 06:53:10 2009 Subject: [GHC] #3296: mention also -RTS after stack overflow In-Reply-To: <045.b258499c759b06282a80550677967359@localhost> References: <045.b258499c759b06282a80550677967359@localhost> Message-ID: <054.85b6c2d340d488d2ee79b917ff44d7e1@localhost> #3296: mention also -RTS after stack overflow ---------------------------------+------------------------------------------ Reporter: maeder | Owner: igloo Type: feature request | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.3 Severity: trivial | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 07:15:43 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 06:56:04 2009 Subject: [GHC] #3390: Make the Windows build work with mingw gcc 4.4.0 In-Reply-To: <047.29bca0c885caf29d0340fe02876b5659@localhost> References: <047.29bca0c885caf29d0340fe02876b5659@localhost> Message-ID: <056.b9593e4e52d8e4062fb6c84c4f776999@localhost> #3390: Make the Windows build work with mingw gcc 4.4.0 -----------------------------+---------------------------------------------- Reporter: simonmar | Owner: igloo Type: task | Status: new Priority: high | Milestone: 6.12.1 Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by simonmar): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 07:19:15 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 06:59:25 2009 Subject: [GHC] #3424: Corrupt executable when compiling large do block for List monad In-Reply-To: <044.0e7bdc71d50ace8354623d9f560b19d9@localhost> References: <044.0e7bdc71d50ace8354623d9f560b19d9@localhost> Message-ID: <053.803746734b553bf37f8506e75c925d61@localhost> #3424: Corrupt executable when compiling large do block for List monad -------------------------+-------------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 07:19:39 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 06:59:49 2009 Subject: [GHC] #3429: Segfault when running with +RTS -N2 In-Reply-To: <044.e690845a92c0fd98b3a90535a9e04248@localhost> References: <044.e690845a92c0fd98b3a90535a9e04248@localhost> Message-ID: <053.dd103e0bfe39ed9d59da46d6678ae33a@localhost> #3429: Segfault when running with +RTS -N2 ---------------------------------+------------------------------------------ Reporter: igloo | 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 | ---------------------------------+------------------------------------------ Changes (by simonmar): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 07:22:45 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 07:02:56 2009 Subject: [GHC] #592: signal handlers should be able to access siginfo_t information In-Reply-To: <047.44a80ef10278cacddbca83ff583da267@localhost> References: <047.44a80ef10278cacddbca83ff583da267@localhost> Message-ID: <056.65772585a4dec10438380dab96152a51@localhost> #592: signal handlers should be able to access siginfo_t information ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/unix | Version: 6.4.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: N/A | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: Subsumed by #2451 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 07:23:47 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 07:03:58 2009 Subject: [GHC] #2451: New signal-handling API In-Reply-To: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> References: <047.5b7641d67bfb4c219c1a85428fd85097@localhost> Message-ID: <056.cae99ab560e2f4437834af5bc159cf3b@localhost> #2451: New signal-handling API ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: proposal | Status: new Priority: high | Milestone: 6.14 branch Component: libraries/unix | Version: 6.8.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): See also #592 (expose siginfo_t to signal handlers) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 13:03:44 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 12:43:53 2009 Subject: [GHC] #3433: Omitted # after LANGUAGE pragma causes panic Message-ID: <050.def0e31e4169c605464040ff0d537645@localhost> #3433: Omitted # after LANGUAGE pragma causes panic ------------------------+--------------------------------------------------- Reporter: viritrilbia | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: minor Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ------------------------+--------------------------------------------------- If the # in the closing #-} after a LANGUAGE pragma is omitted, GHC panics. For example, creating a file containing the single line: {{{ {-# LANGUAGE TypeFamilies -} }}} and passing it to GHC or GHCi produces: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for i386-unknown-linux): getOptions'.parseLanguage(1) went past eof token }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 14:40:31 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 14:20:42 2009 Subject: [GHC] #3434: improve vi tags (add non-exported symbols, add tag kinds, add regex tags) Message-ID: <046.d2dbc3c59e7dd2597dcfc9a0bd98987b@localhost> #3434: improve vi tags (add non-exported symbols, add tag kinds, add regex tags) -----------------------------+---------------------------------------------- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Severity: normal Keywords: vim tags ctags | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Ghci :ctags command does not generate tags for non-exported top level symbols. It also does not add type hints (vim kinds) to tags and does not allow generation of tags which are searched based on a regular expression instead of a line number. All these features of tags are supported well by vim but they are not supported by :ctags command. New :ctags syntax should be: {{{:ctags[!] [file]}}} The new command should generate tags for all top level symbols (regarles whether they are exported). The non-exported symbols should be marked as static in vim tags file. Vim tag kind field should be filled in with a haskell type hint. If the exclamation mark is added then the Ex address expressions in vim tags file should be based on search expression instead of line number. The search exression should search the whole line. This would provide better resistance to edits of unrelated lines. The problem was discussed here: http://www.haskell.org/pipermail/glasgow- haskell-users/2009-June/017399.html The ticket is supported by me and Claus Reinke. Rest of the comunity did not indicate their (positive or negative) opinion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 17 14:56:08 2009 From: trac at galois.com (GHC) Date: Mon Aug 17 14:36:18 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.00b520e3125c8f33e110182728eda56d@localhost> #3434: improve vi tags (add non-exported symbols, add tag kinds, add regex tags) ------------------------------+--------------------------------------------- Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: Keywords: vim tags ctags | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Comment (by phercek): I wanted to attach a solution to this ticket but the darcs patch file is too big to be accepted. The patch itself has only about 300 lines and modifies only two files but the darcs context is big. You can download the patch here: http://www.hck.sk/users/peter/pub/ghc/improveVimTags.dpatch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 18 05:05:26 2009 From: trac at galois.com (GHC) Date: Tue Aug 18 04:45:34 2009 Subject: [GHC] #3435: ghc-stage2 panic while compiling ghc-paths-0.1.0.5 Message-ID: <043.4f1d9667826ab434e5c82a9c75a75a17@localhost> #3435: ghc-stage2 panic while compiling ghc-paths-0.1.0.5 -------------------+-------------------------------------------------------- Reporter: jsch | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- Compilation of ghc-paths-0.1.0.5 with ghc-6.11.20090816 (darcs checkout) fails: {{{ jsch@lafleur:~/Desktop/ghc-paths-0.1.0.5$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.11.20090816 jsch@lafleur:~/Desktop/ghc-paths-0.1.0.5$ cabal --version cabal-install version 0.6.2 using version 1.6.0.3 of the Cabal library jsch@lafleur:~/Desktop/ghc-paths-0.1.0.5$ cabal configure --user Resolving dependencies... Configuring ghc-paths-0.1.0.5... jsch@lafleur:~/Desktop/ghc-paths-0.1.0.5$ cabal build Preprocessing library ghc-paths-0.1.0.5... Building ghc-paths-0.1.0.5... ghc-stage2: panic! (the 'impossible' happened) (GHC version 6.11.20090816 for i386-unknown-linux): Prelude.chr: bad argument: (-939524096) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} To compile ghc-paths-0.1.0.5 I replaced the Cabal library first (Setup.hs fails with 1.7.3): {{{ jsch@lafleur:~/Desktop/ghc-paths-0.1.0.5$ ghc-pkg list /home/jsch/stow/ghc-darcs/lib/ghc-6.11.20090816/package.conf: (Cabal-1.7.3), array-0.2.0.1, base-3.0.3.0, base-4.1.0.0, bytestring-0.9.1.4, containers-0.2.0.1, directory-1.0.0.2, (dph-base-0.4.0), (dph-par-0.4.0), (dph-prim-interface-0.4.0), (dph-prim-par-0.4.0), (dph-prim-seq-0.4.0), (dph-seq-0.4.0), extensible-exceptions-0.1.1.0, ffi-1.0, filepath-1.1.0.1, ghc-6.11.20090816, ghc-prim-0.1.0.0, haskeline-0.6.2, haskell98-1.0.1.0, hpc-0.5.0.2, integer-gmp-0.1.0.0, mtl-1.1.0.2, old-locale-1.0.0.1, old-time-1.0.0.1, pretty-1.0.1.0, process-1.0.1.1, random-1.0.0.1, rts-1.0, syb-0.1.0.0, template-haskell-2.4.0.0, terminfo-0.3.1, time-1.1.4, unix-2.3.1.0, utf8-string-0.3.4 /home/jsch/.ghc/i386-linux-6.11.20090816/package.conf: Cabal-1.6.0.2 }}} I have since updated my checkout (to 20090817) and will update this ticket as soon as I know if the problem persists. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 18 05:22:06 2009 From: trac at galois.com (GHC) Date: Tue Aug 18 05:02:13 2009 Subject: [GHC] #3435: ghc-stage2 panic while compiling ghc-paths-0.1.0.5 In-Reply-To: <043.4f1d9667826ab434e5c82a9c75a75a17@localhost> References: <043.4f1d9667826ab434e5c82a9c75a75a17@localhost> Message-ID: <052.0f448812f772de65a0bf8357ed7481b7@localhost> #3435: ghc-stage2 panic while compiling ghc-paths-0.1.0.5 ----------------------+----------------------------------------------------- Reporter: jsch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86 ----------------------+----------------------------------------------------- Comment (by jsch): Still on ghc-6.11.20090816, the following worked after updating Cabal to 1.6.0.3: {{{ $ cabal install cabal --user --reinstall $ cabal install ghc-paths }}} This leaves me unable to reproduce the above behavior at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 18 05:33:03 2009 From: trac at galois.com (GHC) Date: Tue Aug 18 05:13:11 2009 Subject: [GHC] #3436: internal error: traverseWeakPtrList: not WEAK Message-ID: <050.705145ec7510c89b41279536e44ce954@localhost> #3436: internal error: traverseWeakPtrList: not WEAK ------------------------+--------------------------------------------------- Reporter: sannysanoff | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ------------------------+--------------------------------------------------- I was compiling my program (attached) with jhc version 0.6.1. jhc was compiled with ghc 6.10.4 with -O, not -O2 option, as in jhc's Makefile. ghc 6.10.4 was taken from arch linux repository. warning: jhc compilation takes very long (I went home after 45 min) and very much (maybe 8G RAM?). i am not sure about total memory conditions, around 10G+7G swap was available for compile. error was: jhc: internal error: traverseWeakPtrList: not WEAK (GHC version 6.10.4 for x86_64_unknown_linux) 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 Tue Aug 18 05:36:14 2009 From: trac at galois.com (GHC) Date: Tue Aug 18 05:16:21 2009 Subject: [GHC] #3436: runtime: internal error: traverseWeakPtrList: not WEAK In-Reply-To: <050.705145ec7510c89b41279536e44ce954@localhost> References: <050.705145ec7510c89b41279536e44ce954@localhost> Message-ID: <059.99c3e70bce58bad0c61524863ed010bb@localhost> #3436: runtime: internal error: traverseWeakPtrList: not WEAK ----------------------------+----------------------------------------------- Reporter: sannysanoff | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ----------------------------+----------------------------------------------- Changes (by sannysanoff): * summary: internal error: traverseWeakPtrList: not WEAK => runtime: internal error: traverseWeakPtrList: not WEAK -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 18 06:06:40 2009 From: trac at galois.com (GHC) Date: Tue Aug 18 05:46:47 2009 Subject: [GHC] #3417: Data.Array.IO.hGetArray should be implemented. In-Reply-To: <044.4fe87e98cecbfb577c4777a984e7c8b6@localhost> References: <044.4fe87e98cecbfb577c4777a984e7c8b6@localhost> Message-ID: <053.96a6c34c0a62acf117296787e7a59984@localhost> #3417: Data.Array.IO.hGetArray should be implemented. ----------------------------------+----------------------------------------- Reporter: int-e | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries (other) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by simonmar): I can implement it without too much difficulty in terms of hGetBuf, but it won't be as efficient as before (the data is copied an extra time). I did the same thing for some code in the dph package. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 18 06:29:37 2009 From: trac at galois.com (GHC) Date: Tue Aug 18 06:09:43 2009 Subject: [GHC] #3437: Optimizer creates space leak on simple code Message-ID: <044.cf82c0f7bc349e25c0be89c8ea166251@localhost> #3437: Optimizer creates space leak on simple code -------------------+-------------------------------------------------------- Reporter: lilac | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- The following code should run in constant space: {{{ {-# LANGUAGE BangPatterns #-} go (x:xs) !n !k = go xs 0 (n+k+1) main = print (go (repeat 'x') 0 0 :: Int) }}} However, when compiled with -O2, it rapidly eats up the heap. If n and k are forced to be Int rather than Integer, the problem disappears. Core for the above with -O2 is here: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8268 [[BR]] The original code from which this was taken is here: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8266 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 18 06:31:26 2009 From: trac at galois.com (GHC) Date: Tue Aug 18 06:11:34 2009 Subject: [GHC] #3433: Omitted # after LANGUAGE pragma causes panic In-Reply-To: <050.def0e31e4169c605464040ff0d537645@localhost> References: <050.def0e31e4169c605464040ff0d537645@localhost> Message-ID: <059.1739fb94e2e100e6e66001481afdc916@localhost> #3433: Omitted # after LANGUAGE pragma causes panic ---------------------------------+------------------------------------------ Reporter: viritrilbia | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: minor | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: dup of #3153 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 18 06:45:19 2009 From: trac at galois.com (GHC) Date: Tue Aug 18 06:25:28 2009 Subject: [GHC] #3435: ghc-stage2 panic while compiling ghc-paths-0.1.0.5 In-Reply-To: <043.4f1d9667826ab434e5c82a9c75a75a17@localhost> References: <043.4f1d9667826ab434e5c82a9c75a75a17@localhost> Message-ID: <052.2447563431896667ca28dd947ead43fc@localhost> #3435: ghc-stage2 panic while compiling ghc-paths-0.1.0.5 -------------------------+-------------------------------------------------- Reporter: jsch | 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: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * priority: normal => high * difficulty: => Unknown * owner: => simonmar * milestone: => 6.12.1 Comment: There are two things going on here. The panic is because GHC has tried to read an interface file generated by an older version of GHC (do you have any idea how this happened?). The second thing is that GHC is supposed to report a helpful error message rather than panic when it reads an old interface file. I've been suspicious that this isn't working properly for some time, given the number of panics we've been seeing. I think I now understand what's happened. The external binary format for `Int` was changed recently on 32-bit platforms to be the same as on 64-bit platforms; unfortunately because GHC reads an `Int` before the version check on the `.hi` file, GHC sees a corrupt binary representation for the version and panics while reading it. So I'll fix the binary format to be stable again; unfortunately this will also change the binary format once more, so we'll have another round of panics before things settle down (note this is only an issue if you're working with HEAD, not a released version of GHC). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 18 07:07:07 2009 From: trac at galois.com (GHC) Date: Tue Aug 18 06:47:16 2009 Subject: [GHC] #3435: ghc-stage2 panic while compiling ghc-paths-0.1.0.5 In-Reply-To: <043.4f1d9667826ab434e5c82a9c75a75a17@localhost> References: <043.4f1d9667826ab434e5c82a9c75a75a17@localhost> Message-ID: <052.5273349a162f726acdda58444a949d11@localhost> #3435: ghc-stage2 panic while compiling ghc-paths-0.1.0.5 -------------------------+-------------------------------------------------- Reporter: jsch | 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: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by jsch): I had used the ghc-paths sources for installing the module with another GHC version before, so that should explain the old interface files (and why it worked with "cabal install" which downloaded fresh sources to /tmp). I guess I simply assumed the compiler would handle incompatible .hi and .o files by itself (by simply recompiling) as it does for changed source files. Anyway, I did not think about it, otherwise I would have cleaned the directory first (and probably not tickled this in the first place). (works for me now that I know why it happens) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 18 08:53:58 2009 From: trac at galois.com (GHC) Date: Tue Aug 18 08:34:24 2009 Subject: [GHC] #3405: ghc: panic! FamInstEnv.pprFamInstHdr In-Reply-To: <042.dded98492224a2f28c862d5e30a05f7e@localhost> References: <042.dded98492224a2f28c862d5e30a05f7e@localhost> Message-ID: <051.66cdc5511a81758650c04bed9706a663@localhost> #3405: ghc: panic! FamInstEnv.pprFamInstHdr ------------------------------+--------------------------------------------- Reporter: dsf | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ------------------------------+--------------------------------------------- Changes (by chak): * status: new => closed * resolution: => fixed Comment: You may want to try your example with the current development version to verify that the issue has really been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 18 09:38:16 2009 From: trac at galois.com (GHC) Date: Tue Aug 18 09:18:23 2009 Subject: [GHC] #3438: Unregisterised build broken Message-ID: <047.5cb011817f7e8c7cbec9e1dfcec9f0ae@localhost> #3438: Unregisterised build broken -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- The unregisterised nightly build is failing thusly: {{{ "/home/simonmar/fp/bin/x86_64-unknown-linux/ghc" -optc-O -optc-DNO_REGS -optc-DUSE_MINIINTERPRETER -optc-D__GLASGOW_HASKELL__=611 -optc- Icompiler/stage1 -optc-Icompiler/../libraries/base/cbits -optc- Icompiler/../libraries/base/include -optc-Icompiler/. -optc- Icompiler/parser -optc-Icompiler/utils -optc-DOMIT_NATIVE_CODEGEN -optc- isystem/home/simonmar/fp/lib/x86_64-unknown- linux/ghc-6.10.2/bytestring-0.9.1.4/include -optc- isystem/home/simonmar/fp/lib/x86_64-unknown- linux/ghc-6.10.2/process-1.0.1.1/include -optc- isystem/home/simonmar/fp/lib/x86_64-unknown- linux/ghc-6.10.2/directory-1.0.0.3/include -optc- isystem/home/simonmar/fp/lib/x86_64-unknown- linux/ghc-6.10.2/unix-2.3.2.0/include -optc- isystem/home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.10.2/old- time-1.0.0.2/include -optc-isystem/home/simonmar/fp/lib/x86_64-unknown- linux/ghc-6.10.2/base-4.1.0.0/include -optc- isystem/home/simonmar/fp/lib/x86_64-unknown-linux/ghc-6.10.2/include -H32m -O -package-conf libraries/bootstrapping.conf -package-name ghc-6.11 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/main -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/stage1 -Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include -Icompiler/. -Icompiler/parser -Icompiler/utils -optP- DOMIT_NATIVE_CODEGEN -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.7.3 -package array-0.2.0.0 -package base-4.1.0.0 -package bytestring-0.9.1.4 -package containers-0.2.0.1 -package directory-1.0.0.3 -package filepath-1.1.0.2 -package hpc-0.5.0.3 -package old-time-1.0.0.2 -package process-1.0.1.1 -package unix-2.3.2.0 -DOMIT_NATIVE_CODEGEN -#include cutils.h -DSTAGE=1 -Wall -fno-warn-name-shadowing -fno-warn-orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses -XFlexibleInstances -XRank2Types -XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec -c compiler/parser/cutils.c -o compiler/stage1/build/parser/cutils.o : warning: "__GLASGOW_HASKELL__" redefined : warning: this is the location of the previous definition compiler/parser/cutils.c: In function 'enableTimingStats': compiler/parser/cutils.c:45:0: error: 'RtsFlags' undeclared (first use in this function) compiler/parser/cutils.c:45:0: error: (Each undeclared identifier is reported only once compiler/parser/cutils.c:45:0: error: for each function it appears in.) compiler/parser/cutils.c:45:0: error: 'ONELINE_GC_STATS' undeclared (first use in this function) compiler/parser/cutils.c: In function 'setHeapSize': compiler/parser/cutils.c:51:0: error: 'RtsFlags' undeclared (first use in this function) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 18 10:16:22 2009 From: trac at galois.com (GHC) Date: Tue Aug 18 09:56:29 2009 Subject: [GHC] #3429: Segfault when running with +RTS -N2 In-Reply-To: <044.e690845a92c0fd98b3a90535a9e04248@localhost> References: <044.e690845a92c0fd98b3a90535a9e04248@localhost> Message-ID: <053.82871aafcdd06dbf2080b1e3b2c3b6e3@localhost> #3429: Segfault when running with +RTS -N2 ---------------------------------+------------------------------------------ Reporter: igloo | 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: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * component: Compiler => Runtime System * resolution: => fixed Comment: Fixed: {{{ Tue Aug 18 04:29:42 PDT 2009 Simon Marlow * Fix #3429: a tricky race condition There were two bugs, and had it not been for the first one we would not have noticed the second one, so this is quite fortunate. The first bug is in stg_unblockAsyncExceptionszh_ret, when we found a pending exception to raise, but don't end up raising it, there was a missing adjustment to the stack pointer. The second bug was that this case was actually happening at all: it ought to be incredibly rare, because the pending exception thread would have to be killed between us finding it and attempting to raise the exception. This made me suspicious. It turned out that there was a race condition on the tso->flags field; multiple threads were updating this bitmask field non-atomically (one of the bits is the dirty-bit for the generational GC). The fix is to move the dirty bit into its own field of the TSO, making the TSO one word larger (sadly). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 18 10:17:33 2009 From: trac at galois.com (GHC) Date: Tue Aug 18 09:57:42 2009 Subject: [GHC] #3438: Unregisterised build broken In-Reply-To: <047.5cb011817f7e8c7cbec9e1dfcec9f0ae@localhost> References: <047.5cb011817f7e8c7cbec9e1dfcec9f0ae@localhost> Message-ID: <056.85f929319b0195436a066e3c5393b7a3@localhost> #3438: Unregisterised build broken ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: 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 simonmar): * status: new => closed * component: Runtime System => Build System * resolution: => fixed Comment: Fixed: {{{ Thu Aug 6 02:54:17 PDT 2009 Simon Marlow * Fix unregisterised build }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 18 12:36:41 2009 From: trac at galois.com (GHC) Date: Tue Aug 18 12:16:49 2009 Subject: [GHC] #2337: Data.Array documentation utterly broken In-Reply-To: <045.1fd44b27076f8b28428287ad13138763@localhost> References: <045.1fd44b27076f8b28428287ad13138763@localhost> Message-ID: <054.65e5db83e0f27ad3c92909d97e7def51@localhost> #2337: Data.Array documentation utterly broken ---------------------------------+------------------------------------------ Reporter: japple | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Documentation | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by isaacdupree): So, this should be fixed with Haddock HEAD, as soon as we decide it's stable enough to release... not for a few days at least :-), but pretty surely before the GHC RC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 18 14:35:10 2009 From: trac at galois.com (GHC) Date: Tue Aug 18 14:15:17 2009 Subject: [GHC] #3398: Unicode output in GHC In-Reply-To: <047.de64825b187e674ad618957169425649@localhost> References: <047.de64825b187e674ad618957169425649@localhost> Message-ID: <056.84d850f67af72055c7a85e79afba6e6e@localhost> #3398: Unicode output in GHC ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: 2816 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by judahj): This plan sounds good to me. For Windows code-page encoding: I've got a prototype library for this. I will work on integrating it into the base library. There's another issue with this proposal, specifically printing Unicode !FilePaths in error messages. For example, with ghc-6.10.3 and a utf-8 terminal: {{{ jj-macbook:uni-test $ ghci foo?/Foo.hs [snip] foo?/Foo.hs:2:0: parse error (possibly incorrect indentation) Failed, modules loaded: none. Prelude> :r foo??/Foo.hs:2:0: parse error (possibly incorrect indentation) Failed, modules loaded: none. }}} This happens because the encoded !FilePath is embedded inside the error message as a String, so Haskeline (I think) re-encodes it before printing it out. Eventually, we'll need to solve #3307 and #3309 (better handling of Unicode getArgs and !FilePaths). However, that's part of a larger discussion which won't be completed in the next month. So, I propose that we: 1) Add {{{filePathToPrintableString :: FilePath -> IO String}}} . On Windows this does nothing; on Unix it uses iconv to decode the !FilePath and %-encode each undecodable byte. 2) Make GHC keep track of the printable String of each module's !FilePath, to be used when constructing error messages. Does that sound feasible? I can implement at least the first part and propose it to the libraries list. (I'd also like to use it within Haskeline itself.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 03:49:16 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 03:29:21 2009 Subject: [GHC] #3437: Optimizer creates space leak on simple code In-Reply-To: <044.cf82c0f7bc349e25c0be89c8ea166251@localhost> References: <044.cf82c0f7bc349e25c0be89c8ea166251@localhost> Message-ID: <053.239f7344674f1531b5dd3ad4205cf9bd@localhost> #3437: Optimizer creates space leak on simple code -------------------------------+-------------------------------------------- Reporter: lilac | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: Excellent bug thank you! It turns out that `go` is strict, but we don't do strictness analysis following `SpecConstr` so the specialised version of `go` is not (marked) strict. As a result, the latter builds a thunk each time around the loop, which creates the leak. It's not hard to transfer strictness; I'll try that. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 05:07:08 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 04:47:13 2009 Subject: [GHC] #3439: Improve the setup for ticky Message-ID: <046.97ec1b5f2b20c06c8559b26055a95a61@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 | Keywords: Difficulty: Easy (1 hr) | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Simon Marlow and I came up with the following proposals: * Merge the "ticky" and "debug" builds of the runtime system. This just simplifies the RTS build, and reduces the number of versions. * Arrange that ''every'' build of the RTS defines the symbols that are referenced by code compiled with `-ticky`. That way you won't get link errors if you compile tickified code with a non-debug RTS. The second point is very important. When testing I often want to compile all the libraries with `-ticky`, but it's very fiddly to ensure that every program compiled against those libraries is linked against the debug/ticky RTS. I just want those programs to work. The ones I want to examine closely (ie see the ticky stats) I can certainly link with `-ticky` or `-debug` to get the RTS that does the counting. None of this is difficult; just an hour or two's work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 05:08:38 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 04:48:42 2009 Subject: [GHC] #3439: Improve the setup for ticky In-Reply-To: <046.97ec1b5f2b20c06c8559b26055a95a61@localhost> References: <046.97ec1b5f2b20c06c8559b26055a95a61@localhost> Message-ID: <055.a6e2ed2a6605bb8754aee25295b3b10f@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 | ---------------------------------+------------------------------------------ Old description: > Simon Marlow and I came up with the following proposals: > * Merge the "ticky" and "debug" builds of the runtime system. This just > simplifies the RTS build, and reduces the number of versions. > * Arrange that ''every'' build of the RTS defines the symbols that are > referenced by code compiled with `-ticky`. That way you won't get link > errors if you compile tickified code with a non-debug RTS. > > The second point is very important. When testing I often want to compile > all the libraries with `-ticky`, but it's very fiddly to ensure that > every program compiled against those libraries is linked against the > debug/ticky RTS. I just want those programs to work. The ones I want to > examine closely (ie see the ticky stats) I can certainly link with > `-ticky` or `-debug` to get the RTS that does the counting. > > None of this is difficult; just an hour or two's work. New description: Simon Marlow and I came up with the following proposals: * Merge the "ticky" and "debug" builds of the runtime system. This just simplifies the RTS build, and reduces the number of versions. * Arrange that ''every'' build of the RTS defines the symbols that are referenced by code compiled with `-ticky`. That way you won't get link errors if you compile tickified code with a non-debug RTS. The second point is very important. When testing I often want to compile all the libraries with `-ticky`, but it's very fiddly to ensure that every program compiled against those libraries is linked against the debug/ticky RTS. I just want those programs to work. The ones I want to examine closely (ie see the ticky stats) I can certainly link with `-ticky` or `-debug` to get the RTS that does the counting. None of this is difficult; just an hour or two's work. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 05:21:08 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 05:01:12 2009 Subject: [GHC] #3440: Improve error message for GADT failures Message-ID: <046.b4d392ead07808cb956844cd7c242871@localhost> #3440: Improve error message for GADT failures --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.10.4 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --------------------------------------+------------------------------------- If you write {{{ type family Fam a :: * data GADT :: * -> * where GADT :: a -> Fam a -> GADT (Fam a) unwrap :: GADT (Fam a) -> (a, Fam a) unwrap (GADT x y) = (x, y) }}} then typechecking `unwrap` should certainly fail. And it does, but with a horrible message: {{{ Main.hs:9:21: Couldn't match expected type `a' against inferred type `a1' `a' is a rigid type variable bound by the type signature for `unwrap' at Main.hs:8:20 `a1' is a rigid type variable bound by the constructor `GADT' at Main.hs:9:8 In the expression: x In the expression: (x, y) In the definition of `unwrap': unwrap (GADT x y) = (x, y) }}} It would be better to say something more like: {{{ Cannot deduce (a ~ a1) from (Fam a ~ Fam a1) }}} See the thread at [http://thread.gmane.org/gmane.comp.lang.haskell.cafe/62322] -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 07:53:57 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 07:34:03 2009 Subject: [GHC] #3407: GHC.Prim documentation should mention GHC.Exts! In-Reply-To: <044.b2bcc86bcf34543dca950728f9a46ba1@localhost> References: <044.b2bcc86bcf34543dca950728f9a46ba1@localhost> Message-ID: <053.399006eb79deeeef34ad235ac19aedcc@localhost> #3407: GHC.Prim documentation should mention GHC.Exts! ---------------------------------+------------------------------------------ Reporter: RyanN | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): So the "Int (I#)" problem will be fixed by #2337. I've heard from David Waern and Isaac Dupree that the new support for cross-package documentation in Haddock should be ready very soon, and definitely in time for 6.12.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 07:56:22 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 07:36:27 2009 Subject: [GHC] #3083: Win32 package should bind SHGetFolderPath In-Reply-To: <045.07ec9167505060698bef96705be4add8@localhost> References: <045.07ec9167505060698bef96705be4add8@localhost> Message-ID: <054.3bf0989eeae8f03d740d5b5441c4b570@localhost> #3083: Win32 package should bind SHGetFolderPath ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: closed => reopened * resolution: wontfix => -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 07:57:01 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 07:37:04 2009 Subject: [GHC] #3083: Win32 package should bind SHGetFolderPath In-Reply-To: <045.07ec9167505060698bef96705be4add8@localhost> References: <045.07ec9167505060698bef96705be4add8@localhost> Message-ID: <054.bb0402055d8e33d3d5b3ff596bf2b773@localhost> #3083: Win32 package should bind SHGetFolderPath ----------------------------------+----------------------------------------- Reporter: duncan | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries (other) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: reopened => closed * resolution: => fixed Comment: It's already done, anyway. {{{ Mon Jun 29 11:47:50 BST 2009 Simon Marlow * add SHGetFolderPath support }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 08:07:25 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 07:47:39 2009 Subject: [GHC] #1548: printf bugs In-Reply-To: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> References: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> Message-ID: <060.a5b0e942cd06bbc8177db9be313bb454@localhost> #1548: printf bugs ---------------------------------+------------------------------------------ Reporter: l.mai@web.de | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Moderate (1 day) 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 Aug 19 09:05:14 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 08:45:20 2009 Subject: [GHC] #3286: junk `naughty x86_64 register' after expression In-Reply-To: <044.a884c108b16324d08849108fcabffd26@localhost> References: <044.a884c108b16324d08849108fcabffd26@localhost> Message-ID: <053.0b65596acac0c259e9913b66f59be7ba@localhost> #3286: junk `naughty x86_64 register' after expression -------------------------------+-------------------------------------------- Reporter: igloo | Owner: igloo Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: Compiler (NCG) | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T3286 | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * testcase: => T3286 * status: new => closed * resolution: => fixed Comment: Confirmed now working in the HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 09:37:11 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 09:17:17 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.0b513b4c2886aa3d13d68d281a2753a0@localhost> #3320: Parallel program crashes using GHC 6.11 under OS X -------------------------------+-------------------------------------------- Reporter: sebf | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by simonmar): I can't reproduce this on x86-64/Linux (as the reporter said). Can someone with a Mac confirm that it is still reproducible? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 09:38:47 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 09:18:55 2009 Subject: [GHC] #3374: Profiling libraries are not installed In-Reply-To: <046.8d56386f212a852d9f6e4247f2bbcfa0@localhost> References: <046.8d56386f212a852d9f6e4247f2bbcfa0@localhost> Message-ID: <055.e2aaf79ae75906aaf0a3075fe24611bc@localhost> #3374: Profiling libraries are not installed -------------------------------+-------------------------------------------- Reporter: scsibug | 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 * milestone: => 6.12.1 Comment: this would be a release-critical bug -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 09:52:30 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 09:32:33 2009 Subject: [GHC] #3441: readProcess ... (exit 11): failed Message-ID: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> #3441: readProcess ... (exit 11): failed --------------------------------+------------------------------------------- Reporter: Andriy | Owner: Type: bug | Status: new Priority: normal | Component: libraries/process Version: 6.10.3 | Severity: major Keywords: readProcess exit 11 | Testcase: Os: Linux | Architecture: x86 --------------------------------+------------------------------------------- When one haskell script (here Parent.hs) runs another script (Child.hs), it fails at some point with an error: Parent.hs: readProcess: ./Child.hs "param1" "param2" ... "paramN" (exit 11): failed Details: I have a set of haskell scripts. Each script has following interpreter spec as the first line: #!/usr/bin/env runghc These scripts manage some Java building process. Child.hs is long-running. It can run for a few hours. It builds a Java application, runs tests on it. About once a week the parent script fails with the error above. I use the script about 2-5 times a day. My system is Ubuntu 8.04 (Hardy Heron). I installed GHC 6.10.3 locally, I also have GHC 6.8.2 installed from the Ubuntu repositories. Besides the problem itself, it is not clear what "exit 11" means. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 10:27:55 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 10:08:09 2009 Subject: [GHC] #1548: printf bugs In-Reply-To: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> References: <051.8149d49ae360b0942c780022e9f1c1b0@localhost> Message-ID: <060.fb56e9d7d7cdc18d106415d2af4dbc42@localhost> #1548: printf bugs ---------------------------------+------------------------------------------ Reporter: l.mai@web.de | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.6.1 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: {{{ Wed Aug 19 05:07:00 PDT 2009 Simon Marlow * Apply fix for #1548, from squadette@gmail.com }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 12:04:41 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 11:44:45 2009 Subject: [GHC] #3442: GHC panics if closing #-} for a LANGUAGE pragma is not on the same line Message-ID: <044.c99a1aaca43edb6058ae86c2d82cdf0f@localhost> #3442: GHC panics if closing #-} for a LANGUAGE pragma is not on the same line -----------------------------+---------------------------------------------- Reporter: lilac | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This came up on #haskell: {{{ {-# LANGUAGE ExistentialQuantification #-} main = undefined }}} This sends ghc-6.10.3 into a tailspin: {{{ $ ghc --make foo.hs ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for x86_64-unknown-linux): getOptions'.parseLanguage(1) went past eof token Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Moving the #-} onto the LANGUAGE line fixes this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 12:09:26 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 11:49:29 2009 Subject: [GHC] #3442: GHC panics if closing #-} for a LANGUAGE pragma is not on the same line In-Reply-To: <044.c99a1aaca43edb6058ae86c2d82cdf0f@localhost> References: <044.c99a1aaca43edb6058ae86c2d82cdf0f@localhost> Message-ID: <053.e73dba8b59241b39ade43b0280a40c2f@localhost> #3442: GHC panics if closing #-} for a LANGUAGE pragma is not on the same line -------------------------------+-------------------------------------------- Reporter: lilac | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Comment (by lilac): Looks like the panic happens if the LANGUAGE pragma is more indented than the #-} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 15:29:27 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 15:09:31 2009 Subject: [GHC] #3443: GHCi produces a panic on printing and escaped GBP sign, and won't print gbp sign either Message-ID: <042.85340901ecdb424665a7501ad3deb7d1@localhost> #3443: GHCi produces a panic on printing and escaped GBP sign, and won't print gbp sign either -------------------+-------------------------------------------------------- Reporter: yb2 | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- Prelude> putStrLn "?" ? Prelude> putStrLn "\?" ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): charType: '\163' Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug --- I've also compiled a bit of code with GHC that can't output GBP symbol either. --- Tested with Hugs for comparison, Hugs> putStrLn "?" ? Hugs> putStrLn "\?" ERROR - Illegal character escape sequence "\?" --- I tested the outputting (not the escaping) in roxterm and xterm, and both output the question mark in a diamond symbol. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 17:16:21 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 16:56:24 2009 Subject: [GHC] #3444: index out of range during 'make install' Message-ID: <045.b400afa30ed53cc553630bb3ba81925e@localhost> #3444: index out of range during 'make install' --------------------+------------------------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.11 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 --------------------+------------------------------------------------------- When running 'make install' on an up-to-date pull of ghc+dependencies, 'make install' fails with the following error: {{{ Documentation created: stage2/doc/html/ghc/index.html cd libraries && sh gen_contents_index --inplace haddock: internal Haddock or GHC error: Ix{Int}.index: Index (81209088) out of range ((0,-1)) make[1]: *** [libraries/index.html] Error 1 make: *** [all] Error 2 }}} Let me know if more information is required. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 17:29:11 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 17:09:23 2009 Subject: [GHC] #3296: mention also -RTS after stack overflow In-Reply-To: <045.b258499c759b06282a80550677967359@localhost> References: <045.b258499c759b06282a80550677967359@localhost> Message-ID: <054.f02177a68421c0c5b9bd394d902f6bbb@localhost> #3296: mention also -RTS after stack overflow ---------------------------------+------------------------------------------ Reporter: maeder | Owner: igloo Type: feature request | Status: closed Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.10.3 Severity: trivial | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Fixed by: {{{ Wed Aug 19 21:21:12 BST 2009 Ian Lynagh * Improve the "Stack space overflow" error; fixes trac #3296 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 20:53:37 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 20:33:41 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.eed2a9dfa4b496399e463b903e59bcef@localhost> #3320: Parallel program crashes using GHC 6.11 under OS X -------------------------------+-------------------------------------------- Reporter: sebf | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by igloo): I can reproduce it, but not if I link with -debug as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 19 21:05:17 2009 From: trac at galois.com (GHC) Date: Wed Aug 19 20:45:18 2009 Subject: [GHC] #3444: index out of range during 'make install' In-Reply-To: <045.b400afa30ed53cc553630bb3ba81925e@localhost> References: <045.b400afa30ed53cc553630bb3ba81925e@localhost> Message-ID: <054.a3358fb3e73ca3977202607a47167d35@localhost> #3444: index out of range during 'make install' ------------------------------+--------------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ------------------------------+--------------------------------------------- Changes (by igloo): * difficulty: => Unknown Comment: I can't reproduce this on x86 OS X. Did you "make clean" after updating your tree? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 06:29:53 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 06:10:09 2009 Subject: [GHC] #3208: Type family panic (taking the IdInfo of a coercion variable) In-Reply-To: <046.41bf598a01dd8c4891c9aac614d23c08@localhost> References: <046.41bf598a01dd8c4891c9aac614d23c08@localhost> Message-ID: <055.d387d89a55e63f6c29728b66e3175743@localhost> #3208: Type family panic (taking the IdInfo of a coercion variable) ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by chak): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 06:30:41 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 06:10:55 2009 Subject: [GHC] #3208: Type family panic (taking the IdInfo of a coercion variable) In-Reply-To: <046.41bf598a01dd8c4891c9aac614d23c08@localhost> References: <046.41bf598a01dd8c4891c9aac614d23c08@localhost> Message-ID: <055.7db20455cd5dcbb73012d399ea31ecaa@localhost> #3208: Type family panic (taking the IdInfo of a coercion variable) ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T3208 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by chak): * testcase: => T3208 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 06:32:46 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 06:12:59 2009 Subject: [GHC] #2767: Type family bug ? In-Reply-To: <043.5d7b08e8b12f70310b2c5608326cbdc1@localhost> References: <043.5d7b08e8b12f70310b2c5608326cbdc1@localhost> Message-ID: <052.daa696ba3fc8b0b1861ab10290c40de0@localhost> #2767: Type family bug ? ----------------------------------------+----------------------------------- Reporter: test | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler (Type checker) | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T2767 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by chak): * testcase: => T2767 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 06:41:01 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 06:21:05 2009 Subject: [GHC] #3208: Type family panic (taking the IdInfo of a coercion variable) In-Reply-To: <046.41bf598a01dd8c4891c9aac614d23c08@localhost> References: <046.41bf598a01dd8c4891c9aac614d23c08@localhost> Message-ID: <055.90a6f31d357ae825f552d8d85c98812c@localhost> #3208: Type family panic (taking the IdInfo of a coercion variable) ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T3208a, T3208b | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by chak): * testcase: T3208 => T3208a, T3208b * status: closed => reopened * resolution: fixed => Comment: I did fix the original bug, but I noticed another bug in a modified version of the program; hence, I'll reopen the ticket. The problematic variant is the same program, but with the inferred types for `fce` and `fce'` added as signatures: {{{ {-# LANGUAGE TypeFamilies #-} module T3208b where class SUBST s where type STerm s class OBJECT o where type OTerm o apply :: (SUBST s, OTerm o ~ STerm s) => s -> o fce' :: (OTerm a ~ STerm a, OBJECT a, SUBST a) => a -> c fce' f = fce . apply $ f fce :: (OTerm a ~ STerm a, OBJECT a, SUBST a) => a -> c fce f = fce' f }}} In a debugging compiler (compiled with `-DDEBUG`), this violates an assertion {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 6.11.20090807 for i386-apple-darwin): ASSERT failed! file compiler/typecheck/TcMType.lhs line 349 t_afI{tv} [tau] }}} In a compiler without `-DDEBUG` the program is rejected with the following error message: {{{ T3208b.hs:13:0: Couldn't match expected type `STerm b' against inferred type `OTerm b' NB: `OTerm' is a type function, and may not be injective NB: `STerm' is a type function, and may not be injective When generalising the type(s) for `fce'' T3208b.hs:13:0: Couldn't match expected type `STerm a' against inferred type `STerm b' NB: `STerm' is a type function, and may not be injective When generalising the type(s) for `fce'' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 06:43:02 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 06:23:05 2009 Subject: [GHC] #3208: Incorrect handling of recursive groups with signatures containing equalities and TFs In-Reply-To: <046.41bf598a01dd8c4891c9aac614d23c08@localhost> References: <046.41bf598a01dd8c4891c9aac614d23c08@localhost> Message-ID: <055.465b6bdcb2b7d0b726d4bc540a2a65c1@localhost> #3208: Incorrect handling of recursive groups with signatures containing equalities and TFs ---------------------------------+------------------------------------------ Reporter: simonpj | Owner: chak Type: bug | Status: reopened Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: T3208a, T3208b | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by chak): * summary: Type family panic (taking the IdInfo of a coercion variable) => Incorrect handling of recursive groups with signatures containing equalities and TFs -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 06:55:25 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 06:35:37 2009 Subject: [GHC] #3418: Equality constraint causes ghc panic In-Reply-To: <046.4d0ae1a783985a2b7fcedd0e6c104820@localhost> References: <046.4d0ae1a783985a2b7fcedd0e6c104820@localhost> Message-ID: <055.b409ac395412b4d53bff1fead4a9b519@localhost> #3418: Equality constraint causes ghc panic -------------------------------------------------------+-------------------- Reporter: blarsen | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: type families, equality constraint, panic | Testcase: T3418 Os: Linux | Architecture: x86_64 (amd64) -------------------------------------------------------+-------------------- Changes (by chak): * testcase: => T3418 * status: new => closed * resolution: => fixed Comment: Fixed in the head by one of the recent changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 07:16:14 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 06:56:16 2009 Subject: [GHC] #3432: ghc panic because of incorrect module In-Reply-To: <043.cd2cad0ca79fa41a5887312b19be696b@localhost> References: <043.cd2cad0ca79fa41a5887312b19be696b@localhost> Message-ID: <052.3a9285ff1ed39c756208617fa739a9c0@localhost> #3432: ghc panic because of incorrect module ---------------------------------+------------------------------------------ Reporter: lant | Owner: Type: bug | Status: closed Priority: normal | Milestone: 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 * difficulty: => Unknown * resolution: => duplicate Comment: Thanks for the report; duplicate of #3153. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 07:21:19 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 07:01:22 2009 Subject: [GHC] #3436: runtime: internal error: traverseWeakPtrList: not WEAK In-Reply-To: <050.705145ec7510c89b41279536e44ce954@localhost> References: <050.705145ec7510c89b41279536e44ce954@localhost> Message-ID: <059.a5579524105fe606dea38902578b5389@localhost> #3436: runtime: internal error: traverseWeakPtrList: not WEAK -------------------------------+-------------------------------------------- Reporter: sannysanoff | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Is this reproducible, or was it just a one-off occurrence? (I want to know whether it's worth investing the time in building jhc to diagnose the crash). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 07:29:00 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 07:09:02 2009 Subject: [GHC] #3398: Unicode output in GHC In-Reply-To: <047.de64825b187e674ad618957169425649@localhost> References: <047.de64825b187e674ad618957169425649@localhost> Message-ID: <056.5a8ef8a31bba5ece3e47d2b729b3086b@localhost> #3398: Unicode output in GHC ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: 2816 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Won't the problem you illustrate be fixed by not doing encoding in Haskeline, which is part of this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 07:37:33 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 07:17:34 2009 Subject: [GHC] #3441: readProcess ... (exit 11): failed In-Reply-To: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> References: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> Message-ID: <054.adb07c9c6506e0f05c53db81d1c56058@localhost> #3441: readProcess ... (exit 11): failed ------------------------------------+--------------------------------------- Reporter: Andriy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/process | Version: 6.10.3 Severity: major | Resolution: worksforme Keywords: readProcess exit 11 | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------------------+--------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => worksforme Comment: exit 11 looks suspiciously like a segfault. And from your description, it looks like it is GHC itself that is segfaulting. But the fact that you say it only occurs once a week, and under some hard- to-reproduce conditions, means it's virtually impossible for us to make any progress on diagnosing this bug. It could even be hardware failure. I'm afraid I have to close this one - we're very grateful for the report, but there's nothing we can realistically do with the information you've supplied. If you can isolate the failure in a way that we'll be able to reproduce it here, then by all means re-open the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 07:38:52 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 07:18:54 2009 Subject: [GHC] #3442: GHC panics if closing #-} for a LANGUAGE pragma is not on the same line In-Reply-To: <044.c99a1aaca43edb6058ae86c2d82cdf0f@localhost> References: <044.c99a1aaca43edb6058ae86c2d82cdf0f@localhost> Message-ID: <053.337697413fabe068abc5c7133e34af5e@localhost> #3442: GHC panics if closing #-} for a LANGUAGE pragma is not on the same line ----------------------------------+----------------------------------------- Reporter: lilac | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: This is a popular bug! #3153 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 07:40:52 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 07:21:00 2009 Subject: [GHC] #3442: GHC panics if closing #-} for a LANGUAGE pragma is not on the same line In-Reply-To: <044.c99a1aaca43edb6058ae86c2d82cdf0f@localhost> References: <044.c99a1aaca43edb6058ae86c2d82cdf0f@localhost> Message-ID: <053.0e4c494e47846ff273f01d53711af3ed@localhost> #3442: GHC panics if closing #-} for a LANGUAGE pragma is not on the same line ----------------------------------+----------------------------------------- Reporter: lilac | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.3 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by simonmar): Perhaps we should have merged it into 6.10.3 after all... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 07:59:13 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 07:39:17 2009 Subject: [GHC] #3443: GHCi produces a panic on printing and escaped GBP sign, and won't print gbp sign either In-Reply-To: <042.85340901ecdb424665a7501ad3deb7d1@localhost> References: <042.85340901ecdb424665a7501ad3deb7d1@localhost> Message-ID: <051.a9e4dc8a1e2c391a9687304a178fd461@localhost> #3443: GHCi produces a panic on printing and escaped GBP sign, and won't print gbp sign either -----------------------+---------------------------------------------------- Reporter: yb2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.4 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => duplicate Comment: 6.12.1 will have Unicode support in the IO library which mostly fixes this problem. The rest is fixed by #3398. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 08:03:50 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 07:43:52 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.cabcb22c6f6c44ea12df9961e4d02dc2@localhost> #3320: Parallel program crashes using GHC 6.11 under OS X -------------------------------+-------------------------------------------- Reporter: sebf | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by simonmar): Replying to [comment:3 igloo]: > I can reproduce it, but not if I link with -debug as well. Oh joy. Could you try with `+RTS -g1`. Also, sometimes when the `-debug` flag makes a crash go away, I have some luck compiling the RTS with `-optc-g` but without `-DDEBUG`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 08:36:59 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 08:17:01 2009 Subject: [GHC] #3430: ghci crashes In-Reply-To: <051.7288f438eac16623dc959303accfb5cc@localhost> References: <051.7288f438eac16623dc959303accfb5cc@localhost> Message-ID: <060.543ae297493fbf750d529659901b49f5@localhost> #3430: ghci crashes ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: worksforme Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => worksforme Comment: I didn't manage to repeat it. Tried on x86/Linux with 6.10.4, x86_64/Linux with 6.10.3 and HEAD (today's), Windows with 6.10.1, 6.10.2, 6.10.4 and HEAD (today's). In all cases I get "HLint.hs: argument here" and exit(1). So we'll just have to hope this bug pops up again in a more repeatable form... -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 09:41:49 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 09:21:55 2009 Subject: [GHC] #3441: readProcess ... (exit 11): failed In-Reply-To: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> References: <045.8b36c40db2200ba55ce3ac655baf5782@localhost> Message-ID: <054.a0e0fb0d9a99263a0990c0f48be12622@localhost> #3441: readProcess ... (exit 11): failed ------------------------------------+--------------------------------------- Reporter: Andriy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/process | Version: 6.10.3 Severity: major | Resolution: worksforme Keywords: readProcess exit 11 | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ------------------------------------+--------------------------------------- Comment (by Andriy): Simon, thanks a lot for looking into this. I added "ulimit -c unlimited" to the main shell script. If this is really a segfault I hope the next failure will generate core dump. Andriy -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 09:53:22 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 09:33:23 2009 Subject: [GHC] #3417: Data.Array.IO.hGetArray should be implemented. In-Reply-To: <044.4fe87e98cecbfb577c4777a984e7c8b6@localhost> References: <044.4fe87e98cecbfb577c4777a984e7c8b6@localhost> Message-ID: <053.a7dec15ae3643c356825813bdb18f066@localhost> #3417: Data.Array.IO.hGetArray should be implemented. ----------------------------------+----------------------------------------- Reporter: int-e | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: libraries (other) | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Comment (by int-e): At least for gtk2hs, such a small loss in performance is perfectly acceptable. The code is only used at build time anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 10:48:02 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 10:28:12 2009 Subject: [GHC] #3374: Profiling libraries are not installed In-Reply-To: <046.8d56386f212a852d9f6e4247f2bbcfa0@localhost> References: <046.8d56386f212a852d9f6e4247f2bbcfa0@localhost> Message-ID: <055.1069760369b8f37d13f8978cd4e6fbbe@localhost> #3374: Profiling libraries are not installed -------------------------------+-------------------------------------------- Reporter: scsibug | 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 fasta): * cc: ron@gamr7.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 11:04:03 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 10:44:05 2009 Subject: [GHC] #3398: Unicode output in GHC In-Reply-To: <047.de64825b187e674ad618957169425649@localhost> References: <047.de64825b187e674ad618957169425649@localhost> Message-ID: <056.eb8ff5d2397ed91fba5b7f8fd6cb051f@localhost> #3398: Unicode output in GHC ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: 2816 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by judahj): I don't think that'll fix it, unfortunately. For example, using non- interactive ghc-6.11 we get similar issues: {{{ $ ghc-stage2 --make foo?/Foo.hs [1 of 1] Compiling Foo ( foo??/Foo.hs, foo??/Foo.o ) foo??/Foo.hs:3:0: The type signature for `?' lacks an accompanying binding }}} As I understand it, the code path is: - getArgs returns a !FilePath with the '?' encoded as two separate 8-bit Chars; the !FilePath is stored as-is in the !ModLocation. - The status message calls showModMsg, which takes the !FilePath and sticks it in the middle of a String message, still with two undecoded bytes. - That String is eventually printed to a text Handle, causing those two bytes to be incorrectly re-encoded. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 12:58:38 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 12:38:38 2009 Subject: [GHC] #3444: index out of range during 'make install' In-Reply-To: <045.b400afa30ed53cc553630bb3ba81925e@localhost> References: <045.b400afa30ed53cc553630bb3ba81925e@localhost> Message-ID: <054.f5fa36803a9c267efc2a401eb892676e@localhost> #3444: index out of range during 'make install' ------------------------------+--------------------------------------------- Reporter: judahj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.11 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | ------------------------------+--------------------------------------------- Changes (by judahj): * status: new => closed * resolution: => invalid Comment: I did run `make clean`, but it didn't fix the problem. However, after darcs getting a new local copy everything works fine; so it was probably an issue with my build tree. Thanks for looking into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 20 18:18:32 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 17:58:38 2009 Subject: [GHC] #3445: ":show modules" Panic Message-ID: <047.8dc73ed3d30a03da6b5eab3731690ab3@localhost> #3445: ":show modules" Panic -----------------------+---------------------------------------------------- Reporter: sfjohnso | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.6 | Severity: normal Keywords: impossible | Testcase: Os: Windows | Architecture: Unknown/Multiple -----------------------+---------------------------------------------------- While working exercises in "Haskell Road to Logic, Maths", I got this message in response to a :show modules" command: Prelude> :show modules SetEq ( SetEq.hs, interpreted ) : panic! (the 'impossible' happened) (GHC version 6.6 for i386-unknown-mingw32): missing linkable 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 Aug 20 21:26:11 2009 From: trac at galois.com (GHC) Date: Thu Aug 20 21:06:17 2009 Subject: [GHC] #3374: Profiling libraries are not installed In-Reply-To: <046.8d56386f212a852d9f6e4247f2bbcfa0@localhost> References: <046.8d56386f212a852d9f6e4247f2bbcfa0@localhost> Message-ID: <055.9b90f0ad3536db75376634fdc3d084cb@localhost> #3374: Profiling libraries are not installed -------------------------------+-------------------------------------------- Reporter: scsibug | Owner: 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 by: {{{ Thu Aug 20 10:37:07 PDT 2009 Ian Lynagh * Fix library installation; fixes #3374 When configuring packages, enable library profiling and shared libraries based on the ways in GhcLibWays. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 21 05:59:49 2009 From: trac at galois.com (GHC) Date: Fri Aug 21 05:39:46 2009 Subject: [GHC] #3437: Optimizer creates space leak on simple code In-Reply-To: <044.cf82c0f7bc349e25c0be89c8ea166251@localhost> References: <044.cf82c0f7bc349e25c0be89c8ea166251@localhost> Message-ID: <053.e13cb94471f5735b477e6714c89474fb@localhost> #3437: Optimizer creates space leak on simple code -------------------------------------------+-------------------------------- Reporter: lilac | Owner: Type: run-time performance bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: simplCore/should_run/T3437 | Os: Linux Architecture: x86_64 (amd64) | -------------------------------------------+-------------------------------- Changes (by simonpj): * testcase: => simplCore/should_run/T3437 * status: new => closed * resolution: => fixed * type: bug => run-time performance bug Comment: Done! Fixed by {{{ Fri Aug 21 10:52:51 BST 2009 simonpj@microsoft.com * Fix Trac #3437: strictness of specialised functions 'lilac' helpful pin-pointed a space leak that was due to a specialised function being insufficiently strict. Here's the new comment in SpecConstr: Note [Transfer strictness] ~~~~~~~~~~~~~~~~~~~~~~~~~~ We must transfer strictness information from the original function to the specialised one. Suppose, for example f has strictness SS and a RULE f (a:as) b = f_spec a as b Now we want f_spec to have strictess LLS, otherwise we'll use call-by- need when calling f_spec instead of call-by-value. And that can result in unbounded worsening in space (cf the classic foldl vs foldl') See Trac #3437 for a good example. The function calcSpecStrictness performs the calculation. M ./compiler/specialise/SpecConstr.lhs +44 }}} Thank you for identifying the problem so precisely. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 21 06:10:34 2009 From: trac at galois.com (GHC) Date: Fri Aug 21 05:50:33 2009 Subject: [GHC] #3371: Spurious "Defined but not used" when using record wildcards In-Reply-To: <045.27d6fa5bd2fb93020be76adb054ad300@localhost> References: <045.27d6fa5bd2fb93020be76adb054ad300@localhost> Message-ID: <054.1fdf5d02364e2e6cb3348f571f7bf14e@localhost> #3371: Spurious "Defined but not used" when using record wildcards --------------------------------------------+------------------------------- Reporter: Baughn | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: minor | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: rename/should_compile/T3371 | Os: Unknown/Multiple Architecture: Unknown/Multiple | --------------------------------------------+------------------------------- Changes (by simonpj): * testcase: => rename/should_compile/T3371 * difficulty: => Unknown * status: new => closed * resolution: => fixed Comment: Good point. I fixed this, and some related stuff concerning named fields, with this patch: {{{ Thu Aug 20 13:34:43 BST 2009 simonpj@microsoft.com * Improvements to record puns, wildcards * Make C { A.a } work with punning, expanding to C { A.a = a } * Make it so that, with -fwarn-unused-matches, f (C {..}) = x does not complain about the bindings introduced by the "..". * Make -XRecordWildCards implies -XDisambiguateRecordFields. * Overall refactoring of RnPat, which had become very crufty. In particular, there is now a monad, CpsRn, private to RnPat, which deals with the cps-style plumbing. This is why so many lines of RnPat have changed. * Refactor the treatment of renaming of record fields into two passes - rnHsRecFields1, used both for patterns and expressions, which expands puns, wild-cards - a local renamer in RnPat for fields in patterns - a local renamer in RnExpr for fields in construction and update This make it all MUCH easier to understand * Improve documentation of record puns, wildcards, and disambiguation M ./compiler/basicTypes/RdrName.lhs -5 +9 M ./compiler/main/DynFlags.hs +6 M ./compiler/parser/RdrHsSyn.lhs -11 +4 M ./compiler/rename/RnBinds.lhs -6 +7 M ./compiler/rename/RnEnv.lhs -139 +124 M ./compiler/rename/RnExpr.lhs -6 +27 M ./compiler/rename/RnPat.lhs -384 +394 M ./compiler/rename/RnSource.lhs -5 +4 M ./compiler/rename/RnTypes.lhs -2 +2 M ./compiler/typecheck/TcEnv.lhs -2 +2 M ./compiler/typecheck/TcPat.lhs -1 +1 M ./docs/users_guide/glasgow_exts.xml -22 +92 }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 21 09:28:30 2009 From: trac at galois.com (GHC) Date: Fri Aug 21 09:08:31 2009 Subject: [GHC] #3446: Library enhancement request: Data.Maybe.justIf Message-ID: <046.53ef9f87c100b788b2226965284cdaf1@localhost> #3446: Library enhancement request: Data.Maybe.justIf -----------------------------+---------------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Hi, I found myself often writing the idiom "if a then Just v else Nothing". It can be nicely abbreviated by the function: {{{ justIf :: a -> Bool -> Just a justIf x True = Just x justIf x False = Nothing }}} Which would allow me to write the nicely write- and readable {{{v `justIf` a}}}. Asking on #haskell, I got positive feedback about this addition: {{{ nomeata, I'm all for it. my last project was *full* of that idiom }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 21 09:33:04 2009 From: trac at galois.com (GHC) Date: Fri Aug 21 09:13:01 2009 Subject: [GHC] #3446: Library enhancement request: Data.Maybe.justIf In-Reply-To: <046.53ef9f87c100b788b2226965284cdaf1@localhost> References: <046.53ef9f87c100b788b2226965284cdaf1@localhost> Message-ID: <055.96b1e501628b70ddba77b31ad1e2765f@localhost> #3446: Library enhancement request: Data.Maybe.justIf ------------------------------+--------------------------------------------- Reporter: nomeata | Owner: Type: feature request | 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 nomeata): Of course it should say {{{ justIf :: a -> Bool -> Maybe a justIf x True = Just x justIf x False = Nothing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 21 10:03:49 2009 From: trac at galois.com (GHC) Date: Fri Aug 21 09:43:46 2009 Subject: [GHC] #3446: Library enhancement request: Data.Maybe.justIf In-Reply-To: <046.53ef9f87c100b788b2226965284cdaf1@localhost> References: <046.53ef9f87c100b788b2226965284cdaf1@localhost> Message-ID: <055.3ad42e50c11a75ffcc4e03993c3368bc@localhost> #3446: Library enhancement request: Data.Maybe.justIf ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: Can you please make a [http://www.haskell.org/haskellwiki/Library_submissions library submissions proposal] for this? Given the timing of ICFP, I'd recommend end of September as a discussion deadline. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 21 11:12:27 2009 From: trac at galois.com (GHC) Date: Fri Aug 21 10:52:26 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.474be87d936b5e72a15a1f9a3ade5167@localhost> #3320: Parallel program crashes using GHC 6.11 under OS X -------------------------------+-------------------------------------------- Reporter: sebf | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by igloo): {{{ ian-lynaghs-macbook-pro:foo ian$ ./idfs +RTS -N3 Bus error ian-lynaghs-macbook-pro:foo ian$ ./idfs +RTS -N3 -g1 500 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 21 11:15:47 2009 From: trac at galois.com (GHC) Date: Fri Aug 21 10:55:45 2009 Subject: [GHC] #3424: Corrupt executable when compiling large do block for List monad In-Reply-To: <044.0e7bdc71d50ace8354623d9f560b19d9@localhost> References: <044.0e7bdc71d50ace8354623d9f560b19d9@localhost> Message-ID: <053.27b7ba4d472574f3b54e5264a9ba7395@localhost> #3424: Corrupt executable when compiling large do block for List monad -------------------------+-------------------------------------------------- Reporter: guest | Owner: simonmar Type: bug | Status: closed Priority: high | 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 * resolution: => fixed Comment: Fixed: {{{ Thu Aug 20 06:15:37 PDT 2009 Simon Marlow * Add a case for IND (and a comment). Fixes #3424, perhaps only partially. Thu Aug 20 07:43:08 PDT 2009 Simon Marlow * Relax the assumption that all objects fit in a single block (#3424) }}} Interesting that it took ~10 years for anyone to find this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 21 11:33:09 2009 From: trac at galois.com (GHC) Date: Fri Aug 21 11:13:07 2009 Subject: [GHC] #3447: Class restrictions on type instances Message-ID: <048.c99d50265c5dd4c44f2bab6be9ab501e@localhost> #3447: Class restrictions on type instances -----------------------------+---------------------------------------------- Reporter: LysikovVV | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I'm using type families to implement bools and integers on type level. There is a class BoolT with with two instances and type families representing usual boolean functions, e.g. NotT. By semantics of NotT, implication (BoolT a) => (BoolT (NotT a)) holds, but I cannot specify this to compiler, and using BoolT with NotT is painful. So I think there must be syntactic construction to restrict type family instances to some class, something like {{{ type family NotT a with (BoolT a) => (BoolT (NotT a)) }}} or {{{ class BoolT a where type NotT a with BoolT (NotT a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 21 13:20:43 2009 From: trac at galois.com (GHC) Date: Fri Aug 21 13:00:44 2009 Subject: [GHC] #3446: Library enhancement request: Data.Maybe.justIf In-Reply-To: <046.53ef9f87c100b788b2226965284cdaf1@localhost> References: <046.53ef9f87c100b788b2226965284cdaf1@localhost> Message-ID: <055.9ab0b2789b3da6161f4f04757dc8f513@localhost> #3446: Library enhancement request: Data.Maybe.justIf ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: proposal | Status: reopened Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by nomeata): * status: closed => reopened * type: feature request => proposal * resolution: wontfix => Comment: Ok, darcs patch is sent, and references this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 21 13:46:17 2009 From: trac at galois.com (GHC) Date: Fri Aug 21 13:26:14 2009 Subject: [GHC] #3448: Error with .so files in HEAD snapshot distribution Message-ID: <043.a632d5d0fb8b0e327915fe8944a060e4@localhost> #3448: Error with .so files in HEAD snapshot distribution -------------------+-------------------------------------------------------- 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) -------------------+-------------------------------------------------------- Installing the ghc-6.11.20090818 binary snapshot for x86_64 fails at 'make install' time with: {{{ "inplace/bin/ghc-cabal" install .... .... Installing library in /home/dons/lib/ghc-6.11.20090818/ghc-prim-0.1.0.0 ghc-cabal: dist-install/build/libHSghc-prim-0.1.0.0-ghc6.11.20090818.so: does not exist }}} Meaning I am unable to install the snapshot. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 21 14:38:29 2009 From: trac at galois.com (GHC) Date: Fri Aug 21 14:18:28 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.9c196797f5b9e964efae157447019fa5@localhost> #3320: Parallel program crashes using GHC 6.11 under OS X -------------------------------+-------------------------------------------- Reporter: sebf | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Runtime System | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Comment (by igloo): Here's the end of a run with a slightly instrumented RTS: {{{ RELEASE_LOCK(0x801330) rts/Capability.c 644 Calling yieldCapability 2 with 0x801280 Called yieldCapability with 0x801280 RELEASE_LOCK(0x7009f8) rts/Capability.c 618 ACQUIRE_LOCK(0x8011f0) rts/Capability.c 622 RELEASE_LOCK(0x8011f0) rts/Capability.c 626 ACQUIRE_LOCK(0x7009f8) rts/Capability.c 613 RELEASE_LOCK(0x801330) rts/Capability.c 842 Calling yieldCapability 1 with 0x801140 Called yieldCapability with 0x801140 ACQUIRE_LOCK(0x2ca7e0) rts/Schedule.c 906 RELEASE_LOCK(0x2ca7e0) rts/Schedule.c 916 Garbage collecting ACQUIRE_LOCK(0x2cb8a0) rts/sm/GC.c 199 ACQUIRE_LOCK(0x2ca2a0) rts/Stable.c 325 RELEASE_LOCK(0x2cb8a0) rts/sm/GC.c 755 ACQUIRE_LOCK(0x2cb8a0) rts/sm/GC.c 757 RELEASE_LOCK(0x2cb8a0) rts/sm/GC.c 760 ACQUIRE_LOCK(0x2cb8a0) rts/sm/GC.c 763 RELEASE_LOCK(0x2ca2a0) rts/Stable.c 331 RELEASE_LOCK(0x2cb8a0) rts/sm/GC.c 812 Finished garbage collecting ACQUIRE_LOCK(0x8011f0) rts/Capability.c 534 RELEASE_LOCK(0x8011f0) rts/Capability.c 545 Calling yieldCapability 2 with 0x801140 ACQUIRE_LOCK(0x700ac8) rts/Capability.c 548 Calling yieldCapability 2 with 0x801280 Called yieldCapability with 0x801140 Called yieldCapability with 0xb0103000 Calling releaseCapabilityAndQueueWorker with 0x801140 Calling releaseCapabilityAndQueueWorker with 0xb0103000 ACQUIRE_LOCK(0x8011f0) rts/Capability.c 457 ACQUIRE_LOCK(0xb01030b0) rts/Capability.c 457 ACQUIRE_LOCK(0x700ac8) rts/Capability.c 350 Task is NULL! 0xb0103000 0xb01030b0 RELEASE_LOCK(0x700ac8) rts/Capability.c 356 RELEASE_LOCK(0x8011f0) rts/Capability.c 481 RELEASE_LOCK(0x700ac8) rts/Capability.c 553 ACQUIRE_LOCK(0x700be8) rts/Capability.c 613 ACQUIRE_LOCK(0x8011f0) rts/Capability.c 556 RELEASE_LOCK(0x8011f0) rts/Capability.c 566 Bus error }}} The {{{ Garbage collecting [...] Finished garbage collecting }}} are the start and end of `rts/sm/GC.c:GarbageCollect`, so it looks to me like we aren't supposed to be GCing when things go wrong. In particular, see these two lines: {{{ Calling yieldCapability 2 with 0x801280 [...] Called yieldCapability with 0xb0103000 }}} These are: {{{ if (prev_pending_gc) { do { debugTrace(DEBUG_sched, "someone else is trying to GC (%d)...", prev_pending_gc); ASSERT(cap); printf("Calling yieldCapability 2 with %p\n", cap); yieldCapability(&cap,task); } while (waiting_for_gc); return cap; // NOTE: task->cap might have changed here } }}} and {{{ void yieldCapability (Capability** pCap, Task *task) { Capability *cap = *pCap; printf("Called yieldCapability with %p\n", cap); }}} The {{{ Task is NULL! 0xb0103000 0xb01030b0 }}} is the point where the bus error actually happens: {{{ static void releaseCapabilityAndQueueWorker (Capability* cap USED_IF_THREADS) { Task *task; ACQUIRE_LOCK(&cap->lock); task = cap->running_task; if (task == NULL) { printf("Task is NULL! %p %p\n", cap, &cap->lock); fflush(stdout); } [...] if (!isBoundTask(task) && !task->stopped && !task->suspended_tso) { }}} which looks like a symptom of the corrupt cap. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 21 17:15:59 2009 From: trac at galois.com (GHC) Date: Fri Aug 21 16:55:57 2009 Subject: [GHC] #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work In-Reply-To: <042.bfabde61c4aa31a17887ff9436d679ab@localhost> References: <042.bfabde61c4aa31a17887ff9436d679ab@localhost> Message-ID: <051.3d0cd9abcf01f15bb4c4ff7e27effadb@localhost> #2850: GeneralizedNewtypeDeriving + TypeFamilies doesn't work ---------------------------------------------------+------------------------ Reporter: ajd | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: indexed_types/should_compile/T2850 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------------+------------------------ Changes (by simonpj): * testcase: => indexed_types/should_compile/T2850 * status: new => closed * resolution: => fixed Comment: Happily this seems OK in the HEAD (and hence 6.12). So I'll add a regression test and close the bug. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 21 17:17:16 2009 From: trac at galois.com (GHC) Date: Fri Aug 21 16:57:55 2009 Subject: [GHC] #3423: No match in record selector Var.tcTyVarDetails with ghc >= 6.10.2 In-Reply-To: <045.2396ec1e7c80b838e7d57390c1854284@localhost> References: <045.2396ec1e7c80b838e7d57390c1854284@localhost> Message-ID: <054.37867f4ca832d1aa7c5e39882408e962@localhost> #3423: No match in record selector Var.tcTyVarDetails with ghc >= 6.10.2 ---------------------------------------------------+------------------------ Reporter: morrow | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: indexed_types/should_compile/T3423 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------------------------+------------------------ Changes (by simonpj): * testcase: => indexed_types/should_compile/T3423 * difficulty: => Unknown * status: new => closed * resolution: => fixed Comment: Ah yes, excellent point thank you. A missed instantiation. {{{ Fri Aug 21 22:07:00 GMT Daylight Time 2009 simonpj@microsoft.com * Fix Trac #3423: missed instantiation for newtype-derived instances Somehow I'd forgotten to instantiate the coercion that is stored in a 'NewtypeDerived' constructor in an InstInfo. The necessary code is in TcInstDcls.tc_inst_decl2. The result was ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for x86_64-unknown-linux): No match in record selector Var.tcTyVarDetails because we were looking at an (uninstantiated) TyVar instead of an (instantiated) TcTyVar. }}} Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 21 18:27:14 2009 From: trac at galois.com (GHC) Date: Fri Aug 21 18:07:13 2009 Subject: [GHC] #3449: Unavoidable "unused bindings" warnings in boot files Message-ID: <047.a09ad2532f7f9a89f339f29841e6c44b@localhost> #3449: Unavoidable "unused bindings" warnings in boot files -----------------------------+---------------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: minor Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The {{{-fwarn-unused-binds}}} flag produces warnings for bindings that cannot, in fact, be deleted from hs-boot files. It would be nice not to see these warnings. Definitions in .hs-boot files must match the definitions in .hs files, but .hs-boot files don't necessarily use or export the same identifiers that the .hs file does. Running {{{ghc -c A.hs-boot -fwarn-unused-binds}}} produces warnings for this hs-boot file, regardless of whether the identifiers are exported in the hs file. {{{ {- A.hs-boot -} {-# OPTIONS_GHC -XTypeFamilies #-} -- to demonstrate associated type warnings module A(Foo, HasFoo) where newtype Foo = Foo {unFoo :: Int} class HasFoo a where data Foo' a getFoo :: a -> Foo }}} For identifiers defined on the RHS of an equal sign or 'where'---namely, data constructors, field names, class methods, and associated types---I suggest silencing unused binding warnings in the boot file. The rationale is that you should be allowed to copy an entire definition into the boot file, and regard a binding as unused only if it appears unused in the .hs file. See also #3283. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 21 20:28:39 2009 From: trac at galois.com (GHC) Date: Fri Aug 21 20:08:38 2009 Subject: [GHC] #2798: Enable "rec" keyword when RecursiveDo is enabled? In-Reply-To: <047.c01de827ffb9a59aafb72de68ac54369@localhost> References: <047.c01de827ffb9a59aafb72de68ac54369@localhost> Message-ID: <056.3ce642095ec8c299ac511c8293129861@localhost> #2798: Enable "rec" keyword when RecursiveDo is enabled? ---------------------------------+------------------------------------------ Reporter: nominolo | Owner: igloo Type: task | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * owner: => igloo -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 22 16:56:20 2009 From: trac at galois.com (GHC) Date: Sat Aug 22 16:36:17 2009 Subject: [GHC] #3450: Parser error on Message-ID: <047.7e6421a3e69b908a2871062488c80158@localhost> #3450: Parser error on ---------------------+------------------------------------------------------ Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Parser) Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ---------------------+------------------------------------------------------ Create a single-line file x.hs with contents {-# LANGUAGE -FlexibleInstances #-} And run ghci x.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(2) went past eof token Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug If the dash is removed, {-# LANGUAGE FlexibleInstances #-} the file parses properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 22 16:56:52 2009 From: trac at galois.com (GHC) Date: Sat Aug 22 16:36:47 2009 Subject: [GHC] #3450: Parser error on {-# LANGUAGE -FlexibleInstances? #-} In-Reply-To: <047.7e6421a3e69b908a2871062488c80158@localhost> References: <047.7e6421a3e69b908a2871062488c80158@localhost> Message-ID: <056.4f94724a4349b1cfc0a641b53a435a1a@localhost> #3450: Parser error on {-# LANGUAGE -FlexibleInstances? #-} -------------------------------+-------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Changes (by monoidal): * summary: Parser error on => Parser error on {-# LANGUAGE -FlexibleInstances? #-} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 22 17:04:33 2009 From: trac at galois.com (GHC) Date: Sat Aug 22 16:44:28 2009 Subject: [GHC] #3450: Parser error on {-# LANGUAGE - #-} In-Reply-To: <047.7e6421a3e69b908a2871062488c80158@localhost> References: <047.7e6421a3e69b908a2871062488c80158@localhost> Message-ID: <056.8a86e0d09b7cb03e65167b857c3f23aa@localhost> #3450: Parser error on {-# LANGUAGE - #-} -------------------------------+-------------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- Changes (by monoidal): * summary: Parser error on {-# LANGUAGE -FlexibleInstances? #-} => Parser error on {-# LANGUAGE - #-} Comment: Even simpler way: {-# LANGUAGE - #-} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 22 17:17:32 2009 From: trac at galois.com (GHC) Date: Sat Aug 22 16:57:27 2009 Subject: [GHC] #3450: Parser error on {-# LANGUAGE - #-} In-Reply-To: <047.7e6421a3e69b908a2871062488c80158@localhost> References: <047.7e6421a3e69b908a2871062488c80158@localhost> Message-ID: <056.b05247b1cb11f8c72b8bd01320bdb492@localhost> #3450: Parser error on {-# LANGUAGE - #-} ----------------------------------+----------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.4 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. This has already been fixed in the HEAD (#3153). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 22 20:50:52 2009 From: trac at galois.com (GHC) Date: Sat Aug 22 20:30:47 2009 Subject: [GHC] #3451: HsFFI.h import doesn't work as installed Message-ID: <044.96cd9f1ba1f8fbdefd0037f9ec6aeee0@localhost> #3451: HsFFI.h import doesn't work as installed -----------------------------+---------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: x86_64 (amd64) -----------------------------+---------------------------------------------- After building GHC head I tried to install the 'network' package (version in darcs head). I got compile errors from including HsFFI.h trying to include 'stg/Types.h' which wasn't installed by the installer (that is, "make install"). I then copied the 'includes/stg' directory from the build directory over into the directory where GHC had been installed, and everything started working. This was running on Linux, amd64. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 01:24:31 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 01:04:23 2009 Subject: [GHC] #3452: Show type of most recent expression in GHCi Message-ID: <042.b310a33072e5824be86a04c5e7b9cf0d@localhost> #3452: Show type of most recent expression in GHCi -----------------------------+---------------------------------------------- Reporter: ozy | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Currently, any expression resulting in a value with no `Show` instance results in an error message. This is confusing for new users (especially if they don't yet understand typeclasses) and overly verbose for experienced users. Instead, the REPL should simply display the type of the expression, as if the user had used `:t`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 04:56:45 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 04:36:49 2009 Subject: [GHC] #3453: Add "check" function to Control.Monad Message-ID: <051.70447cf639e8d603bf0c4d32cf8a4684@localhost> #3453: Add "check" function 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 -----------------------------+---------------------------------------------- Generalisation of "guard". check (not . isSpace) 'c' == Just 'c' check (not . isSpace) ' ' == Nothing See example in attached darcs patch -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 05:01:28 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 04:41:25 2009 Subject: [GHC] #3453: Add "check" function to Control.Monad In-Reply-To: <051.70447cf639e8d603bf0c4d32cf8a4684@localhost> References: <051.70447cf639e8d603bf0c4d32cf8a4684@localhost> Message-ID: <060.cf00f6010ed44a9438457ae2bf025ce8@localhost> #3453: Add "check" function to Control.Monad ------------------------------+--------------------------------------------- Reporter: JonFairbairn | 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 JonFairbairn): Timescale: 14 days. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 08:35:39 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 08:15:33 2009 Subject: [GHC] #3305: panic message "impossible happened" loadobj: failed loading SOE packages and trying to run main1 in Animation.lhs In-Reply-To: <051.558ce25b2ee78a9e988e8e8d099ba07d@localhost> References: <051.558ce25b2ee78a9e988e8e8d099ba07d@localhost> Message-ID: <060.991a90684d2bf42b2ce9a8856993cf55@localhost> #3305: panic message "impossible happened" loadobj: failed loading SOE packages and trying to run main1 in Animation.lhs -----------------------------+---------------------------------------------- Reporter: don vinnedge | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => invalid Comment: No response from submitter, so closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 08:40:27 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 08:20:25 2009 Subject: [GHC] #3310: `show BlockedIndefinitely` should not equal `show BlockedOnDeadMVar` In-Reply-To: <045.d15d45f5a8175ad9674d39f51d4c22e6@localhost> References: <045.d15d45f5a8175ad9674d39f51d4c22e6@localhost> Message-ID: <054.1f75792513510c5143878403e4df2b95@localhost> #3310: `show BlockedIndefinitely` should not equal `show BlockedOnDeadMVar` ---------------------------------+------------------------------------------ Reporter: enolan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 08:43:14 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 08:23:32 2009 Subject: [GHC] #3329: Errors Building 6.10.3 on NetBSD 4.0 In-Reply-To: <042.a79f04c63210b2fd7097ecd4b82fa86e@localhost> References: <042.a79f04c63210b2fd7097ecd4b82fa86e@localhost> Message-ID: <051.653f09feb926d0a812c46e67efba7657@localhost> #3329: Errors Building 6.10.3 on NetBSD 4.0 -------------------------------+-------------------------------------------- Reporter: cjs | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 09:04:01 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 08:43:55 2009 Subject: [GHC] #3349: poor responsiveness of ghci In-Reply-To: <051.8d710dd8a00a93e9e65fe6cedca146fa@localhost> References: <051.8d710dd8a00a93e9e65fe6cedca146fa@localhost> Message-ID: <060.b3efac77b832d7594e3439b89a65e551@localhost> #3349: poor responsiveness of ghci -----------------------------------------+---------------------------------- Reporter: dynamic-wind | Owner: Type: run-time performance bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: No response from submitter, so assuming this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 09:13:48 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 08:53:41 2009 Subject: [GHC] #3350: GHC doesn't compile on Mac OS X 10.4 (Tiger) via MacPorts In-Reply-To: <044.ceb05e62d959d517126b90f70525a764@localhost> References: <044.ceb05e62d959d517126b90f70525a764@localhost> Message-ID: <053.64f62180815773a06ef5302ad4ec0f2a@localhost> #3350: GHC doesn't compile on Mac OS X 10.4 (Tiger) via MacPorts --------------------------------------------+------------------------------- Reporter: indil | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Build System | Version: 6.10.3 Severity: blocker | Resolution: Keywords: install, error, gmp, linker | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | --------------------------------------------+------------------------------- Changes (by igloo): * milestone: => 6.12.1 Comment: This looks like a MacPorts issue. Does anyone know more? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 09:16:23 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 08:56:16 2009 Subject: [GHC] #3372: Allow for multiple linker instances In-Reply-To: <049.b54da97038a1da97405ea7b63a99f067@localhost> References: <049.b54da97038a1da97405ea7b63a99f067@localhost> Message-ID: <058.11003db327e6cefedb859e7550407a65@localhost> #3372: Allow for multiple linker instances ---------------------------------+------------------------------------------ Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 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 Sun Aug 23 09:22:38 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 09:02:31 2009 Subject: [GHC] #3373: GHC API is not thread safe In-Reply-To: <049.05da201065b7c5ade7dcf13301c3e81b@localhost> References: <049.05da201065b7c5ade7dcf13301c3e81b@localhost> Message-ID: <058.86ddec369cbd6ef5dcd52a5cb56ff0cd@localhost> #3373: GHC API is not thread safe ---------------------------------+------------------------------------------ Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.1 Component: GHC API | Version: 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 Sun Aug 23 09:28:25 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 09:08:31 2009 Subject: [GHC] #3380: [Patch] Support implicit concatenation in list comprehensions In-Reply-To: <053.31375e41dd51007462e20df85979f732@localhost> References: <053.31375e41dd51007462e20df85979f732@localhost> Message-ID: <062.28dc0a963fbabcbe078de101cadb5b10@localhost> #3380: [Patch] Support implicit concatenation in list comprehensions ---------------------------------+------------------------------------------ Reporter: batterseapower | 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): * milestone: => 6.14.1 Comment: Need to work out what the consensus of the thread was. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 09:28:57 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 09:08:57 2009 Subject: [GHC] #3389: CPP strips out C-style comments In-Reply-To: <047.ed7a4a8a5db27a5742ce2338e8823121@localhost> References: <047.ed7a4a8a5db27a5742ce2338e8823121@localhost> Message-ID: <056.45b08d67f9a5efe87625b5228a70cac1@localhost> #3389: CPP strips out C-style comments ---------------------------------+------------------------------------------ Reporter: nominolo | Owner: Type: feature request | Status: reopened Priority: normal | Milestone: 6.14.1 Component: Driver | Version: 6.10.2 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 Sun Aug 23 09:32:59 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 09:12:55 2009 Subject: [GHC] #3397: :step hangs when -fbreak-on-exception is set In-Reply-To: <045.0c0cb085f9bbd1ffc018c8ff9c9523d7@localhost> References: <045.0c0cb085f9bbd1ffc018c8ff9c9523d7@localhost> Message-ID: <054.da3b8cb72a7ee36b00d6de82ed98c6ad@localhost> #3397: :step hangs when -fbreak-on-exception is set -----------------------+---------------------------------------------------- Reporter: hamish | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14 branch Component: GHCi | Version: 6.10.3 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: x86 | -----------------------+---------------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.14 branch Comment: A minimal test case would be great, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 09:33:15 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 09:13:13 2009 Subject: [GHC] #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} In-Reply-To: <043.61bcbfbf5cb528673d0b1d82854dcbb9@localhost> References: <043.61bcbfbf5cb528673d0b1d82854dcbb9@localhost> Message-ID: <052.e77765cdb113baf8a3b3813f2e85d437@localhost> #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} ---------------------------------+------------------------------------------ Reporter: iago | 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 Sun Aug 23 09:35:58 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 09:15:49 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.a4df52a4c21cda0fd6fe9b1c0e33b62b@localhost> #3403: linear stack usage where constant stack usage expected ---------------------------------+------------------------------------------ Reporter: igloo | 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 Sun Aug 23 09:37:05 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 09:16:58 2009 Subject: [GHC] #3404: Strictness analysis bug with Double In-Reply-To: <046.d8394ff39f5a8fb2e1c2ff08cf3f0634@localhost> References: <046.d8394ff39f5a8fb2e1c2ff08cf3f0634@localhost> Message-ID: <055.c86df58037fb21a2d757e21d3011ed71@localhost> #3404: Strictness analysis bug with Double ---------------------------------+------------------------------------------ Reporter: lpsmith | 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 Sun Aug 23 09:39:08 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 09:18:59 2009 Subject: [GHC] #3406: 'impossible' happened while messing around with ScopedTypeVariables In-Reply-To: <044.9724012c5b1b2098374ba8fb8be5fa12@localhost> References: <044.9724012c5b1b2098374ba8fb8be5fa12@localhost> Message-ID: <053.c71dd436ca9d151bad9f229484022056@localhost> #3406: 'impossible' happened while messing around with ScopedTypeVariables -----------------------------------+---------------------------------------- Reporter: RyanN | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: ScopedTypeVariabes | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -----------------------------------+---------------------------------------- Old description: > The attached bug.hs was an (incorrect) intermediate step on my way to > figuring out how to make a form of heterogeneous collections using > existential types. > > I had just switched on ScopedTypeVariables when I ran into this problem: > > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.3 for x86_64-unknown-linux): > readFilledBox a{tv ary} [box] > > I tested it on 6.10.1 and 6.10.3 (both got the same error). > I ran it on various flavors of Redhat Enterprise/CentOs. > > I also ran into the same crash using 6.8.2 on an 32 bit ubuntu machine, > as well as 6.8.2 on a 64 bit ubuntu machine. > > -Ryan New description: The attached bug.hs was an (incorrect) intermediate step on my way to figuring out how to make a form of heterogeneous collections using existential types. I had just switched on ScopedTypeVariables when I ran into this problem: {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.3 for x86_64-unknown-linux): readFilledBox a{tv ary} [box] }}} I tested it on 6.10.1 and 6.10.3 (both got the same error). I ran it on various flavors of Redhat Enterprise/CentOs. I also ran into the same crash using 6.8.2 on an 32 bit ubuntu machine, as well as 6.8.2 on a 64 bit ubuntu machine. -Ryan -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 09:40:20 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 09:20:11 2009 Subject: [GHC] #3406: 'impossible' happened while messing around with ScopedTypeVariables In-Reply-To: <044.9724012c5b1b2098374ba8fb8be5fa12@localhost> References: <044.9724012c5b1b2098374ba8fb8be5fa12@localhost> Message-ID: <053.3a634d3339f6f3c991764f515b7a0465@localhost> #3406: 'impossible' happened while messing around with ScopedTypeVariables -----------------------------------+---------------------------------------- Reporter: RyanN | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: Keywords: ScopedTypeVariabes | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -----------------------------------+---------------------------------------- Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 09:47:19 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 09:27:15 2009 Subject: [GHC] #3407: GHC.Prim documentation should mention GHC.Exts! In-Reply-To: <044.b2bcc86bcf34543dca950728f9a46ba1@localhost> References: <044.b2bcc86bcf34543dca950728f9a46ba1@localhost> Message-ID: <053.9d8c80900990210469f09736b1c54c28@localhost> #3407: GHC.Prim documentation should mention GHC.Exts! ---------------------------------+------------------------------------------ Reporter: RyanN | 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 * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 09:48:16 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 09:28:09 2009 Subject: [GHC] #3413: configure fails when generated with debian's autoconf 2.64-1 from unstable In-Reply-To: <051.28cd8daefa9e15f72864e5e7a841f7e1@localhost> References: <051.28cd8daefa9e15f72864e5e7a841f7e1@localhost> Message-ID: <060.1b63326cb38f3be0490519725a5f4668@localhost> #3413: configure fails when generated with debian's autoconf 2.64-1 from unstable ---------------------------------+------------------------------------------ Reporter: explicitcall | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.11 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: This patch has now also been applied. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 09:58:18 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 09:38:13 2009 Subject: [GHC] #3416: maximumBy uses too much stack In-Reply-To: <046.92a18780aff581cd9cc2254f3d845a56@localhost> References: <046.92a18780aff581cd9cc2254f3d845a56@localhost> Message-ID: <055.a7accab7a5f1e4b9f70d7d730d667753@localhost> #3416: maximumBy uses too much stack ---------------------------------+------------------------------------------ Reporter: bdonlan | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: This definition is not equivalent, e.g. compare `z1` and `z2` in {{{ import Data.List maximumBy' :: (a -> a -> Ordering) -> [a] -> a maximumBy' _ [] = error "List.maximumBy: empty list" maximumBy' cmp xs = foldl1' maxBy xs where maxBy x y = case cmp x y of GT -> x _ -> y f _ _ = LT z1 = maximumBy f [undefined, undefined, 1] z2 = maximumBy' f [undefined, undefined, 1] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 10:26:41 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 10:06:36 2009 Subject: [GHC] #3419: Incorrect "unnecessary import" warning In-Reply-To: <051.9b501dfeb3f845847a9d65fa1e7b4552@localhost> References: <051.9b501dfeb3f845847a9d65fa1e7b4552@localhost> Message-ID: <060.2cdda6f7662e7f191b4c5d4898c9fdab@localhost> #3419: Incorrect "unnecessary import" warning ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.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.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 10:26:41 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 10:06:38 2009 Subject: [GHC] #3425: compileToCoreModule: ghc: panic! (the 'impossible' happened) In-Reply-To: <043.832f4b8a68b35787dd3f11dce0ad982a@localhost> References: <043.832f4b8a68b35787dd3f11dce0ad982a@localhost> Message-ID: <052.2a3aefe17c1ff8fb7a6c161c94927d56@localhost> #3425: compileToCoreModule: ghc: panic! (the 'impossible' happened) -------------------------------+-------------------------------------------- Reporter: iago | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.12.1 Component: GHC API | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 10:30:10 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 10:10:05 2009 Subject: [GHC] #3428: Wrong pragma parsing In-Reply-To: <044.6fff3c68b090c532da2af6f966b67158@localhost> References: <044.6fff3c68b090c532da2af6f966b67158@localhost> Message-ID: <053.66aaac427999d62f46a9d58861d200fc@localhost> #3428: Wrong pragma parsing ----------------------------------+----------------------------------------- Reporter: boris | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: pragma | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | ----------------------------------+----------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. It looks like this is already fixed in the HEAD: {{{ $ ghci a.hs GHCi, version 6.11.20090821: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. [1 of 1] Compiling TestHS ( a.hs, interpreted ) a.hs:5:15: Not a data constructor: `forall' Perhaps you intended to use -XExistentialQuantification Failed, modules loaded: none. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 10:37:16 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 10:17:14 2009 Subject: [GHC] #3454: ghci freezes on failed pattern match in recursive list comprehension Message-ID: <047.12c63ec3b1fb5aa6f099c62325850def@localhost> #3454: ghci freezes on failed pattern match in recursive list comprehension -----------------------------+---------------------------------------------- Reporter: Syzygies | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The following freezes ghci (top shows no resources consumed): {{{ Prelude> let xs = [1..5] : [ xt | (_:xt) <- xs ] in take 7 xs [[1,2,3,4,5],[2,3,4,5],[3,4,5],[4,5],[5],[] }}} This is not the same issue as [http://hackage.haskell.org/trac/ghc/ticket/3053] (closed, invalid) as there are no elements to filter. (This may be a well-known black hole, but not to me; I was hoping a similar list would just terminate, trying to avoid the Nothing case boilerplate in an unfoldl.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 10:52:47 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 10:32:41 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.507450defe4132605140ba45edf6d964@localhost> #3434: improve vi tags (add non-exported symbols, add tag kinds, add regex tags) ---------------------------------+------------------------------------------ Reporter: phercek | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.14.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): * difficulty: => Unknown * milestone: => 6.14.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 11:11:30 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 10:51:23 2009 Subject: [GHC] #3436: runtime: internal error: traverseWeakPtrList: not WEAK In-Reply-To: <050.705145ec7510c89b41279536e44ce954@localhost> References: <050.705145ec7510c89b41279536e44ce954@localhost> Message-ID: <059.56820250f57a2b2ecb008bb0d2acba94@localhost> #3436: runtime: internal error: traverseWeakPtrList: not WEAK -------------------------------+-------------------------------------------- Reporter: sannysanoff | Owner: 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: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: => 6.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 11:11:43 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 10:51:43 2009 Subject: [GHC] #3445: ":show modules" Panic In-Reply-To: <047.8dc73ed3d30a03da6b5eab3731690ab3@localhost> References: <047.8dc73ed3d30a03da6b5eab3731690ab3@localhost> Message-ID: <056.1384c1b5efdddb8261d459bf05125c0d@localhost> #3445: ":show modules" Panic ---------------------------------+------------------------------------------ Reporter: sfjohnso | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.6 Severity: normal | Resolution: Keywords: impossible | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown Old description: > While working exercises in "Haskell Road to Logic, Maths", I got this > message in response to a :show modules" command: > > Prelude> :show modules > SetEq ( SetEq.hs, interpreted ) > : panic! (the 'impossible' happened) > (GHC version 6.6 for i386-unknown-mingw32): > missing linkable > > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug New description: While working exercises in "Haskell Road to Logic, Maths", I got this message in response to a :show modules" command: {{{ Prelude> :show modules SetEq ( SetEq.hs, interpreted ) : panic! (the 'impossible' happened) (GHC version 6.6 for i386-unknown-mingw32): missing linkable 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 Sun Aug 23 11:16:58 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 10:56:53 2009 Subject: [GHC] #3446: Library enhancement request: Data.Maybe.justIf In-Reply-To: <046.53ef9f87c100b788b2226965284cdaf1@localhost> References: <046.53ef9f87c100b788b2226965284cdaf1@localhost> Message-ID: <055.d398c285587930692a7126329bf80dd6@localhost> #3446: Library enhancement request: Data.Maybe.justIf ---------------------------------+------------------------------------------ Reporter: nomeata | Owner: Type: proposal | Status: reopened 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): * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 11:27:29 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 11:07:22 2009 Subject: [GHC] #3447: Class restrictions on type instances In-Reply-To: <048.c99d50265c5dd4c44f2bab6be9ab501e@localhost> References: <048.c99d50265c5dd4c44f2bab6be9ab501e@localhost> Message-ID: <057.f873ffc9c7ddc3953c3890e1cf25ef5f@localhost> #3447: Class restrictions on type instances ---------------------------------+------------------------------------------ Reporter: LysikovVV | 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 Sun Aug 23 11:28:29 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 11:08:23 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.50fd49db4ad468ef85b55ba03cbb72b4@localhost> #3451: HsFFI.h import doesn't work as installed -------------------------------+-------------------------------------------- Reporter: guest | 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: Unknown/Multiple Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 11:28:54 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 11:08:45 2009 Subject: [GHC] #3452: Show type of most recent expression in GHCi In-Reply-To: <042.b310a33072e5824be86a04c5e7b9cf0d@localhost> References: <042.b310a33072e5824be86a04c5e7b9cf0d@localhost> Message-ID: <051.cd7152f9f59706309a36943b36a75482@localhost> #3452: Show type of most recent expression in GHCi ---------------------------------+------------------------------------------ Reporter: ozy | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.12 branch Component: GHCi | 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 suggestion. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 11:28:58 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 11:08:51 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.4759987b8ed2e60d4be19d081c118295@localhost> #3448: Error with .so files in HEAD snapshot distribution -------------------------------+-------------------------------------------- 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 igloo): * priority: normal => high * difficulty: => Unknown * milestone: => 6.12.1 Comment: Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 11:29:44 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 11:09:40 2009 Subject: [GHC] #3453: Add "check" function to Control.Monad In-Reply-To: <051.70447cf639e8d603bf0c4d32cf8a4684@localhost> References: <051.70447cf639e8d603bf0c4d32cf8a4684@localhost> Message-ID: <060.d1c362dd27ee2e21699cc1e50a988c9e@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 | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => Not GHC Comment: I think 14 days is unrealistic given the timing relative to ICFP et al, and suggest end of Sept as the deadline. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 11:37:18 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 11:17:16 2009 Subject: [GHC] #3454: ghci freezes on failed pattern match in recursive list comprehension In-Reply-To: <047.12c63ec3b1fb5aa6f099c62325850def@localhost> References: <047.12c63ec3b1fb5aa6f099c62325850def@localhost> Message-ID: <056.493efd2424fe370ea2ec7ab5869ecd1e@localhost> #3454: ghci freezes on failed pattern match in recursive list comprehension ---------------------------------+------------------------------------------ Reporter: Syzygies | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => invalid Comment: The 7th element of cs is the tail of the first non-empty element after the 5th element of xs. The 6th element is [], so that one can't be used. So we need to look at whether or not the 7th element is []. Thus this is a black hole. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 11:42:11 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 11:22:10 2009 Subject: [GHC] #3449: Unavoidable "unused bindings" warnings in boot files In-Reply-To: <047.a09ad2532f7f9a89f339f29841e6c44b@localhost> References: <047.a09ad2532f7f9a89f339f29841e6c44b@localhost> Message-ID: <056.22453537f7234150f333429105476d77@localhost> #3449: Unavoidable "unused bindings" warnings in boot files ---------------------------------+------------------------------------------ Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.10.4 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 report. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 11:43:17 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 11:23:14 2009 Subject: [GHC] #3445: ":show modules" Panic In-Reply-To: <047.8dc73ed3d30a03da6b5eab3731690ab3@localhost> References: <047.8dc73ed3d30a03da6b5eab3731690ab3@localhost> Message-ID: <056.076a1265b4518bc4c44269ab3c6cdb15@localhost> #3445: ":show modules" Panic ---------------------------------+------------------------------------------ Reporter: sfjohnso | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.14.1 Component: GHCi | Version: 6.6 Severity: normal | Resolution: Keywords: impossible | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * milestone: => 6.14.1 Comment: Can you tell us how we can reproduce this, please? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 12:07:01 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 11:46:51 2009 Subject: [GHC] #3455: Add a setting to change how Unicode encoding errors are handled Message-ID: <045.14097b0341f39cd69e7f9d0c1052173e@localhost> #3455: Add a setting to change how Unicode encoding errors are handled -----------------------------+---------------------------------------------- Reporter: judahj | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I proposal that we augment ghc-6.12.1's support for Unicode Handles by adding the following functions to System.IO: {{{ hSetOnEncodingError :: Handle -> OnEncodingError -> IO () hGetOnEncodingError :: Handle -> IO OnEncodingError }}} as well as the enumeration `OnEncodingError` with three constructors: - `ThrowEncodingError`: Throw an exception at the first encoding or decoding error. - `SkipEncodingError`: Skip all invalid bytes or characters. - `TranslitEncodingError`: Replace undecodable bytes with u+FFFD, and unencodable characters with '?'. I have implemented this functionality in the attached patch. Haddock docs are here: http://code.haskell.org/~judah/new-io-docs/System-IO.html#23 The choice of error handler is orthogonal to the choice of encoder. Additionally, the same setting is used for both read and write modes. For portability, the handlers are written in pure Haskell rather than using GNU iconv's //TRANSLIT feature. Note that the text package, for example, provides more sophisticated error-handling options. However, I think the above choices are useful enough without making the API too complicated. Discussion deadline: September 9 Haddock docs: http://code.haskell.org/~judah/new-io-docs/System-IO.html#23 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 12:16:38 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 11:56:29 2009 Subject: [GHC] #3456: Add FilePath -> String decoder Message-ID: <045.a4a219f70c8b7f70a278b60a06ef7b94@localhost> #3456: Add FilePath -> String decoder -----------------------------+---------------------------------------------- Reporter: judahj | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Currently, !FilePaths on POSIX systems are represented as raw bytes in a String. When this last came up on the mailing list, the general consensus was to make !FilePath an abstract datatype representing paths as Strings on Windows and raw bytes on POSIX systems. However, such a change is sure to break some existing code. As a small step towards that goal, I propose adding the following two functions to the System.IO module: {{{ filePathToString :: FilePath -> IO String getFilePathToStringFunc :: IO (FilePath -> String) }}} This functionality is implemented in the attached patch; Haddock docs are here: http://code.haskell.org/~judah/new-io-docs/System- IO.html#v%3AfilePathToString On POSIX those functions decode according to the current locale, so they ought to be in the IO monad. I think that the latter function will be easier to integrate into existing pure code. On Windows, those functions are just `return` and `return id`, respectively, since GHC already treats !FilePaths as Strings on that platform. Discussion deadline: September 9 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 12:20:01 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 11:59:52 2009 Subject: [GHC] #3455: Add a setting to change how Unicode encoding errors are handled In-Reply-To: <045.14097b0341f39cd69e7f9d0c1052173e@localhost> References: <045.14097b0341f39cd69e7f9d0c1052173e@localhost> Message-ID: <054.57eaa1a76ef9452b938aa3ae5d70ece7@localhost> #3455: Add a setting to change how Unicode encoding errors are handled ---------------------------------+------------------------------------------ Reporter: judahj | 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 Sun Aug 23 12:20:27 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 12:00:26 2009 Subject: [GHC] #3456: Add FilePath -> String decoder In-Reply-To: <045.a4a219f70c8b7f70a278b60a06ef7b94@localhost> References: <045.a4a219f70c8b7f70a278b60a06ef7b94@localhost> Message-ID: <054.1c233ffc60bf8a9b64688b63bf1fa2e9@localhost> #3456: Add FilePath -> String decoder ---------------------------------+------------------------------------------ Reporter: judahj | 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 Sun Aug 23 15:32:00 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 15:11:52 2009 Subject: [GHC] #3416: Make maximumBy strict on the contents of its list In-Reply-To: <046.92a18780aff581cd9cc2254f3d845a56@localhost> References: <046.92a18780aff581cd9cc2254f3d845a56@localhost> Message-ID: <055.3d493b99afe17620f905d7c4cd93b119@localhost> #3416: Make maximumBy strict on the contents of its list ---------------------------------+------------------------------------------ Reporter: bdonlan | Owner: Type: proposal | Status: reopened Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by bdonlan): * status: closed => reopened * type: bug => proposal * resolution: wontfix => * summary: maximumBy uses too much stack => Make maximumBy strict on the contents of its list Comment: Is being able to use maximumBy on a constant comparison function considered to be the common case here? Is that even _useful_? It's true that the Haskell Report defines 'maximum' as being non-strict on its arguments. This is arguably a bug in the Report, however. Making maximumBy strict on the list elements does indeed change the behavior of maximumBy, but on most reasonable programs, this should have no visible effect. It is hard to imagine many cases in which a lazy version of maximumBy is necessary and desirable, and if it is, it's simple enough to create one. Note also that this issue has confused newbies to haskell before: http://stackoverflow.com/questions/1238883/running-a-compiled-haskell- program-getting-errors Why shouldn't we change the behavior of maximumBy (and similar functions such as minimumBy etc) to be strict on its arguments? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 15:49:35 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 15:29:24 2009 Subject: [GHC] #3457: Impossible to specify pragmas compatible with multiple ghc versions Message-ID: <045.b42d9302a58a1a0f28ab9ef59d342a90@localhost> #3457: Impossible to specify pragmas compatible with multiple ghc versions -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Component: Driver Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- Generally we wish to encourage modules to specify the language options they need directly in the module rather than putting them all in the .cabal file. For one thing it allows a simple `ghc --make` to work. The `bytestring` package works with ghc-6.4 through to 6.11. As far as I can see, it is impossible to specify the language options in a way that allows the package to build using `ghc --make` for a recent ghc version while at the same time building ''at all'' with an older ghc version. Consider the module `Data/ByteString.hs`. If we use: {{{ {-# LANGUAGE CPP, MagicHash, UnboxedTuples #-} }}} Then it works with `ghc-6.8 --make` and `ghc-6.10 --make` however now it cannot compile with `ghc-6.6` because that version does not grok the `MagicHash` and `UnboxedTuples` language options. We might think we could do: {{{ {-# LANGUAGE CPP #-} #if __GLASGOW_HASKELL__ >= 608 {-# LANGUAGE MagicHash, UnboxedTuples #-} #endif }}} Of course we will not expect this to work with `ghc-6.6 --make` but it will at least work with Cabal, because we can set things up so that Cabal passes `-fglasgow-exts`. However the above still will not work with `ghc --make` or even `ghc -cpp --make` because of the problem that ghc handles pragmas and CPP incorrectly (see #2800 and #2464). It holds onto the pragmas gathered before running cpp and assumes they will still be valid after the run of cpp, which of course is not true. The solution would be that after ghc runs cpp, it looks to see what the pragmas are, just as if it were starting from a fresh .hs file. In the mean time we cannot specify the language extensions in the `.hs` files and have it work. For `bytestring` we will just list the language extensions that we would specify if we could specify them. {{{ {-# LANGUAGE CPP #-} -- We cannot actually specify all the language pragmas, see ghc ticket #... -- If we could, these are what they would be: {- LANGUAGE MagicHash, UnboxedTuples -} }}} The way to test if the right ones are listed is to turn them back into pragmas and check `ghc --make`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 23 23:02:53 2009 From: trac at galois.com (GHC) Date: Sun Aug 23 22:42:57 2009 Subject: [GHC] #3220: type variables appearing only in type equality constraints are not generalized In-Reply-To: <044.61e1ea4a3856a3ecde009628edb5e8f4@localhost> References: <044.61e1ea4a3856a3ecde009628edb5e8f4@localhost> Message-ID: <053.9c2d6178aef4696b90ac8b5defe541a8@localhost> #3220: type variables appearing only in type equality constraints are not generalized ----------------------------------------+----------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler (Type checker) | Version: 6.10.2 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: T3220 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by chak): * testcase: => T3220 * status: new => closed * resolution: => fixed Comment: This problem has already been fixed in the HEAD. I added the example (slightly modified) as a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 24 03:37:30 2009 From: trac at galois.com (GHC) Date: Mon Aug 24 03:17:26 2009 Subject: [GHC] #3380: [Patch] Support implicit concatenation in list comprehensions In-Reply-To: <053.31375e41dd51007462e20df85979f732@localhost> References: <053.31375e41dd51007462e20df85979f732@localhost> Message-ID: <062.b20b619e812c2f2ad3c8b9024f2b26dd@localhost> #3380: [Patch] Support implicit concatenation in list comprehensions ---------------------------------+------------------------------------------ Reporter: batterseapower | Owner: Type: feature request | 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): * milestone: 6.14.1 => _|_ Comment: I've just read the thread. My impression is that support is luke-warm at best. I'll milestone this as "_|_" so that it's not forgotten, but meanwhile I am disinclined to take action. (Many responders were enthusiastic about tuple sections, which are indeed now implemented. Thanks for doing that.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 24 04:39:43 2009 From: trac at galois.com (GHC) Date: Mon Aug 24 04:19:35 2009 Subject: [GHC] #3436: runtime: internal error: traverseWeakPtrList: not WEAK In-Reply-To: <050.705145ec7510c89b41279536e44ce954@localhost> References: <050.705145ec7510c89b41279536e44ce954@localhost> Message-ID: <059.a036d80e020326e88afd558b9917a979@localhost> #3436: runtime: internal error: traverseWeakPtrList: not WEAK -------------------------------+-------------------------------------------- Reporter: sannysanoff | Owner: 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: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by sannysanoff): I tried the compilation again, and it segfaulted this time. I will try to run it third time with logging of memory usage (it works overnight). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 24 05:36:46 2009 From: trac at galois.com (GHC) Date: Mon Aug 24 05:16:35 2009 Subject: [GHC] #3458: Allocation where none should happen Message-ID: <044.0be4f1c62ed65da810608cbf23db2085@localhost> #3458: Allocation where none should happen -------------------+-------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.1 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) -------------------+-------------------------------------------------------- These two functions, according to profiling, do a lot of allocation: gen d r n m s p | r == ll = do pokeElemOff p n 0x0a gen d 0 (n+1) (m+1) s p | n == m = do pokeElemOff p n 0x0a return (s, if r == 0 then m else m+1) | otherwise = do let t = next s pokeElemOff p n (pick d t) gen d (r+1) (n+1) m t p ------------------------------------------------------------------------ pick (c, p) r = loop 0 where loop i = if r < unsafeAt p i then fromIntegral $ unsafeAt c i :: Word8 else loop (i+1) ------------------------------------------------------------------------ Core for pick: [GlobalId] [Arity 3 NoCafRefs Str: DmdType LLL] $w$spick_r3kC = \ (ww_s33o :: GHC.Prim.ByteArray#) (ww1_s33v :: GHC.Prim.ByteArray#) (ww2_s33A :: GHC.Prim.Word#) -> letrec { $wloop_s38I :: GHC.Prim.Int# -> GHC.Prim.Word# [Arity 1 Str: DmdType L] $wloop_s38I = \ (ww3_s339 :: GHC.Prim.Int#) -> __scc {pick main:Main !} case GHC.Prim.ltWord# ww2_s33A (GHC.Prim.indexWord32Array# ww1_s33v ww3_s339) of wild_X3O { GHC.Bool.False -> $wloop_s38I (GHC.Prim.+# ww3_s339 1); GHC.Bool.True -> GHC.Prim.narrow8Word# (GHC.Prim.indexWord32Array# ww_s33o ww3_s339) }; } in case __scc {pick main:Main} case $wloop_s38I 0 of ww3_s33d { __DEFAULT -> GHC.Word.W8# ww3_s33d } of ww3_s33D { GHC.Word.W8# ww4_s33E -> ww4_s33E } ------------------------------------------------------------------------ Core for gen (long): Rec { $s$wa_r3mi :: GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.Addr# -> GHC.Prim.Word# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.ByteArray# -> GHC.Types.Int -> GHC.Types.Int -> GHC.Types.Int -> GHC.Prim.ByteArray# -> GHC.Types.Int -> GHC.Types.Int -> GHC.Types.Int -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #) [GlobalId] [Arity 14 NoCafRefs] $s$wa_r3mi = \ (sc_s3es :: GHC.Prim.State# GHC.Prim.RealWorld) (sc1_s3et :: GHC.Prim.Addr#) (sc2_s3eu :: GHC.Prim.Word#) (sc3_s3ev :: GHC.Prim.Int#) (sc4_s3ew :: GHC.Prim.Int#) (sc5_s3ex :: GHC.Prim.Int#) (sc6_s3ey :: GHC.Prim.ByteArray#) (sc7_s3ez :: GHC.Types.Int) (sc8_s3eA :: GHC.Types.Int) (sc9_s3eB :: GHC.Types.Int) (sc10_s3eC :: GHC.Prim.ByteArray#) (sc11_s3eD :: GHC.Types.Int) (sc12_s3eE :: GHC.Types.Int) (sc13_s3eF :: GHC.Types.Int) -> let { m_s39b :: GHC.Types.Int [] m_s39b = GHC.Types.I# sc3_s3ev } in ((__scc {gen main:Main !} case sc5_s3ex of wild_B1 { __DEFAULT -> case GHC.Prim.==# sc4_s3ew sc3_s3ev of wild1_X3F { GHC.Bool.False -> (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) -> let { ww_s33e :: GHC.Prim.Word# [] ww_s33e = GHC.Prim.remWord# (GHC.Prim.narrow32Word# (GHC.Prim.plusWord# (GHC.Prim.narrow32Word# (GHC.Prim.timesWord# __word 3877 sc2_s3eu)) __word 29573)) __word 139968 } in case $w$spick_r3k8 sc10_s3eC sc6_s3ey ww_s33e of ww1_s33i { __DEFAULT -> case GHC.Prim.writeWord8OffAddr# @ GHC.Prim.RealWorld sc1_s3et sc4_s3ew ww1_s33i eta_a2vm of s21_a2wV { __DEFAULT -> $s$wa_r3mi s21_a2wV sc1_s3et ww_s33e sc3_s3ev (GHC.Prim.+# sc4_s3ew 1) (GHC.Prim.+# wild_B1 1) sc6_s3ey sc7_s3ez sc8_s3eA sc9_s3eB sc10_s3eC sc11_s3eD sc12_s3eE sc13_s3eF } }) `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int)) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #) ~ GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int)); GHC.Bool.True -> (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.writeWord8OffAddr# @ GHC.Prim.RealWorld sc1_s3et sc4_s3ew __word 10 eta_a2vm of s21_a2wV { __DEFAULT -> (# s21_a2wV, (GHC.Word.W32# sc2_s3eu, case wild_B1 of wild2_X4o { __DEFAULT -> GHC.Types.I# (GHC.Prim.+# sc3_s3ev 1); 0 -> m_s39b }) #) }) `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int)) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #) ~ GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int)) }; 60 -> (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.writeWord8OffAddr# @ GHC.Prim.RealWorld sc1_s3et sc4_s3ew __word 10 eta_a2vm of s21_a2wV { __DEFAULT -> $s$wa1_r3mk s21_a2wV sc1_s3et sc2_s3eu (GHC.Prim.+# sc3_s3ev 1) (GHC.Prim.+# sc4_s3ew 1) sc6_s3ey sc7_s3ez sc8_s3eA sc9_s3eB sc10_s3eC sc11_s3eD sc12_s3eE sc13_s3eF }) `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int)) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #) ~ GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int)) }) `cast` ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int) :: GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int) ~ GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #))) sc_s3es $s$wa1_r3mk :: GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.Addr# -> GHC.Prim.Word# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.ByteArray# -> GHC.Types.Int -> GHC.Types.Int -> GHC.Types.Int -> GHC.Prim.ByteArray# -> GHC.Types.Int -> GHC.Types.Int -> GHC.Types.Int -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #) [GlobalId] [Arity 13 NoCafRefs] $s$wa1_r3mk = \ (sc_s3fH :: GHC.Prim.State# GHC.Prim.RealWorld) (sc1_s3fI :: GHC.Prim.Addr#) (sc2_s3fJ :: GHC.Prim.Word#) (sc3_s3fK :: GHC.Prim.Int#) (sc4_s3fL :: GHC.Prim.Int#) (sc5_s3fM :: GHC.Prim.ByteArray#) (sc6_s3fN :: GHC.Types.Int) (sc7_s3fO :: GHC.Types.Int) (sc8_s3fP :: GHC.Types.Int) (sc9_s3fQ :: GHC.Prim.ByteArray#) (sc10_s3fR :: GHC.Types.Int) (sc11_s3fS :: GHC.Types.Int) (sc12_s3fT :: GHC.Types.Int) -> let { m_s39b :: GHC.Types.Int [] m_s39b = GHC.Types.I# sc3_s3fK } in ((__scc {gen main:Main !} case GHC.Prim.==# sc4_s3fL sc3_s3fK of wild_X3F { GHC.Bool.False -> (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) -> let { ww_s33e :: GHC.Prim.Word# [] ww_s33e = GHC.Prim.remWord# (GHC.Prim.narrow32Word# (GHC.Prim.plusWord# (GHC.Prim.narrow32Word# (GHC.Prim.timesWord# __word 3877 sc2_s3fJ)) __word 29573)) __word 139968 } in case $w$spick_r3k8 sc9_s3fQ sc5_s3fM ww_s33e of ww1_s33i { __DEFAULT -> case GHC.Prim.writeWord8OffAddr# @ GHC.Prim.RealWorld sc1_s3fI sc4_s3fL ww1_s33i eta_a2vm of s21_a2wV { __DEFAULT -> $s$wa_r3mi s21_a2wV sc1_s3fI ww_s33e sc3_s3fK (GHC.Prim.+# sc4_s3fL 1) 1 sc5_s3fM sc6_s3fN sc7_s3fO sc8_s3fP sc9_s3fQ sc10_s3fR sc11_s3fS sc12_s3fT } }) `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int)) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #) ~ GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int)); GHC.Bool.True -> (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.writeWord8OffAddr# @ GHC.Prim.RealWorld sc1_s3fI sc4_s3fL __word 10 eta_a2vm of s21_a2wV { __DEFAULT -> (# s21_a2wV, (GHC.Word.W32# sc2_s3fJ, m_s39b) #) }) `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int)) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #) ~ GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int)) }) `cast` ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int) :: GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int) ~ GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #))) sc_s3fH end Rec } $s$wa2_r3mm :: GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.Addr# -> GHC.Word.Word32 -> GHC.Prim.Int# -> GHC.Prim.Int# -> (Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32, Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32) -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #) [GlobalId] [Arity 6 NoCafRefs] $s$wa2_r3mm = \ (sc_s3eH :: GHC.Prim.State# GHC.Prim.RealWorld) (sc1_s3eI :: GHC.Prim.Addr#) (sc2_s3eJ :: GHC.Word.Word32) (sc3_s3eK :: GHC.Prim.Int#) (sc4_s3eL :: GHC.Prim.Int#) (sc5_s3eM :: (Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32, Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32)) -> let { m_s39b :: GHC.Types.Int [] m_s39b = GHC.Types.I# sc3_s3eK } in ((__scc {gen main:Main !} case GHC.Prim.==# sc4_s3eL sc3_s3eK of wild_X3F { GHC.Bool.False -> (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) -> case sc5_s3eM of w_X34x { (ww_s32X, ww1_s334) -> case ww_s32X of ww2_X34F { Data.Array.Base.UArray ww3_s32Z ww4_s330 ww5_s331 ww6_s332 -> case ww1_s334 of ww7_X34X { Data.Array.Base.UArray ww8_s336 ww9_s337 ww10_s338 ww11_s339 -> case __scc {next main:Main} case sc2_s3eJ of wild1_a2Bw { GHC.Word.W32# y#_a2By -> GHC.Word.W32# (GHC.Prim.remWord# (GHC.Prim.narrow32Word# (GHC.Prim.plusWord# (GHC.Prim.narrow32Word# (GHC.Prim.timesWord# __word 3877 y#_a2By)) __word 29573)) __word 139968) } of w1_X35g { GHC.Word.W32# ww12_s33e -> case $w$spick_r3k8 ww6_s332 ww11_s339 ww12_s33e of ww13_s33i { __DEFAULT -> case GHC.Prim.writeWord8OffAddr# @ GHC.Prim.RealWorld sc1_s3eI sc4_s3eL ww13_s33i eta_a2vm of s21_a2wV { __DEFAULT -> $s$wa_r3mi s21_a2wV sc1_s3eI ww12_s33e sc3_s3eK (GHC.Prim.+# sc4_s3eL 1) 1 ww11_s339 ww10_s338 ww9_s337 ww8_s336 ww6_s332 ww5_s331 ww4_s330 ww3_s32Z } } } } } }) `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int)) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #) ~ GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int)); GHC.Bool.True -> (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.writeWord8OffAddr# @ GHC.Prim.RealWorld sc1_s3eI sc4_s3eL __word 10 eta_a2vm of s21_a2wV { __DEFAULT -> (# s21_a2wV, (sc2_s3eJ, m_s39b) #) }) `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int)) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #) ~ GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int)) }) `cast` ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int) :: GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int) ~ GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #))) sc_s3eH $wa1_r3mo :: (Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32, Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32) -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Word.Word32 -> GHC.Prim.Addr# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #) [GlobalId] [Arity 7 NoCafRefs Str: DmdType LLLLLLL] $wa1_r3mo = \ (w_s33r :: (Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32, Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32)) (ww_s33u :: GHC.Prim.Int#) (ww1_s33y :: GHC.Prim.Int#) (ww2_s33C :: GHC.Prim.Int#) (w1_s33E :: GHC.Word.Word32) (ww3_s33H :: GHC.Prim.Addr#) (w2_s33J :: GHC.Prim.State# GHC.Prim.RealWorld) -> let { m_s39b :: GHC.Types.Int [] m_s39b = GHC.Types.I# ww2_s33C } in ((__scc {gen main:Main !} case ww_s33u of wild_B1 { __DEFAULT -> case GHC.Prim.==# ww1_s33y ww2_s33C of wild1_X3F { GHC.Bool.False -> (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) -> case w_s33r of w3_X34x { (ww4_s32X, ww5_s334) -> case ww4_s32X of ww6_X34F { Data.Array.Base.UArray ww7_s32Z ww8_s330 ww9_s331 ww10_s332 -> case ww5_s334 of ww11_X34X { Data.Array.Base.UArray ww12_s336 ww13_s337 ww14_s338 ww15_s339 -> case __scc {next main:Main} case w1_s33E of wild11_a2Bw { GHC.Word.W32# y#_a2By -> GHC.Word.W32# (GHC.Prim.remWord# (GHC.Prim.narrow32Word# (GHC.Prim.plusWord# (GHC.Prim.narrow32Word# (GHC.Prim.timesWord# __word 3877 y#_a2By)) __word 29573)) __word 139968) } of w4_X35g { GHC.Word.W32# ww16_s33e -> case $w$spick_r3k8 ww10_s332 ww15_s339 ww16_s33e of ww17_s33i { __DEFAULT -> case GHC.Prim.writeWord8OffAddr# @ GHC.Prim.RealWorld ww3_s33H ww1_s33y ww17_s33i eta_a2vm of s21_a2wV { __DEFAULT -> $s$wa_r3mi s21_a2wV ww3_s33H ww16_s33e ww2_s33C (GHC.Prim.+# ww1_s33y 1) (GHC.Prim.+# wild_B1 1) ww15_s339 ww14_s338 ww13_s337 ww12_s336 ww10_s332 ww9_s331 ww8_s330 ww7_s32Z } } } } } }) `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int)) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #) ~ GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int)); GHC.Bool.True -> (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.writeWord8OffAddr# @ GHC.Prim.RealWorld ww3_s33H ww1_s33y __word 10 eta_a2vm of s21_a2wV { __DEFAULT -> (# s21_a2wV, (w1_s33E, case wild_B1 of wild2_X4o { __DEFAULT -> GHC.Types.I# (GHC.Prim.+# ww2_s33C 1); 0 -> m_s39b }) #) }) `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int)) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #) ~ GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int)) }; 60 -> (\ (eta_a2vm :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.writeWord8OffAddr# @ GHC.Prim.RealWorld ww3_s33H ww1_s33y __word 10 eta_a2vm of s21_a2wV { __DEFAULT -> $s$wa2_r3mm s21_a2wV ww3_s33H w1_s33E (GHC.Prim.+# ww2_s33C 1) (GHC.Prim.+# ww1_s33y 1) w_s33r }) `cast` (sym ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int)) :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #) ~ GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int)) }) `cast` ((GHC.IOBase.:CoIO) (GHC.Word.Word32, GHC.Types.Int) :: GHC.IOBase.IO (GHC.Word.Word32, GHC.Types.Int) ~ GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #))) w2_s33J a2_r3mq :: (Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32, Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32) -> GHC.Types.Int -> GHC.Types.Int -> GHC.Types.Int -> GHC.Word.Word32 -> GHC.Ptr.Ptr GHC.Word.Word8 -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Types.Int) #) [GlobalId] [Arity 7 NoCafRefs Str: DmdType LU(L)U(L)U(L)LU(L)L] a2_r3mq = __inline_me (\ (w_s33r :: (Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32, Data.Array.Base.UArray GHC.Types.Int GHC.Word.Word32)) (w1_s33s :: GHC.Types.Int) (w2_s33w :: GHC.Types.Int) (w3_s33A :: GHC.Types.Int) (w4_s33E :: GHC.Word.Word32) (w5_s33F :: GHC.Ptr.Ptr GHC.Word.Word8) (w6_s33J :: GHC.Prim.State# GHC.Prim.RealWorld) -> case w1_s33s of w7_X35h { GHC.Types.I# ww_s33u -> case w2_s33w of w8_X35q { GHC.Types.I# ww1_s33y -> case w3_s33A of w9_X35z { GHC.Types.I# ww2_s33C -> case w5_s33F of w10_X35J { GHC.Ptr.Ptr ww3_s33H -> $wa1_r3mo w_s33r ww_s33u ww1_s33y ww2_s33C w4_s33E ww3_s33H w6_s33J } } } }) ------------------------------------------------------------------------ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 24 06:56:33 2009 From: trac at galois.com (GHC) Date: Mon Aug 24 06:36:23 2009 Subject: [GHC] #3435: ghc-stage2 panic while compiling ghc-paths-0.1.0.5 In-Reply-To: <043.4f1d9667826ab434e5c82a9c75a75a17@localhost> References: <043.4f1d9667826ab434e5c82a9c75a75a17@localhost> Message-ID: <052.3d9edc70d1c089d1458962a52f39a14e@localhost> #3435: ghc-stage2 panic while compiling ghc-paths-0.1.0.5 -------------------------+-------------------------------------------------- Reporter: jsch | 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: Linux Architecture: x86 | -------------------------+-------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed: {{{ Fri Aug 21 16:47:37 BST 2009 Simon Marlow * Fix the interface-file incompatibility crash (#3435) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 24 07:25:11 2009 From: trac at galois.com (GHC) Date: Mon Aug 24 07:05:01 2009 Subject: [GHC] #3398: Unicode output in GHC In-Reply-To: <047.de64825b187e674ad618957169425649@localhost> References: <047.de64825b187e674ad618957169425649@localhost> Message-ID: <056.5b2917b29a709a96e63f3a7b4c59073e@localhost> #3398: Unicode output in GHC ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: 2816 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): The `FilePath` issue is not a regression (i.e. it was broken in 6.10.x too), so fixing it is not a top priority. However, I really think we should address the general Unicode output issues I raised earlier in this ticket. Let's make a separate ticket for Unicode `FilePath` issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 24 07:25:57 2009 From: trac at galois.com (GHC) Date: Mon Aug 24 07:05:46 2009 Subject: [GHC] #3447: Class restrictions on type instances In-Reply-To: <048.c99d50265c5dd4c44f2bab6be9ab501e@localhost> References: <048.c99d50265c5dd4c44f2bab6be9ab501e@localhost> Message-ID: <057.889d13b4ed4dffc4a7ae41f23098cc1c@localhost> #3447: Class restrictions on type instances ---------------------------------+------------------------------------------ Reporter: LysikovVV | 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 | ---------------------------------+------------------------------------------ Comment (by simonpj): The right thing seems to be to make `BoolT (NotT a)` a superclass, thus: {{{ class BoolT (NotT a) => BoolT a where type NotT a }}} This is legal with `-XFlexibleContexts`. Perhaps you can see if that serves your purpose? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 24 07:46:15 2009 From: trac at galois.com (GHC) Date: Mon Aug 24 07:26:04 2009 Subject: [GHC] #3455: Add a setting to change how Unicode encoding errors are handled In-Reply-To: <045.14097b0341f39cd69e7f9d0c1052173e@localhost> References: <045.14097b0341f39cd69e7f9d0c1052173e@localhost> Message-ID: <054.64f1cb43b4e7a885422e1f4ce114cc20@localhost> #3455: Add a setting to change how Unicode encoding errors are handled ---------------------------------+------------------------------------------ Reporter: judahj | 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 simonmar): It looks like the main question here is whether the `IOError` should be returned explicitly (as in your patch), or whether we should just catch the exception. All things being equal, catching the exception would be simpler, as it wouldn't require any changes in the codecs. Is there a reason why you didn't do it that way? Perhaps because you want to be sure that the exception is really an encoding error, and not some other kind of exception? If that's the case, then we should introduce a new exception for encoding errors (that's probably a good idea anyway). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 24 07:47:55 2009 From: trac at galois.com (GHC) Date: Mon Aug 24 07:27:45 2009 Subject: [GHC] #3398: Unicode output in GHC In-Reply-To: <047.de64825b187e674ad618957169425649@localhost> References: <047.de64825b187e674ad618957169425649@localhost> Message-ID: <056.93acda9d27bfe03e83fbe90b28fcd828@localhost> #3398: Unicode output in GHC ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: 2816 | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Ah, I see you already made a ticket for the `FilePath` issue: #3456. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 24 10:19:27 2009 From: trac at galois.com (GHC) Date: Mon Aug 24 09:59:17 2009 Subject: [GHC] #3458: Allocation where none should happen In-Reply-To: <044.0be4f1c62ed65da810608cbf23db2085@localhost> References: <044.0be4f1c62ed65da810608cbf23db2085@localhost> Message-ID: <053.737ca4c88f48e54533ab83d3d22b6eca@localhost> #3458: Allocation where none should happen -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Comment (by guest): {{{ ll = 60, next :: Word32 -> Word32 next s = (ia*s + ic) `rem` im ia = 3877 ic = 29573 im = 139968 }}} The whole program (changed to use IOUArray everywhere now, but the problem remains): {{{ {-# OPTIONS -O2 -funbox-strict-fields -fexcess-precision -fvia-C -optc-O3 -optc-ffast-math -optc-fomit-frame-pointer -optc-march=native -optc- mfpmath=sse -optc-msse3 #-} ------------------------------------------------------------------------ --- --- The Computer Language Benchmarks Game --- --- http://shootout.alioth.debian.org --- --- Fasta Benchmark --- --- Program by Rohan Lean --- ------------------------------------------------------------------------ import Control.Arrow import Control.Concurrent import Data.Array.Base import Data.Array.IO import Data.Array.Unboxed import Data.ByteString.Internal import Data.Word import System import System.IO ------------------------------------------------------------------------ main = do n <- readIO . head =<< getArgs putStrLn ">ONE Homo sapiens alu" write_alu (2*n) putStrLn ">TWO IUB ambiguity codes" s <- write iub (3*n) 42 putStrLn ">THREE Homo sapiens frequency" write hom (5*n) s ------------------------------------------------------------------------ ll = 60 -- line length ------------------------------------------------------------------------ write_alu n = loop n =<< newListArray (1,bs) ul where cc = length alu_string `lcm` ll bs = cc + quot cc ll un = \s -> (take ll s) ++ [0x0a] ++ un (drop ll s) ul = un $ cycle $ map c2w alu_string loop n b | cc <= n = do hPutArray stdout b bs loop (n-cc) b | otherwise = do hPutArray stdout b (n + quot n ll) if rem n ll /= 0 then putChar '\n' else return () ------------------------------------------------------------------------ --- --- Constants for the linear congruential PRNG --- ia = 3877 ic = 29573 im = 139968 ------------------------------------------------------------------------ next :: Word32 -> Word32 next s = (ia*s + ic) `rem` im skip n s = foldr id s $ replicate n next ------------------------------------------------------------------------ tn = 1 -- number of working threads lc = 250 -- threads prepare that many lines cc = lc*ll -- thus many characters bs = cc+lc -- buffersize ------------------------------------------------------------------------ write d n s = do go_1 <- newMVar () done <- newEmptyMVar spawn tn (convert d) n s go_1 go_1 done ------------------------------------------------------------------------ spawn 1 d n s go_k go_1 done = do a <- newArray (1,bs) 0x0a forkIO $ writer d n a s go_k go_1 done takeMVar done spawn t d n s go_k go_1 done = do go_next <- newEmptyMVar a <- newArray (1,bs) 0x0a forkIO $ writer d n a s go_k go_next done spawn (t-1) d (max (n-cc) 0) (skip cc s) go_next go_1 done ------------------------------------------------------------------------ writer d 0 a s go go_next done = killThread =<< myThreadId writer d n a s go go_next done = do (t,br) <- gen d 0 0 cr s a takeMVar go hPutArray stdout a br putMVar go_next () if n-cr == 0 then putMVar done t else return () let u = skip (cc*(tn-1)) t writer d n' a u go go_next done where cr = min n cc n' = max 0 (n-cc*tn) ------------------------------------------------------------------------ gen d r n m s a | r == ll = gen d 0 (n+1) (m+1) s a | n == m = do unsafeWrite a n 0x0a return (s, if r == 0 then m else m+1) | otherwise = do let t = next s unsafeWrite a n (pick d t) gen d (r+1) (n+1) m t a ------------------------------------------------------------------------ pick (c,p) r = loop 0 where loop i = if r < unsafeAt p i then fromIntegral $ unsafeAt c i :: Word8 else loop (i+1) ------------------------------------------------------------------------ convert :: [(Char, Float)] -> ((UArray Int Word32), (UArray Int Word32)) convert t = (a c, a p) where a s = listArray (1, fromIntegral $ length t) s (c,p) = map fromIntegral *** map (ceiling . (* fromIntegral im)) $ map c2w *** scanl1 (+) $ unzip t ------------------------------------------------------------------------ alu_string = "GGCCGGGCGCGGTGGCTCACGCCTGTAATCCCAGCACTTTGG\ \GAGGCCGAGGCGGGCGGATCACCTGAGGTCAGGAGTTCGAGA\ \CCAGCCTGGCCAACATGGTGAAACCCCGTCTCTACTAAAAAT\ \ACAAAAATTAGCCGGGCGTGGTGGCGCGCGCCTGTAATCCCA\ \GCTACTCGGGAGGCTGAGGCAGGAGAATCGCTTGAACCCGGG\ \AGGCGGAGGTTGCAGTGAGCCGAGATCGCGCCACTGCACTCC\ \AGCCTGGGCGACAGAGCGAGACTCCGTCTCAAAAA" ------------------------------------------------------------------------ iub = [('a',0.27),('c',0.12),('g',0.12),('t',0.27),('B',0.02) ,('D',0.02),('H',0.02),('K',0.02),('M',0.02),('N',0.02) ,('R',0.02),('S',0.02),('V',0.02),('W',0.02),('Y',0.02)] hom = [('a',0.3029549426680),('c',0.1979883004921) ,('g',0.1975473066391),('t',0.3015094502008)] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 24 10:21:06 2009 From: trac at galois.com (GHC) Date: Mon Aug 24 10:00:54 2009 Subject: [GHC] #3447: Class restrictions on type instances In-Reply-To: <048.c99d50265c5dd4c44f2bab6be9ab501e@localhost> References: <048.c99d50265c5dd4c44f2bab6be9ab501e@localhost> Message-ID: <057.270c8282c8637efe073a62d9b1f54103@localhost> #3447: Class restrictions on type instances ---------------------------------+------------------------------------------ Reporter: LysikovVV | 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 | ---------------------------------+------------------------------------------ Comment (by LysikovVV): Replying to [comment:2 simonpj]: > This is legal with `-XFlexibleContexts`. Perhaps you can see if that serves your purpose? {{{ Cycle in class declarations (via superclasses): Bool.hs:(8,0)-(10,26): class (BoolT (NotT a)) => BoolT a where { type family NotT a; } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 24 10:23:26 2009 From: trac at galois.com (GHC) Date: Mon Aug 24 10:03:13 2009 Subject: [GHC] #3458: Allocation where none should happen In-Reply-To: <044.0be4f1c62ed65da810608cbf23db2085@localhost> References: <044.0be4f1c62ed65da810608cbf23db2085@localhost> Message-ID: <053.e8b8e07aea0b2e9e731f01466c3c2704@localhost> #3458: Allocation where none should happen -------------------------------+-------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86_64 (amd64) | -------------------------------+-------------------------------------------- Changes (by guest): * version: 6.10.1 => 6.10.4 Comment: A few more notes: I could reproduce the bug with 6.10.4. When profiling, there is roughly ten times more allocation happening, which gets attributed to the program. Nevertheless, even when running a normal build the program allocates around 4.6GB here, and I don't see where all that allocation comes from. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 24 13:56:53 2009 From: trac at galois.com (GHC) Date: Mon Aug 24 13:37:08 2009 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@localhost> Message-ID: <060.a945461b7f3e4c682a14a453d049eadd@localhost> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) ---------------------------------+------------------------------------------ Reporter: Isaac Dupree | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by explicitcall): * cc: explicitcall@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 24 15:33:29 2009 From: trac at galois.com (GHC) Date: Mon Aug 24 15:13:18 2009 Subject: [GHC] #3459: ghci 6.10.4 and 6.10.1 crash with a big list Message-ID: <046.37f1fbfe6457c6d9dc39b6d0b0bfdcb4@localhost> #3459: ghci 6.10.4 and 6.10.1 crash with a big list --------------------+------------------------------------------------------- Reporter: joaoraf | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Severity: major Keywords: | Testcase: Os: Linux | Architecture: x86 --------------------+------------------------------------------------------- A have a haskell program with a big list of brazillian cities which crash ghci 6.10.4 with the following message (the same error occurred with 6.10.1): Prelude Data.ListTrie.Patricia.Map Data.ListTrie.Base.Map> :l MakeMunicipios.hs [1 of 1] Compiling MakeMunicipios ( MakeMunicipios.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for i386-unknown-linux): linkBCO: >= 64k insns in BCO 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 Mon Aug 24 17:45:46 2009 From: trac at galois.com (GHC) Date: Mon Aug 24 17:25:37 2009 Subject: [GHC] #3460: Can't use superclass when type coercions are involved Message-ID: <044.244b3775004994168c2f11c29886a28f@localhost> #3460: Can't use superclass when type coercions are involved -----------------------------+---------------------------------------------- Reporter: ryani | 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 6.10.4. {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts #-} module Coercion where class Nat n where toInt :: n -> Int class (Nat (Arity f)) => Model f where type Arity f ok :: Model f => f -> Arity f -> Int ok _ n = toInt n bug :: (Model f, Arity f ~ n) => f -> n -> Int bug _ n = toInt n }}} I expect that (Model f) brings (Nat (Arity f)) into scope, and that (Arity f ~ n) means we can derive (Nat n). But the compiler disagrees. {{{ Coercion.hs:14:10: Could not deduce (Nat n) from the context (Arity f ~ n, Model f) arising from a use of `toInt' at Coercion.hs:14:10-16 Possible fix: add (Nat n) to the context of the type signature for `bug' In the expression: toInt n In the definition of `bug': bug _ n = toInt n }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 25 03:18:21 2009 From: trac at galois.com (GHC) Date: Tue Aug 25 02:58:12 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.9a39c6b15d963e0c1ca430c2be0e62a0@localhost> #3460: Can't use superclass when type coercions are involved ----------------------------------------+----------------------------------- Reporter: ryani | Owner: chak Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ----------------------------------------+----------------------------------- Changes (by simonpj): * owner: => chak * difficulty: => Unknown Comment: Yes, that does look like a bug. Thank you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 25 03:23:11 2009 From: trac at galois.com (GHC) Date: Tue Aug 25 03:02:59 2009 Subject: [GHC] #3447: Class restrictions on type instances In-Reply-To: <048.c99d50265c5dd4c44f2bab6be9ab501e@localhost> References: <048.c99d50265c5dd4c44f2bab6be9ab501e@localhost> Message-ID: <057.687687b02d489c51710ed9ddfc12fef3@localhost> #3447: Class restrictions on type instances ---------------------------------+------------------------------------------ Reporter: LysikovVV | Owner: Type: feature request | 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): * milestone: 6.14.1 => _|_ Comment: Ah yes, sorry. I don't think I see a good way to achieve what you want, at least not without a new, ad-hoc extension. Happily, though, what you want is to ''reject'' more programs. You can still write the programs you want. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 25 03:39:35 2009 From: trac at galois.com (GHC) Date: Tue Aug 25 03:19:20 2009 Subject: [GHC] #3406: 'impossible' happened while messing around with ScopedTypeVariables In-Reply-To: <044.9724012c5b1b2098374ba8fb8be5fa12@localhost> References: <044.9724012c5b1b2098374ba8fb8be5fa12@localhost> Message-ID: <053.252695653b166259aab7b06b802a556b@localhost> #3406: 'impossible' happened while messing around with ScopedTypeVariables --------------------------------------------+------------------------------- Reporter: RyanN | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.12.1 Component: Compiler | Version: 6.10.3 Severity: normal | Resolution: fixed Keywords: ScopedTypeVariabes | Difficulty: Unknown Testcase: typecheck/should_fail/T3406 | Os: Linux Architecture: x86_64 (amd64) | --------------------------------------------+------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T3406 * status: new => closed * resolution: => fixed Comment: Good catch. The difficulty is that, in GHC's current type checker, scoped type variables must be "rigid": that is, the type checker must know exactly what they stand for, at their binding site. My commit message for the fix contains a smaller example: {{{ Tue Aug 25 08:30:59 GMT Daylight Time 2009 simonpj@microsoft.com * Fix Trac #3406 (albeit not very satisfactorily): scoped type variables The issue here is this: type ItemColID a b = Int -- Discards a,b get :: ItemColID a b -> a -> ItemColID a b get (x :: ItemColID a b) = x :: ItemColID a b The pattern signature for 'x' doesn't actually rigidly bind a,b. This crashed GHC 6.10 with a 'readFilledBox' panic. Now we fail with an error message }}} Although it's a corner case, GHC's restriction is a bit of a pain. With the planned new "outside-in" type inference algorithm, however, this problem will go away. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 25 04:12:23 2009 From: trac at galois.com (GHC) Date: Tue Aug 25 03:52:09 2009 Subject: [GHC] #3447: Class restrictions on type instances In-Reply-To: <048.c99d50265c5dd4c44f2bab6be9ab501e@localhost> References: <048.c99d50265c5dd4c44f2bab6be9ab501e@localhost> Message-ID: <057.458b683d132ddcf9fe2f08465ef88878@localhost> #3447: Class restrictions on type instances ---------------------------------+------------------------------------------ Reporter: LysikovVV | Owner: Type: feature request | 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 LysikovVV): I have read your paper "Fun with type functions" and learned the concept of algebraic data kinds. This extension resolves the problem too. Is there plans to add it to GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 25 04:43:55 2009 From: trac at galois.com (GHC) Date: Tue Aug 25 04:23:49 2009 Subject: [GHC] #3461: loading package ghc in GHCI; unknown symbol `keepCAFs' Message-ID: <047.1df246ba131709d98697e64af64ff966@localhost> #3461: loading package ghc in GHCI; unknown symbol `keepCAFs' -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- We can't currently load `-package ghc` in GHCi {{{ ghc-stage2: /64playpen/simonmar/nightly/HEAD-cam-04-unx/x86_64-unknown- linux/compiler/stage3/build/HSghc-6.11.20090824.o: unknown symbol `keepCAFs' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 25 04:48:43 2009 From: trac at galois.com (GHC) Date: Tue Aug 25 04:28:31 2009 Subject: [GHC] #3462: New codegen: allocate large objects using allocateLocal() Message-ID: <047.2cff8925cc83a1acf5acaf53c93372b6@localhost> #3462: New codegen: allocate large objects using allocateLocal() -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.14.1 Component: Compiler | Version: 6.11 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -------------------------------+-------------------------------------------- See #3424. In the new code generator, we should allocate large objects (larger than F * block size, for some suitable fraction F) using the RTS `allocateLocal()` API rather than from the nursery. It works to allocate them from the nursery -- this is what GHC 6.12 does after the fix in #3424 -- but then they will not be treated as large objects and will be copied during GC. Also, the allocation is likely to fail, requiring a trip through the RTS to put a large enough block in the nursery to satisfy the allocation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 25 06:55:29 2009 From: trac at galois.com (GHC) Date: Tue Aug 25 06:35:20 2009 Subject: [GHC] #2664: type family + data family + typeclass + type error causes GHC to diverge In-Reply-To: <044.872c3ac7a7ba1538fc338d52d1b94837@localhost> References: <044.872c3ac7a7ba1538fc338d52d1b94837@localhost> Message-ID: <053.ffa896b9cffdd453392355cda0302e36@localhost> #2664: type family + data family + typeclass + type error causes GHC to diverge ---------------------------------+------------------------------------------ Reporter: ryani | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonpj): HEAD gives {{{ WARNING: file compiler/types/Coercion.lhs line 465 Strange! Type mismatch in trans coercion, probably a bug ...plus some more... }}} But Manuel thinks the WARNING has false positives. (Maybe we should nuke it.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 25 10:50:41 2009 From: trac at galois.com (GHC) Date: Tue Aug 25 10:30:35 2009 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.19d61668b20af4c76fe35c47526b4db8@localhost> #1338: base package breakup ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by mokus): Would it be possible to implement at least as much of this splitting as is needed to remove all "unsafe" operations from base? I would very much like to be able to use packages as a 'unit of analysis' for a relatively simple library I'm working on that attempts to maintain a package database of "safe" packages (verified not to perform any "dangerous" IO outside the IO type, for example). Unfortunately, as it stands now the analysis is polluted from the start due to base's inclusion of unsafePerformIO, unsafeCoerce, unsafeSTToIO, the ability to define custom Typeable instances, large parts of the whole GHC subtree, and possibly other surprises. If these could be removed from base, it would make things much simpler. At present I am using a "base- safe" wrapper that uses the PackageImports extension (thanks for that by the way, it's great!) to export a subset of the base library, but it would be much cleaner to have base itself be "pure" so that all cabal packages using it (and build-type Simple and only "safe" language extensions) could be automatically ruled "pure" as well. Plus, doesn't it just give you lots of warm fuzzies to think of Haskell's base library as pure? Or to put it differently, doesn't it just give you the screaming heebie-jeebies that unsafePerformIO is in base at all? ;) If proliferation of small packages is a concern, perhaps the split could be implemented by renaming the existing base to, say, "base-unsafe", and providing smaller interface wrapper packages using PackageImports as, e.g., base, st, unsafe-io, unsafe-st, foreign, and so on. I don't know whether that actually solves whatever the concern is over small packages, but it would at least allow the interface to be broken up without requiring as much effort as a full disentanglement of all the module dependencies. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 25 10:52:34 2009 From: trac at galois.com (GHC) Date: Tue Aug 25 10:32:25 2009 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.cadf123f7f9914264ce6e906be58373c@localhost> #1338: base package breakup ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by mokus): * cc: mokus@deepbondi.net (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 25 11:35:16 2009 From: trac at galois.com (GHC) Date: Tue Aug 25 11:15:09 2009 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.39992939f07b908ba86314e7ed13a459@localhost> #1338: base package breakup ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Replying to [comment:29 mokus]: > Would it be possible to implement at least as much of this splitting as is needed to remove all "unsafe" operations from base? Unfortunately, this isn't as easy as you might expect. Exceptions require `Typeable`, which uses `unsafePerformIO` and `IORef`, which is enough to allow you to both `unsafePerformIO` (obviously) and `unsafeCoerce`. Of course, you could make them not be exported, but that's not as nice as them being completely absent. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 25 11:46:07 2009 From: trac at galois.com (GHC) Date: Tue Aug 25 11:25:53 2009 Subject: [GHC] #3416: Make maximumBy strict on the contents of its list In-Reply-To: <046.92a18780aff581cd9cc2254f3d845a56@localhost> References: <046.92a18780aff581cd9cc2254f3d845a56@localhost> Message-ID: <055.376d44f142502fa41bd22d32fd0a6036@localhost> #3416: Make maximumBy strict on the contents of its list ---------------------------------+------------------------------------------ Reporter: bdonlan | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by igloo): * status: reopened => closed * resolution: => wontfix Comment: The behaviour of `maximumBy` is defined by the Haskell 98 report. If you want to propose a change then you'll have to make a [http://hackage.haskell.org/trac/haskell-prime/wiki/Process Haskell Prime proposal]. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 25 14:54:28 2009 From: trac at galois.com (GHC) Date: Tue Aug 25 14:34:21 2009 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.713cc930d380a1e1769869e9423f9463@localhost> #1338: base package breakup ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by mokus): Replying to [comment:31 igloo]: > Unfortunately, this isn't as easy as you might expect. Exceptions require `Typeable`, which uses `unsafePerformIO` and `IORef`, which is enough to allow you to both `unsafePerformIO` (obviously) and `unsafeCoerce`. > > Of course, you could make them not be exported, but that's not as nice as them being completely absent. As far as I can tell, Typeable is safe as long as the end user cannot inject their own implementations of typeOf. As a separate issue, if this is not correct I'm interested to know that as well ;). In my current implementation, I export Typeable with the class methods replaced by identically-typed functions, so that Typeable may be used but no 'tricky' implementations may be created. It is still possible to derive instances as long as the class itself is in scope, and as far as I can tell this is sufficient to make Typeable both useful and safe. Likewise for Typeable1, Typeable2, and the rest, as well as Data and Ix just to be safe. I'm not requesting that unsafe operations not be present, only that they not be available to packages only importing the base package. Clearly the unsafe operations should be exposed somehow, because they're just too darn useful not to provide. Presently I do this by compiling against the un- wrapped version of base when building other "safe" packages like bytestring (similarly wrapped with a 'safe' version hiding its unsafe operations) that make use of unsafe interfaces but cleanly encapsulate them. I expect that any practical strategy for achieving a safe base would either keep the whole unsafe base around, perhaps under a different name, or place the unsafe operations in separate package(s) depended-upon by base and other packages that need them. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 25 17:20:55 2009 From: trac at galois.com (GHC) Date: Tue Aug 25 17:00:54 2009 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.4fe3671e77fe69974acc51f926bbb3f0@localhost> #1338: base package breakup ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by duncan): Replying to [comment:29 mokus]: > Would it be possible to implement at least as much of this splitting as is needed to remove all "unsafe" operations from base? I would very much like to be able to use packages as a 'unit of analysis' for a relatively simple library I'm working on that attempts to maintain a package database of "safe" packages (verified not to perform any "dangerous" IO outside the IO type, for example). I would suggest an approach using a combination of annotations and analysis. Certainly a package that contains only pure functions and depends only on other packages you've deemed to be ok, is itself ok. That requires no annotation, just analysis. Your problem of course is packages that either exports genuinely unsafe things or that uses unsafe things to export safe abstractions. My suggestion here is to annotate the things that are safe but use unsafe things internally. Of course you then need to "believe" the annotations, so you would want a way to specify a list of packages where you will trust the annotations to be correct. You don't need to annotate things as unsafe since all primitives are considered unsafe unless marked safe. The point is you do not need to conflate the safe/unsafe distinction with package boundaries. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Aug 25 23:47:57 2009 From: trac at galois.com (GHC) Date: Tue Aug 25 23:27:48 2009 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.f85a607b34971db15ec1c14a1017a5a1@localhost> #1338: base package breakup ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by mokus): Replying to [comment:33 duncan]: > I would suggest an approach using a combination of annotations and analysis. Certainly a package that contains only pure functions and depends only on other packages you've deemed to be ok, is itself ok. That requires no annotation, just analysis. Your problem of course is packages that either exports genuinely unsafe things or that uses unsafe things to export safe abstractions. My suggestion here is to annotate the things that are safe but use unsafe things internally. Of course you then need to "believe" the annotations, so you would want a way to specify a list of packages where you will trust the annotations to be correct. You don't need to annotate things as unsafe since all primitives are considered unsafe unless marked safe. > > The point is you do not need to conflate the safe/unsafe distinction with package boundaries. I agree with this in principle, however I believe that it introduces an unnecessary level of indirection. The type system in Haskell, and GHC in particular, is already a very powerful annotation system which under normal circumstances automatically tracks exactly the kind of safety information I need, and automatically infers it at the expression level. Any annotation system I implement in addition to that would be likely be a large amount of wasted effort to provide essentially a very course-grained and primitive supplemental type system. What I'm doing now is essentially what you suggest, but using types as the "annotations". If I could include the base package among those packages for which I can trust the annotations, it would greatly simplify certain aspects of my implementation. As far as conflating safety distinctions with package boundaries, I can see how I gave that impression but I don't believe that's what I'm doing. Ultimately, trust is what I am delimiting with package boundaries. As packages are the basic units of code deployment I believe this is a very natural boundary. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 03:41:39 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 03:21:41 2009 Subject: [GHC] #3447: Class restrictions on type instances In-Reply-To: <048.c99d50265c5dd4c44f2bab6be9ab501e@localhost> References: <048.c99d50265c5dd4c44f2bab6be9ab501e@localhost> Message-ID: <057.06f70b9d69cf4150c1c6bd4b3adf1ed2@localhost> #3447: Class restrictions on type instances ---------------------------------+------------------------------------------ Reporter: LysikovVV | Owner: Type: feature request | 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): * cc: Conor.McBride@cis.strath.ac.uk (added) Comment: Yes, definitely, I plan to add algebraic kinds. Timescale uncertain, though, I'm afraid. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 04:08:08 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 03:48:04 2009 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@localhost> References: <051.9654be8110cd7a09257c98a211221fb3@localhost> Message-ID: <060.1e172378460e0f0a56f47c43665b5096@localhost> #3231: Permission denied error with runProcess/openFile ---------------------------------+------------------------------------------ Reporter: NeilMitchell | Owner: igloo Type: bug | Status: reopened Priority: normal | Milestone: 6.10.4 Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by yugr): * status: closed => reopened * type: merge => bug * version: 6.10.2 => 6.10.4 * resolution: fixed => * severity: major => normal Comment: I think the problem remains. This module Main where import System import System.IO import System.Process import System.Directory import Control.Monad import Data.List tempFile = "mytempfile.txt" run :: FilePath -> IO String run exe = do h <- openFile tempFile WriteMode pid <- runProcess exe [] Nothing Nothing Nothing (Just h) (Just h) exitCode <- waitForProcess pid hClose h if exitCode /= ExitSuccess then error $ exe ++ " failed" else do readFile tempFile main = replicateM_ 10 (run "dir") gives me *** Exception: mytempfile.txt: openFile: permission denied (Permission denied) -- Ticket URL: GHC The Glasgow Haskell Compiler From djd at comp.leeds.ac.uk Wed Aug 26 06:05:07 2009 From: djd at comp.leeds.ac.uk (David Duke) Date: Wed Aug 26 06:15:32 2009 Subject: runhaskell script on head build Message-ID: <4A9508D3.6050803@comp.leeds.ac.uk> This didn't seem like a ghc bug per se, but am happy to put an entry into trac if appropriate. In playing with DPH, I've recently tried building the head code, using Mac OSX 10.5.8 and ghc 6.10.4 After compiling and installing, I tried building an existing package, and noticed that runhaskell was returning with no result. On looking at the script, runhaskell/runghc from the head build is attempting to execute /usr/local/bin/ghc-stage2, rather than /usr/local/bin/ghc. The attempt to invoke the stage2 compiler is coming from the runghc.wrapper text in ghc/utils/runghc. Problem with the wrapper, or did I break something in the build process? David -- Dr. David Duke E: djd@comp.leeds.ac.uk School of Computing W: www.comp.leeds.ac.uk/djd/ University of Leeds T: +44 113 3436800 Leeds, LS2 9JT, U.K. From trac at galois.com Wed Aug 26 06:44:15 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 06:24:05 2009 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.977a6b047e6726332563ffa0d3b65ce7@localhost> #1338: base package breakup ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by simonmar): Why not make a `safe-base` package that re-exports everything from `base` except the unsafe bits? -- Ticket URL: GHC The Glasgow Haskell Compiler From marlowsd at gmail.com Wed Aug 26 06:51:43 2009 From: marlowsd at gmail.com (Simon Marlow) Date: Wed Aug 26 06:31:32 2009 Subject: runhaskell script on head build In-Reply-To: <4A9508D3.6050803@comp.leeds.ac.uk> References: <4A9508D3.6050803@comp.leeds.ac.uk> Message-ID: <4A9513BF.1080409@gmail.com> On 26/08/2009 11:05, David Duke wrote: > > This didn't seem like a ghc bug per se, but am happy to put an entry > into trac if appropriate. > > In playing with DPH, I've recently tried building the head code, using > Mac OSX 10.5.8 and ghc 6.10.4 > > After compiling and installing, I tried building an existing package, > and noticed that runhaskell was returning with no result. On looking at > the script, runhaskell/runghc from the head build is attempting to > execute /usr/local/bin/ghc-stage2, rather than /usr/local/bin/ghc. The > attempt to invoke the stage2 compiler is coming from the runghc.wrapper > text in ghc/utils/runghc. > > Problem with the wrapper, or did I break something in the build process? My fault, I tried to make inplace/bin/runghc work, and broke the installed version at the same time. Am fixing it now. Cheers, Simon From trac at galois.com Wed Aug 26 07:07:33 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 06:47:16 2009 Subject: [GHC] #3463: Binary: Int64 truncated to fit in 32 bit Int Message-ID: <043.f4b03d0a4f63af3d3dbcf70e049d415a@localhost> #3463: Binary: Int64 truncated to fit in 32 bit Int -------------------------------------+-------------------------------------- Reporter: zeno | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: major Keywords: cabal install impossible | Testcase: Os: Linux | Architecture: x86 -------------------------------------+-------------------------------------- When trying to install cabal install via ./bootstrap.sh i get the following: [andrew@newcomp cabal-install-0.6.2]$ ./bootstrap.sh Checking installed packages for ghc-6.10.4... parsec is already installed and the version is ok. network is already installed and the version is ok. Cabal is already installed and the version is ok. HTTP is already installed and the version is ok. zlib is already installed and the version is ok. 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 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Error during cabal-install bootstrap: Compiling the Setup script failed [andrew@newcomp cabal-install-0.6.2]$ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 07:20:18 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 07:00:19 2009 Subject: [GHC] #3447: Class restrictions on type instances In-Reply-To: <048.c99d50265c5dd4c44f2bab6be9ab501e@localhost> References: <048.c99d50265c5dd4c44f2bab6be9ab501e@localhost> Message-ID: <057.49ab1f0a6e4a7dc5b8c38136932e3fa5@localhost> #3447: Class restrictions on type instances ---------------------------------+------------------------------------------ Reporter: LysikovVV | Owner: Type: feature request | 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 conormcbride): Replying to [comment:6 simonpj]: > Yes, definitely, I plan to add algebraic kinds. Timescale uncertain, though, I'm afraid. I guess we should figure out how to proceed here. This is an interesting example, exposing a number of issues. Firstly, and straightforwardly, how do we know Bool is closed under not: typechecking, if we had kind {Bool} inhabited by {True} and {False}. (Digression: whilst some sort of datakinds would be preferable to predicates here, predicate subkinding is still interesting and potentially of value.) Secondly, what happens to choose if we have kind {Bool}? Note that choose is passed an element of some a for which BoolT a holds: the corresponding dictionary is a run-time witness to the ability to choose. What's needed here is not only that Bool is closed under not, but that run-time witnesses to Boolhood are closed under not. The [http://personal.cis.strath.ac.uk/~conor/pub/she/ she] preprocessor lets us write {{{ import ShePrelude -- includes {Bool}, {True}, {False} type family Not (b :: {Bool}) :: {Bool} type instance Not {True} = {False} type instance Not {False} = {True} }}} and we get the obvious nasty untyped translation, before typechecking. It would clearly be preferable to do the typechecking first, but if the semantics is the same, we've only bought security, not power. The question of how to manage run-time witnesses remains. As it happens, she has an experimental treatment, based on a singleton translation. Roughly, if t is a type, then (:: t) is its singleton GADT. Moreover (subject to caveats) if tm :: ty, then {tm} :: (:: ty) {tm}, where the {tm} right of :: is the type-level translation and the {tm} left of :: is the singleton translation. For Bool, it's as if {{{ data (:: Bool) :: {Bool} -> * where {True} :: (:: Bool) {True} {False} :: (:: Bool) {False} }}} More moreover, pi (x :: s). t abbreviates forall (x :: {s}) . (:: s) x -> t. So I can write {{{ choose :: forall (t :: *). pi (b :: Bool). t -> t -> t choose {True} t f = t choose {False} t f = f }}} and even {{{ boolCase :: forall (p :: {Bool} -> *). pi (b :: Bool). p {True} -> p {False} -> p b boolCase {True} t f = t boolCase {False} t f = f }}} However, to combine choose with Not, we need the relevant action on the run-time witnesses. {{{ depNot :: pi (b :: Bool). (:: Bool) (Not b) depNot {True} = {False} depNot {False} = {True} }}} It's this depNot which delivers the extra information corresponding to the missing BoolT constraint requested above. We can then write {{{ esoohc :: forall (t :: *). pi (b :: Bool). t -> t -> t esoohc b = choose (depNot b) }}} It is clearly a nuisance to write type-level Not, together with value- level depNot, especially as yer actual not :: Bool -> Bool is a perfectly well-behaved proletarian. What's my point? Just that algebraic kinds alone do not solve this problem: we need some principled system to manage the associated run-time witnesses. I'm used to getting this for nothing, of course -- dependent types identify the type-level data with their run-time witnesses -- so the thought of Joe manipulating classes and singleton GADTs explicitly in public makes me distinctly queasy. We don't have to solve this problem in order to add algebraic kinds, but we should be aware of it when we're making design choices. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 07:40:39 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 07:20:23 2009 Subject: [GHC] #3464: Find import declaration importing a certain function Message-ID: <044.30a4bd3b165086669168a65fc548f37a@localhost> #3464: Find import declaration importing a certain function -----------------------------+---------------------------------------------- Reporter: fasta | Owner: Type: feature request | Status: new Priority: normal | Component: GHCi Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- 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 Aug 26 07:42:59 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 07:22:40 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.b1655a75ebd3cce4a7ab8a330b0079fc@localhost> #3448: Error with .so files in HEAD snapshot distribution -------------------------------+-------------------------------------------- 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 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 07:46:43 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 07:26:25 2009 Subject: [GHC] #3456: Add FilePath -> String decoder In-Reply-To: <045.a4a219f70c8b7f70a278b60a06ef7b94@localhost> References: <045.a4a219f70c8b7f70a278b60a06ef7b94@localhost> Message-ID: <054.c950522227b54082f7cca984225400c5@localhost> #3456: Add FilePath -> String decoder ---------------------------------+------------------------------------------ Reporter: judahj | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.10.4 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by YitzGale): * status: new => closed * resolution: => duplicate Comment: Duplicate of #3307. See in particular Duncan Coutts' comments, where this function is already mentioned. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 07:55:22 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 07:35:10 2009 Subject: [GHC] #2664: type family + data family + typeclass + type error causes GHC to diverge In-Reply-To: <044.872c3ac7a7ba1538fc338d52d1b94837@localhost> References: <044.872c3ac7a7ba1538fc338d52d1b94837@localhost> Message-ID: <053.2974a15df6e134971c42e9b7f571ae49@localhost> #2664: type family + data family + typeclass + type error causes GHC to diverge ---------------------------------+------------------------------------------ Reporter: ryani | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.11 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by chak): Replying to [comment:6 simonpj]: > HEAD gives {{{ WARNING: file compiler/types/Coercion.lhs line 465 Strange! Type mismatch in trans coercion, probably a bug ...plus some more... }}} > But Manuel thinks the WARNING has false positives. (Maybe we should nuke it.) One case of false positives is when one of the compared types contains an unzonked type variable. I believe this situation arises during solving quality constraints. In most other places where trans coercions are made, the test may be accurate. So, if we knew the caller, it would be easier to say whether a particular warning may potentially be a false positive. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 08:01:30 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 07:41:18 2009 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.808557332694844c918ad28b8bdbb560@localhost> #1338: base package breakup ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by mokus): Replying to [comment:35 simonmar]: > Why not make a `safe-base` package that re-exports everything from `base` except the unsafe bits? That's exactly what I've got right now, and it works fairly well, but it seems to make the process of building safe hackage packages more complex than it could be because I either have to manually "port" each one I want to use or do what I'm doing now which is to use a cabal-install-like build driver that automatically converts dependencies on base to dependencies on safe-base, hoping it really works. If the "real" base were safe I would still be using a fairly customized build tool for other analysis, but it would make for two less things I have to worry about. First, I would not have to modify the PackageDescription, and second, I could have more confidence that a given package will actually successfully build, which I cannot generally expect if I'm dynamically substituting a false base that the package has not necessarily ever been compiled against. I can certainly put my wrapper package up on hackage, and I'd hope it would get used when base is not needed but I'm rather doubtful that it would given that all it does is pretend to be base and provide less functionality. But then again, the Haskell community has surprised me many times before, and I would not be very surprised to be wrong about that. If that winds up being the official recommendation then I can do so without too much trouble, but I think the idea of making base itself type- safe was at least worth bringing up. It seems to me rather appealing on a philosophical level as well, though of course that's not in itself a good enough reason to trump practical concerns. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 08:37:57 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 08:17:44 2009 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.439cd879385b5b5065fba3ea1d096387@localhost> #1338: base package breakup ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): Replying to [comment:35 simonmar]: > Why not make a `safe-base` package that re-exports everything from `base` except the unsafe bits? I think it would be a pain to keep it both complete and correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 08:57:21 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 08:37:08 2009 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.58838c1d8b8fa550ad83435dcc49be8a@localhost> #1338: base package breakup ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by mokus): Replying to [comment:37 igloo]: > Replying to [comment:35 simonmar]: > > Why not make a `safe-base` package that re-exports everything from `base` except the unsafe bits? > > I think it would be a pain to keep it both complete and correct. A bit, but it's not too bad. I've got the versions of my wrapper package tied by strict equality to the versions of base, so it won't compile with a base I haven't examined. base changes infrequently enough that this is quite tractable for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 09:06:15 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 08:46:04 2009 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.fe108e2e8dd18405910a51ad80de644e@localhost> #1338: base package breakup ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by mokus): For what it's worth, I am willing to do as much of the dirty work as I am able given my current level of familiarity with the GHC build system as is necessary to perform a 'safe/unsafe' split if it is something that will actually have a good chance of inclusion. I had already started dabbling in that direction, but wanted to know whether it has any chance of being accepted before digging too deep. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 09:18:43 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 08:58:30 2009 Subject: [GHC] #1338: base package breakup In-Reply-To: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> References: <047.45d745a3053c83d2fddea61bbe99ae6a@localhost> Message-ID: <056.ed0c3e664089e367ad9381b86fc92af4@localhost> #1338: base package breakup ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 6.12 branch Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Comment (by igloo): I think it's strange that, given how much easier a "safe" Haskell should be compared to languages like PHP and perl, they have safe modes and we don't. Personally I think that we should definitely do something along those lines, although we should think carefully about what the options are, and what the best way to achieve it is; this strikes me as the sort of thing where it's possible to do a lot of work, and then realise that you've missed a corner. See also #1380. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 09:26:28 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 09:06:11 2009 Subject: [GHC] #3463: Binary: Int64 truncated to fit in 32 bit Int In-Reply-To: <043.f4b03d0a4f63af3d3dbcf70e049d415a@localhost> References: <043.f4b03d0a4f63af3d3dbcf70e049d415a@localhost> Message-ID: <052.166d70893162a45e44219099747dc345@localhost> #3463: Binary: Int64 truncated to fit in 32 bit Int -----------------------------------------+---------------------------------- Reporter: zeno | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: major | Resolution: Keywords: cabal install impossible | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by simonmar): * difficulty: => Unknown Comment: Is this cabal-install tree clean? Remove any old .hi files that might be lying around. We've seen reports like this before, but never quite got to the bottom of it. They only way I know it can happen is by mixing .hi files generated by a 64-bit GHC with a 32-bit GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 09:41:39 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 09:21:22 2009 Subject: [GHC] #3463: Binary: Int64 truncated to fit in 32 bit Int In-Reply-To: <043.f4b03d0a4f63af3d3dbcf70e049d415a@localhost> References: <043.f4b03d0a4f63af3d3dbcf70e049d415a@localhost> Message-ID: <052.d98c22e6f447505eecbba91014544ada@localhost> #3463: Binary: Int64 truncated to fit in 32 bit Int -----------------------------------------+---------------------------------- Reporter: zeno | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: major | Resolution: Keywords: cabal install impossible | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------+---------------------------------- Comment (by zeno): hurray rming Setup.hi fixed this! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 09:41:54 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 09:21:39 2009 Subject: [GHC] #3463: Binary: Int64 truncated to fit in 32 bit Int In-Reply-To: <043.f4b03d0a4f63af3d3dbcf70e049d415a@localhost> References: <043.f4b03d0a4f63af3d3dbcf70e049d415a@localhost> Message-ID: <052.6be4607b151bcd015ffb363584874c00@localhost> #3463: Binary: Int64 truncated to fit in 32 bit Int -----------------------------------------+---------------------------------- Reporter: zeno | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: major | Resolution: fixed Keywords: cabal install impossible | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | -----------------------------------------+---------------------------------- Changes (by zeno): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 11:15:42 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 10:55:24 2009 Subject: [GHC] #3456: Add FilePath -> String decoder In-Reply-To: <045.a4a219f70c8b7f70a278b60a06ef7b94@localhost> References: <045.a4a219f70c8b7f70a278b60a06ef7b94@localhost> Message-ID: <054.f2aac6138a45c108c8f5c58f97772fc6@localhost> #3456: Add FilePath -> String decoder ---------------------------------+------------------------------------------ Reporter: judahj | Owner: Type: proposal | Status: reopened 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 judah): * status: closed => reopened * resolution: duplicate => Comment: Actually, if it's all right with you I'd like to keep this ticket open, just for the discussion period of the proposal. I was aware of #3307; apologies for neglecting to reference it. I am of course influenced by your and Duncan's comments in that ticket and on mailing list. But I think it's useful to separate the two tickets: - This ticket denotes a specific proposal which follows the library submission procedure and should be accepted or rejected within the next two week (In particular, before 6.12.1). - #3307 is a bug report which I read as describing a path to a larger API change, and will probably stay open for a while (its milestone is set to 6.14.1). Accepting or rejecting this ticket is only a small step towards solving the larger !FilePath issue, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Aug 26 12:35:01 2009 From: trac at galois.com (GHC) Date: Wed Aug 26 12:14:47 2009 Subject: [GHC] #3456: Add FilePath -> String decoder In-Reply-To: <045.a4a219f70c8b7f70a278b60a06ef7b94@localhost> References: <045.a4a219f70c8b7f70a278b60a06ef7b94@localhost> Message-ID: <054.bb27005e7c5b0e4dd1f31d450376489c@localhost> #3456: Add FilePath -> String decoder ---------------------------------+------------------------------------------ Reporter: judahj | Owner: Type: proposal | Status: reopened 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 YitzGale): Replying to [comment:3 judah]: > #3307 is a bug report which I read as describing a path > to a larger API change, Well, it was when I submitted it. But after further discussion - in particular, Duncan's comments - it seems that until Haskell' we can't really do that. So all that is left to do for now is filePathToString and similar. Once we do that I think #3307 will be closed. Anyway, no problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 27 05:07:14 2009 From: trac at galois.com (GHC) Date: Thu Aug 27 04:46:56 2009 Subject: [GHC] #3465: Documentation for init in Prelude requires finite list Message-ID: <048.db8d722eaa5d04793b887d720d3f40fc@localhost> #3465: Documentation for init in Prelude requires finite list -----------------------------+---------------------------------------------- Reporter: MaxRabkin | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- The documentation for the init function at http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:init says that the argument to init must be finite. However, any implementation which actually makes use of this assumption is needlessly strict, so I don't see any reason to document the restriction finite lists. Instead, for infinite xs, it should be the case that init xs == xs (and this is what the current implementation does). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 27 07:03:06 2009 From: trac at galois.com (GHC) Date: Thu Aug 27 06:42:48 2009 Subject: [GHC] #3466: broken link in "ghc --help" Message-ID: <044.fed7374cf357455fd732384b04324661@localhost> #3466: broken link in "ghc --help" -----------------------------+---------------------------------------------- Reporter: bastl | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 6.10.3 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- ghc --help refers to http://www.haskell.org/ghc/documentation.html which doesnt exist atm. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 27 08:10:55 2009 From: trac at galois.com (GHC) Date: Thu Aug 27 07:50:34 2009 Subject: [GHC] #3467: GHC HEAD panics trying to splice a type Message-ID: <044.3bb6c981732c0f783366c3cd6fcdc2a5@localhost> #3467: GHC HEAD panics trying to splice a type -----------------------------+---------------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- This: {{{ {-# LANGUAGE TemplateHaskell #-} module Test where import Language.Haskell.TH import Foreign sizeq :: Name -> Q Exp sizeq n = [| sizeOf (undefined :: $(conT n)) |] }}} leads to {{{ ghc.EXE: panic! (the 'impossible' happened) (GHC version 6.11.20090823 for i386-unknown-mingw32): kcSpliceType }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Aug 27 17:07:46 2009 From: trac at galois.com (GHC) Date: Thu Aug 27 16:47: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.3e1ab54cd185c3ac2b34fb0cd7a9271b@localhost> #3408: idle GC causes large CPU usage if run more frequently than 1 second ---------------------------------+------------------------------------------ Reporter: JeremyShaw | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.12 branch Component: Runtime System | Version: 6.10.4 Severity: normal | Resolution: Keywords: idle GC | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by robgreayer): * cc: robgreayer@gmail.com (added) Comment: Perhaps related ... I've noticed a problem running GHCi on Windows; after loading a fairly complex set of modules, the 'idle' CPU usage of GHC can be quite high. After seeing this bug report, I tried setting the idle GC time to something other than its default, (e.g. ghci.exe +RTS -I1 -RTS ...) and the 'idle' CPU usage drops to 0. With idle GC = 0.3 (or unset), after initialization GHCi's idle CPU usage is about 2%. After loading a test case (Main module of frag-1.1.2, from hackage), it hovers at 15%-25%. With idle GC set to 1, in both cases idle CPU usage is 0%. (This is on XP SP2, Intel Core 2 Duo CPU 2.2Ghz). -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 28 00:07:55 2009 From: trac at galois.com (GHC) Date: Thu Aug 27 23:47:34 2009 Subject: [GHC] #3468: GHC panic: boxy_match_s Message-ID: <044.ef478f54ba5f4d944ccf7a1429e4456e@localhost> #3468: GHC panic: boxy_match_s -------------------------+-------------------------------------------------- Reporter: wkahl | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: critical Keywords: boxy_match_s | Testcase: Os: Linux | Architecture: powerpc -------------------------+-------------------------------------------------- I get, in two different modules in the same 100+ module project (different dependency ordering by ghc --make for different executables): {{{ ghc: panic! (the 'impossible' happened) (GHC version 6.10.4 for powerpc-unknown-linux): boxy_match_s }}} I found `boxy_match_s` as auxiliary function of `boxyMatchTypes` in `compiler/typecheck/TcUnify.lhs`, but, using {{{ find . -type f | xargs grep -n boxyMatchTypes /dev/null }}} , could not even find a call site of `boxyMatchTypes`! The LANGUAGE pragmas of the two modules: {{{ {-# LANGUAGE DeriveDataTypeable, FlexibleContexts, MultiParamTypeClasses, FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables, MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances #-} }}} (I do not consciously use impredicative types anywhere.) This occurred after I added additional type parameters (without fundeps) to intermediate type classes (with other fundeps) in larger class hierarchies, and performed lots of related changes. (`make clean` does not help.) Hoping that just the knowledge that this can happen leads to a fix... Wolfram -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 28 01:18:01 2009 From: trac at galois.com (GHC) Date: Fri Aug 28 00:57:38 2009 Subject: [GHC] #3468: GHC panic: boxy_match_s In-Reply-To: <044.ef478f54ba5f4d944ccf7a1429e4456e@localhost> References: <044.ef478f54ba5f4d944ccf7a1429e4456e@localhost> Message-ID: <053.ca335f6bbfa63a818f381959885c5562@localhost> #3468: GHC panic: boxy_match_s --------------------------+------------------------------------------------- Reporter: wkahl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: critical | Resolution: Keywords: boxy_match_s | Testcase: Os: Linux | Architecture: powerpc --------------------------+------------------------------------------------- Comment (by wkahl): Underlying this panic was apparently really a kind error, involving the existential constructor `Tool` that had been defined by {{{ data Tool = forall a r . (Typeable1 r, ToolC r a) => Tool a deriving Typeable }}} and is now defined by {{{ data Tool d = forall a r . (Typeable1 r, ToolC d r a) => Tool a deriving Typeable }}} in a context of a record field that still had type `Tool` (kind error) --- the .lhs-boot file had only {{{ data Tool }}} --- another kind error. Wolfram -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 28 02:21:46 2009 From: trac at galois.com (GHC) Date: Fri Aug 28 02:01:26 2009 Subject: [GHC] #3468: GHC panic: boxy_match_s In-Reply-To: <044.ef478f54ba5f4d944ccf7a1429e4456e@localhost> References: <044.ef478f54ba5f4d944ccf7a1429e4456e@localhost> Message-ID: <053.1c5f9a081ee75ee0fc187bb888d7d0b1@localhost> #3468: GHC panic: boxy_match_s --------------------------+------------------------------------------------- Reporter: wkahl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: Keywords: boxy_match_s | Testcase: Os: Linux | Architecture: powerpc --------------------------+------------------------------------------------- Changes (by wkahl): * severity: critical => minor Comment: Changed severity to minor: The kind error described in the previous comment was apparently the whole problem. I have not preserved the crashing state of my system. Wolfram -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 28 05:04:16 2009 From: trac at galois.com (GHC) Date: Fri Aug 28 04:43:55 2009 Subject: [GHC] #3417: Data.Array.IO.hGetArray should be implemented. In-Reply-To: <044.4fe87e98cecbfb577c4777a984e7c8b6@localhost> References: <044.4fe87e98cecbfb577c4777a984e7c8b6@localhost> Message-ID: <053.633121e8e1f852d52565d53e40c5794c@localhost> #3417: Data.Array.IO.hGetArray should be implemented. ----------------------------------+----------------------------------------- Reporter: int-e | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 6.12.1 Component: libraries (other) | 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: {{{ Thu Aug 27 05:19:21 PDT 2009 Simon Marlow * implement hGetArray/hPutArray (#3417) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 28 09:56:36 2009 From: trac at galois.com (GHC) Date: Fri Aug 28 09:36:13 2009 Subject: [GHC] #3461: loading package ghc in GHCI; unknown symbol `keepCAFs' In-Reply-To: <047.1df246ba131709d98697e64af64ff966@localhost> References: <047.1df246ba131709d98697e64af64ff966@localhost> Message-ID: <056.edb8c4fcadfb06c2c8e22afb3643c4a6@localhost> #3461: loading package ghc in GHCI; unknown symbol `keepCAFs' ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: 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 Aug 28 13:58:02 BST 2009 Simon Marlow * Fix #3461: protect the use of keepCAFs with #ifdef DYNAMIC }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 28 10:12:12 2009 From: trac at galois.com (GHC) Date: Fri Aug 28 09:51:49 2009 Subject: [GHC] #3461: loading package ghc in GHCI; unknown symbol `keepCAFs' In-Reply-To: <047.1df246ba131709d98697e64af64ff966@localhost> References: <047.1df246ba131709d98697e64af64ff966@localhost> Message-ID: <056.9afd3b9a50a49dcbef3d62ee67b18f6f@localhost> #3461: loading package ghc in GHCI; unknown symbol `keepCAFs' ---------------------------------+------------------------------------------ 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: | 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 Aug 28 11:43:43 2009 From: trac at galois.com (GHC) Date: Fri Aug 28 11:23:21 2009 Subject: [GHC] #3469: Error open file if name contain national symbol Message-ID: <044.8fe343c9395559f39f0fa1d947291b8a@localhost> #3469: Error open file if name contain national symbol --------------------+------------------------------------------------------- Reporter: Tonal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- Os Windows Vista Home Basic Ru + sp2 Steps 1. Haskell code (bug.hs in utf-8): {{{ main = do con <- readFile "????.txt" print con }}} 2. Console session: {{{ C:\Lang\test>ghc -O3 --make bug.hs C:\Lang\test>echo asdf>????.txt C:\Lang\test>bug.exe bug.exe: DK20.txt: openFile: does not exist (No such file or directory) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 28 13:31:33 2009 From: trac at galois.com (GHC) Date: Fri Aug 28 13:11: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.7219eaab54042b67962b49fbdd165cb9@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 ChrisKuklewicz): * cc: ghc2965@mightyreason.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 28 14:57:34 2009 From: trac at galois.com (GHC) Date: Fri Aug 28 14:37:10 2009 Subject: [GHC] #3200: System.Environment.withProgName strips everything before the last slash In-Reply-To: <044.6c7a0324fd6d877811b6a46ca881b0e2@localhost> References: <044.6c7a0324fd6d877811b6a46ca881b0e2@localhost> Message-ID: <053.07ae8a05ebf17fe48c8294fc04a02476@localhost> #3200: System.Environment.withProgName strips everything before the last slash ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: reopened Priority: normal | Milestone: 6.12.1 Component: libraries/base | Version: 6.10.2 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | ---------------------------------+------------------------------------------ Changes (by guest): * status: closed => reopened * resolution: wontfix => Comment: I saw #3199 and it didn't mention `withProgName`. `withProgName` is not part of H98 `System`. All I have to go by is the `System.Environment` documentation, which doesn't match the behavior of the function. This is clearly a bug; either the code or the documentation is wrong (or maybe both). I don't understand why this is ''wontfix''. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 28 17:52:42 2009 From: trac at galois.com (GHC) Date: Fri Aug 28 17:33:15 2009 Subject: [GHC] #3470: OSX installer should give an informative error message when XCode is missing Message-ID: <053.606cf8b25459ae2fb498c9543397706e@localhost> #3470: OSX installer should give an informative error message when XCode is missing ---------------------------+------------------------------------------------ Reporter: GregoryCollins | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: MacOS X | Architecture: x86 ---------------------------+------------------------------------------------ A bug was reported on the haskell-platform trac about this: when Xcode is not installed, the OSX installer shows a blank screen with a greyed-out "Install" button. An informative message should be displayed instead. More details (incl. screenshots) here: http://trac.haskell.org/haskell-platform/ticket/67 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Aug 28 21:36:31 2009 From: trac at galois.com (GHC) Date: Fri Aug 28 21:16:07 2009 Subject: [GHC] #3468: GHC panic: boxy_match_s In-Reply-To: <044.ef478f54ba5f4d944ccf7a1429e4456e@localhost> References: <044.ef478f54ba5f4d944ccf7a1429e4456e@localhost> Message-ID: <053.20719a061e99e4073821423da49af719@localhost> #3468: GHC panic: boxy_match_s --------------------------+------------------------------------------------- Reporter: wkahl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: Keywords: boxy_match_s | Testcase: Os: Linux | Architecture: powerpc --------------------------+------------------------------------------------- Comment (by wkahl): The `boxy_match_s` panic must have come from `TcUnify.boxy_match`, in the following case: {{{ go (TyConApp tc1 tys1) (TyConApp tc2 tys2) | tc1 == tc2 , not $ isOpenSynTyCon tc1 = go_s tys1 tys2 }}} Probably the two arguments came from the unchanged .lhs-boot file and from the changed .lhs file, so `tys1` and `tys2` had different lengths. Since this is still under the heading "Approximate boxy matching", I'd guess you may want to either check for the length here where you are closer to the reason of the failure, or just return `subst` instead of panic in `boxy_match_s`, and in either case let the error be caught by some non-approximate pass. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 29 00:51:48 2009 From: trac at galois.com (GHC) Date: Sat Aug 29 00:31:23 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 Message-ID: <049.cf9489a341286e2ed7b3a5f6baf71d74@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: new Priority: normal | Component: Build System Version: 6.10.4 | Severity: normal Keywords: configure | Testcase: Os: Unknown/Multiple | Architecture: x86 -----------------------------+---------------------------------------------- The environment is a Mac with 10.6 running in 64-bit mode but with a ghc that was built under 10.5. Running configure produces the following output: {{{ $ ./configure --prefix=/Users/prb/opt/localchecking build system type... i386-apple-darwin10.0.0 checking host system type... i386-apple-darwin10.0.0 checking target system type... i386-apple-darwin10.0.0 Canonicalised to: i386-apple-darwin checking for ghc... /Users/prb/opt/local/bin/ghc checking version of ghc... 6.10.1 checking for nhc... no checking for nhc98... no checking for hbc... no checking for ld... /usr/bin/ld checking for path to top of build tree... /var/folders/V+/V+RuS+kKF50QvE4Dmj4MPE+++TI/-Tmp-/ghc19350_0/ghc19350_0.s:144:0: suffix or operands invalid for `push' /var/folders/V+/V+RuS+kKF50QvE4Dmj4MPE+++TI/-Tmp-/ghc19350_0/ghc19350_0.s:189:0: suffix or operands invalid for `push' /var/folders/V+/V+RuS+kKF50QvE4Dmj4MPE+++TI/-Tmp-/ghc19350_0/ghc19350_0.s:892:0: suffix or operands invalid for `push' /var/folders/V+/V+RuS+kKF50QvE4Dmj4MPE+++TI/-Tmp-/ghc19350_0/ghc19350_0.s:941:0: suffix or operands invalid for `push' /var/folders/V+/V+RuS+kKF50QvE4Dmj4MPE+++TI/-Tmp-/ghc19350_0/ghc19350_0.s:967:0: 32-bit absolute addressing is not supported for x86-64 /var/folders/V+/V+RuS+kKF50QvE4Dmj4MPE+++TI/-Tmp-/ghc19350_0/ghc19350_0.s:967:0: cannot do signed 4 byte relocation /var/folders/V+/V+RuS+kKF50QvE4Dmj4MPE+++TI/-Tmp-/ghc19350_0/ghc19350_0.s:970:0: 32-bit absolute addressing is not supported for x86-64 /var/folders/V+/V+RuS+kKF50QvE4Dmj4MPE+++TI/-Tmp-/ghc19350_0/ghc19350_0.s:970:0: cannot do signed 4 byte relocation ./configure: line 3211: utils/pwd/pwd: No such file or directory configure: error: cannot determine current directory }}} Changing this to the usual pwd commands makes the configure run complete, but make fails immediately with a similar trace. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 29 01:02:26 2009 From: trac at galois.com (GHC) Date: Sat Aug 29 00:42:00 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.364d6edd250607ada9ebabc97ebf51ba@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: new Priority: normal | Milestone: Component: Build System | Version: 6.10.4 Severity: normal | Resolution: Keywords: configure | Testcase: Os: Unknown/Multiple | Architecture: x86 ------------------------------+--------------------------------------------- Comment (by paulrbrown): Seems related to #3400 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 29 01:49:32 2009 From: trac at galois.com (GHC) Date: Sat Aug 29 01:29:07 2009 Subject: [GHC] #3472: Porting through .hc files seems broken (seems general but parts of it may be osx-specific) Message-ID: <046.fbcd146ac7544c3ae31be3ef2ccbd0d8@localhost> #3472: Porting through .hc files seems broken (seems general but parts of it may be osx-specific) -----------------------------+---------------------------------------------- Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.11 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I've been trying repeatedly over the past week or two to get an x86_64 build of GHC for OS X, by going through the procedure described at http://hackage.haskell.org/trac/ghc/wiki/Building/Porting. I've encountered several problems, and the process is huge and daunting so it's hard to say exactly what's a real error and what causes the breakage, but I'll try to describe what I've seen so far. I've been treating the x86_64 unregistered build as a .hc port, so I effectively partitioned my box into two machines, one with a gcc that compiles to i386 by default and the other with one for x86_64. I follow the instructions on the page above and first generate the headers describing the 64-bit machine with the 64-bit compiler, then I copy them into another ghc tree, switch the gcc to i386 default, and do a build that keeps its .hc files. Most of it goes fine, and then I start getting massive errors about the assembly output being incorrect (which should be fine because all I want are the .hc files). So I follow the make -k and ignore the errors (although this is rather nerve-wracking as instructions saying "just ignore any errors" seem rather fragile). I then build the tarball with all the .hc files in it and unpack it in the other tree. Now, I switch the gcc back to default x86_64, and go through the rest of the process described. My first issue is that the FB_ macro is inserting --- BEGIN --- explicitly into my assembly. This feels odd, as I'm doing an unregistered build. It seems that somehow the MINI_INTERPRETER macro and NO_REGS aren't getting defined, so the pre-mangler stuff is getting inserted into my assembly. I add -Ds for those to my build.mk and resume. This goes smoothly for a while, and then I encounter an error: make[1]: *** No rule to make target `rts/dist/build/Apply.o', needed by `rts/dist/build/libHSrts.a'. Stop. I check the rts directory and indeed there is an Apply.hc file in there. So I guess the build system forgot that .hc files produce .o files in the case of the rts. Maybe it's missing a .hc.o rule or something, so I tried to figure out the build system files but wasn't able to convince it to build the .hc files. I then emulated the gcc parameters used for other rts .c and .s files and compiled all the .hc files in the RTS myself. So I resume the make and it seems satisfied until it tries to build the rts in a different way (v, instead of l). Again, I compile all the .hc files by hand, and set the make on its merry way again. Now I run into my real problem. It goes to build genprimopcode and doesn't know how to do it. I check utils/genprimopcode and indeed there are no .hc files in there. I jump back to my other tree (the one that produced the .hc files) and manually (guessing on the ghc command-line) ask it to produce all the .hc files for me, first calling alex and happy for the grammar. I copy these .hc files over and resume the build. It happily accepts my .hc files, but then when it goes to link genprimopcode, I get a ''massive'' list of missing symbols. These included things like: _base_GHCziShow_showSignedInt1_closure _stg_CAF_BLACKHOLE_info _integerzmgmp_GHCziIntegerziType_Szh_static_info So this seems to imply that it's trying to build an executable for genprimopcode, and it wants the rts (surprise), base, and integer-gmp linked to it. However, the command-line used to link genprimopcode is: "gcc" -o utils/genprimopcode/dist/build/tmp/genprimopcode -O -m64 -g -O0 -DNO_REGS -DUSE_MINIINTERPRETER utils/genprimopcode/dist/build/Lexer.o utils/genprimopcode/dist/build/Main.o utils/genprimopcode/dist/build/ParserM.o utils/genprimopcode/dist/build/Parser.o utils/genprimopcode/dist/build/Syntax.o ... no linker flags at all, beyond the .o files! I'm not sure how this is supposed to ever link correctly with no rts or libraries. So I take that command-line for gcc and add to it from my 64-bit build tree until I get it to link (it ended up being a massive command-line, so I won't include it here). My built genprimopcode seemed to work, and displayed the help message when I ran it, but when I actually piped real primop specs into it, it segfaulted (in iconv, somehow). I gave up on making my own genprimopcode, and under the assumption that it wasn't excessively platform-dependent, I asked someone to give me the various genprimopcode from their linux x86_64 platform. This may have been misguided but I don't know enough about the process to know better. Anyway, with these files, it gave up on trying to build genprimopcode and went along happily through the build. In the final linkage step for stage2, producing the final ghc binary, I got another massive linker error. Again, I tinkered with its command-line until I got it to link correctly (lots of strange things missing there too, including the PrelIOUtils.o which I had to link in myself for some reason, and something defining __hscore_long_path_size, which I wrote a simple c file for). So anyway, the resulting ghc, somewhat unsurprisingly, segfaulted immediately (in Data.List.last, for what it's worth). ghc +RTS --info did work however, and printed out the expected stuff, so not everything was broken. So anyway, I'm sorry for this rambling "bug report" but I'm not sure what to do, and I've been through the above process (with minor variations and experiments) about 5 times so far, so I'm pretty sure I'm following the instructions correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 29 05:01:33 2009 From: trac at galois.com (GHC) Date: Sat Aug 29 04:41:08 2009 Subject: [GHC] #3473: System.Posix.Semaphore shouldn't create finalizers with Foreign.newForeignPtr Message-ID: <043.f9c52d751ae0cc6e4a228d8481612eb9@localhost> #3473: System.Posix.Semaphore shouldn't create finalizers with Foreign.newForeignPtr -------------------+-------------------------------------------------------- Reporter: kaol | Owner: Type: bug | Status: new Priority: normal | Component: libraries/unix Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86 -------------------+-------------------------------------------------------- Running this program {{{ import System.Posix.Semaphore main = do s <- semOpen "c" (OpenSemFlags True False) 0666 1 semThreadWait s v <- semGetValue s putStrLn "Type!" a <- getLine putStrLn $ "OK, " ++ a semPost s }}} fails like this: {{{ Type! abc OK, abc sem: error: a C finalizer called back into Haskell. This was previously allowed, but is disallowed in GHC 6.10.2 and later. To create finalizers that may call back into Haskll, use Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr. }}} The attached patch for libraries/unix/System/Posix/Semaphore.hsc should fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 29 10:55:45 2009 From: trac at galois.com (GHC) Date: Sat Aug 29 10:35:25 2009 Subject: [GHC] #3400: OS X: ghc broken on Snow Leopard In-Reply-To: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> References: <042.42f8ee6f478d8beecc65fea9d7e2b0b4@localhost> Message-ID: <051.a5ba9b3aff0b35abc408aa4ff3fa433a@localhost> #3400: OS X: ghc broken on Snow Leopard -------------------------+-------------------------------------------------- Reporter: bbb | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: critical | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86 | -------------------------+-------------------------------------------------- Comment (by Syzygies): I'm posting some links of interest, for the many of us finding this ticket on Snow Leopard's release day. This ticket is closely related to ticket #2965 (new feature request) [http://hackage.haskell.org/trac/ghc/ticket/2965 GHC on OS X does not compile 64-bit] One can show one's support for this request by adding one's email to its cc: list. There is an active Haskell Cafe thread, with more detailed directions on the fix given here: [http://www.nabble.com/Snow-Leopard-Breaks-GHC-td25198347.html Snow Leopard Breaks GHC] One sees comments elsewhere, e.g. on reddit posts, to the effect of "aren't most OS X users just 2 core tourists on 2 GB MacBooks"? Meanwhile, as GHC emerges as the only credible choice for a parallel language (add a couple of lines of code, and it ''just works''), what I've seen makes OS X appear to be the only credible choice for a parallel operating system: [http://www.haskell.org/pipermail/glasgow-haskell- users/2009-April/017050.html No "last core parallel slowdown" on OS X] OS X self-identifies as a 64-bit operating system, yet GHC support is limited to 32-bits. It would be nice if there was a status somewhere between (closed) and (new feature request) in tone, that recognized the outdated state of GHC support for OS X. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Aug 29 17:47:31 2009 From: trac at galois.com (GHC) Date: Sat Aug 29 17:27:04 2009 Subject: [GHC] #3474: Add a strict variant of iterate to Data.List Message-ID: <042.bc77ff9ff29dd43eef3ac3d04a1524ac@localhost> #3474: Add a strict variant of iterate to Data.List -----------------------------+---------------------------------------------- Reporter: mux | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/base Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- I suggest adding a strict variant of the iterate function to the Data.List module, as others seem to have had a need for it too. It is useful when you want to repeatedly apply a function a large number of times and get the final result. Using the standard iterate function in this way results in the whole list being held in memory, as exemplified in the following GHCi session (code compiled with -O2 behaves similarly): > let f = (+1) in iterate f 0 !! 10000000 *** Exception: stack overflow Using a strict variant of iterate seems to be sufficient for this code to run in O(1) memory: > let iterate' f x = x `seq` x : iterate' f (f x) > let f = (+1) in iterate' f 0 !! 10000000 10000000 I have no idea if this is something that could/should be detected by the strictness analyzer; that would obviously be preferable if it is indeed possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 30 04:12:11 2009 From: trac at galois.com (GHC) Date: Sun Aug 30 03:51:43 2009 Subject: [GHC] #3475: bump base version to 5, add base4-compat Message-ID: <047.4e76c774049ade104ab88a36737a01ed@localhost> #3475: bump base version to 5, add base4-compat -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: task | 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 -------------------------------+-------------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 30 05:31:03 2009 From: trac at galois.com (GHC) Date: Sun Aug 30 05:10:34 2009 Subject: [GHC] #3476: Compiler warning about non-exhaustive pattern match with GADT and type-signature Message-ID: <053.d13bf6f894f1cc3c85b9d23db6b510dc@localhost> #3476: Compiler warning about non-exhaustive pattern match with GADT and type- signature ---------------------------+------------------------------------------------ Reporter: Ashley Yakeley | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: x86_64 (amd64) ---------------------------+------------------------------------------------ This program: {{{ {-# OPTIONS -Wall #-} {-# LANGUAGE GADTs #-} module Bug where data T n where BoolT :: T Bool IntT :: T Int f :: T Bool -> Int f BoolT = 3 }}} ...gives this warning {{{ $ ghc -c Bug.hs Bug.hs:10:4: Warning: Pattern match(es) are non-exhaustive In the definition of `f': Patterns not matched: IntT }}} The pattern match is, in fact, exhaustive, given the type signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 30 07:52:43 2009 From: trac at galois.com (GHC) Date: Sun Aug 30 07:32:16 2009 Subject: [GHC] #3341: encoding errors could be handled better In-Reply-To: <045.aacea9ec15561126d540765d32ffcd87@localhost> References: <045.aacea9ec15561126d540765d32ffcd87@localhost> Message-ID: <054.0bb484a71018be8a27ecbb635b6ef66c@localhost> #3341: encoding errors could be handled better -------------------------------+-------------------------------------------- Reporter: judahj | Owner: 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: MacOS X Architecture: x86 | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed (but I got the ticket number wrong in the log message :-() {{{ Sun Aug 30 00:59:09 PDT 2009 Simon Marlow * Fix #3441: detect errors in partial sequences }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 30 17:55:58 2009 From: trac at galois.com (GHC) Date: Sun Aug 30 17:35:55 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.319210daca468f74d0afef6b28f9d0fd@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 tadr): * cc: thomasdrake1@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 30 19:08:25 2009 From: trac at galois.com (GHC) Date: Sun Aug 30 18:47:54 2009 Subject: [GHC] #3477: Haskell Platform install failed on Ubuntu on mtl package Message-ID: <044.c079cdf85227aab7df80300d952755a3@localhost> #3477: Haskell Platform install failed on Ubuntu on mtl package -------------------+-------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple -------------------+-------------------------------------------------------- I had just installed the latest version of ghc6 (6.10.4) as required by the haskell platform and I have been unable to get it to build properly. I'm not sure if I have any more details that I can offer that are relevant. As the error message told me to report this as a bug, I did. Failure occurred with the following text: "./Setup" "register" "--inplace" Registering mtl-1.1.0.2... Reading package info from "dist/inplace-pkg-config" ... done. Writing new package config file... done. Building mtl-1.1.0.2 "/usr/bin/ghc" "--make" "Setup" "-o" "Setup" "-package" "Cabal-1.6.0.3" 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 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Error: Compiling the Setup script failed make: *** [build.stamp] Error 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Aug 30 19:26:33 2009 From: trac at galois.com (GHC) Date: Sun Aug 30 19:06:01 2009 Subject: [GHC] #3477: Haskell Platform install failed on Ubuntu on mtl package In-Reply-To: <044.c079cdf85227aab7df80300d952755a3@localhost> References: <044.c079cdf85227aab7df80300d952755a3@localhost> Message-ID: <053.fc8932740170d0000c5917dcba3b1026@localhost> #3477: Haskell Platform install failed on Ubuntu on mtl package ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ----------------------+----------------------------------------------------- Comment (by guest): Forgot to mention: the machine I'm using is a 32-bit laptop, though I've seen about the same problem on my 64 bit desktop. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 31 11:35:08 2009 From: trac at galois.com (GHC) Date: Mon Aug 31 11:14:35 2009 Subject: [GHC] #3478: ghc.exe doesn't work Message-ID: <044.ef537b15bcf446bdfd601d48316f603f@localhost> #3478: ghc.exe doesn't work --------------------+------------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 6.10.4 | Severity: normal Keywords: ghc.exe | Testcase: Os: Windows | Architecture: Unknown/Multiple --------------------+------------------------------------------------------- Installed ghc.exe doesn't executed at all. I can see a window (cmd.exe) but it disappears in a moment, and I can type nothing. However ghci.exe is working well. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 31 12:04:01 2009 From: trac at galois.com (GHC) Date: Mon Aug 31 11:44: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.38e79be5b6b322e19c2cdbeaabe8311d@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 amock): * cc: amock@cse.unl.edu (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 31 13:04:18 2009 From: trac at galois.com (GHC) Date: Mon Aug 31 12:44:22 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.9796a15bb874cf0b8d1a5050cfa4ef62@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 spl): * cc: leather@cs.uu.nl (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 31 15:38:53 2009 From: trac at galois.com (GHC) Date: Mon Aug 31 15:18:20 2009 Subject: [GHC] #3477: Haskell Platform install failed on Ubuntu on mtl package In-Reply-To: <044.c079cdf85227aab7df80300d952755a3@localhost> References: <044.c079cdf85227aab7df80300d952755a3@localhost> Message-ID: <053.551fdf46d439a5886192e79b44fb06a1@localhost> #3477: Haskell Platform install failed on Ubuntu on mtl package ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Severity: normal | Resolution: invalid Keywords: | Testcase: Os: Linux | Architecture: Unknown/Multiple ----------------------+----------------------------------------------------- Changes (by kaol): * status: new => closed * resolution: => invalid Comment: First, the fix: remove any old .hi and .o files that you have left around. Despite the error message, this doesn't have anything to do with GHC itself. As for the cause, this is fallout from a Debian workaround for .haddock files using GHC's Binary types, which use, as default, 32 bit integers on 32 bit architectures and 64 bit integers on 64 bit architectures. I first patched GHC to use 32 bit ints in Binary on all architectures and later changed that to 64 bits on all architectures. This has left files that are incompatible across versions on users' file systems with no easy way to remove those. Sorry for the inconvenience. I know that there could have been a better way to handle the situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Aug 31 17:48:49 2009 From: trac at galois.com (GHC) Date: Mon Aug 31 17:28:15 2009 Subject: [GHC] #3479: Build from source fails with variables passed to configure Message-ID: <044.9b3cb4d5f450e5790f2e39cb68bcc8bf@localhost> #3479: Build from source fails with variables passed to configure -----------------------------+---------------------------------------------- Reporter: atler | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 6.10.4 | Severity: normal Keywords: | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -----------------------------+---------------------------------------------- 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 Mon Aug 31 18:56:43 2009 From: trac at galois.com (GHC) Date: Mon Aug 31 18:36:48 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.4f00c4c6599260339e37ce1653483dad@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: emertens@galois.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler